Development of Transactional Data Specifications for Demand-Responsive Transportation (2020)

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.

43 This chapter presents an overview of the recommended transactional data specification. The objectives of the specification are 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 interoperating computer systems. The chapter covers the following areas: • Definitions for key terms and concepts. • The telegram paradigm, a critical concept in the proposed specification. • Telegrams contained in the specification: 11 specific telegrams, 4 of which are described in detail. • Potential approaches to implementing specification-compliant data communication. 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. Additional detail on the specifications may be found in Appendices E and F. 4.1 Key Concepts The proposed transactional data specification is organized around messages—specifically, a set of agreed upon message types—and data elements, as defined here. Messages can be of many different types, with each type designed to perform a specific function in the transmission and/or exchange of data among interoperating parties. 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 messages will be referred to formally as telegrams when appropriate in this chapter. 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 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 the information the recipient needs to act upon the specific request from the transmitter of the message. C H A P T E R 4 Summary of the Specification

44 Development of Transactional Data Specifications for Demand-Responsive Transportation • 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; the confirmation or rejection of the messages’ validity 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 the 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 composed of a predefined message type whose message contents must include all of the data elements required for that type of message. Telegrams may include valid optional data elements as well. Key characteristics of telegrams are: • Telegrams have a defined structure; • Telegrams have a specific vocabulary; • Telegrams encompass all essential steps in the trip ordering and trip execution process; and • Telegrams imply a request/response approach to data communication concerning transactions. This proposed specification is based on 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. (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 transaction’s status, and while this transactional state can usually be discovered by the other system as necessary, there is no stan- dard 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. Process of a DRT Transaction At different stages in the transactional process of a DRT trip, the primary focus varies among the following: • Rider—Individual wishing to make the trip. • Entity taking the trip order—Service provider itself or an entity that organizes the service but does not actually operate it, such as a trip exchange or the brokers that are common with Medicaid.

Summary of the Specification 45 • Service scheduling entity—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. Certain internal activities of the service provider may not be included in the transactional specifications, as they are relevant only to that entity. For each scenario (or use case) in which the specification is employed, the interacting computer systems use the telegrams to communicate the data informing each system of what the other system is requesting, 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 schedule/route to be performed by the vehicle, including expected arrival times at stops. 4. Completed job—Data on actual trip pickup and delivery details, to be returned for financial settlement and operational quality assessment. Figure 4-1. DRT trip process from initial request to execution and payment.

46 Development of Transactional Data Specifications for Demand-Responsive Transportation From this perspective, there is no requirement to transmit customer-identifying informa- tion, 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. The telegrams enable the computer systems to move through the transactional steps sum- marized; this is described and shown in terms of process flow in Section 4.3. 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 directing the driver’s activities for delivering service to the rider. 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 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 interoperate 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 specification is to provide the functional scope within which a wide range of entities can exchange transactional data to support interoperability among their technology systems. For example, a typical TNC rider orders a trip by indicating the trip’s origin; destination; number of passengers; and desired level of service, for example, 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 nonemergency medical transportation (NEMT) service provider does not provide the customer with any options about its level of service, but it often needs information Figure 4-2. Basic data elements needed for the DRT trip process.

Summary of the Specification 47 regarding special needs and mobility aids to send the appropriate vehicle and driver for a 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 canceled by the healthcare 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 interactions involving one or more service providers or those occurring via multi-provider system clearinghouses. The specification is not designed to support any one approach to how interacting entities organize themselves to enable the ordering, delivery, and payment of demand-responsive transportation services. As emphasized at the beginning of the chapter, the objectives of the specification are simply to establish the common language that entities use to communicate with each other and provide the technical approach for how data communication will occur among interoperating computer systems. 4.3 Telegram Descriptions and Typical Data Flow The proposed transactional data specification is based on 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: • 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; and • Vehicle node—Vehicle and driver assigned by the service provider to complete trip. There are 11 telegrams in the proposed specification, covering five basic activities. The numbering of the telegrams describes not only the activity but also the path the messages follow; this informs which telegram to expect next. Not all messages are used in each transaction. Table 4-1 lists each telegram and describes the basic tasks linked to each activity. Activity Task Accomplished and Flow of Information Telegram Planning Request Trip (rider/client to service provider) Telegram 1A Confirm Trip Request (service provider to client/rider) Telegram 1B 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.

48 Development of Transactional Data Specifications for Demand-Responsive Transportation 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-3 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. This is due in part to the history of DRT service in Sweden, which was frequently built around taxi 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-3. Telegram flow.

Summary of the Specification 49 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 among 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. This 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. Appendix D provides detailed descriptions of each of the 11 telegrams and the data elements that are included in the recommended transactional specification. Appendix E includes the XML description of each telegram. 4.4 Examples of Telegrams The following portion illustrates how 4 of the 11 telegrams 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 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 orga- nization 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 Table 4-2. The number of data elements would depend on the rider and/or provider needs. For this telegram, and all others presented 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 Table 4-2. Telegram 1:A—Request a trip.

50 Development of Transactional Data Specifications for Demand-Responsive Transportation 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, nonmandatory data elements in the telegram for it to be valid 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 D. 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. Sample Telegram 3: Send Trip Information to Vehicle 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. 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 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. Confirmation is in the form of Telegram 3:B, shown in Table 4-5. 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 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 Table 4-3. Telegram 1:B—Trip request/response (confirmation).

Summary of the Specification 51 Telegram 3:A REQUISITION - Route/trip task From: Provider To: Vehicle Purpose: Control Vehicle XSD Complex Type Name trip Task Data Element 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 Table 4-4. Telegram 3:A—Vehicle/trip task. Telegram 3:B CONFIRMATION - Route/trip task From: Vehicle To: Provider Purpose: Vehicle performance XSD Complex Type Name trip Task Confirmation Data Element 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 Table 4-5. Telegram 3:B—Confirm trip task.

52 Development of Transactional Data Specifications for Demand-Responsive Transportation 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 make this a required telegram. 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, 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 as specification-compliant. 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-4 shows how this point-to-point approach works. All participants must have their own software (or embedded system, in the case of devices) that can “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. Model 2: Point-to-Point via Internal Translator The second model is a point-to-point via internal translator approach, shown in Figure 4-5. In this approach, each software system and device can use its own data communication approach. Figure 4-4. Point-to-point communication approach.

Summary of the Specification 53 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 pro- gramming 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. Model 3: Broker Control The third approach is broker control, shown in Figure 4-6. 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 that also has an interface to the broker’s API and can therefore receive standardized messages. This 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 SYS Internal Translator Internal Translator P-SYS Figure 4-5. Point-to-point with internal translator approach. Figure 4-6. Broker control approach.

54 Development of Transactional Data Specifications for Demand-Responsive Transportation and translate the data into the common protocols used for communication. There is also a com- parable 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. Model 4: Control Module This approach uses a control module in which both sides can test the telegrams and ensure their mutual validity. This control module approach (see Figure 4-7) ensures a level of central- ized specification control without requiring a fully centralized brokerage approach that could require substantially more time and money to implement initially, as well as significant ongoing expenditures. As in Model 2, each participating system is responsible for making the transla- tion between its internal representation of data and transactional functionality and that of the specification, but this approach 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. Advantages and Disadvantages of Each Model The four models each have specific advantages and disadvantages. Model 1 (Point-to-Point) 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. Figure 4-7. Control module approach.

Summary of the Specification 55 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 interoperability can be assured across the entire ecosystem of participants. The latter is the disadvantage of this approach to achieving specification lock-in. Model 2 (Point-to-Point via Internal Translator) Advantages—This model enables a completely flexible technology approach by each partici- pant in how it achieves specification compliance. Many internal technology schemes are feasible, and each technology provider will use the one that fits best. Disadvantages—Each technology system is responsible for performing its own specification validation of incoming messages. If it determines that there is an issue of some type, the system is responsible for 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 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. 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 dis- advantage 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 implement and may 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. 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. However, a formalized specification validation approach is not mandatory for implementing the specification. Organizations that wish to use the specification could do so and devise their own specification validation approach on a bilateral or multiparty basis. If the largest players did so, theirs would likely become the de facto standard(s). But at this initial stage of specification implementation, a formalized approach to validation seems the most appropriate way forward.

56 Development of Transactional Data Specifications for Demand-Responsive Transportation Disadvantages—The primary disadvantage of the control module approach is that it requires an additional element compared to the point-to-point approaches, but does not eliminate the need for a syntax-checking step compared to the translation broker approach. At the same time, while syntax checking is a necessary step in the message data flow, it can be handled by the control module, which will determine whether the syntax is acceptable—in which case the message can be processed successfully. If the message cannot be processed, the message initiator or recipient will terminate the conversation. The other party will know only that the message has not been accepted and will not know why. 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 DRT 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 program needs. The specification has accordingly included many nonmandatory data elements in the tele- grams so that it is possible for organizations that have these more comprehensive data needs, to exchange data with other entities using only the specification data fields—albeit optional as well as mandatory fields. In such cases, the involved organizations could specify that their transac- tional 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 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-6. Special attributes— service needs.

Summary of the Specification 57 attributes. Some of these describe the mobility aid that the rider may be using (and bringing onto 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, for attaching such codes to trips. 4.7 Data Structure One other important aspect of the transactional data specification approach is how the data is structured to move from computer system to computer system. There are two approaches typically used to implement this: one uses the JavaScript Object Notation (JSON) and the other using eXtensible Markup Language (XML) with tags. Both approaches create a structured set of data that a receiving computer program can decode from a description of the data received 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 Table 4-7. Special attributes— mobility aids. Code Meaning A Adult day program D Dialysis E Employment G Grocery HR Health related (includes dentist, pharmacy, etc.) M Medical P Personal R Recreation T Transfer to/from public transit Table 4-8. Trip purpose codes (examples).

58 Development of Transactional Data Specifications for Demand-Responsive Transportation from the transmitting computer program. The JSON approach has become more widely used in recent years and is probably the most appropriate way of handling the actual data transmission. The fundamental difference between the two approaches is that XML is a markup language, whereas JSON represents objects. In principle, the specification can be kept in both languages, however choosing one reduces the overhead work for entities to work together. Using the control module approach, XML allows the two sides to validate and enforce the telegrams before they are sent from ordering system to provider system (or vice versa). Both XML and JSON specifications will be available, although the “official” specification is based on XML. 4.8 Summary This chapter presented the technical essentials of the recommended transactional data speci- fication for DRT. The telegram paradigm, in which discrete messages—telegrams—composed of specific data elements are sent to advance a transaction from beginning to conclusion, is the core organizing approach to the specification. The proposed specifications include 11 telegrams which encompass the full range of the trip lifecycle, from initial service request to the telegram transmitted after the execution of the trip and containing all the completed trip data. While the data elements specified for each message/telegram are comprehensive, only a subset of the data elements are mandatory; others will only be used for transactions involving specific organiza- tions for whom they are a requirement. This will be determined by business relationships among the entities involved in actual or potential DRT transactions. The relationships among the full set of telegrams were shown diagrammatically and examples involving 4 of the 11 telegrams were presented, including all mandatory and optional data elements. The entire set of detailed transactional data specifications is contained in Appendix D. 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 that 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 based on XML. Appendix E includes a listing of the XML-based specification.