هل تطبيقك الصحي جهاز طبي؟ SaMD والذكاء الاصطناعي

وجود التطبيق في متجر إلكتروني أو استخدامه لكلمة health لا يجعله جهازًا طبيًا، كما أن وصفه wellness لا يخرجه تلقائيًا من نطاق SFDA. MDS-G027 يربط التأهيل بالغرض الذي حدده المصنّع وبما يفعله البرنامج للمريض أو المستخدم: هل يشخّص أو يراقب أو يعالج أو يقدّم معلومة تُستخدم في قرار سريري؟

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

1 الغرض الطبي هو الحد الفاصل

يذكر MDS-G027 أن المنتج الرقمي يتأهل كجهاز طبي عندما تكون له أغراض مثل الوقاية أو الكشف أو التشخيص أو العلاج أو المراقبة أو إدارة حالة طبية، بحسب intended use الذي يثبته المصنّع في labeling والمواصفات وتعليمات الاستخدام والوثائق المصاحبة. لذلك يجب مراجعة نص المتجر، والعروض البيعية، وشاشات التطبيق، ومواد تدريب الأطباء معًا. claim غير منضبط في قناة واحدة قد يناقض الملف التنظيمي.

SaMD هو برنامج يؤدي غرضًا طبيًا من دون أن يكون جزءًا من جهاز hardware طبي. أما software embedded الذي يشغّل الجهاز فهو SiMD وخارج النطاق المباشر للدليل. والبرنامج المستقل الذي يؤثر في جهاز hardware قد يكون SaMD إذا كان له غرض طبي خاص، أو accessory إذا كان يدعم وظيفة الجهاز دون غرض طبي مستقل. هذا التفكيك يجب أن يسبق أي class.

2 ليست كل وظيفة صحية وظيفة طبية

البرامج التعليمية العامة، والاتصال بين المريض ومقدم الخدمة، والتحليلات السكانية التي لا تستهدف قرارًا لمريض بعينه تُعرض في MDS-G027 كأمثلة خارج SaMD. كما أن وظائف HIT الإدارية مثل المواعيد والفوترة والتوثيق أو نقل البيانات وعرضها من دون تحليل لا تتأهل عادةً كأجهزة طبية. لكن إضافة تفسير لنتيجة مختبرية أو اقتراح تشخيصي أو alert سريري قد تنقل module محددًا إلى النطاق الطبي.

لتحويل هذه القراءة إلى خطة تخص منتجك، راجع مراجعة الملف الفني والجاهزية التنظيمية والرؤية التنظيمية المرتبطة.

في المنصات متعددة الوحدات، لا يكفي وصف المنصة كلها بأنها health IT أو AI platform. يجب رسم خريطة modules: وظيفة كل وحدة، بياناتها، مخرجها، من يراها، وما الإجراء الذي تدفع إليه. MDS-G027 يسمح بفصل الوحدات غير الطبية عندما يكون فصلها ووظيفتها غير الطبية موثقين بوضوح، بينما تُقدّم الوحدات التي تتأهل كأجهزة للمراجعة التنظيمية.

3 شجرة التأهيل الأولية

4 بعد SaMD يأتي سؤال الفئة

إذا تأهل البرنامج كجهاز، تُطبّق قواعد MDS-REQ 1. Rule 11 يصنّف البرنامج الذي يقدم معلومات لقرارات تشخيصية أو علاجية في B عادةً، ويرتفع إلى C إذا قد يؤدي القرار الخاطئ إلى تدهور خطير أو تدخل جراحي، وإلى D إذا قد يسبب وفاة أو تدهورًا غير قابل للعكس. كما أن مراقبة المؤشرات الحيوية قد ترتفع عندما تعرّض تغيراتها المريض لخطر فوري.

لا يمكن اختيار السيناريو من claim وحده. يجب وصف المرض وشدته، المريض، مستخدم البرنامج، degree of automation، وجود human review، الوقت المتاح للتدخل، ودور المخرج في المسار السريري. أداة تعطي توصية optional لطبيب ضمن عدة مدخلات تختلف عن أداة تضبط علاجًا تلقائيًا أو تقدم المعلومة الحاسمة دون مراجعة. هذه الوقائع هي جوهر classification rationale.

5 الذكاء الاصطناعي يوسّع ملف الأدلة

MDS-G027 يحدد مجالات تركيز للمنتجات الطبية المدعومة بـAI أو ML: verification and validation باستخدام بيانات متنوعة وعالية الجودة، data governance والتتبع، الشفافية والحدود والتحيز، إدارة المخاطر بما فيها cybersecurity والخصوصية، human oversight، وإدارة التحديثات وإعادة التحقق ومراقبة الأداء بعد السوق. هذه ليست عبارات تسويقية؛ يجب أن تتحول إلى traceability بين claim والمخاطر والبيانات والاختبارات.

قبل الإطلاق، يحتاج الفريق إلى وصف dataset provenance، population representativeness، فصل training عن validation، مقاييس الأداء بحسب subgroup، handling للبيانات الناقصة، وحدود الاستخدام. وبعد الإطلاق، يحتاج إلى complaints linkage، drift monitoring، trigger لإعادة التحقق، rollback وخطة لإصدار النسخ. مجرد كتابة الطبيب في الحلقة لا يثبت الرقابة البشرية ما لم يوضح التصميم ما يراه الطبيب وكيف يتدخل.

6 إدارة التغيير تبدأ قبل أول إصدار

تغيير input أو output أو population أو threshold قد يعدّل intended purpose أو performance أو المخاطر. MDS-G027 يطلب إجراءات تحكم للتحديثات وإعادة validation ومراقبة الأداء وتوثيق تغييرات الخوارزمية. لذلك يجب ألا تُعامل تحديثات model weights أو retraining أو إضافة تكامل جديد كإصدارات تقنية منفصلة عن الملف التنظيمي.

عمليًا، أنشئ release gate مشتركًا بين product وclinical وquality وregulatory. يسجل gate وصف التغيير، claim المتأثر، البيانات الجديدة، نتائج regression، أثر human factors وcybersecurity، وما إذا كان label أو ملف MDMA أو UDI-DI يحتاج تقييمًا. الهدف ليس إبطاء التطوير؛ بل منع إصدار يغيّر الغرض أو المخاطر قبل اكتمال القرار التنظيمي.

ومن المفيد فصل سجلين: software bill of materials and configuration record الذي يعرّف ما نُشر، وregulatory decision record الذي يوضح لماذا بقي claim والفئة ونطاق التفويض صالحًا. عند ظهور complaint أو اختلاف أداء بين مجموعة مرضى وأخرى، يستطيع الفريق ربط الحادث بالإصدار والبيانات والحدود التي كانت معروفة وقت الإطلاق، ثم تحديد ما إذا كان التصحيح تقنيًا فقط أو يحتاج إجراء تنظيميًا.

المراجع: [1] [2]