CDA 2012 Content Testing Tools

Date	File	Comments
Jan 12, 2011	pcc-content-2011-01-12.zip	Script error in previous release. We were missing the QRPH documents.

IHE CDA content tests are written with the following assumptions:

1. The PCC content profiles are written using a library of modules that are shared across document types.
2. We can ask Content Creators to place specific content in a document section. This is akin to a physician wanting to enter his/her written comments into a system. This is especially true for the modules that are text based.
   1. There are some cases where we ask the creator to enter specific text. The implementation might have a pick list for that element that matches the intended use. If the pick list does not have the exact text, we will accept what is produced by the system.
   2. If the tests ask for an allergy to penicillin and the system can only indicate "Allergies: Yes/No", we would consider that a failure. If the system has an encoded mechanism for expressing this allergy with appropriate text that is reasonable to a clinician, we would accept that.
   3. This is a contrived example. The monitors will understand.
3. We can reuse content modules in the various documents. Because this is for testing only, some of the medical history might not make much sense. We only have to be careful that a real EHR/EMR that one is testing does not have alerts or other software that would preclude our contrived examples. If we find those, we will rework the data requirements.

The content tests are written with this process:

1. A master XML document (not CDA) is written that has the content for each module to be tested.
2. For each document type (EDR, APS, XPHR Extract, ...), we write a style sheet that takes the master XML document and produces the appropriate document type.
   1. This step gives us a lot of reuse for modules shared across document types.
3. Another set of style sheets are used that produce further xsl files with the expected values for each content module. There are many of these xsl files, each one at the level of a content module.
4. For each document type (EDR, APS, XPHR Extract, ...), there is a Content Test XSLT. This stylesheet takes as input the document produced by a Document Creator and uses the many content module xsl files described above. The output of this XSLT is an HTML file that is a list of tables. The tables list the values expected by the test plan (in blue) and the values supplied by the test document (your document) in red.
5. The monitor will quickly scan the output HTML and look for differences.
6. If I was smarter and had more time, I would have written schematron or XSL that would only show when things do not match. (Next year).

You can try this yourself. The file pcc-content.zip contains the files needed to run the content tests.

For users with OxygenXML version 12

1. Unzip pcc-content.zip, preserving folders
2. Open the Oxygen project NA2011_CDA_Evaluation. You open projects by selecting on the Project menu item, not File. This will give you a set of XSL's.
3. Open the file for_evaluation/EHR_ACME_XDSMSDischarge.xml. This is an example we provide and shows where we expect the monitors to place samples for validation.
4. Use the wrench tool on Oxygen to select an XSL transform. Select the one named XDSMSDischarge. On that popup screen, you can select the transform and then execute "Transform Now"
5. You should get an HTML page that pops up with the evaluation result. This is something a monitor will have to inspect. It is not automated.
6. If for some reason the HTML file does not pop up in a web browser, look in the folder html-eval.

For users without OxygenXML or a lower version w/o projects

1. Unzip pcc-content.zip, preserving folders
2. Open the file for_evaluation/EHR_ACME_XDSMSDischarge.xml. This is an example we provide and shows where we expect the monitors to place samples for validation.
3. This is where you have to do something with your XML editor.
   1. You will find an XSL file in xsl-eval/xdsmsreferral_eval.xsl
   2. Apply that XSL file to for_evaluation/EHR_ACME_XDSMSDischarge.xml
   3. The output (stored to a file, opened in a web browser, played on your MP3 player) is HTML with the evaluation output.

Connectathon Testing will be performed using these tools as well as the NIST validation tools. These content validation tools (described here, not the NIST tools) are not perfect, but they are an improvement over last year.