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.

99 Detailed Specification Description A P P E N D I X D This appendix presents the proposed specification for demand-responsive transportation transactional data. A brief introduction to the overall approach is presented first; this approach centers around the concept of “telegrams,” which are messages sent between entities. The remainder of the specification describes each of the individual telegrams in detail. A total of 11 telegrams are proposed. Last, special attributes of passengers that may be applicable in some cases and additional items that may be needed for reporting purposes are described. Approach The proposed transactional data specification is organized around “messages” (and specifically, a set of agreed upon “message types”) and “data elements”. Messages can be of many message types, with each type designed to perform a specific function with respect to the transmission and/or exchange of data among interoperating parties. For example, there may be a message type to send a trip request to another transportation system and another message type to send a trip to a driver application running on a device in a vehicle. Message types and their corresponding data elements can be referred to as “telegrams.” These telegrams will be interchanged by entities participating in transactions. Figure D-1 shows the steps for demand-responsive transportation transactions from left to right in the figure. The entities involved in this transaction include the rider, the organization taking the order, the entity doing route planning, the vehicle performing the order, and the payer or funding entity. Figure D-1. Steps for a DRT trip from ordering to completion and payment.

100 Development of Transactional Data Specifications for Demand-Responsive Transportation Each time information crosses a line in Figure D-1, a telegram must be sent containing the data necessary to advance the transaction to the next step. Since some telegrams confirm the receipt of information, this means the transactional flow is not necessarily one-directional as Figure D-1 would suggest (from planning through completion and payment); exchange of information can go in both directions. The telegrams that follow in the next section represent the bi-directional information needed for requesting and confirming activities among the entities. The telegrams describe each step in the process of ordering and executing a trip as in Figure D-1. There are many data elements that could be included in this process, but many of the data fields may not apply to different customer types or in different situations. For this reason, the telegrams define a set of potential data items, most of which are not mandatory; it is the decision of each provider and ordering client to determine which data elements are essential in their system. For example, a typical transportation network company (TNC) customer orders a trip by indicating their origin, destination, number of passengers, and desired level of service. It is also possible to indicate a future pickup time. In contrast, a nonemergency medical transportation (NEMT) service provider needs to know information regarding special needs and mobility aids to send the appropriate vehicle and driver. Thus, trips being sent to a TNC provider need not contain the same level of detail as a trip being sent to an NEMT provider. By extension, some NEMT providers may require more or less information about a customer, and some customers may need to convey more or less information. These decisions could be left up to the groups establishing business rules for interaction on one or more clearinghouses; the goal of this project is to establish the language these groups use to communicate with one another. The processes in Figure D-1 can in turn be described in terms of functional needs or requirements, as shown in Figure D-2. Figure D-2. Functional needs for a DRT trip use case.

Detailed Specification Description 101 The functional needs are specified in terms of data elements that describe a specific situation, as in Figure D-3. The collective set of functional processes involved and the data describing each process define the DRT trip use case. Figure D-3. Data needs for a DRT trip use case. For each use case in which the specification is employed, the interacting computer systems will use the telegrams to communicate the data that informs each system of what the other system is requesting or offering. The telegrams described in the following sections enable the computer systems to move through the transactional steps shown in Figure D-1 where some steps require a transaction to take place between the trip ordering client and transportation service providing entity while others might be messages communicated between the provider database and the vehicle’s mobile data terminal or similar in-vehicle device that hosts the application that directs the driver’s activities for delivering service to the rider. Flow of Telegrams The process of ordering and completing a DRT trip is separated into 11 unique telegrams (numbered as Telegram 1A to Telegram 5). Figure D-4 illustrates the flow of telegrams between the ordering client, provider and vehicle that would be necessary to complete a transaction. In the following section, each telegram is explained on a separate page with the variables listed in a table, beginning with Telegram 1A to request a trip.

102 Development of Transactional Data Specifications for Demand-Responsive Transportation 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 D-4. Telegram flow.

Detailed Specification Description 103 Telegram 1:A – Request a Trip The first step in most transactions is to request a trip. The trip could be requested directly by the customer, or it might be requested by an organization on their behalf (such as a human service agency or healthcare provider). A trip request is described by the data elements in Telegram 1:A, which is shown in Table D-1. Depending on the customer needs, more or less variables would be considered. For all telegrams, a YES or NO in the “mandatory” column indicates whether this is the minimum variable required to conduct a transaction in general. Specific entities (ordering clients or providers) could require additional variables to be considered a valid message to transact with their specific service/clients. Table D-1. 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 Elements: Explanation Mandatory Field Type Pick up address YES Location/geocode Drop-off address YES Location/geocode Pick up time 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 pick up window NO Time Start of pick up window NO Time Permissible detours NO Factor/binary Negotiated pick up time The zero of the time window that both customer and provider agreed upon NO Time Hard constraint on drop-off Yes/no if the customer must be dropped off at the requested drop-off time NO Binary Hard constraint on pick up Yes/no if the customer must be picked up at the requested pick up time NO Binary Special attribute List of special attributes NO List Transport services List of Transport service to test NO Local List Open attribute Local use NO Local List

104 Development of Transactional Data Specifications for Demand-Responsive Transportation Telegram 1:B – Trip Request/Response The second step is to confirm the trip. The next telegram is the trip request/response or acknowledgment that would be sent from a provider to the ordering client to confirm that the provider can fulfill the needs requested in Telegram 1:A. This is called Telegram 1:B and it can include any number of responses from a provider if they have multiple trip options available that fulfill the needs described in the request Telegram 1:A. The data elements of Telegram 1:B are shown in Table D-2. Table D-2. Telegram 1:B – Trip Request/Response 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 Elements: Explanation Mandatory Field Type Confirmation of trips availability Yes Binary Scheduled pickup time NO Time Scheduled Pick up point YES Location/geocode Scheduled Drop-off point YES Location/geocode Transfer zones/points Coordination NO Location/geocode Fare type cash, credit card, Travelcard NO List Fare amount NO Numeric Transport services Transport service NO Local List

Detailed Specification Description 105 Telegram 2:A – Order Confirmation The next step is that the client system confirms the trip and sends a trip ticket ID. The ordering client sends Telegram 2:A to the chosen provider or providers to confirm additional details for the selected trip. This telegram could include additional information related to constraints on the time window and detailed information about pickup and drop-off location. The data elements of Telegram 2:A are shown in Table D-3. Table D-3. Telegram 2:A – Order Confirmation Telegram 2:A REQUISITION - confirm order From: Ordering client To: Provider(s) Purpose: Order confirmation XSD Complex Type Name: clientOrderConfirmation Data Elements: Explanation Mandatory Field Type Trip ticket Unique ID from Ordering client YES String Pick up address YES Location/geocode Drop-off address YES Location/geocode Pick up time YES or next Time Appointment time Medical/other appointment time NO Time Drop-off time Intended drop-off time NO Time End of pick up window NO Time Start of pick up window NO Time Permissible detours NO Factor/binary Negotiated pick up time Zero of time window agreed to NO Time Hard constraint on drop-off NO Binary Hard constraint on pick up NO Binary Detailed drop-off location description NO Long text Detailed pick up location description NO Long text Funding entity Funding ID YES Local list Customer key Customer ID NO String Customer name YES String Customer mobile phone NO Numeric Customer location in drop-off sequence NO Number Number of other reserved passengers NO Numeric Fare type NO String Fare amount NO Numeric Trip Purpose NO List--Trip Purpose

106 Development of Transactional Data Specifications for Demand-Responsive Transportation Telegram 2:A:1 – Customer Information The next, nonmandatory step is that the ordering client provides additional details about the customer’s trip. This is basically the same functionality as Telegram 2:A, but with customer information added so the provider can update the customer's information in their system. The ordering client may need to send even more detailed information about the customer to the provider if there are special considerations. This would be sent as a follow-up message only for cases where it applies as Telegram 2:A:1, and much of this information would need to be communicated to the driver at the appropriate time to execute the trip. The data elements of Telegram 2:A:1 are shown in Table D-4. Table D-4. Telegram 2:A:1 – Customer Information Telegram 2:A:1 REQUISITION Customer data - confirm order From: Ordering client To: Provider(s) Purpose: Customer info for trip XSD Complex Type Name: customerInfo Data Elements: Explanation Mandatory Field Type Customer key Customer ID NO String Customer name NO String Customer home address NO Location/geocode Customer home phone NO Numeric Billing address (customer) NO Location/geocode Billing information (funding entity) NO String Funding type Indicators for different billing groups (e.g., Medicaid) NO String Gender NO Factor Caregiver's contact information NO String Customer's emergency phone number NO Numeric Customer's emergency contact name NO String Comment about care required (hands-off) NO Long text - to call center Date of birth/Age NO Date Fare type NO Factor Other (free field) Customer: Service Needs NO Long text – for driver

Detailed Specification Description 107 Telegram 2:B – Confirm Trip Scheduled The next step is confirmation of the order details. Regardless of whether the ordering client sends information in Telegram 2:A:1, the provider needs to confirm information contained in Telegram 2:A. This response is Telegram 2:B, which confirms the scheduled pickup and drop-off information, fare information, and vehicle information. The data elements of Telegram 2:B are shown in Table D-5. Table D-5. Telegram 2:B – Confirm Trip Scheduled Telegram 2:B CONFIRMATION - confirm order From: Provider To: Ordering client Purpose: Confirm trip is scheduled XSD Complex Type Name: providerOrderConfirmation Data Elements: Explanation Mandatory Field Type Trip ticket Unique ID from Ordering client YES String Scheduled pickup time YES Time Scheduled pickup point YES Location/geocode Scheduled drop-off point YES Location/geocode Transfer zones/points Coordination NO Location/geocode Fare type cash, credit card, travelcard NO List Fare amount NO Numeric Transport services Transport service NO Local List Vehicle number NO String or Local List Driver ID NO String or Local List Vehicle information NO String or Local List

108 Development of Transactional Data Specifications for Demand-Responsive Transportation Telegram 2:BB – Vehicle Confirmation If special needs were communicated in Telegram 2:A:1, the next step is to confirm those special needs. For the special needs that could have been communicated in Telegram 2:A:1, Telegram 2:BB is the appropriate response confirming the features of the provider (vehicle and driver) that will be sent for this customer. This includes a description of the vehicle that will be sent to the ordering client. The data elements of Telegram 2:BB are shown in Table D-6. Table D-6. Telegram 2:BB – Vehicle Confirmation Telegram 2:BB CONFIRMATION - Vehicle information - confirm order From: Provider To: Ordering client Purpose: Confirm vehicle XSD Complex Type Name: vehicleConfirmation Data Elements: Explanation Mandatory Field Type Vehicle number NO String Driver ID NO String Vehicle information NO String Availability for service NO Time Fuel range NO Numeric Ambulatory space points NO Numeric Large/full wheelchair space points NO Numeric Ramp present NO Binary Lift present NO Binary Standard/manual wheelchair space points NO Numeric Luggage/cargo space points NO Numeric Vehicle ID NO Numeric Vehicle model NO Factor/string Conversion factor for ambulatory points to standard wheelchair points (specific to model) NO Numeric Conversion for ambulatory points to large wheelchair points (specific to model) NO Numeric Flat floor NO Factor Owner NO String/factor Ride quality/vibration NO Factor

Detailed Specification Description 109 Telegram 3:A – Vehicle Trip Task At this point, the provider has confirmed that the trip will take place to the ordering client. This trip now needs to be dispatched. Therefore, the next step is to send the trip information to the vehicle. This message, Telegram 3:A, is what the transportation service provider would send to the specific vehicle (driver) at the appropriate time in advance of the trip so that the driver has all information needed to perform the trip at the required level of service. The data elements of Telegram 3:A are shown in Table D-7. Table D-7. Telegram 3:A – Vehicle Trip Task Telegram 3:A REQUISITION - Route/trip task From: Provider To: Vehicle Purpose: Control Vehicle XSD Complex Type Name: tripTask 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 Customer 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 Customer 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 Customer mobile phone NO Numeric Customer name YES String Other (free field) Customer: Service Needs NO Long text - for driver Special attribute List of special attributes at end of document NO List Number of other reserved passengers NO Numeric Fare type cash, credit card, Travelcard NO List Fare amount NO Numeric

110 Development of Transactional Data Specifications for Demand-Responsive Transportation Telegram 3:B – Confirm Trip Task The next step is for the transportation service provider to confirm that the trip has been delivered. In response to Telegram 3:A, the transportation service provider’s vehicle application (that is, the in-vehicle device and software that receives orders and displays the trip manifest) sends a return confirmation once the trip has been completed in the form of Telegram 3:B. The data elements of Telegram 3:B are shown in Table D-8. Table D-8. Telegram 3:B - Confirm Trip Task Telegram 3:B CONFIRMATION - Route/trip task From: Vehicle To: Provider Purpose: Vehicle performance XSD Complex Type Name: tripTaskConfirmation 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 Customer 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 or local list Driver ID NO String or local list

Detailed Specification Description 111 Telegram 4:A – Completed Trip Data The next step is that the transportation service provider sends trip information to the ordering client. As soon as the service provider receives Telegram 3:B from the vehicle indicating the trip was completed, the provider can send information pertaining to the completed order to the initial ordering client as Telegram 4:A. The data elements of Telegram 4:A are shown in Table D-9. Table D-9. Telegram 4:A – Completed Trip Data Telegram 4:A REQUISITION – Completed job From: Provider(s) To: Ordering client Purpose: Performed trip data XSD Complex Type Name: tripTaskCompletion Data Elements: Explanation Mandatory Field Type Trip ticket Unique ID from Ordering client YES String Cost Ordering client payment YES Numeric Pick up address NO Location/geocode Pick up time YES Time Drop-off address NO Location/geocode Drop-off time YES Time Scheduled pickup point NO Location/geocode Scheduled pickup time NO Time Scheduled drop-off point NO Location/geocode Scheduled drop-off time NO Time Performed pickup point NO Location/geocode Performed pickup time NO Time Performed drop-off point NO Location/geocode Performed drop-off time NO Time Permissible detours NO Time Transfer zones/points Coordination NO Location/geocode Fare type cash, credit card, Travelcard NO List Fare amount Rider payment NO Numeric Transport services Transport service NO Local List Special attribute List of special attributes NO List

112 Development of Transactional Data Specifications for Demand-Responsive Transportation Telegram 4:B – Confirm Trip Data Received and Payment Status The next step is that the ordering client confirms receipt of completed trip details. The ordering client then confirms that the details of the completed trip were received for that trip ticket and whether the payment was completed (the ordering client pays the provider) in Telegram 4:B. The data elements of Telegram 4:B are shown in Table D-10. Table D-10. Telegram 4:B – Confirm Trip Data Received and Payment Status Telegram 4:B CONFIRMATION - Completed job From: Provider To: Ordering client Purpose: Confirm trip data received XSD Complex Type Name: tripScheduledConfirmation Data Elements: Explanation Mandatory Field Type Trip ticket Unique ID from Ordering client YES String Data Received YES Binary Payment Rejected NO Binary

Detailed Specification Description 113 Telegram 5 – Vehicle Current Status The final, optional step is that the information is sent from the vehicle to the provider for reporting purposes. Finally, the specifications could define a telegram whereby the vehicle sends information to the service provider in order to record information that may be useful for reporting in Telegram 5. The data elements of Telegram 5 are shown in Table D-11. Table D-11. Telegram 5 – Vehicle Current Status Telegram 5: INFO From: Vehicle To: Provider Purpose: GPS and trips status XSD Complex Type Name: tripTaskStatus Data Elements: Explanation Mandatory Field Type Vehicle number YES String GPS YES Geocode Timecode YES Time Driver ID NO String Driver hours current value NO Float Odometer readings current value NO Float Passenger miles current value NO Float Vehicle hours current value NO Float Vehicle miles current value NO Float Boardings and alightings at trip ends NO String Other fleet variables NO String Trip/route Task ticket Unique ID from Provider NO String

114 Development of Transactional Data Specifications for Demand-Responsive Transportation Customer Attributes Many of the telegrams in the proposed specification listed a “Special Attribute” for the customer. A list of potential special attributes is detailed below in Table D-12. These attributes would be key to evaluating what sort 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 could have key codes to translate among different platforms as needed. Table D-12. Special Attributes Code Meaning Category A Ambulatory Mobility Aid AL Ambulatory lift Mobility Aid C Cane Mobility Aid CU Crutches Mobility Aid D2D Door to door Service Needs DA Driver Alert Service Needs DTD Door through door Service Needs E Electric wheelchair Mobility Aid HIP hearing impaired Service Needs IDD intellectually or developmentally disabled Service Needs MH Mental health Service Needs MIP Dementia (memory impaired) Service Needs NDD Neurologic and degenerative diseases Service Needs NLA Never leave alone/no leave alone Service Needs O Oxygen Service Needs S Scooter Mobility Aid SA Service Animal Service Needs SD Seizure disorder Service Needs SI Speech impaired Service Needs TD Temporary Disability Service Needs U Unstable needs assistance Service Needs VIP Vision impaired Service Needs W Wheelchair Mobility Aid WA Walker Mobility Aid WAK Knee walker Mobility Aid WE Extended leg w/c = Extended Leg Wheelchair Mobility Aid WT Wheelchair, can transfer Mobility Aid WW Wide wheelchair Mobility Aid

Detailed Specification Description 115 Reporting Trip Purpose Finally, it may be necessary in some cases to report the trip purpose for various reimbursement rules or human service agency reporting needs. Trip purpose codes are given in Table D-13. Table D-13. Trip Purpose Codes Purpose 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 Public transit