HL7 CDA R2 Development Tools Testing
This short article is my free translation of a post on the Rene Spronk blog on “ Analysis of CDA R2 testing tools — most of the requirements are not tested nor respected ” [1], which itself is based on the presentation made during the IHIC (International HL7 Interoperability Conference ) in Prague in early 2015. [2]
Ps. Links to videos and other materials at the end of the article.
During the conference, a very interesting and important topic of validation was touched on both the CDA document and not very numerous CDA development tools. As far as they correspond or do not correspond to the standard.
')
Rene identifies the following 4-step validation steps of the CDA document, which also corresponds to the main steps of the validation of HL7v3 messages (where I will probably indicate this), and if the document or message did not validate at some verification step, then it makes no sense to carry out all subsequent Steps.
1. Checking the file for compliance with the XML standard (what is called well-formedness in Altova XMLSpy and similar tools);
2. Check for compliance with the published XML scams of the CDA document or HL7v3 message;
3. Check for compliance with the abstract model HL7 CDA
Here I will make a small digression. Perhaps you know, and maybe you do not know, but the XML schema means are not enough to describe all the possible requirements for a CDA document, as well as for HL7v3 messages. HL7 recommends using MIF (Model Interchange Format) files for this, but not all tools support this format, or rather, not only everyone can support it, few of the development tools can do it.
It seems to be easy to find the MIF corresponding to the CDA, it should be in the folder .. \ processable \ MIF1-Lite under the name POCD_MT000040UV.mif , but it is only present in V3 Ballot Edition. In the final version of the standard, in the Normative Edition, it is not, because the CDA MIF is not normative. The point is that the CDA XML scheme, after generation, is manually doped, and these changes are not reflected in the CDA MIF.
In addition, returning back to step 3, it is advisable to use the Schematron rules at this level of verification. Some of them are already included in the standard, you only need to carefully search. So, in the datatypes-base.xsd schema (located in the .. \ processable \ coreschemas folder), the rules for checking data types are under the namespace sch. Maybe someone will even try to write a small utility that takes a CDA document element (or any v3 message), climbs into the appropriate XML schema to determine the data type of this element according to HL7, since the data type is not always specified using the xsi: type attribute in the document itself, and substitutes Schematron rules for checking this element from datatypes-base.xsd . As far as I understand, using only XPath, this will not work.
4. Check for compliance with the requirements defined in the CDA Implementation Guide, when it is necessary to check the compliance of section templates and records for compliance with the standard.
At this level of verification, at the first stage, it is also recommended to use Schematron rules, similar ones, can be found in the \ templates folder for CCD, however this is not provided for CDA, i.e. have to write your own.
At the second stage for this verification step, there is no way to get away from the “reading” of the document by a person in order to identify errors that are difficult or impossible to encode. For example, the correspondence of data in different parts of the section, etc.
We now return to the blog Rene. He further writes that a conference was presented at the conference on the topic of research to what extent the existing CDA development tools correspond to the third step of verification. The authors (Abderrazek Boufahja, Eric Poiseau, Guillaume Thomazon, and Anne-Gaëlle Bergé) identified 160 requirements that any CDA document must meet. These requirements are published under the name “ HL7 CDA R2 Basic Requirements ”. [3]
The following CDA development and / or verification tools were analyzed: Trifolia, MDHT, Eclipse Instance Editor, Art-Decor, NIST validation tool, and IHE Gazelle ObjectsChecker. The authors did not know about the MARC-HI Everest Framework at the time when the verification criteria were compiled. Rene does not report anything about Mirth CDAPI, apparently the authors and he himself also do not know about him. Although this tool is built around MDHT, so it can be considered that it is subject to the same errors.
The results of the verification of the development and verification tools themselves were as follows:
• IHE Gazelle ObjectsChecker can be said to have found all the erroneous criteria out of 160, the authors refer to the fact that they took into account their own research in this framework.
• Of the remaining, the old Eclipse Instance Editor, which has not been updated since 2011, turned out to be the best in searching for errors.
• Trifolia and Art-Decor, by definition, are not sharpened to conduct an inspection according to the third step, they are more oriented to the fourth step, namely, to check the templates (and that’s the CDA for the CDA, which may not have pre-defined templates).
• The remaining two, the MDHT and NIST validation tool, still have room for development.
The authors also checked 153 CDA documents from different countries (national projects).
It turned out that the number of errors in them ranges from 2 to 44. Further, Rene remarks that the errors in the documents actually repeat published earlier in 2008 in the blog “ Common issues found in the HL7 Clinical Document Architecture (CDA) ” [4] that it proves once again that checking only for compliance with the CDA XML schema is not enough to ensure the validity of the CDA document and it is necessary to move the bar to the 4th step of validation. I'd add that the same applies to HL7v3 messages.
[1] www.ringholm.com/column/HL7_CDA_Conformance_testing_tools_analysis.htm
[2] Model-based Analysis of HL7 CDA R2 Conformance and Requirements Coverage - vimeo.com/119524890
[3] gazelle.ihe.net/cda/cda-basic-req.pdf
[4] www.ringholm.com/docs/03020_en_HL7_CDA_common_issues_error.htm
Ps. Links to videos and other materials at the end of the article.
During the conference, a very interesting and important topic of validation was touched on both the CDA document and not very numerous CDA development tools. As far as they correspond or do not correspond to the standard.
')
Rene identifies the following 4-step validation steps of the CDA document, which also corresponds to the main steps of the validation of HL7v3 messages (where I will probably indicate this), and if the document or message did not validate at some verification step, then it makes no sense to carry out all subsequent Steps.
1. Checking the file for compliance with the XML standard (what is called well-formedness in Altova XMLSpy and similar tools);
2. Check for compliance with the published XML scams of the CDA document or HL7v3 message;
3. Check for compliance with the abstract model HL7 CDA
Here I will make a small digression. Perhaps you know, and maybe you do not know, but the XML schema means are not enough to describe all the possible requirements for a CDA document, as well as for HL7v3 messages. HL7 recommends using MIF (Model Interchange Format) files for this, but not all tools support this format, or rather, not only everyone can support it, few of the development tools can do it.
It seems to be easy to find the MIF corresponding to the CDA, it should be in the folder .. \ processable \ MIF1-Lite under the name POCD_MT000040UV.mif , but it is only present in V3 Ballot Edition. In the final version of the standard, in the Normative Edition, it is not, because the CDA MIF is not normative. The point is that the CDA XML scheme, after generation, is manually doped, and these changes are not reflected in the CDA MIF.
In addition, returning back to step 3, it is advisable to use the Schematron rules at this level of verification. Some of them are already included in the standard, you only need to carefully search. So, in the datatypes-base.xsd schema (located in the .. \ processable \ coreschemas folder), the rules for checking data types are under the namespace sch. Maybe someone will even try to write a small utility that takes a CDA document element (or any v3 message), climbs into the appropriate XML schema to determine the data type of this element according to HL7, since the data type is not always specified using the xsi: type attribute in the document itself, and substitutes Schematron rules for checking this element from datatypes-base.xsd . As far as I understand, using only XPath, this will not work.
4. Check for compliance with the requirements defined in the CDA Implementation Guide, when it is necessary to check the compliance of section templates and records for compliance with the standard.
At this level of verification, at the first stage, it is also recommended to use Schematron rules, similar ones, can be found in the \ templates folder for CCD, however this is not provided for CDA, i.e. have to write your own.
At the second stage for this verification step, there is no way to get away from the “reading” of the document by a person in order to identify errors that are difficult or impossible to encode. For example, the correspondence of data in different parts of the section, etc.
We now return to the blog Rene. He further writes that a conference was presented at the conference on the topic of research to what extent the existing CDA development tools correspond to the third step of verification. The authors (Abderrazek Boufahja, Eric Poiseau, Guillaume Thomazon, and Anne-Gaëlle Bergé) identified 160 requirements that any CDA document must meet. These requirements are published under the name “ HL7 CDA R2 Basic Requirements ”. [3]
The following CDA development and / or verification tools were analyzed: Trifolia, MDHT, Eclipse Instance Editor, Art-Decor, NIST validation tool, and IHE Gazelle ObjectsChecker. The authors did not know about the MARC-HI Everest Framework at the time when the verification criteria were compiled. Rene does not report anything about Mirth CDAPI, apparently the authors and he himself also do not know about him. Although this tool is built around MDHT, so it can be considered that it is subject to the same errors.
The results of the verification of the development and verification tools themselves were as follows:
• IHE Gazelle ObjectsChecker can be said to have found all the erroneous criteria out of 160, the authors refer to the fact that they took into account their own research in this framework.
• Of the remaining, the old Eclipse Instance Editor, which has not been updated since 2011, turned out to be the best in searching for errors.
• Trifolia and Art-Decor, by definition, are not sharpened to conduct an inspection according to the third step, they are more oriented to the fourth step, namely, to check the templates (and that’s the CDA for the CDA, which may not have pre-defined templates).
• The remaining two, the MDHT and NIST validation tool, still have room for development.
The authors also checked 153 CDA documents from different countries (national projects).
It turned out that the number of errors in them ranges from 2 to 44. Further, Rene remarks that the errors in the documents actually repeat published earlier in 2008 in the blog “ Common issues found in the HL7 Clinical Document Architecture (CDA) ” [4] that it proves once again that checking only for compliance with the CDA XML schema is not enough to ensure the validity of the CDA document and it is necessary to move the bar to the 4th step of validation. I'd add that the same applies to HL7v3 messages.
[1] www.ringholm.com/column/HL7_CDA_Conformance_testing_tools_analysis.htm
[2] Model-based Analysis of HL7 CDA R2 Conformance and Requirements Coverage - vimeo.com/119524890
[3] gazelle.ihe.net/cda/cda-basic-req.pdf
[4] www.ringholm.com/docs/03020_en_HL7_CDA_common_issues_error.htm
Source: https://habr.com/ru/post/257017/
All Articles