Stream: implementers
Topic: FHIR Server Architecture Best Practices (System of Record)
Blake Theiss (Aug 11 2021 at 20:46):
Hello Everyone, The company I work for is in the progress of doing R & D on building our own EHR Application and we are definitely considering have a FHIR component. My question to everyone is: When designing modern healthcare applications, do we make the FHIR Server the system of record? Especially, if you are starting from scratch. (or) Do you have your own internal app/database and do a lot of triggers/subscriptions back and forth to keep both systems up to date.
Vadim Peretokin (Aug 12 2021 at 07:58):
I'm seeing greenfield applications that go FHIR-native and are happy with this. @nicola (RIO/SS) is a proponent of this with aidbox especially.
René Spronk (Aug 12 2021 at 09:33):
Caveat being: FHIR has (sometimes incompatible) releases, and may not exist any more 10 or 20 years from now. If that's not a problem it's ok to use FHIR as a storage format. Prior to FHIR I was one of the proponents of using the HL7v3 RIM as a storage format - only too well [on hindsight] that not too many organizations actually did this ( http://www.ringholm.com/docs/03100_en.htm ). However, this has made me extremely hesitant to use any interoperability standard as a persistence format.
In case of any doubt: create a FHIR frontend (=duplicate), don't go all in.
Michele Mottini (Aug 12 2021 at 13:07):
I would advise against using FHIR as your system of record: it is an interoperability format (actually 3 formats that are going to become 4 etc) designed to support a lot of use cases all over the world - so it has at the same time a lot of stuff you won't probably need and possibly is missing things you'll need (eg if you are in the US most likely you'll collect race and ethnicity information, that are not native elements in FHIR). Design a database to support your use cases and map that to/from FHIR
Daniel Venton (Aug 12 2021 at 13:42):
If your database table definitions look a whole lot like FHIR structure definitions, just chalk that up to coincidence.
Paul Church (Aug 12 2021 at 14:01):
I'm aware of quite a few Google Cloud customers using FHIR as their system of record. It has some tradeoffs because of its focus on interoperability but it provides a lot of structure that can be easier than starting from scratch.
Josh Mandel (Aug 12 2021 at 14:01):
I'd definitely suggest starting with FHIR and evaluating for your needs. In practice, I see developers make "simplifications" to FHIR early on, only to discover later why the FHIR model uses a certain structure (e.g., the prevalence of CodeableConcepts where you'd think a simple code would work).
Josh Mandel (Aug 12 2021 at 14:02):
The value of standardized tooling (as Paul mentions) is significant and growing. But there's no easy answers here; you'll need to evaluate the trade-offs in your own context.
René Spronk (Aug 12 2021 at 14:02):
For that, the HL7v3 RIM would actually be much better as a storage format ;-)
Lloyd McKenzie (Aug 12 2021 at 14:27):
Being informed by FHIR is certainly useful - e.g. building in extensibility, supporting multiple codings, etc. is useful regardless of what external interfaces you have. But also think about what your internal search requirements will be. Also, "internal FHIR" can mean a wide variety of things - lots of discussion on this stream #storage for FHIR.
nicola (RIO/SS) (Aug 12 2021 at 23:08):
We developed and are developing different EHRs on FHIR, and recommend considering this FHIR-first approach. While working on EHR one of the challenging problems is a "good informational model". It's hard to do it "right" with the first and second attempts, under the pressure of business. FHIR is an amazing repository of models (our public treasure), verified by hundreds of professionals. I think in 95% of cases your model will be worse than FHIR. Maybe you are the unique 5%. FHIR-first land is quite unexplored, but at least we can do it together.
nicola (RIO/SS) (Aug 12 2021 at 23:21):
In our FHIR backend (Aidbox), we store FHIR resources almost "as is" using advanced postgres binary json - so we do not need to map it back and forth or replicate into "FHIR CDR". For system internal data, which could not be represented as FHIR resources - we create a lot of "Custom Resources", playing the same rules as FHIR resources (references, API etc)
Blake Theiss (Aug 16 2021 at 14:42):
Thank you everyone for the time. Appreciate you giving me your thoughts.
Last updated: Apr 12 2022 at 19:14 UTC
