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.

7 Introduction 1.1 About This Research Project This project focuses on a key building block for enabling demand-responsive transportation services in the United States to participate more fully and easily in the era of new mobility. The primary product of this effort is a comprehensive data specification for ordering and scheduling trips and vehicles in demand-responsive transportation services, the transactions that are at the heart of providing these types of services. Transactional data specifications include the mechanisms for the software systems of various service providers to routinely exchange such information, so that interoperability among services becomes feasible. This report (1) presents new transactional data specifications for demand-responsive transportation; (2) makes a case for why key stakeholders in the public sector—those that fund and provide demand-responsive services—should adopt and build out these specifications; and (3) provides some tools to help them do so. Once implemented, the proposed transactional data specifications will improve the availability, cost-effectiveness, and quality of demand-responsive transportation services. The primary beneficiaries include: • Customers, who will benefit because transactional data specifications can help increase availability of demand-responsive services. • Demand-responsive service providers, which will benefit because they can better utilize their vehicles, serving more customers at a lower cost per trip, and more seamlessly interoperate with public transportation organizations and others that fund these services. • Publicly supported transportation organizations, which can benefit from improved cost- effectiveness of DRT services as it becomes possible to use multiple transportation providers for a single service program, while also fostering competition among them. • Government transportation funding programs, which will benefit by using public resources more efficiently and effectively to fund transportation services and by improving mobility services to local communities. Experience in Denmark over the past 10 years demonstrates that improvements can occur when transactional data specifications become integral to demand-responsive transportation. Making this a reality in the United States would represent an important building block for more effective use of demand-responsive transportation for public purposes. 1.2 What Is Demand-Responsive Transportation? Demand-responsive transportation (DRT) covers a wide range of on-demand services. For this report, DRT refers broadly to transportation services in which vehicles operate only in response to ride requests and are routed to transport passengers from their origin to their C H A P T E R 1

8 Development of Transactional Data Specifications for Demand-Responsive Transportation destination. In contrast to fixed-route transit, in which the passenger must access the service, in DRT the service is mostly or completely tailored to the passenger’s specific trip. Rider trip requests are scheduled through an automated or manual system. Vehicles are scheduled and routed in accordance with the specific elements of the demand for service; the scheduling system considers origin, destination, desired pickup time and/or desired arrival time, vehicle requirements, and other trip requirements. Applying this broad definition to both public and private transportation services, DRT includes the following: • Dial-a-ride services, the term historically used for public transit shared-ride DRT services for the general public, or similar services geared toward seniors. • Americans with Disabilities Act (ADA) complementary paratransit services, shared-ride DRT required by the ADA and restricted to individuals unable to use fixed-route services because of a disability. • On-demand/flex/microtransit services (all referring to essentially the same thing), contemporary versions of shared-ride DRT service using more advanced technology and potentially using service concepts such as virtual stops or dynamic routes, provided for public transportation purposes for community circulation or first-mile/last-mile access to rail transit and express bus services. • Ride-hailing services, for-hire on-demand transportation services engaged by a smartphone app, such as Uber, Lyft, Via, and other transportation network companies (TNCs), most commonly using vehicles owned by the drivers who connect to the service network via a driver app. These services may be of a shared-ride nature, e.g., Uber Pool, Lyft Shared, Via Van, as well as individually directed, taxi-like trips. • Taxi services, for-hire transportation providing on-demand rides for any paying passenger, using vehicles clearly identified as taxis. Together, these demand-responsive services provide transportation to a wide variety of passengers, with or without mobility impairments, in both urban and rural communities. Figure 1-1 shows two of the many types of vehicles used for DRT services. Historically, DRT has referred to public transportation services that are shared-ride in nature and exclude general, for-hire transportation in which the vehicle is under exclusive control of the rider. Taxis or similar services provided by ride-hailing services (i.e., TNCs such as Uber Figure 1-1. Examples of vehicles used for DRT service.

Introduction 9 and Lyft) are typically in the latter category but have been used for public transportation purposes in certain situations. For the purposes of this report, DRT is defined broadly, to include all forms of demand-responsive transportation in the transactional data specification. As emphasized, DRT services for public transportation purposes typically involve unrelated parties sharing a vehicle which is under the control of the system, not each individual rider. Examples include services for the general public—often referred to as dial-a-ride—that exist in hundreds of communities throughout the United States, as well as services operated by publicly funded human service organizations, ADA paratransit services, and many airport shuttle services. In this report, DRT services that feature mandatory sharing of the vehicle by unrelated parties are referred to as shared-ride DRT. 1.3 What Is Transactional Data for DRT? Transactional data is the data created for each ride occurring in a DRT service spanning a trip lifecycle that begins with a trip-booking request and ends when a customer is delivered and the financial settlement information for the trip has been exchanged among the customer, ser- vice provider, and any third-party funding entity. Transactional data contains all pertinent trip details in a reservations and scheduling system, including: • Origin • Destination • Requested time (pickup/arrival) • Passenger attributes (e.g., wheelchair) • Actual pickup time • Actual arrival time • Trip fare (to passenger) • Trip cost (to provider) • Fare, payment, or funding information 1.4 The Technology and Market Context of Transactional Data Specifications Technology platforms have become the centerpiece of new mobility services. New mobility services include ride hailing, bike sharing, car sharing, electric scooters, and other smartphone- enabled travel modes. These service platforms are also accessible via Mobility as a Service (MaaS) applications, providing an integrated view of all urban transportation options including multimodal trips and certain transactional and payment capabilities. Platforms are now the gateway to most mobility services—of whatever type—that are available on demand. This essential connection between technology and new mobility services provides the back- ground for the direction of this study. The importance of a transactional data specification is integrally connected to the need for interoperability among multiple technology systems; connected digital platforms promise more effective approaches to providing DRT. Figure 1-2 shows how DRT transactional data specifications fit into the larger data framework that is developing for public transportation services. This framework began with the develop- ment (by Google) of the General Transit Feed Specification (GTFS) and is moving rapidly in the direction of MaaS platforms that encompass all forms of available mobility services, and can include open source trip-planning tools such as Open Trip Planner that promise to make basic MaaS functionality widely available.

10 Development of Transactional Data Specifications for Demand-Responsive Transportation As Figure 1-2 illustrates, transactional data specifications are poised to play a key role in a public transportation future in which demand-responsive services are an important element of local mobility. In particular, they make it simple for DRT services to be included in MaaS systems, not merely as an available service but also to book rides on the service and pay for those trips. This is essential if such services are to realize their potential for first-mile/last-mile access to high-capacity rail and bus transit and for community circulation in environments in which fixed-route bus service is ineffective and costly. Transactional data specifications in conjunction with technology platforms also offer the possibility of more effective resource utilization for DRT services. Traditionally, such services— whether in the public or private sector—have been managed by a single software system in a closed environment that is incompatible with software systems of other transportation service organizers or providers. Service integration either vertically or horizontally could occur only if all participants used the same software or if bespoke data specifications were developed to enable interoperability, which has rarely occurred. As a result, demand-responsive transportation in which coordination across suppliers and service organizers occurs in ways that improve service and efficiency is virtually nonexistent in the United States. Data interoperability across software systems is essential for technology platforms to make possible more coordinated, integrative approaches to service organization and delivery for demand-responsive transportation services. This research project has considered the methods of achieving interoperability and identified the development of transactional data specifications Trip Planning Creates an itinerary from origin to destination. May be multimodal -- user presented with options and selects a mode. May be intermodal with GTFS-Flex. Transactional Data Specifications Describes a DRT trip with data messages and data elements. Validation tool provided. DRT Transactions Trip data can be exchanged among scheduling software systems or through a data hub. Financial Systems Fares and fare payment systems. DRT fees for service provision. DRT fee billing/payment systems. Source of funding considerations. DRT Scheduling Booking, scheduling, dispatching. Multiple service providers. Multiple scheduling systems. Mobility as a Service (MaaS) A comprehensive technology platform that enables users to discover, schedule, and pay for trips across multiple modes. Discovery Data Specifications General Transit Feed Specification (GTFS). GTFS describes fixed-route services. GTFS-RT describes real time location and ETA. GTFS-Flex describes DRT services. Figure 1-2. DRT transactional specification in transit data context.

Introduction 11 as the preferred solution to achieving software/data interoperability and facilitating service coordination across demand-responsive transportation systems. Such data specifications are essential to a future in which these services can readily involve multiple service sponsors, funding sources, and transportation providers interoperating via—or across—technology platforms. 1.5 Examples of Transactional Data Specifications in Transportation Transactional data specifications are used in many market contexts. The combination of data specifications and technology platforms has fundamentally changed other transportation markets; two highly relevant examples are the online travel agencies and demand-responsive transportation for public transportation purposes in Denmark. Online Travel Agencies Online travel agencies (OTAs) such as Orbitz and Expedia revolutionized how consumers select a travel itinerary and purchase airline tickets and other travel services. The OTA platforms became feasible because of data technology developments circa 2000 that made it possible to interoperate, using standardized data flows, with the technology systems used by the airlines and the global distribution systems, which manage transactions for many airline ticket bookings. Standardized data made price/service comparisons among airlines seamless. Consumers— platform users—could view and compare information about services and prices on multiple airlines without searching among multiple airline websites and then select and book their preferred flight and pay for their tickets, all using the OTAs. Over time, the scope of what these platforms can accomplish for consumers has expanded (seat assignments, baggage fees, and the like) as all parties (airlines, global distribution systems, OTAs) agreed on additional data specifications, a process that continues to evolve. The OTAs are examples of consumer-payment–based, platform-enabled transportation services. They represent a specific type of e-commerce service targeted at individual consumers— the entire process is handled through private-sector mechanisms. In contrast, FlexDanmark is an example of platform-enabled transportation services constructed on a public-sector foundation. The FlexDanmark organization, itself a government-chartered enterprise, has developed the world’s largest demand-responsive transportation system on a foundation whose essential elements are third-party funding sources from the public sector and a comprehensive technology platform. FlexDanmark: Denmark’s Nationwide DRT FlexDanmark is the platform for DRT delivery throughout Denmark. Organized into Denmark’s six large regional public transportation service districts, DRT services are available to the general public and other target populations, with a large healthcare–related transportation component. Overall ridership is about 18,000 trips per weekday. Funding is provided by more than 500 public-sector (or quasi-public-sector) entities, including municipalities, human service organizations, hospitals and other healthcare organizations, and school districts. Service providers include more than 500 private transportation contractors—taxi companies, school bus contractors, medical van providers, and others, all of which must meet certain performance standards. The FlexDanmark platform includes comprehensive functionality for trip booking— via both agents in call centers and direct online access for many agencies, trip scheduling, assignment of transportation service providers and vehicles, vehicle tracking, and financial transactions for funding sources and service providers.

12 Development of Transactional Data Specifications for Demand-Responsive Transportation The FlexDanmark central platform interoperates with the scheduling/dispatching systems of all transportation service providers using standardized data protocols and flows based on a Scandinavian transactional data specification scheme (the SUTI standard), developed specifically for demand-responsive transportation. The SUTI specification—to which adherence is mandatory for all transportation service providers (i.e., their software systems must be able to exchange data messages with the FlexDanmark platform using SUTI language)—is the founda- tion for the interoperability that enables multiple providers and/or multiple service purchasers (e.g., hospitals, municipalities) to be able to “speak” with the FlexDanmark platform—and hence indirectly with each other. This world-class DRT system depends fundamentally on a compre- hensive transactional data specification. 1.6 Who Are the Stakeholders for DRT Data Specifications? The DRT industry is composed of a variety of organizations with different roles. These include public-sector organizations—whose roles in DRT can include organizing/sponsoring services, funding the service, and/or managing service as well as directly operating the service, and private-sector entities that may operate DRT services or provide technology of various types. Adoption of the recommended transactional data specification will require buy-in and action from stakeholders. The primary stakeholders for DRT data specifications, and the most important target audience for this report, are the following types of organizations and actors: • Public transportation agencies. In the United States, public transportation agencies (including municipalities and counties when they play this role) typically fund and manage DRT services such as dial-a-ride, ADA paratransit, and the emerging on-demand/flex/microtransit services. A public transit agency may operate the services directly, or it may contract with a private company to operate these services; the latter is more common. • Human service agencies. Human service agencies, typically private, nonprofit organizations, may also directly provide DRT services. Often these services are oriented to the elderly, persons with disabilities and/or mobility limitations, or other human service clients. • FTA. While the FTA provides policy leadership and funding programs for public transporta- tion, it has not to date extended its mandate to providing regulations for data standards for operating transportation programs and services. Policy-makers at FTA clearly understand the desirability of data specifications for all aspects of public transportation where data interchanges can improve outcomes. • State DOTs. As significant funders of public transportation in many states, particularly for small cities and rural/semirural areas where DRT services are more likely to be found, state DOTs have reasons for a policy interest in the adoption of data specifications. But like FTA, this is not an area where virtually any state DOT has been involved to date. • Other public funders of transportation service. A significant amount of DRT service is funded through healthcare or human service transportation programs. This includes Older Americans Act services, Centers for Medicare and Medicaid Services, and a variety of other public-sector– funded programs. The organizations in this category do not directly operate DRT for their clients, but fund the services that are provided by others, typically private transportation contractors, often including taxi companies. • Technology providers. Private companies that provide specific technology (typically software) systems or services in the DRT industry are stakeholders. The technology includes software systems used to schedule and manage DRT trips; larger software platforms that include trip- planning and fare-payment capabilities and integrated mechanisms to engage DRT services

Introduction 13 for consumers; and hardware-based technology with embedded software such as mobile data terminals and handheld devices. Some of these companies have hundreds of customers, and others have a handful. With the advent of a new generation of on-demand services, in conjunction with developments in technology, there has been a significant expansion of the number of companies in this category. • Private transportation operators. A variety of private companies provide DRT services to publicly funded agencies or to businesses. Some operate under contracts in which the vehicles, DRT software, and other technology are provided by the service organizer. Others are required to provide vehicles and technology, along with drivers, as part of the contract. Depending on the structure of the contract, these companies may provide their own vehicles, drivers, and operational staff, as well as specialized software for DRT and/or ADA paratransit and other technology (e.g., mobile or tablet computers in the vehicle). Private operators include national companies (e.g., First Transit, TransDev, MV Transportation) as well as regional and local companies. They also include taxi companies in many settings. • Taxi operators. Taxi operators occupy a special position, as they derive the majority of their revenues from private for-hire services—as with TNCs—yet have been used for public-sector– funded demand-responsive transportation services for many decades in many U.S. cities. Now facing an existential threat from the TNCs, the taxi sector has been a partner to the public transportation sector that has certain advantages compared to TNCs and whose preservation is considered important by many involved in DRT. • Transportation network companies (TNCs). Private providers of ride-hailing (or ride-sourcing) services, they typically have a technology platform that manages the entire service, accepting trip requests from customers initiated via a smartphone application, and then assigning rides to specific vehicles. They include companies such as Uber and Lyft for taxi-like service (which includes shared taxi services such as Uber Pool and Lyft Shared) and Via for shared-ride van services. It bears emphasizing that the TNCs are larger economic entities than any of the other organizations in the DRT industry. • Researchers and consultants. Academic researchers and consultants who work on projects in the DRT industry may also find this report relevant to their work, particularly the community of data specialists in the public transportation and on-demand services sectors. The latter recognize the importance of data specifications in all forms of urban mobility. 1.7 Benefits and Challenges of Implementing Specifications Benefits The benefits of transactional data specifications vary according to the interest of the stake- holder. For public transportation agencies and publicly funded entities that operate or fund DRT services, the implementation and use of transactional data standards would help them achieve three important policy goals. 1. Improve coordination. Data specifications for DRT services can improve productivity and effectiveness by better enabling existing DRT providers to share riders and group passengers traveling along similar paths and reduce the number of empty seats on return trips. For difficult-to-serve, lengthy regional or rural trips, implementation and use will allow pro- viders to schedule vehicle trips that combine a variety of passengers, so the cost per passenger is reduced. 2. Create opportunities for improved cost-effectiveness of DRT services. Many DRT services are costly and strain the resources of the organizations that fund them. There are multiple reasons for this, but transactional data specifications that enable multiple DRT service providers

14 Development of Transactional Data Specifications for Demand-Responsive Transportation (particularly those not previously involved but able to provide nondedicated vehicles) to be engaged so the supply of service can be more closely tailored to demand patterns, creates opportunities for more cost-effective DRT. FlexDanmark has been particularly effective in taking advantage of these nondedicated vehicle providers. Studies in Denmark indicate it is able to deliver service for significantly less cost per passenger trip than DRT services that existed prior to its introduction. 3. Strengthen private-sector involvement. Digital interaction capabilities that encompass both the source of DRT trips (trip-booking systems) and the software systems of DRT providers— which require a data specification that spans these domains—will enable transportation and human service agencies to more easily use a variety of DRT providers, many of which are in the private sector. A few agencies have developed efficient approaches to serve multiple types of trips with diverse purposes and destinations by creating fleets from multiple sources, including contracting some service to taxi companies and other private providers. A brokerage model is often cited as desirable, with a single agency controlling many providers using a single scheduling system. The ACCESS service in Pittsburgh and throughout Allegheny County is an example of this, serving a population of 1.2 million in an area of 745 square miles. It provides services for more than 140 agencies using six providers and over 300 vehicles, so each provider’s fleet is fairly large. Contrast this with FlexDanmark, which serves a population of 6 million in a much larger area (875,500 square miles) and uses 500 providers, many of which are small, “mom-and-pop” providers. Larger forms of the broker model are feasible with the right underpinnings. A uniform approach for transactional data would make it much easier for a multitude of small providers to participate in the delivery of DRT services. The expected benefits are similar to what FlexDanmark has experienced, namely, lower costs and a more robust network of service providers. Challenges There are at least three key challenges that must be overcome for the benefits of transactional data specifications for DRT to be realized. • Widespread adoption takes time. It takes time to develop, implement, and institutionalize the use of specifications. While GTFS is an example of the effective use of a specification, it is important to remember that it took well over a decade for widespread adoption. Early adopters do enjoy some benefits, but it is not until a significant number of entities adopt a standard that the benefits multiply. • Change is difficult. Change itself is often the most formidable challenge. Adopting a new way of doing business requires change among public agencies, DRT service providers, and technology companies. This will require adaptation, learning a new language and establishing new business rules and quality control mechanisms. • Lack of leadership or champion. A fundamental challenge to the adoption of recommended transactional data specifications by the DRT industry is that there is no current group or entity leading this effort. To date, no stakeholder has demonstrated sufficient interest or willingness to take a leadership role in promoting transactional data specifications for DRT. Without a leader, it will be difficult to carry such an initiative far enough to realize the complete benefits. A champion would inform others about the benefits of adopting data specifications, provide technical materials (such as language for procurement documents), and oversee a process to develop and maintain the integrity of the specifications. This latter process is important so developers can depend on the specifications for use in creating a technology platform.

Introduction 15 1.8 Strategies for Successful Adoption of Data Specifications Existing Systems While establishing a specification-based digital infrastructure for demand-responsive transportation in the United States will be challenging, successful models exist. As explained in Chapter 3, several European countries have adopted transactional data specifications developed initially in Sweden (SUTI standards), and there is now a process that spans multiple countries by which those data standards are governed and can evolve. But while the technical approach to the SUTI data specifications provided an excellent framework for this research project, the way in which those specifications have been adopted and subsequently governed cannot simply be transferred to the U.S. context, in view of the more authoritative role of the central government in Scandinavian countries. The successful systems from Sweden and Denmark do provide important guidance to the U.S. situation, the key lesson being that it is the governmental (or quasi-governmental) organizations that fund local transportation services that must act decisively to initiate the process of specification adoption. Specification implementation will occur only when such entities insist upon it as a condition for doing business. For transactional data specifications to be widely adopted, it is desirable that one or more organizations that represent public-sector funding sources assume a leadership role. For assuring the specification can continue to be developed while maintaining the integrity necessary for use in technology platforms, such leadership and a process of governance will be necessary. Support Materials The research team developed materials to assist public agencies and other funding sources in understanding the transactional data specifications developed in this project so that they can advocate for, and potentially lead, a process that could result in industry-wide adoption of these (or comparable) specifications. The research report includes information that will facilitate the adoption and use of transactional data specifications for DRT, including: • Materials to market the specifications, specifically a document that makes the business case for the proposed specifications; • Stand-alone technical materials, including a software tool that can validate data flows for consistency with the proposed specifications, that can be used to develop specification- compliant data exchanges; and • Requirements that can be included in requests for proposal, useful for organizations to stipulate that services they fund or contract for, and scheduling software they purchase, must comply with the proposed transactional data specifications for DRT. For the interested few to use these materials could result in a bottom-up approach to specifica- tion adoption, one that is relatively novel and could take a few years to make an impact across the entire industry. However, if even a relatively small number of organizations or states adopted this approach to technology procurement, it might lead to a much broader movement within a year or two and stimulate an industry-wide adoption of transactional data specifications. The experience from Europe with the SUTI standards indicates that DRT transactional data specifications can be developed and adopted by those that fund these services. To support continued development of the specifications, and maintain the integrity necessary to develop the technology platforms that will allow entities to realize the full benefits, a means of governance will be needed.

16 Development of Transactional Data Specifications for Demand-Responsive Transportation The purpose of this report is to provide those who wish to engage in this process with the rationale, knowledge, and practical tools to adopt and promote the widespread use of transactional data standards for DRT in the United States. 1.9 How This Report Is Organized This report consists of five chapters and eight appendices. The first and fifth chapters are oriented to a broad audience, covering all stakeholders who have an interest in developing and adopting transactional data standards for DRT. Chapters 2, 3, and 4 focus on the process of developing specifications that are functional for DRT providers and practical for technology vendors. These three chapters provide information on what was considered in developing the specifications and the result of the research, a proposed specification. Chapter 5 returns to a broader discussion of implementation. The appendices provide technical documentation of the specification and tools for implementation. Chapter 1—Introduction provides overviews of demand-responsive transportation and transactional data. It identifies the report’s target audience and previews the rest of the report. Chapter 2—Principles and Considerations in Developing the Transactional Data Specifi- cation discusses the key factors that were considered to develop the proposed DRT transactional data specification. These factors include core design principles such as simplicity and flexibility, market considerations, and the specific functional requirements for a DRT transactional data specification. Different technical models for implementing a DRT transactional data flow are described and a preferred model is presented. Chapter 3—Examples of Transportation Industry Data Specifications presents five examples of common data formats in the transportation industry, beginning with an example from the airline industry. The second and third examples pertain to the GTFS, which is commonly used to provide information about fixed-route transit services, and a new extension for flexible transit services. The last two examples—one from the Denver region and another from Scandinavia—are most relevant to this project and present examples specific to DRT transactional data. Chapter 4—Summary of the Specification presents an overview of the proposed DRT transactional data specification. Important technical elements, such as the data communication approach and types of data elements, are explained. Additional technical details can be found in Appendices D and E, which contain the full documentation for the proposed specification. Chapter 5—Conclusions and Future Considerations presents a short summary and key conclusions from this research project. Notable future considerations for implementation, such as governance for the specification moving forward, are also discussed. Appendix A—Industry Advisory Panel Members contains a list of the industry experts on the advisory group that participated in some or all of the industry advisory panel meetings. Appendix B—Engaging Industry Experts outlines the group of industry experts who were engaged to advise this project’s development process. This appendix summarizes the research team’s interactions with the industry experts throughout the duration of this project. The industry advisory panel participants took part in regular virtual meetings (calls) to provide input on the specification implementation. In the early stages of the project, team members conducted semi-structured telephone interviews with the members of this group to document their views of the benefits, challenges, and best approaches to developing a DRT transactional data specification. This appendix contains the protocol for those interviews. Appendix C—Industry Advisory Panel Final Meeting Presentation contains the presen- tation provided to industry advisory panel members on the final meeting of the project with

Introduction 17 this group. It summarizes the project and outlines important future considerations, such as governance issues. Appendix D—Detailed Specification Description provides the full documentation for the proposed DRT transactional data specification. This appendix is intended for audiences with background in software development and/or information technology. Appendix E—XML Listing of Specification contains the XML listing of the specification. Appendix F—Validation Tool describes the tool created during this project to validate the specification. The tool is publicly available on a website whose URL is published in the appendix. Appendix G—Marketing Document provides a short (one-page) marketing document that can be given to managers at transit agencies and other DRT service providers. It briefly explains what a DRT data specification is, and why DRT providers should adopt it. It is written in a nontechnical manner. Appendix H—Request for Proposals (RFP) Language presents two sets of text that could be used in a request for proposal (RFP) for paratransit scheduling software that would adhere to the proposed DRT transactional data specification. The first could be used by a transit agency or other DRT service providers in an RFP for procuring software; the second could be used in an RFP to assure that procured DRT services operate with technology that is compliant with the specifications.