Răspuns scurt: un spital rulează zeci de sisteme, iar integrarea este munca de a le face să cadă de acord asupra unui pacient. În centru se află HIS (sistemul informațional al spitalului) sau EHR, care deține identitatea pacientului, internările și fișa clinică. În jurul său: sistemul de laborator (LIS), radiologie (RIS și PACS), farmacie, sală de operație, urgențe, facturare, dispozitive (monitoare, pompe de perfuzie) și, din ce în ce mai mult, aplicații pentru pacienți, dispozitive purtabile și telemedicină. Un motor de interfață în mijloc primește, transformă și direcționează mesaje, astfel încât fiecare sistem să fie conectat o singură dată, în loc să fie conectat la toate celelalte. Traficul este în mare parte mesaje HL7 v2 peste MLLP pentru evenimente (internări, comenzi, rezultate), DICOM pentru imagini, CDA sau PDF pentru documente și FHIR peste REST pentru orice este nou, orientat către pacient sau extern.
Sistemele și ce schimbă între ele
Peisajul de integrare al unui spital este compus din HIS sau EHR, care deține identitatea pacientului, internările și istoricul medical, plus sistemul de laborator, radiologie (RIS și PACS), farmacie, dispozitive, aplicații pentru pacienți, telemedicină și sisteme regionale. Acestea schimbă mesaje HL7 v2 precum ADT, comenzi și rezultate ORU, imagini DICOM, documente CDA și resurse FHIR.
| Sistem | Deține | Trimite | Primește |
|---|---|---|---|
| HIS / EHR | Identitatea pacientului, episoade, comenzi, fișa clinică | ADT (internări, transferuri), comenzi ORM/OML, programări SIU | Rezultate ORU, documente MDM, înregistrări DFT |
| LIS (laborator) | Specimene, analize, rezultate, intervale de referință | Rezultate ORU^R01, răspunsuri la comenzi ORR | Comenzi ORM/OML, ADT pentru demografie |
| RIS / PACS | Comenzi imagistică, liste de lucru, rapoarte, imagini | Rapoarte ORU, DICOM către vizualizatoare, SIU | Comenzi ORM/OMI, ADT; DICOM MWL către modalități |
| Farmacie | Formular, eliberare, stoc | RDS eliberare, RAS administrare | Comenzi medicamente OMP/RDE, ADT |
| Dispozitive și monitoare | Semne vitale, forme de undă, alarme | Observații ORU^R01 (IHE PCD), proprietare | ADT pentru context pacient |
| Portal pacient / aplicații | Date introduse de pacient, acces | Observații FHIR, chestionare, mesaje | Citire FHIR a rezultatelor, programări, documente |
| Telemedicină | Vizite video, monitorizare la distanță | Episod FHIR, Observație, DocumentReference | Programare, context pacient, lansare SMART |
| Sisteme regionale și naționale | Fișe partajate, registre, prescripție electronică | Documente CDA (XDS), FHIR, mesaje naționale | Interogări, notificări |
Motorul de interfață
Un motor de interfață este centrul de mesagerie al spitalului: primește trafic HL7 v2, FHIR, fișiere și baze de date de la fiecare sistem, le transformă și le direcționează către orice alt sistem care are nevoie de ele, și gestionează cozile, reîncercările, monitorizarea și auditul. Fără unul, N sisteme necesită până la N×(N−1)/2 interfețe construite manual; cu unul, fiecare sistem se conectează o singură dată.
Motorul (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare și IRIS for Health, Infor Cloverleaf, Qvera QIE, printre altele) oferă ascultători (MLLP, HTTP, fișiere, baze de date), transformări (mapare câmpuri, corectare coduri, conversie v2 în FHIR), rutare (trimiterea unui ADT către opt sisteme cu opt filtre), cozi și reîncercări, monitorizare și audit. Este, de asemenea, locul unde identitatea pacientului este reconciliată atunci când sistemele nu sunt de acord și unde o fațadă FHIR este adesea construită peste o bază de date existentă. Vezi Motoare de interfață explicate.
Fluxurile care contează cel mai mult
Fluxurile de integrare ale spitalului care contează cel mai mult sunt ADT (admiteri, externări, transferuri și actualizări demografice transmise de la HIS), comenzi și rezultate între EHR și laborator sau radiologie, comenzi de medicamente și eliberare, documente precum scrisori de externare, date de la dispozitive de monitorizare și schimbul de rezultate, programări și măsurători la domiciliu cu pacienții prin FHIR.
- ADT: fiecare internare, externare, transfer, înregistrare și actualizare demografică (A01, A03, A02, A04, A08, A40 fuzionare) se propagă de la HIS către toți ceilalți. Dacă ADT este întârziat sau greșit, fiecare sistem din aval înregistrează date sub pacientul sau episodul greșit. Vezi Mesaje HL7 v2 explicate.
- Comenzi și rezultate: ORM/OML ieșire, ORU retur, cu numere de plasator și completator care le leagă; LOINC și UCUM în rezultate. Vezi Mesaje de comandă HL7 v2 și Integrarea unui sistem de laborator cu un EHR.
- Imagistică: comenzi către RIS, liste de lucru DICOM către scanere, imagini către PACS, rapoarte înapoi ca ORU, vizualizatoare prin DICOMweb. Vezi PACS vs RIS vs VNA.
- Medicație: comenzi către farmacie, eliberare și administrare înapoi, cu bucla închisă (cod de bare la pat) ca obiectiv de siguranță.
- Documente: scrisori de externare, note operatorii și documente scanate ca mesaje MDM, CDA sau PDF într-un depozit de documente, publicate în registre regionale.
- Dispozitive: monitoare care alimentează semne vitale în fișă prin profiluri IHE PCD sau gateway-uri de la furnizori, cu managementul alarmelor ca disciplină separată.
- Orientat către pacient: rezultate, programări și documente către portal și aplicații prin FHIR; chestionare, măsurători la domiciliu și date de la dispozitive purtabile înapoi, cu proveniență care le marchează ca fiind raportate de pacient. Vezi Monitorizarea la distanță a pacienților cu FHIR.
Modele care funcționează
Modelele de integrare spitalicească care funcționează sunt: un sistem master pentru identitatea pacientului, cu toți ceilalți abonați la ADT; maparea codurilor către LOINC, SNOMED CT și ATC o singură dată la motor; confirmări, cozi și reîncercări pentru fiecare mesaj; rezultate și documente idempotente; un strat FHIR pentru aplicațiile pacienților și partenerii externi; și medii de testare cu pacienți sintetici înainte de lansare.
- Un singur maestru pentru identitate. HIS (sau un index principal al pacienților) deține identificatorii; toți ceilalți se abonează la ADT și nu inventează niciodată pacienți.
- Coduri la graniță. Mapează codurile locale la LOINC, SNOMED CT, ATC la motor, o singură dată, și păstrează codul local alături.
- Confirmare, coadă, reîncercare. Fiecare mesaj v2 primește un ACK; motorul persistă și redă; nimeni nu pierde un rezultat pentru că un sistem a fost repornit.
- Idempotență. Rezultatele și documentele poartă identificatori; o redare actualizează în loc să dubleze.
- O stratificare FHIR pentru tot ce este nou. Aplicațiile pentru pacienți, telemedicina, extrasele de cercetare și partenerii externi vorbesc FHIR cu o fațadă sau un server FHIR dedicat alimentat din fluxurile interne, în loc să vorbească direct cu HIS.
- Medii de testare cu pacienți sintetici și o etapă de conformitate (profiluri IHE Connectathon, suite de testare naționale) înainte ca orice să ajungă în producție.
Moduri de eșec întâlnite peste tot
Modurile de eșec întâlnite în aproape fiecare integrare spitalicească sunt pacienți duplicat din cauza greșelilor de tastare la înregistrare, rezultate atribuite unei internări greșite după o fuziune, coduri locale nemapate, erori de fus orar și economisire de vară în marcajele temporale, unități în text liber, interfețe care se opresc silențios fără monitorizare, segmente Z ale furnizorilor care defectează parserele și fluxuri CSV temporare care nu sunt niciodată retrase.
Pacienți duplicați din greșeli de scriere la înregistrare; rezultate înregistrate la episodul greșit după o fuzionare; coduri de test locale pe care nimeni nu le-a mapat; fusuri orare și ora de vară în marcajele temporale ale mesajelor; unități în text liber; o interfață care s-a oprit silențios și nimeni nu a monitorizat-o; segmente Z specifice furnizorului care strică parserele; și fluxul CSV "temporar" care rulează încă zece ani mai târziu.
Unde FHIR schimbă imaginea
FHIR schimbă integrarea spitalicească la margini, mai degrabă decât în nucleu. În interiorul clădirii, HL7 v2 și DICOM rămân, deoarece analizoarele, scanerele și modulele vechi le folosesc; FHIR preia accesul pacienților, aplicațiile SMART on FHIR, suportul decizional CDS Hooks, abonamentele, schimbul regional și național sub egida EHDS și TEFCA, și extragerile pentru cercetare.
Intern, HL7 v2 și DICOM rămân ani de zile, deoarece fiecare analizor, scaner și modul existent le vorbește. FHIR câștigă la margini: accesul pacienților, aplicații lansate în interiorul EHR (SMART on FHIR), suport decizional (CDS Hooks), abonări pentru integrare bazată pe evenimente, schimb regional și național sub EHDS și TEFCA, și extrase de cercetare. Multe spitale rulează acum un server FHIR alimentat de motor ca strat de integrare pentru tot ce este în afara clădirii; vezi Standarde de interoperabilitate în sănătate: harta.
În Anpheros
Platforma Anpheros se află la marginea FHIR a integrării spitalicești: un fișier FHIR R4 la care un spital sau o clinică se poate scrie și din care poate citi cu consimțământul pacientului, alimentat de integrarea proprie a spitalului prin conectorul de laborator (HL7 v2 ORU, CSV sau JSON), cu webhooks și proveniență per sursă. Nu înlocuiește HIS-ul sau motorul.
Anpheros Platform se află la acea margine: o înregistrare FHIR R4 în care un spital sau o clinică poate scrie și citi cu consimțământul pacientului, alimentată de integrarea proprie a spitalului ( conectorul de laborator preia HL7 v2 ORU, CSV sau JSON), cu webhook-uri pentru notificarea modificărilor și proveniență per sursă. Nu înlocuiește HIS sau motorul; oferă pacientului o fișă care îl însoțește în afara clădirii.
Pagini înrudite
- Motoare de interfață explicate
- Cum să integrezi un sistem de laborator cu un EHR
- Mesaje HL7 v2 explicate: ADT și ORU
- PACS vs RIS vs VNA
- Monitorizarea la distanță a pacienților cu FHIR
- Standarde de interoperabilitate în sănătate: harta
- Integrarea sistemelor clinice cu FHIR (site pentru dezvoltatori)
Surse
- Suita de produse HL7 Version 2
- Cadrul tehnic IHE IT Infrastructure
- Domeniul IHE Devices (profiluri Patient Care Device)
- HL7 FHIR R4: Messaging and workflow
- Ghid de implementare HL7 v2-to-FHIR
Întrebări frecvente
Ar trebui un spital nou să integreze totul cu FHIR?
Nu totul. Analizoarele, scanerele și majoritatea sistemelor departamentale vorbesc HL7 v2 și DICOM, iar acest lucru nu se va schimba curând. Folosiți FHIR pentru integrări orientate către pacient, externe și noi, și un motor pentru a face legătura.
Care este diferența dintre un HIS și un EHR?
Utilizarea variază în funcție de țară. HIS se referă adesea la sistemul administrativ și clinic al spitalului împreună; EHR pune accent pe fișa clinică. În termeni de integrare, ambele sunt sistemul care deține identitatea, episoadele și fișa.
Câte interfețe are un spital de dimensiuni medii?
În mod tipic, între cincizeci și câteva sute de fluxuri de mesaje trec prin motor, numărând fiecare direcție și fiecare sistem receptor. Ecranul de monitorizare al motorului este locul unde trăiesc echipele de integrare.
Cine deține integrarea într-un spital?
Echipa de integrare IT a spitalului, de obicei cu suportul furnizorului motorului, și fiecare furnizor departamental pentru partea sa. Programele naționale și profilurile IHE reduc, dar nu elimină munca de proiect.
Încearcă gratuit în sandbox
Primul apel FHIR în 5 minute. Un API HL7 FHIR R4 cu consimțământul pacientului integrat: încearcă-l în sandbox, apoi conectează-ți propria aplicație sau sistemul clinicii.
Gratuit · 30 de pacienți sintetici · fără card
Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.
Despre Anpheros →