Digital asset onboarding checklist

Whilst you build and test your digital asset, please consider and prepare the following. You will need these when you complete the digital asset onboarding form.

Activities or considerations
Your digital asset use case You will need to provide general use cases for your digital asset which include the lawful grounds for disclosure and who the information may be shared with. Your privacy impact assessment (PIA) or privacy specialist should help you define this. Example: The information within the dataset can be used by health professionals responsible for the care of the health consumer or by specialists trained to interpret results and advise the healthcare provider or healthcare consumer on potential care plans. This data may also be shared with healthcare consumers.
Access restrictions You will need to provide information about any required controls or restrictions that need to be in place. Your privacy impact assessment (PIA) or privacy specialist should help you define this. Example: The information within the dataset cannot be accessed by anyone who has not received explicit consent from the concerned healthcare consumer.
Your API/service risk scores You will need to complete the API Risk Score assessment and provide a privacy and clinical risk score to inform subscribers the minimum requirements they need to meet to integrate with your digital asset. Your privacy and clinical specialists should assess this prior to submitting it to us.
Conformance testing The digital asset going up on the Digital Services Hub will need to complete conformance testing as part of your test exit. It verifies whether your digital asset meets Health NZ API standards. An automation test suite has been created and can be run to check overall conformance. It will form part of your release test exit report. An additional sign off for this report will be the Integration Team Design Lead. Any non-conformance will need to be approved by this person.
Compliance testing Compliance testing is carried out by the digital asset subscriber to ensure that a product meets the standards you've set for your digital asset. This process verifies that the product adheres to all legal, security, privacy, clinical, and contractual requirements. As the digital asset owner, you must define these requirements before publishing your asset on the Digital Service Hub. Input from your security, privacy, and clinical experts may be necessary to determine how data should be displayed in the integrating product or what information should be returned in requests. for instance, you might specify that dates must be shown in New Zealand format or define how search results should present minimum required information to accurately select the correct patient. Subscribers must provide evidence of their compliance testing, which will be reviewed by the digital asset owner to confirm that all criteria have been met. This requirement should be factored into your team's operational support for your digital asset. Example: https://nhi-ig.hip.digital.health.nz/ComplianceTestingImportantInformation.html
Any additional or special digital asset requirements Document any special requirements an subscriber must be aware of if they want to integrate with your digital asset. Example: The immunisation API will provide demographic information if you also integrate with NHI and HPI APIs. Otherwise, it will only provide ID attributes.
Operational support information Expected annual availability of your digital asset? What are the days and times your digital asset has support available to help if an issue is encountered: Hours your digital asset is supported (eg 24/7 or 7 days ???) Your organisations standard business hours (days and times) Contact details for support of your digital asset during business hours Contact details for support of your digital asset outside of business hours
Production Go-live Approval Following the standard Health NZ release process, the Digital Services Hub team will seek approval to publish the digital asset from the following teams – clinical, security, privacy, test, D&D Integration Design Lead and D&D operational support team. To ensure these teams provide approval, you need to make sure you have completed and evidenced the following: Privacy Impact Assessment (PIA) Security Risk Assessment and Certifications (SRA) Security Authority to Operate (ATO) Digital clinical safety assessment done Test Exit Report (TER) NOTE – You will need to provide a link to each of the above documents/evidence of completion prior to the release of the digital asset into production.
Funding Funding needs to be in place to cover the build out of the gateways by the Integration team, the Digital Service Hub team time to facilitate and then any ongoing operational support required from the Platform team, the Integration Support team and the Digital Services Hub team.

Activities or considerations

Your digital asset use case

You will need to provide general use cases for your digital asset which include the lawful grounds for disclosure and who the information may be shared with. Your privacy impact assessment (PIA) or privacy specialist should help you define this.

Example: The information within the dataset can be used by health professionals responsible for the care of the health consumer or by specialists trained to interpret results and advise the healthcare provider or healthcare consumer on potential care plans. This data may also be shared with healthcare consumers.

Access restrictions

You will need to provide information about any required controls or restrictions that need to be in place. Your privacy impact assessment (PIA) or privacy specialist should help you define this.

Example: The information within the dataset cannot be accessed by anyone who has not received explicit consent from the concerned healthcare consumer.

Your API/service risk scores

You will need to complete the API Risk Score assessment and provide a privacy and clinical risk score to inform subscribers the minimum requirements they need to meet to integrate with your digital asset. Your privacy and clinical specialists should assess this prior to submitting it to us.

Conformance testing

The digital asset going up on the Digital Services Hub will need to complete conformance testing as part of your test exit. It verifies whether your digital asset meets Health NZ API standards. An automation test suite has been created and can be run to check overall conformance. It will form part of your release test exit report. An additional sign off for this report will be the Integration Team Design Lead. Any non-conformance will need to be approved by this person.

Compliance testing

Compliance testing is carried out by the digital asset subscriber to ensure that a product meets the standards you've set for your digital asset. This process verifies that the product adheres to all legal, security, privacy, clinical, and contractual requirements. As the digital asset owner, you must define these requirements before publishing your asset on the Digital Service Hub.

Input from your security, privacy, and clinical experts may be necessary to determine how data should be displayed in the integrating product or what information should be returned in requests. for instance, you might specify that dates must be shown in New Zealand format or define how search results should present minimum required information to accurately select the correct patient.

Subscribers must provide evidence of their compliance testing, which will be reviewed by the digital asset owner to confirm that all criteria have been met. This requirement should be factored into your team's operational support for your digital asset.

Example: https://nhi-ig.hip.digital.health.nz/ComplianceTestingImportantInformation.html

Any additional or special digital asset requirements

Document any special requirements an subscriber must be aware of if they want to integrate with your digital asset.

Example: The immunisation API will provide demographic information if you also integrate with NHI and HPI APIs. Otherwise, it will only provide ID attributes.

Operational support information

Expected annual availability of your digital asset?

What are the days and times your digital asset has support available to help if an issue is encountered:

Hours your digital asset is supported (eg 24/7 or 7 days ???)
Your organisations standard business hours (days and times)
Contact details for support of your digital asset during business hours
Contact details for support of your digital asset outside of business hours

Production Go-live Approval

Following the standard Health NZ release process, the Digital Services Hub team will seek approval to publish the digital asset from the following teams – clinical, security, privacy, test, D&D Integration Design Lead and D&D operational support team. To ensure these teams provide approval, you need to make sure you have completed and evidenced the following:

Privacy Impact Assessment (PIA)
Security Risk Assessment and Certifications (SRA)
Security Authority to Operate (ATO)
Digital clinical safety assessment done
Test Exit Report (TER)

NOTE – You will need to provide a link to each of the above documents/evidence of completion prior to the release of the digital asset into production.

Funding

Funding needs to be in place to cover the build out of the gateways by the Integration team, the Digital Service Hub team time to facilitate and then any ongoing operational support required from the Platform team, the Integration Support team and the Digital Services Hub team.

Items required to be published
Open API Specification An open API specification must be created and published on our Digital Services Hub for subscribers to view. A template for this can be found here.
Home.md file The home.md file as part of the API package deployment. It gives the consumer all the relevant business information they need to know. Example: https://mohits.atlassian.net/wiki/spaces/SI/pages/3890776208/Home.md+file+template
Implementation Guide An implementation guide should accompany all FHIR APIs with relevant information. The implementation guide will be surfaced on the Digital Services Hub. Example: https://nhi-ig.hip.digital.health.nz/businessView.html
Mock+ data Mock+ is a service designed for subscribers allowing them to perform integration and functional testing before integrating with production or pre-production systems. Each subscriber has their own tenant, allowing them to reset their own data on-demand. Digital asset Owners need to set up their APIs representative test data. This is a set of test data that is rich enough for subscriber development. It needs to cover production-like scenarios. It should contain large search sets with complex relationships taking into consideration data representing user actions, data to simulate errors, timeouts and failed API calls along with extreme values, missing data and unexpected inputs. Ideally it should be good enough to for an API subscriber to complete compliance testing with.
Legal Specification All subscribers of your digital asset will need to agree and sign an Subscriber Agreement. Do you have any specific requirements we need to include in this agreement? You will need to consult with Legal on this. Example: For the cervical screening summary API, the API subscriber application must only allow access to Enrolled Nurse Cervical Sample-takers who have been approved via NCSP Manager approval process.
Product Roadmap (optional)

Items required to be published

Open API Specification

An open API specification must be created and published on our Digital Services Hub for subscribers to view. A template for this can be found here.

Home.md file

The home.md file as part of the API package deployment. It gives the consumer all the relevant business information they need to know.

Example: https://mohits.atlassian.net/wiki/spaces/SI/pages/3890776208/Home.md+file+template

Implementation Guide

An implementation guide should accompany all FHIR APIs with relevant information. The implementation guide will be surfaced on the Digital Services Hub.

Example: https://nhi-ig.hip.digital.health.nz/businessView.html

Mock+ data

Mock+ is a service designed for subscribers allowing them to perform integration and functional testing before integrating with production or pre-production systems. Each subscriber has their own tenant, allowing them to reset their own data on-demand. Digital asset Owners need to set up their APIs representative test data. This is a set of test data that is rich enough for subscriber development. It needs to cover production-like scenarios. It should contain large search sets with complex relationships taking into consideration data representing user actions, data to simulate errors, timeouts and failed API calls along with extreme values, missing data and unexpected inputs. Ideally it should be good enough to for an API subscriber to complete compliance testing with.

Legal Specification

All subscribers of your digital asset will need to agree and sign an Subscriber Agreement. Do you have any specific requirements we need to include in this agreement? You will need to consult with Legal on this.

Example: For the cervical screening summary API, the API subscriber application must only allow access to Enrolled Nurse Cervical Sample-takers who have been approved via NCSP Manager approval process.