Contact Tracing Integration Platform Specification - Proposed use cases and integrations
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Contact Tracing Integration Platform Specification Proposed use cases and integrations Published 21 May 2020 Released 2020 health.govt.nz
Citation: Ministry of Health. 2020. COVID-19 Contact Tracing Integration Platform
Specification. Wellington: Ministry of Health.
Published 21 May 2020 by the Ministry of Health
PO Box 5013, Wellington 6140, New Zealand
ISBN 978-1-98-859792-8 (online)
HP 7402
This document is available at health.govt.nz
This work is licensed under the Creative Commons Attribution 4.0 International licence.
In essence, you are free to: share ie, copy and redistribute the material in any medium or
format; adapt ie, remix, transform and build upon the material. You must give
appropriate credit, provide a link to the licence and indicate if changes were made.Contents
1 Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 Definitions 1
1.4 Reference documents 2
1.5 Revision history 2
2 Background 3
2.1 Contact tracing process 3
2.2 Integration 3
2.3 Data collection principles 3
3 Use cases 5
3.1 Visited locations 5
4 Potential integrations 7
4.1 Subscribe to exposure events of interest notifications 7
4.2 Publish data about a user’s visited locations 8
4.3 Publish data about recorded check-ins to a business 8
[TITLE] iii1 Introduction
This discussion document outlines the Ministry of Health’s intended strategy for
allowing third party developers to provide data and high-level integration with the
National Contact Tracing Solution (NCTS).
1.1 Purpose
This document has been produced as part of the COVID-19 epidemic response in New
Zealand.
The contents of this document are to serve as a basis for discussion with select industry
partners to determine the feasibility, approach, and utility of a Contact Tracing
Integration Platform.
The views expressed in this document are in draft stage only, and no commitment is
being made by the Ministry of Health on the use cases or potential integration options
outlined within.
Any proposed APIs are conceptual only, and are subject to a detailed design,
architectural, and security review in line with standard Ministry technology governance.
The approaches in this document have not been subjected to formal clinical review.
1.2 Scope
This document covers a range of options for allowing developers of third-party
technology and services to provide data that may support contact tracing.
1.3 Definitions
Contact tracing is the process used by public health units and the national close
contact service to track down people who may have been exposed to COVID-19
through contact with a suspect, confirmed or probable case during that person’s
infectious period.
Close contact means a person who has been exposed to a suspect, confirmed or
probable case of COVID-19 during the infectious period, without personal protective
equipment.
Casual contact refers to any person with exposure to a suspect, confirmed or probable
case who does not meet the criteria for a close contact.
COVID-19 CONTACT TRACING INTEGRATION PLATFORM SPECIFICATION 1Exposure event means a place and time where there was a potential exposure of a
close contact to a person who has tested positive to COVID-19
Exposure event of interest means an exposure event that contact tracers are seeking
to collect more information about through a technology integration with contact
tracing applications
1.4 Reference documents
Contact Tracing App Privacy Impact Assessment
HISO 10085:2020 COVID-19 Contact Tracing Data Standard
COVID-19 Contact Tracing QR Code Specification
1.5 Revision history
21 May 2020 Published as draft specification
2 COVID-19 CONTACT TRACING INTEGRATION PLATFORM SPECIFICATION2 Background
In New Zealand, a nationwide state of emergency was imposed in response to the
COVID-19 pandemic. Contact tracing is one of the pillars of the public health response
to COVID-19, along with border control, testing and case isolation. A comprehensive
contact tracing system will enable rapid identification and isolation of new cases and is
central to breaking the chain of transmission and eliminating COVID-19.
2.1 Contact tracing process
Contact tracing starts with a phone call from the public health unit or national close
contact service. The person is provided with advice on self-isolation and their health
and wellbeing is checked. The person receives daily follow up calls during the isolation
period.
Key to contact tracing is getting information about the contacts of persons with
COVID-19 to identify the source of the infection and make close contacts aware of the
risk and the need to get tested and self-isolate.
2.2 Integration
The Ministry recognises that a number of third-party solutions will be developed to
support contact tracing, and the benefit that an ecosystem of solutions can bring to
improving the contact tracing process.
This benefit needs to be carefully balanced with privacy and consent requirements,
data security and integrity of any integrations, and overall clinical utility in collecting
the information.
While the Ministry is developing first-party consumer digital solutions to support
contact tracing, these are not intended to be the only solutions, nor does the Ministry
expect the first-party solutions will meet the needs of everyone in New Zealand.
As such, the Ministry is open to exploring ways for developers of third-party solutions
to securely contribute the data they have collected.
2.3 Data collection principles
The Ministry’s stance on data collection to support contact tracing is that data
collection should be minimised as much as possible. The Health Information Privacy
Code (1994) sets out rules around the collection and storage of health information.
COVID-19 CONTACT TRACING INTEGRATION PLATFORM SPECIFICATION 3The reason the Health Information Privacy Code is important is because some
information collected will become health information during this process. For example,
information collected on a contact tracing register becomes health information when a
person in the register tests positive.
This stance also means the Ministry will not create a central database of the public’s
movements and close contacts. This information would only be collected from people
who have, for example, tested positive, are a suspected close contact, or a suspected
casual contact.
4 COVID-19 CONTACT TRACING INTEGRATION PLATFORM SPECIFICATION3 Use cases
The Ministry has identified the following use cases for interoperability with third party
technology solutions that could contribute data to support contact tracing.
3.1 Visited locations
This capability is broken into two buckets, depending on the model used to capture
the data, and where it is stored.
3.1.1 Potential benefits to integration
The following known opportunities for data to improve the contact tracing process
related to visited locations are:
1. improving the speed that contact tracers can obtain information about potential
close contacts at a location where there is a high transmission risk
2. improving the speed at which a notification to a potential close contact can be
sent, advising them to self-isolate if required
3. improving the accessibility of current contact details for a business or location,
meaning a contact tracer can contact a business quicker
4. reducing the risk of transmission by visitors needing to share a ‘dirty pen’ to sign a
paper-based register
5. reducing the risk of personal information being disclosed to unauthorised staff or
other customers (ie, reading other people’s information off a paper register)
6. in a decentralised model, giving the customer control over their own information,
where it is only disclosed to contact tracers if they test positive, and to nobody
else.
3.1.2 Assumptions
The following assumptions have been made for this use case.
1. Any recorded locations are identified by a Global Location Number (GLN).
2. A location without a GLN has less value to the contact tracing process, as it is not
linked to the current information available on the NZBN.
3.1.3 Centralised models
In this model, when a user ‘checks-in’ to a location the record of that check-in is stored
in a central database, accessible by a central authority who would be responsible for
sharing that data on behalf of the place that captured it.
This model is most closely aligned to a traditional paper register, where a customer
signs a physical piece of paper with their name, phone number, and other details.
COVID-19 CONTACT TRACING INTEGRATION PLATFORM SPECIFICATION 5This is the most commonly seen third party solution to date, and relies on the business
to provide that information to a contact tracer.
Typically these solutions provide less privacy to an end user, but are potentially more
robust for the contact tracing process as it is easy to view everyone that was at a
location at a given time (assuming the records are complete and accurate).
3.1.4 Decentralised models
In this model a user’s visited locations are stored on their device, and the user remains
in control of their data. No requests are made to a central server when a scan is made,
so there is no way to track an individual user’s movements.
This model has a much better privacy posture as it avoids the risk of a bad actor
accessing the central database of visits. This is the model the Ministry is pursuing for its
first-party solution.
However, this model relies on users to be forthcoming if they are notified of a potential
exposure, as it is not possible to know how many people are potentially affected, or
otherwise contact them if they don’t respond.
6 COVID-19 CONTACT TRACING INTEGRATION PLATFORM SPECIFICATION4 Potential
integrations
Based on the above assumptions, benefits, and models, the Ministry has identified the
following options for integration with third party solutions. Note these options are still
being validated and no commitment is made at this stage around when these
integrations will be available, if at all.
However, if developers would like their solutions to integrate with the Ministry and
meet the needs of contact tracing, they should be aware of the data structures and
patterns outlined here.
4.1 Subscribe to exposure events
of interest notifications
This feed would allow authorised developers to receive a list of exposure events of
interest, which they may respond to by providing any matching data. An exposure
event of interest will contain a GLN location, a start timestamp, and an end timestamp.
Subscribers are able to evaluate their owned datasets to determine if any check-ins
between the start timestamp and end timestamp are present.
This would be available as a push mechanism (eg, a webhook), or a polling mechanism
(eg, an API endpoint) that would return a list of exposure notifications, including the
following data.
• The GLN for the location of the exposure event. At this stage only locations that
have a corresponding GLN will be able to be published through this channel.
• The start date and time and the end date and time of when the exposure event is
targeting.
• Additional information, such as risk factor, commentary, and action required, may
also be included depending on the risk.
Any subscribing service that has access to this feed will need the ability to match
locations based on the GLN. This implies that a service allowing businesses to register
should ask businesses to provide relevant GLNs as a mandatory field, so it can be used
later.
COVID-19 CONTACT TRACING INTEGRATION PLATFORM SPECIFICATION 74.2 Publish data about a user’s
visited locations
This endpoint would accept a list of a user’s visited locations. This is useful when an
individual user wants to share their recorded locations. This could be sent
automatically in response to a notification received about an exposure event, with
consent of the user.
This would be exposed as an API endpoint that accepts the following data:
• the GLN of the scanned location, which is recommended but not required
• the date and time when the user ‘checked-in’, required
• the date and time when the user checked-out’, required
• if a GLN is not provided, information about the location that is meaningful for a
contact tracer must be provided. This may include the name of the business or
location, the physical street address and the type of location (café, retail, public
space, etc).
4.3 Publish data about recorded
check-ins to a business
This endpoint would accept a list of recorded check-ins from customers within a
specific time window. Useful in the event an exposure event has been identified at that
business and close contacts are being sought by contact tracers. This could be sent
automatically in response to a notification received about an exposure event, with
consent of the business.
This would be exposed as an API endpoint that accepts the following data:
• the name and phone number of the person at minimum
• the date and time the person checked in
• if available, the date and time they checked out
The information captured on an individual must align to the data standards outlined in
HISO 10085:2020 COVID-19 Contact Tracing Data Standard.
8 COVID-19 CONTACT TRACING INTEGRATION PLATFORM SPECIFICATIONYou can also read
