Yazılım seçim toplantısının kırkıncı dakikasında kalite müdürü sunumu durdurdu ve tek bir soru sordu: "Bu cihazın ömrü on beş yıl. On beş yıl sonra, bugün ürettiğimiz partinin hangi talimat revizyonuyla üretildiğini bana bu ekrandan gösterebilecek misiniz?" Satış ekibi sürüm geçmişini açtı; kalite müdürü tatmin olmadı, çünkü sorduğu şey sürüm listesi değil, parti kaydı ile doküman revizyonu arasındaki bağdı. ISO 13485 doküman yönetimi tam olarak bu bağın kurulmasıyla ilgilidir ve seçim kararı da bu soruyla verilir.
13485'in doküman maddeleri kısa ama sert
ISO 13485 doküman yönetimi şartları 4.2 maddesinde beş alt başlığa ayrılır ve her biri somut bir çıktı ister. 4.2.1 genel dokümantasyon şartlarını, 4.2.2 kalite el kitabını, 4.2.3 tıbbi cihaz dosyasını, 4.2.4 dokümanların kontrolünü, 4.2.5 kayıtların kontrolünü tanımlar. ISO 9001'den gelen ekiplerin ilk şaşırdığı yer 4.2.2'dir; 9001 kalite el kitabı şartını kaldırmıştır ama 13485 hâlâ ister ve içeriğini de sayar: kapsam, hariç tutmalar ve gerekçeleri, prosedür atıfları, süreçler arası etkileşim.
4.2.4 maddesi ise doküman kontrolünde 9001'in bir adım ötesine geçer. Değişikliklerin, ilk onayı veren fonksiyon tarafından ya da karar için gereken arka plan bilgisine erişebilen başka bir yetkili tarafından gözden geçirilip onaylanmasını ister. Yani "kim onaylarsa onaylasın" demez; onaylayanın o dokümanın geçmişini bilmesini şart koşar. Yazılım seçerken bu, onay akışında rol ve yedek onaycı tanımının doğru kurgulanması anlamına gelir.
Satın alma kontrol listesi: her satırın karşısında bir ekran
Aşağıdaki tablo, ISO 13485 doküman yönetimi ve kayıt şartlarını doğrudan bir demo kontrol listesine çeviriyor. Toplantıya bu tabloyla girin ve her satır için ekranın açılmasını isteyin; slayt değil, çalışan ekran.
| Madde | Şart | Demoda görülmesi gereken ekran |
|---|---|---|
| 4.2.2 | Kalite el kitabı, hariç tutmalar ve prosedür atıfları | El kitabı dokümanı, içindeki atıfların tıklanabilir doküman numaralarına bağlanması |
| 4.2.3 | Tıbbi cihaz dosyası | Cihaz bazlı dosya görünümü; spesifikasyon, üretim, etiketleme ve servis dokümanlarının tek listede toplanması |
| 4.2.4 | Değişikliğin bilgili yetkili tarafından onayı | Onay akışında rol tanımı, yedek onaycı ve önceki revizyon karşılaştırması |
| 4.2.4 | Yürürlükten kaldırılmış dokümanın kontrollü saklanması | Arşiv durumu, geçersiz ibaresi, erişim kısıtı ve saklama süresi alanı |
| 4.2.5 | Kayıtların okunabilirliği ve korunması | Kayıt üzerinde değişiklik yapıldığında eski değerin izinin kalması |
| 4.1.6 | Yazılımın doğrulanması | Satıcının doğrulama paketi ve sürüm notları; test senaryosu şablonu |
| 7.3.10 | Tasarım ve geliştirme dosyası | Proje bazlı dosya, girdi-çıktı-doğrulama-geçerli kılma kayıtlarının bağı |
| 7.5.9 | İzlenebilirlik | Parti kaydından o partide yürürlükte olan talimat revizyonuna geçiş |
| 8.2.2 | Şikâyet yönetimi | Şikâyet kaydından düzeltici faaliyete ve etkilenen partilere bağlantı |
Bu tablodaki en ayırt edici satır 7.5.9'dur. Çoğu doküman sistemi revizyon geçmişini tutar ama parti kaydıyla revizyonu ilişkilendirmez. Sistem bu bağı kurmuyorsa, geriye dönük bir soruşturmada hangi partinin hangi talimatla üretildiğini elle çıkarmak zorunda kalırsınız. Doküman yönetimi tarafındaki temel kurguyu ayrıca inceleyebilirsiniz.
Saklama süresini tek bir genel değere bağlamak kolaydır ve bu yüzden çok yapılır: "tüm kayıtlar 10 yıl". Bu tanım hem fazla hem eksiktir. Sarf malzemesi niteliğindeki bir ürünün kalibrasyon kaydını on yıl tutmanız gerekmezken, uzun ömürlü bir cihazın üretim kaydı on yılı aşabilir. Süreyi doküman ve kayıt türü bazında tanımlayın; sistem her kayda kendi süresini yazsın.
Saklama süreleri: cihazın ömrü artı mevzuat
Bu başlık 13485'i diğer standartlardan ayıran yerdir. Madde 4.2.5 kayıtların, kuruluşun tanımladığı cihaz ömrü boyunca ya da mevzuatın öngördüğü süre kadar saklanmasını ister ve alt sınır koyar: cihazın piyasaya verilmesinden itibaren iki yıldan az olamaz. Madde 4.2.4 ise yürürlükten kaldırılmış dokümanlar için ayrı bir şart getirir; cihazın üretildiği ve test edildiği dokümanların en az bir kopyası, cihaz ömrü boyunca erişilebilir kalmalıdır.
Buraya bir de mevzuat katmanı biner. Avrupa pazarına ürün veren üreticiler için teknik dokümantasyonun saklama süresi, son cihazın piyasaya arzından itibaren on yıl, implante edilebilir cihazlarda on beş yıl olarak düzenlenmiştir. Yazılım seçerken sorulacak soru şudur: sistem bu süreleri kayıt türü bazında tanımlayıp süre dolmadan silinmeyi engelliyor mu, süre dolduğunda imha önerisi üretiyor mu? İkisini birden yapmayan sistem bu işi size bırakır.
Madde 4.1.6: yazılımın kendisi de doğrulanır
Tıbbi cihaz üreticilerinin en çok atladığı madde budur. 4.1.6, kalite yönetim sisteminde kullanılan bilgisayar yazılımının uygulamasının doğrulanmasını ister; doğrulama, kullanım riskiyle orantılı olmalı ve kayıtları saklanmalıdır. Yani satın aldığınız doküman yazılımını kendi kullanım senaryolarınızla test etmeniz ve bu testin kaydını tutmanız gerekir. Satıcının "ürünümüz 13485 uyumludur" beyanı bu şartı karşılamaz.
Pratik yol şu: satıcıdan doğrulama paketini ve sürüm notlarını isteyin, ardından kendi kritik akışlarınız için sekiz on senaryoluk bir test protokolü yazın. Doküman yayımlama, revizyon, tebliğ, arşivleme ve yetki kısıtı bu senaryoların içinde olmalı. Sürüm güncellemelerinde protokolü tekrar koşun. Satıcının sürüm takvimini ve geriye dönük uyumluluk politikasını sözleşmede yazılı isteyin; her güncellemede baştan doğrulama yapmak zorunda kalmak ciddi bir yük üretir. Risk temelli yaklaşımın nasıl kurulacağını risk yönetimi sayfamızda anlattık.
Tasarım dosyası ve cihaz dosyası ayrımı
Sahada DHF ve DMR terimleri sık kullanılır; bunlar FDA düzenlemesinin terimleridir. ISO 13485'te karşılıkları ayrı maddelerde durur: madde 7.3.10 tasarım ve geliştirme dosyasını, madde 4.2.3 tıbbi cihaz dosyasını ister. Birincisi ürünün nasıl tasarlandığını, ikincisi nasıl üretildiğini anlatır. Yazılımda bu ikisini ayrı doküman türü olarak kurgulayın; aynı klasöre atıldığında denetimde hangi belgenin hangi dosyaya ait olduğu tartışması çıkar.
Tasarım dosyasında girdi, çıktı, gözden geçirme, doğrulama, geçerli kılma ve tasarım transferi kayıtlarının birbirine bağlı olması gerekir. Denetçi bir tasarım girdisini seçip ona karşılık gelen doğrulama kaydını sorar. Bu bağ sistemde kurulu değilse cevabı klasörlerden toplarsınız ve bu, kayıt bütünlüğü açısından zayıf bir izlenim bırakır.
Tasarım transferi ayrı bir dikkat ister. Tasarım çıktısının üretim spesifikasyonuna dönüştüğü an, doküman sisteminde yeni bir talimatın ya da kontrol planının doğduğu andır. Bu iki kaydı birbirine bağlamazsanız, seri üretime geçtikten sonra "bu tolerans hangi tasarım kararından geliyor" sorusu cevapsız kalır. Bağlantıyı sistemde tasarım projesi numarası üzerinden kurun; her üretim dokümanının kartında o numara dursun.
Bildirilmiş kuruluş denetçisi doküman kontrolünü genellikle şu testle ölçer: rastgele bir üretim partisi seçer, o partinin üretim tarihini alır ve "bu tarihte hangi montaj talimatı yürürlükteydi" diye sorar. Ardından o revizyonun onay kaydını ve tebliğ listesini ister. Üç soruyu üç dakikada cevaplayabiliyorsanız sistem ayaktadır; klasöre gitmek zorunda kalıyorsanız devamı gelir.
Tasarım tarafında bir uyarı daha: tasarım değişikliklerinin kaydı, değişikliğin ürün üzerindeki etkisinin ve halihazırda üretilmiş ürünlere etkisinin değerlendirilmesini de içermelidir. Yazılımda bu, değişiklik kaydının içinde ayrı bir etki değerlendirme alanı olarak durur. Alanı boş bırakılabilir yaparsanız boş kalır; zorunlu yaparsanız ekip önce şikâyet eder, sonra alışır ve denetimde bu alanın dolu olması işinizi görür.
Kayıt bütünlüğü ve elektronik imza
Madde 4.2.5 kayıtların okunaklı, tanımlanabilir ve erişilebilir kalmasını, ayrıca korunmasını ister. Elektronik ortamda bunun karşılığı, bir kaydın değiştirildiğinde eski değerinin izinin kalmasıdır. Demo sırasında şunu test edin: doldurulmuş bir kaydı açıp bir alanı değiştirin, kaydedin, sonra denetim izini açın. Eski değer, yeni değer, kim ve ne zaman bilgisi görünüyor mu? Görünmüyorsa o sistem düzenlemeye tabi bir üretim için yetersizdir.
Elektronik imza kullanacaksanız kullanıcı doğrulamasının ayrı bir adım olarak istenmesi gerekir; oturum açık diye imza atılmamalıdır. İmza kaydında imzalayanın adı, tarihi, saati ve imzanın anlamı (hazırladı, kontrol etti, onayladı) yer almalıdır. Bu dört alan eksikse imza, denetimde imza sayılmaz.
Şikâyetten düzeltici faaliyete uzanan zincir
Madde 8.2.2 şikâyetlerin zamanında incelenmesini ve kayıt altına alınmasını, 8.2.3 ise mevzuatın gerektirdiği durumlarda yetkili otoriteye bildirim yapılmasını ister. Doküman sistemi açısından buradaki kritik nokta, şikâyet kaydının tek başına durmamasıdır. Şikâyet kaydından etkilenen parti numarasına, oradan üretim kayıtlarına ve gerekiyorsa düzeltici faaliyete geçebilmelisiniz. Bu zincir kurulmadığında bir geri çağırma değerlendirmesi günler alır.
Demoda şu senaryoyu isteyin: bir şikâyet kaydı açılsın, içine parti numarası girilsin ve sistem o partiyle aynı hammadde lotunu kullanan diğer partileri listelesin. Bu ekranı gösteremeyen sistemler izlenebilirlik tarafında zayıftır. Düzeltici faaliyet kurgusunun genel mantığı için düzeltici faaliyet sayfamıza bakabilirsiniz; 13485'te bu akışın ek olarak etkinlik doğrulaması ve olumsuz yan etki değerlendirmesi ile kapanması beklenir.
Eğitim, yetkinlik ve temiz oda kayıtları
Madde 6.2 personelin yetkinliğini ve eğitim etkinliğinin değerlendirilmesini ister. Tıbbi cihaz üretiminde bu, kalite dokümanlarıyla doğrudan bağlıdır; bir montaj talimatı revize edildiğinde o istasyonda çalışan personelin yeniden eğitilmesi ve kaydının tutulması gerekir. Sistem, doküman revizyonu ile eğitim ihtiyacını birbirine bağlıyorsa bu iş kendiliğinden yürür. Bağlamıyorsa insan hafızasına kalır ve ilk denetimde açık verir.
Kontrollü ortamda üretim yapıyorsanız temizlik, giysi ve ortam izleme kayıtları da aynı sisteme girer. Bu kayıtların frekansı yüksektir; günlük ya da vardiyalık doldurulur. Yazılım seçerken tekrarlayan kayıtların şablondan otomatik açılıp açılmadığını sorun. Elle açılan her kayıt, unutulan bir kayıt demektir. Ölçüm cihazlarının izlenmesi tarafını da atlamayın; kalibrasyon kayıtlarının süresi dolan cihazı üretimde kullandırmayacak biçimde kurulması gerekir.
Demoda yapılacak beş test
Sunumdan sonra klavyeyi siz alın ve şu beş işi kendiniz yapın. Bir: yeni bir talimat oluşturup iki kademeli onaydan geçirin, sonra revizyon çıkarıp değişiklik gerekçesini girin. İki: bir partiyi açıp o partide yürürlükte olan talimat revizyonunu bulun. Üç: bir dokümanı yürürlükten kaldırıp arşivde nasıl göründüğünü ve kimlerin erişebildiğini kontrol edin. Dört: bir kayıt üzerinde değişiklik yapıp denetim izini okuyun. Beş: saklama süresi dolan bir kayıt için sistemin ne yaptığını sorun.
Bu beş test, ISO 13485 doküman yönetimi için seçim kararının büyük bölümünü tek başına verir; fiyat ve modül sayısı listelerinden çok daha ayırt edicidir. Sektörel kurulum örnekleri için sektörler sayfamıza, bilgi güvenliği şartı da geliyorsa ISO 27001 doküman şartları yazımıza bakın; ikisi aynı doküman sisteminde birlikte kurgulanabilir. PaKalite'nin doküman modülünde revizyon, tebliğ ve arşiv akışı bu testlerin tamamına ekrandan cevap verecek biçimde kurgulanmıştır.