نص التسويق لديكم هو من يحدد ما إذا كانت برمجيتكم جهازًا طبيًا

تخيّلوا تطبيقين. كلاهما يأخذ الأعراض التي يُدخلها المستخدم، ويشغّل خوارزمية، ويُعيد قائمة. الكود متطابق تقريبًا. أحدهما يقع ضمن تنظيم الأجهزة الطبية. الآخر لا يقع.

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

هذا هو الخطأ الأكثر كلفة، والأسهل تجنبًا، الذي أراه في مشاريع تقنية الصحة. التسويق يكتب وصف المنتج، ولا أحد يفكّر في نتيجته القانونية، وينتهي المنتج داخل نظام امتثال لم يقصد الدخول فيه أبدًا.

بيان الغرض المقصود وثيقة قانونية

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

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

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

بنية الوصول إلى بيانات الصحة

المادة 6 من القانون رقم 6698 تصنّف بيانات الصحة كفئة خاصة من البيانات الشخصية وتُخضعها لشروط أضيق. النظير التقني لذلك التصنيف مفقود في معظم المشاريع.

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

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

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

دعم القرار السريري والمسؤولية

أنظمة دعم القرار المدعومة بالذكاء الاصطناعي تثير سؤال أين تقع المسؤولية. عمليًا، التصميم الآمن هو أن يُنتج النظام توصية ويترك القرار النهائي للمهني الصحي المؤهل.

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

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

الرعاية الصحية عن بُعد

الخدمات الصحية عن بُعد في تركيا تعمل ضمن لوائح وزارة الصحة. أي الخدمات يمكن تقديمها عن بُعد، والتزامات حفظ السجلات، وحدود الخدمة، محددة في التشريع الثانوي، ولأن تلك القواعد يمكن أن تتغير، يجب مراجعة المنتج مقابل النص الحالي عند التصميم.

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

البدء بمشروع

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

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