الدليل التفصيلي لعملية التحقق من البرمجيات لدى إدارة الغذاء والدواء الأمريكية

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

من المهم الإشارة هنا إلى أنه في 4 نوفمبر 2021، أصدرت إدارة الغذاء والدواء الأمريكية (FDA) وثيقة قد تغير ملامح التحقق/التصديق على البرمجيات الطبية وأي عمليات ذات صلة. ‘محتوى الطلبات قبل الطرح للاستخدام لوظيفتي برمجيات الجهازأصبح الآن متاحًا للعموم في نسخته الأولية المخصصة للتعليقات فقط، مع جمع الملاحظات حتى نهاية عام 2022.

كما كان الحال مع السابق المقالات، أُعدّ هذا المقال بالتعاون مع كريستوف مينيكي، مدير الرعاية الصحية وعلوم الحياة في Spyrosoft.

ما هو التحقق من البرمجيات الطبية وفقًا لإدارة الغذاء والدواء الأمريكية؟ 

The goal of the medical software verification is to prove that our specified software requirements are consistent, complete and have been properly implemented, and our medical applications work as planned. It serves as confirmation that what we planned to do when it comes to the software implementation has been carried out as required.  

To give you an example, if the application I developed was to provide a daily/weekly/monthly report for my patients’ saturation, temperature, blood pressure in a specific format, then the verification will mean that the application is, in fact, able to generate the report as required. 

ما هو التحقق من صحة البرمجيات الطبية وفقًا لإدارة الغذاء والدواء؟ 

يجب أن يؤكد التحقق – من خلال سلسلة من الأنشطة المختلفة التي تؤدي إلى أدلة موضوعية وقابلة للقياس – أن البرمجيات الطبية المطورة تؤدي وظيفتها كما هو موضح في الاستخدام المقصود وأنها فعالة وآمنة للتشغيل. As with verification, validation is also accomplished through a series of activities to check if the specific groups of requirements have been implemented consistently, completely and as a set of functionalities. This process is focused on providing evidence that the implementation effectively and properly fulfils the requirements and the intended use for this specific medical software.  

Going back to the example, we would have to show the report to a doctor that will be using it, and they would have to confirm that this will be – in fact – useful, clear, accessible and aligned with the initial medical expectations. The clue here is delivering an external validation for our medical software. 

لماذا – عملياً – لا يختلف التحقق والتحقق من الصحة كثيراً عن بعضهما البعض؟ 

من المهم ذكره هنا أن 'يرشدنا دليل «المبادئ العامة للتحقق من البرمجيات؛ الإرشادات النهائية للصناعة وموظفي إدارة الغذاء والدواء» عبر كل من عملية التحقق والتحقق من الصحة. 

While the verification and the validation have both been separated in the medical sector documentation, in practice – the division is arbitrary at times. It makes sense from a business perspective, though – as it clearly divides the responsibilities between our customers and our team. Once we receive the specifications, the requirements and a list of functionalities from a customer, we can then use those to develop medical software and then verify it using manual and automated tests as well as other activities.  

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

IQ/OQ/PQ – الجوانب الأساسية للتحقق من صحة البرمجيات الطبية 

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

تأهيل التركيب (IQ) 

يمكنك تثبيت البرنامج واستخدامه بأمان. 

تُعرّف إدارة الغذاء والدواء الأمريكية (FDA) تأهيل التركيب (IQ) بأنه ‘establishing confidence that process equipment and ancillary systems are compliant with appropriate codes and approved design intentions, and that manufacturer’s recommendations are suitably considered’. 

التأهيل التشغيلي (OQ) 

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

تأهيل الأداء (PQ) 

البرنامج فعال وسهل الوصول إليه وأداؤه جيد حتى مع زيادة عبء العمل. تعرّفه FDA بأنه ‘بناء الثقة من خلال الاختبار المناسب بأن المنتج النهائي الذي تنتجه عملية محددة يستوفي جميع متطلبات الإصدار من حيث الوظائف والسلامة’. 

ما هي مبادئ التحقق من صحة البرمجيات؟ 

The most important are the requirements – especially those related to the system – as they will be later used as a basis for validation. System requirements are later divided into software requirements, software architecture, software components, then again into more specific software requirements and details designs.  

Software validation should be planned at the software lifecycle level. The plan itself should be adjusted to a specific medical application, its class and its risks. The effort will be higher for software with higher risk and class II-III.  

At the planning level, we also need to establish how we want to approach any bugs and software failures that are inevitably related to the software development process. To do that, we need to answer this question: 

• كيف نريد إصلاح هذه الأخطاء وكيف سنتحقق من الإصلاحات ونصادق عليها؟ 

As for the validation process itself, we need to check whether the requirements, including those specific ones listed above, are what was eventually built and delivered during the software development process. We also need to explain in the documentation not only if each of these requirements were addressed but also how it was done. This is usually resolved by a list of requirements registered within a matrix with a list of ways and specific functionalities that we developed to address these requirements. This register should also include test cases for each requirement/functionality. 

بمجرد اكتمال المصفوفة، يمكن اعتبار إحدى خطوات التحقق ناجحة. 

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

كيفية التعامل مع أي تغييرات على المنتج؟ 

Another thing we should plan for is how we will approach any change to our original build and to what extent we will test our medical software after releasing these changes to production. Conducting extensive testing after a minor change may not be necessary, but we should clearly state what our approach will be after a small adjustment. You may need to conduct an analysis to estimate the impact this adjustment has on our software and the risk for the system as a whole. Based on the results of the analysis, you can then plan our next steps, including regressive tests, to ensure that the change is properly validated and verified. 

The extent of our validation and verification strategy will largely depend on the level of risk and the complexity of our software. The less risk it poses to the patient, the simpler our strategy can be. Eventually, we have to be able to prove that all criteria set at the planning stage have been met. 

What’s particularly important is the fact that both the validation and the verification process should be conducted by independent group of specialists from your company or a third-party body. It often happens that the verification is done internally by the software provider, and the validation process is conducted by the company that requested the software to be developed – it is not a rule, though. In practice, both parties cooperate to complete the processes at various stages of development.  

لكل خطوة من خطوات العمليات، نحتاج أيضاً إلى وضع معايير القبول – باختصار: يجب أن يتطابق المدخل مع المخرج. 

دراسات العامل البشري – الخطوة الأخيرة في عملية التحقق 

If you’re a medical software provider, you’re obligated to conduct human factor studies as the crucial step of the validation process. Software is then tested using a simulated environment, yet with a group of its potential end-users. This group of users must be selected carefully taking into consideration factors such as age, race, gender, educational background, language and location. There are two types of HMS depending on when they are conducted: 

• دراسات العوامل البشرية التكوينية التي تُجرى في بداية عملية التطوير، 

• دراسات العوامل البشرية التجميعية محجوزة للمرحلة النهائية من عملية التحقق. 

These studies help to validate whether the final product is useful, accessible and meets the requirements. The sessions are then summarised in a report on the usability of the medical product, including software.  

الدور عليك 

هل تحتاج إلى دعم في التحقق من برمجياتك الطبية وفقًا لمتطلبات FDA؟ تواصل مع مديرنا للرعاية الصحية وعلوم الحياة، Krzysztof Minicki وفريقه علىLinkedIn أو عبر الموقع الإلكتروني.