Basic Pregnancy Logical Model

So there was an interesting conversation in the FHIR chat just recently about representing maternity information in FHIR. It was pointed out by Lloyd that some elements that seem simple – like the LMP (Last Menstrual Period date) – are actually more complex than that, they are more properly Observations made by someone, at some date, with a degree of certainty etc.

So what this means is that a single logical model – like a summary of pregnancy – is going to wind up being represented in FHIR by a number of different resources, presumably ‘bound together’ in some way (eg  a bundle of some sort Document/Message – or just a Composition with appropriate references) and described by an Implementation Guide.

Given that I’m working on a logical modeler in clinFHIR, this seemed like something to address. Here’s where I’ve got to so far.

I started by getting the requirements for a basic logical model from my colleague Peter Jordan (now the chair of HL7 New Zealand), and this is what he gave me:

(he did note that this is a very basic model!)

So based on the chat – at least the LMP and EDDs are going to be Observations rather than a simple dateTime (or date) property. To enable representing this in the model, I made a few changes to the clinFHIR logical modeler, and created the beginnings of a Maternity model.

(You can look at this directly in clinFHIR by setting the conformance server to the SNApp server, then selecting ‘Logical Modeler’ from the ‘gear’ menu to the upper right. You should see a Maternity model in the list to the left. I can’t guarantee that this will always be present of course – but there are plenty of screenshots in this post).

Here’s the designer view of the model:

When creating (or editing) a model element, there’s now an option in the bottom left labeled ‘Map to Model’ which allows you to indicate that this element is actually going to be represented by another model (presumably one that is represented as a profile on a single resource – though I gues it doesn’t need to be) – rather than a single datatype. To keep it simple, you still indicate the datatype of the element (as that is what will make sense to a Clinician). Here’s a screenshot:

(The Mapping path is the path in the base profile – this needs more thought)

As you can see, I’ve indicated that this element is actually going to be an ‘instance’ of NZ-SimpleObservation – a model that profiles an Observation for representing a single value.

Then, I updated the ‘References’ tab to show these references, as well as the ones that are ‘real’ reference types:

and an additional column to the Table to be explicit about ‘referenced’ elements:

Oh, and here’s the mindmap:

This exercise does bring home the fact that we (or at least a particular jurisdiction) need a ‘library’ of ‘core’ models that can be used to create these larger artifacts – similar to openEHR’s archetypes or CIMI, but more constrained, rather  than the concept of a maximal dataset.

There’s still a long way to go – and the UI definitely needs more attention – but I think that it shouldn’t be impossible to generate the real profiles (and the Implementation Guide) from this model – maybe they could be simple resources that a tool like forge could then pick up and refine. I’m keen on exploring Grahames Mapping language for this…

And we need to decide up front what this model will represent – for example a FHIR Document or Message exchanged between partners would seem to make sense here (which would mean that the ‘base’ model would be a Composition…)

And it should also be straightforward to build sample resources from the models (as well as from the real profiles)

So there you go – moving forwards! More examples are really going to help, so ping me if interested in working on this…

Btw – I’ll likely be showing this capability as part of my presentations at the upcoming developer devdays if you’re going to be there…