Uncategorized

A Self-Fulfilling Prophecy: The Continuity of Care Record Gains Ground As A Standard

Brian KlepperWe live in a time of such great progress in so many arenas that, too often and without a second thought, we take significant advances for granted. But, now and then, we should catalog the steps forward, and then look backward to appreciate how these steps were made possible. They sprung from grand conceptions of possibilities and, then, the persistent focused toil that is required to bring ideas to useful fruition.

We could see this in a relatively quiet announcement this week at HIMSS 09. Microsoft unveiled its Amalga Unified Intelligence System (UIS) 2009, the next generation release of the enterprise data aggregation platform that enables hospitals to unlock patient data stored in a wide range of systems and make it easily accessible to every authorized member of the team inside and beyond the hospital – including the patient – to help them drive real-time improvements in the quality, safety and efficiency of care delivery.”

The announcement was amplified by a New York Times article, earlier this week by Steve Lohr about New York Presbyterian’s collaboration with Microsoft, now beyond the pilot stage, to transfer patient data into consumer-controlled personal health records (PHRs). The article acknowledges that Google, as well as Microsoft, are now actively engaged as well with major health care institutions – Mayo Clinic, Cleveland Clinic, Kaiser Permanente – to automatically move patient data into PHRs.

The facilitating technology in all these efforts is the Continuity of Care Record (CCR) Standard. Here is the Wikipedia entry, cited in the Microsoft announcement, describing the CCR. It is”a patient health summary standard. It is a way to create flexible documents that contain the most relevant and timely core health information about a patient, and to send these electronically from one care giver to another.

Because it is expressed in the standard data interchange language known as XML, a CCR can potentially be created, read and interpreted by any EHR or EMR software application. A CCR can also be exported in other formats, such as PDF and Office Open XML (Microsoft Word 2007 format).”

The creation of a new industry standard is an immense undertaking of breathtaking audacity, vision, skill and hope. It starts from scratch to craft a highly useful, flexible tool that can be easily adopted by developers, who are focused on wide-ranging aspects of common problems.

The CCR Standard was developed by a collaborative – the Massachusetts Medical Society[1] (MMS), the HIMSS (HIMSS), the American Academy of Family Physicians (AAFP), the American Academy of Pediatrics (AAP), and other health informatics vendors – under the auspices of ASTM International, a not-for-profit organization that develops standards for many industries, including avionics, petroleum, and air and water quality. David Kibbe MD, my friend, colleague and often co-author on the Health Care Blog, was a co-developer of the CCR, and serves as the 2008-2010 chair of the E31 Technical Committee on Healthcare Informatics, the leadership group within ASTM that works with
individuals and organizations on the implementation and use of the CCR standard in the US and abroad,

The CCR’s increasing adoption by major players is testament to the soundness of its vision and its utility. It’s advance will allow patient health data to be easily transported from one platform to another, intact and with integrity, so that better decisions can positively impact care, health, and the costs of achieving them.

This is something we can all acknowledge and admire, because it fulfills the common mission – better, more affordable care for better health – that brings us together on this site.

Brian Klepper is a health care analyst based in Atlantic Beach, FL.

Spread the love

23 replies »

  1. Wow! It was so cool having to know this blog site. The information is very useful. Just like KimClement. Please visit KimClement.com because there’s a lot information about prophecy, prophet, and etc.
    Archie

  2. Yeah I agree This blog is so wonderful. Just like Kim Clement Website. He is a self-proclaimed modern day prophet. His diverse and extemporaneous perspective has gained him notoriety that transcends culture, race and religion, placing him onto a world platform. Its mission is to reach the unreachable and touch the untouchable through a message of hope, enrichment and the healing of haunting memories. Check it, I am sure that you will love it.
    Abigail

  3. Wow, that’s great! It’s wonderful that someone made this amazing blog. Please check this another wonderful site that defined “the prophet” for the modern era. This has made his journey unique: a journey that has taken his inspired message to schools and colleges, churches and synagogues, alleyways and prison cells.
    Abigail

  4. Margolit: Sorry, the confusion about “experiment” was mine, not yours! I know we’re on the same page here.
    MD as HELL: You’re right. Any application that physicians use should not be “clickety-click” hundreds of times, and unimaginative. Doesn’t have to be that way at all! DCK

  5. David, I apologize for the misunderstanding. The “experiment” description was referring to the CCR transmission through SureScripts, not the electronic prescriptions. I am intimately familiar with the e-Prescribing process and its daily volumes, including the pros and cons, as “MD as Hell” notes above.
    I do agree that the HITECH money would be better spent on facilitating simple data transfer, as opposed to complex data entry. Whichever existing network is selected for that will have to be seriously tweaked and expanded and the costs are not going to be negligible.
    I would suggest that whoever makes these decisions does not contemplate passing the costs on to physicians, at least not until we verify that such data transfer provides enough value to a doctor that he/she will be inclined to pay for the service.

  6. I have to agree with MD as HELL regarding the reality of office and hospital computer systems. It seems there is a disconnect between the people talking about all the wonderful things these systems can do, and we physicians whose experience with the things in the real world is almost uniformly negative, to neutral at best. Some argue that this is generational, but I don’t think that explains all of the discrepancy. Some of the people with big visions need to visit a hospital or large doctors’ office sometime and see how these things actually work (or don’t).

  7. I don’t care which system is adopted. ePrescribing is tedious and cumbersome. It interferes with my educating and interacting with my patients. It decreases my time efficiency and therefore costs me money. It is not a onetime cost. It is with every patient encounter forever, if I am forced to do it. I do not do it now, although I have tried it.
    BTW, why is everyone wanting to “mandate” or “require” me to do something just to make some centralized system of records work. It is always someone selling a system that wants the gov’t to require me to work it to the detriment of my patient and me.
    My group of 10 docs and 8 PA’s has eight employees just to interact with the present healthcare finance system. How many will I need to interact with all these visions of the future? Sounds like I will need inhouse IT just to stay in business. I definitely will need a scribe to touch the keyboard, unless I am ready to just take it easy and not worry about throughput. In any event, each encounter will definitely cost the patient more, whether through taxes or time or cash or insurance.
    My hosital’s “new” computer system is about as imaginative as the Ford Trimotor. It cost millions. It just got turned on this month. It was an upgrade from the Wright Flier version. It is not going to do any of this.

  8. Margalit: As usual, you ask the smart questions. Surescripts, of course, has a registry for all of the physicians who use their network for e-Prescribing, and knows all of the devices, EHR technologies, at the receiving ends — both pharmacies and doctors offices — because these must “certify” their capability to send and receive the ePrescribing data necessary to do ordering and fulfillment of prescription medications.
    This isn’t an experiment; it’s used millions of times a day to send data back and forth between pharmacies and physicians using health IT for ePrescribing.
    It’s paid for by the pharmacies. Not by the doctors. The pharmacies pay the transactions costs because it is in their business interest to do so, as ePrescribing is much more efficient — fewer telephone calls, faxes, etc. — a delivery process for them.
    Consider this a model for health network exchange of data like that which is in the CCR standard XML file format supported by Google Health, limited to demographics, insurance info, problem list/diagnoses, medications, allergies and alerts, vital signs, and lab results. Not a lot of data, but meaningful data much of the time. Kept current and accurate by a person’s health care team, including nurses, doctors, and pharmacists. Very important to mention that responsibility includes the patient, too.
    Who will pay for the additional costs of the non-pharmacy-related health data exchange? Well, I’d suggest that this is where some of the HITECH money ought to go. Pay for the data to be moved around — by Surescripts, or Navimedix, or Zix, or any of a number of national networks that could certify the exchange process along the lines that Surescripts has done.
    Or, perhaps the health plans and Medicare ought to pay physicians who agree to engage in this health data exchange of a minimal data set, kept accurate and up to date, on every patient with a chronic illness, as they’ve agreed to do for ePrescribing (a simple extension of same payment model). And then the physicians can pay a small amount for “renting” the network services, such that the costs are kept relatively low.
    My argument is that it is much more efficient, and in the long run much easier to implement, a system that pays for the data to be transmitted in CCR format among providers, and between care systems; and to trust that the market will come up with innovative tools and technologies for helping doctors and patients to do this; than it is for the government, or anyone else, to pay for complicated “EHRs” that create new silos of data and which force physicians to click dozens or hundreds of times to document a “visit,” while not creating the data set that could be useful in so many ways outside the four walls of the practice to help manage care!
    I don’t think this is as complicated as we’re made to think it is, and I know that the tools are available now to get it done.
    Kind regards, DCK

  9. David, I wasn’t aware of the SureScripts CCR experiment, but obviously Dr. Oates is. Very nice.
    But as I said above, someone needs to maintain a directory of all EHRs and the physicians associated with each one and expose that directory to every EHR user that may want to send a CCR through. Whether it’s SureScripts or Google, it still needs to be done and it will be much more complicated then sending claims to payers. The issue I have with Google is that the post office does not usually maintain copies of all the letters that it handles. I don’t know what the PBMs do with CCR, but I do know that they do maintain all prescription information from all users of SureScripts. The ideal situation would be for the CCR to be encrypted in transit and decrypted only at its final destination. The network (and the standard) should also allow for ad-hoc requests for CCR.
    I was not doubting that this all can be done, I was just wondering how we pay for this network and how we keep the data private.

  10. Margalit and Randall: There is network already established for transmittal of CCR xml files, and it’s being used today. It’s called Surescripts. Now, before you jump all over me, let me say that there will certainly be other national, certified networks able to connect one EHR with another EHR. I grant you that.
    But consider that CVS MinuteClinic is already sending many thousands of CCR xml files from its EHR via the Surescripts network, where they are either routed electronically to practices in xml format (not many yet) or transformed into PDF and sent electronically or faxed.
    There is no reason that existing national network operators (e.g. NaviMedix, Zix, and Quest, just to mention a few that easily come to mind) couldn’t do the same job. It’s really simply an electronic post office.
    Tell me why people think this is so complicated when many, many billions of claims get routed, and millions of prescription refills get routed, etc. ?
    There is growing real world experience. It’s just not coming very often from the incumbent health care organizations and vendors.
    Cheers. DCK

  11. Right on, Dr. Oates!
    I must admit that I too am guilty of making the assumption that a small set of data may be useful to other physicians (like med & problem lists, some test results, maybe allergies, etc.).
    I am partial to CCR since it is so very simple and straightforward, but how would we use it…. exactly? How does it get from one EHR to another EHR? I know the canned answer is “web services over SSL”. That may work fine for exporting to Google or CMS, but how we do it for two disparate client/server EHRs, each residing in a physician office is unclear to me. It is practically impossible without some elaborate web-services directory. Who’s going to maintain that directory?
    Or maybe we are creating and solidifying a PHR market, which is nothing more than an intermediary for exchanging data between various EHRs. Is that why everybody is hell bent on PHRs and both Google and Microsoft are pushing PHR services, seemingly without any ROI? It could turn into a very lucrative business with all that medical data just sitting there….

  12. Should there be evidence that any proposed approaches to interoperability will actually succeed in the real world before we declare such approaches as required?
    Otherwise, who can determine what approaches to interoperability will prove acceptable to the majority of medical practices?

  13. The CCR is great at what it does. It enables the transfer of a summary. Definition of summary may vary here and there. however it does nothing to add to real semantic interoperability. Short term the CCR is helpful. But the US health information industry has been thinking short term for more than 40 years. There is an interesting advancement posted on another blog http://ascannerbrightly.blogspot.com/2009/04/guest-blog-collective-clinical-wisdom.html that requires some lonng term thinking but will deliver computabillity (real decision support anyone?) and semantic interoperability.
    All the while allowing clinicians to do what they do best and software engineers do what they do best.
    So the question remains, do we continue little steps or make a decision to work towards real, long term solutions?
    –Tim

  14. The CCR is indeed a great workhorse for moving data. You know a standard like this is successful when the purists start complaining that it is being abused — and we hear that about CCR every day. 🙂 The kudos that were the original point of this post are well deserved.
    In particular the CCR authors recognized the need for our industry to “ease into” structure … the format does a great job of encouraging coding and normalization without creating an unrealistic bar — this is a tough tightrope to walk!
    That said, Vince has it spot on — Both formats are important and help to move the ball forward. We come across situations every day where CCD is a better (or sometimes the only) option for some particular problem, so both HealthVault and Amalga are built to embrace them both.
    Frankly this isn’t just a CCR/CCD issue — there are a zillion formats out there holding useful information, and the reality is we’re all just going to have to deal with that for some time to come. The good news is that we do seem to have a little bit of bedrock in the form of XML and XSLT — these help a ton.
    The key thing, I believe, is to stay focused on moving data so that it can be reused and shared — not getting dogmatic about how we move it. Turns out that when we do that … the right things are happening, a little more quickly with every turn of the crank.
    —S

  15. Margalit, don’t see any disagreement betwixt us. For many applications — espec ambulatory and small company — CCR is a complete solution. Hospitals can also deploy CCR for specific applications.
    However, hospitals will not view CCR as complete data exchange solution for all applications. Hospitals will need to adopt HL7.
    Yes, vast majority of hospitals today are on HL7 2.x . While HL7 3.x is incompatible with 2.x, my assumption is that hospitals view “eventual” migration to 3.x as necessary, albeit dreaded because of reasons you cite.

  16. Vince, I have to disagree with part of your post. Most institutions and vendors that have large investments in HL7 are dealing with the “classic” HL7 versions, the 2.x standards. Those bear no resemblance to the CDA and the RIM, which look to me as the most mind boggling standards I have ever seen. I must confess that I was never able to read all of the documents from beginning to end. I either fell asleep or got angry enough that I needed to walk away.
    Forcing vendors and institutions to adopt those standards, if one can call them standards, will result in increased IT spending all over the board. I don’t think that this is something we need right now.
    On the other hand, the CCR is almost “simple stupid” which is a compliment when it applies to a standard and could be implemented at very short notice.
    Yes, vocabularies are an issue, but CCR can serve as a means of exchanging meaningful data with just ICD9, NDC and CPTs. Not an ideal situation, but a good start since virtually every system already has those terminologies implemented for billing purposes. Later we can add LOINC (which has ways to go to be truly useful), SNOMED, RxNORM and a host of others, if necessary.
    I just think we have to start somewhere and CCR is just the easiest and simplest way to start the process and achieve meaningful results.

  17. Looking for information on the breakdown of healthcare costs in the U.S., I came across a recent publication by the McKinsey Global Institute (MGI), titled “Accounting for the cost of U.S. health care: A new look at why Americans spend more”. The report contains some statistics and predictions, based on the current trends, which I personally found very alarming. For example, healthcare costs grow at a faster rate than GDP. In 2006, they accounted for 16 percent of GDP, and, according to the Department of Health and Human Services, will post “annual average growth of 6.7 percent over the next decade”. The Congress Budget Office projects that the share of healthcare spending will increase to 25 percent of GDP by 2025.
    MGI analyzed healthcare spending patterns in 13 OECD countries and came up with a measure they call “Estimated Spending According to Wealth” (ESAW), which reflects the fact that countries with higher GDP per capita tend to spend larger portion of their GDP on healthcare. But even adjusted for wealth, in 2006, our combined healthcare expenses were $2.1 trillion, or $643 billion above ESAW.
    MGI did not find any proof that we get a better value for the extra money we spend. Among the reasons why the current system keeps driving healthcare costs up well above their fair share of GDP, they mention several economic factors, which I interpret as follows:
    • Relatively low and flat out-of-pocket expenses for insured patients
    • Large number of uninsured Americans (16%). I believe that creates an incentive for providers to pass on un-compensated costs to those , who pay, in the form of higher prices
    • Diagnostic procedures and treatment strategy are often chosen on the basis of maximum profitability for the provider
    • Lack of statistical data from healthcare institutions, in part, due to patient privacy protection, keep payers in the dark as to available treatment options for different conditions. They basically pay the asking price, and pass on the buck to their customers, raising premiums later on
    It comes at no surprise that ambulatory surgery (ASC) and diagnostic imaging centers (DIC) are two fastest growing areas of healthcare, being extremely profitable. Sometimes, providers may seem obsessed with MRI or CT scan for almost every single encounter, but it also has obvious economic grounds. One of the solutions we could consider is to adopt the law that would require healthcare providers to switch to a CCHIT certified electronic medical record (EMR) system within, say, 3 years. The government should provide grants to public and community clinics and hospitals, delivering care to Medicaid and Medicare recipients, as well as to uninsured or under-insured patients, to assist them with the implementation of such a system. The patient must have the right to get all his or her medical information, collected or created during the encounter, in the electronic form on a portable media, free of charge. EMR system should be able to display that information, regardless of which of them was its origin. Insurance companies, if we keep our multi-payer system intact, or a single payer, whoever it may be, should create incentives for patients to request and share their medical records, by giving discounts or credits/rebates, respectively. The technology to support this already exists in the form of interoperability standards. It just needs to be utilized to stop the medical inflation from getting out of control.

  18. IMHO, CCR and CCD are more complementary than competitive.
    The CCD standard is more likely to be used:
    •By organizations that have already adopted HL7 (e.g., large delivery systems)
    •To support existing business models
    •In non-disruptive applications that achieve costs savings and/or quality improvements by automating EXISTING processes that are INTERNAL TO THE ORGANIZATION (or with existing trading partners), e.g., hospitals sending test result information to doctors.
    •Where implementers have already incurred significant fixed costs to adopt HL7 as a broader enterprise standard
    The CCR standard is more likely to be used:
    •By organizations that have not yet adopted any standard (e.g., early stage companies)
    •To support new business models
    •In disruptive applications that achieve costs savings and/or quality improvements by creating NEW PROCESSES, often involving parties that are not currently exchanging information, e.g., improving patient chronic care management with the goal of avoiding ER visits and hospitalizations.
    •Where the implementers are highly sensitive to incremental costs of IT resources and view the CCR as a “better, faster, cheaper” alternative.
    see http://e-caremanagement.com/cchit-should-support-both-the-hl7-ccd-and-the-astm-ccr-for-phrs/

  19. So the conclusion to this debate is that in order to be more available for third parties, we need to support both standards.
    “CCD and Continuity of Care Record (CCR) are often seen as competing standards.[1] Google Health supports a subset of CCR[2], while Microsoft HealthVault claims to support a subset of both CCR and CCD.”
    If you were to add compatibility as a starter, would it be CCR or CCD?
    Mehdi Akiki,
    Co-Founder Your TeleDoctor Inc.,
    http://blog.yourteledoctor.com
    1-514-562-4580
    Your Doctor Anywhere, Anytime.

  20. jd, there’s something of a religious war going on here. BUT many of the more “open” vendors are using both CCR and CCD–e.g. Kryptik is sending out emails with whichever format the client uses. The more “closed” vendors seem to be waiting until CCD “wins” the war. I think Brian is pointing out that awaiting such victory is unlikely….

  21. OK, I’m confused again. I had thought CCD was gaining on CCR. Is that not true? Or, since CCD is an attempt to meld CCR with HL7 standards for data exchange, is this a difference without a difference? Are you counting the growing use of CCD as also a growing use of CCR?

Leave a Reply

Your email address will not be published. Required fields are marked *