Asking for System Architecture for FHIR API Guidance

Good Day FHIR Community!
The main focus for this post is to ask for correction on what I have picked up from
all the self research I have done.

I am new to FHIR and any HL7 related specification.
I have been doing intense research on FHIR and its application from
the technical perspective.
I also have been looking up Connectathon presentation ppts
as well as FHIR related youtube videos (particularly on the architectural perspective).

I would like to know if what I have picked up is correct and would like to one question as an extension of my understanding.

So here we go…

FHIR is mainly focused on creating a “strict” specification (standard) in representing medical data using REST API as one of the paradigms provided by spec (data model of resources are strictly there → I do know that you can do profiling to customize resources but this would go against the whole idea of “standardization” idealism) to transfer/share data across systems.

The reason for the word “strict” is because from what I have read and seen, in architecture perspective, use of DB is not strictly limited to regular Legacy RDB but Document based DB. However, the model of resources are strictly specified and must follow the structure for FHIR to act as a standard and for different EMR or HIMS system to decode the data.

Referencing to one of the youtube video by Grahame Grieve (Grahame Grieve - FHIR or Relational Model for Storing Data | DevDays 2020 Virtual June - YouTube)
it is up to the implementers to decide how strict you want the system to handle the medical data. Also, depending on the strictness of data granularity, it would affect the proportion of RDBMS and Document DB (MongoDB).

So based on all the information above and how I understood FHIR and supposedly the architecture (although I personally think this depends on how implementers have designed the system architecture)

If we were to utilize FHIR as a “medium” of standardizing data model (in JSON/XML), it would then need a conversion API for “EVERY” system that sends/receives FHIR data?
I would care less about receiving FHIR data since data received would ALREADY be in FHIR format but for the action of “SENDING” data over to different systems, it would need an API for converting Legacy DB (this would differ and its ERD would differ in different EMR systems) based data in the form of FHIR resources?

I personally think this “act” of applying legacy db to FHIR conversion API would need customizing for different systems with different ERD or am I wrong ?

Thank you in advance for the help!

Using extensions with FHIR does not go against the “standardization” ideal. Extensions will be a normal part of FHIR usage and will be essential in some areas. Extensions allow the ‘generic’ base FHIR specification to meet the varying needs of different countries, disciplines and implementation spaces while still ensuring interoperability on the core elements.

FHIR is completely silent on how data is persisted. There is no need to use FHIR in your persistence layer at all. So long as the stored data is mapped to and from FHIR for exchange purposes, the persistence layer can be anything at all. Even if the persistence layer is FHIR-based, mapping will be necessary to accommodate different FHIR versions.

You are correct that adopting FHIR will involve all systems having a conversion layer. That’s true whenever implementing a ‘standard’ interface - v2, v3, FHIR, X12, whatever. However, by creating a mapping to a single interface, systems can interoperate with a wide range of partners, whereas without a standard, systems would be required to have a different set of mapping transformations for each partner they shared information with.

1 Like

Thank you for the response @lloyd!

As you mentioned right off the bat, adding extensions doesn’t go against the “standardization” ideal from FHIR perspective. However, if FHIR was seen as an International “standard” for Interoperability medium, I thought including extensions on base FHIR resource would cause “information” to be lost when data is transferred and shared abroad (it’s probably not common and it also is probably hard to unite medical information [personal identification and such] internationally yet). So from this bigger view perspective I thought adding, possibly unrecognized extension by one FHIR server, would deteriorate “standard” ideal.

In response to your third paragraph about mapping to a single interface, would you then consider FHIR targeting EMR/HIM vendors? As you mentioned about how without standard interface, each partner systems share information with would have to have different set of mapping transformations.
After developing demo client apps with my shallow knowledge in the field, the impression I got about implementing FHIR from client perspective (browser), it is easier to unpackage data since it’s JSON/XML format. However, it is harder to map to FHIR resource format the other way around (client to FHIR server) → of course this would differ and my implementation method may be completely wrong but I’m wondering if other entering developers share the same thoughts?

FHIR doesn’t guarantee support for any element in the standard. It’s completely fine for a system to receive a Patient resource and throw away birth month and day and name because it doesn’t support those elements (maybe it deals with anonymized data or maybe it deals with chickens. Extensions might be more vulnerable to being thrown away because they are, by definition, elements that are less widely supported. But, in particular exchange contexts, there will be extensions that are better supported than some core elements. In summary - core does not reflect ‘ideal’. Core reflects ‘what’s most agreed’.

FHIR is ‘targeting’ anyone/everyone. It’s a standard. We think the world would be a better place if every kind of system used it (hospital, pharmacy, dentistry, chiropractic, research, claims, public health, whatever). How easy or hard it is to map will vary. Also, merely mapping data to FHIR doesn’t guarantee interoperability. Two systems might map their representation of allergy, but if they both use different code systems, one differentiates allergies from intolerances and one doesn’t, and one populates reaction information and one doesn’t, the degree of “interoperability” will be limited (but presumably better than none).

FHIR gives a framework for interoperability. Implementation guides build on that framework by guiding how to use FHIR to achieve a desired ‘level’ of interoperability in a particular space that’s sufficient to address certain requirements. Implementations are then challenged to map their data (and sometimes enhance their capabilities) to meet the requirements of the IG. Those who do so get the benefit of the degree of interoperability promised by the IG. That degree of interoperability is rarely absolute, but rather “good enough” for the desired outcomes.

Often the initial bar is set relatively low - to encourage adoption. Once there’s a critical mass on board, the bar can slowly be raised in a way that’s manageable for implementers and provides discrete benefits that justify the cost of the incremental effort.

1 Like

Thanks for the detailed explanation on FHIR and sorry for the late reply!

I do feel like I’m missing bits here and there but none the less your responses have helped me clear out some of the blurs!

Looking forward to further communicating with the community!