Publication Build: This will be filled in by the publication tooling

Home

This FHIR Implementation Guide (IG) describes a proposal to how the FHIR messaging pattern can be used in communication between NAV and Electronic Health Record (EHR) systems.

There are currently no national IG on how FHIR messaging shall be used in Norway, but the need for such an IG has been recognized by The Norwegian Directorate of eHealth, partially to replace the currently used ebXML-based Dialogmelding. This is why NAV is developing this IG, which hopefully can contribute in creating an official national IG accepted by the Norwegian health sector.

NAV is committed to adhere to whatever standards or best-practices the Norwegian health sector adopts, and have no interest in creating a separate custom integration pattern, it is therefore important to recognize this IG as a proposal, which is open to feedback and adjustments.

Actors

The primary actors in context of this IG are:

1. EHRs, “Elektronisk Pasient Journal (EPJ)”, are systems that contains and manages health information related to a patient and the services that operate on this data.
2. NAV is the Norwegian Labour and Welfare Administration and includes all the services managed by NAV.

Messaging vs. RESTful

FHIR Messaging and FHIR RESTful API are two of the patterns defined in the FHIR specification.

The RESTful API pattern is the most stable and widely used pattern for exchanging FHIR resources. This pattern is well suited for exchanging data between front-end apps and back-end services, e.g. SMART-on-FHIR apps.

The Messaging pattern can be more suitable for exchange between disparate organizations with low levels of process integration and/or trust. For instance, it might be preferred by an organization/system that has not necessarily adopted FHIR internally, because they can receive FHIR messages containing a coherent snapshot of a complete context. The alternative would be to pull the required resources from multiple REST endpoints, where the lifecycle and versioning of these resources also must be considered.

Figure 1 visualizes exchange of FHIR messages between three different organizations, each having multiple internal systems that communicates using different patterns and protocols.

Figure 1

Workflow

The FHIR Messaging pattern does not describe how messages should be transferred. This can be done using Kafka, MQ, FTP, file-store, email, HTTP (including FHIR RESTful API) or any other current or future protocol. Messaging is also not limited to using a single protocol: the same message can be available on multiple channels or be passed through multiple protocols before arriving at the destination.

A simple and powerful way to exchange messages is to simply provide two endpoints: Publish and Retrieve. The specification contains examples of this using the FHIR RESTful API; Publish can be implemented as either POST: {base}/$process-message or POST: {base}/Bundle, and retrieval can be implemented as GET: {base}/Bundle. There is a choice between using $process-message and Bundle for publish; NAV is leaning towards the former due to it already being used by Da-Vinci project and NHS Digital.

HTTP and REST as a message\event exchange protocol might be perceived by some as “old fashion”, but it is a well established protocol that all developers should be familiar with and serves well as a common denominator. Integrators are still able to forward the messages to whatever internal event-streaming technology they prefer.

Figure 2

Polling vs. Pushing

Polling is often simpler to implement and test than a Push-based exchange, especially when reliability, throttling and retries are taken into consideration.

NAV foresee a FHIR RESTful compliant service with the ability to query messages using Bundle search parameters. These messages are represented as a long list of immutable messages ordered from first to last that can be paginated using an offset parameter. Clients can then consume messages at their own pace and even “replay” old messages, new messages are awaited by continuously poll with an offset equal the last entry, this pattern is similar to interacting with a Kafka partition.

Addressing (HER-id)

FHIR Messaging requires a way to identify a message’s source and destination endpoints. These endpoints can be either a protocol-specific endpoint, such as a HTTP URL or email-address, or an identifier used to identify a logical entity without specifying how the message should be delivered.

In order to be technology agnostic, the message-model must be separated from the transfer-protocol. This allows a message to be routed unmodified through multiple intermediates and protocols before arriving at the destination.

In Norway we already have an established standard to identify communicating entities within the health sector called Tjenestebasert adressering. This standard does not force any particular transfer-protocol and can therefore be used to identify source and destination as logical entities in a FHIR message. Such an identifier is called HER-id and shall be populated in the required message elements: source.endpoint and destination.endpoint. Because these elements requires an URI we use HER-id’s reserved OID namespace to create a fully-qualified URI, example:

"destination": [
  {
    "endpoint": "urn:oid:2.16.578.1.12.4.1.2.102287"
  }
]