Extensions are not second class FHIR Citizens!

Hi, my name is Edward and I am a FHIR extension.

David has let me write this short post on his blog, because there seems to be an understanding by those new to FHIR (and possibly those old to FHIR) that extensions are in some way ‘less’ than ordinary resource properties. Nothing could be further from the truth! It is me and my associates that will make FHIR the easiest healthcare interoperability standard to use.

Let me explain.

In the beginning there was HL7 Version 2, which was wildly successful. It’s used all other the place, and most of the time worked really well. But there is a problem, and that is that the core v2 standard doesn’t cover all the things that people need to exchange with each other (and remember – it’s all about the exchange, not about how the data is stored inside a system), so people added their own elements to the messages. Over time this means that there was a good chance that you could receive a message with elements in it that you didn’t understand – and no easy way of finding out what they meant without going back to the sender to ask them.

So, the folk at HL7 designed a new standard – version 3 – that had a common ‘model’ (a way of representing information) that both sender and recipient had to use. In that way both sides would be understand every part of a message. Problem was that because everything that anyone anywhere in the world wanted to send had to be in the model, over time the model (and the messages) became very large and unwieldy and implementers didn’t like it.

So when FHIR was invented by a team led by a clever Australian (originally a New Zealander I believe), they created the idea that each resource would have of a common ‘core’ set of properties that most people in the world included when they exchanged those resources – and a way for different people to easily add the extra stuff that they needed, but others didn’t. And that’s where I come in!

See, without me, FHIR resources would just get bigger and bigger and bigger until they were just like v3 messages, and just as hard to implement! And you don’t want that – do you…

In my opinion, the problem is that when the FHIR team say that something has to be in ‘the 80%’ – i.e. that most implementers are already exchanging that type of information – before it is included in the core, people take that to mean that the 20% is in some way inferior – second class citizens – and that’s just not true! We are going to be what makes FHIR work!

After all, you can use me to represent anything that you want to – using all of the other cool parts of FHIR (like the simplified datatypes, JSON & XML). I can be nested and queried. I am described in a standard way (in a Profile) and when I am in any instance of a resource, there’s a pointer to that Profile so you will always know what I stand for! You can even tell when I change the meaning of a resource (like when something DIDN’T happen).

I’m easy to use – for example here I am giving a persons eye colour:

<extension url="http://spark.furore.com/fhir/Profile/demo#eyecolour">
   <valueString value="blue"/>
 </extension>

or if I change the meaning of a resource:

<modifierExtension url="http://spark.furore.com/fhir/Profile/demo#drugGiven">
   <valueBoolean value="false"/>
 </modifierExtension>

and in both cases, if you don’t know what I mean the description is just a click away! (Actually I made the URL’s up – but you see what I mean).

I’m going to be especially useful when the experts from other standards – like openEHR – start to use FHIR. Rather than getting into big arguments about what should be in the core and what shouldn’t – just create an extension and you’re done! (Plus a profile of course…)

So in conclusion, please don’t ignore me when you’re starting to use FHIR. I’m just the same as the ‘core’ properties – and so much more flexible…

Thank you for your time, and I look forward to helping you with your interoperability work!

* Updated

To define a search query for eye colour, you would define that in the profile like this:

<query>
         <name value='findByEyeColour'/>
         <documentation value="Allows a caller to find all patients based on eye colour"/>
         <parameter>
             <name value="eyecolour"/>
             <type value="string"/>
             <documentation value="The eye colour to search on. "/>
             <target value="Patient"/>
         </parameter>
     </query>

The implementation would be dependent on the server, though a standardized method may be defined in the future.