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.
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 ?
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.
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.