Hacker News Reader

The added complication is also because insurers refuse to pay providers unless every procedure, billing code, time of service, justification, physician notes, physician network accreditation, etc, etc is to their standards (which changes often) Health care providers have teams of full time admins who doing nothing but chase after insurers for missing payments and billing discrepancies. Insurers will delay payments, change billing codes, and refuse to pay pending audit, and then may decide not to pay at all. Doctors are pulled into doing extra admin work mostly because insurers wont pay them if the paperwork is not to their standards, or the patient doesn’t qualify.

I think this is closer to the truth. The problem is rarely "outdated regulation" (although that's what the organizations that build these systems will say) and more that there's so many cooks it becomes impossible to build anything worth anything. Everybody has an opinion about their little corner of the system, and no one is willing to understand anyone else's opinion. If you bring up some fundamental disconnect between the wants of different stakeholders they point to the current system and say "It works there", and ignore the fact that it doesn't actually work.

It's a problem of too many unfounded opinions, and too little actual engineering.

> Everybody has an opinion about their little corner of the system, and no one is willing to understand anyone else's opinion

This is true. If you talk to someone in insurance, fraud is a huge problem, and doctors providing expensive treatments for the wrong conditions is also a huge problem. They are society's defense against doctors prescribing exotic $20k/month cancer medicine for allergies because they heard a rumor it was 5% better than Claritin, and sending every patient with a cough to their brother-in-law's MRI clinic. And this is true to some extent (especially about the brother-in-law's MRI clinic.)

If you talk to a doctor, they won't outright say it, but they're committing insurance fraud on the daily so they can provide basic care. If they talk to a patient about how they've been eating differently since their spouse died, or they spend ten minutes coaxing details about pain from somebody who is reluctant to talk about it, they're going to bill that time as something they're 100% sure the insurance company will pay for. So it might go down as a consultation about blood pressure. Maybe they even think there's a good chance the insurance company will pay for it, but between the insurance companies constantly changing things and the doctor not having complete confidence in their office staff to figure out the right code, they just write down something that they're sure about.

I don't know what happens if you put a doctor and someone from an insurance company in a room together. They probably have a system of polite lies to tell each other.

> brother in law’s MRI clinic

This is a Stark law violation and there are clear rules against it

> The regulations were designed for blood pressure monitors and insulin pumps.

Then again, in US, EHR systems (epic and cerner comes to mind) are not regulated by FDA

I used to work for a regional healthcare system that also owned an insurance company. We had to deal with many more regulations on the insurance side than on the provider side.

Everything about health IT systems is terrible, from protocols to classification systems. A lot of the problems predate regulations. On the other hand, health IT mirrors the real-world systems it meant to service - complex, rigid, and self-serving

What specific regulations are you referring to, that apply to EHR software and the like? I know things sold as medical devices/appliances require FDA approval, but for general electronic healthcare record systems (e.g. Epic), what applies other than of course the security/privacy provisions of HIPAA?

It permeates the systems. For example, any time you want to update the complement that sends e-prescriptions the network will want you to recertify the system for conformance to requirements.

Seems like a better solution would be making the recertification an easy fast automatic process, not skipping it entirely

I doubt very many people skip recertification, because of the risk of losing it.

They are saying, in other words, the answer is not to remove regulations but to fix broken implementations of them.

I’ve worked with 62304 and 13485

Their very existance is a regulation that gets in the way of care. Doctors are in many cases required to keep databases of patient records and they have to be digital. Well that shoehorns them into using old bloated ehr software that takes forever to use when they could just use paper

> Outside of healthcare if you see something broken then you can just fix it, maybe rope in your manager.

Your manager who then proceeds to ignore the request for improvement in favor of adding telemetry, dark patterns and advertising.

Regulations such as CFR 21 Part 11 have a known quantity of dead people behind it. It is not regulation for regulation’s sake.

“Move fast, break things” is not how healthcare infrastructure should work.

This is the standard response, but we’re not measuring the deaths caused by bad software. Bad software causes deaths by:

- user error

- It’s expensive so people don’t get treated in the first place

- doctors making treatment errors because they couldn’t see the whole picture because they couldn’t work the software

Also the non-regulated software is observably better and more reliable than regulated software. The author even compares regulated software to non-regulated software in the article.

Paradoxically ensuring that an error is never made reduces the probability that the system will do the right thing.

There's no noted causation between poor software and patient death.

There is a high correlation against "move fast, break things" and patient death.

There’s a middle ground between “Move fast and break things” and “Don’t make any changes in case you break anything”

Asymmetrical risk/reward profiles breed hyper-conservative behavior. Legacy support and "if it ain't broke don't fix it" attitudes have negative externalities.

A good case study is the NASA Space Shuttle program and how expensive it was especially when compared to SpaceX. Not to downplay the sheer achievements of NASA by any means, plenty of people there are much smarter than I am.

The solution isn't just "ignore the risk", you have to do something fundamentally different (with strong conviction, investment, and leadership) in order to restore symmetry to the risk-reward profile, such as a truly best-in-class testing infrastructure. Operating your business as a meritocracy doesn't hurt either (although I suspect pure meritocracies to be impossible/unfeasible to implement).

Making your point even more stark, for whatever reason the UI that you're forced to use can be substantially changed by your vendor every ~6 months and there's nothing you can do about it.

That is not what happens in health software, the UIs tend to stagnate for years with bugs, so users don’t have to learn new workflows.

Not sure why this comment is dead.

You’re partially correct that a fair bit of health software is stagnant and fixing bugs takes time (although not years) but when discussing EMRs, especially the biggest player (Epic), they fairly regularly change the UI and I’ve had to learn a new workflow at least once a year for the last decade.

I think Im IP banned

Depends on how important the software, it seems like the more safety critical the software, the more likely it is non-critical UI bugs are left to fester until the bug becomes safety critical

As a user of Epic, I can tell you that my comment about Epic’s changing UI is what happens unfortunately. This has been true across two major US academic hospitals.

But you are right, other things are certainly left to stagnate.

It's hard to find the right solution. Users complain when the UI changes, for better or for worse. Users complain when the UI doesn't change and looks 10 years old. There's no good option

Yeah until you have to rollout a bugfix that changes the build of their system and totally reroutes their workflow. Its not like a graphical UI change but permissions updates, config updates, etc can all have impact that end users would consider a UI or workflow change.

Perhaps that makes sense if you can't release anything with more substance due to regulation, but need to show you've done something to validate the company. Customers likely recognize a UI change over a bug fix, so bug fixes are deprioritized.

(IANAL.)

> Outside of healthcare if you see something broken then you can just fix it, maybe rope in your manager.

For the sorts of software stuff the OP is discussing, you can do this inside of healthcare, too. I work in healthtech; in our company, a simple change can go from idea to deployed in prod in a few hours. (And a lot of that delay is our CI system or code reviews being slow, but not regulations.)

That's not to say regulations can't slow things down: I've seen some things take longer because of them. But it's things like "are we doing security adequately?" or "we need to retain these records", etc. Things that (speaking as a patient looking in) we should be slowed down to think about or do, frankly.

> Inside healthcare regulations you have to start a massive change control process which involves several busy people to approve it.

But this isn't entirely fiction: we integrate with a number of providers, and particularly there, these processes do exist. I've been on any number of calls ranging from 10pm to 2am where we're coordinating a production change, usually mostly on the provider's side. (We try to have our own change lined up so that, if at all possible, the 2am "change" is just "enable it". It's 2am, after all — you're basically already incapacitated due to sleep.) Moreover the changes are made frustrating by there usually being a whole pile of them: if you can only make changes once per month? quarter? at midnight, then everybody's changes get smushed together. It's not good, and SWE as a larger industry has (IME) moved on from this anti-pattern, but it persists in some places.

But HIPAA doesn't require this.

I can't speak to hardware.

> A patient data portal is orders of magnitude more complex.

It's funny, because as a patient, my data "portals" still routinely fail at seemingly basic functions. I cannot see accurate billing information, I cannot see forms I've signed, I can't obtain access, AFIACT, to my own data. (All this I've encountered in the last week, too.) AFAICT, data isn't transferred in standard formats. (I tried intercepting the AJAX calls to see … but nope, proprietary junk, AFAICT.)

> Outside of healthcare teams iterate towards a good solution. Inside healthcare teams cannot iterate, because of the regulations.

We do this same iterating at my company. (Which sometimes has its own dysfunction, but it's not unique to healthcare; you can see it in any HN thread about agile.)

Regulations like 62304 and ISO-13485 are specifically designed to stop ideas going to prod in a few hours.

HIPPA is something completely different. HIPPA is much more lightweight.

Probably your company has found a niche that manages to avoid requiring compliance with medical devices regulations. This is a great idea and it lets you make very good software quickly.

Both of these regulations you mentioned are indeed valuable when doing medical software development in EU (mdd/mdr).

However, in US, these giant EHR systems (epic, cerner etc) are not regulated by FDA.

Speaking from the perspective of healthcare software:

ISO-13485 really isn't that heavy in the grand scheme of things. Once you establish your policies you can automate most of it with Jira, which can provide good traceability.

It's really the testing requirements that are the most heavy, and whether you can do that in a few hours is 100% up to how good your testing setup is.

I suspect that the quality management system is often this way at any mature tech company anyways, but who knows.

When you need to perform a 510k, that's where the heaviness comes into play, even a special 510k can be considered heavy.

For those uninitiated, here's the FDA guidance on when to perform a 510k: https://www.fda.gov/regulatory-information/search-fda-guidan...

Rewriting a core piece of your software stack in a significantly different language is one such case (JavaScript to TypeScript? Probably not. Java to C++? Most certainly yes.).

*HIPAA (sorry, I'm in healthcare and it makes my eye twitch)

I think folks are confusing complex IT management in a big complex enterprise with various outsourced vendors and tight SLAs with regulation.

Healthcare is like government in that they had to computerize billing to interact with Medicare and Medicaid first. So some policy decision made 30 years ago by a hospital acquired a decade ago may impact operations today.

my (similarly uninformed) opinion is… similar. the industry is so regulated and unsexy that it doesn’t attracted the thought leaders and technical talent necessary to created modern, inoovative systems. instead you get more verbose epic garbage. i could be totally wrong, but i always assumed it’s related to the sexiness-quotient of the field.

Ads are even more unattractive, both intellectually and ethically. Yet somehow there's still a ridiculous amount of intellect being completely wasted on ads, likely due to the dull motivator called currency. I'm not sure what the factor is, but there are plenty of intellectually unattractive and societally useless careers that suck up capable people's entire lives.