The purpose of this page is to provide guidance to developers who are implementing the new interoperability standards for secure messaging thus enabling clinical information systems (CISs) and secure messaging (SM) systems to find healthcare providers as well as accurately address and securely exchange standards-based messages.
Provider Directory Service & Message Payload Developer Guide
This document is intended to provide practical implementation guidance to developers who are enabling clinical information systems (CISs) and secure messaging (SM) systems to securely exchange standards-based messages. This document can be downloaded here:
dh-2949-2019-provider-directory-service-message-payload-developer-guide-v1.4.pdf [Updated 9 September 2019]
How to test your implementation
How to connect to the test environments and receive test certificates
- Requesting NASH test certificates
Please complete and return the 2 forms below and return to [email protected] Note that a processing time of approximately 2 weeks is required.
- Supporting Resources
Australian Profile for Provider Directory Services
This guide covers capability requirements of FHIR® services to implement a set of profiles and support interfaces in an Australian context for the purpose of implementation of provider directory services.
- Message Payload format Patient Referral Message (REF-I12)
The Australian Referral Message has both constrained and also extended the HL7 International version to allow transmission of a full patient history in one message including referral information, patient summary, allergies, medication history and patient care. For detailed information on the message structure please consult Australian Diagnostics and Referral Messaging – Localisation of HL7 Version 2.4:
- Patient Referral Response Message (RRI-I12)
On receiving a REF^I12 message a system must produce a RRI^I12 response with the following message structure. The purpose of this message is to inform the originating referrer of the RF1-11 External Referral Identifier allocated by the receiving system. Receivers must not return clinical information to the originating referrer such as reports or results in the Referral Response Information (RRI).
For detailed information on the message structure please consult Australian Diagnostics and Referral Messaging – Localisation of HL7 Version 2.4: https://confluence.hl7australia.com/display/OOADRM20181/7+Patient+Referral#id-7PatientReferral-7.2.2PatientReferralAcknowledgementMessagestructure(RRI_I12)
- Master Data Management Message (MDM-T02)
The HL7 v2 MDM message fields shall follow in accordance with the HL7 2.3.1 Australian Standards (AS4700, parts 1, 2 and 6), or the HL7 2.3.1 International Standard, where the Australian Standards do not apply.
The HL7 v2 MDM^T02 v2 message shall only be used for transporting the CDA package using a single OBX segment, and SHALL NOT contain any other OBX segments that contain another format of the same data (e.g. RTF, PDF or text).
All relevant documents SHALL be contained inside the CDA package. For detailed information on the message structure please consult: Clarification on Messaging and CDA Packaging
- Common Conformance Profile v1.7
This document provides conformance requirements applicable to all types of clinical documents. This includes references to other documents containing additional normative content.
- eReferral v1.4
An eReferral facilitates the seamless exchange of significant patient information from one treating healthcare provider to another.
- Specialist Letter v1.3
Specialist Letter documents are used in replying to a referral or reporting on a health event and contain information related to the event or the requested diagnosis or treatment by a specialist.
- eDischarge Summary v1.5
eDischarge Summary supports the transfer of a patient from the hospital to their primary physician
- Clinical documents – FAQ
This FAQ describes an extension to these eDischarge Summary, eReferral and Specialist Letter that involves encapsulating the CDA package within an HL7 v2 MDM^T02 message (which covers the delivery of a document). Using this technique, the message payload can be transported through SMD messaging systems and other messaging networks designed to transport HL7 v2 messages.
Development and Testing Support
To find out more about Secure Messaging visit the Secure Messaging product guide.