Possibile improvement: recupero riferimenti documento e metadati deprecati

[izamberlan]

In riferimento alla issue #1379 (dalla quale ho eliminato un mio precedente messaggio di pari contenuto per evitare dirottamenti) la ITI-18 per la query di GetDocuments non permette di specificare lo status, si veda https://profiles.ihe.net/ITI/TF/Volume2/ITI-18.html#3.18.4.1.2.3.7.5

Con l'uso della metadata update, è possibile che una recupero riferimenti documento, a fronte di un document uniqueId ritorni più uuid; fra questi è probabile che uno solo faccia riferimento ad un'istanza di metadati documento in status Approved, mentre altre saranno in status Deprecated. Dalla response non c'è modo, se la response option è ObjectRef, di capire quale sia il documento Approved. In teoria il Gateway, a fronte di una risposta con più di un uuid, dovrebbe, in caso di sostituzione, tentare di sostituire tutti i documenti con un numero di chiamate pari alle istanze presenti nella response, ma, se prova a sostituire un documento deprecato, il sistema regionale risponderà con un errore.

Chiedo di esaminare la possibilità di limitare, per specifica/accordo, il ritorno della getDocuments ObjectRef per recupero riferimenti documento ai soli documenti in status=Approved (le specifiche AgID FSE 1.0 non sono esplicite in merito).

[rangemasterd]

Buongiorno,
lo standard IHE prevede un modo per ovviare a questo problema.
L'aggiornamento dei metadati porta incompatibilità con le precedenti ITI e per ovviare a tale problematica è stato introdotto il parametro metadataLevel per la ITI-18.

Capitolo 3.18.4.1.2.3.5.1 Compatibility Issues ITI-57.

In Regione Umbria abbiamo implementato questa funzionalità in modo da rimanere nello standard IHE.

Tuttavia rimane fuori la casistica di filtraggio di un documento oscusato.
Se viene effettuata una ITI-18 di un documento oscurato (P99 presente) con retunType=ObjectRef da parte di un soggetto che non è l'assistito stesso, allora la query ha successo e lo UUID del documentEntry viene ritornato.

Questo comportamento non è corretto in quanto il documento è oscurato.

Non sembra esserci una soluzione a livello standard IHE e ritengo che sarebbe opportuno adottare una soluizione condivisa.

[izamberlan]

A nostro giudizio, posto che si ritornino gli identificativi solo ai nodi che hanno originariamente indicizzato il documento, ad eventuali query di recupero riferimenti su documenti oscurati è necessario rispondere, altrimenti si rendono impossibili sostituzione e cancellazione, violando il principio secondo il quale i dati devono essere aggiornati.
Per quanto riguarda il metadataLevel è corretto, non ci avevo pensato

[ivanot]

Buongiorno, rispondo come tecnico della regione FVG.

Non ho capito bene in che modo si potrebbe usare il parametro metadataLevel per ovviare al problema, ma vorrei proporre una soluzione alternativa che potrebbe andare incontro a tutti i casi alternativi di difficile gestione.

Propongo di evitare la ITI-18 per recupero riferimenti procedendo direttamente alla ITI-57, imputando nel lid dell'ExtrinsicObject un identificativo simbolico, lasciando al registry ricevente il compito di trovare i set di metadati esistenti per lo stesso UID e decidere come aggiornare.

In particolare se viene sottomessa una simile ITI-57 al registry gli scenari possibili dovrebbero essere questi:

1. non esiste nessun set di metadati con lo UID indicato -> errore
2. esiste uno o più set di metadati ma sono tutti deprecati -> errore
3. esistono da zero a n set di metadati deprecati e da 1 a n Approved -> procedo a deprecare tutti gli esistenti e attribuisco al lid del nuovo set quello più recente

Un saluto
Ivano Tomainu

[izamberlan]

metadataLevel assume come default 1, se capisco bene basterrebbe non specificare nulla per ottenere il risultato (il registry ritorna solo la DocumentEntry più recente).
La proposta dell'update per uniqueId a noi comporterebbe un certo lavoro (le specifiche AgID prevedono che il Document Administrator sia la RCD, anche se poi assegna alla RDA alcuni dei compiti dell'Administrator).
Forse non ho capito la soluzione proposta, in ogni caso: a quanto ho capito il problema non è la ITI-57 dal gateway, che anche per altre questioni deve fare una LeafClass (i metadati in payload/JWT REST vanno ad aggiornare il risultato di una query perché non sono completi) e quindi può inserire lo status fra le condizioni. Il problema è nelle replace e nelle delete. Però ripeto, forse ho capito male.

[ivanot]

metadataLevel assume come default 1, se capisco bene basterrebbe non specificare nulla per ottenere il risultato (il registry ritorna solo la DocumentEntry più recente).

Ok ho capito come intendete usarla, nel nostro caso però rimarrebbero scoperte le casistiche in cui abbiamo più di un set di metadati attivo, il nostro registry (come da standard XDS) accetta indicizzazioni multiple. Ovvio che nulla ci vieta di "sanarle" con una implementazione ad hoc.

[ivanot]

La proposta dell'update per uniqueId a noi comporterebbe un certo lavoro (le specifiche AgID prevedono che il Document Administrator sia la RCD, anche se poi assegna alla RDA alcuni dei compiti dell'Administrator). Forse non ho capito la soluzione proposta, in ogni caso: a quanto ho capito il problema non è la ITI-57 dal gateway, che anche per altre questioni deve fare una LeafClass (i metadati in payload/JWT REST vanno ad aggiornare il risultato di una query perché non sono completi) e quindi può inserire lo status fra le condizioni. Il problema è nelle replace e nelle delete. Però ripeto, forse ho capito male.

Il problema per noi è emerso in una replace fatta a seguito di una update sullo stesso UID, però concordo con quel che dici che riguarda anche la delete; concordo che la ITI-57 si risolverebbe con una LeafClass, ma la stessa risente del problema che i documenti oscurati non li dovresti avere in risposta: se un documento viene inserito non oscurato e successivamente viene aggiornato con ITI-57 classificata P99, una successiva replace/update/delete fallirebbe usando la query LeafClass

[izamberlan]

Quello dell'oscuramento resta un problema di difficile soluzione. Un'idea di massima potrebbe essere una query dedicata e disponibile solo al Gateway (una pseudo-recupero riferimenti che permetta la leafClass e che sia utilizzata solo all'interno di questo processo), ma limiterebbe l'aggiornamento dei documenti oscurati ai soli flussi FSE 2.0 (impedendo quindi la gestione, ad es., delle ricette oscurate, in questo momento).

[izamberlan]

PS: d'altra parte la ITI-57 ha problemi anche nel contesto FSE 1.0 (previousVersion obbligatorio in update, ma non ritornato dalla recupero riferimenti e se provi a fare una leafClass su un paziente senza consenso alla consultazione ottieni un errore)

[ivanot]

Vero, anche la valorizzazione del previousVersion non eravamo riusciti a realizzarla a causa di una forte disparità nelle risposte ottenute.

Comunque la soluzione che ho proposto non esclude l'altra, potrebbe coesistere offrendo in opzione una gestione più leggera e semplificata.