Stream: implementers
Topic: CARIN BlueButton/SMART on FHIR and Data Persistence
Josh Lamb (Oct 29 2019 at 16:07):
Hello, I am working for a health plan that is newly adopting a SMART on FHIR flow (CARIN BlueButton) to provide a few key resources (EOB and Coverage) to app developers. This process will involve exposing a few FHIR APIs that will provide read only access to these resources.
My question is regarding how others have implemented this soulution. I am struggling with the idea of using a full FHIR server to persist the many resources that are involved to build the EOB and Coverage responses. Instead I am leaning toward the idea of building these response objects on demand using existing data stores that are available at my organization. The benefits in my mind for building responses on demand from non-FHIR resources is that we will not need to maintain a separate copy of all of our Patient data in a FHIR server.
At a high level, am I thinking about this correctly? Is it wise to build FHIR resources on-demand rather than creating the resources before hand? My understanding is that many healthplans and EHR vendors only expose a small number of FHIR resources and mostly deal with read only operations. This leads me to believe that FHIR resources are not being used as the backend, but instead FHIR is primarily being used as an interoperability layer. For further context I was thinking I would use a R4 FHIR client (Fire.ly .NET client) to construct the needed resources for a EOB and to return a bundle containing all relevant information for a patient, rather than constructing a bundle through querying already persisted resources contained under a FHIR server.
Thanks!
Lloyd McKenzie (Oct 29 2019 at 16:29):
Building the FHIR objects on the fly is a viable (and common) strategy. If you're doing SMART, the expectation is that you'll respond to standard FHIR queries, so you'll need to be able to search on standard criteria and return resources individually as requested by the SMART app
Josh Lamb (Oct 29 2019 at 16:57):
Thanks for the input!
Brian Postlethwaite (Oct 30 2019 at 23:18):
And if you're on the dotnet stack, look at the fhir-net-web-api project on github for some examples on doing a facade.
There are other options too.
Check the #dotnet stream if you want to ask questions in that specifically.
Christiaan Knaap (Oct 31 2019 at 10:08):
This is such a common strategy that we created Vonk FHIR Facade for it. See the docs for details.
Josh Lamb (Oct 31 2019 at 20:26):
Thanks for the reply. I am currently trying out a few server options, Azure FHIR Api and Vonk, in case we decide to replicate our data within a FHIR store. I will try out a facade type approach after.
Last updated: Apr 12 2022 at 19:14 UTC
