Sulle “Linee Guida per la Formazione, Gestione e Conservazione del Documento Informatico” di AgID (Allegato 2, pagina 140) si legge che il formato adottato per l’interscambio delle informazioni sanitarie è il “Clinical Document Architecture” (abbreviato CDA); il formato è utilizzato anche per il Fascicolo Sanitario Elettronico, cerchiamo di saperne di più.
Che cosa è la Health Level Seven International
La Health Level Seven International (HL7) è un ente no-profit fondato nel 1987 e accreditato ANSI. Lo scopo principale dell’HL7 è proprio quello di creare standard e infrastrutture deputate allo scambio di dati clinici, alla loro integrazione e corretta condivisione. L’HL7 è autrice di diversi standard e soluzioni in ambito sanitario tra cui:
- Clinical Document Architecture (CDA): definisce specifiche, struttura e semantica di “documenti clinici” e lo fa nel rispetto di sei caratteristiche principali: persistenza, gestione, potenziale di autenticazione, contesto, interezza e leggibilità umana [LINK].
- V2: deputato all’interscambio di messaggi in ambito sanitario allo scopo di supportare i pazienti [LINK].
- Fast Healthcare Interoperability Resources (FHIR): è uno standard di interoperabilità che ha lo scopo di facilitare lo scambio di informazioni tra gli organismi sanitari (pazienti, strutture ospedaliere, ambulatori, professionisti). Il FHIR è composto da due parti: la prima si basa su un set di risorse che costituiscono il modello di riferimento e la seconda parte che riguarda le specifiche per l’interscambio delle risorse [LINK].
La HL7 in Italia è rappresentata da un Direttore affiliato, il Dott. Giorgio Cangioli che terminerà il suo mandato a Dicembre 2023. Un quadro complessivo del personale operante nel direttivo è consultabile a questo link. Il Dott. Cangioli, per HL7 Italia svolge il ruolo di Responsabile Tecnico, con delega alle attività di normazione e certificazione come riportato all’interno del portale italiano ufficiale.
C’è un’iniziativa interessante che riporta la data di febbraio 2023 da parte di HL7 il cui testo si riporta integralmente.
HL7 Italia, di comune intesa con il Dipartimento per la Trasformazione Digitale della Presidenza del Consiglio dei Ministri, intende attivare gruppi di lavoro con lo scopo di formalizzare un insieme di Implementation Guide (IG) aderenti allo standard HL7 FHIR per i documenti sanitari e socio-sanitari previsti nelle linee guida per il potenziamento del Fascicolo Sanitario Elettronico (FSE 2.0).
Fonte: HL7 Italia [LINK]
L’avviso è stato pubblicato dall’Ing. Leonardo Alcaro, membro del Comitato Tecnico Strategico e oprante presso il Dipartimento per la Trasformazione Digitale.
Perchè AgID ha scelto il CDA
Le motivazioni per le quali AgID ha deciso di adottare il CDA sono descritte dalla stessa Agenzia:
Un documento CDA è in grado di contenere qualunque tipo di informazione clinica; supporta inoltre testo non strutturato e può incorporare documenti nei formati PDF, DocumentML e RichText Format come immagini di tipo JPEG e PNG.
AgID ha scelto di inserire questo formato (da notare la tipologia di standard) tra i documenti amministrativi all’interno delle “Linee Guida per la Formazione, Gestione e Conservazione del Documento Informatico”, Allegato 02, pagina 140.
Clinical Data Architecture: caratteristiche
Il CDA fu sviluppato inizialmente proprio dall’ANSI e successivamente portato avanti dalla HL7, al momento il grado di maturità dello standard è tale da aver subito negli anni molte revisioni e integrazioni.
| Versione | Data di pubblicazione Mese/Anno |
|---|---|
| 2.1 | 01/2021 |
| 2.1 | 11/2019 |
| 2 | – |
| 2 | 01/2006 |
| 2.0 | 04/2005 |
| 1.1 | 11/2000 |
L’attuale versione pubblicata sul portale HL7 del CDA è la versione 2.1 denominata “HL7_CDA_R2_1 2021Jan_errata)” ed è denominata in tal modo perchè, come si legge dalla comunicazione interna, sono state apportate alcune correzioni. Il CDA è disponibile anche su GitHub al seguente indirizzo, nel quale è possibile trovare tutte le risorse utili.
C’è però da precisare un altro aspetto di rilievo: il formato CDA è stato scelto dallo standard ISO/HL7 27932 del 2005. Ecco quindi le motivazioni che hanno spinto l’Agenzia ad adottarlo per il Fascicolo Sanitario Elettronico. I riferimenti a cui fa riferimento lo standard sono:
- ISO/HL7 27932:2005, HL7 Clinical Document Architecture
- www.fascicolosanitario.gov.it/Standarddocumentali
- Foglio di stile per la consultazione
interoperabile - Circolare AgID 4/2017
Di seguito si riporta un esempio molto esemplificato dello schema XML dello standard:
<ClinicalDocument>
... CDA Header ...
<structuredBody>
<section>
<text>...</text>
<observation>...</observation>
<substanceAdministration>
<supply>...</supply>
</substanceAdministration>
<observation>
<externalObservation>...
</externalObservation>
</observation>
</section>
<section>
<section>...</section>
</section>
</structuredBody>
</ClinicalDocument>
Il formato viene fornito all’interno di un pacchetto ZIP di circa 110Mb con all’interno tutta la documentazione, inclusi i canonici schemi che agevolano l’implementazione dello standard.
L’intero standard è contenuto e spiegato all’interno di un file HTML che racchiude anche le immagini di cui sopra oltre che istruzioni precise e molto ben realizzate.
Il rapporto con i file
Lo standard prevede che vi sia apertura verso numerose tipologie di file che, a seconda dell’utilizzo applicativo, potranno essere implementati oppure no. Una tabella esaustiva è contenuta nel file denominato datatypes.html. Di seguito si riportano esclusivamente i formati definiti come “raccomandati” e come “necessari” status.
| Codice | Nome | Stato |
|---|---|---|
| text/plain | Plain text | Necessario |
| text/x-hl7-ft | HL7 Text | Raccomandato |
| text/html | HTML | Raccomandato |
| application/pdf | Raccomandato | |
| audio/basic | Basic Audio | Necessario |
| audio/mpeg | MPEG audio layer 3 | Necessario |
| image/png | PNG Image | Necessario |
| image/jpeg | JPEG Image | Necessario |
| application/dicom | DICOM | Raccomandato |
| image/g3fax | G3Fax Image | Raccomandato |
| video/mpeg | MPEG Video | Necessario |
| model/vrml | VRML Model | Raccomandato |
È importante far notare che anche lo standard CDA riporta anche i formati documentali deprecati tra cui rientra anche il formato msword (.doc). C’è da considerare che le “Linee Guida AgID per la Formazione, Gestione e Conservazione del Documento Informatico” non raccomanda l’utilizzo di questo formato (le specifiche del formato .doc sono ferme al 2018).
| Codice | Nome | Stato |
|---|---|---|
| application/msword | MSWORD | Deprecato |
| video/avi | AVI | Deprecato |
Il rapporto tra CDA e DICOM
DICOM (Digital Imaging and COmmunications in Medicine) è lo standard adottato per le immagini diagnostiche che normalmente vengono acquisite e gestite con macchinari come, ad esempio, un ecografo. Lo standard può essere studiato sul sito ufficiale (https://www.dicomstandard.org/) ed è perfettamente integrato all’interno del CDA che, non a caso, lo introduce tra i formati raccomandati. L’interazione tra il CDA e il DICOM, dal punto di vista del DICOM, viene studiato e affrontato a questa pagina “DICOM PS3.20 2023a – Imaging Reports using HL7 Clinical Document Architecture“. Si tenga in considerazione che, al momento della scrittura del presente articolo, la versione ultima del formato DICOM è la 3.20 ma, in futuro, potrebbero esserci ulteriori cambiamenti.
Confidenzialità nel trattamento delle informazioni
Un elemento essenziale dello standard CDA è l’impiego di livelli di confidenzialità che permettono di condividere in modo appropriato le informazioni. Questa è una delle principali carenze nei contesti in cui vengono applicate soluzioni basate sulla gestione diretta di file, per approfondimenti si faccia riferimento a quanto riportato di seguito.
La confidenzialità dentro lo standard CDA si basa, al momento, sui seguenti valori di cui per completezza si inseriscono le caratteristiche così come riportate all’interno della documentazione ufficiale.
| Sigla | Valore | Descrizione |
|---|---|---|
| L | Low | Definition: Privacy metadata indicating that the information has been de-identified, and there are mitigating circumstances that prevent re-identification, which minimize risk of harm from unauthorized disclosure. The information requires protection to maintain low sensitivity. Examples: Includes anonymized, pseudonymized, or non-personally identifiable information such as HIPAA limited data sets. Map: No clear map to ISO 13606-4 Sensitivity Level Care Management: RECORD_COMPONENTs that might need to be accessed by a wide range of administrative staff to manage the subject of care’s access to health services. Usage Note: This metadata indicates the receiver may have an obligation to comply with a data use agreement. |
| M | Moderate | Definition: Privacy metadata indicating moderately sensitive information, which presents moderate risk of harm if disclosed without authorization. Examples: Includes allergies of non-sensitive nature used inform food service; health information a patient authorizes to be used for marketing, released to a bank for a health credit card or savings account; or information in personal health record systems that are not governed under health privacy laws. Map: Partial Map to ISO 13606-4 Sensitivity Level Clinical Management: Less sensitive RECORD_COMPONENTs that might need to be accessed by a wider range of personnel not all of whom are actively caring for the patient (e.g. radiology staff). Usage Note: This metadata indicates that the receiver may be obligated to comply with the receiver’s terms of use or privacy policies. |
| N | Normal | Definition: Privacy metadata indicating that the information is typical, non-stigmatizing health information, which presents typical risk of harm if disclosed without authorization. Examples: In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI) given a covered purpose of use (treatment, payment, or operations). Includes typical, non-stigmatizing health information disclosed in an application for health, workers compensation, disability, or life insurance. Map: Partial Map to ISO 13606-4 Sensitivity Level Clinical Care: Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations. Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable jurisdictional privacy law or disclosure authorization. |
| R | Restricted | Definition: Privacy metadata indicating highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization. May be pre-empted by jurisdictional law, e.g., for public health reporting or emergency treatment. Examples: Includes information that is additionally protected such as sensitive conditions mental health, HIV, substance abuse, domestic violence, child abuse, genetic disease, and reproductive health; or sensitive demographic information such as a patient’s standing as an employee or a celebrity. May be used to indicate proprietary or classified information that is not related to an individual, e.g., secret ingredients in a therapeutic substance; or the name of a manufacturer. Map: Partial Map to ISO 13606-4 Sensitivity Level Clinical Care: Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations. Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable, prevailing (default) jurisdictional privacy law or disclosure authorization.. |
| U | Unrestricted | Definition: Privacy metadata indicating that the information is not classified as sensitive. Examples: Includes publicly available information, e.g., business name, phone, email or physical address. Usage Note: This metadata indicates that the receiver has no obligation to consider additional policies when making access control decisions. Note that in some jurisdictions, personally identifiable information must be protected as confidential, so it would not be appropriate to assign a confidentiality code of “unrestricted” to that information even if it is publicly available. |
| V | Very restricted | Definition: Privacy metadata indicating that the information is extremely sensitive and likely stigmatizing health information that presents a very high risk if disclosed without authorization. This information must be kept in the highest confidence. Examples: Includes information about a victim of abuse, patient requested information sensitivity, and taboo subjects relating to health status that must be discussed with the patient by an attending provider before sharing with the patient. May also include information held under legal lock or attorney-client privilege Map: This metadata indicates that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject. Usage Note: This metadata indicates that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject. |
Si prega di tenere presente come il livello di sicurezza V (Very Restricted) abbia come esempio i dati ottenuti da vittime di abusi. Nei casi italiani di data breach, come ampiamente documentato nel succitato articolo, alcune informazioni afferenti alle violenze sessuali sono state mantenute “in chiaro” e senza alcuna valida ed efficace forma di restrizione da parte di alcuni enti sanitari. Ciò le ha rese oggetto di data breach, esfiltrazione e divulgazione.
Un vocabolario da esplorare
L’intero standard ruota intorno ad un vocabolario che, per ciascun termine, spiega la tipologia di valori e l’uso che se ne deve fare. Un esempio è stato quello sulla confidenzialità mentre un altro, certamente uno più semplice, è quello del marital status.
| Codice | Valore | Descrizione |
|---|---|---|
| A | Annulled | Marriage contract has been declared null and to not have existed |
| D | Divorced | Marriage contract has been declared dissolved and inactive |
| I | Interlocutory | Subject to an Interlocutory Decree |
| L | Legally Separated | – |
| M | Married | A current marriage contract is active |
| P | Polygamous | More than 1 current spouse |
| S | Never Married | No marriage contract has ever been entered |
| T | Domestic partner | Person declares that a domestic partner relationship exists. |
| U | Unmarried | Currently not in a marriage contract. |
| W | Widowed | The spouse has died |
La tabella mostra chiaramente la completezza dello stato attribuibile alla persona esaminata, favorendo così eventuali riflessioni in merito, ad esempio, alla diffusione di una patologia ma anche solo all’esercizio di diritti da parte degli interessati. Il vocabolario è quindi un ottimo punto di partenza per studiare le potenzialità dello standard. Chiaramente alcune di queste informazioni potrebbero avere attinenza con il credo religioso e di fatto il vocabolario include una tabella denominata “ReligiousAffiliation” che presenta numerosi valori selezionabili, così come è molto completa la tabella Race che include le razze classificate e identificabili da un codice univoco.
Ad esempio, gli Italiani hanno un codice 2114-7 e fanno parte della categoria 2108-9 “RaceWhiteEuropean” che, a sua volta, fa parte della categoria 2106-3 “RaceWhite”. In gerarchia si potrebbe visualizzare come segue:
Razza
|
+−2106-3 [RaceWhite]
|
+−2108-9 [RaceWhiteEuropean]
|
+−2114-7 [Italian]
La complessità di tassonomie analoghe è assolutamente apprezzabile e denota la maturità del CDA; ovviamente queste informazioni andranno ad arricchire il profilo del paziente, come mostrato dal diagramma ufficiale.
Conclusioni
La scelta del formato CDA è stata adottata anche per collezionare e gestire le informazioni del Fascicolo Sanitario Elettronico FSE e si presta efficacemente alla gestione delle informazioni che riguardano il trattamento del paziente. Si raccomanda di leggere la documentazione ufficiale per apprezzare la completezza tecnica dello standard.
La documentazione ufficiale può essere recuperata a questo indirizzo.
