Hastaneden gelen e-posta satış temsilcisinin kutusuna düşüyor. İçinde bir cümle var: "Kullanım sırasında bağlantı parçası ayrıldı, hasta etkilenmedi." Temsilci konuyu servise iletiyor, servis parçayı değiştiriyor, iş kapandı sanılıyor. Kalite ekibi olaydan on gün sonra haberdar oluyor. Bildirim süresi hesaplanmaya başlandığında sürenin çoktan işlemiş olduğu anlaşılıyor. ISO 13485 CAPA sisteminin en zayıf noktası prosedürün kalitesi değil, şikayetin kalite ekibine ulaşma hızıdır.
Saat ne zaman başlar
Vijilans yükümlülüğünde süre, olayın kalite biriminde kaydedildiği an değil, kuruluşun olaydan haberdar olduğu an başlar. Satış temsilcisinin e-postayı açtığı dakika kuruluş haberdar olmuş sayılır. Bu tek cümle, şikayet yönetiminin bütün tasarımını belirler: şikayetin giriş kapısı tek olmalı ve o kapı kalite biriminin görebildiği bir yer olmalıdır.
Kapı sayısı pratikte üçü buluyor: tek bir kurumsal e-posta adresi, servis formunun üzerindeki "şikayet mi" kutucuğu ve satış ile teknik ekibin doğrudan kayıt açabildiği bir ekran. Hangi yoldan gelirse gelsin ilk iş aynı — geliş tarihi ve saati ile kuruluşun haberdar olduğu tarih ayrı ayrı kaydedilir. İki tarih arasındaki fark, sisteminizin gerçek performans göstergesidir; bu farkı ölçmeyen bir sistem kendini düzeltemez.
Bu kapıyı kurmanın ikinci şartı eğitimdir. Satış, servis ve teknik destek ekibi neyin şikayet sayıldığını bilmiyorsa kapı açık ama boş kalır. Yılda bir kez, yarım saatlik ve örnek olaylarla dolu bir bilgilendirme yeterlidir. Eğitimde tek bir cümleyi ezberletin: şüpheye düştüğünde kaydı aç, sınıflandırmayı kalite yapar.
Geri bildirim ile şikayeti ayırmak
ISO 13485:2016'nın 8.2.1 maddesi geri bildirim toplamayı, 8.2.2 maddesi ise şikayetlerin ele alınmasını ayrı ayrı ister. Ayrım önemlidir. Geri bildirim, ürün piyasaya verildikten sonra toplanan her bilgidir; kullanıcı yorumu, servis kaydı, eğitimde gelen soru. Şikayet ise cihazın kimliği, kalitesi, dayanıklılığı, güvenilirliği, kullanılabilirliği, güvenliği veya performansıyla ilgili bir eksiklik iddiası taşır.
Her şikayet aynı zamanda geri bildirimdir, ama her geri bildirim şikayet değildir. İki kayıt türünü ayrı tutun ve ayırma kararını da kaydedin. Bir kaydı "geri bildirim" olarak sınıflandırıp şikayet defterine almadıysanız, bu kararın gerekçesi denetimde sorulur. 8.2.1 ayrıca geri bildirimin risk yönetimine ve ürün gerçekleştirmeye girdi olarak kullanılmasını da bekler; yani toplayıp arşivlemek yetmez.
Bir üretici firmada şikayet sayısı yıllık on ikiydi ve yönetim bundan memnundu. Servis kayıtlarını taradığımızda aynı yıl içinde aynı bileşenle ilgili kırk yedi müdahale çıktı. Bunların hiçbiri şikayet olarak kaydedilmemişti, çünkü servis ekibi "arıza" diyordu, "şikayet" demiyordu. Kelime seçimi bütün eğilim analizini bozmuştu. Servis formuna tek bir kutucuk ekledik: "Bu müdahale ürün performansıyla ilgili mi?" Ertesi yıl şikayet sayısı arttı, ama sistem ilk kez gerçeği gösteriyordu.
Şikayet değerlendirme: üç soru
Kayıt açıldıktan sonra ilk yirmi dört saat içinde üç soru cevaplanmalıdır. Bir: bu olay bildirime konu mu? İki: piyasadaki diğer cihazlar için risk var mı? Üç: araştırma açılacak mı, açılmayacaksa gerekçesi ne? Bu üç sorunun cevabı bir formda, tarihli ve imzalı olarak durmalıdır.
Üçüncü soru en çok atlanan yerdir. 8.2.2 maddesi, bir şikayetin araştırılmaması hâlinde bu kararın gerekçesinin kaydedilmesini ve kararı verenin yetkilendirilmiş olmasını ister. Yani "araştırmadık" demek serbesttir, ama gerekçesiz demek değildir. Denetimde araştırılmayan şikayetlerin gerekçe kayıtları ilk istenen belgelerdendir.
Bildirim kararı ve süreler
8.2.3 maddesi, düzenleyici otoriteye bildirim gerektiren şikayetler için dokümante edilmiş prosedür ve bildirim kayıtları ister. Sürelerin kendisi standartta değil, tabi olduğunuz mevzuatta yazar. Avrupa Birliği tıbbi cihaz tüzüğünde ciddi olaylar için kademeli süreler tanımlanmıştır ve Türkiye mevzuatı bu çerçeveyle uyumlaştırılmıştır. Aşağıdaki tablo bu kademeleri özetliyor; kendi ürün sınıfınız ve pazarınız için yürürlükteki metni mutlaka doğrulayın.
| Durum | Azami bildirim süresi | Sayacın başladığı an | Kayıtta bulunması gereken |
|---|---|---|---|
| Ciddi kamu sağlığı tehdidi | 2 gün | Tehdidin farkına varma | İlk bildirim, gerekçe, iletişim izi |
| Ölüm veya beklenmeyen ciddi sağlık bozulması | 10 gün | Olaydan haberdar olma | Olay tanımı, cihaz kimliği, ilk analiz |
| Diğer ciddi olaylar | 15 gün | Olaydan haberdar olma | Olay tanımı, sınıflandırma kararı |
| Ciddi olmayan şikayet | Bildirim yok | — | Değerlendirme kaydı, eğilim analizi |
| Saha güvenlik düzeltici faaliyeti | Mevzuata göre | Karar tarihi | Bildirim, kullanıcı duyurusu, takip |
Tabloda dikkat edilecek nokta üçüncü kolon. Sayaç sizin kayıt açtığınız gün değil, kuruluşun haberdar olduğu gün başlar. Baştaki hikâyede on gün burada kaybedilmişti. Bu yüzden şikayet formundaki ilk alan "kuruluşun haberdar olduğu tarih" olmalı ve bu alan geriye dönük olarak doldurulabilmelidir.
CAPA'yı ne zaman açarsınız
Her şikayet için düzeltici faaliyet açmak, sistemi çalışmaz hâle getirir. Otuz açık kayıt birikir, hiçbiri düzgün araştırılmaz, ekip form doldurmaya çalışır. Bunun yerine eşik tanımlayın ve prosedüre yazın: tekrar eden şikayetler, hasta veya kullanıcı güvenliğini ilgilendiren durumlar, bildirime konu olan olaylar ve belirlediğiniz sıklığı aşan kalemler düzeltici faaliyet açar. Diğerleri düzeltmeyle kapanır ve eğilim analizine girer.
Eşiği belirlerken ISO 13485 CAPA prosedürünüze bir de sayı koyun. "Tekrar eden" ifadesi tek başına yoruma açıktır; aynı ürün ailesinde aynı hata kodundan altı ay içinde üç kayıt gibi somut bir kural yazın. Sayıyı ilk yıl gözlemleyip ayarlayabilirsiniz. Eşiksiz yazılmış prosedürlerin ortak zaafı da burada: karar her seferinde o günkü kişiye ve o günkü iş yüküne kalır.
8.5.2 maddesi düzeltici faaliyetin gecikmeksizin başlatılmasını, nedenin belirlenmesini ve alınan faaliyetin etkinliğinin doğrulanmasını ister. Düzeltme ile düzeltici faaliyeti karıştırmayın: parçayı değiştirmek düzeltmedir, aynı parçanın bir daha ayrılmamasını sağlamak düzeltici faaliyettir. Bu ayrımın imalat tarafındaki karşılığını düzeltici faaliyet sayfamızda ayrıntılı anlattık.
Kök neden ve etkinlik doğrulama
Tıbbi cihaz tarafında kök neden analizi, otomotivdekiyle aynı araçlarla yapılır. Sekiz adımlı problem çözme yaklaşımı ya da beş neden, cihaz sektöründe de çalışır; farklı olan tek şey, çıktının risk dosyasına geri beslenmesi zorunluluğudur. Kök nedeni bulduğunuzda risk analizinizde o hata modunun yer alıp almadığına da bakmalısınız. Yöntemin kendisi için kök neden analizi ve 8D sayfalarımız işinizi görür.
Etkinlik doğrulama, kayıtların en zayıf olduğu yer. "Faaliyet tamamlandı" cümlesi doğrulama değildir. Kayıtta üç şey bulunmalı: hangi veriye bakılacağı, ne kadar süre izleneceği, hangi değerin başarı sayılacağı. Örneğin aynı hata kodunun üç ay boyunca tekrar etmemesi. İkinci bir adım daha var ve en çok o atlanıyor: yapılan değişikliğin cihazın güvenliğini ve performansını olumsuz etkilemediğinin doğrulanması. Bu adım olmadan CAPA kapatılmamalıdır.
Bildirilmiş kuruluş denetiminde şikayet dosyasını açtığımda ilk baktığım şey tarih zinciridir: olay tarihi, haberdar olma tarihi, kayıt tarihi, değerlendirme tarihi, bildirim tarihi. Bu beş tarih arasında açıklanamayan bir boşluk varsa oradan devam ederim. İkinci baktığım şey kapatılmış düzeltici faaliyetlerin etkinlik kayıtlarıdır. Kapanış tarihi ile etkinlik doğrulama tarihi aynı günse o doğrulama yapılmamış demektir; hiçbir etkinlik aynı gün ölçülemez.
Kayıtların izlenebilirliği ve saklanması
Şikayet kaydının cihaz kimliğine bağlanması şart. Model, seri veya lot numarası, üretim tarihi ve mümkünse sevkiyat kaydı aynı ekranda görünmeli. Bunlar yoksa "kaç cihaz etkilendi" sorusuna cevap veremezsiniz ve saha faaliyeti kararı veremezsiniz. Bu bağ, şikayet sisteminin üretim kayıtlarıyla aynı veritabanında yaşamasının en somut gerekçesidir.
Saklama süresinde 4.2.5 maddesi net bir alt sınır koyar: kayıtlar, kuruluşun tanımladığı cihaz ömrü boyunca, ancak ürünün serbest bırakıldığı tarihten itibaren en az iki yıl saklanır. Mevzuatınız daha uzun bir süre istiyorsa o geçerlidir. Saklama süresini kayıt türüne göre tabloya dökün ve sistemde alan olarak tutun; arşivi klasör adına göre yönetmeye çalışan firmalarda bu süre her zaman tartışma konusu oluyor.
Bir uyarı daha: saklama yükümlülüğü sadece dijital dosyayı değil, o dosyayı okuyabilme yeteneğini de kapsar. On yıl önce alınmış bir ölçüm cihazının çıktısı, bugün açılamayan bir formatta duruyorsa kaydınız fiilen yoktur. Uzun ömürlü cihaz üreten firmalarda kayıtları PDF gibi uzun süre okunabilir bir biçimde saklamak ve yedeklerden geri dönüş testini yılda bir yapmak bu riski kapatıyor.
Eğilim analizini ciddiye almak
Tekil şikayetler sistemi düzeltmez; eğilim düzeltir. 8.4 maddesi geri bildirim ve şikayet dâhil verilerin analiz edilmesini ve bu analizin uygunluk ile etkinliği değerlendirmede kullanılmasını ister. Pratikte bu, üç aylık bir tablo demektir: ürün ailesi, hata kodu, adet, önceki döneme göre değişim. Tabloyu yönetimin gözden geçirme toplantısına götürün ve sadece adetleri değil, açılan ve kapanan faaliyet sayılarını da koyun.
Eğilim analizinin işe yaraması için hata kodlaması gerekir. Şikayet metnini serbest yazıya bırakırsanız hiçbir gruplama yapamazsınız. On beş ile yirmi beş arasında bir kod listesi kurun, listeyi servis ekibiyle birlikte yazın ve yılda bir gözden geçirin. Kod listesi olmadan ISO 13485 CAPA sistemi tekil olaylar yığınına dönüşür; kod listesiyle birlikte ise ilk çeyrekte hangi bileşenin sorun çıkardığını görürsünüz. Denetim tarafında da bu analiz istenir; iç denetim programınızda şikayet ve düzeltici faaliyet prosesini ayrı bir satır olarak planlayın.
Zinciri tek sistemde kurmak
ISO 13485 CAPA zinciri altı halkadan oluşur: geri bildirim, şikayet, değerlendirme, bildirim, düzeltici faaliyet, etkinlik. Bu altı halka farklı dosyalarda yaşıyorsa hiçbiri diğerini tetiklemez ve baştaki on günlük gecikme kaçınılmaz hâle gelir. Aynı sistemde yaşadıklarında ise şikayet kaydı açıldığı anda süre sayacı başlar, bildirim kararı forma düşer, eşik aşıldığında düzeltici faaliyet kendiliğinden önerilir.
PaKalite'de şikayet, düzeltici faaliyet ve risk kayıtları aynı veritabanında durur; şikayetten açılan bir faaliyet kaynağını taşır ve etkinlik doğrulama tarihi ayrı bir alan olarak izlenir. Risk dosyasıyla bağı kurmak için risk yönetimi sayfamızdaki çerçeveye, sistemin genel mantığı için de QMS nedir yazımıza bakabilirsiniz. Şunu da açıkça söyleyelim: yılda on şikayet alan küçük bir üreticide bu zincir iyi tasarlanmış formlarla da yürür. Kırılma noktası, eğilim analizi yapmanız gerektiği andır — el ile tutulan kayıtlar eğilimi göstermez.