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.
Does anyone have any stories about setting up / using OpenEMR?