Sağlık Kuruluşları ve HBYS Entegrasyonu İçin API Geliştirme
HBYS, laboratuvar, görüntüleme ve randevu sistemleri birbirini anlamadığında aradaki boşluğu telefon, faks ve elden taşınan çıktı dolduruyor. Veriyi HL7/FHIR yaklaşımıyla ortak bir dile taşıyor, erişimi rol, amaç ve kayıtla sınırlıyoruz.
- HL7/FHIR uyumlu veri modeli
- Rol ve amaç bazlı erişim
- Tam erişim kaydı
- Yalnız gereken alanın taşınması
Veri hastanede var; doğru yerde ve doğru zamanda yok.
Sağlık kuruluşlarında sorun genellikle kayıt tutulmaması değil, kaydın sistemler arasında dolaşamamasıdır. Bedeli hem personelin zamanı hem hastanın deneyimi olur.
- Sonuç raporu elden taşınıyorLaboratuvar veya görüntüleme sonucu çıktı, CD veya faksla poliklinikte aranıyor. Hasta, sonucun taşınmasını bekliyor.
- Aynı hasta birden çok kayıtla duruyorKabul, laboratuvar ve randevu sistemlerinde ayrı numaralarla açılmış kayıtlar birleştirilemiyor; geçmiş parçalı görünüyor.
- Randevu bilgisi tek yerde durmuyorTelefonla, web sitesinden ve merkezi sistemden gelen randevular farklı ekranlarda. Çakışma ve boş slot aynı gün içinde fark ediliyor.
- Hasta her seferinde aynı bilgiyi veriyorKimlik, iletişim ve geçmiş bilgisi her birimde yeniden soruluyor. Veri var; erişimi yok.
- Kim hangi kayda baktı bilinmiyorErişim kaydı ya hiç tutulmuyor ya da incelenebilir halde değil. Bir soru geldiğinde yanıt geçmişten değil, hafızadan veriliyor.
- Dış paydaşa veri paylaşımı elle yapılıyorAnlaşmalı kurum, sigorta veya laboratuvar ile paylaşım dosya aktarımıyla yürüyor; kapsam ve sınır her seferinde yeniden konuşuluyor.
Önce ortak dil, sonra erişim kuralı, en sonunda uç nokta.
Sağlık entegrasyonunda en pahalı hata, alan eşlemesi netleşmeden kod yazmaktır. Sırayı bilinçli olarak tersine çeviriyoruz.
- Kaynak envanteriHBYS, laboratuvar, görüntüleme, randevu ve varsa portal sistemleri; hangi veriyi kim üretiyor, hangi yöntemle dışarı verebiliyor.TeslimSistem envanteriDesteklenen yöntemlerSağlayıcı bağımlılıkları
- Hasta kimliği eşlemesiAynı kişiyi farklı sistemlerde işaret eden anahtarlar belirlenir; çakışma ve birleştirme kuralları yazılı hale gelir.TeslimKimlik eşleme kurallarıÇakışma senaryolarıBirleştirme prosedürü
- Veri alanı eşlemesiHer alan ortak modeldeki karşılığına bağlanır; hangi alanın dışarı çıkacağı ve hangisinin asla çıkmayacağı birlikte kararlaştırılır.TeslimAlan eşleme tablosuDışa açık alan listesiKod/terminoloji kararları
- Erişim ve amaç kurallarıErişim yalnız role değil, amaca ve hasta ilişkisine de bağlanır. Aynı uç nokta farklı kullanıcıya farklı ayrıntı döndürür.TeslimRol/amaç matrisiMaskeleme kurallarıOnay ve kısıt kayıtları
- Uyum katmanı ve uçlarHBYS'nin önüne ince bir katman kurulur; mevcut HL7 akışları korunurken dışa bakan uçlar FHIR yaklaşımıyla tasarlanır.TeslimUyum katmanıOpenAPI sözleşmesiTest ortamı
- Kayıt ve izlemeHer erişim ve her değişiklik kaydedilir; hata, gecikme ve olağandışı erişim için eşik tabanlı uyarılar kurulur.TeslimErişim kaydıUyarı kurallarıDevir dokümanı
HL7/FHIR veri alanı eşleme ve gizlilik kontrol listesi
Dışarıya veya başka bir sisteme taşımayı düşündüğünüz veri gruplarını işaretleyin. Araç, her grubun yaygın FHIR karşılığını, tipik kaynak sistemini ve hassasiyet seviyesini gösterir; seçiminize göre konuşulması gereken teknik önlemleri tek listede toplar. Hesap tarayıcınızda yapılır, hiçbir veri gönderilmez.
| Veri grubu | Yaygın FHIR karşılığı | Tipik kaynak | Hassasiyet |
|---|---|---|---|
| Hasta kimlik bilgileri | Patient | HBYS / kabul | Yüksek |
| İletişim bilgileri | Patient.telecom · Patient.address | HBYS / kabul | Orta |
| Randevu ve müsaitlik | Appointment · Schedule · Slot | Randevu sistemi / HBYS | Orta |
| Hekim, klinik ve lokasyon | Practitioner · Organization · Location | HBYS / kurum tanımları | Düşük |
- Veri minimizasyonuYalnız ihtiyacı karşılayan alanlar taşınır; 'ileride lazım olur' diye alan eklenmez.
- Rol ve amaç bazlı erişimErişim yalnız role değil, kullanım amacına ve hasta ilişkisine de bağlanır.
- Tam erişim kaydıKim, ne zaman, hangi kayda, hangi amaçla eriştiği geriye dönük incelenebilir biçimde kaydedilir.
- Aktarımda ve saklamada şifrelemeGüncel TLS zorunlu; saklanan hassas alanlar için ek şifreleme değerlendirilir.
- Saklama süresi ve imhaVerinin ne kadar tutulacağı ve nasıl imha edileceği yazılı kurala bağlanır.
- Taraflar arası paylaşım sözleşmesiDış paydaşla paylaşımda kapsam, süre ve sorumluluklar sözleşmeyle tanımlanır.
Bu araç teknik bir kapsam çıkarma yardımcısıdır; hukuki görüş, uygunluk değerlendirmesi veya uyum beyanı değildir. FHIR kaynak adları yaygın kullanımı gösterir, kurumunuzun sistemindeki karşılığı incelemeyle doğrulanır. Kişisel verilerin korunmasına ilişkin yükümlülükler veri sorumlusu olarak kurumunuza aittir.
HBYS'nin önüne kurduğumuz uyum katmanı
Mevcut sisteminiz yerinde kalır. Katman, veriyi ortak modele çevirir, erişimi denetler ve dışarıya yalnız kararlaştırılmış alanları açar.
- KimlikKimlik eşleme servisiFarklı sistemlerdeki hasta kayıtlarını birbirine bağlayan anahtar yönetimi ve birleştirme kuralları.
- ModelOrtak veri modeliAlanların FHIR kaynaklarına eşlenmesi; terminoloji ve kod kararlarının tek yerde tutulması.
- ModelHL7 v2 köprüsüMevcut laboratuvar ve kabul mesaj akışlarının korunması; yeni uçlarla birlikte çalışması.
- ErişimRol ve amaç kontrolüAynı uç nokta, farklı kullanıcıya farklı ayrıntı döndürür; maskeleme kuralları merkezde tanımlanır.
- ErişimErişim kaydıHer sorgu ve her değişiklik, kullanıcı ve amaç bilgisiyle kaydedilir; kayıtlar sonradan düzeltilemez.
- UçlarRandevu uçlarıMüsaitlik sorgulama, randevu oluşturma ve iptal; çakışma kontrolü tek yerde.
- UçlarSonuç ve rapor uçlarıLaboratuvar sonucu ve rapor metni; görüntüye erişim süreli görüntüleyici bağlantısıyla.
- TeslimTest ortamı ve dokümanGerçek hasta verisi içermeyen test ortamı, OpenAPI sözleşmesi ve entegrasyon kılavuzu.
Uyum katmanını Node.js ile kuruyor, sözleşmeyi OpenAPI ile yazıyor, kayıt tarafında PostgreSQL, önbellek ve kuyruk için Redis kullanıyoruz. Testlerde gerçek hasta verisi kullanılmaz; temsilî veri setiyle çalışılır. Kapsamın tamamı API geliştirme hizmet sayfasında.
Hasta portalı, randevu ekranı veya klinik içi modüller gerekiyorsa web yazılım geliştirme, mobil uygulama tarafı mobil yazılım geliştirme kapsamında ilerler; hasta akışlarının kullanılabilirlik tarafını UI/UX tasarım ile birlikte ele alıyoruz. Dışa açık uçlarda bağımsız güvenlik doğrulaması isterseniz süreci sızma testi rehberimizde anlattığımız gibi planlıyoruz.
Erişim sorusu 'kim' değil, 'kim, neden ve hangi hasta için'
Sağlıkta yetkilendirme rol tablosuyla bitmez. Aynı unvandaki iki kullanıcı, aynı kayda farklı gerekçelerle bakabilir; sistem bu farkı görebilmelidir.
- Amaç bazlı erişimTedavi, randevu, faturalandırma ve raporlama farklı amaçlardır; her amaç farklı alan kümesi görür.
- Hasta ilişkisi kontrolüKullanıcının o hastayla bir ilişkisi (randevu, yatış, istem) yoksa erişim varsayılan olarak kapalıdır.
- MaskelemeBazı alanlar tamamen gizlenmek yerine kısmi gösterilir; ekranda görünenle kayıtta duran ayrışır.
- Olağandışı erişim uyarısıAlışılmadık hacim veya saat dışı toplu sorgu, eşik tabanlı uyarı üretir; kayıt incelenebilir kalır.
Bu başlıklar teknik tedbirlerdir. Kişisel verilerin korunmasına ilişkin hukuki değerlendirme, aydınlatma ve işleme şartlarının belirlenmesi veri sorumlusu olarak kurumunuzun yükümlülüğündedir; kararları birlikte yazılı hale getirip teknik tarafta uyguluyoruz. Mimari ve kontrol seti için bağımsız bir görüş isterseniz teknik danışmanlık tek başına da alınabilir.
Örnek bir pilot: tek klinik, üç veri grubu
Aşağıdaki plan, tek bir klinikte randevu, kimlik ve sonuç akışının pilot olarak kurulması için hazırlanmış örnektir. Sizin planınız HBYS sağlayıcınızın desteklediği yöntemler incelendikten sonra çıkar.
| Hafta | Ne yapılır | Hafta sonunda elinizde ne olur |
|---|---|---|
| 1. hafta | Kaynak envanteri ve sağlayıcı görüşmesi | Desteklenen yöntemler, bağımlılık listesi |
| 2. hafta | Hasta kimliği eşlemesi | Eşleme kuralları, çakışma senaryoları |
| 3. hafta | Veri alanı eşleme tablosu | Dışa açık alan listesi, kod kararları |
| 4. hafta | Rol ve amaç matrisi | Erişim kuralları, maskeleme kararları |
| 5–6. hafta | Uyum katmanı ve ilk uçlar | Randevu ve kimlik uçları, test ortamı |
| 7. hafta | Sonuç ve rapor akışı | Laboratuvar sonucu, rapor referansı |
| 8. hafta | Kayıt, uyarı ve devir | Erişim kaydı, uyarı eşikleri, kılavuz |
Pilot klinik kararlı çalıştıktan sonra diğer birimler aynı katmana eklenir; kimlik eşlemesi ve erişim kuralları yeniden kurulmaz, yalnız yeni veri grupları eşlenir.
- HizmetAPI GeliştirmeHizmetin tamamı: kapsam, süreç, teslimatlar ve teknoloji yığını.
- HizmetWeb Yazılım GeliştirmeHasta portalı, randevu ekranı ve klinik içi modüller.
- HizmetMobil Yazılım GeliştirmeHasta mobil uygulaması ve bildirim tarafı.
- HizmetTeknik DanışmanlıkMimari ve erişim kontrolü için bağımsız değerlendirme.
- HizmetUI/UX TasarımRandevu ve sonuç ekranlarının kullanılabilirlik tarafı.
- ProjeTYS — Teklif Yönetim SistemiKurumsal entegrasyon yaklaşımımızın kendi ürünümüzdeki hali.
- RehberSızma testi (pentest) nedir?Dışa açık sağlık uçlarında bağımsız güvenlik doğrulaması.
- RehberHosting, VPS, bulut ve dedicated farkıVerinin nerede tutulacağına karar verirken.
Sık sorulanlar
HL7 ve FHIR farkı, HBYS bağımlılığı, güvenlik tedbirleri, mevzuat sorumluluğu ve görüntüleme verisi hakkında en çok sorulanlar.
Hangi verinin nereye akacağını birlikte belirleyelim
Hangi sistemleri kullandığınızı, bugün elden taşınan raporları ve paylaşmak istediğiniz veri gruplarını anlatın; ilk görüşmede eşleme tablosunun taslağını ve gerçekçi bir pilot kapsamı çıkaralım. Keşif görüşmesi ücretsizdir ve sizi bağlamaz.
- ✓ Keşif görüşmesi ücretsiz
- ✓ Kapsam netleşmeden fiyat vermiyoruz
- ✓ Testlerde gerçek hasta verisi kullanılmaz
Sonuç raporu elden değil, sistemden geçsin
HBYS, laboratuvar, görüntüleme ve randevu sistemlerini ortak bir dile taşıyor; erişimi rol, amaç ve kayıtla sınırlıyoruz.