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!)