Hacker News Reader

Comment by petermcneeley | Hacker News Reader

Medicine seems like a technological wasteland. They put "notes" into text boxes and call it "using computers".

I wish I had both CS/SE experience and Medical experience so that I could understand what keeps this field in the 1970s. I have suspicions.

View on HN

In my experience, it's a combination of a couple of things. First off, the field is heavily regulated (in the US anyway) and the penalties for violating regulations like HIPAA are incredibly high. Second, the field is currently dominated by major players such as Epic, so its pretty important to be compatible with them, but they don't really have an incentive to open up their ecosystem since they have such a stranglehold on the market. Finally, a lot of medical folks have been burned by technology in the past, and, in my experience, often view a lot of the tech they have to use as an insurance and government mandated evil, rather than a way to make their lives better.

Not to say things can't be improved, but there are a lot of factors that make it more difficult than a traditional B2B or B2C product.

The Epic ecosystem is actually pretty open now. They have multiple web service APIs with full documentation, and even provide a developer sandbox you can use to test client applications.

https://open.epic.com/

Epic also has an app store. You can write your own SMART on FHIR apps, then deploy them inside the EHR with full access to patient data.

https://apporchard.epic.com/

The full FHIR standard can be a lot at first sight https://www.hl7.org/fhir/ but I'd recommend anyone having to store names, addresses or contact information to check how they do it. The last example for names is always fun: https://www.hl7.org/fhir/datatypes-examples.html#HumanName

> Finally, a lot of medical folks have been burned by technology in the past, and, in my experience, often view a lot of the tech they have to use as an insurance and government mandated evil, rather than a way to make their lives better.

Simply: those who choose the software are not those using it. So they go for recognizable names, certifications and how much money they'll get back for themselves.

> First off, the field is heavily regulated (in the US anyway) and the penalties for violating regulations like HIPAA are incredibly high.

This is why heavy handed regulation is bad. The people on the end of the regulation have to deal with a ton of BS to the point where it becomes security theater. These systems need their own departments, experts, and even legal teams. The overhead is massive.You think a company is going to roll over and eat the costs without trying everything in their power to side step it? Loop holes to outright lies will be used. Anything to trim the fat.

Happened to a place I worked at. New regulations meant more overhead. During my tenure I watched the quality department grow from the side job of the head engineer to a department of three people (manager, assistant, engineer) and an outside contractor. I then watched the employee quality drop proportionately as they put more money into putting lipstick on a pig than actually fixing problems and improving quality. As long as you satisfy the auditor or customer you look like a well oiled machine. Just don't look under the rug.

The regulations are outdated (fax is considered secure communication, as I've harped on before.) There's no patient visibility into these systems, so they don't see just how outdated and broken they are. I think that the biggest problem is this relentless focus on the short term-upgrading systems will cause problems now even if in the long run they'll pay huge dividends. Sort of similar to how medical professionals work extremely long hours with inadequate sleep.

I used to work at Epic as a software developer. My take on it is that the key explanation for why medical software is so bad is that it is so hard to even attempt to compete with established EMR's.

I could go on at length about this but I'll try to keep it short. Basically, imagine that you're a startup and you want to compete with Epic in providing a comprehensive IT solution to health systems. You will _at least_ need to:

1. Write software for every major medical specialty that is comprehensive enough to satisfy the specialists' expectations of domain-specific tailoring

2. Also ensure that these modules are flexible to accommodate intra-specialty variation (for example, oncologists vary a lot in how they divide stages of cancer)

3. Ensure that your software will comply with and help your customers perform well financially with federal, state, local, and program-specific (Medicaid, Medicare...) regulations

4. Go into a room full of health executives who are deeply weary and suspicious of health IT people (for better and worse reasons) and convince them they're better off risking a multi-year, extremely expensive transition project on your startup, which might not be around in a few years, instead of going to an EMR vendor that's almost-not-even-mediocre but stable like Cerner or Epic. (The "nobody gets fired for buying IBM" effect here is real.)

Clearly all of this requires a lot of work, and would require millions of dollars in funding and the poaching of some top talent in healthcare IT who know the lay of the regulatory land. As a result, most HIT startups (that I know of, at least) target something less ambitious than an enterprise EMR. Some target only a specific specialty (like home health or care management), others target small family practices (which are becoming increasingly rare as they are bought out by major health systems).

This is in a way bad for everyone except the software vendors, though, because without a competitive threat, there is little incentive for companies like Epic to undertake the risky, major rewrites which are vital for the company's long-term technical health. Epic still uses a typeless, (almost) data structure-less language called MUMPS for its server and DB code, and on the client side, all of it is still either in VB6 (yes, 6, not .NET) or a quite spartan home-grown JavaScript framework. The result is that bad code never gets totally thrown out, and Epic's developers are not able to benefit from the productivity-multiply amenities of modern languages, which include type systems and abstractions more powerful than subroutines and goto statements. Development then takes an order of magnitude longer than it might have, and the feedback cycle continues.

It seems like most of these articles focus on the documentation side.

There are other elements, like med/consult/lab/diagnostic imaging orders going to the relevant person/department instantly. With a handy interface for following them along, cancelling or re-scheduling them at any time.

A nurse doesn’t need to follow a provider around to find out what the new orders are, they show up automatically on their own task scheduler.

Providers can enter orders remotely.

Or allergies just getting verified instead of collected from scratch each visit.

Or billing/appointments happening electronically instead of manually completing forms.

This is true, but the interaction between the doctor and the nurse was invaluable. The context of those orders and the nurse's knowledge of the patient were used to come up with a plan together. Reducing that interaction to "order giver" and "order taker" greatly reduces the quality of patient care. I was recently in the hospital for a week and this was an issue several times.

That asynchronous behaviour happened in the paper world too. Make chart entries, send paper orders to pharmacy/lab, flag it for the other care providers.

There is a lot of copying and pasting data from one system (i.e. lab results) into the other. This is probably rooted in distrust of the system and fear that the lab results will become unavailable combined with a healthy amount of "cover-your-ass" syndrome.

https://www.newyorker.com/magazine/2018/11/12/why-doctors-ha...

The systems are built to serve administrators, not practitioners.

I think this is very much the case, and most administrators are looking to make sure that billing tasks are completed in a quick and fulfilling matter. IMHO, this is where people should be concerned: one of the primary goals of these products now becomes collecting the data that the insurance companies most want collected.

Some industries require higher table stakes than others, in the form of a defensive patent portfolio.

A principal of a failed medical records startup described it to me as an incumbent coming to them and saying basically "You have a nice disruptive startup. But we don't want to be disrupted. We have some patents. Their details don't matter. Our <unit of time> legal budget is greater than your last round of funding. End of game."

A blend of regulation and complex sensitive domain.. the medical field tried a few time going computerized, it failed badly. Half because of project management issue, half because of the field itself .. I think there should be a dedicated CS staff to grow solution cheap and on the fly rather than large upfront monolith that will fail to actually deliver value to patients and employees

There are multiple reasons for this, in no small part because what people think EMR's are and what they really are is very different.

Medical tech has the seemingly simple barriers voting has, but that once you incorporate it into a system they because heavily limiting and expensive.

I'm a Dr who has just quit my specialist job for the 2nd time to pursue a startup.

You'd think I'd do something medical - I've been in the field 10 years, I should have been able to find a problem IT can address?

To be honest the thought of doing a health IT startup just fills me with dread.

Reply on news.ycombinator.com