Skip to main content
Created date
Updated date

The following frequently asked questions relate to the use of Healthcare Identifiers in Health Software Systems.

How to gain access to the Healthcare Identifiers Service (HI) Service Software Vendor Test (SVT) Environment

To gain access to the HI Service Software Vendor Test (SVT) Environment you will need to register on the Health Systems Developer Portal provided by Services Australia. HI Service - Registration and Certificates

What is the conformance assessment process for healthcare identifiers?

To minimise the risk to clinical safety, privacy, and security arising from the use of healthcare identifiers, software systems must undergo testing before being approved to connect with the HI Service. There are two mandatory testing processes that must be completed:

  1. Services Australia’s Notice of Connection (NOC) 
  2. HI Service Conformance testing with the Australian Digital Health Agency (the Agency)

When should I contact the Agency?  

It is highly recommended that you to email the Agency as soon as you decide to integrate your application with the HI Service. This is to ensure we are able to assist you with your development and testing process and address any issues you may be experiencing. 

 What are the first steps to undergoing conformance testing?  

Before undergoing HI Service conformance testing, your first step is to complete the Healthcare Identifiers Notice of Connection (HI NoC) Testing with Services Australia. Information about the HI NOC testing can be found on the Services Australia website

To commence the second step of your HI Service conformance testing with the Agency, you will need to complete and submit the following documentation: 

  • Healthcare Identifiers Implementation Conformance Statement (ICS). This form identifies the use cases and associated requirements you are implementing. 
  • Conformance Test Specification (CTS). This contains all the test cases that you are required to undertake for the use cases you are implementing. 

    These forms can be obtained by emailing: [email protected]

Which business use cases apply to my software system?  

The business use cases that apply depend on the scope of your software system. For example, software systems designed for front office administration purposes might apply the HI Service business use case 10 (UC.010: register patient) and business case 15 (UC.015: update patient health record). Back office batch software might apply business use case 25 (UC.025: bulk update of IHI details). For information on the use case see the Software Conformance Requirements 

How long does testing take?  

Testing will depend on the set of use cases you have implemented. Typically, testing can take between 2-5 days, and has three phases: 

  1.  Initial planning session. This includes confirming the full scope of testing and completing a brief tour of your system to gain a better understanding of various workflows, usually requiring 1 day.
  2.  Conformance process. This consists of a formal test run against all requirements you have identified in the ICS.  Retesting may be required if any issues are identified. This phase can take 1-4 business days. 
  3.  Review and analysis of test results. Upon completion of all test requirements, the Agency test analyst will complete the Conformance Test Summary, usually requiring 1.5 days.

How will testing be performed? 

The Agency test team will be observing remotely via Microsoft Teams for the duration of the assessment. If you have any issues with this arrangement, please contact [email protected].

My application does not meet all the mandatory requirements in a business use case I am implementing. Is this a problem during testing? 

Requirements are categorised as either mandatory, conditional, or recommended. 

  • You must conform to all mandatory requirements in a business use case to ensure successful test outcome. 
  • Any conditional requirement are conditional in the context of the business use case you are implementing. If the condition is present, the requirement must be met. 
  • Recommended requirements are additional test cases a software developer can choose to implement. If you have selected recommended requirements, the Agency test analyst will conduct the necessary testing. It is good policy for health software to conform to recommended requirements for best practice.

What do the Agency test analysts need?  

The testing will be conducted solely by the software developer whilst an Agency test analyst observes remotely for the duration of the short dry run and formal test execution. 

The Agency test analyst will require a technical liaison developer to be present for the duration of the testing. This will ensure that all complex test cases and enquiries relating to simulating scenarios can be resolved in a timely manner.

Do I require a separate test environment built prior to testing? 

Yes. We recommend testing is conducted in a separate test environment, not your development environment. The test environment will need to support video-conferencing or desk-top sharing (like TEAMS or ZOOM etc.) so the Agency test analysts can observe the software being tested.

Should we complete a self-test prior to scheduled testing date? 

Yes. You will need to execute the tests yourself and submit the completed Conformance Test Specification to the Agency with the Implementation Conformance Statement to ensure you are ready to book in for Conformance testing. Sample test data can be located in the test data spreadsheets – Conformance Test Data for Healthcare Identifiers v3.0 (Updated September 2022) and HPII test data with AHPRA numbers.

Common issues identified during testing 

  • Mandatory requirements - You must comply with all mandatory requirements, even if you think the data you retrieve from the HI Service is not required. The requirements are specifically designed to capture problems within the HI Service such as duplicate IHIs.
  • Warnings and alerts - The requirements use the terms ‘Warning’ and ‘Alert’ in very specific scenarios. For example, an alert must place a complete halt on the operator’s activity sequence and cause an action to be completed to acknowledge the alert before proceeding.
  • Audit and error logs - It is important to read the requirements carefully to ensure mandatory and conditional requirements are met. Audit and error logs are intentionally designed to aid troubleshooting in the event that issues are found in the HI Service data.
  • Resolved status - Many software developers fail the test cases for resolved status. In many cases, if an operator receives a resolved number status from the HI Service, they are required to revalidate the new number before replacing the old number.
  • Failed test cases - If any issues are identified, the Agency test analyst will discuss them with you after the tests have been completed. Once you have made the required changes to your software, retesting can be conducted. The Agency test analyst will continue to work with you until you achieve a conformant test report.

Back - Healthcare Identifiers (HI Service)