Thoughts and comments on the HL7 FHIR standard, from a FHIR Evangelist
March 10, 2017 2 Comments
So I had a question from someone who was wanting to develop some profiles using clinFHIR and not sure of the best way to approach this. I’ll write in more detail later on, but as there has been a substantial change in process and User Interface from the previous version, I thought I’d just do a quick post about how the new process is intended to work.
January 10, 2017 3 Comments
One of the issues we come across quite a lot at Orion Health is where we are creating a read FHIR interface to an existing data service with elements in the FHIR resource that are coded and have a ‘required’ binding to a ValueSet (which means that you must only use one of the values in the ValueSet) – and the data we are mapping from has a different value. AllergyIntolerance is a particular culprit in this regard as it has a number of required bindings, but it has come up most recently in MedicationStatement.status where we have values that are different to the ones in STU2 – the FHIR version we are using.
May 30, 2016 2 Comments
I’ve been working on the profiling abilities of clinFHIR recently. As I’ve said before, although there is the official tool for creating profiles – Forge – I think there is a place for a simple profiling tool primarily aimed at clinicians, with the goal to help them understand how FHIR profiling works.
One of the big things that keeps coming up is ValueSets – and how to create them.
As a short recap – recall that the purpose of profiling is to take the core resources and make them more suitable for real-world Use Cases by adding new elements (extensions) and removing the ones that are not needed. As part of this process you often want to specify a particular set of values for coded elements that is different to the one in the spec and the ValueSet is the mechanism that you use to specify those. The problem is that there isn’t currently any widely available tooling to create ValueSets (outside of the tooling used to build the specification itself) – especially ones for clinicians to use, so over the weekend I decided to write a simple ValueSet Editor.
November 16, 2015 Leave a comment
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).
November 4, 2015 2 Comments
We’ve talked on quite a few occasions about profiling in FHIR, and creating extensions when we need to represent elements that aren’t in the core resources. At Orion Health, we’re putting a fair amount of effort into FHIR (as are all forward looking vendors in this space) so we needed a way to more easily manage the extensions we need to create. Forge is an option – but our extensions are quite simple. clinFHIR has always been able to create extensions, but the process is klunky and we needed a better way. So I’ve added an ‘Extension Editor’ to make this a bit easier.
September 10, 2015 3 Comments
So I was talking with one of my colleagues at Orion Health today – a clinician who has just joined us and wanted to understand what FHIR was – to a reasonable degree of detail. I thought I’d summarize our conversation here as it’s useful to record what a clinician found interesting, and wanted to know about.
September 7, 2015 19 Comments
As part of the preparation for the connectathon and clinicians challenge at the WGM in October, I decided to update clinFHIR so that it can access different servers for data and ‘conformance’ resources like ValueSet and StructureDefinition. Currently clinFHIR assumes that everything it needs to operate is supplied by a single server – from looking up profiles (StructureDefinition resources), finding and expanding ValueSets through to actually storing and retrieving the resources created for a patient. This is fine when the server is Grahames, as he aims to implement the entire specification (and generally succeeds!) but it’s a big ask for any server to do this.
June 23, 2015 9 Comments
I must admit I haven’t paid as much attention to Terminology as I should.
I do appreciate how important it is – most (if not all) resources in FHIR have multiple coded elements that refer to a terminology of some sort, and a common understanding of concepts is one of the key parts of interoperability, but until Grahame asked me to talk to this subject at the recent Brisbane Seminar & Connectathon, I’d regarded coded items as just another datatype.
But DSTU-2 brings a whole new set of possibilities to the picture, so let’s look at how that helps us.
January 4, 2015 Leave a comment
I’ve posted an update to the Extension Viewer that I’ve been working on over the holidays.
January 1, 2015 7 Comments
Actually, on reviewing the previous post about profiling in DSTU-2, I realize that there is a simpler way of applying extensions to a profile (in addition to the Conformance package). If you look at the Profile resource, it contains 2 main parts:
(To be precise, there are 2 collections of elements in the profile:
the reason for the two is to support tooling – we’ll focus on the snapshot for now).
Recent Comments