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

Actually design-time and run-time is even better than what I said.  Let's 
use these words.


The first "white paper" describing the problem is here.
http://www.ringholm.com/docs/05000_Clinical_Models_and_SNOMED.htm

The second one that describes the solution called "Semantic Node Labeling" 
is being read by others for corrections and suggestions now. It was just 
written a few days ago.  I'll send it out, and ask Rene Spronk to put it 
on Ringholm when I get the final version.  It is basically just what I 
wrote below.  You assume the entire run-time model is basic OO logic.  But 
you may designate certain chosen nodes (in the example the "code" of the 
Observation) with the ability to use some intensional logic.  It could be 
OWL, SPARQL or SNOMED or even others.  In the near future, the biggest 
value would probably be to designate certain run-time nodes as safe to use 
SNOMED reasoners on. There is a huge value in adding the ability to do 
subsumption searches on SNOMED to clinical models and artifacts.

This proposal is just a standard way of labeling which nodes you can do 
that with.  And leaving the option to do much more if you want.







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.






"Mead, Charlie (NIH/NCI) [C]" <meadch@mail.nih.gov> 
08/21/2012 09:53 AM

To
Peter Hendler/CA/KAIPERM@KAIPERM
cc
"eric@w3.org" <eric@w3.org>, "helena.deus@deri.org" 
<helena.deus@deri.org>, "kerstin.l.forsberg@gmail.com" 
<kerstin.l.forsberg@gmail.com>, "LINMD.SIMON@mcrf.mfldclin.edu" 
<LINMD.SIMON@mcrf.mfldclin.edu>, "mscottmarshall@gmail.com" 
<mscottmarshall@gmail.com>, "public-semweb-lifesci@w3.org" 
<public-semweb-lifesci@w3.org>, "ratnesh.sahay@deri.org" 
<ratnesh.sahay@deri.org>
Subject
RE: seeks input on Study Data Exchange Standards  An alternative approach






Hi Peter --

Agree --and I think I understand...:-).

Might we refer to them as "design-time" and "run-time"?  Or does that 
gloss over some of the important distinctions you are trying to point out?

Any materials on this topic you could distribute?

Thanks --

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

We are in fact talking about two different things.
If you are talking about how to more easily create new FHIR resources, and 
to assure their correct mapping to the RIM then my points are not 
relevant.


It is my view that clinical models can gain a lot of functionality by the 
addition of semantic web (RDF OWL and I even include SNOMED which is like 
a sub set of OWL).

For the actual use of these clinical models, we (Kaiser) have found it 
extremely useful to consider them as a clean separated model that has the 
largest part based on databases or OO (closed world standard stuff) but 
specifically designate some nodes, like the ones that would use SNOMED to 
represent diagnosis, findings, and procedures, to be considered as 
intensional logic that we use reasoners on.

For the purpose of assuring that the FHIR resources are correct and mapped 
correctly to the RIM, it may be good to move the entire model to RDF or 
OWL.  I haven't thought much about that task.

I was discussing the final use of such models.  In a FHIR resource for a 
diagnosis representation for example, there will be one node where you are 
allowed to use SNOMED to represent the diagnosis.  It is that one node 
that I would have labeled for the receivers (users) of that instance 
telling them they are free to use a SNOMED reasoner on that one part of 
the FHIR resource.

In future discussions we must be able to distinguish between which of 
these two problems we are discussing.

1  The problem you state which is related to the correct creation of 
models like FHIR
2  The problem I'm discussing which relates to the safe actual use of 
these models by clinical systems.

We could maybe call them the "authoring" or "use" problems respectively.









[cid:_2_115EDE7C115ED9A40059F8A388257A61]



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.





"Mead, Charlie (NIH/NCI) [C]" <meadch@mail.nih.gov>

08/21/2012 09:07 AM


To
        Peter Hendler/CA/KAIPERM@KAIPERM, "mscottmarshall@gmail.com" 
<mscottmarshall@gmail.com>
cc
        "helena.deus@deri.org" <helena.deus@deri.org>, 
"kerstin.l.forsberg@gmail.com" <kerstin.l.forsberg@gmail.com>, 
"LINMD.SIMON@mcrf.mfldclin.edu" <LINMD.SIMON@mcrf.mfldclin.edu>, 
"public-semweb-lifesci@w3.org" <public-semweb-lifesci@w3.org>, 
"ratnesh.sahay@deri.org" <ratnesh.sahay@deri.org>, "Eric Prud'hommeaux" 
<eric@w3.org>
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 stable wire format (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.