4 ms·

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. T

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.

curious_cat_163 2y ago
Thanks for sharing your insights. 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?
- bobmcnamara 2y ago
  That's how OpenDental handles it.
- shigawire 2y ago
  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.
  - nativeit 2y ago
    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.
    - FireBeyond 2y ago
      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).
  - Taikonerd 2y ago
    > 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. [0] https://www.healthcareitnews.com/news/mayo-clinic-cio-christopher-ross-breaking-1-billion-ehr-and-it-modernization-rollout-barrier https://www.healthcareitnews.com/news/mayo-clinic-cio-christ...
- whartung 2y ago
  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.
nradov 2y ago
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.
- shigawire 2y ago
  >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.
- nativeit 2y ago
  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.
eisa01 2y ago
Why do the Epic deployments in e.g., Norway and Denmark fail? The most recent "Helseplatformen" in Norway has not been successful according to the practitioners, citing lack of support and training
- shigawire 2y ago
  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.

curious_cat_163 2y ago

Thanks for sharing your insights. 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?

bobmcnamara 2y ago
That's how OpenDental handles it.
shigawire 2y ago
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.
- nativeit 2y ago
  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.
  - FireBeyond 2y ago
    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).
- Taikonerd 2y ago
  > 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. [0] https://www.healthcareitnews.com/news/mayo-clinic-cio-christopher-ross-breaking-1-billion-ehr-and-it-modernization-rollout-barrier https://www.healthcareitnews.com/news/mayo-clinic-cio-christ...
whartung 2y ago
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.

nradov 2y ago

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.

shigawire 2y ago
>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.
nativeit 2y ago
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.

eisa01 2y ago

Why do the Epic deployments in e.g., Norway and Denmark fail? The most recent "Helseplatformen" in Norway has not been successful according to the practitioners, citing lack of support and training

shigawire 2y ago
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.