SRD-1

Secure storage of authentication credentials used for SDHR

N/A

The SEHR system must store SDHR API authentication credentials securely, not available to users, including SEHR staff, without appropriate controls in place.

Yes

Documentation of authentication credential storage solution and/or controls in place to prevent inappropriate access to the credential store

SRD-2

User logins to the SEHR system are performed securely

N/A

Users of the SEHR system have secure user accounts that only they can access, providing confidence that the clinical user making the request is who they claim to be.

Yes

Documentation of SEHR user account controls, SSO, MFA etc.

SRD-3

HPI-Facility and Organisation are accurately reported to SDHR

N/A

Clinical users must only be able to select an HPI‑Facility or HPI‑Organisation with which they have a legitimate relationship. Where a user’s HPI‑Facility/Organisation is assigned directly to their account, appropriate controls must ensure its accuracy. The HPI‑Facility/Organisation submitted to SDHR in API requests must accurately represent the clinical user on whose behalf the request is made.

Yes

Documentation of clinical user onboarding and facility and organisation assignment processes, evidence of mapping from clinical user account to request, test cases

SRD-4

HPI-CPN is accurately reported to SDHR

N/A

Clinical users must have the correct HPI-CPN assigned to their clinical user account so this can be submitted to SDHR. Clinical users cannot "self-select" their HPI-CPN.

Yes

Documentation of clinical user onboarding and CPN assignment process

SRD-5

Capture purpose of use for every access

N/A

The SEHR system must provide SDHR with the correct clinical purpose for every request. This could be based on clinical user selection or programmatically set.

Yes

Purpose of Use selection or recording process details

SRD-6

Enforce appropriate access restrictions to SDHR data

N/A

Non-clinical users cannot see any SDHR data. Where limitations apply to certain types of clinical users, those limitations are consistently enforced.

Yes

Role definitions, permission matrices

SRD-7

No local retention of SDHR clinical data

N/A

SDHR clinical content is not stored, cached, or logged within the SEHR system. Please note: Clinical users can make reference to SDHR data while writing notes or documents.

Yes

Architecture diagrams, technical attestations

SRD-8

Only make requests based on clinical user action

N/A

Requests for SDHR data must only be made for the purpose of displaying data to the clinical user. Non-user-initiated requests MUST NOT be made.

Yes

Documentation of requests that are made, correlation of API requests being linked to a clinical user action in the SEHR

SRD-9

Ensure correct record is being viewed

N/A

Clinical users have safe methods for ensuring the correct patient record is being viewed. This could include integration directly into the existing wider patient record within the same UI or via a launch with the patient context included, display of patient demographics from a local or nationwide source to allow patient identification. An unattached SEHR record without demographics displayed that was found based on a typed NHI is insufficient.

Yes

UI screenshots demonstrating record selection or launching process

SRD-10

Clinical users are made aware of SDHR data completeness limits

N/A

Clinical users are made aware that SDHR data may not present the full patient record. This could be achieved by messages in the user interface, user acknowledgement of this as part of an initial access or user training completed prior to the clinical user gaining access to the SEHR.

Yes

UI screenshots, terms of use content and process or training material extracts

SRD-11

Provide clear feedback when no data is found

Empty search results from SDHR

The SEHR system must display an informative message when no records are returned.

Yes

UI screenshots

SRD-12

Inform clinical users of withheld records

Information withheld outcome from SDHR

The SEHR system must inform clinical users when records are withheld (i.e. an “information withheld” indicator or message is shown).

Yes

UI screenshots demonstrating withheld indicators/messages

SRD-13

Inform clinical users of domain opt out

Domain level opt out outcome from SDHR

The SEHR system must inform clinical users when the patient has opted out of a health domain.

Yes

UI screenshots

SRD-14

Inform clinical users of global opt out

Global level opt out outcome from SDHR

The SEHR system must inform clinical users when the patient has globally opted out of SDHR.

Yes

UI screenshots

SRD-15

Handle SDHR API rate limiting gracefully

HTTP 429 response from SDHR

The SEHR system must provide a meaningful message to clinical users and must not repeatedly retry during the rate-limit window.

Yes

UI screenshots, test evidence showing correct handling of 429 errors

SRD-16

Inform clinical users of deceased patients

Deceased patient message returned from SDHR

The SEHR system must inform clinical users when the patient is deceased. Note that SDHR will not return clinical data for deceased patients.

Yes

UI screenshots

SRD-17

Support linked NHI viewing

SDHR response including multiple NHIs

The SEHR system must display records across all NHIs linked to a consumer.

Yes

UI screenshots demonstrating display of linked NHI test patient

SRD-18

Inform clinical users when additional records are available

Large number of records returned from SDHR

The SEHR system must indicate when there are more records than currently displayed. This could take the form of page counts, infinite scroll or other UI indicators.

Yes

UI screenshots

SRD-19

Prevent data truncation

SDHR response including long text strings

The SEHR system must display data retrieved from SDHR without truncation or loss of meaning.

Yes

UI screenshots demonstrating full field rendering

SRD-20

Inform clinical users of record status information

SDHR response includes records with different statuses

The SEHR system must indicate the status of records where appropriate to ensure they can differentiate between current and past conditions, allergies, etc. This could take the form of status badges or some other indicator.

Yes

UI screenshots

SRD-21

Avoid relying on unverified patient names

N/A

Patient names from SDHR are either not displayed or clearly marked as non-authoritative.

Yes

UI screenshots

SRD-22

Appropriate clinical oversight of the SEHR user interface

N/A

The clinical user experience when accessing SDHR data must be designed with appropriate clinical oversight in place to avoid risk of misinterpretation or harm.

Yes

Governance structure, clinical sign-off

SRD-23

Maintain complete audit logs

N/A

The SEHR system must capture audit logs that provide full traceability for every SDHR interaction in compliance with HIGG. This would include at a minimum:
- SEHR User ID
- HPI CPN or other identifier
- Full name
- IP address
- HPI-Facility and HPI-Organisation the clinical user belongs to
- PoU for access
- The API call that was made
- Timestamp of access

Yes

Audit log extracts

SRD-24

Enable Health NZ audit and investigation

Filtered audit datasets

The SEHR system must be capable of supplying filtered audit logs on request (by NHI, user ID, organisation, facility, time).

Yes

Sample filtered audit extracts

SRD-25

Retrieve access samples from SDHR

SDHR accesses have been performed

The SEHR system must be capable of retrieving sampled SDHR data accesses via the sampling API.

Yes

Time of API calls so SDHR can verify call was received

SRD-26

Submit proactive monitoring outcomes to SDHR

Access samples have been retrieved

The SEHR system must be capable of submitting monitoring outcomes to SDHR via the Sampling API following verification of appropriateness of access by Health Service Provider.

Yes

Time of API calls so SDHR can verify call was received.

SRD-27

Differentiate Prescribed from Dispensed data

Medications data returned containing both prescribed and dispensed records

The SEHR system must distinguish between prescribed and dispensed medications to ensure clinical users have sufficient information to determine which medications the patient may be taking.

Yes

UI screenshots

SRD-28

Prescription data must be surfaced with dispensing data

Medications data returned containing both prescribed and dispensed records

Dispensing record data must take precedence over prescribed record data where both exist for a given medication record. Dispensed data is a more accurate depiction of what the patient received, therefore viewing prescription data without access to corresponding dispensing data can lead to misinterpretations about what the patient received.

Yes

UI screenshots

SRD-29

Extemporaneously Compounded (EC) Items

Medications data returned containing Extemporaneously Compounded records

Extemporaneously compounded medication records can contain a list of ingredients within the record. All ingredients must be displayed in the SEHR UI rather than displaying only the label which may not fully reflect the ingredients in the compounded medication.

Yes

UI screenshots