4 ms·

Existing EMRs are AWFUL and are a major contributor to clinician burnout (0). Simply put, all the different workflows don’t easily map to lots of different form

Existing EMRs are AWFUL and are a major contributor to clinician burnout (0). Simply put, all the different workflows don’t easily map to lots of different forms... paper is so much more versatile. Emrs have a good place though on frequent flyers and repeat presentations. FHIR/HL7 do have use outside of this field though (secure clinical messaging and task management for example) although at some level they are still dependent on EMRs. The existing providers unfortunately have decades of vendor lock-in due to them owning the database. It will take forever to move away from them :( (0) https://catalyst.nejm.org/videos/physicians-facing-crisis-emr-burnout/ https://catalyst.nejm.org/videos/physicians-facing-crisis-em...

jimbokun 8y ago
"The existing providers unfortunately have decades of vendor lock-in due to them owning the database." But if they support FHIR APIs to get the data out, that becomes pretty irrelevant very quickly. They can still be the "official" store of record for the data. But if third party tools can hook in through FHIR APIs to read and write the data, you just need to get buy in from the doctors and clinicians to use your better UI, or better workflow, or better data analysis tools, and the EMR is suddenly relegated to a dumb pipe. The EMRs will resist this, of course. But I don't know if they have much leverage. From what I can tell, doctors despise EMRs and just see them as an inefficient tool that just adds more time spent documenting and less time spent with patients. For doctors, paper was probably a more efficient tool with a better UI for documenting their patient interactions. The EMRs are there to serve regulators and administrators. So I think the pressure for EMRs to support open standards will be huge, and will be very hard for EMRs to resist.
- nradov 8y ago
  The SMART on FHIR standard turns EHRs into a platform where developers can build "write once run everywhere" apps which work in any EHR. Physicians will still need an EHR to tie everything together but it's nice to have an extensibility standard. Most of the major EHR vendors are supporting it, and even offering app stores to make distribution easier for third-party developers. http://docs.smarthealthit.org/ http://docs.smarthealthit.org/
- gravypod 8y ago
  In my experience very few people are supporting FHIR. It's a huge shift for many of the companies running EMRs from HL7/VPN to JSON/HTTPS/REST
  - organsnyder 8y ago
    FHIR is incredibly exciting right now: - CMS Blue Button 2.0 offering access for 53 million Medicare recipients: https://bluebutton.cms.gov/ https://bluebutton.cms.gov/ - First (partially) normative release (R4) - Record attendance at the most recent FHIR Hackathon in San Antonio - MU3 mandating providers offer FHIR endpoints I think there's still plenty of room for old-style HL7v2/CCD/CDA/etc. interop, but FHIR is maturing and gaining adoption at an accelerating clip.
- ivalm 8y ago
  A big problem with EMRs is that they are unfriendly to CDS integration. For example Epic, current market leader in the space, puts a lot of limits in what can actually be presented to the Dr as part of a standard workflow (without using popups or generating your own screens via iframe). Even something simple like generating a patient-specific medication preference list (which is currently static) is hard without directly interacting with cache.

jimbokun 8y ago

"The existing providers unfortunately have decades of vendor lock-in due to them owning the database." But if they support FHIR APIs to get the data out, that becomes pretty irrelevant very quickly. They can still be the "official" store of record for the data. But if third party tools can hook in through FHIR APIs to read and write the data, you just need to get buy in from the doctors and clinicians to use your better UI, or better workflow, or better data analysis tools, and the EMR is suddenly relegated to a dumb pipe. The EMRs will resist this, of course. But I don't know if they have much leverage. From what I can tell, doctors despise EMRs and just see them as an inefficient tool that just adds more time spent documenting and less time spent with patients. For doctors, paper was probably a more efficient tool with a better UI for documenting their patient interactions. The EMRs are there to serve regulators and administrators. So I think the pressure for EMRs to support open standards will be huge, and will be very hard for EMRs to resist.

nradov 8y ago
The SMART on FHIR standard turns EHRs into a platform where developers can build "write once run everywhere" apps which work in any EHR. Physicians will still need an EHR to tie everything together but it's nice to have an extensibility standard. Most of the major EHR vendors are supporting it, and even offering app stores to make distribution easier for third-party developers. http://docs.smarthealthit.org/ http://docs.smarthealthit.org/
gravypod 8y ago
In my experience very few people are supporting FHIR. It's a huge shift for many of the companies running EMRs from HL7/VPN to JSON/HTTPS/REST
- organsnyder 8y ago
  FHIR is incredibly exciting right now: - CMS Blue Button 2.0 offering access for 53 million Medicare recipients: https://bluebutton.cms.gov/ https://bluebutton.cms.gov/ - First (partially) normative release (R4) - Record attendance at the most recent FHIR Hackathon in San Antonio - MU3 mandating providers offer FHIR endpoints I think there's still plenty of room for old-style HL7v2/CCD/CDA/etc. interop, but FHIR is maturing and gaining adoption at an accelerating clip.
ivalm 8y ago
A big problem with EMRs is that they are unfriendly to CDS integration. For example Epic, current market leader in the space, puts a lot of limits in what can actually be presented to the Dr as part of a standard workflow (without using popups or generating your own screens via iframe). Even something simple like generating a patient-specific medication preference list (which is currently static) is hard without directly interacting with cache.