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.

How do they prevent abuse? How does a patient know who is accessing their records?

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.

Good to hear it's gotten better!

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.

There's a ton of slimy dealings going on sadly.

That's changing. Big hospital systems are swallowing up small practices. Old school medical practices are dinosaurs.

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.

I think that the big push to move to EHR's was actually started by Bush. I am sure that Obama continued this push though.

> 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.

Legacy isn't a dirty word.

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.

> You really can't blame the vendors for that.

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.