Rapporto sui risultati

costi. Propongono di cancellare questo requisito. BINT, Integic, IG eHealth e ahdis sono favorevoli allo stralcio del numero 2.9.4.4. La Patient Location Query è esclusa esplicitamente nell’allegato 5 dell’OCIP-DFI. BINT, Integic e ahdis vorrebbero l’inclusione di un numero 2.9.4.5; Update Document Set Cross Community [ITI-xxx]. Essi scrivono che per modificare in un’altra comunità i gradi di riservatezza dei metadati di un documento è necessaria una transazione Cross Community. Vorrebbero poi creare anche un numero 2.9.4.6; On-Demand Documents Option (vedi ITI TF-2a, 3.18.4.1.2.5).

SQS fa rilevare che le verifiche tecniche di tale profondità non possono essere effettuate nell’ambito dell’audit di un sistema di gestione e non sono compatibili con l’essenza stessa dell’audit (prove a campione). I requisiti qui descritti sono dei criteri di prova obbligatori, che devono essere validati e protocollati nel quadro della messa in funzione dei sistemi/delle interfacce. Queste prove devono essere disciplinate al di fuori delle certificazioni vere e proprie, p. es. nell’ambito di una verifica tecnica. Nel corso della certificazione si deve verificare mediante dei controlli solo se tali verifiche sono state effettuate e se gli eventuali esiti sono stati trattati. La norma di certificazione non definisce invece quanto sia rilevante l’esito. Concretamente SQS chiede di completare i numeri 2.9.4 – 2.9.21 con una disposizione riguardante la prova delle avvenute verifiche tecniche delle premesse tecniche e ripete la richiesta per tutti i numeri rilevanti.

2.9.5/2.9.6 Attori e transazioni dei profili d’integrazione – comunicazione di identità autenticate: KSSG osserva in riferimento al numero 2.9.5 che non ritiene sufficiente XUA e che bisognerebbe optare per XUA++. Ahdis fa notare che al numero 2.9.6 manca una spiegazione di come un X-Service User ottiene l’assertion dal X-Assertion Provider e come deve essere la relazione nei confronti dell’User Authentification Provider.

2.9.9 Attori e transazioni dei profili d’integrazione – messa a disposizione dei documenti: KSSG chiede se sia obbligatorio archiviare i documenti nel repository mediante Provide and Register Document Set-

b. Si potrebbero per esempio archiviare i documenti nel repository anche attraverso HL7 MDM e poi registrarli nel registry con la transazione Register Document Set. A San Gallo si procede così, poiché le fonti dei documenti non supportano sempre il Provide and Register Document Set-b. Nell’ambito dei prodotti medici è poco probabile che questo requisito venga sviluppato per il mercato svizzero. Il numero dovrebbe essere ampliato in modo da consentire altre varianti di memorizzazione di documenti nel repository.

2.9.10 Attori e transazioni dei profili d’integrazione – mutazione dei metadati dei documenti: IG eHealth e Posta chiedono chi può assumere il ruolo di «Document Administrator». Se si tiene conto dei diritti degli autori è chiaro che ogni autore è anche implicitamente un «Document Administrator» dei documenti da lui pubblicati. Se non si considerano invece i diritti degli autori, questo requisito non è attuabile. Essi aggiungono che Update e Delete Document sono delle funzioni forti e che bisogna quindi chiarire chi può esercitare tali funzioni. Chiedono pertanto una definizione a riguardo, nel caso in cui l’autore non riceva implicitamente tale funzione. IG eHealth rileva inoltre in riferimento al numero 2.9.10.1 che, secondo l’articolo 1 capoverso 1 OCIP, si deve sempre indicare un grado di riservatezza. Consiglia poi lo stralcio del numero 2.9.10.2, perché basta modificare i metadati.

2.9.11 Attori e transazioni dei profili d’integrazione – registro di documenti: IG eHealth e Posta osservano che la LCIP si focalizza sullo spazio di fiducia fra le comunità. Le transazioni XDS.b sono «out of scope». Sarebbe opportuno definire più chiaramente il campo di applicazione della LCIP, dell’OCIP e delle CTO. Integic sottolinea riguardo al numero 2.9.11.2 che il termine corretto è «Registry Stored Query» e che bisogna quindi correggerlo. Rileva inoltre delle incongruenze nelle transazioni menzionate. Sono indicate per esempio delle transazioni che gli autori devono poter eseguire o ricevere/elaborare. Le transazioni che devono essere eseguite a seconda dell’IHE Actor (quindi ricevere e inviare) sono lacunose. Per esempio, 2.9.12. dovrebbe supportare ITI-42, poiché questa transazione avviene da Document Repository a Document Registry, ma è indicata solo nel Document Registry (2.9.11). Queste incongruenze devono essere corrette.