
Google Cloud Healthcare API - epiphone
https://cloud.google.com/healthcare/
======
markolschesky
Our 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-fhi...](https://azure.microsoft.com/en-us/services/azure-api-for-fhir/) ->
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/)

------
fjabre
HL7 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.

~~~
jimbokun
I don't disagree with your assessment of HL7 historically, but FHIR
documentation is outstanding:

[https://www.hl7.org/fhir/resourcelist.html](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.

~~~
nathas
I disagree. The data format is well defined, but how those documents interact
with each other is still a jumbled mess.

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.

~~~
nradov
FHIR only provides a baseline starting point which covers the most common data
elements. That's why for any particular use case the implementers need to get
together and write a detailed Implementation Guide. The IG may include
extensions for necessary data elements not covered in the standard.

The health IT domain is simply so large and complex that including every use
case in a single comprehensive standard would be totally impractical.

------
gravypod
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.

~~~
bilbo0s
> _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.

~~~
snuxoll
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).

------
netfl0
With 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
While 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
What 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
Comparing a potentially high margin product in a highly regulated sector to an
unpopular social network isn't much of a comparison.

------
AJRF
"Your organization controls where data is stored on Google Cloud"

So...it doesn't actually control the data?

~~~
wheelerwj
“well, we still control it, we’re just storing it with one of the worlds
largest advertising companies.“

------
thefounder
Who 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)

~~~
dejaime
The part about prices is true to any cloud provider. Amazon increased our
prices by 170% over the years, same usage. I was not surprised when I saw big
shots falling back to self hosting (like Dropbox from Amazon to own hardware).

~~~
spullara
I have never seen them increase prices. Do you have a specific example of a
service that has gotten more expensive?

~~~
thefounder
Appengine could be a great example.

~~~
spullara
That is on Google. They mentioned that Amazon increased the price to run their
application.

------
evunveot
Say 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
> 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.

~~~
markolschesky
I agree that some folks often exaggerate the danger in HIPAA, especially for
someone like OP with a relatively small operation. But, for companies with
larger operations and reach it's definitely a non-trivial problem. Our
relatively small organization has two people dedicated to compliance (and
plenty of ancillary support) and goes through hundreds of audits a year. Not
having a locked down well thought out solution, both technical and
operational, can really put growth at risk in healthcare. Of course, that's
not "HIPAA compliance", but it is "what it takes to reach scale in
healthcare".

~~~
snuxoll
> But, for companies with larger operations and reach it's definitely a non-
> trivial problem.

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.

------
jpatokal
This was launched last year:

[https://www.blog.google/products/google-cloud/google-
cloud-h...](https://www.blog.google/products/google-cloud/google-cloud-
healthcare-new-apis-customers-partners-and-security-updates/)

------
drinane
Epic might need to bend over to the big brother uncle G soon.

~~~
organsnyder
Not saying it will never happen, but Epic is too firmly entrenched to be
displaced any time soon.

------
kuzehanka
Nope. Google will never touch my healthcare data. They have already
monopolised far too much information about me.

~~~
partiallypro
It's not like you have a choice if your health vendor uses GCS

~~~
jrowley
Exactly, if went to university of chicago medical center google may already
have your data: [https://www.chicagotribune.com/business/ct-google-
university...](https://www.chicagotribune.com/business/ct-google-university-
chicago-partnership-0518-biz-20170517-story.html)

------
lawrenceyan
IBM Watson Health Care cries in its grave.

------
mothsonasloth
Technology is wonderful, we have managed to become more centralized and less
free with it.

------
dejaime
it reminds me of all the discontinued crap I tried and never comited to.
Google and Microsoft are basically a minefield on that front.

~~~
partiallypro
Don'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
Microsoft Health Vault.

------
jak92
Great, 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.

------
reaperducer
I 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
Would 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.

------
Animats
Didn'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)

