Next Steps for Interoperability

There are some folks in Washington who have made statements that we
should delay investments in EHRs because current vendor products lack
the functionality needed to support a coordinated healthcare system.
Others have said that we lack the standards or security framework to
implement interoperability. Here are my thoughts.

Take a look at
the successes in Massachusetts and New York with commercial EHR
products. We’ve implemented eClinicalWorks, which includes decision
support, e-prescribing, administrative transactions with payers,
clinical summary sharing across the community, and quality measurement
(all the National Quality Forum high priority measures). It’s
web-based, using a service oriented architecture in a cloud computing
environment. By implementing this product at BIDMC, we’re meeting all
the payer guidelines for delivering appropriate, coordinated, high
value care. Vendor products from Epic, Allscripts, NextGen, GE,
Meditech, eMDs, MedSphere, and other CCHIT certified vendors have
similar features.

Should we wait for something better that has more interoperability?

you drive a car? Why? It pollutes, costs a lot, and generally is not
very efficient in traffic. You’d be much better off asking Scotty to
beam you up via the transporter. Should we eliminate all cars, planes
and trains until the transporter is invented? The same can be said of
EHRs and health information exchange.

My definition of good enough

*Support for medication interoperability such as e-prescribing linking providers, payers, and pharmacies
for laboratory and radiology interoperability such as orders and
results integration among providers, hospitals and commercial labs
*Support for seamless electronic interchange between providers and payers for administrative data flows.

In 2009, several EHR vendors will support clinical summary exchange.

can achieve a substantial improvement in care quality and coordination
by implementing the systems available now and not waiting. If anyone
thinks writing a next generation interoperable EHR from scratch is a
good idea, have them look at the UK implementation of the
NPFit/Connecting for Health project. They hired numerous companies to
implement an new scheduling/booking system, a nationwide PACS system
and a coordinated health record. After spending billions, they have
limited success and low provider satisfaction.

On December 18, HITSP completed all the national standards harmonization work for 2008.   This included:

*Biosurveillance Interoperability Specification (IS02)
*Consumer Empowerment and Access to Clinical Information via Networks Interoperability Specification (IS03)
*Emergency Responder Electronic Health Record Interoperability Specification (IS04)
*Consumer Empowerment and Access to Clinical Information via Media Interoperability Specification (IS05)
*Personalized Healthcare Interoperability Specification (IS08)
*Consultations and Transfers of Care Interoperability Specification (IS09)
*Immunizations and Response Management Interoperability Specification (IS10)
*Public Health Case Reporting Interoperability Specification (IS11)
*Patient-Provider Secure Messaging Interoperability Specification (IS12)
*Remote Monitoring Interoperability Specification (IS77)

The documents are accessible through www.hitsp.org

This latest round of work means that we’ve completed the three year AHIC roadmap for standards.   There are no unapproved standards at this point!

course standards will evolve and we’ll keep enhancing this work,
including lessons learned from implementation in vendor products. In
2009, we’ll be given a new body of work including Newborn screening,
and filling several small gaps required to support clinical workflows.

Thus, if we have products that are good enough and interoperability standards, what are we lacking?   Some say security.

HITSP completed security standards harmonization in 2007.

The 2008 CCHIT criteria for security are rigorous. Vendors have described them to me as one of the most challenging aspects of certification.

Although there is still local/state variation in policies, we do have a national framework for EHR and PHR data exchange.

say that they have personal experiences with lack of coordinated care
among multiple providers. Is that an issue with EHRs and standards? My
view is that this is a process and policy issue. In the US we do not
have a healthcare system, we have numerous providers, labs, pharmacies,
and hospitals which do not constituent a single medical home for the

Let’s implement EHRs now and realize their benefits.
Let’s implement the interoperability for administrative transactions,
labs/rads, and e-Prescribing that is robust today. Then let’s implement
the clinical summary exchange that’s coming soon. It’s a journey and we
should start immediately. There is no reason to wait.

Categories: Uncategorized

Tagged as:

9 replies »

  1. It is in no company’s interest to cooperate with another. That’s why we have “fabricated” standards, like HL7. Let’s talk about how the “market” worked out such standards as HTML, HTTP, SMTP, DNS and the rest of the global internet standards.
    Markets don’t decide standards. In fact, the pressure is more often in the other direction, towards a collection of fetid, proprietary ponds.
    Just saying.

  2. There are far too many health care politicians more interested in furthering their own careers by foisting vendor products into the hands of unwilling physicians.
    Enough is enough. Let the market sort it out, provide choice, stop fabricating IT standards that further specific IT systems, further vendors greedy desires and further everyone’s needs except for the clinicians using the system.

  3. rbar,
    I agree with your desire to keep it simple and your solution, as I understand it, isn’t far from what we are proposing. The big difference is that yours doesn’t meet the desires of consumers/patients to control their records and to be certain they are secure (they aren’t on a Web server).
    Also, from the physician point of view, your proposal merely converts a literal pile of paper into a virtual pile of paper. This is no more useful than if a patient walked into your office and handed you a pile of paper notes — you wouldn’t know where to start to find what you are looking for. In the MedKaz™ system, they are indexed so they can be sorted and searched — and you can find and access the specific records you want (and ignore the others).
    The issue of a record accessibility in case of a disaster, natural or merely an accident that leaves a patient comatose, is interesting. If an individual is comatose, his/her portable device can be easily accessed using biometrics — simply put their finger on the device and the records they want emergency providers to see can be accessed. In a natural disaster or power outage, basic emergency information can be available on a self-powered portable device; nothing would be available on a web server.

  4. I have quite longstanding practical EMR experience (Cerner, IDx, and some experience with the VA system), and to me, it sounds (from reading the OP and some comments) that we might get in the process of creating a complicated, costly monster. To maintain 1 EMR in one health system is already complicated and costly, as I witness every day. To have different EMR succesfully and reliably intraoperate seems to be unrealistic to me at this point.
    I already wrote it a couple of times here, but again: just put ALL doctors notes/results on a secure server in the internet, filed by date and specialty. (Medicare could do it, and private insurance can chip in and participate.) Doctors can either type notes directly into the system, or scan and upload hardcopies of their docs in their own office (or send it to a scanning center, which causes furter delay). That way, every provider can access the record even if a patient gets, comatose, into an ER while travelling. Portable devices will fail in that regard.

  5. John,
    With all due respect, I see the healthcare IT debate very differently.
    The Issue is the System
    I submit that the issue we must address is not “interoperability” and whether we should advocate adoption of electronic medical records (EMRs). Rather, it is what system should we adopt to make a patient’s lifetime health record available to care providers when and where they need it?
    The choice of system will depend upon answers to three inter-related, subordinate questions:
    1 How should records be kept (here we can address the issue of EMRs)?
    2 How and where should they be aggregated?
    3 What should be the “delivery system” that enables care providers to access a patient’s records on demand?
    Our objective must be to optimize the system, not its individual components. Accordingly, our criteria should be:
    1 Does it meet the needs of physicians and consumers/patients? If it doesn’t, they won’t support or use it.
    2 Is it simple, cheap, and available sooner rather than later? If it isn’t, it may never get off the ground.
    3 Can we afford it and is it financially self-sustaining? If we can’t afford it, we’ll never build it. If it isn’t financially self-sustaining, it will either be a continual financial drain or it will collapse.
    The “Conventional Wisdom” System
    Today’s “conventional wisdom” calls for a provider-oriented, Internet-based system.
    1 All care providers must adopt and maintain electronic records.
    2 All records are stored on servers.
    3 All records must be accessible over the Internet.
    4 All records are accessible, with patient permission, to any care provider.
    5 All EMR system vendors must standardize their systems.
    Despite widespread support, this system doesn’t appear to meet the criteria.
    1 Most physicians, hospitals and consumers refuse to embrace it; it doesn’t meet their disparate needs. And if care providers are forced to adopt EMRs against their will, they must at the least be subsidized; this will take far too long to implement and will cost billions – which we can ill afford given today’s economy.
    2 It requires significant technical breakthroughs and reprogramming of systems, which will take time and money to accomplish. In the interim, people will continue to die unnecessarily, many will be made sicker rather than cured, and billions of dollars will be wasted.
    3 It requires not only the adoption of costly EMR systems but also the construction of extensive, costly networks to make patient records accessible.
    4 It will take years to implement and will cost — by some estimates — hundreds of billions of dollars to establish and maintain.
    5 Its business model isn’t self-sustaining. Most RHIOs and many other local networks are failing for lack of funding.
    If this were the only system that could do the job, I guess we would have to embrace it. But that’s not the case. We have developed one that gets the job done; I suspect there are others.
    The MedKaz™ System
    As you know, our company, Health Record Corporation, has developed an alternative, consumer-focused system that meets the criteria. One leading authority describes it as “a consumer-driven medical record idea that makes sense.”
    1 It satisfies consumer concerns by storing a patient’s complete health record on a portable device, called a MedKaz™, that the consumer owns, controls and carries or wears, not on Web servers.
    2 It employs established technology and transcends the technical issues troubling EMR vendors and users.
    3 It is its own repository and doesn’t require costly networks to make the system work. (The patient fulfills the function of a network – moving information from where it resides to where it is needed – merely by giving his/her care provider their MedKaz™.)
    4 It allows physicians to maintain either paper charts or electronic records as they wish, and improves their workflow.
    5 It helps physicians get comfortable using simplified electronic records, and reduces the cost of subsequently adopting an EMR system.
    6 Physicians are paid to upload copies of a patient’s records to it. (A typical PCP can increase his/her annual income by $25 thousand or more.)
    7 Physicians can electronically sort and search its contents to quickly access the specific records they need.
    8 It can be implemented in 12 months rather than years.
    9 It is financially self-sustaining and doesn’t require subsidies.
    10 It is simple and cheap; it doesn’t cost hundreds of billions of dollars—but it can save billions. (Eg, if every Medicaid patient carried a MedKaz™, we conservatively estimate the states would save more than $6 billion annually.)
    The beauty of this system is that it gets the job done without getting entangled in the debate over EMR issues or subsidies. At last, we can stop squabbling and solve the problem.
    Personally, I applaud your efforts, the efforts of your HITSP committee, and the many other groups who have advanced the compatibility of EMR systems. Paper records certainly are less than ideal and I would like to see every care provider eventually adopt an EMR system (it would benefit them and work extremely well with the MedKaz™). But the fuss over EMR adoption issues has taken our eye off the ball.
    Thus, by focusing our attention on the primary issue, the system, we can meet our objective of making a patient’s lifetime health record available to a care provider when and where they need it.
    The MedKaz™ System is far from perfect. But — to use your term – it “harmonizes” the controversial issues surrounding healthcare IT so we can get moving! We’ll improve it as we go.

  6. Firstly, eClinicalWorks is not in a cloud (cloud is not synonymous with hosted). While eCW does offer a hosted model, from the many physicians I have spoken using eCW, the vast majority of their installations are onsite in the physician’s office.
    With installed software, interoperability (i.e. sharing patient records) extremely difficult and expensive, as point to point integration is needed for each installation of the software (physicians need to connect their practices to a community of offices).
    With today’s technology, buying an EMR and installing it does not mean you will be interoperable, or even close. To correct the car analogy in this article – distributing EMR to physicians with the majority of today’s software is more like giving a car to person who lives in a cabin in the woods – without roads, freeways, a map and a directory of locations (e.g. infrastructure) she will never be able to get from point A to point B. This is the equivalent for a health record – without a technology infrastructure in place the record will simply never be able to be transported from one physician to another.
    And the problem is actually much more complex than just getting the record from doctor A to doctor B. It comes down needing a master patient record or repository. Without it, a patient who goes to multiple practitioners will have a copy of a record at each of those practitioner’s offices. There is no method or platform in place today to aggregate these records without each practitioner exporting these manually. Even if they go through this exercise, where does this master record reside and where does one go to retrieve it? This is where the real problem and expense resides. What is scary is that the new administration does not seem to be factoring this into the EMR cost equation. To date, the industry has attempted to solve this through RHIOs and other HIE initiatives and the vast majority have failed catastrophically. CalRHIO is an excellent example of this – hundreds of millions in funding and zero progress.
    Is this problem solvable? Definitely. But only with emerging web-service based architectures that were natively designed to share data and manage large communities Antiquated vendors, such as Allscripts, Epic, Misys and eClinicalWorks will fall to the wayside over the next few years to give way to extremely low-cost and rapidly deployable web-based models. These models will be community platforms, natively having the ability to manage numbers of doctors and patients, as well as share patient data without the need for expensive consultants, onsite installations, and upfront licensing. The technology in available and standards are in place – the market simply needs to deliver a solution that is priced right, truly community and web-based and easily adoptable. From working hands-on in the market I have seen at least a half dozen of these models emerging today.
    -Ryan Howard
    CEO, Practice Fusion

  7. Part of me thinks that physicians who protesth HIT innovation too much, focusing solely on flaws, have a hidden political agenda.
    Any system will be guaranteed obsolete. So is my i-Phone. Is that a reason to wait? Not if you are the patient and you would like your records now, please.
    Oh, the patient! (aka the Residual Payer)
    EHRs may not be interoperable, but activated patients are.

  8. Can a family doc with AllScripts efficiently share relevant patient information including a documented patient history with a cardiologist that uses NextGen? If the answer is no, the next quesion is, can the two systems be retro fitted to allow that to happen? If the answer to that question is no, then we must seriously ask whether the spending on IT infrastructure is warranted, or whether it’s better to wait for the next generation to come out.

  9. If anyone wants to take a lesson learned, please look into the enterprise wide systems that SAP and Oracle have. These are monstors. The EHRs, ERPs, all these are needed. The problem is that they create new problems unless the system is well developed and even more importantly well implemented.
    The EHR system without any doubt is fragmented and quite infant state yet. The implementations have rately delivered on the promise.
    THe lack of success has been inexperiece in developers in process/product design and implementers missing the mark on roll out.
    There are a lot of opportunities here…but pouring money without proper competencies getting invlved would just like bailing the auto-industry.