Tanto testo, pochi dati strutturati, ecco perché con i documenti attuali non è possibile alimentare un repository FHIR.
In attesa di disporre di sistemi informativi sanitari in grado di produrre nativamente risorse FHIR si è pensato di ricorrere a uno stratagemma: ricavare i dati strutturati dai documenti CDA che popolano l’attuale Fascicolo Sanitario Elettronico. Ne abbiamo parlato nel primo articolo di questa serie.
È la prima funzione del gateway ad essere rilasciata che ricalca quanto già sono in grado di fare le più evolute piattaforme di interoperabilità. Queste in verità consentono anche di trasformare in risorse FHIR i messaggi HL7 v2, scelta che sarebbe stata più efficace dal momento che nei segmenti che li compongono sono presenti molti più dati strutturati di quelli che sono attualmente presenti nei CDA.
Il referto di specialistica ambulatoriale
Prendiamo ad esempio il referto di specialistica ambulatoriale, il documento CDA con cui si producono (o per meglio dire si dovrebbero visto che è ancora poco diffuso) tutti i referti ambulatoriali ad eccezione del laboratorio di analisi e della radiologia. Vediamo come è articolato il corpo del documento.
Ci sono molte sezioni, alcune delle quali di grande rilevanza clinica, come ad esempio la storia clinica, le allergie, la diagnosi, gli accertamenti da svolgere e la terapia farmacologica consigliata. Peccato però che siano tutte opzionali. Quando presenti contengono blocchi di testo e, anche se alcune di esse consentono di definire dei dati strutturati, questi non sono obbligatori.
Non va meglio con il Profilo Sanitario Sintetico (poco presente nei FSE), il Verbale di Pronto Soccorso e con la Lettera di Dimissione. Meglio invece il referto di laboratorio che prevede una codifica degli esami LOINC e la presenza di dati strutturati per l’unità di misura e i risultati ma che in molti casi contiene invece un PDF.
Per tutte queste ragioni alimentare un repository FHIR a partire dai documenti attuali è molto difficile se non impossibile. Viene allora da chiedersi perché, malgrado ciò, si stia procedendo su questa strada. È evidente che bisogna lavorare sui sistemi clinici e diagnostici per far sì che questi producano dati strutturati in formato nativo FHIR, operazione certamente lunga, complessa e costosa ma inevitabile se si vuole davvero realizzare un nuovo FSE.
Come spesso accade, le scorciatoie alla prova dei fatti non si rivelano tali e comportano uno spreco di tempo e risorse. Quando si progetta non si può prescindere dalla realtà delle cose, anche se queste non ci piacciono.
Articoli precedenti:
Come opera il gateway del nuovo FSE
Autenticazione del gateway del nuovo FSE
4 – Fine.