Peter,
The experiments with the separation of the Ontologies SNOMED, FHIR (Profile)
and FHIR instance support the argument not to combine since you can make
references across Ontologies without putting them into one.
The OWL Import statement works very well so when you are selecting a SNOMED
concept to apply to a FHIR element instance you can see the SNOMED terms but
only the binding gets put in the FHIR instance ontology. When you receive the
FHIR instance file you can again import the SNOMED Ontology and it will resolve
closure on the IRI.
Here is the XML fragment:
<symptom>
……
<severity value="moderate"/>
</symptom>
Here is a Turtle fragment of a FHIR ReactionSeverity (code) which would be
attached to an AdverseReaction.Symptom with a “severity” Object Property
<http://record#01336> rdf:type fhir:ReactionSeverity ,
<http://snomed.info/id/6736007> ,
owl:NamedIndividual .
The instance of fhir:ReactionSeverity also has a type of SNOMED 6736007
In the SNOMED Ontology, 6736007 is defined:
<http://snomed.info/id/6736007> rdf:type owl:Class ;
rdfs:label "Moderate" ;
rdfs:subClassOf
<http://snomed.info/id/272141005> .
There are various permutations of this – you could also apply rdfs:label
“Moderate” to the ReactionSeverity instance itself.
Tony Mallia
From: [email protected] [mailto:[email protected]]
Sent: Saturday, December 20, 2014 8:25 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]
Subject: RE: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / W3C HCLS COI
call -- Review of FHIR ontology approaches (cont.)
I can think of two reasons why (except maybe in an academic paper or PHD
thesis) we would not put SNOMED and the information model in one RDF/OWL
Ontology.
One is the idea of keeping the information model, specifically FIHR, very
small. The goal is to keep it under 200 resources, closer to 100 even better.
SNOMED has over half a million classes. I have argued with others who want to
put it all in one Ontology that you are adding an ocean to a puddle. You don't
need or want all those millions of extra triples riding around in your FHIR.
The other idea has to do with the way people think. Less than one person in
2000 who does clinical models thinks "open world" and OWL. Domains and Ranges
would be thought of as constraints. Differently named resources would be
assumed to be different. There would be many unpredictable modeling and logic
errors if people who clearly think in "closed world" database and UML were to
start mixing OWL DL logic in the same model. Since the whole mixed ontology
would be OWL and not UML or FHIR, there would be many false and unintended
problems.
I believe we should not add the "open world" OWL / SNOMED models into the
closed world UML, DB, FHIR models for these two different reasons. OK to put
FHIR into RDF or even OWL (after you do all the extra work of making all the
disjoint assertions) but keep the connection with the vocabulary the way it is
now, via bindings to coded concepts.
Thanks
[cid:[email protected]]
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you
are prohibited from sharing, copying, or otherwise using or disclosing its
contents. If you have received this e-mail in error, please notify the sender
immediately by reply e-mail and permanently delete this e-mail and any
attachments without reading, forwarding or saving them. Thank you.
From: "Vipul Kashyap"
<[email protected]<mailto:[email protected]>>
To: Peter Hendler/CA/KAIPERM@KAIPERM
Cc: <[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>, "'Vipul
Kashyap'" <[email protected]<mailto:[email protected]>>
Date: 12/20/2014 02:06 PM
Subject: RE: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / W3C
HCLS COI call -- Review of FHIR ontology approaches (cont.)
________________________________
Hi Peter,
Thanks for your email below – If I may summarize:
Clinical Models capture the “who, when, where, why”
Snomed/Medical Terminogies – capture the “what”
Agree with your suggestion that Snomed should not be used for the former –
The underlying motivation for my suggestion – as has been suggested by other
medical informatics researchers is to
“combine” both information models and terminologies is a common
“model/ontology” and leverage the semantic expressiveness of OWL
for the purpose.
I think that primary reason divergence appears to be whether Snomed is viewed
as a set of codes which can be used as “tags” or “values”
or Snomed is a full fledged ontology with classes, properties, relationships
and instances of those classes. Based on the perspective taken,
Of course there are pros and cons of these approaches and can lead us to
different choices of how we model clinical information and knowledge.
---Vipul
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Saturday, December 13, 2014 5:31 PM
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: RE: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / W3C HCLS COI
call -- Review of FHIR ontology approaches (cont.)
SNOMED can not and should not map to FHIR resources. This is the difference
between clinical models that capture who, when where and why with the medical
terminologies like SNOMED that are only the what.
In HL7 V3, the information model has the entities in roles that participate in
acts. That is perfectly what should be in a clinical model. Then the "what"
part of the clinical model may go only as far as say it is an "observation".
SNOMED does not, and should not ever deal with who when where or why. It only
deals with what.
The medical terminology such as SNOMED supplies the "value" of the Observation.
Which might be "diabetes".
There is no one to one between a FHIR observation and a SNOMED concept. They
don't overlap. The FHIR, just like the HL7 V3 tells you who when where why but
the what stops at "observation". The medical terminology which is linked to
that observation resource then can be SNOMED diabetes. You would not make a
FHIR resource for Diabetes. You use the FHIR observation and then code it with
a SNOMED value.
The FHIR Observation does not get subclassed to Diabetes. It is only ever
Observaiton. The specific "value" of the Observation is the medical
terminology part supplied for example by SNOMED.
So I would never see it being appropriate to create any SNOMED terms to
represent FHIR resources.
Thanks
[cid:[email protected]]
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you
are prohibited from sharing, copying, or otherwise using or disclosing its
contents. If you have received this e-mail in error, please notify the sender
immediately by reply e-mail and permanently delete this e-mail and any
attachments without reading, forwarding or saving them. Thank you.
From: "Vipul Kashyap"
<[email protected]<mailto:[email protected]>>
To: "'Grahame Grieve'"
<[email protected]<mailto:[email protected]>>,
"'Lloyd McKenzie'" <[email protected]<mailto:[email protected]>>
Cc: "'David Booth'" <[email protected]<mailto:[email protected]>>, "'w3c
semweb HCLS'"
<[email protected]<mailto:[email protected]>>, "'HL7
ITS'" <[email protected]<mailto:[email protected]>>
Date: 12/13/2014 10:41 AM
Subject: RE: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / W3C
HCLS COI call -- Review of FHIR ontology approaches (cont.)
________________________________
If every FHIR element was mapped to a snomed term, then you could represent
that in RDF no problems.
VK> Would propose that FHIR could be the hub – and we could leverage RDF/OWL
constructs to map FHIR elements to Snomed, MedDRA, ICD11, RxNorm, etc.?
However the problem with this is that we already have a slot for mapping an
element to it's snomed code, but there are hardly any snomed codes that are
appropriate.
VK> Not sure if I understand this – If no Snomed codes are appropriate for a
particular FHIR element – then we can request the IHTSDO folks to create a new
one, no?
Also, if the RDF/OWL metamodel gives us the language to express more
general relationships – we may not want to use a specific slot for a Snomed
code? Or we can perhaps
Create an axiom linking the values of the snomed code based on the
sameAs/subClassOf relationship for a particular terminology, e.g., Snomed?
Thanks,
---Vipul
