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.

V. ADVANCING DATA STANDARDS Existing Foundation Important foundational pieces are in place for advancing data standards, including policies, processes, and specifications. On the policy side, a framework exists in support of this activity. The Research and Innovation Technology Administration (RITA) ITS Joint Program Office is responsible for the National ITS Architecture. This program is grounded in policy, standards development, and technology transfer activities and is guided by a five-year plan that reflects current priorities. RITA is in the process of developing a new strategic plan. FTA’s overall policy is that ITS projects be consistent with the National ITS Architecture. The FTA has integrated this into their grant administration activities. The current federal transportation legislation, known as MAP-21, includes specific funding to continue the process of standards development. Section 5314 provides for technical assistance and standards development, to support the effective and efficient delivery of public transportation service. Eligible activities may include “technical assistance and the development of voluntary and consensus-based standards and best practices by the public transportation industry”. The most notable example of the development of specifications is the General Transit Feed Specifications (GTFS), which have been so widely adopted that they have become a de facto standard for fixed route transit information. With Google Transit considering the extension of GTFS to flexible transit (which includes DRT), another key part of the foundation will be underway. Specifications developed for 2-1-1 and 5-1-1 systems also form an important part of the foundation. The RITA ITS Joint Program Office and the American Public Transit Association (APTA) have partnered in developing the Transit Communications Interface Profiles (TCIP). While the TCIP is focused on data communications between components and systems within vehicles, the existence of the TCIP suggest that there is an overall structure within public transit broad enough to encompass the development of standards for the scheduling, dispatch, and billing needed to coordinate DRT services. While the considerable work that has been completed forms a solid foundation for the next steps towards data standards, work still remains to develop the specifications necessary for one- call, one-click and other mobility management services that are based on data standards. Such specifications will also increase the ability of transportation providers to more effectively utilize ITS to reach mobility management goals. Process and Data Elements To advance data standardization, consideration needs to be given to both process and data elements. Key points in advancing standards through a consensus-based process include: 41

• An understanding that this is a heterogeneous industry with many actors who do not routinely communicate with one another. • An industry group will need to organize the process, as no software vendor has sufficiently dominant market presence to set standards. • The willingness of most software vendors, and all major software vendors, to cooperatively participate is key to a successful outcome. Process Paratransit software vendors will have a key role in developing the standards: their support of the use of standardized data is critical. While most software vendors agreed that standardized data is desirable, there exists inertia around the existing business models. Factors that could provide an impetus to move forwards towards standardized data include: • Hearing from customers that they want to buy products based on standardized data. • A clear message that the FTA wants to obtain full value from this investment by enabling systems to easily communicate with each other. • Addressing the issue of who will be responsible for creating the mechanisms to enable effective data transfers. Transportation providers also have an important role in the development of standards for transactional data. Transportation providers are the end users. Collectively, they understand the unique characteristics of a wide range of human service programs and the idiosyncratic nature of how they are implemented in different regions and states. They know the capacity of the partners with whom they would like to exchange data, from similar systems to very small Medicaid providers to volunteer driver programs. Only a limited number of specialized transportation providers have an information technology staff with sufficient knowledge to be full participants in such a process, but finding these individuals and inducing their involvement is very important to develop balanced data standards. A successful process will most likely be led by a neutral industry group and include both software vendors and transportation providers and result in a consensus-based set of specifications with the potential to be expanded over time. Leadership provided by a national organization will be critical, and the Community Transportation Association of America (CTAA) and/or American Public Transit Association (APTA) are logical choices for this role. CTAA represents many of the community transportation providers involved with delivering DRT services; APTA represents more of the larger public transit agencies and has a standards development process. Such a process might be structured as a “special interest group” or other voluntary association. 42

As one result of this study, a core group of individuals in the transit industry and among vendors has indicated a willingness to participate in a leadership role to develop specifications. It is recommended that such a group be convened approximately twice a year at transit industry conferences with intermediate meetings via web and video conferencing. Work products can be developed by participants and circulated among the group for comment, as they begin to both define the process and initial data elements. It bears re-emphasizing that development of standardized data that can be easily exchanged is a process, not a one-time event. Data Elements Approach In discussions with software and transportation industry representatives, there was concurrence that starting small is a key to establishing data standards. Standards can develop from a basic starting point in response to transportation industry needs. While it is likely that a wide-ranging effort will be needed over time, it is important that the broader issues are not allowed to distract participants from meeting the objective of getting agreement on an initial set of data standards or specifications. It is feasible that an initial set of specifications could be in place within 12 months for a base set of data, given the appropriate process and incentives. It is useful to distinguish here between the development of standards and the development of specifications. The term “standards” has been used throughout this report to describe an outcome: data elements each having an agreed upon definition, described so they can be exchanged in an electronic format. However, the term ‘standards’ can also be used to reflect a set of standards (such as safety standards) that are developed in a top-down process and must be met as minimums. The recommendation of this report is that specifications be developed, using a consensus-based process that involves both private and public sector stakeholders. Such specifications should be rigorously defined using a review process so that the specifications will meet the needs of the users of the data and the software while also achieving certain technical requirements of the software and its interfaces. Proposed Core Data Elements We have made a distinction throughout this study between data needed for service transactions and that needed for service discovery for mobility management initiatives. Consequently, we have divided our proposals for core data elements into those for service transactions and those for service discovery. We also recognize that achieving any level of data standardization, particularly for service transactions, is likely to be a challenging process that will probably occur incrementally and iteratively. This suggests that a “walk before we run” approach to agreeing on standardized data is more likely to be successful than trying to obtain agreement on comprehensive data standards 43

and data exchange protocols as the initial objective. Accordingly, the research team’s assessment of the core data elements that need to be included in the initial data standards follow. Data Elements for Service Transactions The data needed to support service transactions is of 5 types: 1. Trip data 2. Passenger data 3. Organization data 4. Financial data 5. Vehicle data The table on the following pages shows the proposed data elements for an initial standard. Table 2. Proposed Data Elements for an Initial Standard Category and Data Item Required Input? Required Output? Comments Passenger Header Record Passenger ID Y First name Y Last name Y Street address City Zip code Telephone number Y Ambulatory status Y Ambulatory or uses mobility aids Mobility aids indicator List of mobility aids if indicator present, null acceptable and means no aids needed Companion flag Y Number of companions could be substituted for flag Service animal indicator Y Type of service animal if indicator present Disability indicator List of disabilities if indicator present Extra boarding time indicator Y Amount of extra time needed if indicator present Medicaid eligible flag Depends on application whether required ADA eligible flag Depends on application whether required Agency affiliation Depends on application whether required, list of 0 to N agencies Trip Record 44

Category and Data Item Required Input? Required Output? Comments Trip ID Y Vehicle ID Y Passenger ID Y Origin street address Y Origin city Y Origin zip code Y Destination street address Y Destination city Y Destination zip code Y Requested pick-up time Y Promised pick-up time Y Pick-up time min Y Pick-up time max Y Requested delivery time Nullable if P/U time requested Estimated delivery time Y (?) Nullable if P/U time requested? Space type required Y Seat, wheelchair space Vehicle entry type needed Y Lift, ramp, driver assistance, etc. Trip fare Y Fare paid by passenger Trip distance Y O-D distance in miles (from GIS) Organization Record Agency ID Y Agency type Y Sponsoring agency or service provider organization or both Agency name Y Agency street address Agency city Agency zip code Agency phone number Y Financial Record Trip ID Y Sponsoring Agency ID Y Need convention for when no sponsoring agency, as in general public service Provider Agency ID Y Trip Price Bid Y Price agency willing to pay for trip Trip Price Offered Y Price at which provider willing to provide trip Trip Price Final Y Price at which parties agree to transact for trip transportation Vehicle Record 45

Category and Data Item Required Input? Required Output? Comments Vehicle ID Y Agency ID Y Agency ID for service provider WC space type capacity Y (?) Needed only by service provider Seat space type capacity Y (?) Needed only by service provider The two primary data records are the: (1) passenger record, consisting of 16 data elements, eight of which are mandatory; (2) the trip record, consisting of 18 data elements, 16 of which are mandatory. The other record types—organization, financial, and vehicle—have a total of 17 data elements, of which 14 are mandatory. Overall, there are a total of 51 data elements, of which 38 are mandatory, and it is possible that three of the mandatory fields are not essential for all parties to the transaction, as noted in the table. It is our understanding that all of the data fields specified above are present in the software applications currently being used for DRT services. They may have different names than those used in this report, but the data itself is present in the databases used by these applications. Data Elements for Service Discovery The data elements needed for service discovery are of a different character than those necessary to support transactions. Information and referral systems need data that describes fixed route transit, DRT, and other flexible services that operate within the service area of the I&R system. As discussed previously, the GTFS specification has successfully standardized the data that is used to describe fixed route transit services, but no such standards currently exist for DRT services. The proposed core data elements for service discovery for DRT services are presented in Table 3. 46

Table 3: Proposed Data Elements for an Initial Standard for Discovery Data Data Element Required? Comment Service name Y Service sponsor Y Service phone number Y For trip reservations Service Web URL Only relevant if Web booking possible Service area boundaries Y GIS shape file Service operating hours Y By day of week Ridership restrictions Y General public, ADA restricted, agency affiliation, etc. Service fare structure Y Listing of fares and applicability Reservation policies Y Advance notice requirements, subscription availability Cancellation policies Hours in advance of trip to avoid penalty Service accessibility Y Wheelchair accessible vehicles, other accessible options Scheduled points served Y Variation on GTFS-fixed route Timetables for scheduled stops Y Variation on GTFS-fixed route Vendor Comments In addition to the initial survey comments, a variety of comments were received from vendors and stakeholders through follow-up communication and a presentation and discussion of material at the 2013 CTAA EXPO conference. Key comments are summarized here and incorporated into the body of the document and recommendations. • Interest in pursuing data specifications has increased significantly over the course of the project. This appears to be from a combination of increased awareness of the available options and increased understanding of the importance of systems that can exchange data as systems continue to address the need for increased mobility at affordable costs. The research projects and the Veterans Technology Cooperatives at conferences have been important in raising awareness. Vendors’ interest has increased over the course of the project, and some have expressed an interest in taking more of a leadership role. Reasons for this may include their customers expressing the need for scheduling solutions with more flexibility across platforms, a realization that this is the direction of the future with interconnectivity between not just scheduling systems but a wide range of mobility management solutions, and learning firsthand the challenges of keeping track of many different data dictionaries and translators. • Specifications versus standards: this should be a consensus-based process resulting in data specifications rather than imposing standards on the industry. 47

The process should include software vendors and purchasers of scheduling and dispatch systems. It would be useful to broaden the process so that connections and opportunities with related data can be identified. • Consider the longevity of the current software applications, and include how specifications will evolve as part of the process. • Identify the education issues and needs of the vendors and providers. Recognizing that this is as much a business problem as a technology problem, it will be important to include the tools to help the providers and funding agencies in a region reach agreement and to build capacity among decision-makers. • Discuss the funding and responsibility for creating the interfaces and communication tools that will be needed to exchange this standardized data. • Follow existing standards in other industries and processes that have proven effective. At a minimum this would include 2-1-1, 5-1-1, GTFS, and basic computer language and system standards. • Organize another meeting of leaders and individuals with enough interest to pursue this initiative in the interim until it can be appropriately funded. Invite interested parties to address the problem of identifying what the paratransit and human services transportation community needs from the emerging data standards. • Consider the overall framework – scope and depth of effort that will be needed – even though the approach is to start small within that framework. A Scope of Work for Moving Forward A suggested scope of work has been drafted to describe the types of activities needed to move forward. Task 1. Create a forum of stakeholders for DRT to (1) guide the development of initial data specifications, standards and related business protocols, and (2) develop a strategic plan for the expansion of data specifications, standards and protocols. Task 2. Identify the scope and reach of the data specifications, standards and business protocols that will be addressed for DRT. This includes determining the appropriate relationship between activities, specifications, and standardization occurring in other ITS areas, such as with trip planners and the Open 511 Protocols, Transit Communications Interface Protocols (TCIP), and the various Federal requirements within the Regional ITS Architecture for software systems that are interoperable and provide purchasers with access to data. Define a consensus-based process for initial data specification definitions and how these data would be used. 48

Task 3. Review current efforts at Federal and state levels to provide for technology systems for DRT that provide the maximum interoperability, access to data, and building the capacity of staff to understand technology that impacts their jobs. Document how data flows between various software systems including the modes represented on web-based 5-1-1 services. Task 4. Prepare strategic plan that addresses (a) the development of additional data specifications, standards and protocols for DRT, (b) the ongoing maintenance of data specifications, standards and protocols, and (c) the migration from current DRT scheduling systems based on non-standard data to specified or standardized data. Identify how to assess the readiness and capacity of regions to pilot projects where communication between scheduling software systems is needed. Identify stakeholder roles in facilitating necessary transitions and specific steps to assure that specifications and standards across various applications are integrated and provide a solid foundation for ongoing development activities. Task 5. Develop and pilot a curriculum to train transit professionals, mobility managers, community transportation providers, and human service or non-profit agency staff as well as consultants to these agencies. The training should (a) strengthen understanding of the available choices, (b) explain how various options meet differing objectives or provide differing functionalities, and (c) assure that the procurement process reflects the choices and priorities made by the procuring agency and meets specific requirements for interoperability. This task could be initiated early in the work scope. Conclusion The development of data specifications for mobility management functions aligns with the strategic research goals and priorities of FTA and the US Department of Transportation Research and Innovative Technology Administration. Data specifications will enable the FTA to leverage their considerable investment in technology. Common standards providing for readily interoperable demand response scheduling systems will promote scheduling efficiency and increase productivity. One way it will do this is by supporting subcontracting, making it easier for agencies with empty seats on their vehicles to fill the seats with passengers needing service. More importantly, such data specifications will enable transportation providers to adapt to current technology and continue to innovate as technology changes and improves. The recommended approach is to actively involve transportation providers and scheduling software developers in a joint process to define specifications. Both bring important perspectives 49

to the process. Further, it is recommended that the effort start small with a minimal set of data items, growing over time. 50