You could not have had the government sponsor some new software which would eliminate a billion dollar software market.
It's a non-starter. All the hospitals already are signed on multi-year contracts with those large providers. Some of the EHR providers began writing medical software for hospitals in the 1960s and 1970s. These companies have multi-decade relationships with the hospitals they service, and decades of patient data stored.
What Obama and the Democrats did was to break the "paper cycle". Many hospitals used paper-only system with very little software even into the 2000's and 2010's.
The point of investing in each company was to jumpstart their products into meeting the huge new regulations, and the point of giving clients money to buy this new software was to break the paper cycle.
There is no "one size fits all" option in the American market.
I find it funny that you malign our practice as "(idiotic)" when it is your plan, quite frankly, which is so ignorant to the complicated history and reality of medical providers and their software, that seems idiotic to me.
Your opinion sounds to me like "The US Gov should, instead of using MS Windows, pay a company to invent a new operating system, then ban all use of Windows, OSX and Linux to ensure all firms must use the single new solution".
We already had so many options that have existed for decades, with so many clients, and so much built-out software infrastructure. There was no "one-size-fits-all" solution unless your solution includes "Destroy the entire industry, and use force of government to destroy a half dozen major software companies in favor of the government mandated and almost assuredly inferior option"
The crux you may not realize is how customized every major hospital system expects their EHR software to be. I don't think you realize the sheer level of customization these networks require, due to the size and scope of their businesses. It takes entire teams of my company to service certain major clients. The idea of a one-size-fits-all would have been laughed out of our country.
There was a completely open market, made of the majority of physicians, regardless of existing provider contracts with hospitals.
I know I talked to a few physicians (and other healthcare professionals) in the mid-2000s who lamented the paperwork they had to do every day and the lack of available computer automation.
If you're a hospital with lab facilities, imaging facilities, surgical facilities etc. it's hugely useful to have medical records flow internally (quasi-)seamlessly. The EMR does that well, and the large cost of typing things into the EMR (it's slow, painful, annoying, never met a doc who preferred it to the old clipboard and notes system) is totally worth it.
For a small practice, that intercommunication problem isn't anywhere near as large, but the cost of typing things in painfully is the same. So small practices hate it.
And before you say, "but it's useful to share medical records between offices/specialists/hospitals when they move around", it turns out that a lot of these systems don't play very well with one another. Even between two healthcare systems that share the same software provider (in this case Epic, one of the big two, the other one is Cerner), I've heard people finding it easier to print it out, fax it over, and scan it back in. Yes there are people who want to solve that problem, (see YC's own https://www.patientbank.us), but it's a tough area because who pays for the service? How expensive is it to build software that interacts with all the 10 zillion different flavors of Epic? How do you harmonize the peculiarities in how people actually record the data in those systems? It's really really hard.
You can add an additional layer of warning in Epic. I see this most often with psych records or pts who want an extra layer, such as if they work in the same hospital. All this entails though is an extra prompt warning requiring you to put in a reason why you are accessing the records, and put in your usr/pwd again and warns you it is being recorded, etc...
Say I am working a night where I may be paged on 100 patients who I am meeting for the first time. Just opening their records on The EMR eats a significant amount of time. Time which I need to take care of people. Adding an additional click would mean even less time and poorer outcomes.
You also have to realize that nobody is going to carry a USB. I have worked in diabetes clinics where most pts don't remember to bring in their glucometer, which is the entire point of the clinic. You have to realize that the patient population also includes the average American (and half by definition are below average intelligence.)
I mean, I could go on for hours and make my own personal list of the issues with American Healthcare and I wouldn't list pt privacy in the first 100....
Not trying to be dismissive but I'm just trying to give you computer technical folk an idea of why EMR is such a hard field and how many factors you have to consider which is really difficult if you aren't 'in' the system. Even I who knows more about programming than 99% of docs feel completely ignorant when I talk to healthcare IT folks about HL7, etc...
I don't think the challenges you mention are unsurmountable-
An ER doctor seeing 100 patients a night might have the system setup to automatically log in as an emergency, and they already need to log the reason for the appointment- or else there is no there is no record of it...
Setting up the initial access should be handled by staff during check-in for non-emergency visits.
Patients are generally already expected to carry a health insurance card (at least in the US- not sure how that is handled in countries with Government provided health-care). As the system becomes more widespread, it would become normal for everyone to have a security token, and they could use those tokens for access to multiple systems, not just health care (The USB disk thing is probably optional, just a slight improvement for when the network is down or you can't otherwise access the information).
I also think the User Experience on the systems I have seen could be greatly improved to reduce unnecessary clicks- and I have noticed that more often then not though- loading information over a slow network takes more time than navigating the GUI.
I would agree that the problems with health care go far beyond EMR systems, but they were the topic of the discussion.
Thanks for participating, I want to better understand all of the issues and these types of discussions help a lot toward that goal.
You are right there are those who do not seek care because of privacy, but in my experience they are by far a minority compared to the people who don't get healthcare because there aren't enough providers to get an appointment (mostly because they are all already too busy and overwhelmed to take on new patients), are worried about cost, or who just are in denial about how sick they are.
The deal with insurance cards though is that there is no problem or issue if you don't remember to carry it. Registration can still be done, they just look you up by name, address, or SS# if needed. Not to belabor the point (because as you mention you could use a network) but any system that depends on people carrying something will have a lot of caveats.
No matter what you pick it will sometimes not work, the network will be down, the USB flash memory will no longer work, the USB port will be broken, etc... so there will have to be a non-emergency allowance for 'token' system not working. How are you going to verify it really isn't working and that people aren't just clicking 'not working' because it is easier (or because they are malicious and lying to steal data...).
With regards to automatically logging people in: Consider your ER doctor system, ok that works when it is logged as an emergency in the ER. Now consider my role. I am a hospitalist, meaning I admit patients to the hospital and take care of the ones already admitted. Should I already be covered under the emergency since they are sick enough to be in the hospital or do I have to go through additional steps to log in to address a patient who just needs some extra nausea or pain medications or a sleeping pill? If I have to log in it detracts from the time I can spend dealing with a patient who suddenly has a more pressing issue (such as new chest pain that needs to be seen)? Of course, I am going to see the chest pain patient and so the nauseated patient is miserable for a few extra minutes. Now this sounds like squabbling over a loss of seconds but in reality managing an inpatient service is juggling multiple pages at once for sometimes several hours straight on many patients, triaging what needs to be done urgently vs later, and admitting patients, etc... It can be nonstop. So just one additional step really does add up.
So you can then say, why not have it set up that once a patient is admitted, they get logged in once and then you don't have to worry. I would then answer that that is basically what we do now. When you get admitted to the hospital you sign a release which covers this.
I will bring up another issue: you say a new provider should only have to log in once. Do you really want a provider you saw maybe 5 years ago for a one time visit have access to your records. How long until they have to reregister?
Another issue: What if you have tests done that aren't resulted by the time you leave the hospital. For example you have a blood culture that becomes positive after 5 days which means you need to be notified to get new labs done. The doctors that took care of you are off shift or on vacation. Usually this is taken care of by another provider, who you may never meet, are they going to be covered under the token system?
Out of curiosity what is your background in this since you mention User Experience?
There's a ton of slimy dealings going on sadly.
It seems as if to avoid dealing with hipaa regulation it's all paper, fax machine, and come pick up your x-rays burnt on a cd during your work hours (cd that you have to buy).
Having not grown in the states, this type of practices seems very primitive to me. Amongst many other aspects of the American healthcare, but that's another debate.
It also highlights how far the entrenched vendors and hospitals will go to keep their customers "locked in."
The crux that you may not realize is that this customization was done mostly to boost profits and promote vendor lock-in. This was aided by the .gov failing to make public and standardized requirements for things like medical records (and no, referring to an AAMI or whatever doc that costs serious coin to view doesn't count!).
> . There was no "one-size-fits-all" solution unless your solution includes "Destroy the entire industry, and use force of government to destroy a half dozen major software companies in favor of the government mandated and almost assuredly inferior option"
BULLSHIT. Epic is built on MUMPS, arguably one of the worst languages ever designed. Hyperspace is garbage. Their systems are garbage. They get by because they've attached like gigantic leeches to hospitals. Cerner, Allscripts, and others aren't much better.
> Many hospitals used paper-only system with very little software even into the 2000's and 2010's.
Feature not bug--notice how much more physicians and nurses seemed to like those systems.
~
Look, your entire industry is fucking cancer and the sooner the .gov decides to use truly open standards the sooner some hungry companies can clean out all the garbage you and others have managed to clog institutions with. You should be ashamed.
Allscripts is a dumpster fire. I'm quitting my job that deals with them in the next 6 months and traveling.
Most of the EMRs established lock-ins when interface design was still pretty primitive compared to today: before WPF, C#, decent browsers, and javascript libraries. This sucks because we have to deal with extremely verbose code in laying things out. Meanwhile, modern web and desktop design has skyrocketed ahead of these old beasts, so they look extremely dated when we'll soon have a new generation of med students walking in who have grown up with mobile phones, tablets, Chrome, FireFox, IE11, and Win 7 and their beautiful interfaces and design by comparison.
That doesn't change the fact that the software surrounding the entire medical industry is largely ridiculous legacy crap maintained by a little cartel of fat & lazy vendors with a captive market.
With good reason btw... these systems were the earliest big data processing shops. Blue Cross and Medicare was doing centralized billing for healthcare since before fax machines were popular.
But the fact is that these ancient systems are nightmarish to work with, and because they are so ancient, they predate many of the standards and capabilities that modern systems have.
I spent a decade working around a big legacy system originally built on a Sperry mainframe in the mid 70s. The system was awesome in some ways -- amazingly performant, efficient and well tuned. But the reason it was so awesome was it's downside as well... it is almost static, changes are difficult/impossible to make. In the EMR space, things have to change, but because it uses an ancient/domain specific set of artifacts, you're stuck with a small number of incumbent vendors with whatever functionality they are willing to do.
To quote the great Henry Ford: "Any customer can have a car painted any color that he wants so long as it is black."
They've empowered the clients to keep doing stupid things because it's good for business.
This is misinformation. Interoperability via HL7 messages has roots in the 80s. The subsidies encouraging provider adoption of EMRs during Obama's administration set constraints on qualifying EMRs including a certain level of support for interoperability. The government sensibly leveraged existing standards produced by those free market forces you decry.
Alternative methods for passing data between organizations have been proposed, but the vendors as well as the hospitals have been fighting this tooth and nail. The big EMR vendors are dragging their feet (and cashing government checks) but hospitals aren't pushing for this functionality either. IMHO, hospitals also would prefer to keep patient data to themselves.
What we need are government standards for data at rest, similar to DICOM, for other data - and tied to Medicare reimbursement. Literally some functionary at CMS could write that rule and patients would be better off.
"some configuration work is usually needed on each interface" is the key phrase in your response. Just because many organizations have poured cash into yours and your competitors' solutions when the economic stars align does not mean that message passing between organizations is a solved problem.
That said, in my opinion the two organizations looking to exchange messages would need to have a pretty good relationship and a real business need in order to pursue this strategy. They may also have to compromise on dictionary values, etc., in order to have comprehensible data on both sides. For organizations with even a modest amount of rivalry, I can't see them spending this kind of time, effort and money.
My understanding was that "meaningful use" would make interop much easier, perhaps on a higher level than HL7 messages. In my experience this has not been the case.
HL7 is literally just a syntax, and one that isn't reliably followed at that. It makes no solid guarantees about the semantic structure of the messages, and so is next to worthless.
For a simple analogy, consider that two companies have agreed to write contracts in English--and little else.
Additionally, it would open the door for EHR-based research on a massive scale. Getting different hospitals' EMRs to play nice with one another is a huge barrier for large, retrospective cohort studies. Projects like the Million Veteran Program (http://www.research.va.gov/mvp/) would be just the beginning.
Not really a libertarian myself, but were I to pretend for a moment that I was, I'd say that this statement of yours could not possibly be less accurate, and that federal interference of this sort is the precise, diametrical antithesis of what is meant by the phrase "free market".
He suggested following that up with what I believe to be an Upton Sinclair quote, but I'd rather eat my supper than participate in an argument over Mises and Rothbard, so I think it's time I snapshot and terminate the running instance.
By "system that can be standardized", do you mean, e.g., defining standard data content, representation, and interchange formats and perhaps funding one or more open source implementations, or creating and mandating a single mandatory software system?
Most other countries don't have universal EMRs, and the ones who do aren't necessarily happy with them. One size doesn't fit all.