5 ms·

I'm amazed that Google is targeting the EMR space (HL7v2, VPNs, FHIR). This area is one that is ripe for innovation. The incumbents charge high fees, users disl

I'm amazed that Google is targeting the EMR space (HL7v2, VPNs, FHIR). This area is one that is ripe for innovation. The incumbents charge high fees, users dislike the products, the margins for operation are very high. Some products are very legacy. These tools are the things that would make building EMRs much more approachable. Not having to deal with HL7, automatically getting VPNs set up for you, and having someone else be partially liable for HIPAA compliance is a godsend.

allyant 8y ago
A few years ago I worked with a healthcare analytics company, creating an HL7 FHIR server as well as a de-identification product. The main problem with this area isn't technical - FHIR, HL7 etc all exist to meet these problems, rather the issue is buy-in/the market. Most of those healthcare companies take the approach of "if it works don't touch it" or they where already bought into one of the existing large EPR's - which is why we ended up putting our product on the back-burner as the market wasn't there yet.
bilbo0s 8y ago
>having someone else be partially liable for HIPAA compliance is a godsend.... That's not what this is, you still have 100% liability for any data that touches your software or is on your servers. (Any lawyer will tell you that liability, particularly the egregious, criminal kind, cannot be contracted away in the United States.) What Google is saying is that for some of its APIs, the data you send will be operated on in a HIPAA compliant environment. But understand that if Google's HIPAA environment somehow fails in an egregious manner, you would still be liable. All that said, the likelihood of the failure being on Google's end is remote, in the extreme. If there is a failure, it's far more likely to be on your side. In your servers where you hold the data, or where the data is being processed by you, or maybe you displayed the data to someone you shouldn't have or something like that. Very unlikely to be Google given the, I believe intentionally, limited touchpoints they have on the data.
- gravypod 8y ago
  I'm primarily talking about how their services seem to manage persistence for you. They also seem to have some tool for anonimization of PII and setting up VPN integrations.
- markolschesky 8y ago
  It's not necessarily liability, but it is shared responsibility. Someone validating that they will take responsibility for parts of your stack can be very important, especially at scale.
- snuxoll 8y ago
  If you are accepting liability as a HIPAA business associate you have done something tremendously stupid in your BAA. HIPAA business associates only face direct liability for violating the security rule, improper breach notification, misuse of PHI, etc. As a HIPAA covered entity you are still on the hook for everything else - if your cloud provider has a breach and you can identify that N records were accessed you still get the fine, unless your BA put some sort of liability transfer in the agreement (legal will not be OK with this, so I’m betting not).
robbiep 8y ago
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/
conanbatt 8y ago
Its as easy to sell a new EMR as it is to sell a new email client.

allyant 8y ago

A few years ago I worked with a healthcare analytics company, creating an HL7 FHIR server as well as a de-identification product. The main problem with this area isn't technical - FHIR, HL7 etc all exist to meet these problems, rather the issue is buy-in/the market. Most of those healthcare companies take the approach of "if it works don't touch it" or they where already bought into one of the existing large EPR's - which is why we ended up putting our product on the back-burner as the market wasn't there yet.

bilbo0s 8y ago

>having someone else be partially liable for HIPAA compliance is a godsend.... That's not what this is, you still have 100% liability for any data that touches your software or is on your servers. (Any lawyer will tell you that liability, particularly the egregious, criminal kind, cannot be contracted away in the United States.) What Google is saying is that for some of its APIs, the data you send will be operated on in a HIPAA compliant environment. But understand that if Google's HIPAA environment somehow fails in an egregious manner, you would still be liable. All that said, the likelihood of the failure being on Google's end is remote, in the extreme. If there is a failure, it's far more likely to be on your side. In your servers where you hold the data, or where the data is being processed by you, or maybe you displayed the data to someone you shouldn't have or something like that. Very unlikely to be Google given the, I believe intentionally, limited touchpoints they have on the data.

gravypod 8y ago
I'm primarily talking about how their services seem to manage persistence for you. They also seem to have some tool for anonimization of PII and setting up VPN integrations.
markolschesky 8y ago
It's not necessarily liability, but it is shared responsibility. Someone validating that they will take responsibility for parts of your stack can be very important, especially at scale.
snuxoll 8y ago
If you are accepting liability as a HIPAA business associate you have done something tremendously stupid in your BAA. HIPAA business associates only face direct liability for violating the security rule, improper breach notification, misuse of PHI, etc. As a HIPAA covered entity you are still on the hook for everything else - if your cloud provider has a breach and you can identify that N records were accessed you still get the fine, unless your BA put some sort of liability transfer in the agreement (legal will not be OK with this, so I’m betting not).

robbiep 8y ago

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/

conanbatt 8y ago

Its as easy to sell a new EMR as it is to sell a new email client.