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

Hi Vipul,

First, we would never define a specialized resource.  As much as possible,
all resources are orthogonal and never exist in a hierarchical
relationship.  Condition is a structure that includes a code (saying what
kind of condition), time of onset, who diagosed it, the patient who has the
condition, etc.  That's not a notion SNOMED has any concept of.  The only
place SNOMED comes into play is with Condition.code, not with the Condition
resource.

--------------------------------------
Lloyd McKenzie

+1-780-993-9501



Note: Unless explicitly stated otherwise, the opinions and positions
expressed in this e-mail do not necessarily reflect those of my clients nor
those of the organizations with whom I hold governance positions.

On Sat, Dec 13, 2014 at 1:14 PM, Vipul Kashyap <kashyap.vipul@gmail.com>
wrote:
>
> 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
>