Let’s find out what are the limits of LOINC, the system with which to codify the observations.
After having examined the purposes and the structure of FHIR (here you can find the previous article) let’s go into a little more detail on LOINC, the coding system with which to represent vital parameters, measurements, observations and laboratory results.
LOINC is a coding system initially created for this last purpose (in fact it was called Laboratory Observation Identifiers Names and Codes) and subsequently extended to manage observations and clinical documents (transforming the initial L into Logical). The coding criterion is based on six dimensions: the component or analyte, ie the substance or fact that is being measured; the property being measured; the time interval to which the measurement refers; the sample or system; the scale, i.e. how the value of the observation is expressed (e.g. quantitative, qualitative), the (methodical) measurement methodology adopted (optional). Unlike other systems, there is no real ontology. Each item is associated with a five-digit numerical code plus a checksum. For example these two items:
14749-6; Glucose ; SCnc ; Pt ; Ser/Plas ; Qn ; ;
2345-7; ; Glucose ; MCnc ; Pt ; Ser/Plas ; Qn ; ;
refer to blood glucose measured in serum or plasma in a timely manner with a quantitative value. In the first case, the concentration of the substance is measured, the result of which is expressed in mmol/L, in the second, the concentration of the mass, the result of which is expressed in mg/dL.
Whenever there is a change in any of the six dimensions, a new code is generated. For example, again for blood sugar, there are ad hoc codes in the case of results produced with strips in an automated (2340-8) or manual (2341-6) way. Similarly, if the test is done on blood, it takes other codes (15074-8 and 2339-0). As it is easy to understand, this mechanism generates a large number of entries and codes; only for glycemia, in the various systems in which it can be measured (blood, urine, etc.), there are 82 codes.
This phenomenon concerns all the measurements to a certain extent. For example, in the case of arterial pressure there is a code (55284-4) which allows the minimum and maximum to be expressed together (120/80), one for diastolic (8462-4) and one for systolic (8480- 6), as well as a code (35094-2) for a “panel” of items that includes diastolic, systolic, mean blood pressure, and six other (optional) codes that define measurement methodology, cuff size, name, and medical device code.
FHIR allows the use of different coding systems, not only LOINC, with which the semantic value of the data is expressed which, however, is also expressed in the structure of the resources which, being generic, is not said to be sufficient to express all the relevant concepts which may vary from facility to facility, from branch to branch, from one care setting to another.
For this reason, the FHIR data model may be sufficient to guarantee the exchange of data between systems but insufficient to express the variety and complexity of a clinical system (for example an electronic medical record). Setting up a Clinical Data Repository of a medical record on FHIR can therefore lead to limitations in terms of the ability to represent clinical concepts.
Even in the regional context, for example for the ESF 2.0, this choice can prove to be weak as it is not capable of managing the heterogeneity that exists between healthcare companies and between the various branches of medicine. It is not only a mapping problem that can be solved with a good terminology server but it is a much more complex issue concerning the concepts and the semantic structure that they express. Not even the choice of a single regional electronic medical record solves this problem, as I expressed in a previous article which you can read here.
Then there are technological considerations on how FHIR servers are built and structured. Many of them are based on non-relational databases where the JSON of the resources are recorded directly. As we have already seen these have many redundancies and with large volumes of data performance problems can arise. Finally, further reflections can be addressed to the research capabilities of FHIR.
One then wonders if there are alternatives to choosing (shortcut?) FHIR for data persistence. This is what we will find out in the next episode.
2 – Continue
I like:
Like Loading…