Williamtfgoossen at cs.com wrote: > These are archetypes in which the clinicians materials are sorted out, coded > etc. > > They currently are made operational for use in a message. Sam has worked with > the Barthel index, which based on this example for R-MIM, however based on > the tables, could be written up in ADL language in less than 15 minutes, > where the sorting out of Barthel for clinical and making the variable / > coding tables etc took about 8 days of work due to many variants in practice. > William,
undoubtedly there are archetypes available from the models you have defined. However, any HL7 model also contains a lot of junk attributes, and the RMIMs are not based on the same underlying ontology (i.e. reference model). The RIM is quite deficient in many ways which prevent the easy expression of many clinical concepts as archetypes (and it is easy to demonstrate this - just try and build an archetype based on the RIM for Apgar result.) > How these can obey to the model is explained in the CEN 13606 R-MIM which is > going to be discussed next weekend in San Antonio. > > I am just waiting for a tool that helps me with the conversion to the > different operational archetyping. > you are implying that it is simply a matter of a technical transform, but it isn't. For archetypes to be interoperable, they need to be based on the same underlying reference model, or on a model that is machine convertible to a common reference model. This reference model acts as the base ontology for archetypes; if it contains concepts like Observation, History and Event for example, then your archetype can use these. In openEHR, we use a subset of the openEHR reference model as the underlying ontology for archetypes. Obviously some people will say: this is just one possible reference model and we should be able to use any reference model. This would be to misunderstand the ontological basis of modelling in general. There is not easy way for interoperable models of content to be expressed at a certain "high" level, based on lower level concepts (themselves representing various ontological commitments) without being committed to that lower level in some way. To provide an analogy, in object-orientation, we write program texts in the form of "class" definitions, containing "attribute", "function" and "procedure" definitions. These latter terms for a base ontology of commitments assumed by many languages, such that a programmer versed in one language (say C++) is capable (mostly) of understanding texts written in other languages (say Java, C#, Eiffel, Python, Ada etc). You can't define a class text if you don't commit to the concept of a "class" in the first place. The same is true in health informatics. So, with the openEHR reference model we have tried to create a model that also works as a language for expressing higher level concepts in the same realm. Thus classes like Composition, Section, Observation, Evaluation, Instruction, Action, History, Event, Item_list, Item_tree, Quantity, Date_time, Coded_text etc are all sensible ontological concepts in the domain as well as being class definitions in the reference model. openEHR archetypes are based on these concepts in a formal way. Now - we have taken some trouble to minimise the dependence on details in the openEHR reference model. In an archetype you will see that the definition of things like Quantity and Coded_text is done in a syntactic way, and does not try to force everyone to have exactly openEHR's definition of these things, only to have minimal common semantics. Archetypes using constructs like Observation, History, Event, Instruction and so on also do not mention all of their attributes; only the ones germane to the clinical modelling exercise. So - an openEHR archetype could quite reasonable be compatible with another reference model that is contains formally equivalent semantics for the elements mentioned in the archetype, even if other semantics exist. What this means is that the archetype is constraining an assumed "shared reference model", i.e. the common subset of two concrete reference models. Now if we look at an HL7 RMIM, it is based on the RIM. The RIM is quite different semantically from even the implicit shared part of the openEHR reference model in various ways: - there are no addressable data structures like List, Table, Tree etc - there is no History or Event - there is Observation, but incompatibly defined - there is no explicit Evaluation, Instruction - there is Act, but this is so general it is used for everything in the RIM that isn't an Entity, or a Participation or Role; openEHR's Action is just for actions; - there are numerous attributes that don't map clearly, and I would argue really have no place in a model to be used as the basis for domain content modelling (e.g. many attributes relate specifically to the messaging purpose of HL7 v3; content models should be defiinable independent of where the content is actually carried or stored). So RMIMs based on the RIM directly are not going to be safely machine-convertible to archetypes based on the openEHR model. I have tried this with others on paper, and you quickly run into trouble. Is there any hope for interoperability then between these two worlds? One answer is that if an RMIM such as the clinical statement is regarded as the "real" reference model upon which to based clinical and related archetypes in the HL7 world, then there might be some possibilities. From my point of view, the clinical statement RMIM has to solve the same problems as the openEHR reference model. It is closer to it than the RIM but I think it a) has some way to go, and b) still contains numerous HL7 message specificities that are irrelevant to building models of domain content. The mood code is a good example. If a domain expert is given a tool and asked to model "Barthel index", the question of "what mood code" each node is, is just not meaningful. The same is true for most of the Act and Act-relationship attributes - they are not meaningful to content modelling, and yet you are forced to include them in any derived HL7 model. Nevertheless, if there is scope for interoperability, it is from templates based on the clinical statement and possibly the CDA models, not RMIMs based on the RMIM. > This does bring me to the conclusion that we are more or less focussing on > different concepts which we both call archetype. > > For me the archetype (and in HL7 world template and in CEN also GPIC) is a > reusable and standardised format of a small or little larger piece of > clinical information, expressed into a model that makes it implementable into > technology. > So giving structure, determining data type, assigning a mandatory value set > and meaning such as in clinimetric scales (Barthel, Apgar), unique coding > (the tables in the current format under section's 8 - 10) is for me the > essence of the archetype. So a technical specification of clinical content. > I agree with all these words. But an HL7 RMIM based on the RIM does not conform very well to these notions. > Then, I think comes your point, and perhaps I now better understand your > position, this technical specification of the clinical stuff must be given a > specific format to make it work in IT. In our projects I have to make it work > in the HL7 v3 messages and in the EHR's that use the RIM and D-MIMs as their > reference model for the database (similar to Oracle HTB) > yes, this is exactly the point. In openEHR we specifically don't tie archetypes to any specific model of messaging (hence no messaging related attributes), since we know they will be re-used in screen forms, EHR data structures, messages, and in many different technologies. HL7 RMIMs are stick to the RIM, and in particular the message-related attributes (quite apart from the problem of missing the semantics listed above). > In your case for OpenEHR it must adhere to the archetype definition language. > > Well, not to go into the discussion again about which is best the egg or the > hen, I have the experience that we do need a well structured clinical > information set to work in both a message and in an EHR. > > To me it does not matter how it is formalised to work in IT, but to you it > apperently does because you want to implement it in the EHR based on OpenEHR > principles. > it does matter, but not because of openEHR. It is a mathematical certainty that the formalisation matters, due to the ontological commitments of any model. > For the clinical content expressed it does not matter, for what you need to > do with it it does. > but for any hope of sharing, it does matter. It is the difference between having a PDF of a diagnostic guideline expressed in natural language (not interoperable in any computing sense) and the same guideline expressed in a formal guideline language. To actually create the latter, you have to a) commit to a particular language of expression, e.g. prodigy, proforma etc, and b) you have to commit to using it in an agreed way to express the semantics of the guideline. If different groups make either of these choices differently, then interoperability won't happen. > So given the parallel discussion on vocab: > > steps to deal with it are beginning to become clear: > > - formalize the clinical materials (literature, evidence, clinician input) > - make them technically specific operational (data type, coding, valueset > binding, cardinalities etc) > - express them in ADL for use in Open EHR > - express them in Hl7 v3 R-MIM for use in messages. > this forgets one major element: expressing things in ADL doesn't mean interoperable or even comprehensible archetypes - the reference model on which any archetypes that we write are based is the key choice to agree on - the implicit "shared" I describe above. > I earlier assumed that conversion from R-MIM to ADL was doable, but > apparently it is not. > at a syntactic level it is - see http://svn.openehr.org/knowledge/archetypes/dev/adl/hl7-rim/Laboratory/hl7-rmim-observation.observation-general.draft.adl However, this expression of the lab observation RMIM in ADL doesn't really buy anything, since the assumed reference model is the RIM; the lab observation archetype used in openEHR is here (raw ADL: http://oceaninformatics.biz/archetypes/ADL/openEHR-EHR-OBSERVATION.laboratory.v1.adl ; human readable form - http://oceaninformatics.biz/archetypes/openEHR-EHR-OBSERVATION.laboratory.v1.html). Sorry for the raw ADL, but if you take the time to look at it carefully, you will see that there is not much commonality. Now try the same thing with blood glucose as an RMIM, convert to ADL, then compare to http://oceaninformatics.biz/archetypes/openEHR-EHR-OBSERVATION.laboratory-glucose.v1.html (raw form link at top of page). Try some of the other archetypes at http://oceaninformatics.biz/archetypes/MindMap/ArchetypeMap.html - you will see how different they are. The differences are due to the different underlying reference models, not the different syntactic ways of expressing the concepts. > But from a table with technical operational materials (step 2 above) we must > be able to go both ways depending on need and national strategy? > > in principle, but the missing step is that a shared underlying reference model, or concepts thereof have to be agreed. And that requires understanding by all parties of the ontological generalities of modelling (some explanation is given in section 4.1 of http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/overview.pdf) > I look forward to further harmonisation work on archetypes and templates. HL7 > template group is currently working on applying ADL / CEN 13606-2 for further > work, but given the discussion above, we might need to look for a model that > allows us to express it operational, but unbound to specific technology. > The main point for such activities to be meaningful is not syntactic re-expression in ADL (and in fact, there are other alternate expressions, including ones based on XML), but some convergence on a shared underlying reference model. - thomas -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org)
