Determining risk score

Clinical criticality of care


The types of clinical information and data you want to access will have varying levels of clinical risks. This is determined by how critical this data is to make clinical decisions in a clinical setting.

Criticality of API data

Data type

Example

1

Publicly available information

Information aiding health care delivery

eg. HPI ID, practitioner ID, death notification, entitlement, financial information, address

2

Lower risk personal and clinical information

eg. Immunisation record, planned events

3

Significant clinical information

eg. Diagnosis, problem list, historical data, social history

4

High-risk clinical decision-making information

eg. Allergies, labs, medicines, current & relevant data

5

Identity-related Information

eg. Name, DOB, Identifiable IDs, Gender

Clinical use case

Different functionality available within the API can lead to varying levels of clinical risks.

Use case risk tier

API functionality

Example

1

Search / Read 

eg. Displaying read-only view of planned events

2

Update / Edit 

eg. Updating an existing allergy information to add more detail

3

Create / Add to 

eg. Adding a new allergy

4

Use information in Clinical Decision support

eg. using the output on an algorithm to change clinical care

5

Delete 

eg. Can remove existing data

Clinical risk score matrix

This is a combination of API use case (functionality) and the clinical criticality of care of the information requested.

  

  

(2)  Criticality of API data 

  

  

1 

2 

3 

4 

5 

(1)  Use case 

5 

11 

16 

20 

23 

25 

4 

7 

12 

17 

21 

24 

3 

6 

8 

13 

18 

22 

2 

3 

5 

9 

14 

19 

1 

1 

2 

4 

10 

15 

 

 

Legend:

Low

Medium

High

Extreme

Overall risk rating

The table below explains the categorisation of overall risk, onboarding requirements, and recertification period details. We need to recertify API clinical risk and safety requirements periodically, especially if there are updates to healthcare regulations, policy or legislation. The recertification period may be more frequent with a higher risk rating and may vary depending on the trust score of the vendor.

Low 
(1-3) 

Use case is directly related to low level of clinical risk. Lowest level of onboarding and certification conformance is required.

Medium 
(4-13) 

Use case is directly related to medium level of clinical risk. Medium level of onboarding and certification conformance is required.

High 
(14-21) 

Use case is directly related to high level of clinical risk. Medium level of onboarding and certification conformance is required.

Extreme 
(22-25) 

Use case is directly related to making clinical decision support through the integration of clinically critical API. Highest level of onboarding and certification conformance is required.

Onboarding controls

Depending on the clinical risk of the data and use case, you will either fall in low, medium, high or extreme category of clinical risks. For each level of risks, varying degrees of mandatory controls are required in order to gain production access to the API. These controls are not needed for Developer Portal access. We support innovation and growth in our digital health sector, in a safe and collaborative way with the right checks and balances. Our digital clinical safety team can advise and help with the below requirements, especially for smaller technology companies and startups.

Requirements 

Low 

Medium 

High 

Extreme 

Your organisation must be accredited for the RNZCGP Foundation Standard. 

YES 

YES 

YES 

YES 

Your organisation must have processes for identifying and managing clinical risks and issues.  This includes details of processes for escalating significant risks that include preventing, identifying, evaluating, mitigating and controlling for digital clinical risks. 

YES 

  

  

YES 

  

  

YES 

  

  

YES 

  

  

Your organisation must have a process for reporting and managing clinical incidents/adverse events including details for escalating significant incidents. 

YES 

YES 

YES 

YES 

Your organisation must have a clinical incident register and matrix used to assess clinical incidents.

NO 

YES 

YES 

YES 

Your organisation must have a process for notifying Health New Zealand in the event of an incident/adverse event, including ongoing issues and closing the loop. 

YES 

YES 

YES 

YES 

Your organisation must have a process for notifying users/consumers in the event of an incident/adverse event, including ongoing issues and closing the loop. 

YES 

YES 

YES 

YES 

Your organisation must have had input from clinical risk management experts into your risk and incident management plan. 

NO 

NO 

NO 

YES 

Your organisation must have a clinical risk register and matrix used to assess clinical risks. 

NO 

YES 

YES 

YES 

Your product must have had input from a clinician subject matter expert. 

NO  

YES  

YES  

YES 

Your organisation must have release documents available for the current version of your product that include details on the clinical risks and potential treatments that your consumers can adopt in their implementation? 

NO 

YES 

YES 

YES 

Your organisation must have a person responsible for managing digital clinical risks and approving the risk acceptability criteria for your product/s. 

NO 

NO 

NO 

YES