David and Michael Thank you both for the excellent clarification.
Best Regards Vishwa On Tue, Nov 10, 2009 at 4:48 AM, David Kibbe <[email protected]> wrote: > Dear Colleagues: As Chair of ASTM E31 Technical Committee on Healthcare > Informatics, the technical committee within ASTM that has developed and > maintained the Continuity of Care Record, CCR, standard, specification > E2369-05, I want to thank Michael Jahn for his explanation below of the > differences between the CCR standard and the HL7 CDA CCD. His description > is basically correct. > > Let me add that I expect both the CCR standard and the CDA CCD will persist > in the marketplace of IT for some time, for a number of reasons. The CCR > standard is fairly plain vanilla XML tagging of summary health content, and > can stand by itself as both a content and messaging standard for web > services that require structured and encoded data elements. In a number of > instances around the world, developers have launched into the CDA CCD only > to find it too complex, and have then used the CCR standard to "learn the > ropes" so to speak, after which the translation to the CDA CCD as necessary > has been much easier and smoother. There are XSLTs and other methods for > this translation available. The content of the CDA CCD is based upon, some > would say borrowed from, the CCR standard. Which is fine. Translation > between the two standards is highly desirable at this early stage of health > data exchange using XML. And the CCR has helped standardize the expected > contents. > > The CDA CCD is a much more complex construct, referential not only to the > conventions of the CDA but also to the RIM, maintained by HL7 as a model for > all health data. It is quite complex, to say the least. But many of the > large HIS and IT firms are comfortable with the CDA CCD, and they may > already use the CDA for transport of other types of documents that are not > structured, e.g. discharge summaries. In turn, there are now people and > entities using the CCR standard as a new and very simple data model, > primarily applicable for ambulatory care and outpatient uses. > > My own personal opinion, while not very relevant here, or at least no more > so than anyone else's, is that simplicity and ease of use is related to high > levels of adoption for any standard. The same is true for familiarity. > Imposing complexity on any business or industry is normally not a very good > idea, and tends to be self-defeating if your goal is to help the standard > along a route to general utility. > > The CCR standard itself is probably more complicated than it needs to be > for 80% of all web services and computable health data exchange of its > elements. It's not surprising that Google Health and others have utilized > only a small subset of the CCR's data objects and elements, a strong > indication of the success of a sparse information model and very typical of > Google's approach to the world in general. > > We are in the process of evaluating when the CCR standard Version 2.0 > should go to ballot, at which time a number of mostly minor changes will be > made based entirely on the recommendations coming from the industry groups > that are using the standard in some production capacity. In other words, > the CCR standard is already responding to its users in a very practical way. > If you would like to be involved in that effort, please contact me and > Steven Waldren, MD. > > One final note: no XML schema is going to solve all of the problems > involved in structured health data exchange. The vocabularies and coding > nightmare = ambiguity, is one such problem that the CCR standard can't fix, > although its users and developers can help to bring some consensus about the > issues of importance with coding systems, e.g. cost of use. > > Kind regards, DCK > > > David C. Kibbe, MD MBA > Senior Advisor, American Academy of Family Physicians > Chair, ASTM International E31Technical Committee on Healthcare Informatics > Principal, The Kibbe Group LLC > ___________ > > 913-205-7968 mobile > ___________ > [email protected] > [email protected] > > CONFIDENTIALITY: This e-mail message (including attachments, if any) is > confidential and is intended only for the addressee. Any unauthorized use or > disclosure is strictly prohibited. Disclosure of this e-mail to anyone other > than the intended addressee does not constitute waiver of privilege. If you > have received this communication in error, please notify me immediately and > delete this. Thank you for your cooperation. This message has not been > encrypted. Special arrangements can be made for encryption upon request. > > > > > > On Nov 9, 2009, at 5:34 PM, Michael Jahn wrote: > > Hi Vhrao, > > ASTM manages CCR. > > Google Health supports a SMALL SUBSET of the CCR specification - Google > Health does not support anything related to CDA, CCD or HL7 - and one might > be thankful of that as it is quite complex and in the domain of EMR system > vendors who sell things starting at $250,000.00 > > Hl7.org <http://hl7.org/> manages CDA > > http://www.hl7.org/ > > CCD (Continuity of Care Document), an ANSI standard approved in 2007, is > built on CDA elements by using a detailed set of constraints. > > HL7’s Clinical Document Architecture (CDA) stores or moves clinical > documents between medical systems. Documents are things like discharge > summaries, progress notes, history and physical reports, prior lab results, > etc. The CDA uses XML for encoding of the documents and breaks down the > document in generic, unnamed, and non-templated sections. > > HL7’s CDA defines a very generic structure for delivering “any document” > between systems. What is missing in the CDA standard proper is a listing of > the sections of that document. That is, a template of the expected sections > that will appear in a given type of document. For example, on a history and > physical document, sections could be named Current Medications, Prior > Immunizations, Social History, etc. > > Ignoring the political or technical motivation, an independent group at the > ASTM was formed and worked to define an XML standard for moving documents > between systems. > > That is what CCR is (some think "was" but I am not going toi get into that > here... > > Initially, this standard was unrelated to HL7’s CDA standard. It is fair to > say the standards competed for mind share and each expressed a different > integration philosophy. > > In later efforts, the two standards groups agreed to effectively make the > standards compatible with each other. The Memorandum of Understanding (MOU) > between HL7 and ASTM says that they will “harmonize” the two competing > standards. That’s a fancy way of saying they will play nicely. > > Some like to describe the CCR as a specialization of the CDA. That is, the > CCR provides a template of the expected sections that will be provided in > CDA format. This CCR “content profile” is a tightly controlled list of > document sections answering the “What major bits of data will be sent?” > question. The CDA, then, is the structure of how the document will be > formatted in XML. > > There are many many issues... > > Some of us are trying to play nice in this complex sandbox with PDF > > http://www.myhealthcarestuff.com/cdapdf.html > > hope this helps > > Michael Jahn > Jahn & Associates > PDF Conversion Specialist > 1824 North Garvin Avenue > Simi Valley > California 93065 > Office: (805) 527 8130 > Cell: (805) 217 6741 > Email: [email protected] > Skype: michaelejahn > Twitter: http://twitter.com/michaelejahn > Blog: http://michaelejahn.blogspot.com/ > > > > > On Mon, Nov 9, 2009 at 1:49 PM, vhrao <[email protected]> wrote: > >> >> I have been reading up on CCR and CCD. I understand that CCR is a >> snapshot medical record at a given point of time and CCD is history of >> medical records. If this is true then in order to send comprehensive >> mdeical data to providers we need CCD. Is this correct? >> I tried to look up a CCD specificaiton and I could not find it. >> >> How does Google health handle history data? >> >> >> >> >> >> > > > > > > > -- Best Regards --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Health Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/googlehealthdevelopers?hl=en -~----------~----~----~----~------~----~------~--~---
