New Zealand NHI IG - Local Development build (v1.4.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

General

The following notes apply to all resources in this implementation.

Resource representation: Json

Only Json is supported by this implementation.

Id and Identifiers

In this implementation, the id of the resource will always be the same as the value of the identifier assigned by the NHI with a use value of ‘official’. (There will only ever be a single identifier with this use type and system in a resource).

Thus the id for the resource below would be ‘ZAT2348’, and the url to read the resource something like:

https://api.hip.digital.health.nz/fhir/Patient/ZAT2348

Linking resources and Dormant identifiers

​Sometimes a person may have been added more than once to the NHI and been accidentally assigned more than one NHI number. When this is discovered to have occurred, the NHI records are linked, one of the NHI numbers becomes the ‘live’ identifier and the other NHI numbers become ‘dormant’ identifiers. For statistics on Dormant NHI numbers see Dormant NHI statistics

All the NHI numbers will appear in the resource identifier list, the live or active NHI number will have a use value of ‘official’ and the dormant identifiers will all have a use value of ‘old’.

When using a Get operation, if the ‘dormant’ identifier is used in the request, the resource returned will be the live resource and will include all the identifiers, the ‘live’ or ‘active’ with a use value of ‘official’ and the dormants with a use value of ‘old’.

{
  "resourceType": "Patient",
  "id": "ZAT2534",
"identifier": [ {
    "use": "official",
    "system": "https://standards.digital.health.nz/ns/nhi-id",
    "value": "ZAT2534",
}

]
… other data
}

(returned by GET<Endpoint>/Patient/ZAT2534)

And

{
  "resourceType": "Patient",
  "id": "ZAT2518",
"identifier": [ {
    "use": "official",
    "system": "https://standards.digital.health.nz/ns/nhi-id",
    "value": "ZAT2518",
}

]
… other data
}

(returned by GET<Endpoint>/Patient/ZAT2518)

They are determined to be the same person, and the identifier ZAT2518 is made dormant in favour of ZAT2534.

A GET call of GET<Endpoint>/Patient/ZAT2534 or GET<Endpoint>/Patient/ZAT2518 will return the same response

{
  "resourceType": "Patient",
  "id": "ZAT2534",
"identifier": [ {
    "use": "official",
    "system": "https://standards.digital.health.nz/ns/nhi-id",
    "value": "ZAT2534"},
{
    "use": "old",
    "system": "https://standards.digital.health.nz/ns/nhi-id",
    "value": "ZAT2518"},
]
… other data
}

Errors

HTTP Error response codes

Response Body

The Response body may contain an OperationOutcome resource describing the result of the request message processing
The table below describes how the OperationOutcome should be populated

Error Format

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "error",
            "code": "processing",
            "details": {
                "coding": [
                    {
                        "system": "https://standards.digital.health.nz/ns/hip-error-code",
                        "code": "EM07201"
                        "display": "Missing a required field"
                    }
                ],
                "text": "Name is a required field"
            }
        }
    ]
}

Request Rules and Errors

• Request rules
  • Every request must include an:
    • http header item UserId that uniquely identifies the individual initiating the request.
    • OAuth 2 access token
    • An api-key
• Request errors
  • Authentication: missing userid header, HTTP401, Processing
  • Unauthorized, HTTP401
  • Forbidden, HTTP403

HTTP Header Details

• This is a list of any additions to standard HTTP header protocol

Request Headers

Response Headers

Security

OAUTH2

The NHI server uses the OAUTH2 Client Credentials flow for authentication and authorisation and complies with the SMART specification for backend services

Scopes

The following scopes are supported. For more information on available functionality please see Business Functions.

• Access to a Patient’s enrolled General Practice and Contact details are additional permissions that should be requested during the onboarding process

API Keys and Usage Plans

Clients will be emailed their API key, which should be treated as confidential information and not shared with other parties

An api-key associates the client with a usage plan, which sets upper limits on the API request volume which is permitted. If a client exceeds their usage plan allocation an http error will be returned

Clients will need to add their api key to the x-api-key header in each API request. If no API key is included in the request header, a “Forbidden” error will be returned

Usage Plans

All test accounts will be assigned to the bronze usage plan. If a Vendor wishes to be assigned to a higher plan, they should contact the Integration team via the General Enquiry form Please request a change to the usage plan and make sure you include the ClientID at minimum (AppId and Orgid also recommended).

Production accounts will be assigned to the silver usage plan. If an Organisation wishes to be assigned to the gold usage plan, they should contact the Te Whatu Ora NHI access team

If an application reaches its usage plan limit an HTTP 429 error will be returned. The expected behaviour is that the application will retry several times with an exponentially increasing delay

GEO Restriction

GEO Restriction rules prevent access from clients with IPs located in countries other than those listed below. If you need access from another country, please contact our team by completing the Enquiry form or adding a comment to the online onboarding request form if you have one.

• New Zealand
• Australia
• Canada
• Cook Islands