Comparative analysis of HL7 and openEHR
The following article is my free translation of the comparative (rather superficial) analysis of the HL7 and openEHR standards published in electronic Journal of Health Informatics 2010 Vol 5 entitled “ Putting Health Record Interoperability Standards to Work ”. The article itself, as is customary to say, was kindly provided by one of the authors, although, in view of the length of publication, I refrained from a heap of additional questions.
From the whole article, only the positive and negative sides of each of the standards are taken from the point of view of the authors, who (the authors) are adherents of openEHR and, as it were, should lead readers to the idea that openEHR has clear advantages over HL7.
Obviously, how many people have so many comparisons (you can look " What should be the standards " by Adam Bosworth), for me the following is more like a comparison of soft and green, because HL7 and openEHR pursue different goals, their development was based on different principles, and if you managed to spot some correspondence between them, this does not mean that they are equivalent. Nevertheless, this comparison takes place, the authors themselves are engaged in the development of the standard (openEHR), so their opinion should be interesting. My rare comments in square brackets. If something is not entirely clear, I recommend referring to the source, perhaps your translation will be better. Also, the article contains positive and negative sides of CDA and CEN EN13606, in my opinion, these comparisons are not so significant, because refer to their standards ancestors.
HL7v2
')
Positive sides:
• The data types of the HL7v2 standard are quite expressive and allow you to send arbitrarily structured objects. As a result, an existing, HL7v2-based infrastructure can be used to transfer various, semantically rich, data. [This is even more relevant to HL7v3, but it is not mentioned there.]
• Segments added in later versions largely avoided the need to define additional segments by the user.
• Ease of use and wide distribution contributes to further use and relatively inexpensive implementation of third-party vendors. [The comparison does not take into account those who start from scratch.]
Negative sides:
• Optionality and ambiguity in the interpretation of message segments inhibits overall compatibility, for a successful exchange of messages a preliminary agreement between counterparties is necessary.
• Lack of explicit semantics complicates messaging. There are no means for describing semantic content except that it is strictly prescribed in the standard. Unable to establish relationships between different parts of the message.
• Regional implementations have achieved limited success. [And how is this consistent with their own statement about ease of use and wide distribution?]
• Confidentiality and access rights issues required for EHRs. [These problems can be blamed on, for example, the SOAP in the body of which the HK7 message is transmitted.]
• The means of expressing HL7v2 is insufficient for coding complex clinical studies. [Question - Do you need to transmit messages with complex clinical studies?]
HL7v3
Positive sides:
• Flexible and rich semantics allows you to express any area of health.
• The standard solves many of the difficulties encountered in practice with medical data (such as lack of information, inaccuracies, duplication of records, etc.)
• HL7 RIM provides tools for describing the medical reality, although it is at the mercy of working groups that do this with the help of terminology or ontology.
• There are a variety of development tools. [It's not entirely clear what exactly is meant by development tools - modeling tools, integration tools, XML tools.]
• Can be used in analytical decision-making systems.
• “Most of the work in the field of medical care (in the USA) is based on v3.” [Apparently, CDA and other document templates are meant.]
• HL7v3 is not so complicated if it is dealt with once and most implementations do not need all the subtleties of the standard. The dynamic model is as simple as the HL7v2. [Maybe not more complicated, which can be difficult in the request-response, but more often it does not directly correspond to HL7v2.]
Negative sides:
• Even among the v3 specialists, there is no confidence in its suitability for the stated goals.
• Switching to v3 for many medical processes, such as alerts, drug testing, etc., does not give clear advantages over v2. Those. ROI is not transparent enough. [Again, what about those who start from scratch.]
• The first regulatory publication was in 2005, but since then the standard has been constantly updated. [Actually, this refers to any standard.]
• The structure of the v3 message is quite complicated and difficult to understand, which requires a rather long learning process, which, in turn, affects the number of specialists in this standard.
• It is incorrect to say that the v2-v3 mapping can automatically perform the integration engine, while some fields of the v2 message can be easily matched to the fields of the v3 message, the interaction process itself and its trigger events are different in the two standards. [In reality, it is still worse, mapping is almost impossible to perform automatically, trigger events in v2 and v3 messages are different.]
• It is much harder to get all the artifacts from a v3 message than to send them, because more effort is needed to extract meaning from the v3 message. [This is more relevant to CDA with complex sectional patterns than to messages. This is just one of the drawbacks of this comparison, in my opinion, because The authors constantly mix messaging and documents.]
• RIM suffers from a mismatch between the Information Model (entity objects) and the Reference Ontology (entities as entity descriptions). [Explain it to me in Russian!]
• RIM confuses the act with the record, and the documents themselves are hardly structured. There is no hierarchy of documents, there is no formal model for expressing relations between documents, and there are no means to express data in a clinical context. [And where are the documents, and here is the relationship between document templates inherited from CDA?]
• Some definitions are illogical, there are no such concepts as "diagnosis", "assessment" and "prognosis". [The entire PRPA domain is dedicated only to this, all concepts are present there.]
• The information contained in documents (CDA) and in messages is interpreted differently. While the document is allowed to make an actual statement (albeit in the narrative section), the message can only indirectly state the Observation Act class. [Maybe because these are different things. CDA is just one of the HL7v3 NE domains.]
• v3 is not suitable as a model for storing information for an EHR, and the standard itself does not describe any architectural model (apart from the EHR-S FM, which describes the functions of the system, and not the architecture). [I wrote about this in the last article, so I will not repeat it.]
• The information content of v3 XML messages is very low (no more than 5%), while the message itself is quite large.
• The complexity of the model and its interaction with external dictionaries, such as SNOMED CT, means that you can express a statement in a multiple way, while at the same time there is no unique way for the recipient to interpret the information in the same way.
• The semantics of the message content are mixed with the semantics of the message itself.
• It is not clear how one could request a repository of v3 messages. [Can someone explain what they are about?]
• The design of the HL7v3 is closer to the process description language than to the document description. This creates a relationship between documents and processes — the content of the documents is limited by the process requirements associated with them. [And let's talk about ASTM CCR, its content is not limited to the process in which it is used? CCR is the progenitor of the HL7 CCD. Or other HITSP documents that were prototypes for CDA document templates.]
• Implementing messages requires a lot of resources. In all systems involved in communications messages must be implemented in the same way. [A very strange statement, if I communicate with someone in Russian, I expect that they will also answer me in Russian, even if it takes a long time for the speaker to study.]
openEHR
Positive sides:
• The model is intuitive and easy to understand doctors. Archetypes are generally easy to understand, discuss, and design. The terms used are easily correlated with the clinical record.
• The approach used is to record the doctor's observations and requests for these records.
• The model fully complies with ISO / TS 13808.
• Requests can be sent by HL7v2 messages. [Probably they can also be transferred to HL7v3 and saved to CDA.]
• Since domain-specific semantics in declarative archetypes and dictionaries, the reference model must be stable for a long time.
• Archetypes can be converted to CDA using XSLT.
Negative sides:
• The approach used lacks sense rigor, it also does not contain ontology. The reference model does not provide a basis for semantic compatibility — a separate model is required to represent the clinical semantics and relationships between the concepts.
• It does not provide sufficient support for semantic links between archetypes. Within archetypes, semantics is defined by the author of this archetype.
• The standard has not yet been used for the implementation of medium and large systems.
• The standard is almost not common, despite the sufficient time of existence. [Article written in 2010, since then, probably, there have been some changes.]
• The specification of the standard is not stable and is constantly changing. [Where does she go.]
• It is quite problematic to create an interconnected and logically non-intersecting model. To avoid semantic duplication and conflicts for national repositories, more sophisticated development tools may be needed than those that exist at the moment.
• Support from official standards developers, such as SNOMET CT or ISO 13606, is very weak.
Roughly speaking, HL7 and openEHR use diametrically opposite approaches to the same field. If HL7 acts like a sculptor, takes a lump of RIM and cuts off all unnecessary from it to express some kind of honey area, implying that if the system is able to operate with RIM concepts, it will be able to interpret any message built on the trimmed RIM model. In theory. In practice, everything is somewhat more complicated.
In contrast, openEHR takes the cubes of archetypes, clones them an unlimited number of times and tries to build a virtual EHR from them backing it up with an information model.
From the whole article, only the positive and negative sides of each of the standards are taken from the point of view of the authors, who (the authors) are adherents of openEHR and, as it were, should lead readers to the idea that openEHR has clear advantages over HL7.
Obviously, how many people have so many comparisons (you can look " What should be the standards " by Adam Bosworth), for me the following is more like a comparison of soft and green, because HL7 and openEHR pursue different goals, their development was based on different principles, and if you managed to spot some correspondence between them, this does not mean that they are equivalent. Nevertheless, this comparison takes place, the authors themselves are engaged in the development of the standard (openEHR), so their opinion should be interesting. My rare comments in square brackets. If something is not entirely clear, I recommend referring to the source, perhaps your translation will be better. Also, the article contains positive and negative sides of CDA and CEN EN13606, in my opinion, these comparisons are not so significant, because refer to their standards ancestors.
HL7v2
')
Positive sides:
• The data types of the HL7v2 standard are quite expressive and allow you to send arbitrarily structured objects. As a result, an existing, HL7v2-based infrastructure can be used to transfer various, semantically rich, data. [This is even more relevant to HL7v3, but it is not mentioned there.]
• Segments added in later versions largely avoided the need to define additional segments by the user.
• Ease of use and wide distribution contributes to further use and relatively inexpensive implementation of third-party vendors. [The comparison does not take into account those who start from scratch.]
Negative sides:
• Optionality and ambiguity in the interpretation of message segments inhibits overall compatibility, for a successful exchange of messages a preliminary agreement between counterparties is necessary.
• Lack of explicit semantics complicates messaging. There are no means for describing semantic content except that it is strictly prescribed in the standard. Unable to establish relationships between different parts of the message.
• Regional implementations have achieved limited success. [And how is this consistent with their own statement about ease of use and wide distribution?]
• Confidentiality and access rights issues required for EHRs. [These problems can be blamed on, for example, the SOAP in the body of which the HK7 message is transmitted.]
• The means of expressing HL7v2 is insufficient for coding complex clinical studies. [Question - Do you need to transmit messages with complex clinical studies?]
HL7v3
Positive sides:
• Flexible and rich semantics allows you to express any area of health.
• The standard solves many of the difficulties encountered in practice with medical data (such as lack of information, inaccuracies, duplication of records, etc.)
• HL7 RIM provides tools for describing the medical reality, although it is at the mercy of working groups that do this with the help of terminology or ontology.
• There are a variety of development tools. [It's not entirely clear what exactly is meant by development tools - modeling tools, integration tools, XML tools.]
• Can be used in analytical decision-making systems.
• “Most of the work in the field of medical care (in the USA) is based on v3.” [Apparently, CDA and other document templates are meant.]
• HL7v3 is not so complicated if it is dealt with once and most implementations do not need all the subtleties of the standard. The dynamic model is as simple as the HL7v2. [Maybe not more complicated, which can be difficult in the request-response, but more often it does not directly correspond to HL7v2.]
Negative sides:
• Even among the v3 specialists, there is no confidence in its suitability for the stated goals.
• Switching to v3 for many medical processes, such as alerts, drug testing, etc., does not give clear advantages over v2. Those. ROI is not transparent enough. [Again, what about those who start from scratch.]
• The first regulatory publication was in 2005, but since then the standard has been constantly updated. [Actually, this refers to any standard.]
• The structure of the v3 message is quite complicated and difficult to understand, which requires a rather long learning process, which, in turn, affects the number of specialists in this standard.
• It is incorrect to say that the v2-v3 mapping can automatically perform the integration engine, while some fields of the v2 message can be easily matched to the fields of the v3 message, the interaction process itself and its trigger events are different in the two standards. [In reality, it is still worse, mapping is almost impossible to perform automatically, trigger events in v2 and v3 messages are different.]
• It is much harder to get all the artifacts from a v3 message than to send them, because more effort is needed to extract meaning from the v3 message. [This is more relevant to CDA with complex sectional patterns than to messages. This is just one of the drawbacks of this comparison, in my opinion, because The authors constantly mix messaging and documents.]
• RIM suffers from a mismatch between the Information Model (entity objects) and the Reference Ontology (entities as entity descriptions). [Explain it to me in Russian!]
• RIM confuses the act with the record, and the documents themselves are hardly structured. There is no hierarchy of documents, there is no formal model for expressing relations between documents, and there are no means to express data in a clinical context. [And where are the documents, and here is the relationship between document templates inherited from CDA?]
• Some definitions are illogical, there are no such concepts as "diagnosis", "assessment" and "prognosis". [The entire PRPA domain is dedicated only to this, all concepts are present there.]
• The information contained in documents (CDA) and in messages is interpreted differently. While the document is allowed to make an actual statement (albeit in the narrative section), the message can only indirectly state the Observation Act class. [Maybe because these are different things. CDA is just one of the HL7v3 NE domains.]
• v3 is not suitable as a model for storing information for an EHR, and the standard itself does not describe any architectural model (apart from the EHR-S FM, which describes the functions of the system, and not the architecture). [I wrote about this in the last article, so I will not repeat it.]
• The information content of v3 XML messages is very low (no more than 5%), while the message itself is quite large.
• The complexity of the model and its interaction with external dictionaries, such as SNOMED CT, means that you can express a statement in a multiple way, while at the same time there is no unique way for the recipient to interpret the information in the same way.
• The semantics of the message content are mixed with the semantics of the message itself.
• It is not clear how one could request a repository of v3 messages. [Can someone explain what they are about?]
• The design of the HL7v3 is closer to the process description language than to the document description. This creates a relationship between documents and processes — the content of the documents is limited by the process requirements associated with them. [And let's talk about ASTM CCR, its content is not limited to the process in which it is used? CCR is the progenitor of the HL7 CCD. Or other HITSP documents that were prototypes for CDA document templates.]
• Implementing messages requires a lot of resources. In all systems involved in communications messages must be implemented in the same way. [A very strange statement, if I communicate with someone in Russian, I expect that they will also answer me in Russian, even if it takes a long time for the speaker to study.]
openEHR
Positive sides:
• The model is intuitive and easy to understand doctors. Archetypes are generally easy to understand, discuss, and design. The terms used are easily correlated with the clinical record.
• The approach used is to record the doctor's observations and requests for these records.
• The model fully complies with ISO / TS 13808.
• Requests can be sent by HL7v2 messages. [Probably they can also be transferred to HL7v3 and saved to CDA.]
• Since domain-specific semantics in declarative archetypes and dictionaries, the reference model must be stable for a long time.
• Archetypes can be converted to CDA using XSLT.
Negative sides:
• The approach used lacks sense rigor, it also does not contain ontology. The reference model does not provide a basis for semantic compatibility — a separate model is required to represent the clinical semantics and relationships between the concepts.
• It does not provide sufficient support for semantic links between archetypes. Within archetypes, semantics is defined by the author of this archetype.
• The standard has not yet been used for the implementation of medium and large systems.
• The standard is almost not common, despite the sufficient time of existence. [Article written in 2010, since then, probably, there have been some changes.]
• The specification of the standard is not stable and is constantly changing. [Where does she go.]
• It is quite problematic to create an interconnected and logically non-intersecting model. To avoid semantic duplication and conflicts for national repositories, more sophisticated development tools may be needed than those that exist at the moment.
• Support from official standards developers, such as SNOMET CT or ISO 13606, is very weak.
Roughly speaking, HL7 and openEHR use diametrically opposite approaches to the same field. If HL7 acts like a sculptor, takes a lump of RIM and cuts off all unnecessary from it to express some kind of honey area, implying that if the system is able to operate with RIM concepts, it will be able to interpret any message built on the trimmed RIM model. In theory. In practice, everything is somewhat more complicated.
In contrast, openEHR takes the cubes of archetypes, clones them an unlimited number of times and tries to build a virtual EHR from them backing it up with an information model.
Source: https://habr.com/ru/post/257883/
All Articles