question archive Conceptual Design Commercial Airlines COVID-19 Contact Tracing App   Problem: With the COVID-19 pandemic spreading across most of the world, air travel can accelerate virus transmission between distant locations

Conceptual Design Commercial Airlines COVID-19 Contact Tracing App   Problem: With the COVID-19 pandemic spreading across most of the world, air travel can accelerate virus transmission between distant locations

Subject:Computer SciencePrice: Bought3

Conceptual Design

Commercial Airlines COVID-19 Contact Tracing App

 

Problem: With the COVID-19 pandemic spreading across most of the world, air travel can accelerate virus transmission between distant locations. However, technologies can help slow the spread. One approach to control the spread is by applying technology solutions to the area of contact tracing for airline use. This brings several benefits, but also has key privacy challenges. Collecting airline passenger data for this purpose requires personal and sensitive information subject to European privacy laws; in particular, the GDPR. Collected privacy data requires specific handling and processing requirements throughout the lifecycle. This paper addresses the development of a contact tracing app for airline passengers using privacy by design principles.

Overview. As we design our application, we follow privacy by design principles. These include proactive measures, privacy by default, purpose specifications, data minimization, end-to-end security, consent, access, risks and controls, and other PbD principles. These are discussed in detail below.

Purpose. The purpose of developing an application for contact tracing on flights between the EU and the US is to provide healthcare professionals with additional benefits vs. the traditional, manual contact tracing approach. These benefits include: 1) Speed: an application can offer faster contact/ proximity identification vs. a manual process; 2) Accuracy: an application can offer improved accuracy over a manual method, as it may have the ability to cover person-to-person interactions that a human may not recall; 3) Flexibility: an application can overcome language barriers and cultural norms that may complicate manual methods. 4) Efficiency: an application may also be able to work through the legal barriers and privacy laws in advance, and can be updated quickly as laws change.

Data elements to be collected. The following passenger contact tracing data elements have been grouped into several major groups: passenger data, flight basics, and proximity data (both pre-boarding and in-flight).

A. Passenger descriptor information: Name, contact information, passenger pre-screening health status (T/F) prior to boarding – part of the process to ensure obviously sick / symptomatic passengers do not board.

B. Data relating to flight basics – this data provides a coarse level of information on particular passengers, to confirm who was on the flight. This can be accomplished outside of a tracing app, as a normal part of the flight manifest for airlines.

· Flight origin & Destination country / city / airport

· Flight #, date / time of departure

C. Data relating to location proximity to other passengers - this data provides a more granular level of detail on passenger movements prior to and during flight. The data would include:

1. Pre-boarding data (note that some of this data is also obtained outside of a tracing app, part of the airline's normal data gathering):

· Timestamp of arrival time at gate (possible through Wi-Fi check-in or other method). Used to determine duration at gate prior to boarding

· Boarding group (for pre-boarding proximity)

· Timestamp of boarding – for proximity in line / jetway

2. In-flight data (this data comprises the time the passenger enters the aircraft to the time they exit the plane)

· passenger assigned / actual seat location (actual in case of change during boarding / flight)

· aircraft type and seating layout

· passenger movement in-flight (e.g., lavatory use, aisle movements) – this data element is one of the few that is not already known by the airline, and provides the most specific proximity information, but is also the most sensitive)

With the above elements, airlines will be able to quickly identify passengers in close proximity to a target passenger that may develop symptoms post-flight.

Data classification. We classify the above data elements into the following categories to separate privacy-related information:

Personal Information: This would include the passenger’s name, address, phone number, family members traveling with them, emergency contact info, and potentially proximity information in flight or in the lounge, if not anonymized. If destination contact info is different than phone #, then that information would also be considered in this category.

Sensitive personal information: This includes passport number, and any health information collected at check-in (screening answers).

Non-personal information: This would include flight number, departure / arrival airports, boarding group, aircraft type and seating layout, gate check-in times, and boarding time.

Data retention. While the GDPR does not specify retention periods, it states that data retention should be no longer than necessary for the purposes it was needed. For our contract tracing, this is a short time. Since symptoms typically occur within 14 days of exposure, and there may be a lag in passengers reporting symptoms associated with COVID, a period of 30-45 days seems reasonable to collect post-travel data, notify any affected parties, and possibly anonymize data for health research purposes. After this time, data should be deleted by the app in all databases.

Consent. In the GDPR laws, obtaining user consent is not mandatory. It is one of six legal bases in Article 6 that can be used by business in processing user data (Wolford). Related to COVID data, other legal bases that could apply are:

· (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person;

· (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;

However, while either of these could be used as a basis to collect and process passenger data for our contact tracing application, it may be better to follow privacy by design principles to obtain consent from passengers, as well as from an airline public relations standpoint. In this case, we must follow the guideline that consent is “freely given”. We can’t restrict a passenger from flying if they choose to decline consent. Consent must also be specific, informed, unambiguous, and able to be revoked.

Given this, our mobile application will provide a privacy notification describing what data we collect and how we will use it, have a user-prompted method of consenting to use, and be granular in consenting to each part of the data collected.

To make this application successful, we will need a way of both identifying and contacting a person post-flight. The user’s cell phone number is a good way to do both. So, we need to get consent for use of the user’s phone number and agreement to contact them via this number as a follow-up.

With this background, we will design a prompt screen that displays after the user launches the app, displaying the privacy notice, and requesting that they proactively provide consent for us to collect their phone number, track their location before and during flight, and contact them post-flight if necessary. We will ask them to positively affirm that we can link their data to the flight information database for proximity location processing. We will provide a clear, unambiguous description of the data needed, and how we will use it, and when we will delete it. This may be on one or two successive screens. The ability to review the privacy notification at a later date will be accessible from the main menu of the application, as well as an option to revoke consent at some later date.

Process to Update and Delete. In the GDPR, there are two rights that apply here. The first is the right to rectification, whereby a passenger can request that inaccurate or incomplete personal data be updated. This request can either be verbally or in writing. We must respond within one month of receipt of the request, at the latest. The second right that applies is the right to erasure, giving passengers the right to have personal data deleted. The same timing applies as above.

So, with this background, we have a few options in how we support these requirements. We will need to document a process to ensure we collect the necessary request data, and also to document that we completed the request. One option is to include a menu item in the app with a phone # to call to request information to be updated or deleted. This will necessitate standing up a call center with agents trained to handle these requests. This will require agent script development, a confirmation process, escalation options, and related mechanisms associated with call center information processing.

A second and better option is to use the app to directly facilitate the request. The app can be used to access the related data and present it to the passenger, in an editable format to allow the passenger to update their own data, or delete specific parts. Since our app uses encryption in both the app’s storage and transmission, we can be confident that this method will sufficiently protect the data. By allowing the app to query the specific passenger’s information from a secure database in the cloud, we can have fast and accurate results. We will need to log the request, including time of request (start / end), method used (app, or possibly web), and the data elements changed or deleted, without including the specific data changed. This will be useful for follow-up purposes. The app can also trigger a change / delete confirmation e-mail to provide the passenger with assurance that the request was received and processed.

Applicable Laws. Our contact tracing app must comply with applicable privacy laws. In our case, the EU’s GDPR is a primary law in protecting European traveler’s privacy data. As a data controller, we pay close attention to GDPR Articles 24 through 43, as these are focused on the controller and processor. However, many other articles of the GDPR also apply, as described above. As far as U.S. laws, as a private company, we would not be subject to HIPAA laws per se, but since we may be storing health-related data, it is wise to protect the collected data both in motion and at rest.

Privacy Risk. Like any data processor, we are subject to the risk of data breaches, through either intentional or unintentional acts. To limit the damage of any breach, we need to encrypt any stored data, and also apply best practices in data protection (multi-factor access controls, boundary protection, host protections, etc.), and also destroy data after it is no longer useful. The risks of a breach will affect not only our company, as the app developer, but also our airline customers. There is reputational damage risk, as well as financial risk of notifications, potential liabilities, and related (Strawbridge, 2020). Regarding notification requirements in the case of any data breaches, we would be governed not only by the GDPR requirements, but also by U.S. State law in the place of our primary location.

Controls. We will apply controls from each of the three safeguard categories: Administrative, Physical, and Technical. Administrative controls for our app will include a policy for auto-deletion of the data as soon as it is no longer useful, within 30 days or less of receiving it / date of travel. We will publish a privacy policy that will be available both at app initialization and from within the app for on-demand reading. We will have an incident management plan to address any incidents that may arise with the app or data. We will have a policy of data updating and deleting, and also have policies for our workforce on appropriate use of this data.

Technical controls for our app include the following: on the user side, we will use the customer’s phone security mechanisms for access control, including biometrics for access to the app. Between the customer’s phone and our cloud-based back-end, we will encrypt the data in transit, and also encrypt it in the cloud. Access controls for the database in the cloud will follow cloud best practices of identity and access management, PKI, and similar practices. We will employ cybersecurity monitoring tools to detect and prevent intrusions into our systems, and data loss prevention tools to minimize data leakage.

Physical controls for our app are primarily provided by the cloud service provider that we are using to host the compute, database and storage systems to support the contact tracing. These include physical barriers and access controls to the data centers housing our contact tracing systems, perimeter barriers and monitoring, security guard monitoring, and similar safeguards.

By implementing safeguards across all three categories, we are able to mitigate risks to the passenger contact tracing data.

 

 

Conclusion: Airline passengers can be re-assured that our app has incorporated privacy by design principles throughout. By including proactive measures, privacy by default, purpose specifications, data minimization, end-to-end security, consent, and access, among others, we have a well-designed contact tracing application that is compliant with the EU GDPR, and helps fight the spread of COVID-19.

pur-new-sol

Purchase A New Answer

Custom new solution created by our subject matter experts

GET A QUOTE