Senza categoria
Nuove specifiche per FSE 2.0
E’ stato rilasciato un cambiamento di specifiche FSE 2.0, riferite al tag locality pubblicate alla URL https://github.com/ministero-salute/it-fse-support/tree/main/doc/integrazione-gateway
L’ambiente di staging di Regione Toscana sarà adeguato il giorno 28 Ottobre. L’ambiente di produzione il giorno 11 Novembre.
L’adeguamento consiste nella introduzione di controlli bloccanti di validazione del tag locality.
I referenti aziendali e le software house dovranno verificare con accortezza come oggi viene gestito il tag locality e provvedere nei termini previsti all’adeguamento delle mutate specifiche tecniche nei tempi indicati .
Si suggerisce di effettuare dei test di integrazione ad hoc sull’ambiente di staging a partire dal giorno 28.10.2024 per non andare in disservizio alla attivazione dei controlli di validazione in ambiente di produzione previsti per 11 Novembre .
Di seguito la specifica aggiornata.
*STRUTTURA UTENTE*
*DESCRIZIONE* Tale attributo, univoco, identifica la struttura a cui appartiene l’utente. L’elemento è sottoposto alle validazioni come da sezione “VALIDAZIONE” e viene utilizzato dal Gateway per il colloquio con INI come riportato nella sezione “NOTE”. Per maggiori informazioni sulla valorizzazione di tipo XON si può far riferimento ad AuthorInstitution nell’Affinity Domain Italia v.2.5 par. 2.1.2.
*ESEMPIO* I valori ammessi per il custom claim “locality” si differenziano per i vari servizi del Gateway.
Per i servizi di CREATE e REPLACE (anche con validazione contestuale), l’unica valorizzazione possibile è quella come tipo XON, ad esempio:
* LABORATORIO DI
PROVA^^^^^&2.16.840.1.113883.2.9.4.1.3&ISO^^^^111101123456 (tipo
XON), che indica la struttura “LABORATORIO DI PROVA” della Regione
“111”, ASL “101” e codice STS.11(6) “123456″.
Per i servizi di DELETE e UPDATE sono ammesse ulteriori valorizzazioni.
Esempi di valorizzazioni possibili per la stessa struttura al punto precedente sono i seguenti:
* LABORATORIO DI PROVA^^^^^&2.16.840.1.113883.2.9.4.1.3&ISO^^^^111101123456 (Tipo XON);
* ^^^^^&2.16.840.1.113883.2.9.4.1.3&ISO^^^^111101123456 (Tipo XON);
* 2.16.840.1.113883.2.9.4.1.3.111101123456 (tipo OID);
* 111101123456 (Regione “111”, ASL “101” e codice STS.11(6) “123456″);
* 101123456 (ASL “101” e codice STS.11(6) “123456″);
* 123456 (Codice STS.11(6) “123456″)
*VALIDAZIONE* Per i servizi di CREATE e REPLACE (anche con validazione contestuale) il Gateway fa un controllo bloccante per verificare che il popolamento rispetti lo standard XON (in cui XON.1 contiene il nome della struttura, XON.6.2 rappresenta l’OID del sistema di codifica, XON.6.3 è obbligatoriamente “ISO” e XON.10 rappresenta il codice della struttura);
Per i servizi di DELETE e UPDATE non vengono effettuati controlli bloccanti; viene controllato solo quando il campo in input è conforme al tipo XON, per le logiche di popolamento dell’asserzione di attributo locality riportate in Note.
*CAMPO JWT* |locality|
*NOTE* L’identificativo della struttura utente verrà utilizzato dal Gateway in base al servizio richiesto.
Nelle operazioni di CREATE e REPLACE (anche con validazione contestuale), il Gateway utilizza il contenuto del claim “locality” per valorizzare, verso INI, il metadato “Author.AuthorInstitution” e l’asserzione di attributo “locality”; nel caso in cui il claim “locality” (che deve essere di tipo XON) sia valorizzato come di seguito
LABORATORIO DI PROVA^^^^^&2.16.840.1.113883.2.9.4.1.3&ISO^^^^111101123456 :
* Lo stesso valore verrà utilizzato per la valorizzazione del metadato
“Author.AuthorInstitution” che il Gateway comunica a INI;
* L’asserzione di attributo “locality” che il Gateway comunica a INI
verrà valorizzato come concatenazione di codice catalogo (XON.6.2) e
codice struttura (XON.10): 2.16.840.1.113883.2.9.4.1.3.111101123456
Nelle operazioni di DELETE e UPDATE, il Gateway utilizza il contenuto del claim “locality” per popolare l’asserzione di attributo “locality” verso INI:
* Se il custom claim locality è conforme al tipo XON, attua la stessa
trasformazione prevista per CREATE e REPLACE, ovvero, concatenando
di codice catalogo e codice struttura.
* In caso contrario, il suo valore viene ribaltato senza ulteriori
controlli.
Il metadato “Author.AuthorInstitution” non è necessario in DELETE, mentre in UPDATE viene popolato utilizzando il valore che il Gateway ottiene con l’operazione di recupero metadati (FindDocuments) propedeutica all’aggiornamento metadati.
Il teamfse2.0 rimane a disposizione per chiarimenti.