Creating Clinical and Analysis models

As you may know, one of the things that excites me about FHIR is the potential that it has to involve the clinician in the design of health IT systems (and I’m using ‘clinician’ in the widest sense – doctor, nurse allied health etc – anyone who delivers care to a patient).

So far a lot of my thoughts have been theory rather than practice, so it is great to try these ideas out on a real project – the reporting of Adverse Drug Reactions (ADR) by a clinician to a central service – such as a National EHR!

The primary Use Case is:

1. Clinician suspects an ADR
2. They complete a form which is submitted in real-time, and becomes part of the clinical record, but is also used for ‘population’ based reporting.
3. The data is assessed and recommendations given around the likelihood of it being a true allergy, and management advice.

Eventually, we’d like step 3 to become automated – and, ideally, in real-time using some form of automated Decision Support.

The value of this is not only in reporting (which is the primary use at the moment), but because it’s important clinical data about the patient, it should be made available to other clinicians involved in the care of the patient. And because the data is coded and the source known, it will allow the viewing clinician to make their own judgements as to the accuracy of the reaction when making a prescribing decision, and also to feed back into automated Decision support.

In this post, we’ll take a look at how we might define the contents of the form that is submitted in step 1 – what is the information we need to receive from the submitter?

The overall design process is as follows:

Using the Logical Modeler in clinFHIR, the Clinicians or ‘Subject Matter Experts’ (SME) – create a ‘clinical’ model that represents the information they believe is necessary to properly determine if the reported reaction can be assigned to a specific substance, and should appear in the patient’s allergy list. This model is very much from the perspective of the clinician – there’s no attempt at this stage to decompose it into FHIR resources, but in particular it does attempt to identify the elements that should be coded – and as much detail about the codes as possible (These will, of course, become ValueSets)

Using this model as requirements, a ‘FHIR Analyst’ then constructs another model that more accurately reflects the underlying FHIR resources and other artifacts (eg Extension Definitions, ValueSet, NamingSystem) that can, in turn, lead to the definition of the various profiling artifacts either as a manual or an automated process.

I suspect that these models will, to some extent, exist at the some time, as the process of defining/building the profiling artifacts may lead to questions back to the SME, and the models will iterate as the design progresses. However, my hope is both models will be ‘understandable’ to the clinician, even though they may not have created them.

So let’s take a look at the example of the Adverse Drug Reaction (ADR). We’ll start with a model that was created by a clinician – John Fountain (Do note that this is incomplete – it’s very much a work in progress).

We’ll take a look at each section in turn, starting with the Patient Details

The column to the left is the ‘Clinician’ model, and to the right is the ‘Analyst’ model. This doesn’t show the details of the models – including the datatypes –  but we’ll call out the important parts in the discussion.

• The first thing to note is that in the Analyst model, there are 2 groupings – demographics and observations. The demographics are going to appear as a profile on Patient resource, while the observations will be Observation resources – and will have the date/time collected as well.
• Next note that different components of name in the clinical model have become a single entry in the Analyst model. It has a datatype of HumanName, so the other elements aren’t needed.
• We’ve kept the NHI – in the Patient resource it will be an Identifier with a fixed ‘system’ to represent the National Health Identifier.
• The ethnicity is going to become an extension – likely a CodeableConcept referring to a national ValueSet.

The next node we’ll take a look at is the substance node:

Quite a difference here! (But one that is completely expected). Remember that the clinician is describing all the information that they want to be collected so we’d expect it to be a longer list. It’s the Analyst that can then pick the FHIR datatypes that will best record this data (but – once picked – the Clinician can easily verify that all the data they specified is present).

• For a start we’ve collapsed SubstanceCode and MedicineName into a single element – substance. This is because we really only want one place where a consuming application needs to look for the ‘thing’ that the clinician thinks the reaction is to. And there are many similarities between a medication and some other substance (sea food or peanut perhaps) in terms of the data we wish to capture. We’ve included a ‘substance.type’ element – though this might not be necessary as the code element might provide sufficient discrimination (it’s a CodeableConcept, so gives us the name of the substance, code in the terminology (SNOMED in this case) and a text field).
• The period has a datatype of Period – so we get the start and end dates (we might consider re-naming the element to ‘periodfOfExposure’)
• The dose element is where a lot of the elements from the Clinician model has gone to (like dose value/unit, frequence & route). This is actually an ‘internal’ Logical model in the FHIR spec called Dosage as it is so widely used in the pharmacy domain – here are the details. (Of course, in the Logical Modeler there’s an icon that will load this page – or the details of any datatype for that matter). In the case of a ‘substance’ it is likely that many of these fields will be unused – but that doesn’t matter. There’s only an issue if there’s a field for a substance that we can’t accommodate where we’d need to think again.

Now for medications:

Again, we’ve been able to represent the required fields more simply – the medications element is simply a repeating series of MedicationStatement resources. We may want to consider having a ‘top level’ element called ‘currentData’ with medications and previously identified allergies below that (using AllergyIntolerance for the existing allergies). Maybe even the current problems. Lets see what our clinicians think 🙂

The last element we’ll explore here is the reaction.

Not so different really – just having a single dateTime datatype for the onset – though again a period might prove useful. I expect there’s more data to go in here in the next round! Interestingly, there’s talk of a separate ‘AdverseReaction’ resource being defined (though it hasn’t made it into the spec yet) that may be of interest. We’ll probably need to move before that becomes defined – but it might be an opportunity to feed our requirements back into the community.

So there‘s a first cut at going from a ‘Clinician oriented’ model to a ‘FHIR oriented’ model. Of course this is only the first iteration – there will be plenty more as we challenge both of these models against as many Use Cases as we can find and as many clinicians as we can find before we land on a final version – at least one that all can agree on, even if we don’t get complete agreement! During this process we’ll also work to define the ValueSets and locate/build the Extension Definitions and other artifacts that we’re going to need.

And what’s nice is that we can open the logical model in the Scenario Builder to enter some real data – it isn’t real FHIR of course, but it let us prove that there is a place for any of the data items we need to capture.

The next stage (once we’ve agreed on the model) is to convert this into real FHIR profiles and one interesting thing to think on is what these profiles are going to look like – and how many there will be. Take the patient for example, do we create a single patient profile for New Zealand that all of our profiles use (refer to), or do we create one specifically for this project? If we do create one for this project, then we can absolutely describe what are the elements we’re interested in – but if each project has it’s own profile, then we’re going to have a lot of them! (We can have profiles that alter other profiles, so there are quite a few options open to us).

In this case it seems more sensible to create a single Patient profile that everyone uses, and accept the fact that there will be elements that we don’t need – but there are some fish hooks with this approach that we’ll need to think through. For example what do we do if one project needs to make Patient.ethnicity a required field? Time will tell how this gets managed…

We’ll also need to think about the ‘paradigm’ of exchange, and whether we want to define a Questionnaire resource to help capture the information we want…

Incidentally – this is exactly the exercise (with a bit of training as well) that we be doing both at HINZ and Devdays in November. Come along if you’re interested (and bring your laptop!)