SMD and the ReferralNet Agent

Minimum Requirements for using SMD with the ReferralNet Agent

The minimum requirements for using SMD with the ReferralNet Agent are:

  • ReferralNet Agent v4.0 or above
  • NASH PKI Certificate for Healthcare Provider Organisations

This minimum requirement allows for SMD messaging only to other ReferralNet users who also have SMD messaging configured. In order to send and receive messages to users with a different messaging provider the full SMD requirements need to be satisfied.

ePIP Commissioning Requirements for SMD

The full requirements for SMD messaging with ReferralNet are:

  • ReferralNet Agent v4.0 or above
  • NASH PKI Certificate for Healthcare Provider Organisations
  • Organisation details published in the Medicare HI Services Healthcare Provider Directory (HPD)
  • ReferralNet's ELS address published in the HPD
  • Certified Service Provider (CSP) authorisation for ReferralNet

Additional requirements for the ePIP program are:

  • The ReferralNet Agent must be installed and a commissioning document signed off - SMD Commissioning Form
  • The ReferralNet Agent must be integrated with a clinical system on the ePIP register

A full list of commissioning requirement are available on the NEHTA PIP Implementation WebSite

PIP SMD Commissioning Requirements

Publishing Details to the Medicare Healthcare Provider Directory (HPD)

Ideally your organization details should have been published to the HPD when they were registered for a HPI-O, however this is an opt-in service. If you have not requested for your organization details to be published, your OMO or RO can do so by calling Medicare Support.

Publishing the ReferralNet ELS address

Your organization ELS details in the HI Services need to include ReferralNet's ELS so that other people can find out where to send messages to you.

This can be set up in Medicare's HPOS web application.

Full step by step instructions for entering details in HPOS.

The required settings are;

Once entered they must also be published to the HPD using the HPD tab in HPOS.

The screen shot below shows the settings being added using HPOS.

Certified Service Provider (CSP) Authorisation

In order for SMD to function ReferralNet must be able to look up the HPD on your behalf to determine where to send your message to so that it will be delivered to the recipient. This functionality requires CSP Authorisation before it can be used.

In order to Authorise Global Health (ReferralNet) as a CSP logon to HPOS as an RO and follow the details in the document: Full step by step instructions for entering details in HPOS.

Setting up your account

Adding a NASH Certificate to your organisation account

A NASH Organisation Certificate can be added to your ReferralNet organization account by:

  1. Log into to the ReferralNet WebSite and viewing your profile
  2. Expand the "Certificate" area and modify the certificate
  3. Choose "NASH" as the Certificate Source and fill in your HPI-O
  4. Select the returned certificate (drop down menu) and save

After doing this the "Alternate Id" area will show your HPI-O associated with your account.

Please remember that if you change the certificate of your ReferralNet account on the website, you also must update the account settings in the ReferralNet Agent.

Checking HI Services Requirements

When viewing the Alternate Id or your ReferralNet account on the web pages, it is possible to click on the HPI-O alternate id (see above screenshot). This will perform checks against the HI Services and determine if everything has been setup correctly in order to use SMD across messaging providers.

If all check boxes are ticked then your account has all required pre-requisites completed.

Configuring SMD in the ReferralNet Agent

SMD Send Actions

Only non-interactive sending is currently supported for SMD. Note that you can setup interactive sending via ReferralNet and non-interactive via SMD. Part of the reason for this is that the CDA document for sending needs to be populated with the HPI-O/HPI-I and IHI identifiers and hence the recipient must already be known/identified before sending by the generating clinical system.

To set up a send action:

  • Specify the location of the file to send (a HL7v2 MDM with an embedded CDA file is required by the community, however raw CDA files can also be sent – instructions differ slightly)
  • Non Interactive Sending
  • Recipient: HL7 by receiving facility with HPI-O
  • Sender: Choose the organization user and with the NASH HPI-O certificate attached
  • No transformations are needed
  • The SMD Service Category (Document Type) is automatically determined

An example of these setting:

SMD Send Action

SMD Receive Actions

To set up a Receive action via SMD the following need to be set when creating a receive action:

  1. Protocol: SMD
  2. Document Type: The type of documents that can be accepted (eReferral, Specialist Letter, Discharge Summary, etc). Only one document type is allowed per receive action
  3. The method of saving the message (e.g. File System Storage and the path)

FAQ

What is a NASH Certificate?

A NASH Certificate is a PKI Certificate issued by the Medicare NASH CA. More formally this is known as "NASH PKI Certificate for Healthcare Provider Organisations". An "eHealth record Individual PKI Certificate" cannot be used for SMD messaging. In order to apply for a NASH Certificate you must first be registered with Medicare and have a HPI-O issued.

A NASH Certificate is NOT the same as the Certificate used to access the HI Services.

To read more about NASH Certificates for Healthcare Provider Organisations or to apply for one, see Medicare Australia - eHealth record and NASH PKI Certificates

Why can a NASH certificate only be used with one account?

With ReferralNet messaging accounts are identified by unique usernames and as such a username must be unique to an account. This is something that almost everyone is familiar with.

With SMD messaging accounts are identified by the Certificate (and through that their HPI-O). This means that no two accounts can share the same NASH Certificate.

Accounts not using SMD messaging can still share common certificates for encryption as long as they don't use NASH certificates

Why does ReferralNet require CSP Authorization when another messaging providers doesn't?

As part of the design of the SMD capabilities of ReferralNet we decided that extending the SMD protocol beyond the Australian Standards was a bad idea. Without extending the SMD standards (and hence creating a proprietary solution), all SMD intermediaries require CSP Authorisation if they are to use Medicare's HI Services in order to determine where to send a message. This is not required when sending via SMD to another ReferralNet user.

This mean that:

  • Any SMD conformant software can be used to send messages via the ReferralNet Intermediary for authorised users
  • Configuration of the ReferralNet Agent is simpler as it doesn't need to have access to your HI Services Location Certificate
  • Security Disciplines are fully followed as without the HI Services Certificate ReferralNet does not have more privileges than needed

What is an ELS

An Endpoint Locator Service (ELS) is a cloud based service that tells client programs the network address to use for specific functions. In the case of SMD messaging, the document types accepted and the network address (of the SMD Messaging Service) where other vendors messaging agents can send messages so that you can receive them is published.

Access to this information is restricted to healthcare organisations only (A NASH HPI-O or Supporting Organisation certificate is required to access the ELS).

This is the only way that another vendor knows where to send messages so that you can receive them.

An organisation can have as many ELS entries configured as it likes. This means that you can have more than one SMD provider, or ELS entries for non SMD purposes can also be added.

SMD Interop

The proposed changes in this document do not break conformance with the SMD or its related standards

Goals

The overall goal is to increase the uptake and use of secure messaging in Australia by providing interoperability between vendors and removing the commercial barriers to uptake.

  • Provide seamless interoperability between messaging vendors
  • Overcome the administrative overhead of using NASH Certificates
  • Overcome the administrative overhead of using HPI-O's
  • Allow discovery of users without the need to rely on a centralised address book service
  • Interchange of HL7 v2 REF I12 and ORU R01 messages as well as Australian CDA messages
  • Be compatible with the SMD Standard
  • Work seamlessly with the NEHTA / ADHA ePIP Requirements

Background and strategic fit

Whist interchange between vendors has been technically proven using SMD messages, NASH Certificates, HPI-O's and ELS entries in Medicare's HPD, interchange is not effectively happening in a production environment. This is due to:

  1. Lack of good end clinical system support for SMD Messages
  2. Difficulty and / or effort (red tape) required for practices to obtain NASH Certificates and HPI-O's
  3. Lack of technical staff required to maintain an organisations entries and structure in the HPD
  4. Difficulty of authoring CDA documents in clinical system

There is a big push from customers, general medical community and governments to have interoperability, with the messaging vendors being blamed for it not working despite interoperability being technically possible for the last several years if using the NEHTA and Government prescribed requirements of NEHTA SMD content, NASH Certificates, HealthCare Identifiers and the HPD.

These specifications are aimed to providing the interoperability that is desired by removing the external barriers to its setup and use.

Assumptions

  • Messaging Vendors are willing to trust each other for ensuring the identity of their users
  • Messaging Vendors are willing to trust other vendor issued certificates

Requirements

In order to provide a greater degree of interoperability than that provided by the SMD ePIP project an alternative choice is used for each of the ePIP areas.

Vendor Id's

The SMD ePIP project relies on the use of HPI-O's for message addressing, however in order to broaden the message traffic to include HL7 v2 messaging and users that either are not eligible for HPI-O's or do not currently have them there is a need to also support Messaging Vendor Id's.

It is acknowledged that not all Messaging Vendors can deliver via SMD to the vendor messaging id that is often used in clinical systems for proprietary HL7 v2 messaging. As such each vendor should publish and support a mechanism to resolve the id commonly used for their users in clinical system address books to an id that can be used for SMD messaging within their network.

For ReferralNet, the ReferralNet Username which is used in the clinical system address book can be transformed for SMD messaging by taking the username portion of the fully qualified id and prepending it with http://members.referralnet.com.au/id/.
e.g. urn:refnet:johndoe becomes http://members.referralnet.com.au/id/johndoe 

To validate that a ReferralNet Username exists the ReferralNet SOAP call FindRecipientByUID can be used with the urn:refnet:username format.

Certificates

In order to support cases where a sender or recipient does not have a NASH certificate, vendor issued certificates also need to be supported for messaging endpoints.

Connections between messaging systems intermediaries must still use commercial web server certificates (server role) and NASH CSP certificates (client role) as per the SMD ePIP project requirements.

All vendor issued certificates should be created by a single Root (or intermediary) Certificate owned by the messaging vendor. This allows distribution of each vendors root (or intermediary) certificate to allow for certificate trust. The distributed certificate should only be used for the purpose of secure messaging in the nominated environment (production or test but not both).

The certificate used should adhere to the requirements below. This should allow existing vendor code that examines NASH certificates to be largely reused.

Subject Alternative Name This should follow the general form of NASH certificates. That being: A namespace that is vendor specific; followed by The username For ReferralNet an example is:
url=http://members.referralnet.com.au/id/<username>
Subject This should follow the general form of NASH certificates. That being: The first RDN containing a common name element formed with the username as the second subpart when separated by periods ('.'); followed by Structural elements relating the DN to the messaging vendor For ReferralNet an example is:
CN = general.<username>.id.referralnet.com.au
O = <org name>
DC = id
DC = referralnet
DC = com
DC = au
Issuer
Key UsageThis must include Digital Signature and Key Encipherment usages
CRL Distribution pointThis must be present and accessible by all vendors
Certificate PolicyIt is recommended that a certificate policy is identified. This should use the vendors registered OID arc
Public Key2048 bits


ELS

Each vendor must share the address of the ELS they use. The CERTREF field of an interaction response must contain (carry) a base64 encoded copy of the recipients certificate.

Address Book

Each vendor must provide real time access for searching their respective address books.

This service is intended only for the following uses:

  1. End users to find recipients on other vendors networks interactively when sending
  2. End users to find recipients on other vendors for the purpose of populating their own clinical systems address book
  3. Software to sync local clinical systems address books where possible

Where possible the address book search should return the messaging id that can be used for SMD interop in addition to any messaging id that customers have been using for regular messaging.

It is permissible to provide the required logic to determine and messaging identifier for the user from the returned entry if it is not directly available in the entry (e.g. if an individual practitioner is returned and the messaging identifier is stored against an associated service or organisation entry).

Details for the ReferralNet Address Book searches are publicly available:

FindRecipientByEmailSearch for a recipient in which to send the referral.
FindRecipientByNameSearch for a recipient in which to send the referral.
FindRecipientByUIDReturn recipient details if their unique identifier is known.
FindRecipientNaturalUses the organic / natural search algorithm to locate a recipient in which to send the message. This should be your search operation of choice as it is the most flexible, acutely tuned to the ReferralNet and integrated 3rd party directories, and is constantly being extended to support wildcards and other useful search notations.

A ReferralNet user id will need to be issued for access to the SOAP calls.

Service Categories

The following additional HL7 v2 Service Categories are being supported in addition to the NEHTA CDA ones

Service Category Description
http://ns.ahml.com.au/smd/sc/HL7v2.3.1~AS4700.2-2006~ORU_R01HL7 ORU
http://smxchange.net.au/smd/sc/HL7v2.3.1~REF_I12/RTFHL7 REF-I12 with Base 64 encoded RTF payload
http://smxchange.net.au/smd/sc/HL7v2.3.1~REF_I12/eRTFHL7 REF-I12 with escaped RTF payload
http://smxchange.net.au/smd/sc/HL7v2.3.1~REF_I12/PDFHL7 REF-I12 with Base 64 encoded PDF payload
http://smxchange.net.au/smd/sc/HL7v2.3.1~REF_I12/FTHL7 REF-I12 with Formatted Text payload
http://smxchange.net.au/smd/sc/HL7v2.3.1~REF_I12/TEXTHL7 REF-I12 with Base 64 encoded Plain Text payload

Interop Test Environments

Each vendor must provide ongoing access to an interop test messaging intermediary and user addresses so that current and future software releases can be tested.


 
smd_and_referralnet.txt · Last modified: 2017/08/16 08:38 (external edit)