My last blog post detailed some of the features of Trifolia that help make my life as an information analyst easier. In this post, I discuss the part of the workflow I use to develop an implementation guide (IG) and the templates contained in it.

This part of the workflow starts after the analysis and design of the IG and templates, and at the stage where I’m ready to start creating the templates using Trifolia. Basically, stuff I want to spend as little time on as possible. As you can imagine, if I didn’t have a tool to help me, I’d have to either have a ton of specifications open at all times, or have a considerable photographic memory!

Thankfully, I have Trifolia to rely upon in this part of the process so that I do not need. Just a few of the things that Trifolia takes care of include:

• ensuring the templates I enter into the tool are valid based on the underlying information model (CDA R-MIM in the case of CDA templates)
• prohibiting invalid data types on elements
• automatically generating the correct wording for constraints (and dynamically showing the wording as I build the constraint)
• when binding to value sets or code systems, looking them up based on all or part of the name or OID
• versioning templates and IGs
• automatic generation of XML fragments to represent a template and its constraints
• automatic generation of Schematron for validation

I use the XML editor, oXygen, to create XML documents and test my work. You can use any XML editor that supports Schematron validation.
As I create templates for an IG, I build up a corresponding CDA XML sample file and repeatedly test that file using the Trifolia-generated Schematron. The templates determine what is allowable and required for each template in the XML. These template rules are translated into Schematron which is used to validate that the XML document correctly represents the template.

Trifolia supports the process by generating XML fragments that represent the general constraints. Where single values are bound (hard-coded) to a data element, the XML fragments will be populated with those values. Certain types of constraints will be automatically filled with random data (dates, identifiers, etc.).

In this way, Schematron is a tool for the designer to validate the design. Note that this process is a QA step for the design itself, not a test of the Schematron. The auto-generated Schematron is, by definition, an objective representation of the rules in the database. Discrepancies between the sample and the rules, therefore, call into question the appropriateness of the constraints themselves. If the constraints are modified, the Schematron will reflect those changes when regenerated.

The first, one-off step, is to hand-craft (or, more likely, use an already-existing valid XML sample) the shell of a valid CDA XML sample.

Then, I’m ready to start entering constraints into Trifolia. The following represents the iterative workflow that I use for creating and testing templates:

 

 

The steps are as follows:

1. Trifolia: Enter/modify constraints defining the rules for the templates
2. Trifolia/XML Editor: Work through the template constraints (similar to the way in which an implementer might) and hand-craft an XML fragment in the XML sample file created earlier
3. Trifolia: Automatically generate sample XML, according to the template rules
4. Compare hand-crafted fragment to generated fragment to assess how well the rules capture the intended design
5. Trifolia: Export Schematron and vocabulary file
6. XML Editor: Validate XML using Schematron (and the CDA base Schema)
7. XML Editor: Edit XML to test good/bad scenarios

I’ll explain each one in more detail.

1. Trifolia: Enter/modify constraints defining the rules for the templates
   • Set conformance and cardinality
   • Add single value bindings (hard-coded values)
   • Add value set bindings
   • Change data types
   • etc.

 

 

• Preview the constraints to ensure they accurately represent the concept being modeled

• Save the template

 

2. Trifolia/XML Editor: Work through the template constraints (similar to the way in which an implementer might) and hand-craft an XML fragment in the XML sample file created earlier
   • Looking at each constraint, translate it into XML and enter into XML sample file.This is similar to how an implementer would work through the constraints and code them into their software.

 

3. Trifolia: Automatically generate sample XML, according to the template rules
   • Generate the sample XML
   • Edit generated XML to add any codes/values that the generator can’t fill in (the generator only fills in single value bindings and certain other elements will be filled with random values – e.g. dates, ids, etc.)

 

4. Compare hand-crafted fragment to generated fragment to assess how well the rules capture the intended design
   • Do the rules capture the intended design?
     • Yes – go to next step
     • No – go back to step 1

 

5. Trifolia: Export Schematron and Vocabulary file
   • Export the Schematron for the relevant IG into the same directory as the sample file
   • Export the XML vocabulary file into the same directory as the sample file and Schematron file

 

6. XML Editor: Validate XML using Schematron (and the CDA base Schema)
   • Use your XML editor to run the Schematron (and the CDA base Schema) to validate the XML
   • Does the validation pass?
     • Yes – go to next step
     • No – go back to step 1

 

7. XML Editor: Edit XML to test good/bad scenarios
   • Edit the XML to make sure the Schematron fails where it should (single-value bindings, for instance)

   

   • Does the validation pass/fail as expected?
     • No – go back to step 1
     • You’re finished!

The end result should be a template with all its moving parts in place. As an added bonus, you’ve got valid examples in your template (Trifolia exports these with the IG) and a valid CDA XML sample file to deliver with the IG.