La sanità moderna non è più un insieme disconnesso di servizi, ma un ecosistema complesso in cui il flusso di dati tra diversi attori gioca un ruolo chiave. Però, garantire che questi dati siano facilmente accessibili e utilizzabili in maniera sicura ed efficace rappresenta una sfida significativa.
Gli standard come HL7-FHIR e openEHR sono strumenti cruciali per affrontare questa sfida, offrendo la possibilità di scambiare e utilizzare dati sanitari in modo standardizzato. Tuttavia, la loro adozione porta con sé una serie di opportunità e sfide che devono essere attentamente valutate nel contesto nazionale e internazionale.
Il nostro obiettivo è di proporre una serie di considerazioni sulle scelte effettuate a livello nazionale sull’adozione dello standard HL7-FHIR come standard di interoperabilità dei dati nell’ecosistema della sanità.
Partendo dalla definizione di ecosistema, evidenziamo le esigenze informative dell’ecosistema sanitario e le diverse caratteristiche dell’interoperabilità dei dati.
Successivamente descriveremo le differenze sostanziali tra lo standard HL7-FHIR e lo standard openEHR per concludere evidenziando quali le opportunità per una adozione realmente sostenibile di questi standard.
L’ecosistema della sanità: definizione e necessità informative
Un ecosistema digitale si riferisce all’insieme interconnesso di servizi, piattaforme, dispositivi e persone che collaborano e interagiscono tra loro attraverso tecnologie digitali. Questo concetto è ampiamente utilizzato nel contesto dell’informatica e dell’innovazione digitale.
Un ecosistema digitale può comprendere diversi elementi, tra cui:
- Piattaforme digitali: sono i principali motori dell’ecosistema digitale, fornendo le infrastrutture e gli strumenti tecnologici necessari per consentire l’interazione tra diversi attori.
- Applicazioni software: questi sono strumenti digitali specifici che offrono funzionalità particolari, come app mobili, software gestionali, di produttività, sw, ecc.
- Dispositivi digitali personali dei cittadini o dei professionisti: l’insieme di tutti i dispositivi che si connettono al mondo digitale, come smartphone, tablet, computer, dispositivi indossabili, sensori IoT (Internet delle cose), ecc.
- Dati: i dati rappresentano il cuore dell’ecosistema digitale. Possono essere generati da persone, dispositivi o sistemi e vengono utilizzati per gestire e migliorare servizi per gli “utenti”, prendere decisioni e alimentare piattaforme di intelligenza artificiale.
- Persone: l’insieme degli “attori” dell’ecosistema digitale: i professionisti che utilizzano quotidianamente sw e dispositivi digitali e raccolgono dati, gli utenti finali e/o i clienti, gli sviluppatori hw e sw, che di fatto utilizzano, sviluppano e gestiscono le risorse/piattaforme digitali, data analyst che analizzano i dati raccolti nelle varie interazioni tra professionisti e utenti etc, il middle e top management.
- Regolamenti e standard: le normative e gli standard giocano un ruolo importante nell’ecosistema digitale, poiché hanno impatti sulla privacy dei dati, la sicurezza delle transazioni e altri aspetti legali e tecnici.
Appare evidente come sia necessario, al fine del funzionamento di sistema, un pre-requisito che consiste nella necessità che tutti gli attori dell’ecosistema condividano obiettivi, finalità e regole dell’ecosistema digitale stesso.
Nel contesto della sanità, un ecosistema digitale si riferisce all’integrazione di tecnologie digitali, dati, servizi, professionisti, pazienti, stakeholder per migliorare l’accesso ai servizi, la loro efficienza e efficacia, la qualità dell’assistenza sanitaria, i processi di governance e di ricerca clinica in un quadro di sostenibilità complessiva. Questo include una vasta gamma di elementi e attori che interagiscono tra loro per supportare la gestione dei dati clinici, la comunicazione tra operatori sanitari e pazienti, le attività di gestione dei diversi setting assistenziali tra cui prevenzione e population health management, la diagnosi e il trattamento delle malattie ivi compresa la fase di riabilitazione e del fine vita, la gestione delle strutture sanitarie, la governance di sistema, la ricerca clinica e epidemiologica, nel rispetto di regole di gestione e di riuso dei dati, di sicurezza delle transazioni digitali e di privacy, preso atto che i dati sanitari sono dati particolarmente sensibili.
Obiettivi e funzioni dell’ecosistema digitale in sanità
Obiettivo dell’ecosistema digitale in sanità è la raccolta sistemica e sistematica nel tempo dei dati dei cittadini-pazienti per fini primari o secondari. Questa distinzione è fondamentale al fine di chiarire fonti informative, finalità e responsabilità nella raccolta e trattamento dei dati di carattere sanitario. Il Sistema Informativo Sanitario Nazionale rappresenta le modalità attraverso cui le Aziende Sanitarie (pubbliche o private) e altri soggetti erogatori di prestazioni e/o servizi per il SSN nonché i livelli istituzionali sovraordinati, Regioni e Ministeri, e altri Enti di Ricerca si scambiano dati di natura sanitaria. In particolare, le Aziende Sanitarie e altri soggetti erogatori di prestazioni e/o servizi per il SSN.
- raccolgono, gestiscono, elaborano dati a fini di prevenzione, cura, governo clinico, trial clinici e gestione, attività tipiche delle aziende sanitarie
- fanno circolare le informazioni tra i silos organizzativi quando il processo di cura del paziente li attraversa.
- scambiano parte di queste informazioni, mediante specifici flussi, con Organismi sovraordinati (Regione e Ministero della Salute) o altri Enti/strutture di Ricerca (ad es. Istat, Ministero Economia e Finanza, Università…) a fini prevalenti di Ricerca e Governance, attività peculiari di Regioni, Ministeri e istituzioni di Ricerca[1]
I dati per finalità primarie sono quindi i dati clinico-sanitari utilizzati per le attività di presa in carico e cura dei cittadini in senso lato, vale a dire dalle attività di prevenzione e di health population management, alle attività di diagnosi e cura, alla riabilitazione e alla gestione del fine vita. Questi dati sono frequentemente dispersi in «silos» tra loro non comunicanti, in assenza di standard che li rendano realmente “ri-usabili” (interoperabili) e di norma sono dati “in chiaro”. I dati per finalità secondarie sono dati utilizzati per le attività di programmazione e verifica del sistema sanitario, per attività di ricerca clinica e epidemiologica che vengono derivati dai dati primari.
Hanno un contenuto/orientamento prevalentemente amministrativo o statistico (esenzioni, flussi informativi tra ASL e regione/ministero) per finalità prevalenti di governance del sistema. Questi dati sono di norma «pseudo anonimizzati o anonimizzati». Appare evidente che la qualità dei dati presenti nell’ecosistema digitale della sanità dipenderà quindi dalle caratteristiche dei dati prodotti nei processi primari (“garbage-in/garbage-out”). Ogni analisi sulla costruzione di un ecosistema di dati sanitari locale, regionale o nazionale deve quindi considerare alcune precondizioni necessarie per assicurare che i dati prodotti nei processi primari soddisfino “ex ante” adeguati livelli di qualità sintattica e semantica.
Interoperabilità dei dati in ambito sanitario: una panoramica
In tale contesto una prima precondizione è legata al tema della interoperabilità dei dati vale a dire la possibilità che un dato clinico prodotto da una struttura “A” possa essere ri-utilizzato con lo stesso significato sintattico e semantico da una struttura “B”, dove per struttura si può intendere due applicativi diversi della stessa azienda, due unità operativa della stessa azienda, due unità operative di due aziende diverse della stessa Asl o della stessa Regione, due strutture di cui una pubblica e una privata, due strutture diverse di Regioni diverse.
L’interoperabilità può essere sinteticamente descritta come un insieme di regole che garantiscono quattro livelli di comunicazione tra entità diverse (vedi fig. 2): interoperabilità tecnologica, sintattica, semantica e organizzativa. Gli standard openEHR e HL7 FHIR tendono a soddisfare questi quattro livelli, se pur in modo differente.
Fig. 2 caratteristiche dell’interoperabilità in sanità
Lo scenario dell’interoperabilità in sanità deve tener conto di diversi ambiti e esigenze tipiche del mondo sanitario. Da un lato la necessità di poter scambiare dati in modo efficiente sia all’interno della medesima azienda sanitaria ad es. tra dipartimenti diversi (PS e reparti, tra reparti e diagnostiche, tra reparto di accettazione e reparto di dimissione, tra Ospedale per acuti e Ospedale di comunità tramite COT, tra Casa della Comunità e Adi, etc) sia tra strutture sanitarie diverse e di diverse regioni/Nazioni. In questo contesto si utilizzano modelli di scambio dei dati ad es. HL7, CDA-2, gli scenari IHE).
Un secondo tema è legato alla creazione di modelli clinici per la raccolta dei dati in modo tale che gli stessi siano persistenti nel tempo: a livello internazionale si fa riferimento allo standard openEHR. Un terzo tema è legato all’utilizzo di dizionari terminologici clinici internazionali ad es. Loinc, Snomed, ICD IX ecc al fine di rafforzare ulteriormente il significato semantico univoco dei dati trasmessi e condivisi.
Lo standard HL7-FHIR, come sintetizzato in fig. 3, tende a ricomporre in un unico standard, questi tre ambiti consentendo sia un adeguato e sicuro scambio dei dati sia la creazione di un data repository persistente sia il medesimo significato semantico dei dati grazie all’utilizzo obbligatorio di alcuni dizionari terminologici internazionali.
Fig. 3 scenario dell’interoperabilità in sanità
Evoluzione delle architetture per la condivisione dei dati nell’ecosistema sanitario
Nel corso degli anni, nel contesto della sanità italiana, si è assito a una evoluzione delle architetture che supportano il trattamento dei dati e la loro interoperabilità, che potremmo definire in quattro stadi, come descritto in Fig 4:
- Stadio 1: un panorama in gran parte basato sulla carta, con alcuni sistemi di base (dipartimentali stand alone) utilizzati all’interno delle strutture sanitarie. I dati sono generalmente conservati in modo non standardizzato e la condivisione delle informazioni è molto limitata.
- Stadio 2: introduzione di sistemi dipartimentali connessi tra loro prevalentemente tramite API. I dati sono conservati in modo standardizzato all’interno di ciascun sistema dipartimentale, ma la condivisione dei dati tra sistemi è ancora limitata.
- Stadio 3: diffusione di sistemi dipartimentali tra loro integrati tramite un ESB (Enterprise Service Bus) e l’adozione di regole (HL7) per la condivisione dei dati e la costruzione di clinical repository
- Stadio 4: evoluzione dello stadio 3 con creazione di un repository clinico e regole di interoperabilità sintattica e semantica “ex ante” e la integrazione tra repository clinico locale e EDS nazionale/regionale.
Fig. 4 evoluzione delle architetture per la condivisione dei dati in sanità
Il tema, oggi poco approfondito e sui cui le ricerche e/o le evidenze empiriche sono sostanzialmente inesistenti, riguarda quale sia il reale stato di maturità dei sistemi informativi delle strutture sanitarie pubbliche o private, vale a dire a quale stadio di maturità si posizioni oggi la sanità italiana nel suo complesso.
A parere dell’autore la media delle strutture della sanità italiana si pone tra il secondo e il terzo stadio, con una prevalenza del secondo.
Questa considerazione è di particolare importanza nella scelta degli standard di interoperabilità da implementare in quanto, qualsiasi scelta possa essere fatta, deve tener conto della sua reale sostenibilità che, a sua volta, dipende direttamente dal reale stato di maturità dei sistemi informativi delle strutture sanitarie che producono i dati clinici.
OpenEHR e HL7-FHIR a confronto
Lo standard openEHR è stato ideato come standard indipendente dal fornitore per la costruzione di un EHR (Electronic Health Record) persistente nel tempo. Si basa sulla definizione e costruzione di “archetipi” che costituiscono elementi di base per la definizione di un concetto clinico (ad es. pressione sanguigna, parametri vitali…). L’utilizzo di modelli (templates) consente l’aggregazione di archetipi per creare set di dati clinici per casi d’uso specifici. La costruzione di set di dati clinici può avvenire attraverso l’utilizzo di valori terminologici “interni allo standard o mediante adozione di dizionari terminologici “esterni” (ad es. Snomed CT, ICDx e altri)[2]. E’ uno standard fortemente focalizzato sulla costruzione di un modello di dati clinici meno sulla interoperabilità dei dati e la disponibilità di API’s per il mondo degli sviluppatori di piattaforme applicative.
Lo standard HL7-FHIR nasce in continuità con gli standard HL7 v2/3 e CDA al fine di consentire interoperabilità sintattica e semantica dei dati tra sistemi diversi. Si basa sulla definizione e costruzione di “risorse” che vengono aggregate in “profili” che definiscono gli use case. La costruzione dei set di dati clinici avviene attraverso l’utilizzo di dizionari terminologici internazionali (ad es. Snomed CT, ICDx e altri). E’ uno standard fortemente focalizzato alla interoperabilità dei dati, sulla conseguente disponibilità di API’s, pur garantendo interoperabilità semantica (attraverso l’utilizzo di dizionari terminologici clinici internazionali) e un EHR persistente. In fig 5 un sintetico confronto tra i due standard.
| openEHR | HL7-FHIR | |
| Struttura | Archetipi Definiscono elementi di base di un concetto clinico (pressione sanguigna, parametri vitali…) | Risorse Costituiscono elementi base per la costruzione di casi d’uso (condizioni pz, storia familiare, allergie, osservazioni, farmaci…) |
| Modelli Aggregazione di archetipi per creare set di dati clinici e casi d’uso | Profili Aggregazione di risorse per creare casi d’uso specifici | |
| Set di valori terminologici | Classificazione terminologia clinica prevalentemente interna associata a classificazioni internazionali (ad es. Snomed, ICDx…) | Utilizzo classificazioni terminologiche cliniche internazionali (ad es. Snomed, ICDx…) |
| Caratteristica principale | Modellazione e persistenza dei dati pur fornendo un insieme di API’s | Interoperabilità dei dati pur fornendo un proprio modello dati persistente |
| Governance e manutenzione | Libreria di archetipi e modelli clinicamente validati e manutenuti in modo coerente nel tempo dalla community openEHR e gruppi di lavoro con clinici | Sottoposto al processo ANSI standard (fasi:normative,trial-use, draft,informative, deprecated) con comitato di coordinamento internazionale |
Fig. 5 confronto tra openEHR e HL7-FHIR
Alcuni studi comparativi tra i due standard[3],[4] segnalano le seguenti conclusioni:
- Entrambi gli standard sono stati creati per risolvere due diversi problemi: lo scambio di dati clinici tra sistemi di diversi produttori (HL7 FHIR) e per creare un modello di dati indipendente dal fornitore che potesse essere compreso da qualsiasi sistema basato su questo standard (openEHR). Ognuno di essi raggiunge il proprio obiettivo e ciascuno di essi contiene caratteristiche che si sovrappongono a quelle dell’altro standard.
- HL7 FHIR oltre all’interoperabilità definisce un modello di dati persistente che deve essere utilizzato per trasferire informazioni tra sistemi: non è esteso come il modello openEHR, ma è stato creato secondo il principio di Pareto (80/20): la semplicità realizzativa del modello gli consente di descrivere la maggior parte dei casi riscontrati in medicina, prevedendo delle estensioni per i casi d’uso non previsti. Questa elasticità di FHIR può rappresentare una criticità laddove queste estensioni venissero utilizzate con frequenza, trasformando lo standard in più ”dialetti”, cosa in parte già verificatasi nelle precedenti versioni di HL7.
- openEHR ha rappresentato uno sforzo eccezionale per standardizzare la struttura delle informazioni dell’assistenza sanitaria ma sembra che il suo approccio abbia portato a un modello piuttosto complicato da utilizzare con una curva di apprendimento molto ripida. Alcuni studi evidenziano inoltre che l’uso di openEHR in un sistema ICT ospedaliero è associato ad una notevole riduzione dell’efficienza e del throughput rispetto alla soluzione basata su un modello dati proprietario[5] e che la progettazione di applicativi basati su openEHR sia complessa[6].
- Nonostante le differenze nell’approccio, entrambi gli standard supportano l’interoperabilità sintattica e semantica: openEHR cattura un livello di dettaglio eccezionale e adempie al suo mandato di definire la struttura delle cartelle cliniche elettroniche, anche se in modo noioso e complicato. FHIR è leggero e agile, ha un migliore supporto terminologico, è più facile da apprendere, manutenere e implementare rapidamente sia come interfaccia per l’aggregazione, lo scambio e il riutilizzo dei dati, sia come EHR autonomo.
- In teoria, entrambi i sistemi sono complementari e si potrebbe immaginare di utilizzare i dati archiviati in openEHR e renderli interoperabili tramite HL7-FHIR. In realtà questo sarebbe un compito difficoltoso a causa delle capacità di modellazione dei dati molto più ampia in openEHR. Viceversa potrebbe essere più semplice utilizzare il tool FHIR Transform Engine (FTE) per trasformare dati del modello FHIR da e verso qualsiasi altro formato di dati sanitari, precisando che FTE di FHIR dispone di un supporto specializzato verso openEHR.
Al momento sono in corso, parallelamente, in diversi Paesi, alcune iniziative di carattere nazionale che tendono ad evidenziare come l’organizzazione esistente (stato di maturità digitale della sanità) e le dimensioni dei Paesi influenzano le scelte in merito alla scelte di standardizzazione. Da un lato, Paesi con reti e architetture sanitarie molto eterogenee puntano all’adozione di standard che consentano la condivisione di documenti informativi e dati “estratti” dalle cartelle cliniche elettroniche e da altra documentazione clinica. È il caso della Spagna con ISO 13606[7] o degli Stati Uniti con HL7 CDA[8] o dell’Italia con HL7 FHIR. Diverso il caso ad es. della Norvegia che si sta dirigendo verso l’adozione di un’architettura informativa delle cartelle cliniche elettroniche a livello nazionale con openEHR. Tre fattori hanno influenzato questa direzione di lavoro. Il primo è l’omogeneità del mercato poiché un solo fornitore rappresenta l’80% della quota di mercato dei software di cartella clinica elettronica per l’assistenza ospedaliera. Il secondo è la stretta collaborazione tra vendor e autorità sanitarie: ciò ha consentito di coordinare la definizione ex ante dell’intero modello informativo dei nuovi sistemi applicativi. Il terzo, e più determinante, è il corpo di conoscenze già disponibili che ha alimentato la pipeline di definizione dei protocolli di cura nazionali con gli archetipi esistenti in openEHR.[9]
La situazione italiana in merito al trattamento dei dati sanitari
Andando oltre ai dibattitti teorici su quale sia lo standard migliore per trattare i dati clinici credo sia opportuno ragionare invece su quale sia lo standard che meglio si adatta alla situazione italiana, che sia realmente sostenibile e che consenta una reale interoperabilità a livello trans-regionale (EDS Ecosistema Dati Sanitari Nazionale) e trans-frontaliero (EHDS Electronic Health Data Space) utilizzando in modo efficace (raggiungere concretamente l’obiettivo) e efficiente (spendendo in modo adeguato) i finanziamenti messi a disposizione dal Pnrr.
La situazione italiana in merito al trattamento dei dati sanitari sembra essere caratterizzata da tre livelli di maturità:
Livello di maturità dei professionisti
Le componenti professionali cliniche (team professionali) non sempre sono “educate” ad utilizzare dizionari terminologici internazionali e non sono abituate a codificare e classificare la propria attività clinica. Qualsiasi standard dovesse essere adottato ha come pre-requisto l’adozione obbligatoria di terminologie semantiche comuni. Ciò significa che ad es. un referto di una visita specialistica o una anamnesi o un esame obiettivo che oggi contengono sostanzialmente “testo” dovranno essere prodotti sia in formato testuale sia con dati strutturati. In Fig 6 un esempio. Appare evidente che ciò comporterà adeguati processi di change mangement e percorsi formativi per le componenti professionali senza i quali parlare di interoperabilità semantica in sanità resta un puro esercizio di estetica tecnologica
Livello di maturità del mercato ICT della sanità italiana
Consentire ai clinici di non perdere tempo nella attività di classificazione della loro attività che distrarrebbe tempo dai processi di cura significa prevedere necessariamente, e nel medesimo tempo, il re-engineering dei sw applicativi utilizzati in sanità. In proposito si segnala che nessun applicativo oggi presente nel mercato ICT sanitario italiano (ad eccezione dei sw di Anatomia Patologica) consente l’utilizzo di Snomed-CT
che rappresenta il dizionario terminologico clinico che, ai sensi del Decreto di attuazione del FSE 2.0, dovrebbe essere utilizzato per qualsiasi registrazione clinica. Ancora più desolante ipotizzare un utilizzo di openEHR come repository clinico dato che da un lato moltissime strutture sanitarie non dispongono ancora di un repository e dall’altro che nessun fornitore ICT del mercato italiano dispone di realizzazioni di questo tipo.
Livello di maturità delle strutture sanitarie
Non può esistere alcun interscambio/interoperabilità di dati sociosanitari di qualità elevata senza che le Aziende Sanitarie produttrici dei dati primari (pubbliche o private) siano dotate di un adeguato sistema informativo aziendale, che, per la parte clinica, si sostanzia nella creazione di un repository clinico. Ciò significa che le Aziende Sanitarie dovrebbero essere incentivate, anche con l’utilizzo dei fondi Pnrr, all’adozione di un modello di sistema informativo aziendale nel quale l’interoperabilità semantica dei dati nell’area sanitaria del modello è garantita “ex ante” come elemento di qualificazione e creazione del repository clinico che ciascuna azienda sanitaria, dovrebbe possedere.
Fig 6. Esempio di nuova registrazione clinica con dati testuali e dati strutturati
Nel loro libro “Fundamentals of Software Architecture” Mark Richards e Neal Ford [10]definiscono la prima legge dell’architettura software come segue: “la prima legge dell’architettura software è che tutto è un compromesso”.
Partendo dai livelli di maturità della sanità italiana sopra elencati, appare necessario pensare a un processo graduale nel tempo che però consenta oggettivamente e rapidamente un miglioramento dello scenario degli EHR delle strutture sanitarie e dell’interoperabilità.
Conclusioni
In questo contesto lo standard HL7-FHIR, è stato individuato sia come lo standard obbligatorio per la costruzione del nuovo FSE 2.0,[11] sia come lo standard di riferimento previsto per la costruzione dell’European Health Data Space[12], [13] probabilmente in ragione alla sua semplicità e facilità di implementazione nonché a una curva di apprendimento meno impegnativa sia per i team clinici sia per i team degli sviluppatori.
Può non rappresentare il meglio assoluto in merito ad una presunta completezza del modello dati ma, stante le condizioni della sanità italiana sopra descritte, consentirebbe di poter disporre di dati clinici di qualità sia per usi primari (processi di cura) sia per usi secondari (governance e ricerca) in tempi ragionevolmente brevi (e i test sull’adozione del gateway FHIR per trasferire i dati dalle strutture sanitarie all’EDS lo confermano). Un salto quantico per la sanità italiana.
Note
- Consiglio Superiore Sanità, Documento Gruppo di Lavoro per la “Riforma del Sistema Informavo Sanitario e Sanità Digitale”, Marzo 2022 ↑
- Lo standard openEHR consente di precisare esattamente i due diversi set terminologici (interni o esterni): ad es.
- local::at0007::Gonfiore dentale
- SNOMED-CT:: 162007004::Gonfiore dentale
- Jacek Kryszyn, Waldemar T. Smolik, Damian Wanta, Mateusz Midura and Przemysław Wroblewski, Comparison of openEHR and HL7 FHIR Standards, Journal of Electronics And Telecommunications, 2023, VOL. 69, NO. 1, PP. 47–52 ↑
- Eneimi Allwell-Brown, A Comparative Analysis of HL7 FHIR and openEHR for Electronic Aggregation, Exchange and Reuse of Patient Data in Acute Care, Karolinska Istitutet, 2016 ↑
- J. Kryszyn, K. Cywoniuk, W. T. Smolik, D. Wanta, P. Wro ́blewski, and M. Midura, Performance of an openEHR based hospital information system, International Journal of Medical Informatics, vol. 162, p. 104757, 6 2022. ↑
- Koray Atalag, Hong Yul Yang, Ewan Tempero, James R. Warren, Evaluation of software maintainability with openEHR – a comparison of architectures, International Journal of Medical Informatics,Volume 83, Issue 11, November 2014, Pages 849-859 ↑
- J. E. Huerta, C. A. Villar, M. C. Fernández, G. M. Cuenca, and I. A. Acebedo, “Nhs Electronic Health Record,” Ministerio de Sanidad y Politica Social, 2014 ↑
- Health Level Seven. Hl7 Standards Product Brief – Cda® Release 2. Marzo 2015 ↑
- Rune Pedersen, Conceição Granja, Luis Marco Ruiz, Implementation of openEHR in Combination with Clinical Terminologies: Experiences from Norway, International Journal on Advances in Life Sciences, vol 9 no 3 & 4, 2017 ↑
- Mark Richards e Neal Ford, Fundamentals of Software Architecture: An Engineering Approach, O’Reilly Media, 2020 ↑
- Linee Guida per l’attuazione del FSE, DM 20.5.2022. GU 160, 11.7.2022 ↑
- AA.VV. Hospitals on FHIR: Preparing Hospitals for European Health Data Space, HealthManagement, Volume 22 – Issue3, 2022 ↑
- Regolamento del Parlamento e del Consiglio Europeo sullo Spazio Europeo dei Dati Sanitari, COM(2022) 197 final 2022/0140 (COD) che fa esplicito riferimento alle Commission Recommendation of 6.2.2019 on a European Electronic Health Record eXchange Format EEHRXF, C(2019) 800 final, nelle quali si identifica HL7-FHIR come standard di interoperabilità dei dati sanitari a livello europeo. ↑
