Dear Andrew, See some reactions in the text below.
Gerard as former chairman of CEN/tc251 wg1, responsible for the EN13606 Begin forwarded message: > > The biggest issues with inter-operability relate to the use of Semantic > attributes in both HL7 and openEHR. > > They are not really semantic in the SNOMED-CT sense in either format, and > because they are different, inter-operability between openEHR and HL7 is > difficult. OpenEHR has attributes such as "data", "state" etc and HL7 has Act > Relationships that are supposed to be semantic rather than just > compositional. OpenEHR also has a lot of specific CLUSTERS such as ITEM_TREE > and subclasses of ENTRY such as "EVALUATION" which have semantics that are in > the implicit in the model, rather than pure clinical knowledge. Yes. HL7 RIM based messages and EN13606 extract are different. No. Both transport the same clinical information from a proprietary system A to B. The clinical information is expressed in a limited set of expressions. Each semantic expression has one specific pattern using HL7 and another specific one using EN13606. When we think about looking at the differences between HL7 CDA and EN 13606 than we see a lot of similarities since CDA (at the semantic level) is a subset of the EN13606 part one. As chair of CENtc251 I was part of that process. > > This makes a DCM (Detailed Clinical Models) format that both agree on a > difficult proposition. There are other differences, such as the ability of > HL7 Observations to have both a value and child acts via Act Relationships, > where as openEHR does not have CLUSTERS with values. I disagree? Each DCM is expressing a limited set of semantic constructs that can be represented using a DCM reference model. This DCM Reference Model uses the same classes as EN13606/CDA to indicate the structure. And per class possible semantic constructs (also called documentation patterns) A complete DCM model defines 'MEDSPEAK'. A controlled language. Examples in other fields are AIRPSEAK (air trafiic) and SEASPEAK (sea traffic). An other terms I use is: Model of USE, Model of Documentation/Archiving, and DCM ONTOLOGY. > > The best way to resolve these is to accept that openEHR and HL7 cannot use > the same models without adding extra information to the format ie > extending ADL or adding attributes to the RMIM. > > If the clinical knowledge was modelled in ISO-13606 there are only > compositional attributes ie "items" and only one of them and the data > structures defined require the terminology to impart the meaning and not > semantic attributes. This could be translated into openEHR and HL7 in a loss > less way. There are obviously some issues with the 13606 reference model, but > the pure clinical content is then representable with a tree of Name=Value > pairs, with the meaning in the terminology rather than the attribute names. > It is also an international standard that gives a degree of certainty and > stability to the format, even if its not a perfect fit for every system. Perhaps we do not disagree after all. One of the issues is the fact that EN13606 and therefor openEHR allows too many degrees of freedom to express the same semantic construct. The next version of EN13606 must be designed such that these degrees of freedom are reduced to none. The way to do this is via an additional accepted Model of Use (DCM Model) that defines all semantic constructs plus one mapping to the EN13606 or CDA. > > I think in most cases the demographic content is able to be mapped, as people > have a lot of practice at that. A bigger issue is things like Medication, > which has specific classes in HL7 V2 and 3. However the ability to model > clinical knowledge outside the contentious areas and represent the clinical > knowledge in a standards based format that can be adapted to other formats > would be a huge leap forward. It is even possible to represent this in a loss > less way in HL7 v2. For things like Medication and Allergies an archetype > that can be mapped to HL7 V2 and V3 Segments/classes is needed for > interoperability. > > The use of Semantic or "named" attributes specific to a format is the major > barrier to a common DCM format. The HL7 V3 assessments and scales RMIM is and > example of a HL7 V3 format that is adaptable to an archetype, although it > does have a cluster with a value, which would have to be mapped to the > "value" ELEMENT of an archetype. > > > The formula for calculated values is also undefined, but GELLO, which is a > standard could be used for this and this is what we use with ISO-13606 > archetypes. > > I cannot see how openEHR archetypes can be used for a general DCM format, but > ISO Archetypes could, as long as they were modelled in a fashion that is > neutral to final implementation format. It is imperative that DCM's are absolutely free to use and in the public domain. CEN/ISO and ANSI assure that with the standardisation IP rules in general. DCM's must be absolutely free from IP problems, well maintained in a formal, flexible, organisation, owned and controlled by all that use them. OpenEHR as we know it today is a private company. (See under Status: http://www.openehr.org/about/foundation.html) > > A common format would require both sides to either map the generic structures > into their own specific classes or adopt a more generic model with the > semantics in the terminology. The overlap between the information model and > the terminology model is probably at the heart of the conflict. I produced (but not published) a draft document with the DCM Ontology as addition to the EN13606 and my thoughts about the next version of EN13606. But also with my thoughts about the Boundary problem with coding systems and ontologies. In collaboration with the Technical University in Valencia we started a project to think about the next version of EN13606. For this purpose a website is created as focus point for discussions: www.EN13606.EU > > Andrew McIntyre Gerard Freriks Electronic Record Services B.V. Ditlaar 7 NL-1066 EE Amsterdam PO Box: 376, NL-2300AJ Leiden the Netherlands M: +31 620347088 E: g.freriks at e-RecordServices.EU W: www.e-recordservices.eu Gerard Freriks +31 620347088 gfrer at luna.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/88f76f5f/attachment.html>
