OpenEHR / 13606 and HL7 v3 are doing fundamentally the same: Further debate about the 'Actionability' of orders within OpenEHR
Clinicians care for patients and to do this properly they exchange information, in the current era with use of information and communication technology (ICT). The document based approach (13606 / CDA), archetype exchange approach (OpenEHR), and message based approach (HL7 v3) are all three attempts to facilitate clinicians use of ICT in storing and exchanging information. Due to flaws in human thinking there are philosophical, fundamental limitations in what we as human beings can achieve: claiming that one approach is 'the perfect system' ridicules this system by loosing sight of what we always cannot do. However, we can do a lot, and I will focus on that with the fundamental limitation always in the back of my mind, if only to put things into perspective. These fundamental limitations in what human developed ICT can achieve require us (analysts, modelers, designers, developers, evaluators of ICT) to do two preparation 'things'. First is that clinicians need to make up their minds about what to document and communicate, and how to make their multidisciplinary (there is no other care than multidisciplinary care in 21st century, mobile phones to consult are everywhere) care effective and efficient. This leads to formalization attempts of care, especially the care documentation and the care processes, two other fundamental characteristics of care and care delivery that the ICT solutions need to support. The human interaction between patient and HCP is best left alone from the ICT perspective (although human communication, like applying empathy, interviewing in a matter that respects the patient and brings the real problems to the surface can be learned, it is beyond the ICT). In ICT terminology: we deal with the structure and the dynamics of the world we want to deal with. Examples: HL7 v3 starts with the assumption that this dynamics exist and develops messages that go from health care professional (HCP) A to HCP B, vice versa. The content of messages is made explicit via models. OpenEHR and 13606 start with the assumption that information is documented in ICT and is communicated between ICT solutions, and ensure the content of documentation is based on models to facilitate the exchange. To prevent the vendor lock in, and the inability of systems to communicate, there are tricks invented. One important new development in ICT is the split of clinical content and technology, with use of supporting approaches and tools. For the OpenEHR / 13606 'line' of defining documents and exchanging them between systems, this is nicely done with a reference information model and archetypes that define the structure and content of the clinical data to be exchanged. For the HL7 v3 messaging approach, based on deriving and integrating the clinical content from and to systems, this is nicely done with a reference information model and artifacts that define the structure and content of the clinical data to be exchanged. Basically, from a clinical point of view, there is no difference at all between OpenEHR / 13606 and HL7 v3: both facilitate in the structural aspects of getting clinical data into ICT and communicate about. Differences here (between OpenEHR and HL7v3) is that the dynamics of document / message (in fact clinical data and document structures) exchange builds upon about 15 years of development of v2 messages, and thousands of applications successfully exchanging clinical data (and administrative, but that is not our discussion). I further ignore v2 due to its lack to fully support all clinical data to be structured, but I value the knowledge and expertise of the dynamics of the support of care processes. Apparently, the OpenEHR / 13606 approach is lacking on the dynamic support of the communication of the clinical content and structure (documents and archetypes). Discussions earlier this week on the OpenEHR list, based on Searle's speech acts of illocution and proposition. The illocutionary aspects relate to the dynamics of communication and within HL7 v3 these are modeled carefully as request, promise, referral and event in the mood attribute of classes. Indeed a powerful technological development which supports the dynamics of one HCP asking the other HCP: can you help me with this patient? Where the other answers with Yes, I promise you to help you with this patient, or no I am not smart enough to help you with this patient, but please go to HCP C. And of course then after referral, the care given by HCP C will lead to one to many propositions about the patients (declare that something exist in the patient, e.g. a Barthel score of 7 out of 20, and the medical diagnosis stroke), which in turn are put in a document/system and communicated back as event message to the first HCP, who will use this data in his ICT solution. Here I come to the second preparation 'thing' to be done after clinicians have made up their mind. In order to be able to use the clinical 'things' we develop to work in the ICT solution of choice, smart IT people invented Object Orientation and Unified Modeling Language. Modeling has become the essential step to facilitate communication between clinicians and ICT experts. Modeling gives representations of the real clinical world that can be implemented in ICT. Both OpenEHR and HL7 v3 depend on this modeling, and both are based on the OO / UML methodology. OO essentially works as this: Objects in the real world are modeled in classes that can hold characteristics (attributes) and make behavior explicit (e.g. being active, on hold, completed). There are at least two RIMs playing this modeling game: the 13606 and OpenEHR RIM and the HL7 v3 RIM, especially the derivates of the latter that are models of parts of the clinical world, developed by input from many clinicians (the D-MIMs and R-MIMs). From the clinical perspective, I see no difference in the two, except that the OpenEHR / UML approach looks a little different, especially more abstract / less clinically oriented. HL7 applies additional UML models like use case diagram to describe who are involved in the clinical communication, activity diagrams that explain the complex workflow of multidisciplinary care and sequence and state diagrams that explain the difficult dynamics of mimicking the clinical processes in system behavior, with a focus on the communication between ICT solutions. I am uncertain as to which extend OpenEHR / 13606 support the dynamics of communicating clinical content in document / archetype format between ICT solutions. This brings me to the point both approaches are dealing with: getting the ICT solutions work for clinicians. The two preparations: Sorting out the clinical world and modeling this clinical world to make it fit in ICT are assumed to have taken place before building an ICT system. Direct mapping of clinical world to ICT has proven to fail in supporting communication, processes and data exchange. There are minor differences in the two approaches: both want the clinical world be represented in different ICT solutions and use a standardized approach. Both use the OO / UML approach to model this for fit in the ICT, both distinguish between structure and dynamics, both use a RIM (D-MIM) and more or less formal expressions of clinical content that fit in the RIM / D-MIM, both document and both exchange. The argument that documents are not messages is an irrelevant argument: especially OpenEHR / 13606 documents are communications (so messages in document format) to be exchanged between systems. The OpenEHR / 13606 ICT solution is much smarter compared to old legacy systems in that the document (message) structure is kept and the behavior is kept in the archetype collection to be exchanged. (I assume OpenEHR is not about building one monolithic system that stores everything about every patient because that would cause ownership, maintenance, legal and performance problems of unseen dimensions). The HL7 v3 message format is much smarter because all the dynamics of communication have been carefully developed and proven to work for exchange of clinical information. Interesting is that the HL7 v3 D-MIMs and R-MIMs, especially the one about Care Provision are excellent points of reference to built ICT solutions that support the documentation of detailed clinical information and that support the dynamics of processes via the internal systems use of the mood and status attributes: clinicians can ask a colleague to take over a particular test (request mood: can you do the Barthel index for me later today, I had to explain so many things to the patient, yes, I will do the Barthel later (promise), and the patients Barthel score is entered by Jenny at 18.00 hrs and the score is 12 (event). It becomes even nicer when Jenny 'forgets' to do this and the status attribute interferes on system level with Jenny's work list: the Barthel is in status 'active' once in order mood, and during promise mood. The timing of scoring the Barthel can be set between 9.00 and 19.00 hrs, with an alert 30 minutes before. If the time is 18.30 hrs. The ICT solutions can send Jenny an alert to her mobile pager that the Barthel is still active and in promise mood. When Jenny completes it, the status is changed and mood code in event. OpenEHR might not like such attributes in OO derived classes, but clinicians love such features of the ICT because it makes their work more effective and more efficient. Here I come to the focus of this debate: I find it ridiculous to blame the other approach as inferior: neither approach is. The distinguishing between document/message structure and behavior on one side, and the clinical details expressed in archetypes/templates/R-MIMs/GPICS/CMETs (which from clinical perspective are synonyms because they structure the content) is powerful for support of clinical communication with use of ICT. Key issues where our minds and work should focus on are: 1. Stop arguing against of for a particular stream: it distracts us from the important work to be done! And these approaches are very much complementary to each other on ICT solution side and 99,9% similar on the archetype level where the intention is to represent clinical knowledge as best as we can. 2. Focus on further completion of the generic domain models, irrespective of OpenEHR/13606 or HL7v3 D-MIM, because they are essentially the same. The best model I have seen lately is the HL7 v3 representation of the 13606 RIM. However, it is still unavailable to me: what a shame! HL 7 v3 Care Provision D-MIM is in my opinion a good example of an clinical instantiation of the 13606 model, but the mapping needs to be done. 3. Focus on improving the current archetypes. Both OpenEHR and HL7 v3 have about a hundred archetypes / R-MIMs (small sized, representing one detailed clinical concept). See for examples R-MIM style www.zorginformatiemodel.nl. Still not the best, requiring too many XML schema's, datatypes perhaps clumsy, coding should be improved, too much Dutch orientation, name it, but improve it don't blame it. >From clinical and research perspective most are still not complete. Put effort in getting for instance the top 10 ready for use in ICT, which means: optimal storage in a database, optimal representation in user interface, optimal representation of its behavior in workflow, optimal representation in an XML format for message / document exchange. From OpenEHR perspective I believe that would be work on the dynamics of applying the archetype in the system (order, promise, event, on hold, cancelled, exchanged). From HL7 v3 perspective this would be to prevent the new instantiation of new classes for every clinical concept, but to come to one XML schema for vital signs, for scales and indexes, and probably for other similar items. Perhaps we can eventually come up with XML example representations for the clinical archetypes, which can be put in a HL 7 v3 XML message as a slot, which can be presented to the user in a style sheet, which can be stored in a smart system as an object keeping all characteristics and which can be placed on the appropriate spot in a document. 4. Focus on a tool (set) that helps us to achieve 2 and 3 for clinical ICT solutions, both for messaging and for document exchange, so both for clinical communication. dr. William Goossen, RN, PhD. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20050914/f31c487b/attachment.html>
