IHI Numbers in Australia: Privacy and Compliance for Businesses

If your business operates in or around the health sector in Australia, there’s a good chance you’ve heard of Individual Healthcare Identifiers (IHIs). They’re a key part of Australia’s digital health system and play a big role in patient safety and continuity of care.

But IHIs also come with strict privacy and security requirements. If you’re unsure when you can collect or use an IHI, or what policies you need in place to stay compliant, you’re not alone - the rules can be tricky if you don’t deal with them every day.

In this guide, we’ll break down what an IHI is, when businesses can lawfully handle them, the privacy laws that apply, and the practical steps you can take to protect your business and your patients’ information.

What Is An Individual Healthcare Identifier (IHI)?

An Individual Healthcare Identifier (IHI) is a unique 16‑digit number assigned to every person who receives healthcare in Australia. It’s used to match the right health information to the right person across different providers and systems (for example, in My Health Record and e‑health platforms).

IHIs are created and managed under the Healthcare Identifiers Act 2010 (Cth). They’re not a general ID number - the law limits how they can be collected, used and disclosed. That limitation is what makes IHI compliance a distinct piece of your privacy program, separate from day‑to‑day customer data handling.

When Can Businesses Handle IHIs?

Not every business can collect or use an IHI. Generally, only health service providers (and certain organisations that support them) should ever need to handle IHIs. Even then, the purpose must be directly related to providing healthcare or operating an e‑health system lawfully.

Typical scenarios where handling IHIs is permitted

• Verifying a patient’s identity within a clinical record system or My Health Record integration.
• Exchanging information with other treating providers (for example, referrals or shared care) where the IHI supports accurate matching.
• Operating a healthcare information system or secure messaging service as an authorised operator or contracted service provider to a health service.

Situations where handling IHIs is not permitted

• Using IHIs for marketing, customer profiling, or loyalty programs.
• Collecting IHIs “just in case” when your business is not a health service provider or does not need IHIs to deliver care.
• Disclosing IHIs to third parties who are not authorised or do not have a lawful purpose related to healthcare.

If your business model sits near the boundary (for example, health-adjacent technology, wearables, or health research support), it’s wise to get advice on whether you’re a “health service provider” for privacy law purposes and whether you may handle IHIs at all.

What Privacy Laws Apply To IHIs?

When it comes to IHIs, several laws work together. It’s important to understand how they overlap so you can build one, coherent compliance approach.

Healthcare Identifiers Act 2010 (Cth)

This Act creates the IHI system and tightly regulates who can collect, use, and disclose IHIs, and for what purposes. Breaches can lead to serious penalties. If you handle IHIs, you need processes to ensure they’re only used for permitted, healthcare‑related purposes.

My Health Records Act 2012 (Cth)

If you connect to or use My Health Record, this Act adds additional obligations around access controls, audit, security, and notifications. It also defines strict rules on when you can view or upload information - including when an IHI is used to match an individual’s record.

Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs)

Under the Privacy Act, health information is “sensitive information,” which is subject to higher standards. IHIs are also “identifiers,” and the APPs place limits on how you can adopt, use or disclose identifiers assigned by government agencies.

In practice, this means you must have a lawful basis and a clear need for handling IHIs, and you must meet the APPs for collection, consent (where relevant), security, access and correction, and disclosure.

Security and breach notification

Given the sensitivity of health information, your security controls should be proportionate to the risk. If you experience a data breach that is likely to result in serious harm, the Notifiable Data Breaches (NDB) scheme requires assessment and, where necessary, notification to the OAIC and affected individuals.

How Do I Build A Practical IHI Compliance Program?

Compliance doesn’t have to be complicated. The key is to translate legal requirements into daily processes, supported by clear documentation and training. Here’s a practical roadmap you can adapt to your business.

1) Map your data flows

• Identify where and how IHIs enter your systems (e.g. intake forms, secure messaging, system integrations).
• Document who accesses IHIs (roles, not individual names), why they need access, and where IHIs are stored.
• Note any external parties (cloud providers, software vendors) that may process IHIs on your behalf.

2) Define lawful purposes and limit collection

• Write down the specific, permitted purposes for which your business will collect and use IHIs.
• Configure forms and systems to avoid collecting IHIs unless they’re strictly necessary for the health service you provide.
• Ensure IHIs are never used for marketing, analytics, or any non‑clinical purpose.

3) Build security controls around the data

• Enforce least‑privilege access - only staff who genuinely need IHIs to do their job should have access.
• Apply technical safeguards (MFA, encryption at rest and in transit, audit logs, role‑based access).
• Set up vendor and integration due diligence for any system that stores or transmits IHIs.

4) Embed privacy by design

• Before launching new features or integrations, complete a short privacy assessment focused on IHIs (e.g. a lightweight Privacy Impact Assessment Plan).
• Minimise what you retain: store the IHI only where it’s needed and for as long as required by law and clinical practice.
• Where possible, segregate IHI data from non‑health data to reduce the risk profile.

5) Train your team and set rules

• Provide regular training for clinical and administrative staff on permitted IHI use and common pitfalls.
• Document procedures for identity verification, access, corrections and disclosures.
• Make it easy for staff to report suspected incidents early.

6) Prepare for incidents

• Have a clear incident response playbook that aligns with the NDB scheme and your clinical risk processes.
• Test your response steps yearly so you can act quickly if something goes wrong.
• Keep an up‑to‑date Data Breach Response Plan and assign roles in advance.

What Policies And Documents Will I Need?

Policies turn your compliance intent into day‑to‑day practice. The exact suite you’ll need depends on your operations, but the following are common for health service providers and health‑tech businesses working with IHIs.

• Privacy Policy (Health Service Provider): Explains how you collect, use and disclose health information and IHIs, including access/correction rights and complaints.
• Privacy Collection Notice: Short notices on forms or portals to tell patients why you’re collecting IHIs and how they’ll be used.
• Information Security Policy: Sets out your technical and organisational security measures, acceptable use, access control, and incident handling.
• Data Processing Agreement: Contract terms with software vendors and other processors to ensure they handle IHIs lawfully and securely on your behalf.
• Data Breach Response Plan: A step‑by‑step playbook to triage, assess and notify if there’s a suspected breach involving IHIs or other health information.
• Privacy Policy: If you’re not a clinical provider but still handle personal information, ensure your general policy covers any interaction with IHIs (or states that you do not collect them).
• Privacy Complaint Handling Procedure: A clear internal process so complaints are acknowledged, investigated and resolved within APP timeframes.

These documents should match how your business actually works. If you’re integrating with a PMS, secure messaging, or My Health Record, your policies should speak to those environments and the safeguards you use.

Common IHI Compliance Mistakes (And How To Avoid Them)

Small oversights can create big risks when healthcare data is involved. Here are the missteps we see most often - plus simple fixes.

Collecting IHIs “just in case”

Collect the minimum necessary. If you don’t need the IHI to deliver your service, don’t collect it. Update intake forms and API configurations to reflect this.

Using IHIs for non‑clinical purposes

IHIs are not marketing or analytics IDs. Keep them out of CRM fields, email marketing tools and any non‑clinical reporting.

Assuming vendors are compliant by default

Don’t rely on a vendor’s brand name alone. Build due diligence into procurement and include robust security and privacy terms in your Data Processing Agreement.

Unclear staff responsibilities

Everyone should know when they can access an IHI, how to verify patients, and what to do if there’s an error. Train regularly and maintain an accessible, up‑to‑date Information Security Policy.

Policies that don’t match practice

It’s not enough to have a policy - it must reflect reality. If you change systems or workflows, update your Privacy Policy (Health Service Provider) and procedures, and consider a focused Privacy Impact Assessment Plan for the change.

Key Takeaways

• IHIs are unique identifiers used in Australian healthcare and are tightly regulated - only collect and use them for permitted, healthcare‑related purposes.
• Expect overlapping obligations under the Healthcare Identifiers Act, My Health Records Act and the Privacy Act (APPs), with higher standards applying to health information.
• Build a practical compliance program: map data flows, limit collection, enforce access controls, train staff, and prepare for incidents with a clear plan.
• Put the right documents in place, including a tailored Privacy Policy (Health Service Provider), Information Security Policy, and Data Breach Response Plan, supported by robust vendor terms.
• Avoid common pitfalls such as over‑collection, non‑clinical use of IHIs, weak vendor oversight, and policies that don’t reflect real practices.
• If you’re unsure whether your business should handle IHIs at all, or how to design compliant processes, getting early legal guidance will save time and reduce risk.

If you’d like a consultation on IHI privacy compliance for your Australian business, you can reach us at 1800 730 617 or team@sprintlaw.com.au for a free, no‑obligations chat.