كيفية تنفيذ تحليل فجوات البرمجيات القديمة كما هو مطلوب بموجب IEC 62304-2015؟

غالبًا ما تشكّل البرمجيات القديمة التي لم تُبنَ وفقًا لمعيار IEC 62304 تحديًا صعبًا للعديد من مصنّعي الأجهزة الطبية، لا سيما عند الحاجة إلى تصميم نسخة جديدة من جهاز طبي أو إجراء تغييرات على نسخة موجودة.

ما هي الطريقة الأكثر ملاءمة والموصى بها للتعامل مع البرمجيات القديمة؟ كيف يتم تنفيذ تحليل فجوات البرمجيات القديمة المطلوب بموجب IEC 62304؟ كريستوف مينيكي، مديرنا لقطاع الرعاية الصحية وعلوم الحياة، يناقش المشكلات ويشرح الطرق الممكنة لمواءمة البرمجيات القديمة مع متطلبات IEC 62304.

ما هو البرنامج القديم؟

البرمجيات القديمة هي نوع البرمجيات الموجودة بالفعل في جهاز طبي تم طرحه في السوق قبل عام 2006 عندما دخلت النسخة الأولى من معيار IEC 62304 حيز التنفيذ، ولا يزال يُسوَّق حتى اليوم. على الرغم من مرور 15 عامًا بالفعل، لا يزال من الممكن مواجهة مثل هذه المواقف.

البرمجيات القديمة مقابل SOUP

أحياناً يُخلط بين البرمجيات القديمة وSOUP (البرمجيات مجهولة المصدر). وينتج هذا الالتباس عن كون كليهما قد طُوِّر دون اتباع عمليات دورة حياة البرمجيات وتوثيقها.

كيف يمكن مواءمة البرامج القديمة مع معيار IEC 62304؟

هناك عدة مقاربات يمكنك اتباعها عند التعامل مع البرمجيات القديمة، وذلك حسب ما إذا كانت ستتأثر بالتغييرات أم لا.

1. لن تكون هناك تغييرات على برمجيات الأجهزة الطبية، بما في ذلك البرمجيات القديمة

أولًا وقبل كل شيء، طالما أنك لا تغيّر أي شيء يتعلق ببرمجيات الجهاز الطبي التي تشكل البرمجيات القديمة جزءًا منها، فلا حاجة لاتخاذ أي إجراء. لنفترض أن البرمجيات القديمة غير متأثرة بالتغييرات. في هذه الحالة، فإن النهج الأبسط والموصى به هو التعامل معها باعتبارها SOUP، أي برمجيات خارجية لا تملك أي سيطرة عليها، واتباع الخطوات المناسبة التي يتطلبها معيار IEC 62304.

تزداد الأمور تعقيدًا عندما ترغب في إجراء تغييرات على جزء البرمجيات القديمة، وعلى برمجيات الجهاز الطبي ككل، دون أن يشمل ذلك بالضرورة الجزء القديم. تخيّل برمجيات جهازك الطبي كدائرة، حيث تكون البرمجيات القديمة مجرد شريحة منها. يمكنك اتباع عدة مقاربات، اعتمادًا على ما إذا كنت ترغب في إجراء تغييرات على أي جزء من تلك الدائرة ليس تلك الشريحة، أو ترغب في إجراء تغييرات على الكل.

اسمحوا لي أن أوضح ذلك بمثال. لنفترض أنه قبل 15 عاماً، أصدرت إحدى الشركات جهازاً طبياً يُستخدم لتصور البيانات، مثل جهاز مراقبة تخطيط القلب. لم يُبنَ برنامج التشغيل الخاص بهذا الجهاز وفقاً لمتطلبات IEC 62304 لأن المعيار لم يكن سارياً بعد. والآن هناك حاجة لتغيير الألوان التي يعرضها. في مثل هذه الحالة، لا يتعين عليك إجراء أي تغييرات على برنامج التشغيل لأنه سيتواصل مع جهاز المراقبة بالطريقة نفسها، ببساطة ستكون الأوامر المتعلقة بالألوان المعروضة مختلفة. ويمكن التعامل مع برنامج التشغيل هذا باعتباره SOUP.

ومع ذلك، إذا كنت ترغب في إزالة الهوامش من الشاشة، فلن يكون ذلك ممكناً دون تغيير وضع العرض. وهذا بدوره يؤدي إلى إجراء تغييرات على برنامج التشغيل، أو بعبارة أخرى برمجياتنا القديمة. وفي مثل هذه الحالة، عليك مواءمتها مع متطلبات IEC 62304. وسنوضح كيفية القيام بذلك في الفقرات التالية. في الوقت الحالي، دعنا نعود إلى الاستراتيجيات لدقيقة، حيث توجد استراتيجيتان أخريان على الأقل يمكنك تطبيقهما في هذه الحالة.

2. ستكون هناك تغييرات على برمجيات الأجهزة الطبية و/أو البرمجيات القديمة

أولًا، عليك أن تجيب نفسك عن سؤال: هل التغيير جوهري وواسع النطاق بما يكفي للتأثير على البرمجيات القديمة أم لا. إذا كان الأمر كذلك وكان التغيير يؤثر على البرمجيات القديمة، فلا يمكن التعامل معها بعد الآن باعتبارها SOUP، بل يلزم إعادة تصميم كاملة ويجب تطبيق معيار IEC 62304 بالكامل. وإلا، فستكون هناك صعوبات كثيرة وسيكون الحفاظ عليها أمرًا صعبًا.

هناك احتمال آخر وهو تقسيم البرمجيات القديمة إلى مكونات ستُعدَّل وأخرى لن تُعدَّل، لكنها تشكّل أقل من 10-15% من الإجمالي. بعد ذلك، نتعامل مع الجزء المُنقَّح من البرمجيات القديمة كـ SOUP، تمامًا كما شرحنا سابقًا. بالإضافة إلى ذلك، يمكننا بناء طبقة تكامل إضافية للتخفيف من المخاطر تمنحنا حماية ضد العواقب السلبية المحتملة لدمج SOUP مع جهاز طبي. يجب تقييم المخاطر المرتبطة بهذا التكامل لتحديد ما إذا كانت هناك حاجة لتنفيذ تدابير رقابية إضافية. يُستخدم هذا النهج بشكل متكرر عند التعامل مع البرمجيات القديمة.

هناك نهج آخر يتمثل في تحليل وتقييم البرمجيات القديمة وفقاً لمعيار IEC 62304، وتحديداً الفصل 4.4. فهو ينص على أنه يمكنك إجراء تطوير تصميم كامل وفقاً لجميع المتطلبات الموضحة في الفصول 5-9، وبالتالي لا ينبغي القيام بأي شيء آخر بشأن البرمجيات القديمة. غير أن هناك عيباً كبيراً في هذا النهج: فهو يولّد تكاليف مرتفعة جداً.

الآن بعد أن وصفنا الاستراتيجيات الأكثر شيوعًا، دعنا ننتقل إلى الجزء العملي.

كيفية مواءمة البرامج القديمة مع IEC 62304؟

الخطوة 1: تقييم مخاطر البرمجيات القديمة

أولًا وقبل كل شيء، وفقًا لمتطلبات إدارة المخاطر، علينا تحليل بنية حلنا وتحديد فئة المخاطر للبرمجيات القديمة. هناك ثلاث فئات للمخاطر: A وB وC. إذا كان جهازنا الطبي ينتمي إلى إحدى هذه الفئات، وخاصة الفئة C عالية المخاطر، فيجب علينا التحقق مما إذا كان يمكن إجراء التفكيك.

بمجرد الانتهاء من التحليل التفصيلي، يمكننا تحديد ما إذا كانت البرمجيات القديمة مسؤولة عن وظائف غير طبية ذات مخاطر أقل على المريض، على سبيل المثال، نقل البيانات، أو أنها مكون حاسم من الفئة B أو C. وبناءً على ذلك، يتعين علينا تحديد ما إذا كان بإمكاننا التعامل مع برمجياتنا القديمة باعتبارها SOUP أم أن ذلك ليس خيارًا متاحًا، على سبيل المثال في حالة انتماء الجهاز الطبي إلى الفئة C وانتماء برمجياتنا القديمة أيضًا إلى الفئة C، بينما تستوفي المكونات الأخرى متطلبات فئات المخاطر الأدنى.

أول ما ينبغي أن نأخذه في الاعتبار عند إجراء تحليل المخاطر هو المشكلات المحتملة التي تسببها برمجياتنا بناءً على ملاحظات المستخدمين. في تقييم المخاطر لدينا، يجب أن نصف جميع الأنشطة التي تؤثر على الجهاز والتنظيم والعمليات والمرضى.

وهناك أمر آخر يتمثل في تقييم المخاطر المرتبطة بدمج برمجياتنا القديمة مع مكونات أخرى في الجهاز الطبي، سواء كانت هي أيضًا جزءًا من البرمجيات القديمة أم لا. ويتعين علينا التحقق مما إذا كانت هناك أي مخاطر موصوفة بالفعل لبرمجياتنا الطبية، وما تدابير التحكم التي طُبقت لخفض هذه المخاطر أو الحد منها، والتحقق من مدى تأثير برمجياتنا القديمة على تدابير التحكم هذه. وإذا كان لها تأثير، فيتعين علينا تقييم المخاطر المحتملة والتحقق مما إذا كانت هذه التدابير ستظل فعالة.

إذا عدنا الآن إلى مثال جهاز مراقبة تخطيط القلب ECG، فربما كانت المسافة على الشاشة قد نُفذت كإجراء للتحكم في المخاطر حتى لا تُقطع أي معلومات مهمة، فإذا أزلناها، قد يكون هناك خطر من تفويت مثل هذه المعلومات. في مثل هذه الحالة، ينبغي تحديد إجراءات إضافية للتحكم في المخاطر وإدراجها في ملف إدارة المخاطر.

الخطوة التالية هي إجراء تحليل الفجوات.

الخطوة 2: تحليل فجوات البرمجيات القديمة وفقاً لمعيار IEC 62304

عند تحديد فئة المخاطر لبرمجياتنا القديمة، ينبغي لنا إجراء تحليل للفجوات والتحقق مما إذا كنا نفتقد أي وثائق مطلوبة وفقًا للفصل 5.2 (متطلبات البرمجيات)، و5.3 (تصميم بنية البرمجيات)، و5.7 (اختبار نظام البرمجيات)، و7 (عمليات إدارة مخاطر البرمجيات).

كحد أدنى، يجب أن يفي برنامجنا القديم بما يلي:

• تلبية المتطلبات المتعلقة بالوظائف والكفاءة والسلامة وغيرها كما هو موضح في الفصل 5.2؛

• أن تُدرج في وثائق معمارية البرمجيات مع وصف واضح لحدودها، وعناصر العزل والتكامل، فضلاً عن خطة التكامل مع المكونات الأخرى بما في ذلك المخاطر المحتملة المرتبطة بفئاتها المعنية، وفقًا للفصل 5.3؛
• تم إجراء جميع الاختبارات اللازمة وتوثيقها وفقاً للفصل 5.7؛
• تطبيق عمليات إدارة المخاطر كما هو مطلوب في الفصل السابع.

يساعدنا تحليل الفجوات في تحديد عناصر التوثيق المتعلقة بالبرمجيات القديمة التي تفتقر إلى بعض المعلومات الحيوية التي تحتاج إلى استكمال. كما يمنحنا صورة أوضح عن المخاطر المحتملة ومدى أهمية البرمجيات القديمة لبرمجيات الأجهزة الطبية ككل.

بناءً على نتائجنا، يمكننا إعداد خطة تتضمن نتائج تحليل الفجوات بالإضافة إلى خطوات موصوفة بشكل شامل سنتخذها لإصلاح المشكلات المحددة. ويعتمد الجدول الزمني لتنفيذ الخطوات على مدى خطورة المخاطر ومدى شدة العواقب المحتملة على المستخدمين النهائيين. كما يجب أن تتذكر تبرير سبب رغبتك في الاستمرار في صيانة البرمجيات القديمة، ولفترة كم، وما إذا كنت تخطط للتوقف عن استخدامها في المستقبل.

خلاصة القول

إذا كنت لا تخطط لإدخال أي تغييرات على برنامج جهازك الطبي، فإن النهج الأكثر ملاءمة والموصى به هو التعامل معه باعتباره SOUP، إن أمكن. وبهذه الطريقة، سيكون الحفاظ على البرمجيات القديمة أسهل بكثير. ومع ذلك، وبغض النظر عن النهج الذي تختاره، فإنك تحتاج دائمًا إلى بذل العناية الواجبة: اختبار البرمجيات القديمة، وتقييم المخاطر، والتحقق من صحة تدابير التحكم، وتحديد المتطلبات المفقودة، ووصف خطة العمل الخاصة بك.

لمزيد من المعلومات حول إجراء تحليل فجوات البرمجيات القديمة، يرجى الرجوع إلى IEC 62304.

إذا كنت بحاجة إلى مساعدة في اختيار النهج المناسب لبرمجياتك القديمة أو إجراء تحليل الفجوات، فلا تتردد في التواصل مع Krzysztof Minicki باستخدام النموذج أدناه.