Hi Gerard, I agree that we need a DCM model that is free of association with a specific messaging/document specification, but is transformable into the desired one in a reliable manner.
Currently EN 13606-2 is the closest to this, but because it is linked to its own EHR reference model, is not free of issues. While transformation to CDA is possible, using CDA with compositional Act Relationships, the reverse is not always possible. eg CDA, in the form of CCD as an example, uses semantic ACT relationships in places, rather than compositional ones and EN-13606-2 uses only compositional ones (ie items) The semantic Act Relationships would need to become ?CLUSTERS in EN13606-2. I think a DCM format should exclude the administrative attributes, such as Author and Observation Time and leave those to the Information model. Drawing that line is potentially tricky, but needs to be done in order to allow each Information model to do it the way it wants to. Things like order numbers and links to orders should also stay out of the DCM model. In the end we want the pure clinical hierarchical structure that does not conflict with the information model and ideally does not conflict with the Terminology Model. The line between the DCM and terminology is also hard to draw as it varies depending on the ability of the terminology. eg SNOMED-CT is quite rich wrt its models and ICD-X is quite poor. A DCM optimised for SNOMED-CT will be inadequate if the only coding system is ICD-10. I guess including SNOMED-CT context structures with the option to use them for ICD-10 and move them to the terminology for SNOMED-CT is one possibility? 2 similar DCMs (?archetypes) with stated terminology affinity would be another. wrt a "DCM Format" I am sure OWL could provide what's needed, but is not a format that widely understood and optimised for uptake. An Archetype with a DCM Reference model would also be possible. That reference model would not try and be a full EHR model, but the glue to join an information Model to the terminology Model and the gaps to the information models would be filled differently in different information Models. The DCM elements may well be represented in a specific way, but they would need to be transformable back to the DCM model. DCM models in UML and mindmaps/spreadsheets capture pieces of the puzzle but are all inadequate in some way or lack adequate constraints. There is a project in the HL7 Patient Care committee to try and work on a DCM format. Are you suggesting something like this? We have been using EN-13606-2 to structure HL7 V2 messages in Australia, and that works, but you have to design the archetypes in a neutral way. In HL7 V2 we have managed to create the EN13606-2 ENTRY/CLUSTER-ELEMENT hierarchy within OBX segments and there are no Semantic attributes available (ie Act Relationships) so it fits well with the EN13606-2 Model. All the EN13606 reference model outside the COMPOSITION/ENTRY/CLUSTER/ELEMENT relationships has to be mapped, so we are in effect using EN13606-2 as a DCM format. A true DCM format would in my view not have those other attributes, but allow the information model to specify how to do Author, Observation date, Attestation, Patient etc etc. As a clinician I think I can identify what the clinical model is, ie "MEDSPEAK" is. It should be possible to transform that into any information model which then added the administrative attributes about the patient, the author and Observation date etc in its own specific way. I appreciate this is an openEHR list, and maybe this discussion should be transferred to a DCM list, but I don't think there are enough resources to model every clinical concept in every information model and there is enormous value in a neutral DCM format. The archetype concept is a good way to achieve this, but perhaps a generic "DCM only" Reference Model that does not try and be a EHR model would help? Andrew McIntyre Wednesday, February 10, 2010, 8:37:08 PM, you wrote: GF> Dear Andrew, GF> See some reactions in the text below. GF> Gerard GF> as former chairman of CEN/tc251 wg1, responsible for the EN13606 GF> Begin forwarded message: GF> The biggest issues with inter-operability relate to the use of GF> Semantic attributes in both HL7 and openEHR. GF> They are not really semantic in the SNOMED-CT sense in either GF> format, and because they are different, inter-operability between GF> openEHR and HL7 is difficult. OpenEHR has attributes such as GF> "data", "state" etc and HL7 has Act Relationships that are GF> supposed to be semantic rather than just compositional. OpenEHR GF> also has a lot of specific CLUSTERS such as ITEM_TREE and GF> subclasses of ENTRY such as "EVALUATION" which have semantics that GF> are in the implicit in the model, rather than pure clinical knowledge. GF> Yes. HL7 RIM based messages and EN13606 extract are different. GF> No. Both transport the same clinical information from a proprietary system A to B. GF> The clinical information is expressed in a limited set of expressions. GF> Each semantic expression has one specific pattern using HL7 and GF> another specific one using EN13606. GF> When we think about looking at the differences between HL7 CDA GF> and EN 13606 than we see a lot of similarities since CDA (at the GF> semantic level) is a subset of the EN13606 part one. As chair of GF> CENtc251 I was part of that process. GF> This makes a DCM (Detailed Clinical Models) format that both GF> agree on a difficult proposition. There are other differences, GF> such as the ability of HL7 Observations to have both a value and GF> child acts via Act Relationships, where as openEHR does not have CLUSTERS with values. GF> I disagree? GF> Each DCM is expressing a limited set of semantic constructs that GF> can be represented using a DCM reference model. GF> This DCM Reference Model uses the same classes as EN13606/CDA to indicate the structure. GF> And per class possible semantic constructs (also called documentation patterns) GF> A complete DCM model defines 'MEDSPEAK'. GF> A controlled language. Examples in other fields are AIRPSEAK (air GF> trafiic) and SEASPEAK (sea traffic). GF> An other terms I use is: Model of USE, Model of GF> Documentation/Archiving, and DCM ONTOLOGY. GF> The best way to resolve these is to accept that openEHR and HL7 GF> cannot use the same models without adding extra information to the GF> format ie extending ADL or adding attributes to the RMIM. GF> If the clinical knowledge was modelled in ISO-13606 there are GF> only compositional attributes ie "items" and only one of them and GF> the data structures defined require the terminology to impart the GF> meaning and not semantic attributes. This could be translated into GF> openEHR and HL7 in a loss less way. There are obviously some GF> issues with the 13606 reference model, but the pure clinical GF> content is then representable with a tree of Name=Value pairs, GF> with the meaning in the terminology rather than the attribute GF> names. It is also an international standard that gives a degree of GF> certainty and stability to the format, even if its not a perfect fit for every system. GF> Perhaps we do not disagree after all. GF> One of the issues is the fact that EN13606 and therefor openEHR GF> allows too many degrees of freedom to express the same semantic construct. GF> The next version of EN13606 must be designed such that these GF> degrees of freedom are reduced to none. GF> The way to do this is via an additional accepted Model of Use GF> (DCM Model) that defines all semantic constructs plus one mapping to the EN13606 or CDA. GF> I think in most cases the demographic content is able to be GF> mapped, as people have a lot of practice at that. A bigger issue GF> is things like Medication, which has specific classes in HL7 V2 GF> and 3. However the ability to model clinical knowledge outside the GF> contentious areas and represent the clinical knowledge in a GF> standards based format that can be adapted to other formats would GF> be a huge leap forward. It is even possible to represent this in a GF> loss less way in HL7 v2. For things like Medication and Allergies GF> an archetype that can be mapped to HL7 V2 and V3 Segments/classes is needed for interoperability. GF> The use of Semantic or "named" attributes specific to a format is GF> the major barrier to a common DCM format. The HL7 V3 assessments GF> and scales RMIM is and example of a HL7 V3 format that is GF> adaptable to an archetype, although it does have a cluster with a GF> value, which would have to be mapped to the "value" ELEMENT of an archetype. GF> The formula for calculated values is also undefined, but GELLO, GF> which is a standard could be used for this and this is what we use with ISO-13606 archetypes. GF> I cannot see how openEHR archetypes can be used for a general DCM GF> format, but ISO Archetypes could, as long as they were modelled in GF> a fashion that is neutral to final implementation format. GF> It is imperative that DCM's are absolutely free to use and in the GF> public domain. CEN/ISO and ANSI assure that with the GF> standardisation IP rules in general. GF> DCM's must be absolutely free from IP problems, well maintained GF> in a formal, flexible, organisation, owned and controlled by all that use them. GF> OpenEHR as we know it today is a private company. (See under GF> Status: http://www.openehr.org/about/foundation.html) GF> A common format would require both sides to either map the GF> generic structures into their own specific classes or adopt a more GF> generic model with the semantics in the terminology. The overlap GF> between the information model and the terminology model is GF> probably at the heart of the conflict. GF> I produced (but not published) a draft document with the DCM GF> Ontology as addition to the EN13606 and my thoughts about the next version of EN13606. GF> But also with my thoughts about the Boundary problem with coding systems and ontologies. GF> In collaboration with the Technical University in Valencia we GF> started a project to think about the next version of EN13606. GF> For this purpose a website is created as focus point for discussions: www.EN13606.EU GF> Andrew McIntyre GF> Gerard Freriks GF> Electronic Record Services B.V. GF> Ditlaar 7 GF> NL-1066 EE Amsterdam GF> PO Box: 376, NL-2300AJ Leiden GF> the Netherlands GF> M: +31 620347088 GF> E: g.freriks at e-RecordServices.EU GF> W: www.e-recordservices.eu GF> Gerard Freriks GF> +31 620347088 GF> gfrer at luna.nl GF> __________ Information from ESET NOD32 Antivirus, version of GF> virus signature database 4853 (20100210) __________ GF> The message was checked by ESET NOD32 Antivirus. GF> http://www.eset.com -- Best regards, Andrew mailto:andrew at Medical-Objects.com.au
