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

Hi Peter,

Yes, we'll definitely want to model the FHIR instance expression in such a
way that it closes the world (or at least allow for a closed world form) in
a similar manner to what I did for v3.

--------------------------------------
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 20, 2014 at 6:20 PM, <Peter.Hendler@kp.org> wrote:
>
> 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
>
>
>
>
>
>
> *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" <kashyap.vipul@gmail.com>
> To:        Peter Hendler/CA/KAIPERM@KAIPERM
> Cc:        <david@dbooth.org>, <grahame@healthintersections.com.au>, <
> its@lists.hl7.org>, <lloyd@lmckenzie.com>, <public-semweb-lifesci@w3.org>,
> "'Vipul Kashyap'" <kashyap.vipul@gmail.com>
> 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:* Peter.Hendler@kp.org [mailto:Peter.Hendler@kp.org
> <Peter.Hendler@kp.org>]
> * Sent:* Saturday, December 13, 2014 5:31 PM
> * To:* kashyap.vipul@gmail.com
> * Cc:* david@dbooth.org; grahame@healthintersections.com.au;
> its@lists.hl7.org; lloyd@lmckenzie.com; public-semweb-lifesci@w3.org
> * 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
>
>
>
>
>
>
>
> * 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" <*kashyap.vipul@gmail.com*
> <kashyap.vipul@gmail.com>>
> To:        "'Grahame Grieve'" <*grahame@healthintersections.com.au*
> <grahame@healthintersections.com.au>>, "'Lloyd McKenzie'" <
> *lloyd@lmckenzie.com* <lloyd@lmckenzie.com>>
> Cc:        "'David Booth'" <*david@dbooth.org* <david@dbooth.org>>, "'w3c
> semweb HCLS'" <*public-semweb-lifesci@w3.org*
> <public-semweb-lifesci@w3.org>>, "'HL7 ITS'" <*its@lists.hl7.org*
> <its@lists.hl7.org>>
> 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
>
>