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:
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/
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.
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.
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.
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.
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.
HL7 is an independent, worldwide standards development organization. Which specific framework are you referring to?
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.
I was referring to all frameworks/standards that the HL7 org has developed for handling of patient/clinical data.
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.
HL7v2 was invented in 1989. It was invented to meet the needs of then intra-operability between existing HIS systems. HL7 itself is a open organization comprised of a variety of members from vendors to health systems to life sciences/pharma.
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.
People love to bitch about HL7, but it gets far too much vitriol compared to X12. You want to talk about an antiquated format that should be taken out back and shot, here is your target.
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.
I 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.
We still use Mirth in a few legacy systems at work. I have fond memories of writing some custom JavaScript modules that were manipulating HL7 data at the time, was some fun work. I believe that they're still in use today, too.
Ha! This brings back memories - trying to figure out exactly what HL7 FHIR resource your data belongs to, and how the relationships are setup can take a long time.
Yeah, healthcare standards are peculiar..
Not just HL7 though, I find that a lot of the communication formats (with government services etc) are either badly documented or badly designed. Usually, both.
Have you taken the time to enter formal change requests for problems you have found in HL7 standards? Implementers are encouraged to do so, and the HL7 work groups do take those requests seriously. Sometimes you have to take active steps to improve the situation.
For HL7 I have not done so because I don't actively work with it(apart from helping a colleague every now and then). For other formats provided by the (Belgian) government I have. And even made some PRs to their services :)
Which they did merge and overal they do seem open to improvements of their systems and standards.
I wrote a HL7 ADT parser (version 1/2 with the horrible MSH header) with some fields removed/obfuscated to meet legislation in my country, yes HL7 is a mess, it looks awful, but it works.
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.
>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.
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).
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.
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.
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.
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 :(
"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.
A big problem with EMRs is that they are unfriendly to CDS integration. For example Epic, current market leader in the space, puts a lot of limits in what can actually be presented to the Dr as part of a standard workflow (without using popups or generating your own screens via iframe). Even something simple like generating a patient-specific medication preference list (which is currently static) is hard without directly interacting with cache.
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.
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.
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 ...""""
To 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)
My experience with GCP over the last 3 years has been that they have stuck to their contractual obligations really well. A few APIs were deprecated, but always in accordance with their deprecation policy, which matches exactly with Amazon's.
We got completely bait and switched as they assured us some feature was 100% possible, now we're partly in GCP and the feature is "impossible" now, so we're rolling back to aws. Our need is pretty unique, and it was a move that no engineer supported, but let's say gcp doesn't have any fans over here.
That's my complaint with GCP. Everyone always points to Google's history of deprecating things, but I think the bigger issue is the lack of obvious follow-through and customer empathy.
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.
What's crazy is that we were an initial launch partner for a big new product and have very personal connections inside google. We host events with google every few months, and they pushed us super hard on gcp. Even with all of this it's still a can't do, idk what a company who doesn't have these connections would do.
Didn't know about that. To be fair though, it wasn't deprecated, but migrated to another service. And the migration guide looks extremely simple (effectively just change some config vars).
Why? The original comment was around GCM being deprecated in favor of FCM. It was literally a simple API key change and that is it. Not sure why this is so hard to comprehend.
Google literally already has one product cancellation in the EHR space: Google Health was introduced in 2008 and canceled in 2011. https://en.wikipedia.org/wiki/Google_Health
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).
Google Health was a completely unrelated experiment, an online repository aimed at consumers to facilitate storage & sharing of personal medical records. That's not remotely the same as what's going on here.
Google Health was a consumer product in the PHR space, not an enterprise infrastructure product.
supporting the EHR space. There is a loose descriptive similarity (they both involve “health records”), but substantively they are not at all the same business domain.
> 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.
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)
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).
Google 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/
[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
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.
> 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.
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".
> 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.
Have 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.
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.
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.
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.
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/