8 ms·

Unfortunately the problem is much greater than engineers not understanding doctors and other clinical staff, in my experience. For startups that want to sell to

Unfortunately the problem is much greater than engineers not understanding doctors and other clinical staff, in my experience. For startups that want to sell to health systems and similar-sized/larger entities (really this is the minimum size that can work for most startups, practice sales usually have more friction than value), you unfortunately have to focus on the buyer, which is very rarely someone who is "in the trenches." Best case scenario, having software that is compelling to the end users can help you get your foot in the door early on, but actual adoption will only happen if you can convince the business stakeholders of your value. In the US healthcare system, clinicians and the business often have opposing objectives and values. This is starting to change with value based care becoming more popular, but it's still all about providing what the business wants, it just happens to align with the clinicians more these days. You'll still need to support IE9 due to that botched Vista upgrade, build out a custom EMR integration, and deliver whatever random feature the sales folks promised (can you automatically fax things?) before you can move on to the features that the clinicians actually want. The system itself is how we ended up with billing-driven documentation EHRs like Epic. Paradoxically, due to massive adoption, I think Epic and Cerner are some of the only places where real innovation could happen. I think even huge companies like Apple, Amazon, and Google will have a hard time breaking into the space, no matter how much cash they throw at it. For them, the only answer is to go fully vertical like Kaiser-Permanente, but I doubt they have the stomach for this.

tracker1 8y ago
Exactly.. short of the parent company of a hospital also owning a software company for the software this likely won't happen. Even then, software engineers RARELY get to interact with the people using said software for any meaningful time... It's usually meetings with your PM, Manager, their manager, and maybe the same on the other side. That's like 3-6 layers of separation in this telephone game.
- gaius 8y ago
  Didn’t Massachusetts General develop MUMPS in-house?
cordite 8y ago
Epic is often compared to Salesforce, which is to say even if there is a better localized app for a specialty (of which there are many in healthcare), the next questions are: How do integrate this into the other apps, how does it get into the record, how can people in other specialties receive information downstream to act appropriately from medical side to billing side. Then there's the last non-app part, what is the cost structure, what are the hardware requirements, who's going to watch it when it goes down, what disaster recovery strategies are available, what downtime-protocols should be followed when it goes down and up, who can I call when there's a problem I need fixed now, and finally who out there is already using it and demonstrated success with it? I used to work at Epic and have seen in the field the requirements the immediate people need as I listed above. Billing driven documentation is an accurate way to label it. The software is implemented to maximize revenue for the hospitals and organizations, without reliable targeted information coverage agencies won't pay for what was supposedly done. There are whole teams in health care and applications from suites like Epic for such teams just for refining billing. A physician knows what they are ordering for a patient, a temp worker downstream refining billing data doesn't, therefore prioritizing accurate data from the physician will result in better likelihood of obtaining claims downstream. That however competes with the immediate need of the patient.
- odyssey7 8y ago
  > There are whole teams in health care and applications from suites like Epic ... just for refining billing. To anyone interested in AI in healthcare, I suspect that datasets of procedure and diagnosis billing codes could be some of the most accurate and immediately usable of their size.
chapium 8y ago
Cerner and Epic are billing driven because that is priority 1 for hospitals.
- Scoundreller 8y ago
  Not a surprise. Overbilling Medicare is a huge Nono. Having a nice audit trail of who gave that Tylenol and when makes life a lot easier.
bm98 8y ago
Standards like SMART-on-FHIR [1] and CDS Hooks [2] have the potential to allow innovation developed outside of Epic and Cerner inside of those products. Both of those vendors even have "App Stores" [3] [4]. So far, though, there aren't a lot of apps in these stores, and none of my doctors (all of whom work for large academic medical centers and use Epic) have access to any third-party apps - so I do wonder whether the vendors (or their customers) may be putting up roadblocks that are slowing adoption. [1] http://docs.smarthealthit.org/ http://docs.smarthealthit.org/ [2] https://cds-hooks.org/ https://cds-hooks.org/ [3] https://apporchard.epic.com/ https://apporchard.epic.com/ [4] https://code.cerner.com/apps https://code.cerner.com/apps
- nradov 8y ago
  Epic, Cerner, and their major competitors are actually a lot more open now and no longer putting up major roadblocks. The real roadblocks appear to be in the hospital and clinic IT departments. They have to upgrade to a current version of the EHR which supports SMART on FHIR (many organizations are several versions behind) and then enable the app store feature. Some organizations have concerns about using third-party apps due to training requirements, security, and malpractice liability. I do think that SMART on FHIR makes it easier to turn clinicians into software developers, so hopefully that will spur some innovative apps.
  - toymachiner62 8y ago
    Although FHIR is very complete, it's still implemented wayyy too many different ways. There are like a million fields, most of them are optional so it's always a crapshoot what data you actually get from the API responses.
dr_ 8y ago
It’s true that Epic and Cerner are the dominant players when it comes to hospital EMRs, but they have less of an influence in outpatient settings outside of academic medical centers. For larger outpatient practices that are participating in value based programs (ACOs, care bundles, etc.), such as the type apple amazon or google may choose to work with or, less likely, build, there’s less of a need to rely existing EHR vendors and a greater likelihood to rely on a variety of tools that are able to interact with each other. The trend is for more and more care to move outpatient. There’s opportunity for innovation there.
analog31 8y ago
I'm sure I'm being naieve, but could we just get rid of billing altogether if we nationalize the health care system? I have to recount an anecdote. My mom was hiking in a foreign country, and got injured. She hobbled to the next town, and found a clinic. They treated her and were ready to let her go. She said: Q: Okay, how do I pay? A: You don't pay for health care. Q: I'm American. I'm not part of your health care system. A: That's all well and good, but we have no way of knowing how much to charge you, how to take your money, or where to send it. Have a nice vacation. The clinic probably maintained some accounting records, but they simply had no billing system.
- ams6110 8y ago
  Somebody will be paying, and will want adequate and auditable documentation about what they are paying for. The potential for fraud is too great. Medicare and states all have to watch for fraud in their claim payments.
  - bdamm 8y ago
    Right, but it’s probably done by auditing resources to treatment records. The actual patient needn’t be involved. And in countries like Canada you may end up with multiple operating agencies that are competing for efficiency, such as Coastal Health vs Providence, even though ultimately it’s the government footing the bill.
    - Scoundreller 8y ago
      Providence is under Vancouver Coastal health. The authorities aren’t competing with each other (well, not really) as they have their own geographic catchments.
      - bdamm 8y ago
        Right, but they're able to be audited against each other, even though they have separate geographic catchments. Significant discrepancies can be then analyzed. Folks who view single-payer as a system without checks need to know how those checks do in fact occur.
megablast 8y ago
We solved it by having a doctor on our team. In fact, not sure how you could solve any healthcare issues without it.
- jaabe 8y ago
  I work in the public sector of Denmark, and I’d recommend doing this. The companies who hire actual domain knowledge and listens to it are simply miles ahead on making software that doesn’t suck for the end-users. It would be better if we allowed departments to build their own software, because our in-house software is honestly the only stuff that truly does the job right, but I don’t see that being prioritised. So having contractors hire a few doctors is probably the best we get.
- Scoundreller 8y ago
  It also helps to have them as a conduit for your communications to other doctors. It’s sad that you have to pay someone a lot to (partly) forward your emails, but it works. If responding to internal emails had a billing code, I think they would fight over who gets to respond.
sli 8y ago
> For startups that want to sell to health systems and similar-sized/larger entities (...), you unfortunately have to focus on the buyer, which is very rarely someone who is "in the trenches." This is my current experience. The person bankrolling the project delivers lists of requirements, and nearly half of them end up being removed later when someone "in the trenches" either says they don't need/want it or it's too confusing of a feature. Another part of the problem? "Confusing features" for doctors includes some very standard app features, like back buttons and refresh buttons. This honestly frightens me. We had to remove the back button -- which was requested by the buyer -- because it became a patient safety issue. At least we don't have to target IE9.

tracker1 8y ago

Exactly.. short of the parent company of a hospital also owning a software company for the software this likely won't happen. Even then, software engineers RARELY get to interact with the people using said software for any meaningful time... It's usually meetings with your PM, Manager, their manager, and maybe the same on the other side. That's like 3-6 layers of separation in this telephone game.

gaius 8y ago
Didn’t Massachusetts General develop MUMPS in-house?

cordite 8y ago

Epic is often compared to Salesforce, which is to say even if there is a better localized app for a specialty (of which there are many in healthcare), the next questions are: How do integrate this into the other apps, how does it get into the record, how can people in other specialties receive information downstream to act appropriately from medical side to billing side. Then there's the last non-app part, what is the cost structure, what are the hardware requirements, who's going to watch it when it goes down, what disaster recovery strategies are available, what downtime-protocols should be followed when it goes down and up, who can I call when there's a problem I need fixed now, and finally who out there is already using it and demonstrated success with it? I used to work at Epic and have seen in the field the requirements the immediate people need as I listed above. Billing driven documentation is an accurate way to label it. The software is implemented to maximize revenue for the hospitals and organizations, without reliable targeted information coverage agencies won't pay for what was supposedly done. There are whole teams in health care and applications from suites like Epic for such teams just for refining billing. A physician knows what they are ordering for a patient, a temp worker downstream refining billing data doesn't, therefore prioritizing accurate data from the physician will result in better likelihood of obtaining claims downstream. That however competes with the immediate need of the patient.

odyssey7 8y ago
> There are whole teams in health care and applications from suites like Epic ... just for refining billing. To anyone interested in AI in healthcare, I suspect that datasets of procedure and diagnosis billing codes could be some of the most accurate and immediately usable of their size.

chapium 8y ago

Cerner and Epic are billing driven because that is priority 1 for hospitals.

Scoundreller 8y ago
Not a surprise. Overbilling Medicare is a huge Nono. Having a nice audit trail of who gave that Tylenol and when makes life a lot easier.

bm98 8y ago

Standards like SMART-on-FHIR [1] and CDS Hooks [2] have the potential to allow innovation developed outside of Epic and Cerner inside of those products. Both of those vendors even have "App Stores" [3] [4]. So far, though, there aren't a lot of apps in these stores, and none of my doctors (all of whom work for large academic medical centers and use Epic) have access to any third-party apps - so I do wonder whether the vendors (or their customers) may be putting up roadblocks that are slowing adoption. [1] http://docs.smarthealthit.org/ http://docs.smarthealthit.org/ [2] https://cds-hooks.org/ https://cds-hooks.org/ [3] https://apporchard.epic.com/ https://apporchard.epic.com/ [4] https://code.cerner.com/apps https://code.cerner.com/apps

nradov 8y ago
Epic, Cerner, and their major competitors are actually a lot more open now and no longer putting up major roadblocks. The real roadblocks appear to be in the hospital and clinic IT departments. They have to upgrade to a current version of the EHR which supports SMART on FHIR (many organizations are several versions behind) and then enable the app store feature. Some organizations have concerns about using third-party apps due to training requirements, security, and malpractice liability. I do think that SMART on FHIR makes it easier to turn clinicians into software developers, so hopefully that will spur some innovative apps.
- toymachiner62 8y ago
  Although FHIR is very complete, it's still implemented wayyy too many different ways. There are like a million fields, most of them are optional so it's always a crapshoot what data you actually get from the API responses.

dr_ 8y ago

It’s true that Epic and Cerner are the dominant players when it comes to hospital EMRs, but they have less of an influence in outpatient settings outside of academic medical centers. For larger outpatient practices that are participating in value based programs (ACOs, care bundles, etc.), such as the type apple amazon or google may choose to work with or, less likely, build, there’s less of a need to rely existing EHR vendors and a greater likelihood to rely on a variety of tools that are able to interact with each other. The trend is for more and more care to move outpatient. There’s opportunity for innovation there.

analog31 8y ago

I'm sure I'm being naieve, but could we just get rid of billing altogether if we nationalize the health care system? I have to recount an anecdote. My mom was hiking in a foreign country, and got injured. She hobbled to the next town, and found a clinic. They treated her and were ready to let her go. She said: Q: Okay, how do I pay? A: You don't pay for health care. Q: I'm American. I'm not part of your health care system. A: That's all well and good, but we have no way of knowing how much to charge you, how to take your money, or where to send it. Have a nice vacation. The clinic probably maintained some accounting records, but they simply had no billing system.

ams6110 8y ago
Somebody will be paying, and will want adequate and auditable documentation about what they are paying for. The potential for fraud is too great. Medicare and states all have to watch for fraud in their claim payments.
- bdamm 8y ago
  Right, but it’s probably done by auditing resources to treatment records. The actual patient needn’t be involved. And in countries like Canada you may end up with multiple operating agencies that are competing for efficiency, such as Coastal Health vs Providence, even though ultimately it’s the government footing the bill.
  - Scoundreller 8y ago
    Providence is under Vancouver Coastal health. The authorities aren’t competing with each other (well, not really) as they have their own geographic catchments.
    - bdamm 8y ago
      Right, but they're able to be audited against each other, even though they have separate geographic catchments. Significant discrepancies can be then analyzed. Folks who view single-payer as a system without checks need to know how those checks do in fact occur.

megablast 8y ago

We solved it by having a doctor on our team. In fact, not sure how you could solve any healthcare issues without it.

jaabe 8y ago
I work in the public sector of Denmark, and I’d recommend doing this. The companies who hire actual domain knowledge and listens to it are simply miles ahead on making software that doesn’t suck for the end-users. It would be better if we allowed departments to build their own software, because our in-house software is honestly the only stuff that truly does the job right, but I don’t see that being prioritised. So having contractors hire a few doctors is probably the best we get.
Scoundreller 8y ago
It also helps to have them as a conduit for your communications to other doctors. It’s sad that you have to pay someone a lot to (partly) forward your emails, but it works. If responding to internal emails had a billing code, I think they would fight over who gets to respond.

sli 8y ago

> For startups that want to sell to health systems and similar-sized/larger entities (...), you unfortunately have to focus on the buyer, which is very rarely someone who is "in the trenches." This is my current experience. The person bankrolling the project delivers lists of requirements, and nearly half of them end up being removed later when someone "in the trenches" either says they don't need/want it or it's too confusing of a feature. Another part of the problem? "Confusing features" for doctors includes some very standard app features, like back buttons and refresh buttons. This honestly frightens me. We had to remove the back button -- which was requested by the buyer -- because it became a patient safety issue. At least we don't have to target IE9.