Aile Hekimliği Bilgi Sistemi (AHBS)

(Bu yazı SD Platform dergisinin 15. sayısında Haziran 2010'da yayınlanmıştır).

Riskli bir adım, AHBS

Sağlıkta Dönüşüm Programı (SDP) kapsamında Aile Hekimliği’nin pilot uygulamasının arifesinde önemli bir karar daha alındı. Buna göre, aile hekimliği sadece sağlık hizmet sunumunda değil, kendi bilişim altyapısıyla da bir dönüşüme ön ayak olacak ve son 50 yıldır neredeyse hiç değişmemiş olan hantal bilgi toplama yapısı değişecekti. Uygulamanın adı dahi “aile hekimliği” “aile doktorluğu” arasında gidip geliyorken ve işin teorisyenleri “aile doktoru ne yapar?” sorularına kafa yoruyorken, köklü bir dönüşüme bilişim altyapısını da dâhil etmek, bu yeni sistemle ilgili riskleri artırıcı bir adımdı; ancak bir o kadar da vizyoner bir yaklaşımdı. Bu yaklaşım, bugün Aile Hekimliği Bilgi Sistemi’nin (AHBS) adını verdiğimiz yapının ortaya çıkmasına neden oldu.

Başlangıcından itibaren 6 yılı geride bırakan AHBS için bugün sanırım daha sağlıklı analiz yapma imkânımız var. Ancak AHBS’yi kritik etmeden önce, yazılım, insan ve bilgi ilişkisinin gelişiminden az da olsa bahsetmek istiyorum. Zira bu tür değerlendirmeler, yazılımla ilgili algımız ve onlardan ne beklediğimize göre şekilleniyor.

Yazılımların kısa geçmişi

İş hayatımızda kullandığımız yazılımlar, başlangıçta hesap makinesi gibi, asıl işimizin sadece belirli bir parçasını kolaylaştıran harici unsurlar olarak sahneye çıktı. Onları kullanır, çıktılarından yaralanır; ama asıl işimize “bildiğimiz gibi” devam ederdik. MS Word ve MS Excel gibi ofis yazılımları bu türün en yaygın kullanan örnekleridir. Bu tür yazılımların, özellikle ofis, mühendislik ve bilim alanlarında yaygın olduğunu görüyoruz. Yazılım geliştirme işi, o zamanlar daha çok “kodlama” veya “programlama” olarak adlandırılmaktaydı.

Donanım, veri saklama ve haberleşme konuları son 15-20 yıla kadar yazılımların kullanım alanını sınırlandıran üç temel unsurlardı. Donanım hızındaki artış, Moore tarafından 1965 yılında ortaya atılan teze uygun şekilde ilerledi (1). Moore,  bilgisayar donanım hızının her iki yılda iki katına çıkacağını öngörmüştü. Veri saklama kısıtı ise, eskiden işlenen/üretilen verilerin ancak dosyalar ve veri yapıları halinde saklanabiliyor olmasından ileri gelmekteydi. Veritabanı sistemleri de bu sorunu çözdü. İlk örneklerini 1960’larda gördüğümüz veritabanı sistemleri, 70’lerde ilişkisel veritabanlarının piyasaya sunulması ve 1980’lerde de ticari olarak yaygınlaşmasının, kişisel bilgisayarların ve Internet’in hayatımıza girdiği 90’ların  ardından günümüz yazılımlarının vazgeçilmez bir parçası oldular. Son engel ise, bilgisayarlar arası haberleşme ile ilgiliydi. Kişisel bilgisayarların yaygınlaşmasıyla yerel bilgisayar ağı (LAN), geniş bilgisayar ağı (WAN) ve buna paralel olarak Internet’in yaygınlaşması, giderek artan bant genişlikleri, hayallerimizi gerçekleştirebilmemiz için bize fırsatlar verdi. 1990’lardan itibaren yazılımların iş dünyasının her alanına girmesinin önündeki teknik engeller kalkmıştı. Hatta bu kısıtların ortadan kalkmasının yan ürünleri olan kablosuz haberleşme ve mobil cihazlar da, yazılımların kullanımında çok farklı yaklaşımların gelişmesine ve hatta günlük hayatımızda bile yeni alışkanlıklar kazanmamıza neden oldu.

Yazılımlarla ilgili teknolojik kısıtların ortadan kalkmasının ardından, öncekilere oranla aşılması daha zor görünen başka bir engel kendini göstermeye başladı. Nitekim bu altyapısal gelişmeler, gerçekten “kullanılabilir” yazılımlar geliştirebilmek için hem kullanıcıların yazılımlarla ilgili algısını değiştirmesini, hem de yazılımcıların kullanıcı ihtiyaçlarını çok iyi anlamasını zorunlu kılıyordu. Bu durum, daha önce kodlama ve programlama olarak adlandırılan yazılım geliştirme sürecini de etkilemiş, artık yazılım geliştirme işi bir “mühendislik” olarak görülmeye başlanmıştı. Bu durum, “sistem analistliği”, “yazılım mühendisliği”, “yazılım mimarlığı” gibi uzmanlık alanlarının doğmasına neden olmuştu.

Ancak bu değişim iki temel nedenden dolayı kolay olmadı. Bunlardan birincisi, kullanıcıların yazılımların kendi işlerine bu kadar müdâhil olmasını kabullenmekte zorlanmalarıydı, bir çeşit doku uyuşmazlığı yaşandı. İkinci olarak yazılımların “kullanılabilir” olmayı yeterince önceleyememesi ve işi sadece bir mühendislik konusundan ibaret teknik bir olgu olarak görmeye devam etmeleri de bu süreci zorlaştırdı. Gerçi, bu iki nedenin yumurta tavuk ilişkisine sahip olduğunu söyleyebiliriz. Fakat bir gerçek var ki, her ikisinde de ilerleme olması gerektiği kesin. Yazılım geliştirme tarafında ilerlemeler oldu. Örneğin yazılım mühendisliğinin üstüne, insan-bilgisayar etkileşimi (human-computer interaction), bilgi mühendisliği (knowledge engineering) ve bilgi yönetimi (knowledge management) gibi insanın öğrenme, algı ve tepki mekanizmalarını inceleyen, insana özel, kullanılabilir yazılımlar ve araçlar geliştirmeyi hedefleyen uzmanlıklar geliştirildi. Bununla birlikte, son kullanıcının beklentilerinin öncelendiği yazılım geliştirme metodolojileri (İş Temelli Analiz (Task Based Analysis), Kullanıcı Merkezli Tasarım (User Centered Design), vb) kullanılmaya başlandı. Artık elimizde, çok büyük veritabanları, tüm iş süreçlerini ve bu süreçlerde doğan bilginin yönetilebildiği bilgi sistemleri için daha uygun bir altyapı var. Bu nedenle bir yazılım projesinde yer aldığınızda, teknik kişilere “şu da mümkün mü?” diye sorduğunuzda, evet teknik olarak her şey mümkün, hatta Zeki Müren bile bizi görecek” diyeceklerdir. Buna mukabil, her ne kadar teknik kısıtlar ve sorunlar ortadan kalkmış gibi görünse de, hâlâ yazılım projelerinin başarı oranının düşüklüğü ortadadır. Benim de gelmek istediğim nokta tam da budur. Zira yazılım projelerinin önündeki artık teknik değil, psikolojik ve sosyal engeller var. Mühendislerse bu alanda yeterince eğitimli ve tecrübeli değiller. Diğer taraftan kullanıcıların da yazılımları bünyelerine dâhil etme konusunda hala direnç gösterdiğini söylemek lazım.

Söz konusu psikolojik ve sosyal engeller, modern yazılımların takip olduğu yeni misyondan ileri gelmektedir. Zira modern yazılımlar, son derece izafî bir kavram olan “bilginin yönetimine” talip olmaktadır. Dolayısıyla bilginin kime, ne zaman, hangi detayda ve hangi amaçla gösterileceği veya nasıl işleneceği gibi son derece “göreceli” konuların yazılım geliştiriciler tarafından bir şekilde çözümlenmesi gerekiyor. Bu konuda yazılan tüm kitapların tavsiye ettiği şey, son kullanıcıların mümkün olduğu kadar yazılım geliştirme sürecine dâhil edilmeleri ve küçük ve sonuçları hemen görülecek adımlarla ilerlemeleridir. Bugün yaşadığımız kullanılabilirlik sorunlarının merkezinde de bu eksiklik yatıyor diyebilirim.

AHBS, kim için, ne için?

Bu kısa izahattan sonra AHBS hakkında yapacağımız kritiğe dönecek olursak, öncelikle AHBS’nin yukarıda bahsettiğimiz çerçevede hangi tür yazılımlardan olduğunu tespit etmemiz lazım. AHBS, ilk nesil yazılımlar gibi işimizin bir kısmında kullanacağımız bir “araç” değil, hekimin günlük tüm işlerini planlamasına, yapmasına ve elde edilen bilgiyi yönetmesine yardımcı olacak bir klinik bilgi sistemidir. AHBS’nin kendi yerel veritabanı vardır; ancak her AHBS Internet aracılığı ile Sağlık Bakanlığı’ndaki veritabanı ile entegre olan büyük ve bütün bir ağın parçasıdır. Sağlık Bakanlığına gönderdiği veri setleri sayesinde bir kişisel Elektronik Sağlık Kaydı (ESK) oluşturması açısından da önemli bir e-sağlık projesidir. Diğer taraftan verilerin merkezi bir yerde toplanması ve ihtiyaca özel bilginin türetilmesine imkân sağladığı için de, hem idari hem de klinik anlamda merkezi ve taşra teşkilatları Karar Destek Sistemleri için bulunmaz bir bilgi kaynağıdır. Ayrıca ESK üzerine inşa edilebilecek onlarca farklı uygulamanın (laboratuar entegrasyonu, hastane randevu entegrasyonu, sevk sistemi, e-reçete, vatandaşlar için sağlık portali, evde bakım, vb) daha kolay hayata geçirilmesi için zemin oluşturan bir platformdur.

Yazılımların hayatımıza girmesi ile ilgili yukarıda kısaca anlatmaya çalıştığım süreçteki zorluklarla AHBS’nin geliştirme ve uygulanma sürecinde de karşılaşıldı. AHBS, bir araç değil, bilgiyi yönetmeye ve tüm ülkedeki aile hekimlerinin bağlı olacağı ortak bir ağın bir üyesi olmaya talip bir yazılımdı. Dolayısıyla önündeki engeller teknik değil, daha çok psikolojik ve sosyal engellerdi; ancak iş teknik bir proje olduğundan çözümler de büyük ölçüde teknik insanlardan bekleniyordu. Bu anlamda AHBS’nin bugünkü durumuna dari yapılacak her türlü eleştirinin temelinde, geliştirme sürecinde yeteri kadar son kullanıcı desteğinin olmamasına (bir şekilde olamamasına) ve kapsamı ile ilgili bazı belirsizliklere bağlayabiliriz.

AHBS gibi çok yönü ve hedefi olan bir projede, paydaşların AHBS ile ilgili farklı algılarının ve beklentilerinin olması gayet doğal. Ancak diğer yandan herkesin bütün resmi de görmeye çalışıp, projenin gövdesinin altına elini koyması da önemli bir gereklilik. Diyebilirim ki, bu algılar ve beklentiler çoğu zaman AHBS’nin mimarlarının başlangıçtaki vizyonunun altında kaldı ve teknik bazı yetersizliklerin de katkısıyla AHBS’den kısıtlı bir şekilde ve daha geç yararlanabilmemize neden oldu. Zira enerjinin önemli bir kısmı, teknik işlere değil, değişimi kabullenme ve yazılımları işimizin bir parçası haline getirme konusundaki psikolojik ve sosyal engelleri gidermeye ve tarafları projenin içine dâhil etmeye harcandı.

Bu enerji israfının neden olduğu gecikmelerin en dramatik örneği, AHBS’nin ilk ve kurumsal olarak en önemli amaçlarından birisi olan kâğıt ortamda bilgi toplama alışkanlığının terk edilmesiydi ki maalesef ancak 2010 Temmuzunda gerçekleşebildi. Açıkçası Sağlık Bakanlığı sitesinde Bakan Beyin konuyla ilgili genelgesini gördüğümde hem sevindim, hem de kamu içinde görünüşte çok kolay gibi görünen adımların atılmasının ne derece zor olduğu üzerinde derin düşüncelere daldım. Hâlbuki AHBS’nin en büyük ve ilk ortaya çıkacak faydalarından birisi bu kâğıt kürek işini ortadan kaldırmak olacaktı. Kanaatimce, AHBS’nin gerçek kullanıcısı olan merkez ve taşra teşkilatı ile aile hekimleri, uzunca bir süre AHBS’yi işlerinin ana unsuru (yardımcısı) olarak değil, tâli bir unsuru ve bir araç olarak gördüler. Proje çalışmalarını da teknik adamların kotarması gereken işlerden ibaret olarak değerlendirdiler. Bu tür gecikmelerin önemli nedenlerinden birisi budur. Ancak yukarıda da ifade ettiğim yumurta tavuk ilişkisi nedeniyle aynı gecikme, pek tabi ki AHBS’nin tarafların beklentilerini karşılayamamasına veya yeterince kullanılabilir olamamasına da mâl edilebilir. Şüphesiz herkesin kendi argümanları olacaktır ve kendine göre haklıdır. Ancak neticede AHBS’den beklenene göre daha geç faydalandığımız da ortadadır. Bu tür değişimler, mümkün olsa elbette daha erken yapılacaktı; ancak bize düşen süreci bu kadar uzatan etmenleri de iyi değerlendirmek ve bundan sonraki çalışmalarda dikkate almaktır. Her durumda böylesine bir uygulamanın bu kadar çok kullanıcıyla, bu kadar yaygın bir coğrafyada kullanılmasının dünyada başka bir örneğinin olmadığını da ifade ederek, tüm tarafların hakkını teslim etmek lazım. Burada işaret istediğim husus, vizyoner anlamda çok yüksek ve erişilebilir hedeflerin realize edilmesinin sanıldığı kadar kolay olmadığıdır.

AHBS’nin Gelişim Süreci

AHBS’nin gelişim sürecini kendi bağlamı içinde değerlendirmeliyiz. 2005’lerde aile hekimlerinin görev kapsamının dahi tartışma konusu olduğunu hatırlayalım. İş sürecinin bir parçası olmaya ve bilgiyi yönetmeye aday bir yazılım geliştirirken bu durumun ne kadar büyük bir zorluk çıkartacağı açıktır. Buna bir de, yukarıda değinmeye çalıştığım üzere, kullanıcı ve yazılımcı tarafındaki değişim ve gelişim ihtiyacı eklendiğinde, AHBS gerçekten zorlu bir yoldan geçmiştir. Buna rağmen başarılı bir sonuç elde edildiğini söyleyebiliriz.

Sağlık Bakanlığının yüklenici bir firmaya ihale yoluyla yazdırdığı AHBS, 2005 yılındaki ilk sürümü olan 1.0’dan sonra sırasıyla 2006’da 2.0 ve 2007’de de 3.0 sürümleri ile meydana çıktı. Aile hekimliği uygulaması netleştikçe ve değiştikçe AHBS de ortama uyum sağlamaya çalıştı ve kervan yolda dizildi. 2007 yılında yayınlanan AHBS 3.0 sürümü ile birlikte Bakanlığa gönderilecek verilere bir standart getirildi ve bunlar ilan edildi. Bu sayede ilk defa 2007 yılı sonlarına doğru özel sektörün geliştirdiği AHBS’leri görmeye başladık. Başlangıçta genellikle eski Sağlık Ocağı otomasyon programlarından uyarlanmış olan bu programlar, sonraları daha özgün ve kullanışlı hale gelerek kalitenin artmasına çok önemli katkı sağladılar.

AHBS ilk defa 2007 yılında standart bir veri gönderme yapısı üzerine oturdu ve bu sayede merkezdeki verileri kullanan ilk Karar-Destek Sistemi de 2007 yılında hayata geçti. Ardından aynı yıl AHBS ile laboratuar ve hastane randevu entegrasyonu da tamamlandı ve talep eden bazı illerde uygulaması yapıldı. Yine aynı yılın sonunda bir konsept çalışması olsa da AHBS’de mobil imza uygulaması yapıldı ve Sağlık Bakanlığının 2007 yılındaki eSağlık kongresinde canlı sunumu yapıldı. Buna göre, aile hekimine gelen bir hastanın sağlık verilerine erişmek için hastanın mobil imza ile onay vermesi isteniyordu. İmzanın ardından Sağlık Bakanlığındaki verilere aile hekimi erişebiliyordu.

AHBS ve Sağlık-NET

2005-2007 arasındaki bu hızlı ilerleyiş, Sağlık-NET çalışmalarının başlamasıyla biraz hız kesti. Zira Sağlık-NET’in devreye alınmasından hemen sonra AHBS ile entegre olması ve tüm sağlık kurumlarının ortak bir ağı kullanması planlanıyordu. Bu nedenle çalışmalar Sağlık-Net üzerine yoğunlaşmıştı. Hazırlıkları 2006 yılında başlayan Sağlık-NET vizyon olarak AHBS ile aynı olan, ama sadece aile hekimlerini değil, hastaneleri de kapsayan bir sistemin adıdır. AHBS, bu yönü itibariyle Sağlık-NET için bir prototip ve pilot uygulaması rolü oynamıştır. AHBS’de edinilen tecrübeler Sağlık-NET’te kullanılmış ve Türkiye’de sağlık bilişimi alanında önemli standardizasyon çalışmaları yapılmıştır. Ulusal Sağlık Veri Sözlüğü (USVS) ve Sağlık Kodlama Referans Sunucusu (SKRS) bunların başlıcalarıdır. Sağlık-NET’in de kendi Karar-Destek Sistemi vardır ve AHBS ile entegre olduğunda her ikisinin de tek başlarına sağlayacağı katma değerler katlanarak artacaktır.

Sağlık bilgi sistemlerinde merkezi ve yerel yaklaşımlar

Sağlık Bakanlığı, AHBS ile başlattığı ve Sağlık-NET’le tüm sağlık hizmetini kapsayan bir bilgi ağı kurma projesini ilerletirken, taşra teşkilatında da veriyi il çapında toplamayı hedefleyen eğilimler ortaya çıkmaya başladı. 2007 yılında görmeye başladığımız özel sektörün AHBS yazılımları, ifade ettiğim üzere, başlangıçta sağlık ocağı otomasyonlarından uyarlanan çözümler olduğundan, bazı sağlık ocağı alışkanlıklarını da aile hekimliğine taşıdılar. Bunlar arasında en önemlisi, AHBS ile verileri Sağlık Bakanlığı’na gönderiyorken, eskiden olduğu gibi İSM’ye de göndermeye devam etmeleriydi. Bu durum zaman içinde İl Sağlık Otomasyonu oluşturma fikrinin ortaya atılmasına neden oldu. Aslında İSM’lerin keşfettiği şey, Sağlık Bakanlığının çok önce keşfedip hayata geçirmekte olduğu Sağlık-NET fikrinin, İSM çapında yapılmasından başka bir şey değildi. Nitekim İSM’ler bu tür yazılımlar alırken, maksatlarının ilin sağlık yönetimini doğrudan veriye ulaşarak daha etkin yapmak olduğunu ifade ediyorlar. Hâlbuki bu amaç, Sağlık Bakanlığının SDP’de ifade ettiği “karar sürecinde etkili bilgiye erişim” amacıyla aynıydı ve önce AHBS, sonra da Sağlık-NET sadece Bakanlığın değil, tüm Türkiye'nin bu faydaya ulaşması için yapılmaktaydı. Bu nedenle bu tür talepler, Sağlık Bakanlığının politikalarına uygun değildi. Ancak Bakanlık başlangıçta İl Sağlık Otomasyonlarına karşı çıksa da, sahadan gelen talepleri de sönümlendirmemeyi ve onlara fırsat tanımayı tercih ederek, bu girişimleri engellemedi. Bu sayede, bir şekilde bu tür çözümlerin faydası ve zorlukları da tecrübe edildi. Benim kişisel kanaatim, aynı amaca hizmet eden farklı yaklaşımların eş zamanlı olarak varlığını sürdüremeyeceği ve birbirine olumsuz etkileyecekleri şeklindedir. Zira bu durum, “iki uçtan tünel kazmaya başlayalım, ortada buluşamazsak iki tünelimiz olur” anlayışı ile yönetilecek bir durum değildir. Bu örnekten yola çıkacak olursak, bize yük taşımasını istediğimiz kamyonların istediği tünelden değil, her iki tünelden de geçmesini beklemekteyiz. Bu durumda bir süre sonra bu anlamsız talep nedeniyle tünellerden biri atıl kalmaya mahkûm olacak ve sadece biri kullanılacaktır. Bu nedenle, her ne kadar yerel yönetimlerinin ihtiyaçları merkezinkinden farklı görünse de, temelde ihtiyaç duyulan tüm bilgilerin neredeyse aynı verilerden (veri setlerinden) elde edilebildiğini düşünüyorum. Dolayısıyla Bakanlığın topladığı verilerden yeterli miktarda ve içerikte rapor alınabilmesi halinde İSM ve TSM’lerin ihtiyaçları büyük oranda karşılanabilecek ve bu ikinci tünele gerek kalmayacaktı. Ancak belki farkındalık azlığı belki de beklentilerin yeterince karşılanamaması bazı İSM’leri bu yola sevk etti. Her durumda bu gelişmeler, bize tecrübe ederek değerlendirme yapma imkânı sağlamıştır. Ancak şu kadarını söyleyebilirim ki, münferit başarılı örnekleri olsa da her iki sistemin bir arada ve başarıyla çalışması sürdürülebilir değildir. İSM’lerin bilgi talepleri iyi bir şekilde analiz edilerek, bu ihtiyacın merkezdeki verilerden etkin bir şekilde karşılanması daha doğru ve daha az maliyetlidir.

Elimizdeki değerin farkında mıyız?

Bugün AHBS ile elde edilmiş çok büyük bir hazinenin üzerinde oturuyoruz. Bunların başında da Elektronik Sağlık Kaydı (ESK) geliyor. Öyle ki, kişisel sağlık dosyası ile 5 yıldır toplanan veriler üzerinde yapılabilecek araştırmaları hayal etmek bile zor. Hastalık yükleri, tedavi eğilimleri, tedavi süreçleri ve maliyetleri, eşlik eden hastalık istatistikleri, sağlığın demografik dağılımı, vb yüzlerce gösterge elde edilebilir durumda. Özellikle 2007 Mayıs ayından itibaren protokol defterlerinin kaldırılıp, protokol defteri çıktılarının gerektiğinde AHBS ile kaydedilip Bakanlığa gönderilen muayene verilerden elde edilmeye başlanmasının ardından, temel muayene ve reçete verilerinin sağlıklı bir şekilde Bakanlığa ulaştığını söyleyebiliriz.

Bu verilerin, bir portal üzerinden güvenli bir erişimle kişilerin erişimine açılması durumunda sağlanacak vatandaş memnuniyetini düşünelim. Ardından kişilerin kendi sağlık verilerinin bir kısmın kendilerinin de bu portal üzerinden sisteme aktarabilmeleri ve hekimleri ile bu portal üzerinden haberleşebilmeleri… Bütün bunlar AHBS ve Sağlık-NET’in birleşmesi ile elde edilmesi beklenen faydalar arasında. Halen pilotu yapılan Merkezi Hastane Randevu Sistemi de bu portalle entegre olacak ve portal hem randevu hem de kişisel sağlık verilerine erişmeye imkân sağlayacaktı. Bunların, gelişmiş ülkelerin dahi “keşke yapabilsek” dediği türden işler olduğunu vurgulamak isterim. Biz pek çoğunu başardık, daha iyisine ise çok yaklaştık.

Burada üzerine yoğunlaşılması gereken şey, AHBS ve Sağlık-Net’in entegre edilmesi ve eldeki ESK’dan mümkün olduğu kadar karar sürecinde bilgi elde etmektir. Şüphesiz yaklaşan seçimler bu süreci etkileyecektir; ancak ben bunların başarılabileceğine inanıyorum.

(1)   Moore, Gordon E. (1965). "Cramming more components onto integrated circuits". Electronics Magazine. pp. 4.