I sistemi informativi ospedalieri e territoriali sono composti da un numero ampio di applicazioni eterogenee che condividono informazioni mediante piattaforme di interoperabilità. Queste sono costituite da strumenti per l’inoltro e lo scambio di messaggi e da archivi di base, come ad esempio l’anagrafe aziendale dei pazienti (Master Patient Index) che hanno la funzione di omogeneizzare e identificare univocamente pazienti, utenti, prestazioni.
Per facilitare lo scambio di informazioni è poi normalmente presente un repository clinico che viene alimentato dai sistemi che producono dati o documenti e che viene utilizzato per accedere a tali informazioni. Lo standard più diffuso è IHE XDS nelle sue diverse varianti, anche perché è quello previsto dall’architettura del Fascicolo Sanitario Elettronico.
Ogni sistema possiede un suo database strutturato e conferisce al repository, molto spesso sotto forma di documento HL7 CDA, un sottoinsieme delle informazioni che tratta, talvolta al termine del processo che gestisce, ad esempio la Scheda di Dimissione Ospedaliera (SDO) nel caso di un ADT, la lettera di dimissione nel caso di una cartella clinica elettronica.
Quando si sostituisce un sistema con uno nuovo, anche se dello stesso produttore, è necessaria un’attività di migrazione dati che può essere molto complessa, costosa e dai risultati non sempre soddisfacenti. I dati e le strutture dei database cambiano, non sempre esiste una corrispondenza, talvolta la logica è differente. Il patrimonio informativo dell’azienda sanitaria, in questi passaggi, viene compromesso o, in alcuni casi, perduto.
C’è poi un altro aspetto che questa architettura comporta. Qualsiasi arricchimento funzionale deve essere necessariamente realizzato all’interno dell’applicazione che gestisce l’informazione che magari è in via di dismissione da parte del fornitore o sulla quale, per diverse ragioni, non intende investire. Oppure, in alternativa, accedendo al database operativo dell’applicazione. Operazione facile da compiere se si deve solo leggere dei dati, molto più complessa quando si devono anche aggiungere delle informazioni al database.
Per tutte queste ragioni è molto importante progettare e realizzare un’infostruttura che non sia solo finalizzata allo scambio di informazioni e all’interoperabilità dei sistemi ma che invece costituisca il cuore del sistema informativo ospedaliero (o territoriale), il repository dove siano presenti, in forma strutturata, tutte le informazioni rilevanti per la cura e l’assistenza del paziente.
Le informazioni che il repository gestisce devono essere organizzate non soltanto per episodio ma, in una logica più ampia, per patologia e percorso di cura. L’organizzazione delle informazioni può avvenire o perché il sistema che le produce è in grado di articolarle in questo modo o tramite logiche cliniche in grado, ad esempio, di correlare i dati in funzione della patologia (ad esempio un farmaco o un esame di laboratorio), di un pathway predefinito e così via.
Un repository in questa accezione costituisce lo strumento operativo per eccellenza di medici ed infermieri che vi accedono tramite un portale clinico che implementa una serie di funzioni e logiche che permettono di correlare le informazioni, definire allarmi, impostare workflow, calcolare indicatori e parametri, attraverso viste intelligenti e dinamiche, aggregabili in cruscotti. Rappresenta una sorta di “cartella clinica integrata“.
Questa impostazione offre la possibilità di “alleggerire” le funzionalità dei sistemi di base, ad esempio la cartella clinica elettronica, spostando e concentrando le logiche e le funzioni a livello di portale clinico. La sostituzione di un sistema non richiede la migrazione dei dati, in quanto questi sono presenti nel repository.
Insieme al repository devono essere previsti e vanno a costituire l’infostruttura aziendale l’anagrafica pazienti, l’anagrafica operatori con i relativi permessi di accesso, un sistema di gestione del consenso (indispensabile per regolare gli accessi) e un Data Terminology Server per la gestione delle codifiche.