Live data from Hacker News

GNU Health

gnuhealth.org

131–138 of 138 posts

Re: GNU Health

#131
post #97
post #83

Earlier quoted context omitted.

That's broken window fallacy.

"Broken windows" is not a fallacy. The common belief that it's a fallacy is a fallacy. "Broken windows" indeed can stimulate the economy and improve the lives of people. But not _always_.

The fallacy is not that it doesn't create work or money circulation, it's that you are taking money and forcing it to be spent badly. The $100 someone spends on a windows you broke would've spent better spent on literally anything. And if it's not being spent, there's a reason for that as well.

Re: GNU Health

#132
post #97

Earlier quoted context omitted.

"Broken windows" is not a fallacy. The common belief that it's a fallacy is a fallacy. "Broken windows" indeed can stimulate the economy and improve the lives of people. But not _always_.

The fallacy is not that it doesn't create work or money circulation, it's that you are taking money and forcing it to be spent badly. The $100 someone spends on a windows you broke would've spent better spent on literally anything. And if it's not being spent, there's a reason for that as well.

But what if the reason for not spending is that other people are also not spending?

Remember, "your spending is my income".

Re: GNU Health

#133
post #76

Earlier quoted context omitted.

No, MUMPS (or M) is a remote descendant of JOSS, an interactive language of the 1950s. JOSS has all sorts of variants (DEC's FOCAL language of the 1960s was a dialect), but I think MUMPS is the only living one. MUMPS code is mostly unreadable, as the commands can be, and often are, abbreviated to the first letter. As a result, it looks a lot like line noise. Regardless of its many warts, Cobol cannot be accused of be…

MUMPS was originally developed in the 1960s for use on minicomputers that had maybe 64KB RAM. At the time it was a lot more important to keep code size small, hence the single letter commands. Readability wasn't a concern then but it sure looks like a mess today.

It's hard to imagine it's an improvement over just the raw assembly.

Re: GNU Health

#134
post #79

Earlier quoted context omitted.

Revenue cycle issues are important but not the only factor. It's simply no longer economically feasible for provider organizations to maintain bespoke EHRs. The costs have gone up too much. They can't afford to pay developers to build and maintain all of the functionality now required due to federal interoperability rules compliance and escalating user expectations.

> They can't afford to pay developers to build and maintain all of the functionality now required due to federal interoperability rules Yep, and more and more payors - government and private - are demanding systems that are both interoperable and audiable Internal, bespoke systems are notoriously nightmarish for auditing

As opposed to the Epic MUMPS pile?

Epic has been sold in in Denmark and Finland, where it was a disaster, and then in Norway, where they failed to take lessons from the disasters. I don't think it's federal requirements which is the selling point there, though I wonder what the hell the selling point is, or what the Epic sales people put in acquirers' coffee.

Re: GNU Health

#135

There was a guy on reddit a few years ago who started a dental practice with entirely open-source software and his own EHR system. Really interesting stuff, don't think anyone's posted about it here. Can't view his reddit history but he must still be using it, last commit 1 week ago. https://www.reddit.com/r/linux/comments/p5phju/progress_repo... https://www.reddit.com/r/linux/comments/x2mls1/update_starti...

A doctor in my little town created his own open source EMR software in FileMaker:

https://cottagemed.org/p/24/Cottage-Med

His practice also accepts payment in the form of barter: https://cottagemed.org/p/15/About-Our-Practice

Re: GNU Health

#136
post #2

Heath centers pay unreal amounts of money for these kinds of commercial products, but in my experience the health centers themselves have very few technical resources. So the real "value" being delivered by the commercial software providers is often the setup, support, and hand-holding provided to customers who pay the crazy amounts. I imagine there will be a niche but high-paid market integrating these GNUHealth pro…

> the real "value" being delivered by the commercial software providers is often the setup, support, and hand-holding provided to customers who pay the crazy amounts

That is also possible and even usual with open source. The difference is you can choose the provider for each of those things, they can be different, you are not locked in.

Re: GNU Health

#137
post #76

Earlier quoted context omitted.

MUMPS was originally developed in the 1960s for use on minicomputers that had maybe 64KB RAM. At the time it was a lot more important to keep code size small, hence the single letter commands. Readability wasn't a concern then but it sure looks like a mess today.

It's hard to imagine it's an improvement over just the raw assembly.

Imagine harder. It was an enormous improvement over assembly language. Not so much for the basic coding but for the portability and built-in persistent data structures. MUMPS has an excellent "NoSQL" database built in which is a pretty good fit for a lot of healthcare use cases.

Re: GNU Health

#138
post #74

Earlier quoted context omitted.

I wonder what would happen if EU harmonized the legislation so that the EU states could go together and develop an OSS journaling system. The amount of money saved would be astronomical.

Spending money is what drives the economy. No diverse expensive healthcare software means thousands of employees don't get paid and don't spend earned money within the economy.

Efficiency also drives growth, by avoiding waste.
Post reply on HN