The Transactional Data Specification: A Building Block for Equitable Mobility-as-a-Service

A simple, but integral technological advancement holds the promise of creating a stronger, more equitable transportation system. In the fall of 2019 the National Academies of Sciences, Engineering, and Medicine’s Transportation Research Board took a small but meaningful step towards addressing access inequality when it published the transactional data specification (TDS) for demand responsive transportation (DRT). This rather mundane step is vital to facilitating the integration of human services transportation with emerging Mobility-as-a-Service (MaaS) platforms—where all the ways one can travel about the community become available at the click of a button on one’s smartphone. But this new world of mobility where ridehailing businesses like Uber grow in popularity threatens to be inaccessible to a large swath of people who currently depend on paratransit buses unless MaaS developers embrace a common format for data sharing.

Open Data Standards Reduce the Cost and Complexity of MaaS Platform Build-out

The TDS complements other transit specifications, including the General Transit Feed Specification (GTFS). The GTFS defines the common format for public transportation discovery data that can be readily used by Google Maps and other trip planners. The GTFS-Flex is an extension that allows customers to view services that don’t follow a fixed route or schedule. Both are key to accurate navigation.

By expanding data-sharing the TDS enables the exchange of the transactional information necessary to request, schedule and fulfill trips on demand-responsive services. Even more important the TDS enables multiple DRT providers to operate as one integrated network. Each providers’ use of their chosen scheduling software is no longer a barrier to interoperability as they can now exchange information about vehicle capacity, schedules, and routes in order to automate the task of co-mingling riders. The use of data specifications allows this interoperability to occur more efficiently and affordably than can be done through traditional means.

This is a significant departure from the status quo in demand-responsive transportation. In the outdated approach, software developers must create one-off translators for each connection while maintaining their own APIs. Relying on non-standardized translators or APIs, raises the cost of interoperability significantly, both initially and over time. It also creates brittle technology that scales poorly. And it often results in “vendor lock,” meaning that software vendors may encourage DRT providers to switch vendors rather than support interoperability with a competitor. Vendors may also reduce or withdraw support for translators arbitrarily or without advance notice.

The more streamlined and sustainable approach is for software vendors to embed a standardized API, such as the TDS, into their applications. If software applications and updates are made compatible with the TDS, then interoperability with all providers is maintained. Using a specification for data exchange can improve data quality and compatibility. It would also reduce the complexity and the cost of information exchange. Furthermore, the TDS is open source, meaning anyone can access the software code for free and incorporate it into its system.

Encouraging the Use of the TDS

As the industry moves in the direction of providing customers with MaaS, there is the inherent need for systems to interoperate, or at a minimum share data efficiently. The challenge lies in the immediate moment, in which software companies are competitors within a highly siloed environment. They may fear that they could lose market share if all software products speak the same “language.”

There are roles for both the public and private sectors to address the inequality of access to MaaS before it takes hold. While human services transportation efforts must modernize to keep pace with the acceleration of emerging platforms, public agencies and businesses need to understand the value of data standardization.  

The TDS is being tried in a handful of pilot projects. Over time, as more entities use and refine the specification, it may become a defacto or official data standard. The key is to halt business-as-usual and move toward an open platform future where human services transportation has a seat at the MaaS table. To get there, the public sector needs to insist on open data specifications and standards rather than proprietary, walled-garden solutions, which may not be able to adequately serve all segments of the community—particularly those with incomes too low to purchase market-rate transportation or those whose physical or cognitive needs may be more expensive to accommodate. An open-platform future can facilitate the participation of many software companies and transportation providers in regional MaaS platforms and ensure the most efficient delivery of high-quality services.

Human services transportation should be part of the new mobility ecosystem. Only when it is can we ensure that those who depend on DRT services tailored to their needs can access the seamless, on-demand services of the future. The TDS is a fundamental building block.

To learn more, read the full paper, “Modernizing Demand-Responsive Transportation in the Age of New Mobility