Australia: national infrastructure shapes the integration design
In Australia, enterprise interoperability is not only a standards problem. It is also a national program problem. My Health Record, the HI Service, and NASH PKI add operational dependencies that architects must treat as part of the runtime design.
That means an AWS integration tier often has to perform identifier lookup, hold protected certificate material securely, and interact with SOAP-based national gateways before it can fetch or publish patient information.
Australia-oriented clinical access path
Loading diagram...
My Health Record overview
Official Australian Government overview of My Health Record and its role in national digital health.
Read the MHR overviewNASH PKI for software vendors and developers
Official Services Australia guidance for developers working with NASH certificates.
Open the NASH guidanceAustralia uses multiple national access surfaces, not one universal API
Australian national-health integrations are a bundle of dependencies, not a single interface. A clinical system may need identifiers from the HI Service, trust material from NASH, document exchange with the My Health Record B2B Gateway, and in some programs a FHIR-based surface through the ADHA FHIR Gateway.
Australia-oriented integration boundary on AWS
Loading diagram...
What each national dependency contributes
| Dependency | Primary purpose | Architectural consequence |
|---|---|---|
| HI Service | Resolve or verify nationally managed healthcare identifiers | Identity lookup becomes a runtime dependency in patient-binding workflows |
| NASH PKI | Provide trusted certificate material for national-service interactions | Certificate storage, rotation, and environment separation become first-class design concerns |
| My Health Record B2B Gateway | Support established SOAP-based document and view workflows | Legacy transport and certificate handling may remain in the platform even if newer APIs are added |
| ADHA FHIR Gateway | Expose supported My Health Record interactions through a FHIR-oriented surface | Enables modern app integration patterns, but does not remove the need to reason about national conformance and trust boundaries |
Do not compress national dependencies into one box on the architecture diagram
HI lookup, certificate trust, SOAP B2B workflows, and FHIR-based access have different failure modes, conformance obligations, and operational owners. Treat them as separate dependencies in the design and runbooks.
My Health Record B2B Gateway overview
Official ADHA overview of the B2B gateway used by software conformant to national digital-health workflows.
Read the B2B gateway overviewMy Health Record FHIR Gateway
Official ADHA material for connecting conformant software to My Health Record using FHIR-based interfaces.
Read the FHIR Gateway guideHealth Identifiers service overview
Official ADHA overview of the Health Identifiers service and how it supports healthcare interoperability.
Read the HI Service overviewNew Zealand: governance frameworks influence workload shape and evidence
In New Zealand, the Health Information Security Framework (HISF) and API Risk Framework push architects to think beyond pure interoperability semantics. A design may be standards-compliant and still fail governance if auditability, assurance evidence, privacy handling, or clinical risk treatment are weak.
Regional governance concerns that affect design
| Concern | Typical design impact | What to prepare |
|---|---|---|
| Security framework alignment | More formal control mapping and operational evidence | Control matrix, logs, runbooks, and access reviews |
| Clinical API risk | Sharper review of exposure, trust boundaries, and downstream usage | Threat model and API classification rationale |
| Data residency and privacy | May restrict regional replication choices | Documented hosting and recovery architecture |
Health Information Security Framework
Official Te Whatu Ora publication for health-sector security expectations.
Read the HISFAPI Risk Framework
Official Te Whatu Ora guidance for API risk posture and classification.
Open the API risk frameworkRegional context changes what "good AWS architecture" looks like
The same XDS or MHD workflow can lead to different deployment decisions depending on jurisdiction. One environment may permit multi-region active-active replication. Another may require domestic-region hosting, stronger legal review for cross-border backup, or even Outposts-style local recovery for sovereignty reasons.
Regional architecture decision flow for healthcare workloads
Loading diagram...
Evidence artifacts the regional review usually asks for
| Artifact | Why it matters |
|---|---|
| Control mapping to national or sector frameworks | Shows that transport, audit, secrets, and recovery controls were designed intentionally |
| Data-flow and residency documentation | Explains where patient data lives, moves, and is recovered |
| Runbooks for certificate rotation and national-service outages | Regional dependencies often fail operationally, not only logically |
| API risk and threat model | Needed when exposing MHD, FHIR, or partner-facing services beyond the private network |
Decision rule
Start with the workflow and data classification, then test the hosting model against national service dependencies, privacy law, and recovery requirements. Do not bolt regional compliance on after the platform shape has already been chosen.
AWS IRAP
AWS compliance material relevant to Australian assurance and evidence conversations in government and healthcare environments.
Read AWS IRAP guidanceUsing AWS in the context of New Zealand privacy considerations
AWS material that helps frame regional privacy and residency decisions in New Zealand deployments.
Read the privacy guidanceKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.