Digital asset onboarding checklist

Access restrictions

You 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.

Legal specification

All subscribers of your digital asset will need to agree and sign a Subscriber Agreement. This should include requirements specific to your digital asset. You will need to work with Legal to create the agreement.

Specific requirement example: For the cervical screening summary API, the digital asset subscriber product must only allow access to Enrolled Nurse Cervical Sample-takers who have been approved via the NCSP Manager’s approval process.

Digital asset clinical risk score

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

Compliance testing

Compliance testing ensures that a subscribers product meets the standards you’ve set for your digital asset and verifies that their product adheres to all legal, security, privacy, clinical, and contractual requirements. It is carried out by the digital asset subscriber, however as the digital asset owner, you must define these requirements and ensure test data is set up in UAT or Mock+ (whichever your subscriber will use to complete compliance testing) to enable the subscriber to complete this task.

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 you - 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

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 digital asset 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 digital asset calls along with extreme values, missing data and unexpected inputs. Ideally it should be good enough to for a digital asset subscriber to complete compliance testing with.

Any additional or special digital asset requirements

Document any special requirements a 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 (e.g. 24/7 or 7 days or ….)
• 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.

Operational monitoring and alerting

Operational monitoring and alerting needs to be defined and set up using Datadog. By default, you will get a standard dashboard and alerts that needs to be configured for your resolver group. You need to work directly with Datadog to organise this.

Conformance testing

Conformance testing 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 and needs to be signed off by the integration lead. 

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.

Health NZ release process

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 or copy of to each of the above completed items (documents/evidence of completion) prior to the release of the digital asset into production.

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 (or equivalent) as part of the digital asset 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