W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2012

RE: seeks input on Study Data Exchange Standards An alternative approach

From: Sahay, Ratnesh <ratnesh.sahay@deri.org>
Date: Tue, 21 Aug 2012 17:36:49 +0100
Message-ID: <316ADBDBFE4F4D4AA4FEEF7496ECAEF908644B6B@EVS1.ac.nuigalway.ie>
To: "Mead, Charlie (NIH/NCI) [C]" <meadch@mail.nih.gov>, <Peter.Hendler@kp.org>, <mscottmarshall@gmail.com>
Cc: "Deus, Helena" <helena.deus@deri.org>, <kerstin.l.forsberg@gmail.com>, <LINMD.SIMON@mcrf.mfldclin.edu>, <public-semweb-lifesci@w3.org>, "Eric Prud'hommeaux" <eric@w3.org>
Hi Peter and All,

I think RIM (in XML format coreSchemas) can be represented in OWL (as an
Intensional view or OWA), however problem may arise due to local RMIMs.
In my work so far I see them as a problem of integrating global
(OWL-RIM) and local ontologies (OWL-RMIM). As Charlie said, main use of
the SW is the "common/stable wire format or framework".

Regards,
Ratnesh        


-----Original Message-----
From: Mead, Charlie (NIH/NCI) [C] [mailto:meadch@mail.nih.gov] 
Sent: 21 August 2012 17:07
To: Peter.Hendler@kp.org; mscottmarshall@gmail.com
Cc: Deus, Helena; kerstin.l.forsberg@gmail.com;
LINMD.SIMON@mcrf.mfldclin.edu; public-semweb-lifesci@w3.org; Sahay,
Ratnesh; Eric Prud'hommeaux
Subject: RE: seeks input on Study Data Exchange Standards An alternative
approach

Hi Peter --

I haven't read the notes of today's discussion, but since I was the one
that summarized the relationship between FHIR and OWL/RDF, I'd like to
try and clarify things.  As it sounds like you know FHIR pretty well,
let me start by saying that the original motivation behind seeing to
what extent SW technologies were relevant to FHIR resource definition
began with the observation that the initial proposed resource definition
strategy for resources in general -- but particularly for the "core"
resources that HL7 proposes defining and managing as balloted standards
-- requires RIM mappings of resource elements.  The question that was
put on the table several months ago was "Is there a computational
grammar that we could use to define these mappings so that we can
automatically process resource definitions to ensure that they are
non-intersecting in terms of their overall semantics?"  In a really
basic way, resources are identical to a SOA service inventory in which
the design pattern of "service normalization" -- non-overlapping
functional boundaries -- is critical for meaningful integration and
composition of services.  The same is true of FHIR resources except at a
purely static/informational rather than functional (as in the case of
services) level.  The notion of having a computational grammar that
defines a given resource's semantics also becomes important given that
FHIR resources are expected to be deployed via REST interfaces, so
trying to distinguish the boundary of one resource from another can't
simply be done based on the semantics of the contract per se.  As we dug
a bit deeply into this issue and figured out how to define these
mappings in OWL and make them available at run-time as RDF, it became
clear that being able to publish -- or at least have the publishable
form be accessible through a single transform -- resource definition
files in SW-friendly terms would be a very positive feature of FHIR (for
those who were able to consume and leverage those definitions).  I think
I understand and appreciate your Intensional/Extensional view and
certainly agree that particularly if you're working in the world of
SNOMED's expressivity, the approach makes sense.  However, the core
motivation behind the use of SW technologies to model FHIR resources is
simply to express the RIM mappings in a computational manner.  It is my
personal -- and as yet unproven - hypothesis that this will also lead to
a more stable wire format (an irrelevant issue with FHIR because one of
its base tenants is a (something which HL7 V3 messaging does not
provide), but will have relevance if/when SW approaches to other HL7
specifications are applied.

Would it be possible for you to share any of your work -- ppt, white
papers, etc. -- on your approach.  I think that the most positive aspect
of this activity is that we're having a fairly new set of discussions
within the HL7 community.

Thanks --

charlie
________________________________________
From: Peter.Hendler@kp.org [Peter.Hendler@kp.org]
Sent: Tuesday, August 21, 2012 11:47 AM
To: mscottmarshall@gmail.com
Cc: helena.deus@deri.org; kerstin.l.forsberg@gmail.com;
LINMD.SIMON@mcrf.mfldclin.edu; Mead, Charlie (NIH/NCI) [C];
public-semweb-lifesci@w3.org; ratnesh.sahay@deri.org
Subject: Re: seeks input on Study Data Exchange Standards  An
alternative approach

Sorry I didn't make the meeting but just looked at the minutes.

We (Kaiser) do use the Ontology features of SNOMED extensively and have
a different take on how it should be done.

Specifically we would not advocate for example, putting FHIR in RDF or
OWL.  What we've fount to be simple, useful, and very clean is to
recognize the two different kinds of logic involved.
And keep them isolated to different parts of the model.

Intensional  (like OWL, Open World, Reasoners and inferences)
Extensional (like HL7 openEHR all Object Oriented models, all databases)

The base of a clinical model is always extensional Object Oriented, but
there are nodes (attributes in the classes) that can take the data type
Coded Data CD)

For example the "code" of an Observation class takes a code.  You can
then designate that the code must be filled with only SNOMED or a SNOMED
extension term that follows the same ontological scheme as SNOMED.

If you do this, then you can safely use a reasoner on the "code" for any
Observation.

For example you can ask for codes that represent  "a disease with
finding site lung structure with morphology fibrosis and disease process
autoimmune".

Once you get this list of SNOMED codes then you iterate through them
using Extensional logic (SQL) and then you have your list of patients.

This is the clear separation of the intensional and extensional parts of
the model.  It is not the representation of the entire model in RDF or
OWL.

We are just finishing a second white paper on a suggestion of how to
extend this principle.  The basic idea is that clinical models, like HL7
are primarily at the base Extensional OO models and should not be
represented as OWL or RDF.

But where it makes sense, you pick particular nodes like the "code"
value of the Observation class, and then you add some meta information
that indicates the following.

Intensional  TRUE/ FALSE   (the default is FALSE, you can not use a
reasoner or SPARQL, this is an extensional OO node)
If TRUE then you supply the following additional meta tags.

logic  (for example OWL-DL, EL+ "same as SNOMED", RDF etc) ontology
(for example SNOMED-CT) post_coordinated_experessions_allowed
(TRUE/FALSE) hierarchies (for example Clinical Findings, Observables)

Now any user or receiver of a model can scan the nodes for these tags.
If they find any with intensional="true" then they can inspect the other
associated meta tags and know if they can use reasoners or SPARQL.

For the huge numbers of instances of these artifacts (messages or
documents) that would be in the millions, you don't want to use
reasoners but something faster like SQL. But for the nodes where it
makes sense you can use OWL or some other reasoner dependent intensional
logic.

In summary, it probably isn't a good idea to just move the model (for
example FHIR) completely over to RDF or OWL.  Rather keep it an OO model
but then use "Semantic Node Labeling" to designate particular nodes that
you are allowed or expected to take advantage of SPARQL or OWL-DL or
SNOMED





[cid:_2_1259C88C1259C4100056C87E88257A61]



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.
Received on Tuesday, 21 August 2012 16:37:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:01:13 GMT