Context
FHIR® (Fast Health Interoperability Resources), is not the guarantee of interoperability even if it remains a great tool for exchanging or modeling health objects.
It is essential that the modeling and the data respect certain rules in order to ensure their interoperability.
Various issues around FHIR need to be resolved in order to correctly exploit this standard.
FHIR, the assurance of semantic interoperability ?
In medical interoperability, semantics is the representation of concepts by codes. If the codes used are not the same, it becomes very complicated to function and to exploit health data. For example, using the same FHIR Condition resource (for a personal history) if one healthcare facility models cancer by a code “CAN” and another by “Cancer”, what should I look for if I want the history of Cancer ?
Although FHIR makes it possible to define sets of values for the coding of concepts, it is preferable to rely on terminological standards, standardized and agreed at national (eg: NOS) or international (UCUM, Loinc, Snomed) level. This ensures unambiguous interpretation, sharing and understanding of data between different systems, and even between different countries.
Although Fyrstain is not a specialist in semantic interoperability, we have experience with the various terminological standards and can refer you to specialized partners to meet your needs.
FHIR profiling or adaptation to specific solutions.
The standard makes available a common base specification on which a variety of different solutions are implemented, these are the resources. There is great variability across jurisdictions, across the healthcare ecosystem, and across use cases in practices, requirements, and regulations: an animal in vets and a patient in the emergency room are all two modeled by the Patient FHIR resource is therefore nothing without profiling: “Profiling FHIR” (https://www.hl7.org/fhir/profiling.html
Profiling consists of adapting FHIR resource definitions according to a particular context, using constraints and extensions. For example, these adaptations specify rules regarding which resource items are or are not used. Also, by providing descriptions of how resource elements and API functionality correspond to local requirements and/or implementations.
Creating profiles requires specific skills and tools. We can accompany you on these tasks or train you.
Difficulty finding efficient FHIR servers
A FHIR server implements the HL7 FHIR standard by using FHIR resources to exchange data, but also store and access it.
3 TB (terabyte) is the storage capacity necessary for an FHIR server to allow the proper functioning of an organization welcoming millions of patients a year. This organization will have to create an average of 500 FHIR resources per patient and therefore 5 billion FHIR resources per year. Without substantial storage capacity and massive production of resources, the FHIR server will not be efficient enough to handle such important data.
A system sending 8 million HL7 messages per day, or 15 FHIR resources produced per message, means that the system is ingesting approximately 2000 FHIR resources per second. A FHIR server should therefore be able to ingest/create thousands of resources per second.
Many manufacturers are working to improve their solutions to these problems. In the meantime, it is important to study the performance needs of your solution and to plan an architecture that does not bind you to a single technology.
Discover Fyrstain solutions on FHIR® (Link : Our services).
