I assume that there are and that they are all individually fantasizing about being the company that builds that standard.
So long as health care is a product needed by every individual in the country and remains the beneficiary of some $1T in federal outlays (to say nothing of state and private costs), equilibrium will be elusive. There is far too much money to be made in the churn.
You should checkout OpenEhr[0], "enable the development and deployment of open, interoperable and computable patient-centric health information systems"
I have done all paper, all EMR, and a combination of the two. The combination is the worst. So far paper alone is the winner for most situations, although even crappy EMRs have advantages over paper. Most of the problems, as I see them, come from the general baggage of enterprise software (not sold to the people who use it, likely focus of dev time is on accounting/billing stuff I never see) and an attempt to slavishly emulate paper in digital form.
Pre-EMR, I thought most docs dictated their notes on tape that were then transcribed to the medical record by clerks. Why are doctors having to keyboard this stuff now?
Because no hospital system wants to pay for transcriptionists when they can mandate the MD do the data entry themselves. You hear the big backlash from the private practice MDs who still used a combination of paper chart and dictation that are just now being forced to move to EMR through MU 1 and 2. And with the cost of buying a whole new EMR rollout and support contract, find they can't afford to pay the transcriptionists too.
This isn't a problem with EMR. This is a problem with poor UX in the software that the doctors are using. Here's the thing about paper records: they're costly as well. Paper records need to be photocopied, faxed, paged through, sorted, filed, unfiled, etc. God forbid the doctor needs to physically move a wall of patient records, or a disaster in the office. EMR are theoretically just O(1) to access, update, save, and send. Not true with paper records.
I obviously don't know the true statistics, but I'd hasten a guess that although EMR costs doctors a few extra minutes per patient but cuts the overhead of maintaining and handling those records by an order of magnitude. If the biggest complaint is information overload (as the article seems to suggest), the whole system could be completely "fixed" with a simple OS X system preferences-style quick search box.
I have first hand experience doing this, true, for some cases it is invaluable, but in most cases extracting valuable data from something that was designed primarily for billing purposes is just as hard.
Reminds me of my employers Oracle Financials rollout, which makes submitting a travel voucher a 30 minute chore that takes 3x longer to process.
Sure, somebody could analyze our 150,000 annual vouchers and figure out some sort of insight. But that's unlikely, as the people who have access to the data care only about payment KPIs, and accessing any data in the system is a nightmare for anyone else.
The scenario you describe is problematic as well. The liability associated with drawing conclusions about the efficacy of a drug based on unscientifically collected data would probably make it difficult to use it to drive decisions.
When the driver behind the EMR implementation is the billing department, the UX just reflects this needs. Doctors (good doctors at least)want tools that helps them do a better job, but no one wants to pay for it.. (Including doctors themselves)
If we built EMR's for epidemiological reasons, the reality would be totally different.
My primary care physician had 2 receptionists and a biller.
Supposedly, EMR would replace the biller. The reality is, they replaced the part-time IT died with a FTE, kept the biller and picked up a big "software maintenance" bill.
Other than electronic transmission of prescriptions, the whole process has taken a step backwards from paper.
Electronic Medical Record systems, and their non-healthcare counterparts in Enterprise Resource Planning systems, never delivered the cost savings and efficiency they promised because, at the end of the day, they're designed to streamline the billing/finance department, not the rest of the organization. The user interfaces are universally awful because they're designed to 'get finance/billing the information they need' rather than 'streamline the process for practitioners,' and at the end of the day the people buying the system aren't the ones who have to use it.
Someone once joked to me that an EMR installation was where you replaced all the people in your billing department with the same number of people, at a higher salary, in your IT department.
The worst part of "billing" driven EMR's is that doctors get really good at recording procedures and diagnoses to fit what the insurance companies want to hear, not what the real medical condition is. This has the effect of distorting the patients reality polluting the medical data, rendering it mostly useless or of poor quality for any decent medical research work.
You got a throat ache, but that is not payed by the insurance? uhhmm immediate upgrade to a pharyngitis.
There is a great chapter in the book "Hacking Healthcare" that addresses the challenges met with writing software that bests paper. I have linked it below for any software engineers interested in this problem space!
I had a client that made an EMR that was built on the concept of disease management. The basic idea was that by giving the doctor the right data and questions to ask, the doctor would help the patient manage their chronic condition and help them not need to come to the office so often. Doctors loved it. Patients loved it. Management didn't buy it because it lowered per patient revenue.
I'm a resident physician. EMRs are simultaneously awesome and awful. Awesome because most of the data and past records on a patient are a click away, just as promised.
Awful because they're invariably run by underpowered servers and delivered via laggy-as-hell Citrix windowing to crappy end-clients with smallish monitors.
Awful because they are all proprietary silos, and good luck migrating your hospital system off one and onto another. The idea of a portable electronic health record is largely a fiction at this point.
Awful because so much of the documentation you have to write has nothing to do with patient care, and more to do with defensive medico-legal CYA, and everything to do with the hospital getting reimbursed at the level it wishes to for each patient seen.
Awful because the software is legacy enterprisey garbage with a codebase written in MUMPS (look it up!) or some other esoteric language in the 1980s and carried forward with ongoing encrustation and decay since then. Awful because the UI actively gets in the way of our patient care workflow, and not the other way around. Need to look at lab data while writing progress notes on a patient? Too bad, you can't open both at once! Need to look at lab data or inpatient notes while discharging a patient from the hospital? Too bad, there are two layers of modal dialog boxes related to the discharge blocking access to anything else while you're discharging.
I've used the two market-leading big-enterprise EMRs in the US, Epic and Cerner, and they're both like this.
I used to write software for a living. The crappiness of even the most expensive EMRs (the ones that will set a big hospital system back a couple hundred million for an initial install, like Epic) completely floors me.
Do you have an opinion on or know much about newer / more user-friendly EMR's? I'm specifically thinking of PracticeFusion, but I imagine there are others.
Why doesn't stuff like this take-off? Is it the product of slow-moving hospital bureaucracy, or are there other reasons?
I had never heard of PracticeFusion, but clicking through their web site it looks like they're targeting solo practitioners and small practice groups.
Hospital systems with thousands of practitioners need systems that are many orders of magnitude more complex. The amount of investment it'd take to build a modern hospital-system EMR from scratch is enormous. A well-funded startup could certainly do it, but then there's the problem of adoption to deal with.
Hospital systems are very like big government from an IT standpoint: extremely conservative and risk-averse, even more so than regular big business tends to be ("you'll stop us from using Windows XP when you rip the install media from our cold, dead hands"). You know the old adage that nobody ever got fired for recommending IBM? Well, nobody ever got fired for recommending Epic.
The CFO of large healthcare organizations is historically who decides what software is purchased and used. Why the CFO? Because most enterprise healthcare software is built to support the billing/accounts receivable department.
It's very difficult to find an EMR that focuses on patient care and communication. The cynical side of me thinks that there isn't an incentive to build this kind of software. Doctor's aren't paid to make you healthier; they're paid to submit to insurance companies the correct diagnosis and procedure codes.
Well, there isn't an incentive because typically it isn't physicians (or, at best, it is physicians who are primarily administrators and somewhat out of touch with clinical practice) who are making the purchase decisions.
I can tell you that most clinicians would be jumping for joy if software that was more physician- and patient-oriented became the norm.
I'm a nurse/programmer and working with EMRs are maddening. The problem is the requirement that EMRs are built to protect against every potential thing that could go wrong. As a nurse, I'm spending a minimum of an hour a day clicking boxes and copy & pasting CYA lingo for all of my patients to protect against the 1% scenario.
EMR is not dysfunctional because it's EMR; it's dysfunctional because it's enterprise software for the Windows desktop.
It's very easy for the HN demographic to forget what it's like to use an "average" Windows machine. Startup and login times in the minutes to tens of minutes, extreme disk latency everywhere, nagging popups to update Java (has happened in my doctors' office more than once) and virus definitions, etc. Cheapass hardware is frustrating by default.
A surprising number of network-based Windows line-of-business applications are written with inexcusable naïveté - the application simply doesn't respond while waiting for network/server and a request that gets dropped or whatever will render the entire application inoperable for several minutes (or some other irrationally high timeout, if there even is one) unless you kill and reopen it.
Because Windows desktop management is so brittle/difficult/expensive and so many applications don't play well with MSI, updating is a manual process of walking around the practice and waiting for computers to be unoccupied so that you can load the new .exe onto them. In practice this sometimes just doesn't get done.
Add on the incredibly poor software quality that comes with lowest-bidder offshore development, zero attention to UX, and very aggressive and well-funded sales teams, and you get roughly the situation we have today.
I can't wait for somebody to take this on with a well-written web or Linux application. Even better if it targeted a domain-specific, stripped-down, locked-down Linux distro that could be netbooted by thin clients around the practice and deployed in a high-availability setup inside the firewall.
>Even better if it targeted a domain-specific, stripped-down, locked-down Linux distro that could be netbooted by thin clients around the practice and deployed in a high-availability setup inside the firewall.
I can hear it now...
"This looks great, but my staff only knows about how to use Windows computers; I'll have to retrain them to use these strange new Lee-nuks things. Can't you just make this run in a little box like on the other guys' systems, so I can keep my Windows PC workstations? I'd like that because our time-clock software is only available for Windows and that will save us having to keep two CPUs and screens on the desks."
Maybe because it was their first (and only) EMR system, but in the practice I worked at, all the initial infrastructure was put in by Allscripts explicitly for EMR, with all other applications being secondary. They sold the boxes, set up the Windows domain, and managed everything. Only relatively recently did they start using it as their own infrastructure, instead of just the magic to make Allscripts EHR work. In that kind of scenario, it could just as easily have been Linux.
> In that kind of scenario, it could just as easily have been Linux.
In any of these systems, any general purpose OS would suffice. There is no real problem for people to move from one platform to another that can't be overcome in a short time.
38 comments
[ 414 ms ] story [ 1857 ms ] threadSo long as health care is a product needed by every individual in the country and remains the beneficiary of some $1T in federal outlays (to say nothing of state and private costs), equilibrium will be elusive. There is far too much money to be made in the churn.
Built by an engineer-turned-physician.
0: http://www.openehr.org/
I obviously don't know the true statistics, but I'd hasten a guess that although EMR costs doctors a few extra minutes per patient but cuts the overhead of maintaining and handling those records by an order of magnitude. If the biggest complaint is information overload (as the article seems to suggest), the whole system could be completely "fixed" with a simple OS X system preferences-style quick search box.
Want to see how drug X affected lab levels of Y on your organization's patients for the past Z years? Good luck with paper records.
Sure, somebody could analyze our 150,000 annual vouchers and figure out some sort of insight. But that's unlikely, as the people who have access to the data care only about payment KPIs, and accessing any data in the system is a nightmare for anyone else.
The scenario you describe is problematic as well. The liability associated with drawing conclusions about the efficacy of a drug based on unscientifically collected data would probably make it difficult to use it to drive decisions.
If we built EMR's for epidemiological reasons, the reality would be totally different.
Supposedly, EMR would replace the biller. The reality is, they replaced the part-time IT died with a FTE, kept the biller and picked up a big "software maintenance" bill.
Other than electronic transmission of prescriptions, the whole process has taken a step backwards from paper.
Someone once joked to me that an EMR installation was where you replaced all the people in your billing department with the same number of people, at a higher salary, in your IT department.
You got a throat ache, but that is not payed by the insurance? uhhmm immediate upgrade to a pharyngitis.
https://www.safaribooksonline.com/library/view/hacking-healt...
Another flaw of insurance covering normal doctor visits.
Imagine this in auto insurance. "Sorry, your car accident coverage was denied because you didn't get prior approval."
Awful because they're invariably run by underpowered servers and delivered via laggy-as-hell Citrix windowing to crappy end-clients with smallish monitors.
Awful because they are all proprietary silos, and good luck migrating your hospital system off one and onto another. The idea of a portable electronic health record is largely a fiction at this point.
Awful because so much of the documentation you have to write has nothing to do with patient care, and more to do with defensive medico-legal CYA, and everything to do with the hospital getting reimbursed at the level it wishes to for each patient seen.
Awful because the software is legacy enterprisey garbage with a codebase written in MUMPS (look it up!) or some other esoteric language in the 1980s and carried forward with ongoing encrustation and decay since then. Awful because the UI actively gets in the way of our patient care workflow, and not the other way around. Need to look at lab data while writing progress notes on a patient? Too bad, you can't open both at once! Need to look at lab data or inpatient notes while discharging a patient from the hospital? Too bad, there are two layers of modal dialog boxes related to the discharge blocking access to anything else while you're discharging.
I've used the two market-leading big-enterprise EMRs in the US, Epic and Cerner, and they're both like this.
I used to write software for a living. The crappiness of even the most expensive EMRs (the ones that will set a big hospital system back a couple hundred million for an initial install, like Epic) completely floors me.
Why doesn't stuff like this take-off? Is it the product of slow-moving hospital bureaucracy, or are there other reasons?
Hospital systems with thousands of practitioners need systems that are many orders of magnitude more complex. The amount of investment it'd take to build a modern hospital-system EMR from scratch is enormous. A well-funded startup could certainly do it, but then there's the problem of adoption to deal with.
Hospital systems are very like big government from an IT standpoint: extremely conservative and risk-averse, even more so than regular big business tends to be ("you'll stop us from using Windows XP when you rip the install media from our cold, dead hands"). You know the old adage that nobody ever got fired for recommending IBM? Well, nobody ever got fired for recommending Epic.
It's very difficult to find an EMR that focuses on patient care and communication. The cynical side of me thinks that there isn't an incentive to build this kind of software. Doctor's aren't paid to make you healthier; they're paid to submit to insurance companies the correct diagnosis and procedure codes.
I can tell you that most clinicians would be jumping for joy if software that was more physician- and patient-oriented became the norm.
It's very easy for the HN demographic to forget what it's like to use an "average" Windows machine. Startup and login times in the minutes to tens of minutes, extreme disk latency everywhere, nagging popups to update Java (has happened in my doctors' office more than once) and virus definitions, etc. Cheapass hardware is frustrating by default.
A surprising number of network-based Windows line-of-business applications are written with inexcusable naïveté - the application simply doesn't respond while waiting for network/server and a request that gets dropped or whatever will render the entire application inoperable for several minutes (or some other irrationally high timeout, if there even is one) unless you kill and reopen it.
Because Windows desktop management is so brittle/difficult/expensive and so many applications don't play well with MSI, updating is a manual process of walking around the practice and waiting for computers to be unoccupied so that you can load the new .exe onto them. In practice this sometimes just doesn't get done.
Add on the incredibly poor software quality that comes with lowest-bidder offshore development, zero attention to UX, and very aggressive and well-funded sales teams, and you get roughly the situation we have today.
I can't wait for somebody to take this on with a well-written web or Linux application. Even better if it targeted a domain-specific, stripped-down, locked-down Linux distro that could be netbooted by thin clients around the practice and deployed in a high-availability setup inside the firewall.
I can hear it now...
"This looks great, but my staff only knows about how to use Windows computers; I'll have to retrain them to use these strange new Lee-nuks things. Can't you just make this run in a little box like on the other guys' systems, so I can keep my Windows PC workstations? I'd like that because our time-clock software is only available for Windows and that will save us having to keep two CPUs and screens on the desks."
In any of these systems, any general purpose OS would suffice. There is no real problem for people to move from one platform to another that can't be overcome in a short time.