GreenCDA Project

Project Scope

The greenCDA project has developed a pragmatic methodology for creating simplified schemas that can be transformed directly to or from normative CDA.

This page provides a high-level overview of the greenCDA specification which has been officially balloted via HL7.

Full details on the greenCDA methodology can be found via the ballot document references at the bottom of the page.

Releases

Changes to the implementation guide and technical artifacts for the greenCDA balloted package are listed here.

• Version 1.0 - Download
  • Initial ballot package.

What is greenCDA?

greenCDA is a different thing to different people:

• To the CDA designer, it is a document describing a process.
• To an implementer, it is a module/package that is the result of the process described in the document and developed by the CDA designer.

The methodology is tool-neutral, meaning that it does not suggest a specific tool to use when following the process outlined in the document.

Principles of the methodology

GreenCDA instances are delivered in modules. A greenCDA module contains: the greenCDA schema, the transform to normative CDA, and the documentation which describes the business process the greenCDA is capturing.

Module development guiding principles:

1. HL7 datatypes _should_ be used in greenCDA modules to ease the transformation development.

General Process

1. Identify requirements
   1. Dynamic fields (fields that are used to gather user data) are identified and assigned business names.
   2. Hierarchies are flattened to a level that is meaningful to the business application.
   3. Static fields (fields that do not change, such as template IDs, moodCodes and typeCodes) are left out of the requirements, but are documented for the development of the transform.
   4. Cardinality and data types are identified for each field.
2. Develop schema
   1. The requirements are translated into a schema.
   2. The schema is compliant with XML Schema 1.0
   3. The schema is as simple as possible; complex types are only used when absolutely necessary and xsi:type is used absolutely nowhere.
   4. A mechanism for recording the schema version is put in place.
      1. Must be developed in a way that allows the transform to be aware of the version so that the transform may be associated with a specific version of the schema.
3. Develop transform
   1. Requirements from #1 are used to generate a mapping XSLT from the green schema to the normative cda.
   2. Static values, such as template ids, moodCodes and eventCodes are defined in the transform that generates normative cda.
   3. Optionally: a reverse transform from normative cda to a green schema may be created.
4. Test transform
   1. Ensure that each of the data-points in green instances are mapped to valid data-points in normative cda.
   2. If a reverse transform is developed in 3.c., it can be used to perform a round-trip test of green instance to normative and back to green again. When done, the new green instance should be the same as the original green instance.
5. Document schema/transform for implementers
   1. At a minimum, requirements from #1 should be used to develop documentation indicating what green data translates to in normative cda after the transformation.
   2. Green instance values based on conditional logic should be documented. IE: If green/XXX/@value is "YYY" then green/AAA/@value must be one of "bbb" or "ccc" or "ddd".
   3. Value-sets associated with green elements are included or referenced by documentation.

Who

A number of organizations were involved in creating/approving the methodology outlined by greenCDA and have developed green-CDA modules:

• SDWG (Structured Documents Working Group) - The HL7 working group that developed greenCDA.
• HL7 (Health Level 7) - Approved the project scope and managed the ballot process.
• Lantana Consulting Group - Developed the ballot document and the example technical artifacts that accompany the release of the document.
• ITS(Implementable Technology Specifications)
• MITRE - hData project is an initiative from the vendor community to simplify the document and technical architectures related to CDA. MITRE has provisionally accepted greenCDA as its format for CDA documents, setting aside its earlier goal of defining an XML format to replace CDA.

Module Contributions

HL7 and the SDWG would like to encourage sharing of greenCDA modules which have been developed in the greater community. The group foresees the development of a registry where greenCDA modules would be documented and made available for wider distribution.

References

Publications

• Introducing greenCDA (Geek Doctor, John Halamka)
• Robert Worden's MU ITS Prototype
• HIMSS11: greenCDA and greenCCD PDF (Lantana Group)

Known Issues

greenC32

• Narrative generation creating incorrect table rows.
• legalAuthenticator needs to be added to model and transform.