Clinical Modeling - A critical analysis

Koray Atalag k.atalag at auckland.ac.nz
Sun Mar 1 15:31:07 EST 2015


I’m completely disappointed, but not surprised, that this paper was accepted as a scientific paper in the first place with such bold arguments.
We have all seen him advocating on openEHR during quite a few EU FP6 project proposals – I certainly attended a few workshops together. At some point he must have been alienated or something?? At any rate I think it is our responsibility to publish a formal rebuttal and challenge this paper. That’s what science is about, isn’t it?

Cheers,

-koray

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of "Gerard Freriks (privé)"
Sent: Sunday, 22 February 2015 3:15 a.m.
To: For openEHR clinical discussions
Subject: Re: Clinical Modeling - A critical analysis


On 20 feb. 2015, at 15:50, Ian McNicoll <ian at freshehr.com<mailto:ian at freshehr.com>> wrote:

Hi Birger,

I did read this paper some months ago and to be honest but as a
non-computer scientist found it quite difficult to understand. It
seems to be based on a comparison of a theoretical architectural
approach based on high-level ontologies but also contains some
puzzling assertions

Ian, I noticed before, in other publications by Bernt Blobel, serious misconceptions about his understanding of Archetypes.



e.g. "An archetype is a user-defined table in relational database
models, so intentionally or not-intentionally notifying the ICT-focus
of the Archetype approach." - which is almost universally incorrect
and may have misled the entire assessment.

An archetype is much more than a view on a data base.
- an expression of data needs of a system
- the Information Viewpoint in an Interface between EHR-system Services (of which the database is one)
- a set of constraints on a Reference Model

I agree that without the proper definition of the concept Archetypes the assessment is void.



and

"However, the archetype schemas used, refer to existing ontologies
like SNOMED CT [32] just as terminology. We should remember that
SNOMED CT itself has developed from a terminology and is still in
process of growing into a logically and ontologically coherent
ontology. The problem still is a strong conceptualist legacy. So, it
might be better to derive schemas from realism-based ontologies, e.g.,
from members or candidates of the OBO Foundry [13], most of which are
based on BFO.”

What the hell are Archetype Schema’s. Schema’s of Archetypes? I fear they are not.

What the authors write is questionable.
EHR’s, Patient records are NEVER about the reality in the Patient System.
They are about what one author wishes to document.
It is what the author is thinking and documents.

Archetypes and the RM they constrain are about documenting and archiving statements.

I reserve reality for Ontologies to take care of.
Ontologies with an Open World Assumption, using expressions that define logical relationships.
Ontological systems because they are based on logical expressions can make inferences and generate new rules.

Archetypes and the Reference Model take care of what gets documented.
This world is based on the Closed World Assumption.
In Closed World Systems what is not defined, never will exist.
It will never exist despite what really is going on in reality.

Stating that it is better to derive schema’s from Ontologies is perhaps wrong and impossible when using first order logics and Ontological Methods like Owl.



when openEHR is com defined never can exist.pletely terminology/ontology neutral and its own
'minimal ontology' Compostions, sections, Entries etc has no
relationship to SNOMED CT whatsoever.

The comparison with Hl7v3 seems to be to be completely spurious. HL7v3
constructs are directly analagous to those in openEHR and 13606

Both allow the definition of clinical and non-clinical statements as part of an organising documentation structure



e.g "In contrast to the archetypes that are derived from a top down
approach, the clinical statement structure in HL7 v3 allows a top down
decomposition through the headers, sections, and core content. "

how does this clinical statement structure with headers, sections and
core content fundamentally differ from the openEHR/13606 approach?

I agree.

What do they consider top-down?
And what bottom up?




Finally .. "Therefore, they are facing the problem that the
architectural representation and composition/decomposition of
real-world classes and instances cannot be provided appropriately.
Instead, the models are quite different from reality and themselves
inconsistent."

This statement makes the assumption that clinical modelling is trying
to represent 'real-world' classes and instances, when we are actually
trying to represent the content found within clinical records, not
their 'real world' equivalents i.e the record of diagnosis of diabetes
, not diabetes itself. The reason that the models are inconsistent is
that we are reflecting the inconsistency found in clinical content
capture and understanding. If every clinican in the world agreed on
the content of an allergy record, or if the content could be derived
from a scientific/logical examination of the concept , then perhaps
ontology would have its place but ... in the real, messy inconsistent
world such differences have to be resolved by negotiation and messy.
emergent consensus not by the application of logics.

Wrong, unproven, assumptions by the authors about what Archetypes are, make any discussion void.
If the conclusion by Ian is true, it worries me that one or more reviewers have not noticed this essential issue.

I’m convinced that terms from a terminology (that is built using ontological methods) is -together with complete EHR standards like EN13606) can create Statements that are semantically interoperable.
When it is enough for human understanding to resort to syntax, to standard phrases, and worlds from a dictionary plus an encyclopedia, I think that these same is enough for semantical interoperability in and between EHR-systems.

HL7 v3 and EN13606 are about documenting statements by authors ABOUT what they see and think reality could be.



or perhaps I have just missed the authors' point altogether!

Ian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150301/ad363671/attachment-0002.html>


More information about the openEHR-clinical mailing list