Rapporto sui risultati

portale. In particolare non si può escludere che il paziente o il fornitore di prestazioni voglia utilizzare formati proprietari per i quali non sono disponibili dei programmi di conversione o esistono solo programmi con una conversione parziale. A ciò si aggiunge che la conversione in uno dei formati ammessi rappresenta un trattamento dei dati ai sensi della LPD. Bleuer segnala che è l’allegato 4 (e non il 3) a definire i formati di scambio, cosa da rettificare al numero 3.4.1.1.

A parere di 6 Cantoni¹¹⁰, per motivi d’integrità dei dati è pericoloso che il portale converta un file fonte. È responsabilità dei professionisti della salute fornire il formato giusto. Ciò implicherebbe che il portale di accesso debba essere in grado di leggere tutta una serie di formati. Chiedono di stralciare il numero 3.4.1.2. Bleuer ricorda che in seguito alla conversione potrebbero affiorare errori che modificano il senso del testo e chiedono quindi di conservare sempre anche i formati originali. Se si lasciano i documenti nel formato originale diventa problematico limitare i formati a quelli ammessi. In ogni caso bisognerebbe ammettere tutti i formati usuali, fra cui in particolare ZIP e ISO. Il partecipante propone la seguente formulazione del numero 3.4.1.2: «[…] in eines der in Anhang 4 aufgeführten Formate umwandeln. Dokumente sind bei Umwandlung zusätzlich im Originalformat vorzuhalten». Analogamente, BINT e Integic chiedono che in caso di conversione si debbano archiviare i file anche nel formato originale. Ciò significa l’ammissione di oggetti anche come bitstream. SUVA osserva che la conversione non è compatibile con la sicurezza di revisione e si dichiara favorevole a lasciare i file nel formato originale. Posta chiede perché è necessario convertire anche formati usuali e chi si assume la responsabilità nel caso in cui la conversione automatica provochi una perdita di informazioni che possa condurre a un errore terapeutico. K3 e VZK ritengono necessario vietare la conversione durante l’upload, perché durante la conversione si potrebbero falsificare dei contenuti, con una conseguente violazione dell’integrità dei dati. Il risultato sfuggirebbe al controllo dell’autore e il documento presenterebbe un contenuto diverso. La disposizione dovrebbe quindi essere modificata in modo da non consentire la conversione durante l’upload. Non si dovrebbero poter convertire i documenti e quindi il requisito deve essere stralciato. In riferimento al numero 3.4.1.2, Integic chiede inoltre quali modalità di conversione siano previste e come si debba gestire il caricamento di dati provenienti da fitness tracker o da applicazioni. Secondo HIN dovrebbe essere nell’interesse dei produttori di sistemi primari offrire le apposite possibilità di conversione. Il portale dovrebbe autorizzare solo determinati tipi di dati. Si chiede la seguente riformulazione del numero 3.4.1.2: «Dateien der im Anhang 3 definierten Formate entgegennehmen. Dateien in anderen Formaten müssen entweder automatisiert umgewandelt oder abgewiesen werden». Per precisare il numero 3.4.1.2, medshare desidera la seguente aggiunta: «[…] in ein gemäss 3.4.1.1 zugelassenes Format umwandeln».

3.5 Formati di dati: consultazione

K3, VZK, ZAD nonché i Cantoni ZG e ZH considerano superflue le disposizioni di cui al numero 3.5 e chiedono pertanto di stralciarle. Posta vuole sapere perché alcuni tipi di documenti correnti come Word, non sono supportati.

3.5.1: Riguardo al numero 3.5.1.2, privatim rimanda alle spiegazioni fornite nel quadro delle osservazioni generali sull’OCIP. SBC segnala che il «bulk download» consente una lacuna di sicurezza e che il numero 3.5.1.3 deve quindi essere stralciato. Integic chiede se in caso di «bulk download» l’utente sia tenuto a inserire una verifica per ogni documento o se debba farlo una sola volta in blocco. Il punto dovrebbe essere chiarito o completato. In riferimento al numero 3.5.1.5, BINT, Integic e IG eHealth evidenziano che il concetto di umanamente leggibile non è un problema di scaricamento ma di presentazione. Chiedono se non s’intenda piuttosto un «rendering» a livello di server. In tal caso il punto dovrebbe essere esplicitato. Anche SUVA desidera una precisazione del concetto di «menschenlesbar». A parere di KSSG non si può partire dal presupposto che il portale sappia gestire ogni tipo di dati strutturati, ma solo i formati di scambio indicati nell’allegato 4 dell’OCIP-DFI. Il numero 3.5.1.5 dovrebbe essere adeguato in modo da consentire solo i formati di scambio previsti nell’allegato 4 dell’OCIP-DFI. 6 Cantoni¹¹¹ vogliono stralciare il numero 3.5.1.1 e riformulare i numeri, 3.5.1.2, 3.5.1.3 e 3.5.1.5 come