راهنمای جامع استاندارد IEC 62304:2015
فرآیندهای چرخه عمر نرمافزار دستگاههای پزشکی
این استاندارد، یک سند بینالمللی است که فرآیندهای چرخه عمر نرمافزار برای نرمافزار دستگاههای پزشکی را مشخص میکند. هدف اصلی آن تضمین ایمنی و کارایی نرمافزار از طریق تعریف فعالیتها و وظایف منظم است. این استاندارد یک مدل توسعه خاص (مانند مدل آبشاری یا چابک) را تحمیل نمیکند، بلکه الزامات را بر اساس کلاس ایمنی نرمافزار تعیین میکند.
۱. الزامات عمومی و مبانی استاندارد
این بخش، پایههای اساسی برای انطباق با کل استاندارد را فراهم میکند و فرآیندهای لازم قبل از شروع توسعه را توضیح میدهد.
سیستم مدیریت کیفیت (Quality Management System)
- توضیح: تولیدکننده باید توانایی خود را در ارائه نرمافزاری که به طور مداوم با الزامات مشتری و مقررات قانونی مطابقت دارد، نشان دهد.
- مثال: یک شرکت تولیدکننده نرمافزار برای یک دستگاه پمپ انسولین، باید یک سیستم مدیریت کیفیت مطابق با استاندارد ISO 13485 داشته باشد. این سیستم شامل رویههایی برای مدیریت مستندات، کنترل تغییرات، و سوابق آموزشی کارکنان است.
مدیریت ریسک (Risk Management)
- توضیح: تمام فرآیندهای مربوط به نرمافزار باید بر اساس یک فرآیند مدیریت ریسک جامع که با استاندارد ISO 14971 سازگار است، انجام شود. این فرآیند به تولیدکننده کمک میکند تا خطرات احتمالی را شناسایی، ارزیابی و کنترل کند.
- مثال: تیم توسعه نرمافزار برای یک دستگاه مانیتورینگ قلب، باید تمامی خطرات احتمالی مانند نمایش نادرست ضربان قلب یا خاموش شدن ناگهانی دستگاه را شناسایی و برای کاهش آنها، رویههایی مانند اضافه کردن هشدارهای صوتی و تصویری را تعریف کند.
طبقهبندی ایمنی نرمافزار (Software Safety Classification)
-
توضیح: هر سیستم نرمافزاری باید بر اساس ریسک بالقوهای که میتواند به بیمار یا کاربر وارد کند، به یکی از سه کلاس ایمنی طبقهبندی شود.
-
کلاس A (کمترین ریسک): نرمافزار به یک وضعیت خطرناک منجر نمیشود یا ریسک آن با اقدامات کنترلی خارجی (مثلاً یک سیستم سختافزاری ایمنی) قابل قبول است.
- کلاس B (ریسک متوسط): نرمافزار میتواند به یک وضعیت خطرناک منجر شود که نتیجه آن آسیب غیرجدی باشد.
- کلاس C (بالاترین ریسک): نرمافزار میتواند به یک وضعیت خطرناک منجر شود که نتیجه آن مرگ یا آسیب جدی باشد. این بالاترین سطح ریسک است و سختگیرانهترین الزامات را دارد.
- قاعده پیشفرض: تا زمانی که یک کلاس ایمنی به نرمافزار اختصاص داده نشده است، الزامات کلاس C اعمال میشود.
نرمافزار قدیمی (Legacy Software)
- توضیح: این بخش راهکاری برای انطباق نرمافزارهایی فراهم میکند که پیش از اعمال این استاندارد توسعه یافتهاند.
-
فرآیند: تولیدکننده باید یک تحلیل شکاف (Gap analysis) انجام دهد تا مستندات و فرآیندهای موجود را با الزامات استاندارد مقایسه کند. سپس، فعالیتهای لازم برای بستن شکافها و مستندسازی مناسب انجام میشود. حداقل محصول قابل تحویل از این فرآیند، سوابق آزمون سیستم نرمافزاری است.
-
مثال: یک شرکت در حال بهروزرسانی نرمافزار دستگاه قدیمی تصویربرداری است. آنها باید یک تحلیل شکاف (Gap analysis) انجام دهند تا مشخص کنند کدام الزامات استاندارد IEC 62304 در فرآیند توسعه اولیه رعایت نشده است و سپس با مستندسازی و آزمونهای اضافی، این شکافها را پوشش دهند.
۲. فرآیند توسعه نرمافزار
این بخش، هسته اصلی استاندارد است و تمام مراحل توسعه را به صورت یک زنجیره منطقی شرح میدهد.
برنامهریزی توسعه (Software Development Planning)
- توضیح: یک برنامه جامع برای فرآیند توسعه باید تهیه و بهروز شود.
-
اهمیت: برنامهریزی باید متناسب با دامنه و کلاس ایمنی نرمافزار باشد. این برنامه همچنین باید استانداردها، روشها و ابزارهای مورد استفاده، بهویژه برای کلاس C را مشخص کند.
-
مثال: برای توسعه یک دستگاه پمپ تزریق داروی خودکار (کلاس C)، برنامه توسعه باید شامل یک جدول زمانی دقیق، مشخص کردن مسئولیت هر عضو تیم، ابزارهای مورد استفاده (مانند کامپایلرها و سیستمهای مدیریت نسخه) و رویههای بازبینی کد باشد.
تحلیل الزامات نرمافزار (Software Requirements Analysis)
- توضیح: الزامات سیستم به الزامات دقیق و قابل آزمون نرمافزاری تبدیل و مستند میشوند.
- مثال: یکی از الزامات سیستم برای دستگاه پمپ انسولین ممکن است این باشد: "دستگاه باید دوز دقیق انسولین را بر اساس سطح قند خون فعلی تزریق کند." الزامات نرمافزاری باید این را به یک الزام قابل آزمون تبدیل کند: "نرمافزار باید سطح قند خون را از سنسور بخواند و دوز انسولین را با دقت ۰.۱ واحد محاسبه و نمایش دهد."
طراحی معماری نرمافزار (Software Architectural Design)
- توضیح: الزامات به یک معماری مستند تبدیل میشوند که ساختار نرمافزار را شرح میدهد.
- جداسازی برای کنترل ریسک: هرگونه جداسازی بین اقلام نرمافزاری که برای کنترل ریسک لازم است (مثلاً اجرای کد در پردازندههای جداگانه)، باید شناسایی و اثربخشی آن تضمین شود.
- مثال: معماری نرمافزار برای پمپ انسولین، باید بخشهای مختلف را مشخص کند: ماژول محاسبه دوز، ماژول ارتباط با سنسور، ماژول رابط کاربری و ماژول مدیریت آلارم. این معماری باید نشان دهد که چگونه این ماژولها با یکدیگر در تعامل هستند. همچنین، برای کنترل ریسک، ماژول محاسبه دوز ممکن است در یک بخش جداگانه از ماژول رابط کاربری اجرا شود تا خطاهای رابط کاربری بر عملکرد حیاتی آن تأثیری نگذارند.
طراحی دقیق نرمافزار (Software Detailed Design)
- توضیح: هر مورد نرمافزاری به واحدهای نرمافزاری تقسیم شده و طراحی دقیق آنها برای پیادهسازی مستند میشود.
- مثال: ماژول محاسبه دوز (از مثال قبل)، به واحدهای کوچکتری مانند "تابع محاسبه دوز بر اساس الگوریتم A" و "تابع تأیید صحت دادههای ورودی" تقسیم میشود. طراحی دقیق هر واحد، شامل شرح عملکرد و جزئیات پیادهسازی آن است.
پیادهسازی و تأیید واحد نرمافزاری (Software Unit Implementation & Verification)
- توضیح: کد برای هر واحد نرمافزاری نوشته میشود و سپس بر اساس معیارهای پذیرش مشخص، تأیید میشود.
- مثال: کد مربوط به "تابع محاسبه دوز" نوشته میشود و سپس با استفاده از آزمون واحد (Unit Testing) و بازبینی کد (Code Review)، تأیید میشود که خروجی آن برای دادههای ورودی مشخص، دقیقاً مطابق انتظار است.
یکپارچهسازی و آزمون یکپارچهسازی (Software Integration and Integration Testing)
- توضیح: واحدهای نرمافزاری در کنار هم قرار گرفته و آزمون میشوند.
- مثال: پس از تأیید هر واحد، ماژولهای "محاسبه دوز" و "ارتباط با سنسور" با هم ادغام شده و آزمون میشوند تا مطمئن شویم دادههای سنسور به درستی به ماژول محاسبه دوز منتقل میشوند. آزمونهای رگرسیون انجام میشود تا اطمینان حاصل شود که این ادغام، عملکرد ماژولهای دیگر را مختل نکرده است.
آزمون سیستم نرمافزاری (Software System Testing)
- توضیح: کل سیستم نرمافزاری برای تأیید اینکه تمامی الزامات نرمافزاری برآورده شدهاند، آزمون میشود.
- مثال: تیم QA (تضمین کیفیت) کل پمپ انسولین را با شبیهسازها و در شرایط مختلف (مانند باتری کم، اتصال ضعیف سنسور) آزمون میکند تا از صحت عملکرد کل سیستم اطمینان حاصل کند.
انتشار نرمافزار (Software Release for Utilization)
- توضیح: آمادهسازی و انتشار نهایی نرمافزار.
- مثال: پس از اتمام تمامی آزمونها و تأیید آنها، نرمافزار نهایی به همراه مستندات کامل (مانند نتایج آزمون، گزارش مشکلات باقیمانده) آرشیو میشود. سپس، رویهای برای تحویل امن نرمافزار به کارخانه برای نصب روی دستگاهها اجرا میشود تا از هرگونه تغییر غیرمجاز جلوگیری شود.
۳. فرآیندهای نگهداری و پشتیبانی
این بخشها فرآیندهایی را پوشش میدهند که در طول کل چرخه عمر نرمافزار به صورت مداوم به کار میروند.
فرآیند نگهداری نرمافزار (Software Maintenance Process)
- توضیح: رسیدگی به مشکلات و تغییرات پس از انتشار نرمافزار.
- مثال: پس از انتشار پمپ انسولین، یک کاربر گزارش میدهد که در صورت خاصی، آلارم باتری کم به درستی فعال نمیشود. این بازخورد به عنوان یک گزارش مشکل ثبت میشود و فرآیند نگهداری برای رفع آن آغاز میشود.
فرآیند مدیریت ریسک نرمافزار (Software Risk Management Process)
- توضیح: مدیریت ریسکها به صورت مداوم در طول چرخه عمر نرمافزار.
- مثال: هنگام بررسی گزارش مشکل بالا، تیم توسعه باید تأثیر آن بر ایمنی دستگاه را ارزیابی کند. اگر این نقص بتواند منجر به آسیب شود، باید یک درخواست تغییر با اولویت بالا برای رفع آن ایجاد شود و در پرونده مدیریت ریسک ثبت گردد.
فرآیند مدیریت پیکربندی نرمافزار (Software Configuration Management Process)
- توضیح: کنترل سازمانیافته تغییرات در نرمافزار و مستندات آن.
- مثال: هرگونه تغییر در کد نرمافزار پمپ انسولین (مثلاً برای رفع مشکل آلارم) باید در یک سیستم مدیریت پیکربندی ثبت شود. این شامل اختصاص یک شماره نسخه جدید به نرمافزار و ردیابی اینکه کدام درخواست تغییر باعث این تغییر شده است.
فرآیند حل مشکل نرمافزار (Software Problem Resolution Process)
- توضیح: ارائه یک فرآیند رسمی برای رسیدگی به مشکلات شناساییشده.
- مثال: گزارش مشکل آلارم باتری کم، به تیم توسعه ارجاع داده میشود. آنها علت را بررسی کرده، یک تغییر در کد ایجاد میکنند و سپس راهحل را تأیید (Verification) میکنند تا مطمئن شوند مشکل حل شده است. پس از تأیید، گزارش مشکل بسته میشود و سوابق آن نگهداری میشود.
بخش ۴: فرآیند مدیریت ریسک نرمافزار (Software Risk Management Process)
این بخش از استاندارد، بر مدیریت ریسک در طول چرخه عمر نرمافزار تمرکز دارد و با استاندارد ISO 14971 برای مدیریت ریسک دستگاههای پزشکی ادغام شده است. هدف اصلی آن، شناسایی و کنترل خطراتی است که ممکن است به دلیل عملکرد نادرست یا نقص در نرمافزار رخ دهند.
تحلیل مشارکت نرمافزار در وضعیتهای خطرناک
- توضیح: تولیدکننده باید اقلام نرمافزاری (Software Items) که میتوانند به یک وضعیت خطرناک منجر شوند را شناسایی و علل احتمالی این خطر را بررسی کند. این وضعیت میتواند نتیجه یک خطای مستقیم در نرمافزار یا ناتوانی آن در پیادهسازی صحیح یک اقدام کنترلی باشد.
- مثال: برای یک دستگاه رادیولوژی، یک وضعیت خطرناک میتواند تابش اشعه X با دوز بالاتر از حد مجاز باشد. علت نرمافزاری میتواند یک نقص در کد کنترلکننده دوز یا خرابی در ماژولی باشد که مسئول خاموش کردن اشعه است. تولیدکننده باید هر دو مورد را شناسایی و مستند کند.
ارزیابی لیست ناهنجاریهای SOUP
- توضیح: اگر از SOUP (نرمافزار با منشأ نامشخص) مانند یک کتابخانه منبعباز یا یک سیستمعامل تجاری استفاده میکنید، باید هرگونه لیست ناهنجاری (Anomaly) یا باگهای منتشرشده توسط تأمینکننده را ارزیابی کنید تا مطمئن شوید هیچکدام از آنها به یک وضعیت خطرناک منجر نمیشوند.
- مثال: اگر نرمافزار از یک کتابخانه گرافیکی منبعباز برای نمایش تصاویر استفاده میکند، تیم توسعه باید لیست باگهای این کتابخانه را بررسی کند. اگر یک باگ باعث نمایش نادرست تصویر شود و این نمایش نادرست به تشخیص نادرست توسط پزشک منجر شود، این یک وضعیت خطرناک است و باید در پرونده مدیریت ریسک ثبت و کنترل شود.
اقدامات کنترل ریسک (Risk Control Measures)
- توضیح: برای هر وضعیت خطرناکی که توسط نرمافزار ایجاد میشود، باید اقدامات کنترلی تعریف و مستند شوند. این اقدامات میتوانند در سختافزار، نرمافزار یا حتی در دستورالعملهای کاربری پیادهسازی شوند.
- مثال: برای جلوگیری از دوز بالای اشعه در دستگاه رادیولوژی، یک اقدام کنترلی میتواند اضافه کردن یک سختافزار مستقل باشد که دوز را اندازهگیری کرده و در صورت تجاوز از حد مجاز، برق دستگاه را قطع کند. یک اقدام کنترلی نرمافزاری میتواند اضافه کردن یک الگوریتم تأییدیه دوز باشد که دوزهای ورودی را پیش از اجرا بررسی میکند.
تأیید اقدامات کنترل ریسک
- توضیح: پیادهسازی هر اقدام کنترلی باید به صورت مستقل تأیید شود تا اثربخشی آن اثبات شود.
- مثال: برای اقدام کنترلی نرمافزاری، باید یک تست اختصاصی طراحی شود که دوزهای ورودی غیرمجاز را شبیهسازی کرده و تأیید کند که نرمافزار به درستی واکنش نشان داده و دوز را رد میکند.
مدیریت ریسک تغییرات نرمافزار
- توضیح: هرگونه تغییر در نرمافزار، حتی تغییرات کوچک، باید تحلیل شود تا مشخص شود آیا ریسکهای جدیدی معرفی شده یا بر اقدامات کنترلی موجود تأثیری میگذارد یا خیر.
- مثال: اگر یک بهروزرسانی برای رابط کاربری نرمافزار پمپ انسولین منتشر میشود، تیم توسعه باید تأیید کند که این تغییر بر ماژول محاسبه دوز تأثیری نمیگذارد و عملکرد صحیح آن را تضمین میکند.
بخش ۵: فرآیند مدیریت پیکربندی نرمافزار (Software Configuration Management Process)
این فرآیند، چارچوبی را برای کنترل تغییرات در نرمافزار و مستندات مربوط به آن فراهم میکند تا از یکپارچگی و ردیابی مناسب اطمینان حاصل شود.
شناسایی پیکربندی (Configuration Identification)
- توضیح: باید یک طرح برای شناسایی منحصر به فرد اقلام پیکربندی (Configuration Items) و نسخههای آنها ایجاد شود. این اقلام میتوانند شامل کد منبع، مستندات طراحی و نتایج آزمون باشند.
- مثال: برای نرمافزار یک دستگاه اندازهگیری فشار خون، اقلام پیکربندی میتوانند شامل "کد منبع ماژول اندازهگیری فشار خون (نسخه ۱.۲)" و "سند الزامات نرمافزار (نسخه ۱.۰)" باشند.
کنترل تغییرات (Change Control)
- توضیح: تمامی تغییرات در اقلام پیکربندی تنها باید در پاسخ به یک درخواست تغییر (Change Request) تأییدشده انجام شوند. این فرآیند از تغییرات غیرمجاز جلوگیری میکند.
- مثال: برای رفع یک باگ در نرمافزار، یک درخواست تغییر با جزئیات کامل (شامل علت، تغییرات پیشنهادی و تأییدیه) ثبت و تأیید میشود. سپس، تغییرات در کد اعمال شده و در سیستم مدیریت نسخه (مانند Git) ثبت میشود.
حسابداری وضعیت پیکربندی (Configuration Status Accounting)
- توضیح: تولیدکننده باید سوابق قابل بازیابی از تاریخچه اقلام پیکربندی، شامل تغییرات و نسخههای آنها، را نگهداری کند.
- مثال: یک پایگاه داده یا سیستم اطلاعاتی باید سوابق تمام تغییرات در نرمافزار را نگهداری کند؛ مثلاً اینکه "در تاریخ ۲۰۲۵/۰۲/۲۰، ماژول محاسبه فشار خون از نسخه ۱.۲ به ۱.۳ بهروزرسانی شد تا باگ شماره CR-0123 را رفع کند."
بخش ۶: فرآیند حل مشکل نرمافزار (Software Problem Resolution Process)
این فرآیند، یک رویکرد سیستماتیک برای مدیریت و حل مشکلات (باگها و ناهنجاریها) در نرمافزار را فراهم میکند.
تهیه گزارش مشکل (Prepare Problem Reports)
- توضیح: برای هر مشکلی که در نرمافزار شناسایی میشود، یک گزارش مشکل تهیه میشود. این گزارش باید شامل جزئیاتی مانند میزان بحرانی بودن، دستگاههای تحت تأثیر و مراحل لازم برای بازتولید مشکل باشد.
- مثال: یک تستکننده گزارشی با عنوان "عدم نمایش آلارم فشار خون بالا" ثبت میکند. این گزارش شامل جزئیاتی مانند نسخه نرمافزار، مدل دستگاه و مراحل دقیق برای بازتولید مشکل است.
بررسی مشکل (Investigate the problem)
- توضیح: تولیدکننده باید مشکل را بررسی کرده و علت آن را شناسایی کند. این بررسی باید شامل ارزیابی تأثیر مشکل بر ایمنی با استفاده از فرآیند مدیریت ریسک باشد.
- مثال: تیم توسعه متوجه میشود که آلارم فشار خون بالا به دلیل یک خطای کدنویسی در یک شرط منطقی غیرمعمول فعال نمیشود. آنها این مشکل را به عنوان یک خطر ایمنی متوسط ارزیابی میکنند و تصمیم به رفع آن میگیرند.
نگهداری سوابق و تحلیل روند (Maintain records & Analyse for trends)
- توضیح: سوابق تمام گزارشهای مشکل و راهحلهای آنها باید نگهداری شوند. علاوه بر این، باید تحلیلهایی برای شناسایی روندها (Trends) در مشکلات انجام شود.
- مثال: اگر تیم متوجه شود که اکثر گزارشهای مشکل از یک ماژول خاص میآیند، این نشاندهنده یک مشکل اساسی در طراحی یا کدنویسی آن ماژول است که نیاز به بررسی عمیقتر دارد.
تأیید حل مشکل (Verify software problem resolution)
- توضیح: تأیید راهحلها باید انجام شود تا مشخص شود که مشکل به طور کامل حل شده، درخواستهای تغییر پیادهسازی شده و مشکلات جدیدی ایجاد نشده است.
- مثال: پس از اعمال تغییر در کد، تیم QA تستهای مجددی (Re-testing) را انجام میدهد تا مطمئن شود آلارم فشار خون بالا در شرایطی که قبلاً فعال نمیشد، اکنون به درستی کار میکند. همچنین، آزمونهای رگرسیون انجام میشود تا تأیید شود که این تغییر هیچ عملکرد دیگری را مختل نکرده است.
مستندات آزمون (Test documentation contents)
- توضیح: هنگام آزمون مجدد پس از یک تغییر، نتایج آزمون، ناهنجاریهای یافتشده و جزئیاتی مانند نسخه نرمافزار و پیکربندیهای آزمون باید به صورت دقیق مستند شوند.
- مثال: گزارش آزمون باید شامل اطلاعاتی مانند "آزمون برای رفع باگ آلارم فشار خون بالا انجام شد"، "نسخه نرمافزار: ۱.۳.۱"، "نتیجه: موفقیتآمیز" و "توسط: [نام تستکننده] در تاریخ [تاریخ]" باشد.
![[IEC62304_Software_62304.png]]