Page tree
Skip to end of metadata
Go to start of metadata


This page covers the basic flow of the Secure Message Delivery (SMD) overall flow for sending a secure message using FHIR, HL7v2 and SMD.

Note: The messaging format is different between the 2 projects, one is done using a simplified HL7v2 (documented here) and the other utilizes CDA message content.

 The basic sequence of actions is:

  • Directory Lookup (locate destination)
  • Message Creation (HL7v2)
  • Directory Lookup (delivery)
  • Message delivered (SMD)
  • Message received (SMD)
  • Directory Lookup (reply)
  • Reply message delivered (SMD)

Directory Lookup (locate destination)

The user will be able to search for the required PractitionerRole or HealthcareService that they desire to send a message to.

This could use a variety of search parameters, and may or may not want to filter down to only those that are able to perform electronic transmission.

Example Query: (to be verified - not used in the discharge summary POC)


Just omit the endpoint.payload-type parameter if you want to list all roles, even if they don't have the simplified profile available.

The following table shows a list of search parameters that could be used during this stage (supported by both Argus and Medical Objects):

ResourceSearch Parameters_include



Support is highly desirable for _include as this reduces the number of API calls to retrieve the information

Message Creation (HL7v2)



Example Query: 

Directory Lookup (delivery)

In order to deliver the message, we need to retrieve the details of the endpoint for the required destination role.

Example Query:  (with parameters _has:PractitionerRole:endpoint:identifier, payload-type and connection-type)

(This example is to locate the endpoint relevant for a simplified REF message at a practitioner role)


The identifier comes from PRD7 and will need to map the type from PRD7 (do we need to derive it from the content)

PRD7 should have all 3 components

MSH 6 from v2.3 messages is also appropriate and would require a search with no system defined, then check the results for supported identifier types.

If this step was not involved in the search stage there may not be adequate information to deduce if this is a PractitonerRole or a HealthcareService to deal with, and hence may need to query against both types to locate the endpoint to send to.

If this result produces multiple values, then locating the intended PractitionerRole/HealthcareService and checking the endpoint referenced by that may be required.

This Endpoint resource contains the SMD Target value in the Endpoint.Identifier[system=] value

Message delivered (SMD)


Example Query: 

Message received (SMD)


Example Query: 

Directory Lookup (reply)

When sending the application acknowledgement via SMD we need to use several custom search parameters defined on the Endpoint resource:

Search Parameter NameExpressionExpressionExtract from HL7 v2 segment 

To determine the payload-type parameter the HL7v2 message should be inspected to determine the appropriate type to use.

For the simplified REF profile, this is by looking at segment MSH-12 (HL7 version identifier) for the value "HL7AU-OO-REF-SIMPLIFIED-201706" (and ensure that it is conformant to this profile)

(as described here)

Example Query: (with parameters: payload-type, connection-type and au-receivingfacility-namespace-id, au-receivingfacility-universal-id, au-receivingfacility-universal-type-id)



Where you have the identifier, you can look perform the search like this: (with parameters: identifier, connection-type and payload-type)



Reply message delivered (SMD)

Example Query: 


  • No labels