Hi all, My, it is refreshing to read that there are others on this list who are not simply Google API cowboys !
If I could be so bold - I suggest we set aside any discussion as to if Google Health, or any other online PHR needs anything more than the current subset of the CCR that is currently supported by Google. I really do not think Google Engineers can do much about that anyway. Personally, I think what Google Health supports today is sufficient. We have what we have, and lets be thankful for that. We need it to become widely used and wildly popular in order to get Google to provide us better tools for Google Health, and that will only work if we can make it easier to use. They idea that I would have to get my details and type them in is a non-starter. We need a simple method that is easy to implement that enables a physician to upload a partial record, like 'todays encounter" Months ago, I tried to design a usecase for a homecare health patient encounter, where a fictitious physician was to update a patients Google Health record. This seems to me to have been a very simple process, but I am stalled. I have a PDF file that can export a CCR file file. I have a system set up that enables a user to use a paper form and an Anoto pen and then convert that into a CCR XML file Anyone who might help me at slide 21 http://www.myhealthcarestuff.com/presentation.html If you are unfamiliar with the Anoto pen; http://www.myhealthcarestuff.com/anoto.html Thank you for your time ! 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 Wed, Nov 11, 2009 at 5:56 AM, David Kibbe <[email protected]> wrote: > Nathan: You're very welcome. In fact, the CCR standard has seen much > faster adoption that the CDA CCD, but the latter has received a lot more > press due to political pressure from HL7 and HIMSS, etc. The world isn't > always the way it appears, even on the Internet! > > However, we are better off as a development community in 2009-10 with these > two very different standards in play at the same time, and I'm quite sure > that both will improve from the 'competition' that has been stirred up. > > 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 10, 2009, at 2:55 PM, Nathan wrote: > > > Yes, I would like to also extend thanks to Michael and David for their > insightful overview. > > This is one of the better discussions on the use/purpose of the CCR as > it relates to developers that I have found and actually provides me > with a bit more confidence in having adopted it for use in our own > start-up project. > > As noted we did not need an overly complex data model for the health > information we are seeking to exchange, but at the same time I've been > concerned about limiting the scope of exchange opportunities due to > what seems like low adoption of the CCR standard as compared to the > CCD. So it is good to hear that there are active efforts in moving the > standard forward and working out the details of integrating with the > CCD. > > Best regards, > > Nathan Botts > HealthATM, Inc. > > On Nov 10, 2: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 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? > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
