CCR and CCD Translations
The first topic that was heavily debated in the Structured Documents working group meeting was whether or not HL7 should publish transforms between the HL7 CCD format and the ASTM E2369 CCR format and back, and document the limitations of such a transform. Most of the debate was between cochairs, with me on the side of publication, two others adamantly against it, and a third being realtively neutral.
Conceptually, we all agree that the only meaningful way forward (e.g., for 2013) is to communicate clincial information is through the CDA standard and HL7, IHE and HITSP implementation guides based on those. Where we differ is in tactics. Some would have HL7 do nothing to make it easier to use CCR with EHR systems, and others would make it easier to transition between use of CCR and use of CDA. I'm in the second camp. We voted on whether to develop a project to do this and the outcome is that the committee agreed to do so, though not unanimously given the divisions.
Even though I'm not fond of the CCR XML, I must acknowledge that A) It's been regulated as a requirement that applications be able to view them at a very minimum, and B) that regulation is extremely unlikely to change as a result of ANY industry feedback. Having acknowledged that, there are a couple of ways forward. 1) Penalize those who have gone down one path or another, or 2) make it easier to cross between the two. My own thoughts are to take the latter road, because this will make it easier for others to come to HL7 and use CDA. That includes both vendors and healthcare providers. Most of the latter are simply caught in the middle of this debate.
This has the danger that it also enables implementors to go the other direction. I have the same attitude about this concern as I do about the concern that sharing healthcare data could cause a healthcare facility to lose customers. If you believe that providing better service to your customers will enable them to leave you to go elsewhere, you need to look at what you are doing much more closely. However, if you really believe in what you are doing, this can only be to your own advantage.
The industry needs this, and it will be done whether or not HL7 does it. I would prefer to see HL7 take the lead and do it right because it is the appropriate thing to do to serve our constituents. Some feel that this will simply perpetuate the problem of two standards, and those concerns are indeed reasonable. However, HL7 cannot ignore the lessons that CCR had to teach us. Furthermore, we must not ignore the needs of our constituents just because their requirements (imposed from an external body), seem not to be in HL7's best interests tactically. The strategic move is to serve the industry, and by so doing, gain the trust and confidence that will allow that industry to adopt the HL7 CDA standard.
This is the high road, or path less travelled by. It may be more difficult, but to me it seems to be the right direction to go. I may not like having to choose this path, but it will be a better result for patients. I am here not for any one company or organization. I develop healthcare standards for my wife, my children, my mother and anyone else who needs healthcare. If there is something I can do to make sure that they get the right care, I will, and this seems to be it.
Green CDAGreen CDA is good for the environment because it uses fewer electrons. The idea behind Green CDA is that there is a simpler way to exchange CDA documents that meets 80% of the capabilities of CDA, but has a much simpler to understand XML. This is another of the lessons learned from CCR. I can see the point of pain that Green CDA is going after. As someone who has taught CDA to more developers than I can count, and having implemented CDA using numerous implementation guides, I very clearly see the point of pain it is addressing. I agree wholeheartedly that it needs to be addressed. Green CDA is very similar to the hData format developed by MITRE.
There are some limitations in Green CDA as currently proposed that I have some concerns about, and so I propose something just a litte bit different. I'll just introduce this concept below, as it needs more fleshing out.
The μ ITS
Green CDA is simply another Implementation Technology Specification or ITS for use with the CDA standard. The same techniques could readily be applied to any other HL7 Version 3 message or document with similar benefits. I believe that we should approach this as an alternate ITS for HL7 Version 3. I call this the μ ITS because it is close to the New ITS proposes a few years ago in HL7, but takes a slight step backwards. Also the μ ITS takes its name from the synthesis of model of meaning and model of use that I discussed earlier this year. When I told the cochair of the TSC and a past supporter of the New ITS that we needed something like this he was floored because I adamantly and successfully opposed that ITS. I still think the idea is a little bit wonky because I understand the value of communicating meaning vs. use, but I don't see a way around it. I guess it goes to show that I can indeed be educated even though I turn 45 in two days.
It's getting late, and the details of the μ ITS are still rolling around in the back of my head. I'm going to sleep on it and write more about it tomorrow.