The plan for adopting Italy’s Electronic Health Record (FSE 2.0), presented to the State-Regions Conference in the briefing of 2 March 2022, sets a precise technical objective: to move from a record made of signed documents to one made of queryable data. What changes is the interoperability model, not the regional portals.

Context

The first-generation FSE, started in Italy from 2012, was born with a document-centric architecture: clinical content takes the form of digitally signed HL7 CDA R2 documents, indexed and shared through the IHE XDS.b profile, and the National Interoperability Infrastructure (INI), run by Sogei, acts as the bridge between the regional records. Decree DPCM 178/2015 set its legal framework and minimum content.

The structural limit of this model is well known: the atomic unit is the document. A lab report in CDA R2 is read by a person and archived by a system, but the individual value — blood glucose, creatinine — is not an addressable datum outside the document that contains it. Reconstructing the trend of a single parameter across years of reports means, in practice, parsing heterogeneous documents produced by different clinical systems.

On top of this comes the General Data Protection Regulation (EU) 2016/679, which requires a legal basis for every processing of health data: secondary use — research, planning, pharmacovigilance — needs pseudonymised extracts that the document model makes laborious to produce.

The problem FSE 2.0 sets out to solve

By 2022 the FSE is established in every Region, but adoption is uneven: content varying from Region to Region, non-uniform feeding by providers, limited actual use by patients and professionals. The briefing of 2 March 2022 attributes part of this unevenness to the architecture itself and lays out the directions for the second generation:

  • aligning content to a common national minimum set;
  • retroactive data feeding from 2020 onward;
  • extending coverage to telemedicine data, outpatient specialist tests, prescriptions, exemptions, immunisations, and the patient’s personal log;
  • adopting HL7 FHIR as the exchange format, alongside CDA R2 for legacy documents;
  • a new architecture with a national FSE Gateway and a Health Data Ecosystem (EDS) in each Region.

Funding comes from the National Recovery and Resilience Plan (PNRR), Mission 6 Health, Component 2, Investment 1.3, which allocates 1.38 billion euro to strengthening the technical infrastructure and the tools for collecting and processing health data.

Target architecture

The plan’s model introduces two distinct layers.

Regional Health Data Ecosystem. Each Region consolidates its health data — clinical documents, flows from the National Health Information System (NSIS), telemonitoring data, immunisations — into a single platform. The EDS is the point where data converges and from which the regional record and the flows toward the national level start. Here structured data is extracted from documents and made addressable.

National FSE Gateway. Run by Sogei, it extends the role of INI: beyond inter-regional interoperability, it exposes national document catalogue and identification services and draws on the existing MEF/Sogei infrastructures (National Patient Registry, Electronic Prescription, Immunisation Registry, Health Card), consumed as services.

On formats, CDA R2 remains for documents already produced and for backward compatibility, while FHIR R4 is the format for the new data content: patient summary, reports, telemonitoring data, allergies, immunisations. The Italian FHIR Implementation Guides are being built by HL7 Italy and the bodies involved; as of 2022 they are being defined, not yet published as stable specifications.

The critical point

Between CDA R2 and FHIR the difference is not only syntactic — both use XML, FHIR adds JSON. It is a change of granularity. In CDA the model is the document; in FHIR the model is the resource: Patient, Observation, Condition, MedicationRequest, Immunization are autonomous entities, each with its own identity and referenceable through a RESTful API. A FHIR Observation is a single clinical fact that can be queried, indexed, and aggregated without re-parsing the source document.

The cost of that granularity falls on the regional EDS, which must produce the FHIR resources. There are three routes, with different trade-offs:

  • extracting FHIR from existing CDA documents: this inherits the quality and ambiguities of the source documents and depends on the coding the clinical systems actually used;
  • producing native FHIR at source: this requires updating the electronic health records of individual providers and reopening the procurement contracts with vendors;
  • dual track, with CDA and FHIR generated in parallel during the transition: this doubles the surface to maintain and verify.

In all three, the quality of the result depends on coding with controlled terminologies — LOINC for laboratory tests, SNOMED CT where adopted, drug dictionaries. A FHIR resource that is syntactically valid but carries unmapped local codes is interoperable only in appearance: it passes structural validation, but across Regions it is not comparable. The real constraint lies in the underlying semantics, which was already the weak point of the Italian CDA.

Implications

Secondary use becomes technically tractable. On a coded FHIR base, producing pseudonymised cohorts for observational studies or pharmacovigilance comes down to a query: no document-extraction project is needed any longer. The plan explicitly provides for enabling research and planning purposes on the regional EDS.

Then there is the European level. On 3 May 2022 the European Commission published the proposal for a Regulation on the European Health Data Space (EHDS), COM(2022) 197 final, which distinguishes primary use (care) from secondary use (research, statistics, policy) of health data and will call for compatible national infrastructures. A regional data layer coded in FHIR is the technical precondition for that compatibility, even if at this date the EHDS legislative process has only just begun.

Limits

The scale of the undertaking conditions the timeline. Twenty-one regional records with different architectures and vendors, hundreds of health authorities with heterogeneous clinical systems, tens of thousands of general practitioners and paediatricians with independent software, more than thirty information flows to realign: the technical challenge is inseparable from the contractual and organisational one, because each Region has to rewrite its procurement contracts and conventions.

The PNRR milestones — 85% of general practitioners feeding the FSE by June 2025, deployment across all Regions by 2026 — are a condition for the disbursement of NextGenerationEU funds, tied to measurable results rather than spending. Implementing acts remain to be published: the update of DPCM 178/2015, AgID’s FSE 2.0 technical guidelines, and the Italian FHIR Implementation Guides. Until the IGs are stable, some coding choices remain open, and with them the actual comparability of data across Regions — which is, in the end, the concrete measure of the move from archive to data store.

Cover image: Main entrance of the Agostino Gemelli University Hospital in Rome, a large Italian hospital — photo by Sergio D’Afflitto, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:2013-06-18_Roma_Policlinico_Gemelli.jpg