SRD-1

Securely storage of authentication credentials used for SDHR

N/A

Authentication Credentials for the SDHR API are stored securely, not available to users 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 allowing for confidence that the user making a request to SDHR is who they say they are

Yes

Documentation of user account controls, SSO, MFA etc.

SRD-3

HPI-Facility and Org 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/Org is assigned directly to their account, appropriate controls must ensure its accuracy. The HPI‑Facility/Org submitted to SDHR in API requests must accurately represent the user on whose behalf the request is made.

Yes

Documentation of user onboarding and facility/org assignment processes, evidence of mapping from 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 user account so this can be submitted to SDHR. Users cannot "self-select" their HPI-CPN.

Yes

Documentation of user onboarding and CPN assignment process

SRD-5

Capture purpose of use for every access

N/A

SDHR is informed of the correct clinical purpose for every request. This could be based on user selection or programatically 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, clinical users can only see data appropriate for their role.

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: Clinicians can make reference to SDHR data while writing notes or documents.

Yes

Architecture diagrams, technical attestations

SRD-8

Only make requests based on user action

N/A

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

Yes

Documentation of requests that are made, correlation of our audit events being linked to a 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

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.

Yes

UI screenshots, terms of use, training material extracts

SRD-11

Provide clear feedback when no data is found

Empty search results from SDHR

Informative message displayed when no records are returned.

Yes

UI screenshots

SRD-12

Users informed of withheld records

Information withheld outcome from SDHR

Users are informed when records are withheld (“information withheld” indicator shown).

Yes

UI screenshots demonstrating withheld indicators

SRD-13

Users informed of domain opt out

Domain level opt out outcome from SDHR

Users are informed when the patient has opted out of a health domain.

Yes

UI screenshots

SRD-14

Users informed of global opt out

Global level opt out outcome from SDHR

Users are informed 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

User receives meaningful message; system does not repeatedly retry during rate limit window.

Yes

UI screenshots, test evidence showing correct handling of 429 errors

SRD-16

Users informed of deceased patients

Deceased patient indicator from SDHR

Users are alerted that a patient is deceased.

Yes

UI screenshots

SRD-17

Support linked NHI viewing

SDHR response including multiple NHIs

Viewer can display records across all NHIs linked to a consumer.

Yes

UI screenshots demonstrating display of linked NHI test patient

SRD-18

Users informed when there are more records

Large number of records returned from SDHR

Users are informed 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

SDHR data fields are displayed without truncation or loss of meaning.

Yes

UI screenshots demonstrating full field rendering

SRD-20

Users informed of appropriate statuses of records

SDHR response includes records with different statuses

Users are made aware of 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-authortative.

Yes

UI screenshots

SRD-22

Appropriate clinical oversight of user interface

N/A

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

Governance structure, clinical sign off

SRD-23

Maintain complete audit logs

N/A

Audit logs capture 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 -Facility and Organisation 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

SEHR can supply filtered audit logs on request (by NHI, user, org, time).

Yes

Sample filtered audit extracts

SRD-25

Retrieve access samples from SDHR

SDHR accesses have been performed

SEHR is 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 can determine the appropriateness of accesses to SDHR data by a clinician. SEHR can submit monitoring outcomes to SDHR via the Sampling API.

Yes

Time of API calls so SDHR can verify call was received. Business process/rules for determining appropriateness of SDHR data access

SRD-27

Perform proactive monitoring of access

Monthly monitoring outputs

Regular monitoring detects inappropriate or anomalous access in compliance with HIGG.

Yes

Monitoring reports; attestation

SRD-28

Support privacy investigations and corrective action

Incident records

Privacy breaches are investigated, recorded, and corrective action taken.

Yes

SOPs, incident register extracts - this is the content though