To read this article in English, please visit; How to Validate your Online Monitoring System?

Öncelikle bu makaleye geçmeden hatırlatmakta fayda var. Bu makale websitemde yeralan Temizoda Partikül İzleme Sistemi Nasıl Tasarlanır? isimli makalenin devamı niteliğinde. Henüz okumadıysanız başlamadan göz gezdirmekte fayda var.

Bir önceki yazımızda, bir izleme sisteminin tasarımının ayrıntılarını ele aldık. Özellikle güncel düzenlemeler, standartlar ve yardımcı referanslar bu makalede ele alındı. Şu an okumakta olduğunuz yazı ise, ISPE GAMP5'e göre doğrulama adımlarının ardından izleme sistemi kurulumunu kapsayacaktır.

ISPE GAMP5 Hakkında

ISPE (International Society for Pharmaceutical Engineers), diğer adı ile Uluslararası İlaç Mühendisleri Derneği tarafından global ölçekte yazılan GAMP bilgisayarlı sistem validasyonları için risk temelli bir yaklaşımdır. Good Automated Manufaturing Practices cümlesinin kısaltmasıyla oluşan bu terim dilimize “İyi Ototmatik (bilgisayarlı/otomasyon) Üretim Uygulamaları” olarak çevrilebilir. GAMP5 sürümü uzman görev ekibi ve çeşitli ülkelerden saha ve yönlendirme komitelerinde görev alan Konu Uzmanları tarafından 2008 yılında yayımlanmıştır. Kategori 1 “altyapı yazılımı”ndan Kategori 5 “özel uygulamalara” kadar uygun yaşam döngüsü aktivitelerinin ve dokümantasyonun seçilmesi ile ilgili kategorizasyon yardımcıları içerir. Sistemi kategorize etmek, sistem dokümantasyonunun verimli bir şekilde yazılmasına yardımcı olur (şartnameler ve test komut dosyaları ve bunların arasında kalan her şey). Aşağıdaki tablo, kategoriler ve kullanım amaçları hakkında daha fazla bilgi vermektedir.

ISPE GAMP5 Seviye Tanımları
KATEGORI	AÇIKLAMA	ÖRNEK UYGULAMA
Kategori 1 Altyapı Yazılımı	Altyapı Yazılımı Çalışma ortamları Katmanlı Yazılım	İşletim sistemleri, Programlama dilleri, Tablolar
Kategori 2	GAMP 5'te mevcut değil (GAMP4'te aygıt yazılımı olarak kullanılmaktaydı)
Kategori 3 Yapılandırılmamış	Çalışma zamanı parametreleri girilebilir ve saklanabilir, ancak sw yapılandırılamaz	Firmware tabanlı uygulamalar, Hazır yazılım Enstrümanlar
Kategori 4 Yapılandırılmış Yapılandırılabilir karmaşık yazılım	apılandırılmış Yapılandırılabilir karmaşık yazılım SW kodu değiştirilmemiş.	LIMS, Veri Toplama Sistemleri SCADA, ERP, HMI Bina yönetim sistemi Tablolar,
Kategori 5 Özel	İş sürecine uygun tasarlanmış ve kodlanmış özel yazılım	IT Uygulamaları, Proses Kontrol uygulamaları Özel merdiven mantığı, Özel aygıt yazılımı, Elektronik tablo (makrolar)

Risk değerlendirmesi ve tedarikçi değerlendirmesi ile birlikte yapıldığında, kategorizasyon etkili bir kalite risk yönetimi yaklaşımının bir parçası olabilir. Kategoriler, diğer risk yönetimi araçlarıyla birlikte ve sistemin karmaşıklığı ve büyüklüğü göz önünde bulundurularak kullanılırsa yararlıdır. Kategorizasyon açısından, aşağıdaki durumda karmaşıklık ve risk artmaktadır;

Özel (Kategori 5) > Yapılandırılmış (Kategori 4) > Yapılandırılmamış (Kategori 3) > Altypaı (Kategori 1)

Buradaki 2 yaklaşım oldukça kritiktir: risk temelli yaklaşım ve yaşam döngüsü yaklaşımı. Şu anda tüm Temiz oda endüstrilerinde moda oldukları için değil, gerçekten doğru sistem tasarımı ve uygulamasına hizmet ettikleri için kritiktirler.

kurulum ve performans kalifikasyonu

Yaşam Döngüsü Yaklaşımı Nedir?

Tüm sistem bir kavram olarak yaşadığından, birçok parametre, değerlendirme ve/veya gereksinimler bu yaşam sürecinde değişmektedir. Bu nedenle bilgisayarlı sistem doğrulaması için A'dan Z'ye düz bir çizgi yoktur. Yaşam döngüsü yaklaşımı, Şekil 1'de gösterildiği gibi GAMP5'te de açıklanmaktadır.

Yasam Dongusu Yaklasimi

Şekil 1 - Yaşam Döngüsü Yaklaşımı

Herhangi bir sistem için yaşam döngüsü dört ana aşamadan oluşur;
Konsept,
Proje,
Operasyon,
Sistem Emekliye Ayırma

GAMP5'e göre, ürün ve hizmet tedarikçileri yaşam döngüsü boyunca uygun şekilde dahil edilmelidir. Tariflenen faaliyetlerin birçoğunu, tatmin edici tedarikçi değerlendirme ve kontrol önlemlerine tabi olacak şekilde tedarikçiye vermek uygun olabilir.

Risk Tabanlı Yaklaşım Nedir?

Tanımlanan riskleri yönetmek ve yaşam döngüsünün her aşamasında gereken faaliyetlerin kesinliğini ve kapsamını belirlemek için yaşam döngüsü boyunca uygun risk yönetimi süreçleri izlenmelidir.

Şekil 2, yaşam döngüsü boyunca risk temelli karar verme yaklaşımının tipik kullanımını göstermektedir.

ISPE GAMP5 Risk Tabanli Yaklasim

Şekil-2 Yaşam Döngüsünde Risk Tabanlı Yaklaşım

Sistem yazılımlarının izlenmesi ile ilgili konuşurken bahsettiğimiz sistemlerin hepsi yapılandırılmış sistemler (kategori 4) ve hatta müşterinin özel gereksinimlerini karşılamak için özel veri modülleri içeren karmaşık yapıları hatta özel merdiven mantığı olan PLC'ler ve özel aygıt yazılımlarına sahip özel (kategori 5) platformlardır. Uygun GAMP5 gereksinimlerini uygulayabilmek için, özel uygulama için risk temelli yaklaşım sürdürülmelidir. Burada 2 aşama vardır: Kullanıcı Gereksinimi Şartnamesi oluşturulmadan önce yapılan ilk risk değerlendirmesi ve spesifikasyon aşamalarında (fonksiyonel, tasarım, modül spesifikasyonları) yapılan Fonksiyonel Risk Değerlendirmesi

İlk risk değerlendirmesi için aşağıdaki noktalara dikkat etmek gerekir;

İşletmenin genel riskleri nelerdir?
Sistem GxP belirlenmesi,
Sistemin genel etkisi nedir?
Daha ayrıntılı risk değerlendirmeleri gerekli mi?

Fonksiyonel Risk Değerlendirmesi için aşağıdaki noktaları belirleyin ve tanımlayın;

Belirli süreçler için riskleri belirleyin,
Belirli fonksiyonlar için riskleri belirleyin,
Kontrolleri tanımlamak ve riski azaltın,
Gerekirse bu adımları yineleyin

Şekil 2'de görebileceğiniz gibi, proje aşaması planlamadan raporlamaya kadar birçok faaliyeti kapsar. GAMP5 V Şeması adı verilen bu şekilde, sol taraftaki bu spesifikasyon adımları sağdaki doğrulama adımlarıyla eşleşir.

GAMP 5 V Şeması Nedir?

Şekil 3 - ISPE GAMP5 Genel V Şeması

GAMP V şeması, tüm spesifikasyon ve test faaliyetlerini basitçe özetler. Şekil 2, sol taraftaki şartname adımlarını ve sağ taraftaki test/yeterlilik/doğrulama adımlarını göstermektedir. Sağ taraftaki her seviye aynı zamanda soldaki aynı seviye spesifikasyon adımlarını doğrular.

Şekil 3, çevrimiçi izleme sistemlerine ilişkin adımları kategori 5 olarak özetlemektedir: özel uygulama için doğrulama planlamasından doğrulama raporlamasına kadar geçen süreç.

Şekil 4 : Özel bir uygulama için GAMP5 V Şema Yaklaşımı (Kategori 5)

Görebileceğiniz gibi, kategori 1'den kategori 5'e kadar en kritik adım ilk adımdır: Kullanıcı Gereksinimi Şartnamesi. Müşterinin multidisipliner yönlendirme komitesi tarafından belirlenen uygun kullanıcı gereksinimi spesifikasyonları olmadan, çevrimiçi izleme sistemi kurulum ve onaylama süreçleri tedarikçilerin bilgisi, KYS'lerinin etkinliği, ürün kapasitesi ve proje yönetimi yetenekleri ile sınırlı kalacaktır. Canlı ve cansız izleme sistemleri üzerindeki uygulamaların çoğu sınırlıdır ve uygun Kullanıcı Gereksinimi Şartnamesi bulunmamasından dolayı ihtiyaçları tamamen karşılamamaktadır.

Kullanıcı İstekleri Spesifikasyonu (URS) Nedir?

Denetlenen bir şirket olarak doğru sonuçlar elde etmek için, kendi Kullanıcı İstekleri Spesifikasyonu (User Requirement Specification) veya bir diğer adı ile Kullanıcı Gereksinimleri Şartnamenizin hazılrık sürecini kalite, üretim, mühendislik vb. gibi farklı operasyonlardan birkaç kişi ile yürüttüğünüzden emin olun. Piyasada URS için hazır şablonlar bulunmaktadır, ve ne yazık ki bazı son kullanıcılar bu tarz “her koşul için tek çözüm” şeklindeki KGŞ şablonlarını benimseme eğilimindedir. Tanımlanan limitler, düzenlemeler ve/veya standartlar gibi birçok son kullanıcı için aynı olan belli parametreler olsa bile, yine de planlandığı gibi hedeflere ulaşabilmek için son kullanıcı tarafından göz önünde bulundurulması gereken birçok husus vardır. Bununla birlikte, Kullanıcı Gereksinimi Anket formları, Teknik yönleri belirlemek, beklentileri özetlemek ve ürünün teknik yetenekleri ile amaçlanan kullanım alanları arasındaki boşluğu doldurmada yardımcı olabilir.

Gereksinimlerinizi belirlerledikten sonra dönüp bir daha bakın ve aşağıdaki özelliklere sahip olduğundan emin olun;

Spesifik
Ölçülebilir,
Başarılabilir,
Gerçekçi,
Test edilebilir.

Test ve kontrol için spesifik olun;

Anlaşılır
Açık ve net,
Kesin
Kendine yeten

Gereksinim önceliklerini sıralandırın;

Zorunlu (Yüksek)
Faydalı (Orta)
Olsa iyi olur (düşük)

Gereksinimler tam olarak tanımlandıklarından ve doğrulanabilir ve objektif olduklarından emin olmak için analiz edilmelidir. Örneğin “oda 20˚C’de kontrol edilecek” demek eksik bir gereksinimdir. Ancak, “oda 20˚C ± 2˚C de kontrol edilmelidir. 7˚C'den daha büyük olmayan sapmalara <10 dakika süreyle izin verilir” şeklindeki tanımlama eksiksiz, ölçülebilir ve nesnel gereksinimin güzel bir örneğidir.

Fonksiyonel Spesifikasyon

Fonksiyonel Spesifikasyon (FS), Kullanıcı Gereksinimi Şartnamesi bölümünde açıklandığı şekilde kullanıcı gereksinimlerini karşılayacak bir sistemi tanımlar. FS, tasarımın devam etmesini sağlamak için dokümanı hazırlayan tarafa sık sık danışılmasını gerektirmeyecek şekilde yalın olmalıdır. Uygun olan yerlerde diyagram ve grafikleri kullanmak her iki tarafın da spesifikasyonları kolayca anlamalarına yardımcı olabilir.

Dokümanın içeriği şöyledir:

Giriş: mülkiyet, üretici, yetki ve URS gibi diğer belgelerle ilişki.
Genel bakış: Arka plan, GxP düzenlemelerine referans, etkiler (ürün, hasta, kalite vb.), Sistem ile diğer sistemler ve/veya çevre arasındaki ana arayüzler. Varsa URS ile uyumsuzluk.
Fonksiyonlar: Sistemin diğer bölümleriyle arayüz de dahil olmak üzere işlev veya tesisin amacı, ve kullanımının ayrıntılarına değinilmelidir. URS'deki özel gereksinimlere yönelik izlenebilirlik burada da ele alınmalıdır.
Veri: Tüm girdi ve çıktılar için izin verilen değer aralıkları, veri ilişkisi, kapasite, bütünlük, güvenlik, taşıma.
Arayüzler: Sunucu, bilgisayar, klavye, ekranlar, modüller, sensörler, kontrolörler vb. tüm arayüzler burada tanımlanmalı ve açıklanmalıdır.
İşlevsel olmayan nitelikler: Sistemin yerine getireceği ek işlevler bu bölüm altında açıklanmalıdır (kullanılabilirlik, sürdürülebilirlik vb.)
Sözlük : Kullanılan kısaltmalar, teknik terimler ve iş özelinde belirlenen kelimelerin açıklandığı kısım.

Ekler

Şekil 5 - Konum, kablo kimiği, cihaz kimliği ve seri numarası ile doğru etiketleme

Konfigürasyon Spesifikasyonu

Konfigürasyon ve tasarım spesifikasyonları, FS’nin ayrıntılı bir şekilde teknik olarak genişletilmesini sağlar. Bu bölüm sistemin FS'de tanımlanmış olan şeyleri nasıl yapacağını açıklar. Hem donanım hem de yazılım tasarım spesifikasyonları bu belgenin altında ele alınır. Konfigürasyon Spesifikasyonu yapılandırılmış ürünler için sağlanmalı ve sistemi oluşturan yazılım ürünlerinin belirtilen gereksinimleri karşılamak için uygun konfigürasyonunu kapsamalıdır.

Dokümanın içeriği şöyledir:

Giriş: mülkiyet, üretici, yetki ve URS ve FS gibi diğer belgelerle ilişki.
Genel bakış: Yapılandırma ve/veya tasarımı, belgede tanımlandığı şekilde kısaca tanımlamalıdır. Sistem, donanım ve / veya yazılımın tamamını kapsayabilir. Bu bölümde diyagramlar kullanılabilir.
Konfigürasyon: Gerekli yapılandırma ayarları ve parametreleri, ayarların nedenleri, gerekli seçenekleri ayarlamak için kullanılacak araçlar veya yöntemler. Modül veya sistem durumu, ayarların güvenliği vb.
Donanım Tasarımı: Bilgisayar sistemi, kablo ve konektör özellikleri, çizim, ağ ve diğer dış bağlantılar, diyagramlar (konum, düzen, kablolama, borulama, vakum altyapısı, güç kabloları, çevre parametreleri, elektrik malzemeleri vb.).
Yazılım Tasarımı: Yazılım tanımı, sistem verileri, modül tanımı, kullanıcı seviyeleri vb.

Sözlük : Kullanılan kısaltmalar, teknik terimler ve iş özelinde belirlenen kelimelerin açıklandığı kısım.

GAMP5 V Şemasının sol tarafı olan spesifikasyon kısmını bitirdikten sonra; Kullanıcı Gereksinimi Şartnamesinde belirttiğimiz ve Fonksiyonel Spesifikasyon dokümanında ele aldığımız ve yerine getirdiğimiz ve daha sonra Konfigürasyon Spesifikasyonu dokümanında ayrıntılı olarak açıklanacak olan online partikül izleme sistemimizi artık kurabiliriz.

Bir sonraki yazımız V şemasının sağ tarafında olan verifikasyon adımlarını ve ayrıca sistem bakımını kapsayacaktır.