OpenEHR / 13606 and HL7 v3 are doing fundamentally the same

Clinical (archive)
1

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.

2

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

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).

It is more correct that most systems exchange data. It becomes information in the head of the clinician, that is recorded. But it becomes data again when in transport to an other clinician.

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.

The scope of EN13606 is to document information and exchange this stored EHR information.
The scope of HL7 is to transmit data.

What they have in common is that both use the same semantic content.

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.

Part on of EN13606 is the fundamental reference model of the EHR record that Archetypes will constrain.
So CEN/tc251 is not riduculing anything. Part 1 is not about what can be exchanged as data.
CEN/tc251 is not advising people in HL7 to stop working by voting down proposed standards.
HL7-affiliates (and IHE) try to do in the CEN environment.

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.

This part is for the healthcare providers.
And when asked they prefer a system where they can express their information needs and definitions and then implement them without ICT vendor intervention on the fly.
Meaning that local, regional, national or super-national communities can define end express their content and agreed changes without a technical standarisation body (like HL7, CEN or ISO) and the ICT vendors. They want control and flexibility.

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.

Correct.
But EN13606 provides the user communities with the tools to define their minimal data sets, and clinical concepts.
Plus a simple method to implement al this.
Plus an object interface to the database system, business and presentation logic in their systems. Resulting in an uniform interface for exchange of data in the system and between systems.

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.

See above.
Each new EHRextract will be using the same XML-schema. The definition of the clinical content is ‘coded’ in the Archetype that provides its own schema on a more semantic level.

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.

The structure and content are defined at standards making time. And implemented in the system by the vendor in its implementation time. And lastly it has to be implemented in every system that wants to be able to process the new standard message.

Each message and its version is one unique XML-schema to be implemented.

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.

Not as far as expression of semantic content is concerned.
The important differences are in deployment and power to the healthcare professions.

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).

And to a large degree on EHR standards in Europe for communication between systems in different legal entities as opposed to HL7 where they produced standards for exchange of communication within legal entities.

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).

CEN/tc251 EN13606 is scoping Healthcare Records and the exchange between EHR systems. This is about communication and the documentation between healthcare providers and their systems.
And that is different from HL7 v2 and v3 messaging between systems.

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.

This is all fine, with me.

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).

The question is: The model of what?
HL7: Of what can be said, communicated.
CEN (and OpenEHR): Of what can be documented.

These two models have an overlap but a considerable difference at the same time.

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.

When they look at the OpenEHR tools clinicians perceive what the see (and model) as very real and NOT abstract.
And with HL7 is the other way around.

This cause for this is:
OpenEHR (and EN13606) provide very abstract models and the clinicians do their part in a tool they understand and don’t see the underlying complexities.
In HL7 v3 they see all the complexities of H7v3 RIMs etc.

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.

The dynamics between applications that exchange HL7 messages are different from EHR exchanges.
The EHR is there to document and exchange what has been documented. THE EHR-system holds the records and the EN13606 defines the records as stored and in transit to an other system. The triggers are the clinicians them selves and it is all handled by the system. EN13606 is NOT dealing with orders from one system to an other.
This EHR-system is outside of the scope of EN13606. (We have the HISA standard to take care of that)

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.

HL7 is using the RIM and used for exchange of data between systems
CEN/tc251 is using the Document Reference Model part one. It can be compared with the CDA R2. And is used for exchange of Information between EHR’s but also to provide an interface to the database system, the business logic and the presentation logic in the EHR-system.

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.

Requirements for data and information stored in documents in an EHR-system differ from those that are sent to an other EHR-system. EN13606 encompasses both.
EHR-extracts don’t have a series of trigger events described as in HL7 v3 messages between systems.
In the CEN way humans are the triggers. The business logic is in an other place.

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.

All nice.
But this is not part of the CEN/tc251 EN13606 specification. This is in HISA. We have the notion that it is better to separate clinical content from workflow, clinical support etc. It is confusing and creating problems to do to many things in the same process of making standards and implementing them in systems.
Other models, other standards will deal with it. And HL7 has some nice examples, I agree.

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.

Yes what they have in common is the same clinical content.

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.

We discuss two different standards produced for different reasons (scopes) in two different organisations.
On both sides there are plusses and minuses.
And the funny thing is:

  • it most likely will be possible to use the same standardised formal expression of clinicical content in both;
  • because EN13606 have so much in common, both EN13606 and HL7 are able to live together;
  • mapping from one to the other is possible to a high degree;

Let the market decide what they like best:

  • HL7 definition of clinical content in the HL7 standardisation process, the adoption of the resulting XML-schema for each message and version of it by ICT vendors in their systems and the implementation of new software in all systems;
  • the definition of clinical content in the realm of clinicians using CEN/tc251 EN13606 standardised tools, producing archetypes, that always conform to one unique stable XML-schema the vendor will have to use.
  1. 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.

HL7 v3 is a fixed possible clincical instantiation that could be mapped to the EN13606 definition.

  1. 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.

“too many XML-schemas”?

I (we) never blamed it. I agree lets focus on the archetypes, the clinicial models.

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.

  1. 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.

Okay.
Lets continue work