Go to top of page

More information:

Secure Messaging home page

1. Testing 

  • Does the Agency test my product?
    The Agency is not in a position to undertake detailed testing for the 50+ products in the industry offer. The Agency’s undertakes a conformance checking process that is primarily concerned with ensuring SMIO participants meet their contractual obligations, along with providing technical help and advice to participants. Responsibility for detailed testing remains with the product owners. Participants have the same responsibility to fully test their SMIO functionality as they do with any other updates and changes to their product(s).
  • There isn't a great deal of data in the test FHIR directories – how can I test paging? 
    The easiest way to test paging is to use the _count operator. When a CIS 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 the CIS in testing paging.
  • Isn’t the purpose of the conformance testing to ensure malformed messages don’t occur? 
    Yes, conformance testing helps CIS to assess if they are creating properly formed messages, however no amount of testing can ensure that a malformed message will not occur. 
  • Will we be able to configure the Clinical Package Validator (CPV) to pick up messages from a file location and then drop the responses into another file location? 
    Yes, you will be able to browse to select the applicable folder.
  • Are all these test scenarios required or are some optional? 
    Yes, these are a minimum set of test scenarios and yes, we want to see the results of tests.
  • Are there any instructions or existing provider directory service endpoints that I can use to do some testing?
    Yes, the environment URLs are detailed in the PDS Tester Guide artefact: Provider Directory Service & Message Payload Tester Guide

2. FHIR R4 

  • Are the FHIR resources proposed for use for Secure Messaging at Normative stage of specification in R4? 
    No, the resources are at various levels of maturity. We have a baselined Provider Directory PD2 of FHIR on R4 so there will be a static baseline to work to.

  • What if by the time a practice management system is migrated to this new FHIR interface, but one of the secure messaging vendor hasn’t. Should the practice management system keep the old integration part and the new FHIR interface both running at the same time in order to integrate with all secure messaging vendors? 
    Yes, there may be two endpoints available STU3 or R4 and the CIS should connect to the R4 if it’s available.

3. Provider Directory Service

  • How does a sender tell if a recipient supports secure messaging?
    Before sending a secure message to a recipient, senders must check whether that recipient (i.e. Healthcare Service or Practitioner Role) is able to receive secure messages. There are three steps involved:

    (1) Check that the recipient has an Endpoint (https://hl7.org.au/fhir/pd/pd2/StructureDefinition-au-pd-sm-endpoint.html) 
    (2) Check that the Endpoint.connectionType has the following value:  http://ns.electronichealth.net.au/smd/intf/SealedMessageDelivery/TLS/2010. 
    (3) 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. Message payloads are discussed further in Section 7 of the Developer Guide, "Message payload functional implementation".

  • How can a CIS 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. Where the Practitioner Role or Healthcare Service has no Endpoint, no source can be displayed. This will be reviewed by the Secure Messaging Technical Working Group (TWG) with a view to adjusting the FHIR PD2 directory structure such that all records returned from online Provider Directories are be able to contain a "source" field.

  • What happens when we want to send a message to an organisation that is not listed in an Online Provider Directory, their entry is out-of-date or 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. 

  • Does this mean as a CIS Developer we need to have an agreement with a Secure Messaging Provider to access the federated search? 
    Yes.

  • Does the Agency maintain the directory service or Secure Messaging Providers maintain the directory service?
    No. The Agency facilitates a Technical Working Group (TWG), that any CIS Developers and Secure Messaging Providers can participate in. The TWG develop specifications and set standards for Secure Messaging. If you want to join the TWG please send an email to [email protected] to request to join the technical working group and we can provide more information.

    Secure Messaging Providers will deliver aggregation end points based on FHIR profiles and host those end points for CIS Developers to leverage.

  • Do we need to implement both 6.2.1 Directory Consumer with Directory Operator and 6.2.2 Directory Consumer with Aggregator? 
    No. The intent of the developer guide was to allow for the CIS developers (Directory Consumers) to choose whether they want to integrate with an Aggregation endpoint hosted by the Secure Messaging vendors (we believe this to be the more common implementation pattern) or whether they want to integrate with a Directory Operator endpoint (if provided by Secure Messaging vendor) and perform the aggregation locally (we anticipate less of a take up of this implementation pattern).

  • Do we need to implement authentication mechanisms for each Secure Messaging Provider? 
    No. Mutual x509 provides the minimum mandatory standard. However, if the CIS Developer and Secure Messaging Provider can agree to use an additional authentication profile, this will be based on a bi-lateral agreement between the CIS Developer and Secure Messaging Provider.

  • To authenticate to the Provider Directory do we only need to implement the mandatory Mutual x509 profile or will some Secure Messaging Providers require us to implement one of the optional profiles in addition to mutual x509? 
    Yes at a minimum the x509 access profile is mandatory for CIS and SM vendors to support so there is certainty of interoperability with any vendors. Please see section 6.1.4 of the Provider Directory Service & Message Payload Developer Guide.  

  • Who will ensure that the Secure Messaging Providers’ aggregation capabilities are similar and they don’t produce different results? 
    They should all be the same as they need to follow the agreed AU FHIR PD specifications.

  • How complete is the data in the Provider Directory? Do all Healthcare Providers have provider numbers, AHPRA numbers and HPI-I codes etc. required for referrals? 
    The AU FHIR PD profiles have optional fields to drive adoption, so initially data completeness will be partial, however there are initiatives that the Agency has in the proof-of-concept stage to improve both data quality and completeness.

  • Who will connect to the FHIR services we publish as a CIS Developer? Is this the Secure Messaging Provider who will include it in their federated search? 
    The typical scenario will be for the Secure Messaging Providers to publish the FHIR services for CIS Developers to consume and present to users (Healthcare Providers). Currently, the Provider Directory FHIR services are read/search only. There is no write capability. Any updates to Healthcare Provider details will continue as they currently do via existing channels. 

  • Will there be an additional cost to use the Address book and services. What is expected? 
    The Agency cannot comment on commercial agreements between CIS and Secure Messaging organisations. ​

  • Do you have developer documentation for FHIR (API) based the National Health Services Directory (NHSD)? 
    The NHSD, managed by HealthDirect, is accessed using FHIR APIs. Further documentation on the NHSD FHIR API can be found here: https://help.nhsd.com.au/plugins/servlet/desk/portal/2/create/67 

  • What is the recipient’s preferred Secure Messaging Provider and if our CIS customer has HealthLink and the recipient prefers ReferralNet does the API tell us if that is commercially possible? 
    If you have a HealthLink Secure Messaging agent at a Practice and HealthLink has agreement with ReferralNet to be able to publish their details (and therefore exchange messages) then HealthLink would effectively be able to aggregate those details and provide them to the CIS – there may be duplicates that will be presented to the user allowing them to then select the Healthcare Provider address they want to select. 

  • Will each Secure Messaging Provider only provide information for the networks it supports? 
    Secure Messaging providers will provide information based on the networks and other Secure Messaging providers it has an agreement with. 

  • How are duplicate healthcare provider records identified when conducting a search? 
    There is no requirement or agreed method to identify duplicate records. Users will be presented with all results to enable them to decide which record to select. For more information please see section 6.2.2.2 of the Provider Directory Service & Message Payload Developer Guide. The Service Registration Assistant (SRA) will address some of the data quality aspects of the Provider Directory. 

  • Who will develop the federated search/aggregator? ADH, CIS or SMD provider? 
    Typically Secure Messaging vendors. However, there is nothing in specifications that states that a CIS provider cannot develop aggregation capabilities. Please see section 3 of the Provider Directory Service & Message Payload Tester Guide. The Service Registration Assistant (SRA) will address some of the data quality aspects of the Provider Directory.

  • Is there any sample code for connecting to the directory service?  
    There are FHIR libraries in .NET and Java with the following links:  

    .NET FHIR 
    WebSite: 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 
    Website: 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
  • Can Healthcare Provider Identifiers – Individuals (HPI-I) be published in the directories? 
    Yes, provided it is for a purpose as defined in Healthcare Identifiers Regulation 9: 
    (2) A healthcare provider is authorised to use, and to disclose to another entity, the healthcare identifier of a healthcare provider for the purpose of communicating or managing health information as part of: 
    (a) the provision of healthcare to a healthcare recipient; or 
    (b) the management (including the investigation or resolution of complaints), funding, monitoring or evaluation of healthcare.
    (3) The other entity is authorised to collect, use or disclose the healthcare identifier of a healthcare provider for the purpose for which the healthcare identifier was disclosed to the entity under sub-regulation (2). 
    Please also ensure that access to the directory is controlled and users agree to Ts and Cs that reflect the regulation.

4. Local Address Book

  • Is synchronisation between the Local Address Book and the Online Directory required every time a message is sent or the user can choose to check? 
    Ensuring the Local Address Book is up to date each time a message is sent, is the recommended approach. The goal of this requirement is to ensure the message reaches it desired recipient. There are alternative suboptimal ways to implement this functionality such as periodic batch updates. 

  • If the CIS has a Local Address Book, is it mandatory to save the Online Provider Directory search results to the Local Address Book? 
    ​It is not mandatory to save search results in the Local Address Book. For CIS products that use a Local Address Book we strongly recommend validating the Local Address Book as often as possible to ensure consistency across search results. 

  • Currently we store provider details in the CIS, usually received from the PAS. We send this directly to the Secure Messaging Provider. Is the recommended practice to change from this and then perform searches as required? 
    Any updates to healthcare provider details in online directories should be done as per existing channels and processes. The scope of the current Secure Messaging industry offer does not include or specify updating healthcare provider details in the online directories. It specifies how provider details can be found across multiple online provider directories from varying organisations. Having said that, suggestions are provided on how to maintain local address books aligned with healthcare provider details in online directories. 

  • Is this service replacing our internal address book? 
    The Agency understands that some products with local address books manage additional metadata about healthcare providers. This service is intended to ensure that if products use a local address book to manage information about healthcare providers that they are kept up to date and aligned with the core addressing changes made in the online provider directory to ensure delivery of message. 

  • Can we update information in the local address book automatically, without troubling the user? 
    Yes, this is possible and recommended. 

  • The main thing we'd be wanting to synch to local address book is preferred Secure Messaging Provider of the recipient and their mailbox name for that Secure Messaging Provider (e.g. HealthLink ‘Sunnybank Med’ but these fields not in sample page - will this be there ? 
    Yes, you can search for the recipient and the Secure Messaging identifier (a.k.a. Vendor Directory Identifier – VDI). This is effectively the “mailbox name” issued by the recipient Secure Messaging provider.  

  • Is PUT/POST required to send back up? 
    HTTP PUT and POST to online provider directory are currently not supported. The read/search is executed by performing a GET operation. 

  • Do you have any suggestions on aggregating healthcare providers from the Provider Directory into an existing local provider address book? 
    Please refer to section 6.3.2 of the PDS & MP Developer Guide. Although directory caching is not a mandatory requirement, is recommended for implementation to improve performance of queries.

5. Message Payloads

  • 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: 
    https://developer.digitalhealth.gov.au/resources/faqs/how-do-i-populate-msh-3-msh-4-msh-5-and-msh-6-segments-outgoing-ref-i12-and-mdm-t02-messages-support 
  • Do CIS need to be able to send both REF-I12 and MDM-T02 messages? 
    No. All CIS must be able to send one of these types of messages. They are free to be able to send both, and are encouraged to do so, but there is no requirement to be able to do so.
  • Do CIS need to be able to send messages (REF-I12 or MDM-T02) to Healthcare Services or just to Practitioner Roles? 
    CIS may have the capability to send REF-I12 or MDM-T02 messages to specific Practitioner Roles, to Healthcare Services, or to both. CIS should be guided by their users' business needs and business rules when choosing the type(s) of recipients they choose to support. SMIO participants should be aware that some Healthcare Services in online Provider Directories do not list their individual Practitioner Roles in the directory. Other Healthcare Services may list the Practitioner Roles, but not provide Secure Messaging Endpoints for them. In both cases, systems that can only send REF-I12 or MDM-T02 messages to Practitioner Roles will not be able to send messages to these recipients. Please be aware that sending systems cannot send a message to a Practitioner Role by sending the message to the Secure Messaging Endpoint of the Healthcare Service. 
  • Do CIS need to be able to receive both REF-I12 and MDM-T02 messages? 
    Yes. It is imperative that all CIS are able to receive both REF-I12 messages (containing PDFs) and MDM-T02 messages (containing a CDA document and optional attachments) and display the received content to their users. This is because the receiving system cannot control which type of message sending systems are able to send.
  • Do CIS need to be able to receive REF-I12 and MDM-T02 messages from Practitioner Roles and from Healthcare Services? 
    Yes. The REF-I12 and MDM-T02 specifications permit the sender to be a Practitioner Role or a Healthcare Service. To align with these specifications, receiving CIS must be able to receive REF-I12 and MDM-T02 messages sent by a Practitioner Role or by a Healthcare Service, and send the corresponding response messages (RRI-I12 or ACK-T02) back to these senders. SMIO participants whose business rules don't allow for incoming messages authored by a Healthcare Service may choose to respond with an RRI-I12 or ACK-T02 message that notifies the sending system that the receiver is unable to process messages sent by a Healthcare Service – that it must be sent by 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
  • Before sending a message, must a CIS check the recipient's digital certificate (retrieved from the Provider Directory)? 
    Yes. Successful transmission of secure messages is dependent on the recipient's secure messaging endpoint having a valid, digital certificate associated with it. The digital certificate is used in the secure transmission process. A sending CIS should therefore check this before attempting to send a secure message to the recipient. This is a good practice, but will not be formally tested as part of the SMIO.
  • Before sending a message, must a sending CIS check the recipient's au-receivingfacility? 
    Yes. Successful transmission of secure messages is dependent on the recipient's secure messaging endpoint having an au-receivingfacility. The au-receivingfacility is used to address the HL7 message so that it can be successfully delivered. However, in the Australian Provider Directory Implementation Guide (PD 2), au-receivingfacility is an optional field (0:1). For this reason, it is a good practice for sending CIS to check that this information is available before attempting to send a message to the recipient, but this will not be formally tested as part of the SMIO.
  • Is there a requirement to check conformance of incoming messages? 
    It is recommended that CIS test the structure of the message but it is not mandated.
  • When validating the CDA Package, is signature checking all we have to do to test 'man in the middle attack"? 
    Yes.
  • If the REF-I12 message has an error but not a critical one, should the system accept the message and generate the error code in RRI-I12? Some fields are crucial, but others are not. If there is enough information to process the message, should it still fail? 
    Each CIS needs to determine whether to accept or reject messages with errors; and accept the associated risks of their decision. 
  • What are the appropriate error or rejection codes? 
    The applicable application error codes are: 
    AE – Application Error 
    AR – Application Reject 
    Any other specific error codes are not required.
  • CISs that have an interface engine gateway will error in the gateway before it gets to the CIS so not realistic to assume that CISs will be doing all the error handling? 
    The overall architecture requires multiple levels of error handling. If the CIS uses an interface engine gateway to validate incoming messages and error handling, the expectation is that the interfaces engine gateway will generate the appropriate acknowledgement messages. 
  • Do the message acknowledgments (HL7 ACK) need to be original mode or enhanced mode?
    Enhanced mode. 
  • Do the payload profiles support sending a referral to a “copy to” recipient? 
    Yes however, messages will only be sent to one provider. Each provider requires their own message addressed to that individual just like when posting a paper based letter. Multiple recipients can be listed in the message body but there will be only one message recipient for each message.
  • For “copy to” healthcare providers, is there a HL7 message for each healthcare provider? 
    Yes as above.
  • Do we need to provide a lookup for each “copy to” healthcare provider?
    No. You can select multiple recipients from the search results plus there should be the ability to add more recipients during message/letter creation.  
  • Do recipients need to accept all messages? Is there any information in the directory that says if these can be received? 
    As per PDS-MP Developer Guide recipients need to support rendering of both the MDM-T02 and REF-I12 (and their associated acknowledgements). The supported payload types are listed in the payloadType of the Australian Secure Messaging Endpoint Directory Entry. 
  • As a SaaS recipient of messages, we rely on either a known provider number in the PRD segment OR a known org in the MSH - have the working parties dealt with any standardisation of what goes in the MSH in the absence of a provider number identified recipient? 
    Yes, as stated in the Simplified REF Profile: https://confluence.hl7australia.com/display/OO/Appendix+8+Simplified+REF+profile#Appendix8SimplifiedREFprofile-A8.12Addressing

6. ​NASH PKI Organisation Certificates 

  • Do Secure Messaging Industry Offer (SMIO) NASH requirements apply to me? 
    The SMIO has three NASH-related requirements. These are specified in the NASH Developer Guide that can be downloaded from the following page: https://developer.digitalhealth.gov.au/resources/faqs/national-authentication-service-health-nash-pki-organisation-certificate. All three of the NASH-related requirements apply to you if These requirements apply to vendors in the following circumstances: 

    • NASH-1 - Support NASH PKI organisation certificates. This applies if the current production version of your CIS connects to the HI Service or My Health Record. 

    • NASH-2 - Support SHA-2 NASH PKI organisation certificates. This applies if the your system uses a NASH certificate for any reason (connection to HI Service, connection to My Health Record, or to digitally sign CDA documents). 

    • NASH-3 - Ensure users of the software update NASH PKI organisation certificates prior to their expiry date. This applies if the your system uses a NASH certificate for any reason (connection to HI Service, connection to My Health Record, or to digitally sign CDA documents).

  • What is the expectation of the NASH expiry test for a CSP-NASH? Our NASH cert covers all CIS users and it is meaningless to end users as we the vendor have to action for our whole cloud infrastructure. 
    As detailed in the NASH PKI Organisation Certificate Developer Guide, certificate expiry needs to be managed by the CSP organisation to ensure continuity of connection to the HI Service and My Health Record for your clients. Requirement NASH-3 is not applicable for contracted service providers (CSP) or general supporting organisations (GSO) however, it is recommended to develop similar functionality to ensure certificates are updated. 
  • Is there somewhere at the ADHA website where we can get a SHA-2 NASH certificate?  
    • NASH Test Kit form – https://developer.digitalhealth.gov.au/sites/default/files/application-requestnash-pki-test-certificate.pdf.
    • NASH Test Certificates order form - https://developer.digitalhealth.gov.au/sites/default/files/testnash-certificate-order-form.pdf.
    • SHA-1 and SHA-2 certificates are provided in the NASH test kit. 
      To obtain your test certificates please download the NASH test kit and NASH test certificates ordering forms from the site below and return to [email protected].
  • Is the Agency or Services Australia able to provide workflows/ policy for the issuing of SHA-2 certificates to Medical Clinics? 
    The workflow for Healthcare provider organisations to apply for their NASH PKI certificates remains unchanged after the introduction of the SHA-2 certificates. The digital certificates will be available for them to download via Services Australia Health Professional Online Services (HPOS).  The NASH PKI certificate for Healthcare Provider Organisations SHA-1 and SHA-2 Policies are available here: 
    https://www.servicesaustralia.gov.au/organisations/health-professionals/services/medicare/national-authentication-service-health/applying/nash-pki-certificate-healthcare-provider-organisations/pki-policy-documents#a4

  • Will all new NASH certs be issued as SHA-2 or SHA-1? 
    A Release date for SHA-2 NASH PKI Organisation Certificates in production has yet to be confirmed. Until then only SHA-1 certificates are issued to Healthcare provider organisations. Once the release date is announced, there will be a transition period where both SHA-1 and SHA-2 certificates are available to access HI and MHR systems. When a SHA-1 certificate expires (before the 12 March 2022), it will be replaced by a SHA-2 certificate. 

  • Will there be an instance where a Medical Clinic will be issued a SHA-2 certificate and continue to have a valid SHA-1 cert or will the SHA-1 cert be revoked on issuing of the SHA-2? 
    As per above, expired SHA-1 certificates will be replaced by SHA-2 certificates. 

  • When will there only be SHA-2 NASH certificates in circulation? 
    Services Australia have announced that NASH PKI Organisations SHA-1 Certificates will no longer be supported by DHS from 12 March 2022. The Australian Digital Agency is currently working with Software providers to ensure that their software products cater for this change to minimise the impact on their customers. 

  • Is NASH being replaced? Will PRODA be used?  
    NASH isn’t being replaced but it is being updated.

    There are two types of NASH certificates one for Organisations and one for Individuals. NASH for Individuals has not been widely used and is being discontinued. PRODA will replace NASH certificates for Individuals to better align and support applications. NASH for organisations has not been changed but has been upgraded to the more secure SHA-2 and the way certificates are requested and delivered has been improved.

    See https://developer.digitalhealth.gov.au/resources/faqs/national-authentication-service-health-nash-pki-organisation-certificate 

  • Are NASH PKI Organisation Certificates replacing the method to connect to the HI Service and My Health Record (PCEHR)?
    Yes. NASH PKI Organisation Certificates downloaded via the Health Professional Online Services (HPOS) from the 18th of September 2018, can be used to connect to the HI Service and My Health Record system. Medicare PKI site certificates can still be used until they are phased out.

  • Will CSP certificates be supported? Or do we need to have a certificate for each organisation we represent? 
    In the context of obtaining provider addressing information from an organisation hosting an online directory based on AU FHIR PD, the x509 certificate presented for authentication will be based on policies set out by the hosting organisation. Given the CSP certificates are issued by NASH we would assume most Secure Messaging Providers hosting AU FHIR PD services to allow this. 

    In the context of message encryption, the ATS standard states it is responsibility of the sender to assure the certificate (public key) it is using belongs to the recipient organisation or in the case of CSP, that the CSP is authorised to represent the recipient organisation. In the same way the recipient organisation needs to assure the message authenticity and if a CSP certificate was used to sign the message its up to recipient to confirm that the CSP is authorised to sign messages on behalf of that organisation.

  • Is there information associated with a NASH Organisation Certificate that is needed to identify the health care organisation that sends the message (rather than CSP 'facilitator')? 
    The NASH organisation certificate contains the HPI-O of the organisation which could be used to validate the message authenticity. Signing messages using the NASH organisation certificate is in fact a mandatory requirement for a MDM-T02 CDA based message. ​

  • We have a CSP NASH Certificate - has the provider directory service been tested with CSP Certificates? 
    Yes, the Agency’s test bed has been tested with CSP NASH certificates. 
  • Are the certificates only used for accessing the Provider Directory? Or are they also used in secure messaging and for signing payloads? 
    X509 Certificates are used for both provider address lookups and message signing.
  • Can we identify the provider/user using the NASH Organisation Certificate? 
    No, the NASH Organisation Certificate only identifies an organisation by a HPI-O. 
  • How can I resolve the following error when using NASH Certificates “Curl error: The Client Credentials presented are not trusted by this server”? 
    Ensure the CRT certificates are in the trusted certificate store not in the personal store.

CRT Certificate Location

CRT Certificate Location

  • Currently, can SHA-2 NASH PKI Organisation Certificates be used to connect to the HI Service?
    No, SHA-2 is not currently in production.

7. Industry Offer Contract

  • Not all industry partners have implemented this solution – does that mean we have built software that cannot be used? 
    Definitely not. The software you have developed is based on standards (FHIR PD2, HL7v2, ATS-5822/21/20, etc) that have been widely accepted by the healthcare industry. Completing the work of the Secure Messaging Industry Offer (SMIO) will position your product well to support secure messaging as the industry moves to align with these standards. In an ideal world, all industry participants would be ready on "Day X", the solution would be "switched on", and secure messaging would be enabled. Realistically, though, not all partners will be ready on the same day. Naturally, there will be a "transition period" where some companies (particularly those that participated in the Secure Messaging Industry Offer) have forged ahead and completed the work, and are fully capable of working with FHIR-based directories, creating standardised messages that all systems can understand, creating message acknowledgements, and working with NASH certificates. For a variety of reasons (e.g. Covid-19, work capacity, etc), other partners may take longer to complete this work. But rest assured, the healthcare industry is fully engaged and committed to the secure messaging standards and solution. Even industry partners unable to take part in the SMIO formally have been actively engaged in developing and refining the standards and solution design for secure messaging, and reviewing SMIO documents and test plans, with a view to making sure that the solution will work for everyone. SMIO participants are simply the "early adopters", completing the work first that many will undertake. As we go forward, the ADHA will be encouraging and working collaboratively with all industry partners to ensure that the secure messaging solution is viable, widely adopted and implemented as quickly as possible across the industry.  
  • If I have further questions who should I contact? 
    Please call the Agency Help Desk 1300 901 001 or email [email protected] 
  • Who do I send my contact details to? 
    Please email your contact details to [email protected]  
  • Do we have a list of Secure Messaging Providers participating in the program? 
    Please refer to media release and list of participants.​

8. Reference Data

9. HIPS

  • HIPS material talked about supporting secure messaging. Does it support this in R7.1.1? 
    No, the current version of HIPS V7.1.1 does not support any secure messaging components. The older HIPS versions (V5 to V6) did have some secure messaging components and integration to the older forms of provider directory work, this was a connection to the National Health Services Directory (NHSD) using the older NEPS (National Endpoint Proxy Service). These were then removed from HIPS in V7. The secure messaging components of HIPS were unsuccessful and removed. HIPS may implement the newer forms of secure messaging and the new FHIR Provider Directory work in the future. No decision has been made as yet.

10. Working Groups

11. Public Announcement

  • Your public announcement must meet the following criteria:
    • Published on your public facing website.
    • Accessible from your home page.
    • Reference the new capabilities implemented under the industry offer
      • Enhanced searching across multiple secure messaging providers by using a federated provider directory service;
      • Interoperability and message exchange with different secure messaging enabled software products by utilising standardised messages;
      • The ability to securely exchange messages based on current and future Australian encryption standard.
    • Include the product, version and expected date of the release

-->