Hacker News Reader

Comment by mfer | Hacker News Reader

Something is missing in this conversation. Do the people who are creating the applications that deal with medical data have motivation to make it better or more useful?

I've spoken with numerous people in my life who deal with these types of systems. Everyone complains. Fields for information are in unexpected places. There are too many things to click on. All of the people I've talked with agree on the same things.

It's as if no UX people were involved. The experience doesn't fit the need quite right.

What would motivate the makers of these things to improve on the situation? How are the contracts won? Do the people who have to use this stuff have a say in it? Do the hospitals and doctors offices measure stats to see what's working and what's not?

This space is ripe for disruption simply based on user experience.

View on HN

I worked on EMS data entry software for a while (deepest apologies to any EMTs reading) and the big issue we ran into was needing to fulfill doctor/administrator pet projects to get a sale.

The county wants to collect data on if a drowning incident happened at a pool without a locking gate. Now all services need to update their software to include a random checkbox. An EMT was caught without gloves and now the parent hospital wants EMTs to record what levels of PPE they wear on every run. The customer might get a grant if they can help track infectious diseases so now there is an extra box where the EMT can guess if the patient has the flu.

In the abstract that is good data to want to know, but it ends up being more junk on the screen for the EMT to skip over while dealing with the patient or sitting in the hospital parking lot after a run.

If I had a dollar for every time I swore at NEMSIS, I could quit my day job...

NEMSIS is ugly, but it is vastly easier to work with than HL7. That was an evil XML standard.

Was? Has the US medical system finally moved on from HL7?

Newer versions of HL7 (and FHIR) aren't (exclusively) XML.

If it's anything like non-critical software, then I'd say the middle layer between developers and users. That is, the sales and management teams on both customer and producer sides. There are many reasons this middle layer might appear and cause problems - lack of trust in developers, need to "protect" company "secrets", software's main utility is checking some boxes on some contract and not actually being useful, etc. But almost everywhere I look this happens.

Like qudat said, the level of rules and regulations required to enter the market are indeed pretty high, but I don't think they are insurmountable. And industry connections certainly do help in getting contracts, but people will generally listen if you have good ideas.

The people making the purchasing decisions are almost always pretty removed from day-to-day usage of clinical software (and the bigger the company, the more true this is).

But how will you present to them that your new product is "better" than that of the incumbent's? You can say, "our product can do X feature 10x better than another product", but if they reply with "unless your product has dark mode for a select number of physicians who live in WA and NY state, it's going to be a no-go. We already have another quote from someone else who will do this for us", what are you going to do? You may resist at first, but in order to win the business, you too will likely repeat this process ad-nauseum, until your "MVP" becomes just a "VP".

These decision-makers are also cautious about "new" technology (and rightly so, for the most part). Since if something does go wrong with patient data, it is considered catastrophic - and who will be to blame then?

There's not much room for competition because the level of rules and regulations required to enter the market are very high. Basically the only companies that can manage that red-tape are massive corporations. The end result is a system like Epic that can do everything. These monoliths are usually large, difficult to change, and riddled with tech debt. Creating user stories for the thousands of different things that an administrator/physician/nurse/patient can do in these systems is seemingly an insurmountable task. I wouldn't want to try to rebuild a software system like Epic and I absolutely would not want to work on a system like that.

Furthermore, Epic is sold to administrators, not physicians. It checks all the boxes so it gets the contract.

Reply on news.ycombinator.com