11 ms·
Google Cloud Healthcare API
- gravypod 8y agoI'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 agoA 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 agoI'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 agoIt'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 agoIf 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 agoExisting 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 agoThe 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 agoIts as easy to sell a new EMR as it is to sell a new email client.
- netfl0 8y agoWith Google’s history of cancelling huge and expensive initiatives, why would anyone build on something like this. It will be different this time, they said.
- penagwin 8y agoWhile I agree with this sentiment in their consumer products (and what I'll call "consumer devs"), I feel this industry (i.e. medical) is different. 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.
- thefounder 8y agoWhat you don't understand is that Google doesn't like things that "move slow". If the product doesn't get enough attention or for whatever reason Google may pull the plug and you have no immediate replacement/open source version. Now that you mentioned that the industry moves slow I can actually see sunsetting blog post. Note this is from Google Plus but could apply to any product: ..." 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 ...""""
- glennpratt 8y agoComparing a potentially high margin product in a highly regulated sector to an unpopular social network isn't much of a comparison.
- lg 8y agoG+ is a going concern for enterprise, they only shut down the consumer version.
- penagwin 8y agoTo be fair, your example is of a social network which lives and dies by widespread usage and growth. Yes certain niches enjoyed G+ but it seems their aim was to compete with the likes of Facebook which explains why they believe they failed their goal to achieve widespread usage. 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)
- fjabre 8y agoHL7 is a joke as are most acronyms in the healthcare tech space. 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.
- droobles 8y agoI used to sit next to a guy at a healthcare startup that wrote some huge HL7 parser, I wonder if they still use it. They were considering open sourcing it.
- eclipxe 8y agoI built an HL7 parser at a startup that was open source. Mirth.
- CalumSult 8y agoI use Mirth, thanks for open sourcing it!
- markolschesky 8y agoI love Mirth and the community that's built around it. Thank you very much for all the work you did on the project.
- thefounder 8y agoWho would trust Google to build expensive products on their platform? I wouldn't be surprised if the prices change dramatically or they decide to discontinue the service. Worst decision you can make is to invest in cloud proprietary APIs/services(i.e Google Datastore/Firestore). You can put Google next to Facebook(with Parse or whatever "cloud" service they've been offering)
- javagram 8y agoGCP is 11 years old. It’s a paid service. Is there any reason to believe it would actually be deprecated? This doesn’t seem like a google reader or other free B2C product.
- mattigames 8y agoGoogle Fusion Tables [0] is B2B, its over 10 years old and it will be killed this December. Fabric is also B2B and 4 years old and will be killed in a couple of months. Source: https://killedbygoogle.com/ https://killedbygoogle.com/ [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
- v7p1Qbt1im 8y agoOff the top of my head I‘d say you have Data Studio and Firebase now, which support all of those features and more. Or am I missing something?
- tpetry 8y agoYou missed the statement of FREE b2b product ;) Google is killing dozens of free products but not the ones you are paying for.
- agentdrtran 8y agoFusion Tables was never widely used and was always a beta product.
- dejaime 8y agoit reminds me of all the discontinued crap I tried and never comited to. Google and Microsoft are basically a minefield on that front.
- partiallypro 8y agoDon't even compare Google and Microsoft on product deaths. Microsoft will deprecate a product but support it for 10 years, giving you plenty of time to move. Google will kill a product and you're SOL.
- mav3rick 8y agoMicrosoft Health Vault.
- AJRF 8y ago"Your organization controls where data is stored on Google Cloud" So...it doesn't actually control the data?
- wheelerwj 8y ago“well, we still control it, we’re just storing it with one of the worlds largest advertising companies.“
- Proven 8y agoI'd opt out. 1) I don't want to share my med data with Google 2) I don't think Google can refuse to share my health data with the US gov if they ask
- drinane 8y agoEpic might need to bend over to the big brother uncle G soon.
- organsnyder 8y agoNot saying it will never happen, but Epic is too firmly entrenched to be displaced any time soon.
- kuzehanka 8y agoNope. Google will never touch my healthcare data. They have already monopolised far too much information about me.
- partiallypro 8y agoIt's not like you have a choice if your health vendor uses GCS
- jrowley 8y agoExactly, if went to university of chicago medical center google may already have your data: https://www.chicagotribune.com/business/ct-google-university-chicago-partnership-0518-biz-20170517-story.html https://www.chicagotribune.com/business/ct-google-university...
- SmirkingRevenge 8y agoHave you ever worked in healthcare IT? The state of health care IT systems, all up and down the chain is generally horrifying (like, Equifax-level horrifying). Your data would be far safer in a managed gcloud service.
- mothsonasloth 8y agoTechnology is wonderful, we have managed to become more centralized and less free with it.
- reaperducer 8y agoI work in healthcare, and even after reading the entirety of Google's blog post about this, I still feel uneasy. 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.
- tdb7893 8y agoWould be performance and SLA for this API be built into contracts with other companies? In my experience they might be contractually obligated to maintain the API but idk if that's applicable to something like this.
- jpatokal 8y agoThis was launched last year: https://www.blog.google/products/google-cloud/google-cloud-healthcare-new-apis-customers-partners-and-security-updates/ https://www.blog.google/products/google-cloud/google-cloud-h...
- markolschesky 8y agoOur company had early access to this product and I was impressed by it. Our company had built our own FHIR datastore and I can attest to the fact that it's a more complex endeavor than it seems externally. 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-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 https://github.com/Microsoft/fhir-server 2) HAPI FHIR: http://hapifhir.io/doc_intro.html 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/ https://smilecdr.com/. 3) Vonk: Made by a company that has focused alot on FHIR based tooling. https://fire.ly/vonk/ https://fire.ly/vonk/
- evunveot 8y agoSay I'm a solo web developer and I've built informational websites for some doctors' offices and small hospitals. They want to have simple patient referral and appointment request forms on their websites (mostly they still do that stuff by phone and fax), but in order to comply with HIPAA, I'd have to adopt a whole bunch of infrastructure above and beyond the couple of semi-managed VPSs I have now, not to mention paperwork and self-audits and so forth. (Or at least that's my understanding.) 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. [0] https://www.truevault.com/pricing https://www.truevault.com/pricing
- snuxoll 8y ago> I'd have to adopt a whole bunch of infrastructure above and beyond the couple of semi-managed VPSs I have now, not to mention paperwork and self-audits and so forth. (Or at least that's my understanding.) 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.
- Animats 8y agoDidn't Google try and fail with this once already? Remember "Google Health"?[1] [1] https://en.wikipedia.org/wiki/Google_Health https://en.wikipedia.org/wiki/Google_Health
- jak92 8y agoGreat, another spot where my information will be without any (explicit ) input or consent by myself. More or less any business system these days is hosted through a service provider, with unknown policies, protections and security.
- deleted 8y ago[deleted]
- lawrenceyan 8y agoIBM Watson Health Care cries in its grave.