[racking7]

FHIR provides a structure for communicating these data, but does not solve the hard problem in the parent comment about the massive heterogeneity of health care data across institutions (and even within institutions). The same messiness of the original raw data in the proprietary EHR data format can be replicated in FHIR. But at least the mess is available then in an open data format and a bit more regimented on canonical elements (i.e. things like effectiveDate/DateTime).

Have you used HAPI FHIR in production at any scale? Our experience is that it completely falls over under any reasonable strain. Try working with a few thousands patents and ~100M Observations and you will see HAPI work very poorly. It's great that HAPI is very feature rich on the API side--they've implemented most of the spec. But JPA and how they're using it is not a healthcare-scale technology. Google's (Spanner based) and Microsoft's (CosmosDB & SQL Sever based) FHIR API are better at scale but have far fewer features. I'm actually ok with that because the FHIR spec's query functionality is actually much more limited. Google's BigQuery integration really helps here. I'm interested to see where AWS is going with Health Lake. In talking with them I believe they have the best paradigm for their technical implementation.

It is a shame that the open source FHIR servers haven't been great. I think they will probably improve once a scalable paradigm for working with FHIR emerges.

[claytongulick]

We'll, I tend to silo phi per client to provide for auditable data segregation, so I don't try to scale HAPI up vertically.

FHIR is nice in that you can do uri pointers to external FHIR systems for resources, so it's possible to build up a pretty complex care team and access relationships that way.

I was going down this path and had a lot of it built out, but we ended up changing direction so I never saw it all the way through.

Shame.