======================================= Readme - MDS 20090119 --------------------------------------- These materials were prepared by Alschuler Associates, LLC, under the auspices of the office of the Department of Health and Human Services, Assistant Secretary for Planning and Evaluation (ASPE). For information on the transformations, to report bugs and to address queries, please contact Project Manager, Michelle Dougherty, Michelle.Dougherty@AHIMA.org. ======================================= This package includes four processes. Three are file-transformation processes; the fourth validates an MDS CDA file. All use an XSLT transform. This readme explains: - the four processes - how to run an XSLT transform - what to look for in the validation result For a graphical view of three file-transformation processes, see the included file mds_cda_process_flow.gif --------------------------------------- File list --------------------------------------- readme README.txt mds_cda_process_flow.gif cda2html.xsl cda2mds.xsl entries2cda.xsl mds_as_entries.xml mds_cda.xml mds_html_from_cda.html mds_voc.xml mds_xml_from_cda.xml schematron.sch schematron.xsl --------------------------------------- The four processes --------------------------------------- 1. Turn coded CDA entries into a full CDA document A CDA section has a narrative block (the "text" element before the coded entries). In the expected usage scenario, the input file lacks narrative blocks but otherwise conforms to the MDS Implementation Guide. This transform creates each section's narrative block from its coded entries. It uses the vocabulary listings ("voc.xml") to find display text for codes. If run on a CDA MDS file that already contains narrative blocks, this transform regenerates the narrative blocks from the coded entries. Input mds_as_entries.xml Processing entries2cda.xsl transform to add narrative block mds_voc.xml vocabulary listings Output mds_cda.xml MDS CDA (the CDA document) 2. Validate MDS CDA An MDS CDA file should obey the constraints on CDA that are stated in the MDS Implementation Guide. Checking whether an XML file meets its constraints is called validation. An application of XSLT called Schematron is a tool for expressing such constraints in a computable way. The file schematron.xsl expresses the MDS constraints. (The schematron.sch file is the source for schematron.xsl and is included for developers who have an existing Schematron installation.) To validate an MDS CDA file against these constraints, run schematron.xsl as an XSLT transform: Input mds_cda.xml (the output of process #1) Processing schematron.xsl checks the MDS IG constraints mds_voc.xml vocabulary listings Output validation.xml the validation report 3. Turn CDA document into HTML / Display CDA document in browser The narrative block is the source for what a browser displays. This transform converts the narrative block into HTML for display. The CDA document includes a call to this transform: an end-user just opens the CDA document in a browser. Input mds_cda.xml (the output of process #1) Processing cda2html.xsl transform MDS CDA to HTML / show it in a browser Output mds_html_from_cda.html HTML view (as seen in browser) 4. Turn CDA document into MDS XML The MDS XML format is specified by CMS. This transform converts the MDS CDA file to that format. Input mds_cda.xml (the output of process #1) Processing cda2mds.xsl transform MDS CDA to MDS XML Output mds_xml_from_cda.xml MDS XML produced from CDA document --------------------------------------- How to run an XSLT transform --------------------------------------- To run an XSLT transformation, you need: - a stand-alone XSLT transformation engine such as saxon or xalan, or a development environment with an XSLT engine and - an input file - a transformation specification - an output filename or a handoff to a target application Here is a sample command line using the saxon (java) XSLT engine run as a stand-alone application: java -jar c:\mlofc\saxon\saxon.jar -o mds_cda.xml mds_as_entries.xml entries2cda.xsl ^ ^ ^ | | | output file ------------------------------| | | | | input file --------------------------------------------| | | XSLT transform ------------------------------------------------------------| In this form, the command lines for the four processes in this package, using the sample filenames, are -- 1. Turn MDS entries into full CDA java -jar c:\mlofc\saxon\saxon.jar -o mds_cda.xml mds_as_entries.xml entries2cda.xsl 2. Validate the MDS CDA XML java -jar c:\mlofc\saxon\saxon.jar -o validation.xml mds_cda.xml schematron.xsl 3. Turn CDA into HTML java -jar c:\mlofc\saxon\saxon.jar -o mds_html_from_cda.htm mds_cda.xml cda2html.xsl 4. Turn CDA into MDS XML java -jar c:\mlofc\saxon\saxon.jar -o mds_xml_from_cda.xml mds_cda.xml cda2mds.xsl --------------------------------------- What to look for in validation results --------------------------------------- The validation result file reports on all the tests applied, whether passed or failed. To find the report of a test that was not passed, look for the element . Example: test="count(cda:entry)>0" CONF-QA-18:Questionnaire assessment sections SHALL have at least one entry for each question/answer on the form. -- failed-assert/@location where in the CDA document the test failed (in this example, the 18th top-level section) -- failed-assert/@test the coded form of the test -- failed-asert/text the conformance statement that was being tested ======================================= END =======================================