Sınır Ötesi Bir EHR Entegrasyonundan 5 Öğrenim
İki farklı ülke arasındaki hasta kayıtlarını birbirine bağlamak için aylarımı harcadım. On yıllık klinik deneyime sahip bir Kıdemli İş Analisti (Lead Business Analyst) ile çalıştım. Onun yaklaşımı, sağlık yazılımlarına bakış açımı değiştirdi.
İşte o projeden çıkarılan beş ders.
- Terminoloji eşleme, veri eşlemeden daha zordur
Mühendisler entegrasyonu genellikle bir şema problemi olarak görürler. A alanını B alanına eşlersiniz ve iş biter. Sağlık sektöründe bu yöntem başarısız olur.
Bir sistem ICD-10 kullanırken diğeri ICD-11 kullanıyordu. Bunlar birbirine temiz bir şekilde eşlenemiyor. Bir sistem laboratuvarlar için LOINC kullanırken diğeri eski dahili kodları kullanıyordu.
İş Analistimiz (BA), kod yazmaya başlamadan önce bir kavram çapraz tablosu (concept crosswalk) oluşturdu. Yerel kodları SNOMED CT gibi standart bir sete eşledi. Bu olmasaydı, klinik anlam bozulurdu.
Hatalı alan eşleme yanlış değerler oluşturur. Hatalı terminoloji eşleme ise makul görünen ancak klinik olarak yanlış değerler oluşturur. İkincisi çok daha tehlikelidir.
- Veri yasaları mimariyi erkenden şekillendirir
Önce veri modelini tasarlayacağımızı ve uyumluluk (compliance) konusunu daha sonra halledeceğimizi düşünmüştüm. Yanılmışım.
Sınırları aşan hasta verileri HIPAA veya GDPR gibi birden fazla yasaya takılır. Bazı ülkeler sağlık verilerinin sınır dışına çıkmasını yasaklar.
İş Analistimiz hukuk ekipleriyle erkenden çalıştı. Hangi alanların kopyalanabileceğine (replicate) ve hangilerinin kimliksizleştirilmesi (de-identification) gerektiğine karar verdi.
Bu durum mimarimizi değiştirdi. Tek bir kopyalanmış veritabanı yerine federasyon sorgu katmanı (federated query layer) oluşturduk. Şemamıza doğrudan veri sınıflandırma etiketleri ekledik.
Veri modelinizi tasarlamadan önce uyumluluk uzmanlarını ve bir iş analistini sürece dahil edin.
- Standartlar yeterli değildir
Her iki sistem de HL7 destekliyordu. Ancak biri HL7 v2, diğeri ise FHIR R4 kullanıyordu. Bir çeviri katmanı olmadan birbirleriyle iletişim kuramazlardı.
FHIR içinde bile profil uyumsuzluklarıyla karşılaştık. Her iki sistem de uyumlu olduğunu iddia ediyordu ancak farklı uygulama kılavuzları (implementation guides) kullanıyorlardı.
Bir sistem bir standardı destekliyor diye entegrasyonun kolay olacağını varsaymayın. Her zaman spesifik versiyonu ve profili sorun. Bir adaptör katmanı için zaman ayırın.
- İş akış diyagramları gizli uç durumları yakalar
Eskiden iş akış diyagramlarını fazladan dokümantasyon olarak görürdüm. Yanılmışım.
İş Analistimiz hasta transferlerini detaylı bir şekilde haritalandırdı. Tedavi sırasında hastanın yer değiştirmesi veya bir laboratuvar sonucunun taburcu edildikten sonra gelmesi durumunda neler olacağını inceledi.
Bunlar bir hastanede uç durum (edge case) değildir. Her gün yaşanırlar.
Bu diyagramlar veri modelimizi değiştirdi. Her iki sistemde de kesintisiz bakımı takip etmek için bir "bakım dönemi" (care episode) kavramı ekledik.
- Erken aşamada ortak bir sözlük oluşturun
"Encounter" veya "discharge" gibi kelimeler farklı sistemlerde farklı anlamlara gelir. Ekipler terimleri farklı yorumladığı için zaman kaybettik.
İş Analistimiz ortak bir sözlük oluşturdu. Her paydaş bu tanımları inceledi ve onayladı. Her gereksinimde bu belgeye atıfta bulunduk.
Her alan teriminin belirsiz olduğunu varsayın. Terimi, her iki tarafın da imzalayacağı bir belgede tanımlayın.
Özet
Güçlü bir iş analisti sadece görev (ticket) yazmaktan fazlasını yapar. Düzenleyici kısıtlamalar ve klinik anlam için birer mimar gibi hareket ederler. Karmaşık yazılımlar geliştiriyorsanız, bu rolü bir ek yük (overhead) olarak görmeyin. Bu rol, teknik başarının klinik bir başarısızlığa dönüşmesini engeller.
İsteğe bağlı öğrenme topluluğu: https://t.me/GyaanSetuAi