What kind of beast is HL7 Interoperability?
If you read books about Health Level 7 (HL7), or took courses, or can take part in conferences, watch presentations, etc. etc., they probably noticed that most often they start with the statement that the main goal of the Health Level 7 organization is to improve interoperability or interoperability.
If you learn to hesitate to pronounce this very “interoperability”, you can issue phrases like “ Our company successfully consolidates even more aspects of the interoperability of quasi and multi-domain heterogeneous systems and means of customization to the conditions of a particular application ” and blow your cheeks. Everything around will nod their heads meaningfully - well, interoperability, it's absolutely understandable, we swam, we know.
Let's try to figure it out, what the word means and why HL7 considers this concept to be so important. For a start, let's replace it with an equivalent in value, but Russian word. It seems to me that “compatibility” is quite suitable. Then it turns out that HL7 is concerned about the compatibility of medical systems. It sounds not so clever, the cheeks are no longer possible to blow, but the term itself becomes much simpler and clearer.
')
HL7 identifies three types of compatibility: technical, semantic, and process compatibility. Let's look at examples of what each of them means.
Technical compatibility
Here everything seems to be clear, the systems should communicate in one "language". I think many people remember how programs like “Stirlitz” existed in the days of the Internet, and “Encoding” was the favorite button in the browser. These are examples of non- compatibility at the technical level. We can assume that in HL7 communications there are few or no problems with this at the moment.
Semantic compatibility
Discussing semantic compatibility, i.e. compatibility at the semantic level, believe that the technical is already fully ensured. As an example of semantic compatibility, we take the following hypothetical case. Suppose that a team of paramedics (ambulance) arrived at the call. The victim is unconscious, but his demographic data are known. The paramedic sends a request to the central medical system for the presence of allergic reactions to the anesthetics for the affected person. The answer is no.
This “no”, what does it mean? Should a paramedic decide that:
• The sufferer does not have an allergy to the medication.
• The system does not have data on allergic reactions for this patient.
• This patient is not in the system.
It is clear that the clinical risks are significantly different for each of the selected responses.
If this example seems too far-fetched to you, then there are several ways to negate the result in HL7v3: using the NullFlavor, using the negationInd attribute and using the SNOMED CT code. As it is easy to notice, it is very easy to construct a negation negation construct. Or another case, when the machine-readable code uses NullFlavor, and the human-readable part (element originalText) carries some information. What to choose in this case?
Process compatibility
I will try to explain this type of compatibility in the following, again, a hypothetical example, although someone may say that it also relates to semantic compatibility, which, in part, it is. Suppose a malicious smoker was offered to complete a smoking cessation program (smoking cessation) and the following provisions need to be coded: the smoker could not complete the program due to its closure . Well, it's easier than that, someone will say, take SNOMED CT and find the necessary code. The term search - smoking cessation - returns more than 20 results, this does not include local dictionaries. Moreover, the terms refer to different branches, i.e. we can not say that if the code is in the range from ... to ..., then probably it is about smoking cessation. That is, if clinics do not agree in advance on which term to use to refer to a particular concept, then compliance may not occur, despite overcoming the first two levels of compatibility.
In one of the previous articles, I wrote that the customer, and often the direct developer, is often unable to assess the complexity of the project with HL7. It is enough to note that only bringing the SNOMED CT dictionary from its 300 thousand concepts to the possibility of real use (significantly reducing the terminology to 5-10 thousand concepts) will take not a week or two. A team of experts can spend 6 months only for this part of the project easily. And without it, you can’t say that honey systems are compatible.
So that the examples do not seem too far-fetched, take the real picture of the interaction in one of the clinical cases (below):
It is easy to see that compatibility at least on the first two levels should be between all participants in the treatment process.
The three levels presented are not the only possible compatibility levels. For example, the European Interoperability Framework (EIF) adds another layer - Legal Interoperability - which includes data protection and more.
In the conclusion of this short article. Those who first encountered this term and want to learn more, you can try with the book “ Principles of Health Interoperability HL7 and SNOMED ” (Tim Benson). How to search for books in the internet, probably, is not necessary to explain.
For advanced users, we recommend that you subscribe to the listserver - HL7 Electronic Health Record Interoperability Work Group (EHR Interoperability WG) list - on the hl7.org website
If you learn to hesitate to pronounce this very “interoperability”, you can issue phrases like “ Our company successfully consolidates even more aspects of the interoperability of quasi and multi-domain heterogeneous systems and means of customization to the conditions of a particular application ” and blow your cheeks. Everything around will nod their heads meaningfully - well, interoperability, it's absolutely understandable, we swam, we know.
Let's try to figure it out, what the word means and why HL7 considers this concept to be so important. For a start, let's replace it with an equivalent in value, but Russian word. It seems to me that “compatibility” is quite suitable. Then it turns out that HL7 is concerned about the compatibility of medical systems. It sounds not so clever, the cheeks are no longer possible to blow, but the term itself becomes much simpler and clearer.
')
HL7 identifies three types of compatibility: technical, semantic, and process compatibility. Let's look at examples of what each of them means.
Technical compatibility
Here everything seems to be clear, the systems should communicate in one "language". I think many people remember how programs like “Stirlitz” existed in the days of the Internet, and “Encoding” was the favorite button in the browser. These are examples of non- compatibility at the technical level. We can assume that in HL7 communications there are few or no problems with this at the moment.
Semantic compatibility
Discussing semantic compatibility, i.e. compatibility at the semantic level, believe that the technical is already fully ensured. As an example of semantic compatibility, we take the following hypothetical case. Suppose that a team of paramedics (ambulance) arrived at the call. The victim is unconscious, but his demographic data are known. The paramedic sends a request to the central medical system for the presence of allergic reactions to the anesthetics for the affected person. The answer is no.
This “no”, what does it mean? Should a paramedic decide that:
• The sufferer does not have an allergy to the medication.
• The system does not have data on allergic reactions for this patient.
• This patient is not in the system.
It is clear that the clinical risks are significantly different for each of the selected responses.
If this example seems too far-fetched to you, then there are several ways to negate the result in HL7v3: using the NullFlavor, using the negationInd attribute and using the SNOMED CT code. As it is easy to notice, it is very easy to construct a negation negation construct. Or another case, when the machine-readable code uses NullFlavor, and the human-readable part (element originalText) carries some information. What to choose in this case?
Process compatibility
I will try to explain this type of compatibility in the following, again, a hypothetical example, although someone may say that it also relates to semantic compatibility, which, in part, it is. Suppose a malicious smoker was offered to complete a smoking cessation program (smoking cessation) and the following provisions need to be coded: the smoker could not complete the program due to its closure . Well, it's easier than that, someone will say, take SNOMED CT and find the necessary code. The term search - smoking cessation - returns more than 20 results, this does not include local dictionaries. Moreover, the terms refer to different branches, i.e. we can not say that if the code is in the range from ... to ..., then probably it is about smoking cessation. That is, if clinics do not agree in advance on which term to use to refer to a particular concept, then compliance may not occur, despite overcoming the first two levels of compatibility.
In one of the previous articles, I wrote that the customer, and often the direct developer, is often unable to assess the complexity of the project with HL7. It is enough to note that only bringing the SNOMED CT dictionary from its 300 thousand concepts to the possibility of real use (significantly reducing the terminology to 5-10 thousand concepts) will take not a week or two. A team of experts can spend 6 months only for this part of the project easily. And without it, you can’t say that honey systems are compatible.
So that the examples do not seem too far-fetched, take the real picture of the interaction in one of the clinical cases (below):
It is easy to see that compatibility at least on the first two levels should be between all participants in the treatment process.
The three levels presented are not the only possible compatibility levels. For example, the European Interoperability Framework (EIF) adds another layer - Legal Interoperability - which includes data protection and more.
In the conclusion of this short article. Those who first encountered this term and want to learn more, you can try with the book “ Principles of Health Interoperability HL7 and SNOMED ” (Tim Benson). How to search for books in the internet, probably, is not necessary to explain.
For advanced users, we recommend that you subscribe to the listserver - HL7 Electronic Health Record Interoperability Work Group (EHR Interoperability WG) list - on the hl7.org website
Source: https://habr.com/ru/post/256795/
All Articles