Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
55 : Summary of the Specification This chapter presents an overview of the recommended transactional data specification. The objective of the specification is to (1) establish the common language that entities use to communicate with each other; and (2) provide the technical approach for how that data communication will occur among the inter-operating computer systems. The chapter covers the following areas. â¢ Definitions for key terms and concepts are presented. â¢ The telegram paradigm, a critical concept in the proposed specification, is explained. â¢ Specific telegrams contained in the specification are described. In total, there are 11 telegrams, and four of them are selected for detailed description in this chapter. â¢ Potential approaches to implementing specification-compliant data communication are presented. This pertains to how data is transmitted among entities and how the system validates that the transmitted data complies with the specification. A control module approach is recommended for the specification. â¢ Other data considerations necessary for government-funded transportation services, such as ADA paratransit service. â¢ A short discussion of data structures is presented. Additional detail on the specifications may be found in appendices 5 and 6. 4.1 Key Concepts The proposed transactional data specification is organized around messagesâand specifically, a set of agreed upon message typesâand data elements, as defined below. Messages can be of many different message types, with each type designed to perform a specific function with respect to the transmission and/or exchange of data among inter-operating parties. These messages will be referred to formally as âtelegramsâ when appropriate in this chapter. For example, there may be a message type to send a trip request to one or more service providers and another message type to send trip-specific data (e.g., passenger name and pickup location) to a device in a vehicle. These are key concepts that this chapter will use: â¢ Telegrams: different types of messages designed to transmit specific transactional requests and acceptance/confirmation of these requests. (âMessage typeâ is a generic synonym for a specific type of telegram; âmessageâ is a synonym for an individual telegram; both of these sets of terms are used interchangeably in the remainder of this chapter.) â¢ Data Elements: the specific data items contained in each message that collectively communicate all of the necessary information needed for the recipient of the message to act upon it appropriately with respect to the specific request from the transmitter of the message. â¢ Data Communication Approach: the specific mechanism by which system to system (âmachine-to-machineâ) data communication occurs so that messages are reliably transmitted from requestor to recipient(s)/respondent(s) to enable transactions to occur. â¢ Specification Validation Approach: the means by which the syntax of messages and their data elements are determined to meet the requirements of the specification and the
56 confirmation or rejection of the validity of these messages is transmitted to the transmitter and/or recipient(s) of the messages. 4.2 Telegram Paradigm for DRT Trips This report refers to message types and their corresponding data elements as âtelegrams.â This term comes from SUTI data standard developed in Sweden and used in Nordic countries. There can be many different types of telegrams. Telegrams are sent from one party to anotherâor more precisely, from the computer system of one party to the computer system of the other partyâto advance a transaction involving a passenger trip. All valid telegrams are comprised of a pre- defined message type whose message contents must include all of the data elements required for that type of message. It may include valid optional data elements as well. Key characteristics of telegrams are as follows: â¢ Telegrams have a defined structure â¢ Telegrams have a specific vocabulary â¢ Telegrams encompass all essential steps in the trip ordering and trip execution process â¢ Telegrams imply a request-response approach to data communication concerning transactions It is important to emphasize that this proposed specification is based upon a strict request-response approach to transactional data flow. In contrast, the more loosely coupled API-based schemes that are often used in contemporary system to system (or application-to-application) data communication typically do not enforce a consistent, accurate view of the state of a transaction across the systems. (Of course, such API-based approaches use their own form of request-response data communication to return data to a system that requests some action from another system that may involve a transaction or knowledge of a transactional state.) As discussed in Chapter 2, while the open API approach has many virtues, it places the responsibility for transactional certainty on each entity in the process. Each system maintains its own internal view of the status of the transaction, and while this transactional state can usually be discovered by the other system as necessary, there is no standard method for categorizing this transactional state. In contrast, the request/response approach recommended by this specification enforces certainty in transactional data flow and makes possible a standard approach to knowing the state of a transaction. Given the relatively undeveloped status of transactional data interaction in the demand responsive transportation sector in the United States, it is prudent to begin with a specification approach that verifies that each step in the transactional data flow has in fact occurred and which enables an application to know the current status of the transaction using a standardized categorization approach and vocabulary. 4.2.1 Process of a DRT Transaction At different stages in the transactional process of a DRT trip, the primary focus of the transactional data might be the: â¢ Rider: the individual wishing to make the trip; â¢ Entity taking the trip order: this could be the service provider itself or an organization that organizes the service but does not actually operate it, including brokers such as are common in Medicaid, or even a trip exchange;
57 â¢ Service scheduling entity: the service provider or an organization that handles vehicle scheduling and routing for one or more service providers and instructs them on how to deliver service; â¢ Service provider and/or vehicle performing the trip order: with a specific focus on the trip delivery information; â¢ Payer/funder: organization that pays for the trip, could include the traveler indirectly. Figure 4-1 shows the process for typical DRT transactions. Each time that information crosses a line in Figure 4-1, a telegram must be sent containing the data necessary to advance the transaction to the next step. (âPlanningâ in this diagram includes Passenger Request and Booking.) Moreover, the transactional flow is not simply one-directional as the figure may suggest (from planning through execution and payment), but also includes exchanges of information (data) that go both ways. The telegrams presented in Section 4.4 of this chapter represent the minimum information needed for requesting and confirming activities among the entities while covering all essential steps from ordering to executing a trip. Note that certain internal activities of the service provider may not be included in the transactional specifications as they are relevant only to that entity. Figure 4-1: DRT Trip Process from Initial Request to Execution and Payment For each scenario (or âuse caseâ) in which the specification is employed, the interacting computer systems use the telegrams to communicate the data that informs each system of what the other system is requesting or offering or confirming. From a functional perspective, the basic use case for a transaction has four steps. 1. Requested tripâa request (or order) for transportation from the tripâs pickup address to the drop-off address with information about pickup and/or drop-off time requirements and any customer mobility aid needs 2. Confirmed orderâorder assignment specifying which means of transportation (e.g., wheelchair accessible vehicle required) will be used and the service level for the customer (e.g., acceptable waiting time for service) 3. Route/trip taskâdescription of the vehicle schedule/route to be performed by the vehicle including expected arrival times at stops
58 4. Completed jobâdata on actual trip pickup and delivery details, to be returned for financial settlement and operational quality assessment From this perspective, there is no requirement to transmit customer-identifying information, simply functional requirements and a set of tasks to be performed on behalf of customer requests. (Basic customer identifying data such as name will eventually be included in the data messages, but such data is not essential to advance the transactions prior to actual service execution.) The basic data elements needed to support these functional requirements are shown in Figure 4-2. Figure 4-2: Basic Data Elements Needed for the DRT Trip Process The telegrams enable the computer systems to move through the transactional steps summarized above; this is described and shown in terms of process flow in Section 4.3 below. Some steps require a transaction to take place between the entity ordering the trip (possibly an application used directly by the trip maker) and the transportation service provider or other entities; others might be messages communicated between two service providers or between a provider database and the vehicleâs mobile data terminal/in-vehicle device that hosts an application that directs the driverâs activities for delivering service to the rider. 4.2.2 Required versus Optional Data Elements Telegrams describe each step in the process of ordering and executing a DRT trip. There are a large number of data elements that could be included in the different steps of this process, but many of the possible data items apply only in specific circumstances or for certain rider types. For this reason, the telegrams include a comprehensive set of potentially relevant data items, but most are not mandatory. Each service provider and DRT software system must determine which optional data elements are necessary to inter-operate with its own system. Business relationships and system requirements determine which data elements must be exchanged in specific transactional settings and are not the focus of the specification. Rather, the intent of the
59 Client: Individual or entity associated with the trip request Service Provider: Organization that provides the trip (typically a transit agency or a company under contract) Vehicle Node: Vehicle and driver assigned by the service provider to complete trip Figure 4-3: Senders/Receivers of Telegrams specification is to provide the functional scope within which a wide range of entities can exchange transactional data to support inter-operability among their technology systems for their specific organizational purposes involving demand responsive transportation. For example, a typical TNC rider orders a trip by indicating the tripâs origin, destination, number of passengers and desired level of service, e.g., exclusive use of the vehicle with the quickest possible response time or shared use of the vehicle with a willingness to wait as much as 15 to 20 minutes to be picked up. In this booking process, little information is provided about the rider. In contrast, a non-emergency medical transportation (NEMT) service provider does not provide the customer with any options about its level of service, but it often needs information regarding special needs and mobility aids to send the appropriate vehicle and driver for a specific customer. In addition, the entity booking the trip typically wants to know the time of the medical appointment, as arriving too early imposes inconvenience on the customer and arriving late may cause the appointment to be cancelled by the health care provider. Moreover, some NEMT providers may require more information about customer trips than others, and different NEMT service organizers may request more or less customer or trip information: for example, a customer might be expected to pick up prescription medication on the return trip from an appointment. The decisions about which data elements are essential for all trips and which are optional can be left up to the groups establishing business rules for interaction on one or more multi-service provider, multi-ordering system clearinghouses. The specification is not designed to support any one approach to how different inter-acting entities organize themselves to enable the ordering, delivery, and payment of demand responsive transportation services. As emphasized at the beginning of the chapter, the objective of the specification is to simply (1) establish the common language that entities use to communicate with each other; and (2) provide the technical approach for how data communication will occur among the inter-operating computer systems. 4.3 Telegram Descriptions and Typical Data Flow The proposed transactional data specification is based upon the request-response model (as described in Chapter 2) using a set of telegrams. Telegrams are described in terms of the relevant parties sending or receiving each telegram, which are defined in Figure 4-3. .
60 There are 11 telegrams in the proposed specification, covering five basic activities. Note that the numbering of the telegrams is designed to describe not only the activity but also the path the messages follow; this provides informs one about which telegram to expect next. Not all messages are used in each transaction. Table 4-1 lists each telegram and describes the basic activities linked to each activity. Activity Task Accomplished and Flow of Information Telegram Planning Request Trip (rider/client to service provider) Telegram 1-A Confirm Trip Request (service provider to client/rider) Telegram 1-B Confirm Scheduling Details Confirm Order (client/rider to service provider) Telegram 2A Rider Details (optional) (client/rider to service provider) Telegram 2A1 Confirm Trip Scheduled (service provider to client/rider) Telegram 2B Confirm Vehicle (optional) (service provider to client/rider) Telegram 2BB Schedule Vehicle Route/Trip Task Information (service provider to vehicle) Telegram 3A Confirm Route/Trip Task (vehicle to service provider) Telegram 3B Trip Completion Completed Job Data (service provider to client/rider) Telegram 4A Completed Job Confirmation (service provider to client/rider) Telegram 4B Reporting Vehicle Performance Information (vehicle to service provider) Telegram 5 Table 4-1: Telegrams and Their Roles All 11 telegrams are needed to encompass the full set of core functional needs for a demand responsive transportation transaction. Over time, additional telegrams can be added as participants wish to add more detail for certain aspects of transactions. Figure 4-4 (next page) illustrates the flow of telegrams among the ordering client (the individual or agency requesting a trip), the transportation service provider, and the vehicle delivering the trip. Decisions on the telegram structure depend on how the actors involved in the specification process wish to organize the data flow and the transactions. For example, the SUTI standard discussed in Chapter 3 has 71 telegrams to handle every detailed aspect of its transactions. In part, this is due to the history of DRT service in Sweden, which was frequently built around taxi services. The public agency trip booking software was commonly distinct and separate from the software used by taxi companies that handled their vehicle operations and customer interface. As a consequence, it was necessary to have numerous telegrams to enable data flow amongst all of the different software systems and components involved in trip booking, vehicle scheduling, trip dispatching, and driver communications. In the contemporary DRT context, this level of transactional disaggregation is much less essential. That is due to the greater convergence of functionalitiesâ and greater data integration among component technologiesâin the technology systems used by service organizers and providers currently compared to two decades ago when the SUTI standards were initially established.
61 Telegram 1A Request a Trip Provider VehicleOrdering Client Telegram Flow Telegram 1B Trip Request Response Telegram 2B Confirm Trip Scheduled Telegram 2BB Vehicle Confirmation Telegram 3A Vehicle Trip Task Telegram 4A Completed Trip Data Telegram 2A Order Confirmation Telegram 2A1 Customer Information Telegram 3B Confirm Trip Task Telegram 5 Vehicle Current Status Telegram 4B Confirm Trip Data Received and Payment Status Figure 4-4: Telegram Flow
62 Appendix 5 provides detailed descriptions of each of the 11 telegrams and the data elements that are included in the recommended transactional specification. Appendix 5 also includes the XML description of each telegram. 4.4 Examples of Telegrams The following portion of this chapter provides a discussion of four of the 11 telegrams to illustrate how they work. The first sample telegram is to request a trip, the second is to confirm the trip request, the third is to send trip information, and the fourth example is the telegram used to confirm trip completion. Sample Telegram 1: Request a Trip The first step is to request a trip. The trip could be requested directly by the rider, or an organization (such as a human service agency) may request the trip on behalf of the rider. This request is described by data elements in Telegram 1:A shown in
63 Table 4-2 : The number of data elements would depend on the rider and/or provider needs. For this telegram (and all others presented in this chapter), a YES or NO in the âMandatoryâ column indicates whether this is one of the minimum required data elements needed to conduct a transaction. Some entities may require one or more of the additional, non-mandatory data elements to be included in the actual telegram for it to be considered a valid message to transact with their specific service/clients. The data types in Table 4-2 whose definitions are not obvious, e.g., address, special attribute, are defined in Appendix 5.
64 Table 4-2 : Telegram 1:A â Request a Trip Telegram 1:A REQUISITION - Requested trip From: Ordering client To: Provider(s) Purpose: Query for trip availability XSD Complex Type Name tripRequest Data Element Explanation Mandatory Field Type Pickup address Address with both street number & name and geocode YES Address Drop-off address Address with both street number & name and geocode YES Address Pickup time Requested time of pickup YES or next Time Appointment time A medical or other appointment time NO Time Drop-off time Intended drop-off time NO Time End of pickup window NO Time Accessible vehicle required Yes/No only YES Binary Number of passengers YES Numeric Start of pickup window NO Time Permissible detours NO Factor/binary Negotiated pickup time The start of the time window that both rider and provider agreed to NO Time Hard constraint on drop-off Yes or no if the rider must be dropped off at the requested drop- off time NO Binary Hard constraint on pickup Yes or no if the rider must be picked up at the requested pickup time NO Binary Special attribute List of special attributes NO Special Attribute List Transport services List of transport services to use NO Local List Open attribute Local use NO Local List
65 Sample Telegram 2: Confirm Trip The second step is to confirm the trip. Table 4-3 shows the next telegram, named Telegram 1:B. This sets forth the elements of a message sent from a provider to the client who ordered the trip to confirm that the provider can fulfill the needs requested in Telegram 1:A. Telegram 1:B may include any number of responses from a provider if they have multiple trip options available that fulfill the needs described in Telegram 1:A. Table 4-3 : Telegram 1:B â Trip Request Response (Confirmation) Telegram 1:B CONFIRMATION - options - Requested trip From: Provider To: Ordering client Purpose: List of trip options - 1 to many reply on Telegram 1:A XSD Complex Type Name tripRequestResponse Data Element Explanation Mandatory Field Type Confirmation of vehicle availability Yes/No response only Yes Binary Scheduled pickup time NO Time Pickup address Address with both street number & name and geocode YES Address Drop-off address Address with both street number & name and geocode YES Address Transfer zones/points Coordination NO Location/ geocode Fare type Cash, credit card, fare card NO List Fare amount Cost/fare of trip, local definition NO Numeric Transport services Transport service type (from list) NO Local List Sample Telegram 3: Send Trip Information to Vehicle Further ahead in the flow of communication, a subsequent telegram deals with sending the trip information to the vehicle. This information is transmitted to a driver application in the vehicle, and that application will guide the actions of the driver. Telegram 3:A, shown in Table 4-4 presents the data that the transportation service provider would send to the specific vehicle (driver) in advance of the trip so that the driver has all information needed to perform the trip at the required level of service.
66 Table 4-4 : Telegram 3:A â Vehicle/Trip Task Telegram 3:A REQUISITION - Route/trip task From: Provider To: Vehicle Purpose: Control Vehicle XSD Complex Type Name trip Task Data Elements Explanation Mandatory Field Type Trip ticket Unique ID from ordering client YES String Trip/route task ticket Unique ID from provider YES String Rider pickup location in vehicle performance sequence YES Numeric Pickup node address/geocode YES Address Pickup node scheduled time YES Time Pickup location detailed description NO Long text Rider drop-off location in vehicle performance sequence YES Numeric Drop-off node address/geocode YES Address Drop-off node scheduled time NO Time Drop-off location detailed description NO Long text Rider mobile phone NO Numeric Rider name YES String Other (free field) Rider: Service Needs NO Long text - for driver Special attribute List of special attributes of passenger trip NO List Number of other reserved passengers YES Numeric Fare type Cash, credit card, fare card NO List Fare amount Fare to collect from passenger YES Numeric
67 Sample Telegram 4: Confirm Delivery of Trip The next step is for the transportation service provider to obtain confirmation from the vehicle that the trip has been delivered. A software application in the vehicle that operates on an in-vehicle device (such as a tablet computer or mobile data terminal) and interfaces with the driverâtypically referred to as the driver applicationâfor the purpose of receiving orders and displaying the trip manifest, sends a confirmation to the service provider once the trip has been completed in the form of Telegram 3:B, shown in Table 4-5. Table 4-5 : Telegram 3:B â Confirm Trip Task Telegram 3:B CONFIRMATION - Route/trip task From: Vehicle To: Provider Purpose: Vehicle performance XSD Complex Type Name trip Task Confirmation Data Elements Explanation Mandatory Field Type Trip ticket Unique ID from ordering client YES String Trip/route task ticket Unique ID from provider YES String Rider drop-off location in vehicle performance sequence YES Numeric Node performed time YES Time Trip status Performed, no show, no pickup YES List Vehicle number YES String Driver ID NO String This specification does not require a telegram to be sent from vehicle to provider when the passenger is picked up, only when delivered. In practice, the driver application associated with the providerâs scheduling and dispatching systems will almost always send a data message from the vehicle to the central system when a passenger is picked up. As it is not clear that other systems need the pickup information in real time the proposed specification does not to make this a required telegram. Such a telegram could be added to the specification if there is a consensus that such information is essential for the real-time transactional data flow. Actual pickup time information is a data element in the telegram that transmits data about the completed trip 4.5 Approach for Specification-Compliant Data Communication The specification for demand responsive transportation includes not only the details of the telegrams and the data elements discussed in the last section, but also the approach for transmitting data among the entities involved in the transaction. Those entities are usually a service requestor (e.g., client entity) and a service provider. It is necessary as part of the specification development process to recommend an approach for validating that the transmitted data complies with the specification. This section presents four potential approaches to exchanging trip data in a way that it can be validated to be specification compliant.
68 Model 1: Point-to-Point The point-to-point approach to data communications requires all parties to agree upon and share a common protocol for data exchange. Every entity agrees to use the same message set and data elementsâtelegramsâto communicate with another entity, at each point in the process. Figure 4-5 shows how this point-to-point approach works. This means that all participants must have their own software (or embedded system in the case of devices) that could âtalkâ directly to other participants using the message set and data elements specified by the data protocols. As a result, the data protocols are internalized in each technology providerâs system. The SUTI system that is widely used in the Nordic countries is a point-to-point approach. Figure 4-5: Point-to-Point Communication Approach Model 2: Point-to-Point via Internal Translator The second model is a point-to-point via internal translator approach that is shown in Figure 4-6. In this approach, each software system and device can use its own data communication approach. It then interfaces with an internal data translator that transforms the data messages and their elements into the common data protocol. In essence, this is an internal API (application programming interface) for each technology system that enables it to talk in the transactional language when it needs to communicate with other systems. Functionally, it is virtually identical to the Model 1 point to point approach, but it relies on a somewhat differentâand conceptually more flexibleâtechnology approach for the participating systems.
69 Figure 4-6: Point-to-Point with Internal Translator Approach Model 3: Broker Control The third approach is broker control, shown in Figure 4-7. This approach also uses a shared API, that of the translation broker. Technology systems use the brokerâs API to transmit messages to one another via the broker. These messages can be passed along to any other participant who also has an interface to the brokerâs API and can therefore receive standardized messages. This third approach introduces a need for another significant piece of software, the âtranslation broker.â The function of the translation broker is to provide the APIs used by the endpoint systems and translate the data into the common protocols used for communication. There is also a comparable amount of technical work for the external technology systems; they must translate data between the agreed upon common specificationâthe language that the broker speaksâand their respective internal data schemes. Figure 4-7: Broker Control Approach
70 Model 4: Control Module The last approach under consideration uses a control module in which both sides can test the telegrams and ensure their mutual validity. This control module approach (see Figure 4-8) ensures a level of centralized specification control without requiring a fully centralized brokerage approach that could require substantially more time and money to initially implement, as well as requiring significant ongoing expenditures. As in Model 2, each participating system is responsible for making the translation between its internal representation of data and transactional functionality and that of the specification, but this approach then adds a centralized module that ensures that all transactional communication is compliant with the specification. In principle, if each partyâs message is validated by the control module then the other party can translate it with assurance that it will be syntactically correct and meaningful. Figure 4-8: Control Model Approach Advantages and Disadvantages of Each Model The four models presented above each have specific advantages and disadvantages, and each will be briefly discussed in the following paragraphs. Model 1 (point-to-point approach) Advantages All software systems and devices use the same data protocols internally in their systems; therefore, the technology vendors are responsible for all of the work needed to maintain the data specification. This also promotes âlock-inâ to the specification, since significant changes or the move to another specification would be costly and disruptive.
71 Model 1 (point-to-point) Disadvantages The disadvantage is the converse: all systems must use a similar internal representation of dataâ or in essence have an internal translation capabilityâand all changes in the specification must be adopted by all parties before inter-operability can be assured across the entire eco-system of participants. The latter is the disadvantage of this approach to achieving specification lock-in. Model 2 (point-to-point via internal translator) Advantages Enables a completely flexible technology approach by each participant in how it achieves specification compliance. Many internal technology schemes are feasible and each technology provider will use that which makes the most sense to it. Model 2 (point-to-point via internal translator) Disadvantages Each technology system is responsible for performing its own specification validation of incoming messages and, if it determines that there is an issue of some type, informing the message originator that their message has been rejectedâand why. This opens the door to potential inconsistency among how participants enforce the specification and what they communicate to other systems. With a small number of participants this might not be a major problemâand it resembles the actual situation in the airline industry due to the presence of a small number of core systemsâbut it could prove to be unwieldy and complicated in an ecosystem with a large number of technology systems. Model 3 (translation broker) Advantages The translation broker represents one approach to avoiding the issues inherent in Model 2. The advantages of this approach are: â¢ The technology systems do not change anything internally, but rather they may need only to translate their existing data outputs into the proposed specification to communicate with the broker â¢ It affords the opportunity to have a single point for data specification validation in multiparty service integration solutions such as a marketplace for trips or vehicle capacity â¢ The broker solution gives even more access to transport markets, allowing small providers to participate in competitive markets without excessive technology costs for data flows Model 3 (translation broker) Disadvantages The research team had initially assessed that a standards-based broker function would ensure the best functionality and the best chance of successful adoption of a transactional specification. However, after substantial discussion with the industry advisory panel, it became clear that the dependence on a third-party inherent in this approach represented a major disadvantage and, at this initial stage of specification development, could pose a substantial barrier to implementation because of the additional dependence and cost. Model 4 (control module) Advantages The advantage of the control module approach is that it ensures a level of centralized specification controlâas in Model 3âwithout requiring a fully centralized brokerage approach. The translation broker approach (Model 3) is likely to require substantially more time and money to initially implement, and also require significant ongoing expenditures. The control module approach thus overcomes the issues inherent in Model 2 and Model 3 while providing the technology vendors with the flexibility that is potentially constrained in Model 1.
72 The recommended approach uses a control module (Model 4) in which both parties involved in the transactional data communication can test the telegrams and ensure their mutual validity. It bears noting that a formalized specification validation approach is not mandatory for implementation of the specification. Organizations that wish to use the specification could do so and devise their own specification validation approach on a bi-lateral or multiple party basis. If the largest players did so their approach(s) would likely become the de facto standard(s). But at this initial stage of specification implementation, a formalized approach to validation seems to be the most appropriate way forward. 4.6 Other Considerations for Government-Funded DRT Services Most types of demand responsive service have a common set of data elements. However, certain specialized types of service require additional categories of data. These services are often government-funded and/or intended for a targeted set of riders. In the United States, the most common of these services is ADA complementary paratransit. The recommended specification does not, for the most part, require telegrams or mandatory data elements within telegrams, which directly support these specialized types of DRTs services. At the same time, it is important to acknowledge the need of certain government funding programs to obtain dataâor to use and transmit such dataâon these specific needs of the program. The specification has accordingly included many non-mandatory data elements in the telegrams so that it is possible for organizations who have these more comprehensive data needs to exchange data with other entities using only the specification data fields, albeit optional fields as well as mandatory ones. In such cases, the involved organizations could specify that their transactional partners must also provide certain optional data elements in their data messages. Rider Attributes Many of the telegrams in the proposed specification include special attributes to describe the rider and/or their needs in more detail. Table 4-6 and Table 4-7 present lists of potential special attributes. Some of these describe the mobility aid that the rider may be using (and bringing on to the vehicle). Other attributes describe types of disabilities or special service needs. These attributes are important for determining what type of vehicle is needed and whether the trip requires a driver with special training (or requires that the driver be cognizant of any special needs before pickup and while performing the trip). These special attributes may have codesâsuch as those shown, which are merely suggestiveâto translate among different platforms as needed. Trip Purpose for Reporting/Reimbursement Another trip characteristic that some DRT services capture is the trip purpose. Some programs report the trip purpose for various reimbursement rules or human service agency reporting needs. Possible trip purposes and codes are shown in Table 4-8. (Typically, both legs of a round trip are viewed as having the trip purpose of the initial leg in terms of attaching such codes to specific trips).
73 Table 4-6 : Special Attributes â Service Needs Code Attribute D2D Door to door DA Driver alert DTD Door through door HIP Hearing impaired person IDD Intellectually or developmentally disabled MH Other mental health concerns MIP Memory impaired person (Dementia) NDD Neurologic and degenerative diseases NLA Never leave alone O Oxygen SA Service animal SD Seizure disorder SI Speech impaired TD Temporary disability U Unstable, needs assistance VIP Vision impaired person Table 4-7 : Special Attributes â Mobility Aids Code Attribute A Ambulatory AL Ambulatory, needs lift C Cane CU Crutches E Electric wheelchair S Scooter W Wheelchair WA Walker WAK Knee walker WE Extended leg wheelchair WT Wheelchair, can transfer
75 Four approaches were considered for ensuring the verification and validation of telegrams/messages sent among transactional participants. The recommended approach uses a control module in which both sides can test the telegrams and ensure their mutual validity A software control module accessible to all participants is used to verify that data messages they receive are compliant with the specifications and can be processed with expected results. This project has developed a software tool which is similar to an external validator and can be used as such for testing purposes. Finally, the data structure for the specifications was considered. It was decided to make available both XML-based and JSON-based specifications, with the âofficialâ specification being based on XML. Appendix 5 includes a listing of the XML-based specification.