MDS Working Group

• Every other Thursday at 9am PT, 12pm ET, 5/6pm CET

Zoom Registration Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York) - though we encourage Zoom

Note: Attendees register upon entry into the Zoom meeting. An attendee count will be posted here after the meeting:

30 Attendees

Main Topics

Passenger Services Data Field Mapping

• led by Marie M, Neil G, Alex D
• See Pull Request #763 for comments from agencies
• Review new table mapping existing agency data requests to MDS fields
• Categorized fields by level of difficulty (easy, medium, hard)
• Discuss and document uses cases for new fields

WGSC Meeting Organizers

• Host: Sebastian Berthaud, Blue Systems
• Facilitator: Marie Maxham, E&A
• Outreach: Michael Schnuerle, OMF
• Note taker: Nivedya Madankara Kottayi, SANDAG

1. Steve: Review and contribution from cities specially how to implement this.
2. Marie: Link to document: https://docs.google.com/document/d/1OV6MiH0bZSF_jswCNwObKwXO-PYdr_uWxf3no27Slk4/edit#

• Marie Maxham (MM) presented the document which is work in progress. MS came up with the structure. Looking at across 6 different municipalities we got a variety of data fields resulted in sparse mapping. In some cases, differences are straight forward, and some cases are very obvious.
• Information about drivers: We have anonymized the passengers, but driver information needs to be discussed.
• Fare information: How much they are paid. Are they working unsafe number of hours is something need to look into.
• Other consideration: We collect trips, we do not collect the notion of trip that wad requested that never happened. All trips need to have device ID. For trip cancelled by the user there might have been a vehicle assigned. But the company level, it is not captured anywhere. How to capture, new endpoints, is derivable from events, new trip type as incomplete trip and multiple ways to address that.
• We should incorporate the feedback as possible at the same time not bloating the spec. So that is why we have mandatory and optional components. Trip attributes will have fare, and make it more standardize it when we have more appointments and may be leave it open. We have good representation of cities and would like to get additional feedback from them.
• Brooks Jessup: It seems like we are talking about the expansion of provider vs agency. We do separate API for telemetry vs trip data. So, are we combining it into one?
• MM: It is done differently by different API. Right now, in provider the telemetry comes through the trips. But you can also get the events stream to track the vehicle out of trip behavior, you will be looking at out of trio events which had telemetry associated wit it. We have existing mech for telemetry and agency to attach to events and outside of events as well.
• How we are going to bring agency and provider in close alignment. Next Friday working group to drill that down.
• MM: Discussion on Information about drivers. Where to draw the line. Do we need opaque ids, and perform regulatory functions and yet resolvable mechanism.
• Alex Demisch: Compensation is also a compelling use case.
• MM: Right, drivers would give up some amount of privacy for better protections. Tell me more about ideal driver information collection looks like. What will you be willing to settle for.
• Alex: They already established processes. I think we feel strongly about keeping at least the operator’s ID, eg. driver’s license number.
• Danny Yeung: It is super critical to have their ID, we use legacy thing and collect driver’s license number and consider privacy protection feature also.
• MM: How privacy protecting is the driver’s license ID is? It doesn’t have name associated with it and does it have available through public records.
• Danny: I believe no, we get it from a different database.
• Vlamidi Gallegor: We also have database associated with drivers and keep them disconnected and limited access. To enable Drivers to be able to log on the distance how long they have been on. Some things like over charging, not picking up seniors are looked into.
• Where do you envision the driver ID information stored in MDS? Is it from the license plate?
• VG:It should be unique to the company. Not certain where how.
• MM: We found a gap and will take that to the team
• MM: Back to SFO, License Id is a Unique ID tracked across multiple vendors
• Danny: That is correct. ID is used to log in to theory systems and easy to remember and at the back end we can infor and if they switch to a different cab company, we get that info too. We will know if they are working unhealthy hours, or any suspicious action we can go to the unique person.
• Matt: As someone who handles data from cities all over the world with a variety of regulatory regimes I'd prefer to minimize the personal data involved, I like the idea of using a UUID driver ID that operators can look up if necessary.
• MM: We have a vehicle registry and some human registry is probably on the bail and may be left to the individual municipalizes.
• Matt Davis: No need of human registry and just ID is needed and get to the operator regarding the driver.
• Peter Panov: Tracking patterns of behavior across services would be impossible. Ask the services to provide some hash sort of driver’s license and it should be consistent.
• MM: Is this an achievable goal? May be a hashed driver’s license ID is a good start. Any counter example to share? People can come back and contribute to document.
• Information about compensation: Let us assume we have some way to identify driver compensation trip by trip and handle it. First reaction was to stuff it in trip attributes as well. Does that sound reasonable. Compensation is not directly tied to a trip. Any feedback to that.
• Danny: In SFO, we do give compensation/incentives for delivering trips to wheel-chair users, also on odd hours and for underserved communities. It has to be liked to a trip and if they meet the min number of trips, they get this compensation.
• MM: MDS is intended to be able to verify. It is important to have fine grained compensation details somewhere.
• Last thing I want to cover is the data types that are currently nowhere. Specific ones are italicized in the document. In Portland, they collect, unable to fulfill request, declined by the company, cancelled by the customers. In New York, more into passenger explicitly cancelled and some details about driver covered % of the distance etc and that failed. We do not have how a way to represent this in MDS other than events. Events has meta data and some of this information can be derived. Any use cases that are flat out and not covered by MDS.