Denetimin ikinci günü, öğleden sonra. Denetçi doküman kontrolünü inceliyor, ekranda revizyon geçmişini görüyor ve tek cümle kuruyor: "Bu yazılımın validasyon dosyasını görebilir miyim?" Masaya satıcının tanıtım sunumu ile bir teknik şartname konuyor. İkisi de cevap değil. Firma yazılımı iki yıldır kullanıyor, yüzlerce kayıt üretmiş, ama tek bir test senaryosu kaydı yok. Yazılım validasyonu ISO 13485 denetimlerinde en sık bulgu yazılan başlıklardan biri ve nedeni genelde ihmal değil, yanlış varsayım: satıcının dosyasının yeterli olacağının sanılması.
Standart tam olarak ne istiyor?
ISO 13485:2016, kalite yönetim sisteminde kullanılan bilgisayar yazılımlarının uygulanmasının valide edilmesini ister; bunu 4.1.6 maddesinde tanımlar. Aynı standart üretimde ve izleme-ölçmede kullanılan yazılımlar için de ayrı validasyon şartları koyar. Buradaki anahtar kelime "uygulanmasının" kelimesidir. Yazılımın kendisi değil, sizin kullanım biçiminiz valide edilir.
Bunu somutlaştırayım. Satıcı, doküman onay akışının çalıştığını kendi test ortamında göstermiş olabilir. Ama sizin kurulumunuzda onay iki kademeli, ikinci onaycı kalite müdürü, üçüncü kademe atlanabiliyor ve belirli doküman tipleri onaysız yayınlanabiliyor. İşte bu yapılandırmanın istediğiniz gibi çalıştığını gösteren kanıt sizden istenir. Bilgisayarlı sistem validasyonu (computer system validation, CSV) dediğimiz iş budur.
Yazılım validasyonu ISO 13485 ile sınırlı bir beklenti de değil. Amerika pazarına ürün gönderiyorsanız oradaki kalite sistemi düzenlemesi de aynı şeyi ister: kalite sisteminin parçası olarak kullanılan yazılım, kullanım amacına göre valide edilmelidir. Elektronik kayıt ve elektronik imza kullanıyorsanız bunlara ilişkin ek şartlar devreye girer. Uygulamada iki beklenti aynı dosyayla karşılanır; ayrı iki çalışma yapmaya gerek yok. Şikâyet ve düzeltici faaliyet tarafındaki beklentileri CAPA ve şikâyet yönetimi yazımızda ayrıca ele aldık.
Risk bazlı kapsam: her ekran valide edilmez
Gördüğüm en büyük hata, validasyonu bütün yazılımı test etmek olarak anlamak. Bu yaklaşım dört yüz sayfalık, kimsenin okumadığı ve ilk güncellemede geçersizleşen bir dosya üretir. Doğru yol, kapsamı risk temelli daraltmaktır. Ürün güvenliğine, kayıt bütünlüğüne veya serbest bırakma kararına dokunan fonksiyonlar yüksek riskli sayılır; diğerleri değil.
Şu üç soruyu her fonksiyon için sorun. Bu fonksiyon yanlış çalışırsa hatalı bir ürün sahaya çıkabilir mi? Bir kayıt kaybolabilir veya izlenemez şekilde değişebilir mi? Bir karar yanlış veriyle alınabilir mi? Üçüne de hayır diyorsanız o fonksiyon düşük risklidir ve bir satırlık gerekçeyle kapsam dışında bırakılır. Denetçiler çoğu zaman test sayfalarından çok bu gerekçe listesini okur.
Validasyonu yazılımı kurduktan sonra değil, kurulumla birlikte yapın. Sistem canlıya alınmadan önce test ortamında koşulan senaryolar hem daha temiz kanıt üretir hem de yapılandırma hatalarını erken yakalar. Geçmişte bu sırayı ters kurduğumuz bir kurulumda, validasyonu canlıya geçtikten altı ay sonra yaptık ve zorunlu olması gereken bir alanın boş bırakılabildiğini ancak o zaman fark ettik. Altı aylık kayıtların bir kısmını elle tamamlamak zorunda kaldık. Sıra doğru olsaydı bu iş yarım gün sürerdi.
Validasyon planı ne içerir?
Plan, işin iskeletidir ve uzun olması gerekmez; on sayfa yeter. İçinde şunlar bulunmalı: sistemin tanımı ve sürüm numarası, kullanım amacı, kapsam ve kapsam dışı bırakılanların gerekçesi, risk değerlendirmesi, sorumluluklar, test yaklaşımı, kabul kriterleri, sapma yönetimi ve onay imzaları. Kullanım amacı bölümünü ciddiye alın; buradaki bir cümle bütün testlerin çerçevesini belirler.
Test yaklaşımı bölümünde kurulum doğrulaması, işlevsel doğrulama ve kullanım doğrulaması ayrımını yapın. Kurulum doğrulaması sunucunun, veritabanının ve sürümün beklendiği gibi kurulduğunu gösterir. İşlevsel doğrulama fonksiyonların şartnameye göre çalıştığını, kullanım doğrulaması ise gerçek kullanıcının gerçek bir senaryoyu baştan sona yürütebildiğini gösterir. Üçünü tek başlık altında karıştıran dosyalar denetimde dağılıyor.
Test senaryoları nasıl yazılır?
Senaryo, bir kullanıcının yapacağı işi adım adım ve beklenen sonucuyla yazar. İyi bir senaryo tek sayfada durur, tek fonksiyonu test eder ve sonucu "geçti / kaldı" diye işaretlenebilir. Aşağıdaki tablo, bir doküman ve kayıt yönetimi kurulumunda kullandığımız senaryo setinin özetidir.
| Senaryo | Risk | Beklenen sonuç | Kanıt |
|---|---|---|---|
| Onaysız doküman yayınlanamaz | Yüksek | Sistem yayın işlemini reddeder | Ekran görüntüsü + hata mesajı |
| Yetkisiz kullanıcı revizyon açamaz | Yüksek | Menü görünmez veya işlem reddedilir | Yetki matrisi + ekran |
| Yürürlükten kalkan doküman aramada çıkmaz | Yüksek | Arama sonuçlarında yer almaz | Arama ekranı çıktısı |
| Denetim izi silinemez | Yüksek | Kayıt salt okunur, silme yok | Yönetici hesabıyla deneme |
| Zorunlu alan boş bırakılamaz | Orta | Kaydetme engellenir | Ekran görüntüsü |
| Elektronik onay kullanıcıya bağlanır | Yüksek | Onayda ad, tarih, saat görünür | Kayıt detay ekranı |
| Yedekten geri yükleme çalışır | Yüksek | Test kaydı eksiksiz geri gelir | Geri yükleme raporu |
| Saklama süresi dolan kayıt korunur | Orta | Kayıt arşivde okunabilir | Arşiv ekranı |
| Rapor sayıları kayıt sayısıyla uyuşur | Orta | Manuel sayımla aynı sonuç | Rapor + sayım tutanağı |
| Eşzamanlı düzenleme çakışması | Orta | İkinci kullanıcı uyarılır | İki oturum ekranı |
On senaryo az gelebilir. Sahada gördüğüm kadarıyla iyi seçilmiş on beş senaryo, gelişigüzel yazılmış yüz senaryodan daha fazla koruma sağlıyor. Her senaryonun altında testi yapanın adı, tarihi ve imzası bulunsun; kanıt ekran görüntüsü olarak eklensin ve görüntünün üzerinde tarih görünsün.
Elektronik kayıt bütünlüğü
Validasyonun ikinci yarısı, kayıtların zaman içinde güvenilir kalacağının gösterilmesidir. Dört başlık yeterli: denetim izi, yetkilendirme, yedekleme ve geri yükleme, okunabilirlik. Denetim izinde kimin ne zaman ne değiştirdiği görünmeli ve bu iz kullanıcı tarafından silinememelidir. Yönetici hesabının bile silememesi beklenir; silebiliyorsa bunu bir kayıtla açıklamanız gerekir.
En sık atlanan başlık geri yüklemedir. Firmalar yedek aldıklarını gösterir, ama yedekten geri dönmeyi hiç denememiştir. Yılda bir kez test ortamına geri yükleme yapın, birkaç kaydı karşılaştırın ve sonucu bir sayfalık tutanakla imzalayın. İmzalı o tek sayfa, denetimde uzun bir tartışmayı baştan kapatıyor. Doküman yönetimi tarafında saklama sürelerini de aynı tutanakta gözden geçirmek işi kolaylaştırır.
Güncelleme geldiğinde ne yapılır?
Yazılım güncelleniyor diye validasyon baştan yapılmaz; etki değerlendirmesi yapılır. Sürüm notlarını okuyun, hangi fonksiyonların değiştiğini işaretleyin ve yalnızca etkilenen senaryoları tekrar koşun. Değişiklik yüksek riskli bir alana dokunmuyorsa kısa bir regresyon seti yeterlidir. Bu değerlendirmenin kendisi imzalı bir kayıt olarak saklanır.
Burada bir uyarı: güncellemeyi kendi kontrolünüzde yapabildiğinizden emin olun. Sağlayıcının istediği anda sürüm değiştirdiği kurulumlarda, valide ettiğiniz sürümle çalıştığınız sürüm arasında fark oluşabilir ve bunu sonradan fark edersiniz. Medikal tarafta çalışan firmaların şirket içi kurulumu tercih etmesinin başlıca sebebi budur; sürüm değişikliği sizin takviminize göre yapılır. Yazılım seçerken bu maddeyi de listenize alın; QMS seçim kriterleri yazımızda diğer başlıkları topladık.
Kim yapar, ne kadar sürer?
Validasyonu bilgi işlem tek başına yapamaz, kalite tek başına da yapamaz. Çalışan kadro üç kişidir: süreç sahibi, yani sistemi günlük kullanan kişi; kalite tarafından bir sorumlu; ve teknik tarafı bilen bir kişi. Süreç sahibi olmadan yazılan test senaryoları gerçek kullanımı yansıtmaz, teknik kişi olmadan da yedekleme ve yetki testleri havada kalır.
Süre, kapsamla doğru orantılı. Doküman ve kayıt yönetimiyle sınırlı bir kurulumda plan iki gün, testler üç dört gün, rapor ve onay bir gün sürer; toplam iki hafta içinde biter. Üretim ve ölçüm tarafını da kapsayan bir kurulumda bu süre altı haftaya çıkar. Yazılım validasyonu ISO 13485 kapsamında bir kereye mahsus bir iş değildir; her önemli güncellemede ve genellikle yılda bir kez periyodik gözden geçirmeyle tekrar gündeme gelir.
Danışman kullanacaksanız şunu isteyin: dosyayı sizin adınıza yazmasın, sizinle birlikte yazsın. Dışarıdan gelen hazır şablonlar denetimde hemen belli oluyor, çünkü içindeki senaryolar sizin ekranlarınızı değil genel bir sistemi anlatıyor. Denetçi bir senaryoyu okuyup "bunu bana ekranda gösterir misiniz" dediğinde eşleşmeyen her ayrıntı dosyanın tamamını şüpheli hâle getiriyor.
Testleri koşarken bir de veri hacmi denemesi yapın. Boş bir test ortamında her senaryo geçer; asıl soru, sistem beş yıl sonra binlerce kayıtla dolduğunda aramanın ve raporların hâlâ doğru çalışıp çalışmayacağıdır. Örnek veriyle doldurulmuş bir ortamda rapor sayılarını elle sayımla karşılaştırmak yarım gün sürüyor ve ileride ortaya çıkacak en can sıkıcı sürprizi baştan eliyor. Aynı denemede yanıt sürelerine de bakın; kullanıcı bekleten bir ekran, zamanla kayıt girilmeyen bir ekrana dönüşüyor.
Sık yapılan beş hata
Birincisi, validasyonu tek seferlik bir belge işi sanmak. Dosya yazılır, imzalanır, klasöre kaldırılır ve iki yıl açılmaz. Bu arada sistem üç kez güncellenmiş, iki yeni iş akışı eklenmiş, yetki yapısı değişmiştir. Dosya artık çalışmayan bir sistemi anlatıyordur.
İkincisi, testleri gerçek kullanıcıya değil bilgi işlem personeline yaptırmak. Sistemi kuran kişi testi geçirir, çünkü nereye tıklayacağını bilir. Testin değeri, sistemi ilk kez kullanan birinin aynı adımları takip edebilmesindedir. Üçüncüsü, ekran görüntüsü almadan "geçti" yazmak; kanıtsız test kaydı denetimde kabul görmez.
Dördüncüsü, sapmaları gizlemek. Test sırasında bir senaryo kaldıysa bunu dosyada göstermek zorundasınız; sapmayı yazmak, çözümü tanımlamak ve tekrar test etmek doğru yoldur. Hiç sapma içermeyen validasyon dosyası, denetçide testlerin gerçekten koşulmadığı izlenimi yaratıyor. Beşincisi, eğitim kayıtlarını atlamak. Valide edilmiş sistemi eğitimsiz kullanıcının kullanması ayrı bir bulgu konusu.
Yazılım validasyonu ISO 13485 denetimlerinde bu beş hatanın dışında bir de kapsam belirsizliği çıkıyor. Hangi modüllerin valide edildiği net yazılmamışsa denetçi en geniş yorumu yapıyor ve kapsam dışı bıraktığınız her ekran için gerekçe soruyor. Kapsam cümlesini planın ilk sayfasına, tek paragrafta ve modül adlarıyla yazın.
Periyodik gözden geçirmeyi de takvime bağlayın. Yılda bir kez validasyon dosyasını açıp şu üç soruyu cevaplayın: sistemde kapsamı değiştiren bir yapılandırma oldu mu, yeni kullanıcı grupları eklendi mi, kullanım amacı değişti mi? Üçüne de hayır diyorsanız tek sayfalık bir gözden geçirme notu yeterli. Bu not, iki yıl sonra dosyanın hâlâ geçerli olduğunu gösteren en kısa kanıt.
Dosyada ne saklanır?
Validasyon dosyasının içeriği şu sırayla dursun: validasyon planı, kullanım amacı ve şartname, risk değerlendirmesi, kurulum doğrulama kayıtları, test senaryoları ve sonuçları, sapmalar ve çözümleri, eğitim kayıtları, validasyon raporu ve serbest bırakma onayı. Eğitim kayıtlarını unutmayın; valide edilmiş bir sistemi eğitimsiz kullanıcının kullanması denetimde ayrı bir başlık olur.
Satıcıdan isteyeceğiniz şeyler ise sınırlıdır: sürüm bilgisi, sürüm notları, veri modeli ve denetim izi hakkında teknik açıklama, varsa geliştirme süreci sertifikaları. Bunlar dosyanın ekidir. Ana gövde sizin kullanımınızı anlatır ve sizin imzanızı taşır. Denetim günü dosyayı çıkarıp masaya koyduğunuzda denetçinin ilk baktığı yer imza sayfası oluyor.
Ölçek üzerine dürüst bir not da düşeyim: yılda birkaç kayıt üreten, üç kullanıcılı çok küçük bir firmada bu dosya iki günde hazırlanır ve on beş sayfayı geçmez. Danışmanlık teklifiyle gelen yüz sayfalık paketler çoğu zaman gereğinden büyük. PaKalite kurulumlarında denetim izi silinemez şekilde tutulur ve sürüm değişikliği sizin takviminizle yapılır; ama validasyon dosyasını yine sizin yazmanız gerekir. Bu iş devredilemiyor, çünkü valide edilen şey yazılım değil sizin onu kullanma biçiminiz.