Il processo di trasferimento indice del FSE da un sistema (RPDA o INI) ad un altro (RDA o INI) si basa sulla individuazione di tutti gli oggetti documentali (metadati, politiche ) presenti nel registro della RPDA (ovvero dell’INI nel caso in cui il FSE dell’assistito era gestito temporaneamente dall’INI) e la loro nuova indicizzazione nel registro della RDA (ovvero dell’INI nel caso in cui il FSE dell’assistito è gestito temporaneamente dall’INI). Questo processo non prevede il trasferimento degli oggetti SubmissionSet.
Nel primo caso, in cui è l’INI a richiedere il trasferimento dell’indice verso la RPDA, l’INI svolge il ruolo di XDS Document Consumer ed avvia una transazione [ITI-18] Registry Stored Query del tipo FindDocuments con returnType uguale a ObjectRef (ovvero per ottenere l’elenco degli identificativi dei metadati che si riferiscono ai documenti che corrispondono ai parametri di ricerca della stored query) con l’obiettivo di ottenere l’elenco di tutti i metadati dei documenti presenti nell’indice del paziente da trasferire. Il messaggio di richiesta è caratterizzato da una asserzione di attributo che attesta alla RPDA che il motivo della query è legata al trasferimento dell’indice del FSE (purposeOfUse uguale a SYSADMIN) e che il ruolo del soggetto che sta effettuando la richiesta di trasferimento è l’INI (role uguale a INI); inoltre, nel caso in cui al paziente siano associati più codici fiscali, il messaggio è caratterizzato da una asserzione di identificazione. L’attore XDS Document Consumer, valutando la lista dei metadati restituiti come risultato alla query, può eventualmente procedere alla richiesta per ogni DocumentEntry di tutti i metadati associati a uno o più documenti procedendo con una serie di query di tipo GetDocuments con returnType uguale a LeafClass (in questo tipo di query sono specificati valori degli uuid dei documenti per i quali si vogliono recuperare i metadati). Ogni set di metadati, relativi ad uno o più documenti, presenti nella risposta della transazione [ITI-18] Registry Stored Query di tipo GetDocuments viene indicizzato dall’INI che svolge il ruolo di XDS Document Registry. Lo stesso processo viene ripetuto per tutti i codici fiiscali presenti nella asserzione di identificazione associati al paziente. Si precisa che, in fase di trasferimento, l’INI deve verificare che gli identificativi utilizzati dal registry della RPDA per identificare i metadati che si trasferiscono non coincidano con identificativi presenti nel registry di destinazione (per esempio associati ad altri oggetti relativi a diversi assistiti); prima di completare il trasferimento occorre pertanto che il processo di importazione effettui questa verifica ed eventualmente sostituisca gli identificativi duplicati (è comunque possibile aggiornare sempre tutti gli identificativi in fase di importazione, a prescindere dall’eventuale esistenza di duplicati).
Nel secondo caso, in cui è la RDA a richiedere il trasferimento dell’indice verso la RPDA, la RDA svolge il ruolo di XDS Document Consumer, che esegue una transazione [ITI-18] Registry Stored Query del tipo FindDocuments con returnType uguale a ObjectRef (ovvero per ottenere l’elenco degli identificativi dei metadati che si riferiscono ai documenti che corrispondono ai parametri di ricerca della stored query), con l’obiettivo di ottenere l’elenco di tutti i metadati dei documenti presenti nell’indice del paziente da trasferire. La richiesta è inviata dal XDS Document Consumer verso l’attore National Gateway che provvede ad inoltrare adeguatamente la richiesta, ovvero a soddisfare la richiesta direttamente nel caso in cui la gestione sia affidata all’indice temporaneo. Il messaggio di richiesta è caratterizzato da una asserzione di attributo che attesta alla RPDA che il motivo della query è legata al trasferimento dell’indice del FSE (purposeOfUse uguale a SYSADMIN) e che il ruolo del soggetto che sta effettuando la richiesta di trasferimento è un Nodo Regionale (role uguale a NOR). Nel caso la richiesta venga inoltrata dall’INI verso la RPDA e al paziente siano associati più codici fiscali, al messaggio di richiesta è aggiunta l’asserzione di identificazione del paziente. L’attore XDS Document Consumer, valutando la lista dei metadati restituiti come risultato alla query, può eventualmente procedere alla richiesta per ogni DocumentEntry di tutti i metadati associati a uno o più documenti procedendo con una serie di query di tipo GetDocuments con returnType uguale a LeafClass (in questo tipo di query sono specificati valori degli uuid dei documenti per i quali si vogliono recuperare i metadati). Ogni set di metadati, relativi ad uno o più documenti, presenti nella risposta della transazione [ITI-18] Registry Stored Query di tipo GetDocuments viene indicizzato dalla RDA che svolge il ruolo di XDS Document Registry. Lo stesso processo viene ripetuto per tutti i codici fiscali presenti nella asserzione di identificazione associati al paziente. Si precisa che, in fase di trasferimento, la RDA deve verificare che gli identificativi utilizzati dal registry della RPDA (ovvero INI) per identificare i metadati che si trasferiscono non coincidano con identificativi presenti nel registry di destinazione (per esempio associati ad altri oggetti relativi a diversi assistiti); prima di completare il trasferimento occorre pertanto che il processo di importazione effettui questa verifica ed eventualmente sostituisca gli identificativi duplicati (è comunque possibile aggiornare sempre tutti gli identificativi in fase di importazione, a prescindere dall’eventuale esistenza di duplicati).
Di seguito si riporta il dataset della richiesta e della risposta del messaggio di richiesta trasferimento indice.
Messaggio di richiesta Trasferimento indice (flussi RDA->INI, INI->RPDA)
|
Campo |
Tipologia |
Codifica |
Descrizione |
Obbligatorietà |
Dato SAML/XDS (ove applicabile) |
|---|---|---|---|---|---|
|
Identificativo utente |
asserzione attributo |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Codice Fiscale dell’utente che fa richiesta del servizio di interoperabilità |
no |
urn:oasis:names:tc:xacml:1.0:subject:subject-id |
|
Identificativo organizzazione |
asserzione attributo |
Codifica secondo la Tabella 5.4-3 del documento di Affinity Domain |
Identificativo del dominio dell’utente che ha in carico l’assistito |
si |
urn:oasis:names:tc:xspa:1.0:subject:organization-id |
|
Descrizione organizzazione |
asserzione attributo |
Codifica nazionale delle regioni/province autonome italiane |
Descrizione del dominio dell’utente che ha in carico l’assistito |
no |
urn:oasis:names:tc:xspa:1.0:subject:organization |
|
Struttura utente |
asserzione attributo |
Codifica HSP.11 - HSP.11bis - STS.11 - RIA.11, ovvero codifica ISTAT della Azienda (ASL) o codifica Tabella 5.4-3 del documento di Affinity Domain |
Identificativo della struttura dell’operatore/professionista sanitario |
si |
urn:oasis:names:tc:xspa:1.0:environment:locality |
|
Ruolo utente |
asserzione attributo |
Vedi Tabella 5.4-1 del documento di Affinity Domain per la codifica ruoli |
Il ruolo utente deve essere NOR oppure INI |
si |
urn:oasis:names:tc:xacml:2.0:subject:role |
|
Contesto operativo richiesta |
asserzione attributo |
Vedi tabella 5.4-2 del documento di Affinity Domain |
Contesto operativo della richiesta, il valore deve essere SYSADMIN |
si |
urn:oasis:names:tc:xspa:1.0:subject:purposeofuse |
|
Tipo documento |
asserzione attributo |
Codifica LOINC |
Elenco dei tipi di documento da trasferire |
no |
urn:oasis:names:tc:xspa:1.0:resource:hl7:type |
|
Identificativo assistito |
asserzione attributo |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Codice Fiscale |
si |
urn:oasis:names:tc:xacml:1.0:resource:resource-id |
|
Tipo Attività |
asserzione attributo |
Valore: READ |
Descrive il tipo di attività: CREATE, READ, UPDATE, DELETE |
si |
urn:oasis:names:tc:xacml:1.0:action:action-id |
|
Identificativo assistito |
asserzione di identificazione |
|
Lista dei codici fiscali associati all’assistito, di cui uno è quello valido |
si (solo per il flusso INIàRDA e per assistiti con più codici fiscali) |
|
|
Identificativo assistito |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Codice Fiscale dell’assistito. Questo elemento deve essere indicato nel caso di stored query FindDocuments. |
si |
$XDSDocumentEntryPatientId |
|
Stato documento |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Questo elemento deve essere indicato nel caso di stored query FindDocuments. |
si (solo in caso di stored query FindDocumetns) |
$XDSDocumentEntryStatus |
|
Identificativi documenti |
Specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Identificativi degli oggetti nel registry da trasferire. Questo elemento deve essere indicato nel caso di stored query GetDocuments. |
si (solo in caso di stored query GetDocumetns) |
$XDSDocumentEntryUniqueId oppure $XDSDocumentEntryEntryUUID |
Messaggio di risposta Trasferimento indice con successo (flussi RPDA->INI, INI->RDA)
Ad esclusione dello stato della risposta, tutti gli altri elementi devono essere indicati per ogni oggetto soddisfacente i criteri di ricerca.
|
Campo |
Tipologia |
Codifica |
Descrizione |
Obbligatorietà |
Dato XDS (ove applicabile) |
|---|---|---|---|---|---|
|
Stato risposta |
specifico per messaggio |
Come da specifiche IHE |
Successo/Fallimento |
si |
AdhocQueryResponse.status |
|
Tipologia di struttura che ha prodotto il documento |
specifico per messaggio |
Da Affinity Domain, Tabella 2.8-1 |
(codifica della specialità o del tipo di struttura) |
si |
XDSDocumentEntry. healthcareFacilityTypeCode (ITI TF:3 4.2.3.2.11) |
|
Identificativo assistito |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Codice Fiscale dell’assistito |
si |
XDSDocumentEntry.patientId (ITI TF:3 4.2.3.2.16) |
|
Tipo MIME |
specifico per messaggio |
Da Affinity Domain, Tabella 2.10-1 |
Indica il mime type del documento |
si |
XDSDocumentEntry.mimeType (ITI TF:3 4.2.3.2.15) |
|
Identificativo organizzazione |
specifico per messaggio |
Codifica OID nazionale delle regioni/province autonome italiane, come specificato al paragrafo 2.9 del documento di Affinity Domanin |
Identificativo della regione di Assistenza |
no |
XDSDocumentEntry.homeCommunityId (ITI TF:3 4.2.3.2.12) |
|
Identificativo repository |
specifico per messaggio |
Codifica OID, come specificato al paragrafo 2.14 del documento Affinity Domain |
Identificativo del Repository che custodisce il documento |
si |
XDSDocumentEntry.repositoryUniqueId (ITI TF:3 4.2.3.2.18) |
|
Identificativo documento |
specifico per messaggio |
Codifica OID, come specificato al paragrafo 2.19 del documento Affinity Domain |
identificativo del documento |
si |
XDSDocumentEntry.uniqueId (ITI TF:3 4.2.3.2.26) |
|
Tipo documento (alto livello) |
specifico per messaggio |
Da Affinity Domain, come specificato al paragrafo 2.3 |
Descrive la tipologia di documento ad alto livello (Prescrizione, Report, Immagine, …) |
si |
XDSDocumentEntry.classCode (ITI TF:3 4.2.3.2.3) |
|
Tipologia documento (medio livello) |
specifico per messaggio |
Codifica LOINC (i possibili valori sono indicati in Tabella 2.18-1 del documento di Affinity Domain) |
Descrive la tipologia di documento in modo più dettagliato (prescrizione specialistica, prescrizione farmaceutica, …) |
si |
XDSDocumentEntry.typeCode (ITI TF:3 4.2.3.2.25) |
|
Tipologia documento (basso livello) |
specifico per messaggio |
Da Affinity Domain, come specificato in Tabella 2.6-1 |
Unito al typeCode permette di individuare la struttura di un documento (es. template per i documenti in formato CDA R2) |
si |
XDSDocumentEntry.formatCode (ITI TF:3 4.2.3.2.9)
|
|
Identificativo univoco dell’oggetto documento all’interno del Registry |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Necessario per creare relazioni tra i documenti |
si |
XDSDocumentEntry.entryUUID (ITI TF:3 4.2.3.2.7) |
|
Data validazione documento |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Data del documento |
si |
XDSDocumentEntry.creationTime (ITI TF:3 4.2.3.2.6) |
|
Autore del documento |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Codice fiscale, struttura sanitaria, ruolo, specialità e riferimenti dell’autore del documento |
si |
XDSDocumentEntry.author (ITI TF:3 4.2.3.2.1) |
|
Hash |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Parametro caratterizzante il documento |
si |
XDSDocumentEntry.hash (ITI TF:3 4.2.3.2.10) |
|
size |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Parametro caratterizzante il documento |
si |
XDSDocumentEntry.size (ITI TF:3 4.2.3.2.21) |
|
Assetto organizzativo che ha portato alla creazione del documento |
specifico per messaggio |
Da Affinity Domain, come specificato in Tabella 2.12-1 |
Es. Medicina Generale, Pediatria, ecc. |
si |
XDSDocumentEntry. practiceSettingCode (ITI TF:3 4.2.3.2.17) |
|
Identificativo del paziente al momento della creazione del documento |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Questo valore non cambia a seguito dell’unione di più identificativi |
si |
XDSDocumentEntry.sourcePatientId (ITI TF 3: 4.2.3.2.23) |
|
Riferimento al documento di prescrizione |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Nel caso i metadati fanno riferimento ad un documento di referto prodotto a partire da un documento di prescrizione, questo metadato identifica il documento di prescrizione dematerializzata dal quale è generato il referto |
No (obbligatorio se presente nel registry) |
XDSDocumentEntry.referenceIdList (ITI TF:3 4.2.3.2.28) |
|
Conservazione sostitutiva |
specifico per messaggio |
Da Affinity Domain, come specificato al paragrafo 2.21 |
Indica se il documento è memorizzato negli archivi di conservazione sostitutiva |
si (solo nel caso in cui il documento è in conservazione) |
urn:ita:2017:repository-type |
|
Lingua del documento |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Indica la lingua del documento |
no |
XDSDocumentEntry.languageCode (ITI TF 3: 4.2.3.2.14) |
|
Data della prestazione |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Indica le date di inizio e fine della prestazione sanitaria che ha comportato la produzione del documento |
no |
XDSDocumentEntry. serviceStartTime (ITI TF 3: 4.2.3.2.19) XDSDocumentEntry. serviceStopTime (ITI TF 3: 4.2.3.2.20) |
|
Livello di confidenzialità |
specifico per messaggio |
Da Affinity Domain, tabella 2.5-1 |
Indica il livello di confidenzialità del documento (ad es. se contiene informazioni a maggior tutela di anonimato). I documenti a maggior tutela di anonimato devono essere resituiti solo se il paziente ha deciso preventivamente di renderli visibili. |
si |
XDSDocumentEntry.confidentialityCode (ITI TF:3 4.2.3.2.5) |
|
Regole di accesso |
specifico per messaggio |
Da Affinity Domain, come specificato al paragrafo 2.7. |
Indica la lista di codici che identificano le politiche di accesso associate al documento. Permette quindi di specificare ad esempio l’oscuramento del documento. Si nota che per i documenti contenenti informazioni a maggior tutela dell’anonimato, salvo diversa indicazione del paziente, il documento deve essere oscuramento. |
No (obbligatorio se presente nel registry) |
XDSDocumentEntry.eventCodeList (ITI TF:3 4.2.3.2.8) |
|
Versione dell’oggetto documento gestito dal Registry |
specifico per messaggio |
Formato codifica conforme alla specifiche IHE (ITI TF-3) |
Necessario per aggiornare i metadati associati ad un documento Esempio:
<VersionInfo versionName=”1” /> |
si |
|
Messaggio di risposta Trasferimento indice con fallimento (flussi RPDA->INI, INI->RDA)
Il messaggio di risposta, in caso di errore, può essere:
- generato dall’INI, per il flusso di comunicazione tra l’INI e la RDA (per segnalare che la regione chiamante non è RDA dell’assistito o altri errori);
- generato dalla RPDA, per il flusso di comunicazione tra la RPDA e l’INI (per segnalare un errore nella richiesta).
|
Campo |
Tipologia |
Codifica |
Descrizione |
Obbligatorietà |
|---|---|---|---|---|
|
Stato risposta |
specifico per messaggio |
Come da specifiche IHE |
Successo/Fallimento |
si |
|
Codice errore |
specifico per messaggio |
Come da specifiche IHE |
Vedi tabella messaggi errore |
si |
A titolo esemplificativo, in appendice A6, sono riportati i messaggi di richiesta e risposta del servizio. Per maggiore dettagli, si rimanda alle specifiche tecniche ufficiali IHE.
Fallimento / parziale successo servizio
Codici di errore
AdhocQueryResponse/RegistryErrorList/RegistryError
|
Attributo |
Tipo di dato |
Valore |
|---|---|---|
|
codeContext |
String |
Vedi tabella messaggi di errore |
|
errorCode |
String |
[ERROR_CODE] |
|
location |
String |
Indica la posizione dell’errore verificatosi |
|
severity |
String |
urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error |
AdhocQueryResponse/RegistryErrorList/RegistryError.errorCode
|
[ERROR_CODE] |
Descrizione |
|---|---|
|
XDSRepositoryBusy |
Carico di lavoro eccessivo |
|
XDSRepositoryError |
Errore interno: specificare solo se non sono disponibili codici più dettagliati |
|
XDSRepositoryOutOfResources |
Poche risorse |
|
XDSDocumentUniqueIdError |
Documento associato all’id indicato non disponibile |
Gestione errori di verifica delle asserzioni
Gli errori generati da eventuali fallimenti di controllo sulle asserzioni sono descritti nel capitolo 4.