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: graha...@gmail.com [mailto:graha...@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 / grah...@healthintersections.com.au / +61 411 867 065
