3.5 Trasferimento indice

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.

Ultimo aggiornamento: 06/02/2018