Rapporto sui risultati

segue: «3.5.1.2 permettre d'enregistrer des fichiers présents dans le système primaire ("upload"); 3.5.1.3 prévoir la publication, non seulement un par un, mais aussi en masse ("bulk upload") des documents sélectionnés; 3.5.1.5 […] données structurées brutes ou d'exporter la forme affichée de ces données». OFAC sottolinea in riferimento al «bulk download» di cui al numero 3.5.1.3 che una gran parte dei dati relativi al paziente esce dalla comunità e sfugge a qualsiasi controllo. Tale disposizione è inoltre in totale contraddizione con il concetto di «Patient Empowerment».

3.5.2: Medshare segnala che la parola «erlaubte» presenta un errore di battuta. K3 e VZK lamentano la scarsa precisione della redazione. Sulla stessa falsariga, SQS domanda chi definisce i limiti massimi ammissibili e chiede di precisare le competenze per la definizione dei limiti massimi ammissibili. Secondo Integic, BINT e IG eHealth, non è ammissibile fissare un limite assoluto. Si dovrebbe avere la possibilità di riconoscere e consultare semplicemente altri documenti disponibili. Per Posta l’argomentazione a favore dei «rate limit» non è comprensibile. Il paziente ha deciso che il professionista della salute ha accesso alla cartella informatizzata del paziente. Un limite artificiale non sembra quindi adeguato. A parere di Bleuer vi è il rischio che i documenti vengano consultati in modo incompleto. Il numero 3.5.2 deve quindi essere stralciato. Anche SUVA è a favore dello stralcio e ricorda che tale disposizione comporterebbe un’incompletezza dei dati del paziente. In caso di dati aggiunti personalmente dal paziente, questa disposizione significherebbe un’ingerenza nella sua sfera privata perché il paziente non avrebbe la possibilità di trasmettere i dati desiderati. HIN ritiene che i rate limit dovrebbero (poter) essere definiti dalle comunità. Il numero 3.5.2 dovrebbe essere completato come segue: «[…] auslösen. Die rate limits werden von den Gemeinschaften definiert».

4. Protezione e sicurezza dei dati (art. 11 OCIP)

ISSS vuole un nuovo numero 4.25 per garantire che i dati del paziente, dopo la distruzione, non rimangano archiviati per sempre. Chiede il seguente testo: «4.25 Datensicherung (Backups): Datensicherungen sind spätestens nach 2 Jahren zu vernichten, sofern keine gesetzlichen oder regulatorischen Anforderungen etwas Anderes verlangen. Im Falle belegbar betrieblicher Notwendigkeit kann diese Dauer auf maximal 3 Jahre ausgedehnt werden». SQS segnala che tutto il numero 4 contiene gran parte degli elementi della norma ISO/IEC 27001:2013 e dei Controlli dell’allegato A. Sarebbe più opportuno rinviare all’ISO/IEC 27001:2013 incl. allegato A e descrivere solo gli elementi aggiuntivi specifici per l’OCIP. Un elemento di questo tipo potrebbe essere la notifica all’UFSP degli eventi rilevanti per la sicurezza. Nell’allegato s’impiegano inoltre dei termini non corrispondenti all’ISO/IEC 27001:2013. Concretamente si propone la separazione degli elementi contenuti nella norma ISO/IEC 27001:2013 e nei Controlli dell’allegato A dalle aggiunte specifiche per l’OCIP nonché l’impiego della terminologia dell’ISO/IEC 27001:2013. FMH afferma che nell’ambito della protezione dei dati ci si debba riferire alle norme e alle good practice in vigore e non elaborare nuove disposizioni. Come SSIM anche FMH chiede di riformulare tutto il numero 4. A parere di Tessaris, le onerose condizioni tecniche e organizzative previste nel numero 4, non potranno essere interamente sostenute da una comunità con risorse di personale e di mezzi limitate, come un ambulatorio con un solo medico o un piccolo ambulatorio collettivo che desidera introdurre e gestire la cartella informatizzata del paziente. Queste piccole strutture dovranno pertanto ricorrere a terzi («organizzazioni di esercizio»). Se tali organizzazioni forniscono prestazioni per le comunità, dovrebbero anche soddisfare i requisiti di cui all’articolo 11 OCIP e al numero 4, altrimenti vi sarebbe una lacuna nel dispositivo di garanzia della protezione e della sicurezza dei dati.

4.1 Requisiti per terzi

Privatim approva questa regolamentazione per motivi di protezione dei dati. Sebbene tali aspetti siano già disciplinati nelle LPD cantonali e federali, ai fini di una maggiore chiarezza e completezza è opportuno riprenderli nelle CTO.

4.2 Responsabile della protezione e della sicurezza dei dati (cpv. 1)

4.2.1: HIN si rallegra che la norma ISO 27001 sia menzionata in modo esplicito. SQS segnala che