Stream: dotnet
Topic: FHIR Server vs App Tier
Ryan Jorgensen (Nov 19 2020 at 00:50):
My organization is struggling with clarity on a FHIR Server vs. an App tier. Our current setup calls multiple internal microservices and transforms that data into appropriate FHIR resources specific to the CMS interoperability rule. All of the OAuth is handled via dotnet core middleware. It seems like there are two distinctions here, where the majority of the service layer is transforming data from traditional RDBMS to FHIR and the other part is handling things like token introspection, calling Epic (or other EHR) servers to retrieve FHIR resources for gathering additional patient information (i.e. member matching, coverage lookup, etc). It is a bit hard to put into words but should these things really reside in the same API? I would love some insight/examples on structure/architecture from anyone willing to provide any. Thanks!
Peter Jordan (Nov 19 2020 at 02:07):
Old school Microsoft Distributed Application Architecture makes a clear distinction between tiers (physical deployment nodes) and layers (logical application components). In this case, the basic layers appear to be API (what's exposed to external systems), Service Integration ( handling requests & responses), Application Logic Layer (processing business objects - including entity transformations), Data Access Layer (communication with the DB) and Persistence Layer. How many projects you might create to implement this in a single solution is a matter of choice - but it would certainly make sense to have at least 2 - one for the Web API and another for the remaining layers (an important factor here is whether any of them can be used by other solutions)....oh, and of course, the C# FHIR Library will be an integral part of the solution!!
Last updated: Apr 12 2022 at 19:14 UTC
