I'm presently evaluating the HL7 C-CDA DSTU 2.1 update. I'm doing it by way of updating the DSTU 2.0 sample files to conform to DSTU 2.1. Along the way I've been testing my samples against both the 2.1 specification, and the 1.1 specification which it is to be backwards compatible with.
I have various validation tools for 1.1. There's the Schematron produced by Trifolia, the TTT testing tool used for Meaningful Use, and the SITE Tool, as well as Josh Mandel's SMART CCDA Scorecard, and if I dug around hard enough, I could probably also find an Art Decor based validator.
Each one of these provides overlapping results. Some are more up to date that others with HL7 Errata. I'm still finding bugs with each of these so far.
One of the challenges that we have as an industry is that there is no single authority on what is a valid CCDA. It should be HL7, but since ONC oversees the Certification program, and NIST develops the tools for that program, we have three different validators with slightly different ideas about what is a valid CCDA 1.1 document.
The validators are of varying quality with respect to how they work. The Schematron-based tools are my favorite, simply because those tools are the most transparent about what they are testing. None of the validation tools does a great job of taking me back to the source of truth used, although I can readily go from Conformance identifier back to the related specification.
I guess I'm spoiled by some of the W3C validators I've used, which link me directly to the conformance requirements in the standard. Until we get an HTML version of CCDA, we won't be seeing that. But hopefully that can be something that is produced sooner rather than later.
Keith
I have various validation tools for 1.1. There's the Schematron produced by Trifolia, the TTT testing tool used for Meaningful Use, and the SITE Tool, as well as Josh Mandel's SMART CCDA Scorecard, and if I dug around hard enough, I could probably also find an Art Decor based validator.
Each one of these provides overlapping results. Some are more up to date that others with HL7 Errata. I'm still finding bugs with each of these so far.
One of the challenges that we have as an industry is that there is no single authority on what is a valid CCDA. It should be HL7, but since ONC oversees the Certification program, and NIST develops the tools for that program, we have three different validators with slightly different ideas about what is a valid CCDA 1.1 document.
The validators are of varying quality with respect to how they work. The Schematron-based tools are my favorite, simply because those tools are the most transparent about what they are testing. None of the validation tools does a great job of taking me back to the source of truth used, although I can readily go from Conformance identifier back to the related specification.
I guess I'm spoiled by some of the W3C validators I've used, which link me directly to the conformance requirements in the standard. Until we get an HTML version of CCDA, we won't be seeing that. But hopefully that can be something that is produced sooner rather than later.
Keith
Hi Keith,
ReplyDeleteIHE Services have done some research in the validation strength of the various tools, see my earlier post at http://www.ringholm.com/column/HL7_CDA_Conformance_testing_tools_analysis.htm as well as https://vimeo.com/127800129 (Eric's presentation about the IHE ObjectsChecker toolkit).
In general, as has been documented in this (http://wiki.hl7.org/index.php?title=Software_Implementation_of_CDA) best practices document for years the validation strength of any schematron tool is weak compared to model based validation. Therefore I'd rather use a model based validator such as MDHT or IHE ObjectsChecker rather than any Schematron based validation tool.
I don't know about MDHT, but IHE ObjectsChecker certainly references the source of truth as to why it's producing an error or warning. But then again, IHE ObjectsChecker doesn't contain the C-CDA 2.1 requirements as far as I'm aware.
We urgently need all of these tools to start supporting the Templates DSTU, so we can do a proper comparison of their functionality, and not have 'tool lock-in' which prevents us from moving to a tool that provides a better level of validation.
In the long run I'd urge you to please ditch those schematron, and move to a model based validator.
-Rene
Rene, My preference for Schematron has to do with the transparency of the tests and the ease of use of the tool with XML editors. I will ALSO note that Schematrons are often created based on a model, and are as capable of "Model Based" validation as tools written using ANY other programming language.
Delete