Noto con grande stupore che, salvo poche eccezioni, si continuano a progettare le applicazioni sanitarie come “isole a sé stanti“, salvo poi preoccuparsi, una volta terminato lo sviluppo, capire come integrarle con altri sistemi.
Il problema riguarda non soltanto l’offerta ma anche la domanda. Se oggi è abbastanza usuale trovare nei requisiti non funzionali dei capitolati di gara la richiesta di sistemi “privacy by default” e “privacy by design“, grazie alle indicazioni del GDPR, niente di tutto ciò avviene per l’interoperabilità.
L’attenzione dei progettisti è focalizzata sulla scelta delle tecnologie di sviluppo, le funzioni da implementare, i dati e la struttura del database. L’interoperabilità è, di solito, un requisito che viene assolto da un middleware o da un’apposita infrastruttura ma che non incide sull’architettura del sistema.
Questo approccio poteva andare bene fintanto che si adoperano gli standard HL7 versione 2 e CDA CDA che si basano sulla logica degli eventi e dei messaggi / documenti. Ciascun sistema, al verificarsi di alcuni eventi, predeterminati, scambia attraverso messaggi o documenti delle informazioni con i sistemi che sono potenzialmente interessati / coinvolti. L’integrazione presuppone quindi la definizione di specifici casi d’uso, l’individuazione degli eventi e la messa a punto della messaggistica.
HL7 FHIR, lo standard di riferimento per il futuro della sanità, si basa su una logica completamente differente. Ciascuna componente applicativa “mette a disposizione” una o più risorse. Una risorsa è, in FHIR, un’entità in grado di memorizzare e scambiare informazioni strutturate attraverso una URL. Ogni applicazione può quindi, per svolgere una funzione o eseguire un processo, accedere alle risorse che gestiscono le informazioni necessarie; oppure, viceversa, mettere a disposizione di altri sistemi le informazioni che gestisce.
Nel progettare un’applicazione è dunque necessario pensare in termini di risorse secondo lo schema di HL7 FHIR: risorse esposte, che altri sistemi possono richiamare; risorse che l’applicazione utilizza per svolgere le funzioni che gestisce.
Tra componenti applicative o applicazioni dello stesso produttore, a maggior ragione se basate su logica a servizi, l’interoperabilità deve avvenire tramite risorse FHIR. In questo modo si ottiene la massima intercambiabilità tra applicazioni e diviene davvero facile “calare” un’applicazione in un sistema eterogeneo.
La sanità è un mondo complesso: in un ospedale possono essere presenti sino a 60 diverse applicazioni; in una ASL oltre 100. L’interoperabilità e l’intercambiabilità delle applicazioni sono assolutamente necessarie. Non è concepibile continuare a sviluppare software senza affrontare questi aspetti in modo nativo e a dover investire tempo, denaro e risorse per realizzare sistemi clinici e gestionali.