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.

First a (very) quick background on v2 messaging. First released in 1987, v2 messaging defines a series of ‘triggers’ – or events that happen in the real world, messages that are emitted in response to those triggers, and in some cases behaviours that a recipient system should take when a message is received.

For example, a common event that occurs in a hospital is when a patient is admitted. The details of the patient details are entered into the hospitals Patient Administration System (PAS), which then generates a v2 message that is sent to all subscribing systems – such as the radiology system or the laboratory system which will need these details later when X-Rays and Lab tests are ordered for the patient.

In this case, the trigger event has the code ‘A01’, and the type of message is an ‘ADT’ (Admission/Discharge/Transfer) – hence the message is commonly called an ADT^A01 message (combining message type and event).

Once the message has been processed by the recipient (whatever that processing might be) the message is no longer used – it can be thrown away. Of course, most systems will keep a copy for audit purposes, but this is quite different to a document like CDA, which is intended to be a persistent part of the clinical record. It’s also different to REST where the behaviour of the system is defined by the specification – a GET means to retrieve something, POST creates a new resource and so forth – in messaging, the behaviour is less well defined (at least in detail as we will see).

Now, the v2 spec is large and in very wide use (it has been around for almost 30 years after all) so we’re not going to cover it all here, but rather we’re going take a small subset of that spec and think about how we’re going to implement it in FHIR – thinking about some of the issues as we go.

FHIR messaging hasn’t had the degree of scrutiny that the REST interface has had, so we’re going to make a few assumptions that may well be incorrect – and might even uncover issues that will lead to updates in the spec. You can refer to the FHIR spec for the current description of how messaging is intended to be performed in FHIR.

We’ll use the Patient Administration domain for our examples – often these are referred to as ‘ADT’ (Admission/Discharge/Transfer) messages, as in the example above as these are very commonly used (and therefore available) in healthcare. Our intention is to create a repository of FHIR resources that are of interest to a clinician that can be derived from these messages. Over time, we will increase the range of the v2 messages that we can accept thus improving the quality of data on offer.

Lets start by thinking about what resources we’re going to be able to extract.

The first message to have a look at is the ADT^A01, which is an ‘admission notification’ message. Usually it’s generated by the PAS system when a patient is admitted to a hospital and consists of a number of segments – most of which are optional. The table below lists the segments that we are interested in, and the likely FHIR resources that we can get from them. (We say ‘likely’ because we may change our minds as the analysis proceeds)

This is not a complete list of all the segments in the message – we’ve pulled out the ones of most interest to us – those that are likely to be of most interest to a clinician (If you were doing something like then this then you may well have a different set of segments – or messages – of interest). For a complete list of the possible fields, have a look at the spec, which you can download from the HL7 website at HL7.org. Unfortunately it’s not an on-line specification as FHIR is.

Note that we’re going to use DSTU-2 candidate resources as we are getting close (hopefully) to that being released.

Segment Likely resource Discussion
MSH MessageHeader This will contain the sender and recipient, plus event type (important for workflow), identifiers and dates
PID Patient The patient that this message is about. We’re going to need to think about how to ‘match’ the patient in the message with the patient in our repository (assuming we already have a record of course)
PD1 Patient This will (may) provide additional details about the patient
PV1 Encounter The encounter is going to be the central resource for our little exercise. In particular we’re going to need to think about changes that occur to the encounter with all messages about that encounter
PV2 Encounter More encounter details.
OBX Observation Not entirely sure (yet) what clinical relevance observations are in ADT messaging – but an OBX maps to an Observation – so that’s what we’ll use.
PR1 Procedure Given that ADT are administrative rather than clinical based messages, presumably this procedure is the reason for the admission – i.e. it is the ‘planned’ procedure, so we can’t assume that the patient actually has had it based on this message alone.
AL1 AllergyIntolerance Allergy records are really important in clinical proactice so we really want these. One thing to consider is that as ADT are administrative, presumably these records came about when the admitting clerk asked the patient what allergies that had when they were admitted – rather than being elucidated by a clinician. Is that going to make a difference to how we record them?
DG1 Condition A diagnosis is a clearly a condition – its use here would be the reason why the patient was admitted.
DRG Condition Adds to the condition information.

So we’ve got the basic list of resources we’re going to store in our repository – and we’ll look at each of these in more details in forthcoming posts – hopefully answering some of the points we’ve noted.

But v2 is a messaging standard that represents events in the real world, so it’s not as simple as just converting the message into resources and saving them – we need to think about workflow – how different types of message are going to effect our resources, and some of the issues that flow from those changes.

That can be the topic for the next post…

(Oh, and v2 messaging is not a particular area of familiarity for me – if I get something wrong, or you just disagree with the analysis then leave a comment!)

About David Hay
I'm a Product Strategist at Orion Health, Chair emeritus of HL7 New Zealand and co-Chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

8 Responses to More FHIR Messaging: ADT messages

  1. Pingback: FHIR Messaging: Clinical data from ADT Messages | Hay on FHIR

  2. Thank you for all of your work on FHIR, as well as taking the time to provide such great information to us as consumers.

    In the comparison of v2 segments to likely resources, you state “Not entirely sure (yet) what clinical relevance observations are in ADT messaging – but an OBX maps to an Observation – so that’s what we’ll use.”

    From my experience implementing Hl7v2 messaging feeds, OBX segments in an ADT message are generally used to provide vitals at the time of the encounter. These include, but are not limited to, weight, blood pressure, age, height, and temperature at the time of intake. They may also include admitting diagnosis and chief complaint, and are generally sent within ADT^A08 message types. Additionally, a final diagnosis may come within an ADT^A03.

    I was recently tasked with creating an interface which used a participant’s existing ADT feed within a public HIE to register newborn patients into a downstream system identifying potential risk factors for possible hearing issues. The Early Hearing Detection and Intervention program utilizes OBX segments within an ADT message to capture clinically relevant information such as birth weight and gestational age to set up case management files, allowing them to work directly with the primary care provider to help develop long-term care plans to prevent or mitigate the developmental delays and academic failures associated with late identification of Hearing Loss.

    I hope this information helps establish how observations are able to provide clinically relevant information within the first steps of the health messaging process…

    Thanks again for all of your research. I hope to be an early adopter of the FHIR guidelines, and plan on using the information you provide as the building blocks to learning this exciting development in the exchange of health information.

  3. David Hay says:

    You’re welcome!

  4. Thibaud says:

    Thank you for this very interesting article.
    I am begining with FHIR and I am not sure to understand how does it works when a patient is admited. Does those steps corresponds to what you say at the begining of the post ?
    1. Patient admission data is entered into the PAS client
    2. The PAS server receive the PAS client request
    3. The request is processed by the server
    4. Once the request is processed the client received a ok response and the ADT^A01 is emited to the suscribed systems

    • David Hay says:

      Thank you! I was really more focussing on your step 4 – the generation of the ADT messaging from the server to the subscribers and what the subscribers did with the messages. The details of the interaction between the PAS client & Server are up to the design of the application. Currently these tend to be ‘thick’ desktop applications I believe, though there’s no reason why there couldn’t be a PAS server that uses REST to communicate with its client/s and then emit messages…

      You may want to go and take a look at Ringholm (http://www.ringholm.com/) – they’ve been talking about HL7 messaging for years, and are very active in the FHIR community – Rene Spronk is the best contact.

      cheers…

  5. Thibaud says:

    Another question while reading another time this article.
    Is it possible for the client to comunicate with the server with the FHIR-REST paradigm while this same server work with messages with its suscribers ?

    • David Hay says:

      Absolutely – no reason why a server can’t use multiple paradigms if required – and, of course, the resources are the same…

      cheers…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: