Privacy Impact Assessment - Ministry of Health My Health Account Minimum Viable Product (MVP) - Ministry of Health NZ
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Ministry of Health
My Health Account Minimum Viable Product (MVP)
Privacy Impact Assessment
Date 5 August 2021
The author of this document is Data & Digital Directorate, Ministry of Health.
Disclaimer
This Assessment has been prepared to assist the Ministry of Health (“the Ministry”) to review the purposes for
which the information collected for the establishment of each Consumer’s My Health account can be used, and
the privacy safeguards that are required to manage those purposes.
Every effort has been made to ensure that the information contained in this report is reliable and up to date. This
Privacy Impact Assessment represents the current expectations of the way My Health account MVP services will
operate.
This Assessment is intended to be a ‘work in progress’ and may be amended from time to time as circumstances
change or new information is proposed to be collected and used.
Assumptions applied
The assumptions that have been applied in the development of this assessment include:
o As this project develops, there will be evidence and information generated through the development and
deployment of the application (e.g. Statistics of use and feedback from users) that will impact on how the
Ministry of Health determines what is important for the future purpose of this application. These may result in
changes to the terms of use, the information collected, and the risks and mitigations required.
o Discussions will continue between key parties (i.e. the Ministry of Health and the Office of the Privacy
Commissioner in the first instance, also, the Government Chief Privacy Officer and the Privacy Foundation)
and future versions of this assessment will record changes to information that is collected and the
consequent risks, further analysis and mitigations.
o This version of the Privacy Impact Assessment will be made publicly available for the public to understand
the collection, storage, use and sharing of personal and third-party information for purposes of transparency.
Privacy Impact Assessment – Draft 1.0 Page 2
Contents
GLOSSARY 4
SECTION ONE – EXECUTIVE SUMMARY 6
SCOPE OF ASSESSMENT 7
ASSESSMENT CONTENT 8
RECOMMENDATION SUMMARY 8
SECTION TWO – MY HEALTH ACCOUNT 10
BACKGROUND 10
MINIMUM VIABLE PRODUCT 11
THE SIGN UP PROCESS 14
PROJECT CREDIBILITY 18
INFORMATION FIELDS INVOLVED IN THE IDENTIFICATION: 19
RETENTION OF INFORMATION 21
WHERE AND HOW THE INFORMATION WILL BE STORED 23
INFORMATION FLOWS 25
SECURITY FEATURES 26
PRESENTATION OF MY HEALTH INFORMATION TO THIRD PARTIES 26
MANUAL PROCESS IF NHI ISSUES ARISE 26
GOVERNANCE 27
POTENTIAL FEATURES TO BE ADDRESSED IN FUTURE PRIVACY IMPACT ASSESSMENT ACTIVITY 28
SECTION THREE – PRIVACY ANALYSIS 29
APPENDIX ONE - PROCESS FLOWS 34
APPENDIX TWO - LEVELS OF CONFIDENCE 38
APPENDIX THREE – DATA FIELDS FOR MY HEALTH ACCOUNT 41
APPENDIX FOUR – SERVICES AUTHORISED TO USE MY HEALTH ACCOUNT 44
APPENDIX FIVE – DRAFT PRIVACY STATEMENT 45
APPENDIX SIX – CONSUMER TERMS OF USE - DRAFT 51
APPENDIX SEVEN – DRAFT SIGN UP SCREEN FLOWS 54
Page 3 of 59
Glossary
The following are definitions used in this Assessment:
Terms Description, relationship and business rules
Authorised Private An entity authorised to participate as a Service Provider in the
Entity health information sector after completing authorisation processes
established by the Ministry of Health. This includes both providers
of health services and health IT services.
B2C Microsoft Azure B2C
CIAM Consumer Identity Access Management
Cloudcheck This is the electronic identity verification service to be used to verify
an identity document as part of the My Health processes. More
information can be found here:
https://www.verifidentity.com/cloudcheck/
Common Person A unique identifier given to each health practitioner. The CPN is a
Number (CPN) separate identifier given to the practitioner that is different to the
NHI used by them as a health Consumer.
Consumer Each user who registers to use the My Health account services as
their unique Digital Identity
Consumer Terms The terms that the Consumer will accept as part of signing up to
of Use use the My Health account service
COVID Consumer A solution to be provided by the Ministry of Health that enables
Channel (C3) Consumers to book, manage and view the outcome of COVID
related health services such as vaccinations and COVID tests. This
is to be the first use case for the Digital Identity project.
Digital Identity The NHI and other entity information that is bound to the My Health
account used by the Consumer. Informally – an individual’s My
Health account. Non-identity accounts are also available as an
information channel.
Health Information The HISO 10064:2017 Health Information Governance Guidelines
Governance August 2017 http://www.health.govt.nz/our-work/ehealth/digital-
Guidelines (HIGG) health-standards-and-governance/health-information-
standards/health-information-governance-guidelines .
Hira This is a Ministry initiative. It is intended to be the national health
information platform programme, and will be designed to enable
accessibility of health information from many sources and a provide
a range of digital services that make health information easier to
access, use and share (with appropriate controls around privacy
and security).
Microsoft Azure Microsoft Azure Business to Consumer product is the underlying
B2C technology used by My Health account
Page 4 of 59
Terms Description, relationship and business rules
Ministry The Ministry of Health
MIQF Managed Isolation and Quarantine Facility
MVP Minimum viable product, being the initial stage of the My Health
account digital identity service where users can activate their own
account, and verify their identify to different confidence levels of
their choosing.
My Health account The Ministry application to enable Consumers to obtain, and
assert, a digital health identity. In future, it is expected that My
Health account could interact with Hira offerings, and potentially it
may also support third-party party Consumer services with
Consumer opt in consent.
Privacy Notice Material to be prepared to inform Consumers in compliance with
Materials relevant rules in the Health Information Privacy Code 2020,
including rule 3 in particular.
Project The My Health account project
RealMe A Consumer facing digital identity service for government agency
use provided by the Department of Internal Affairs. More
information at https://realme.govt.nz
Service Provider A government agency (including the Ministry of Health) or
Authorised Private Entity that is authorised to use the My Health
account to authenticate Consumers in order to provide services
and / or support health information management by Consumers.
Service Provider The terms that will apply to each Service Provider when allocated
Terms of Use rights to interact with the My Health account services
Page 5 of 59
Section One – Executive Summary
1. The Ministry of Health (the Ministry) aims to enhance its communications with health
Consumers with information via digital channels. It also intends to enable individuals to
have greater access to information about their own health. To implement these digital
services, and enable direct engagement with Consumers, it will be necessary to
accurately identify Consumers. Only the right person should be able to access and
manage information about themselves.
2. To enable these services, the digital identity tool My Health is being developed.
3. This Privacy Impact Assessment reviews the concept for the My Health account, and the
integration with the COVID-19 Consumer Channel (C3) is addressed. C3 itself has been
reviewed in two other separate Privacy Impact Assessments.
4. The My Health account development has completed its MVP release called release 1b
and is currently working on its second release, called release 1c, which is designed
primarily to support the COVID Consumer Channel including:
4.1. Release 1b: This release is now complete and has received an Authority to Operate
(ATO). Features for this release include the ability for a user to create an account
using a unique email address. Any trusted witness processes would be by offline
processes only.
4.2. Release 1c: This is due for completion by the end of July. This release includes:
4.2.1. NHI search and bind using an algorithm similar to Match+1;
4.2.2. support for RealMe verified identity, and
4.2.3. support for the COVID Consumer Channel vaccination and COVID test
results display.
5. The initial use case will be to support the COVID Consumer Channel (C3) to utilise the
My Health account to enable Consumers to view and assert COVID-19 vaccination
status and test results. My Health will perform the identification requirement to link the
right person to the right information.
6. The Ministry will endeavour to minimise any potential privacy risks in its development of
the My Health account, and balance these against the public health benefits of enhanced
Consumer control over access to relevant health records related to them. Consumer
trust is essential if use of My Health account is to become widespread. The Ministry
intends to earn and respect that trust.
1
If there is a unique match on NHI within set parameters, the NHI will be bound. If not, then manual matching will occur.
Page 6 of 59
6.1. The intention of the Ministry is to retain Consumer choice, minimise the collection of
personal information to those matters most directly useful to the unique digital
identification of the Consumers, and limit who will have access to that information2.
6.2. Information about Consumers who choose to use the My Health account Services
will be stored by the New Zealand Ministry of Health, and will not be shared with any
other agencies (Government or otherwise) unless explicit Consumer consent is
obtained or it is authorised by law. Use of information by Service Providers will either
be authorised by Consumers or under legal authority (such as in compliance with
the rules in the Health Information Privacy Code 2020 and other enactments that
require or allow information to be used or disclosed).
7. The Office of the Privacy Commissioner and the Government Chief Privacy Officer have
been consulted and provided comments on a draft Privacy Impact Assessment. The
comments have been considered by the Ministry and incorporated as appropriate.
8. This Privacy Impact Assessment is expected to be a ‘living’ document that will be
reviewed as the Project progresses. The Ministry of Health plans a phased release of
functionality in the My Health account Services, so features available in subsequent
releases will require privacy review.
Scope of Assessment
9. The current Assessment covers:
9.1. The personal, demographic and anonymous3 information to be collected from
the Consumer to create a My Health account.
9.2. The National Health Index (NHI) number obtained from the Ministry of
Health’s National Health Index service which is to be used as an element in
the My Health account process.
9.3. The role of My Health in the C3 project (noting the C3 service is subject to a different
Privacy Impact Assessment).
10. This Assessment does not address:
10.1. any further services My Health account may in future be able to interact with,
as each of these will be addressed in subsequent Privacy Impact Assessment
activity4;
2
The access to the information (generally by Service Providers) will be reviewed in future Privacy Impact Assessment activity.
3
Consumers can choose the level of engagement with the system. At the lowest level of identity assurance (level 1), users can
provide pseudonymous information such as phone number, email address and “names” without the information being verified
with official sources. Users who choose a low level of identity assurance will not have access to sensitive information (e.g.
medical records) without successfully providing more evidence of identity.
4
Future releases of My Health account will also assess the privacy impact of including the Common Person Number (CPN) of
health practitioners who have an account.
Page 7 of 59
10.2. the decision-making process, approvals, nor the conclusions reached about
the decision to create the My Health account services.
11. It is instead focused on the collection, storage, use and sharing of personal information
for the purposes of providing My Health authentication and identity assertion services.
Full purposes for potential use of the My Health account will be evolving and will be
addressed in additional Privacy Impact Assessment activity as this matter progresses.
Assessment content
12. Section Two contains the Description of the Project and User/Information Flows.
13. Section Three contains the Privacy Analysis.
Recommendation Summary
14. The Ministry will identify and mitigate privacy risks associated with this Project, prior to
collecting, storing, using and sharing this personal and contact information, and prior to
the release of additional functionality.
15. My Health account will be a voluntary identity tool, enabling individuals to opt in to having
access to, and some control over, their personal health information as Consumers.
Individual Consumers can choose the level of confidence they wish to apply to their
account.
15.1. My Health account will be a ‘doorway’ to C3 and other future services. Careful
oversight of the project will be applied to address how controls are managed
within other services, and how Consumer control can be retained from within
the My Health account.
15.2. There is a danger of function creep if other services / access or authorities
are enabled that are not directly subject to easily manageable Consumer
control within the My Health account.
15.3. Social licence and governance oversight will be key to successful
management of privacy risks associated with the My Health account.
16. The Ministry will work to ensure it obtains, and then maintains, Consumer trust in its
operation of My Health and related services.
Page 8 of 59
Release 1c recommendations:
17. The following are areas that it is recommended that the Ministry concentrate on as it
develops Release 1c of this My Health project:
Release 1c Planned Date for
completion
My Health – Second Privacy Assessment (IPA)
IPA-01 Complete any Ministry security assessment requirements including Prior to go live
Certification and Authorisation, and independent security testing.
Security has been approved for Release 1b (Approval to Operate) –
and will be for 1c before go live. The pen testing is finished as is the
independent audit report
If any risks are identified they will be resolved or mitigated to ensure
appropriate security will be applied to all aspects of the project.
It is important that such security is applied across the end-to-end
services available via the My Health account to maintain trust in the
service, as it is a gateway to those other services. Consumers can
reasonably expect that the Ministry will maintain oversight of all
interconnected services, and not offer them unless assured of
security. These matters however will be potentially outside the direct
control of the My Health account project so connections must remain
strong with other interconnected projects, such as Hira.
IPA-02 Clear Privacy Statement Materials to be developed and made To be finalised
available via the My Health Account. Current draft attached in prior to go live
Appendix Five.
This Statement will incorporate reference to linked services permitted
to participate with the My Health digital identity
The Privacy Notice Materials must be able to be disseminated to
Consumers and Service Providers prior to any new release of
information, or changes to use conditions. Consideration will be given
to determine how a Consumer could opt out of new services, or
existing services, at any point. This would also require consideration
of the status of information already held. These matters should be
factored in for each new service that may be associated with the My
Health account.
IPA- 03 Any linked services must incorporate a relevant Privacy Statement for To be finalised
those services as part of the Consumer onboarding processes prior to go live
IPA-04 Implement Terms of Use for Consumers (to reinforce the important of To be finalised
Consumers taking care of their digital identity and the responsibilities prior to go live
of both the Ministry and the Consumer). Current draft attached in
Appendix Six.
IPA-05 Service Providers permitted to interact with the My Health account Prior to service
must also be bound to appropriate Terms of Use that confirms the providers being
permitted purposes for use of the information accessed, to ensure permitted to
they are clear about expectations for use, and limitations on use of interact with My
this personal information Health
IPA-06 Strong governance will need to be maintained over both My Health Prior to go live in
and connected services to ensure adequate oversight of operations respect of any
services being
connected to My
Health
Page 9 of 59
Section Two – My Health account
Background
1. The Ministry intends to give all Consumers of New Zealand health services the ability to
view and digitally manage their own, and their dependents, health records
2. The Ministry of Health Digital Health Strategic Framework5 objectives include the
following:
2.1. People are in control of their own health information
2.2. Digital services and health information improve health outcomes and equity
2.3. Digital services enable health providers to delivery better services
2.4. Digital services increase the performance of the public health system
2.5. Data insights provide evidence to make and support informed decisions
3. Previously the Ministry drove the initiative for GP Practices to provide patient portals, to
enable patients to have access to their own heath information. This initiative resulted in
the establishment of multiple private services like Manage My Health, ConnectMed,
Health365, Myindici, and more recently, a number of Telehealth consult and
ePrescription applications. A key limitation with the private applications presently is they
are not directly interoperable in many instances and do not give access to records and
services digitally from publicly funded health providers such as District Health Boards.
4. The Project is to provide a Digital Identity solution that Consumers will select as their
preferred system so that they are able to access a greater range of their own health
records and are in control of aspects of their own health records. My Health account is to
be the digital identity component of this Project.
5. This Privacy Impact Assessment is the second in relation to the My Health Project. It
covers the Minimum Viable Product (MVP) and the release 1c stages of Project
development. This includes:
5.1. the development of the voluntary digital identity tool: the My Health account, and the
inherent levels of confidence that can be achieved with the use of this tool,
5.2. the support for RealMe as a way to easily reach Level 3 confidence; and
5.3. support for the COVID Consumer Channel (C3). C3 has its own Privacy Impact
Assessment which dovetails with this one.
5
https://www.health.govt.nz/our-work/digital-health/digital-health-strategic-framework
Page 10 of 59Minimum Viable Product
6. The Digital Identity Project’s Minimum Viable Product (MVP) intends to establish a
Consumer Identity and Access Management (CIAM) service. An example of a CIAM
service is set out below:
7. The Ministry needs to ensure this digital identity is trusted by both Consumers and
Service Providers. This digital identity service will be called My Health account.
8. This identity will allow people to prove who they are to digital Service Providers. Level
3N verified users will also be linked to their NHI6 number to enable access to health data
where that is authorised in future. But before My Health account can be used by
Consumers, their identity must be validated.
9. This validation process requires several steps, and the confidence level increases with
each step of validation. Details of the planned confidence levels are set out in Appendix
Two. Each Consumer (at a given point in time) has a level of confidence that the person
behind the screen is ‘who they say they are’. The different levels of confidence will
enable use cases that require lower levels of confidence (for example booking an
appointment at level 2N) or higher levels of confidence (for example viewing highly
sensitive personal health records at Level 3N).
10. The following diagram indicates the existing Consumer authentication processes on the
left-hand side, and the proposed account creation process using My Health account on
the right. The benefit of My Health account is that the account is created only once and
can be used over and over for online and offline transactions.
6
CPN will be added at a later time
Page 11 of 594. patient
proves
claim
of identity
attributes
Patient Patient
1. Obtain patient 1. Binding
3. Patient Bound to NHI Create an Account and
Details (e.g. Name, DOB) Entity Information
For this transaction Prove control over it Claim: ID
Document
2. Claim a person s
attributes e.g. Name, DOB
2. Check against NHI 3. Claim an NHI based
on those attributes
5. Registration –
Bind NHI to Account
Authenticator: NHI Service
MyHealthAccount NHI Service
Provider 6. Authentication
6. Trust for digital services
Policy & Planners
Innovators Providers
Consumers
Most Health Transactions - for each
transaction:
1. Provider asks for patient details e.g. 3rd Party Ecosystem Services& Tools
name, DOB, address, GP, etc. national
2. Provider checks details against NHI Health
(including copy of NHI e.g. a label) Information
Platform
3. If successful, the patient is bound to Relying Party: National
the NHI for this transaction (e.g. GP visit, Provider Solutions
Social
Secondary
Wellness
Primary
Consumer
Other
Data Data Data
blood draw, observations, etc). Data Sources
The process is repeated for the next
Why MyHealthAccount – Create account Once only
transaction which is one reason patient
1. Patient registers for an account.
quickly get tired of giving their name
2. Person claims an identity by checking e.g. drivers
and DOB
licence or passport details.
3. Person is then matched to the NHI using the identity
details.
4. The person proves they own the identity (this liveness
check stops others from claiming your identity)
5. NHI is registered to the MyHealthAccount.
Reuse MyHealthAccount over and over online and offline
6. MyHealthAccount enables services and consumers to
authenticate consumers and providers online and offline.
11. Health services will continue to be provided regardless of whether or not a person has a
My Health account.
12. The Ministry has taken an approach informed by the work done for the development of
Hira. The Ministry will be transparent with the use of the data, in order to maintain and
grow social license. The Ministry will follow these principles:
• The information collected will be voluntarily provided by the Consumer
• Information collected will be secured and shared only with those who need to know.
• Only the minimal information that is needed will be collected.
• Information used temporarily (e.g. for identity verification) will be deleted once the
purpose has been completed.
• In future releases, the Consumer will be able to consent or withdraw consent for the
My Health account to be used for participating services.
Page 12 of 5913. In the MVP, the key focus is on asking Consumers to create an account in order to
volunteer their details to the Ministry of Health, for the purposes of creating their unique
Digital Identity: the My Health account.
14. Release 1c of My Health Account expands the MVP by supporting RealMe accounts,
improving the NHI searching and matching algorithm and by supporting the C3
Application. C3 has its own separate Privacy Impact Assessment. C3 will be the main
channel by which Consumers will create a My Health Account.
15. Additional services the My Health account may provide access to will be addressed as
future development progresses (including Hira development) and will be addressed in
future privacy impact assessment activity.
16. Once My Health account is established, it is expected that it will also be used to support
the Hira digital enablement programme that the Ministry is currently in the process of
developing.
16.1. Hira aims to empower Consumers and their carers to become more active in
managing their health, and will be designed to bring data together and make it
trusted and accessible.
16.2. The Ministry intends to give all Consumers of NZ health services the ability to
view and digitally manage their own, and their dependents, health records.
My Health account will also be the key enabler for the Hira digital enablement
programme.
16.3. The Ministry’s Hira initiative intends the My Health account to provide an
identity confirmation tool to enable secure sharing of health records real-time
and in a modern, standardised manner. It will be available by both webform
and App.
16.4. The My Health account application will provide each Consumer with the
option of obtaining a unique and unified Digital Identity to support Consumers
to exercise choice, and some control of their own health records.
17. The approach the Ministry has taken is to make My Health account as easy as possible
for Consumers to sign up and provide their information. Consumers will visit the website
(that works with both mobile and desktop devices) primarily from the new COVID
Consumer Channel (currently under development) but also from the Ministry of Health
website.
18. If they choose to sign up they will see the Privacy Statement and agree to Consumer
Terms of Use prior to signing up. The process flows are set out in the diagrams in
Appendix One.
19. The Ministry has identified three key sets of information using the principles above:
• Personal contact details – Consumers providing this information to My Health
account will validate that the Digital Identity created is being claimed by the right
Page 13 of 59person - the one who holds the documented identity and can bind the digital identity
to the person’s NHI.
• Identity confidence level – Depending on the level of proof of identity that the
Consumer provides, My Health account sets an identity confidence level (in
accordance with the Identity Management Standards 2020). Service Providers can
use the confidence level to ensure that private information is only released to
Consumers who meet that confidence level of identity. More detail of the processes
that will apply in the initial MVP and release 1c project are set out in Appendix Two.
This will include:
o A basic identity account (email address only) that will be sufficient to access
generic services, such as where to access certain service types, or testing
locations for example;
o A verification service confirming key identification documents are held to match
submitted personal identification and contact details;
o A ‘bound’ identity account, which will be uniquely linked to an NHI. This will
require confirmation that the person who has submitted the details is the person
seeking to ‘bind’ the NHI to their My Health account.
o An alternative identity account that makes use of the Consumer’s RealMe
credential and their RealMe verified identity to create an account with a high
level of confidence. NHI binding is still required, and the Consumer has to
consent to sharing RealMe information with My Health for that purpose.
• Explicit Individual Service Consent – Consumers who have attained 3N
verification can consent, and withdraw consent, to enable a Service Provider to
authenticate them using My Health account services. For MVP, this consent will be
integrated into the general account consent. A consent dashboard for Consumers
will be available in later releases.
The Sign Up Process
18. A draft of the planned screen flows for Consumers when creating a My Health account is
attached in Appendix Seven.
19. The Ministry of Health will produce standardised Privacy Notice Materials that are
compliant with rule 3 of the Health Information Privacy Code.
19.1. The standardised information will be provided to, or easily available to be
accessed, by all Consumers, via the services or Service Providers.
19.2. It will be made clear to Consumers that it is their choice to opt-in to use the
My Health account Services. In some cases, Consumers may receive an
invitation to register for a My Health account as part of another health-related
event such as receiving a vaccination. In these cases, the voluntary nature of
registration will be emphasised along with details of how the information will
be used, and the benefits to Consumers.
Page 14 of 5919.3. The Privacy Notice Materials provided for both the My Health account, and
any interacting services, should be clear, and appropriately worded for the
intended audience (level of complexity and language(s) it is written in). Links
to a web-based explanation could be publicised which could contain more
detail for those individuals that wish to know more (a layered privacy notice in
effect).
19.4. An initial draft of the Privacy Statement for My Health is in Appendix Five.
Level 1
20. Consumers can sign up using a unique email address7. They will be asked to confirm
(via a code sent to the registered email address) that they control this address. This
email and password will prevent unauthorised users from accessing the information the
Consumer provides. The Consumer has not yet claimed an identity or bound themselves
to an NHI record at this point. This is Level 1 access and will enable the account holder
to view generic information about health services that are available in New Zealand. No
identifiable information would be available to this level.
21. A second layer of protection will allow the use of Time-limited One Time Passcode
(TOTP) to be used in order to further protect the account from unauthorised use
(commonly described as “multi-factor”). The TOTP settings are Consumer controlled so
that Consumers can choose the level of additional security they want. Some Service
Providers may not enable certain services (especially transactions) without TOTP being
enabled. This is for the services that require a higher level of authentication for specific
transactions. SMS or an authenticator app may also be used in future.
22. A Consumer can optionally use a RealMe verified or RealMe login account to create a
My Health Account. Because RealMe has a policy of not sharing email address with
other services, My Health will still need to collect and check an email address directly
with the Consumer. But if the user has a RealMe verified account, the asserted identity
can be used to elevate the account directly to level 3. Then NHI binding is the only step
left for an account to reach the top 3N level of confidence.
Level 2
23. Next, to achieve Level 2 verification, Consumers are invited to claim their identity
attributes using a document such as NZ Passport or Drivers Licence, Australian
Passport or Drivers Licence. Consumers are asked to provide minimal details to claim a
unique set of identity attributes including document number, names, date of birth and
other details depending on the document used.
24. This information is checked against government records via the Cloudcheck service8, to
make sure that there is a record on an official document that matches the details given
for the Level 2 verification. Verifi Identity Services (A New Zealand company) provides
the Cloudcheck service, an electronic identification verification tool that allows you to
7
This is an address of the Consumers choice – although not more than one digital identity can be linked to the same email
address. The project will need to identify measures for those who wish to change email address. At Level 1 it is likely that they
will be required to simply start a new account.
8
https://www.verifidentity.com/cloudcheck/
Page 15 of 59verify the identity of an individual in seconds using New Zealand government data
sources such as Drivers Licences. This Cloudcheck service is widely used within New
Zealand and Australia for this purpose and they are an existing provider of this service to
the Ministry of Health.
25. Because the level 2 verification above compares attributes given by a user from their
document (including birth certificates) to original source databases (e.g. at DIA and
NZTA) then this check meets the requirements of Information Assurance according to
the Identification Management Standards 2020. This check does not assure Entity
Binding to a high enough level to display personal information. To assure Entity Binding,
either a trusted witness checks that the user is entitled to claim their identity attributes
(see below) or the user has already assured Entity Binding by verifying their RealMe
account.
26. More information about how the Cloudcheck service retains and manages data and
meets the requirements of the Privacy Act can be found here;
https://www.verifidentity.com/legal/ and https://www.verifidentity.com/legal/#privacy . The
Privacy Statement (and the screen in which the Consumer will enter the details) will need
to clearly detail the purpose for use, and clarify that it is not mandatory to complete this
activity, but the consequences will be that the verification level 2 will not be able to be
obtained.
27. The Ministry will retain the outcome of the Cloudcheck verification (only whether it was
valid or invalid) along with the applicant’s name and email address. The date and time of
application will also be recorded. This information is held within the Ministry Project
database and will be used solely for audit purposes in the event there is an apparent
misuse of the Cloudcheck service (in the case a person seeks to misrepresent the
identity of another Consumer). It will only be accessible to select authorised individuals
from the Ministry (or their agents) if they are required to investigate a possible breach of
the Consumer Terms of Use or fraud. This role will be limited, and all access tracked.
Level 2-N
28. It is expected that most Level 2 account holders will proceed promptly to Level 2N.
29. To achieve Level 2N, the system attempts to use the identity attributes provided to get to
level 2 such as names and DoB to find and match a unique NHI number. If this automatic
process fails, then Consumers are then asked to provide their NHI number and/or
address and/or gender and these additional details given by the Consumer are used to
find and match the correct NHI held by the Ministry.
29.1. If the Consumer does not know their NHI, then the My Health account will
search for a matching NHI based on the information given by the Consumer.
29.2. If the Consumer chooses to submit their gender, if it does not match with the
NHI this is unlikely to cause the NHI match to fail if other features do match.
29.3. If the NHI cannot be matched automatically, then the Ministry NHI matching
team will manually match the NHI within two working days. The matching
Page 16 of 59algorithms are designed to reject a match (and send it to manual matching) if
there are multiple potential matches (such as the same name and birth dates
for two individuals).
29.4. The Consumer will be notified by email when matching is complete.
30. The sensitivity of health information indicates caution is required before releasing any
identifiable information. This Level 2N does not confirm the identity of the person behind
the ‘screen’, rather it links the NHI to the Consumer’s account.
31. The following diagram shows the potential registration flows:
My Health Account Registration Flow
Registrant
Start
NHI Number or details Account code Account code
Email and password Document Details
Given to user
Witness
Trusted
User can pause User can pause
registration here registration here
Witness
My Health
Account
Validate email Bind account to Complete Liveness
Agree terms and Complete RealMe
address and obtain National Health check / Entity
privacy statment Document Check Verified
password Identifier (NHI) binding
Yes
Identity Record
RealMe Create Update Update
Verified Account Account Account
VALIDATED account Fully VERIFIED
(Level 1 Pseudonymous) Partly VERIFIED Partly VERIFIED account (Level 3N)
account (Level 2) account (Level 2N)
Yes
Third Party IdP
(e.g. RealMe)
RealMe
BYO Identity from supported IdPs
Drivers Licence
Proof of Identity
Passport
RealMe Verified
OTI
others
Multiple Document types supported
NHI / CPN
Binding
NHI
Level 3N
32. If a Consumer wants to assert an identifiable health status to others (such as the
proposed first use cases is for a Consumer to access their COVID-19 vaccination status,
or their identifiable test results) it is expected they will have a 3N account to be able to
access these services9. This will require some confirmation that the Consumer with the
My Health account is who they say there are.
33. The options for a Consumer to achieve Level 3N will require one of the following:
9
A level 2N account may display whether or not a vaccination record is held by the Ministry, but not any further details .
Page 17 of 5933.1. Use of a ‘trusted witness’:
33.1.1. A unique code held by participating GPs. The GP receptionist will confirm that
it is the person who created the account, with that NHI; or
33.1.2. There may be certain vaccinator (or border worker) roles who will be
authorised to check and confirm recognised photo identity documents – that
matches the person in front of them (not part of the vaccination process – just
taking advantage of a ‘trusted witness’ status in that vicinity), or
33.2. If a Consumer uses their RealMe verified identity, then that identity is
automatically confirmed to Level 3. In most cases My Health will be able to
automatically match the Consumer’s NHI number as well, so they achieve
Level 3N.
34. The C3 project is piloting the ability of the Consumer to be able to verify their identity and
bind that identity to their NHI by visiting a vaccination or testing station. A trusted
witness10 can complete verification using an administrative function on a portal
developed for this purpose, within My Health account.
Project Credibility
35. To support credibility of the Digital Identity project, any suspected compromise, including
any unauthorised or accidental access to, disclosure, alteration, loss or destruction of My
Health account details, NHI details or suspected fraud will be assessed and further
investigated where necessary. As the My Health account is under development,
strategies and reporting will need to be developed to identify when a suspected
compromise might have occurred, and responsibilities for monitoring this.
35.1. Cases where there is evidence of fraud may be passed to Police for further
investigation, and evidence of an offence under the Privacy Act 2020 will be
passed to the Privacy Commissioner11.
35.2. Notifiable privacy breaches will be reported to the Privacy Commissioner and
affected individuals as soon as practicable unless an exception in the Privacy
Act applies.
35.3. A warning will be incorporated into Privacy Materials to ensure Consumers
are aware of the seriousness of misrepresenting their identify or assuming the
identity of another. Consumers will be expected to complete Terms of Use,
and this could be incorporated into those terms.
10
Such as a MIQF manager with a validated account and who can demonstrate employment connection to a DHB or
contracting organisation to a DHB or the Ministry
11
Misleading an agency by impersonating an individual, falsely pretending to be an individual or to be acting under the
authority of an individual for the purpose of obtaining access to that individual’s personal information or having that individual’s
personal information used, altered or destroyed, is an offence against the Privacy Act – see section 212(2)(c)
Page 18 of 59Information fields involved in the identification:
36. The following table summarises the data dictionary of the details that will be collected by
the My Health account, or via the Cloudcheck identity services.
37. A full description of each of these fields in contained in Appendix Three. Obtaining a My
Health account is voluntary. All information fields are ‘voluntary’ as the Consumer
chooses how much information to provide, and how far to progress. To progress through
confidence levels it will be compulsory to provide certain information to achieve that
level:
Data Compulsory Purpose / necessity
Access to generic information – Confidence Level 1
Email address Yes, if the This is required to create an account, so
Consumer that any contact details or identity
chooses to information can be submitted by the
create the My Consumer. The email is also used to
Health account allow contact to be made with the holder
of the My Health account to provide non-
identifiable information. The Consumer is
not identifiable at this Level.
Identity verification service – to claim a documented identity – Confidence Level 2
Identity document number Yes if the My Health account will retain only a
(e.g. passport or drivers’ Consumer record of whether the identity check was
licence), names, date of chooses to use ‘valid’ or ‘invalid’ along with the
birth and other details the verification applicant’s name and email address. The
depending on the service date and time of application will also be
document used. recorded.
The document number It is the name, and date of birth confirmed
details submitted for this via Cloudcheck that will be displayed to
purpose are not retained on other services that are authorised to use
the My Health account as the My Health verification processes.
this service is performed
This is a record retained for the purposes
directly with Cloudcheck
of audit review, if necessary (access is
limited).
This may enable bookings to be made for
certain services in future but is expected
to be limited use. It is expected that most
users will progress to Level 2N.
Use cases will be subject to future
Privacy Impact Assessment activity
NHI Verification – Confidence Level 2N – to bind the NHI to the documented identity
First Name
Page 19 of 59Preferred Consumer Name Yes, if the To identify the documented identity
(if different to first name) Consumer details against the matching NHI.
chooses to
It is intended that the NHI database itself
Middle Name verify the NHI
remains the source of truth for all of the
attributes contained within it12. The
Last Name
personally identifiable details held within
My Health Account will not be displayed
Date of Birth
to Service Providers, beyond confirmation
that the NHI binding process has been
confirmed and the NHI number itself.
Supplied NHI number Stored – so that if does not match verified
NHI any issues can be resolved
Verified NHI number Storing the correct Consumer NHI
number to able to use in future tokens
(includes timestamp when presented for
matching, and when matched)
Confirmation whether or To record manual assistance from NHI
not the identity requires team has been provided
assistance with offline NHI
confirmation
In person ‘liveness’ check – Confidence Level 3N. Exact process to be determined
prior to implementation. May include real person ‘liveness check’, Real Me or other
options to be determined
In addition to details from Yes, if the Identity verification by visiting their GP,
2N, confirmation of identity Consumer (or other option to be determined in
of person and link to NHI chooses to future) and getting confirmation from a
determined in person by verify their trusted witness (such as a GP practice
the ‘trusted person’ identity with a manager with a validated account and
confirmation via a GP ‘trusted person’ who can demonstrate employment
practice (see the proposed as approved by connection to a GP practice) can
process set out in Appendix My Health complete verification using an
One – In person liveness processes administrative function in My Health
check). The details of how account.
this will operate will be
finalised prior to
implementation of any use
case.
RealMe Verified – Information obtained from RealMe after user consent (except for
email which is obtained directly from the user per a level 1 account above).
Email address (obtained Yes, if the This is required to create an account, so
directly from the user rather Consumer that any contact details or identity
than RealMe as RealMe chooses to information can be submitted by the
Consumer. The email is also used to
allow contact to be made with the holder
12
It is possible that the My Health account may eventually have details of address, etc. that do not match current NHI details.
Eventually there may be a future sync process but the NHI will remain the master copy.
Page 20 of 59does not provide email create the My of the My Health account to provide non-
address) Health account identifiable information. The Consumer is
not identifiable at this Level.
First Name No. Obtained To match the identity details provided by
from RealMe if RealMe against the matching NHI (noting
Middle Name the user that NHI records gender and RealMe
consents to records sex – so a difference in details
Last Name share their recorded will not automatically result in a
RealMe verified match rejection).
identity.
Date of Birth It is intended that the NHI database itself
If the user does remains the source of truth for all of the
Place of Birth not consent to attributes contained within it13.
RealMe sharing
The personally identifiable details held
their identity
Sex within My Health Account will not be
then they will
displayed to Service Providers, beyond
need to provide
Address (optional) confirmation that the NHI binding process
an ID document
has been confirmed and the NHI number
and take further
itself.
steps per level
2 and following
above.
Additional information
Gender No Used to assist in matching the correct
NHI record
Mobile Phone Number No To identify the individual and allow
contact to be made. This can also be
used for Multi-factor authentication via
SMS
Current/Permanent No Used to assist in matching the correct
Address NHI record
Retention of information
38. Information that will be retained on the My Health Account once the verification levels
have been achieved includes:
Confidence Level Information retained Retention timeframe
Confidence Level One Email For the duration of the My
Health account
RealMe account token For the duration of the My
identifier (if used) Health account
13
It is possible that the My Health account may eventually have details of address, etc. that do not match current NHI details.
There may be a future sync process but the NHI will remain the master copy.
Page 21 of 59Confidence Level Two Confidence Level Two For the duration of the My
Health account
Email
Confirmation of Cloudcheck
verification of that applicant
name (including date and
time of confirmation).
Applicant name, date of Until account is fully verified
birth, gender to Level 3N – and then
retained under Level 3N
rules
Confidence Level Two N Confidence Level Two N For the duration of the My
Health account
Email
Preferred name
Supplied NHI
Verified NHI
Confirmation whether NHI
assistance was required
Applicant name, date of Until account is fully verified
birth, (optional: supply their to Level 3N – and then
own NHI, gender, address if retained under Level 3N
initial match not achieved rules
with name and date of birth)
Confidence Level Three N Confidence Level 3 For the duration of the My
Health account Applicant
Email
name, date of birth, gender,
Preferred name address, preferred name,
Verified NHI email and supplied and
verified NHI will be retained.
Confirmation of trusted These details will be
person who verified NHI for supplied to authorised
person at in person check services connecting to the
(and identity of that trusted My Health service as
person) identified in the PIA for each
Confirmation if the person of those services (and as
achieved the digital identity approved by the My Health
using RealMe (RealMe service).
token)
39. If a person requests their My Health account be closed then the confidence level, contact
email, RealMe account identifier (if used), linked NHI and dates when confidence levels
Page 22 of 59were granted will be retained indefinitely (as they may be required to link in to other audit
related records in audit trails of access to records). The account would not be able to be
used to validate further activities in future.
40. The My Health Account operations team will process the “death” files issued by the NHI
service to the health sector on a regular basis in order to disable the accounts of
deceased people. It is anticipated that this process will be automated in future releases.
41. It is anticipated that every five years each person will be requested to verify again for
continued use of their My Health Account. This will be incorporated into processes to
signal to the Consumer if this deadline is approaching (and is indicated in the Privacy
Statement).
Where and how the information will be stored
42. In order to deliver the My Health account services the Ministry will use Microsoft Azure
services located in both Sydney and Melbourne, Australia.
43. The diagram below depicts the high-level architecture of the digital identity solution and
specifically denotes the trust boundaries between the main components.
44. The design establishes a security perimeter around the core services and data, with all
external access being via the Azure Front Door network appliance. Front Door provides
a single point of entry into the solution and provides protection for the solution as it
enables both load-balancing and firewall services.
Page 23 of 5945. The solution uses two datastores. Information held in these stores is encrypted and
resides within Australian borders. The stores are:
Azure AD B2C B2C is a user identity directory for My Health account. It
holds some of the Consumer attribute information (such
as username and password).
The Active Directory instance that underlies B2C holds
health Consumer attribute information collected in the
sign-up process.
All the data Active Directory stores is BitLocker encrypted.
Azure PostgreSQL The system also holds additional attribute data collected
(Attribute Store in from the health Consumer. These attributes relate to the
the diagram) state of the applicant’s enrolment process, as
progressively provide more information in order to validate
their identity. First name, last name, date of birth, middle
name, gender and address will be stored here until level
3N is achieved and then it will be deleted
PostgreSQL is an Azure service and all data at rest is
encrypted.
46. Each of the above stores is distributed across Azure regions within Australia in order to
provide highly available services. There is more than one instance of the architecture,
and the ‘Front Door’ distributes the traffic to make sure that the service remains available
to users. The changes are synchronised with each other so that each instance is a copy
of the others.
47. Ministry staff will maintain the Ministry cloud-based solution using a secure access
channel (the Secure channel above). This channel provides access to all service
management functions as well as system event and telemetry (monitoring for
performance – making sure there are no problems with performance, reliability and
integrity) information served up through the Azure Monitor (the data and the access
channel is encrypted).
48. The intent of the monitoring design is to avoid holding personally identifiable information
in any log files. Log and event data are moved off site to the Ministry’s SIEM14, which is
managed by a contracted security specialist. The SIEM data remains onshore in
Wellington at the contacted specialist’s data centre.
49. In addition to the above, the data flow diagram below illustrates how the components
exchange information as part of the sign-in and sign-up processes. This diagram is used
for threat modelling purposes and denotes the flow of information across trust
boundaries.
14
The Security Information and Event Management (security management system)
Page 24 of 59Information Flows
50. The potential information flows for the My Health account are set out below (noting this
diagram does not show the flows for related services to any significant degree as these
have not yet been finalised or reviewed – and will be subject to a subsequent Hira
Privacy Impact Assessment):
CloudCheck
National
Health
Index
Consumer
Secure Web service
COVID Immunisations
MyHealth account – Identity
service only
C3
COVID Test Results
National
Health
Index
MyHealthAccount – Identity
Secure Web service
service only
HIRA
COVID
Examples Only C3 Immunisations
COVID Test Results
Health Apps
Page 25 of 5951. The mechanism by which controls over the information interactions will be imposed are
currently the responsibility of other parts of the larger information project within the
Ministry, and are not further addressed in this project.
52. The diagrams do not yet show the details of which services or Service Providers will be
able to access information with the use of the My Health Account as those options have
not been identified at this stage outside of C3. C3 information access details are in the
C3 and CTIP Privacy Impact Assessments.
Security features
53. The Ministry will perform its usual security testing prior to production go live of My
Health. It will have completed any Ministry security assessment requirements including
Certification and Authorisation, and independent security testing.
54. Security has been approved for Release 1b (with an Approval to Operate already in the
sign off process) – and will be for 1c before go live. The penetration testing for Release
1b is complete as well as the independent audit report. Any necessary mitigations are
already in place.
55. The Ministry has also deployed security strategies including Security Information and
Event Management (SIEM) and Security Operations Centre (SOC).
56. My Health will operate with the built in Microsoft security management features. This
looks at factors such as whether a person has signed into the account in the last 30
days, using a different IP address for continuity. If these look appropriate the person will
be able to access their account with their unique email and password they created. If not,
the person will be asked to complete a two-factor authentication challenge in addition to
the password.
Presentation of My Health information to third parties
57. Service Providers seeking identification services will receive an access token, preferred
name (if one is provided), NHI and Level of Confidence the Consumer has obtained.
Actual Consumer name and other details will then be obtained via the Service Provider’s
connection to the NHI (or their own NHI linked records).
Manual process if NHI issues arise
58. There is a risk, like with all automatic processes, that an NHI may not be able to be
matched automatically or (very rarely) may be matched to the wrong Consumer. The
automated processes for an NHI match are that if there is not sufficient confidence in the
match (in accordance with the algorithm) with the basic details supplied, My Health will
ask the Consumer for other relevant details – it is up to the Consumer if it chooses to
provide any, and if so which details. The options include NHI (if they know it), gender, or
address (on eSAM – the Ministry of Health automated look-up). The automated match
will try again with the additional details and see if an NHI match can be achieved. If not,
the matter will be sent to the manual match team and the NHI binding component of the
digital identity will not be complete until that is resolved.
Page 26 of 5959. My Health account Application administrators will have access to stored Consumer
information in order to manually match and investigate and correct Consumer identity
and NHI binding issues. This may occur under the following circumstances:
• During registration, the NHI may not be automatically matched to the Consumer’s
account. The Ministry’s NHI matching team (notified by email) will complete the
manual match within two working days.
• From time to time, mismatched NHIs may need to be investigated and corrected.
Governance
60. Strong governance is to be in place to manage any potential risk of ‘function creep’ – the
expansion of use of or access to information beyond that originally contemplated.
60.1. New and potentially novel uses of information may evolve over time, and the
Project will need to be flexible to respond to those innovations. As My Health
account will be part of the wider digital health environment a governance
structure that is empowered to review, and be informed about, other
interlinked services will be essential. My Health account is not a stand-alone
service.
60.2. The social licence for the overall project will be key in assisting with
management of the features with which the My Health account will interact.
60.3. Security and audit oversight will also be important to enhancing the trust in
the various services associated with the My Health account.
60.4. It is essential that experienced governance oversight and control is retained
to make sure Consumers remain fully informed, and their information is used
in a way that is acceptable to them.
61. Governance will include:
61.1. Privacy Impact Assessment of all services to be associated with the Digital
Identity Project;
61.2. Reference of any privacy related issues to the Ministry Data Governance
Group; and
61.3. The project MVP and therefore the collection, management, authorised use
and disclosure, and deletion of data is governed by the Digital Identity project
board:
61.3.1. The project board is chaired by DDG Data and Digital.
61.3.2. Once the project is operationalised, the governance will be transferred to an
operational governance group to be detailed in later Privacy Impact
Assessments for this project.
Page 27 of 59You can also read
