Yea, just convert it all into PDF (by the specialist of course) and let people read through hundreds of pages of stuff faxed directly to Google. I'm sure they have an image search engine soon that allows you to find and interpret all the abnormal test results. :)
Talking about this bank record analogy, I don't need excel either, just fax me my account statement. Google will soon have an image search engine that keeps my accounts balanced. Ha, sorry, couldn't resist. CDA isn't hard. And neither is the HL7 RIM. What is it that you don't understand? -Gunther PS: How many people are actually using this Google health thing now? Michael Jahn wrote: > Hi Juggy, > > I do not need Google Health to consume a lab report as a CDA. > > The last time I was asked to go and get blood drwn and analyzed, the > report came to him as a Fax - that fax certainly did not need to be > converted into a CDA 'anything'. > > Even if they sent an email - or *gasp* - an CRR data file - it could > today be uploaded to my Google health record under the "Test Results" > section > > I am simply asking "what else do i need that is not there already" ? > > - I am not interested in listening to dictated clinical summaries. > > The plumbing is NOT right (in that few have a method to pass data in the > first place) but I don't 'need' HL7 or CDA to get the bits I am > interested in. > > > 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] <mailto:[email protected]> > Skype: michaelejahn > Twitter: http://twitter.com/michaelejahn > Blog: http://michaelejahn.blogspot.com/ > > > > > On Wed, Nov 11, 2009 at 4:57 PM, Juggy Jagannathan <[email protected] > <mailto:[email protected]>> wrote: > > With all due respect, I completely disagree with the position that > we DON'T need to support HL7 CDA. You all are complaining that there > is no uptake of the PHR. What value is a PHR for a patient, if the > PHR does not have any or most of the information about him or her > stored in the variety of EHR systems? You talk about having labs. > Lab results are available in a HL7 format. There are tons of > dictated reports (600 million of them) about patient clinical > condition - they will all be soon available in CDA format. Why not > get that information over to a PHR? > > Only when the PHR, has ALL the content of an EHR, will you see the > true vision of a Personal Health Bank. It might even obviate the > need for all the RHIOs! The patient collects and maintains his own > EHR and shares it with which ever care giver he needs to see. Once > the detailed technical information is available, there will be > hundreds of service providers who will provide all kinds of > solutions to automatically interpret that information to the end > user in terms understandable to them. > > Get the plumbing right and you will reap all kinds of rewards. > > My two cents. > > - regards > - juggy > V. "Juggy" Jagannathan, Ph.D. > VP of Research > MedQuist, Inc. > Adjunct Associate Professor of Computer Science > West Virginia University > > > > > > On Wed, Nov 11, 2009 at 4:37 PM, David Kibbe <[email protected] > <mailto:[email protected]>> wrote: > > Michael: I think you concatenated my emails with those of > someone else: I would never complain that we need HL7 and the > CDA CCD at Google Health. I think the CCR standard is good > enough. ; ) > However, I do thank you for your candid responses to my > questions regarding easy(er) health data entry at the point of > care to produce an XML summary file, e.g. a Continuity of Care > Record. > > I am very much thinking about the patient, as well as about the > doctor. The patient needs his or her health information in > summary file format, and his/her personal physician is the ideal > individual to provide that under many circumstances. We > shouldn't need complex EMRs to do this. And you're right, most > physicians aren't particularly interested in, and don't get paid > for, generating this summary health information in human- and > machine-readable format. > > So, I'm simply picking your brain for ideas about how this might > be done in a modular way, an inexpensive way using familiar > desktop and webtop tools and formats.....perhaps the cultural, > social, and economic incentives will arise. After all, there > was a time when no bank would provide me with my financial data. > Not so many years ago. > > Again, thanks so much for your thoughts on this topic. > > 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] <mailto:[email protected]> > [email protected] <mailto:[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 11, 2009, at 4:10 PM, Michael Jahn wrote: > >> Hi Dr. David, >> >> Is it okay to go off on a wee bit of a rant (please, not >> directed at YOU personally !) >> >> Like I decided to leave a bank years back when they did not >> offer ATM cards or online banking services, so I would "like" >> to leave my current medical service provider because they have >> not enabled me to access my PHR, or do not posses the ability >> to upload my PHR data to my Google Health record. >> >> This is why we are stuck in the doldrums, it has nothing to do >> with technology, file formats, etc...this is a pure issue of >> ecosystem, in that there is no ecosystem to grow PHRs in. >> Without an incentive, no one moves. >> >> I feel that needed to be said. As evidence, I offer this >> simple URL link to a page where I have complied the many many >> PHR systems that are - in my view - simply twisting in the >> wind and being largely ignored. >> >> http://www.myhealthcarestuff.com/phr_list.html >> >> unlike banks who saw the benefits of online banking, >> physicians simply do not yet see the benefits of PHRs. Perhaps >> this is one of the things Obamas stimulus package is about, >> but if it is, someone need to put on their marketing hat on (I >> will not be holding my breath) >> >> So, to that point, we should consider Occams Razor >> <http://en.wikipedia.org/wiki/Occam%27s_razor> - why do we >> need anything more than CCR for Google Health - what does CCD >> do so much better or differently that would help Google Health >> ? What is broken that CCD fixes ? If you have something to >> injects or consumes CCR, it is XML - you can always build a >> converter. I fail to see anything that CCD brings to the party >> that would make Google Health suddenly widely adopted or >> wildly popular - this is NOT about how, this is ALL about why. >> >> Okay, that should take care of the first paragraph (smile) >> >> I will be happy to answer your questions, but I think it is >> only fair to share my tao. >> >> I am a product launch marketing type - please know that! >> >> I am not an MD, I am not a coder, I am a technology evangelist >> who is often a hired gun trying to convince you to change what >> you are doing...so, bear that in mind as you read my answers ! >> >> I have a degree in Biomedical Communications, which was a >> fancy name for a program for medical Illustrators that was >> invented to appease the folks at the AMI --> http://www.ami.org/ >> >> So, there, now you know who I am and that might help explain >> why I care. >> >> Kibbe - Would developers like yourself be able to offer PDF >> forms capable of collecting and transporting these data in CCR >> standard, with tools that are inexpensive and easy to use? >> >> Jahn - Anyone can make a PDF Form - you simply need to by >> Acrobat Standard or Professional. Creating a PDF form that >> uses a schema requires would require using Adobe LiveCycle and >> an understanding of how to use a schema, but you already new >> that (since you have Dr. Waldren on staff) >> >> Once a form is made, one can use the free version of Adobe >> Acrobat Reader to fill it out and submit it. My hope is that I >> could have the PDF export go directly to a Google health >> record, and had asked Mark Donner at Google to help, but I >> think Google may have other ideas (like Flex / Flash) - so my >> request remains ignored. >> >> Kibbe - Why would or wouldn't other developers take advantage >> of the capabilities of Word and other XML based word >> processing systems to do the same kind of things? >> >> Jahn - because it does not work well. The Microsoft Word >> document format is notorious as poster child for cross >> platform display and print misbehavior. That is death to >> things like forms. The Word file format is designed for >> editing an authoring. There is a reason that the very first >> reliably exchanged digital for was a PDF of the IRS 1040 form >> - that was with Acrobat 3 in 1997. >> >> No marketing or engineering team at Microsoft really invested >> any time or effort on a "portable document format" - that >> "interacts and enables third parties". Microsoft did offer XPS >> as it's "PDF Killer" but it didn't even dent anything. It does >> not support any notion of forms. >> >> >> Kibbe - Could Dragon be used to move data from speech, to >> form, to XML file? >> >> Jahn - yes, people do that, but just like anything, they still >> need someone to listen and then code. >> >> Kibbe - And wouldn't this be attractive to some clinicians as >> a way of quickly gathering the necessary data elements? >> >> Jahn - that's backwards (IMHO) - the patient is the target - >> not the physician ( of course you know, physician are patients >> too sometimes !) - I use it to manage my kids and my mom PHR. >> The Physicans think I have two heads when I ask them to >> update. They have no dog in that fight. Again, like the banks, >> they had no incentive whatsoever in 1985 to 'change' - they >> were forced to when customers left to join other banks who >> offered ATM card and online banking services. >> >> So, that is a marketing persons opinion - would love to hear >> others. >> >> I don't need CCR or CCD or M O U S E any more that I care >> about DICOM or SNOMED, just like I don't care how that >> magnetic strip on the back of my bank card works - I want my >> log-in and password, and I want to see my test results and >> send a message to my moms doctor that her prescription is >> getting low. >> >> So, why bother worrying about wasting Google's time >> complaining that they don't support HL7 - who cares ? My >> physician does not even have an EMR - I think maybe he has >> QuickBooks and some practice management system that helps with >> coding and billing the insurance companies. >> >> >> 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] <mailto:[email protected]> >> Skype: michaelejahn >> Twitter: http://twitter.com/michaelejahn >> Blog: http://michaelejahn.blogspot.com/ >> >> >> >> >> On Wed, Nov 11, 2009 at 8:08 AM, David Kibbe >> <[email protected] <mailto:[email protected]>> wrote: >> >> Michael: This is very cool stuff you're showing us. Let >> me make a couple of assumptions, and then ask a few simple >> questions. >> Let's just suppose that Meaningful Use and HHS >> Certification create a designated data set very similar to >> the Google CCR profile (subset of potential CCR data >> objects and elements); AND that the CCR standard is one of >> the specified standards allowable for formatting and >> transport of such a data set; AND that physicians are >> willing to purchase and use modular "solutions" that allow >> them to collect, store, and transport these data from >> their practices to PHRs like Google Health, other EHRs, etc. >> >> Ok, here are my questions: >> Would developers like yourself be able to offer PDF forms >> capable of collecting and transporting these data in CCR >> standard, with tools that are inexpensive and easy to use? >> Why would or wouldn't other developers take advantage of >> the capabilities of Word and other XML based word >> processing systems to do the same kind of things? >> Could Dragon be used to move data from speech, to form, to >> XML file? And wouldn't this be attractive to some >> clinicians as a way of quickly gathering the necessary >> data elements? >> Etc. >> >> 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] <mailto:[email protected]> >> [email protected] <mailto:[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 11, 2009, at 10:47 AM, Michael Jahn wrote: >> >>> 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] <mailto:[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] <mailto:[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] <mailto:[email protected]> >>> [email protected] <mailto:[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] >>>> <mailto:[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] <mailto:[email protected]> >>>>> [email protected] <mailto:[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] >>>>>> <mailto:[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] <mailto:[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 > -~----------~----~----~----~------~----~------~--~--- > -- Gunther Schadow, M.D., Ph.D. [email protected] Associate Professor Indiana University School of Informatics Regenstrief Institute, Inc. Indiana University School of Medicine tel:1(317)423-5521 http://aurora.regenstrief.org CONFIDENTIALITY NOTICE: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose. If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited. -- 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]. For more options, visit this group at http://groups.google.com/group/googlehealthdevelopers?hl=.
