The obstacles and aspects to be faced in order to put the new Electronic Health Record into operation and make it really useful.
I continue, in this post, the analysis of the prospects and developments necessary for the ESF 2.0. Anyone who missed the first episode can read it here. Author’s note: there are images and considerations that I didn’t present at the Assinter Academy event due to lack of time.
To carry out my analysis I will use my own logical representation of how the new ESF should be designed and implemented and which is therefore not present in any official documentation.
The clinical model
Logica would like a top-down approach to be followed when designing an infrastructure such as the FSE, starting with what is indicated in the image as a clinical model, i.e. the analysis of the scenarios and use cases in which the dossier should be used. A simple list of purposes of care, programming, research is not enough, but it is necessary to go into detail about each of them by identifying the needs and functions that one wants to introduce to support the activity of healthcare personnel (analysis of requirements). For example, if we want to use the FSE to support doctors’ decisions, it is necessary to identify the necessary functions and design the user interface in order to make useful information available, as I illustrated in the previous article.
The organizational model
Once the previous phase has been concluded, it is necessary to define the organizational model, i.e. the roles, responsibilities and methods of using the ESF. This work must be carried out on the basis of existing and future organizational models (see DM 77), the care settings involved and the rules / constraints deriving from the GDPR. The transition from the use of documents to data requires, in my opinion, a particular reflection with health professionals because it changes the habits and certainties that the digital transposition of paper documents has so far ensured (authenticity, reliability, recognition of the author, etc. …). How to ensure the same things in the case of the vision of a punctual datum?
The functional model
The possibility of developing services and functions starting from the Health Data Ecosystem represents the most important and useful novelty of the new FSE, according to the designers the key to overcoming the limits of the current one which as it is, i.e. a mere collection of documents, it is of little use to doctors and citizens.
This thesis is absolutely acceptable. Does it make sense then to design an infrastructure regardless of the services and functions that you want to create and that have not even been defined at the moment? Logic would say no because it’s like to design and realize a car without having thought about the roads. What will I do with the new ESF? If there are no services and functions immediately, I will only be able to use it to access the data and documents as they are, with the risk of repeating the experience of the current file (see previous article).
The semantic model
To obtain real interoperability it is not enough to define a data model but it is necessary, on the basis of the higher levels (clinical, organizational and functional model) to work on a semantic model, i.e. to describe in detail the meaning of the individual information.
It is not enough to choose FHIR to solve this problem and not even to say LOINC or SNOMED generically which, moreover, Italy has never adopted. For example, I express an Individual Care Plan in a resource CarePlan by FHIR? If the meaning of each attribute is not precisely and punctually defined, it is almost certain that it will not be possible to share PAIs between different healthcare companies. This is what was done in the past with the HL7 CDA documents and which now needs to be repeated in the case of FHIR, an operation that requires time and knowledge of health domains.
The idea of extracting structured content from current CDA documents to feed a FHIR repository is also quite fanciful. The documents are not very structured and very descriptive (free text).
The data model
One of the reasons that led to the choice of creating a central repository rather than thinking of a federated architecture that would be more consistent with the institutional model and with the role that the regions have is the idea that in this way a single data model is pursued and that services to healthcare workers and citizens are homogenized.
However, both considerations are wrong. Having a single data model does not ensure that you do not have multiple semantic models for the reasons explained above. In any case, even in a federated architecture it is possible to obtain this result, the choice is only a purely technical aspect.
As for the services, these will depend on the data present, the quantity and variety of which may vary due to many factors as has already happened for the current file, the diffusion and completeness of which is very uneven among the regions.
What should be done
The answer to this question is contained in the figure at the head of the article. Instead of proceeding in bottom-up mode (from the data model upwards) it would be necessary to do the opposite (top-down) or better, since the works have already started, do as is done in the construction of tunnels: start from the two ends and then meet in the center (hoping not to miss the intersection).
In other words, it is necessary to take all the necessary logical steps involving all the stakeholders, patients included. Naturally, a direction is needed, a coordination that operates with a holistic vision of the problem and is not only focused on the technological aspects. We need the involvement of the regions and healthcare companies, the people who work there, their patients.
In a previous article, which you can find here, I provocatively stated that I don’t let IT lead the digital transformation, causing many angry reactions from the latter. I didn’t want to denigrate the category, to which I belong, but to raise the problem of the limits that exist when design is limited to technicians only or guided by them. What is happening with the FSE 2.0 is further confirmation of this.
The new ESF could really be a valuable tool for improving the quality and efficiency of care, let’s not waste another opportunity!