۱. مقدمه: تعریف احراز صلاحیت (احراز کیفیت) طراحی در چرخه حیات نوین
احراز صلاحیت (احراز کیفیت) طراحی (DQ) فرآیندی مستند است که تأیید میکند طراحی پیشنهادی برای تأسیسات، سیستمها، تجهیزات جانبی و ماشینآلات برای هدف مورد نظر مناسب است. در بستر یک چارچوب نوین راهاندازی و احراز صلاحیت (احراز کیفیت) (C&Q)، "مناسب بودن" دلالت بر این دارد که الزامات تعریف شدهاند، طراحی برای کنترل فرآیند مناسب است، و سیستم به گونهای ساخته و نصب شده است که در سراسر محدودههای عملیاتی خود مطابق با هدف عمل کند.
به عنوان یک ممیز فنی ارشد (Lead Technical Auditor)، اغلب میبینم که تیمها با گذار از آزمایشهای سنتی و تکراری به رویکرد مبتنی بر علم و ریسک که توسط راهنمای پایه ISPE نسخه ۵ حمایت میشود، دست و پنجه نرم میکنند. رویکرد C&Q نوین، DQ را به عنوان یک نقطه عطف رسمی در چرخه حیات پروژه ادغام میکند. برخلاف رویکرد قدیمی که اغلب با DQ به عنوان یک تمرین کاغذبازی گذشتهنگر برخورد میکرد، رویکرد نوین از DQ برای تأیید این موضوع استفاده میکند که "وضعیت احراز صلاحیت (احراز کیفیت) شده" پیش از آغاز ساخت و ساز به درستی برنامهریزی شده است.
مزایای سطح بالای اجرای زودهنگام DQ:
- شناسایی شکافهای طراحی: شناسایی زودهنگام مغایرتهای میان طراحی و مشخصات الزامات کاربر (URS) از "حلقه دوبارهکاری" که باعث تأخیرهای عظیم در زمانبندیِ فاز آزمایش میشود، جلوگیری میکند.
- کنترل استراتژیک ریسک: این امر تضمین میکند که عناصر طراحی بحرانی (CDEs) — ویژگیهای فیزیکی یا عملکردی که به عنوان کنترلکننده ریسک استفاده میشوند — برای محافظت از کیفیت محصول در طراحی گنجانده شدهاند.
- کارایی چرخه حیات: با همراستا کردن ذینفعان در مورد الزامات کیفی در طول فاز طراحی، DQ از اجرای "بار اول درست" (right-the-first-time) پشتیبانی کرده و نیاز به اصلاحات میدانی پرهزینه را کاهش میدهد.
۲. اهداف استراتژیک DQ
هدف اصلی DQ ارائه تأییدیه مستند مبنی بر این است که یک سیستم جدید یا اصلاحشده همانطور که در نظر گرفته شده عمل خواهد کرد. این فاز به عنوان پل بحرانی میان ارزیابی ریسک و تأیید فیزیکی عمل میکند. این صرفاً یک بررسی در برابر URS نیست، بلکه تأییدی است بر اینکه هر کنترل ریسک شناساییشده در ارزیابی ریسک سیستم (SRA)، به یک ویژگی طراحی قابل تأیید تبدیل شده است.
| دستهبندی هدف | هدف تأیید |
|---|---|
| الزامات کیفی کاربر | تأیید اینکه طراحی تمام الزامات محصول و فرآیند مستندشده در URS را برآورده میکند. |
| کنترلهای ریسک | تأیید اینکه طراحی به طور کافی ریسکهای مؤثر بر کیفیت محصول و ایمنی بیمار را که در طول ارزیابی ریسک سیستم (SRA) شناسایی شدهاند، کنترل میکند. |
| عناصر طراحی بحرانی (CDEs) | تأیید اینکه ویژگیهای فیزیکی یا عملکردی خاص (CDEs) که برای اجرای کنترلهای ریسک ضروری هستند، وجود داشته و قابل تأیید میباشند. |
۳. پیشنیازهای DQ: فراهم کردن بستر موفقیت
پیش از آنکه DQ بتواند به طور رسمی آغاز شود، مدیر پروژه مسئول است اطمینان حاصل کند که طراحی به سطح کیفی و بلوغی رسیده است که در آن، تأیید معنادار باشد. چهار پیشنیاز زیر الزامی هستند:
- مشخصات الزامات کاربر (URS) تأییدشده: سند پایهای که الزامات محصول، فرآیند و نظارتی را مشخص میکند.
- الزامات عملکردی (Functional Requirements): برای سیستمهای اتوماتیک به منظور تعریف نحوه تعامل نرمافزار و سختافزار مورد نیاز است. (توجه: این موارد معمولاً برای سیستمهای کاملاً مکانیکی الزامی نیستند).
- ارزیابیهای ریسک سیستم (SRA): اعمال مدیریت ریسک کیفیت (QRM) برای شناسایی جنبههای بحرانی (CAs) و عناصر طراحی بحرانی (CDEs).
- بررسیهای طراحی تکمیلشده (DR): تأیید اینکه تمامی مسائل بازِ طراحی که بر CAs، CDEs، CPPs و CQAs تأثیر میگذارند، بسته شده و در طراحی نهایی گنجانده شدهاند.
۴. ارتباط میان بررسی طراحی (DR) و احراز صلاحیت (احراز کیفیت) طراحی (DQ)
در تجربه من به عنوان یک ممیز، شایعترین نقطه شکست، حذف واحد کیفیت (QU) از فرآیند بررسی طراحی است. اگرچه DR و DQ به یکدیگر مرتبط هستند، اما عملکردهای متمایزی دارند. DR یک فرآیند تکرارپذیر و مستمر است که در سراسر چرخه حیات برای ارزیابی خروجیها در برابر استانداردهای مهندسی و نیازهای کسبوکار انجام میشود. DQ نقطه عطف رسمی و مستندی است که برای سیستمهای "با تأثیر مستقیم" الزامی است.
تمرکز مهندسی در برابر تمرکز کیفی
- تمرکز مهندسی (DR): با هدایت متخصصان (SMEs)، این بررسیها بر قابلیت بهرهبرداری، قابلیت نگهداری و ایمنی تمرکز دارند.
- تمرکز کیفی (DQ): بر انطباق و CDEهای سیستم متمرکز است. در حالی که متخصصان (SMEs) طراحی فنی را هدایت میکنند، واحد کیفیت (QU) باید نظارت را فراهم کند.
نکته حرفهای: حضور واحد کیفیت (QU) در بررسیهای طراحی برای سیستمهای با تأثیر مستقیم به شدت توصیه میشود. این امر مرحله نهایی DQ را ساده کرده و از کشف دیرهنگام شکافهای طراحی که میتواند یک پروژه را متوقف کند، جلوگیری میکند.
فازهای تکرارپذیر طراحی:
- مفهوم (Concept): ارزیابی گزینههای محدوده (scope) و الزامات کیفی/فرآیندی سطح بالا.
- مبانی طراحی (BOD): توسعه محدوده کار (SOW) و اسناد "صادرشده برای طراحی" (IFD).
- طراحی دقیق (Detailed Design): نهاییسازی نقشههای ساختوساز و مشخصات "صادرشده برای ساخت" (IFC).
۵. اجرای فرآیند DQ: یک رویکرد گام به گام
فرآیند DQ شامل یک بررسی سیستماتیک از طراحی نهایی در برابر SRA و URS است. تیم پروژه باید تأیید کند که تمامی الزامات فرآیند، کیفی و نظارتی در طراحی نهایی گنجانده شدهاند.
دیدگاه ممیز در مورد "پروتکلها": یک تفاوت ظریف اما بحرانی که اغلب توسط تیمهای پروژه نادیده گرفته میشود این است که وجود یک سند رسمی پروتکل DQ برای بررسی الزامات در برابر طراحی، یک الزام نظارتی نیست. تمرکز باید بر روی تأیید مستند باشد. چه این موضوع در یک ماتریس ردیابی (Traceability Matrix) ثبت شود و چه در خود گزارش خلاصه DQ، از تولید پروتکلهای تکراری و اضافی خودداری کنید، مگر اینکه توسط SOPهای داخلی سایت شما الزامی شده باشد.
الزامات گزارش نهایی احراز صلاحیت (احراز کیفیت) طراحی:
بر اساس بخش ۵.۴.۴ منبع، گزارش نهایی باید شامل موارد زیر بوده یا به آنها ارجاع دهد:
- هرگونه بررسی ریسک مورد نیاز برای مستندسازیِ گنجاندن عناصر کنترل طراحی جهت پشتیبانی از تولید محصول باکیفیت.
- شناسایی تکتک CDEها (ویژگیهای خاص فیزیکی و عملکردی طراحی) که به منظور کنترل خرابیهای بالقوه فرآیند عمل میکنند.
- شرحی از هر CA و هرگونه CDE پشتیبانیکننده با عباراتی که از طریق بازرسیها یا آزمایشها (معیارهای پذیرش) قابل تأیید باشند.
- تأیید اینکه CDEها، الزامات کاربرِ محصول یا فرآیند را با عباراتی قابل تأیید (عمدتاً از طریق آزمایش عملکرد) برآورده میکنند.
۶. ماتریس ردیابی: اتصال الزامات به طراحی
ماتریس ردیابی ابزار اصلی برای مستندسازی مناسب بودن سیستم است. این ماتریس درک علمی از محصول را به ویژگیهای فیزیکی تجهیزات متصل میکند. برای یک ممیزی موفق، این ماتریس باید منعکسکننده یک زنجیره منطقی باشد:
CQA (ویژگی محصول) → CPP (پارامتر فرآیند) → CA (عملکرد سیستم) → CDE (ویژگی طراحی)
با پیروی از این جریان، شما شواهد روشنی ارائه میدهید که سیستم برای هدف مورد نظر خود مناسب است. اگرچه این ماتریس یک ابزار مدیریتی حیاتی است، اما اگر اطلاعات آن در جای دیگری (مانند گزارش خلاصه DQ) ثبت شده باشد، همیشه به عنوان یک خروجی مستقلِ الزامی برای تأیید در نظر گرفته نمیشود.
۷. نظارت و تأیید واحد کیفیت (QU)
مشارکت واحد کیفیت در فاز DQ برای سیستمهای با تأثیر مستقیم غیرقابل مذاکره است. تمایز قائل شدن برای نقش آنها بسیار مهم است: واحد کیفیت (QU) در جایگاه تضمین کیفیت عمل کرده و بر CAها و CDEها نظارت میکند تا از قابل تأیید بودن آنها اطمینان حاصل کند. آنها صرفاً یک کنترلِ "کیفیت مستندات" انجام نمیدهند.
الزامات تأیید: گزارش خلاصه نهایی DQ باید توسط نمایندگانی از بخشهای زیر امضا شود:
- متخصصان (SMEs) مهندسی/فنی (برای تأیید دقت فنی)
- تولید/عملیات (برای تأیید تناسب برای استفاده)
- واحد کیفیت (برای ارائه نظارت بر وضعیت احراز صلاحیت (احراز کیفیت) شده)
تأیید واحد کیفیت (QU) نشان میدهد که "وضعیت احراز صلاحیت (احراز کیفیت) شده" به درستی برنامهریزی شده و سیستم برای ساخت و تأییدات بعدی آماده است.
۸. نتیجهگیری: کارایی از طریق طراحی مبتنی بر علم و ریسک
یک فرآیند مستحکم احراز صلاحیت (احراز کیفیت) طراحی، سنگ بنای اجرای "بار اول درست" است. با حرکت منطقی از CQAs و CPPs به سمت CAs و CDEs، شما تضمین میکنید که هر فعالیت آزمایشی، به جای چکلیستهای دلخواه و تصادفی، بر درک علمی از فرآیند استوار است.
ستون فقرات این فرآیند، پایبندی به استانداردهای مستندسازی رویه مهندسی خوب (GEP) است (همانطور که در فصل ۱۳ منبع به تفصیل بیان شده است). پیروی از GEP در سراسر چرخه حیات DQ، یکپارچگی دادهها را تضمین کرده و یک مسیر حسابرسی قابل دفاع ارائه میدهد که اثبات میکند سیستم، از همان بدو تأسیس، برای محافظت از کیفیت محصول و ایمنی بیمار طراحی شده است.