Giriş
İlaç ve biyoteknoloji sektöründe üretim süreçlerinin dijitalleşmesiyle birlikte, elektronik kayıtların ve dijital imzaların yasal geçerliliği kritik bir konu haline gelmiştir. ABD Gıda ve İlaç Dairesi (FDA) tarafından 1997 yılında yayımlanan 21 CFR Part 11 düzenlemesi, elektronik kayıtların ve elektronik imzaların kağıt tabanlı muadilleriyle eşdeğer kabul edilmesi için gerekli koşulları tanımlamaktadır.
Ancak bu düzenleme yazıldığında SCADA sistemleri bugünkünden çok farklıydı. Geleneksel mimarilerde geliştirme ortamı (development) ile çalışma ortamı (runtime) birbirinden kesin çizgilerle ayrılırdı: yazılım geliştirilir, derlenir (compile), test edilir ve üretim ortamına dağıtılır (deploy). Bu süreç doğası gereği belirli bir "dondurma noktası" yaratır ve değişiklik yönetimini nispeten kolaylaştırır.
Peki ya bu ayrım ortadan kalkarsa? Modern SCADA platformlarında runtime ve development aynı ortamda yaşar; compile-deploy döngüsü yoktur. Bu, mühendisler için müthiş bir esneklik sunarken, kalite güvence yöneticileri için yepyeni bir soru ortaya çıkarır.
Bu Yazıda: FDA 21 CFR Part 11'in temel gereksinimlerini özetledikten sonra, modern SCADA mimarilerinin bu düzenlemeye nasıl farklı bir perspektif getirdiğini ve kalite güvence yöneticilerinin bu yeni paradigmada nasıl bir strateji izlemesi gerektiğini tartışacağız.
1. FDA 21 CFR Part 11: Kısa Bir Özet
Düzenleme üç temel eksen üzerine kuruludur:
1.1 Denetim İzi: Kim, Ne, Ne Zaman, Neden
Denetim izi (audit trail), 21 CFR Part 11'in bel kemiğidir. Proses verileri üzerindeki her değişikliğin kronolojik, değiştirilemez (immutable) ve tam bir kaydını gerektirir. Her kayıt şunları içermelidir:
- Değişikliği yapan kullanıcıyı
- Değiştirilen değerin eski ve yeni halini
- İşlemin zaman damgasını (NTP senkronize, UTC formatında)
- Değişiklik gerekçesini
1.2 ALCOA+ ve Veri Bütünlüğü
FDA'nın veri bütünlüğü çerçevesi olan ALCOA+ prensipleri, verilerin Atfedilebilir, Okunabilir, Eş zamanlı, Orijinal, Doğru olmasını ve ayrıca Tam, Tutarlı, Kalıcı ve Erişilebilir nitelikler taşımasını zorunlu kılar. Bu prensipler yalnızca proses verilerine değil, sistem yapılandırma verilerine de uygulanabilir.
1.3 Elektronik İmza Gereksinimleri
Elektronik imzaların yasal geçerlilik kazanması için:
- Benzersiz kullanıcı kimliği
- Çok faktörlü doğrulama
- İmza ile kayıt arasında kriptografik bağlama
- Her imzada anlam belirtilmesi (onay, inceleme, red)
2. Paradigma Değişikliği: Compile-Deploy'suz SCADA
Geleneksel SCADA dünyasını düşünün: Bir mühendis geliştirme ortamında ekranlar tasarlar, alarm limitlerini ayarlar, lojik yazar. Sonra bu proje derlenir, bir paket haline getirilir ve üretim sunucusuna yüklenir. Bu süreçte doğal bir "kapı" vardır: Derleme anı.
Modern SCADA platformlarında ise bu kapı yoktur. Runtime ve development aynı ortamda yaşar. Bir mühendis canlı sistemde bir tag'ın PLC adresini değiştirdiğinde, bu değişiklik anlık olarak devreye girer. Compile yok, deploy yok, aradaki tampon bölge yok.
Kritik Fark
Geleneksel mimaride değişiklik yönetimi doğal olarak compile-deploy sürecine gömülüdür. Modern mimaride ise bu süreç yoktur — dolayısıyla değişiklik yönetimi stratejisinin bilinçli olarak tasarlanması gerekir.
2.1 Bu Esneklik Ne Anlama Geliyor?
Bu mimari yaklaşım, sahada çalışan mühendisler için büyük bir avantajdır. Yeni bir sensör eklenip PLC programı güncellendiğinde, SCADA tarafındaki tag tanımını hemen canlı sistemde yapılandırabilirsiniz. Anlık müdahale, hızlı adaptasyon ve kesintisiz operasyon mümkün hale gelir.
Ancak bu esneklik, FDA 21 CFR Part 11 perspektifinden bakıldığında önemli bir soru işareti çiziyor: Bir geliştiricinin proje üzerinde yaptığı yapısal değişiklikler denetim izi kapsamına girmeli mi?
3. İki Yaklaşım: Dijitalizasyon mu, Kilitleme mi?
Bu sorunun iki temel cevabı vardır ve her ikisinin de güçlü argümanları bulunmaktadır. Kalite güvence yöneticisinin görevi, tesisinin gerçeklerine en uygun yaklaşımı seçmektir.
Yaklaşım A: Geliştirici Değişikliklerini de Dijitalize Et
Bu yaklaşımda, SCADA projesi üzerinde yapılan her türlü yapılandırma değişikliği FDA uyumlu denetim izi kapsamına alınır.
- Tam izlenebilirlik: Proje üzerindeki her değişiklik; kim yaptı, ne değişti, ne zaman değişti ve neden değişti bilgileriyle kaydedilir.
- Elektronik imza entegrasyonu: Kritik yapılandırma değişiklikleri için elektronik imza ile onay zorunlu kılınabilir.
- Otomatik versiyon geçmişi: Projenin her anına geri dönülebilir bir zaman çizelgesi oluşur.
- Sürekli uyum: Denetim sırasında hiçbir değişikliğin belgelenmediği itirazıyla karşılaşma riski ortadan kalkar.
Yaklaşım B: Test Et, Onayla, Kilitle
Bu yaklaşımda geleneksel validasyon mantığı korunur. Geliştirici değişiklikleri serbestçe yapılır; proje konvansiyonel IQ/OQ/PQ test sürecinden geçtikten sonra kilitlenir.
- Serbest geliştirme: Mühendisler herhangi bir denetim izi kısıtlaması olmadan proje üzerinde çalışır.
- Validasyon süreci: Proje tamamlandığında standart IQ/OQ/PQ test süreci uygulanır.
- Proje kilitleme: Validasyon sonrası proje "frozen" duruma alınır.
- Değişiklik kontrolü: Kilitli projeye yapılacak her değişiklik, resmi değişiklik kontrol süreci gerektirir.
4. Karşılaştırmalı Değerlendirme
| Boyut | Yaklaşım A (Dijitalize Et) | Yaklaşım B (Kilitle) |
|---|---|---|
| Geliştirme hızı | Denetim izi yükü olabilir | Maksimum hız |
| Denetim hazırlığı | Her an hazır | Validasyon belgesi gerekli |
| İzlenebilirlik | Sürekli ve otomatik | Validasyon sonrası |
| Esneklik | Kontrollü esneklik | Kilitleme sonrası kısıtlı |
| Uygulama karmaşıklığı | Yüksek (platform desteği gerekli) | Düşük (SOP tabanlı) |
| En uygun senaryo | Sık değişen, kritik süreçler | Kararlı, nadiren değişen sistemler |
5. Hibrit Yaklaşım: En İyisini Birleştirmek
Pratikte çoğu tesis için en uygun çözüm, iki yaklaşımın güçlü yönlerini birleştiren bir hibrit model olacaktır.
Katmanlı Değişiklik Yönetimi
Değişiklikleri kritiklik düzeyine göre sınıflandırın:
| Seviye | Örnek | Gereksinim |
|---|---|---|
| Kritik | Alarm limiti, PLC adresi, kontrol lojik | Denetim izi + Elektronik imza + Onay |
| Orta | Ekran düzeni, tag açıklaması | Denetim izi + Otomatik log |
| Düşük | Renk şeması, dil ayarı | Standart değişiklik kaydı |
Geliştirme ve Üretim Modları
- Geliştirme modunda değişiklikler otomatik olarak loglanır ancak onay gerektirmez.
- Üretim moduna geçiş bir validasyon süreci ve elektronik imza gerektirir.
- Üretim modunda kritik değişiklikler için anlık onay mekanizması devreye girer.
- Mod geçişleri de denetim izine dahil edilir.
6. Kalite Güvence Yöneticileri İçin Pratik Öneriler
Hangi yaklaşımı seçerseniz seçin, aşağıdaki adımlar uygulama sürecinizi sağlamlaştıracaktır:
- Risk değerlendirmesi yapın: SCADA projenizde hangi yapılandırma unsurlarının ilaç kalitesini veya hasta güvenliğini doğrudan etkilediğini belirleyin.
- Değişiklik kategorilerini tanımlayın: Kritik yapısal unsurlar ile düşük etkili unsurları ayrı sınıflandırın.
- SOP'larınızı güncelleyin: Mevcut SOP'larınız muhtemelen compile-deploy varsayımına göre yazılmıştır. Runtime development mimarisi için spesifik prosedürler oluşturun.
- SCADA tedarikçinizle çalışın: Platformun denetim izi, proje kilitleme, elektronik imza ve rol tabanlı erişim kontrolü yeteneklerini detaylı şekilde değerlendirin.
- Eğitim planı oluşturun: Geliştiriciler ve operatörler, seçilen yaklaşımın gereksinimlerini ve kendi sorumluluklarını anlamalıdır.
- Periyodik gözden geçirme planlayın: Seçilen stratejiyi düzenli aralıklarla değerlendirin ve gelişen gereksinimlere göre uyarlayın.
Sonuç
FDA 21 CFR Part 11, 1997 yılında yazıldığında SCADA sistemleri katı bir compile-deploy döngüsüne sahipti ve düzenlemenin varsayımları bu gerçekliğe dayanıyordu. Bugün ise SCADA dünyası kökten değişti. Runtime ve development'ın iç içe geçtiği modern platformlar, esneklik ve hız sunarken, değişiklik yönetimi konusunda yeni sorular ortaya çıkarıyor.
Bu soruların tek bir doğru cevabı yoktur. Doğru strateji; tesisinizin risk profiline, üretim süreçlerinizin kritikliğine, ekibinizin yapısına ve mevcut kalite yönetim sisteminize bağlıdır. Önemli olan, bu soruyu görmezden gelmek değil, bilinçli bir seçim yapmak ve bu seçimi belgelemektir.
Modern SCADA platformları, her iki yaklaşımı da — ve ikisinin hibrit kombinasyonlarını da — teknik olarak destekleyebilecek altyapıya sahiptir. Kalite güvence yöneticisi olarak sizin göreviniz, bu teknik imkânları doğru stratejiyle buluşturmak ve FDA denetçisinin karşısına çıktığınızda "Biz bu sorunu düşündük ve işte stratejimiz" diyebilmektir.