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

Dear All,

One of my colleagues has pointed out this discussion, and I am following 
the discussion with great interest. Unfortunately it seems we missed the 
meeting, however I read the minutes and the related discussions.

In an FP7 Project named SALUS [1] , we are addressing very similar 
problems for enabling the re-use of EHRs for clinical research studies 
especially for post market safety studies. I was about to write a post 
presenting our approach and I saw that Kathrin already provided a link 
to us, thank you Kathrin!.

Our aim in SALUS project is to establish a semantic and functional 
interoperability environment so that hospitals and/or national health 
networks can continue to work with their existing models (which may be 
proprietary database model, OO models, or HL7 RIM based models or EN 
13606  RM based models) but still can provide de-identified EHRs for 
clinical research studies. For addressing the interoperability problems, 
we are following an ontological approach, we build semantic content 
models on top of the existing models (has been previously called data 
definition ontologies), and export the data itself as RDF. We are aware 
that these models themselves do not carry much semantics, but when 
interlinked with external domain ontologies and/or terminology systems 
like SNOMED CT, reasoning capabilities increase. In an initial attempt 
[2], we showed that it is possible to query the collected EHR data from 
disparate heterogeneous resources semantically by reasoning on top of 
the terminological resources. Such an environment also enables us to 
semantically mediate between different models like, HL7, CDISC ODM, and 
BRIDG. You can find a slide set introducing this initial prototype in [3].

As mentioned, this was an initial prototype, now together with AGFA 
Advanced Clinical Applications (ACA) Team we are working on the actual 
system that will be built upon EYE reasoning engine. More results to 
come ;).

Best regards,

Gokce B. Laleci , Ph.D.
Coordinator of SALUS Project

[1] http://www.salusproject.eu
[2] http://www.srdc.com.tr/publications/2011/SALUSSemanticFramework.pdf
[3]http://www.salusproject.eu/docs/SALUSInitialPrototype.pptx 
<http://www.salusproject.eu/docs/SALUSInitialPrototype.pptx>
From: Kathrin Dentler <k.dentler@vu.nl 
<mailto:k.dentler@vu.nl?Subject=Re%3A%20seeks%20input%20on%20Study%20Data%20Exchange%20Standards%20%20An%20alternative%20%20approach&In-Reply-To=%253C5033EB66.8020308%40vu.nl%253E&References=%253C5033EB66.8020308%40vu.nl%253E>>
Date: Tue, 21 Aug 2012 22:11:18 +0200
Message-ID: <5033EB66.8020308@vu.nl>
To: <public-semweb-lifesci@w3.org 
<mailto:public-semweb-lifesci@w3.org?Subject=Re%3A%20seeks%20input%20on%20Study%20Data%20Exchange%20Standards%20%20An%20alternative%20%20approach&In-Reply-To=%253C5033EB66.8020308%40vu.nl%253E&References=%253C5033EB66.8020308%40vu.nl%253E>>

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  <http://www.few.vu.nl/%7Ekdr250/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  <mailto:Peter.Hendler@kp.org?Subject=Re%3A%20seeks%20input%20on%20Study%20Data%20Exchange%20Standards%20%20An%20alternative%20%20approach&In-Reply-To=%253C5033EB66.8020308%40vu.nl%253E&References=%253C5033EB66.8020308%40vu.nl%253E>  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  <mailto:k.dentler@vu.nl?Subject=Re%3A%20seeks%20input%20on%20Study%20Data%20Exchange%20Standards%20%20An%20alternative%20%20approach&In-Reply-To=%253C5033EB66.8020308%40vu.nl%253E&References=%253C5033EB66.8020308%40vu.nl%253E>        |k.dentler@amc.uva.nl  <mailto:k.dentler@amc.uva.nl?Subject=Re%3A%20seeks%20input%20on%20Study%20Data%20Exchange%20Standards%20%20An%20alternative%20%20approach&In-Reply-To=%253C5033EB66.8020308%40vu.nl%253E&References=%253C5033EB66.8020308%40vu.nl%253E>


-- 
PS: Please note the change in the phone/fax numbers...

Gökçe Banu Laleci Ertürkmen, PhD.

Software Research, Development and Consultancy Ltd.
Phone: +90 (312) 2101763
Fax: +90 (312) 2101837
mail: gokce@srdc.com.tr