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.

Here’s what it might look like, with the arrows representing the flow of v2 messages:

The resources we identified that we could get from this data were:

• Encounters (always useful to know when people have been – or are – in hospital)
• Conditions – actually ‘Diagnoses’ relating to those encounters. Not as good as a formal problem list, but still helpful. (And, once we get the basics working, there are other Condition-related messages that we might tap into)
• Allergies – good to know those! Of course, the provenance of allergies from ADT messages might not be as good as coming from clinical messages, but still useful.
• Procedures – well, you would expect a hospital to know what procedures they are performing.
• Observations. Not quite sure what these represent in the context of an ADT message, but let’s store them.

Now we’re said that we’re in a messaging paradigm now, but what does that actually mean?

Well, as the diagram above shows. we are receiving messages that have been sent by another system (generally the PAS) in response to real world events that occur as the patient is treated in the hospital. This has a couple of implications for us:

• We need a way to link all the messages to the same patient (actually, the same encounter or visit for that patient). In fact, this extends to the actual model itself – there needs to be some link from each resource to the message that created it (or at least to the Encounter resource that represents it).
• We need to think about what the impact each message type has on our data model, which will vary according to the event that it is describing.

(Actually, in real-life we also need to consider how to manage ‘out of order’ messages – what do we do when, say, a bed transfer message arrives after a discharge message? This is an implementation issue, and so we’re going to ignore it in this discussion, but if you’re doing this for real then you will need to decide what strategy you are going to follow – for example you could reject such messages and make the sender decide what to do, or you could make a decision based on the date of the message – or anything else, an exercise for the reader 🙂 )

So what does our model look like? Well, here’s a first draft:

Note that all the ‘clinical’ resources have a link back to the encounter where we got them from. We’re going to need this to be able to properly manage changes that might occur due to workflow issues, and also as a kind of ‘provenance’ – knowing the source of clinical information is always important. (Actually, there’s a formal Provenance resource that we could use if we wanted to).

In most of the resources there is a property that makes sense:

• Condition: Encounter when condition first asserted. We’ll be setting the Condition.category to ‘diagnosis’, and creating a new Condition for each visit (as the diagnosis is about that visit).
• Observation: The healthcare event where this observation is made
• Procedure: The encounter when the procedure was performed
• AllergyIntolerance: This needs to be an extension, as there is no encounter reference available. You could argue that this should be similar to Condition – i.e. that there should ‘encounter first asserted’ property – if you feel strongly about it, then raise a change request on the spec – we’ll just use an extension.

We haven’t indicated any Patient, which all of the resources will have a reference to. As we’re getting information from different sources which will have their own patient referencing systems, this is going to need some thought which we’ll go into in the next post.

OK, so we have the model – let’s think about what each message is going to do to our model (we’ll come back to the question of linking all messages to the same ‘encounter stream’ later on).

There are a lot of messages to consider – over 60 of them in the 2.4 spec (which is the version we’re using)! The actual messages that are used will be different in each implementation, and we don’t have space to consider them all, so we’ll pick a selection that will highlight the major factors that we are going to need to consider.

The table below lists some of these messages and the impact on our model. For readability, we’ve just included the event code, so A01 is actually ADT^A01.

Some of these messages are reasonably straight forward to process – and others are not!.

(btw – it’s a good idea to read this in conjunction with the v2.4 spec – it’s in chapter 3 – Patient Administration)

So there’s a few things we’re going to need to give careful thought to – and these are likely to be ‘implementation dependant’ – i.e. they will vary between different hospitals.

• How is a single ‘visit’ identified – i.e. when we receive a message, how can we identify the Encounter that this message is going to effect?
• Which messages will create a new encounter, and which ones will update an existing one?
• How is the patient associated with the visit? There’s both the concept of the ‘patient account’ and the ‘patient identifier’ to think about.
• What do we do with the extracted clinical data when the patient identifier changes on the encounter? (A45)
• What is our strategy for updating clinical data within a visit when there are updates, as quite a few of the messages have the capability to include clinical data?
  • Do we assume that each message has the complete set of data (i.e. a snapshot at a point in time), or are they updates? Suppose the A01 message has a particular diagnosis and an A02 doesn’t – do we remove it from the list of diagnoses for that visit?
  • Should we ‘accumulate’ data? E.g. if the A02 contains a diagnosis that wasn’t in the A01 do we just append it to the list
  • Do we update at all? Should we create a set of clinical data from the A01, and then assume/require that the source system send an A08 or A28 when the clinical data changes?

So there are a few things to think about (and I’m sure many others that we haven’t listed here). To keep things moving we’ll make the following assumptions (your assumptions may be different):

• That the PV1-19 contains the visit identifier – that’s the formal way that we’ll recognise messages belonging to the same visit. We’ll also use a combination of the MSH-4 (sending facility) and MSH-3 (sending application) to recognise messages from different hospitals (and different applications from within those hospitals)
• That the PID-3 holds all the patient identifiers.
• That we’ll use the A01, A04 or A05 to create the clinical data, and require an A08 or A28 for updates to that data – and that the update will be a snapshot – it will replace the data that is already present for that visit.
• That we’ll support multiple identifiers for a patient – but keep data against the identifier that was specified when we receive it. We’ll ‘resolve’ multiple identifiers for a patient at read-time. (ie when a querying system asks for data using an identifier, we’ll resolve all the identifiers for that person – using an EMPI – and return all the matching data).
• If the patient changes as a result of an A45, we’ll assume that there will be an A08 message that will follow with updated clinical information. This message will be able to change the subject associated with these resources.
• We’ll be tolerant of ‘out of order’ messages, but we’ll use the message time (MSH-7) to decide what action they will have. For example, if we’ve received a discharge message (A03) and so set the encounter.status to ‘finished’ and then we receive a bed transfer (A02) then the action will depend on the relative dates. If the transfer message is dated after the discharge then we’ll revert the status to ‘in-progress’, otherwise we’ll ignore the bed transfer (though we might update the status history).

In practice of course, we’d need to ensure that the source systems abide by these rules. If they don’t, then we’ll either need to change our system – or possibly use an Integration Engine to update messages from specific hospitals to make them compliant. For example, if a particular hospital does not emit A08, but does include a snapshot of clinical data in all update messages (like an A02) then the Integration Engine could create an additional A08.

So let’s take another look at our list of supported messages and what they are going do in our system.

That’s quite a chunk to think about! And hopefully explains why workflow is so important, and why this stuff can be so complicated! We’ve just looked at a small selection of messages – and all we’re really doing is to maintain a store of resources – imagine if we were writing a PAS ourselves!

In the next post we’ll delve into architectural issues and think about what we need in our FHIR server to support these messages. Oh, and if you disagree with anything in the post – feel free to make a comment!