2025 yılında bir tıp merkezinde göreve başladığımda bilgi işlem odasına ilk girişimi hâlâ hatırlıyorum. Sunucular bir kabinin içinde değil, açıkta ve korumasız duruyordu. Üzerlerinde kurumun hasta kayıt sistemi, radyoloji PACS sistemi, muhasebe verileri ve tüm iş uygulamaları çalışıyordu; ancak bu verilerin hiçbir yedeği yoktu. Sanallaştırma yoktu, izleme yoktu, bir arıza anında neyin ne kadar sürede geri geleceğini kimse bilmiyordu. Bu tablo, Türkiye’de pek çok özel sağlık kurumunun bilgi işlem gerçeğinden çok da farklı değil: sistem çalıştığı sürece kimse ona bakmaz, çalışmadığı gün ise herkes bakar.
Bu yazıda o günden bugüne attığımız adımları, hangi sırayla ve neden attığımızı anlatacağım. Amacım bir teknik kurulum rehberi yazmak değil; benzer bir tabloyla karşı karşıya olan hastane ve tıp merkezi yöneticilerine, sınırlı bütçe ve sınırlı ekiple bile bu dönüşümün nasıl planlanabileceğini göstermek ve bu dönüşümün büyük bölümünü yapay zekâ desteğiyle tek başıma nasıl yaptığımı anlatmak.
Nereden başlamalı?
Böyle bir tabloda ilk refleks genellikle “önce yedek alalım” olur. Ben de öyle düşündüm, ama bir adım geri çekilince şunu gördüm: fiziksel sunucu üzerinde doğrudan çalışan bir sistemin yedeğini almak, aslında yalnızca dosyaları kopyalamaktır. O sunucu bir sabah açılmadığında elinizde dosyalar vardır ama işletim sistemini, veritabanını, lisansları ve yapılandırmayı sıfırdan kurmanız gerekir. Bu da iyi ihtimalle günler demektir; bir sağlık kurumunda ise poliklinik kapısında bekleyen hastalar demektir.
Bu yüzden ilk adım yedekleme değil, sanallaştırma oldu. Proxmox’u devreye alıp mevcut sistemleri sanal makineler hâline getirdiğimizde her uygulama, donanımdan bağımsız ve bütün olarak taşınabilir bir dosyaya dönüştü. Artık yedek dediğimiz şey bir klasör değil, dakikalar içinde başka bir sunucuda ayağa kaldırılabilen çalışır bir sistemdi. Ancak bu sanal makinelerin kaydedileceği, sunuculardan bağımsız ve güvenilir bir depolama alanı gerekiyordu; TrueNAS kurulumu tam bu ihtiyaçtan doğdu ve kurumun tarihindeki ilk düzenli yedekleme süreci böylece başladı.
Sıralamanın mantığı şuydu: önce veriyi taşınabilir hâle getir, sonra onu güvenli bir yere koy, ancak ondan sonra donanıma ve fiziksel ortama dokun. Çünkü kabin kurmak, kablo çekmek ve sunucu taşımak kaçınılmaz olarak kesinti demektir; bu kesintiye, elinizde geri dönebileceğiniz bir kopya olmadan girilmez.
Fiziksel altyapı: görünmeyen temel
Sanallaştırma ve ilk yedekler sayesinde artık elimizde geri dönebileceğimiz bir kopya vardı; fiziksel ortama dokunma zamanı gelmişti. Burada yapılanlar dışarıdan bakınca en az “teknolojik” görünen işlerdi, ama kurumun bilgi işlem güvenliğine en çok katkı sağlayan adımlar da bunlardı.
İlk iş, sunuculara bir ev vermekti. Açıkta duran bir sunucu yalnızca toz ve ısı sorunu değildir; herkesin erişebildiği, kablosuna takılabildiği, üstüne bir şey koyabildiği bir cihazdır. Standart bir sunucu kabini kurup tüm donanımı içine taşıdığımızda hava akışı düzene girdi, kablolar etiketlenip toplandı ve en önemlisi fiziksel erişim kilit altına alındı. Bir sağlık kurumunda hasta verisinin bulunduğu cihaza kimin dokunabileceğini belirlemek, KVKK açısından da teknik bir tercih değil bir zorunluluktur.
İkinci iş, yeni donanımdı. Eski makinelerin üzerine yeni bir yük bindirmek yerine iki yeni sunucu aldık: biri sanallaştırma için kurumun önümüzdeki yıllardaki ihtiyacını karşılayacak güçte bir uygulama sunucusu, diğeri yalnızca depolama ve yedekleme için ayrı bir TrueNAS sunucusu. Bu ayrımın arkasındaki mantık basitti: işlem gücü ile veriyi aynı kutuda tutmamak. Uygulama sunucusu bir gün çökse bile veri başka bir makinede, sağlam biçimde duruyor. Sanallaştırma sayesinde tek bir güçlü sunucu, eskiden ayrı makinelerde koşan tüm işi üstlenebiliyor; daha az cihaz, daha az arıza noktası, daha az elektrik ve daha kolay bakım demek.
Üçüncü iş, ağ altyapısının yenilenmesiydi. Yıllar içinde ihtiyaç oldukça çözüm üretilmiş bir ağ, odaların köşelerine sıkıştırılmış küçük switch’lerle büyümüş, kimsenin tam haritasını bilmediği bir yapıya dönüşmüştü. Bu ara switch’lerin her biri bir yavaşlama ve arıza noktasıydı. Hepsini söktük; ihtiyaç duyulan her noktaya kat switch’lerinden doğrudan kablo çektik, sorunlu hatları tespit edip değiştirdik ve her uç noktayı adresleyip etiketledik. Ağın merkezine yönetilebilir bir Layer 2 switch koyduk, kat switch’lerini de bu omurgaya göre yeniden yapılandırdık. Sonuçta tüm ağ uçtan uca 1 Gbps hızında çalışır hâle geldi. Yönetilebilir switch’in bir yöneticiye anlamı şudur: ağ artık kör bir kutu değil; hangi portta ne olduğunu görebilir, bir cihazı uzaktan izole edebilir, ileride farklı birimleri ayrı ağ segmentlerine bölebilirsiniz. Bu adımın somut karşılığı, bir poliklinikte bilgisayar ağa bağlanamadığında sorunun dakikalar içinde bulunmasıdır; eskiden bu bazen yarım günlük bir aramaydı.
Dördüncü iş, kurumun dış dünyayla sınırıydı. Göreve başladığımda internet bağlantısı modemin kendi basit güvenlik ayarlarıyla korunuyordu; kurumun kendine ait bir güvenlik duvarı yoktu. Eski sunuculardan birine açık kaynaklı OPNsense güvenlik duvarını kurarak bu boşluğu kapattık. Artık iç ağ ile internet arasındaki tüm trafik tek bir noktadan geçiyor, hangi servisin dışarıya açık olduğu kurallarla tanımlı, şüpheli trafik kayıt altında. Aynı cihaz bir başka yapısal sorunu da çözdü: bulunduğumuz bölgede fiber altyapı olmadığı için kurum VDSL hatlarına mahkûmdu ve tek bir hat koptuğunda hastane bilgi sistemi, PACS ve çağrı merkezi aynı anda dışarıya kapanıyordu. İki VDSL hattını sürekli ve birlikte kullanılacak, bir 4,5G modem bağlantısını ise bunlar düştüğünde kendiliğinden devreye girecek şekilde yapılandırdık. Sonuç, fiber olmayan bir bölgede bile kesintisiz sayılabilecek bir bağlantı: hatlardan biri koptuğunda kullanıcı bunu fark etmiyor.
Sanallaştırmanın tamamlanması ve yedekleme stratejisinin kapanması
Göreve başladığımda üç eski sunucu vardı. Biri o kadar yaşlıydı ki hiç kullanmadık; biri yukarıda anlattığım güvenlik duvarına ev sahipliği yaptı; üçüncüsünü ise yeni sunucuya taşıdığımız sistemler boşa çıkardıktan sonra ikinci bir Proxmox düğümü olarak sıfırdan kurduk. Böylece dün tek bir uygulamayı taşıyan ve her an çökebilecek bir makine, bugün yük paylaşımı yapan ve ana sunucudaki sanal makinelerin ihtiyaç anında taşınabildiği bir hedef hâline geldi. Yöneticiler için buradaki mesaj önemli: sanallaştırma eski donanımı çöpe atmanızı değil, ona yeni bir rol vermenizi sağlar.
İki düğümün bir arada yönetilmesi için bunları tek bir küme (cluster) altında birleştirdik. Ancak iki düğümlü bir kümenin bilinen bir zaafı vardır: düğümler birbirini göremediğinde hangisinin “haklı” olduğuna karar verecek bir çoğunluk oluşmaz. Bu yüzden üçüncü ve çok hafif bir düğüm ekledik; bu düğüm depolama sunucusu üzerinde sanal olarak çalışır, üzerinde hiçbir uygulama barındırmaz, tek görevi oylamaya katılıp kümenin karar alabilmesini sağlamaktır. Ek bir donanım maliyeti olmadan, küme artık tutarlı ve kendi başına karar verebilen bir yapı.
Bu kümenin üzerinde bugün kurumun bütün omurgası sanal olarak çalışıyor: hastane bilgi yönetim sistemi ve veritabanı, radyoloji PACS sunucusu, personel devam kontrol sistemi, iç web uygulamaları ve ileride anlatacağım izleme ve otomasyon araçları. Her biri donanımdan bağımsız, taşınabilir ve bütün olarak yedeklenebilir birer dosya.
Yedekleme tarafında ise iki katmanlı bir yapı kurduk. Birinci katman depolama: ayrı donanım üzerindeki ana TrueNAS sunucusu kurumun merkezi veri havuzu ve paylaşımlarını tutar; sanallaştırma kümesi üzerinde çalışan ikinci bir TrueNAS ise bu verinin düzenli olarak çoğaltıldığı ve ek kapasite sağlayan ikincil birimdir. Böylece aynı veri her zaman iki farklı donanımda durur; tek bir depolama cihazına güvenmek, tek bir sunucuya güvenmekten farksızdır. İkinci katman ise Proxmox Backup Server: tüm sanal makinelerin zamanlanmış olarak, yalnızca değişen kısımlarıyla yedeklendiği, yedeklerin bütünlüğünün düzenli olarak doğrulandığı ve ihtiyaç anında bir sanal makinenin tek tıkla, dakikalar içinde geri döndürülebildiği sistem. Kurumun yedekleme politikası artık bir kişinin hatırlamasına bağlı değil; zamanlanmış, doğrulanan ve raporlanan bir süreç.
Sunucuları korumak işin yarısıydı; diğer yarısı kullanıcı bilgisayarlarındaydı. Bir sağlık kurumunda kurumsal hafızanın hiç de küçük olmayan bir kısmı sunucularda değil, masaüstlerinde durur: muhasebenin yıllardır biriktirdiği Excel dosyaları, yönetimin yazışmaları, laboratuvarın raporları, radyolojinin dışa aktardığı görüntüler. Bu bilgisayarlardan birinin diski bozulduğunda ya da bir fidye yazılımı bulaştığında kaybolan şey, kimsenin yedeğini almadığı o verilerdir. Bu riski kapatmak için her kritik bilgisayarın masaüstü ve belgeler klasörlerini, kullanıcı hiçbir şey yapmadan, sürekli olarak depolama sunucusuna eşitleyen açık kaynaklı bir araç kurduk. Bugün yönetimden muhasebeye, laboratuvardan radyolojiye kadar kritik bilgisayarların tamamında dosya değiştiği anda merkeze kopyalanıyor; muhasebe, PACS ve personel devam sisteminin yedekleri de aynı düzenle korunuyor. Bir bilgisayar yarın tamamen kaybedilse, kullanıcı yeni makinesinde oturum açtığında dosyalarını olduğu gibi bulur.
Aynı depolama sunucusu üzerinde birim bazlı paylaşım alanları da kurduk: hasta hizmetleri, idari birimler, yönetim ve bilgi işlem için ayrı ayrı yetkilendirilmiş klasörler. Eskiden flash bellekle ya da e-postayla dolaşan dosyalar artık tek bir merkezde, erişimi tanımlı ve yedeklenen bir alanda duruyor. Bunun yöneticiye anlamı şudur: kurumun verisi artık “kimin bilgisayarında” sorusuyla değil, “hangi birimin alanında” sorusuyla bulunur.
Göreve başladığım gün sorulamayan soru nihayet cevaplanabilir hâle geldi: “Bu sunucu yarın açılmazsa ne olur?” Cevap: sanal makineler ikinci düğüme taşınır ya da yedekten dakikalar içinde ayağa kalkar.
Görmek, ölçmek, otomatikleştirmek
Altyapı ayağa kalktıktan sonra sıradaki soru şuydu: bu sistemin sağlıklı çalışıp çalışmadığını nasıl bileceğiz? Göreve başladığımda bir sorun ancak bir kullanıcı şikâyet ettiğinde öğreniliyordu. Hedef, sorunu kullanıcıdan önce görmekti.
İlk adım görmekti. Ağa bağlı her cihazı keşfedip çevrimiçi durumunu izleyen hafif bir araç kurduk. Bugün ağdaki 63 cihazın tamamı, hangi katta ve hangi birimde olduğu belli olacak şekilde isimlendirilmiş durumda; hangi cihazın ne zaman çevrimdışı kaldığı, hangi IP’nin hangi cihaza ait olduğu geçmişe dönük tutuluyor. Ağa yetkisiz bir cihaz bağlandığında bunu ilk fark eden artık biziz. Aynı katmanda Zabbix, sunucuların, servislerin ve ağ cihazlarının merkezi izlemesini yapıyor: bir disk dolmaya başladığında, bir servis cevap vermez olduğunda ya da bir sunucunun sıcaklığı yükseldiğinde kimse şikâyet etmeden önce uyarı geliyor.
İkinci adım ölçmekti. Anlık uyarı yeterli değildir; bir yöneticinin asıl ihtiyacı eğilimi görmektir. Bu yüzden tüm ölçümleri zaman serisi olarak InfluxDB’de biriktiriyor, Grafana ile panolara dönüştürüyoruz. Depolama alanının aylar içinde nasıl dolduğunu, hangi saatlerde sistemin yüklendiğini, hangi sanal makinenin kaynak tükettiğini grafikte görmek, bir sonraki donanım yatırımının ne zaman ve ne büyüklükte olacağını tahminle değil veriyle planlamak demek.
Üçüncü adım otomatikleştirmekti. Docker ile konteyner tabanlı bir uygulama sunucusu kurduk; bu sunucu üzerinde iç uygulamalar birkaç dakikada kurulup kaldırılabiliyor, birbirinden yalıtılmış çalışıyor ve tek bir arayüzden yönetiliyor. Tüm iç servislere tek bir giriş noktasından, sertifikalı ve düzenli adreslerle erişimi bir ters vekil sunucu sağlıyor. Yine aynı zeminde bir kurumsal doküman uygulaması ve yapay zekâ destekli bir fiyat sorgulama asistanı çalışıyor.
Bu zeminin üzerinde n8n ile iş akışı otomasyonu kurduk ve en çok fark yaratan uygulama, izleme verisinin yapay zekâ ile birleşmesi oldu. Her sabah Zabbix ve InfluxDB’den toplanan ölçümler bir yapay zekâ modeline iletiliyor; model bunları bir yöneticinin okuyabileceği günlük bir sağlık raporuna dönüştürüp e-posta ile gönderiyor. Ayrı bir “kritik sistem nöbetçisi” akışı ise her iki kaynağı birlikte izleyip yalnızca gerçekten müdahale gerektiren durumlarda uyarı üretiyor. Böylece ham grafiklere bakmak yerine sabah “dün gece her şey yolundaydı, yalnızca şu diskin doluluğu yüzde seksene yaklaştı” diyen bir paragraf okuyorum. Aynı mantıkla reklam kampanyalarının günlük performans özeti ve sosyal medya için aylık paylaşım planı taslakları da otomatik üretiliyor (dijital pazarlama konusundaki hikayeyi çok yakın bir zamanda ayrı bir yazıda ele alacağım); insan eliyle saatler alan hazırlık işleri, artık onaylanmayı bekleyen hazır çıktılar hâline geldi.
Altyapının kendisi kadar, onun üzerinde kurumun günlük işleyişine dokunan küçük uygulamalar da bu dönüşümün parçası oldu. Koridorlardaki büyük ekranlar eskiden her biri ayrı ayrı, USB bellekle güncellenen bağımsız televizyonlardı; bugün tamamı bulut tabanlı bir dijital tabela sistemiyle tek merkezden yönetiliyor. Hangi ekranda hangi içeriğin kaç saniye gösterileceği tek bir panelden planlanıyor; hekim listesi ve çalışma saatleri, kampanya duyuruları ve bilgilendirme görselleri dakikalar içinde bütün binaya yayılıyor. Ekranlardan biri ise tamamen kendi geliştirdiğimiz canlı bir bilgi ekranı: güncel döviz ve altın kurları, hava durumu ve haber akışı, bekleme alanındaki hastalara anlık olarak sunuluyor. Yine aynı dönemde hekim izinlerinin takibi için küçük bir program yazdık; eskiden telefonla ve kâğıtla yürüyen, kimin ne zaman izinli olduğunun randevu planlamasına geç yansıdığı bir süreç, artık tek bir kayıt ekranından yönetiliyor. Bunların hiçbiri büyük yatırımlar değil; ama hepsi aynı zeminden, aynı sanal altyapıdan ve aynı ağdan güç alıyor. Altyapı doğru kurulduğunda bu tür ihtiyaçlar birer proje olmaktan çıkıp birkaç günlük işlere dönüşüyor.
Bütün bunların üzerine, hangi sunucuda hangi servisin çalıştığını, hangi adresten erişildiğini ve ne işe yaradığını tek sayfada gösteren bir servis panosu hazırladık. Bu pano küçük bir ayrıntı gibi görünebilir, ama kurumsal hafızanın tek bir kişinin aklında değil belgede durması, bu dönüşümün belki de en kalıcı kazanımı.
Bütün bunları kim yaptı?
Buraya kadar anlattıklarımı okuyan bir yönetici muhtemelen şunu merak ediyor: bu dönüşüm için kaç kişilik bir ekip, hangi firmalar, ne kadar bütçe gerekti? Dürüst cevap şu: hastane bilgi yönetim sisteminin tedarikçisinin kendi tarafında yaptığı iş dışında, bu yazıda anlattığım kurulum ve yapılandırmaların tamamını tek başıma yaptım. Bunu bir övünme olarak yazmıyorum; bu işin nasıl mümkün olduğunu anlatmak istiyorum, çünkü cevap benzer durumdaki yöneticiler için önemli.
Yirmi yılı aşkın süredir sağlık sektöründeyim ve bu yolculuğa bilgi işlemden başladım; ilk hastanemde hem yönetici hem de bilgi işlem sorumlusuydum. Bir sistem mühendisi değilim, ama bir sunucunun, bir ağın ve bir hastane bilgi sisteminin nasıl çalıştığını yıllardır içeriden biliyorum. Bunun kadar önemli bir başka şey daha var: açık kaynak dünyasını uzun süredir takip ediyorum. Proxmox, TrueNAS, OPNsense, Zabbix ya da n8n gibi araçların varlığını, nerede güçlü ve nerede zayıf olduklarını, hangisinin bir tıp merkezinin ölçeğine uyduğunu bu dönüşüme başlamadan önce biliyordum. Bu yazıdaki mimariyi, sıralamayı ve araç seçimlerini yapan bu birikimdi.
Ancak bilmekle yapmak arasında her zaman bir boşluk vardır. Bir sanallaştırma kümesinin nasıl çalışması gerektiğini bilmek başka, gece yarısı çoğunluk kaybeden kümeyi ayağa kaldırmak başka şeydir. Birkaç yıl önce olsa bu boşluğu tek başıma kapatmaya cesaret edemezdim; kalkışsam aylar sürerdi. Nitekim işe başlarken bu kurulumlar için firmalardan teklif aldık ve karşılaştığımız rakamlar bir tıp merkezinin bilgi işlem bütçesinin çok üzerindeydi.
Bu boşluğu kapatan şey büyük dil modelleri oldu. Her kurulumda, her yapılandırmada ve her hata mesajında yanımda sabırla soru cevaplayan, gece saat ikide bile erişilebilen, yanlış yaptığımda beni uyaran üst düzey bir uzman vardı. Ben neyin, neden ve hangi sırayla yapılacağını biliyordum; yapay zekâ bunun nasıl yapılacağını, komut komut ve hata hata benimle birlikte çalıştı. İki VDSL hattının OPNsense üzerinde nasıl dengeleneceğini ya da ZFS çoğaltmanın nasıl kurulacağını ders kitabından değil, kendi sistemimin üzerinde adım adım sorarak uyguladım.
Abartmamak gerekir. Yapay zekâ bazen yanlış cevap verir ve bu yanlışı ancak konuyu bilen biri fark eder; her adımı önce ayrı bir deneme ortamında test ettim, canlı sisteme dokunmadan önce yedek aldım ve anlamadığım hiçbir komutu çalıştırmadım. Sorumluluk hâlâ insana aittir ve HBYS gibi tedarikçi bağımlı alanlarda firmanın işini firmaya bırakmak doğru olandır. Ama şunu açıkça söyleyebilirim: bilgi işlem alanında bir şeyler gerçekten değişti. Uzmanlık ortadan kalkmadı; uzmanlığa erişimin maliyeti düştü. Alanını bilen, ne istediğini tarif edebilen ve öğrenmeye zaman ayırmaya hazır bir yönetici, bugün bu dönüşümü kendi kurumunda başlatabilir. Birkaç yıl önce bu cümleyi kurmak mümkün değildi.
Önce ve sonra: bir yöneticinin çıkardığı dersler
Yola çıktığımız noktayla bugünü yan yana koyduğumda şunu görüyorum. Önce: açıkta duran sunucular, hiç alınmamış yedek, sanallaştırmasız bir yapı, güvenlik duvarsız ve tek hatta bağlı bir internet, kimsenin haritasını bilmediği bir ağ ve ancak şikâyet geldiğinde öğrenilen arızalar. Sonra: kilitli bir kabin, uygulama ile verinin fiziksel olarak ayrıldığı iki yeni sunucu, üç düğümlü bir sanallaştırma kümesi, iki katmanlı ve doğrulanan bir yedekleme düzeni, masaüstlerine kadar inen veri koruması, kendi güvenlik duvarı ve yedekli internet bağlantısı, uçtan uca 1 Gbps çalışan belgeli bir ağ, 63 cihazın anlık izlendiği bir görünürlük katmanı ve her sabah masama gelen yapay zekâ destekli bir sistem raporu.
Bu süreçten benzer bir tabloyla karşılaşan yöneticilere aktarmak istediğim birkaç ders var.
Birincisi, sırayı doğru kurmak bütçeden daha önemlidir. Önce veriyi taşınabilir hâle getirin, sonra güvenli bir yere koyun, ancak ondan sonra fiziksel ortama dokunun. Bu sıra ters kurulduğunda her adım bir öncekini riske atar.
İkincisi, işlem gücü ile veriyi aynı kutuda tutmayın. Uygulama sunucusu çökebilir, değiştirilebilir; verinin başka bir makinede duruyor olması, kurumun en kötü gününde fark yaratan tek şeydir.
Üçüncüsü, eski donanımı hemen gözden çıkarmayın. Sanallaştırma sayesinde dün risk olan bir makine bugün güvenlik ağının ya da güvenlik duvarının parçası olabilir.
Dördüncüsü, ağ görünmez bir temeldir. Köşelere sıkıştırılmış küçük switch’ler, etiketlenmemiş kablolar ve bilinmeyen hatlar, en pahalı sunucuyu bile yavaş ve güvenilmez kılar.
Beşincisi, görmediğiniz sistemi yönetemezsiniz. İzleme bir lüks değil yönetim aracıdır; sorunu kullanıcıdan önce görmek, bilgi işlemi arıza birimi olmaktan çıkarıp planlama birimi yapar.
Altıncısı, belgeleyin. Hangi sunucuda ne çalıştığını tek bir kişinin bildiği bir kurum, o kişi kadar kırılgandır.
Yedincisi, yapay zekâ bilgiyi değil, bilgi ile uygulama arasındaki boşluğu kapatır. Alanını bilen bir yönetici, doğru soruları sorabildiği sürece birkaç yıl önce ancak dışarıdan satın alabileceği işleri kendi kurumunda yapabilir; yeter ki test etmeden canlıya dokunmasın.
Son olarak, bu dönüşümün yazılım tarafının tamamı açık kaynaklı araçlarla kuruldu: Proxmox, TrueNAS, OPNsense, Zabbix, InfluxDB, Grafana, Docker ve n8n. Lisans maliyeti sıfıra yakın; yatırımın büyük kısmı donanıma ve en önemlisi zamana gitti. Sınırlı bütçeli bir sağlık kurumunun bu dönüşümü yapamaması için teknik ya da mali bir engel yok; engel çoğu zaman sıranın ve önceliğin yanlış kurulmasıdır.
Bu dönüşüm bitmiş bir proje değil, sürekli bakım isteyen bir düzen. Ancak artık “bu sunucu yarın açılmazsa ne olur” sorusunun cevabı bilinmiyor değil; bu da bir sağlık kurumunda bilgi işlemin varlık sebebidir.
