Le strutture sanitarie si affiliano a una comunità. In caso di integrazione profonda della CIP nel sistema primario, oltre che con la comunità quest’ultimo deve collegarsi anche con il fornitore di identità (Identity Provider) della comunità per autenticare gli utenti. Ogni comunicazione della comunità con le altre comunità o con i servizi della Confederazione è eseguita in background.

Questo livello si rivolge ai responsabili tecnici che vogliono sapere quali interfacce e requisiti di sicurezza devono implementare per poter successivamente collegare il loro sistema primario alla piattaforma CIP della comunità. Link inseriti sotto le designazioni delle interfacce aprono esempi di messaggi e informazioni dettagliate destinate agli sviluppatori delle interfacce.

Questa offerta su GitHub viene continuamente integrata e ampliata.

Link esterno: GitHub

Panoramica dei componenti e delle interfacce CIP rilevanti

La seguente figura mostra i casi d’uso richiesti (frecce tra il sistema primario e la comunità o il sistema primario e il fornitore di identità) assieme ai componenti tecnici pertinenti.

Link esterno: La figura può anche essere scaricata nel formato PDF qui. (412 KB, 30/10/23)

I casi d'uso e le interfacce in dettaglio

I casi d'uso e le relative interfacce sono descritti di seguito.

1. Gestione dei pazienti

Per consentire a un professionista della salute o al suo personale ausiliario l’accesso a una CIP, il sistema primario deve registrare il paziente all’interno della comunità.

A tal fine invia al Master Patient Index (MPI) della comunità l’ID paziente locale assieme ai dati demografici estratti dalla banca dati delle persone UPI dell’Ufficio centrale di compensazione della Confederazione.

Per sapere come ricevere i dati demografici dalla banca dati UPI si prega di contattare la propria comunità.

Una volta registrato il paziente all’interno della comunità, per accedere alla CIP il sistema primario può richiamare mediante l’ID paziente locale gli identificatori necessari per l’accesso.

1.1 Ricerca di un paziente

Se il paziente è già registrato nel MPI della comunità, il sistema primario può cercarlo anche in base a dati demografici (p. es. cognome, nome o data di nascita), per poi ad esempio registrare l’ID locale (Link esterno: Patient Demographics Query ).

1.2 Registrazione di un paziente

Per registrare un paziente nel MPI della comunità, il sistema primario invia i dati personali estratti dall’UPI e l’ID paziente locale (Link esterno: Patient Identity Feed ).

1.3 Consultazione dell’identità di un paziente

Dopo che il paziente è stato registrato nell’MPI della comunità, il sistema primario può richiamare, in base all’ID paziente locale, gli identificatori EPR-SPID e MPI-PID per l’accesso alla CIP (Link esterno: PIXV3 Query ).

Nota: per motivi legali, l’EPR-SPID non può essere salvato durevolmente nel sistema primario e deve quindi essere richiesto ogni volta.

2. Autenticazione degli utenti CIP

Il professionista della salute o il suo personale ausiliario si autentica mediante l’identità elettronica, attraverso il sistema primario, presso il proprio fornitore di identità. Quest’ultimo conferma alla comunità che si tratta effettivamente di lui e crea una Identity Provider User Session.

A tal fine sono necessarie tre interfacce: l’autenticazione dell’utente (Link esterno: Authenticate User ), il rinnovo di una Identity Provider User Session scaduta, ma rinnovabile (Link esterno: IdP Renew ) nonché il logout (Link esterno: SSO Logout ).

Nel contesto della CIP è prescritto l’uso di SAML 2 Artifact Binding attraverso HTTP con un XML SOAP Webservice Backchannel. L’autenticazione avviene in due fasi: nella prima sono trasmessi via HTTP solo token astratti, mentre i dati sull’utente (claim) sono richiamati soltanto nella seconda fase attraverso una chiamata Webservice protetta.

3. Autorizzazione degli utenti CIP

Una volta autenticatosi presso il fornitore di identità, il professionista della salute o l’assistente indica il contesto dell’accesso alla CIP, ad esempio il proprio ruolo utente o il grado di riservatezza per la consultazione dei documenti. Questi dati sono inviati al X-Assertion Provider (Link esterno: Get X-User Assertion ). Quale risposta, il professionista della salute ottiene una SAML 2.0 User Assertion, che conferma i dati immessi.

Per tutte le interfacce, protette anche attraverso la gestione dei diritti di accesso (soprattutto per quanto riguarda la gestione dei documenti), assieme al messaggio tecnico occorre inviare anche questa SAML 2.0 Assertion (Link esterno: Provide X-User Assertion ).

4. Gestione dei documenti nella CIP

Qui di seguito sono illustrati i casi d’uso per l’immissione, la ricerca e la consultazione nonché l’aggiornamento di documenti e metadati nella CIP.

4.1 Immissione di documenti

Il sistema primario registra e salva documenti nella propria comunità (Link esterno: Provide and Register Document Set ). A tal fine immette uno o più documenti con i relativi metadati (autore, specialità dell’autore, classe di documento ecc.). Il Document Repository riceve la richiesta, registra l'ID del documento e i metadati nel Document Registry centrale e carica il documento al suo interno.

4.2 Ricerca e consultazione di documenti

Normalmente, la consultazione dei documenti avviene in due fasi:
Nella prima il sistema primario richiama i metadati di tutti i documenti di un paziente, se del caso filtrati in base a determinati metadati. A tal fine il sistema primario esegue una ricerca e mostra all’utente l’elenco dei risultati (Link esterno: Registry Stored Query ).
Nella seconda fase, il sistema primario richiama uno o più documenti selezionati e visualizza i contenuti nelle superfici utente o li salva nel sistema primario (Link esterno: Retrieve Document Set ).

5. Comunicazione sicura e verbalizzazione

Per comunicare in modo sicuro, il sistema primario utilizza TLS. Si autentifica mediante il proprio certificato client (mutua autentificazione).

Per ogni comunicazione il sistema primario configura un audit log e lo trasmette alla comunità servendosi di Record Audit Event. Per il formato, è definito uno speciale schema XML. Informazioni dettagliate sugli audit sono disponibili nelle interfacce su GitHub. 

Link esterno: A GitHub

Panoramica delle interfacce rilevanti