Australian governance starts with identifiers and specialty-system expectations
In Australia, imaging archives do not operate in a policy vacuum. Identity, specialty-system obligations, and information-sharing rules all shape what the VNA is allowed to store, how it links reports, and which identifiers it should trust.
Australian policy signals that affect VNA design
| Policy area | Why it matters | Typical design response |
|---|---|---|
| Healthcare identifiers | Clinical systems need a coherent patient-identity model | Align archive identity resolution with enterprise and national identifier policy |
| Specialty systems | Diagnostic imaging systems are expected to support standards-based exchange | Keep DICOM and report-linkage paths explicit |
| My Health Record reforms | Written report sharing expectations change operating workflows | Preserve report linkage and export readiness alongside the image archive |
Healthcare identifiers
Australian Government overview of the Healthcare Identifiers Service and how identifiers are used in clinical systems.
Read the Healthcare Identifiers overviewSpecialty systems
Australian Digital Health Agency guidance for diagnostic imaging and other specialty systems, including standards expectations.
Read the specialty-system guidanceNational service integration requires authenticated identity and publication workflows
Australian imaging platforms often need more than local archive logic. They may have to validate or look up an Individual Healthcare Identifier through the HI Service, use NASH credentials for protected interactions, and publish report-linked outputs through My Health Record boundaries that are separate from the pixel archive itself.
Identity validation and report publication boundary
Loading diagram...
Boundary reminder
The VNA is still the authoritative imaging archive. National-service integration sits at the identity and report-publication boundary, not in place of archive stewardship.
HI Service - IHI Lookup
Australian implementer guidance for IHI lookup payloads, validation rules, and response expectations.
Read the HI Service IHI lookup guideNASH SHA-2 Certificates - Developer Guide
Developer guidance for NASH certificate use in protected national-health integrations.
Read the NASH SHA-2 developer guideMy Health Record B2B Gateway - Upload document
Implementer guidance for document upload workflows through the My Health Record B2B Gateway.
Read the upload document guideResidency, retention, and destruction need explicit policy controls
Archive governance is not finished once a team picks an Australian region. The platform still needs explicit rules for where identifiable data can live, when it may move, and what evidence is retained when a record finally reaches an authorized destruction state.
Governed retention and destruction control loop
Loading diagram...
Architecture inference
The exact retention period is jurisdiction- and provider-specific, so the safe architectural pattern is to make destruction an explicit governed event with recorded evidence rather than a blind age-based lifecycle rule.
REQ1: Data residency
AWS data-residency guidance for architectures that have to keep personal data in a required jurisdiction.
Read the AWS data residency guidanceData retention
AWS healthcare industry lens guidance for aligning retention policy with legal, compliance, and business requirements.
Read the AWS healthcare retention guidanceManaging the lifecycle of objects
S3 lifecycle documentation for the storage mechanics that may sit underneath a governed retention policy.
Read the S3 lifecycle documentationKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.