Go to top of page

Testing

There are two types of testing required to validate your software product for connection to the My Health Record system. These are:

  • Conformance and compliance testing. Your own internal self-assessment testing in preparation for Conformance, Compliance and Declaration (CCD); and
  • Notice of Connection (NOC) testing. Testing your software using test cases and test data provided by, and observed by the National Infrastructure Operator (NIO).

All software products must successfully pass these testing requirements before gaining access to the My Health Record production system.

My Health Record Notice of Connection (NOC)

All software products need to pass NOC testing. NOC testing confirms that your software product performs according to the specified standards and conformance points defined in the technical and logical service specification documents. These documents are referenced within each implementation guide available here on the Developer Centre. 

Once you have submitted the Software Vendor Product Details Form to the NIO at [email protected], the NIO will send you a test plan, which includes the services nominated for use during the NOC process. You will be required to submit self-assessment of all relevant test cases, and the NIO will also conduct an observed NOC session. When this process is completed successfully, the NIO will issue you with a My Health Record Declaration of Notice of Connection for the specific version of your product that has been tested.

My Health Record Compliance, Conformance and Declaration (CCD) Testing

Conformance and compliance testing supports the safe and secure implementation and use of the My Health Record system as part of the CCD process. The CCD process requires that your software conforms to all applicable conformance profiles and the specifications they reference, and the conformance requirements for My Health Record Connecting Systems (Specifications), prior to your software being granted connection to the My Health Record system. Furthermore, you are required to maintain compliance following connection of your product to the production environment.

You verify conformance of your software product by conducting self-assessment testing using the conformance test specifications that are also available applicable to your specific scope (available in the Developer Centre), in conjunction with the Clinical Package Validator tool. You are required to retain evidence of the tests performed during self-assessment testing.

This testing takes the form of self-assessment, and then a declaration (in the form of a Deed that you may need to obtain legal advice on prior to executing). Your software must pass the conformance test specifications, and you need to record the test results in the conformance test specifications.

Conformance Test Specifications have been developed to support your self-assessment. These will vary according to your specific development scope. However, here are some key ones:

Conformance Test Specification

Available here:

PCEHR Connecting Systems - Conformance Test Specification v1.6

https://developer.digitalhealth.gov.au/specifications/national-infrastructure/ep-2156-2015/nehta-1299-2012

Clinical Documents - Conformance Test Specification for My Health Record Usability

https://developer.digitalhealth.gov.au/specifications/clinical-documents/ep-2807-2019/nehta-2063-2015

Clinical Documents - Conformance Test Specification for PCEHR Views v1.0

https://developer.digitalhealth.gov.au/specifications/clinical-documents/ep-2807-2019/nehta-2189-2015

Common - Clinical Document - Conformance Test Specification for Authoring Systems v1.0

https://developer.digitalhealth.gov.au/specifications/clinical-documents/ep-2395-2016/dh-2209-2017

Clinical Documents - Conformance Test Specification for Clinical Documents v1.2

https://developer.digitalhealth.gov.au/specifications/clinical-documents/ep-2320-2016/nehta-1329-2012

eHealth Diagnostic Imaging Report - Conformance Test Specification v1.0

https://developer.digitalhealth.gov.au/specifications/clinical-documents/ep-2455-2016/dh-2526-2017

eHealth Pathology Report - Conformance Test Specification v1.0

https://developer.digitalhealth.gov.au/specifications/clinical-documents/ep-2454-2017/dh-2525-2017

Clinical Documents - Conformance Test Specification for CDA Packaging v1.5

https://developer.digitalhealth.gov.au/specifications/clinical-documents/ep-2395-2016/nehta-2065-2015

Clinical Documents - Conformance Test Specification for CDA Rendering v1.4

https://developer.digitalhealth.gov.au/specifications/clinical-documents/ep-2807-2019/nehta-2064-2016

My Health Record Compliance, Conformance and Declaration (CCD) Testing - Test Data

Conformance Test Data required for performing some of the testing can be downloaded here; Note that they are to be used for the sole purpose of the CCD testing for the Conformance Requirements and Conformance Test Specifications listed below. Please use the test data sent by Human Services OTS LIaison for My Health Record NOC and other testing.

Clinical Package Validator (inc. Template Package Libraries and IQ Rules)

  • The Clinical Package Validator is a tool to automate some of the tests needed to assess conformance of clinical documents and clinical packages with the eHealth Specifications. The Clinical Package Validator (CPV) does not test conformance against all specifications. The product data sheet for the CPV lists the tests that are supported, tests partially supported, and a general description of the types of tests not supported. In order to validate a specific document type using the CPV, you will be required to load in the relevant template package. The Information Quality Rules (IQ Rules) is a set of rules that can be loaded into the CPV to further help developers, testers and analysts determine the conformance of clinical documents to the My Health Record system conformance requirements. It should be used in addition to the CPV tests. Learn more

Re-testing

When a software vendor makes changes to their products which adds/removes or updates My Health Record system functionality or materially changes the interaction with the system, the software vendor is required to re-complete the NOC and CCD process with an incremented version number for the software.

Triggers for subsequent registration may be:

  •   The development of new functionality;
  •   Upgrading conformance to a newer version of specifications; or,
  •   Development in response to an identified software error.

In all cases the software version in the SOAP header must be updated, and the product version declared.

My Health Record NOC testing may be required prior to the version being whitelisted in the system.