لائحة الأجهزة الطبية الأوروبية (EU MDR): أسئلة وأجوبة

If EU MDR لا يزال يجعلك تحك رأسك، فقد وصلت إلى المكان الصحيح. في هذه التدوينة، نناقش بعضاً من أكثر الأسئلة المحيرة المتعلقة بلائحة الأجهزة الطبية الأوروبية (EU MDR) التي صادفناها.

جميع الإجابات يقدمها خبير EU MDR لدينا، كريستوف مينيكي، مدير الرعاية الصحية وعلوم الحياة في Spyrosoft.

هل إجراء استشارة التقييم السريري إلزامي لجميع الأجهزة الطبية؟

في حالة الأجهزة الطبية من الفئة IIb، يكون إجراء الاستشارة اختياريًا. أما بالنسبة للأجهزة من الفئة III، فهو إلزامي.

هل يُعتبر البرنامج الذي يعمل على جهاز طبي ملحقاً للجهاز الطبي؟

Software is considered as a medical device accessory when it can be treated as an addition to some kind of configuration. If software serves a specific medical procedure, or a specific functionality of a medical device, for example, a web app used for configuration of such a device, then this software can but doesn’t have to be, considered as a medical device accessory.

Mind you, firmware is not considered as a medical device accessory. For software to be considered a medical device accessory, it must be integrated externally with a medical device that works independently.

These are just the general rules. To ultimately determine, whether specific software qualifies as a medical device accessory or not, you need to take other factors and MDR rules into consideration.

When it comes to the classification of a medical device accessory, it always “inherits” the same class as the medical device it’s used with. That’s because it doesn’t have a separate Intended Use: it’s used only as an addition to the medical device.

هل من الممكن أن يكون للجهاز الطبي والبرمجيات فئتان مختلفتان؟

Yes, it’s possible. For example, a class III medical device that has the highest risk level can be supported by software that includes only simple, basic functionalities, doesn’t impose any risk, and therefore qualifies to a lower class than the medical device.

بالإضافة إلى ذلك، وفقًا لـIEC 62304، فمن الممكن إلغاء تصنيف مكونات برمجية معينة إذا تم استيفاء معايير محددة تراعي العزل والتفكيك.

For example, let’s say your software has certain components that perform different functionalities, and these functionalities have different risk levels. You can decompose your software on the software architecture level into modules that belong to different software classes. For example, the whole device will be in class III (class C as software) due to a high-risk level, but certain modules that meet the isolation criteria will belong to lower classes (software class b or a).

This approach is often applied in the case of complex systems due to proper medical risk management and cost optimization (the higher the class, the more expensive the development and maintenance process).

ماذا لو لم يُستخدم جهاز طبي وفقاً للاستخدام المقصود منه؟ من يتحمل المسؤولية: الطرف الذي اشترى الجهاز أم الشركة المصنّعة له؟

إذا استخدم شخص ما جهازًا طبيًا بما يخالف الاستخدام المقصود المتوقع، تقع المسؤولية عليه هو، لا على الشركة المصنّعة.

هل يمكنني إضافة إخلاء مسؤولية داخل النظام أو التطبيق لتجنب تصنيفه كجهاز طبي بسبب ميزة معينة؟

يجب أن يكون نطاق الوظائف المعلن في الاستخدام المقصود للبرنامج دقيقاً وأن يعكس الحالة الفعلية للأمور. وإضافة إخلاء المسؤولية ليست حلاً مقبولاً.

For example, if a medical device is used to monitor some aspects of a patient’s health and provides suggestions for medical diagnosis and treatment-related decisions based on the data gathered, while its Intended Use is limited to monitoring, you as a manufacturer aren’t allowed to add such a disclaimer.

When developing new functionalities of your software, keep in mind that you can’t add any features that would exceed the scope of its Intended Use. To be able to do that, you shall first make changes to the Intended Use, which may result in the reclassification of your device.

كيفية تفكيك البرمجيات إلى وحدات لتحديد أي منها يُعتبر جهازًا طبيًا؟

It’s done based on a software architecture document. It should describe the Intended Use of the whole system and present the decomposition into medical and non-medical modules together with the justification.

هل هناك ممارسات جيدة أو إرشادات لتفكيك النظام؟

هناك قاعدة بسيطة: البنية المعمارية الجيدة للبرمجيات ضرورية. فهي تخدم المطورين واستراتيجية الامتثال التنظيمي بأكملها.

Firstly, you should think over the strategy, starting from defining the Design Input, which included the Intended Use, project requirements, determine the Intended Market and Intended User, etc. This will be the foundation for your further work.

يجب عليك أيضًا التحكم في كل تغيير يتم إجراؤه على البرمجيات، خاصة فيما يتعلق بمدخلات التصميم (Design Input). قبل إدخال أي تغيير، ينبغي أن تسأل نفسك:

• هل يؤثر ذلك على الاستخدام المقصود الحالي أو تصنيف الأجهزة الطبية؟ إذا كان الأمر كذلك، كيف؟
• هل يؤثر ذلك على مستوى المخاطر الحالي؟

You should also keep in mind that the modularity and architecture should serve your needs and be structured well enough so as not to increase the overhead. However, separating the medical modules from the non-medical ones implies architectural consequences. You must foresee all possible risk areas. This, in turn, leads to more complexity and more labour.

أي أسئلة أخرى متعلقة بلائحة الأجهزة الطبية الأوروبية؟

لم تجد ما كنت تبحث عنه؟ اطلع أيضًا على منشورات أخرى تتعلق بلائحة EU MDR على مدونتنا:

• لائحة الأجهزة الطبية الأوروبية (EU MDR) مقابل توجيه الأجهزة الطبية (MDD): ما الذي يتغير في صناعة التكنولوجيا الطبية الأوروبية؟
• لائحة الأجهزة الطبية الأوروبية (EU MDR): ما تحتاج إلى معرفته عن لائحة الأجهزة الطبية في 2021
• لائحة الأجهزة الطبية الأوروبية (EU MDR) سارية المفعول: الدعوة الأخيرة لقطاع التكنولوجيا الطبية لاتخاذ إجراء

إذا كان لديك أي استفسار آخر ترغب في معرفته حول EU MDR، فلا تتردد في استخدام نموذج الاتصال أدناه وإرسال رسالة إلينا. سنعاود التواصل معك في أقرب وقت ممكن.