In my first job I had to work with healthcare software and it horrified me. There is a standard for interop, HL7, but every system implements HL7 in its own special way so there are "integration engines" to massage the data so that they all conform to the same standard.

It's a gigantic grift.

▲

ch4s3 6 days ago | parent [-]

The history of HL7 is kind of nuts. It was originally developed for copper wire communication in 1979. Formalization was ongoing until maybe the early 1990s and lots of proprietary usage arose, because back in the 1990s none of these systems really inter-operated and everything eventually ended up on paper. It wasn't until after the ACA that a lot of interoperability pushes really got going at scale. Before that you had a few Health Information Exchanges at state levels so there was usually a local standard if there was an HIE. HL7 FHIR is much more standardized now.

I wouldn't call any of it a grift. It's just old tech built for a fragmented archipelago of systems that didn't communicate. Also you can write a pretty good HL7v2 parser in an afternoon, I've written maybe 5 of them.

▲

ethbr1 5 days ago | parent [-]

The koan that unlocked why healthcare technology is the way it is for me:

I was working on automating health insurance claims processing on a mainframe system.

In their key interface, a key form had 8 blanks for ICD codes. If more than 8 codes were needed, a child claim was created and linked to the parent claim.

This was a long project, so I was staring at this interface for months, as linked child claims made automation more complex than it needed to be. (E.g. if a parent claim had aged, been archived, and needed to be reloaded to active overnight before processing the child claim)

Finally, I started asking around. "This is a computer system. Why are there a finite number of fields for something that might need more?"

Nobody knew. Project continued. I continued asking different people.

Finally, I asked a guy who had been working in the industry since the 1960s...

"Oh, because that's how many fields there were on the paper version of the form that preceded the mainframe app."

Which seems insane, until you think it through. There were innumerable downstream processes of that paper form.

Changing the number of fields on the digital version would have cascaded that change downstream to all those processes. In the interest of rapid implementation, the optimal approach was to preserve everything about the form.

And then nobody had a reason to go to the bother to change it for the next 50 years. (And that was a process within a single company!)

▲

1718627440 5 days ago | parent [-]

But you can split these claims into child claims upon printing. That's the thing with good software, the user model and the internal implementation are completely orthogonal. I think a good example of this is postfix.

	▲	ch4s3 5 days ago \| parent [-]
		> But you can split these claims into child claims upon printing Maybe, if business rules and the law allow a thing like that. If insurance won't pay claims like that then you can't do it.