Risposta breve: un ospedale gestisce decine di sistemi e l'integrazione è il lavoro di farli concordare su un singolo paziente. Al centro si trova il sistema informativo ospedaliero (HIS) o cartella clinica elettronica (EHR), che gestisce l'identità del paziente, i ricoveri e la cartella clinica. Attorno ad esso: il sistema di laboratorio (LIS), la radiologia (RIS e PACS), la farmacia, la sala operatoria, il pronto soccorso, la fatturazione, i dispositivi (monitor, pompe per infusione) e sempre più app per pazienti, dispositivi indossabili e telemedicina. Un motore di interfaccia intermedio riceve, trasforma e instrada i messaggi, in modo che ogni sistema sia connesso una sola volta anziché a tutti gli altri. Il traffico è principalmente costituito da messaggi HL7 v2 su MLLP per eventi (ricoveri, ordini, risultati), DICOM per immagini, CDA o PDF per documenti e FHIR su REST per tutto ciò che è nuovo, rivolto al paziente o esterno.
I sistemi e ciò che scambiano
Il panorama di integrazione di un ospedale è composto dall'HIS o EHR, che gestisce l'identità del paziente, gli accessi e la cartella clinica, oltre al sistema di laboratorio, alla radiologia (RIS e PACS), alla farmacia, ai dispositivi, alle app per pazienti, alla telemedicina e ai sistemi regionali. Questi scambiano messaggi HL7 v2 come ADT, ordini e risultati ORU, immagini DICOM, documenti CDA e risorse FHIR.
| Sistema | Gestisce | Invia | Riceve |
|---|---|---|---|
| HIS / EHR | Identità del paziente, ricoveri, ordini, la cartella clinica | ADT (ricoveri, trasferimenti), ordini ORM/OML, pianificazione SIU | Risultati ORU, documenti MDM, addebiti DFT |
| LIS (laboratorio) | Campioni, analisi, risultati, intervalli di riferimento | Risultati ORU^R01, risposte agli ordini ORR | Ordini ORM/OML, ADT per dati demografici |
| RIS / PACS | Ordini di imaging, liste di lavoro, referti, immagini | Referti ORU, DICOM ai visualizzatori, SIU | Ordini ORM/OMI, ADT; DICOM MWL alle modalità |
| Farmacia | Formulario, dispensazione, scorte | Dispensazione RDS, somministrazione RAS | Ordini di farmaci OMP/RDE, ADT |
| Dispositivi e monitor | Segni vitali, forme d'onda, allarmi | Osservazioni ORU^R01 (IHE PCD), proprietari | ADT per contesto paziente |
| Portale paziente / app | Dati inseriti dal paziente, accesso | Osservazioni FHIR, questionari, messaggi | Lettura FHIR di risultati, appuntamenti, documenti |
| Telemedicina | Visite video, monitoraggio remoto | Incontro FHIR, Osservazione, DocumentReference | Appuntamento, contesto paziente, avvio SMART |
| Sistemi regionali e nazionali | Cartelle condivise, registri, prescrizione elettronica | Documenti CDA (XDS), FHIR, messaggi nazionali | Query, notifiche |
Il motore di interfaccia
Un motore di interfaccia è il centro di messaggistica dell'ospedale: riceve traffico HL7 v2, FHIR, file e database da ogni sistema, lo trasforma e lo instrada a tutti gli altri sistemi che ne hanno bisogno, e gestisce code, tentativi, monitoraggio e audit. Senza di esso, N sistemi richiedono fino a N×(N−1)/2 interfacce costruite manualmente; con uno, ogni sistema si connette una sola volta.
Il motore (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare e IRIS for Health, Infor Cloverleaf, Qvera QIE, tra gli altri) fornisce listener (MLLP, HTTP, file, database), trasformazioni (mappa campi, correggi codici, converti v2 in FHIR), routing (invia un ADT a otto sistemi con otto filtri), coda e tentativi, monitoraggio e audit. È anche il luogo in cui viene riconciliata l'identità del paziente quando i sistemi non concordano, e dove spesso viene creato un facciata FHIR sopra un database legacy. Vedi Motori di interfaccia spiegati.
I flussi che contano di più
I flussi di integrazione ospedaliera più importanti sono ADT (ammissioni, dimissioni, trasferimenti e aggiornamenti demografici distribuiti dall'HIS), ordini e risultati tra l'EHR e il laboratorio o la radiologia, ordini e dispensazione di farmaci, documenti come lettere di dimissione, dati dai dispositivi di monitoraggio e scambio di risultati, appuntamenti e misurazioni domiciliari rivolti al paziente tramite FHIR.
- ADT: ogni ricovero, dimissione, trasferimento, registrazione e aggiornamento demografico (A01, A03, A02, A04, A08, A40 merge) si propaga dall'HIS a tutti gli altri. Se l'ADT è in ritardo o errato, ogni sistema a valle archivia i dati sotto il paziente o il ricovero sbagliato. Vedi Messaggi HL7 v2 spiegati.
- Ordini e risultati: ORM/OML in uscita, ORU in rientro, con numeri di placca e riempitore che li collegano; LOINC e UCUM nei risultati. Vedi Messaggi di ordine HL7 v2 e Integrazione di un sistema di laboratorio con un EHR.
- Imaging: ordini al RIS, liste di lavoro DICOM agli scanner, immagini ai PACS, referti come ORU, visualizzatori tramite DICOMweb. Vedi PACS vs RIS vs VNA.
- Farmaci: ordini alla farmacia, dispensazione e somministrazione in rientro, con il ciclo chiuso (codice a barre al capezzale) come obiettivo di sicurezza.
- Documenti: lettere di dimissione, note operative e documenti scansionati come messaggi MDM, CDA o PDF in un repository di documenti, pubblicati nei registri regionali.
- Dispositivi: monitor che alimentano i segni vitali nella cartella tramite profili IHE PCD o gateway del fornitore, con la gestione degli allarmi come disciplina separata.
- Rivolto al paziente: risultati, appuntamenti e documenti al portale e alle app tramite FHIR; questionari, misurazioni domestiche e dati dei dispositivi indossabili in rientro, con la provenienza che li contrassegna come segnalati dal paziente. Vedi Monitoraggio remoto del paziente con FHIR.
Modelli che funzionano
I modelli di integrazione ospedaliera che funzionano sono: un sistema master per l'identità del paziente, con tutti gli altri che si iscrivono agli ADT; mappatura dei codici a LOINC, SNOMED CT e ATC una sola volta al motore; conferme, code e tentativi per ogni messaggio; risultati e documenti idempotenti; uno strato FHIR per le app dei pazienti e i partner esterni; e ambienti di test con pazienti sintetici prima del go-live.
- Un unico master per l'identità. L'HIS (o un indice master del paziente) possiede gli identificatori; tutti gli altri si iscrivono all'ADT e non creano mai pazienti.
- Codici al confine. Mappa i codici locali a LOINC, SNOMED CT, ATC al motore, una volta, e mantieni il codice locale accanto.
- Conferma, accoda, ritenta. Ogni messaggio v2 riceve un ACK; il motore persiste e riprova; nessuno perde un risultato perché un sistema si è riavviato.
- Idempotenza. Risultati e documenti portano identificatori; una rielaborazione aggiorna anziché duplicare.
- Uno strato FHIR per tutto ciò che è nuovo. App per pazienti, telemedicina, estratti per la ricerca e partner esterni comunicano in FHIR con una facciata o un server FHIR dedicato alimentato dai flussi interni, anziché direttamente con l'HIS.
- Ambienti di test con pazienti sintetici, e una fase di conformità (profili IHE Connectathon, suite di test nazionali) prima che qualsiasi cosa tocchi la produzione.
Modalità di fallimento riscontrate ovunque
Le modalità di fallimento riscontrate in quasi tutte le integrazioni ospedaliere sono pazienti duplicati dovuti a errori di battitura nella registrazione, risultati archiviati nell'accesso errato dopo un merge, codici locali non mappati, errori di fuso orario e ora legale nei timestamp, unità di testo libero, interfacce che si interrompono silenziosamente senza monitoraggio, segmenti Z dei fornitori che rompono i parser e feed CSV temporanei che non vengono mai dismessi.
Pazienti duplicati da errori di battitura nella registrazione; risultati archiviati nel ricovero sbagliato dopo una fusione; codici di test locali non mappati; fusi orari e ora legale nei timestamp dei messaggi; unità di misura in testo libero; un'interfaccia che si è silenziosamente interrotta e nessuno l'ha monitorata; segmenti Z specifici del fornitore che rompono i parser; e il feed CSV "temporaneo" ancora attivo dopo dieci anni.
Dove FHIR sta cambiando il quadro
FHIR sta cambiando l'integrazione ospedaliera ai margini piuttosto che al centro. All'interno dell'edificio, HL7 v2 e DICOM rimangono perché analizzatori, scanner e moduli legacy li utilizzano; FHIR prende il sopravvento sull'accesso del paziente, sulle app SMART on FHIR, sul supporto decisionale CDS Hooks, sulle Sottoscrizioni, sullo scambio regionale e nazionale sotto EHDS e TEFCA, e sugli estratti per la ricerca.
Internamente, HL7 v2 e DICOM rimangono per anni, perché ogni analizzatore, scanner e modulo legacy li utilizza. FHIR vince ai margini: accesso del paziente, app avviate all'interno dell'EHR (SMART on FHIR), supporto decisionale (CDS Hooks), sottoscrizioni per integrazione basata su eventi, scambio regionale e nazionale sotto l'EHDS e TEFCA, ed estratti per la ricerca. Molti ospedali ora gestiscono un server FHIR alimentato dal motore come strato di integrazione per tutto ciò che è esterno all'edificio; vedi Standard di interoperabilità sanitaria: la mappa.
In Anpheros
Anpheros Platform si posiziona al margine FHIR dell'integrazione ospedaliera: una cartella FHIR R4 a cui un ospedale o una clinica possono scrivere e leggere con il consenso del paziente, alimentata dall'integrazione dell'ospedale tramite il connettore di laboratorio (HL7 v2 ORU, CSV o JSON), con webhook e provenienza per ogni sorgente. Non sostituisce l'HIS o il motore.
Anpheros Platform si trova a questo margine: un record FHIR R4 su cui un ospedale o una clinica può scrivere e leggere con il consenso del paziente, alimentato dall'integrazione dell'ospedale stesso (il connettore di laboratorio accetta HL7 v2 ORU, CSV o JSON), con webhook per la notifica dei cambiamenti e la provenienza per origine. Non sostituisce l'HIS o il motore; fornisce al paziente una cartella che lo segue fuori dall'edificio.
Pagine correlate
- Motori di interfaccia spiegati
- Come integrare un sistema di laboratorio con un EHR
- Messaggi HL7 v2 spiegati: ADT e ORU
- PACS vs RIS vs VNA
- Monitoraggio remoto del paziente con FHIR
- Standard di interoperabilità sanitaria: la mappa
- Integrare sistemi clinici con FHIR (sito per sviluppatori)
Fonti
- Suite di prodotti HL7 Version 2
- Framework tecnico IHE IT Infrastructure
- Dominio IHE Devices (profili Patient Care Device)
- HL7 FHIR R4: Messaging and workflow
- Guida all'implementazione da HL7 v2 a FHIR
Domande frequenti
Un nuovo ospedale dovrebbe integrare tutto con FHIR?
Non tutto. Analizzatori, scanner e la maggior parte dei sistemi dipartimentali utilizzano HL7 v2 e DICOM, e questo non cambierà presto. Utilizza FHIR per le integrazioni rivolte al paziente, esterne e nuove, e un motore per fare da ponte.
Qual è la differenza tra HIS ed EHR?
L'uso varia a seconda del paese. HIS spesso indica insieme il sistema amministrativo e clinico ospedaliero; EHR enfatizza la cartella clinica. In termini di integrazione, entrambi sono il sistema che possiede l'identità, i ricoveri e la cartella.
Quante interfacce ha un ospedale di medie dimensioni?
Tipicamente tra cinquanta e qualche centinaio di flussi di messaggi passano attraverso il motore, contando ogni direzione e ogni sistema ricevente. Lo schermo di monitoraggio del motore è dove vivono i team di integrazione.
Chi gestisce l'integrazione in un ospedale?
Il team IT di integrazione dell'ospedale, solitamente con il supporto del fornitore del motore, e ogni fornitore dipartimentale per la sua parte. I programmi nazionali e i profili IHE riducono ma non eliminano il lavoro di progetto.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →