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

Hi Vipul;

Just my two cents here:

|"Let’s say we define a new Resource called Diabetes (since FHIR is 
extensible) which is a subclass of Condition"
 
I think the example of diabetes taken will not help. The "Diabetes" is 
seen as instance not as a "extension". 

Coming back to SNOMED mapping, this is feasible (and even recommended if 
we need to work towards interoperability). 
How to achieve that can be discussed.
I can imagine one use case of condition mapping as follow---this is an 
instance based example, not an official RDF expression, so do not think 
it's an agreed approach. 
Let's formalize the FHIR condition as RDF graph:

---------------
[
a fhir:Condition;
fhir:extension [a fhir:Disease]; #do not take this approach as 
final/official, this is still under discussions within RDF HL7 group

#eg:
a <http://purl.bioontology.org/ontology/SNOMEDCT/64572001>;

#we can here even addd more granular codes.

fhir:identifier "External Ids for this condition";
fhir:subject <Resource(Patient) Who has the condition URI>;
fhir:encounter <Resource(Encounter) Encounter when condition first 
asserted  URI>.
fhir:asserter <Resource(Practitioner|Patient) Person who asserts this 
condition  URI>
fhir:dateAsserted "1967-01-25+01:00Z01:00"^^xsd:dateTime;
fhir:code <f.eg. ICD9 code URI>; #CodeableConcept Identification. Do not 
take this as final approach, this is still under discussions within RDF 
HL7 group 
fhir:category " CodeableConcept E.g. complaint | symptom | finding | 
diagnosis  ---URI";
fhir:status " provisional | working | confirmed | refuted ";
fhir:certainty "CodeableConcept Degree of confidence"
fhir:severity "CodeableConcept Subjective severity of condition "
fhir:onset "date|Age|boolean If/when in resolution/remission "; #Follow 
datatypes handling approach in FHIR
fhir:abatement "date|Age|boolean If/when in resolution/remission "; 
#Follow datatypes handling approach in FHIR
fhir:stage "Stage/grade, usually assessed formally -->
fhir:summary "CodeableConcept Simple summary (disease specific)" 
fhir:notes "Additional information about the Condition"^^xsd:string.
].
---------------

Kind Regards,

Marc Twagirumukiza | Agfa HealthCare
Senior Clinical Researcher | HE/Advanced Clinical Applications Research
T  +32 3444 8188 | M  +32 499 713 300

http://www.agfahealthcare.com

http://blog.agfahealthcare.com

Click on link to read important disclaimer: 
http://www.agfahealthcare.com/maildisclaimer 



From:   "Vipul Kashyap" <kashyap.vipul@gmail.com>
To:     "'Grahame Grieve'" <grahame@healthintersections.com.au>
Cc:     "'Lloyd McKenzie'" <lloyd@lmckenzie.com>, "'David Booth'" 
<david@dbooth.org>, "'w3c semweb HCLS'" <public-semweb-lifesci@w3.org>, 
"'HL7 ITS'" <its@lists.hl7.org>
Date:   13/12/2014 21:16
Subject:        RE: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / 
W3C HCLS COI call -- Review of FHIR ontology approaches (cont.)



I think it would benefit for this discussion to be based on a concrete 
example – to make sure we are on the same page:
Advance apologies for inappropriate use of terminology (as I am new to 
FHIR)
 
FHIR has a Resource called Condition.
Let’s say we define a new Resource called Diabetes (since FHIR is 
extensible) which is a subclass of Condition
 
Condition and Diabetes is what I refer to as “Elements” of FHIR
 
Now we can leverage the sameAs/subClassOf constructs to map FHIR Resource 
Diabetes to the Snomed Concept Diabetes.
 
Leveraging RDF/OWL constructs enables us to map FHIR “elements” to any 
purpose specific ontologies – e.g., Snomed (for CDS), MedDRA (for CTs), 
ICD10/ICD11 (for healthcare claims processing and reimbursement)
Furthermore, this approach gives us the flexibility to map to OWL 
expressions which can be used to model Snomed postco-ordinations as well.
 
For now – just want to make sure we are on the same page – we can figure 
out whether this approach has value, is feasible etc. later.
 
---Vipul
 
 
From: grahameg@gmail.com [mailto:grahameg@gmail.com] On Behalf Of Grahame 
Grieve
Sent: Saturday, December 13, 2014 2:16 PM
To: Vipul Kashyap
Cc: Lloyd McKenzie; David Booth; w3c semweb HCLS; HL7 ITS
Subject: Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / W3C 
HCLS COI call -- Review of FHIR ontology approaches (cont.)
 
 
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.?
What does it mean to "map elements to FHIR"? It's really clear for FHIR 
defined concept codes, though generally we would only define these if they 
aren't in the space of snomed. But generally, snomed doesn't define 
concepts for 'an element for x'. Instead, it defines the concept of 'x' - 
these are not the same thing. They sound like it, but once you consider 
the relationships, it turns out to be a difference you can't ignore. Then, 
snomed defines codes for situations that are also orthogonal to resources 
that let you represent situations.
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?
Well, yes, they could, but how is that different to us just defining them 
by robot in an extension? The value to this is in the relationships, and 
this would require a whole new perspective in snomed to make this useful. 
Right now, ihtsdo are looking at the mappings . I expect them to come to 
the same conclusion as me, but I'm waiting to see
 
Grahame


-- 
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au 
/ +61 411 867 065