I'm super biased admittedly as I have worked on the implementation side for these big systems but...
Try to ask those same friends to agree on the "correct" workflow for some aspect of their clinical work. You won't find agreement in the same state, in the same hospital system, in the same hospital, or even in the same department.
I can't claim what is out there is great, but it's like that quote about democracy. It is a terrible system but the best available.
Making something like this open source could work, but whenever this comes up on HN it seems like people think making it open source magically makes it better. It's not technically complex, just organizationally complex to find agreement - and I think open source would make that aspect harder.
> It's not technically complex, just organizationally complex to find agreement
Assuming you’re talking about the EMR and its records, I think that quite a lot is technically complex as well as being organisationally complex. Without a deep domain knowledge it can be hard to tell if something is needlessly convoluted or actually complicated and healthcare conflates the two all the time.
There are already standard APIs defined for all of your item 1 from HL7 and ASC X12. Some of them are messaging APIs rather than HTTP/REST/JSON APIs so they can be a bit daunting to new developers. Most modern EHRs support those APIs but it can still be a huge amount of work to build interfaces to other organizations.
As someone (biased) who works with one of those two, I have a hard time believing the complexity of installing an EMR can be handled by this type of project.
The challenges are not the challenges of tech. They aren't sexy. It is just really boring and complex business logic and the strength of both those companies is the vast amount of support they provide during install and future maintenance.
The problem is less about software that works, more about finding standardized workflows even within the same hospital. Or building in enough configurability to support all conceivable workflows - which leads back to the requirement above of very robust support.
It's the same old thing with any vertical market software. Do you modify your business processes to suit an existing piece of software or customize the software to suit your existing business processes? Every healthcare provider organization likes to believe that they're a special snowflake with unique requirements. That's almost never true, but it's tough to convince the decision makers and veto holders otherwise.
I am making a general comment about industry dynamics here. Not recommending OpenEMR.
>Every healthcare provider organization likes to believe that they're a special snowflake with unique requirements
Very, very true in my experience. But it isn't as crazy as it sounds on the surface. Very little of what hospitals do is truly evidence based. So we can say, well Duke does this or Cleveland Clinic does that, but maybe your hospital doesn't have the resources of a top 10 hospital and you can't make their protocols work. Or your patient population is different.
For me, the root problem goes back to difficulty in automating data analysis that truly "understands" outcomes. Even with full EMR data good luck assessing the outcome of a given therapy in a scientific, controlled way.
The mish-mash of regulatory regimes and insurance industries that change state-by-state, as well as practice-specific workflows that are every bit as unique as any business logic developed for one-off companies who evolve without any unifying or centralized force to standardize procedures, apart from compliance requirement, but those are not prescriptive in regards to the content specifics. If nothing else, just the combinations of integrations necessary for radiological imagery, insurance and patient forms, billing, patient services, communications, office admin, marketing/outreach, etc., make a lot of small healthcare offices some of the most unique businesses I have encountered in my ~9-years of freelancing as an I.T. consultant.
One restaurant has much the same needs and day-to-day procedures as another, even if they serve different types of food at a different price point to a different target market in a different part of the country. Healthcare is not nearly so uniform, and to the extent there are common elements to their processes, they are elements that have long since become standard features in every ePHI management system. But even then, the task of adapting those features to an individual doctor's workflow is nowhere near as straightforward as setting up a POS or inventory management system.
Then there is the unique nature of the data itself. It doesn't just store SKUs of mutable entities with well defined attributes that support pattern-matching, data verification, and formatting rules. It stores patients, each with unique histories, conditions, diagnoses, prognoses with instructions, contraindications, supporting documents, scheduling, billing options, and the documentation of each discrete visit or encounter. Every doctor will have their own approach to all of these aspects that should comply with applicable laws and standards, but who are otherwise empowered to construct their own policies and procedures, especially if they are focused on a specialty or niche.
TLDR; I expect the idiosyncrasies and demands in ePHI management are more diverse and uniquely challenging than one might think.
I'd say whether it failed is debatable. My understanding is the best counter bid was building a new system from the ground up... I feel that outcome would have been much worse.
I think that would be a good idea and the only way it would work.
Unless this is way, way, way more polished you won't see a Mayo Clinic or Cedars-Sinai using something like this. They tried that 20 years ago and it was scrapped for Epic.
If it targeted smaller rural access hospitals or smaller practices and sold consulting and hosting services it might work if it way undercut the current bigger players... But this market is already way more crowded than the massive enterprise systems like Cerner-Oracle and Epic.
I work with a lot of smaller healthcare offices, and there are plenty of field-specific solutions like MedicFusion, ChiroTouch, et al.. Despite the relative small sizes and simpler needs for these offices, you'll still find unique complexities, business logic, and bespoke integrations.
The process of migrating from one solution to another is so involved and time-consuming that I wouldn't expect it to happen more than once in a decade, and only then if the current solution is somehow critically deficient, or their practice is changing in a way that demands expanded options.
The only potential advantage I can think of is the relatively higher frequency of new practices being opened, which creates a wider target audience of potential customers, and that's probably why there's more field-specific solutions, rather than general ePHI that supports multiple fields of practice.
One of the more interesting ones is ESO's ESOsuite, for pre-hospital providers.
It has to deal with rough and spotty connectivity even during record creation, it has to handle sync between different providers (FD arrives first, starts gathering information, EMS arrives after to transport. How do you reconcile field values? It's one thing to coalesce provider interventions, but what about demographic discrepancies? "Just give the provider a choice between options" you think - not the biggest priority when approaching the hospital and stabilizing your patient, and not when you need to contact the hospital and give them said demographics and CC/HX/VS before you arrive).
> They tried that 20 years ago and it was scrapped for Epic.
Did the Mayo Clinic use to use something open-source? They switched from Cerner to Epic 6 years ago [0], but that's just switching one closed-source vendor to another.
In the old days that would be classic VAR opportunity. Independents solving local problems. And, while license fees always affect the value proposition of a solution, there’s typically a lot of consulting and implementation labor dominates those contracts.
Today, though, the electronic medical record is a much more regulated with all the government standards. Part of the whole consolidation of smaller practices is just keeping up with the EMR requirements and other systemic parts of the modern health care system.
But where there are great opportunities for things like OpenEMR is internationally in developing countries. There’s a great need for fundamental EMR services and information exchange that open source solutions can be a really good fit.
I definitely think that today's nofap and other similarly dubious "bodily control" temperance movements are predominantly associated with those who hold right-wing views.
It's not to suggest that all forms of temperance are affiliated with the right-wing—many aren't, and some have even been noted in sibling comments.
I thought that atheists believed that politics and religion have caused most if not all wars in history?
Guess what was the impetus for developing technology? War. i.e. politics by other means. Guess that Stalin developed technology for the love of the game, though. Not for war or politics or anything.
Or are we saying that religion and politics have moderated the impulse to war? i.e. in an ancient atheist world, war would have been much more furious and necessary for survival, so the pressure to develop technology would have been much greater than it was with all those pacifist monks running around spoiling everyone's armed conflict fun with their woo-woo? -- Maybe ICBMs should have been invented around the time that Byzantium was founded
No, because they were permitted to violate the law by legislators.
> In the six years since lawmakers in both states waived anti-monopoly laws...
> Ballad Health was formed in 2018 after state officials approved the nation’s biggest hospital merger based on a so-called Certificate of Public Advantage, or COPA, agreement. COPAs have been used in about 10 hospital mergers over the past three decades, but none has involved as many hospitals as Ballad’s.
> State lawmakers in Tennessee and Virginia waived federal anti-monopoly laws so rival hospital systems — Mountain States Health Alliance and Wellmont Health System — could merge into a single company with no competition. Ballad is now the only option for hospital care for most of about 1.1 million residents in a 29-county region at the nexus of Tennessee, Virginia, Kentucky, and North Carolina.
Most do have automation in place. In fact, the big EHRs are now working with payors to help facilitate automatic interoperability for insurance claims.
So the insurer can directly pull up the patient's chart and use discrete data elements for claims processing.
Not to minimise OP’s work, but if you’re looking for markdown in a single chat thread, you usually can just ask chatgpt to give you markdown in a code block.
Yeah. Walker also turned down federal infrastructure funds because he didn't want to be seen using federal tax dollars.allbbecause he thought he was gearing up for a presidential run ... Until Trump ate his lunch
