FHIR Medication lists revisited

We’ve looked at representing a patients list of medications in a number of previous posts. This one describes using the List resource to describe the list, here we talked about updating the list using a transaction, and here were some thoughts on what a regional shared list might look like.

Just recently I’ve been involved in doing some more detailed design for this, as we’re looking at building a concrete implementation at Orion Health, so I’ve revisited how we could do it.

Business Requirements

The business requirement is to have (ideally) a single place where ‘medication reviews’ can be placed, and we imagine a number of different review types ranging from a comprehensive clinical review, through changes made on discharge from a hospital – to a review by a patient indicating that there are meds they are taking that are not on the most recent list.

This should make it easer for a consuming system to find the ‘current list’ (the most recent review – possibly of a specific type or types) and the history of changes (all reviews over some period). Having this information readily available – and accurate – can lead to a significant improvement in the delivery of health care – and the potential for considerable financial savings.

For each medication review we need to record:

• The date/time of the review
• Who did it
• The type of review. (eg a simple update to record a new mediation added, or a comprehensive review of all mediations)
• Where the review was performed (hospital, GP surgery, pharmacy)
• Who the funder was
• The list before the review was performed
• The list after the review – including any changes and why the change occurred. This includes medications that were stopped, as well as changes to existing medications (like a change in dose) and new ones.

For each medication item we will need:

• The medication name and code
• The generic drug name and code (if not already a generic medication)
• Dosage information (including ‘as needed’ or PRN status)
• Patient instructions (as we anticipate that the patient will be participating in this process)
• Reason for prescription
• Duration of treatment

(The idea is that there is sufficient information for each item to be able to generate an order – a prescription – if needed)

In terms of accessing the reviews, we need to be able to:

• Retrieve the most recent List for a Patient (of a certain type/s)
• Get a summary of list changes by type
• Retrieve a history of changes to the List
• Update the List
• And doubtless others we haven’t thought of yet…

There are going to be a few things to think about as we go though this so we’ll think about it in a couple of posts. This one will focus on the modelling of the list, and the next will look at some practical implementation issues concerning the interface (API) and some considerations based on the storage technology.

We will also be creating a Profile that describes this Use Case.

As an aside, in true FHIR fashion, I’m hoping that we can create a working prototype of this application so that we can see whether it delivers on the requirement – and what needs to be changed! This also helps in getting buy-in from the various actors in this space as well of course…

So lets think about the Medication resource first.

In the previous posts we used the MedicationPrescription resource, mainly because it had dosage information plus reason for prescribing, whether to take regularly or ‘as required’, duration of treatment and so forth. However, it’s been pointed out that MedicationStatement might be a better choice as MedicationPrescription is more suited to a specific order instance. And, referring to the spec, this use is one of the usages in scope – so MedicationStatement it is.

However this decision does mean that we need to add a few extensions to meet our requirements:

• Generic medication (#generic – Reference to Medication resource). The medication resource has an ‘isBrand’ so we can tell if we need the extension.
• Reason for prescription (#reason – String)
• Patient Instructions (#patientinstructions – String)
• Duration of treatment (#duration – Period)

Now, for each of these we need to decide the extension type and an extension name that will be in the Profile that contains the extension definitions. This is reasonably straightforward (and in the list above for reference).

Next, lets think about how to represent the List itself.

Looking at these requirements, it’s obviously going to be a List resource. This will give us the patient (List.subject), who did it (List.source) and date/time (List.date). List.code will give us the type of list (loinc 10160-0 – history of medication use).

We’re going to need some more extensions though, so:

• Where the review was performed. Probably a Location resource, so an extension of type ResourceReference on the List.
• The funder of the resource. An Organization seems the closest fit at the moment – unless the Financial Management committee comes up with something closer. So – an extension of type ResourceReference.

Next – how to represent the ‘before’ and ‘after’ lists. Well, there’s a couple of options here.

We could infer that by only including the current list, and comparing the current list with its immediate predecessor to get the difference. But that means we need to retrieve that list and perform the comparison. Plus – it’s a bit harder to record why the change was made. And – how will we know for sure that that was the list that the reviewer started with?

A better solution will be to use the characteristics of the List.entry element – plus an extension. The specific elements we’ll use are:

• entry.flag. This is ‘workflow’ information about this entry so we’ll use that to record whether the medication is new, unchanged from the previous, altered in some way or discontinued. We’ll talk more about this in a moment.
• entry.deleted. We’ll set this true when a medication has been stopped (as well as setting the appropriate flag). This is a ‘modifier’ element, which means that clients need to understand it, so there’s no risk of a client not realizing that the medication has been stopped (assuming a compliant client of course).
• entry.changeReason (extension). This extension allows us to indicate the reason for the change. We’ll use a CodeableConcept data type so we can have a consistent set of reasons – yet still support text. (This is a nice example of applying extensions to a specific resource element, rather than to the resource as a whole)

Here’s how it will work.

Now, the flag element has a datatype of CodeableConcept and in the specification has an example binding to http://www.hl7.org/implement/standards/fhir/valueset-list-item-flag.html which happens to be change codes for medications use – just what we need! But – this is just an example binding, which means we can’t rely on it always being the same. We need a way to specify a specific binding. (Oh, if the term ‘binding’ is new to you – it refers to how we  ‘bind’ the coded element to its list of possible values).

It may be that there is an existing codeset we can use – and for maximum interoperability this is the best option. But there will be many situations where this isn’t the case, and this is where the ValueSet comes into play. We’ve talked about ValueSets before so won’t repeat that here – and in any case we have a different issue to resolve.

To perform the binding we use a system element that identifies the collection of values that can be used for the flag element (Actually, it’s the coding datatype within CodeableConcept to be precise) – what do we use for that? My original thought was to use a uri to the ValueSet definition, but after some discussion with the community (via the implementers chat – indispensable for this kind of question) we agreed that this isn’t the best approach for a number of reasons, not the least being that a system is not always a ValueSet. There isn’t any ‘best practice’ for this at the moment, so the best solution for now is to use a uri that you know will be stable, and place a page there that describes the system (possibly with a link to the ValueSet).

The same discussion applies to changeReason.

We also need to decide what mode the List is operating in. Given that we’re recording a series of reviews, the appropriate mode is ‘changes’ – ie changes that are occurring to the list as a result of the review (if any). This allows us to record items that have actually been removed from the list – using the deleted element as described above.

So putting all that together, here’s what a single MLOM would look like:

In the next post we’ll take a look at the options for the actual API to the service (eg the REST interface), as well as some more practical considerations – some of which rose out of the actual implementation architecture that we are considering. We’ll also have a think about how to represent multiple lists in the response.