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

We probably agree.

I mostly object to models where I see words like "Systolic Blood Pressure" 
in-lined in the OO model.  I object because if that model intends to use 
SNOMED and map to the same thing, then the "thing" <systolic blood 
pressure> is defined twice in the model, in the in-lined OO part and also 
in the SNOMED part.

What you are doing is rather advanced.  What I wanted to do mainly, is to 
stop the mixing of the "what" where you have Systolic Blood Pressure in 
both the OO part of the model as words "Systolic Blood Pressure" and also 
in SNOMED.


If you are using OWL with full knowledge and you are doing some advanced 
things with the "who what where why and how" then there is probably value 
in that.  But it's more advanced and I just wanted to stop the haphazard 
mixing of "what" in the models.

For the more mundane uses, I think we really need to "draw the line" in 
any given model where it's extensional OO and where it's intensional OWL 
or ontology.

If people agreed on that first, then I'd have no problem saying, now we 
are going to open it up to more advanced uses of ontology like the ones 
you mention.

But not right away, as that might confuse people on my first simple 
request on where to draw the "first line" having to do with the "what" of 
the model.



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.






Kathrin Dentler <k.dentler@vu.nl> 
08/21/2012 01:11 PM

To
<public-semweb-lifesci@w3.org>
cc

Subject
Re: seeks input on Study Data Exchange Standards  An alternative  approach






Hi Peter,

Just my two cents: Having read your white paper, I find your separation 
into the "What", i.e. the terminological model (intensional), and the 
"When, Who, Where, Why", i.e. the context/information model (extensional), 
very useful and intuitive.

In your paper, I only found two reasons against expressing both parts of 
the model in RDF or OWL, one being performance and the other limited 
knowledge of clinical modelers. I agree that speed is essential for 
real-time use. Regarding the limited knowledge of clinical modelers, I 
would say that understanding extensional logic is just as hard: As an EHR 
can only express a fraction of reality, its content should not necessarily 
always be interpreted in a closed world (e.g. a patient could have a 
certain allergy even though it has not been recorded). So open and closed 
world reasoning will have to be combined, and it is always important to be 
aware of the consequences. Thus, I think that your "Semantic Node 
Labeling" idea is excellent.

So I don't see any conceptual problem of representing the "When, Who, 
Where, Why" in OWL and making use of reasoners to harvest implicit 
knowledge. In contrary, I just worked with an OWL representation of 
openEHR archetypes [1], and I see many valuable applications for RDF or 
OWL representations of information models. Possibilities are to mediate 
between several standards as in the Salus project [2] or to "leverage 
publicly available data from the Linked Open Drug Data cloud to federated 
querying for type 2 diabetes patients" [3] (Mayo Clinic). They exported 
data of 6.7 million patients to RDF and stored it in Virtuoso. I also find 
the reasoning it enables interesting: integrating rules [4], hierarchy / 
subclass reasoning (i.e. when querying for a "problem" archetype, also 
results from its sub-archetype "diagnosis" should be retrieved). 
Furthermore, validating archetypes themselves as in [5] or validating 
patient data by turning the OWL representation into integrity constraints 
are interesting in my opinion. It could also be worthwhile to gain insight 
into the implicit knowledge contained in patient data, to infer 
relationships between comparable models and to reason on the boundary 
between information models and terminologies. So - in my opinion - much 
work to do!

Best,
Kathrin

[1] http://www.few.vu.nl/~kdr250/prohealth12kr4hc_archetypes_owl.pdf
[2] http://www.salusproject.eu/
[3] http://dl.acm.org/citation.cfm?id=2110415
[4] http://www.ncbi.nlm.nih.gov/pubmed/21118725
[5] http://ceur-ws.org/Vol-674/Paper150.pdf



Op 21-08-12 17:47, Peter.Hendler@kp.org schreef: 
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 









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.




-- 
Kathrin Dentler

AI Department         |   Department of Medical Informatics
Faculty of Sciences   |   Academic Medical Center
Vrije Universiteit    |   Universiteit van Amsterdam
k.dentler@vu.nl       |   k.dentler@amc.uva.nl