{"id":1407,"date":"2024-10-29T11:32:15","date_gmt":"2024-10-29T10:32:15","guid":{"rendered":"https:\/\/compliance.toscana.it\/wordpress\/?p=1407"},"modified":"2024-10-29T14:11:37","modified_gmt":"2024-10-29T13:11:37","slug":"nuove-specifiche-per-fse-2-0","status":"publish","type":"post","link":"https:\/\/compliance.toscana.it\/wordpress\/it\/nuove-specifiche-per-fse-2-0\/","title":{"rendered":"Nuove specifiche per FSE 2.0"},"content":{"rendered":"\n

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<\/a>

L’ambiente di staging di Regione Toscana sar\u00e0 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\u00a0 nei tempi indicati .

Si suggerisce\u00a0 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\u00a0 di produzione\u00a0 previsti per 11 Novembre .

Di seguito la specifica aggiornata.
<\/p>\n\n\n\n

*STRUTTURA UTENTE*<\/strong>
*DESCRIZIONE*<\/strong>\u00a0\u00a0\u00a0\u00a0 Tale attributo, univoco, identifica la struttura a cui appartiene l\u2019utente. L\u2019elemento \u00e8 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\u00f2 far riferimento ad AuthorInstitution nell’Affinity Domain Italia v.2.5 par. 2.1.2.
*ESEMPIO*<\/strong>\u00a0\u00a0\u00a0\u00a0 I valori ammessi per il custom claim \u201clocality\u201d si differenziano per i vari servizi del Gateway.
Per i servizi di CREATE e REPLACE (anche con validazione contestuale), l\u2019unica valorizzazione possibile \u00e8 quella come tipo XON, ad esempio:

\u00a0* LABORATORIO DI
\u00a0\u00a0 PROVA^^^^^&2.16.840.1.113883.2.9.4.1.3&ISO^^^^111101123456 (tipo
\u00a0\u00a0 XON), che indica la struttura “LABORATORIO DI PROVA\u201d della Regione
\u00a0\u00a0 \u201c111\u201d, ASL \u201c101\u201d e codice STS.11(6) \u201c123456″.

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:

\u00a0* LABORATORIO DI PROVA^^^^^&2.16.840.1.113883.2.9.4.1.3&ISO^^^^111101123456 (Tipo XON);
\u00a0* ^^^^^&2.16.840.1.113883.2.9.4.1.3&ISO^^^^111101123456 (Tipo XON);
\u00a0* 2.16.840.1.113883.2.9.4.1.3.111101123456 (tipo OID);
\u00a0* 111101123456 (Regione \u201c111\u201d, ASL \u201c101\u201d e codice STS.11(6) \u201c123456″);
\u00a0* 101123456 (ASL \u201c101\u201d e codice STS.11(6) \u201c123456″);
\u00a0* 123456 (Codice STS.11(6) \u201c123456″)

*VALIDAZIONE*<\/strong>\u00a0\u00a0\u00a0\u00a0 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\u2019OID del sistema di codifica, XON.6.3 \u00e8 obbligatoriamente \u201cISO\u201d 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 \u00e8 conforme al tipo XON, per le logiche di popolamento dell\u2019asserzione di attributo locality riportate in Note.
*CAMPO JWT*<\/strong>\u00a0\u00a0\u00a0\u00a0 |locality<\/code>|
*NOTE*<\/strong>\u00a0\u00a0\u00a0\u00a0 L\u2019identificativo della struttura utente verr\u00e0 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 \u201clocality\u201d per valorizzare, verso INI, il metadato \u201cAuthor.AuthorInstitution\u201d e l’asserzione di attributo \u201clocality\u201d; nel caso in cui il claim \u201clocality\u201d (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 :

\u00a0* Lo stesso valore verr\u00e0 utilizzato per la valorizzazione del metadato
\u00a0\u00a0 \u201cAuthor.AuthorInstitution\u201d che il Gateway comunica a INI;
\u00a0* L’asserzione di attributo \u201clocality\u201d che il Gateway comunica a INI
\u00a0\u00a0 verr\u00e0 valorizzato come concatenazione di codice catalogo (XON.6.2) e
\u00a0\u00a0 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 \u201clocality\u201d per popolare l’asserzione di attributo \u201clocality\u201d verso INI:

\u00a0* Se il custom claim locality \u00e8 conforme al tipo XON, attua la stessa
\u00a0\u00a0 trasformazione prevista per CREATE e REPLACE, ovvero, concatenando
\u00a0\u00a0 di codice catalogo e codice struttura.
\u00a0* In caso contrario, il suo valore viene ribaltato senza ulteriori
\u00a0\u00a0 controlli.

Il metadato \u201cAuthor.AuthorInstitution\u201d non \u00e8 necessario in DELETE, mentre in UPDATE viene popolato utilizzando il valore che il Gateway ottiene con l\u2019operazione di recupero metadati (FindDocuments) propedeutica all\u2019aggiornamento metadati.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Il\u00a0 teamfse2.0 rimane a disposizione per chiarimenti.<\/p>\n","protected":false},"excerpt":{"rendered":"

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\u00e0 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 […]<\/p>\n","protected":false},"author":2,"featured_media":1148,"comment_status":"closed","ping_status":"closed","sticky":true,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/posts\/1407"}],"collection":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/comments?post=1407"}],"version-history":[{"count":6,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/posts\/1407\/revisions"}],"predecessor-version":[{"id":1413,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/posts\/1407\/revisions\/1413"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/media\/1148"}],"wp:attachment":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/media?parent=1407"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/categories?post=1407"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/tags?post=1407"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}