Clinical Scenarios in FHIR – II

In a previous post we talked about the clinical connectathon coming up at the next Working Group Meeting, and described how we could use FHIR resources to represent one of the scenarios – the chronic care scenario. Looking back, much of that scenario was around the creation and maintenance of a Care Plan (which might be worth a re-visit at some point). In this post, we’re going to shift gears a bit and look and another scenario created by the Patient Care Working Group – the Acute Care Scenario.

This is a complicated scenario that describes a patient being assessed in ED for abdominal pain (that turns out to be related to over-use of anti-inflammatories), so we won’t copy the whole scenario in this post (here’s the link for reference) – but at a high level the flow is as follows:

1. A patient attends ED with acute abdominal pain, and is triaged on arrival by a triage nurse
2. He then has an initial assessment by an ED nurse
3. Next comes the ED Doctor who also does a history and examination, starts treatment and orders some investigations
4. The registration clerk completes some of the administrative details
5. The orders that were made by the ED doctor are completed, and the results are gathered in due course.
6. After the results are back, the ED doctor completes the diagnosis and on going treatment (which includes a new medication) and a referral to the outpatient clinic. The patient is discharged.
7. Following discharge from ED, the patient is seen in the outpatients clinic for a few months until eventual discharge from that clinic as well.

Looking at this flow of events, the first thing that is apparent is that there are a number of different contacts between the patient and hospital staff – most of which are clinical and include both observations and orders. Given that we want to be able to record who did what, this suggests that for the ED visit at least, one way to model this is to have a number of different encounters under the ‘umbrella’ of a single ED encounter. The FHIR encounter resource has a ‘partOf’ element intended just for this purpose, which gives us a picture a bit like this (showing only the encounters and their associated Practitioner participant):

Each encounter resource will have:

• The period over which the encounter took place (start and end date/time) – and/or the length of the encounter
• A reference to the patient (the subject).
• A reference to the participants that were involved – eg the Triage Nurse, ED Nurse, Doctor
• If we want to specifically record the reason for each encounter (e.g. triage, initial assessment etc) , then we can record that in the reason element (which is a CodeableConcept).

The ‘parent’ encounter resource that represents the ED visit will have additional elements that relate to the overall ED attendance rather than each contact with a clinician, such as:

• admitSource – the fact that patient attended directly
• the reason (or indication) – why the patient attended
• dischargeDiagnosis. This is a resource reference, so we’d most likely create a condition resource (peptic ulcer), and reference that. The condition resource has elements for properties like certainly, severity, evidence and so forth that might be useful. It also has an encounter reference that we can link back to the encounter so we know when the diagnosis was made.
• dischargeDisposition – that the patient went home rather than being admitted
• We might also want to reference all the participants as well

One question is whether we have an encounter resource for the registration clerk. From a clinical perspective it’s not necessary, but local policy may require that to be recorded as well.

The Outpatient visits would also have encounters – but these are likely to just be single encounters rather than multiple ones.

So the encounters form the ‘backbone’ of the record – how to record the actions and observations that were performed/noted?

Many of these will be recorded as observations (the history from the patient, the vitals, clinical assessment and so forth). A couple of notes about our use of observation:

• We definitely want to be able to reference the encounter from the observation. While the observation does have a reference to the person who made the observation (the performer) we do want to be able to aggregate at the encounter level as well. We noted this in the previous scenario – so we either use a common extension or we add an ‘encounter’ reference to the observation. (Note that the direction of the reference is from observation to encounter – not the other way around. If it was from encounter to observation we’d need to be updating the encounter very frequently so it’s better this way. Having said that, another possibility might be to have a ‘details’ extension on the encounter that references the observation).
• We want to be able to record observations that the patient made. Looking at the observation the performer property does not include patient, so we probably want to get patient added as a valid option here (and there’s a request in for that for the next ballot)

There were a number of Orders made throughout this encounter. Some of these were for treatment (IV fluids, Oxygen, pain relief) and some were for investigations (blood tests, a CT scan). In FHIR there is the Order  and OrderResponse resources that manage the workflow involved in these activities, with the details of the actual order being indicated by resources within the order (in the detail element – DiagnosticOrder for the investigations and MedicationPrescription for the treatment). Again we might want to be able to link these orders back to the Encounter where they were generated so either a standard extension or an update to the Order resource is required.

(Actually, given how often this kind of reference is going to be required we should probably get the standard extension organized so we can use it anywhere. We certainly don’t want every single resource to have to have have an encounter property, and it’s hard to predict when it will be required.)

The results of the various investigations can be represented as DiagnosticReport and ImagingStudy. It’s unclear whether these require a specific encounter link – and this will probably depend on the specific implementation.

The referral to the Outpatient clinic would be another Order, with the new Referral resource (under development) as the detail property.

So having collected the resources for this scenario, how do we package it to send to another provider (like the patients primary care provider)?

Well technically it’s quite straight forward – this would be a FHIR document (as it’s a summary of a clinical encounter) consisting of a bundle (atom feed) with a Composition resource as a header (like in CDA) and containing the ‘section’ references, and all the resources as contents with internal references as required. Easy.

But we might want to think about what the purpose of the document is – and maybe align ourselves with C-CDA and the document types defined in Meaningful Use. There are a number of documents types we could use, but let’s pick the Consultation Note (Discharge Summary might be a better choice – but let’s stick with Consultation Note for the moment). Reviewing the requirements, we see that there are 2 required sections:

• History of present Illness (another Observation)
• Care Plan (a CarePlan)

And a number of optional fields:

• Immunizations
• Medications
• Problems
• Procedures
• Reason for visit
• Results
• Review of Systems
• Social History
• Vitals

So what we need to do in our document is to add the required sections in the composition, and from there refer to the appropriate resources – either directly or through an intermediate resource like a List (for example, in the medications section we’d probably refer to a List resource which in turn refers to the actual MedicationPrescription resources. This has the added advantage that it allows us to list all of the patients medications – not just the one we added – and even record updates to the list, like a discontinued medication).

And the Composition has an entry for encounter that we’d use to refer to the ‘parent’ ED encounter, which also has the references from the other encounters.

The diagram below shows a small sub-set of what the document might look like – with only a small number of the resources and links shown. (Actually, the details of this might be a good candidate for another post some time…)

In real life we’d probably only include a summary of the ED visit rather than all the detailed interactions that there were – but it’s nice to know we have the option if we want to!

So to wrap this up, we’ve looked at our second clinical scenario to see how it could be represented in FHIR. Like the first one, there are no obvious gaps, though a more detailed analysis might be needed to confirm this – and the scenario does include a referral – and that resource is currently in development.

We used multiple encounter resources to separate out the different contacts with a clinician – perhaps a bit over the top as there are other ways of linking activities to the person who performed them.

One of the most interesting outcomes is the desire to link many of the resources back to an encounter. Given that there are many possible resources that might want such a link, it might be that the best approach is to use a standard extension for this – rather than adding ‘encounter’ to all resources – or just some. A good topic for debate! (but don’t forget that extensions are first class citizen in FHIR)! If we do go down this route, then we (the FHIR team) might want to think about how to make querying on extensions a bit easier…