HSAAP Special Authority FHIR Implementation Guide
0.1.1 - draft New Zealand flag

HSAAP Special Authority FHIR Implementation Guide - Local Development build (v0.1.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Security, Onboarding and Auditing

Authentication and authorisation

Authentication and authorisation mechanics are defined in the HSAAP Special Authority - Security (Auth & Auth) Design. In summary:

  • Every request requires a validated OAuth 2.0 access token and a validated signed Request-Context header.
  • The authenticated requester identity is taken from the token and Request-Context header, never from the FHIR payload.
  • Values asserted in the payload - the submission-context extension, the submitting Organization, and any practitioner CPN - are provenance only. They are checked for consistency with the authenticated context and never used for authentication or authorisation.

Onboarding

The API uses the established Health NZ Digital Services Hub (DSH) processes. The API is onboarded through the Digital Asset Onboarding process. PMS vendors follow the Digital Asset Subscriber Onboarding process, which assesses the organisation, product and intended use cases against security, information-handling and lawful-disclosure requirements before UAT credentials are issued. Successful onboarding accredits the subscriber product for an approved business function. Contact integration@tewhatuora.govt.nz.

Auditing

The API aligns with the Health NZ DSH centralised logging and auditing design. Audit events are captured and processed asynchronously, transformed into FHIR AuditEvent resources and persisted to the centralised auditing solution. See the Audit Events Implementation Guide.