This week I was in Washington DC for the inaugural FHIR terminology services connectathon. This was the first of its kind: a connectathon focused on the terminology services portion of the FHIR specification.
The following organizations were represented:
The focus of the connectathon was on the two simplest operations in the terminology services API:
In order to use or implement the terminology services API, the first thing to do is to understand value set expansions. Logically, a value set has 3 aspects:
The key to understanding this is that content logical definition can be both complicated and/or not fully specified. The most common example is that the logical definition doesn’t fix the version of the code system, e.g. “take all procedures from SNOMED CT” – but which version of SNOMED CT? That’s delegated to the run-time environment.
This means that the process of converting from the “content logical definition” to the expansion is complicated, and is basically a job for terminology expert systems.
The FHIR terminology service API includes a very simple operation to fetch the expansion for any given value set:
This says that for the server’s value set [id], return the list of codes in the value set. It’s up to the server how it decides to generate the expansion – maybe it generates it each time based on the definition, or maybe it caches it internally and simply sends it.
Value set validation is easier – the client simply gives the server a system and a code and asks whether it’s valid in a particular value set:
The server returns a true/false – is the code valid, and in the specified valueset? – along with human readable description of any issues detected.
Note that for these operations, there’s a number of syntactical variations to reflect the various conditions under which the operation is executed.
A key part of the first day of the connectathon was a mini-tutorial that was a detailed review of the value set resource, the expansion operation, and the way that the entire terminology service space works in the FHIR eco-system.
This connectathon introduced a new feature that we intend to introduce in future connectathons: a test script (view the source). The test script contains:
Note: The test script is actually written as if it’s a FHIR resource, though we haven’t actually defined a resource for this yet.
For the terminology services connectathon, the test script
For this connectathon, the terminology script could be used in the several different ways – as simply a detailed technical specification of the kind of things that were being tested by the connectathon, or as an executional test sequence using the FHIR Sprinkler tool. For this connectathon, several parties used the script, but needed to vary its content to account for differences in server functionality, and also the inner details of the various SNOMED and other code systems in use.
The test script wasn’t the only way to test – a number of participants used either their browser or thePOSTman browser plug-in to test the functionality of the various servers represented at the connectathon.
Since this was the first connectathon, we didn’t have any particular expectations in terms of formal testing outcomes. So it was a pleasant surprise that by the second day, a number of participants were using the test script to automate testing their server for technical conformance to the specification.
In particular, the VSAC prototype FHIR server was passing all 55 tests in the test script – congratulations! (This doesn’t mean that VSAC is going to put up a FHIR server to access all the value sets as of tomorrow, but clearly that’s the end game. Of course, it will take considerable time for them to get to that point and depends on approvals, budgets etc).
That’s our desired end-point, though – that all the primary sources of value sets will make them available through a standard API, one that’s used by all the operational terminology services as well. Really, this connectathon was initiated by the openHIE community, who are examining the FHIR terminology services API to see whether it’s suitable for adoption as their base terminology API for exactly this use. For the FHIR project, it’s our pleasure to work with openHIE, because there’s strong alignment between our two communities.
This connectathon also produced the normal outcomes that we’ve come to expect:
I’m really pleased with these outcomes – I’ve come to believe that the terminology space will be a significant early win for the FHIR community. With that in mind, the attendees felt that for future connectathons, it would be good to make them part of the overall FHIR connectathons held the weekend before the HL7 working group meeting. This would have several advantages, the most important of which is that we can start testing out practical ways to further the integration of terminology services into routine use of FHIR for clinical purposes. OpenHIE may also consider holding their own connectathon at some time.
At the moment, the only server that was tested at the connectathon that is publicly available is mine. It’s athttp://fhir-dev.healthintersections.com.au/open, and it passes all the tests in the test script. Hopefully we’ll be able to add a couple more servers that will be available in an ongoing fashion.
p.s. I’m intending to make a follow up post soon about how simple the terminology service is to use in practice, but we’re pretty busy preparing the upcoming FHIR DSTU ballot.