Stream: implementers
Topic: EHR vs FHIR Server
ravi.kuchi (Nov 09 2021 at 02:30):
Hi all,
I am looking for some thoughts and recommendations from the community. In the current architecture we have all the Enterprise data including our legacy EHR data pooled into a FHIR server (SmileCDR).
All the clinical apps feed off from the FHIR server, some of them also write into the FHIR server. We are currently in the process of replacing our legacy EHR with a new EHR that has some FHIR (R4) API capability. The thought process of the management is that the apps can leverage the out of box FHIR api capability and some custom api that the EHR offers and therefore get rid of the full blown FHIR server model.
However, being with the community over 5 years I see that this is a grave mistake because a full blown FHIR server offers:
1) Advanced Search Capabilities that the EHR can not offer
2) Workflow (Subscription) capabilities that are fine grained and can be delivered in different mechanisms.
3) Full fledged terminology capabilities
4) Smart on FHIR App Framework
5) CQL capabilities
6) GraphQl Capabilities
I may have missed a few other capabilties, so I humbly request the community to provide your thoughts...
@Grahame Grieve @Lloyd McKenzie @Bryn Rhodes @Josh Mandel
Grahame Grieve (Nov 09 2021 at 05:00):
well, yes, a capable FHIR server does all sorts of things an EHR server doesn't, but you don't get those things for free; there's a reason an EHR server doesn't do all of those things
Cooper Thompson (Nov 09 2021 at 15:22):
On the other hand, often EHR FHIR servers have very tight integration between the FHIR API and data access policies. I've seen standalone FHIR servers struggle to replicate the policies. The challenge isn't really technical - the standalone FHIR servers often can support defining user based security policies (and I expect SmileCDR does). The challenge is operational. Anytime you change a policy (i.e. this lab test result for children ages 16-18 can no longer be seen by delegate users) you need to remember to update the policy everywhere, so that it applies both to the EHR patient portal and the FHIR APIs.
Also, you'll need to sync user accounts and user<->patient relationship information. For example, if a husband is no longer has delegate access to their ex-wife's chart, that relationship revokation often is done in the EHR, and you'd need to sync it to the standalone FHIR server. Or sync it from wherever it is maintained to wherever it needs to be.
ravi.kuchi (Nov 10 2021 at 23:55):
Let me rephrase my Question, "Is it worth to afford a full blown FHIR server when you have considerable amount of clinical applications that will be built outside EHR (Because the EHR cannot support these functionalities)?"
Bryn Rhodes (Nov 10 2021 at 23:58):
I think that depends on what those applications are and how much of a gap there is between what they need and what your EHR's native server provides.
ravi.kuchi (Nov 10 2021 at 23:59):
I listed the capabilities 1-6 in my first post that we foresee to leverage
Bryn Rhodes (Nov 11 2021 at 00:00):
The open source FHIR servers are built pretty modularly such that you can plug in capabilities as you need them. I've seen the HAPI FHIR server, for example, implemented as a facade on top of an existing EHR and that was very effective and low cost to implement. It was set up as passthrough for everything by default, and then when there were additional capabilities required by applications, those could be provided by plugging in custom providers for just those resources.
Bryn Rhodes (Nov 11 2021 at 00:01):
That architectural pattern would allow you to implement each of the 6 capabilities you listed, with varying degrees of difficulty.
ravi.kuchi (Nov 11 2021 at 00:05):
Yes, we were in the facade implementation model initially but it limited the search capabilities as it was directly dependent on the native indexes being supported and also we had data in multiple sources which made aggregation difficult/impossible in some use cases. We later moved to full blown FHIR server model and pooled all resources, now we are able to meet the data needs of most of the applications as it offers _include, _revincludes, chain parameters etc.
ravi.kuchi (Nov 11 2021 at 00:10):
We also use lot of subscriptions which enabled workflows in the applications. This is not possible in facade implementation.
Grahame Grieve (Nov 11 2021 at 01:58):
it is possible. Just rather hard and intricate
Cooper Thompson (Nov 11 2021 at 14:26):
@Bryn Rhodes for HAPI as a façade on top of an EHR, I'm curious what authorization pattern you used, and how you operationalized the data access policy. Do you have any info on how that was done? Was HAPI acting as the OAuth2 server? Or was it OAuth2 at all? How did you manage user identity across the two components?
Bryn Rhodes (Nov 11 2021 at 14:55):
My understanding of the implementation was that authorization was just passthrough to the EHR's authorization server. Happy to try to put you in touch with the technical lead on that implementation if it would help?
Last updated: Apr 12 2022 at 19:14 UTC
