3 ms·

Sadly, I don't see this happening without the government making it a requirement that EMR adopt the standard. The resilience to change in healthcare is unimagin

Sadly, I don't see this happening without the government making it a requirement that EMR adopt the standard. The resilience to change in healthcare is unimaginable.

krschultz 12y ago
Maybe that's because we (software engineers) are not providing them value? As far as I can tell, the EMR system my surgeons & doctors use is solely a hindrance to his workflow as compared to paper charts. I'm sure it's easier for the people/computers processing paperwork and billing on the backend, but for the doctors and nurses in the room all I've heard so far are complaints. From my observation, the UI/UX of the whole thing is terrible. I'm actually embarrassed by it as a member of the profession.
- misthop 12y ago
  Sadly, the EMR is not made for your surgeons - it is made for the people doing billing. EMRs are good at capturing the data that is needed to get as many dollars as possible from insurance companies. It is only recently that quality of care metrics have had any impact on billing (Gross oversimplification - Under the ACA Medi[care/caid] payments can be limited for low quality care). Prior to the ACA the increased costs of making good EMR workflows for providers was a net negative from a hospital revenue perspective.
  - tel 12y ago
    This is super true. There's not a lot of proof of business models for healthcare IT outside of billing. If you try it you'll quickly learn that a practice or hospital's interaction with insurers is the most important one they have.
markolschesky 12y ago
I don't know if this is true. Epic has already implemented large parts of FHIR and Cerner has also committed to it as well. You can even play around with Epic's implementation on FHIR here: http://open.epic.com/Interface/FHIR http://open.epic.com/Interface/FHIR. I'll admit. I was shocked when I found out it connected to a real Interconnect engine. This makes a lot of sense. IHE profiles and CCDAs are suboptimal ways in 2015 to transfer data between HIEs and Epic/Cerner/Allscripts along with every other EHR vendor either sell them or need to connect with them. It would behoove them to embrace this support in the same way it behooved hospitals to embrace HL7v2 in 1990: it saves them alot of work and money. Of course, this doesn't help the average patient or app developer. How users will interact with these APIs and whether or not hospitals will have a standard and easy way to open them up is still yet to be seen. I imagine there will still be some work involved there, but I'm optimistic for the future.

Sadly, I don't see this happening without the government making it a requirement that EMR adopt the standard. The resilience to change in healthcare is unimaginable.

krschultz 12y ago

Maybe that's because we (software engineers) are not providing them value? As far as I can tell, the EMR system my surgeons & doctors use is solely a hindrance to his workflow as compared to paper charts. I'm sure it's easier for the people/computers processing paperwork and billing on the backend, but for the doctors and nurses in the room all I've heard so far are complaints. From my observation, the UI/UX of the whole thing is terrible. I'm actually embarrassed by it as a member of the profession.

misthop 12y ago
Sadly, the EMR is not made for your surgeons - it is made for the people doing billing. EMRs are good at capturing the data that is needed to get as many dollars as possible from insurance companies. It is only recently that quality of care metrics have had any impact on billing (Gross oversimplification - Under the ACA Medi[care/caid] payments can be limited for low quality care). Prior to the ACA the increased costs of making good EMR workflows for providers was a net negative from a hospital revenue perspective.
- tel 12y ago
  This is super true. There's not a lot of proof of business models for healthcare IT outside of billing. If you try it you'll quickly learn that a practice or hospital's interaction with insurers is the most important one they have.

markolschesky 12y ago

I don't know if this is true. Epic has already implemented large parts of FHIR and Cerner has also committed to it as well. You can even play around with Epic's implementation on FHIR here: http://open.epic.com/Interface/FHIR http://open.epic.com/Interface/FHIR. I'll admit. I was shocked when I found out it connected to a real Interconnect engine. This makes a lot of sense. IHE profiles and CCDAs are suboptimal ways in 2015 to transfer data between HIEs and Epic/Cerner/Allscripts along with every other EHR vendor either sell them or need to connect with them. It would behoove them to embrace this support in the same way it behooved hospitals to embrace HL7v2 in 1990: it saves them alot of work and money. Of course, this doesn't help the average patient or app developer. How users will interact with these APIs and whether or not hospitals will have a standard and easy way to open them up is still yet to be seen. I imagine there will still be some work involved there, but I'm optimistic for the future.