HBYS Nedir? Hastane Bilgi Yönetim Sistemi Mimarisi, USS Entegrasyonu ve SBYS Tescili

HBYS (Hastane Bilgi Yönetim Sistemi), bir hastanenin hasta kabulünden laboratuvara, eczanesinden faturasına kadar tüm iş süreçlerini tek bir veri modeli üzerinde yürüten yazılım bütünüdür. Sağlık Bakanlığı'nın tanımıyla HBYS, tek bir program değil, "hastanelerin yapmış olduğu işlemleri bilgisayar üzerinde gerçekleştiren yazılımlar grubuna verilen genel ad"dır. Türkiye'de bir HBYS'nin yasal olarak çalışabilmesi için üç dış sistemle konuşması zorunludur: USS/e-Nabız (Sağlık Bakanlığı veri gönderimi), MEDULA (SGK provizyon ve faturalama) ve SKRS (ulusal kod listeleri). Bu rehber, HBYS'nin iç mimarisini, bu üç entegrasyonun teknik gerçeklerini ve SBYS tescil sürecini geliştirici gözüyle anlatıyor.

Bu yazı bir ürün tanıtımı değil, entegrasyon rehberidir. Hastane yazılımı satın alacak teknik yöneticiler ve HBYS'ye bağlanacak bir uygulama (mobil, tele-tıp, randevu, karar destek) geliştiren ekipler için yazıldı.

Önce Terminoloji: HBYS, SBYS, USS ve e-Nabız Aynı Şey Değil

Türkiye sağlık bilişiminde en çok zaman kaybettiren şey, dört kısaltmanın birbirinin yerine kullanılmasıdır. Bir ihale şartnamesini ya da entegrasyon dokümanını okurken bunları ayırt edemezseniz, yanlış sistemin API'sini araştırmakla haftalar kaybedersiniz.

Kritik ayrım: Sağlık Bakanlığı (USS) veriyi alır, SGK (MEDULA) parayı öder. Bunlar ayrı kurumlar, ayrı protokoller, ayrı kimlik doğrulama ve ayrı test ortamlarıdır. Bir HBYS projesinde bu iki entegrasyonu aynı ekip yapar ama asla aynı kod yolunu paylaşmazlar.

HBYS'nin İç Mimarisi: Modüller ve Aralarındaki Sözleşmeler

HBYS'nin "tek program değil, yazılımlar grubu" olması pratikte şu anlama gelir: birbirinden bağımsız geliştirilmiş ve çoğu zaman farklı satıcılardan gelen modüller, ortak bir hasta ve başvuru kimliği etrafında buluşur.

Çekirdek modüller

• Hasta Kayıt / Kabul (ADT): Hasta dosyası, başvuru, yatış-çıkış, transfer. Tüm sistemin kimlik kaynağıdır.
• Poliklinik / Klinik: Muayene, tanı (ICD-10), istem girişi, epikriz.
• Laboratuvar (LIS): Numune kabul, cihaz arayüzü, sonuç onayı.
• Radyoloji (RIS) + PACS: Çekim istemi, görüntü arşivi, rapor.
• Eczane ve Stok: İlaç/malzeme çıkışı, kritik stok, UTS (Ürün Takip Sistemi) barkodları.
• Ameliyathane: Planlama, malzeme sarfı, ameliyat notu.
• Döner Sermaye / Faturalama: Hizmet fiyatlandırma, SUT kuralları, MEDULA fatura kaydı.
• İnsan Kaynakları ve Performans: Nöbet, ek ödeme hesabı.

Modüller arası entegrasyonun gerçek dili

Kurum içinde iki standart hâkimdir ve bunlar USS/MEDULA protokollerinden tamamen bağımsızdır:

• HL7 v2.x mesajlaşması: LIS ve RIS entegrasyonlarının fiili standardı. Tipik akış: HBYS'den laboratuvara ORM^O01 (istem), laboratuvardan HBYS'ye ORU^R01 (sonuç); hasta hareketleri için ADT^A01 ailesi. Pipe-delimited, segment tabanlı, XML değil.
• DICOM: Görüntüleme cihazları (MR, BT, USG, mamografi) ve PACS arasındaki standart. HBYS tarafında genellikle DICOM Modality Worklist (MWL) ile çekim listesi yayınlanır.

Bir HBYS'ye entegre olacak üçüncü parti uygulama geliştiriyorsanız, en olası temas noktanız bu iki protokoldür — çünkü HBYS üreticilerinin çoğu dışarıya modern bir REST API açmaz, ama bir HL7 arayüzü neredeyse her zaman vardır. Bu tür arayüz tasarımını API geliştirme hizmetlerimiz kapsamında ele alıyoruz.

Zorunlu Entegrasyon #1: USS Veri Gönderimi (SYS Web Servisi)

Bir sağlık tesisi, ürettiği klinik veriyi Sağlık Bakanlığı'na göndermekle yükümlüdür. e-Nabız rehberinin ifadesiyle: "Sağlık hizmeti veren kurumlar, belirlenen standartlar çerçevesinde ilgili metodları kullanarak xml yapıda veri seti (paket) oluşturarak e-Nabız'a göndermektedir."

Bu gönderim, tek bir SOAP uç noktası üzerinden yapılır. Servisin sözleşmesi şaşırtıcı derecede sadedir — ve bu sadelik entegrasyonun en çok yanlış anlaşılan yönüdür:

Endpoint : https://sys.sagliknet.saglik.gov.tr/SYS/SYSWS.svc
WSDL     : https://sys.sagliknet.saglik.gov.tr/SYS/SYSWS.svc?wsdl
Binding  : BasicHttpBinding_ISYSWS  (WCF, SOAP 1.1)
Operation: SYSSendMessage
SOAPAction: https://sys.sagliknet.saglik.gov.tr/SYS/ISYSWS/SYSSendMessage

// XSD sözleşmesi:
<xs:element name="SYSSendMessage">
  <xs:complexType><xs:sequence>
    <xs:element minOccurs="0" name="input" nillable="true" type="xs:string"/>
  </xs:sequence></xs:complexType>
</xs:element>

<xs:element name="SYSSendMessageResponse">
  <xs:complexType><xs:sequence>
    <xs:element minOccurs="0" name="SYSSendMessageResult" nillable="true" type="xs:string"/>
  </xs:sequence></xs:complexType>
</xs:element>

Dikkat edilmesi gereken nokta: servis string alır, string döner. Yani WSDL size hiçbir tip güvenliği sunmaz. Gönderdiğiniz XML paketinin yapısı WSDL'de tanımlı değildir; paket şeması ve alan kuralları ayrı kılavuzlarda ve SKRS kod listelerinde yaşar. Pratikte bu şu demektir:

• Kod üretici (wsdl2php, svcutil, SoapClient) size yalnızca bir metot verir; asıl iş XML'i doğru kurmaktır.
• Şema doğrulamasını siz yapmak zorundasınız. Servise geçersiz paket göndermek, tip hatası değil, iş kuralı hatası olarak geri döner.
• Yanıt bir string olduğu için hata ayıklama disiplini şart: her gönderimin isteğini ve yanıtını ham haliyle saklayın.

PHP tarafında minimal bir istemci iskeleti:

<?php

use SoapClient;
use SoapFault;

final class UssClient
{
    private SoapClient $client;

    public function __construct(private string $wsdl)
    {
        $this->client = new SoapClient($this->wsdl, [
            'soap_version' => SOAP_1_1,
            'trace'        => true,   // __getLastRequest() icin sart
            'exceptions'   => true,
            'cache_wsdl'   => WSDL_CACHE_DISK,
            'connection_timeout' => 15,
        ]);
    }

    /**
     * @param string $paketXml SKRS/USVS kurallarina gore hazirlanmis XML paket
     */
    public function gonder(string $paketXml): string
    {
        try {
            $yanit = $this->client->SYSSendMessage(['input' => $paketXml]);

            return (string) $yanit->SYSSendMessageResult;
        } catch (SoapFault $e) {
            // Ham istek/yanit olmadan bu servisi hata ayiklamak mumkun degil
            logger()->error('USS gonderim hatasi', [
                'fault'   => $e->getMessage(),
                'request' => $this->client->__getLastRequest(),
                'response'=> $this->client->__getLastResponse(),
            ]);

            throw $e;
        }
    }
}

Mimari tavsiye: bu çağrıyı asla hasta kabul veya muayene kaydetme isteğinin senkron yoluna koymayın. USS tarafındaki bir gecikme, poliklinikte sıra bekleten bir arıza haline gelmemeli. Doğru desen: klinik olay veritabanına yazılır, bir outbox kaydı üretilir, kuyruk işçisi paketi kurup gönderir, yanıt koduna göre yeniden denenir. Bu deseni referans mimarilerimiz sayfasında daha genel bağlamda anlatıyoruz.

Zorunlu Entegrasyon #2: SKRS — Kodları Sabitlemeyin

SKRS (Sağlık Kodlama Referans Sunucusu), ulusal sağlık bilgi sisteminde kullanılan kodlama ve sınıflandırma standartlarını barındıran referans sunucudur. Tanı, işlem, branş, ilaç, kurum, ilçe gibi onlarca liste buradan yayımlanır.

Sahada en sık görülen ve en pahalıya patlayan hata şudur: geliştirici, projenin başında SKRS listesini indirip veritabanına sabit bir ENUM ya da hard-coded dizi olarak gömer. Listeler güncellenir; altı ay sonra yeni bir branş kodu ya da değişen bir işlem kodu yüzünden gönderimler reddedilmeye başlar ve hata mesajı "kod geçersiz"den ibaret olduğu için kimse nereye bakacağını bilemez.

Doğru yaklaşım:

1. Her SKRS listesi ayrı bir tabloda, kod + ad + gecerlilik_baslangic + gecerlilik_bitis + surum alanlarıyla tutulur.
2. Senkronizasyon zamanlanmış bir görevle yapılır, elle değil.
3. Uygulama kodunda kod değeri değil, kod anahtarı referans edilir; iş mantığı koda göre switch yapıyorsa bu bir tasarım kokusudur.
4. Bilinmeyen bir kodla karşılaşıldığında sistem sessizce düşmez — kaydı karantinaya alıp operasyona bildirir.

// Laravel ornegi: SKRS listesini idempotent senkronize etmek
foreach ($skrsSatirlari as $satir) {
    SkrsKod::updateOrCreate(
        ['liste' => $listeAdi, 'kod' => $satir['kod']],
        [
            'ad'                  => $satir['ad'],
            'gecerlilik_baslangic'=> $satir['baslangic'] ?? null,
            'gecerlilik_bitis'    => $satir['bitis'] ?? null,
            'surum'               => $mevcutSurum,
            'senkron_zamani'      => now(),
        ]
    );
}

// Bu surumde gelmeyen kodlari SILME - pasife al.
// Gecmis kayitlar hala o koda referans veriyor olabilir.
SkrsKod::where('liste', $listeAdi)
    ->where('surum', '!=', $mevcutSurum)
    ->update(['aktif' => false]);

Son satır önemli: geçmiş kayıtların referans verdiği kodları silmek, geriye dönük raporlamayı ve itiraz süreçlerini bozar. Kodlar silinmez, pasifleştirilir.

Zorunlu Entegrasyon #3: MEDULA (SGK)

MEDULA, HBYS'nin gelir tarafıdır. Hasta kapıdan girdiğinde SGK'dan provizyon alınmazsa hizmet faturalanamaz. Teknik olarak tamamen ayrı bir dünyadır: SOAP, HTTP Basic Authentication, ayrı test ortamı (sgkt.sgk.gov.tr) ve ayrı kullanıcı adı/şifre.

Akış üç süreçten oluşur — Hasta Kabul, Hizmet Kayıt, Fatura Kayıt — ve her biri kendi WSDL'ine sahiptir. Bu sürecin metot metot teknik anlatımını ayrı bir rehbere ayırdık: MEDULA Entegrasyonu: SGK Provizyon, Hizmet ve Fatura Web Servisleri Teknik Rehberi.

SBYS Tescili: Yazılımınız Kayıtlı Değilse Veri Gönderemez

25 Ağustos 2022 tarihli ve 31934 sayılı Resmî Gazete'de yayımlanan Sağlık Bilgi Sistemleri Hakkında Yönetmelik, SBYS hizmeti sağlayıcılarının uyacağı kuralları, alım süreçlerini, standartları ve tescil işlemlerini düzenler. Pratik sonucu nettir: bir sağlık yazılımının sahada çalışabilmesi için üreticisinin KTS (Kayıt Tescil Sistemi)'nde kayıtlı olması gerekir.

Aktif listede, sağlık bilişim standartlarına ve yayımlanan veri gönderim servislerine uyum sağlamış, veri gönderimlerinde başarılı olan üreticiler yer alır. Aktif listeden düşmek, ticari olarak ölümcüldür — hastane ihalelerinin şartnamesi aktif listede olmayı şart koşar. Bu yüzden veri gönderim başarı oranı bir "nice to have" metrik değil, şirketin satış yapabilmesinin ön koşuludur.

Bir HBYS ürünü geliştiriyorsanız, gönderim başarı oranını ürününüzün birinci sınıf SLA metriği olarak izleyin. Panoda gösterin, alarm kurun. "Bu ay %97" cümlesi, o %3'ün hangi tesis ve hangi paket tipi olduğuyla birlikte anlam taşır.

Karar: Hazır HBYS Almak mı, Kendi Yazılımını Yazmak mı?

Bu soru bize en çok özel hastane grupları, tıp merkezi zincirleri ve poliklinik ağlarından geliyor. Dürüst cevap: tam kapsamlı bir HBYS'yi sıfırdan yazmak neredeyse hiçbir zaman doğru karar değildir. Sebep teknik değil, regülatiftir — SUT kuralları, SKRS listeleri, MEDULA sürümleri ve mevzuat sürekli değişir; bu değişimi takip etmek başlı başına bir ürün ekibi işidir.

Gerçekçi ve sık işe yarayan üç senaryo:

Maliyet tarafında somut konuşalım: ininia'da yazılım geliştirme 300–400 USD/adam-gün bandında fiyatlanır ve teklifler adam-gün dökümüyle verilir. Yani bir entegrasyon işinin bütçesi, "kaç adam-gün" sorusunun cevabıdır. Kendi kapsamınız için hızlı bir aralık görmek isterseniz proje fiyat hesaplama aracımızı kullanabilirsiniz; kapsamı yazmanız yeterli.

HBYS'ye Bağlanacak Uygulama Geliştirenler İçin 6 Mimari Kural

1. Yozlaşma önleyici katman (anti-corruption layer) kurun. HBYS'nin veri modeli sizin ürününüzün modeli olmamalı. Araya bir çeviri katmanı koyun; HBYS değiştiğinde tek bir yer değişsin.
2. Her dış çağrıyı idempotent yapın. Sağlık entegrasyonlarında çift kayıt, eksik kayıttan daha maliyetlidir. İstek anahtarı üretin ve tekrarlanan çağrıda aynı sonucu dönün.
3. Kuyruk + outbox deseni. Klinik işlem ile dış gönderim aynı transaction'da olmasın.
4. Ham istek/yanıt saklayın. Bu sistemlerin hata mesajları kısa ve bağlamsızdır. Ham SOAP zarfını saklamayan ekip, üçüncü haftada geriye dönük hata ayıklayamaz.
5. TC kimlik numarasını loglamayın. Sağlık verisi KVKK'da özel nitelikli kişisel veridir. Loglarda maskeleyin, erişimi rol bazlı kısıtlayın, erişim kayıtlarını (audit log) ayrı tutun. Genel yaklaşımımızı güvenlik merkezi sayfasında bulabilirsiniz.
6. Test ortamını canlı ortamdan konfigürasyonla ayırın, kodla değil. MEDULA'nın test ve canlı adresleri farklıdır; if ($production) dallanmaları er ya da geç yanlış ortama veri gönderir.

FHIR Nereye Oturuyor?

FHIR (Fast Healthcare Interoperability Resources), sağlık verisi paylaşımının modern ve REST tabanlı standardıdır. Türkiye'de HBYS'nin USS'ye gönderim ve MEDULA yükümlülükleri FHIR'dan bağımsız kendi kanallarında yürür; FHIR daha çok kurum içi modern arayüzlerde, uluslararası entegrasyonlarda ve yeni nesil dijital sağlık ürünlerinde devreye girer. İkisini karıştırmamak gerekir: FHIR desteği vermek, yasal veri gönderim yükümlülüğünüzü karşılamaz.

FHIR kaynak modelini ve kullanım senaryolarını ayrıntılı ele aldığımız yazı: FHIR Nedir? Sağlık Verisi Standardı Rehberi. Vatandaşa dönük tarafı ve OAuth akışları için ise e-Nabız Entegrasyonu: Teknik Rehber yazımıza bakabilirsiniz.

Sıkça Sorulan Sorular

HBYS ile SBYS arasındaki fark nedir?

SBYS üst kategoridir; hastane, aile hekimliği, ağız-diş sağlığı, muayenehane ve laboratuvar yazılımlarının tamamını kapsar. HBYS, SBYS'nin hastanelere özgü alt türüdür. Mevzuat ve tescil süreçleri "SBYS" terimini kullanır, sahadaki konuşma dili ise "HBYS" der.

HBYS verisi doğrudan e-Nabız'a mı gönderilir?

Hayır. Veri, Ulusal Sağlık Sistemi'ne (USS) gönderilir; e-Nabız, bu veriyi vatandaşa gösteren arayüzdür. Teknik olarak hedefiniz SYS web servisidir, e-Nabız'ın kendisi değil.

Kendi yazdığım hastane yazılımıyla USS'ye veri gönderebilir miyim?

Gönderim, üreticinin Kayıt Tescil Sistemi'nde kayıtlı ve yazılımın tescilli olmasına bağlıdır. Sağlık Bilgi Sistemleri Hakkında Yönetmelik bu süreci düzenler. Tescil olmadan üretim ortamına veri gönderemezsiniz.

MEDULA entegrasyonu için Sağlık Bakanlığı'ndan izin gerekir mi?

Hayır — MEDULA'yı SGK işletir. Sağlık tesisi SGK ile sözleşmeli olmalı ve tesise ait kullanıcı adı/şifre ile tesis kodu tanımlanmalıdır. Bu, USS tescilinden tamamen ayrı bir süreçtir.

HBYS entegrasyonu ne kadar sürer?

Kapsama göre çok değişir, ama ayırt edici soru şudur: HBYS üreticisi size dokümante bir arayüz veriyor mu? Veriyorsa iş, iki API arasında eşleme yazmaktır. Vermiyorsa — ki sıkça olur — süre, arayüzün tersine mühendisliği ve üreticiyle koordinasyona bağlı hale gelir ve tahmin bandı genişler. Teklif alırken "HBYS üreticisinden yazılı arayüz dokümanı temin edilecektir" maddesini sözleşmeye koymanızı öneriyoruz.

SKRS kodlarını neden veritabanına gömmemeliyim?

Listeler güncellenir. Gömülü kodlar, güncelleme sonrası reddedilen gönderimlere ve geriye dönük raporlama hatalarına yol açar. Kodlar sürümlenerek senkronize edilmeli, kullanımdan kalkanlar silinmek yerine pasifleştirilmelidir.

PACS ve LIS entegrasyonunda hangi standart kullanılır?

Görüntüleme tarafında DICOM, laboratuvar ve hasta hareketlerinde HL7 v2.x mesajlaşması yaygındır. Bu standartlar kurum içi entegrasyonda kullanılır; USS ve MEDULA gönderimleriyle ilişkili değildir.

Sonuç

HBYS projelerinde işi zorlaştıran şey hastane iş süreçlerinin karmaşıklığı değil — o karmaşıklık öğrenilebilir. Asıl zorluk, üç ayrı kurumun (Sağlık Bakanlığı, SGK, hastanenin kendi yazılım tedarikçisi) üç ayrı protokolünü, üç ayrı test ortamını ve sürekli değişen kod listelerini aynı anda ayakta tutmaktır. Bu sistemlerin ortak özelliği, hata mesajlarının kısa ve bağlamsız olmasıdır; dolayısıyla projenin kaderini belirleyen şey mimarinin zarafeti değil, gözlemlenebilirliğidir: ham istek/yanıt saklama, kuyruk tabanlı yeniden deneme, sürümlenmiş kod tabloları ve gönderim başarı oranının birinci sınıf metrik olarak izlenmesi.

ininia olarak sağlık sektöründe HBYS'ye bağlanan uygulamalar, entegrasyon ara katmanları ve veri gönderim hattı kuruyoruz. Sağlık alanındaki yaklaşımımızı sağlık ve medikal yazılım sayfasında bulabilirsiniz; kendi kapsamınız için bir adam-gün tahmini almak isterseniz iletişim sayfasından yazabilir veya doğrudan proje fiyat hesaplama aracını kullanabilirsiniz.

Bu yazıdaki teknik ayrıntılar 24 Eylül 2026 tarihinde resmî kaynaklardan doğrulanmıştır: SYS web servisi sözleşmesi sys.sagliknet.saglik.gov.tr/SYS/SYSWS.svc?wsdl adresinden, veri gönderim tanımı rehber.enabiz.gov.tr adresinden, HBYS tanımı dijitalhastane.saglik.gov.tr adresinden, tescil süreci kayittescil.saglik.gov.tr ve 25.08.2022 tarihli 31934 sayılı Resmî Gazete'de yayımlanan Sağlık Bilgi Sistemleri Hakkında Yönetmelik'ten alınmıştır. Mevzuat ve servis sözleşmeleri değişebilir; üretime çıkmadan önce güncel kılavuzu teyit edin.