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.

74 Engaging Industry Experts A P P E N D I X B The research team engaged a group of leaders drawn from the demand-responsive transportation industry as an external industry advisory panel during this project. The purpose of this industry advisory panel was to assess the current state of practice, learn about challenges and opportunities that currently exist, and discuss implementation and management issues for adoption of transactional data specifications. This appendix describes these activities and the analysis that was produced. The appendix begins with a description of the industry advisory panel approach and composition, then presents key findings from interviews and meetings with the advisory panel, and last, includes a discussion of governance of the proposed data specification, which was a key concern among the industry panel members. Industry Advisory Panel Approach and Composition The paratransit industry involves a variety of organizations with unique specializations. The industry can be described in a general manner as follows: Demand-responsive transportation service and technology providers range from small, independent services to large, international software firms and contractors Provisions and service requirements for demand-responsive transportation are affected by a mix of local, state and federal regulations Transit agencies have varying degrees of resources dedicated to demand-responsive transportation This collection of providers and regulations results in a fragmented market with operating characteristics adapted to each region. This patchwork of regulations and services is one challenge to widespread use of transactional data specifications. In light of these industry conditions, the research team identified experts to participate in an advisory panel to explain the nuances of the demand-responsive industry - including the differences across service providers, software companies and local market characteristics - and to help achieve agreement on a transactional data specification that can be implemented in the demand-responsive transportation industry. The industry advisory panel was comprised of members from representative organizations within the industry. The individuals and firms invited to participate were deliberately selected to represent a full picture of participants providing services within the demand response industry.

Engaging Industry Experts 75 Transportation network companies (3) Technology providers (8) Researchers in demand-responsive transportation and/or transit/DRT data systems (2) The industry advisory panel was involved in two types of activities. First, industry panel members participated in interviews with the research team. The interviews explored common themes, challenges and opportunities in the existing paratransit market, plus detailed discussion of how transactional data specifications could be introduced and managed within the market. Second, the panel convened for regular meetings held virtually throughout the project, during which the research team presented and discussed project development. These activities are discussed in the following sections, beginning with the industry advisory panel interviews. Industry Advisory Panel Interviews At the beginning of the project, the research team assessed the current state of practice, opportunities, and challenges for potential transactional data specifications through in-depth phone interviews with industry advisory panel members. The first part of each interview aimed to summarize the current state of the industry and provide background information about each participant. The second part asked about key benefits of a common specification for transactional data, and the third part focused on challenges to adopting a common specification. The last part of the interview asked participants to envision what a future specification would look like and the process for managing the specification in the future. Refer to the last section of this appendix for the interview protocol that research team members used to guide the interviews with industry advisory panel members. Interview Process Members of the industry advisory panel were invited to participate in an approximately 45- minute phone interview with one or more project team members in the summer of 2017. The interviews were semi-structured: team members had a set of discussion topics, pursuing those topics for each interview that yielded the most relevant information and opinions for this research. See the last section of this appendix for the interview protocol. Participation in the interview process was voluntary for advisory panel members; some declined participation and others were willing to participate but were not available during the timeframe when the interviews took place. Interviews were recorded and transcribed for accuracy. Overall, a total of 14 panel members participated in the interviews. The panel composition represents public agencies, private firms, and nonprofit groups. The research team recruited a total of 22 members for the industry advisory panel, who are listed in Appendix A; each member can be classified in one or more of the following categories: Transit agency managers (4) Private transportation operators (5)

76 Development of Transactional Data Specifications for Demand-Responsive Transportation Interview Findings on Industry and Roles Participants first discussed how their organization was using transactional data for demand- responsive transportation services. Three key findings are summarized here. Finding 1—Many private-sector players have developed internal systems that interface with different vendors’ proprietary systems. There are several large-sized software providers in the demand-responsive transportation industry (e.g., Trapeze, Routematch, Ecolane), and numerous interviewees worked with more than one of these vendors. In order to facilitate working with multiple technology companies across different regions, some private-sector players have developed internal systems capable of integrating with multiple products. This is happening at numerous companies (particularly technology providers and transportation service providers) with various levels of sophistication and integration. For example, one transportation service provider said that for the most part, it uses a single vendor (Trapeze) for its systems; however, it also works with two other vendors (Ecolane and Routematch) in a small number of locations. It then takes the data from each system and brings the data back to its own system, and it tries to standardize it so that it can run reports across locations. Similarly, one consultant said that for one of their products used in numerous locations, paratransit trips can be booked through three different systems (Ecolane, Trapeze, and an open source platform). Because each of these systems is slightly different, each booking is translated into one of three different languages on the backend to process these requests. Finding 2—There are a small number of very innovative pilot projects and programs. The first was the Denver Regional Transportation District (RTD) project, which included members of this TCRP research team. The second is a Vermont Agency of Transportation (VTrans) project that was using General Transit Feed Specification (GTFS) Flex in Open Trip Planner. The third was in the state of Pennsylvania, where customers used the “One Click” system to book trips; a noteworthy characteristic of this was that Pennsylvania Department of Transportation was working to streamline eligibility and payment rules for demand-responsive transportation services throughout the state. These three initiatives may warrant further study and future collaboration since they are particularly innovative projects in the demand-responsive transportation industry. Interview Findings This section presents the key findings from the interviews. The first part discusses general trends in the industry and roles of the various players. The second and third sections describe key benefits and challenges, respectively, of transactional data specifications identified by panel members, and the final section presents a brief summary.

Engaging Industry Experts 77 Interview Findings on Benefits The potential benefits of moving to a common specification for transactional data in demand- responsive transportation were discussed at length during the interviews. The interview responses varied somewhat across the industry advisory panel members. Through an analysis of interview content, the research team identified four broadly shared benefits. Benefit 1—Reducing operating costs. A key benefit that multiple parties repeatedly cited during the interviews was the potential for reducing the costs associated with software solutions for demand-responsive transportation services. In the interviews, one transit agency stated that controlling costs of paratransit service was a key benefit. Similarly, one technology provider said if there was a common data format, it would probably save them significant labor costs. Benefit 2—Facilitating data sharing. A common specification for transactional data could facilitate data sharing among public agencies that provide demand-responsive trans- portation services. For example, one transit agency said that it currently participates in a benchmarking group with approximately 20 other international agencies, and each year they provide data to this group. Its reporting could be streamlined if a data specification existed for paratransit services. example, the research team interviewed one transit agency that was conducting a pilot program with Uber and Lyft for its ADA complementary paratransit services. While this project had numerous potential benefits (including cost reduction), one key challenge was that there is no central clearing house for transactional data, which goes directly to the TNCs. A specification for transactional data could facilitate data sharing. Another transit agency that was interviewed was conducting a pilot program that provided demand- responsive transportation to the general public in a partnership with Via. Via provides an application (app) and the software, and the transit agency provides the vehicles, which are also used for the agency’s traditional ADA paratransit service. However, Via’s system is completely separate from this transit agency’s existing ADA paratransit software system. A specification for transactional data could facilitate integration of these systems. Finding 3—Some agencies are conducting pilot programs with TNCs that make standardized transactional data increasingly relevant. Public-sector participants in this project are seeking new, more flexible means of providing demand-responsive transportation services, and some transit agencies are currently partnering with transportation network companies (TNCs) to provide new demand-responsive transportation options to customers. These new partnerships create data-related challenges that make efforts to standardize transactional data increasingly relevant. For

78 Development of Transactional Data Specifications for Demand-Responsive Transportation Interview Findings on Challenges Interviewees also discussed the challenges of moving to a common specification for transactional data in demand-responsive transportation services. Five key concerns are highlighted. Benefit 3—Increasing flexibility of DRT services. During the interviews, numerous parties stated that they envision demand-responsive transportation services becoming increasingly flexible in the future, and standardizing transactional data is a step in this direction. For example, one transportation service provider explained during his interview that the indus- try is moving to a more flexible system, where passengers have more control over their own rides and can get same-day rides. This is a model similar to that of the TNCs applied to the paratransit market. There are unique challenges to coordinating this for paratransit, but data standards would help. Another transit agency said that it envisioned procuring a more dynamic and flexible system for operating demand-responsive trips in the future. It wanted it to be more TNC-like, and it was preparing for an RFP process in the near future to procure a new system. Benefit 4—Increasing availability of passenger apps. Another benefit of a more TNC-like paratransit industry is having simpler mobile applications that passengers can use to book trips. These would likely be easier to develop if there were common specifications for transactional data. In the interviews, one transportation provider said that a key benefit for passengers would be rolling out one application across all of their locations. Then, tech- savvy paratransit customers would benefit from this (similar to GTFS and Google Maps, which are used in many locations). Challenge 1—Wide variation in business rules and operational practices. Nearly all inter- view participants stated that a key challenge to developing a common specification for transactional data is the many differences in business rules and/or operational policies across service providers and agencies. For example, one transportation service provider said that if there was one universal system for providing demand-responsive transporta- tion services, then it could easily standardize across all of its locations. However, there are challenges because each transit agency has different rules and different vehicles. Similarly, one transit agency noted that big agencies tend to have different ways of doing things from smaller agencies. One technology provider stated that some people may say that technolo- gy is the barrier, but the real barrier is the operational needs and policies. Last, a consultant noted that everyone seems to have different rules in different regions. Challenge 2—Lack of incentive to standardize. Some interviewees noted that without some sort of financial incentive to standardize, it is unlikely that major players in the demand-responsive transportation industry will adopt a common specification for transac- tional data. For example, one transportation service provider stated in the interview that a common specification is actually against the interests of some of the software companies.

Engaging Industry Experts 79 Summary of Interviews This section graphically summarizes the key findings of the industry advisory panel interviews. Findings on the state of the DRT industry and implications for this project that aims to develop common transactional data specifications are shown in Table B-1. The most frequently mentioned benefits and challenges to this TCRP effort are shown in Table B-2. Challenge 3—High costs of switching to a new specification. Another key challenge to adopting a common specification for transactional data is the switching costs of moving from existing systems, which are often highly customized, to a new system. For example, one transit agency said that a major challenge would be the changes to its internal reporting systems. Right now, the transit agency has many customized reports based on its own naming conventions; changing the data naming conventions would require changing its reporting system, which would likely require significant in-house resources. One technology provider also noted that it will likely cost more for its clients the first time they order a new product; a standard could require extra development and testing, which would increase costs initially. Challenge 4—Possible privacy issues for healthcare–related data. A small number of interview participants suggested that there may be some concerns with medical-related data for some trip requests. The data privacy provisions of the Health Insurance Portability and Accountability Act (HIPAA) are important considerations. The HIPAA consider- ations could be considered an additional layer of data exchange in an XSD module (as proposed in an approach discussed in Chapter 4), and several healthcare technology start-ups are exploring solutions to this challenge. The need for coordination of health care and healthcare transportation is important, as reflected by it being the subject of other ongoing TCRP studies (including TCRP B-44: Examining the Effects of Separate Non-Emergency Medical Transportation (NEMT) Brokerages on Transportation Coordi- nation; and TCRP B-45: Transportation to Dialysis Centers: Health/Transportation Policy Intersection). Bringing experts in both industries together to solve this problem— potentially using tokens/keys to communicate sensitive information among healthcare providers’ and transportation providers’ systems end points—makes true coordination a formidable challenge. Challenge 5—Mis-specification. Some interview participants noted that a key challenge to this effort is making sure that the specification for transactional data has an appropriate scope. If the specification is too detailed or too broad, it may not work as intended. For example, one technology provider stated that he was concerned with diluting the standard. The standard might have a certain number of data fields, but more fields may be required for certain situations. On the other hand, another technology provider noted that if the stan- dard tries to encompass everything in a paratransit environment for all agencies, there would be so many variables, it would become too complicated and unwieldy. Similarly, one technology provider noted that the biggest threats of adopting common specifications are to the incumbents in the industry.

80 Development of Transactional Data Specifications for Demand-Responsive Transportation Private-sector players have developed internal systems to work with other vendors’ proprietary systems. Companies have various levels of sophistication and integration, which complicates adoption of new specifications. Few existing innovative programs and projects are relevant to transactional data specifications. Limited ability to learn from other successful projects. Pilot programs with TNCs raise the importance of common transactional data specifications. DRT services risk creating “walled gardens” of proprietary systems that do not communicate with each other. Table B-2. Benefits and challenges of common data specifications. Benefit Challenge + Reduced operating costs - Business rules vary widely + Facilitate data sharing - Lack of incentives to standardize + Increased flexibility in DRT services - Costs of switching specifications + Increased availability in passenger apps - Privacy concerns for healthcare data - Mis-specification of future standards Industry Advisory Panel Quarterly Meetings The second activity of the industry advisory panel was participation in six meetings held throughout the project period. These meetings took place in the form of conference calls approximately once each quarter to allow the industry panel members to receive updates on the research and to provide suggestions for development of the specification. All panelists were invited to participate, and in some cases two calls were scheduled for the same presentation to increase attendance. For all meetings, attendance was less than the full panel. Contemporaneous notes and recordings provide records of each discussion. The six industry advisory panel meetings took place on the following dates: Meeting 1 April 18 and 21, 2017 Meeting 2 June 2 and 6, 2017 Meeting 3 October 18 and 20, 2017 Meeting 4 December 4, 2017 Meeting 5 May 17, 2018 Meeting 6 August 20, 2018 Table B-1. State of DRT industry and implications for this project. Finding Implication

Engaging Industry Experts 81 For each meeting, the project team presented an overview of progress made and solicited direct feedback about specific issues. Most of the issues brought up in the panel meetings mirrored what was discussed in the interviews, which were summarized in the previous section. What the panel meetings highlighted beyond what was covered in the interviews was the issue of how to manage future specifications and what might a governance structure look like. The content of the quarterly meetings progressed concurrent with the project. Meetings held earlier were focused on helping the project team understand the DRT market and what elements were required of transactional data specifications. In the middle and later parts of the project, meetings focused on feedback of draft transactional data specifications developed by the project team and a discussion of potential models of governance for managing the specification after completion of this project. The following list provides a brief description of the meeting topics. Meeting 1 This meeting was used to introduce the project to the industry advisory panel. Much of the meeting was a presentation by the project team describing an existing example of DRT transactional data standards used in Scandinavia known as SUTI and discussing their applicability to transactional data specifications in the U.S. context. Meeting 2 This meeting covered some of the issues crucial for the successful development and implementation of a DRT data specification. This included specifications used in other countries (e.g., SUTI), and essential versus optional components of the specification (“must have” versus “nice to have”). The research team also queried members of the industry advisory panel on the challenges with their previous attempts at integration. There was a wide range of perspectives—particularly the level of effort and different objectives of public and private operators. Meetings 3–6 In each of these meetings, the research team presented updated approaches to the DRT transactional data specifications to the industry advisory panel. The research team then incorporated comments from industry panel members into the specifications. In Meeting 5, the research team presented the full draft of the proposed data specifications. In Meeting 6, the final specifications were summarized, and a key topic identified for continued discussion was governance of the specification, which is the focus of the following section. Appendix C includes the presentation provided to the industry panel members at the final meeting (#6), which summarizes many key aspects of this project. Governance of the Specification As mentioned in the previous section, a key issue that came out of the industry panel meetings was the appropriate entity to manage the DRT data specifications moving forward. Governance of the transactional specifications was widely viewed as critical for the short- and long-term successful adoption and use. Based on the industry advisory panel interviews and quarterly

82 Development of Transactional Data Specifications for Demand-Responsive Transportation meetings, eight possible models of governance were identified. The research team and industry advisory panel discussed the pros and cons of each potential governance model at length; however, there was no consensus as to the best approach. These models are listed in Table B-3 and described in the following paragraphs. Table B-3. Potential models for governance of the specification. Number Description Model 1 Federal Government Mandates Specification Model 2 International Organization Manages Specification Model 3 One or More Large Local Agencies Agree On Specification Model 4 Large Company Puts Forth Specification Model 5 Professional Organization Manages Specification Model 6 University Research Center Manages Specification Model 7 Consortium of Private-Sector Players Agree on Specification Model 8 Develop and Manage Specification as Open Source Project Model 1: Federal Government Mandates Specification Some interviewees suggested that the federal government might need to mandate a specification for it to be widely adopted. The specific agency that was mentioned by numerous interviewees was the FTA; however, there were some concerns about a government-mandated approach. Model 2: International Organization Manages Specification Another model that was suggested was having an international organization or collaboration manage the data specification. One technology provider noted that many of its clients are international, and there would be benefits of coordinating this effort beyond the United States. Model 3: One or More Large Local Agencies Agree on Specification Multiple interviewees suggested that collaboration among a few large public agencies could result in a means of managing a future specification for demand-responsive transactional data. For example, one technology provider suggested that a few large public agencies (such as the transit agencies that serve New York, Los Angeles, and Chicago) could come together to make a standard happen; then, they could release RFPs requesting that vendors use the standard. An interviewee from a transit agency suggested that a few innovative transit agencies work together and agree on a specification. However, it could be challenging to coordinate across cities. Model 4: Large Company Puts Forth Specification Numerous interviewees mentioned the example of Google and GTFS, which was a case in which a large company worked with a public agency to create a de facto standard. However, interviewees were not able to suggest a company that is sufficiently large in the demand-

Engaging Industry Experts 83 responsive transportation industry to develop a standard and convince a large part of the market to adopt it. Model 5: Professional Organization Manages Specification Many interviewees suggested that either APTA or CTAA would be an appropriate forum for managing a specification for transactional data. One interviewee from a transit agency favorably recommended APTA because the organization is well known in the industry. They would likely be able to convince their board that using a common specification is worthwhile if APTA is backing it. On the other hand, some private-sector players were skeptical of the role that APTA or CTAA could play due to a lack of technical expertise. Model 6: University Research Center Manages Specification At least one interviewee mentioned involving a university research center in the process of developing and maintaining the data specification. One possibility may be the Center for Urban Transportation Research (CUTR) at the University of South Florida. However, this would likely require a dedicated funding source. Model 7: Consortium of Private-Sector Players Agree on Specification Another model that was mentioned by several interviewees was gathering a consortium comprised of predominantly private-sector players. This could follow the model of the GTFS Best Practices Working Group that was recently convened; this effort was funded by the Rocky Mountain Institute, which is encouraging interoperable data standards. Model 8: Develop and Manage Specification as Open Source Project A final model that was mentioned by interviewees was an open source project. For example, one technology company cited the example of Android and Google. This could be in combination with another model or separate from the previously mentioned methods of managing the specification. Conclusions from Industry Advisory Panel Involvement In summary, engaging a panel of industry experts was a key component of this research project. Through individual interviews and regular online meetings, the research team was able to glean more nuanced knowledge of the issues at hand and began to work toward initial consensus on a common specification for transactional data. Overall, the industry advisory panel saw many benefits to having a common data specification in the demand-responsive transportation industry. Key challenges and concerns varied from organization to organization, yet there was generally broad support for this initiative. Given the input and ideas from the industry advisory panel, the research team next sought to investigate “lessons learned” from other data specifications implemented in the transportation industry to help guide this effort toward a meaningful and implementable specification; these examples are the focus of Chapter 3.

84 Development of Transactional Data Specifications for Demand-Responsive Transportation Interview Protocol The protocol is for semi-structured interviews by phone, with each interview taking approximately 45 minutes. Two TCRP project team members participated in each interview, one to ask questions and one to focus on taking notes. With permission, we audio recorded the interviews for accuracy. These recordings will not be published in any way or shared outside of the project team. Responses will be used to inform TCRP project reports and academic journal articles. Responses will not be tied to individuals. Rather, responses will be attributed to industry affiliations (e.g., technology providers, transportation service providers, public agencies, etc.). We assured each interviewee that participation in these interviews was voluntary and would not affect participation in the Advisory Board activities moving forward. The semi-structured interviews focused on the following four topics: Current State of Practice Please describe your organization’s current method for demand-responsive transactions (in as much detail as you feel comfortable sharing). Probe for knowledge of current industry practice for interoperable data (e.g., GTFS- Flex). What current or potential DRT projects is your firm working on, including use of APIs? Description of any actual experiences with data sharing and/or data transactions with other organizations in process of delivering service—probe for obstacles, issues, outcomes of any such experiences. Potential Future Specification How does your organization envision a DRT transactional specification evolving in the future? Who would they expect to lead this initiative (what type of organization and/or specific organization)? What would they expect would be the scope of the specification? Can you describe this future specification or the process that would be needed to create it? What would you anticipate that the specification would look like? Advantages What are the advantages for your organization of adopting a widely used specification? What are the perceived disadvantages, if any, of adopting a specification? What are the needs of your organization vis-à-vis any such specification? Probe for specific areas or examples.

Engaging Industry Experts 85 Probe about specific topics: operational advantages, options for using multiple service providers, ridership increases, etc. Challenges What are the challenges for your organization of adopting a transactional data specification?