The Health Data Ecosystem will be the keystone of the Electronic Health Record. All issues still on the table.
The decree regulating the part “documentary” of the Electronic Health Record (FSE) 2.0, the Ministry of Health, the Department for Digital Transformation and the Regions are working on the definition of the Health Data Ecosystem (EDS). There are many aspects that need to be answered and which I will try to report in a series of articles, of which this is the first.
A first observation concerns the chosen method which I imagine was also determined by the PNRR timing. We have defined the data that make up the CDA files injected into the PDFs before defining which services we want to create with EDS. It would have been better to do the opposite and determine what data would be needed to develop dashboards or functions in the EDS. Wanting to use a legal lexicon, first define the “treatments” from which to derive the data. This approach would also have, in my opinion, facilitated the dialogue with the Guarantor which is ongoing and which I will return to later.
In architectural terms the discussion with the Regions is still ongoing but we can say that the EDS will most likely be “federated”, i.e. composed of various regional EDSs. The choice, in terms of interoperability, fell on FHIR which many regions are also thinking of using for data persistence by creating FHIR repositories, a rather risky and incorrect choice. Here you can find various articles in which I explain the reasons for this opinion.
However, remaining on interoperability, the choice of FHIR that I agree with raises the question of how to federate the different servers in which patient information (resources in the FHIR concept) will be available. At the document level we have ebXML technology and the presence of registries that solve the problem. What to use in the case of FHIR? HL7 suggests three possible paths:
In an environment where relevant information may be distributed across multiple servers, client systems will need a mechanism to determine where the data is located.
There are three main mechanisms for detection:
Manual configuration: Systems are manually configured to point to other (relevant) servers with indications of what types of data reside on which server, the address of the server, the necessary authentication information, either coded into the software or managed through the system configuration
Cross-cutting: Client systems should initiate queries from a single server that manages “primary” resources (e.g., encounters, diagnostic reports, episodes, etc. Other relevant information, such as diagnoses, observations, conditions, procedures, etc. are retrieved by browsing through the references contained in the primary resources
Registry: Client systems discover the “current” set of relevant servers by querying a central location for server endpoints that contain relevant data
The first hypothesis cannot be used, the second is complex given the high number of resources that can be associated with each patient, the third is more feasible but still not trivial to implement also due to the large numbers involved.
Returning to the privacy aspect, there is the problem of how to manage the right to blackout which today is expressed at the document level. It is possible to consider maintaining this setting since more FHIR resources will be extracted from each document, provided however that the document – FHIR resources link is maintained.
A central question then remains: what services will EDS have to offer? Limit yourself to data only or include processing or functions? In other words, will the “logic” be part of the EDS or dependent on the systems that invoke it? The answer is complex and I will try to explain it to you in the next article.
1 – Continue
I like:
I like Loading…