Choosing FHIR as the data model for a Clinical Data Repository is very risky. Let’s see why.
I return to a topic that has aroused a lot of curiosity and several questions. Let’s remember what FHIR is, reporting what the HL7 website says – “FHIR is a standard for health care data exchange, published by HL7®” – i.e. a standard for data exchange. There are two models:
Facade, in which a system exposes services for accessing and writing FHIR resources, in which data can have any format; Repository (archive), in which data is converted and stored as FHIR resources and made accessible via services.
As you know, many regions, driven by what the Ministry of Health and the Department for Digital Transformation have defined for the Health Data Ecosystem, foreseen with the ESF 2.0, have decided to base the Clinical Data Repositories of Electronic Medical Records and of its EDS infrastructures on the FHIR data model.
But why do I mention quicksand in the title? Because FHIR is a standard that is not yet consolidated. Let’s look at the resource map of the current version, 5.
I report, translating literally, what the HL7 website indicates. Resources marked with N are “normative,” meaning they have been approved through the ANSI regulatory process in a previous version and their content can be considered stable and has been “locked,” subjecting it to FHIR cross-version compatibility rules. Changes are possible, but are expected to be infrequent and strictly limited.
The others are identified by a number (on the right) indicating the level of maturity, with zero being the lowest, 5 the highest. Almost all, except 4, are defined as Trial Use, the contents of which have been well reviewed and the authors consider them ready for use in production systems. They were put to a vote and approved as the official standard. However, they have not yet seen widespread production use across the full spectrum of environments in which they are intended to be used. In some cases, there may be documented known issues that require implementation experience to determine appropriate solutions. Future versions of FHIR may make significant changes to Trial Use content that are not compatible with previously published content.
As you can see for yourself, in the clinical setting, there is only one resource that has achieved regulatory status: Observation. All the others vary from 0 to 5. Important resources such as AllergyIntolerance (3), AdverseEvent (2), CarePlan (2), CareTeam (2), RiskAssessment (2) are between 3 and 2. Same thing for some resources too basic, important, such as Task (3), Appointment (2), Schedule (3), EpisodeOfCare (2).
But what changes can a resource have? Is backward compatibility or forward compatibility guaranteed? Let’s see some examples. The Observation resource, in version 5, despite being normative from 4, introduced these elements:
Let’s examine the Condition – Content resource which is at level 5 and find out what changes have been made by version 4 and 4B.
The Condition resource is used for define a condition, problem, diagnosis, or other clinical event, situation, issue, or concept that has reached a level of concern. As you can see, the changes are not insignificant.
But how much time has passed between one version and another? Version 4 came out in October 2019, 4B in May 2022, and 5 in March 2023.
Does it then make sense to choose FHIR as a data model for a Clinical Data Repository? Did whoever made this choice consider these aspects? And if so, what conclusions did you reach?
For those who want to know more about FHIR and also about other reasons that suggest not using it for data persistence, as well as about the openEHR alternative, find several articles here.
I like:
I like Loading…