Uncertain dates in FHIR

There are a lot of date properties in FHIR resources, but sometimes you don’t have the exact date. For example AllergyIntolerance has an ‘onset’ property which is a dateTime – but what if all we’re told is that they have been allergic to peanuts since childhood?

Well, assuming that a string is not as an option (as it is for Condition.onset for example) then one way is to use an extension. We’d add an onset property, but leave the value blank and just add the extension.

Here's what is looks like in JSON:
 "_onsetDateTime": {
   "extension": [
     {
       "url": "hl7.org.nz/fhir",
       "valueString": "Since early childhood"
     }
   ]
 },

And in XML:

<onsetDateTime>
  <extension url="hl7.org.nz/fhir">
    <valueString value="Since childhood" />
  </extension>
</onsetDateTime>

Just for fun, let’s think about how we’d create an extension definition that describes that (remember that extension definitions are actually StructureDefinition resources).

First off, we need to decide exactly what the extension is on. There are a couple of possibilities.

1. We could create an extension against the dateTime datatype itself. That way we could use that extension whenever we have a dateTime property that is uncertain
2. We could create an extension that is specifically used for AllergyIntolerance.onset

There are no hard and fast rules for this – probably the first is more reusable, and indeed it’s one that could be defined as an ‘HL7 level’ one (once we’ve figured out the process for doing that of course). However, for this exercise let’s use one against AllergyIntolerance.onset specifically.  (In truth, because we’re going to use clinFHIR to create the extension, and it doesn’t support extensions on datatypes – yet).

First we need to make sure there isn’t already an extension that we can use. As a community, it’s best if there’s only one extension for any particular purpose to maximize interoperability and we’d prefer not to ‘re-invent the wheel’. The infrastructure isn’t quite there to support that yet – Furore have got an initial version of the registry up, but it’s not yet fully populated – but we can see how it could work using clinFHIR. Start the app, then select the ‘Extensions Editor‘. In the search box to the upper left, select ‘Resource’ as the search type, then ‘AllergyIntolerance’ from the drop down of reauce types. Then click the magnifying glass (or ‘search’) icon.

After a short delay’ you’ll get a screen like the one below:

These are all the extensions that have been created to be used for the AllergyIntolerance. You can scroll down the list to see if there’s one that matches – there wasn’t when I wrote this post, but that might change… This is a pretty basic search – and it only works against extension definitions on Grahames server (or whatever conformance server you select in the top NavBar, but you can see how it could work, and where it could be improved (more sophisticated searching – maybe with ‘fuzzy’ logic, checking multiple registries etc.)

So we need to create a new extension. At the top right is a button labelled ‘New Extension’. Click it and you’ll get the following modal dialog. (Note that I’ve filled in the details).

One thing to look at is the resource context (Where it says ‘Resource types where this extension can be used’ at the lower right). Note that it has the complete path of the onset property. This indicates that the extension is to be used on that specific property  not on the resource as a whole. (You are prompted to select the path when selecting the resource type – it’s optional).

So that’s about it – you can save the extension, and if you refresh the list you should see it there, and it’s available to be used in a resource. We can talk about how we could create a profile on AllergyIntolerance that used this extension in another post.

Just a couple of notes:

• The resource builder in clinFHIR doesn’t support extensions on properties – it places them all at the root. (It doesn’t like complex extensions either).
• The Extension Builder won’t create extensions on datatypes. It will display them ok though.

I’m working on these.

By the way, as part of the testing for this post, I noticed that a number of the test servers didn’t like empty properties – I’m not sure if that is a bug or whether there’s an issue in the spec with empty properties. The healthConnex one (http://sqlonfhir-dstu2.azurewebsites.net/fhir/ ) works just fine though…