My Health Record System Integration

Two Fundamental Integration Steps

ntegrating with MHR generally involves two major phases: (1)  integration with the Healthcare Identifiers (HI) Service, and (2) integration with the My Health Record system itself. The Healthcare Identifiers Service is a national service that provides unique identifiers (e.g. IHI, HPI-I, HPI-O) for patients and providers, which your system must use to accurately identify individuals when transacting with MHR. Once the identifier integration is in place, your software can then connect to MHR’s B2B APIs. This step is the core of MHR integration, enabling data flow into the national record system. In practice, there are a number of prerequisites, registrations, certificates, and compliance checks to address. Below we break down the entire process into manageable steps.

Understanding Regulatory Requirements

The recent passage of the Modernising My Health Record (Sharing by Default) Act 2025 significantly changes the landscape for healthcare providers. While the specific rules and timelines are still being developed through stakeholder consultation, healthcare providers should prepare for mandatory sharing requirements for certain types of health information. This regulatory shift makes My Health Record integration not just beneficial but potentially mandatory for many healthcare providers.

Successful My Health Record system integration requires meeting certain regulatory requirements and registrations. As a healthcare business, you must ensure your organization and software are authorized and compliant before exchanging data with MHR. Key preparatory steps include:

1. Registering Your Organization and Obtaining Identifiers: Your healthcare business needs to be registered with the Healthcare Identifiers Service (HI Service) operated by Services Australia. This involves obtaining a Healthcare Provider Identifier – Organisation (HPI-O). If your organization is not yet in the HI Service, an authorized officer (usually the practice owner or manager acting as the Responsible Officer) should register the organization via PRODA/HPOS (Provider Digital Access / Health Professional Online Services). Once the organization is registered in the HI Service, it is issued an HPI-O number, and importantly “registering a seed organisation with the HI Service also registers the organisation for My Health Record”. In other words, the act of obtaining an HPI-O through HPOS automatically enrolls your organization as a participant in the My Health Record system. You will designate key roles in this process: a Responsible Officer (RO) and an Organisation Maintenance Officer (OMO), who are responsible for managing the HI Service and MHR participation for your organization.

2. Registering as an MHR Software Provider (if developing in-house): If you are building or customizing software to connect to MHR (as opposed to using an already-conformant product), you should register as a developer with the Australian Digital Health Agency (ADHA). ADHA provides a My Health Record Developer Program for software vendors. This usually involves downloading a Software Vendor Welcome Pack and filling out a Vendor Product Details form, which captures information about your product and the MHR functionality you plan to implement. You will submit this to the Agency’s developer support team. This is the first step toward initiating the formal testing and onboarding process with ADHA. (If you are a healthcare provider using a commercial software system, this step is handled by your software vendor, you can skip directly to obtaining certificates and configuring your system.)

3. Identity Verification (PRODA Account): To perform the above registrations, an authorized person in your business (e.g. the RO or OMO) will need a PRODA account. PRODA is an online identity verification and authentication system for access to government services like HPOS. Setting up a PRODA account requires verifying your identity with personal documents (e.g. passport, driver’s license, Medicare card). This is a quick process (about 10 minutes online) and is mandatory for linking to HPOS and managing your organization’s registrations. Ensure the PRODA registration details (name, DOB, etc.) exactly match your identity documents to avoid delays. Once PRODA is set up, you will link HPOS to your PRODA account, which allows access to the Health Identifiers and My Health Record services in HPOS. Through HPOS, the RO/OMO can register the organization in the HI Service (to get the HPI-O) by completing an online form. If your business has multiple sites or sub-entities, you might also register them as network organizations under your seed HPI-O (this can be done via HPOS as well).

4. Establishing a Security and Access Policy: Before actively using My Health Record, your organization must complete My Health Record system integration requirements including certificates and identifiers for security and access policy. The Office of the Australian Information Commissioner (OAIC), in collaboration with ADHA, provides a template policy to guide you. This policy outlines how your practice will ensure only authorized staff access the system, how patient consent and privacy will be handled, and how data will be protected. Make sure to develop and implement this internal policy and train your staff accordingly prior to going live.

Obtaining Certificates and Identifiers (NASH, HPI-I)

A crucial part of integration is obtaining the digital certificates and identifiers necessary for secure communication:

• NASH PKI Certificate: The National Authentication Service for Health certificate (NASH PKI) is required for any system-to-system connection with My Health Record and the HI Service. This is essentially a digital certificate for your organization that enables secure encryption, digital signing, and authentication when your software calls the MHR or HI Service APIs. You will request a NASH certificate via HPOS once your organization has an HPI-O and you (as OMO) are linked to it. The OMO uses their PRODA login to go to HPOS > Healthcare Identifiers/My Health Record section, then under your organization’s record, navigate to the Certificates tab and select “Request a NASH PKI site certificate”. You’ll need to provide a mobile number to receive a Personal Identification Code (PIC) via SMS when the certificate is ready. After the request, Services Australia will issue the NASH certificate (usually available to download from HPOS within a few days, and the SMS PIC is used to activate the download). Once downloaded, this certificate (a file with a .p12 or similar extension) must be installed/imported into your clinical software or system keystore.
  Note: NASH certificates have an expiry (usually 2 years), so you will need to renew it and update your software periodically. The NASH certificate is used for accessing both MHR and the HI Service, and also for other digital health functions like Secure Message Delivery and electronic prescribing.

• Individual Healthcare Identifiers (IHIs and HPI-Is): In addition to the organization’s HPI-O, you will use individual identifiers in the workflow. Every patient whose record you access will be identified by their Individual Healthcare Identifier (IHI), a unique 16-digit number. Your software can connect to the HI Service to look up a patient’s IHI using their personal details. This is typically a prerequisite step before accessing or uploading to their My Health Record, to ensure you are using the exact correct identifier for that person. Likewise, each healthcare provider (doctor, nurse, etc.) in your practice should have a Healthcare Provider Identifier – Individual (HPI-I). Healthcare professionals in Australia obtain an HPI-I automatically if they are registered with AHPRA (Australian Health Practitioner Regulation Agency); the HPI-I can be looked up via the HI Service by using the provider’s AHPRA registration number or name. Make sure to record each clinician’s HPI-I in your system’s user settings/configuration so that any MHR transactions include the proper provider identifier. Many clinical software systems have a field for HPI-I in the user profile, populating this is critical because My Health Record transactions typically include both the organization’s HPI-O and the accessing clinician’s HPI-I for audit and access control purposes.

• Test Certificates vs. Production Certificates: During development and testing (covered in the next section), you will use test certificates. ADHA and Services Australia issue Test NASH certificates and Test Data for use in the Software Vendor Test (SVT) environments. These are separate from your live production NASH certificate. To get a test certificate, you fill out a form (e.g. the “Application to Request a NASH PKI Test Certificate”) and submit it to Services Australia’s developer liaison. This usually happens in parallel with your developer registration, it is better to initiate that early since there is some turnaround time to get test credentials. Once you have a test NASH certificate, you install it in your development environment or integrate it into your software code to start building and integrating the APIs. When you later go live, you will switch to the production NASH certificate obtained via HPOS as described above.

Development, Conformance Testing, and MHR Integration Process

If your healthcare business is using an existing conformant software system, you won’t need to do custom development, you can skip to configuration and ensure your vendor has handled this process. However, if you are developing your own integration (or significantly extending a system), you must follow ADHA’s process for testing and conformance before being allowed to connect to the real My Health Record system. There are two primary testing phases for software integration:

1. Notice of Connection (NoC) Testings: This is a formal test of the web service interactions between your software and the Healthcare Identifier and My Health Record systems. It ensures your product can connect to HI’s and MHR’s B2B gateway and perform operations correctly in a controlled test environment. To initiate NoC testing, you will need to have submitted the Vendor Product Details (VPD) form (from the Welcome Pack) to ADHA, expressing your intent to connect. Once ADHA receives your details, their testing partner will provide you with a Test Data Pack, including specific test cases and dummy patient data tailored to the features you intend to implement. There are two NoC tests required: one with the HI system and another with the MHR system. If all goes well, they will issue a Declaration of Notice of Connection for your software version, indicating it has passed this stage. This declaration is needed to progress to production access.

2. Conformance, Compliance and Declaration (CCD) Testings: Beyond connectivity, ADHA also mandates that your system conforms to various technical specifications and standards related to My Health Record. This covers things like the correct formatting of clinical documents (using CDA standards), proper implementation of views, security requirements, usability guidelines, etc. The My Health Record Conformance Profiles and test specifications are published by ADHA and serve as the benchmark. Conformance testing is largely a self-driven process by the software developer. You will use ADHA’s Conformance Test Specifications to run through all necessary scenarios and ensure your product meets each requirement. For example, there are test specs for Connecting Systems (ensuring you handle error cases, timeouts, authentication correctly), for Clinical Documents (ensuring your CDA documents are structured and coded properly), for Views (how data like medications are displayed), etc. ADHA provides tools such as the Clinical Package Validator (CPV) to help automatically validate the conformance of your CDA documents and packages. After completing your internal testing, you will fill out a Conformance Vendor Declaration form, a legal declaration that your software conforms to all required specifications. After that there will be a live conformance testing session in which your software will be observed. Essentially, you are attesting that the product is compliant, and you assume ongoing obligations to maintain that compliance. This declaration (along with evidence of test results, and possibly additional documentation like test reports if required) is submitted to ADHA for final approval.

Only after both the NoC testing and the Conformance Declaration are successfully completed will your software product be permitted to connect to the production My Health Record system. At that point, ADHA (the system operator) may update their Conformance Register to include your product/version as a My Health Record–connected system. Your organization can then proceed to Go-Live by configuring the production endpoints and using your production NASH certificate.

Tip: ADHA’s Developer Portal and support team provide extensive guidance during this process. Make use of the sample code libraries (available on GitHub/NuGet for .NET and Java), and don’t hesitate to reach out to the Agency’s developer liaison for clarifications. The overall process can take some time (several weeks to a few months), so plan accordingly and start early, especially with registrations and certificate requests that have lead times.

Working with the My Health Record API: Technical Aspects of Integration

At present, the My Health Record system is built on SOAP-based web services. All B2B integration uses SOAP APIs (with WS-Security and NASH certificate authentication), not REST. Similarly, when uploading clinical content, your system must generate documents in the Clinical Document Architecture (CDA) format, following templates such as Shared Health Summary, Event Summary, Discharge Summary, etc. These CDA XML files are then transmitted via the SOAP APIs to My Health Record. While ADHA is exploring modern standards like FHIR, the current production environment for My Health Record integration remains SOAP + CDA.

With preliminaries addressed, the technical implementation can begin. Integrating with MHR B2B involves working with several components and standards:

• My Health Record B2B Gateway APIs: The MHR system exposes a set of web services (APIs) for B2B integration. These are SOAP-based web services (with XML payloads) defined by the older PCEHR specifications. Key services include:

  • Patient Record Query Services: e.g. “Find Record” to check if a patient has a My Health Record (using their IHI), and “Get Record Access” (often called GainPCEHRAccess) to establish access for the organization to a patient’s record. In practice, since the system is opt-out, most patients will have a record unless they opted out, but your system can explicitly verify existence. If a patient’s record is not automatically accessible (e.g. if they have set access restrictions), a provider can invoke an emergency access (break-glass) procedure via the API which requires declaring a reason.

  • Document Listing and Retrieval: e.g. “GetDocumentList” to fetch a list of documents available in a patient’s record, “ViewDocument” or “GetDocument” to download a specific clinical document (like a PDF or CDA XML), and “GetView” to retrieve aggregated views (such as a consolidated medications view or immunisation view).

  • Document Upload and Management: e.g. “UploadDocument” to upload a new clinical document into a patient’s My Health Record, “SupersedeDocument” to replace a previously uploaded document with a newer version (while keeping history), and “RemoveDocument” to remove (effectively delist) a document from the record(for instance, if added in error).

• These web services use standards like SOAP with WS-Security. Each request must be secured with your NASH certificate (for mutual TLS and request signing) and will include identifiers (HPI-O, HPI-I, IHI) in the headers or body. ADHA’s developer documentation provides WSDLs and specifications for each service, and even sample code to demonstrate how to call them. For example, if using C# or Java, you can use the provided proxy classes to construct and send requests, if not, you have to implement your own functionalities to generate the right request.
  Clinical Document Format: Note that when uploading documents, they must be in CDA (Clinical Document Architecture) format conformant to My Health Record templates (e.g. Shared Health Summary, Event Summary, Discharge Summary, etc.). Generating a CDA XML document requires assembling patient data (demographics, clinical content like medications, diagnoses, etc.) into the specific structured format. ADHA provides template packages and libraries for CDA creation. This can be one of the more technically complex parts of integration, so plan for adequate development and testing time to get document formats right (using tools like the Clinical Package Validator).

• Healthcare Identifiers (HI) Service Integration: As mentioned, a prerequisite to any MHR transaction is being able to interact with the HI Service. The HI Service itself provides a set of web service APIs (also SOAP-based) for looking up and validating identifiers. Your software will typically use the HI Service to:

  • Retrieve IHI for a patient: using demographics (name, DOB, Medicare number, etc.) to find the unique IHI. This ensures you are using an exact identifier, critical because using the wrong IHI could lead to accessing or uploading data to the wrong record, a serious safety issue and will be denied by the MHR.

  • Lookup HPI-I or HPI-O: e.g. find a provider’s HPI-I by their AHPRA number, or confirm an organization’s HPI-O. This might be used when configuring your system or if your software needs to verify external providers’ identifiers (for example, when sending referrals or creating documents that reference other providers like a GP or an agedcare).

• Access to the HI Service requires the NASH certificate (as of 2019, NASH replaced the old Medicare site certificates for HI access). In your software’s architecture, you might create a module or service client dedicated to the HI Service. The lookup can be done in real-time when registering a new patient or user, or cached as appropriate. ADHA’s developer guides emphasize implementing IHI validation in your system’s workflow, for example, prompting the user to do an IHI search when adding a new patient record to ensure the IHI is captured upfront.

• Software Solution Architecture: When you start the B2B integration, ADHA will ask you to provide your Software Solution Architecture Document for review and validation. They will then give you feedback on how your system should be correctly architected.

Testing Process Summary: HI First, Then MHR

To sum up, the critical procedural detail is that you must complete Notice of Connection (NoC) testing and Conformance testing twice:

1. With the Healthcare Identifiers (HI) Service

   • Before you can integrate with My Health Record, your software must demonstrate it can correctly connect to and use the HI Service (to look up IHIs, HPI-Is, HPI-Os).

   • This involves passing a Notice of Connection (NoC) test: you’ll be provided test cases, along with test data and test certificates. Your task is to run the scenarios, capture the SOAP requests and responses, and submit them as evidence that your system can connect and interoperate correctly.

   • After the NoC is complete, you conduct Conformance testing against the HI Service’s specifications (often using ADHA’s conformance test documents). You’ll then submit a Conformance Vendor Declaration stating your system complies.

2. With the My Health Record (MHR) System

   • Once HI Service integration is proven, you repeat the same two phases with My Health Record itself:

     • A Notice of Connection (NoC) test for MHR’s B2B APIs (again, you’ll be given a test plan, test patients, and test certificates; you must demonstrate connection by executing and capturing requests/responses).

     • Then a Conformance, Compliance, and Declaration (CCD) phase, where you self-test against the MHR conformance test specifications (covering CDA formatting, API usage, security, and usability requirements).

Only after passing both HI and MHR NoC + Conformance stages is your software permitted to connect to the live production environment.

Future Considerations and Strategic Planning

FHIR Transition Preparation

The My Health Record system is transitioning from CDA to FHIR standards to support real-time, interoperable health solutions. Healthcare provider businesses should consider this transition in their long-term technology planning, as FHIR-based integration will become the preferred approach over the current SOAP/CDA implementation for future digital health initiatives.

Allied Health Integration Expansion

The Australian Digital Health Agency is actively expanding My Health Record access to allied health professionals through vendor partnerships. This expansion represents opportunities for comprehensive care team integration and enhanced patient care coordination across multiple healthcare disciplines.

Regulatory Compliance Evolution

Stay informed about the development of Sharing by Default Rules, which will specify mandatory sharing requirements for different types of healthcare providers. Early preparation for these requirements will position your organisation advantageously as regulations evolve.

My Health Record B2B system integration represents a significant strategic investment for healthcare provider businesses, requiring careful planning, substantial technical implementation using CDA/SOAP technologies, and rigorous sequential NoC testing with both HI Service and My Health Record systems. Success requires thorough preparation, appropriate resource allocation for SOAP web service development, meticulous test case execution and documentation, and commitment to ongoing maintenance and evolution of your digital health capabilities.