Active Forum Topics | Getting Started | Interviews | EMR Forum | Medical | Billings | Press & News | Voice Recognition | The Water Cooler
CCR is always a hot topic.
Here is a thread from last year that generated much heat and debate. http://www.emrupdate.com/forums/thread/28212.aspx
Its a new year and time for a new thread.
Dr. Kibbe Dec 05 update
from: David Kibbe To: "Electronic Medical Records" <emr@lyris.aafp.org> Sent: Friday, December 09, 2005 9:46 AM Subject: Re: [emr] lab interface frustrations > Dear Matt and others: The AAFP Center for Health Information Technology > has been working really hard with a number of people and organizations on > both connectivity and interoperability standards that will, eventually, > make it possible for physicians who purchase EHRs to "plug and play." > We're making progress, and here is a brief synopsis of some of the work > that we're involved in. We are involved with all of the federal > government's standards efforts, and most people would agree that the AAFP > is both a leader and a significant player in most of the HIT standards > work that is occurring nationally. > > E-prescribing -- we have been supportive of SureScripts' solution because > it truly is plug-and-play for bi-directional computer-to- computer > exchange of prescribing and fulfillment data between doctors' EHRs and at > least the retail pharmacies, and there is no cost to the physicians for > this service. We have also been involved with NCPDPscript standard and > its evolution towards XML, and have helped to make certain that the CCR > standard's medication information conforms with both NCPDPscript and the > XML version of that used by SureScripts. We believe that within another > 3 years or so 100% of retail pharmacies will be SureScripts certified, > and 100% of EHRs will be SureScripts certified, and that the PBMs will > have jumped on this bandwagon by then, too. > > Lab connectivity -- the progress here has been slower, in part because > the clinical lab industry has not done what the retail pharmacy industry > has done to create an XML hub into which EHRs and labs could plug for > bi-directional lab results reporting and order- entry informational flow. > Clearly, a SureScripts-like solution for lab data connectivity is the way > to go, but it hasn't happened yet due to structural and economic issues > in the lab industry. However, the program called ELINCs has at least > provided a national standard implementation guide for lab results > reporting for the majority of tests to EHRs, using HL7 version 2.4 and > LOINC. Its clumsy, it is still an interface, not an interoperability > solution, and it's not XML. However, some of you on this listserv are > already taking advantage of this work, because it is being used by > LabCorp and Quest in various parts of the country to help decrease the > hassle and cost of doing the interfacing. > > EHR-to-EHR exchange -- the CCR standard is clearly established for the > purpose of exchanging summary clinical information between information > systems, and over 40 vendors large and small have signed on to the > effort. In addition, the CCR is likely to become the national standard > for populating PHRs and moving personal health information between EHRs > and PHRs as the latter evolve. Acceptance of the CCR standard by the EHR > vendors now means that EHR buyers can get much of the data out of their > systems if they decide to convert to another vendor's system, and this > level of interoperability removes one of the biggest and justified worry > that potential EHR purchasers have had, which is "how can I get my data > out if I need to get it out?" > > Immunizations -- making vaccine and immunization information > interoperable between EHRs and, say, state immunization registries or > hospital databases, is very important to the pediatricians, and should be > to us as well. The CCR's xml tagging for immunizations may help out > here, because if patients and parents of kids start to use the CCR > standard as a vehicle for transporting and storing their immunization > records, then this will help convince the state registries to develop > reads and writes to the CCR's xml, which will mean all these systems will > be able to talk with one another and exchange immunization data. It's > the right thing to do, and there is some early work going on. > > Matt Levin says that he'd love to see a "CCR-type initiative" for labs. > Of course, he's right. For us clinicians, it's all about the data, the > information, and the exchange without loss of meaning or relevance. It's > no longer about documents as much as it is about information and its flow > from one system to another, for its use by people who make clinical > decisions, and how to keep this inexpensive. > > The CCR standard is having a large impact nationally because of what Matt > recognizes: we need clinically useful standards designed by physicians > that the vendors will accept and that don't increase the costs of EHRs > and HIT in general, but rather decrease the costs because there are fewer > proprietary components involved. > > Posed against this effort are a small number of vendors and organizations > who make a heck of a lot of money off of the proprietary nature of their > products and services, and the complexity of the processes for getting > data into and out of these proprietary systems. They are where the > friction comes from. > > But consumers of HIT are getting smarter and smarter, and refusing to pay > the big bucks for complexity and proprietary solutions. > > Hope this is useful information. > > With kind regards, DCK > > David C. Kibbe, MD MBA > Director, Center for Health information Technology > American Academy of Family Physicians
Dr. Winn writes regarding CCHIT certification:
If anything, I would argue that EHRs should be CCR certified. That way, if GE or eCW or e-MDs bites the dust, patient summary data could be transferred to another system with minimal pain and suffering. We don't have that today, but many of us are working towards that reality. The big players (like GE and Siemens) are resisting CCR. Why? They are big, propietary systems that cost a lot of dinero. If an e-MDs or Medtuity with arguably better technology could come in and make it easy for a hospital or physician organization to make a wholesale transfer of patient records.... they would be in serious trouble.
The take home message is CCHIT certification will have minimal value in assuring survival of the EHR you purchase. CCR certification is the holy grail and all of the smaller vendors have recognized this and are writing to this standard. The biggest, propietary systems are resisting. This message should be shouted in the streets whenever a physician group is seriously considering a Centricity, Cerner, EPIC or other big name purchase. They are buying dinosaurs that in some cases have already failed once in the marketplace. The big company name is a false sense of security. CCHIT certification is a false sense of security. One can argue that these things help - and they probably do, but CCR certification is what is desperately needed.
In a thread discussing, "What if your EMR isn't around in 5 years?"
Matt from Medtuity concludes that interoperability is the ultimate answer. So your entire database can be migrated into another EMR. All your progress notes, letters, labs, etc.
Something to play around with ...
https://www.solventus.com/aquifer/ReportContainer.aspx?control=CCRgeneratorform
User Name: doqitPassword: demo
FPdoctor,
Do you want to discuss CCR? I don't know why, but I get the feeling that you do, Amigo!
One thing I must say about CCR is that it survived our heated discussions on CCHIT certification unscathed. Most of us have agreed to CCR. It's been heat-treated and case-hardened in the crucible of this Forum.
What I do not understand is why it's not a done deal? Why do we need a central server instead of using email?
One of the most difficult moments in the creation of anything is to let go of it. When is it done? When is enough enough? You've got to know when to stop creating and start promoting.
I consider email a secure way to transmit and receive data. What's wrong with one doctor sending a medical CCR record to another doctor via email? Can't we all just get along? Do we really need the central server to get CCR launched? This is what is holding up the show, as far as I can see.
CCR will help doctors who do not even have EMR. But only if it becomes a function of email, most likely, an encrypted function.
CCR must be universally acceptable--and accessible--to as many doctors as possible in order for it to become the worldwide standard that we want it to be.
Robert Gleeman, Medical Journalist for EMR Update.com Email: robert@emrupdate.com Tel: 1-650-968-6359 Skype and ooVoo user name: robertgleeman EMR progress is a matter of fact. EMR Update supports your right to know.
There is nothing in the CCR that requires it to be exchanged only through a secure central server.
The CCR is nothing more than an XML file (which is a plain text file that is formatted in a highly regulated way so that it can always be read by any other CCR compatible program). This differs from HL7 where vendors must always exchange "their HL& formatting specifications" beforehand to make programming changes to insure that they can transmit and read the other vendors' messages.
The CCR file could be put onto a USB thumb drive, sent by email, printed, saved in a database, saved as a text file anywhere on the drive, placed on an Internet site for everyone to view, or anything else that is normally done with text data.
Vendors can limit how the CCR file is exchanged by, for example, only using a secure connection encrypting it with a private key only known to the other vendor. That is up to the vendor, though.
The little understand fact about the CCR is that it can contain very granular data-- so granular in fact, that many EMRs will have no facility to handle the granularity. If the receiving EMR's data structure is not so granular, then it must either discard data for which it has no storage place, or concatenate it to data where is does have a storage spot. When the receiving EMR packages up that data later, adding its own content, that granularity can be lost. That is not a problem with the CCR; it is a problem with the EMR.
mchasemd: The little understand fact about the CCR is that it can contain very granular data-- so granular in fact, that many EMRs will have no facility to handle the granularity. If the receiving EMR's data structure is not so granular, then it must either discard data for which it has no storage place, or concatenate it to data where is does have a storage spot. When the receiving EMR packages up that data later, adding its own content, that granularity can be lost. That is not a problem with the CCR; it is a problem with the EMR.
That is why we must encourage... nay, insist that all vendors map their data to SnoMed and RxNorm. When that happens the planets will align, war and suffering will cease and mankind will live in harmony.
Disclaimer: I am the founder of e-MDs - highest rated EHR in 5 consecutive AAFP and ACP physician surveys
RxNorm
http://www.nlm.nih.gov/research/umls/rxnorm_main.html
SnoMed
http://www.snomed.org/
Dr. Winn writes to Flip, in another thread:
People bought Amicore because it was safe. It couldn't have been because it was good because it was really awful. Amicore was the big bad troika of Microsoft, Pfizer and IBM destined to rule the world. I heard the same thing with Glaxo's Healthmatics and Logician (before they both went belly up). Then GE pulled the plug on their popular, but inexpensive Internet Logician. When, if ever, will docs wake up and realize they are being sold down the river by these big companies. Your purchase will only be safe when your vendor embraces CCR and freely commits to making it easy for you to transfer your patient records to another system. Guess what. GE and the others got big by building propietary systems. They cannot compete on price and to make their products CCR compliant signs their death warrant. Anyone buying on the false premise that big is safe is sadly misinformed. Well Flip, its time you rethink your situation and flip to the safe bet - and that is not GE. I would have suggested someone like Allscripts because they have gotten fairly big and they embrace CCR.... but I think they are falling under GE's hammer. Good luck indeed!
CCR web site: http://www.centerforhit.org/x201.xml
AAFP statements: http://www.aafp.org/x38487.xml
Kibbe emphasized that physicians should ensure that any EHR they acquire is CCR-compatible.
"You don’t want your EHR to be a data island."
CCR Acceleration Group
LISTING OF vendors who support CCR.
Notice whether they export, or inport, or both.
http://www.centerforhit.org/x1556.xml
"+ A special thanks to Solventus for helping with the CCR gallery and allowing the free use of their CCR Generation tool to demonstrate CCR interoperablity. "
CCHIT is leaning towards CCR http://www.cchit.org/files/20050729_Minutes_Interoperability.pdf
FPdoctor:CCR Acceleration Group LISTING OF vendors who support CCR. Notice whether they export, or inport, or both. http://www.centerforhit.org/x1556.xml "+ A special thanks to Solventus for helping with the CCR gallery and allowing the free use of their CCR Generation tool to demonstrate CCR interoperablity. " CCHIT is leaning towards CCR http://www.cchit.org/files/20050729_Minutes_Interoperability.pdf
Bryan D. Uslick, MD CFCDD (Gastroenterologist) eMDs user since 3/3/2006. Currently using version 6.1 (Prior Praxis user.)
Provation MD endoscopy report writer
Yea, I like the link too. Its an important enough link for vendors to get their name on it.
And also to have any new info updated. I would imagine they would submit changes to
Solventus.
"CCR compatible" will become a mantra phrase EMRs will need to include in their future marketing.
Graham http://www.synapse-ehr.com/ Synapse - the EMR for the superior physician