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:

patient Patient() 1
lead maternity carer Participant() 0…1
LMP – last menstrual period date/time 0…1
date of conception date/time 0…1
gravida integer 0…1
parity integer 0…1
EDD By Dates date/time 0…1
EDD By Scan date/time 0…1
EDD Agreed date/time 0…1

(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…



About David Hay
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.

5 Responses to Basic Pregnancy Logical Model

  1. Peter Jordan says:

    Great start David – glad that you’ve used date, rather than date/time for the relevant elements. As others have commented recently around DOB, adding time adds a whole heap of unnecessary complexity.

    • Peter Jordan says:

      …and to emphasise the point about just how basic the above model is, the NZ data dictionary for maternity is a door-stopper, weighing in at over 300 pages – and even the constrained HISO CDA Maternity Summary standard is fairly substantial. This domain represents a significant challenge for FHIR logical modeling.

  2. Koray Atalag says:

    Just chipping in here – in openEHR for non-atomic data types we usually use other archetypes which you are familiar with but over a long time we recognized the need for a lightweight archetype approach which doesn’t bring along all the clinical semantics (e.g. an openEHR Observation archetype has to have certain data elements dictated by the EHR Reference Model – which is an overkill). Our solution was what we call “Structural Archetypes” that are just trees (using CLUSTER data structure). This was we can reuse certain composite data elements which are tightly couples (such as the LMP which obviously needs to have certain other attributes depending on your use case). See one example (level of exertion):
    I guess you can already use List resource for that – but if you need more clinical semantics then going for Observation might be a solution.

    • David Hay says:

      Thanks Koray – in that model I was assuming that we’d use a profile on Observation for that – I’m hoping to give it a bit more of a test when I try to do the full maternity spec – we’ll see what happens then! Thanks for the link – and the comments…

Leave a Reply

%d bloggers like this: