Data Privacy Plan · 2019. 2. 8. · commitment in its Statement of Data Stewardship Principles (Chapter 3). It then defines controls for privacy (Chapter 4), data security (Chapter

Smart Columbus

Data Privacy Plan

for the Smart Columbus

Demonstration Program

DRAFT REPORT | February 8, 2019

Produced by City of Columbus

Notice

This document is disseminated under the sponsorship of the Department of

Transportation in the interest of information exchange. The United States Government

assumes no liability for its contents or use thereof.

The U.S. Government is not endorsing any manufacturers, products, or services

cited herein and any trade name that may appear in the work has been included

only because it is essential to the contents of the work.

Acknowledgement of Support

This material is based upon work supported by the U.S. Department of

Transportation under Agreement No. DTFH6116H00013.

Disclaimer

Any opinions, findings, and conclusions or recommendations expressed in this

publication are those of the Author(s) and do not necessarily reflect the view of

the U.S. Department of Transportation.

Data Privacy Plan – Draft Report | Smart Columbus Program | i

Acknowledgements

The Smart Columbus Program would like to thank the following members of the Technical Working Group

for their assistance in drafting and reviewing this Data Privacy Plan.

Dennis Hirsch

Keir Lamont

Mehmet Munur

Dorene Stupski

Kirk Herath

Charles Campisano

Tom Harris

Ty Sonagere

Peter Voderberg

David Landsbergen

David Daniel

Doug McCollough

Amanda Girth

Jeff Hunsaker

John Sohner

Jeff Kanel

Nick Nigro

Brian Nutwell

Jim Perry

Jack Maher

Schlaine Hutchins

Data Privacy Plan – Draft Report | Smart Columbus Program | iii

Abstract

The Smart Columbus Demonstration Program Data Privacy Plan (DPP) provides an overarching

framework for the ways in which Smart Columbus will protect the security of personal information that it

collects and uses, and the privacy of the individuals to whom this information pertains. Smart Columbus is

committed to be a responsible steward of this personal information. The DPP makes clear this

commitment in its Statement of Data Stewardship Principles (Chapter 3). It then defines controls for

privacy (Chapter 4), data security (Chapter 5), publicly available data (Chapter 7), and the oversight of an

institutional review board (IRB) (Chapter 6). Together, these components provide a structure for

protecting privacy and data security throughout the Smart Columbus Operating System.

In addition to this DPP, system security protocols for non-PII data are contained in project-specific

documents.

Data Privacy Plan – Draft Report | Smart Columbus Program | v

Table of Contents

Executive Summary ....................................................................................................................... ix

Scope and Approach ......................................................................................................................... ix

Chapter 1. Introduction .................................................................................................................. 1

1.1. Project Description .................................................................................................................... 1

1.2. Core Functions of the Operating System .............................................................................. 4

1.3. System of Systems overview .................................................................................................. 6

1.4. Roles ............................................................................................................................................ 7

Chapter 2. References .................................................................................................................. 9

Chapter 3. Principles and Legal Protections for Projects that Utilize Personally Identifiable

Information ..................................................................................................................................... 11

3.1. Statement of Data Stewardship Principles .......................................................................... 11

3.2. Compliance with Applicable Laws ....................................................................................... 12

3.3. Demonstration Data ................................................................................................................ 13

Chapter 4. Personally Identifiable Information Privacy Controls ............................................... 15

4.1. Privacy Controls ...................................................................................................................... 15

4.1.1. Authority ......................................................................................................................... 15

4.1.2. Notice and Consent ....................................................................................................... 15

4.1.3. Data Minimization .......................................................................................................... 16

4.1.4. Use and Sharing of Personally Identifiable Information ................................................ 16

4.1.5. Data Quality ................................................................................................................... 17

4.1.6. Data Retention ............................................................................................................... 17

4.1.7. Access and Correction ................................................................................................... 18

4.1.8. Transparency ................................................................................................................. 18

4.1.9. Accountability ................................................................................................................. 18

4.1.10. Control Boards ............................................................................................................... 19

4.1.11. Contractors and Other Third Parties .............................................................................. 20

4.1.12. Privacy Impact Assessments ......................................................................................... 20

Chapter 5. Personally Identifiable Information Security Controls ............................................. 21

5.1. Types of Controls .................................................................................................................... 21

5.2. Means of Control ..................................................................................................................... 22

5.3. Control Implementation Details ............................................................................................ 22

Table of Contents

vi | Smart Columbus Program | Data Privacy Plan – Draft Report

5.3.1. Security Control Catalogue ............................................................................................ 22

5.3.2. System Monitoring ......................................................................................................... 26

5.3.3. Data Loss Prevention .................................................................................................... 26

5.3.4. Antivirus and Malware Checking ................................................................................... 26

5.3.5. De-Identification ............................................................................................................. 26

5.3.6. Need-to-Know ................................................................................................................ 27

5.3.7. Compartmentalization .................................................................................................... 27

5.3.8. Training .......................................................................................................................... 27

5.3.9. Audits ............................................................................................................................. 27

Chapter 6. Institutional Review Board Oversight of Personally Identifiable Information ......... 29

6.1. Participant Personally Identifiable Information Data Integrity and Storage .................. 29

6.2. Other Institutional Review Board Issues ............................................................................. 33

6.3. Privacy Incident Reporting .................................................................................................... 34

Chapter 7. Public Availability of Datasets ................................................................................... 35

7.1. Commitments ........................................................................................................................... 35

7.1.1. Benefit-Risk Analysis for Making Datasets Publicly Available ....................................... 36

7.2. Technical, Administrative and Legal Controls ................................................................... 40

7.2.1. Technical Controls ......................................................................................................... 40

7.2.2. Administration and Legal Controls ................................................................................. 41

7.3. Registering Applications to Provide Downstream Usage Information .......................... 41

7.4. Transparency and Public Engagement ............................................................................... 42

7.5. Motivated Intruder Test ........................................................................................................... 42

7.6. Review and Continuous Improvement ................................................................................ 42

Appendix A. Data Inventory ......................................................................................................... 43

A.1 Connected Vehicle Environment Project ............................................................................ 43

A.2 Multimodal Trip Planning Application/Common Payment System ................................. 44

A.3 Smart Mobility Hubs ................................................................................................................ 44

A.4 Mobility Assistance for People with Cognitive Disabilities .............................................. 45

A.5 Prenatal Trip Assistance ........................................................................................................ 45

A.6 Event Parking Management ................................................................................................... 46

A.7 Connected Electric Autonomous Vehicles ......................................................................... 46

A.8 Truck Platooning ..................................................................................................................... 46

Table of Contents

Data Privacy Plan – Draft Report | Smart Columbus Program | vii

Appendix B. Privacy Impact Assessment ................................................................................... 49

Appendix C. National Institute of Standards and Technology Special Publication 800-53

Control Categories ....................................................................................................................... 53

Appendix D. National Institute of Standards and Technology Special Publication 800-122

Checklist Summary ...................................................................................................................... 63

Appendix E. Acronyms and Definitions ...................................................................................... 65

Appendix F. Glossary ................................................................................................................... 69

List of Tables

Table 1: References ...................................................................................................................................... 9

Table 2: ‘Participant’ Groups ....................................................................................................................... 31

Table 3: Publication Value ........................................................................................................................... 37

Table 4: Publication Risk ............................................................................................................................. 38

Table 5: Benefits and Risks of Dataset Inclusion ........................................................................................ 39

Table 6: Privacy Impact Assessment Outline of Required Contents ........................................................... 49

Table 7: National Institute of Standards and Technology Control Categories Correlation .......................... 53

Table 8: National Institute of Standards and Technology Checklist ............................................................ 63

Table 9: Acronym List .................................................................................................................................. 65

Table 10: Glossary ...................................................................................................................................... 69

Table 11: Connected Vehicle Environment Project Data Flow Matrix ......................................................... 71

Table 12: Truck Platooning Project Data Flow Field Matrix ........................................................................ 72

Table 13: Prenatal Trip Assistance Project Data Flow Field Matrix............................................................. 75

Table 14: Multimodal Trip Planning Application Project Data Flow Field Matrix ......................................... 77

Table 15: Event Parking Management Project Data Flow Field Matrix ....................................................... 84

Table 16: Mobility Assistance for People with Cognitive Disabilities Project Flow Field Matrix .................. 86

Table 17: Connected Electric Autonomous Vehicles Project Data Flow Field Matrix ................................. 87

List of Figures

Figure 1: Smart Columbus Framework ......................................................................................................... 2

Figure 2: Core Functions of the Smart Columbus Operating System .......................................................... 5

Figure 3: System of Systems External Context Diagram .............................................................................. 6

Data Privacy Plan – Draft Report | Smart Columbus Program | ix

Executive Summary

This Data Privacy Plan (DPP) provides high-level guidance, principles and policies to ensure the privacy

of Smart Columbus Demonstration data subjects and project participants. While the City of Columbus

Smart Columbus Program Office oversees many innovation initiatives, the scope of this document

includes all data in the Smart Columbus Operating System (Operating System) and other United States

Department of Transportation (USDOT) funded projects. The City of Columbus USDOT funded Smart

Columbus program will be known throughout this document as Smart Columbus.

The intended audience is the Smart Columbus project managers, the USDOT, transportation researchers,

the Institutional Review Board (IRB) and those engaged in the deployment of Smart Columbus projects.

This document applies to all individuals who use or share data with Smart Columbus, including all Smart

Columbus employees, partners and consultants. Where applicable, contract and other acquisition-related

documents will include terms providing for compliance with the requirements of this DPP.

SCOPE AND APPROACH

To provide more efficient, equitable and sustainable transportation options, Smart Columbus will need to

collect and process certain categories of personal information. Smart Columbus is committed to good

stewardship of this personal data, providing notice and consent for collecting personal information,

collecting the minimum amount of personal information necessary to achieve its specified purposes,

protecting it securely, and handling it with respect for individual privacy and autonomy. This DPP sets out

the measures that Smart Columbus will take to ensure the privacy of demonstration data subjects and

participants in Smart Columbus projects.

This DPP describes the principles that will guide the Smart Columbus project teams in developing

governance documents to protect the privacy of users and participants, guard against potential breaches

of Smart Columbus systems, and prevent unauthorized use of the participant data and other Personally

Identifiable Information (PII). Therefore, the DPP will inform all contracts, notices and processes that are

being formed to comply with its stated approach to security and privacy for the Operating System and all

Smart Columbus projects. Any successor entity to the City of Columbus shall comply with this DPP with

respect to the data collected under the policy.

This DPP sets out high-level privacy protections and oversight governing Smart Columbus. The initial

plan was developed early in the Smart Columbus program and set forth the system essentials to which

project-level clarifications have been added quarterly, as Smart Columbus projects progressed. The

approach to documenting high-level privacy protections and oversight has been iterative, bringing this

high-level plan forward in manageable steps as the projects that it guides have informed it. Project-level

data privacy development will use the guidance of this plan to resolve project-level designs, having

helped to inform this plan. Details of data privacy for data subjects will be realized as part of the systems

engineering process as user needs and requirements are developed under IRB oversight.

The Data Management Plan for the Smart Columbus Demonstration Program (DMP) is a companion

document to this DPP and describes how data will be collected, managed, integrated and disseminated

before, during and after the Smart City Challenge demonstration. This DPP provides privacy and security

guidelines and controls that govern Smart Columbus and therefore is the highest-level governing

reference for the projects in this program. It does not address system security of the individual

Executive Summary

x | Smart Columbus Program | Data Privacy Plan – Draft Report

demonstration projects. The requirements for each individual project will separately address system

security.

The treatment of project participants and their PII will be defined by IRB processes that are consistent

with this DPP, made through IRB-approved informed consent documents and research protocol

documents.

Data Privacy Plan – Draft Report | Smart Columbus Program | 1

Chapter 1. Introduction

1.1. PROJECT DESCRIPTION

In 2016, the U.S. Department of Transportation (USDOT) awarded $40 million to the City of Columbus,

Ohio, as the winner of the Smart City Challenge. With this funding, Columbus intends to address the most

pressing community-centric transportation problems by integrating an ecosystem of advanced and

innovative technologies, applications, and services to bridge the sociotechnical gap and meet the needs

of residents of all ages and abilities.

With the award, the City established a strategic Smart Columbus program with the following vision and

mission:

Smart Columbus Vision: Empower residents to live their best lives through responsive,

innovative, and safe mobility solutions.

Smart Columbus Mission: Demonstrate how Intelligent Transportation Systems (ITS) and

equitable access to transportation can have positive impacts on every day challenges faced by

cities.

As stated in the Executive Summary, while the City of Columbus Smart Columbus Program Office

oversees many innovation initiatives, the scope of this document is any data that is in the Operating

System or that is in any of the other USDOT funded projects. The City of Columbus USDOT funded

Smart Columbus program will be known throughout this document as Smart Columbus.

To enable these new capabilities, the Smart Columbus program is organized into three focus areas

addressing unique user needs; enabling technologies, emerging technologies and enhanced human

services. The individual projects described below were categorized into these three focus areas as seen

in Figure 1: Smart Columbus Framework.


2 | Smart Columbus Program | Data Privacy Plan – Draft Report

Source: City of Columbus

Figure 1: Smart Columbus Framework

The Columbus Smart City Demonstration Projects include the following:

The Smart Columbus Operating System (Operating System)

The Operating System is the essence of Smart Columbus – it brings to life the innovation. The

Operating System is being designed and built to collect data from a variety of inputs; including

public, nonprofit, education-based and private sector contributors. These inputs may come from

other systems, devices and people. All of which are a critical part of building this ecosystem of

innovation. Data will be available for analytics and visualization as well as for artificial intelligence

required by various smart city applications. The Operating System is a platform designed for Big

Data, Machine Learning and Artificial Intelligence, Analytics, and complex data exchange. It will

capture the data and provide a means for multi-tenant access to aggregate, fuse, and consume

data.

The Operating System will have an isolated environment that will transform and ingest Personally

Identifiable Information (PII). Datasets housed in the Operating System include the Smart

Columbus demonstration projects, traditional transportation data, and data from other community

partners, such as food pantries and medical services. The Operating System will be scalable and

will demonstrate the potential for serving city and private sector needs well beyond the life of the

Smart City Challenge award period.

Connected Vehicle Environment (CVE)

Cars, trucks and buses will talk to the infrastructure and talk to one another to reduce traffic and

increase safety. The CVE will connect 1,800 vehicles and 113 smart intersections across the

region. Safety applications are intended to be installed on multiple vehicle types including transit

buses, first responder vehicles, city and partner fleet vehicles and private vehicles. Applications

will be deployed to ensure emergency vehicles and the Central Ohio Transit Agency (COTA) Bus



Rapid Transit (BRT) fleet can utilize signal prioritization when needed to ensure safety and

efficiency. The data created by the system will be anonymized, de-identified, aggregated and

stored by the Operating System for historical analysis and visualization.

Multimodal Trip Planning Application (MMTPA)

The MMTPA will provide a robust set of transit and alternative transportation options including

routes, schedules and dispatching possibilities. The application will allow travelers to request and

view multiple trip itineraries and make reservations for shared-use transportation options such as

bike-sharing, Transportation Network Companies (TNCs) and car-sharing. Users will be able to

compare travel options across modes, and plan and pay for their travel based upon current traffic

conditions and availability of services. The data created by the system will be anonymized, de-

identified, aggregated and stored by the Operating System for historical analysis and

visualization. A trip optimization micro-process will reside within the Operating System platform

and be supported by the real-time data-handling in the Operating System.

Common Payment System (CPS)

The CPS will serve as an account-based, back-office payment processor for the MMTPA and

EPM application. To facilitate integration with both applications, the CPS will provide landing

pages and Application Programming Interfaces (APIs) allowing Travelers to manage CPS

accounts and issue payment requests for transportation and parking services. Requests for

payment will flow through a payment broker microservice in the Operating System, which will be

responsible for directing payment requests to the CPS back office, communicating payment

status to the applications, and for capturing anonymous trip and payment data for use in analytics

and performance measurement. The CPS back office will be compliant with Payment Card

Industry (PCI) Data Security Standards (DSS), ensuring the security and confidentiality of PII.

Smart Mobility Hubs (SMH)

Smart Mobility Hubs will be deployed to serve traveler more effectively needs by expanding

transportation resources and offering access to comprehensive trip planning tools at designated

locations. SMH sites are primarily located adjacent to existing COTA CMAX and transit center

facilities and will help bridge the First Mile/Last Mile gap between transit and destination by

providing physical space for the consolidation of services such as bike/scooter share, car share,

and ride share. Interactive kiosks and public Wi-Fi will be made available to the traveler to view

real-time travel information and to book multi-modal trip plans via the MMTPA/CPS.

Mobility Assistance for People with Cognitive Disabilities (MAPCD)

The city will deploy an innovative smartphone application for people with cognitive disabilities to

transition off costly paratransit services and travel independently on the fixed-route bus system.

The application will be piloted with 15 to 30 individuals in the Columbus region in partnership with

the Central Ohio Transit Authority (COTA) and The Ohio State University (OSU). The application

will include a highly accurate, turn-by-turn navigator designed to be sufficiently intuitive such that

older adults and groups with disabilities including the cognitively and visually disabled can travel

independently. The data created by the system will be anonymized, de-identified, aggregated and


Prenatal Trip Assistance (PTA)

The city will develop a system for providing flexible, reliable, two-way transportation to expectant

mothers using Medicaid Managed Care Organization brokered non-emergency medical

transportation services. The data created by the system will be anonymized, de-identified,

aggregated and stored by the Operating System for historical analysis and visualization.



Event Parking Management (EPM)

The EPM system will integrate parking information from existing garages, surface lots, and

parking meters in Downtown and the Short North into a single mobile application and web-based

solution. This system will allow travelers to search for and reserve parking in advance or on the

go. More direct routing of travelers during large events is expected to reduce congestion during

those times. The data created by the system will be anonymized, de-identified, aggregated and


Connected Electric Autonomous Vehicles (CEAVs)

CEAVs that operate in a mixed-traffic environment interacting with other vehicles, bicyclists and

pedestrians will be deployed. The project provides an accessible and easily expandable first

mile/last mile transportation solution to the region by deploying a fleet of multi-passenger CEAVs

that will leverage the enhanced connectivity provided by the CVE and the citywide travel planning

solution. The data created by the system will be anonymized, de-identified, aggregated and


Truck Platooning

Freight signal prioritization on CV-enabled trucks will be deployed to reduce freight-induced

congestion and queuing. In addition, multiple two-vehicle CV-enabled truck platoons will be

deployed from Columbus to the eastern Ohio area. Wireless communications will be added to

existing vehicle technologies to allow trucks to reduce their headways when traveling on

freeways. On arterials, these vehicles will receive platoon intent signal priority enabling two trucks

to traverse an intersection during the same signal phase cycle. Platooning is also expected to

save fuel and reduce vehicle emissions. This project is anticipated to increase the efficiency and

stewardship of logistics companies by improving freight mobility and reducing emissions. The

data created by the system will be anonymized, de-identified, aggregated and stored by the

Operating System for historical analysis and visualization.

1.2. CORE FUNCTIONS OF THE OPERATING SYSTEM

Figure 2: Core Functions of the Smart Columbus Operating System depicts high-level system

elements of the Operating System.




Figure 2: Core Functions of the Smart Columbus Operating System

The Operating System is a platform for Smart Cities development. It consists of several core functions,

which can be leveraged across the Smart Columbus program, as well as other functions that will

specifically enhance and support “Smart Applications.”

The core functions in the Operating System are described below:

Data Environment: The orderly ingestion, aggregation and tagging of many forms of data from

real-time, to slow-moving or manually-uploaded data.

Data Lake: A storage repository that holds a massive amount of raw data in a secure way and

makes it available to all the other supported operations in the system.

Security: To ensure trust, it is imperative that the Operating System is exceptional at managing

the users and systems that have access to it.

Scalable Capacity: The Operating System is “scalable” and “elastic” which means that it can

grow and shrink to meet the demand of the system at any given time.

Shared Services Environment: Application components can be housed and made available to

any number of applications connected to the Operating System.

Data Research Environment: In a data-rich environment, Columbus and its residents,

businesses, nonprofits and visitors will be increasingly able to share, use and leverage previously

unavailable datasets to address complex problems and improve current operations and

capabilities.

Analytics: Analytics will also be used to predict future conditions and the potential benefits of

implementing different operational strategies, control plans and response plans coordinated

among agencies with Mobility Providers.



1.3. SYSTEM OF SYSTEMS OVERVIEW

The Smart Columbus program has many interrelated systems that work together to provide a System of

Systems (SoS). Information from these systems are shared in the Smart Columbus Operating System.

Both real-time and archived data is maintained in the Operating System for use by other Smart Columbus

projects and future applications. The SoS provides Smart Applications, Smart Vehicles, and Smart

Infrastructure to travelers in the Columbus area. The Operating System enables the SoS to share data

with many other external systems to provide the framework for the services provided. Figure 3 shows the

relationship of the SoS to the external travelers and systems.


Figure 3: System of Systems External Context Diagram

The Smart Infrastructure element contains the roadside units (RSUs), hubs, and corresponding network

that enable interactions between these items and the Operating System. Smart Vehicles include the on-

board units (OBUs) that will be installed in vehicles and include various vehicle types. Smart Applications

include the software-oriented solutions that will deliver other Smart Columbus project capabilities such as

multimodal trip planning, common payment, prenatal trip assistance, etc. The Operating System is the

repository for all performance data from the Smart Infrastructure and Smart Vehicles, as well as the

shared services platform that allow the Smart Applications to be directly integrated.



1.4. ROLES

Smart Columbus will appoint individuals with the following roles:

Chief Privacy Officer – Responsible for the sustained viability, compliance and oversight of data

privacy policies and processes.

Chief Security Officer – Responsible for the design, implementation and oversight of the

information technology and physical security of the program and its project components.

System Administrators – Responsible for the integrity and availability of the data.

Data Curators – Involved with the design and integration between the Operating System and

entities that contribute data. Responsible for the proper execution of the data curation process to

include ongoing efforts to validate data, its usage, and continuous improvement. Establishment

and maintenance of relationships with data providers.

Data Architects – Responsible for the design and integration of all system back-end components.

Data Stewards – Responsible for working with the Operating System to ensure that data is

validated, categorized and compliant with all agreements established at ingestion.

An individual may share one or more of these roles.


Chapter 2. References

Table 1: References lists documents and literature referenced during development of this DPP.

Table 1: References

Document Number Title Revision

Publication Date

N/A Ben Green et al., “Open Data Privacy: A Risk-Benefit, Process-Oriented Approach to Sharing and Protecting Municipal Data,” Berkman Klein Center

https://cyber.harvard.edu/publications/2017/02/opendataprivacyplaybook

N/A 2/2017

N/A Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, FIPS PUB 199. (2004). FIPS Pub 199

http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

N/A 2/2004

N/A Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, FIPS PUB 200. (2006). FIPS PUB 200

http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf

N/A 3/2006

N/A Erica Kinkel, “Open Data Release ToolKit,” DataSF

https://datasf.org/resources/open-data-release-toolkit/

N/A 11/3/2016

N/A Future of Privacy Forum, “City of Seattle Open Data Risk Assessment”

https://fpf.org/wp-content/uploads/2018/01/FPF-Open-Data-Risk-Assessment-for-City-of-Seattle.pdf

N/A 1/2018

N/A Khaled El Eman, “A De-Identification Protocol for Open Data,” IAPP

https://iapp.org/news/a/a-de-identification-protocol-for-open-data/

N/A 5/16/2016

800-60 National Institute of Standards and Technology (NIST), NIST Special Publication 800-60 Revision 1. (2008). NIST Special Publication 800-60

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v1r1.pdf

N/A 8/2008

800-122 NIST Special Publication 800-122

https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-122.pdf

N/A 4/2010

800-53 NIST Special Publication 800-53 Revision 4 (2013)

http://dx.doi.org/10.6028/NIST.SP.800-53r4

N/A 4/2013
















http://dx.doi.org/10.6028/NIST.SP.800-53r4

Chapter 2. References


Document Number Title Revision

Publication Date

800-188 NIST Special Publication 800-188, “De-identifying Government Datasets”

https://csrc.nist.gov/csrc/media/publications/sp/800-188/archive/2016-08-25/documents/sp800_188_draft.pdf

N/A 12/15/2016

N/A Official (ISC)² Guide to the CISSP CBK, Fourth Edition. (2015). ISC2 Press.

N/A 2015

N/A The Privacy Act of 1974 (Title 5, U.S. Code, Sec. 552a) N/A 1974

N/A The Common Rule (Title 45, Code of Federal Regulations (CFR), Part 46 (Protection of Data Subjects)

N/A 1981

N/A Ohio Revised Code § 1347: Personal information systems N/A

N/A Ohio Revised Code § 149.43: Availability of public records for inspection and copying

N/A 12/19/2016

N/A “Protection of Human Subjects,” Title 45, CFR, Part 46 (Public Welfare Department of Health and Human Services)

N/A 1/15/2009

FHWA-JPO-17-461

THEA Connected Vehicle Pilot Data Privacy Plan, Phase 2, Task 2-C, FHWA-JPO-17-461

https://rosap.ntl.bts.gov/view/dot/32034

N/A 2/2017

FHWA-JPO-17-317

THEA Connected Vehicle Pilot Human Use Summary, Phase 1, Task 8, FHWA-JPO-17-317


N/A 7/2016

N/A Smart Columbus System of Systems Concept of Operations, FHWA-JPO-18-635

N/A 1/12/2018

N/A Draft Smart Columbus Data Management Plan N/A 2018







Chapter 3. Principles and Legal Protections for Projects that Utilize Personally Identifiable Information

This Data Privacy Plan details the privacy and security controls for all aspects of the Smart Columbus

data environment that collect, use and/or share PII. To maintain focus on the importance of privacy and

security, the City has aligned this Plan with the following Statement of Principles that sets out Smart

Columbus’ strong commitment to privacy and data security. It then explains how Smart Columbus will

implement and achieve each of these principles and serve as a responsible data steward.

3.1. STATEMENT OF DATA STEWARDSHIP PRINCIPLES

To provide more efficient, equitable and sustainable options, to improve the livelihood of Columbus

residents, and to administer the project, Smart Columbus must collect, process and share some

participant personal information. Smart Columbus takes very seriously its obligation to respect individual

privacy and to protect personal information. The following PII data privacy and security principles will

guide Smart Columbus in its collection and handling of personal information that is managed during the

USDOT grant program and into the future:

Smart Columbus will not collect, use or share PII without the data subject’s knowledge and

informed consent.

Smart Columbus will collect and use the minimum amount of PII necessary to satisfy the

purposes of the demonstration.

Smart Columbus will use and share PII only for the specific purpose to which the data subject

consented, or for other compatible purposes, and will do so in ways that respect individuals’

reasonable expectations.

Smart Columbus will take all reasonable measures to ensure the quality and accuracy of the

information it uses.

Smart Columbus will retain PII only for so long as is necessary to accomplish the purposes for

which it was collected or to accomplish other compatible purposes.

Smart Columbus will provide a mechanism for individuals to access and correct their PII.

Smart Columbus will take reasonable data security measures to protect PII.

Smart Columbus will be as transparent as possible about its collection, use, maintenance and

disclosure of personal information, without revealing security measures.

Smart Columbus will institute the processes necessary to hold itself accountable for compliance

with these principles and with the project policies and procedure documents that implement them.

Smart Columbus will notify affected individuals, USDOT and the relevant IRB of the existence of

and its response to data security breaches.



3.2. COMPLIANCE WITH APPLICABLE LAWS

Smart Columbus will comply in all material respects with all applicable federal and state laws, rules,

regulations, orders and decrees including but not limited to:

The Privacy Act of 1974 (Title 5, USC, Sec. 552a)

The Common Rule (Title 45, CFR, Part 46 (Federal Policy for the Protection of Human Subjects))

The Ohio Revised Code § 1347: Personal information systems

The Ohio Revised Code § 149.43: Availability of public records for inspection and copying

Smart Columbus Data Classifications:

Non-PII is anything that is not PII. Encrypted data and data reasonably de-identified of PII and

Sensitive Personally Identifiable Information (SPII) are Non-PII.

Publicly Available PII is Non-PII for the purposes of this policy.

PII is information that can be used to distinguish or trace an individual’s identity, such as their

name, Social Security number (SSN), biometric records, location data, etc., alone, or when

combined with other personal or identifying information which is linked or linkable to a specific

individual, such as date and place of birth, and mother’s maiden name. The definition of PII is not

anchored to any single category of information or technology. Rather, it requires a case-by-case

assessment of the specific risk that an individual can be identified by examining the context of

use and combination of data elements. Non-PII may become PII when additional information is

made publicly available. This applies to any medium and any source that, when combined with

other available information, could be used to identify an individual.

Sensitive PII (SPII) is a subset of PII which, if lost, compromised or disclosed without

authorization, could result in substantial harm, embarrassment, inconvenience, or unfairness to

an individual. Sensitive PII requires stricter handling guidelines because of the increased risk to

an individual if the data are compromised. The following PII is always (de facto) sensitive, with or

without any associated personal information:

o SSN

o Passport number

o Driver’s license number

o Vehicle Identification Number (VIN)

o Biometrics, such as finger or iris print

o Financial account number such as credit card, bank account number, or CPS Identification

o Health information, including medical history, mental or physical condition, or medical

treatment or diagnosis

o Medicare status

o Alien Registration Number.



In addition to de facto Sensitive PII, some PII may be deemed sensitive based on context. Some PII

becomes SPII when paired with another identifier, such as:

Citizenship or immigration status

Ethnic, religious or sexual orientation or lifestyle information

Last four digits of SSN

Date of birth

Criminal history

Mother’s birth name

Several Smart Columbus projects require that participants register which, by necessity, may include the

collection of SPII. Protecting this data creates special considerations. SPII must be treated in accordance

with Title 45, CFR, Part 46 (Protection of Human Subjects), and the approved documents of the IRB.

Smart Columbus has established policies and procedures to ensure that PII and SPII can be protected in

accordance with all applicable standards and documents. This DPP discusses the policies, procedures

and security controls that will be used in the protection of all participant PII and data subject information.

3.3. DEMONSTRATION DATA

Smart Columbus will collect data both before and during the demonstration projects’ life cycles. Some of

this data will be baseline data that existed prior to Smart Columbus, is already publicly available and may

contain PII. For example, data that contains PII may be used to validate performance measures for a

specific project. Based on the scope of this document, unless that data is ingested into the Operating

System, this DPP will not dictate its protection.


Chapter 4. Personally Identifiable Information

Privacy Controls

The following Smart Columbus privacy controls are broadly guided by the USDOT-City of Columbus

Cooperative Agreement, the Fair Information Privacy Practices (FIPPs), and the National Institute of

Standards and Technology (NIST) privacy control catalog contained in Special Publication 800-53(r4)

“Security and Privacy Controls for Federal Information Systems and Organizations” – Appendix J. The

NIST Privacy Control Catalog applies to the majority of U.S. federal information systems. It provides

agencies with a structured set of privacy controls, based on best practices, which help organizations

comply with generally applicable, and organization-specific, privacy laws and policies. The NIST privacy

controls are consistent with and supplement those specified in the Cooperative Agreement. Appendix C,

National Institute of Standards and Technology Special Publication 800-53 Control Categories

summarizes how this DPP correlates to the NIST categories.

4.1. PRIVACY CONTROLS

In accordance with the Cooperative Agreement, Smart Columbus will apply the following controls to all

Smart Columbus data containing PII throughout the demonstration’s entire data life cycle and will require

all sub-awardees and contractors to do the same.

4.1.1. Authority

Smart Columbus projects will collect and use only categories of personal information that are required to

fulfill the grant objectives. By dates respective to each project’s progress, Smart Columbus will develop a

data inventory that specifies data classification that Smart Columbus intends to collect through each

demonstration project and all anticipated uses of that information.

All distinct Smart Columbus projects and sub-entities will maintain a record of datasets that have PII

restrictions.

4.1.2. Notice and Consent

Where possible, Smart Columbus will provide timely, clear and specific notice of its collection, use and

sharing of PII. Through various methods, Smart Columbus will provide this notice, at the point of

collection, to the individuals from whom the PII is being collected. Where notice at the point of collection is

not possible, Smart Columbus will provide clear and specific notice as soon as practicable.

For example, in the CVE project, prospective participants will receive a clear and understandable

presentation covering the privacy risks associated with joining the project. Only data that is necessary to

get the participant into the informed consent process will be collected prior to the execution of the

informed consent, in accordance with procedures that have received advance approval from the

demonstration’s IRB (see Chapter 6. Institutional Review Board Oversight of Personally Identifiable

Information). Informed consent will be predicated upon:

Chapter 4. Personally Identifiable Information Privacy Controls


Data to be collected

The intended use and recipients of the data

Clear notice of any privacy risks of participating, and of opportunities to opt out

The general controls put in place to mitigate those risks

All rights that participants will hold over their own data

At the end of the presentation, each participant must sign a consent agreement to confirm their

understanding of how the demonstration will collect and use PII and receive a description of the Smart

Columbus privacy controls.

Smart Columbus demonstrations will provide notice and informed consent pursuant to IRB- and/or

USDOT-approved processes before collecting or using PII. Smart Columbus should provide such notice

at the point of collection. For mobile applications such as the MMTPA, Smart Columbus will obtain notice

and informed consent through clear and concise opt-in privacy policies presented upon installation of the

application. Informed consent may not be applicable to several projects (e.g., SMH, EPM, CEAV). The

IRB will be informed of all expected participant uses and collected PII in the entire Smart Columbus

program, so it can determine need for its oversight in each project.

4.1.3. Data Minimization

A common best practice that reduces the negative consequences of a breach involving PII is for

organizations to limit their PII collection to the least amount needed to accomplish legitimate purposes.

Therefore, Smart Columbus will collect only the minimum amount of PII required to conduct USDOT

approved Smart Columbus Demonstration services. Smart Columbus project managers will identify the

minimum PII elements that are relevant and necessary to accomplish the legally authorized purpose of

the project requirements.

4.1.4. Use and Sharing of Personally Identifiable Information

Smart Columbus will use and share PII only as needed for the purpose it provides via notice to the data

subject, and to which the data subject consented, or for compatible purposes. In addition, Smart

Columbus will seek to ensure that its use and sharing of PII is consistent with data subjects’ reasonable

expectations. Each demonstration project manager will ensure that project PII is used only for specific

purposes that are explicitly described in its privacy notices or are compatible with the described purposes,

and that are within the reasonable expectations of data subjects.

Demonstration data will be shared only with authorized entities in service of legitimate demonstration

purposes and subject to limitations on use and assurances that the privacy and security of the information

will be protected in accordance with this DPP. Based on approval of the IRB and upon signing applicable

data-sharing and use policies, Smart Columbus will provide certain demonstration data to USDOT IEs,

subject to appropriate privacy and security safeguards, to ensure demonstration success.

Before Smart Columbus can use PII for purposes incompatible with those initially disclosed to individuals

in privacy notices, it will need approval from the IRB and must provide the relevant data subjects with

additional privacy notices and receive their informed consent to the use of their data for the new purpose.

Smart Columbus will not use, sell or distribute PII or SPII collected through the USDOT Smart Columbus

program for any commercial marketing or advertising purposes. Smart Columbus will use PII only for

Smart Columbus-authorized purposes.



In addition to the above-described purposes, Smart Columbus may use PII to the extent strictly required:

To comply with applicable law or respond to valid legal process, including law enforcement or

other government requests, but only to the extent strictly required to comply with such requests or

processes;

To protect the rights or interests of Smart Columbus, its partners, customers, individuals or

others, to prevent the loss of life or serious injury;

To enforce Smart Columbus agreements, terms, or notices; or

As otherwise described in its privacy notices.

4.1.5. Data Quality

Smart Columbus will ensure that information originated from the demonstration environment that will be

used by demonstration projects is accurate, relevant and available for the purposes specified in its

privacy notices. For complete details about how Smart Columbus will ensure accurate and complete

information, see the Smart Columbus Data Management Plan.

4.1.6. Data Retention

Smart Columbus will retain information only for so long as it needs to satisfy the purposes specified in its

privacy notices, or for other compatible purposes, and in accordance with the applicable State of Ohio

Public Records law, the National Archives and Records Administration (NARA) records schedule and

applicable contracts with third-party vendors. When PII is no longer necessary for the purposes specified

in its privacy notices or for other compatible purposes, or at the conclusion of the project for which Smart

Columbus collected the PII (whichever comes last), Smart Columbus will take reasonable steps to

destroy, securely erase or irreversibly de-identify all PII records in accordance with the NARA-approved

record retention schedule to prevent loss, theft, misuse, unauthorized access or re-identification.

Among other reasons, Smart Columbus may also retain information to the extent strictly required:

To comply with applicable law or respond to valid legal process, including law enforcement or

other government requests;

To protect the rights or interests of Smart Columbus, its partners, customers, individuals or

others, to prevent the loss of life or serious injury;

To enforce Smart Columbus agreements, terms, or notices; or

As otherwise described in its privacy notices.

Smart Columbus might need to retain some categories of PII, such as registration and account

information for continued routine operations and post-project administration; however, it will only retain

such PII in accordance with the NARA records schedule and will specify in privacy notices the information

categories that might be retained beyond the Smart Columbus demonstration lifetime.

As the volume of the data that the Operating System platform houses increases over time, data

administrators will evaluate applying expiration policies to datasets or data within a dataset. This may

include the moving of infrequently accessed data to other, less expensive storage or to make a

recommendation to purge it in accordance to Ohio Public Records law requirements.



4.1.7. Access and Correction

Where feasible, Smart Columbus will provide data subjects with a means to access and correct their PII

that demonstration projects collect and use. Smart Columbus privacy notices and consent forms will

inform data subjects of these access and correction opportunities, and of all other applicable rights under

Ohio or federal law. Smart Columbus will establish a process for receiving and responding to questions,

concerns and complaints from participants in Smart Columbus projects and data subjects in a

reasonable, timely manner. The process will allow demonstration participants to:

Request clarification on their data rights and Smart Columbus data uses and protections.

Access and inspect their PII maintained in Smart Columbus information systems.

Correct, update and seek review of inaccurate or outdated PII that they have provided.

Request information about any logged disclosure of their personal information held under Smart

Columbus systems as well as the date, and recipient of that disclosure.

Request to opt out or leave a demonstration project for which they have registered. Where

reasonable, Smart Columbus may delete existing PII and cease to collect new PII if a participant

leaves a demonstration project. PII may have to be retained for project administrative procedures

to follow up with participants for verification purposes related to legal and other matters after their

participation.

4.1.8. Transparency

Smart Columbus will be open about its information collection and use practices. It will make information

available about its data collection and use practices to demonstration participants, residents and

interested parties through easily accessible mechanisms such as a public-facing website or information

phone line staffed during normal business hours. In addition, as specified in Section 4.1.2, Smart

Columbus is committed to providing individuals with timely, clear and specific privacy notices.

4.1.9. Accountability

Smart Columbus will institute the processes necessary to hold itself accountable for compliance with its

data privacy principles and with the Data Privacy and Data Management controls that implement them.

Smart Columbus will appoint resources to implement and monitor information security, and information

privacy protection in compliance with this DPP. These resources will document compliance with the

provisions of this DPP as well as the Data Privacy and System Security provisions in the Grant

Agreement. Upon request, Smart Columbus will provide to the USDOT Contract Officer sufficient

documentation to demonstrate compliance with this DPP and the Data Privacy and System Security

provisions in the Grant Agreement.

Smart Columbus will develop a process and systems for monitoring privacy controls to ensure they are

protecting PII as designed, including regularly scheduled audits. Smart Columbus will also arrange to

engage an independent, third-party auditor to confirm that the DPP is effectively implemented and that

Smart Columbus is protecting PII as intended. All audits will produce a report of findings to be shared with

the IRB, the Smart Columbus Privacy and Security Board, and USDOT.

Smart Columbus will maintain a log of all disclosures to third-parties of PII in its system. Smart Columbus

will maintain this record for the lifetime of the demonstration, and it will include:



The data, nature, purpose and authority for each disclosure of records.

The name and address of the person or agency to which the disclosure was made.

Smart Columbus will, upon request, make available to data subjects the accounting of disclosures to third

parties.

4.1.10. Control Boards

Smart Columbus projects will empanel IRB professionals from Advarra IRB and/or The Ohio State

University to be the IRB of Record. The IRB(s) will fulfill the requirements of an IRB under the Federal

Policy for the Protection of Human Subjects (“Common Rule”), U.S. Department of Health and Human

Services’ Title 45, CFR, Part 46, and the USDOT’s Guidance Summary for Connected Vehicle

Deployments, Human Use Approval (FHWA-JPO-16-346). The Human Use Approval Summary (HUAS)

guidance form USDOT (FHWA-JPO-16-346) is available on the USDOT CV Pilots’ website.1

The role of the IRB is to administer the approval of all informed consent forms and privacy agreements

(e.g., website privacy notice, application, kiosk click-through terms of service or posting in an autonomous

vehicle) relating to participation in specific projects and collection and use of personal data through the

Smart Columbus demonstration. Further, the IRB will:

Review and approve privacy notices and data uses for demonstration projects involving projects

that use data subjects.

Receive notice of security or privacy incidents as well as resolution and status.

Authorize any disclosures of Smart Columbus data to third parties.

By July 2019, Smart Columbus will empanel a five-member Privacy and Security Board, made up of three

privacy professionals and two security professionals in central Ohio. This Board will advise Smart

Columbus on privacy and security issues. The City will appoint volunteer board members for staggered,

two-year terms. The Privacy and Security Board will:

Advise Smart Columbus on new developments and emerging best practices in information

privacy and security.

Recommend, where relevant, and advise upon any modifications to the DPP.

Receive notice of security or privacy incidents as well as resolution and status.

Annually review any audits conducted through the year.

1 NIST 800-53(J) (AR-3) “Privacy Requirements for Contractors and Service Providers”



4.1.11. Contractors and Other Third Parties

Smart Columbus will establish privacy roles, responsibilities and access requirements for any sub-

recipients, contractors and service providers that may interact with demonstration PII. Smart Columbus

will also develop standard contract language to ensure that any sub-recipients, contractors or service

providers that collect, maintain, possess, access, use, store or destroy personal information collected

through the demonstration will comply in all material respects with the security and privacy requirements

of this DPP and the USDOT Cooperative Agreement. Such contracts will include, at minimum:

Limitations on use, access and disclosure of PII to the purposes specified in the City’s privacy

notices as determined and directed by Smart Columbus in accordance with this DPP.

Incident-reporting procedures and timeframes.

The process by which the third-party will respond to an individual’s request to access or correct

PII.

Duty to return or securely destroy all PII when no longer needed to retain for contract or upon

termination, whichever comes first.

Consequences of failure to comply with privacy contractual terms – breach of contract resulting in

possible termination and damages.

4.1.12. Privacy Impact Assessments

Privacy Impact Assessments (PIAs) are structured processes for identifying and mitigating privacy risks,

including risks to confidentiality, within an information system. The Smart Columbus team will conduct a

project-appropriate PIA for each Smart Columbus demonstration project and before using personal

information for new or unique purposes. Smart Columbus will complete the PIA before implementation of

any Smart Columbus project, and it will address confidentiality risks at every stage of the life cycle for

every demonstration project. Appendix B. Privacy Impact Assessment includes a PIA example.


Chapter 5. Personally Identifiable Information Security Controls

Data security is fundamental to public confidence in Smart Columbus project demonstrations and the

overall success of the program’s objectives. While no information system can guarantee that a breach will

never happen, the Smart Columbus team views data security as a foundational principle. It is dedicated to

ensuring that all Smart Columbus data including PII and SPII will be stored only on IT infrastructure that

employs security controls commensurate with the risk to the individual that would result from unauthorized

access, disclosure, or use of the information.

Information Security is based on maintaining the “CIA Triad”: confidentiality, integrity and availability of

information. The Smart Columbus approach to system threat assessment, analysis of application flows

and device classifications is based on the process defined by the Federal Information Processing

Standards (FIPS) Publications 199 and 200.

5.1. TYPES OF CONTROLS

Three types and three means comprise security controls. The three types of controls are:

Preventive: Put in place to inhibit harmful events.

Detective: Put in place to discover harmful events.

Corrective: Put in place to restore systems after harmful events.

These security controls follow a progression from blind optimism (believing that prevention will eliminate

all negative events) to the sky is falling (we cannot stop them, better prepare to pick up the pieces). The

best security plans utilize a balance of the available controls to accomplish the best solution based on

multiple factors including:

Risk tolerance of data owner.

Value of data at risk.

Damage expected from loss or exposure.

Likelihood of loss or exposure.

Cost of various safeguard options compared to the level of assurance they bring and the above

factors.

Smart Columbus will identify and manage Security Controls following the steps recommended by NIST in

its FIPS SP 800-53 Document, and the Smart Columbus systems requirements will be constructed

around these steps:

Categorize the demonstration information systems as low-impact, moderate-impact, or high-

impact for the security objectives of confidentiality, integrity, and availability based on FIPS

Publication 199 impact assessment (partially completed by USDOT – pre-award, preliminary

reassessment based on current state of design at point of DPP creation, and another

reassessment to follow final design).



Select the applicable security control baseline based on the results of the security categorization

and apply tailoring guidance (including the potential use of overlays).

Implement the security controls and document the design, development, and implementation

details for the controls.

o Assess the security controls to determine the extent to which the controls are implemented

correctly, operating as intended, and producing the desired outcome with respect to meeting

the security requirements for the system and examining all hardware elements within the

network that serve as potential points of entry or vulnerable to entry.

Authorize information system operation based on a determination of risk to organizational

operations and assets, individuals, other organizations resulting from the operation and use of the

information system and the decision that this risk is acceptable.

Monitor the security controls in the information system and environment of operation on an

ongoing basis to determine control effectiveness, changes to the system/environment, and

compliance to legislation, policies, regulations and standards.

5.2. MEANS OF CONTROL

The means for implementing controls are:

Administrative: Includes policies and procedures; security awareness training; background

checks, and levels of supervision.

Logical or Technical: Targets the restriction of access and includes encryption, smart cards,

access control lists, and biometrics, etc.

Physical: Incorporates security guards, alarm systems, locks, etc.

5.3. CONTROL IMPLEMENTATION DETAILS

5.3.1. Security Control Catalogue

The development and application of security controls and standards for Smart Columbus demonstration

data are based on the recommendations of NIST 800-122 “Guide to Protecting the Confidentiality of PII”

and NIST 800-53 “Security and Privacy Controls for Federal Information Systems and Organizations” (see

Appendix D. National Institute of Standards and Technology Special Publication 800-122 Checklist

Summary).

Consistent with the Cooperative Agreement to meet the minimum-security baselines for demonstration PII

as required by USDOT, Smart Columbus will:

Protect all PII, electronic and hardcopy, in its custody from unauthorized disclosure, modification,

or destruction so that the confidentiality, integrity, and availability of the information are

preserved.

Store PII only on IT infrastructure employing security controls commensurate with the risk to the

individual that would result from unauthorized access, disclosure, or use of the information.

Encrypt all PII in transit or at rest.

Encrypt all PII transmitted or downloaded to mobile computers/devices.



Ensure that all individuals having access to PII have received training in the policies and

procedures that protect PII.

5.3.1.1. ANONYMITY

According to NIST SP 800-122 (see Appendix D. National Institute of Standards and Technology

Special Publication 800-122 Checklist Summary), generalizing, suppressing, introducing noise into,

swapping, or replacing the data with the average value can introduce anonymity.

This will be applied to Smart Columbus data by anonymizing identifying/potentially identifying data with an

appropriate technique relevant to the type of dataset. There will be a link between the anonymized data

and the original identifying data for the purposes of audits, controls and administrative purposes. This link

information will only be available to specific staff specially trained in the protection of human research

subjects.

Datasets that are anonymized will contain metadata indicating that they have been anonymized.

5.3.1.2. ENCRYPTION

All data collected through Smart Columbus projects that contain PII will be encrypted while in transit and

at rest. Because reasonably de-identified data has already had all PII/SPII removed by the application of

a technical filter, it is the only form of data permitted to be stored or transmitted in clear text or as

appropriate. 256-bit Advanced Encryption Standard (AES) encryption will be used for all other data types.

All personnel/staff access to cryptographic key material and will be kept and internally audited bi-annually.

A cryptographic material custodian will be designated for control, inventory, storage and distribution of

cryptographic key as needed.

5.3.1.3. ACCESS TO LIVE DATA

Project managers on the Smart Columbus team may need to periodically view real-time live data for the

purpose of calibration, diagnosis, validation or other reasonable purposes. Because live data has not

been reasonably de-identified for release, this access will be limited to designated Smart Columbus staff

with explicit clearance, adequate training experience to ensure safe handling within this plan. Safeguards

to avoid abuse include least privilege access, training and awareness programs to ensure they

understand the risk, and so on. Any capture of “live” data will be considered to reasonably contain PII and

will be classified and safeguarded as PII, including the use of approved, encrypted storage devices for the

capture, storage and transfer of the data. Access will typically be required for system testing or

troubleshooting issues, and an audit log will be maintained to track name, date and location of live data

access. Live data may be broadcast over Dedicated Short-Range Communications (DSRC) in an

unencrypted state or encrypted state, as needed, but access to the data requires multiple layers of

requirements including a device to capture the communication, software to interpret the data and SCMS

bootstrapping and valid certificates.

5.3.1.4. INDEPENDENT EVALUATOR’S ACCESS TO STORED DATA

In accordance with the USDOT-City of Columbus Cooperative Agreement, Independent Evaluator (IE)

appropriate data will be sent to the USDOT’s ITS Public Data Hub (Secure Data Commons), which the IE

can access. The IEs will only receive “reasonably de-identified data” per PII/SPII Requirements. IEs will

not access data directly from the Operating System.

Reasonably de-identified data will be made available to the Secure Data Commons from the Operating

System. For this reason, data in the Operating System will exist in two states: original data and

reasonably de-identified data. Original data will be presumed to contain PII and/or SPII and will be



protected as such. Once the original data has been analyzed for relevance, validity and has had any PII

removed, it will exist as “reasonably de-identified.” This reasonably de-identified data will be released to

the IE. An audit trail will be created to track who accessed the data, when it was accessed, and where the

data was stored. The process implemented to creating reasonably de-identified data is referred to as

“filtering” and is described below.

5.3.1.5. PHYSICAL CONTROL

The technical means of data and privacy protection are only as secure as the physical means preventing

access to stored or live data. For example, requiring an extremely sophisticated password schema is of

insignificant effect if user passwords are widely known to be written and stored in an unlocked desk

drawer. The Smart Columbus security officer will ensure that physical protection devices are fully and

correctly utilized to protect against physical exposure to original project data of any type and that Smart

Columbus staff are professionally trained in their use. Example of physical devices and data include

computer storage devices and hard-copy paper records. Further physical controls will include alarm

systems, cabinet locks, and security background checks.

5.3.1.6. ACCESS CONTROL – REMOTE ELECTRONIC ACCESS TO DEVICES AND SYSTEMS

All access to project data via electronic means will be protected by an access control system including:

Identification, Authentication, Role-Based Authorization, Access and Event Logs and Internal Audits.

5.3.1.7. AUTHORIZATION – ID-BASED

Authorization occurs after authentication. Whereas the authentication establishes the identity of person

requesting access, authorization based on ID determines the level of access to be granted. All access to

any level of project data will begin at this ID-based authorization. A Privileged ID Management (PIDM)

system may be implemented in the later phases of the Operating System development.

Authorization details will be developed as the project progresses and should include:

Multifactor authentication should be required to access PII. This protects the data from phishing

attacks, which is a prominent method for gaining unauthorized access to sensitive data. This is

the kind of protection used to access personal bank accounts and electronic medical records, and

it is appropriate for use to access sensitive data stored in the Operating System.

The creation, storage and protection of keys is a vital component in keeping data safe. There

should be no confusion surrounding algorithms, key length, key exchange, or other areas that

could lead to the defeat of Operating System encryption systems.

Managers will periodically review the access privileges of each of their associates to ensure they

have not changed.

A process/technology should be in place to ensure access is removed quickly if someone is

terminated and altered if someone takes a new role.

Password management should include the following processes, at a minimum:

o Periodic change.

o A set number of failed login attempts results in account being locked.

o Set time period for login attempts to include minimum and maximum time intervals.

o Enforced password complexity.



5.3.1.8. AUTHORIZATION – ROLE-BASED

In addition to the ID-based authorization above, personnel access will be further restricted based on

specific job roles within the project. For example, the staff involved in the registration of participant data

will not be involved in the collection or analysis of CVE and other project data and the staff involved in

analyzing project data will not have access to participant data. This precludes staff with project data

access from being able to extrapolate PII from project data via comparison with the registrant data.

Throughout the project there may be situations where an examination of both project data and registrant

data is required. Designated project staff with adequate training, as approved by the IRB, will be

responsible for the protection of human subjects throughout the project. These staff comprise a limited

number of individuals that includes the project manager and minimal and identified staff for each Smart

Columbus project.

5.3.1.9. ACCESS TO PERSONALLY IDENTIFIABLE INFORMATION AND SENSITIVE PERSONALLY IDENTIFIABLE INFORMATION

PII data is easily commingled with SPII in the context of the rapidly moving exchanges taking place in the

movement of data. Because of this, the Smart Columbus team will treat all PII as SPII for the purpose of

operational security controls and with an abundance of caution. For access to data for use, PII and SPII

will be treated separately wherein role-based access controls will be administered to provide appropriate

differentiation.

Only Smart Columbus staff with data security clearance for SPII (Section 4.1.9) and those who use SPII

in their work with participants whose identities are protected as SPII data (e.g., MAPCD, PTA) will have

access to SPII. They will avoid discussing SPII in person or over the telephone when they are within

earshot of anyone who does not need to know the information.

In the Smart Columbus workplace, hardcopy of SPII should never be unattended and unsecured. SPII

documents should be physically secured (e.g., in a locked drawer, cabinet, desk, or safe) when not in use

or not otherwise under the control of a person with a need to know. SPII may be stored in a space where

access control measures are employed to prevent unauthorized access by persons without a need to

know (e.g., a locked room or floor, or other space where access is controlled by a guard, cipher lock, or

card reader). This is not a substitute for physically securing SPII in a locked container when not in use.

SPII should not be sent using a fax machine. If possible, hardcopy SPII should be scanned and then the

document(s) encrypted prior to emailing.

Access to computer hard drives containing PII/SPII by computer or telecommunications third parties (e.g.,

for repair) should be supervised and adequate precautions taken to disallow copying of files. Computers

or hard drives with SPII will not be sent out for repairs until the data is removed and secured.

5.3.1.10. PENETRATION TESTING

Ethical hackers under the authority of project management will conduct penetration testing on the

Operating System. These ethical hackers operate outside of the sphere and influence of the system

architecture design and implementation for the sole purpose of identifying vulnerabilities and exploits

within the system. During and after system design and deployment, the penetration-testers will attempt to

break down any of the three tenets of the CIA Triad. By providing this type of targeted attack by safe

sources, the team can better prevent or mitigate malicious or inadvertent outside attacks. Smart

Columbus will make reasonable efforts to promptly rectify any vulnerabilities and exploitations discovered

through penetration testing.



5.3.2. System Monitoring

Both passive and active system monitoring controls will be implemented for the system architecture.

These monitoring applications will examine system activity for anomalies and other signs of improper

operation or possible system exploits. These systems may have a corrective component that

automatically implements safeguards to inhibit further exploit or may simply alert project staff of the event

so that manual action can be affected. These systems may include network monitoring, data-sniffers, key

loggers, Simple Network Management Protocol traps (send alerts to management system regarding

suspicious traffic), Access Control Lists (hardware monitoring rule configuration) and others. A 24/7

operations center to address alerts would be most effective.

5.3.3. Data Loss Prevention

There are many controls to implement to reduce the loss of PII data within this category of controls:

Restrict internal resources from emailing a file with more than “X” PII records embedded. “X”

should represent an exceedingly small number of records that could be downloaded

Restrict internal resources from copying a file with “X” PII records to a USB drive or send out via

email.

If associates are permitted to copy files to a USB drive, allow use of only a specific encrypted

USB drive.

Lock down any computers provided for PII to only allow work-related access. If possible,

shutdown the USB ports, eliminate the ability to copy files to the local drive, do not allow web-

based email, etc.

5.3.4. Antivirus and Malware Checking

Antivirus and malware-checking software will be utilized for each system component as appropriate.

Antivirus and malware-checking applications are primarily detective in that they recognize, and report

code patterns associated with potential exploits. These are most effective for open networks in which

access control is weak. While the Smart Columbus communication system and network will be actively

secured, antivirus and malware checking software will still be deployed on workstations, servers and

other items where inadvertent introduction of hostile code could occur. Demonstration personnel will apply

patches to servers and desktop computers in alignment with vendor updates. Further privacy protection

will be provided by information and network security systems, such as firewalls, web application firewalls,

intrusion detection and prevention systems.

5.3.5. De-Identification

During data curation of datasets, the data will be evaluated to see whether it contains SPII/PII

information. If found to contain SPII/PII information, the confidential information will be evaluated for

complete removal before being sent to the Operating System. If it cannot be removed, it will be masked or

redacted during the data ingestion design process based on the technical controls defined herein.

The actual de-identification technologies/processes that Smart Columbus will use are part of ongoing final

design, and they will be documented upon completion.



5.3.6. Need-to-Know

A “need-to-know,” Least Privileged Access further restricts access to data based on having a legitimate

need to access the data for completing a requirement of one’s job. As an illustration, the U.S. Department

of Defense classifies information into Confidential, Secret and Top-Secret categories; however, even

having Top-Secret clearance, one cannot access even Secret data for which they have no “need to know.”

For access to be authorized, a need to know the information must accompany the appropriate clearance.

Smart Columbus will apply a need-to-know policy when granting access to collected data. The need know

will be based upon an assessment of each data type and the authorized staff role.

5.3.7. Compartmentalization

Compartmentalization is the partner to role-based access discussed earlier. Information is divided into

compartments to keep any one entity from having the entire picture. In the case of Smart Columbus CVE,

for example, this will be applied to participant registration data and vehicle identification information. The

staff maintaining registrant data and those analyzing the project are not granted access to the data of the

other team. This keeps the data compartmentalized such that only the role with access to both project

data and PII can make the correlation.

5.3.8. Training

Any Smart Columbus personnel or individuals who have access to PII such as software developers,

system testers and project managers will be required to complete training covering the security policies,

procedures and requirements of this DPP. The Chief Security Officer of the Operating System will

manage this. The Chief Privacy Officer will require separate training specific to data privacy policies and

procedures. The training will communicate the importance of protecting PII and build knowledge and skills

that will enable Smart Columbus personnel to protect the security and confidentiality of PII in accordance

with the DPP. Training should target the employees’ level without unnecessarily complicating the tasks to

recall or exposing privileged knowledge of the system.

The training will include:

Instruction in specific privacy and security control mechanisms.

Role-based privacy and security training.

Individual certification of acceptance of privacy responsibilities.

Periodic refresher courses and re-certification.

Any Smart Columbus personnel that interacts with demonstration data involving human subjects will be

required to take an additional training course that covers the following: review of Belmont Report,

Common Rule Regulations, relevant IRB policies and procedures for the protection of human subjects,

Smart Columbus privacy and security controls, as determined by the IRB. The Security and Privacy

officers of the Operating System will manage this.

5.3.9. Audits

5.3.9.1. INDEPENDENT AUDITS

Independent Audits are the hallmark of prevention when it comes to staff misbehavior. Knowing that an

independent entity will be reviewing your work and actions is a strong deterrent to cutting corners or

malicious activities. In the case of Smart Columbus, the likelihood of such activities is already minimal.



But due to the sheer volume of data that will be amassed and the potential for human error, independent

audits will be applied to reviews of both policy/procedure adherences and data integrity.

Documents reviewed by auditors will include the IRB’s required research protocol documents, informed

consent documents, security policies, access logs and recruiting/media materials. Chapter 6. Institutional

Review Board Oversight of Personally Identifiable Information discusses the role of the IRB.

5.3.9.2. INTERNAL AUDITS (SMART COLUMBUS TEAM)

System elements will generate system event logs and administrative logs for staff access and PII use.

Internal audits will review the logs to ensure security controls are effectively protecting PII as designed.

The Smart Columbus team will regularly review and analyze information system audit records for

indications of inappropriate or unusual activity affecting PII and take any necessary restorative and

preventative actions.

5.3.9.3. BREACH DETECTION AND REMEDIATION

Smart Columbus will implement appropriate measures to detect, investigate, remediate, and notify

reasonably suspected data privacy or security breaches in accordance with its policies and procedures

and applicable laws.

Smart Columbus will develop a Privacy Incident Response Plan that includes training for all staff in the

proper procedures for reporting a breach or suspected breach of PII data. The Privacy Incident Response

Plan will provide for:

Promptly reporting to the USDOT Agreement Officer any suspected loss of control or any

unauthorized disclosure of PII by the Recipient, its sub-grantees or contractors.

Promptly reporting to the USDOT Agreement Officer all suspected or actual unauthorized

collection, use, maintenance, dissemination or deletion of PII by the Recipient, its sub-grantees or

contractors.

A breach response team that will investigate the incident, preserve evidence, eliminate any

ongoing risks, and determine what, if any, violations have occurred.

Disclosing the breach or suspected breach to the appropriate law enforcement agency.

Disclosing a breach of security of the system to any data subject whose personal information was

or is reasonably believed to have been accessed or acquired without authorization and what is

being done about it.

Promptly reporting to the IRB data privacy breaches as laid out in the project Research Protocol.

The report to the IRB will include any resolutions.

Reporting, within one month, to Health and Human Services (HHS) Office of Human Research

Protections (OHRP) Adverse Events that are Unanticipated Problems (UP), such as data breaches. The

IRB may undertake this. Breach detection may require outsourced forensics. Security Information and

Event Management (SIEM) software products, appliances and managed services may be considered.


Chapter 6. Institutional Review Board Oversight of Personally Identifiable Information

Title 49, CFR, Part 11 codifies the USDOT-adopted Common Rule, which provides guidance on defining

when a project falls under the rule, and associated requirements, for approvals, oversight, and IRB

involvement. Because Smart Columbus is federally funded and involves the use of participants, approval

of human use by an IRB is required.

Smart Columbus data security and participant PII are under the oversight of the IRB. IRB approval will be

determined within each of the constituent projects of the Smart Columbus demonstration. Documents for

submission to the IRB will be developed for each project, with oversight by an IRB compliance consultant,

and will include the research protocol documents, participant recruitment plans, informed consent

documents, training plans and materials and ongoing amendments as needed. A Human Use Approval

Summary report will be delivered to USDOT covering the entirety of the ongoing IRB process.

IRB approval is subject to ongoing and periodic review as progress advances past concept development

and into the details of recruitment, screening, registration, PII and SPII data storage, training and

message sharing with participants. Treatment of Smart Columbus participant data, especially of

vulnerable populations, will depend on project provisions, made through the project-specific, IRB-

approved informed consent and research protocol documents.

Smart Columbus will submit periodic updates to the IRB to revise the project-specific research protocol

documents and informed consent documents as the Smart Columbus demonstration progresses. In the

context of this DPP, participant PII and SPII data integrity and storage are of interest.

6.1. PARTICIPANT PERSONALLY IDENTIFIABLE INFORMATION DATA INTEGRITY AND STORAGE

While details of participant and IRB involvement in the demonstration remain under development, enough

information is available at this stage to establish the basics of the participant privacy plan and to

anticipate what the IRB will require.

Each Smart Columbus project will require its own IRB oversight. Following is an example of how the

process is managed within a specific project. Participants in the Smart Columbus CVE study are to

include drivers from COTA transit agency, which manages a fleet of buses and other City-owned vehicles.

The anticipated and planned potential sample size of participants is subject to the actual recruitment

response of drivers as well as budgetary constraints.

Recruitment of auto drivers will require collection of the following PII to administer training, education and

any notifications leading up to and continuing throughout the Smart Columbus demonstration (see

Appendix A. Data Inventory).

Name

Contact Information (one of these)

o Home and work mailing addresses

o Email

o Phone number



Vehicle information

o Driver license identification number

o Insurance card (only for auto drivers)

o Vehicle type data (only for auto drivers)

o Sociodemographic data (as needed for analysis)

o Recruitment method

Sociodemographic data requested by the IE may be added to the study as needed with IRB approval.

Sociodemographic data may be released to the IE if PII and SPII are withheld or de-identified.

Sociodemographic data may be of interest to the IRB to evaluate the protection or treatment of vulnerable

populations.

Sociodemographic data are not an in-scope, per se, requirement. However, some sociodemographic

information is inherent in participant registration. While the team is not focused on performance

measurement in this area, sociodemographic data, which is collected out of necessity, will be stored for

the potential use by the Smart Columbus project team or IE. In the case of IE use, sociodemographic

data will be de-identified for release in a similar manner as other potential PII and SPII. For example, data

regarding year, model and class of vehicles may be summarized for sociodemographic study, but they

would not be specific to any individual.

As done in the Ann Arbor Safety Pilot Model Deployment and in the Tampa Connected Vehicle Pilot, no

PII will be collected by Smart Columbus on COTA transit drivers. Transit drivers will be treated as

employees of the agency (i.e., the owner of the vehicles). This treatment corresponds to the approach

taken with auto drivers in that only the owner of the vehicle will register and supply PII, while users of their

vehicles are not required to do so. The transit agency, thus, is the informed consent document signatory

and use of its vehicles and employees is expected to be according to the drivers’ union contract. COTA

will operate according to its standard operating procedures and will know which drivers have CVE

equipped vehicles. The Smart Columbus equipment will not add new capabilities to COTA’s current ability

to monitor drivers’ behavior.

The arrangements with COTA and its drivers may or may not apply for freight and autonomous vehicle

projects. Similar arrangements may be applied depending upon project details to be developed.

The Smart Columbus team is preparing for participant recruitment to include, as needed, from among the

following methods and avenues of communication:

Public-facing website

Secure participant portal on the website for communications with participants.

Email and/or Short Message Service (SMS) alert system for critical communication with

participants, such as for a recall or application update.

User survey(s) at the start, during and at the end of the study by Smart Columbus and the IE,

which will have “blind” access to participants through Smart Columbus.

These communication methods will require collection of information on participant contact information

such as email address and phone number to send newsletters, emails, and/or SMS alerts. Participants

may sign up for a registration appointment over the secure participant portal on the website with a

username and password. The informed consent documents, to be signed by participants, will state that, if

there is a security breach related to personal information of participants, the Smart Columbus team will

notify the participants of the breach, the nature of the breach, and what the team is doing to resolve it.



To secure participant confidentiality, Smart Columbus will facilitate IE access to Smart Columbus staff and

stakeholders to support IE surveys and interviews, but this will exclude the sharing of participant PII. The

IE will submit questions to Smart Columbus that it wishes to ask participants in surveys and Smart

Columbus will include them in periodic participant surveys. In this way, no PII will be given to the IE and

PII will be secured by the limited Smart Columbus staff that will have access to participant PII for

administration of the project.

Three categories comprise stakeholders:

General stakeholders: Any stakeholder that has an interest in or is impacted by the project

Partner stakeholders: Any stakeholder who is also an active partner in the project (active

participation or contribution)

Participant stakeholders: Registered users of the system (NO ACCESS to this class of

stakeholder by IE or any other third party)

The project involves people from various stakeholder or “participant” groups that are categorized in Table

2: “Participant” Groups. These distinctions are made to remove any ambiguity in use of the word

“participant” when discussing the project and to reserve the word “participant” for those who sign informed

consent documents.

Table 2: ‘Participant’ Groups

“Participant” Group Membership

Sponsor USDOT FHWA

Independent Evaluator Texas Transportation Institute, Volpe (CV)

SC Project Performance Evaluators

Evaluators will be identified for performance monitoring of each of the Smart Columbus projects.

Stakeholder Agency COTA, OSU, City of Columbus, The Columbus Partnership, ODOT

Administrator Stakeholder staff, trainer, Help Desk responder, TMC Operator, installer

Public A person for whom an outreach message is intended

Prospective Participant A person in recruitment, for whom a recruitment message is intended

Participant System User A person who has signed an informed consent document and COTA, as owner of the transit agency

Non-Registered System User A user of public systems that does not require registration or informed consent

Guest Driver A driver of a participant’s vehicle (e.g., family members) who does not sign an informed consent document and receives informal training by the participant

Staff Driver A driver of a transit vehicle who does not sign an informed consent document and receives formal training by Protecting Human Research Participants (PHRP)-certified Smart Columbus staff

Follower/Fan Someone who signs up for project updates but is ineligible or chooses not to participate




The participant data collected for participant management must be in an encrypted, standalone,

password-protected database that is separate from all other project data that is to be used by the Traffic

Management Center staff, the performance measurement team, IE or any other agency accessing project

data, now and in the future. The Smart Columbus team will establish a detailed IRB-approved process for

handling participant data and provide a list of team personnel that have access to the participant data.

The Smart Columbus team will limit access to those personnel who require access to the data to perform

their administrative duties within the demonstration, such as contacting drivers who appear to be no

longer driving in the study area and so forth. The informed consent documents which participants sign

before undergoing training and application or equipment installation will define these activities. Smart

Columbus personnel who induct participants and enter participant data or use original participant data in

any way will have training in protecting human research participants.

While individual projects within Smart Columbus will vary, a standard procedure for drivers is described as

follows:

At the registration location, the potential participant will watch a brief video explaining the informed

consent process. A staff person will present the person with an electronic informed consent document

(on a tablet or PC) and ask him/her to read it. For the length of the study and to avoid additional

costs, the project will initially be tendered in English only. The staff person will be available to answer

questions in person or by the Help Desk phone. The participant will then sign or not sign the informed

consent document. If the participant signs, he or she goes on to the training and his or her vehicle is

taken for installation of the device. The participant will receive an electronic or paper copy of their

signed informed consent document, as preferred. The participant may then also receive a Tip Card

and/or User Manual as a reference to using the equipment installed in his or her vehicle.

While individual projects within Smart Columbus will vary, a standard procedure for smartphone users is

described as follows:

The registration, informed consent document and training process will be done online followed by

downloading the application to be used on their smartphone. The application will initially not be a

bilingual offering, as to be agreed upon with the IRB, due to the expense of creating the online

process and application in multiple languages. A facility with English may be needed to download and

use the application. The participant will receive an electronic informed consent document and Tip

Card along with the app as part of the download.

While individual projects within Smart Columbus will vary, a standard procedure for transit is described as

follows:

Transit drivers will be treated as employees of the agency (i.e., the owners of the vehicles). Only

the transit agency COTA will register and supply PII; drivers of the vehicles are not required to do

so.

Transit-users who use a smartphone app and are recruited online will sign an informed consent

document, register their PII, receive training and download an app, as needed.

City fleets, CEAV and freight projects will develop a standard procedure similar to those listed

above as project details emerge during development.

Demonstration projects not treated above (e.g., MMTPA/CPS, PTA, MAPCD) and using online

registration will make available the means for informed consent, registration (including PII and

SPII), training, and downloading of any apps as appropriate to the project design and application

use. Note that registration, including PII, will need to be performed after the informed consent

document is signed so that PII is not collected from people who fail to complete the registration

and do not become participants. The project managers whose participants have greater need for



SPII protections will determine specific protocol and informed consent procedure as the projects

become more defined.

Smart Columbus will provide a secure interface for capturing PII data during the registration process.

Smart Columbus will supply software for capturing the data by the registrar(s), which the participant will

verify with ID – driver’s license, vehicle registration and proof of insurance for drivers. The data will be

uploaded to a secure database. With respect to the informed consent document signature, there are two

possibilities:

Store paper copies of the signed informed consent document in a secure, locked file cabinet at

the project registration facility.

Store digital copies of the electronically signed informed consent document in the secure facility

with the other registration information.

Participants will be given a paper copy or emailed a copy of their signed informed consent document,

which will also act as a registration certificate with instructions for contacting the Smart Columbus

administrators if the participants have questions, relocate, wish to quit the study, and so forth. To ensure

data quality and integrity for participant contact information, participants will have the ability to update

their personal information via a Smart Columbus online portal, as well as have access to a staffed Help

Desk Center to resolve questions and complaints. Help Desk logged calls, which can be PII or SPII, will

be kept secure and backed up to a secure facility for later administration that may be required (e.g.,

possible legal actions, quality control) after the Smart Columbus project is completed.

6.2. OTHER INSTITUTIONAL REVIEW BOARD ISSUES

The DPP is focused on data privacy and confidentiality. In addition to participant PII, data integrity and

storage, the IRB has general oversight of treatment of participants with respect to equity, safety,

beneficence and informed consent. Participants must be treated fairly and equitably, fully informed of the

study goals, aware of what their participation involves, the study risks, their legal rights, who to contact

with questions, and their ability to withdraw and the procedure to withdraw from the demonstration at any

time. Informed consent will include discussion of the uses of participant data and ensure that participant

data is understandable to project participants. Interpreters and/or translations will be provided as

determined by the IRB for fairness and vulnerable populations as well as providing reasonable means to

participate to the general population.



6.3. PRIVACY INCIDENT REPORTING

Smart Columbus shall report all events pertaining to unanticipated problems concerning privacy to the

IRB and others as described below:

Changes of substance to the DPP shall be reported to USDOT JPO during the grant period.

System breaches or failures that are discovered by Smart Columbus and are conclusively

determined to have not resulted in an unauthorized disclosure of PII will be reported to the project

manager, Smart Columbus Management, IRB and USDOT JPO along with a resolution plan and

status.

System breaches or failures that are conclusively determined to have resulted in an unauthorized

disclosure of PII will be reported to the project manager, Smart Columbus management, IRB and

USDOT JPO and along with a resolution plan and status. Any unauthorized disclosure of privacy

data will also require notification of participants and any State of Ohio authority as determined in

the legal compliance review by City of Columbus counsel. Serious system breaches will also be

reported to HHS OHRP within one month.

Annual or other regularly scheduled audits shall be documented in a report of findings.

Authorized disclosures of PII are only made to professionally trained (e.g., PHRP-certified) and

IRB-approved staff. Authorized disclosures will occur regularly throughout the process and shall

not require reporting. There will, however, be an accounting of such disclosures and the

accounting shall be made available during IRB audits or continuing review.

All reports in this section shall be retained in the project records according to the requirements of the

applicable NARA records schedule (available from the USDOT Agreement Officer).


Chapter 7. Public Availability of Datasets

The Operating System is a web-based, dynamic, governed data-delivery platform built on an

interoperable architecture that is at the heart of the Smart Columbus technology system. It accepts and

disseminates data from new transportation systems within the Smart Columbus portfolio, including

multimodal services and connected and autonomous vehicles. The Operating System plays a critical role

in helping Smart Columbus understand and analyze data and evaluate the success of Smart Columbus

projects to address the complex urban challenges facing the city.

The Operating System will allow Columbus residents, businesses, nonprofits and visitors to access,

share, integrate, and leverage previously unavailable or hard to find datasets to meet the challenges of

transportation, sustainability and quality of life. Making datasets such as demographic information, crime

statistics, energy consumption, air quality sensors and traffic sensors available on the Operating System

will allow for new and innovative integration and uses of data that will help serve the needs of public

agencies, researchers and entrepreneurs and assist health, human services organizations and other

agencies provide more effective services to their clients.

Over time, the Operating System will be used to host third-party applications that will integrate data from

multiple public and private sources. The City of Columbus seeks to encourage the local software

community to quickly develop software applications and tools through the Operating System that provide

value and collect, organize, and share data in new and innovative ways.

The City of Columbus has an obligation to ensure that only public datasets that meet privacy, quality, and

ethical standards will be added to the Operating System. This plan establishes a technical and

administrative control process that will be used to determine what datasets are added to the Operating

System.

7.1. COMMITMENTS

To serve as an ethical data steward and protect members of the public, Smart Columbus makes the

following commitments pertaining to data and Operating Systems:

Data created by the projects will be aggregated by the Operating System, anonymized, de-

identified and stored for historical analysis and visualization.

All datasets added to the Operating System, including information collected or generated through

Demonstration projects will undergo a benefit-risk analysis and meet privacy protective technical

and administrative protocols applied by a Smart Columbus data curator to ensure that it is in an

aggregated or de-identified format.

Smart Columbus will conduct an ethical review of Operating System dataset including whether

datasets could be used for inappropriate purposes, such as disadvantaging vulnerable

populations, which is also an IRB oversight concern.

Smart Columbus will be transparent in the Operating System process and seek to engage the

community for feedback.

Smart Columbus will consider the life cycle of Operating System datasets and will conduct routine

audits of its data treatment and release procedures.

Data added to the Operating System by a Smart Columbus data curator will meet defined quality

and accuracy standards set forth by and controlled by processes defined in the DMP.



Smart Columbus may make already publicly available data available on the Operating System if

the risk/benefit analysis described in Section 7.1.1. concludes the data should be made available

on the Operating System.

7.1.1. Benefit-Risk Analysis for Making Datasets Publicly Available

To add a dataset to the Operating System, a Smart Columbus data curator must complete and document

the following process:

Step 1: Evaluate the Information the Dataset contains

Step 2: Evaluate the Benefits

Step 3: Evaluate the Risks

Step 4: Weigh the Benefits against the Risks, and Apply Appropriate Technical and

Administrative Controls

This process is informed by the work of: Future of Privacy Forum’s Model Benefit-Risk Analysis; NIST SP-

800-188 De-identifying Government Datasets; Khaled El Eman, A De-Identification Protocol for Open

Data; the DataSF Open Data Release ToolKit; and the Berkman Klein Center’s risk-benefit, process-

oriented approach to sharing and protecting municipal data.

7.1.1.1. STEP 1: EVALUATE THE INFORMATION THE DATASET CONTAINS

A Smart Columbus data curator will review a dataset that has been submitted for inclusion in the

Operating System and classify the information it contains by the following data categories:

Direct Identifiers: Data points that identify a person without additional information or by linking to

other readily available information such as names, SSNs, and employee ID numbers.

Indirect Identifiers: Data points that do not directly identify a person, but that in combination can

single out an individual. This could include information such as birth dates, ZIP codes, gender,

race, or ethnicity.

Non-Identifiable Information: Information that cannot reasonably identify an individual, even in

combination and does not present privacy risks. For example, this might include city traffic

patterns or atmospheric readings.

Sensitive Attributes: Information that is sensitive in nature such as health conditions, financial

information and criminal justice records that should not be linkable to personal identities.

Special Data Categories: Certain categories of information that are particularly difficult to de-

identify such as geographic/location information, dates and times, unstructured or free form fields,

biometric information, and photographs or videos and may require the application of de-

identification tools.2

2 Future of Privacy Forum, “City of Seattle Open Data Risk Assessment” (January 2018) p. 35 (https://fpf.org/wp-

content/uploads/2019/01/FPF-Open-Data-Risk-Assessment-for-City-of-Seattle.pdf)





7.1.1.2. STEP 2: EVALUATE THE BENEFITS

Making datasets available in the Operating System can increase transparency, improve internal efficiency,

and stimulate innovation, ideas, and services across an array of city challenges. For example, at the

Smart Columbus Hackathon, civic innovators leveraged information from the Operating System to

develop applications, tools, and services that will help:

Manage city parking services.

Share traffic information.

Food insecure individuals/families find, share and/or access food assistance resources in central

Ohio.

Trip planning by routing individuals to appropriate transit options based on their mobility ability.

Advise truck drivers of available spaces to stop for a break or to take their mandated rest.

Inform oversized vehicle drivers of travel directions to avoid low clearance bridges.3

Various categories of information can also serve the purposes of government accountability and

efficiency, analysis, and reporting.4 The Smart Columbus data curator will identify which of the following

groups may use a dataset and who stands to benefit from the data:

Individuals

Businesses, innovators, private entities

Policymakers, researchers

Civic hackers

Community groups

Journalists5

Table 3: Publication Value demonstrates assessing the value of publication.

Table 3: Publication Value

Likelihood of Occurrence

Low Impact of Foreseeable Benefits

Medium Impact of Foreseeable Benefits

High Impact of Foreseeable Benefits

Low Low Benefit Low Benefit Medium Benefit

Medium Low Benefit Medium Benefit High Benefit

High Medium Benefit High Benefit High Benefit


3 Smart City Hackathon (May 18-20) (https://scos.splashthat.com/’) 4 DataSF “Open Data Release Toolkit: Privacy Edition” p. 22 (https://datasf.org/resources/open-data-release-toolkit/) 5 Ben Green, Gabe Cunningham, Ariel Ekblaw, Paul Kominers, Andrew LIzer and Susan Crawford, “Open Data

Privacy Playbook”, Berkman Klein (Feb. 27, 2017), p. 15 (https://cyber.harvard.edu/publications/2017/02/opendataprivacyplaybook)

https://scos.splashthat.com/





7.1.1.3. STEP 3: EVALUATE THE RISKS

Each dataset that is contemplated to be added to the Operating System must be evaluated for any risks

that data may create. Following are the risk categories that will be assessed against each dataset:

Re-Identification: Even when a dataset has been de-identified of names and other potentially

identifying traits and rendered “de-identified,” there is a chance that someone might be able to

deduce that some of the data relates to a specific individual. This is an extremely difficult

technical task to attempt to do automatically. These risks may rise over time as additional

information is added to the Portal or there are advances in re-identification technologies. The

responsibility of the Operating System is to inform those managing data of the potential

opportunity for re-identification when datasets are added or modified in the system. Re-

identification could harm individuals or organizations through:

o Exposure to the risk of identity theft, discrimination, or abuse

o Revealing location information that could lend itself to burglary, property crime, or assault

o Exposing a person to financial harms or loss of economic opportunity

o Causing embarrassment or psychological harm

Data Quality and Equity: In some circumstances, the consequences of inaccurate, incomplete,

or biased data can lead to group level risks such as:

o Creating or reinforcing biases towards or against a particular group

o Disproportionately including or excluding information from a particular group in the dataset in

a way that causes poor policymaking or inequitable distribution of services

Public Trust Impacts: Even if properly de-identified or aggregated, making certain types of

datasets publicly available may engender public opposition. Smart Columbus data curators will

consider:

o Does a dataset contain sensitive types of information that could lead to public opposition?

o Public expectations as to how the particular dataset will be used or shared.

o Is it likely that the information it the dataset will lead to a chilling effect on individual,

commercial, or community activities, particularly activities protected by the First Amendment?

o Could third parties use the data set improperly?

Table 4: Publication Risk demonstrates assessment of the risk of publication.

Table 4: Publication Risk

Likelihood of Occurrence

Low Impact of Foreseeable Risks

Medium Impact of Foreseeable Risks

High Impact of Foreseeable Risks

Low Low Risk Low Risk Medium Risk

Medium Low Risk Medium Risk High Risk

High Medium Risk High Risk High Risk




7.1.1.4. STEP 4: WEIGH THE BENEFITS AGAINST THE RISKS, APPLY APPROPRIATE TECHNICAL AND ADMINISTRATIVE CONTROLS

Table 5: Benefits and Risks of Dataset Inclusion demonstrates weighing the benefits against the risk

of including that dataset in the Operating System to decide about inclusion.

Table 5: Benefits and Risks of Dataset Inclusion

Benefit Low Risk Medium Risk High Risk

High Benefit Add data to operating System subject to appropriate controls.

Add data to Operating System subject to appropriate controls.

Possibly add Data and consider heightened controls. Possibly consider public awareness campaign.

Medium Benefit Add data to Operating System subject to appropriate controls.

Possibly add Data and consider heightened controls. Possibly consider public awareness campaign.

Do not release data.

Low Benefit Possibly add Data and consider heightened controls. Possibly consider public awareness campaign.

Do not release data. Do not release data.




7.2. TECHNICAL, ADMINISTRATIVE AND LEGAL CONTROLS6

Any data included in the Operating System must be subject to appropriate technical, administrative and

legal controls to protect privacy.

7.2.1. Technical Controls

The Operating System Team will develop expertise in applying specific De-Identification Tools based on

NIST 800-188 De-Identifying Government Datasets.7 These De-Identification Tools complement and

support PII security controls discussed in Chapter 5. Personally Identifiable Information Security

Controls:

Suppression: Removing a data field or an individual record to prevent the identification of

individuals in small groups or those with unique characteristics.

Generalization/Blurring: Reducing the precision of disclosed data to minimize the certainty of

individual identification, such as by replacing precise data values with ranges or sets.

Pseudonymizing: Replacing direct identifiers with a pseudonym (such as a randomly generated

value, an encrypted identifier, or a statistical linkage key). Pseudonymizing is a way of labeling

multiple de-identified records from the same individual so that they can be linked together.

Pseudonymizing is a form of masking identifiers; it is not necessarily a form of de-identification.

Pseudonymized data can, in some instance, constitute PII.

Aggregation: Summarizing the data across the population and then releasing a report based on

those data (such as contingency tables or summary statistics), rather than releasing individual

level data.

Visualizations: Rather than providing users access to raw microdata, data may be presented in

more privacy-protective formats, such as data visualizations or heat maps.

Perturbation: An expert adds “noise” to the dataset (such as swapping values from one record to

another, or replacing one value with an artificial value), making it difficult to distinguish between

legitimate values and the “noise.”

K-Anonymity: A technique to measure and limit how many individuals in a dataset have the

same combination of identifiers. K-anonymity suppresses or generalizes identifiers and perturbs

outputs until a particular k-value is reached.

Differential Privacy: A formal mathematical definition of privacy, which may be satisfied by a

range of techniques if the result of an analysis of a dataset is the same before and after the

removal of a single data record.

Synthetic Data: A process in which seed data from an original dataset is used to create artificial

data that has some of the statistical characteristics as the seed data. Datasets may be partially

6 Future of Privacy Forum, “City of Seattle Open Data Risk Assessment” (January 2018) p. 43-49 (https://fpf.org/wp-

content/uploads/2018/01/FPF-Open-Data-Risk-Assessment-for-CIty-of-Seattle.pdf); Ben Green, Gabe Cunningham, Ariel Ekblaw, Paul Kominers, Andrew Lizer and Susan Crawford, “Open Data Privacy Playbook”, Berkhan Klein (Feb. 27, 2017), p. 26-29 (https://cyber.harvard.edu/publications/2017/02/opendataprivacyplaybook); DataSF, “Open Data Release Toolkit: Privacy Edition” p. 25-27 (https://datasf.org/resources/open-data-release-toolkit/)

7 Future of Privacy Forum, “City of Seattle Open Data Risk Assessment” (January 2018) p. 35 (https://fpf.org/wp-contenct/uploads/2018/01/FPF-Open-Data-Risk-Assessment-for-City-of-Seattle.pdf)

https://fpf.org/wp-content/uploads/2018/01/FPF-Open-Data-Risk-Assessment-for-CIty-of-Seattle.pdf





https://fpf.org/wp-contenct/uploads/2018/01/FPF-Open-Data-Risk-Assessment-for-City-of-Seattle.pdf

https://fpf.org/wp-contenct/uploads/2018/01/FPF-Open-Data-Risk-Assessment-for-City-of-Seattle.pdf



synthetic (in which some of the data is inconsistent with the original dataset) or fully synthetic (in

which there is no one-to-one mapping between any record in the original dataset and the

synthetic dataset).

7.2.2. Administration and Legal Controls

The Operating System Administrative team will develop administrative and legal controls8 to complement

technical de-identification controls to protect data. Depending on the sensitivity and identifiability of the

data, it will employ mechanisms such as the following to set access and use controls on Operating

System datasets:

Contractual Provisions: Data is made available to qualified users under legally binding

contractual terms (such as commitments not to attempt to re-identify individuals or link datasets,

to update the information periodically or to use data in noncommercial and nondiscriminatory

ways). Data may be backed up by audit requirements and penalties for noncompliance.

Access Fees: Charging users for access to data increases accountability and may discourage

improper use of the data. An access fee may also implement tiered fee structures for commercial

access or remote versus in-person access.

Tiered Access Controls: This system allows data to be made available to various categories of

users through different mechanisms.

Ethical and/or Disclosure Review Board: The City may develop an advisory group with broad

expertise and community engagement for further review of particularly risky or ambiguous policy

decisions.

7.3. REGISTERING APPLICATIONS TO PROVIDE DOWNSTREAM USAGE INFORMATION

The Operating System will also serve as a Platform as a Service (PaaS) that will enable third-party

entities and individuals to develop, operate, and manage innovative applications on the system. These

applications may collect and use PII that is not stored in the Operating System. In addition, third parties

could merge these proprietary datasets with Operating System public datasets and so produce PII

sensitive fields outside the immediate control of the Operating Systems team. Applications must register

with the Operating System and provide downstream uses of information and disclose information

sources. The Smart Columbus team must approve the usage notice and apps must receive opt-in

consent from users.

8 Future of Privacy Forum, “City of Seattle Open Data Risk Assessment” (January 2018) p. 49-52 (https://fpf.org/wp-

content/uploads/2018/01/FPF-Open-Data-Risk-Assessment-for-CIty-of-Seattle.pdf)





7.4. TRANSPARENCY AND PUBLIC ENGAGEMENT

The Smart Columbus team will maintain a public website with current information about the Smart

Columbus Operating System, including educational material regarding using and sharing data in the

exchange, all policies and procedures for Operating System operation, and any appropriately related

public meeting minutes or reports, and information about the datasets on the Operating System, including

risk assessment. The City shall include a mechanism for the public to give feedback on and assess the

quality of published information, provide input about what information should be a priority for inclusion,

and provide overall input on the Operating System.

7.5. MOTIVATED INTRUDER TEST

Smart Columbus will periodically apply a “motivated intruder” test to determine whether any data presents

a risk of re-identification. The motivated intruder would be a person who starts without any prior

knowledge but wishes to identify an individual from personal data that was de-identified on the Operating

System. This test is meant to assess whether the motivated intruder would be successful.9

A motivated intruder test will include:

A web search to discover whether a combination of date of birth and postcode data can be used

to reveal a particular individual’s identity;

Searching the archives of a national or local newspaper to see whether it is possible to associate

a victim’s name with crime map data;

A social network search to see if it is possible to link anonymized data to a user’s profile; or

Using the electoral register and local library resources to try to link anonymized data to

someone’s identity.10

7.6. REVIEW AND CONTINUOUS IMPROVEMENT

As with any policy, and the system engineering process, review and continuous improvement are keys to

success. The City will continue to review and improve upon this DPP.

9 UK, Information Commissioners Office “Anonymisation: Managing Data Protection Risk Code of Practice”

(https://ico.org.uk/media/1061/anonymisation-code.pdf) 10 El Emam, :A De-identification Protocol for Open Data” IAPP (May 2016) (https://iapp.org/news/a/a-de-identification-

protocol-for-open-data/)

https://ico.org.uk/media/1061/anonymisation-code.pdf




Appendix A. Data Inventory

To develop appropriate and effective privacy controls, it is essential first to understand the data to which

these controls will apply (see Sub-Appendix 1. Field Matrices for detailed project-by-project predicted

flows). The first step in implementing such controls is, accordingly, to conduct a data inventory. In a

dynamic project such as Smart Columbus, this data inventory will evolve, since it is contingent on

requirements and designs that are to follow in the systems engineering process. What follows herein is an

initial, contingent snapshot of the PII and SPII that the Smart Columbus demonstration projects may

collect and employ.

A.1 CONNECTED VEHICLE ENVIRONMENT PROJECT

Data to be collected from participants in the Connected Vehicle Environment project will include many of

the following forms of PII about individual participants and their motor vehicles and motor vehicle use. The

following data represent the minimum amount of data required for performance analysis to be effective

and statistically relevant as determined by USDOT.

Participant background information

o Individual identifiers

o Full name (first, middle, last) Individual subject research identifier created by SC

o Driver’s license number, issuing state and qualifiers

Vehicle identifiers

o VIN of government- or corporate-issued vehicles

o Identifiers for equipment installed

Contact information (one of these)

o Mailing/residential address

o Phone number(s)

o Email address(es)

o Institutional or organizational information

Eligibility information

o Driver history and habits

o Medical history relevant to the scope of the project

o Outcomes of criminal background check

Project information

o Vehicle sensor information

o Video or still images, including infrared

o Audio recordings



o Dynamic information about a vehicle, including location, heading, proximity to and interaction

with other vehicles and infrastructure

o Dynamic information about a driver’s interaction with the vehicle, including steering wheel,

turn signal, and accelerator and brake pedal positions

o Data collected from drivers by means of surveys, focus groups or interviews

A.2 MULTIMODAL TRIP PLANNING APPLICATION/COMMON PAYMENT SYSTEM

While more information on the PII and SPII that this project deployment is likely to generate will become

available as the project develops, PII and SPII datasets to be considered include:

Participant background and contact information – only for passengers; COTA drivers will fall

under the COTA standard operating procedures

Routes traveled

Origin and destination points

Reservations for transportation options

Time of travel

Travel preferences

Trip itineraries viewed and those selected

Payment Identifications

Amounts paid and tipped

A.3 SMART MOBILITY HUBS

Smart Mobility Hubs are for those who do not have smartphones, so this project may not need or collect

any PII, depending on its design and use characteristics. Users are likely to be anonymized since they

are Non-Registered System Users. If PII needs to be collected, it may include:

Use of trip planning Kiosks

Trips planned


Time of travel

Travel preferences

Vehicle sharing



A.4 MOBILITY ASSISTANCE FOR PEOPLE WITH COGNITIVE DISABILITIES



Participant background and contact information, as defined for a CVE project above

Nature and severity of disability

Other health information

Scheduling assistance needed

Boarding assistance needed

Standard routes traveled


Time of travel

Agency or agencies offering assistance

Agency assistance needed or preferred

Duration of visit to agency

Income

Medicaid or other financial assistance eligibility

A.5 PRENATAL TRIP ASSISTANCE



Participant background and contact information, as defined for CVE project above; the

participant’s insurance company will send Operating System filtered information

Pregnancy status

Other health information; only as pertaining to a need for trip scheduling

Routes traveled


Time of prenatal visits

Missed prenatal visits

Other visits – pharmacy, other medical, County Medicaid redetermination hearings, food bank,

WIC appointments

Duration of appointment

Agency of agencies offering assistance, only as needed for trip information

Assistance needed or preferred for trip



Income (probably not needed)

Medicaid or other financial assistance eligibility (all participants are Medicaid recipients)

Offspring date of birth

Offspring Medicaid eligibility

A.6 EVENT PARKING MANAGEMENT



Non-Registered System User background and contact information, as defined for CVE project

above, as needed

License plate number

Location and time of parking reservations

Duration of parking requested or reserved

Type or size of vehicle (ADA, Electric Vehicle, Oversized)

Origin and destination points.

A.7 CONNECTED ELECTRIC AUTONOMOUS VEHICLES



Non-Registered system users background and contact information, as defined for CVE project

above


Information about other vehicles in vicinity of CEAV as recorded in CEAV’s sensors

Use of other transportation options that connect to CEAV for first mile/last mile service

A.8 TRUCK PLATOONING



Participant background and contact information, as defined for CVE projects above – depending

upon the arrangements made with freight companies and private operators, drivers need not be

identified, only companies and their vehicles, or as determined by the IRB

VIN (SPII, only as needed)

Freight weight and type moving through study area (PII)

Relationships and use of communications in platooning between truck drivers (PII)

Time and duration of trip (SPII, only as needed)

Trip characteristics – origin and destination points (PII in full deployment)



Road sections where platooning occurred, which may be used to identify vehicles (non-PII)


Appendix B. Privacy Impact Assessment

The criteria shown in Table 6: Privacy Impact Assessment Outline of Required Contents will be used

for evaluating project privacy impact.

Table 6: Privacy Impact Assessment Outline of Required Contents

Section 1.0: Characterization of Information

1.1 What information is collected, used, disseminated, or maintained in the system?

1.2 What are the sources of the information in the system?

1.3 Why is the information being collected, used, disseminated, or maintained? Is there a specific legal mandate or business purpose that requires the use of this information?

1.4 How is the information collected?

1.5 What specific legal authorities, arrangements, and/or agreements defined the collection of information?

1.6 Conclusion: Given the amount and type of data collected, discuss the privacy risks identified and how they were mitigated.

Section 2.0: Uses of the Information

2.1 Describe all the uses of information.

2.2 How will the information be checked for accuracy?

2.3 What types of tools are used to analyze data and what type of data may be produced?

2.4 If the system uses commercial or publicly available data please explain why and how it is used.

2.5 Conclusion: Describe any types of controls that may be in place to ensure that information is handled in accordance with the described uses in 2.1.

Section 3.0: Retention

3.1 What information will be retained?

3.2 How long will information need to be retained?

3.3 Has the retention met the NARA records schedule?

3.4 Is the information deleted in a secure manner?

3.5 Conclusion: Please discuss the privacy risks associated with the length of time data is retained and how those risks are mitigated.



Section 4.0: Internal Sharing and Disclosure

4.1 With which internal City or demonstration entities is the information shared, what information is shared and for what purpose?

4.2 How is the information transmitted or disclosed?

4.3 Conclusion: Considering the extent of internal information sharing, discuss the privacy risks associated with the sharing and how they were mitigated.

Section 5.0: External Sharing and Disclosure

5.1 With which external organization(s) is the information shared, what information is shared, and for what purpose?

5.2 Is the sharing of personally identifiable information outside the demonstration compatible with the original collection? If so, is it addressed in a data-sharing agreement? If so, please describe. If not, please describe under what legal mechanism the program or system is allowed to share the personally identifiable information outside of the demonstration.

5.3 How is the information shared outside the agency and what security measures safeguard its transmission?

5.4 How does the agency verify that an external organization has adequate security controls in place to safeguard information?

5.5 Conclusion: Given the external sharing, explain the privacy risks identified and describe how they were mitigated.

Section 6.0: Notice

6.1 Was notice provided to the individual prior to collection of information?

6.2 Do individuals have the opportunity and/or right to decline to provide information?

6.3 Do individuals have the right to consent to particular uses of the information? If so, how does the individual exercise the right?

6.4 Conclusion: Describe how notice is provided to individuals, and how the privacy risks associated with individuals being unaware of the collection are mitigated.

Section 7.0: Access, Redress and Correction

7.1 What are the procedures that allow individuals to gain access to their information?

7.2 What are the procedures for correcting inaccurate or erroneous information?

7.3 How are individuals notified of the procedures for correcting their information?

7.4 If no formal redress is provided, what alternatives are available to the individual?



7.5 Conclusion: Please discuss the privacy risks associated with the redress available to individuals and how those risks are mitigated.

Section 8.0: Security Implementation

8.1 What procedures are in place to determine which users may access the system and are they documented?

8.2 Will contractors have access to the system?

8.3 Describe what privacy training is provided to users either generally or specifically relevant to the program or system?

8.4 What auditing measures and technical safeguards are in place to prevent misuse of data?

8.5 Does the project employ technologies which may raise privacy concerns? If so, please discuss their implementation.

8.6 Conclusion: Given the sensitivity and scope of the information collected, as well as any information sharing conducted on the system, what privacy risks were identified and how do the security controls mitigate them?



Appendix C. National Institute of Standards and Technology Special Publication 800-53 Control Categories

NIST SP 800-53 specifies a list of control categories to be included in a data privacy plan. Table 7:

National Institute of Standards and Technology Control Categories Correlation illustrates how the

DPP correlates to the NIST categories.

Table 7: National Institute of Standards and Technology Control Categories Correlation

NIST Category DPP Section NIST Objective Verification Method/Outcome

AP Authority and Purpose

AP-1 Authority to Collect

Determine and document the legal authority that permits the collection, use, maintenance, and sharing of PII either generally or in support of a specific program or information system need.

Does the DPP cite its authority to collect PII data?

AP-2 Purpose Specification



Describe purpose(s) for which PII is collected, used, maintained, and shared in its privacy notices.

Does the DPP provide purpose(s) for PII usage?

Do informed consent documents disclose purpose(s) for which data will be used?

AR Accountability, Audit and Risk Management

AR-1 Governance and Privacy Program

Executive Summary

Identify individual to monitor and enforce privacy policies and to monitor federal privacy laws and policies for changes that affect the SC program’s privacy policies.

Has an individual been identified to monitor and enforce privacy policies for the project?

AR-2 Privacy Impact and Risk Assessment


Verify the creation and implementation of a privacy risk management process and related PIAs.

Has SC created and implemented a privacy risk management process and related PIAs?




Assess the most likely threat scenarios:

Malicious Outsider attempting to steal PII

Malicious Outsider attempting to commit fraud or steal funds

Negligent Insider being compromised

Malicious Insider attempting to steal PII or commit fraud

And so forth.

AR-3 Privacy Requirements for Contractors and Service Providers

Executive Summary

Verify the establishment of privacy roles, responsibilities, and access requirements for contractors and service providers; and includes privacy requirements in contracts and other acquisition-related documents.

Do contractor and service providers’ contracts and other acquisition-related documents contain privacy requirements?

Do systems include and enforce permission-based roles for any contractor or service provider users?

Are all contractors and service providers given documentation regarding their responsibilities and access restrictions with regards to PII?

AR-4 Privacy Monitoring and Auditing

Section 5.3.9. Audits


To monitor and audit privacy controls and internal privacy policy to ensure effective implementation

Internal Audits

o Is there a method for periodic Internal Audits in alignment with Performance Measurement and Evaluation Support Plan (PMESP) requirements?

o Is there budget and staff assigned for Internal Audits?

o Is there a process to resolve audit findings?

o How many Internal Audits are scheduled?

o How many Internal Audits have been performed?

External Audits

o Is there a method for periodic external Audits in alignment with PMESP requirements?

o Is there budget and resources identified for External Audits?

o How many External Audits are scheduled?




o How many External Audits have been performed?

AR-5 Privacy Awareness and Training


Verify the establishment and implementation of privacy protection training, along with documented staff acceptance of privacy protection responsibilities.

Does the training provided to study staff include content regarding privacy protection policies and practices as well as documented staff acceptance of appropriate responsibilities?

AR-6 Privacy Reporting



The development, distribution and updating of reports that demonstrate compliance with Ohio State University IRB

Are reports of privacy plan changes and/or system breaches shared in all cases and within stated timeframes?

Are reports are retained in accordance with NARA requirements?

AR-7 Privacy-Enhanced System Design and Development


Verify that information systems support privacy by automating privacy controls

Anonymity

o Is live data, accessed in the field on OBUs, RSUs or sniffers – protected according to the stated security standards?

o Is stored CV raw data protected against unauthorized dissemination and intrusion according to the stated methods?

o Is ID-based/role-based authorization required to access the following?

o Live or stored connected vehicle (CV) data (original and de-identified)

o PII or SPII data in any state

Filtering/Scrubbing

o Has “de-identified” CV data been cleared of data identified in the project as ‘sensitive’?

Need to Know

o For all systems collecting, transmitting or storing CV, PII, SPII or participant data – is all access restricted by an assigned system-enforced role?




Compartmentalization

o According to Smart Columbus standards, are data types in all systems that collect, transmit or store data properly separated from each other? (i.e.: raw data is not available to users of de-identified data etc.)

AR-8 Accounting of Disclosures



Track information disclosed from each system of record including date, nature and purpose of each disclosure as well as the name and address of the person or agency receiving the information. Also verify that this audit trail is retained for the life of the record or 5 years after the disclosure is made. Also verify that the audit trail of disclosures is made available to the person named in the record upon request.

Are internal disclosures within the SC team documented and available for IRB audit?

Are unauthorized disclosures tracked and reported?

DI Data Quality and Integrity

DI-1 Data Quality



Verify that the program confirms the accuracy, relevance, timeliness and completeness of PII upon collection or creation, collect PII directly from the individual as much as possible, checks for and corrects as needed – any inaccurate or outdated PII used by SC programs or systems.

Has the SC program provided the ability for individuals to enter their own PII directly?

Does the Smart Columbus program provide a method by which individuals can update their PII?

DI-2 Data Integrity and Data Integrity Board


Document processes to ensure the integrity of PII through existing security controls

Does the system used to collect and store PII have controls applied to protect the integrity of the data?

Does it protect against unauthorized access?




Does it protect against unauthorized PII modification?

Does it a process for to validate the accuracy of PII?

DM Data Minimization and Retention

DM-1 Minimization of Personally Identifiable Information

Section 3.1: Statement of Data Stewardship Principles

Section 4.1.3: Data Minimization

Identify the minimum PII that is necessary to accomplish the project goals, limit the collection and retention of PII to those minimum elements, and conduct an initial evaluation of PII holdings and follow a regular schedule for reviewing those holdings to ensure that only PII identified as minimum required data is collected and retained, and that the PII continues to be necessary to accomplish the legally authorized purpose.

Does the program only gather the PII identified in the DPP?

Has the program conducted an initial review of PII holdings to ensure that only PII identified as minimum required data is collected and retained?

Does the program periodically review its PII data categories to ensure that they remain required to accomplish its legally authorized purpose?

DM-2 Data Retention and Disposal


Verify that the SC program retains PII to fulfill stated purpose for the PII, that the project disposes of the PII in accordance with a NARA-approved record retention schedule and in a manner that prevents loss, theft, misuse or unauthorized access and uses identified methods to ensure secure deletion when destroying PII.

Is PII data used to exclusively fulfil its stated purpose in the project?

Once the PII’s usage is complete, is PII disposed of in a NARA-approved method?

DM-3 Minimization of PII Used in Testing, Training, and Research

Section 3.1: Statement of Data Stewardship Principles

Section 4.1.3: Data Minimization

Chapter 6. Institutional Review Board

Verify the development of policies and procedures that minimize the use of PII for testing, training and research.

Verify that controls have been implemented to protect PII used for testing, training and research.

Do policies and procedures exist that minimize the use of PII?

Have the controls enumerated in the DPP been implemented?




Oversight of Personally Identifiable Information


IP Individual Participation and Redress

IP-1 Consent Chapter 4. Personally Identifiable Information Privacy Controls

Verify that the project has provided a means for individuals to authorize the collection, use, maintenance and sharing of PII prior to its collection.

Verify that the project has provided a means for individuals to understand the consequences of decisions to approve or decline the authorization of the collection, use dissemination and retention of PII.

Does the method of signing up new participants include an explicit authorization from those individuals regarding PII collection?

Does the method of signing up new participants include a summary of consequences regarding either the approval or the rejection of PII collection?

IP-2 Individual Access


Verify that the project provides individuals the ability to have access to their PII maintained in its system(s) of records.

Verify that the project publishes rules and regulations governing how individuals may request access to records maintained in a Privacy Act system of record as appropriate.

IP-3 Redress Chapter 6. Institutional Review Board Oversight of Personally Identifiable Information

Verify that the project provides a process for individuals to have inaccurate PII corrected.

Does the project provide a method for participants to correct their PII?

IP-4 Complaint Management

Chapter 6. Institutional Review Board Oversight of Personally

Verify that the project has implemented a process for receiving and responding to complaints, concerns or

Does the project provide a method for participants to lodge complaints, concerns or




Identifiable Information

questions from individuals about the project’s privacy practices.

questions regarding privacy practices?

How many complaints have been received during the span of the study?

How many questions have been received during the span of the project?

Of the complaints received, what percentage have been resolved?

Of the questions that have been received, what percentage have been answered?

SE Security

SE-1 Inventory of Personally Identifiable Information


Verify that the project has establishing and updating an inventory containing a listing of all programs and information systems that collect, use, maintain or share PII, and that this inventory is shared with the CIO or Information Security Official for the project.

Has the project program established an inventory of all systems and programs that collect, use, maintain or share PII?

Does the program maintain that inventory on a periodic basis?

Has that inventory been shared with the individual charged with managing security for the program?

SE-2 Privacy Incident Response


Verify that the project has developed and implemented a Privacy Incident Response Plan and does provide an organized and effective response to privacy incidents in accordance with the Plan.

Does the SC program have a Privacy Incident Response Plan?

How many incidents have been logged since the inception of the study program?

On average, how many days elapsed between the detection of the incident and the final response?

TR Transparency

TR-1 Privacy Notice


Verify that the project provides effective notice to the public and to individuals regarding its activities that impact privacy, including its collection use, sharing, safeguarding, maintenance and disposal of PII its authority for collecting PII, and the ability to

Does the program effectively notify participants of its activities that impact privacy?

Does the program share with participants the types of PII that is collected, the purpose for collection, if the PII will be shared with third parties, how the data will be secured, and how it will be eventually disposed of?




access and have PII corrected.

Verify that the project describes the PII collected and its purpose, how the project uses the PII, whether the project shares PII with external entities, how individuals may obtain access to PII and how the PII will be protected.

Verify that the project revises its public notices to reflect changes in practice or policy that affect PII or changes in its activities that impact privacy – in a timely manner.

Have the program’s processes or practices regarding PII changed, and have its public notices been updated accordingly?

TR-2 System of Records Notices and Privacy Act Statements

N/A

TR-3 Dissemination of Privacy Program Information


Verify that the project ensures that the public has access to information about its privacy activities and is able to communicate with its Senior Agency Official for Privacy.

Does the project or its sponsor, USDOT, ensure that the public has adequate access to information with regards to PII used in the project?

Does the public have access to the individual assigned to manage Privacy for the project?

UL Use Limitation

UL-1 Internal Use


Verify that the project uses PII internally only for the authorized purpose identified in public notices and the Privacy Act.

Does the project use PII internally according to its stated authorized purpose?

UL-2 Information Sharing with Third Parties


Verify that Smart Columbus shares PII only for the authorized purposes.

Verify that the project monitors, audits and trains its staff on the authorized sharing of PII with third parties and on

Does the project consistently filter/scrub data prior to sharing with third parties?

Audit SCMS Certificates/CRL

Do logs exist? Do they show a pattern of attempted intrusion?

Encryption

Is live data encrypted?




the consequences of unauthorized use or sharing of PII, and that the project evaluates any proposed new instances of sharing PII with third parties to assess whether the sharing is authorized and whether additional or new public notice is required.

Is stored raw CV data encrypted?

Is data in transit encrypted?

Is all PII or SPII data encrypted?

Is Electronic Participant data encrypted?

Access Control – Physical

Is physical access to the following devices protected according to the project’s stated standards?

Devices collecting or transmitting CV data of any kind

Devices storing raw or de-identified CV data

Devices collecting, transmitting or storing PII or SPII

Are all hard-copy documents containing participant data under physical protection according to the project’s stated standards?

Access Control – Remote

Is remote access to the following devices protected according to the project’s stated standards?

Devices collecting or transmitting CV data of any kind

Devices storing raw or scrubbed CV data

Devices collecting, transmitting or storing PII or SPII

Penetration Testing

What is the frequency of penetration testing?

What is the number of systems tested?

What is the number of systems with high-risk findings?

What is the number of findings per system?

What is the number of closed finding per system?

System Monitoring

Are systems that collect, transmit or store CV data monitored




according to the SC program’s stated practice?

How many systems are being monitored?

What is the average system availability to date?

How many intrusions have System Monitors logged to date?

How many blocked intrusions have System Monitors logged to date?

Antivirus

Do all systems that transmit or store CV or participant data have up-to-date antivirus protection?

How many malware incidents have been logged by antivirus software per system?



Appendix D. National Institute of Standards and Technology Special Publication 800-122 Checklist Summary

Table 8: National Institute of Standards and Technology Checklist

Checklist Question DPP Consideration

Has your organization ever performed work for a Federal agency that involved handling PII?

Yes. The City handles federal tax information governed by IRS Publication 1075. IRS Contact: Jackie Nielson, Fed State Coordinator, Ohio District Department of the Treasury, (614) 280-8739

Does your organization have any policies/procedures to protect the security and confidentiality of PII?

Yes. The City has Executive Orders, policies and procedures to protect the security and confidentiality of PII. City Executive Orders and Policies are posted at https://www.columbus.gov/hr/Executive-Orders-and-Policies/

Does your organization have any policies/procedures to control and limit access to PII?

Yes. The City has Executive Orders and Policies to control and limit access to PII. City Executive Order and Policies are posted at https://www.columbus.gov/hr/Executive-Orders-and-Policies/

Does your organization store PII on network drives and/or in application databases with proper access controls (i.e., User IDs/passwords)?

Yes. The City assigns unique identifiers and requires complex passwords.

Does your organization limit access to PII only to those individuals with a valid need to know?

Yes. The City limits access to PII only to those individuals with a valid need to know.

Does your organization prohibit or strictly limit access to PII from portable and mobile devices, such as laptops, cell phones and personal digital assistants, which are generally higher risk than nonportable devices (e.g., desktop computers at the organization’s facilities)?

Yes. Executive Order 2007-03 prohibits such actions.

Does the information system used by your organization to store PII contain automated or easy-to-use process to ensure that only authorized users access PII – and only to the extent that each user has been authorized to do so?

Yes. The City uses Active Directory to assign unique identifiers, require complex passwords and control access to private or sensitive information.

Does your organization monitor events that may affect the confidentiality of PII, such as unauthorized access to PII?

Yes. The City monitors events and configures alerts for events that may affect the confidentiality of PII.

https://www.columbus.gov/hr/Executive-Orders-and-Policies/




Appendix D. National Institute of Standards and Technology Special Publication 800-122 Checklist Summary


Checklist Question DPP Consideration

Does your organization audit its information systems on a regular or periodic basis?

Yes. The City performs security assessments by various methods including access, rule and configuration reviews. The City is also subject to external audits including an IRS Safeguards Review.

Does your organization analyze information system audit records for indications of inappropriate or unusual activity affecting PII, investigate suspicious activity or suspected violations, report findings to appropriate officials, and take necessary actions?

Yes. The City has a Security Incident Response Plan written to provide a well-defined, organized approach for handling any potential threat to systems and data.

Does your organization restrict access to information system media containing PII, including digital media (e.g., CDs, USB flash drives, backup tapes) and non-digital media (e.g., paper, microfilm)?

Yes. The City maintains strict control over the internal or external distribution of any kind of media. Digital containing sensitive information is physically secured from unauthorized access, labeled, inventoried and its tracked via logs. Non-digital media containing sensitive information is only kept when necessary for business purpose and physically secured from unauthorized access.

Does your organization restrict access to portable and mobile devices capable of storing PII?

Yes. Executive Order 2007-03 prohibits copying sensitive information to such devices.

Does your organization require that information system media and output (such as printed documents) containing PII be labeled to indication appropriate distribution and handling?

Yes. PO 22 requires that media must be classified so that the sensitivity of the data can be determined.

Does your organization securely store PII, both in paper and digital forms, until the media are destroyed or sanitized using approved equipment, techniques, and procedures?

Yes. Physical and logical access to media containing PII is strictly controlled. Encryption is used on digital media.

Does your organization sanitize digital and nondigital media containing PII before disposing of or reusing the media?

Yes. Paper media is destroyed using cross cut shredders. Digital media is sanitized prior to reuse or destroyed as part of disposal.


Appendix E. Acronyms and Definitions

Table 9: Acronym List contains program level acronyms used throughout this document.

Table 9: Acronym List

Acronym/Abbreviation Definition

ADA Americans with Disabilities Act

AES Advanced Encryption Standard

BRT Bus Rapid Transit

BSM Basic Safety Message

CAMP Crash Avoidance Metrics Partnership

CEAV Connected Electric Autonomous Vehicles

CFR Code of Federal Regulations

CIA Confidentiality, Integrity and Availability

CMAX Brand for COTA Cleveland Avenue Bus Rapid Transit

COTA Central Ohio Transit Authority

ConOps Concept of Operations

CPS Common Payment System

CRL Certificate Revocation List

CVE Connected Vehicle Environment

DMP Data Management Plan

DPP Data Privacy Plan

DSRC Dedicated Short Range Communications

EPM Event Parking Management

EU European Union

EV Electric Vehicle

FHWA Federal Highway Administration

FIPPs Fair Information Practice Principles

FIPS Federal Information Processing Standards

GDPR General Data Protection Regulation

GPS Global Positioning System

HHS Health and Human Services

HUAS Human Use Approval Summary




HURB Human Use and Review Board

ID Identification

IE Independent Evaluator

IRB Institutional Review Board

IT Information Technology

ITS Intelligent Transportation Systems

JPO Joint Program Office

MAPCD Mobility Assistance for People with Cognitive Disabilities

MMTPA Multimodal Trip Planning Application

NARA National Archives and Records Administration

NIH National Institutes of Health

NIST National Institute of Standards and Technology

OBU (DSRC) Onboard Unit

ODOT Ohio Department of Transportation

OHRP Office of Human Research Protections

ORC Ohio Revised Code

OSU The Ohio State University

PC Personal Computer

PHRP Protecting Human Research Participants

PIA Privacy Impact Assessment

PIDM Privileged Identification Management

PII Personally Identifiable Information

PoC Proof of Concept

PTA Prenatal Trip Assistance

RDF Resource Description Framework

RSU (DSRC) Roadside Unit

SC Smart Columbus

SCC Smart City Challenge

SCMS Security and Credentials Management System

SIEM Security Information and Event Management

SMH Smart Mobility Hubs

SMS Short Message Service

SoS System of Systems




SPaT Signal Phase and Timing

SPII Sensitive Personally Identifiable Information

SSN Social Security Number

TIM Traffic Information Message

TNC Transportation Network Company

UP Unanticipated Problems

USB Universal Serial Bus

USC United States Code

USDOT United States Department of Transportation

USDOT-JPO United States Department of Transportation – Joint Program Office

VIN Vehicle Identification Number

WIC Women, Infants and Children

ZIP Zone Improvement Plan



Appendix F. Glossary

Table 10: Glossary contains project specific terms used throughout this document.

Table 10: Glossary

Term Definition

Access Control Terms Identification: The means by which users claim their identities to a system. Identity is a required precursor to authentication and authorization.

Authentication: The testing or reconciliation of evidence of a user’s identity. IT established and verifies that a user is who they say they are.

Authorization: The right and privileges granted to a person or process.

Accountability: The processes and procedures by which a system obtains its ability to determine the actions and behavior of a single individual or process within the system and to identify that individual person or process. Audit trails and logs are examples of tools supporting accountability.

Aggregated Data Information is summarized across the population and released as a report of those statistics. Does not contain PII.11

Agile A method of project management that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.

App Software application.

Data Subject Refers to the subject of PII used by Smart Columbus.

Drivers The drivers (residents and visitors) in Columbus who will be interacting with the Smart Columbus projects.


11 Green et al., p. 27


Sub-Appendix 1. Field Matrices

Table 11: Connected Vehicle Environment Project Data Flow Matrix

Segment Number Type Name From To Messages

CVE 1.0 Message Broadcast BSM OBU OBU, RSU BSM

CVE 1.0a Message RSU Message Set RSU OBU SPAT

MAP

RTCM

SSM

TIM

CVE 1.0b Message BSM OBU Transit Management Center

Cellular BSM

CVE 1.0c Message MAP, TIM Broadcast Message Handler Traffic Management Center

MAP

TIM

CVE 1.1 Message Load BSM and SRM RSU Message Handler Load BSM

SRM

CVE 1.2 Message Load SRM and Signal Phase Timing Plan

Traffic Management Center

Message Handler Signal Timing Plan

CVE 1.3a Message Local SRM, Signal Timing Plan

Message Handler Traffic Signal Controller

Local SRM

Signal Timing Plan

CVE 1.3b Message Message Handler Message Handler Traffic Management Center

Backhaul Operations and Status Data

CVE 1.4 Message Local SPAT and SSM Traffic Signal Controller

Message Handler Local SPAT

SSM



Segment Number Type Name From To Messages

CVE 1.5 Message MH Message Set Message Handler RSU Local SPAT

MAT

RTCM

CVE 1.6 Message Combined Broadcast Traffic Management Center

Smart Columbus OS MAP

TIM

Signal Timing Plan

CVE 1.7 Message Backhaul Interaction Data Transit Management Center

Smart Columbus OS Backhaul Interaction Data


Table 12: Truck Platooning Project Data Flow Field Matrix

Segment Number Type Name From To Fields

Truck Platooning

Data Store

Platooning Events Smart Columbus OS

Platooning events

FPS events

Truck Platooning

1.1 Message Truck Info Truck OBU Logistics TMC GPS Location

Origin

Destination

Configuration e.g. HAZMAT

Truck Platooning

1.2 Message Platooning Opportunity Logistics TMC Truck OBU Route of travel

Trucks available for platooning

Platoon ID

Truck Platooning

1.3 Message Platooning Acceptance Truck OBU Logistics TMC Selected truck for platooning




Truck Platooning

1.4a Message Platooning Confirmation Logistics TMC Truck OBU Truck ID

Confirmation

Platoon ID

Truck Platooning

1.4b Message Platooning Info Logistics TMC Smart Columbus OS

Platoon ID

Route

Trucks

Platooning distance

Truck Platooning

1.5 Message Performance Metrics Truck OBU Logistics TMC Platoon ID

Route

Trucks

Platooning distance

Truck Platooning

1.6 Message Performance Metrics Logistics TMC Smart Columbus OS

Platoon ID

Truck ID

Starts

Stops

Idling time

Speed distribution

Truck Platooning

1.7 Message FSP Request Truck OBU RSU Truck ID

GPS location

Platoon ID

Truck Platooning

1.8 Message FSP Request RSU City TMC Intersection ID

RSU ID

FSP request

FSP initiation time

Truck Platooning

1.9 Message FSP Event City TMC Traffic Signal System

FSP initiation plan

FSP initiation time




Truck Platooning

1.10 Message FSP Event Traffic Signal System

Smart Columbus OS

FSP event data

Truck Platooning

2 Message Coordination Notification Truck OBU Truck OBU Traffic: curve ahead, variable speed, congestion, maneuvers

Weather: light conditions, rain

Road conditions: traction, potholes

Safety messages: deceleration rate, braking, speed




Table 13: Prenatal Trip Assistance Project Data Flow Field Matrix

Segment Type Name From To Fields

PTA Data Store

Trip and Usage Data PTA System SCOS Trip and Usage Data

Trip to physician start

Trip to physician end

Trip cancelled in route

Trip cancelled before start

Route detour from original plan

Appointment successful

Appointment unsuccessful

Trip from physician start

Trip from physician end

Trips planned and not booked

Satisfaction trip to physician

Satisfaction trip from physician




PTA Trip and Usage Data SCOS-Trip and Usage Data City of Columbus Trip to physician start












PTA Trip and Usage Data SCOS Trip and Usage Data Third-Party Users Trip to physician start















PTA Route Optimization API

SCOS Trip Optimization Services

PTA NEMT Transit routing data

Trip booking data

Real time traffic information


Table 14: Multimodal Trip Planning Application Project Data Flow Field Matrix


MMTPA Data Store Incentives MMTPA Loosely defined but along these lines: Get $5 off parking when using COTA as a segment of your trip

System will store rules queried at time cost calculations are done

System will need popup capability that informs traveler of current incentives, maybe when traveler fingers over trip options or at beginning of trip planning

MMTPA Data Store Provider Rules MMTPA Minimum rates

Distance requirements

Pickup/drop-off requirements




MMTPA Data Store Rate Table /Rules MMTPA Route cost

Per-mile /minute cost estimate

Startup cost

Parking cost

Surge pricing/time of day pricing

MMTPA Data Store Trips /Feedback MMTPA Booking history

Trip history

MMTPA Data Store Mobility Asset Location Probability

Route Optimizer Expected availability with timestamp

Actual availability with timestamp

MMTPA Data Store Traffic Stats Route Optimization

Road segment

Time

Average speed

MMTPA Data Store Route Stats Route Optimization

Expected pickup time

Actual pickup time

MMTPA Data Store Route Library Route Optimization

COTA stops (waypoints)

Facilities at the stops (bike racks, TNC pickup points, car-share parking, micro-transit parking)

Route number

Schedule




MMTPA Planning

Data Store Traveler Profile Travelers MMTPA Profile

Average walking speed

Average cycling speed

Preferences (Defaults)

Default price vs. time

Specific routes

Vendor

Mode preferences

Charity

MMTPA Planning

1.1 Message Plan Trip Travelers MMTPA Origin

Destination

Preferences (Temporal)

Price

Time

Vendor

Mode preferences

Route

Charity

Desired time

MMTPA Planning

1.2a Query Preference Constraints Traveler Profile MMTPA Preferences (Default)

Default price vs time

Specific routes

Vendor

Mode preferences

Charity

MMTPA Planning

1.2b Query Route Constraints Provider Rules




MMTPA Planning

1.2c Message Trip Plan and Provide Info MMTPA Route Optimization

Departure and destination location and time

User preferences

Provider constraints

MMTPA Planning

1.3a Message Request Traffic Conditions Route Optimization

Traffic Info Providers

Street speed data by segment (INRIX, Geotab, Waze)

Vehicle position and speed (transportation providers)

MMTPA Planning

1.3b Message Request Vehicle Location Mobility Provider Route Optimization

Vehicle location

Availability

MMTPA Planning

1.3c Query Provide Available Routes Route Library Route Optimization

Origin

Destination

MMTPA Planning

1.3d Query Asset Historical Availability Mobility Asset Location Probability

Route Optimization

MMTPA Planning

1.4a Message Vehicle Location Mobility Provider Route Optimization

This should be real-time stream from the providers

MMTPA Planning

1.4b Message Trip Duration Route Optimization

MMTPA Trips – each trip with a list of segments

Each segment has:

o Start

o End

o Duration

o Provider

o Transfer segment time requirement




MMTPA Planning

1.4c Query On Time History Route Stats Route Optimization

Variance in minutes and seconds

MMTPA Planning

1.4d Query Roadway Historical Speed Traffic Stats Route Optimization

Average speed by segment

MMTPA Planning

1.5 Message Route Options Route Optimization

MMTPA List of available trip options to include:

o Route provider pairing

o Route by segment and time

MMTPA Planning

1.6a Query Rates and Rate Constraints Rate Table/Rules MMTPA Route cost

Per-mile/minute cost estimate

Startup cost

Parking cost

Surge pricing /time of day pricing

MMTPA Planning

1.6b Message Loyalty Status Mobility Providers MMTPA Credits/points available

MMTPA Planning

1.6c Query Incentive Availability Incentive Data Store

MMTPA Incentives that pertain to each transit option provided by RO

MMTPA Planning

1.7 Message Get Credit Amount MMTPA CPS Funds available

MMTPA Planning

1.8 Query Get Available Credit Credit Info/Traveler Account Ledger

CPS Funds available

MMTPA Planning

1.9 Message Available Credit CPS MMTPA Funds available




MMTPA Planning

1.10 Message Available Credit MMTPA Traveler Funds available

MMTPA Booking

2.1 Message Provide Options MMTPA Travelers List of route options

MMTPA Booking

2.2a Save Data Post Booking MMTPA User History Origin

Destination

List of segments with provider info and cost

Booking time

Trip time

Incentives?

MMTPA Booking

2.2b Message Booking Request MMTPA CPS Account ID

For each vendor: vendor info, amount

Trip summary

Trip ID

MMTPA Booking

2.3a Save Data Post to Ledger CPS Credit Info/Traveler Account Ledger

Account ID

For each vendor: vendor info, amount

Trip summary

Trip ID

Type: Booking

MMTPA Booking

2.3b Save Data Booking Escrow CPS Payment Broker Mobility provider ID

Amount

Timestamps

Trip ID

MMTPA Booking

2.4 Message Booking Confirmation CPS MMTPA Trip ID

Confirmation number




MMTPA Booking

2.5 Message Booking Confirmation MMTPA Mobility Providers Trip ID

Confirmation number

Trip details

MMTPA Booking

2.6 Save Data Post Info Mobility Providers Traveler Loyalty Profile

Trip ID

Trip details

Reward points

MMTPA Booking

2.7 Message Booking Confirmation MMTPA Travelers Trip ID

Confirmation number

Trip details

MMTPA Execution

3.1 Message Detect Segment Started MMTPA Traveler Position relative to planned position

Detect speed relative to planned speed

MMTPA Execution

3.2 Message Segment Started Confirmation Travelers MMTPA Popup confirmation

MMTPA Execution

3.3 Message Update Trip MTPA Rout Optimization Real time route speed/duration prediction

MMTPA Execution

3.4a Message Update Traffic Info Route Optimization

Traffic Info Providers

Continuous stream that provides real time data by road segment

MMTPA Execution

3.4b Message Request Vehicle Location Route Optimization

Mobility Providers TNC availability

Micro-transit asset position

MMTPA Execution

3.5a Message Updated Traffic Info Traffic Info Providers

Route Optimization

Continuous feed

MMTPA Execution

3.5b Message Vehicle Location Mobility Providers Route Optimization

Continuous feed planned versus actual




MMTPA Execution

3.6 Message Trip Updates Route Optimization

MMTPA Continuous feed

MMTPA Execution

3.7 Message Trip Progress MMTPA Travelers Continuous feed planned versus actual

MMTPA Execution

3.8 Message Detect Segment Completion/Feedback

MMTPA Travelers GPS speed vs planned

GPS position vs planned

Quick feedback popup

MMTPA Execution

3.9 Message Completion/Provide Feedback/Tip

Travelers MMTPA Validate segment complete

Rate the segment

MMTPA Execution

3.10 Message Pay Provider/Tip MMTPA CPS Check funds available for tip

Release escrowed funds for segment

MMTPA Execution

3.11 Message Release Funds CPS Payment Broker Release funds for segment

MMTPA Execution

3.12 Message Transfer Funds Payment Broker Mobility Providers Transfer Funds


Table 15: Event Parking Management Project Data Flow Field Matrix


EPM 1 Message Parking Information City Parking Meter System

OS Meter Activity

Meter ID

Fare

Payment type

Meter rules




EPM 1.1 Message Parking Information OS EPM Central System

City meter value/time add command

City meter availability

EPM Central System

OS Parking location

Reservation

Payment

Availability at location

Probe vehicle data




Table 16: Mobility Assistance for People with Cognitive Disabilities Project Flow Field Matrix


Mobility Assistance

1.1 Message Trip Details Wayfinder Mobility Management System

Trip ID

User ID

Title

Route downloaded

Start time

Complete time

Cancel time

Assistance requested

Caregiver requested

Battery level

GPS accuracy

Route type

Cell network coverage

Trip paused

Trip resumed

GPS signal loss

GPS signal reacquired

Off route time

Off route LAT

Off route long

Return route time

Return route LAT

Return route long

Mobility Assistance

1.2 Message Trip Details Mobility Management System

Smart Columbus Operating System

Same fields are passed through to SCOS




Table 17: Connected Electric Autonomous Vehicles Project Data Flow Field Matrix


CEAV Message Route Information COTA MMTPA and Operating System

Route

Current location

CEAV Message Route Information CEAV Management System

MMTPA and Operating System

CEAV route

Current location

CEAV Message Roadway Information CEAV Management System

CEAV Roadway conditions/closures

CEAV Message Weather Information CEAV Management System

CEAV Weather Forecast

CEAV Message Route Information MMTPA CEAV Passenger CEAV and vehicle route and current location

CEAV Message Route Information CEAV CEAV Passenger CEAV route and current location

CEAV Message Travel Information CEAV Passenger Operations Staff Travel questions and information

CEAV Message Passenger Travel Information CEAV CEAV Passenger Boarding and alighting

CEAV Message Application Status CEAV Management System

CEAV CEAV status/override

CEAV Message Application Status Operations Staff CEAV Drive/override

CEAV Message Connected Vehicle and Infrastructure Communication

Transportation Network (CVE and Connected Infrastructure)

CEAV Detection

CEAV Message Connected Vehicle and Infrastructure Communication

CEAV Transportation Network (CVE and Connected Infrastructure

Messages to CVE (guided by CVE)




CEAV Message Facility Activation CEAV CEAV Charging and Maintenance Facility

Activate facility

Open/close door

Active automatic charger

CEAV Message CEAV Activity OS City User CEAV Activity Metrics

CEAV Message CEAV Activity OS 3rd Party User CEAV Activity

CEAV Message CEAV Activity CEAV Management System

OS CEAV Activity

Ridership (APC data)

Miles traveled (from AVL data)

Electric charge used

Number of time human operator intervened

Record of other notable events


Table 18: Smart Mobility Hub Project Data Flow Field Matrix


MMTPA Trip Planning/Requests/Bookings

1 Message Trip Planning/Requests/Bookings

Traveler SMH Refer to MMTPA data field column

MMTPA Trip Planning/Requests/Bookings

1.1 Message Trip Planning/Requests/Bookings

SMH MMTPA Refer to MMTPA data field column

SMH Emergency Call Button 2 Message Emergency Call Information SMH Emergency Responders and Operating System

Timestamp of call

Location of SMH from which the call is made