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:[email protected]] 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.html>
