Kısa cevap: Bir hastane onlarca sistem çalıştırır ve entegrasyon, bu sistemlerin tek bir hasta hakkında anlaşmasını sağlamaktır. Merkezde, hastanın kimliğini, kabulünü ve klinik kaydını barındıran HIS (hastane bilgi sistemi) veya EHR bulunur. Etrafında: laboratuvar sistemi (LIS), radyoloji (RIS ve PACS), eczane, ameliyathane, acil servis, faturalandırma, cihazlar (monitörler, infüzyon pompaları) ve giderek artan şekilde hasta uygulamaları, giyilebilir cihazlar ve teletıp yer alır. Ortadaki bir arayüz motoru, mesajları alır, dönüştürür ve yönlendirir, böylece her sistem diğer her sisteme değil, yalnızca bir kez bağlanır. Trafik çoğunlukla olaylar (kabul, siparişler, sonuçlar) için MLLP üzerinden HL7 v2 mesajları, görüntüler için DICOM, belgeler için CDA veya PDF ve yeni, hasta odaklı veya harici her şey için REST üzerinden FHIR'dir.
Sistemler ve ne alışverişi yaparlar
Bir hastanenin entegrasyon yapısı, hasta kimliğini, ziyaretleri ve klinik kaydı yöneten HIS veya EHR'yi; ayrıca laboratuvar sistemini, radyolojiyi (RIS ve PACS), eczaneyi, cihazları, hasta uygulamalarını, tele-tıp ve bölgesel sistemleri içerir. Bu sistemler ADT, siparişler ve ORU sonuçları gibi HL7 v2 mesajları, DICOM görüntüleri, CDA belgeleri ve FHIR kaynakları alışverişi yaparlar.
| Sistem | Sahip Olduğu | Gönderir | Alır |
|---|---|---|---|
| HIS / EHR | Hasta kimliği, karşılaşmalar, siparişler, klinik kayıt | ADT (kabul, transferler), ORM/OML siparişleri, SIU planlama | ORU sonuçları, MDM belgeleri, DFT ücretleri |
| LIS (laboratuvar) | Numuneler, analizler, sonuçlar, referans aralıkları | ORU^R01 sonuçları, ORR sipariş yanıtları | ORM/OML siparişleri, demografi için ADT |
| RIS / PACS | Görüntüleme siparişleri, iş listeleri, raporlar, görüntüler | ORU raporları, görüntüleyicilere DICOM, SIU | ORM/OMI siparişleri, ADT; modalitelere DICOM MWL |
| Eczane | Formüler, dağıtım, stok | RDS dağıtım, RAS uygulama | OMP/RDE ilaç siparişleri, ADT |
| Cihazlar ve monitörler | Yaşam belirtileri, dalga formları, alarmlar | ORU^R01 gözlemleri (IHE PCD), özel | Hasta bağlamı için ADT |
| Hasta portalı / uygulamaları | Hasta tarafından girilen veriler, erişim | FHIR Gözlemleri, anketler, mesajlar | Sonuçların, randevuların, belgelerin FHIR okunması |
| Teletıp | Video ziyaretleri, uzaktan izleme | FHIR Karşılaşma, Gözlem, BelgeReferansı | Randevu, Hasta bağlamı, SMART başlatma |
| Bölgesel ve ulusal sistemler | Paylaşılan kayıtlar, kayıtlar, e-reçete | CDA belgeleri (XDS), FHIR, ulusal mesajlar | Sorgular, bildirimler |
Arayüz motoru
Arayüz motoru, hastanenin mesajlaşma merkezi gibidir: her sistemden HL7 v2, FHIR, dosya ve veritabanı trafiğini alır, dönüştürür ve ihtiyaç duyan diğer tüm sistemlere yönlendirir; kuyrukları, yeniden denemeleri, izlemeyi ve denetimi yönetir. Bir arayüz motoru olmadan, N sistemin N×(N−1)/2 adede kadar özel yapım arayüze ihtiyacı olur; bir tane ile her sistem yalnızca bir kez bağlanır.
Motor (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare ve IRIS for Health, Infor Cloverleaf, Qvera QIE ve diğerleri), dinleyiciler (MLLP, HTTP, dosya, veritabanı), dönüşümler (alanları eşleştirme, kodları düzeltme, v2'yi FHIR'a dönüştürme), yönlendirme (sekiz filtre ile sekiz sisteme bir ADT gönderme), kuyruklama ve yeniden denemeler, izleme ve denetim sağlar. Ayrıca sistemler anlaşmazlığa düştüğünde hasta kimliğinin uzlaştırıldığı ve eski bir veritabanı üzerinde genellikle bir FHIR cephesinin oluşturulduğu yerdir. Arayüz motorları açıklandı bölümüne bakınız.
En önemli akışlar
En önemli hastane entegrasyon akışları şunlardır: HIS'ten yayılan ADT (kabul, taburcu, transfer ve demografik güncellemeler), EHR ile laboratuvar veya radyoloji arasındaki siparişler ve sonuçlar, ilaç siparişleri ve dağıtımı, taburcu mektupları gibi belgeler, monitörlerden gelen cihaz verileri ve FHIR üzerinden hasta odaklı sonuç, randevu ve ev ölçümleri alışverişi.
- ADT: Her kabul, taburculuk, transfer, kayıt ve demografik güncelleme (A01, A03, A02, A04, A08, A40 birleştirme) HIS'ten diğer herkese yayılır. ADT geç veya yanlış olursa, her alt sistem verileri yanlış hasta veya karşılaşma altına kaydeder. Bkz. HL7 v2 mesajları açıklandı.
- Siparişler ve sonuçlar: ORM/OML giden, ORU dönen, bunları birbirine bağlayan yerleştirici ve doldurucu numaralarıyla; sonuçlarda LOINC ve UCUM. Bkz. HL7 v2 sipariş mesajları ve Bir laboratuvar sistemini bir EHR ile entegre etme.
- Görüntüleme: RIS'e siparişler, tarayıcılara DICOM iş listeleri, PACS'a görüntüler, ORU olarak geri raporlar, DICOMweb aracılığıyla görüntüleyiciler. Bkz. PACS vs RIS vs VNA.
- İlaç: Eczaneye siparişler, dağıtım ve uygulama geri, güvenlik hedefi olarak kapalı döngü (yatak başında barkod) ile.
- Belgeler: Taburculuk mektupları, operasyon notları ve taranmış belgeler MDM mesajları, CDA veya PDF olarak bir belge deposuna, bölgesel kayıtlara yayınlanır.
- Cihazlar: Monitörler, yaşam belirtilerini IHE PCD profilleri veya satıcı ağ geçitleri aracılığıyla kayda besler, alarm yönetimi ayrı bir disiplin olarak.
- Hasta odaklı: Sonuçlar, randevular ve belgeler FHIR üzerinden portala ve uygulamalara; anketler, ev ölçümleri ve giyilebilir cihaz verileri geri, kökeni hasta tarafından bildirildiğini belirten işaretlerle. Bkz. FHIR ile uzaktan hasta izleme.
Çalışan desenler
İşe yarayan hastane entegrasyon desenleri şunlardır: hasta kimliği için tek bir ana sistem ve herkesin ADT'ye abone olması; motor üzerinde LOINC, SNOMED CT ve ATC için kod eşleştirmesi; her mesaj için onaylar, kuyruklar ve yeniden denemeler; idempotent sonuçlar ve belgeler; hasta uygulamaları ve harici ortaklar için bir FHIR katmanı; ve canlıya geçmeden önce sentetik hastalarla test ortamları.
- Kimlik için tek ana sistem. HIS (veya ana hasta indeksi) tanımlayıcılara sahiptir; diğer herkes ADT'ye abone olur ve asla hasta oluşturmaz.
- Sınırda kodlar. Yerel kodları LOINC, SNOMED CT, ATC'ye motorda, bir kez eşleştirin ve yerel kodu yanında tutun.
- Onayla, kuyruğa al, yeniden dene. Her v2 mesajı bir ACK alır; motor kalıcı hale getirir ve yeniden oynatır; bir sistem yeniden başlatıldığı için kimse bir sonucu kaybetmez.
- Tekrarlanamazlık. Sonuçlar ve belgeler tanımlayıcılar taşır; bir yeniden oynatma çoğaltmak yerine günceller.
- Her yeni şey için bir FHIR katmanı. Hasta uygulamaları, teletıp, araştırma çıktıları ve harici ortaklar, doğrudan HIS'e değil, bir cepheye veya dahili akışlardan beslenen özel bir FHIR sunucusuna FHIR ile konuşur.
- Sentetik hastalarla test ortamları ve üretime dokunmadan önce bir uyumluluk adımı (IHE Connectathon profilleri, ulusal test paketleri).
Her yerde görülen hata modları
Neredeyse her hastane entegrasyonunda görülen hata modları şunlardır: kayıt hatalarından kaynaklanan yinelenen hastalar, birleştirme sonrası yanlış ziyarete kaydedilen sonuçlar, eşlenmemiş yerel kodlar, zaman damgalarındaki saat dilimi ve yaz saati hataları, serbest metin birimleri, izleme olmadan sessizce duran arayüzler, ayrıştırıcıları bozan satıcı Z-segmentleri ve asla emekliye ayrılmayan geçici CSV beslemeleri.
Kayıt yazım hatalarından kaynaklanan yinelenen hastalar; birleştirmeden sonra yanlış karşılaşmaya kaydedilen sonuçlar; kimsenin eşleştirmediği yerel test kodları; mesaj zaman damgalarında saat dilimleri ve yaz saati uygulaması; serbest metin birimleri; sessizce duran ve kimsenin izlemediği bir arayüz; ayrıştırıcıları bozan satıcıya özel Z-segmentleri; ve hala on yıl sonra çalışan "geçici" CSV akışı.
FHIR'ın resmi değiştirdiği yerler
FHIR, hastane entegrasyonunu çekirdekten ziyade kenarlarda değiştiriyor. Bina içinde, analiz cihazları, tarayıcılar ve eski modüller bunları konuştuğu için HL7 v2 ve DICOM kalmaya devam ediyor; FHIR, hasta erişimi, SMART on FHIR uygulamaları, CDS Hooks karar desteği, Abonelikler, EHDS ve TEFCA kapsamındaki bölgesel ve ulusal değişim ve araştırma verileri için devralıyor.
Dahili olarak, HL7 v2 ve DICOM yıllarca kalır, çünkü her analiz cihazı, tarayıcı ve eski modül bunları konuşur. FHIR kenarlarda kazanır: hasta erişimi, EHR içinde başlatılan uygulamalar (SMART on FHIR), karar desteği (CDS Hooks), olay odaklı entegrasyon için abonelikler, EHDS ve TEFCA kapsamında bölgesel ve ulusal değişim ve araştırma çıktıları. Birçok hastane artık bina dışındaki her şey için entegrasyon katmanı olarak motor tarafından beslenen bir FHIR sunucusu çalıştırıyor; bkz. Sağlık birlikte çalışabilirlik standartları: harita.
Anpheros'ta
Anpheros Platformu, hastane entegrasyonunun FHIR kenarında yer alır: hastanın rızasıyla bir hastanenin veya kliniğin yazıp okuyabileceği bir FHIR R4 kaydı, hastanenin kendi entegrasyonu aracılığıyla laboratuvar bağlayıcısından (HL7 v2 ORU, CSV veya JSON) beslenir, her kaynak için webhook'lar ve köken bilgisi içerir. HIS'i veya motoru değiştirmez.
Anpheros Platform bu kenarda yer alır: bir hastanenin veya kliniğin hastanın rızasıyla yazıp okuyabileceği bir FHIR R4 kaydı, hastanenin kendi entegrasyonu tarafından beslenir (laboratuvar bağlayıcısı HL7 v2 ORU, CSV veya JSON alır), değişiklik bildirimi için web kancaları ve kaynak başına köken ile. HIS veya motorun yerini almaz; hastanın bina dışına çıkan bir kaydını ona verir.
İlgili sayfalar
- Arayüz motorları açıklandı
- Bir laboratuvar sistemini bir EHR ile nasıl entegre edilir
- HL7 v2 mesajları açıklandı: ADT ve ORU
- PACS vs RIS vs VNA
- FHIR ile uzaktan hasta izleme
- Sağlık birlikte çalışabilirlik standartları: harita
- Klinik sistemleri FHIR ile entegre etme (geliştirici sitesi)
Kaynaklar
- HL7 Sürüm 2 ürün paketi
- IHE BT Altyapısı teknik çerçevesi
- IHE Cihazlar alanı (Hasta Bakım Cihazı profilleri)
- HL7 FHIR R4: Mesajlaşma ve iş akışı
- HL7 v2'den FHIR'a uygulama kılavuzu
Sık sorulan sorular
Yeni bir hastane her şeyi FHIR ile mi entegre etmeli?
Her şeyi değil. Analiz cihazları, tarayıcılar ve çoğu departman sistemi HL7 v2 ve DICOM konuşur ve bu yakında değişmeyecektir. Hasta odaklı, harici ve yeni entegrasyonlar için FHIR'ı ve köprü kurmak için bir motoru kullanın.
HIS ve EHR arasındaki fark nedir?
Kullanım ülkeye göre değişir. HIS genellikle idari ve klinik hastane sistemini birlikte ifade eder; EHR klinik kaydı vurgular. Entegrasyon terimlerinde her ikisi de kimlik, karşılaşmalar ve kaydın sahibi olan sistemdir.
Orta büyüklükte bir hastanenin kaç tane arayüzü vardır?
Tipik olarak elli ile birkaç yüz mesaj, her yön ve her alıcı sistem sayıldığında motor aracılığıyla akar. Motorun izleme ekranı, entegrasyon ekiplerinin yaşadığı yerdir.
Bir hastanede entegrasyona kim sahip?
Genellikle motor satıcısının desteğiyle hastanenin BT entegrasyon ekibi ve her departman satıcısı kendi tarafı için. Ulusal programlar ve IHE profilleri proje işini azaltır ancak ortadan kaldırmaz.
Sandbox'ta ücretsiz deneyin
İlk FHIR çağrınız 5 dakikada. Hasta izniyle yerleşik HL7 FHIR R4 API: sandbox'ta deneyin, ardından kendi uygulamanızı veya klinik sisteminizi bağlayın.
Ücretsiz · 30 sentetik hasta · kart gerekmez
Anpheros, hasta kontrolünde olan ve herhangi bir klinik ile paylaşılabilecek, AB merkezli bir HL7 FHIR R4 platformu üzerinde tıbbi kayıtlar oluşturur. Bu rehberler, sağlığınızı anlamanıza ve düzenlemenize yardımcı olur; doktorunuzun yerini tutmaz.
Anpheros Hakkında →