İstisnalara Göre Toplu İnceleme (BRBE) – QA'yı Gerçekten Önemli Olan Şeylere Odaklamak

Bu konu, şu konunun bir parçasıdır: SG Systems Global düzenleyici ve operasyonel terimler sözlüğü.

Kasım 2025'te güncellendi • eBR, MES, Veri Bütünlüğü, Sürüm • İlaç, Biyoteknoloji, Gıda, Cihazlar, Kozmetikler

İstisnai Durumlara Göre Parti İncelemesi (BRBE), doğrulanmış elektronik sistemlerin her adımı, imzayı, parametreyi ve malzeme hareketini otomatik olarak kontrol ettiği ve insanların yalnızca sistemin işaretlediği istisnaları incelediği, risk tabanlı bir parti kaydı inceleme yaklaşımıdır. Kalite güvence ekibinin her parti kaydının her satırını okuması yerine , dikkat, ürün kalitesi ve uyumluluk için gerçekten önemli olan sapmalara, uyarılara ve olağandışı kalıplara odaklanır.

“Önemli olan daha hızlı okumak değil; sistemin insanlardan daha iyi kontrol edebildiği şeyleri okumayı bırakmaktır.”

1) İstisnaya Göre Toplu İnceleme Gerçekte Nedir?

BRBE, "toplu incelemeyi atlama" anlamına gelmez; kontrollü ve doğrulanmış koşullar altında incelemenin tekrarlayan kısımlarını otomatikleştirir. Geleneksel bir süreçte, QA, toplu kayıttaki her hesaplamayı, imzayı, parametreyi ve girişi manuel olarak kontrol eder. BRBE'de ise eBR/MES sistemi, önceden tanımlanmış kuralları kullanarak bu kontrolleri otomatik olarak gerçekleştirir ve yalnızca istisnaları (eksik veriler, aralık dışı değerler, sıra ihlalleri, eksik adımlar veya çözülmemiş sapmalar) vurgular.

İnsan değerlendirici yine de yayın kararını veriyor, ancak zamanını mekanik olarak kutuları işaretlemek yerine risk ve bağlamı değerlendirmeye harcıyor . Eğer BRBE tasarımınız sorunları ortaya çıkarmak yerine gizliyorsa, BRBE'ye sahip değilsiniz; incelemede bulunmayı bekleyen gizli bir veri bütünlüğü sorununuz var demektir.

2) Düzenleyici Perspektif ve Kabul

Düzenleyici kurumlar, onaylanmış bir sistem zaten kontrolü yapmışsa, kalite güvence biriminin her satırı yeniden okumasını şart koşmaz. Onların önemsediği şey, inceleme sürecinin etkili , risk temelli ve belgelenmiş olup olmadığıdır. 21 CFR 211 ve küresel GMP'ler, üretim ve kontrol kayıtlarının kapsamlı bir şekilde incelenmesini gerektirir; 21 CFR Bölüm 11 ve Ek 11, elektronik kayıtlar ve imzalar için beklentileri tanımlar.

Denetçiler, istisnaların nasıl tanımlandığını, kuralların nasıl doğrulandığını, değişikliklerin nasıl kontrol edildiğini ve QP veya QA sorumlusunun kural setinin zaman içinde uygunluğunu nasıl sağladığını soracaktır. Bunu açıklayıp belgeleyemezseniz, kullanıcı arayüzü ne kadar modern görünürse görünsün, sistemin yeterince kontrol altında olmadığını varsayacaklardır.

3) Ön Koşullar – Yapılandırılmış eBR, Taranmamış Kağıt

BRBE yalnızca parti verileri yapılandırılmış ve makine tarafından kontrol edilebilir olduğunda çalışır. Eğer "eBR"niz sadece taranmış kağıt veya yapılandırılmamış PDF'lerden oluşuyorsa, kuralların üzerinde çalışabileceği bir şey yoktur. Gerçek BRBE, malzemelerin, ağırlıkların, parametrelerin, imzaların ve durumların meta verilerle birlikte ayrı alanlar olarak saklandığı veri merkezli bir elektronik parti kaydı gerektirir.

Bu da sırasıyla net URS'ye , konfigürasyon standartlarına ve sağlam bir Doğrulama Ana Planına (VMP) bağlıdır . Tasarım çalışmalarını atlayıp sadece kağıt formları "parametrelendirirseniz", manuel inceleme zorluğunu kalıcı hale getirir ve BRBE'nin sunabileceği değerin çoğunu ortadan kaldırırsınız.

4) Sistemin Kontrol Ettiği Şeyler ve İnsanların Hâlâ İncelemesi Gerekenler

Sistemler kuralları kontrol etmede iyidir ; insanlar ise bağlamı değerlendirmede daha iyidir . BRBE, genellikle adım tamamlama, zorunlu alanlar, durum geçişleri, malzeme kimliği ve durumu, aralık içi parametreler, denklem doğruluğu ve barkod eşleşmeleri gibi kontrolleri sisteme devreder. Bu kontroller bir kez tanımlanabilir ve her parti için tutarlı bir şekilde çalıştırılabilir.

Karmaşık sapmaları, gruplar arası eğilimleri, bilimsel makullüğü, sıra dışı operatör yorumlarını ve kalan manuel ekleri incelemekten insanlar sorumlu olmaya devam ediyor. Yargı kararlarını otomatikleştirmeye çalışan bir BRBE tasarımı genellikle başarısız olur; herhangi bir sistem kontrolünden kaçınan bir tasarım ise israftan başka bir şey değildir. En iyi nokta, otomatik kontroller ve insan incelemesi arasında açıkça belgelenmiş bir iş bölümüdür.

5) İstisna Kurallarını ve Risk Sınıflarını Tanımlama

BRBE'nin özünde istisna kuralları yer alır: sistemin insan müdahalesi gerektiren durumları işaretlediği koşullar. Bunlar Kalite Risk Yönetimi (QRM) , PFMEA , kontrol planları ve ürüne özgü bilgilerden türetilmelidir. Tipik kurallar kritik proses parametrelerini, malzeme kimliklerini, durum kontrollerini, ayar noktası/limit ihlallerini ve eksik onayları kapsar.

İstisnalar, değerlendiricilerin önceliklendirmesine yardımcı olmak için risk derecesine (kritik, büyük, küçük) göre derecelendirilmelidir. Çok az kural varsa, gerçek sorunları gözden kaçırırsınız. Çok fazla düşük değerli kural varsa, uyarı yorgunluğu yaratırsınız ve değerlendiricileri istisnaları okumadan toplu olarak kapatmaya teşvik edersiniz. Bu dengeyi doğru bir şekilde kurmak, yineleme ve hasta güvenliğini ve ürün kalitesini gerçekten etkileyen şeylere acımasızca odaklanmayı gerektirir.

6) Veri Bütünlüğü, Denetim İzleri ve ALCOA

BRBE'nin başarısı veya başarısızlığı veri bütünlüğüne bağlıdır . Temel veriler eksiksiz, tutarlı ve güvenilir değilse, otomatik kontroller yalnızca daha hızlı bir şekilde yanlış sonuçlar üretir. Sistemler ALCOA+ prensiplerine uymalı ve tüm kritik veri unsurları için sağlam denetim kayıtları tutmalıdır.

Yetkililer, denetimler sırasında BRBE raporlarını düzenli olarak denetim izleri, kullanıcı erişim hakları ve değişiklik geçmişleriyle karşılaştırır. Sistem, değerlerin sessizce üzerine yazılmasına, geriye dönük tarih atılmasına veya belgelenmemiş kural değişikliklerine izin veriyorsa, BRBE programınız bir kontrol iyileştirmesi değil, bir risk artırıcı olarak değerlendirilecektir.

7) Sapmalar, CAPA ve OOS ile Entegrasyon

Olgun bir tasarımda, BRBE (İşlem Hatası İncelemesi) sapma, OOS (Standart Dışı Sonuç) ve CAPA ( Düzeltici ve Önleyici Eylemler) iş akışlarıyla yakından bağlantılıdır. Belirli istisna türleri (örneğin kritik limit ihlalleri, reddedilen malzemelerin kullanımı, eksik anahtar imzalar) otomatik olarak bir sapma veya soruşturma kaydı gerektirmelidir. Diğerleri ise uygun yorumlar ve eklerle doğrudan eBR'de belgelenebilir ve gerekçelendirilebilir.

Denetçilerin görmek istediği şey tutarlılıktır: benzer istisnalar benzer yanıtlar üretir ve istisnalardaki eğilimler sistemik CAPA ve iyileştirmeleri yönlendirir. Aynı kural, aynı zayıf gerekçeyle defalarca tetikleniyorsa, BRBE verileriniz bir sonraki gözleminizin nereye varacağını sessizce söylüyor demektir.

8) Yayın Süresi ve QA İş Yükü Üzerindeki Etki

Doğru şekilde uygulandığında, BRBE, özellikle yüksek hacimli operasyonlarda, sürüm teslim sürelerini ve parti başına kalite güvence iş yükünü önemli ölçüde azaltabilir. İncelemeciler sayfaları taramak için daha az, gerçek sorunları çözmek için daha fazla zaman harcarlar. Metrikler genellikle zamanında sürüm, kuyruk uzunluğu ve "ilk seferde doğru" parti dokümantasyonu açısından iyileşir.

Ancak, asıl gerekçe personel sayısının azaltılması olmamalıdır. BRBE, çabayı tekrarlayan kontrollerden kural tasarımı, doğrulama, izleme ve sürekli iyileştirmeye kaydırır. Yönetim, BRBE'yi yalnızca bir maliyet düşürme aracı olarak ele alırsa, tasarım ve doğrulamada bazı hatalar yapılır ve düzenleyiciler sonunda bunu fark eder.

9) Uygulama Yol Haritası – Daraltarak Başlayın, Kanıtlayın, Sonra Ölçeklendirin

Pragmatik uygulamalar küçük adımlarla başlar: bir ürün, bir satır, parti kaydının bir bölgesi. BRBE için net bir URS tanımlayın , eBR/MES platformunda kuralları yapılandırın ve bunları yapılandırılmış bir CSV yaklaşımı altında (genellikle GAMP 5 ile uyumlu ) nitelendirin. Bir süre boyunca gölge modunu çalıştırın ve geleneksel tam incelemeyi BRBE çıktılarıyla karşılaştırın.

Güven sağlandıktan ve veriler eşdeğer veya daha iyi bir kusur tespiti gösterdikten sonra, BRBE kapsamını daha fazla ürüne, tesise ve sürece genişletebilirsiniz. Bu "kanıtla" aşamasını atlayıp her şeyi bir gecede tersine çevirmek, doğrulanmamış kural setleriyle ve denetçilerin önünde panik içinde geri adım atmanızla sonuçlanır.

10) Kuralların Kontrolü ve Yönetimini Değiştirin

İstisna kuralları, kontrol stratejinizin bir parçasıdır ve resmi değişiklik kontrolü altında olmalıdır . Değişiklikler risk değerlendirmesine tabi tutulmalı, test edilmeli ve belgelenmelidir; kuralları QRM, PFMEA ve spesifikasyonlarla ilişkilendiren açık gerekçeler sunulmalıdır. Kalite güvence ekibi, sürüm kararlarını etkileyen kural değişiklikleri üzerinde görünürlüğe ve veto hakkına sahip olmalıdır.

Siteler, kapsam, kritiklik, test kapsamı ve geçmişi de içeren aktif BRBE kurallarının bir envanterini tutmalıdır. Periyodik inceleme (örneğin PQR/APR veya doğrulama bakımıyla bağlantılı olarak), kuralların hala geçerli olup olmadığını ve istisna kalıplarının tasarım amacına uygun olup olmadığını kontrol eder.

11) Hibritler, Ekler ve Eski İşlemler

Çoğu kuruluş yıllarca hibrit modda yaşar: İşin bir kısmı tamamen elektroniktir; bir kısmı ise kağıt, PDF veya harici sistem çıktılarıdır. BRBE bu sınırlar konusunda dürüst olmalıdır. Sistemin göremediği veya yorumlayamadığı şeyleri "istisnai olarak inceleyemezsiniz".

Politikalar, kaydın hangi bölümlerinin BRBE'ye uygun olduğunu ve hangilerinin hala geleneksel inceleme gerektirdiğini açıkça belirtmelidir. Ekler (örneğin harici laboratuvar sertifikaları, manuel olarak yüklenen trend grafikleri), yapılandırılmış veri olarak entegre edilene kadar genellikle insan incelemesi gerektirir. Her şeyin kapsandığı varsayımı, aslında kapsanmadığı halde veri bütünlüğü bulgularına ulaşmanın hızlı bir yoludur.

12) Siteler, CMO'lar ve Kalite Anlaşmaları Arasında BRBE

Çok lokasyonlu ağlarda ve CMO ilişkilerinde, BRBE'nin kalite anlaşmalarıyla uyumlu olması gerekir . Sponsorlar, hangi kontrollerin otomatik olarak yapıldığı, istisnaların neye benzediği ve ne sıklıkla meydana geldiği konusunda şeffaflığa ihtiyaç duyar. CMO'lar ise parti serbest bırakılmadan önce hangi istisnaların üst kademeye bildirilmesi gerektiği konusunda netliğe ihtiyaç duyar.

BRBE tasarım ilkelerinin merkezler arasında standartlaştırılması, karşılaştırılabilirliği artırır ve istisnalar, CAPA ve verim konusunda ortak analizlere olanak tanır. Her merkez koordinasyon olmadan kendi kural taksonomisini oluşturursa, ağ düzeyinde yönetişim neredeyse imkansız hale gelir ve denetim yanıtları tutarsız hale gelir.

13) Yaygın Arıza Türleri ve Müfettişlerin Bunları Nasıl Tespit Ettiği

Yaygın BRBE başarısızlık örnekleri arasında zayıf veya eksik kural kümeleri, kural gerekçelerinin yetersiz dokümantasyonu, aynı istisna türünün tutarsız işlenmesi ve kuralların değişiklik veya yükseltmelerden sonra test edildiğine dair kanıt eksikliği yer alır. Bir diğer tehlike işareti ise, karmaşık bir sürece rağmen neredeyse boş bir istisna günlüğüdür; bu genellikle kuralların çok gevşek olduğu veya insanların düşündüğü yerde uygulanmadığı anlamına gelir.

Müfettişler, istisna istatistiklerini sapma kayıtları, CAPA temaları ve atölyedeki manuel gözlemlerle karşılaştıracaktır. BRBE kaydı her şeyin mükemmel olduğunu söylerken gerçekler açıkça mükemmel değilse, elektronik kontrollerinize olan güven keskin bir şekilde düşer ve müfettişin akıcı inceleme uygulamalarını kabul etme isteği de aynı şekilde azalır.

14) KPI'lar, Gösterge Panoları ve Sürekli İyileştirme

Tipik BRBE metrikleri arasında parti inceleme döngü süresi, zamanında serbest bırakılan partilerin yüzdesi, parti başına istisna sayısı (tür ve risk sınıfına göre), sapmalara yol açan istisnaların oranı ve tekrarlanma oranları yer alır. Bu metrikler PQR/APR , QMS gösterge panelleri ve yönetim incelemesine entegre edilmelidir.

"İdeal" bir istisna sayısı yoktur, ancak uç değerler bilgilendiricidir. Çok yüksek sayılar, zayıf temel kontrol veya gürültüyü gösterir; karmaşık bir süreçteki çok düşük sayılar ise genellikle yetersiz spesifikasyon anlamına gelir. Amaç, gerçek riskle ilişkili ve zaman içinde hedeflenen iyileştirmeleri yönlendiren, istikrarlı ve yorumlanabilir bir istisna profili oluşturmaktır.

15) SSS

S1. İstisnai Olarak Toplu İnceleme düzenleyiciler tarafından kabul edilebilir mi?
Evet, ancak belgelenmiş risk değerlendirmelerine dayanan, açık prosedürlere ve kuralların etkili olduğuna dair kanıtlara sahip, doğrulanmış bir sistemde uygulanırsa. Düzenleyiciler, konseptin kendisine değil, zayıf tasarıma ve yetersiz dokümantasyona itiraz ediyor.

S2. BRBE, QA çalışan sayısını azaltabileceğimiz anlamına mı geliyor?
Otomatik olarak değil. BRBE, QA'yı düşük değerli kontrollerden kurtarabilir ve fazla mesaiyi azaltabilir, ancak aynı zamanda kural tasarımı, doğrulama, izleme ve iyileştirme süreçlerinde yeni işler de yaratır. Çalışan sayısındaki herhangi bir azalmayı, birincil hedef olarak değil, olgunluğun bir yan ürünü olarak ele alın.

S3. Parti başına kaç istisna "normal"dir?
Evrensel bir sayı yoktur. Doğru seviye, süreç karmaşıklığına, kural seti tasarımına ve ürün riskine bağlıdır. Önemli olan, istisnaların anlamlı, yönetilebilir ve gözlemlenen süreç performansı ve kalite çıktılarıyla uyumlu olmasıdır.

S4. Doğrulama ve SOP'larda BRBE'yi nasıl gerekçelendiriyoruz?
Sistemin hangi kontrolleri gerçekleştirdiğini, kuralların QRM ve spesifikasyonlardan nasıl türetildiğini, nasıl test edildiğini (IQ/OQ/PQ), değişikliklerin nasıl kontrol edildiğini ve incelemecilerin istisnaları nasıl ele alıp belgelendirdiğini açıklayın. Ardından bunları URS'ye, risk değerlendirmelerine, doğrulama raporlarına ve SOP'lara yansıtın.

S5. Hala tam manuel parti incelemesi yapıyorsak pratik bir ilk adım nedir?
QA'nın bugün hangi kontrolleri gerçekleştirdiğini ve bunlardan hangilerinin eBR/MES'te güvenli bir şekilde otomatikleştirilebileceğini belirleyerek başlayın. Bir ürün için küçük bir yüksek değerli kural kümesi uygulayın, tam incelemeyle paralel olarak çalıştırın ve ölçeklendirmeden önce BRBE yaklaşımınızı iyileştirmek için sonuçları kullanın.

İlgili Okuma
• Toplu Kayıtlar ve Elektronik Sistemler: BMH | eBR | MES | Otomatik Toplu Kayıtlar | CSV
• Sürüm ve Kalite Denetimi: Toplu Sürüm | QP Sürümü | PQR/APR | KYS
• Veri Bütünlüğü ve Risk: Veri bütünlüğü | Denetim İzi | ALCOA + | QRM | Sapma/NCR | CAPA | GxP