Rapporto sui risultati
Consultazione 2015/88: Diritto esecutivo relativo alla legge federale sulla cartella informatizzata del paziente (LCIP)(solo francese) · 150 pagine
Fedlex · Rapporto sui risultati · Pagina 103Fedlex · Rapporto sui risultati
3.2.5 Art. 5 Integrationsprofil (allegato 5)
Art. 5 Integrationsprofile
Anhang 5 legt in Anwendung von Artikel 9 Absatz 3 Buchstabe d und e OCIP fest:
a. die Integrationsprofile;
b. die nationalen Anpassungen der Integrationsprofile;
c. die nationalen Integrationsprofile.
Articolo 5: Il Cantone NE si associa in questo punto al commento del Cantone FR sull’articolo 1 OCIP-DFI. H+ si rallegra che il DFI si avvalga di standard tecnici riconosciuti a livello internazionale e utilizzati da tempo anche in Svizzera. L’importante è che alle comunità e comunità di riferimento non venga impedito, a causa della loro forma giuridica, di partecipare alle piattaforme di scambio di dati esistenti nell’ambito dell’eGovernment.
Allegato 5a
I Cantoni GE, VS, VD, JU und FR affermano di non avere le competenze per pronunciarsi su questo allegato, che deve essere validato da IHE Suisse. OFAC si affida a IHE Suisse per la standardizzazione e la documentazione dei profili d’integrazione. Anche KSSG ha fiducia nel parere di IHE Suisse e HL7. Il Cantone SG rimanda alla verifica da parte di IHE Suisse e HL7 e aggiunge che mancano dei profili d’integrazione che definiscono la cancellazione attraverso le comunità. Secondo LUKS è importante che il diritto d’esecuzione della LCIP sia al passo coi tempi in campo tecnico. È quindi opportuno tenere conto e autorizzare i futuri sviluppi dello standard FIHR di HL7. IHE Suisse e HL7 dovranno essere consultati per un’ulteriore valutazione e rielaborazione. IG eHealth e Posta dichiarano che questa disposizione non ha senso. I profili IHE definiti sono previsti in parte per l’impiego in un Affinity Domain e in parte per l’impiego «Cross Community». Il legislatore ha stabilito che la legge disciplina il settore fra le comunità e quindi non ha senso definire dei profili che sono destinati a essere utilizzati esclusivamente all’interno di Affinity Domain. Non è inoltre chiaro come si debba interpretare l’elenco dei profili. Ogni sistema che vuole partecipare alla comunità deve supportare tali profili? È quindi vietato integrare una soluzione che trasmette messaggi di HL7 mediante File Transfer? Queste disposizioni possono essere oggetto di audit e generano pertanto dei costi, che devono essere invece evitati. IG eHealth e Posta propongono di distinguere, nella formulazione dei profili, fra MUST (deve) e SHOULD (dovrebbe). Integic scrive a riguardo: «1.4 Requirements on ATNA, XDS.b and XCA Profiles for Audit Trail Consumption»: RESTful- ATNA è un nuovo Supplement for Trial Implementation e dovrebbe pertanto essere ripreso (Add RESTful Query to ATNA - Published 2015-08-07)166. Accanto alla soluzione proposta tramite estensione nazionale, è disponibile anche una soluzione con IHE RESTful-ATNA. SSIM e SBC osservano che i fornitori di componenti informatici dovrebbero registrarli (omologazione). La registrazione dei sistemi informatici dovrebbe inoltre essere completamente separata dalla certificazione delle comunità. Tale modo di procedere permetterebbe di ridurre notevolmente i costi di certificazione delle singole comunità, poiché i componenti tecnici sarebbero già registrati; ci sarebbe una ripartizione chiara delle responsabilità fra fornitori di componenti informatici e comunità, si otterrebbe un mercato aperto per i componenti tecnici, si semplificherebbe il processo di acquisto da parte della comunità, si promuoverebbe un’infrastruttura «best of breed», che non sarebbe un ecosistema chiuso di un solo fornitore, e si conferirebbe così uno stimolo a tutto il settore. SSIM e SBC propongono di far sì che la certificazione di una comunità, la quale impiega componenti registrati, non debba ripetere la procedura di registrazione dell’infrastruttura tecnica, ma si limiti a certificare solo i processi organizzativi e le misure di protezione dei dati. SSIM sostiene inoltre le proposte di IHE Suisse. HIN considera molto utile la panoramica e la breve descrizione sotto forma di tabella. Medshare è a favore della soluzione attraverso i profili d’integrazione. FMH chiede invece ancora lo stralcio, perché si oppone a una regolamentazione a livello di ordinanza.
166 http://wiki.ihe.net/index.php/ATNA_Repository_RESTful_Access http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_RESTful-ATNA.pdf