Healthcare Identifiers Service Integration Guide

What the HI Service is

The Healthcare Identifiers Service is operated by Services Australia under the Healthcare Identifiers Act 2010. It assigns and resolves three national identifiers: the IHI (Individual Healthcare Identifier) for patients, the HPI-I (Healthcare Provider Identifier – Individual) for clinicians, and the HPI-O (Healthcare Provider Identifier – Organisation) for healthcare organisations. Every My Health Record transaction, electronic prescription, and identifier-addressed secure message is keyed on them.

Almost nobody integrates with the HI Service for its own sake. It's a prerequisite: the My Health Record B2B services expect your software to have sourced and validated identifiers through it, and its conformance requirements are tested alongside My Health Record's in Notice of Connection testing.

The three identifiers, and what changes underneath them

• IHI — assigned automatically to everyone enrolled in Medicare or with the Department of Veterans' Affairs, plus people who request one. An IHI is 16 digits and is not a Medicare card number. Critically, an IHI record has two dimensions of state: a record status (verified, unverified, provisional) and a number status (active, deceased, retired, expired, resolved). Your software must handle all of them, not just 'active and verified'.
• HPI-I — identifies an individual provider. AHPRA-registered practitioners are assigned HPI-Is through their registration, but having one and it being locatable are different things, and non-AHPRA workers (many in aged care and community services) may have none.
• HPI-O — identifies the organisation, in a hierarchy: a seed organisation at the top, with optional network organisations underneath for sites and departments. Which HPI-O your software presents on a transaction is a design decision with conformance consequences, especially in multi-site groups.

Integration mechanics

The HI Service exposes SOAP web services over mutually authenticated TLS, using the organisation's NASH certificate — see NASH certificates explained for the credential side. Requests identify the organisation (HPI-O), the responsible user, and your product; responses come back with service messages your software is expected to surface, log, and act on.

Don't start from the WSDL. The Agency publishes the Healthcare Identifiers integration toolkit — sample client libraries for .NET and Java under the AuDigitalHealth GitHub organisation (also on NuGet) — which encode the request structure and signing behaviour the service expects. Development happens against the vendor test environment with supplied test data, arranged through the Digital Health Developer Portal.

Handling statuses, alerts and mismatches

The difference between a compliant integration and a dangerous one is what happens on the unhappy paths. The behaviours that matter:

• No match is an answer, not an error. The correct response is a workflow for staff to review demographics against the source document (Medicare card, ID) and retry — never silently proceeding without an IHI, and never loosening the search until something matches.
• 'Resolved', 'retired' and 'expired' IHIs must stop being used. Duplicates get resolved into a surviving IHI; your software needs to pick up the replacement and re-key its records, keeping an audit trail of the change.
• Deceased status needs deliberate handling — both suppressing inappropriate workflows and not broadcasting the status where it shouldn't appear.
• Alerts and service messages aren't noise. Duplicate and replica alerts, in particular, are the HI Service telling you two records may be the same person. They need a human-facing queue, not a log file.
• Store what you're permitted to store, with provenance. Keep the identifier, the date/time of validation, and the demographics as at validation — you'll need all three to implement currency windows and to answer 'why did this record have that IHI' later. The use and disclosure of healthcare identifiers is regulated under the Healthcare Identifiers Act; treat access control and audit logging as first-class requirements.

Conformance for HI Service integration

Products connecting to the HI Service go through Notice of Connection testing and HI conformance requirements before production access — in practice usually bundled with My Health Record testing, driven by the use cases you nominate on your Vendor Product Details form. The test cases exercise exactly the unhappy paths above: mismatch handling, status transitions, and alert behaviour. Current schemes and test specifications are on the developer portal; the ADHA conformance checklist covers how to plan the process.

Common failure modes and gotchas

• Treating the IHI as write-once. The classic bug: look up the IHI at registration, store it forever, never revalidate. Statuses change, duplicates get resolved, and demographics drift. Downstream systems (My Health Record uploads especially) reject stale identifiers, and you'll be debugging those rejections in the wrong place.
• Loosening demographics until something matches. Truncating names, dropping middle names, or trying date-of-birth permutations to 'help' the match rate is how identifiers end up on the wrong patient. The HI Service is strict on purpose; work with staff-verified demographics instead of fighting the matcher.
• Medicare card edge cases. Families share a card; the IRN (the position number beside the name) distinguishes individuals. Wrong-IRN lookups can still match convincingly at the demographic level — a notorious source of parent/child mix-ups. Card reissue changes the card number's final digit, which is not a new person.
• Newborns and patients without Medicare enrolment. Newborns may not have an IHI immediately; overseas visitors may never have one. Registration workflows need a compliant 'no IHI yet, retry later' state rather than blocking or fabricating.
• Assuming every clinician has a usable HPI-I. Locum arrangements, non-AHPRA staff, and providers who've never activated anything digital all surface as authorship problems when a document upload requires an HPI-I. Detect this at rostering/setup time, not at upload time.
• Ignoring the two-dimensional status model. An IHI can be active but unverified, or verified but retired. Logic that checks only one dimension passes SVT's happy paths and fails on production patients.
• Batch-refreshing everything, constantly. The opposite failure: re-validating your whole patient database daily hammers the service for no clinical benefit. Validate on a sensible currency window and at moments that matter — arrival, before an upload, before a prescription.