General
How can we learn more about the NSMN and how our solution can participate in it?
The Resources section of the National Secure Messaging Network web page contains more information.
NSMN solution design
How does a Sending System determine if a Receiving System supports secure messaging?
Before sending a secure message, the Sending System must check whether the Receiving System is able to receive a secure message generated by the Sending System. There are three steps involved, using information about the Receiving System retrieved from a Provider Directory:
- Check that the Receiving System has an Endpoint (https://hl7.org.au/fhir/pd/pd2/StructureDefinition-au-pd-sm-endpoint.html)
- Check that the Endpoint.connectionType has the following value: http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010.
- Check whether the Endpoint.payloadType contains the payload type that the sending system intends to send. For example, if the Sending System intends to send an MDM-T02 message containing a referral, the sending system should confirm that the Endpoint supports the following payload type: http://ns.electronichealth.net.au/er/sc/deliver/hl7Mdm/2012.
Do Sending Systems need to be able to send Clinical Messages to Healthcare Services and to Practitioner Roles?
No. Sending Systems may develop their systems to be able to send Clinical Messages to Healthcare Services, Practitioner Roles, or both. Sending Systems should be guided by their users' business needs and business rules when choosing the type(s) of Intended Recipients they choose to support. However, vendors building Sending Systems should be aware that some Healthcare Services in Provider Directories (e.g. a Pathology service) do not list their individual Practitioner Roles in the directory- all Clinical Messages are to be directed to the Healthcare Service. In this case, systems that can only send Clinical Messages to Practitioner Roles will not be able to send messages to these recipients.
Do Receiving Systems need to be able to receive Clinical Messages sent by Practitioner Roles and by Healthcare Services?
Yes. Some Clinical Message specifications (e.g. REF-I12 and MDM-T02) permit the sender to be a Practitioner Role or a Healthcare Service. To align with these specifications, Receiving Systems must be able to receive Clinical Messages sent by a Practitioner Role or by a Healthcare Service, and send the corresponding Acknowledgement Messages back. Solutions whose business rules do not allow for incoming messages to be authored by a Healthcare Service may choose to respond with an Acknowledgement Message (e.g. RRI-I12 or ACK-T02) message that notifies the Sending System that the Author must be a specific Practitioner Role. This is a "minimum requirement" necessary so that the Sending System is informed of the result of their message send attempt, does not attempt to resend, etc.
When sending a Message to a Practitioner Role, can I just send it to the Endpoint of their Healthcare Service? No. Sending Systems cannot send a Message to a Practitioner Role by sending the Message to the Secure Messaging Endpoint of the Healthcare Service. This is part of the FHIR PD specification.
Our system holds information retrieved from a Provider Directory in a "Local Address Book". Do I need to refresh that record?
Information systems that copy information from a Provider Directory into a Local Address Book are required to ensure that the information in the Local Address Book remains up to date. The preferred approach is that, each time the recipient from the Local Address Book is selected for use in secure messaging, the software calls the Provider Directory to make sure the information held in the Local Address Book is up to date. An alternative method is through regular (e.g. nightly) batch updates of the Local Address Book records.
Provider Directories
How many Provider Directories are there?
There will be multiple Provider Directories in use. Secure Messaging vendors, and potentially other parties, will expose Provider Directories that can be queried to identify potential Intended Recipients for messages. The ADHA will not be providing a production Provider Directory, but will provide test Provider Directories that information system vendors can use during development and testing.
Do we need to connect to all Provider Directories, or just one?
Typically just one. The solution design for the NSMN requires that Provider Directory operators aggregate the results from all other Provider Directories and return the combined result set as query results. This means that systems that query one Provider Directory will typically get the results held in all Provider Directories.
What happens when we want to send a Message to an organisation that is not listed in a Provider Directory, their entry is out-of-date or it indicates the Receiving System does not support secure messaging?
You can choose to send the message, but you will take on the risk that the message may not be delivered to the Intended Recipient.
How can a system querying a Provider Directory determine the source of a retrieved record?
Source comes from the field PractitionerRole.endpoint.managingOrganization.display for Practitioner Roles and HealthcareService.endpoint.managingOrganization.display for Healthcare Services. Note that, where the Practitioner Role or Healthcare Service has no Endpoint, no source can be displayed.
How complete is the data in the Provider Directories? Do all Practitioner Roles have provider numbers, AHPRA numbers, HPI-I codes etc.?
There is no guarantee that all required data will be present, and systems using information retrieved from Provider Directories should be built and tested accordingly. The Service Registration Assistant (SRA), currently being developed by the ADHA, will address some of the data quality aspects of the Provider Directories.
Will a search of a Provider Directory return duplicate records? How can duplicates be identified?
There is no requirement or agreed method for Provider Directory operators to identify duplicate records in their returned search results (e.g. while aggregating information from other Provider Directories). Users should be presented with all results to enable them to decide which record to select. The results may contain duplicates. The Service Registration Assistant (SRA), currently being developed by the ADHA, will address some of the data quality aspects of the Provider Directories.
Is there any sample code for connecting to a Provider Directory?
There are FHIR libraries in .NET and Java with the following links:
.NET FHIR: http://docs.simplifier.net/fhirnetapi/index.html
- GitHub: https://github.com/FirelyTeam/fhir-net-api
- Nuget FHIR R4: https://www.nuget.org/packages/Hl7.Fhir.R4/
- Nuget FHIR STU3: https://www.nuget.org/packages/Hl7.Fhir.STU3/
JAVA FHIR: https://hapifhir.io/
- GitHub: https://github.com/jamesagnew/hapi-fhir
- Downloads: https://hapifhir.io/download.html
For other open-source FHIR implementations projects (Javascript, Swift, Delphi, Python), please refer to the following reference: https://wiki.hl7.org/index.php?title=Open_Source_FHIR_implementations
Message formats, message content
What message formats does the NSMN support?
Solutions participating in the NSMN will be able to send and receive a variety of HL7 v2 message types, including Clinical Messages and Acknowledgement Messages. The list of supported Message formats can be found in the Appendices of the NSMN Conformance Profile, part of the NSMN Conformance Assessment Scheme. Download instructions for these documents can be found on the Resources section of the National Secure Messaging Network web page.
Must Sending Systems be able to send all supported Clinical Message types?
For each type of clinical document they support, Sending Systems are required to be able to send at least one of the corresponding Clinical Message types used by the NSMN. For example, patient referrals may be sent as a REF-I12 v2.4 (with a PDF inside) or as an MDM-T02 message (with a CDA document inside). Sending Systems that send patient referrals must be able to send one of these types of messages. They may be able to send both, and are encouraged to do so, but there is no requirement to be able to do so.
Must Receiving Systems be able to receive all supported Clinical Message types?
For each type of clinical document they support, Receiving Systems are required to be able to receive all of the corresponding Clinical Message types used by the NSMN. For example, patient referrals may be sent as a REF-I12 v2.4 (with a PDF inside) or as an MDM-T02 message (with a CDA document inside). Receiving Systems that receive patient referrals must be able to receive and process both these types of Clinical Messages. This is a core interoperability principle underpinning the NSMN.
How do I populate MSH-3, MSH-4, MSH-5 and MSH-6 segments of the outgoing REF-I12 and MDM-T02 messages to support successful message exchanges?
Successful message exchange is dependent upon the correct population of segments MSH-3, MSH-4, MSH-5 and MSH-6 of outgoing messages. For more information refer to: How do I populate MSH-3, MSH-4, MSH-5 and MSH-6 segments of the outgoing REF-I12 and MDM-T02 messages to support successful message exchanges?
Reference data
How do I get the lists of reference data to use for Healthcare Service types, Healthcare Service specialties, Practitioner Role specialties and Practitioner Role codes?
These reference data lists can be sourced from the CSIRO Ontoserver. URLs are provided below. NB: Use an HTTP tool, such as POSTman, when retrieving the lists, as making the request with a browser may cause the result set to be truncated.
- HealthCareService.Type - https://r4.ontoserver.csiro.au/fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/%3C224930009&count=1000&activeOnly=true
- HealthCareService.Specialty and PractitionerRole.Specialty - https://r4.ontoserver.csiro.au/fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/%3C394658006&count=1000&activeOnly=true
- PractitionerRole.Code - https://r4.ontoserver.csiro.au/fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/%3C223366009&count=1000&activeOnly=true
Where can I find the list of SNOMED specialities?
SNOMED speciality list can be sourced from here - https://r4.ontoserver.csiro.au/fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/%3C394658006&count=1000&activeOnly=true
NB: Use an HTTP tool, such as POSTman, when retrieving the list, as making the request with a browser may cause the result set to be truncated.
My Health Record uses ANZSIC codes to identify specialties. Are there mappings to SNOMED CT?
No mappings are available at this stage.
Testing, technical support
How can I get technical support as we develop our solution?
Send an email to [email protected].
Does the Agency test my product?
The Agency is not in a position to undertake detailed testing of vendor information systems. The Agency’s undertakes a light conformance checking process that is primarily concerned with assessing the breadth of the work done by vendor so that the public conformance register can be maintained with up-to-date and accurate information on solution capabilities. Responsibility for ensuring information systems participating in the NSMN have the required capabilities and are appropriately tested remains with the product owners.
Are there any existing Provider Directories available that that I can use during development and testing?
Yes, the ADHA provides test Provider Directories at the following URLs:
| FHIR Version | Service | URL |
|---|---|---|
| R4 | Directory X | https://sandbox.digitalhealth.gov.au/FhirServerR4-PDX/fhir |
| R4 | Directory Y | https://sandbox.digitalhealth.gov.au/FhirServerR4-PDY/fhir |
| R4 | Directory Z | https://sandbox.digitalhealth.gov.au/FhirServerR4-PDZ/fhir |
| R4 | Aggregator | https://sandbox.digitalhealth.gov.au/FhirServerR4-PDA/fhir |
There isn't a great deal of data in the test Provider Directories provided by the Agency – how can I test paging?
The easiest way to test paging is to use the _count operator. When a system querying the test Provider Directories adds it to their requests, and sets it to a low value (e.g. ...PractitionerRole?_count=2), the test server will return paged result sets (in this case, pages that contain 2 resources). This will assist in testing paging.
Standards, terminology
Is there a glossary that defines the terminology used in the NSMN documents?
Yes. You can access the NSMN glossary here. [TODO - this link points to my new NSMN Glossary page].
Where can I get copies of the standards and specifications on which the NSMN is based?
Links to the ATS, HL7, FHIR and other specifications and standards that underpin the NSMN can be found on the ADHA's secure messaging web page.
What standard defines the use of Message Acknowledgments in the NSMN solution?
The Acknowledgements section of the "Australian Diagnostics and Referral Messaging - Localisation of HL7 Version 2.4" specification defines the use of Message Acknowledgements in the NSMN solution (NB: the NSMN uses "enhanced mode").
Committees, Working Groups, Organisations
Is the NSMN Governance Committee run by the ADHA?
No. The NSMN Governance Committee is a voluntary, cooperative body made up of representatives from clinical peak body groups, jurisdictions, secure messaging vendors, clinical information system vendors and others with a drive to make secure messaging a successful, widely adopted and highly valued capability of the Australian healthcare industry. The ADHA helped set up the NSMN Governance Committee but does not run it- it is run by its members.
What is the HL7 Australia O&O Working Group and how does it affect the NSMN?
The HL7 Australia Orders & Observations (O&A) Working Group defines the specifications for the Australian localisation of HL7 version 2.4 messages (REF-I12 and RRI-I12).
What is the HL7 Australia Patient Working Group and how does it affect the NSMN?
HL7 Australia Patient Administration Working Group has responsibility for the FHIR PD specification which formally defines the Provider Directories used in the NSMN solution.
What is the Secure Messaging Technical Working Group (SMTWG) and how does it affect the NSMN?
The Secure Messaging Technical Working Group (SMTWG) is the key decision-making authority through which design issues and technical questions that pertain to the NSMN are discussed and resolved. Contact the Agency at [email protected] for further information, including how your organisation can participate in the SMTWG.