This week a host of organizations responded to a Senate Finance Committee request for feedback on how to better use healthcare data.
The inquiry is timely, given the widespread frustration providers have with health information technology (HIT), and electronic health records (EHR) systems in particular. This frustration stems from many HIT/EHR systems are locked in proprietary systems. This hinders technology’s ability to connect and exchange information freely between disparate systems, devices and sensors along the care continuum, thus undermining the overall goal of using HIT to improve efficiencies and reduce costs.
An example illustrates the point. Because HIT systems don’t work together, most hospitals use nurses to manually double check input from disparate “smart” devices. For instance, an infusion pump reports the level of pain medication being administered to a patient, as does the EHR. But these numbers sometimes don’t match, and must be double checked by at least two nurses to confirm the right dosing. Not only is this a step back for efficiency, but it’s also another manual process that has the potential to create errors and patient safety issues.
There are also economic consequences of data fragmentation. According to the Office of the National Coordinator (ONC), U.S. providers are spending $8 billion a year due to the lack of interoperability.
To address this problem and reduce the unnecessary fragmentation of healthcare data, it’s time to require the use of open and secure applications programming interfaces (APIs).
In April, a group of America’s leading scientists, named JASON, published a report that found the current lack of interoperability among HIT data sources is a major impediment to the exchange of health information. They recommended that EHR vendors be required to develop and implement APIs that support health data architecture. The recommendation was also endorsed by the President’s Council of Advisors on Science and Technology (PCAST) in May. Requiring open APIs as a foundational standard for healthcare data would reverse the current legacy of locked systems and enable the real-time exchange of information in EHR systems to reduce costs and improve patient safety.
While it would be preferable for the market to respond to these challenges and voluntarily open APIs based on the needs of providers, it’s essential that we move as quickly as possible. To achieve the fastest momentum, it may be necessary for the ONC to lead, through government action, by requiring open API data elements in EHRs to meet meaningful use.
A recent Health Affairs article noted that today’s HIT systems operate less like ATM cards, allowing providers to access patient information anytime, anywhere, and more like frequent flyer club cards designed to preserve brand loyalty. It’s time to change that dynamic with open APIs. Without it, we will never unlock the true potential of HIT.
Keith Figlioli is senior vice president of Healthcare Informatics and a member of the ONC Standards Committee
Super interesting article. We can use all this information for our business. Thank you for posting this article.
http://www.peakinsuranceadvisors.com for NY State Health Insurance Help
This could pretty easily be market driven. Why don’t the hospitals demand these sorts of APIs as part of the normal vetting process for choosing an EHR?
Must do nothing but troll the blogs persistently defending the EHR systems that have been toxic to health. Here to stay??? NOT
Who’s the troll here?
“There is nothing wrong with not being one. It’s just that all that work that you did on EHR’s have little to do with the problems physicians face.”
That’s a tired, old, lame blow-off. “If You’re Not a Physician, You Just Don’t Get It” and have no right to an opinion.
I think I have a pretty fair handle on the problems physicians face.
Health IT is here to stay. Get over it. The systems will improve significantly, in accelerating fashion.
Bobby, once again you didn’t listen. I didn’t say EHR’s weren’t something that could be good. I said mandates and coercion produce an EHR that doesn’t efficiently work. I even had an early EHR in the 1980’s so it is obvious I am not averse to them.
Secondly, I didn’t say there was something wrong if one is not a physician nor did I say one couldn’t have an opinion if they weren’t. I did say there was a difference in thinking patterns between different types of groups and that is necessary.
The EHR thought patterns are not directly oriented towards the thought patterns that make up an efficient exchange of knowledge between the physician and the patient along with other providers. Go back to the different EHR’s and try inputting all the data so it goes in the places the EHR demands. See what happens. Make it a complex patient and see the time needed to input the information. Then consider at each step that the program might not permit explanation of the data forcing one to be incomplete.
Patients have the same problem outside of the EHR for physicians when interviewed with questions that have more than a yes or no answer. Example: Some programs will ask the patient if they want to be put on a ventilator, but the patient doesn’t consider it a yes or no answer. They are forced into putting down one or the other for the program will not continue until all the preceding boxes are filled. Let’s say the patient had a qualification to that yes or no answer. Some computers programs can’t manage that and if they can that increases the amount of time spent getting the information and increases complexity.
What happens when a physician receives the record. There is so much stuff there that he doesn’t have the time to read it. Researchers have the time, but physicians don’t. Not only that, but because of the time involved one has to wonder if the record is copied from a previous one or canned. Both can lead to substandard care. When detailed complex information is necessary there are frequently better ways of getting that information that can be book size all because of the requirements that fill bookkeeping, research, fraud and abuse, legal and other needs.
The only ones benefiiting from this Rube Goldberg work flow adjustment are the vendors of HIT, who sold Congress a bill of goods as the guise, “typewriters for orders”.
And both sides of the aisle of Congress and the White House are perpetuating the illusion using the ONC as the chearleader to dazzle voters with sweeping notions of better health care from big data and fewer errors from the scourge of bad handwriting.
Delusions of grandeur.
See Dr. Carter’s excellent blog “EHR Science.” http://ehrscience.com/
BTW, (“dazzle the voters?”) I rather doubt that the average citizen even knows what the ONC is. Moreover, ONC appears to be fading back into their GW Bushian era of benign neglect, in line with our tradition of Policy ADHD.
More on data mining. We can only improve quality and cost effectiveness when we can see what we are doing. Or better who is doing what to whom. So far the information released by CMS on Medicare seems to suggest there should be lists of room for savings and improvement but I have been disappointed in the lack of any constructive steps to even be recommended, For instance in my own community it is the rare gastroenterologist who recommends a ten year follow up for a normal colonoscopy and some even do upper endoscopies several times a year on stable patients with benign gastritis. Cardiologists express frustration at patients who go to multiple hospitals and have multiple angiograms in one year. Patients with headache make more than 100 visits to emergency rooms in a year, The data mining should be used to evaluate cost effective providers and abusing patients.
I’m not sure that visualizing information will stop patient churning reinforced by our current system. Medicare has loads of data and cannot stop overutilization. In fact, they pay for it routinely without question. How will I fare any better?
Certainly the goal of EHR was clarity and communication and data mining was also a desired benefit. It does or can make it easier to see a summary of a patient’s history and for instance allergies and medications which can be flagged for interactions or dosage errors. Yet somehow it is too complex and has not come together and led to acceptance and satisfaction by many providers as we read above. The properly developed EMR would not lead to extra hours spend away from patient care or from ones family but where is it?
“but where is it?”
The promoters of EHR’s have their own agendas. However, why should those agendas be fed for free especially when it isn’t free. Eventually it costs the patient a portion of his time with the doctor and the doctor a portion of his time with his family.
How do people generally get these extras? They pay for them. If they actually had to pay they would suddenly find their needs shrinking. Then we might be able to see an appropriate EHR, but only if it isn’t mandated.
“Eventually it costs the patient a portion of his time with the doctor and the doctor a portion of his time with his family.”
No different from having to complete paper charts.
Have you ever entered a patient’s history into a mandated electronic record?
Obviously from your answer you have no idea.
“Have you ever entered a patient’s history into a mandated electronic record?”
In particular, I had intense onsite training on eClinicalWorks at their Massachussetts HQ, the culmination of which was having to do an entire “new patient” workup under time pressure, soup to nuts, including intake demographics, FH, SH, PMH, CC, Vitals, HPI, Active Meds, Active dx’s, ROS, SOAP (including dx, rx, px,tx), E&M coding, and successfully dropping a claim (the “pass” criterion for closing the note).
Most of which I would now do via Dragon 4.0, it’s gotten so good (even on my iPhone).
Other platforms with which I’m personally hands-on familiar include athemaHealth, e-MDs, Greenway PrimeSUITE, SOAPware, Amazing Charts (excellent), CareTracker, EMR-lite (ugh, POS), Praxis, PracticeFusion, OpenEMR, NextGen, Allscripts Professional, and about 20 more onesees-twosees among our REC clients.
But, yeah, I have no clue.
Oh, and we must not forget my own EHR product (given that I get accused of being a “vendor shill” here), Clinic Monkey. http://ClinicMonkey.blogspot.com
So you are a physician that understands what he has to write into the EHR? But you have stated otherwise in the past. You just don’t know because you don’t understand how a physician thinks and what he must do to enter data. There is a big difference in bureaucratic thinking and the thinking of those that have to think quick on their feet.
Check out “Sources of Power: How People Make Decisions by Gary Klein
The problem is that you don’t know what it takes to fill out the forms necessary when dealing with a complex patient history and physical. You don’t know how it alters the data. You don’t know how it alters the way the physician thinks.
Understand I am not against electronic medical records. My office had a partial record in the 80’s that could be accessed electronically. My only objection is to mandates and coercion. They impede the innovative process of creating a successful EHR.
“So you are a physician that understands what he has to write into the EHR? But you have stated otherwise in the past.”
You simply do not pay attention.
“You simply do not pay attention.”
Is this your way of making believe you are a physician?
There is nothing wrong with not being one. It’s just that all that work that you did on EHR’s have little to do with the problems physicians face.
Concerning the ONC concept paper:
How is this ten year vision any different from the last 10 year vision that was ineffectively implemented and unrealized? The promises are the same.
Excellent article. It’s worth noting in this context the vision document released by ONC in June, which various groups in government are now starting work on :
It’s fairly easy to read and only 16 pages long. Disappointingly, APIs are not mentioned at all, but the goal of seamlessness is clear, and the ONC has enthusiastically adopted the JASON report mentioned in Keith’s article, so at some point a focus on APIs can be expected. One of the benefits of APIs–if they are openly published and not encumbered by licenses–is that they would encourage a market for innovate third-party applications. No longer would we have to wait for the original vendor to add a feature. If the data supports the feature, someone can write and distribute an app for it.
Keith, the frustration of physicians you describe might be your own or that of researchers hoping that doctors and nurses tailor their product so it is understandable to your needs and theirs. What you are demonstrating is that technology combined with government mandates doesn’t lend itself to an efficient process for the ones actually treating the patient and not the EHR or any of its alternative-market products.
If you are really interested in looking into the frustration I suggest you pair yourself with a frustrated physician that sees patients night and day. Follow him step by step and get home to dinner late because of the extra time needed for the EHR. Follow him in the middle of the night as well so you can see how fatigue can enhance the frustration. Then on the weekend when your son is playing first base for the team follow the physician as he makes rounds and take note how you miss your child’s ball game because of time consumed by the EHR. Do this for awhile and you too will find the EHR both fatiguing and frustrating. Then you will be better able to comment on physician frustrations with EHR’s.
It’s pretty clear that this has nothing to do with alleviating physician frustration, and everything to do with facilitating data mining.
That isn’t clear to me at all. Why do you think this?
Ryan, what isn’t clear to you?
No different from paper charting, in the aggregate.
“the extra time needed for the EHR”
Very, very different from paper charting, especially with MU added in.
Documentation has to be completed one way or another. BTW, 11 of the 15 MU Core can be completed at the sub-MD, support staff level with nil net pressure on workflow. The billing paradigm is the principal problem in any event. It’s absurd that a doc has to see 25-30 pts a day to stay in business.
That’s only going to get worse though. Much worse. And your point sort of underlines the need for more data transfer capabilities within HIT. I see a future where patients receive most of their primary care outside of the actual clinic — via mobile devices and telehealth. But having all the data locked up in silos hinders that shift.
As a UX guy in HIT, love the thought of doing the user research and building empathy toward physician frustrations. I’ve learned through my research it’s not just fixing the EMR, but there are data gaps through the lack of integration that is causing a lot of pain out there.
“This frustration stems from many HIT/EHR systems are locked in proprietary systems”
Perfect interoperability would change the daily routine of the vast majority of physicians not one iota.
The frustration comes from being forced to do data entry chores.
“It’s time to change that dynamic with open APIs. Without it, we will never unlock the true potential of HIT.”
Without a standardized comprehensive Data Dictionary, we’ll continue to nibble around the edges from the outside in.
I’m not convinced that a comprehensive Data Dictionary is really all that useful here. We have that in HL7, and it hasn’t exactly revolutionized HIT. In many ways, the comprehensiveness has made our lives worse rather than better.
“We have that in HL7”
I just have to beg to differ. I’m talking about a foundational metadata standard at the individual RDBMS level. And, to which of the myriad HL7 flavors do you refer?
You need not take my word for it. Ask Fred Trotter, a health IT SME if ever there were one.
None of which, btw, is to argue that it would comprise a panacea. Schema considerations would remain to be issues.