OpenEMR: Open-source medical record software
open-emr.org
open-emr.org
Does ONC certification test for that kind of thing? They briefly mention "security"...
[0]: https://www.open-emr.org/blog/openemr-achieves-onc-certifica...
What would you recommend today as an OpenSource EMR?
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.
Open EMR - https://news.ycombinator.com/item?id=25141287 - Nov 2020 (127 comments)
OpenEMR v5.0.1 - https://news.ycombinator.com/item?id=16949974 - April 2018 (37 comments)
OpenEMR is Accepting Donations on OpenCollective - https://news.ycombinator.com/item?id=15951191 - Dec 2017 (43 comments)
OpenEMR: Electronic Medical Records and Medical Practice Management Software - https://news.ycombinator.com/item?id=13888893 - March 2017 (203 comments)
Ask HN: Anyone interested in working on an OpenEMR modernization project (OSS)? - https://news.ycombinator.com/item?id=13807371 - March 2017 (4 comments)
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.
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.
And I understand why it's hard! But it should be possible to make progress around the edges, on more defined use cases and subsets... like pricing.
That said, the major system vendors have zero incentive to originate interoperability, so it'll have to come from HHS if anywhere.
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.
https://www.cms.gov/priorities/key-initiatives/burden-reduct...
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.
But it is moving the system forward.
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.
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.
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).
Sources:
https://en.m.wikipedia.org/wiki/DXplain
https://www.dhinsights.org/news/does-ai-matter-if-human-clin...
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).
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.
The tools actually save time and effort now, and don’t have a steep learning curve.
At least that’s my view from radiology as a tech.
It is hard to imagine that any kind of textual computer input will persist more than 20 years in the future.
But really. Always, always bet on text. Chances are it'll work in 10000 years if we still exist.
LLMs are not going to help if the input data is also garbage, let alone hallucinations.
“Are you dizzy?” - sometimes, I’m not sure… etc
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.
Mind elaborate how is this done?
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.
Here is a talk by Dr Mwogi on implementing at one of Kenya’s largest public hospitals https://youtu.be/yL6akPy2X5c?si=4UzUSJYm3PjxA3hL
If I'm running a hospital, I want my record software to be developed and maintained by a company that can pay its developers.
The place for openness, vendor neutrality and transparency are protocols and file formats, which define how different software communicate.
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.
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.
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.
Does that argue for a two-part design like:
1. APIs for scheduling, billing, lab tests, etc. These are standardized across all health systems.
2. "Workflow" code for a particular health system. This is custom.
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.
Does anyone have any stories about setting up / using OpenEMR?
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).
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.
The part where person making the purchase decision is neither the user nor beholden to the users? That's bad.
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.
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.
I am making a general comment about industry dynamics here. Not recommending OpenEMR.
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.
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.
The most recent "Helseplatformen" in Norway has not been successful according to the practitioners, citing lack of support and training
One wonders if the business model for supporting efforts like this could be to provide the support/services, while keeping the code base open source?
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.
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.
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).
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.
[0] https://www.healthcareitnews.com/news/mayo-clinic-cio-christ...
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.
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.
Most of their value is in not getting the implementing team fired.
This is amazing.
That great thread on falsehoods programmers believe about names gets a new twist when you add in a variety of species.
Those are just the ones I've had to work with in the past but I'm sure there's many more.
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."
"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.
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.
Medical records is not a website.
Medical records are not a website, so its logic should not be in PHP.
A frontend for medical data? Yes, a HIS? NO
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.
Is there other decent open source EMR coded with other languages to try out?
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
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.
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.
That said, I hope they have more luck than OSCAR did.