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 between jurisdictions, within the healthcare ecosystem and across use cases in terms of practices, requirements and regulations: an animal at the vet’s and a patient in the emergency department are both modeled by the Patient FHIR® resource, so is 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, using FHIR® resources to exchange, store and access data.
3TB (terabyte) is the storage capacity required by a FHIR® server to ensure the smooth running of an organization handling millions of patients a year. This organization would need to create an average of 500 FHIR® resources per patient, or 5 billion FHIR® resources per year. Without substantial storage capacity and massive resource production, the FHIR® server will not be able to handle such large amounts of 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).
