An off the shelf terminology solution can save developers a lot of time. However, depending on the feature set offered, you can lose a lot of the capabilities provided by SNOMED CT. Especially so with a FHIR server, whose standardised API supports text searching and subsumption, but little else in the way of queries leveraging the terminology concept model. Until ECL…
During last years SNOMED CT expo I tweeted that ECL is going to be a game changer for SNOMED CT. In my opinion, the two main implementation use cases for ECL are:
- Defining implicit value sets;
- A dedicated query language for secondary analysis of health records.
Ontoserver allows implementers to define implicit value sets for use at runtime, which is especially useful for constraining search fields. Of course, you can use any reference sets that might be available (depending on which edition you’re using) and most often these bundled refsets are probably adequate. But sometimes you might want a more precise constraint. Or you simply don’t want to be dependent on the refsets.
Let’s say we have two fields, “Presenting problem” and “Diagnosis”.
The most straightforward approach is to constrain both fields just to use concepts from the clinical finding hierarchy. But where’s the fun in that?
Let’s say we want the diagnosis field constrained to things somehow relevant to the presenting problem. For now, I’m going to say that a shared finding site will determine the “relevance”.
So let’s say Injury of forearm is entered as the presenting problem. We can determine all the specific body structure candidates that may have been injured using a query such as:
<< (125597008 | Injury of forearm | . 363698007 |Finding site|)
The diagnosis field can then be constrained to just the Clinical finding for these structures.
<< 404684003 | Clinical finding | : 363698007 |Finding site| = << (125597008 | Injury of forearm | . 363698007 |Finding site|)
Now the Diagnosis field is limited to around 500 concepts, compared to over 100 thousand with the entire Clinical finding hierarchy. Over half the results were already subtypes of Injury of forearm; so the nested expression might seem a bit overboard. However, what if the presenting problem was Pain in forearm. Constraining the diagnosis to just subtypes is only going to give us two concepts, neither of which is probably the desired diagnosis. However, using the ECL constraint above:
<< 404684003 | Clinical finding | : 363698007 |Finding site| = << (444899003| Pain in forearm | . 363698007 |Finding site|)
We get the same 500 or so concepts!
So what’s the benefit to end users?
If the diagnosis is “fracture of ulna”, a basic search for “frac of” is going to return over 1500 results, with the desired concept 54556006| Fracture of ulna | nowhere to be seen. But using our ECL, “fracture of ulna” appears in the top 4 results. (You can try the above search constraints out here).