As other comments mention, this project has been going for a while, the central reason it (or something like it) has not been robustly built out and deployed universally is because of the way congress chose to structure the funding for development of EMRs/EHRs. Rather than trying to find a system that could be universalized, the (idiotic) plan has been to give millions of dollars to multiple corporations to develop systems, then subsidize the purchase cost to providers to encourage adoption. Then, only once everyone has invested in their own proprietary system will they begin trying to universalize the system by developing cross compatibility. This methodology is perfectly in line with the free-market approach that the US has championed for decades. It is also the opposite of how almost every other country has developed and adopted universal EMRs. Sad. Especially because we know that a good, affordable universal EMR would significantly enhance the ability to deliver care for almost all sizes of healthcare providers.
As a programmer for an American EHR firm -- all of the market share already belongs to one of those companies you malign.
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.
But most physicians don't work for hospitals. They work at small practices with 10 physicians or fewer (according to the AMA).
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.
The issue with small practices and even slightly larger physician's groups is that an EMR is often just a cost, with very little benefit.
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.
So I am a physician with a large hospital system that uses Epic. I think your comments about poor communication (btw Epic systems) are outdated. For the last two years when I admit a patient I can easily access all Epic records not only in other hospitals in my state, but in the country through their system labeled "CareEverywhere". It is a game changer and is really the main reason why I rank Epic above other EMRs I've used.
It is primarily through deterrence. Anyone allowed to use an EMR must go through training about HIPAA rules. A waiver is sometimes required that Epic asks you to print out and sign and put in the patient's chart (although they obviously can't prove you did this, it would be an issue if there was a problem later and it turns out you didn't do this, i.e. You would be liable for whatever penalties/prosecution). Furthermore, all usage is recorded and occasionally audited in my system. I'm not 100% sure the auditing is a requirement and true everywhere (definitely with any hospital or large clinic it will be).
Also, in reply to who is accessing your records you don't know. I suppose you could ask for records of who had accessed it by a certain date, but once your records are in there they will likely be accessed by your insurance company for billing purposes.
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...
Thanks- ideally the auditing would be done regularly, and require a reason to be entered for any access the first time a new provider accesses your information. Even better each patient would have a USB stick with a One Time Token generator that would 1) hold basic emergency information on the USB drive) 2) Generate One Time Keys to grant access to new providers. Of course, in an emergency situation where a provider has an ID but can't find your USB key, they could enter an over-ride with a reason- which would be strictly audited. Also, patients should have a list of who has accessed their information and why- and even be able to sign up for alerts anytime someone new accesses it.
So I think your ideas are good, but you have to realize the multiple competing priorities in healthcare. When you say ideally, you mean from a privacy standpoint. In my opinion "best health outcome of the patient" should be the highest ideal.
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 see your points- I agree that "best health outcome of the patient" is the priority. I don't think that is always at the cost of privacy, though. In fact, if people feel more secure about the privacy of their information, they will be more likely to be open and to even visit a health care provider in the first place. (Some people may not care either way, but there are those who do- and certain circumstances that people are more likely to care about than others).
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.
I agree that the challenges aren't unsurmountable, but we have to make sure that we realize everything we change has unintended and unforeseen consequences, even things that seem as simple as adding an additional click or checkmark.
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?
That is great for other accesing records from other hospitals that use Epic, but what happens if you want to access the records of a patient who also visits a VA or Cerner hospital? You are still in the dark.
Absolutely, I still have to fax and it's ridiculous how low the bar is. I was just replying to the op that just the fact that Epic can talk to itself at other hospitals (for the record the VA can do this too, but it is slow) makes it relatively great.
What I see happening is that eventually there will be so much merging of our healthcare systems in the next 10 years that there will eventually be a point where there are only several "players" in any area meaning that the problem of intercommunication becomes much simpler (i.e. Epic, Cerner, and Medtronic).
Unfortunately with the consolidation into medical "groups" that has been going on among doctors and with the hospitals offering "deals" along side those vendors they use for the doctors to adopt them, a lot of doctor's groups have adopted whatever system they are most integrated with's EHR.
The small medical practices are rapidly disappearing. Providers are consolidating in order to have more negotiating power with payers (insurance companies), and the payers and in turn consolidating to have more negotiating power against providers, and so on.
Not entirely related, but the pain of the "paper cycle" as a "customer" of health-care is real.
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.
I am actually not opposed to the "CD you have to buy" policy. If I was hospital network admin I would not want people just plugging in random usb sticks into my network.
I think the expectation is that these organizations should be able to send this data to each other. That they was put the data on a disk and then give that to a patient who the drives it over to another part of town and hands the disk over is a ridiculous waste of everyone's time.
It also highlights how far the entrenched vendors and hospitals will go to keep their customers "locked in."
And in most cases they can send that data to each other, at least in the sense that their existing systems are capable of interoperating based on open standards. But to make it work the provider organizations often have to configure and test data interfaces with other organizations. That's an expensive process and no one wants to pay for it.
> The crux you may not realize is how customized every major hospital system expects their EHR software to be.
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.
>Cerner, Allscripts, and others aren't much better.
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's simply false. Hospitals and other large provider organizations often do insist on extensive customization and non-standard configuration during EHR implementations. I've seen it happen. They'll spend weeks going around in circles about ridiculous issues like the placement of a logo and the format of a lab result document. You really can't blame the vendors for that.
All enterprise customers are stupid about COTS customization.
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.
Labeling something as "legacy" is a lame basis for criticism. Customers don't care about the age of a product's code base. What matters is price, functionality, and support. If you want a non-legacy EMR just for the sake of novelty then there are plenty of options available. But they aren't necessarily any better.
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.
>Rather than trying to find a system that could be universalized, the (idiotic) plan has been to give millions of dollars to multiple corporations to develop systems, then subsidize the purchase cost to providers to encourage adoption. Then, only once everyone has invested in their own proprietary system will they begin trying to universalize the system by developing cross compatibility.
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.
I don't think we will ever see HL7 messages exchanged between organizations. Each product has it's own list of message types that they support, and even then they will vary in terms of which segments have data and in some cases, even what that data will be. Patient identifiers also vary between organizations, making it hard to know which patient goes with which piece of data.
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.
I work at a top 10 EMR on the interface engine team. Messages between products require a lot of custom work to align message types and IDs, establishing a compendium of identifiers for external labs and identifiers, but it's not uncommon.
Yeah, but I can't take my data from Epic and move it all into Cerner via HL7, no matter what.
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.
You haven't been paying attention. I've been working on products which exchange HL7 messages between organizations for 20 years. It's very common now. Some configuration work is usually needed on each interface but that's mostly a solved problem.
I think he likely meant "I don't think we will ever see HL7 messages exchanged between organizations [routinely and with little effort]."
"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.
My experience has been closer to that of
mcphilip, every time we bring in a new system we end up with consultants from both sides (the new product and the hospital information system) and the cost is quite high. Where I work, exchanging HL7 messages directly with another organization has never been on the table and we have done a couple interop projects with other area hospitals.
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.
My experience is that "some configuration" translates to 6 months and 50k$. Especially when the really big vendors are involved and when those vendors have competing products.
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.
>affordable universal EMR would significantly enhance the ability to deliver care for almost all sizes of healthcare providers.
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.
I work in this space in the private sector. From my perspective, the greatest impediment in the U.S. relates to our laws regarding PHI. I work on a system with petabytes of medical data -- but researchers can't access it because our laws and regulations don't support it (and thus provide no financial incentive and only risk and lawsuits for the companies holding it.) It's abysmally sad.
Well, PHI protection (HIPAA) is actually a good thing and doesn't really prevent researchers from accessing data as long as PHI is stripped (de-identified dataset). Now getting that de-identified data is not always easy...
Now you've hit my area of expertise. This might help enable large retrospective cohort studies but would not be sufficient. In order to do that the universal system would need to do several things which are unlikely: 1)Universal clinically meaningful data model 2) Extensive use of standard terminology codes 3) good model of timeline 4) user interface which encourages the entry of discrete data over free text
> This methodology is perfectly in line with the free-market approach that the US has championed for decades.
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".
Ah, but then you ignore the many years of deliberate effort by politicians to equate "privatization" and "public/private partnerships" with "free markets", to the point where OP's statement is perfectly reasonable in light of history.
My undoubtedly imperfect emulation of a libertarian wishes me to note in response that that's just the sort of thing which a statist politician, heavily invested of necessity in the status quo, would say, and that there's no reason why we should lend the claim credence just because it's been around for a while.
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.
> Rather than trying to find a system that could be universalized,
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?
If the government has to get involved, it should be on helping (forcing) to define a flexible/complete vendor agnostic data interchange model that patients can carry along wherever they may go. The rest is just GUI, bells and whistles.
The Office of the National Coordinator has been helping on some aspects of that through support of the HL7 Consolidated CDA (C-CDA) initiative. So we do have a vendor agnostic data interchange format. But typically patient records are sent from one provider to another; there's still no good way for patients to "carry" their records.
Your statement is factually incorrect. The US federal government has given little or no money directly to EMR vendors. Instead the HITECH Act grant funding went to providers to reimburse them for purchasing and implementing EMRs. And in order to receive that funding the providers had to demonstrate that they were actually using their EMRs in a meaningful way.
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.
Why is the almost no other coverage of this if it is indeed legitimate evidence of some connection? Even if it's its just conspiracy theory, I'd have thought people would be all over it.
If correct, the comment from jasode is much clearer at explaining the point of the site than the landing page. I got it that they were comparing brokers, but its not clear that this is the point of the site.
