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 - HL7 Bookstore Download
  • Initial publication.

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 greenCDA 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.
• Results in C32 are supposed to conform to the Simple Observation template specified in the IHE PCC. It appears effectiveTime should be a single value (the time the observation was made). It should not be a time range. NIST has interpreted this template in the same way and has written its Schematron rules to check for a single value (or nullFlavor). It does not look for a time range. However, greenCDA for C32 uses a time range in the effectiveTime element. It should be changed just to a simple date time.
• Same as above comment (time range versus simple date time) for Vital Signs.
• On medications, there is a tag called "indicateMedicationStartStop". It is represented as a time range, so you can do things like center time and width. It seems like it would easier to have separate start and stop time tags that are just dates.
• It may be useful to use restrictions when small code sets are involved. An example of this is type of medication. In greenCDA for C32, it is a fully open coded value. But per the C32 spec, you can only use two values: 329505003 (over the counter) or 73639000 (prescription), both from SNOMED-CT. Why not come up with a type in XML that fixes the code system to SNOMED and restricts the value to those two? XML tools will pick up on this and give users additional help when creating these documents.