Le caratteristiche, le funzioni e i limiti del componente chiave della nuova infrastruttura del Fascicolo Sanitario Elettronico.
La nuova architettura prevede due nuovi elementi infrastrutturali: il Gateway, che ha il compito di verificare la coerenza nell’applicazione degli standard, sia per dati che per documenti, l’Ecosistema Dati Sanitari (EDS) che raccoglie, gestisce e rende fruibile il dato mediante servizi REST. L’EDS, mediante servizi di sottoscrizione e sincronizzazione può alimentare repository regionali con i dati di pertinenza delle regioni nelle modalità indicate dalla norma. L’EDS infine realizza le funzionalità di monitoraggio di alimentazione e di utilizzo del sistema FSE da parte del cittadino e degli operatori sanitari.
Le Linee guida di attuazione del Fascicolo Sanitario elettronico prevedono che nel FSE 2.0 confluiscano: dati in formato HL7 FHIR, direttamente acquisiti dai sistemi produttori delle strutture e archiviati nel Data Repository Centrale (e opzionalmente presso data repository locali) e documenti, in formato HL7 CDA2 iniettati in PDF firmati, prodotti a valle della validazione dai sistemi produttori e archiviati nei repository documentali delle strutture sanitarie stesse (dislocati a livello regionale o aziendale).
Si inizia dai CDA
Al momento le specifiche tecniche e la componente Gateway riguardano il secondo caso, ossia i documenti CDA2. Il gateway oggi prevede cinque servizi:
- Validazione del documento CDA2
- Pubblicazione del documento CDA2
- Eliminazione di un documento CDA2
- Sostituzione di un documento CDA2
- Aggiornamento metadati di un documento CDA2
La pubblicazione di un documento CDA2 deve essere sempre preceduta da una sua validazione. Viceversa non è obbligatorio pubblicare un CDA2 dopo che è stato validato (ad esempio per fare dei test). I due servizi di validazione e pubblicazione sono correlati da un identificativo di transazione referenziato nel documento come “workflowInstanceId” secondo standard IHE (Data Type CXi).
Per identificare invece i documenti da cancellare o aggiornare il chiamante dovrà fornire al gateway l’OID (Object Identifier) del documento da gestire (lo stesso che è stato fornito in creazione e propagato ad INI in XDSDocumentEntry.uniqueId e all’EDS tramite il MasterIdentifier della DocumentReference).
Validazione di un documento CDA2
Per validare un documento il Sistema Produttore deve inviare un file PDF con iniettato un Clinical Document in formato XML in linea con quanto riportato nelle «Implementation Guide CDA R2» che potete consultare qui.
Il servizio, sincrono, può essere richiamato per due finalità: verifica della correttezza sintattica e semantica del file; validazione del file per la successiva pubblicazione. La finalità è definita nel campo activity contenuto nel corpo del CDA. Il servizio esegue le validazioni ed i controlli sintattici e semantici e restituisce un esito tramite un codice: 200 o 201 in caso di successo (il primo per la verifica, il secondo per la validazione), un valore in una lista da 400 a 504 in caso di errori, time-out o servizio non disponibile.
In caso di validazione eseguita con successo, l’esito tornato è positivo e la validazione può ritenersi conclusa correttamente. L’hash del documento CDA2 verrà salvato in cache con chiave “workflowInstanceId”. Nella risposta verrà fornito l’identificativo “workflowInstanceId”.
Pubblicazione di un documento CDA2
Per pubblicare un documento il Sistema Produttore invia, direttamente o attraverso un Repository Documentale locale il file PDF firmato digitalmente in modalità PADES con iniettato un HL7 CDA2 corredato di alcuni metadati. Il documento CDA2 innestato nel documento dovrà corrispondere esattamente a quello precedentemente validato secondo il servizio di Validazione Documenti CDA2.
La verifica della corrispondenza verrà fatta calcolando l’hash del CDA2 estrapolato dal PDF con quello calcolato nel flusso di validazione (recuperato dalla cache tramite il “workflowInstanceId”).
Il servizio ha lo scopo di effettuare la conversione del dato in ingresso in formato FHIR per l’invio verso EDS, e preparare i metadati del documento per la comunicazione verso INI ai fini della indicizzazione.
Il servizio è sincrono e fornisce un acknowledgment di presa in carico.
Eliminazione di un documento pubblicato
Questo servizio asincrono consente di eliminare le risorse FHIR precedentemente pubblicate, inclusi i metadati scritti su INI. Il documento deve essere identificato tramite l’OID.
Sostituzione di un documento pubblicato
Questo servizio asincrono consente di pubblicare un documento sovrascrivendo il documento che era stato precedentemente pubblicato. Il documento deve essere identificato tramite l’OID.
Aggiornamento metadati di un documento pubblicato
Questo servizio asincrono consente di aggiornare i metadati di un documento precedentemente scritti su INI. Il documento deve essere identificato tramite l’OID.
Nel prossimo articolo vedremo in dettaglio come sono codificati i parametri per la pubblicazione di un documento.
1 – Continua
Massimo, grazie mille