Standardizing Data for Mobility Management (2013)

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.

IV. DATA EXCHANGE STANDARDS This chapter covers the related topics of how data is exchanged, the use of data exchange standards in other industries and common processes for developing data standards. Approaches to Standardized Data Exchange Many industries need major software systems to exchange data with other organizations. In the past decade, three key approaches to standardized data exchange have become commonplace. 1. Explicit data standards, whereby a core set of data is designated, including specifying data formats and meanings, that conforming software applications will be able to exchange with another application of the same type; such data standards often include consideration of how the data transmission process itself will occur (the Internet is typically the medium for data communications). 2. Data hubs, which provide a mechanism for software applications to exchange data without directly communicating with one another; the hub typically uses a proprietary approach to specifying data format and meaning, and while the hub is responsible for the actual data exchange process, each conforming software application must implement an “adaptor” (or “connector”) that translates data from its native format to that specified by the hub for the different data elements included. 3. Application programming interface (API) mechanisms, which are essentially a bi- lateral mechanism that enables collaborating systems to exchange data, in which one system “publishes” an API specification that enables another system to obtain data from—or submit data to—the host system using the data formats (and meanings) specified in the API document; the Internet is typically used as a communications medium. Each of these approaches has advantages and disadvantages, all are potentially relevant for mobility management systems, and they may be used in combination with each other. The focus in this section is on the first approach, in which an “industry” group of some type agrees on data formats and communication protocols and publishes these as the standards for data exchange. It bears emphasizing, however, that the other two approaches may represent a more rapid means of achieving data exchange among systems when no data standards exist and there is no existing industry framework for establishing standards. 32

Data Exchange Standards in Other Industries Air Travel Industry Since the 1960’s, the air travel industry has made use of a standardized means of structuring data about airline flights—and eventually, much more—in order to enable computer reservations system to share information about airline reservations/tickets. The need for data standards arose due to inter-lining requirements, in which a passenger’s travel itinerary involved one or more airlines other than the airline that the itinerary was booked on and which was used for the initial flight. There was a need to transmit the data for the flights on the other airline(s) to the computer reservations systems of those airlines, where a new record could be created in the other airline’s system which included a reference to—and all of the data of—the original record. This record could then be retrieved in the second airline’s computer system just as if the ticket had been originally booked on that second airline. The “solution” was the Passenger Name Record (PNR) system that continues to exist today in the airline travel industry, and which has been extended as well to hotel and rental car reservations booked in conjunction with airline travel. The PNR message system is far from ideal, as it was begun when teletype machines were used to transmit data and includes many features that are undesirable in a contemporary data standards system. It is quite complex, and there is a nearly 500-page manual that specifies the rules for message construction and transmission. While the syntax in that manual is now implemented in the computer systems used by the air travel industry, human beings using airline and global distribution system (GDS) computer systems nonetheless need to know how to “read” PNR data messages. Despite these shortcomings, the air travel industry continues to rely on these data standards and it is unlikely they will be superseded anytime soon. The basic PNR consists of the following information: 1. Record identifier—a 6 character value 2. Passenger name 3. Origin airport 4. Airline and flight number 5. Destination airport 6. Scheduled arrival and departure times 7. Additional data elements as in (3) thru (6) for other flight segments on the itinerary There are many optional data elements that can be included in the PNR, including bi-lateral data (defined just for the two systems exchanging the data). While there are very detailed rules about many of the data fields, others are somewhat flexible, such as the passenger name field, 33

which can contain multiple types of formats, particularly when multiple passengers are traveling on the same record locator number. By contemporary standards, the PNR system is undesirable as an approach to data standards. It suffers from numerous limitations and deficiencies. Nonetheless, it underpins data exchange among very large computer systems in a huge industry, and illustrates that what is most important in data standards is not technical elegance, but the simple act of the key organizations agreeing to use a common scheme to format and exchange data among systems. Electronic Health Records and Health Information Exchange The development of electronic health records (EHR, also commonly referred to as electronic medical records, EMR) systems began over a decade ago. Numerous large and small software vendors have developed EHR systems, and they have been implemented by thousands of health care organizations ranging from small medical practices to national scale health care giants with huge medical centers. It quickly became apparent that for EHR systems to have the greatest value, they needed to be able to exchange data. Consumers frequently change health service providers, and the data that has been generated for them in one EHR system needs to be transferred to the system of their new provider. Or a patient may receive treatment from medical practitioners in different health care organizations in the course of a medical episode, and the different practitioners need data from an EHR system other than their own. The federal government has played the key role in facilitating data standards for EHR systems, its leverage attributable to the magnitude of funding of health care services that occurs via the Medicare and Medicaid programs. Several years ago a certification program for EHR systems was developed, and most producers of these systems have had their products certified— which in important part means they must meet data standards, including 32 required data elements. The certification process is focused on EHR Modules, hence some EHR systems may have only some of their modules certified and others their entire product. The certification process and the accreditation of certification organizations is the subject of federal rules and quite detailed. Moreover, while certification of EHR systems is the key mechanism, the ultimate objective is actually health information exchange (HIE). That is, the movement of data between EHR systems to support the health care a consumer receives. The federal government has published other rules that are intended to encourage this objective, although they do not focus on specific data standards. The requirements for data standards for EHR systems are among the most rigorous for any industry, and are not a recommended model for mobility management systems. Nonetheless, this indicates that in a situation where the stakes are high, standards for data formats and data exchange are perceived as fundamentally important for driving positive change in an industry and for creating consumer benefits. 34

Data Exchange Standards in the Public Transit Industry The “Transit Communications Interface Profiles” (TCIP) standards are a major initiative organized by APTA, working in partnership with the US Department of Transportation Research and Innovative Technology Administration, to implement the U.S. ITS program within the transit industry. As stated by the key TCIP document: “TCIP is an interface standard. Its primary purpose is to define standardized mechanisms for the exchange of information in the form of data among transit business systems, subsystems, components and devices. The standardization of these interfaces is intended to reduce the cost of future procurements of transit computer based systems, and to facilitate a greater degree of automation and integration of those systems. TCIP recognizes that transit agencies operate differently, and have different internal architectures for their business systems, vehicles, and field systems. As a result TCIP does not mandate a single agency operating paradigm or any agency ITS architecture. Instead TCIP provides a rich vocabulary of possible information exchanges that agencies can use on an a-la-carte basis according to their specific business needs.”1 The TCIP standards are broad and flexible, containing a very large number of data elements. To date the TCIP data standards have been primarily focused on data communications between components and systems within vehicles. As such, the TCIP documents are focused on the so- called “connected vehicle” for transit systems. The TCIP standards define data and messages, and have a strong focus on data dialogs, which are exchanges of data via messages. The content of the messages is specified, including required data elements. The scope is relatively broad, encompassing much of the data on scheduling, passenger information display, vehicle positioning, real-time operations, fare collection, dispatching messages, etc. that occurs in the course of day to day transit operations. At the same time, the TCIP document is explicit in stating that these standards apply only to data exchange, and do not have any relevance to how data is internally stored, manipulated, displayed, etc. within the software systems internally used by a transit agency. The TCIP data standards represent potentially relevant guidance about how to approach the development of core data standards for mobility management systems. The focus on core data, minimum essential functionality, and data dialogs all seem to be important guidance for the development of first generation data standards for mobility management. The TCIP standards were developed within the “National ITS Architecture”2, a framework for ITS activities. The 1 American Public Transit Association, “APTA Standard for Transit Communications Interface Profiles”, Version 4.0.0, Vol. 1, p.1. 2 A summary from the paper “Key Concepts of the National ITS Architecture” states “The National ITS Architecture provides a common structure for the design of ITS. It defines the functions that must be performed 35

FTA maintains a policy that ITS projects be consistent with the National ITS Architecture. The National ITS Architecture identifies the services required by users (who could be the public or a systems operator) and then defining more detailed requirements for users. One of the service categories is Public Transportation, and within this are more specific requirements in areas such as Fixed Route Transit Operations, Demand Response Transit Operations and Transit Traveler Information. It is under the Public Transportation area that the USDOT has partnered with APTA in developing the Transit Communications Interface Profiles (TCIP), the transit component of the ITS family of standards. While this general policy provides support for the concept of interoperable systems, significant work is needed to assure that investments are made in systems that have the capability to easily exchange data with one another. The recommendations in this report provide a framework for such work. A brief on interoperability3 prepared by Community Transportation Association of America (CTAA) and provides sample language that can be used in current Requests for Proposals to obtain scheduling software systems with access to the information needed for the scheduling system to interoperate with other scheduling systems. Such systems will likely rely on translators that will require updating to reflect changes to the system such as a new provider or a new release of one of the software systems. Over time, as the data definitions are standardized and the means to exchange data are developed, more elegant methods of achieving this will be possible. The suggested language follows: “The Provider considers broad freedom of access to Provider data residing on the selected system to be of paramount importance. Proposers should describe how the Provider will be assured of complete, unfettered, direct, and perpetual access to Provider data and all associated information that renders the data useable and human-readable. This includes the following: full rights to create, read, update, and delete provider data as it resides on the proposed solution via SQL (structured query language) and common interfaces such as the Open Database Connectivity (ODC) standard, access to metadata-related documentation such as data schemas and data dictionaries that facilitate understanding of the solution’s data structures, and complete documentation of all application programming interfaces that the proposed solution exposes either via a network interface or to other applications residing on the same server.” by components or subsystems, where these functions reside (e.g., field, traffic management center, or in-vehicle), the interfaces and information flows between subsystems, and the communications requirements for the information flows in order to address the underlying user service requirements. Since the National ITS Architecture is also the foundation for much of the ongoing ITS standards work, consideration of the interface and information exchange requirements established by the Architecture today will likely facilitate or ease the transition to incorporating standards-compliant interfaces in the future.” Source accessed on August 2, 2013: http://www.iteris.com/itsarch/documents/keyconcepts/keyconcepts.pdf 3 The Interoperability Brief was prepared under a cooperative agreement with the Federal Transit Administration (FTA) for technical assistance to the Veteran's Transportation and Community Living Initiative (VTCLI). 36

Processes for Developing Data Exchange Standards In the case of the airline industry, standards were developed internally as the industries saw a business advantage in working together to create mechanisms to exchange data. This is common in many industries, particularly where the industry owns the software. In contrast, in the transit industry the scheduling software is purchased through third party vendors. In the development of electronic health records, the federal government played a significant role in facilitating the development of standards across diverse industries in which the government is a major purchaser of services. Similarly, the government and industry associations had a significant role in developing the TCIP data standards. Common to all processes are that it takes time and is an evolutionary process. Following are four examples of ways in which specifications have been developed to illustrate different processes: • General Transit Feed Specifications • Joint Council on Transit Wireless Communications • Alliance of Information and Referral Systems • 5-1-1 Data Exchange The private sector took a lead in the first example while the remaining examples illustrate how public sector and private non-profit sector groups have advanced standards. General Transit Feed Specifications (GTFS) provide an example of a mature process of developing standards. The GTFS evolved out of the original Google Transit initiative, in which Google developed a standardized method of describing fixed route transit services for use in its Google Maps platform to describe transit options for travelers. The Google Transit application is essentially a trip planner application with a map-based interface. Initially the system focused on a few big city transit systems. Google then informed the transit industry that if transit agencies submitted their fixed route system data to Google using these data formats, Google would enable Google Transit for that transit system. Many transit agencies took advantage of this offer, and within a few years the Google Transit application was available for most of the larger transit systems in the country. Because Google Transit’s data formats for fixed route service had in this manner become a de facto industry standard, Google decided to develop a formal specification for these data formats. This was named the General Transit Feed Specification (GTFS), although for all practical purposes this remains a Google standard. The Google Transit group within Google is responsible for managing the GTFS process of maintaining and extending the data specification (which is essentially a standard, despite the difference in terminology). There are a number of major data elements that comprise the specification, e.g., routes, stops, shapes, etc., each including many data sub-elements that must conform to a specific format. Google published the 37

initial GTFS document, and then created a process whereby a “community” of GTFS users could extend and modify the specification. Transit agencies and individual software developers—or the Google Transit manager themselves—propose modifications to the specification, comments are generated, participants engage in discussion and debate about the merits of the proposals, and eventually the Google Transit manager makes a decision about changes to the specification. There have been many relatively minor changes made to the specification in this manner, and there is an active community of users who participate in this process. It bears emphasizing that even though GTFS has had a major impact on how public transit agencies format their data for use on the Web, there is no official public sector direction of the GTFS process—it is entirely a voluntary effort with Google itself the ultimate decision maker of how the specification evolves. The Joint Council on Transit Wireless Communications. According to their website, the organization “was established in 2009 in response to results developed under the National Academies, Transportation Research Board (TRB), Transit Research Cooperative Program (TCRP) Project, C-18 Strategic Plan for Meeting Transit Industry Wireless Communications Needs. Under this project, a strategic plan for transit industry wireless communications was developed through a collaborative effort with the American Public Transportation Association (APTA), the Community Transportation Association of America (CTAA), and other industry representatives. One of the transit industry goals identified in the resulting strategic plan is the creation of a joint council to implement the strategic plan.” “The vision of the Joint Council on Transit Wireless Communications is to be the collective voice committed to addressing transit industry wireless communications needs. Transit industry wireless communications needs have too often been not adequately represented in the Federal Communications Commission (FCC) regulatory process, Federal Transit Administration (FTA) funding, Department of Homeland Security (DHS) emergency planning, and equipment standards. Our mission is to assure that the transit industry wireless communications needs are continuously met through information sharing. This sharing of information is in both directions — to and from transportation providers and other groups, including government, manufacturers, and service providers.” The Joint Council on Transit Wireless Communications was established as a voluntary (non- membership) transit organization to capture all aspects of the passenger transportation industry, to provide a place to address interests, and to engage crucial partner organizations. (Source: www.transitwireless.org) The American Public Transit Association and Community Transportation Association are national partners supporting this initiative, and the members represent a wide range of private industry and public transit interests. Initial funding was received under the National Academies through TRB and TCRP, with these organizations receiving their funding from the Federal Transit Administration. 38

Alliance for Information and Referral Systems is a professional member association serving over 1,200 information and referral services. Their mission is to "To provide leadership and support to its members and Affiliates to advance the capacity of a Standards-driven information and referral industry that brings people and services together."
 AIRS works in partnership with a variety of national associations and: • Supports a taxonomy for organizing 2-1-1 social service information, • Establishes processes and standards to provide quality control, and • Provides training, and certification. One of the unique characteristics of this organization is the massive amount of volunteer time that went into the development of the taxonomy, led by a Los Angeles County librarian. The website describes this taxonomy as follows: “The AIRS/211 LA County Taxonomy is the North American standard for indexing and accessing human services resource databases.
 The Taxonomy is a hierarchical system that contains more than 9,000 fully-defined terms that cover the complete range of human services…. The Taxonomy is an intellectual property copyrighted by 211 LA County4 and available only to licensed subscribers. Vendors who create I&R software that incorporates the Taxonomy and I&R services that use the software to maintain a resource database employing the Taxonomy, are required to maintain a valid license. The Taxonomy serves as a common language that facilitates interoperability between different I&R resource databases. It represents a tremendous gift to the I&R movement that has evolved over 20 years thanks to the commitment of 211 LA County and the Taxonomy's editor, Georgia Sales. The cost of developing and maintaining anything comparable from scratch today is almost inconceivable.” Both the Joint Council on Transit Wireless Communications and AIRS have dealt with issues of developing standards and informing a wide range of participants. Both bridge issues that cross between traditional organizations. These are characteristics that are also common to developing data standards for specialized transportation. A key difference is that the Joint Council on Transit Wireless Communications received substantial funding through research organizations and the Federal Transit Administration while AIRS undertook much of its technical work on a volunteer basis. It is notable that AIRs recognizes the value of the taxonomy and the benefits to the I & R sector in having the taxonomy. 39 4 http://www.airs.org/i4a/pages/index.cfm?pageid=3386 211 LA County has provided licensing to the human service taxonomy for over a decade at www.211taxonomy.org.

5-1-1 Data Exchange. A third example of developing common standards is for transportation information through 5-1-1 centers. A group working through the Metropolitan Transportation Commission in California’s Bay Area and Open North is developing a 5-1-1 Data Exchange that includes a proposed Open511 Protocol. Their working paper draft version 1.0 describes the Open511 Protocol and notes the reasons for a 511 Data Exchange, “Open511 is a newly designed open standard that defines a set of data interfaces in order to facilitate access to 511 data. These interfaces are intended to benefit both internal and external traveller application development…..511 systems host a wealth of traveller information that can be a valuable resource for innovative application development by external parties if the data can be exposed through a data exchange standard. In addition to sharing data with developers, adoption of standard based data exchange would also help share data between a 511 system and other data sources, a transit agency for example, as well as neighbouring 511 systems, facilitating traveller information across neighbouring 511 jurisdictions. Each 511 system has developed its own mechanism to collect data and disseminate information. An open standard for disseminating data would help 511 data consumers easily access data and develop their products based on a set of known interfaces.” Often the software used by 5-1-1 systems is developed internally and owned by the 5-1-1 organization, although portions may be purchased from vendors. This is in contrast to scheduling software for demand response transportation. The ownership of the software provides the entities with the flexibility to determine the auxiliary components they find to be useful. Application to Data Standards for Mobility Management Characteristics of mobility management include: • It is a diverse industry that includes public sector, private non-profit agencies, and private for-profit agencies of all sizes. • Activities range from the discovery functions of one-call, one-click centers to the transactional functions involved in scheduling, dispatching, and billing for DRT trips. • Software is primarily provided by for-profit vendors, although in some areas open- source software is used. • It is important to bridge to data used for fixed route trip planning software and the communications platforms used in the transit industry, so building upon existing specifications (GTFS, TCIP) will be useful. Any process for advancing data standards will need to be consensus-based and include the software vendors and the consumers. Ideally it will have the support of both major associations, APTA and CTAA, and will be supported by federal agencies with a vested interest in the outcomes. 40