I was the main contributor and maintainer to OpenEMR about ~20 years ago and then decided it was irredeemable and started over with ClearHealth/HealthCloud. Shockingly some of my code code lives on (from PHP 3). I am reluctant to say don't use it but if you do please don't expose it to anything public, which sadly happens most of the time. There are some real problems that exist in that code base from a security and HIPAA perspective.
If you consult https://chpl.healthit.gov/#/listing/10938 you will see that it is a certification of a subset of the full criteria (toggle 'see all certification criteria'). OpenEMR foundation says they had to raise $125k to do the partial certification, that sounds right. That is a good thing but some items like eprescribing are not certified, which is an absolute deal breaker to most providers. I would guess it's because you have to license a drug database. At ClearHealth we built and maintained our own drug db as open source also, it was a large endeavour. We had to lobby federally for there to be a carve out in the HITech legislation to even allow for an open source drug database to exist rather than the original requirement of two dominant existing providers codified in law. You can stitch together some other third party offerings to meet those needs but hardly anyone wants to do that.
ClearHealth and it's affiliated companies were acquired in 2017. ClearHealth the EMR stopped open source releases in 2017/2018. You can kind of hair split what is and isn't an "EMR" but if you want a system most providers would call an EMR it is extremely difficult to have it be any sort of open source anymore. Basic fundamentals like procedure codes, diagnosis codes, eprescribing, billing, drug databases, interoperability, mandatory reporting and certifications all involve large fees, licensing and other ongoing costs. At ClearHealth our main business was healthcare management. We spent about ~2 million a year on those things, we released what was not encumbered otherwise under the GPL. The EMR is still used and maintained internally by some larger institutional users.
Good points, but diagnosis codes don't generally require any licensing fees. Depending on the use case those are usually either ICD-10-CM or SNOMED CT, both of which code systems are free to use.
I would recommend the open source EMR project that is literally staring at you in the face here, which is OpenEMR :)
There is a reason why there is a healthy community of passionate volunteers and contributors from all walks of life that have spent an inordinate amount of time and resources to support this open source software.
Coming from one of the core volunteer developers that has contributed to this project over the last 18 years all I can say is that a lot has changed over that time. I consider it a robust and secure project regardless of its humble origins. And always happy to answer any questions regarding the project.
I worked in EMR company and the amount of monthly legislative changes was insane. Insurance companies always changed their data formats every month. I think they did it because if hospital's monthly export contained some error they could hold their money for couple days more.
So anyway when our country switched to euro, the deadline came and the insurance company still didn't publish format for the new month. They were too busy with the euro switch that they didn't have time to mess with the export format. Few hours later they published new format. They just switched orders of 2 columns.
But back to churn. Month old EMR is useless. Forget about working 2 years on something, publishing it on GitHub and calling it a day. In a small 250k town we needed 7 full-time programmers and 5 servicemen to keep it going. Patient arrives at v7.13.148 and leaves two weeks later at v7.15.203 and you need to keep their data in some kind of consistent way.
When you work in a a patient facing role, you battle the EMR (or Radiology Information System in my case) and hate it’s ancient, bug ridden mess of inefficiency. Why is it just as crap as it was 20 years ago?
But if you ever see the billing side you realise that billing is where the bulk of the action happens and that the horror is even worse over there.
There are existing interoperability standards covering just about every healthcare use case (including price transparency) from organizations like HL7, DirectTrust, ASC X12, NCPDP, CMS, etc. The trouble is that many payer and provider organizations have chosen not to fully implement those standards. Instead they just do the bare minimum to achieve regulatory compliance because it's a cost center, not a revenue driver.
The major EHR vendors are all active participants in open industry standards development. You can literally read the meeting minutes from standards development organizations to see that. But just because they ship a new interoperability feature doesn't mean their customers actually turn it on.
In the USA at least there is a single mandated technical standard for providers to send claims to payers (insurance companies). Changes to the technical format are infrequent, although some payers do change their coverage rules all the time.
HHS/CMS is making forward progress, usually when mandated to do so by Congress.
Granted, whenever a new requirement comes into play, cue frantic scrambling by underfunded provider/insurer IT departments to support, followed by a few years of waivers from HHS to allow everyone to implement, followed by support a decade later.
Sometimes it feels like the pursuit of digitization has actually made them less efficient and lower quality overall.
Instead of just having a doctor providing medical care and a government giving them a check suddenly you have a thousand programmers, data center management, managers of programmers, information security teams trying in vain to secure the whole mess, etc.
And that's before you get into the fact that the doctor suddenly can't practice at all when some teenager decides to ransomware the whole business.
Doctor here, I hate EMRs, they are oppressive, in many ways they make things worse for patients. I think the future of EMR is no EMR.
An LLM that takes multimodal input (audio, video, images, observations etc etc) and outputs whatever is required (a podcast summary of clinic patients, a checklist relevant to a patient’s condition in preop) is the future.
Forcing doctors, nurses and allied health to manually document everything they do in annoying web forms is stupid and soul destroying.
Multimodal LLMs will also replace much of medicine and nursing which is good.
> Multimodal LLMs will also replace much of medicine and nursing which is good.
You should read up on the history of AI in medicine. 30-40 years ago they had rudimentary (by our current era understanding) systems that basically equalled and beat physicians in diagnosing and prescribing medicine to patients when given a list of symptoms (sources at the end).
None of these ever had any uptake because physicians didn't want to use them, even when shown they performed more accurately.
Ultimately credentialed professionals like medicine and law will never be replaced by LLMs because LLMs cannot be held responsible for the medical regimes they place patients under (or the legal advice they give).
> Ultimately credentialed professionals like medicine and law will never be replaced by LLMs because LLMs cannot be held responsible for the medical regimes they place patients under (or the legal advice they give).
It’s not quite the same as what you are saying, but things are changing quickly.
Software is diagnosing pathology in radiology now. Software made up at least 3/4 of the pixels in the MRI scans I acquire. Sometimes it makes up more than that as every second slice is made up too.
Clinic letters are being written by applications that listen to the consult with the patient and write up a summary (for the clinician to authorise).
Why would things be changing quickly now when old-school AI have been out-diagnosing doctors for years?
Again, like I said, doctors are ultimately responsible for the final call made. So no amount of AI will replace any doctors. It may remove some toil, but they cannot be replaced.
Was the previous test Done with massive amounts of structured input which would be incredibly time-consuming for the doctor involved? I think the difference now is that we’re talking About making diagnosis with minimal extra work or time from the clinicians
In most cases the diagnosis is the easy part. The hard part is gathering the signs and symptoms necessary to make the diagnosis. AI isn't particularly helpful for that.
Yep - and the hardest part about getting the input signs and symptoms data is that patients often don’t know the words to describe what they’re feeling.
LLMs are not going to help if the input data is also garbage, let alone hallucinations.
Tangential, will we ever certify current LLMs as "medical grade", for example they reveal suicide steps too easily, pick up Redditor snark as serious content, contatenate parts of random sentences together etc?
LLMs aren't intelligent. They won't replace an EMR. They'll hallucinate information, associate the wrong details and just generally be not deterministic in the way you want an EMR to be. But they can be a powerful interface that does reduce documentation and time spent hunting down information in an EMR.
The future of EMRs is more machine learning models of various kinds(not just LLMs) all built into the EMR to turn it into a medical scribe with great memory and a keen eye for what's important.
Nurses and doctors aren't going anywhere until we achieve true artificial intelligence, but until then the goal is to keep their eyes off the computer and on the patient as much as possible.
For starters, ward nurses spend 25-35% of their time doing documentation. This is doing patient notes, transcribing vitals, filling in forms and checklists, logging in and out of workstations, etc etc.
Much of this could be replaced by audio/video input.
Secondly, if the LLM can identify at risk patients or drug checks, you don’t need a nurse or 2 nurses to dispense medications or identify at risk patients. Multimodal input LLM plus a caring low skilled person can do the necessary things far more often.
These 2 factors alone can reduce nursing workload by half.
As for family doctors, I would personally be very happy to transfer my basic general care to a good LLM right now. Everything I need is straightforward, protocolised and the hassle of making appointments, delays, waiting rooms, form filling etc is more of a barrier to my healthcare than current LLM deficiencies.
Agreed, and honestly this is one of the easiest and best behaving use case for LLMs. We’re not talking replacing any diagnoses, but freeing the humans to do what they do best, using their intuition.
AIs performed better at replacing human diagnoses long ago. Physicians don't like to use them because, well 8-10 years of specialized study tends to make you feel like you know what you're talking about vs some computer
I haven't seen a single friend who works in a medical profession recommend or feel well supported or feel like their system was well rolled out.
I would 100% rather go to a place using open source software, with enthusiasts hope & open improvement iterating forward & leaving the door open to others to improve & build community around.
It's a shame that we leave the work of important things locked to a couple far off product development organizations, that changes are gated in so few. When so many feel & experience the end result, are left at ends to cope with whatever has been given.
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.
Being famous the medical space, it’s almost universally because an EMR rollout becomes a political game.
Every single implementation I’ve seen involved a bunch of executive stake holders requesting features with absolutely no input from front line staff. Everyone’s goal is to get a resume item in without any care about how the hospital is actually run.
OpenEMR seems like it could have a market opportunity, in principle. The EMR market in the US is dominated by two big, unpopular systems (Cerner and Epic). A smaller, nimbler competitor could make inroads among health systems that don't like that duopoly.
Does anyone have any stories about setting up / using OpenEMR?
I don't have experience with health systems. I do have experience with entering a market with settled incumbents, and I do have experience in large organisations.
Firstly, Open Source is not a factor here. The number of customers who care about our code is zero. Not even rounding to zero, just zero. Paying someone to look at, understand, Make, test, change etc dwarfs what they pay us. They are in the "health" business not the software business.
Our business model -does- matter though. We often get evaluated "as a supplier". The obvious things like how long we've been around, staffing levels, track record etc. Also non-obvious things like profitability, income model, some even ask to see the books (we draw th line before that.)
It turns out they're not buying software. They're buying a relationship. They want to know we'll be around in 5 years, 10 years, 15 years. That's -much- more important than the cost.
(As an aside, having the primary message on your front page literally soliciting donations is a bad look. Funding via donations overall is not a good look.)
Lastly the software is not used by the guy who makes the purchasing decision. The buyer doesn't care about the UI or workflow (much). As long as the price is "ok" (and he has a large budget to spend) that doesn't matter either. He cares about the warm and fuzzies the salesman gives him. He cares about the success of the project overall. He cares about his job rolling out this big project. Decisions like this are career making, or career breaking.
Oh, and the desire to -change- systems is zero. Sure there's lots of whining, that's easy to ignore. Changing is high risk (and will bring in the same amount of whining).
This rings more than true, but it reflects market conditions that are not set in stone (otherwise we'd have lots of hundred-year old incumbents, but the evidence is that companies live shorter and shorter lives).
The cost dimension is (ultimately) what indicates whether a domain is ripe for disruption. No matter how cozy an arrangement it will eventually implode if it extracts unjustified rents while alternatives are readily available. Ofcourse cartels can remain untouched longer than you can remain solvent. There is a timing element and luck involved.
Open source can be an important lever in this direction because it is not just "free", it is also more transparent. Ceteris paribus the cost of assurance should be lower. When resistance to chance is primarily due to risk aversion this could be an other element to weigh in. But for this dynamic to kick in there has to be adoption and amortization of costs and that is a catch-22.
In other words you can choose to play the game, or you can choose to fight the rules. I don't recommend the latter, it doesn't work.
Frankly I recommend the former - if you don't like the game, don't play. There are lots of other markets to play - enterprise software is just one of them. Other markets have different rules and you should find a market that suits your strengths.
While it frankly doesn't matter, I will point out that your comment that "its bad" should have the phrase "from my point of view" tacked on. You might even suggest it's bad from the "users point of view". But the "business point of view" is a different view, and also important. The ability to understand that point of view - and to best address those needs as well, are critical if you want to enter the Enterprise space. The business writes yhe check, not the user. The business is the customer not yhd user.
Or, to reference back to the original article, if you want to play in the Hospital Admin space you need to understand what hospital admin is, and what it needs. Are hospital admins asking for free unsupported, open source software, with funding models based on "hope"?
As software people we are seldom trained to understand business needs. Our career is in writing software for end users. We focus on technical things, complain about bloat or speed, are UI focused and think "user" when someone talks about "customer experience".
Google is the poster child for this. They push the technical boundaries, have really good products, do technical things really well, spend lots of yikes on UI etc. But I wouldn't depend on them for my business, because, frankly they're not dependable. They don't offer me customer (much less user) support. Their pricing is erratic and subject to change. And the service they provide may be gone tomorrow. They serve "me the user" but not "me the business". They're not "bad" - they just don't serve the needs I have.
The last part missing is "build a flawed product and bake it into the contract so you charge high consultant costs to the customer to fix it" which is where the cash cow is for many enterprise / B2G products.
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.
There are several others like eClinical in wide use. Depends on acute/outpatient etc. Open source is more a less a losing proposition for a mainstream EMR because of certification and integration requirements that amount to at least hundreds of thousands of dollars per year. ClearHealth was, as far as I know, the only open source EMR ever to have surescripts and full federal certification. It cost us about ~2 million a year to maintain all that.
It’s not about the clinical record; it’s about being able to bill insurance companies without getting the claim rejected. Clinical formats are all over the place (HL7v2, CCDA, FHIR) and the data is garbage. Claim data is clean because you don’t get paid if it’s wrong.
With Epic and Cerner, they offer the full white glove experience plus a reputation for quality billing; plus, they have a larger internal network to pull from for interoperability.
In the dental space, the market opportunity has been demonstrated by OpenDental, a GPL competitor in the dental space. Others include Epic and Dentrix.
I wonder if there’s a similar opportunity in the veterinarian space? Still a lot of independent vets out there, and it’s presumably simpler problem as there’s less coding and insurance to worry about.
My son worked in this space for a successful NZ company. It sounded like it was indeed a bit simpler (but still with plenty of complexity) but since nature abhors a vacuum, they added complexity by shoveling in features. I remember one being a surprisingly complex system for tracking the creatures' nickname(s).
There are already many smaller competitors such as Paradigm, eClinicalWorks, Intellicure, gGastro, Athena, Practice Fusion, PrimeSUITE, eMD Central, NextGen etc.
Those are just the ones I've had to work with in the past but I'm sure there's many more.
I think nowadays OpenEHR [0] is the most credible option for a FOSS EMR/EHR solution. In my understanding (not 100% sure) in Sweden OpenEHR is obligatory for hospitals.
I was confused before: parent post is talking about OpenEHR with an "H", which is different from OpenEMR.
Is OpenEHR actually code, or just a set of standards? Their web page says, "openEHR is a non‑profit organisation that publishes technical standards for an EHR platform along with domain‑developed clinical models to define content."
Ah good comment, I was always under the impression that OpenEHR was a platform but indeed [0] says:
"The openEHR platform is based on a stable Reference Model, defining the data of the EHR, the archetype model, which defines injected data models, REST APIs, and the AQL query language."
There are open source and commercial openEHR platforms available.
I want to love this, as someone who has dealt with multiple EMRs as an engineer, and as a provider...
but no EMR is going to gain traction with documentation that has five bullet points for its backup discussion.
Even the linked "back up using our tools" is just "tar things up and run mysqldump".
There's no discussion of how to handle and maintain this on a system that may be available 24/7. It's possible to do these things, certainly, but no credence or weight is paid to the real world concerns of how often you should be backing up, state management, intelligent restoration. It's as much about the business continuity aspect as it is the technical.
I know basking projects based on their choice of language is controversial, but PHP really is pushing it for me. And for medical data, too. PHP isn't boring technology - Java is boring technology - PHP is downright dangerous.
PHP is used by at least 76% of web sites on the internet today [0], down from 79-80% as of a few years ago... If anything PHP is quick to develop in and very fast. It takes me about 5 times longer to develop a web app in Java versus PHP, mainly because of lines of code, and pre-compilation wait-time to execute.
No... you can write secure code in PHP perfectly well. However, a lot of code written in PHP is insecure, and the reason for that is simple - PHP has relatively low barrier of entry, which means a lot of people that know little about security write in PHP.
A friend of mine running a subscription service to obesity drugs used OpenEMR and it was far too complex for them. They just hired two NYC engineers and they moved to SF and built them a sufficiently capable EMR system. I was asked to inspect the code. It's perfectly fine. My impression is that the software is very capable but is not a good tool to bootstrap from.
There's a saying in hospital tech sales: if you've seen one hospital's stack, you've seen one stack.
The sheer amount of bespoke deployments and lack of interoperability in these facilities would blow the average HN reader's mind. And through the inertia of these deployments and their (absolutely necessary) adherence to HIPAA and SoC, getting any kind of competitor in, much less one with the lack of support resources like an open source project, is nearly impossible.
I do believe in the mission of these guys, though! I just think EMR is so complex and entrenched that they don't have much hope of success, at least not the way most OSS does in the SaaS world
I would agree with this. The actual tech isn't all that difficult, you just need a very large and flexible database with a functional front-end, detailed process automation and business rules, hardened security, and high reliability. All very well-worn and established elements that can be found pretty readily even in the open source software space. It's the aforementioned integrations, as well as the overall implementation, that will be seriously difficult, especially with all of the unique requirements, extensive compliance, and regulatory pressures that make the kind of software development oversights that might be embarrassing in less complex projects potentially criminal here, or at the very least very damaging and expensive for the developers, their customers, and possibly even their customers' patients.
So the development of any given ePHI system is very high-risk, exceedingly tedious, difficult and time-consuming (aka, expensive), and from my own experience as an I.T. consultant, the potential customer base is going to be full of healthcare orgs who are likely already entrenched within an existing solution, one that has likely been integrated with several other operational services, and one that the lead will almost certainly be very reticent to switch from, considering the huge workload, expense, and disruption to routines that such a migration necessarily involves. That means it could take a very long time to pull in new customers, so you'll need deep cash reserves to maintain development and operational budgets while the initial sales, onboarding, and subsequent support takes place.
I have gone through such a migration process for a very small healthcare provider, and even in a small clinic with a single doctor, it was extremely involved. I am a fierce proponent of open source software and a DIY ethos, but at least in this specific genre of software, I think the larger established players are ultimately the only ones adequately prepared to pull it off properly.
I think that, if an OSS EMR takes off, it won't take off in America. We have a lovely combination of high bureaucracy and low standardization.
But another poster here talked about how Frappe Health is getting some traction in Kenya. Developing countries are more price-sensitive, and not as locked-in as US health systems are. So there's some hope there.
Their demo seems incomplete. I see what looks like a test patient (I hope), but I can't enter a lab order as a physician because there is no list of tests (cbc, lytes, etc).
That said, I hope they have more luck than OSCAR did.
