Extensions are not second class FHIR Citizens!
March 6, 2014 24 Comments
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.
About David Hay
Can you please provide an example how you would query an extension? For example, I want to query on my extension for eyecolour.
In the Profile you can define ‘custom’ (named) queries – and they can include extensions as criteria. I’ll update the post to put an example of this in…
cheers…
There’s actually two ways to search on extensions. You can use the Query mechanism, but you can also define custom search criteria in Profiles in exactly the same way you can define custom extensions.
How do you actually go about calling your query? Does it work like a search parameter, e.g. {{URL}}/Patient?findByEyeColor=Green ?
If so, can it be combined with other parameters, so for example, all patients where eye color is green, and first name begins with ‘A’?
Hi Andrew – you’ve got it. In your definition of the search parameter (which in STU3 is a separate resource btw) http://build.fhir.org/searchparameter.html you define the code for the parameter name and then it works like any other (on servers that support your extension of course – it will be server specific).
cheers
Hi Ted – my name is Ethnicity and I’m also a FHIR Extension. While I realize that I’m banned in some countries and restricted to a single instance in others, I would feel happier if my failure to make the core resource set was justified by something like…”in the opinion of the FHIR Management Group” rather than unverifiable usage criteria. An Extension property to hold a mapping to any CIMI field, like those nice links to HL7 v2 segments and RIM properties, might also help those wishing to use both openEHR Archetypes and FHIR.
Hi Ethnicity – good to speak with you, but you do need to raise your self esteem a bit! Not being a ‘core’ property is not a ‘failure’ in FHIR – after all, do you really want to be a part of the common herd? This is where FHIR differs from the other standards after all. Be proud! You are on the same team! You’re desire to be able to be mapped to some other system does seem reasonable though, perhaps the nice people at FHIR will add that ability for us.
Oh, and I should also say that it is the various Working Groups within HL7 that make this call – with the assistance of FMG and the FHIR core team of course…
FHIR already has the ability to map to any specification desired. All that’s required is to find someone willing to do the work of deciding what the mappings need to be and adding a column to the spreadsheet that defines the resource. That said, mappings will likely be most useful if they’re to specifications that have roughly the same granularity as the resource. A more useful approach for most CIMI models, and perhaps some Archetypes will be to create profiles and define the mappings there.
I get it. The profile has a collection of mappings that other elements within the profile (core elements and extensions) can use. Again, showing that extensions are no different to core elements other than the frequency of use!
Pingback: FHIR Profiles: an overview | Hay on FHIR
David, What we have now in FHIR is two parallel worlds: the world of creating and maintaining base resources, and the world of creating and maintaining profiles. The team at MITRE has spent a great deal of time in the world of profiling, and believes that this design choice will hinder the widespread adoption of FHIR. I think the two worlds were originally created because of governance considerations, one side being tightly managed, and the other the land of the user. However, governance can be enforced without the need for two parallel technology tracks. Having different technology tracks for resources and profiles causes many unnecessary complications. This complexity exhibits itself in terms of irregularities in wire formats, validation, in the build system, the documentation, in the simplicity of reuse — essentially, in every important respect. The MITRE team feels that FHIR could retain all its good properties, including extensibility, but at the same time, could be vastly simplified by combining these two worlds into one.
Well, if we retain the notion of extensions, then by definition, we have to have two worlds. The resource contains the stuff everyone gets. The profiles introduce extensions not everyone needs. If we eliminate profiles, then we have to put everything anyone needs in the core resource. And we’ve been down that road before. I think you know that, which means you must be proposing something else – can you explain further?
Yes, I am proposing a radical simplification that will make FHIR easier, faster, and much less complicated for authors and developers. Let me explain.
Currently, we know resources are “core” because they are resources, and we know profiles are “not-core” because they are profiles. We have accepted these two worlds in order to make this distinction. The distinction is necessary, but the two worlds are not. The information differentiating “core” and “not-core” can be carried by other indicators of provenance. These indicators are in fact, already present. If we remove the distinction between resources and profiles, the provenance information would still indicate the core resources, and differentiate from those defined by other individuals, groups, and organizations.
For example, DAF-Condition would still carry provenance information indicating it is a creation of the ONC for US Realm. It would still be based on the core Condition resource. This would not change. However, the structure definition for DAF-Condition could be altered to be the same as the structure definition of a core resource. The extra elements defined by DAF-Condition would be represented the same way as core elements of Condition.
At present, the first world (the core) can create simple and complex data types and resources. The second world (the non-core) can create extensions and profiles. Yet all are represented by StructureDefinitions, so there is an underlying unity. There are simply too many distinctions. If we allow users of FHIR to create complex data types and “non-core resources”, then what would happen? The confusion between “core” and “non-core” is a fear that would not materialize. But, many, many things would get much, much simpler. There would be just one way to create structure definitions, one way to create documentation, one way to validate resources, one way to parse resources, one way to search, one way to deal with modifying elements, one way to deal with conformance. All the extra machinery that is now needed to deal with profiles could be eliminated. Let me repeat: All the extra machinery that is now needed to deal with profiles could be eliminated. The overall complexity of FHIR for authors and users would be vastly reduced. That would be a huge win.
Let’s ask ourselves as a community, whether we think profiling is working? I can tell you from direct experience, it is not. Let me repeat: Profiling is not working. If we can only escape from cognitive lock-in, we can still make many important design improvements to FHIR.
I don’t see how you can do what you’re proposing while still having a single universal schema for FHIR – which is one of the core precepts of the spec and what guarantees base interoperability of all FHIR solutions. Receivers need to know exactly what elements they can expect to see in the instances. If we don’t differentiate core and extension elements, that is no longer possible.
I am not sure I see the problem. If a receiver decides they will accept any FHIR instance, then they will use an XSD with wildcards that enables them validate the core and also accept unknown elements and attributes (see http://www.xml.com/pub/a/2002/07/03/schema_design.html). If a receiver will only accept instances that conform to certain profiles, then at present they must use a different, invented system of profile validation that does not use accepted standards for XML content validation. Again, two different systems. But if extensions were handled in the way I suggest, then XSDs can also be used to validate profiled content. Since XSDs are automatically created for resources, there would be no extra tooling needed to create XSDs for profiles if profiles were modeled like core resources. Can you explain why we did not used wildcards to solve this problem, and created a second, parallel set of validation methods instead?
FHIR could use one XML namespace for all core elements with schema wildcards that accept elements from other namespaces. A single universal schema could still validate all FHIR resource instances while ignoring extensions and profiles could generate additional schemas to validate extensions.
Foreign namespaces are a mess for most programming languages. And they make the instances a mess too. Not to mention how ugly mapping them into the JSON would be.
Wildcards don’t work in an ordered schema with optional elements unless you force all extensions to the end, and even then, you eliminate any ability to have profile-specific schemas because there’d be no way of enforcing order amongst the extensions such that the extensions your profile cares about come first. Believe me, if there was a better way to make this work for schemas, we’d have done it long ago.
To rephrase what you are saying here, the wildcard approach won’t work because you can’t enforce the order of extensions. Is that right? If so, I’d ask if that is a large enough issue to take this approach off of the table.
It seems like a fatal flaw. I don’t see how we could work around it.
But the problem with claiming that extensions are first-class citizens and should be treated as such is that they manifestly are _not_ first-class citizens. From authoring, where building profiles that use extensions is an order of magnitude more difficult than authoring data elements in core resources, to consumption where accessing values of extensions is done in an entirely different manner, to documentation where the view of extended elements is totally different than primary elements. Multiple pilot teams in the CQF initiative have independently spent huge amounts of effort into trying to deal with extensions as first-class elements of the structures in which they appear. If extensions really are the only way to enable interoperability at the level suggested, then we need to take seriously the commitment to treat them as first-class citizens.
Reality is that extensions are second class citizens. They do involve a different approach, do consume more space and are slightly less efficient – on the wire. However, it’s entirely possible to generate a reference implementation that is profile-specific and causes the specific extensions that a given system cares about to appear as if they’re core. (And for that matter, cause core elements the system doesn’t care about to appear as though they were extensions.) We’ve spent a great deal of time exploring how to make extensions less painful/verbose in the instances. None of the proposals appearing here are things that haven’t been considered several times. However, they all have drawbacks that make them less appealing than the non-ideal approach we have now.
Pingback: Using Rhapsody as a FHIR® Façade (Part Two) | Lyniate