HL7 CDA R2 Development Tools Testing
This short article is my free translation of a Rene Spronk blog post on the topic “ Analysis of CDA R2 testing tools - most requirements are neither tested nor respected ” [1], which itself is based on a presentation made during the IHIC (International HL7 Interoperability Conference ) in Prague at the beginning of 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 of both the CDA document and the not very numerous CDA development tools was discussed. How much they meet or do not meet the standard.
Rene identifies the following 4 steps for validating a CDA document, which also corresponds to the main steps for validating HL7v3 messages (where possible I will indicate this), and if the document or message did not pass validation 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 Altova XMLSpy and similar tools call well-formedness);
2. Check for compliance with published XML schemas of a CDA document or HL7v3 message;
3. Check for compliance with the abstract model HL7 CDA
Here I will make a small digression. Maybe you know, but maybe you don’t, but the XML schema is 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 this.
Finding the MIF corresponding to the CDA seems to be as simple as it should be in the .. \ processable \ MIF1-Lite folder under the name POCD_MT000040UV.mifHowever, it is only present in the V3 Ballot Edition. In the final version of the standard, in the Normative Edition, it is not, since CDA MIF is not normative. The fact is that, after generation, the CDA XML schema is manually updated, and these changes are not reflected in the CDA MIF.
In addition, returning back to step 3, it is advisable to use Schematron rules at this verification level. Some of them are already included in the standard, you just need to carefully search. So, in the datatypes-base.xsd schema(located in the folder .. \ processable \ coreschemas) the rules for checking data types are under the sch namespace. Maybe someone will even try to write a small utility that takes an element of a CDA document (or any v3 message), crawls into the corresponding XML schema to determine the data type of this element according to HL7, because 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 XPath only will not work.
4. Check for compliance with the requirements specified in the CDA Implementation Guide, when it is necessary to check the conformity of section templates and records for compliance with the standard.
At this level of verification, at the first stage it is recommended to also use Schematron rules, similar, which can be found in the \ templates folder for CCD, but this is not provided for CDA, i.e. will have to write your own.
At the second stage, for this verification step, there is no escape from the "proofreading" of a document by a person to identify errors that are difficult or impossible to encode. For example, data matching in different parts of a section, etc.
Now back to the Rene blog. He writes further that at the conference a report was presented on the topic of research to what extent the existing CDA development tools correspond to the third verification step. 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 title “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 MARC-HI Everest Framework at the time of drawing up the verification criteria. Rene doesn’t say anything about Mirth CDAPI, apparently the authors and he himself do not know about him either. Although this tool is built around MDHT, so we can assume that it is subject to the same errors.
The test results of the development and verification tools themselves turned out to be the following:
• IHE Gazelle ObjectsChecker can be said to have found all the erroneous criteria out of 160, the authors refer to the fact that in this framework they took into account their own research.
• Of the remaining ones, the old Eclipse Instance Editor, which has not been updated since 2011, turned out to be the best for troubleshooting.
• Trifolia and Art-Decor, by definition, are not sharpened to carry out checks according to the third step, they are more focused on the fourth step, namely on checking templates (and CDA is for CDA, which may not have predefined templates).
• The remaining two, MDHT and NIST validation tool, have more to develop.
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 notes that the mistakes made in the documents actually repeat the ones published earlier in 2008 on the blog “Common issues found in implementations of the HL7 Clinical Document Architecture (CDA) ”[4] which once again proves that checking only for CDA XML schema compliance is not enough to ensure CDA document validity and you need to move the bar to the 4th validation step. I’ll add from myself 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 of both the CDA document and the not very numerous CDA development tools was discussed. How much they meet or do not meet the standard.
Rene identifies the following 4 steps for validating a CDA document, which also corresponds to the main steps for validating HL7v3 messages (where possible I will indicate this), and if the document or message did not pass validation 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 Altova XMLSpy and similar tools call well-formedness);
2. Check for compliance with published XML schemas of a CDA document or HL7v3 message;
3. Check for compliance with the abstract model HL7 CDA
Here I will make a small digression. Maybe you know, but maybe you don’t, but the XML schema is 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 this.
Finding the MIF corresponding to the CDA seems to be as simple as it should be in the .. \ processable \ MIF1-Lite folder under the name POCD_MT000040UV.mifHowever, it is only present in the V3 Ballot Edition. In the final version of the standard, in the Normative Edition, it is not, since CDA MIF is not normative. The fact is that, after generation, the CDA XML schema is manually updated, and these changes are not reflected in the CDA MIF.
In addition, returning back to step 3, it is advisable to use Schematron rules at this verification level. Some of them are already included in the standard, you just need to carefully search. So, in the datatypes-base.xsd schema(located in the folder .. \ processable \ coreschemas) the rules for checking data types are under the sch namespace. Maybe someone will even try to write a small utility that takes an element of a CDA document (or any v3 message), crawls into the corresponding XML schema to determine the data type of this element according to HL7, because 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 XPath only will not work.
4. Check for compliance with the requirements specified in the CDA Implementation Guide, when it is necessary to check the conformity of section templates and records for compliance with the standard.
At this level of verification, at the first stage it is recommended to also use Schematron rules, similar, which can be found in the \ templates folder for CCD, but this is not provided for CDA, i.e. will have to write your own.
At the second stage, for this verification step, there is no escape from the "proofreading" of a document by a person to identify errors that are difficult or impossible to encode. For example, data matching in different parts of a section, etc.
Now back to the Rene blog. He writes further that at the conference a report was presented on the topic of research to what extent the existing CDA development tools correspond to the third verification step. 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 title “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 MARC-HI Everest Framework at the time of drawing up the verification criteria. Rene doesn’t say anything about Mirth CDAPI, apparently the authors and he himself do not know about him either. Although this tool is built around MDHT, so we can assume that it is subject to the same errors.
The test results of the development and verification tools themselves turned out to be the following:
• IHE Gazelle ObjectsChecker can be said to have found all the erroneous criteria out of 160, the authors refer to the fact that in this framework they took into account their own research.
• Of the remaining ones, the old Eclipse Instance Editor, which has not been updated since 2011, turned out to be the best for troubleshooting.
• Trifolia and Art-Decor, by definition, are not sharpened to carry out checks according to the third step, they are more focused on the fourth step, namely on checking templates (and CDA is for CDA, which may not have predefined templates).
• The remaining two, MDHT and NIST validation tool, have more to develop.
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 notes that the mistakes made in the documents actually repeat the ones published earlier in 2008 on the blog “Common issues found in implementations of the HL7 Clinical Document Architecture (CDA) ”[4] which once again proves that checking only for CDA XML schema compliance is not enough to ensure CDA document validity and you need to move the bar to the 4th validation step. I’ll add from myself 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