Google Cloud Healthcare API
cloud.google.com
cloud.google.com
The killer feature of the product is its simple connectivity to other Google Cloud products for ML/Analytics purposes. Being able to receive a large quantity of radiology images (DICOM) or clinical data (using tools like Epic Kit/Caboodle) and immediately _do something with it_ is pretty impressive and hopefully lowers the burden for innovators in the space.
Of course, there are other options if you are looking for them, namely:
1) Azure API for FHIR: https://azure.microsoft.com/en-us/services/azure-api-for-fhi... -> Focused a bit more on application-workflows currently than ML/Analytics. Also has an open-source version: https://github.com/Microsoft/fhir-server
2) HAPI FHIR: http://hapifhir.io/doc_intro.html Open-source library from the makers of the most popular HL7v2 parser library. We run a bit of this today and it works smoothly. There's unofficial commercial support (same creators, different effort) from https://smilecdr.com/.
3) Vonk: Made by a company that has focused alot on FHIR based tooling. https://fire.ly/vonk/
It's like reading through a framework devised by lawyers and policy makers. I cant wrap my head around healthcare tech to save my life and ive been working the field for 15 years. It's a jumbled mess.
HL7 is what happens when a regulator designs a tech framework.
I have personally participated in quite a bit of HL7 standards development and I can guarantee you that regulators have only minor influence over the process. HL7 work groups have multiple types of participants including providers, payers, vendors, and regulators.
The older HL7 V2 and V3 standards can take a while to learn. FHIR (which is essentially HL7 V4) is a bit easier to understand. But the health IT domain is inherently complex and can never be made simple.
Patient data is not special other than its security requirements. There does not need to be a layer of standards in this space dedicated to handling/transfer of clinical/hospital data between organizations. Private industry & hospitals can solve this without the need for a standards board or HL7 standards. We have enough standards for handling/transfer of sensitive data.
Engineers have already solved that with interoperable data systems dedicated to managing and sorting through large sets of data. Healthcare data is simply data. There are plenty of other types of highly sensitive data that don't need an entire organization dictating bloated standards implementations that are already highly fragmented themselves.
HL7 is an unnecessary abstraction.
Which they did merge and overal they do seem open to improvements of their systems and standards.
https://www.hl7.org/fhir/resourcelist.html
Documents both the REST API and JSON and XML formats for every type of resource, with lots of examples, and sufficient detail for anyone to create a compliant implementation. Documentation for all of the datatypes like dates and times, terminologies, identifiers, references, numeric values, and how to serialize and parse them. Cross links everywhere.
It's legitimately one of the best documented and well thought out APIs I have worked with. I think they took all the mistakes made and legacy baggage of the old HL7 specs to heart, and did a great job of replacing them with something much better with very high quality documentation.
There's also so much extensibility that someone implementing it could just throw away all of the default fields in a patient's record and create their own, and we're right back to a mess of records that are useless across systems without having custom handlers.
The health IT domain is simply so large and complex that including every use case in a single comprehensive standard would be totally impractical.
Most specification pages have more shoulds than shalls.
Foundational types are a huge mess. For instance there are countless types of references that look very similar but work differently: absolute references, relative references, contained references and references that are replaced as part of a transaction all use the same field. Literal references suddenly lack the type that is referenced which can be not clear from the context. Then there are references that are just free text. Nothing you would expect to be mandatory actually is: code and system are both 0..1 in Coding for instance. A lot of things are not specified how they work at all but just have examples, for instance slicing or how the serialization actually works. Adhering to profiles from someone else is a huge pain in the ass, xml schemas are easier to understand and work with, you gain nothing from using FHIR. If a FHIR rest server does not understand your conditional requests it might just execute them when the condition would evaluate to false. Types that somehow look similar are shoehorned into one type, like transaction requests and search results. FHIR sits in a sweet spot of modeling Health data: not detailed enough to be useful interoperable on its own, detailed enough to not be compatible with other models without a pain in the ass. It’s like the semantic web again where people tried modeling the world.
FHIR is a bit like JavaScript easy to get something to work at the start but hard to actually get it right.
HL7v2's problem is that it is 30 years old and probably should have been replaced by something earlier. Then again, so should most X12, mainframes, COBOL, etc. etc. FHIR is good, but the challenge is that the incentives for interoperability are much lower than those for intra-operability.
The annoying part is the QACH CORE Connectivity Rule has finally made interacting with health care partners for X12 transactions suck less by providing standard REST and SOAP interfaces for transaction exchange, but we couldn’t be bothered to implement a less shitty transaction format.
HL7 is a work of art in comparison.
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.
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.
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).
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.
It will be different this time, they said.
These customers are different, Google had to go through a lot of work to allow them to legally use their products, and will get to charge a premium. This is the high end of B2B, and unless they're moronic (which is possible) they'll know the medical industry moves slow, so any customers they acquire will almost guaranteed be long term customers.
..." while our engineering teams have put a lot of effort and dedication into building Google+ over the years, it has not achieved broad consumer or adoption, and has seen limited user interaction ...""""
I'm skeptical too, we can only wait and see. I'm essentially just hoping they understood the market they're entering but hey it's Google.
I'd also imagine they'd have service contracts for X years though? I can't imagine a health network wanting to use their service without guaranteed support for 5/10+ years. (Heck I imagine it'd take a year or two to even develop applications that use it)
https://techcrunch.com/2011/06/24/google-shuts-down-medical-...
"All you need to do is rewrite your software to use a different solution"
You do understand why this isn't an OK answer to a lot of people, right?
It appears to be more (5) steps than changing a key.
My experience with Azure and AWS paid support frankly isn't much better. But Google is definitely the leader in absolutely horrible paid customer service.
For me, Google has clearly demonstrated that I should not use any of its services until several big movers are on board.
Apple has had consumer-facing health software for longer than Google at this point: https://en.wikipedia.org/wiki/Health_(Apple)
And, since this is still Beta, it's excluded from the Google Cloud Deprecation policy at https://cloud.google.com/terms/deprecation. (And even if it was covered, you'd only have one year to migrate off of it -- so I hope you don't have a FDA-certified hardware widget directly talking to Google's APIs).
> And, since this is still Beta, it's excluded from the Google Cloud Deprecation policy
Well, sure.
> And even if it was covered, you'd only have one year to migrate off of it -- so I hope you don't have a FDA-certified hardware widget directly talking to Google's API
Yes, that would be very bad design. And not just because of the deprecation policy.
So...it doesn't actually control the data?
Is there any reason to believe it would actually be deprecated? This doesn’t seem like a google reader or other free B2C product.
[0] Google Fusion Tables was a web service for data management that provided a means for visualizing data in different charts, maps, and graphs.
[1] Fabric was a platform that helped mobile teams build better apps, understand their users, and grow their business
Is this Healthcare API just targeted at people building full-blown EMRs or is there something here that would help me handle small amounts of PHI like in the above scenarios?
Going by the examples on the pricing page, this looks like it would be massively cheaper than e.g. TrueVault [0] (who don't seem to publish their prices any more but IIRC start out in the thousands per month), if indeed this could be an alternative to TrueVault.
HIPAA isn't that complex, the hard part with cloud hosting is the need to find somebody who is willing to sign a BAA with you since (contrary to the argument of some) they are, in fact, business associates if you are storing or processing any ePHI through their services. DigitalOcean can't seem to figure their shit out, Linode appears to have everything in place based on their compliance page but they don't have any detail on a BAA (so contact support, I guess). The big cloud providers like Azure, AWS and Google are willing to work with you on this, you just don't get the nice cheap servers like you do with DigitalOcean/Linode/Vultr/etc.
This is actually the most infuriating part, hosting providers should all have the bare minimum to operate as a business associate in place if they want you to trust them with any commercial workload in general - auditing, access control and breach notification. Yet so many don’t want to sign a BAA, because compliance/legal has no idea what it actually entails I guess. PCI has a more rigid technical standard than HIPAA for fucks sake.
All of the regulatory stuff beyond that is pretty easy - and most of the framework is rough guidelines instead of "you must do X". You need to have access control and auditing in place, properly secure systems, and deal with the breach notification rules in the (hopefully unlikely) event that you detect an intrusion or accidental exposure.
People make way too big of a deal about HIPAA compliance, it's not some certification you must obtain or a huge audited ordeal. Just don't take this to mean you can be lazy, you don't fuck around with PHI because the CMS will come and smack you upside the head.
The more hands you have touching any given system the work required to ensure compliance in any regulated industry increases, that's certainly a given.
Technical compliance is the easy part in all honesty, all of the human elements (policy, procedure) requires constant attention and is the majority of what our compliance and QA teams deal with. This is the hardest thing to deal with, and it's not even just "don't expose PHI" but making sure you have everything just the way a certain insurance company likes things, that a chart has supporting documentation for a specific procedure, etc. Makes me glad I only have to deal with our applications and the systems they run on, props to the compliance team for all the headache they have to deal with.
https://www.blog.google/products/google-cloud/google-cloud-h...
More or less any business system these days is hosted through a service provider, with unknown policies, protections and security.
I'm not sure what the root of my misgivings are. Maybe I just don't trust Google anymore.
One thing I can put my finger on is the fear that Google will one day pull the plug on this project like so many others. And now we're not talking about social media posts being in jeopardy, but people's lives.