Italy’s Electronic Health Record — the Fascicolo Sanitario Elettronico (FSE) — is defined by DPCM 29 September 2015 no. 178 as a federated system of signed documents: each Region keeps its own repositories and a national infrastructure routes requests, without centralising clinical data. The regulation appeared in the Gazzetta Ufficiale, Serie Generale no. 263 of 11 November 2015, implementing article 12 of Decree-Law 18 October 2012 no. 179 (converted by Law 221/2012).

Context

Article 12 of DL 179/2012 had introduced the FSE into Italian law but left the operational rules to a regulation. DPCM 178/2015 is the first text to address content, consent, access and interoperability in substance. The underlying choice was already implicit in the architecture a few Regions had built and in the technical specifications AgID published in May 2015: the FSE is a document-based system, not a unified clinical database.

Everything else follows from this. A document-based system shares reports, discharge letters and summary profiles as complete, signed objects, not as queryable atomic fields. The technical consequence is a single one: the unit of exchange, of indexing and of access control is the document.

Architecture

The DPCM confirms the federated model. Under article 3 the FSE is established by each Region and Autonomous Province, which manages its contents and operation. At national level it creates the National Interoperability Infrastructure (Infrastruttura Nazionale per l’Interoperabilità, INI), entrusted to the Ministry of Economy and Finance and built through Sogei, which must guarantee interoperability between regional records when a patient is treated outside their Region of residence.

INI does not duplicate the regional records: it acts as their gateway. Documents stay in the regional repositories; INI handles localisation and routing between the Region of treatment and the Region of residence.

For the profiles, AgID’s technical specifications for interoperability between regional FSE systems (the 2015 reference version) adopt the IHE stack:

  • Document Registry — the regional registry of document metadata;
  • Document Repository — the physical store, usually at the care providers;
  • Document Consumer — the client that queries and retrieves;
  • the XDS.b profile for document sharing within a Region;
  • the XCA profile (Cross-Community Access) for communication between regional records through INI.

The minimum-core documents follow the Italian HL7 CDA R2 profiles defined with HL7 Italia. Transport is SOAP/WSDL conformant to the IHE profiles, under TLS.

Content and consent

Article 2 distinguishes a mandatory national minimum core (identifying and administrative data, reports, A&E records, discharge letters, the summary health profile, the pharmaceutical dossier, consent to or refusal of organ and tissue donation) from supplementary data left to the patient’s choice (prescriptions, bookings, the clinical record, certificates, a personal notebook).

On consent the regulation separates purposes (article 8). Care calls for a general, revocable consent to populating the record; the clinician accesses on a need basis, within the care relationship. Study and research require specific consent and work on pseudonymised or anonymised data. Planning and system governance access in anonymous or, where justified, pseudonymous form. The patient keeps the right to obscure individual documents — a document-level opt-out carried over from the Data Protection Authority’s guidelines of 16 July 2009.

Here too the grain of control is the document. Obscuring acts on a whole report, not on a field within it, because the report is the system’s atomic object.

The critical point

The limit of the document-based model is semantic before it is legal. Exchange holds as long as the use case is consultation: opening a discharge letter, reading a report, retrieving a summary profile. For these, a signed CDA R2 document, stored under archival rules, is more than enough.

Things get harder when you want to query the content. CDA R2 allows different levels of structure: from a narrative-body document (free text, written for a human reader) to coded, machine-readable entries. In practice most regional documents stop at the lower levels, with the clinical body in narrative form. The regulation and its annexes mandate the CDA structure, not the semantic coding of contents: terminologies such as SNOMED CT or LOINC remain used in a partial and uneven way across providers.

The consequence is measurable. A query like “all patients with a given lab value out of range” does not run against an XDS repository that indexes document metadata (type, author, date, patient), not their clinical content. The system knows that a lab report exists for a patient; it does not know, in a queryable and reliable way, what it contains. DPCM 178 delivers interoperability of transport and of index, and stops just short of meaning.

Implications

For anyone writing clinical software that talks to the FSE, this sets the boundary. Publishing to the FSE means producing CDA R2 conformant to the Italian profiles, signing it, registering its metadata in the regional Registry, exposing it via XDS.b. Consuming means querying the Registry for metadata, fetching the document from the Repository, and then — this is the point — parsing its content downstream, because the system does not return it already structured.

Decision support and secondary uses of the data (research, surveillance, evaluation) run into the same burden: they must derive the structure from documents written to be read, not queried. As long as the document layer stays narrative, analytics on the FSE is extraction work, not direct reading of fields.

Limits

DPCM 178 closes a regulatory phase that had been open for years and gives a coherent base to cross-regional consultation. Its constraints are those of the paradigm it chose.

  • Real adoption varies widely across Regions: some are ahead, others structurally behind.
  • Completeness depends on providers’ ability to produce conformant CDA R2: between declared and populated the gap is wide.
  • Semantic coding is, in practice, optional, and this holds back any use of the FSE beyond reading the document.

The signed-document model holds up well if the goal is integrity, non-repudiation and compliant retention. The use cases that need granular data will grow: whether they are covered by extending this design or by adding a resource-oriented layer alongside it remains open. Within HL7 that direction is already under discussion, through the work on FHIR.

Cover image: Diagram of the Austrian ELGA electronic health record architecture: several federated document registries at the top, document… — diagram by Sebastian19781, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:20120217_structure_of_the_Austrian_electronic_health_records_(ELGA).jpg