1. Pendahuluan: GAMP® 5, GMP, dan Pentingnya Manajemen Risiko
Lingkungan Good Manufacturing Practice (GMP) modern, termasuk manufaktur farmasi, laboratorium, dan uji klinis, sangat bergantung pada sistem terkomputerisasi untuk mengontrol proses, mengelola data, dan memastikan kualitas produk.1 Ketergantungan ini membawa serta pengawasan regulatori yang ketat dari badan-badan seperti FDA (Food and Drug Administration) Amerika Serikat dan EMA (European Medicines Agency) Eropa.4 Memastikan kepatuhan terhadap regulasi ini adalah standar minimum yang harus dicapai oleh perusahaan di industri life sciences.1
Dalam konteks ini, pedoman GAMP® 5 (Good Automated Manufacturing Practice, Versi 5), yang diterbitkan oleh ISPE (International Society for Pharmaceutical Engineering), telah menjadi kerangka kerja panduan industri terkemuka secara global.4 GAMP® 5 menyediakan pendekatan praktis untuk mencapai sistem terkomputerisasi yang sesuai dengan GxP (Good Practice) yang berlaku.12 Penting untuk dipahami bahwa GAMP® 5 bukanlah regulasi yang mengikat secara hukum, melainkan seperangkat panduan dan praktik terbaik yang diterima secara luas oleh regulator dan dirujuk dalam dokumentasi mereka.6
Tujuan utama GAMP® 5 adalah memastikan bahwa sistem terkomputerisasi “sesuai untuk tujuan penggunaan” (fit for intended use) dan, yang terpenting, melindungi keselamatan pasien, kualitas produk, dan integritas data.1 Pedoman ini juga bertujuan untuk mencapai tujuan ini secara efektif dari segi biaya.7
Inti dari GAMP® 5 adalah penerapan pendekatan berbasis risiko.1 Pendekatan ini selaras dengan prinsip-prinsip Manajemen Risiko Mutu (Quality Risk Management – QRM) yang diuraikan dalam ICH Q9.1 GAMP® 5 mengadopsi QRM sebagai proses berulang yang diterapkan sepanjang siklus hidup sistem terkomputerisasi, mulai dari konsep hingga pensiun (retirement), untuk mengelola risiko yang terkait.1
Secara signifikan, GAMP® 5, terutama Edisi Kedua (Second Edition), menandakan pergeseran filosofis dalam validasi sistem terkomputerisasi. Pedoman ini sangat menekankan penggunaan pemikiran kritis (critical thinking) oleh para ahli materi (Subject Matter Experts – SMEs) yang berpengetahuan dan berpengalaman.2 Ini merupakan langkah menjauh dari pendekatan berbasis kepatuhan yang kaku dan preskriptif (“pendekatan checklist” 20), yang seringkali tidak sepadan dengan risiko aktual dan dapat menghambat inovasi.17 Sebaliknya, GAMP® 5 mendorong pendekatan yang proporsional, pragmatis, dan efektif dalam mengelola risiko, berfokus pada aktivitas yang menambah nilai daripada sekadar “dokumentasi demi dokumentasi”.13 Hal ini mencerminkan pemahaman bahwa validasi bukanlah tentang menghasilkan tumpukan dokumen, tetapi tentang membangun keyakinan bahwa sistem aman, efektif, dan andal untuk tujuan penggunaannya. Lebih jauh lagi, GAMP® 5 mengakui sifat dinamis dari sistem modern dan pergeseran dari paradigma lama “validasi sistem dan jaga agar tetap statis” menuju pendekatan yang fleksibel untuk mempertahankan status terkontrol yang tervalidasi sepanjang masa operasionalnya, terutama mengingat pembaruan perangkat lunak dan lingkungan operasi yang sering terjadi.21
Peningkatan fokus regulator pada integritas data (Data Integrity – DI) dalam beberapa tahun terakhir juga sangat memengaruhi penerapan GAMP® 5.1 Kekhawatiran tentang masalah integritas data, seperti yang sering dikutip dalam temuan inspeksi 5, telah memperkuat pentingnya penilaian risiko yang secara khusus menargetkan kerentanan DI. Aspek-aspek seperti jejak audit (audit trails), kontrol akses, dan tanda tangan elektronik (electronic signatures) kini menjadi fokus utama dalam penilaian risiko untuk memastikan data GxP bersifat ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, Available).5
Laporan ini bertujuan untuk memberikan penjelasan tingkat ahli mengenai Penilaian Risiko Fungsional (Functional Risk Assessment – FRA) dalam konteks kerangka kerja GAMP® 5 dan lingkungan GMP, menyoroti definisi, proses, dokumentasi, contoh praktis, dan hubungannya dengan strategi validasi.
2. Penilaian Risiko Fungsional (FRA) dalam Kerangka GAMP® 5
Definisi FRA
Penilaian Risiko Fungsional (FRA) adalah teknik penilaian risiko spesifik yang digunakan dalam proses QRM GAMP® 5.1 Tujuan utamanya adalah untuk mengevaluasi secara sistematis risiko yang terkait dengan fungsi-fungsi spesifik dari sistem terkomputerisasi.23 Penilaian ini difokuskan terutama pada fungsi-fungsi yang memiliki dampak potensial terhadap area GxP kritis: keselamatan pasien, kualitas produk, dan integritas data.1
Peran FRA dalam Siklus Hidup QRM
FRA menempati posisi penting dalam alur kerja QRM GAMP® 5 secara keseluruhan.1 Proses ini biasanya dilakukan setelah penilaian risiko awal atau penilaian dampak sistem (yang menentukan apakah sistem tersebut relevan dengan GxP) telah selesai.1 FRA kemudian berfokus pada fungsi-fungsi yang diidentifikasi memiliki potensi dampak GxP.1
Secara waktu pelaksanaan, FRA umumnya dilakukan setelah Spesifikasi Kebutuhan Pengguna (User Requirements Specifications – URS) dan Spesifikasi Fungsional (Functional Specifications – FS) dan/atau Spesifikasi Desain (Design Specifications – DS) telah didefinisikan dan disetujui.23 Penempatan waktu ini sangat penting karena memungkinkan penilaian risiko dilakukan terhadap fungsionalitas sistem yang telah ditentukan dengan jelas.
FRA berfungsi sebagai jembatan krusial yang menerjemahkan persyaratan GxP tingkat tinggi (seperti yang diuraikan dalam URS) dan konsep desain sistem (dari FS/DS) menjadi kontrol risiko yang konkret dan dapat ditindaklanjuti, serta aktivitas validasi yang terarah. Tanpa FRA, validasi berisiko menjadi latihan generik yang tidak fokus. Dengan menilai risiko pada tingkat fungsional, FRA memastikan bahwa upaya validasi terkonsentrasi pada area-area yang benar-benar penting untuk kepatuhan GxP dan kinerja sistem, sehingga mengoperasionalkan pendekatan berbasis risiko pada tingkat detail fungsional.39
Tujuan FRA
Tujuan spesifik dari pelaksanaan FRA meliputi 23:
Mengidentifikasi Mode Kegagalan Potensial: Untuk setiap fungsi kritis GxP, mengidentifikasi cara-cara potensial fungsi tersebut dapat gagal atau menyimpang dari operasi yang dimaksudkan.
Menilai Dampak (Severity): Mengevaluasi konsekuensi potensial dari kegagalan fungsi tersebut terhadap keselamatan pasien, kualitas produk, dan integritas data.
Menilai Kemungkinan (Probability): Menilai seberapa besar kemungkinan mode kegagalan tersebut terjadi.
Menilai Detektabilitas (Detectability): Mengevaluasi seberapa besar kemungkinan kegagalan atau dampaknya dapat dideteksi secara tepat waktu oleh sistem atau prosedur sebelum menyebabkan kerugian signifikan.
Menentukan Prioritas Risiko: Menetapkan tingkat prioritas risiko keseluruhan untuk setiap fungsi/mode kegagalan berdasarkan kombinasi severity, probability, dan detectability.
Mengidentifikasi Kontrol (Mitigasi): Mengidentifikasi dan mengusulkan tindakan pengendalian (tindakan mitigasi) yang diperlukan untuk mengurangi risiko yang tidak dapat diterima ke tingkat yang dapat diterima.1
Menginformasikan Strategi Validasi: Memberikan masukan penting untuk pengembangan strategi validasi dan pengujian, memastikan bahwa upaya pengujian sepadan dengan tingkat risiko (dibahas lebih lanjut di Bagian 6).
Membedakan FRA dari Penilaian Risiko Tingkat Sistem
Penting untuk membedakan FRA dari penilaian risiko tingkat sistem atau proses yang lebih tinggi.1 Sementara penilaian risiko tingkat sistem melihat sistem secara keseluruhan atau proses bisnis yang didukungnya, FRA menggali lebih dalam ke detail fungsional spesifik di dalam sistem tersebut. Keduanya saling melengkapi dalam memberikan gambaran risiko yang komprehensif.
Meskipun kategorisasi sistem GAMP® 5 (misalnya, Kategori 3 untuk perangkat lunak COTS, Kategori 4 untuk produk terkonfigurasi, Kategori 5 untuk aplikasi kustom) 2 memberikan panduan awal mengenai kompleksitas dan potensi risiko inheren suatu sistem, FRA memberikan profil risiko yang jauh lebih granular dan spesifik. Profil ini didasarkan pada tujuan penggunaan sistem dan fungsi spesifik yang akan diimplementasikan dalam konteks GxP tertentu, bukan hanya pada kategori generiknya. GAMP® 5 sendiri memperingatkan agar tidak terlalu bergantung pada kategori (“pemikiran silo” – silo-thinking20) dan menekankan perlunya menskalakan aktivitas berdasarkan dampak GxP, kompleksitas, dan kebaruan sistem.2 FRA adalah mekanisme untuk melakukan penskalaan ini secara cerdas. Sebagai contoh, sistem Kategori 4 (terkonfigurasi) mungkin memiliki banyak fungsi berisiko rendah, sementara sistem Kategori 3 (COTS) dapat digunakan sedemikian rupa sehingga satu fungsi spesifiknya menjadi sangat kritis dan berisiko tinggi. FRA memungkinkan identifikasi dan pengelolaan nuansa risiko semacam ini.
3. Melaksanakan FRA: Panduan Langkah demi Langkah
Pelaksanaan FRA yang efektif memerlukan pendekatan sistematis dan keterlibatan tim yang tepat.
Prasyarat
Sebelum memulai FRA, pastikan prasyarat berikut terpenuhi:
Dokumen yang Disetujui: URS dan FS/DS yang telah disetujui harus tersedia sebagai dasar penilaian.23 Dokumen-dokumen ini mendefinisikan apa yang harus dilakukan sistem dan bagaimana fungsi-fungsi tersebut diimplementasikan.
Tim Lintas Fungsi: Bentuk tim yang terdiri dari perwakilan dari berbagai bidang keahlian, termasuk SMEs (Subject Matter Experts) proses bisnis, personel Quality Assurance (QA), spesialis IT/otomasi, dan Pemilik Proses/Sistem.20 Keberagaman keahlian ini memastikan analisis risiko yang komprehensif.
Pemahaman Produk dan Proses: Pemahaman mendalam tentang produk yang diproduksi, proses yang didukung oleh sistem terkomputerisasi, dan persyaratan GxP yang relevan sangat penting.2 Efektivitas FRA sangat bergantung pada kualitas masukan ini; persyaratan yang ambigu atau kurangnya pemahaman proses akan menghasilkan penilaian risiko yang lemah atau tidak akurat.
Langkah-langkah Proses FRA
Berikut adalah langkah-langkah umum dalam melakukan FRA berdasarkan GAMP® 5:
Langkah 1: Identifikasi Fungsi dengan Dampak GxP
Tinjau URS dan FS/DS untuk membuat daftar semua fungsi sistem.
Berdasarkan penilaian dampak sistem awal dan pemahaman proses, identifikasi fungsi-fungsi mana yang memiliki potensi dampak langsung atau tidak langsung terhadap keselamatan pasien, kualitas produk, atau integritas data.1 Fokuskan upaya FRA pada fungsi-fungsi ini. Masukan untuk langkah ini meliputi spesifikasi, arsitektur sistem, dan kategorisasi komponen (jika relevan).1
Untuk setiap fungsi relevan GxP yang diidentifikasi pada Langkah 1, lakukan brainstorming untuk mengidentifikasi cara-cara potensial fungsi tersebut dapat gagal berfungsi (failure modes) atau menyimpang dari operasi yang diharapkan.25
Pertimbangkan berbagai skenario operasi, termasuk kondisi normal, kondisi batas, dan potensi kesalahan pengguna atau sistem. Identifikasi potensi bahaya (hazards) yang terkait dengan setiap mode kegagalan.1
Metode Analisis Mode Kegagalan dan Efek (Failure Mode and Effects Analysis – FMEA) sering digunakan sebagai teknik terstruktur untuk langkah ini.16 Meskipun FMEA sering digunakan dalam FRA GAMP® 5, penting untuk dicatat bahwa FRA GAMP® 5 secara khusus memfokuskan analisis pada dampak GxP dari kegagalan fungsional.1 FMEA murni mungkin memiliki cakupan yang lebih luas.25 FRA GAMP® 5 mengadopsi prinsip-prinsip FMEA tetapi menerapkannya melalui lensa GxP yang spesifik.
Untuk setiap mode kegagalan yang diidentifikasi, nilai tiga faktor risiko kunci 1:
Severity (S – Keparahan): Menilai dampak potensial dari kegagalan terhadap keselamatan pasien, kualitas produk, atau integritas data.1 Skala penilaian (misalnya, Tinggi, Sedang, Rendah atau skala numerik seperti 1-3, 1-5, 1-10) harus didefinisikan secara jelas sebelumnya, dengan deskripsi yang relevan dengan konteks GxP.3 (Lihat Tabel 3.1)
Probability (P – Probabilitas) / Kemungkinan Terjadi: Menilai kemungkinan atau frekuensi terjadinya mode kegagalan tersebut.1 Skala penilaian yang telah ditentukan juga digunakan di sini.3 (Lihat Tabel 3.1)
Detectability (D – Detektabilitas): Menilai kemungkinan kegagalan (atau efeknya) akan terdeteksi secara tepat waktu oleh sistem (misalnya, melalui alarm, pemeriksaan internal) atau prosedur (misalnya, tinjauan manual, pemantauan) sebelum menyebabkan dampak GxP yang signifikan.1 Skala penilaian yang telah ditentukan digunakan.3 (Lihat Tabel 3.1)
Definisi skala Severity, Probability, dan Detectability sangat penting dan harus spesifik konteks serta diterapkan secara konsisten. Menggunakan skala generik tanpa menyesuaikannya dengan sistem spesifik dan konteks GxP dapat menghasilkan skor risiko yang tidak berarti.3 Konsistensi aplikasi adalah kunci untuk perbandingan risiko yang valid.
Deskripsi Contoh (Sesuaikan dengan Konteks Spesifik)
Sumber Contoh Skala
Severity
Tinggi
Dampak parah pada keselamatan pasien (cedera/kematian) ATAU dampak signifikan pada kualitas produk (penarikan kembali) ATAU kehilangan data kritis GxP.
32
Sedang
Dampak potensial pada keselamatan pasien/kualitas produk ATAU masalah kepatuhan mayor ATAU korupsi data GxP yang dapat dipulihkan.
32
Rendah
Tidak ada dampak pada keselamatan pasien/kualitas produk ATAU masalah kepatuhan minor ATAU dampak minimal pada data GxP.
32
Probability
Tinggi
Kemungkinan terjadi sering (misalnya, > 2 kali/tahun atau dalam kondisi operasi tertentu).
32
Sedang
Kemungkinan terjadi jarang (misalnya, 1-2 kali/tahun atau hanya dalam kondisi tertentu).
32
Rendah
Tidak mungkin terjadi (misalnya, < 1 kali/tahun atau hanya dalam kondisi kegagalan ganda).
32
Detectability
Tinggi
Kemungkinan besar terdeteksi segera (misalnya, >95% deteksi, alarm otomatis, pemeriksaan sistem bawaan).
32
Sedang
Kemungkinan terdeteksi, mungkin sedikit tertunda (misalnya, >75% deteksi, tinjauan rutin, pemantauan berkala).
32
Rendah
Berpotensi terlewatkan atau terdeteksi dengan penundaan parah (misalnya, <75% deteksi, hanya terdeteksi melalui audit atau investigasi).
32
(Catatan: Skala di atas adalah contoh. Organisasi harus mendefinisikan skala mereka sendiri berdasarkan toleransi risiko dan konteks operasional mereka).
Langkah 4: Tentukan Prioritas Risiko
Gunakan metodologi yang telah ditentukan sebelumnya, seringkali proses dua langkah seperti yang disarankan dalam GAMP® 5 (meskipun detail Apendiks M3 tidak ada dalam cuplikan, prosesnya dijelaskan) 20:
Langkah 4a: Tentukan Kelas Risiko (Risk Class): Gabungkan skor/level Severity (S) dan Probability (P) menggunakan matriks yang telah ditentukan untuk mendapatkan Kelas Risiko (misalnya, Tinggi, Sedang, Rendah atau Kelas 1, 2, 3).26 Matriks ini secara visual mewakili tingkat risiko awal berdasarkan potensi bahaya inheren dan kemungkinannya terjadi. (Lihat Tabel 3.2)
Langkah 4b: Tentukan Prioritas Risiko Keseluruhan (Overall Risk Priority): Gabungkan Kelas Risiko dari Langkah 4a dengan skor/level Detectability (D) menggunakan matriks lain yang telah ditentukan untuk mendapatkan Prioritas Risiko akhir (misalnya, Tinggi, Sedang, Rendah atau Prioritas 1, 2, 3).26 Matriks akhir ini menggabungkan kemampuan untuk mendeteksi kegagalan, memberikan prioritas risiko keseluruhan yang lebih halus yang secara langsung memandu upaya mitigasi dan tingkat pengujian. Kegagalan berdampak tinggi dan kemungkinan besar terjadi yang mudah dideteksi mungkin memiliki prioritas lebih rendah daripada kegagalan yang sulit dideteksi. (Lihat Tabel 3.3)
Tabel 3.2: Contoh Matriks Kelas Risiko (Severity vs. Probability)
Probability: Rendah
Probability: Sedang
Probability: Tinggi
Severity: Tinggi
Sedang
Tinggi
Tinggi
Severity: Sedang
Rendah
Sedang
Tinggi
Severity: Rendah
Rendah
Rendah
Sedang
(Catatan: Ini adalah contoh matriks; kombinasi spesifik dapat bervariasi).
Tabel 3.3: Contoh Matriks Prioritas Risiko (Kelas Risiko vs. Detectability)
Detectability: Tinggi
Detectability: Sedang
Detectability: Rendah
Kelas Risiko: Tinggi
Sedang
Tinggi
Tinggi
Kelas Risiko: Sedang
Rendah
Sedang
Tinggi
Kelas Risiko: Rendah
Rendah
Rendah
Sedang
(Catatan: Ini adalah contoh matriks; prioritas akhir (misalnya, Tinggi, Sedang, Rendah) memandu tindakan selanjutnya).
Langkah 5: Identifikasi dan Usulkan Kontrol (Strategi Mitigasi)
Untuk risiko yang dinilai tidak dapat diterima (biasanya yang memiliki Prioritas Risiko Tinggi atau Sedang, tergantung pada kriteria penerimaan risiko organisasi), identifikasi tindakan pengendalian (kontrol) untuk mengurangi risiko tersebut ke tingkat yang dapat diterima.1
Jenis-jenis kontrol dapat meliputi 1:
Modifikasi Desain: Mengubah desain proses atau sistem untuk menghilangkan atau mengurangi bahaya (misalnya, menambahkan validasi input, menyederhanakan alur kerja).
Kontrol Teknis: Menerapkan fitur teknis dalam sistem (misalnya, aturan validasi data otomatis, peringatan/alarm, jejak audit yang ditingkatkan, kontrol akses yang lebih ketat).
Kontrol Prosedural: Menerapkan prosedur operasi standar (SOP), pemeriksaan manual, tinjauan data sekunder, atau pelatihan pengguna yang ditingkatkan.
Peningkatan Detektabilitas: Menambahkan mekanisme pemantauan, alarm tambahan, atau tinjauan data yang lebih sering.
Peningkatan Verifikasi/Pengujian: Meningkatkan cakupan, kedalaman, atau keketatan pengujian selama validasi untuk memberikan keyakinan yang lebih tinggi pada fungsi tersebut.1
Langkah 6: Tentukan Risiko Residual
Setelah kontrol diidentifikasi, nilai ulang risiko (Severity, Probability, Detectability) dengan asumsi bahwa kontrol tersebut diterapkan secara efektif. Ini disebut risiko residual (residual risk).
Tujuannya adalah untuk menunjukkan bahwa kontrol yang diusulkan berhasil mengurangi Prioritas Risiko ke tingkat yang dapat diterima (misalnya, Rendah atau mungkin Sedang dengan justifikasi yang kuat) sesuai dengan kriteria penerimaan risiko organisasi.23 Perlu diakui bahwa “risiko nol” tidak dapat dicapai 24; tujuannya adalah pengurangan risiko ke tingkat serendah mungkin yang dapat dicapai secara wajar (as low as reasonably practicable – ALARP) dan dapat diterima.
Langkah 7: Implementasikan & Verifikasi Kontrol
Kontrol yang diidentifikasi pada Langkah 5 harus diimplementasikan.
Efektivitas kontrol ini harus diverifikasi, biasanya melalui pengujian yang dilakukan selama fase validasi (IQ, OQ, PQ).1
Sangat penting untuk memastikan adanya ketertelusuran (traceability) yang jelas antara risiko yang diidentifikasi, kontrol yang diterapkan, dan bukti verifikasi (misalnya, ID kasus uji).1
Langkah 8: Tinjau Risiko & Pantau Kontrol (Siklus Hidup)
FRA bukanlah aktivitas satu kali. Penilaian risiko harus ditinjau secara berkala (misalnya, selama tinjauan sistem periodik) dan sebagai bagian integral dari proses manajemen perubahan (change management).1
Tinjauan ini memastikan bahwa penilaian risiko tetap relevan, kontrol masih efektif, dan tidak ada risiko baru yang muncul akibat perubahan sistem atau lingkungan operasi.
4. Mendokumentasikan FRA: Struktur dan Elemen Kunci
Dokumentasi FRA yang jelas, komprehensif, dan terstruktur adalah elemen penting dari proses validasi berbasis risiko.
Tujuan Dokumentasi FRA
Dokumen FRA berfungsi sebagai bukti formal dan terdokumentasi dari proses penilaian risiko yang telah dilakukan.3 Tujuannya adalah untuk:
Mencatat identifikasi risiko fungsional dan analisisnya.
Memberikan justifikasi untuk kontrol yang diimplementasikan.
Menjadi masukan utama untuk perencanaan validasi dan strategi pengujian.
Mendemonstrasikan penerapan pendekatan berbasis risiko kepada auditor dan regulator.5
Mendukung manajemen siklus hidup sistem, termasuk manajemen perubahan dan tinjauan periodik.
Lebih dari sekadar artefak kepatuhan, dokumen FRA adalah alat komunikasi penting. Dokumen ini mengartikulasikan alasan di balik pilihan desain, strategi pengendalian, dan upaya validasi kepada seluruh tim proyek, QA, dan manajemen.23 Dengan menyajikan logika penilaian risiko dan kontrol yang diusulkan secara transparan, dokumen FRA memfasilitasi pemahaman bersama dan kesepakatan di antara berbagai pemangku kepentingan.
Elemen Kunci Dokumen FRA
Meskipun formatnya dapat bervariasi, dokumen FRA yang komprehensif biasanya mencakup elemen-elemen berikut:
Kontrol Dokumen: Informasi standar seperti judul dokumen, nomor identifikasi unik, versi, tanggal efektif, penulis, peninjau, dan pemberi persetujuan.
Identifikasi Sistem: Deskripsi yang jelas tentang sistem terkomputerisasi yang dinilai, termasuk nama, versi, cakupan (fungsi apa saja yang termasuk), batasan, dan tujuan penggunaan (intended use).23 Harus ada referensi silang ke dokumen URS, FS, dan/atau DS yang relevan.
Metodologi: Penjelasan rinci tentang proses penilaian risiko yang digunakan (misalnya, berbasis FMEA), termasuk definisi skala yang digunakan untuk Severity, Probability, dan Detectability, serta matriks yang digunakan untuk menentukan Kelas Risiko dan Prioritas Risiko.3
Anggota Tim: Daftar peserta yang terlibat dalam FRA, beserta peran dan bidang keahlian mereka.23 Ini menunjukkan bahwa keahlian yang relevan telah dilibatkan.
Tabel/Log Penilaian Risiko: Ini adalah inti dari dokumen FRA, biasanya disajikan dalam format tabel (lihat Tabel 4.1). Kolom-kolom penting meliputi:
ID/Deskripsi Fungsi: Identifikasi unik fungsi yang dinilai, dapat ditautkan ke URS/FS.
Mode Kegagalan/Bahaya Potensial: Deskripsi cara fungsi dapat gagal.
Efek/Dampak GxP Potensial: Penjelasan konsekuensi kegagalan terhadap Keselamatan Pasien, Kualitas Produk, dan Integritas Data.
Penilaian Risiko Awal: Skor/peringkat untuk Severity (S), Probability (P), dan Detectability (D).
Perhitungan Risiko Awal: Kelas Risiko dan/atau Prioritas Risiko yang dihasilkan.
Kontrol/Tindakan Mitigasi yang Diusulkan: Deskripsi kontrol teknis, prosedural, atau pengujian yang diidentifikasi untuk mengurangi risiko.
Penilaian Risiko Residual: Penilaian ulang S, P, dan D setelah mempertimbangkan efektivitas kontrol yang diusulkan.
Perhitungan Risiko Residual: Kelas Risiko dan/atau Prioritas Risiko setelah mitigasi.
Ketertelusuran Verifikasi/ID Kasus Uji: Tautan ke protokol atau kasus uji spesifik dalam rencana validasi yang akan memverifikasi efektivitas kontrol atau menguji fungsi berisiko tinggi.1
Tanggung Jawab/Status: (Opsional) Penanggung jawab dan status implementasi tindakan mitigasi.
Kriteria Penerimaan Risiko: Definisi formal tentang tingkat risiko residual yang dianggap dapat diterima oleh organisasi (misalnya, hanya Prioritas Risiko Rendah yang diterima, atau Sedang dapat diterima dengan justifikasi tambahan).
Ringkasan dan Kesimpulan: Tinjauan singkat tentang area berisiko tinggi yang teridentifikasi, kontrol kunci yang diterapkan, dan pernyataan konfirmasi bahwa semua risiko residual berada pada tingkat yang dapat diterima.3 Pernyataan tentang bagaimana hasil FRA menginformasikan strategi pengujian validasi.
Referensi: Daftar dokumen lain yang dirujuk, seperti URS, FS, DS, Rencana Validasi, SOP terkait, dll.
Apendiks: (Opsional) Dapat berisi definisi skala rinci, matriks risiko, atau informasi pendukung lainnya.
Tabel 4.1: Contoh Struktur Tabel FRA
ID Fungsi (Ref URS/FS)
Mode Kegagalan / Bahaya
Efek / Dampak GxP
S (Awal)
P (Awal)
D (Awal)
Prioritas Risiko (Awal)
Kontrol / Mitigasi yang Diusulkan
S (Residual)
P (Residual)
D (Residual)
Prioritas Risiko (Residual)
ID Kasus Uji Verifikasi
FUNC-001
…
…
Tinggi
Sedang
Rendah
Tinggi
Kontrol Teknis X, SOP-123, Uji OQ-05
Tinggi
Rendah
Sedang
Sedang
OQ-05, PQ-12
FUNC-002
…
…
Sedang
Rendah
Tinggi
Rendah
Tidak diperlukan (Risiko Awal Rendah)
Sedang
Rendah
Tinggi
Rendah
OQ-06 (Fungsional Dasar)
…
…
…
…
…
…
…
…
…
…
…
…
…
(Catatan: Struktur tabel ini memberikan kerangka kerja yang jelas dan komprehensif untuk mendokumentasikan seluruh proses FRA per fungsi, memfasilitasi tinjauan, persetujuan, dan ketertelusuran).
Pentingnya Ketertelusuran (Traceability)
Ketertelusuran adalah aspek fundamental dari dokumentasi FRA dan validasi GAMP® 5 secara keseluruhan.42 Harus ada hubungan dua arah yang jelas antara:
Kebutuhan Pengguna (URS) -> Fungsi Sistem (FS) -> Risiko Fungsional (FRA) -> Kontrol Mitigasi (FRA/DS) -> Kasus Uji Verifikasi (Protokol IQ/OQ/PQ).
Ketertelusuran ini seringkali dikelola dalam Matriks Ketertelusuran (Traceability Matrix) terpisah atau diintegrasikan dalam dokumen FRA itu sendiri. Memelihara ketertelusuran yang kuat tidak hanya penting untuk menunjukkan kepatuhan selama audit, tetapi juga sangat berharga untuk analisis dampak yang efisien selama manajemen perubahan dan tinjauan periodik. Ketika suatu fungsi atau persyaratan diubah, matriks ketertelusuran memungkinkan tim untuk dengan cepat mengidentifikasi risiko, kontrol, dan pengujian terkait yang mungkin terpengaruh, sehingga menyederhanakan proses penilaian dampak perubahan.1
Memanfaatkan Alat Bantu (Tools)
Untuk sistem yang kompleks dengan banyak fungsi dan risiko, mengelola proses FRA dan dokumentasinya secara manual bisa menjadi tantangan. Penggunaan alat bantu seperti spreadsheet yang terstruktur dengan baik, atau perangkat lunak manajemen risiko/validasi khusus (seperti yang disebutkan dalam 50) dapat sangat membantu. Alat-alat ini dapat memfasilitasi pencatatan data, perhitungan risiko otomatis, pembuatan matriks, pelacakan tindakan mitigasi, dan pemeliharaan ketertelusuran.
5. FRA dalam Praktik: Contoh untuk Sistem Terkomputerisasi GMP
Penerapan prinsip FRA perlu disesuaikan dengan jenis sistem terkomputerisasi spesifik dan perannya dalam lingkungan GMP yang diatur. Bagian ini akan memberikan contoh bagaimana FRA dapat diterapkan pada tiga jenis sistem yang umum ditemukan: Laboratory Information Management System (LIMS), Enterprise Resource Planning (ERP), dan Process Control System (PCS).
Pertimbangan GMP Umum dalam FRA
Terlepas dari jenis sistemnya, ada beberapa fungsi atau aspek umum yang seringkali menjadi fokus dalam FRA karena relevansinya yang tinggi dengan GxP:
Integritas Data (Data Integrity – DI): Fungsi yang berkaitan dengan pembuatan, modifikasi, pemrosesan, penyimpanan, pengambilan, transfer, pencadangan/pemulihan (backup/restore), dan pengarsipan data GxP.1 Penilaian risiko harus mempertimbangkan potensi data menjadi tidak akurat, tidak lengkap, tidak dapat diatribusikan, tidak kontemporer, tidak asli, tidak konsisten, tidak tahan lama, atau tidak tersedia (prinsip ALCOA+ 5). Risiko modifikasi atau penghapusan data yang tidak sah atau tidak terdeteksi adalah perhatian utama.
Jejak Audit (Audit Trails – AT): Fungsi untuk mencatat secara otomatis peristiwa-peristiwa penting yang relevan dengan GxP, seperti pembuatan, modifikasi, atau penghapusan data/catatan GxP, login/logout pengguna, perubahan pada pengaturan kritis, upaya akses yang gagal, dll..5 FRA harus menilai risiko terkait jejak audit yang tidak lengkap, tidak akurat, tidak dapat diakses, mudah dinonaktifkan, dimodifikasi, atau ditimpa. Kebutuhan dan frekuensi tinjauan jejak audit (audit trail review) juga merupakan pertimbangan risiko.17
Tanda Tangan Elektronik (Electronic Signatures – ES): Fungsi untuk menerapkan dan memverifikasi tanda tangan elektronik sesuai dengan persyaratan peraturan yang berlaku (misalnya, FDA 21 CFR Part 11 di AS, EU GMP Annex 11 di Eropa).5 FRA harus menilai risiko terkait pemalsuan tanda tangan, penolakan (repudiation), penerapan yang salah, kegagalan untuk menautkan tanda tangan secara unik ke catatan elektronik tertentu, atau penggunaan kredensial yang tidak sah.
Kontrol Akses/Keamanan: Fungsi yang berkaitan dengan otentikasi pengguna (misalnya, ID pengguna dan kata sandi), otorisasi (penetapan hak akses berbasis peran), manajemen kata sandi (kompleksitas, kedaluwarsa), dan batas waktu sesi (session timeouts).15 FRA harus menilai risiko akses tidak sah, modifikasi data oleh pengguna yang tidak berwenang, atau manipulasi sistem yang dapat membahayakan GxP.
Kekritisan (dan skor risiko yang dihasilkan) dari fungsi-fungsi umum ini, seperti jejak audit atau tanda tangan elektronik, secara langsung proporsional dengan kekritisan data atau tindakan yang dilindunginya. Misalnya, jejak audit untuk perubahan pada header laporan mungkin memiliki risiko lebih rendah dibandingkan jejak audit untuk perubahan pada status rilis bets produk.27 Demikian pula, tanda tangan elektronik untuk menyetujui SOP mungkin memiliki profil risiko yang berbeda dari tanda tangan elektronik untuk meloloskan bets akhir. FRA harus mencerminkan konteks penggunaan spesifik ini dalam penilaian Severity.
Untuk sistem yang kompleks dan terintegrasi, seperti ERP yang berinteraksi dengan LIMS dan PCS 5, FRA juga harus secara eksplisit mempertimbangkan risiko yang terkait dengan fungsi antarmuka (interface) dan transfer data. Kegagalan pada antarmuka dapat menyebabkan korupsi data, data yang hilang, atau tindakan yang salah di sistem hilir, yang semuanya dapat memiliki konsekuensi GxP yang signifikan. Oleh karena itu, fungsi antarmuka itu sendiri harus menjadi subjek FRA jika mereka menangani data atau perintah yang relevan dengan GxP.
Contoh Sistem 1: Laboratory Information Management System (LIMS)
LIMS adalah sistem penting di laboratorium QC (Quality Control) dan R&D (Research and Development) untuk mengelola alur kerja pengujian, data, dan pelaporan.15
Fungsi Kritis GxP Umum: Login dan pelacakan sampel 55, penjadwalan pengujian, antarmuka instrumen analitik, pengambilan data mentah, perhitungan otomatis 56, entri dan persetujuan hasil, pemeriksaan terhadap spesifikasi, pembuatan Sertifikat Analisis (CoA), manajemen studi stabilitas, pelacakan standar referensi dan reagen, manajemen kompetensi dan pelatihan pengguna 55, jejak audit komprehensif 56, dan tanda tangan elektronik untuk tinjauan/persetujuan.15
Contoh FRA (Jejak Audit untuk Perubahan Hasil):
Fungsi: Mencatat semua perubahan yang dilakukan pada hasil pengujian yang dimasukkan.
Mode Kegagalan: Sistem gagal menghasilkan entri jejak audit ketika pengguna yang berwenang mengubah hasil tes yang sudah dimasukkan.
Efek/Dampak GxP: Kehilangan ketertelusuran data (tidak dapat mengetahui siapa yang mengubah, kapan, dan apa nilai sebelumnya), potensi manipulasi data yang tidak terdeteksi, ketidakmampuan untuk merekonstruksi peristiwa selama investigasi OOS (Out of Specification). Dampak Tinggi pada Integritas Data.
Penilaian Risiko Awal (Contoh): S=Tinggi, P=Rendah (jika sistem dirancang dengan baik), D=Sedang (mungkin terdeteksi saat tinjauan data/audit trail review). Menghasilkan Prioritas Risiko Sedang/Tinggi.
Kontrol/Mitigasi yang Diusulkan: (Teknis) Memastikan fungsi jejak audit diaktifkan dan dikonfigurasi dengan benar untuk menangkap semua data relevan (nilai lama, nilai baru, pengguna, tanggal/waktu, alasan perubahan jika memungkinkan). (Prosedural) SOP untuk tinjauan data dan jejak audit secara berkala. (Pengujian) Kasus uji spesifik dalam OQ dan PQ untuk secara eksplisit memverifikasi bahwa jejak audit dihasilkan dengan benar untuk berbagai skenario perubahan hasil (termasuk pengujian negatif).
Contoh Sistem 2: Manufacturing Enterprise Resource Planning (ERP)
Sistem ERP di lingkungan manufaktur GMP sering mengelola data dan proses kritis terkait produksi, inventaris, dan kualitas.30
Fungsi Kritis GxP Umum: Manajemen material (penerimaan, karantina, pengujian, rilis, inventaris, status kontrol, penimbangan dan penyerahan), manajemen Bill of Materials (BOM), manajemen Master Batch Record (MBR) / Electronic Batch Record (EBR) 34, manajemen perintah produksi, penjadwalan sumber daya, pelacakan status kualitas bets (misalnya, rilis, ditolak), manajemen penyimpangan, jejak audit 38, tanda tangan elektronik untuk persetujuan (jika digunakan), dan antarmuka dengan sistem lain seperti LIMS atau PCS.5
Contoh FRA (Tanda Tangan Elektronik untuk Rilis Bets):
Fungsi: Menerapkan tanda tangan elektronik oleh personel QA yang berwenang untuk menyetujui rilis final suatu bets produk di sistem ERP.
Mode Kegagalan: (a) Sistem memungkinkan pengguna yang tidak berwenang untuk menerapkan tanda tangan rilis. (b) Tanda tangan diterapkan tetapi tidak tertaut secara aman dan permanen ke catatan rilis bets spesifik. (c) Sistem tidak memberlakukan urutan penandatanganan yang benar (jika diperlukan).
Efek/Dampak GxP: (a) Rilis bets yang tidak sah. (b) Ketidakmampuan untuk membuktikan siapa yang merilis bets dan kapan, potensi penolakan. (c) Rilis bets tanpa semua tinjauan/persetujuan yang diperlukan. Semua skenario dapat menyebabkan rilis produk yang tidak sesuai atau berpotensi tidak aman. Dampak Tinggi pada Kualitas Produk dan Keselamatan Pasien.
Penilaian Risiko Awal (Contoh): S=Tinggi, P=Rendah (jika kontrol akses baik), D=Rendah (jika tautan rusak atau otorisasi salah, mungkin tidak mudah terdeteksi). Menghasilkan Prioritas Risiko Tinggi.
Kontrol/Mitigasi yang Diusulkan: (Teknis) Implementasi fitur tanda tangan elektronik yang sepenuhnya sesuai dengan 21 CFR Part 11 / Annex 11 (ID pengguna unik + kata sandi, tautan ke catatan, timestamp aman, tidak dapat digunakan kembali). Konfigurasi peran pengguna dan hak akses yang ketat. (Prosedural) SOP untuk manajemen akun pengguna (pembuatan, penonaktifan, tinjauan berkala). Pelatihan pengguna tentang prosedur tanda tangan elektronik. (Pengujian) Pengujian OQ/PQ yang ketat untuk memverifikasi semua aspek fungsi tanda tangan elektronik, termasuk skenario negatif (misalnya, mencoba menandatangani dengan kredensial yang salah, mencoba menandatangani di luar urutan).
Contoh Sistem 3: Process Control System (PCS) / SCADA / DCS / BMS / EMS
Sistem ini mengontrol dan memantau parameter proses kritis (Critical Process Parameters – CPPs) dalam manufaktur atau kondisi lingkungan kritis.3
Fungsi Kritis GxP Umum: Pemantauan CPPs (misalnya, suhu, tekanan, waktu, kelembaban, kecepatan putar) 27, pengendalian CPPs dalam batas yang divalidasi, manajemen alarm (konfigurasi, pencatatan, pengakuan), akuisisi data dan penyimpanan data historis (data historian) 11, manajemen resep/formula, pelaporan bets, jejak audit untuk perubahan setpoint atau konfigurasi alarm, kontrol akses pengguna ke fungsi kritis.
Contoh FRA (Integritas Data – Pemantauan CPP Suhu):
Fungsi: Merekam data suhu secara terus-menerus dari sensor kritis selama siklus sterilisasi uap dalam autoklaf.
Mode Kegagalan: (a) Data suhu tidak direkam sama sekali selama sebagian atau seluruh siklus. (b) Data suhu direkam tetapi tidak akurat (misalnya, karena masalah sensor atau konversi A/D). (c) Ada celah (gap) dalam data yang direkam.
Efek/Dampak GxP: Ketidakmampuan untuk memverifikasi bahwa CPP kritis (suhu sterilisasi) tercapai dan dipertahankan selama waktu yang diperlukan. Potensi pelepasan produk yang tidak steril. Dampak Tinggi pada Kualitas Produk dan Keselamatan Pasien.
Penilaian Risiko Awal (Contoh): S=Tinggi, P=Sedang (tergantung keandalan sensor/sistem), D=Sedang (mungkin terdeteksi saat tinjauan data bets atau melalui alarm sistem). Menghasilkan Prioritas Risiko Tinggi.
Kontrol/Mitigasi yang Diusulkan: (Desain) Pertimbangkan penggunaan sensor redundan. Implementasikan buffering data di tingkat PLC/kontroler untuk mencegah kehilangan data saat komunikasi jaringan terputus sementara. (Teknis) Alarm untuk kegagalan akuisisi data atau nilai di luar rentang. Pencadangan data historis secara teratur dan aman. (Prosedural) SOP untuk tinjauan data bets kritis, termasuk data proses. Prosedur kalibrasi sensor secara berkala. (Pengujian) Pengujian OQ/PQ yang ketat untuk memverifikasi akurasi perekaman data, fungsi alarm, penanganan kegagalan komunikasi, dan pemulihan data.
Tabel 5.1: Contoh Entri FRA untuk Fungsi GMP
Sistem
Fungsi (Contoh)
Mode Kegagalan
Efek / Dampak GxP
S
P
D
Prioritas (Awal)
Kontrol / Mitigasi (Contoh)
Prioritas (Residual)
LIMS
Jejak Audit: Perubahan Hasil Tes
Gagal mencatat perubahan hasil
Kehilangan ketertelusuran, potensi manipulasi data tidak terdeteksi (DI Tinggi)
T
R
S
Tinggi
Aktifkan & konfigurasikan AT dengan benar; SOP tinjauan AT berkala; Uji OQ/PQ spesifik verifikasi AT.
Sedang
ERP
Tanda Tangan Elektronik: Rilis Bets
Pengguna tidak sah dapat menandatangani rilis
Rilis bets tidak sah, potensi rilis produk tidak sesuai (KP/KS Tinggi)
T
R
R
Tinggi
Implementasi ES sesuai 21CFR11/Annex11; Kontrol akses ketat; SOP manajemen pengguna; Uji OQ/PQ ketat fungsi ES.
Rendah
PCS
Integritas Data: Perekaman Suhu Sterilisasi
Data suhu tidak akurat atau hilang
Gagal verifikasi CPP, potensi produk tidak steril (KP/KS Tinggi)
T
S
S
Tinggi
Sensor redundan (opsional); Buffering data; Alarm kegagalan akuisisi; Backup data teratur; SOP tinjauan data bets; Kalibrasi sensor; Uji OQ/PQ ketat akuisisi data & alarm.
6. Dari Penilaian Risiko ke Validasi: Menginformasikan Strategi Pengujian
Salah satu hasil paling signifikan dari FRA adalah dampaknya secara langsung pada strategi validasi dan pengujian sistem terkomputerisasi.1 FRA menyediakan dasar rasional untuk menentukan cakupan, kedalaman, dan fokus upaya pengujian, memastikan bahwa sumber daya dialokasikan secara efektif untuk mengatasi risiko GxP yang paling signifikan.
Pengujian Berbasis Risiko (Risk-Based Testing)
FRA memungkinkan penerapan pendekatan pengujian berbasis risiko dengan cara berikut:
Memfokuskan Upaya: Upaya pengujian (termasuk pengembangan kasus uji, eksekusi, dan dokumentasi) terkonsentrasi pada fungsi-fungsi yang diidentifikasi memiliki Prioritas Risiko Tinggi atau Sedang dalam FRA.1 Fungsi dengan risiko rendah mungkin memerlukan pengujian yang kurang ketat, berpotensi memanfaatkan dokumentasi vendor (setelah penilaian vendor yang memadai) atau pemeriksaan fungsional dasar.28 Ini sejalan dengan prinsip GAMP® 5 tentang aktivitas siklus hidup yang dapat diskalakan (scalable activities).2
Menentukan Keketatan Pengujian (Test Rigor): Tingkat risiko yang diidentifikasi dalam FRA secara langsung memengaruhi jenis dan kedalaman pengujian yang dilakukan.1 Fungsi berisiko tinggi memerlukan pengujian yang lebih menantang dan komprehensif, seperti:
Pengujian fungsional positif (memastikan fungsi bekerja seperti yang diharapkan).
Pengujian fungsional negatif (memastikan sistem menangani input atau kondisi yang tidak valid dengan benar).
Pengujian batas/limit (boundary/limit testing) untuk mengeksplorasi tepi rentang operasi.
Pengujian skenario kegagalan yang diidentifikasi dalam FRA.
Pengujian volume atau stres (jika relevan dengan risiko kinerja). Dokumentasi untuk pengujian fungsi berisiko tinggi juga cenderung lebih rinci.31
Menguji Kontrol: Aktivitas verifikasi dalam protokol Kualifikasi Instalasi (IQ), Kualifikasi Operasional (OQ), dan Kualifikasi Kinerja (PQ) harus secara eksplisit dirancang untuk menguji efektivitas kontrol (baik teknis maupun prosedural) yang diidentifikasi dalam FRA untuk memitigasi risiko spesifik.1 Ketertelusuran dari risiko/kontrol ke kasus uji sangat penting untuk menunjukkan bahwa mitigasi telah diverifikasi.1
Memberikan Justifikasi Strategi Pengujian: Dokumen FRA menyediakan justifikasi yang terdokumentasi dan berbasis risiko untuk keseluruhan strategi validasi.17 Ini menjelaskan mengapa pengujian tertentu disertakan (untuk memverifikasi fungsi berisiko tinggi atau kontrol mitigasi) dan mengapa pengujian lain mungkin dikurangi atau dihilangkan (karena risiko rendah yang teridentifikasi). Pendekatan berbasis bukti ini mengubah validasi dari proses yang berpotensi subjektif menjadi aktivitas yang lebih objektif dan dapat dipertahankan selama inspeksi. Daripada hanya menyatakan “kami menguji ini karena ada di URS,” justifikasinya menjadi “kami menguji ini dengan tingkat keketatan ini karena FRA mengidentifikasinya sebagai risiko tinggi.”
Dampak pada Fase Kualifikasi (IQ/OQ/PQ)
Hasil FRA memengaruhi berbagai fase kualifikasi:
IQ (Installation Qualification): Umumnya kurang terpengaruh secara langsung oleh FRA, karena fokus utamanya adalah verifikasi instalasi fisik dan konfigurasi dasar. Namun, verifikasi instalasi komponen perangkat keras atau lunak spesifik yang merupakan bagian dari kontrol teknis yang diidentifikasi dalam FRA mungkin perlu ditelusuri kembali ke FRA.
OQ (Operational Qualification): Sangat dipengaruhi oleh FRA.3 Pengujian fungsional selama OQ difokuskan pada verifikasi bahwa fungsi-fungsi kritis GxP (yang diidentifikasi dan dinilai risikonya dalam FRA) beroperasi dengan benar sesuai dengan spesifikasi fungsional. Pengujian juga harus memverifikasi bahwa kontrol teknis yang diidentifikasi dalam FRA (misalnya, alarm, aturan validasi, fungsi jejak audit) efektif. Keketatan pengujian OQ untuk setiap fungsi diskalakan berdasarkan Prioritas Risiko yang ditentukan dalam FRA.
PQ (Performance Qualification): Juga dipengaruhi oleh FRA.3 Pengujian PQ bertujuan untuk menunjukkan bahwa sistem memenuhi kebutuhan pengguna (URS) secara konsisten dalam lingkungan operasi normal, seringkali menggunakan data atau proses aktual. Fokus pengujian PQ adalah pada persyaratan pengguna yang terkait dengan fungsi atau proses bisnis berisiko tinggi yang diidentifikasi melalui FRA. Verifikasi efektivitas kontrol prosedural (misalnya, SOP, pemeriksaan manual) yang diidentifikasi dalam FRA seringkali dilakukan selama PQ.
Memanfaatkan Pengujian Pemasok
FRA juga dapat membantu dalam menentukan sejauh mana pengujian dan dokumentasi yang dilakukan oleh pemasok (supplier) dapat dimanfaatkan.1 Untuk fungsi standar dengan risiko rendah yang teridentifikasi dalam FRA, dimungkinkan untuk lebih mengandalkan bukti pengujian pemasok (dengan asumsi pemasok telah diaudit dan dinilai memadai 3). Namun, perusahaan yang diatur tetap bertanggung jawab penuh untuk memastikan kesesuaian sistem secara keseluruhan untuk tujuan penggunaan dalam konteks GxP mereka. FRA membantu membuat keputusan berbasis risiko tentang di mana pengujian internal tambahan diperlukan dan di mana pengujian pemasok dapat dimanfaatkan secara efektif untuk menghindari duplikasi upaya yang tidak perlu.7
Penerapan proses FRA yang kuat dapat menghasilkan efisiensi yang signifikan dalam upaya validasi. Dengan mencegah “pengujian berlebihan” (over-testing) pada fungsi berisiko rendah dan memfokuskan sumber daya pada area berisiko tinggi, organisasi dapat mencapai kepatuhan GxP dengan cara yang lebih hemat biaya tanpa mengorbankan kualitas atau keamanan.7 FRA menyediakan mekanisme berbasis data untuk membuat keputusan cerdas tentang alokasi sumber daya validasi.
7. Kesimpulan: Mengintegrasikan FRA untuk Kepatuhan GxP dan Kesesuaian Sistem
Penilaian Risiko Fungsional (FRA) memainkan peran sentral dan tak terpisahkan dalam pendekatan berbasis risiko GAMP® 5 untuk validasi sistem terkomputerisasi di lingkungan GMP.1 Ini adalah mekanisme kunci untuk memastikan bahwa sistem tidak hanya memenuhi persyaratan fungsional tetapi juga “sesuai untuk tujuan penggunaan” (fit for intended use) dalam konteks spesifik GxP, dengan fokus utama pada perlindungan keselamatan pasien, kualitas produk, dan integritas data.1
FRA secara efektif mewujudkan prinsip-prinsip inti GAMP® 5:
Pendekatan Berbasis Risiko: FRA adalah penerapan praktis dari penilaian risiko pada tingkat detail fungsional, mengidentifikasi di mana risiko GxP sebenarnya berada.
Manajemen Siklus Hidup: Meskipun dilakukan terutama selama fase proyek, output FRA (risiko teridentifikasi, kontrol, justifikasi pengujian) menginformasikan operasi berkelanjutan, manajemen perubahan, dan tinjauan periodik sistem.
Skalabilitas: Hasil FRA memungkinkan penskalaan upaya validasi dan pengujian yang proporsional, memfokuskan sumber daya pada area berisiko tinggi dan berpotensi mengurangi upaya pada area berisiko rendah.
Pemahaman Produk dan Proses: Pelaksanaan FRA yang efektif sangat bergantung pada pemahaman mendalam tentang produk, proses, dan persyaratan GxP terkait.
Pemikiran Kritis: FRA menuntut penilaian dan keahlian dari tim lintas fungsi, bukan sekadar pengisian formulir secara mekanis.
Manfaat menerapkan FRA secara efektif sangat signifikan. Ini mengarah pada validasi yang lebih terfokus dan efisien, penggunaan sumber daya yang lebih baik, peningkatan kualitas dan keandalan sistem, postur kepatuhan yang lebih kuat, dan kontrol risiko GxP yang lebih baik secara keseluruhan.7
Namun, keberhasilan implementasi FRA membutuhkan lebih dari sekadar prosedur terdokumentasi. Hal ini memerlukan pergeseran budaya dalam organisasi menuju manajemen risiko yang proaktif dan pemberdayaan SMEs untuk menerapkan pemikiran kritis dalam siklus hidup validasi.2 Organisasi perlu menumbuhkan lingkungan di mana evaluasi risiko yang bijaksana dihargai, dan para ahli merasa diberdayakan untuk membuat keputusan berbasis risiko yang dapat dipertanggungjawabkan, bergerak melampaui pendekatan yang murni didorong oleh kepatuhan atau ketakutan akan temuan audit.17
Pada akhirnya, ukuran keberhasilan implementasi FRA bukanlah dokumen itu sendiri, tetapi apakah FRA secara nyata menghasilkan produk yang lebih aman, kualitas yang lebih tinggi, integritas data yang lebih baik, dan upaya validasi yang lebih efisien yang dapat dipertahankan selama inspeksi peraturan.7 FRA, bila diterapkan dengan benar, adalah landasan dari validasi sistem terkomputerisasi modern yang efisien, efektif, dan berfokus pada risiko dalam industri farmasi dan life sciences. Ini adalah proses berkelanjutan yang integral untuk mempertahankan status tervalidasi dan memastikan kepatuhan GxP yang berkelanjutan sepanjang siklus hidup sistem terkomputerisasi.
No comments yet.