The following diagram shows the processing path for Outbound HL7 v2.x Support.
Outbound HL7 v2.x messaging requires several components:
First, you should have a Subscription Matcher (All FHIR Versions) module associated with your FHIR Storage module, and have REST HOOK subscriptions enabled on your FHIR Storage module.
Then, you should create one or more modules of type HL7 v2.x Sending Endpoint. This module creates the outgoing endpoint that will transmit messages to an external system. It defines the target host and port, as well as the transmission protocol. In HL7 v2.x terms, you should create one such module for each "interface".
Finally, you should create one or more subscriptions which are used to trigger message transmission. The exact contents of the Subscription will depend on the style of message generation you are using, as described below.
Smile CDR relies on FHIR Subscription functionality to trigger the transmission of outgoing HL7 v2.x messages. There are several different mechanisms for generation of HL7 v2.x messages for outgoing processing, and the specific properties of the Subscription determine which one is used.
The Default Resource Conversion Subscription type uses one or more resource-type specific subscriptions, and uses built-in HL7 v2.x conversions (which can be enhanced with additional user-defined customizations) to convert that resource type and its references into an appropriate HL7 v2.x message.
The Custom Resource Conversion Subscription type provides a Java-based API for generating messages. This requires more work to set up, but is much more flexible both in terms of which events cause messages to be transmitted, as well as the type and contents of those messages.
The Verbatim Message Subscription type transmits messages verbatim from MessageHeader resources. This is useful if you want to create a pass-through where messages are sent out exactly as they were received.