RE: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / W3C HCLS COI call -- Review of FHIR ontology approaches (cont.)

I think using a concrete example helps. One thing which is becoming clear it that we are perhaps  modeling Snomed in different ways.

 

 

 

ok, well, how it works is that FHIR has a resource called "condition", which is a record keeping construct people use to exchange information about problems, diagnoses, signs and symptoms. Note that Snomed differentiates between those things carefully, which is it's point, but in practice, people don't differentiate the records so well

 

VK> This might depend on the use case you are looking at – For e.g., this differentiation could be very useful in the context of CDS, Clinical Documentation, Quality Metrics, et.c

 

You could use this resource to represent information about a patient's diabetes - in this case, the condition.code could be the snomed code for diabetes. 

 

VK> This is another place we differ – Would represent diabetes as a class with the patient’s diabetes as an instance of this class. We could relate the class diabetes with the FHIR Resource Condition

(which I know realize is a much broader concept than “condition”) by modeling appropriate relationships in OWL

 

You could then write profiles that describe two different things:

- how do you say that the patient has diabetes?

- if the patient has diabetes, what things should you say about them? 

 

VK> These appear to be necessary and sufficient conditions which could be modeled as OWL axioms (one of these may not be possible expressivity wise) and one could run the OWL inference

to figure out if someone has diabetes based on the information available to them – This is a classic CDS use case!

 

well, ok, but note that we usually use 'elements'  in a different sense in FHIR, in that Condition is a resource that has elements such as:

 

VK> Ok – “Elements” are used as the properties of a resource?

 

 ... category (E.g. complaint | symptom | finding | diagnosis)

... status          M            (e.g. provisional | working | confirmed | refuted)

... certainty    (Degree of confidence)

... severity                (Subjective severity of condition)

 

well, I don't think we can - as you can see, my description of how things work doesn't involve subclasses, and, in fact, we don't have sub-classing in FHIR very much at all 

 

VK> This is  a design choice we have to make as we come up with an RDF/OWL representation – of course this depends on the use case –CDS vs basic data interoperability.

Whereas – FHIR may not have subclasses – would it make sense to come up with a richer semantic representation – and which could help us derive more value?

 

 

so where's the value snomed brings here? I don't think it does, for non-snomed users. For snomed users, there's value in mapping the information constructs to qualifier attributes, though in practice no one is capable of decomposing a snomed term / expression  into it's parts in a resource, or re-composing them. It's theoretically possible, but not practical, so far as I am aware. 

 

VK> So – I am more focusing on the value of the RDF/OWL semantic representations as opposed to Snomed per se (of course there is an overlap). BTW, there are OWL representations of Snomed available from various folks with various

Post-coordinated expressions represented in OWL.

 

Note that this means I disagree with Peter on this - in general, information models and snomed have different purposes, but there is a grey area where overlaps form, which is why I think that there is value is mapping some things.

 

VK> I don’t disagree with Peter either – They do have different purposes but getting them into a common metamodel and representing them in a richer semantic representation can enable new value and functionality – which may not be achievable

if we keep them separate.

 

There's another kind of mapping which we haven't considered, but which actually comes up fairly quickly in implementation space: mapping between a knowledge statement construct and a information usage model. An easy one to get your head around is a set of observations - you're going to have a LOINC code, and for each LOINC code, units, ranges, interpretation codes. Some of those things you can inherit by referencing LOINC. A something might apply to getting knowledge about what's possible in conditions from examining Snomed relationships - in fact, that's what Keith Campbell wants to do in terms of the relationship between FHIR and SOLOR. Is anyone from Keith's team involved in this work?

 

VK> Can you give me a concrete use case and example regarding the above – I am not familiar with SOLOR and slowly becoming familiar with FHIR.

 

Thanks,

 

---Vipul

 

Grahame