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.
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.
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).
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.
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-em...
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.
- CMS Blue Button 2.0 offering access for 53 million Medicare recipients: 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.