Whose greenCDA anyway

Recently within and outside HL7, there is great debate and discussion with regard to the role and position of greenCDA - whether greenCDA should be used as normative wire format. The context of discussion is from the blog post greenCDA over the wire by Dr John D. Halamka which I initiated the discussion within HL7 group.

Back in Feb 2011, I was also involved in the discussion, HL7 structured document working group stated that greenCDA is a simplified process to produce CDA, greenCDA is not intended to be normative standards as wire format for data exchange. Though greenCDA also produces XML schema, however the greenCDA XML schema is to be treated as XML API by application internally, for example you can use JAXB (Java to XML Binding) to generate Java classes from greenCDA XML schema.

So What's my opinion and position w.r.t greenCDA? Two main points

1) I agree that greenCDA is only a process, a 'green' approach to produce CDA on the wire, it is NOT meant for normative standard for the wire format. Why can't? What's the implication? I will explain it in greater detail below.

2) I also agree that there is a need to simplify CDA wire format to some extent, but the simplification of CDA wire format is completely different from greenCDA. greenCDA may provide some direction and suggestion on how to simplify CDA, but greenCDA is NOT the answer. I will probably provide another post in the future to talk about this topic.

Before I explain my reasons, let me first quickly run through some key concepts of greenCDA. Below figure is the overall greenCDA design process, it uses CDA as basis to create user-friendly XML schema whose element name and cardinality follows the business requirements, and at the same time produces XSLT which is used at run time to transform greenCDA XML document to CDA XML document. Note, currently the tooling is not fully ready yet, most of them are done manually.



Source: greenCDA - an Implementation Methodology for CDA, Release 1

Below figure illustrates the run time process illustrating how these design artifacts are used at run time.



Source: greenCDA - an Implementation Methodology for CDA, Release 1

Now lets use a concrete example, how to translate HITSP spec to greenCDA XML schema. On the top left corner, it shows the spec of HITSP C83 (CDA Content Module) which specifies the data elements and the mapping to CDA. At bottom right corner, the implementer defines a greenCDA XML schema with element name from HITSP specification.



Source: greenCDA - an Implementation Methodology for CDA, Release 1


Having explained the key concepts of greenCDA, now we can see the potential downstream issues and implications for using greenCDA over the wire.

1) greenCDA is not stable XML schema even for the same use case, and there are many greenCDA XML Schema for the same use case within different projects, e.g for exchanging lab result in different projects or different countries since the XML scheme element is named after the data element name in the requirement specification. For example you may name the element name as "adverseEventDate", I may decide to name the element as "adverseOnsetDate" and with additional timing related data elements for allergy, as a result each project will end up having different XML schema for exchanging allergy information.

2) When two independent greenCDA systems need to exchange information, we will end up with two approaches, either a) modify the existing greenCDA schema for these two systems, which will of course affect the existing systems which are exchanging data with them, or b) either of them implements the transformation bidirectionally. The cost of first approach is high (for some explanation, please refer to my another post - intended use vs actual use of CDA), the cost of second approach is also high, may be not as high as the first approach initially, but the long term the implication of second approach is eventually there are tons of point-to-point integration, so the overall cost of both approaches is very high. If that's the case, what's the benefits at all in adopting greenCDA as wire format, the goal of adopting standardized wire format is to reduce the overall cost, and make the system more adaptive.

Why stable XML schema is important for reducing the overall software system cost? From software architecture's perspective, this will ensure system more extensible and resilient - That's the essence of adaptive architecture (Another blog topic for me in the future so that you will have better understanding)

3) Thirdly, if everyone adopts greenCDA as wire format, eventually everyone will define his/her own XML schema, and he/she can claim whatever greenCDA he/she produced conforms to CDA XML schema. Any XML document can be transformed to full CDA schema technically, with this capability, people will create his/her own whatever XML schema for their data exchange requirement, and the transformation to CDA or whatever XML schema can be done later when there is a need since it always be able to transform back to CDA schema. This in fact re-enforce the danger of trying to use greenCDA as wire format as detailed in the above point.


Does that mean you can't use greenCDA XML schema as wire format, yes it can be used as wire format technically. But just be aware of the above implementations I highlighted, and be aware that whatever your greenCDA or anyone's greenCDA will not become normative standards at all if one of your project goal is to pursue standards conformance.