FHIR messaging

This was a messaging question just posted on the FHIR List (and Stack Overflow)

We have a scenario where we are evaluating the use of FHIR to transfer information on planned encounters from a EHR application (source application) to an internet portal application (destination application). The event that triggers this message transfer is that an encounter is planned, or that an planned encounter is canceled.

Quoting https://www.hl7.org/fhir/messaging.html:

In FHIR messaging, a “request message” is sent from a source application to a destination application when an event happens.

Some questions/issues:

  • First of all: Is the use of FHIR messaging suitable for this scenario?
  • If I understand the FHIR website correctly, the source application should send a “Bundle” to the destination application. Correct?
  • The destination application needs various information on the scheduled encounter, such as the location and the referral request. Am I correct in assuming that these “extra” information elements should also be in the bundle, and that the “main” element should somehow reference these elements ?
  • How should the main element reference the extra elements? Is there an XML example that shows “intra-bundle” references?
  • If I read the spec correctly, the destination application is supposed to send a response message back. What should this response bundle contain to indicate that the message is received OK?


And Lloyd replied:

Messaging is most appropriate mechanism when:

  • You want to pass a number of resources as a single package
  • You don’t need the overhead of a document (table of contents, tight rules over rendering)
  • There’s a potential need for asynchronous communication and/or for routed communication
  • You want to do something more complex than simple CRUD operations
  • You want to use transports other than HTTP

However, you can choose to use messaging for any communication. I.e. No-one will call you non-conformant for choosing to use messaging even if another paradigm might be more ‘typical’.

Messages are Bundle resources where the first entry is a MessageHeader. The MessageHeader points to the focal resource(s) using the ‘data’ element. In this case, the focus would be the Encounter. Additional resources can also be conveyed. Typically you use a profile to provide guidance around what should be included in the bundle vs. not. (element.type.aggregation identifies whether something needs to appear in the bundle or not). The only rule is that when you trace all the relationships between the resources in the bundle, they form a totally connected network. However, the associations can be in either direction. I.e. It’s ok to include things that point to the Encounter, not just things the Encounter points to.

Within the Bundle, references can be full URLs, relative URLs (based on the URL of the referencing resource) or UUIDs. You can see an example message here.

For a notification-type message interaction, your response message would typically just contain a MessageHeader whose .response would point to the identifier of the original message hand have code of “ok”. In other cases, a message response might contain data. E.g. the results of a create or merge, the response to a query, decision support information, etc.

(I like to put this stuff where I can find them when I forget!)

FHIR Messages

Rene Spronk recorded this video on the v2/FHIR messaging at the recent FHIR connectathon.


Resource References, v2 Messages and Locations

There’s been an interesting conversation today on the Implementers chat about the various ways that one resource can reference another, and there are a number of possibilities! They are all variants of the Resource Reference so, lets’ take a quick look at that before we dive into the details.

The resource reference element has 2 properties:

  • The reference, which is a string
  • The display – also a string.

and both properties are optional.

Read more of this post

The Architecture and the (FHIR) Message

So now that we’ve established how we intend to build our model from HL7 v2 messages, let’s turn our attention to architectural issues. We’ll need to look at how FHIR thinks about managing messages – both in terms of the structure and content of a FHIR message, and also how the server should process those messages.

Read more of this post

FHIR Messaging: Clinical data from ADT Messages

In the last post, we started to think about how we might be able to capture clinically useful information (naturally as FHIR resources) from the HL7 v2 messages that are used within many hospitals. These messages are used to move information between the various components of a hospital such as the PAS (Patient Administration System), the RIS (Radiology Information System), the LIS (Laboratory Information System) and so forth.

A common pattern is that the ‘downstream’ systems (LIS, RIS) ‘subscribe’ to these messages emitted from the PAS – generally via an Integration Engine. So all we’ll do is add ourselves to the list of interested parties, and we’ll get a copy of each message as well.

And actually, there’s no real reason why we should confine our attentions to just one hospital – if there are multiple co-operating hospitals then there’s no reason why we can’t receive messages from all of them, though we do need to be careful with identifiers (patient and visit) as these might overlap between providers.

Read more of this post

More FHIR Messaging: ADT messages

We’ve previously talked about converting HL7 Version 2 messages (hereafter called ‘v2’) to FHIR bundles. Let’s take that a step further and dig into a bit more detail about processing messages in FHIR.

Read more of this post