Kısa cevap: Bir arayüz motoru (entegrasyon motoru), sağlık mesajlaşması için tasarlanmış bir ara yazılımdır. Birçok protokolde (HL7 v2 için MLLP, FHIR ve SOAP için HTTP, dosyalar, veritabanları, kuyruklar) dinler, mesajları dönüştürür (alan eşleştirme, kod çevirisi, HL7 v2'den FHIR'a format dönüştürme), filtrelerle bir veya daha fazla hedefe yönlendirir ve kuyrukları, yeniden denemeleri, kayıtları ve kontrol panellerini tutar, böylece bir mesaj asla kaybolmaz ve her hata görünür olur. Hastaneler, her sistemin diğer tüm sistemlere değil, yalnızca motora bir kez bağlanması için bir tane kullanır. Bilinen ürünler arasında Mirth Connect (NextGen Connect, geçmişte açık kaynaklı), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion ve daha birçokları bulunur; bulut sağlayıcıları yönetilen eşdeğerlerini sunar.
Yapı taşları
Bir arayüz motorunun yapı taşları; kanallar (kaynaktan hedeflerine giden tek bir akış), MLLP ve HTTP gibi kaynak bağlayıcıları veya dinleyicileri, bir mesajın devam edip etmeyeceğine karar veren filtreler, alanları ve kodları eşleyen dönüştürücüler, hedef bağlayıcıları, yeniden deneme kuyrukları, uyarılarla izleme ve kanal değişiklikleri ile mesaj geçmişinin denetim izidir.
Her motor, kullandığı kelime dağarcığı ne olursa olsun aynı parçalara sahiptir:
- Kanal (arayüz): Kendi ayarları ve istatistikleriyle birlikte bir kaynaktan bir veya daha fazla hedefe giden bir akış.
- Kaynak bağlayıcısı / dinleyici: MLLP (HL7 v2 için çerçevelemeli TCP), HTTP(S) uç noktaları, SFTP ve dosya yoklama, veritabanı sorguları, JMS veya diğer kuyruklar, bazı ürünlerde DICOM.
- Filtre: Bir mesajın devam edip etmeyeceğine karar veren bir kural (bu hasta sınıfı için yalnızca ADT^A01).
- Dönüştürücü: Mesajı değiştiren betikler veya eşleştirmeler: alan adlarını değiştirme, bir arama tablosu aracılığıyla yerel kodları LOINC'e eşleme, bir OBX segmentinden bir FHIR Observation oluşturma, eski bir sistemin beklediği bir Z-segmenti ekleme.
- Hedef bağlayıcısı: Sonucun gittiği yer, kendi protokolü ve hata işleme mekanizmasıyla.
- Kuyruk ve yeniden deneme: Mesajlar onaylanana kadar kalır; hatalar geri çekilerek yeniden denenir; bozuk mesajlar insanlar için bir hata kuyruğuna düşer.
- İzleme ve uyarı: Kanal başına sayaçlar, gecikme, hata oranları, bir kanal sessiz kaldığında uyarılar (sağlık entegrasyonunda en kullanışlı uyarı).
- Denetim: Hangi kanalı kimin değiştirdiği ve sorun giderme için mesaj geçmişi, saklama ve erişim kontrolleriyle birlikte, çünkü bu hasta verisidir.
Tipik görevler
Bir sağlık arayüz motorunun tipik görevleri; YBYS'den departmanlara ADT dağıtımı, laboratuvar sonuçlarının birkaç alıcıya yönlendirilmesi, yerel kodların LOINC, ATC ve UCUM'a çevrilmesi, HL7 v2, FHIR, CDA ve CSV formatlarının köprülenmesi, eski bir veritabanı üzerinde bir FHIR cephesinin sunulması, cihaz akışlarının normalleştirilmesi ve MLLP'nin içeriden HTTPS'ye uyarlanmasıdır.
- ADT fan-out: HİS'ten kabul bilgilerini alma, departmana göre filtreleme ve çevirme, laboratuvar, radyoloji, eczane, yatak yönetimi ve hasta portalına teslim etme.
- Sonuç yönlendirme: LIS'ten EHR'ye, siparişi veren GP'nin sistemine, bölgesel kayda, hastanın FHIR kaydına ORU, her biri farklı bir alt küme ve formatla.
- Kod çevirisi: Yerel test kodlarını LOINC'e, yerel ilaç kodlarını ATC'ye, serbest metin birimlerini UCUM'a, bakımı yapılan arama tabloları aracılığıyla (laboratuvar kodlarını LOINC'e eşleme).
- Format köprüleme: HL7 v2'den FHIR'a ve geri, CDA'dan FHIR'a, eski bir sistemden CSV'yi herhangi bir şeye.
- Bir FHIR cephesi: Motor FHIR uç noktalarını sunar ve eski veritabanını sorgulayarak veya v2 sorguları göndererek bunlara yanıt verir, böylece uygulamalar var olmayan bir yerde bir FHIR sunucusu görür.
- Cihaz entegrasyonu: Özel monitör akışlarının IHE PCD gözlemlerine normalleştirilmesi.
- Protokol uyarlaması: Bina içinde MLLP, dışarıya OAuth ile HTTPS.
Birini seçmek
Bir arayüz motoru seçimi altı kritere iner: mesaj hacmi ve gecikme ile kesintilerin ne kadar kritik olduğu, kutudan çıktığı anda desteklenen protokoller ve standartlar (HL7 v2, FHIR R4, DICOM, ulusal formatlar), geliştirici deneyimi, kümeleme ve yük devretme gibi operasyonlar, lisanslama koşulları (bazı ürünler için 2025'te değişti) ve kanalları sürdürmek için mevcut becerilerdir.
- Hacim ve kritiklik: Günlük mesaj sayısı, kabul edilebilir gecikme süresi ve iki dakikalık bir kesintinin önemli olup olmadığı (ADT ve sonuçlar için önemlidir).
- Hazır protokoller ve standartlar: HL7 v2 sürümleri ve ayrıştırıcıları, doğrulama ile FHIR R4 desteği, DICOM, ABD'de X12, ulusal formatlar.
- Geliştirici deneyimi: Betik dili (Mirth'te JavaScript, diğerlerinde özel), kanal tanımlarının sürüm kontrolü, test araçları, birden fazla ortama dağıtım.
- Operasyonlar: Kümeleme, hata devri, izleme entegrasyonları, yükseltme yolu, destek modeli.
- Lisanslama: Açık kaynak veya topluluk sürümleri, kanal veya çekirdek başına abonelik, yönetilen bulut teklifleri; bazı geçmişte açık kaynaklı ürünlerin lisanslaması 2025'te değişti, bu nedenle güncel şartları kontrol edin.
- Mevcut beceriler: Motor, kanalları bakımını yapan insanlar kadar iyidir.
Birini güvenli çalıştırmak
Bir arayüz motorunu güvenli bir şekilde çalıştırmak; kanal tanımlarını sürüm kontrolü altındaki kod olarak ele almak, üretim öncesinde sentetik mesajlarla test etmek, adlandırılmış sahiplerle kod arama tablolarını yönetmek, bir kanal sessizleştiğinde uyarı vermek, hasta verisi olduğu için mesaj geçmişini kısıtlamak ve temizlemek, her kanalın amacını belgelemek ve motorun hiçbir zaman kayıt sistemi olmasına izin vermemek anlamına gelir.
Kanal tanımlarını kod gibi ele alın: sürüm kontrolünde, gözden geçirilmiş, test ve hazırlık ortamlarına sentetik mesajlarla dağıtılmış. Sahipleri olan arama tablolarını (kod haritaları) yönetime tabi tutun. Yalnızca hatalara değil, sessizliğe de uyarılar ayarlayın. Mesaj geçmişine erişimi kısıtlayın, bu hasta verisidir ve programlı olarak silinmelidir. Her kanalın amacını ve sahibini belgeleyin; belgelenmemiş kanal, yazarı ayrıldığında bir departmanı durduran kanaldır. Ve motorun asla kayıt sistemi olmasına izin vermeyin: veriyi taşır ve dönüştürür, ona sahip olmaz.
Birine ihtiyacınız olmadığında
Yeşil alan sisteminin tüm ortakları FHIR konuştuğunda, bu durumda Abonelikler ve bir API ağ geçidi ile bir FHIR sunucusu yönlendirme ve kimlik doğrulama işlemlerini kapsar, veya tek bir HL7 v2 arayüzü HAPI HL7v2 veya hl7apy gibi bir kütüphane tarafından halledilebildiğinde bir arayüz motoruna gerek yoktur. Motor, birçok sistem ve formatla yerini hak eder.
Ortaklarının tümünün FHIR konuştuğu yeşil alan bir sistem, Abonelikler ve kimlik doğrulama, hız sınırlama ve yönlendirme için bir API ağ geçidi ile bir FHIR sunucusu kullanabilir ve dönüşümler sıradan hizmetlerde yapılır. Tek bir HL7 v2 arayüzü, uygulama içindeki küçük bir kütüphane (Java'da HAPI HL7v2, Python'da hl7apy veya python-hl7) tarafından işlenebilir. Motor, çok sayıda sistem, çok sayıda format ve geliştirici olmayanların izleyebileceği bir operasyon konsolu ihtiyacı olduğunda yerini kazanır.
Anpheros'ta
Anpheros Platform, motorun FHIR tarafındadır: hastaneler paylaşmak istedikleri akışları (sonuçlar, belgeler, karşılaşmalar) motorları aracılığıyla veya laboratuvar bağlayıcısı aracılığıyla buraya yönlendirir ve FHIR API'leri ve web kancaları aracılığıyla geri okur. Geliştirici sitesi, bağlayıcının uyguladığı HL7 v2'den FHIR'a eşlemeyi gösterir.
İlgili sayfalar
- Hastane sistemi entegrasyonu açıklandı
- Bir laboratuvar sistemini bir EHR ile nasıl entegre edilir
- HL7 v2 mesajları açıklandı: ADT ve ORU
- Yerel laboratuvar kodlarını LOINC'e nasıl eşlenir
- FHIR Abonelikleri açıklandı
- HL7 v2'den FHIR'a eşleme (geliştirici sitesi)
Kaynaklar
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- HAPI HL7v2 kütüphanesi
- HL7 v2'den FHIR'a uygulama kılavuzu
Sık sorulan sorular
Arayüz motoru ESB veya iPaaS ile aynı mı?
Aynı aileden, uzmanlaşmış: bir arayüz motoru HL7 v2, DICOM, CDA ve FHIR desteği, MLLP, sağlık hizmetlerine özel izleme ve ekiplerin kullandığı kelime dağarcığı entegrasyonu ile birlikte gelir. Genel ESB'ler ve iPaaS ürünleri, daha fazla yapılandırmayla işi yapabilir.
Motor HL7 v2'yi FHIR'a otomatik olarak dönüştürebilir mi?
Birkaç motor, HL7 v2'den FHIR'a kılavuzuna dayalı eşleştirmeler içerir ve yaygın segmentleri işler. Yerel gelenekler, Z-segmentleri ve kod eşleştirmesi her zaman proje çalışması gerektirir.
Motor hasta verilerini saklar mı?
Aktarım halindeki mesajları kalıcı hale getirir ve sorun giderme için mesaj geçmişini tutar, bu hasta verisidir ve korunmalı ve silinmelidir. Uzun süreli depolama veya kayıt sistemi olarak kullanılmamalıdır.
Açık kaynak mı yoksa ticari mi?
Her ikisi de büyük hastanelerde üretimdedir. Karar genellikle destek, beceriler, kümeleme ihtiyaçları ve bazı ürünler için değişen mevcut lisanslama şartlarına bağlıdır; taahhütte bulunmadan önce kontrol edin.
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 →