How effective is it to use the FHIR data model to store and search for clinical data? Is it a reasoned choice or a shortcut to simplify the problem?
FHIR is a standard, as indicated by the letter I – Interoperability – of the acronym, for the interchange of health data that are exposed as resources (to find out more see here). In the design of the new electronic health record, as well as in regional telemedicine tenders, FHIR was indicated not only to achieve interoperability with other systems but also as a format for information persistence. In other words, it was decided to adopt FHIR to create the Health Data Ecosystem (in FSE 2.0) or the Clinical Data Repository (CDR) of telemedicine.
The CDR equal FHIR server equation has also been used as a model in many regional-corporate Electronic Medical Record projects or in the case of new territorial systems. The question we must ask ourselves is whether this choice is the most appropriate for storing and researching clinical data. Before answering the question, however, it is necessary to define the context and the purpose for which we must / want to manage structured and non-structured clinical data.
The context
If the context includes multiple data sources for the same classes, for example a region where there are multiple laboratory systems (LIS) or electronic medical records (CCE), it becomes essential to be able to organize and aggregate information so as to, for example, be able to graphically display the trend of blood sugar (which can be measured in different ways and with different units of measurement) or blood pressure.
What do we want to do with the data
If we want to use data to enrich clinical systems and equip them with intelligent functions (see for example here) it is necessary to associate them with a precise medical meaning, an operation which requires an exact understanding of the information they express. This task is now performed by doctors who, by reading the data, are able to interpret, correlate and use them in their decision-making process. If we want to implement these logics in clinical software, it is essential to attribute a precise meaning to the data.
The importance of semantics
To use the data in the two areas described above, it is not enough to fix a data format, i.e. the syntax, but it is necessary to define a semantics that expresses the meaning that the data expresses and which, in medicine, can be very broad. Let’s take blood pressure for example. This is expressed in two measures, the diastolic (also called minimum) and the systolic (maximum). Pressure can be measured in different parts of the body, at rest or in motion, in different positions (for example sitting or lying down), with different medical devices and methods. In some cases the two measurements may be sufficient while in others, for example in the case of an unstable form of hypertension, the other information may also be relevant.
The data model of FHIR
The FHIR data model is made up of 157 resources divided into 5 logical levels, each of which includes one or more modules.
In principle, resources are designed for exchange between systems, rather than as a database storage format. A practical consequence of this is that, somehow, resources are highly denormalized, so that granular exchanges are fairly independent. Each resource manages a type of data, for example, patient demographics are found only in the Patient resource but at a clinical level there may be overlaps (for example a health problem expressed as an Observation rather than a Condition).
The Observation
One of the most used resources is Observation which can express:
Vital signs such as body weight, blood pressure, and temperature Lab data such as blood glucose or a GFR measurement Imaging findings such as bone density or fetal measurements Clinical findings such as abdominal tension Medical device measurements such as heart rate data electrocardiogram or pulse oximetry Device settings, such as mechanical ventilator parameters. Clinical assessment tools such as APGAR or Glasgow Coma Score Personal characteristics such as eye color Social history, such as tobacco use, family support or cognitive status. Key features such as pregnancy status or death certificate Product quality tests such as pH, dosage, microbial limits, etc. on product and substance
The data expressed by Observation is identified by a code and a coding system (e.g. LOINC). The resource structure includes various data including date and time, body part observed, method, sample, device, reference values. The semantic meaning is therefore left to the coding and is integrated by the data present in the structure, with the risk of possible inconsistencies with what is defined by the coding system (for example a LOINC code which refers to a different sample from the one expressed within the ‘Observation).
In the Health Data Ecosystem, LOINC is mentioned as a coding system (already used in the current ESF) and SNOMED is mentioned, which however has not been officially adopted by our country.
In the next episode we will see in detail how LOINC is structured and what problems it presents.
1 – Continue
I like:
Like Loading…