في مختبر يعمل على WSI، المشكلة اليومية تظهر عندما يحتاج القسم إلى أكثر من AI model: biomarker quantification، tissue classification، أو أداة تساعد في ترتيب الحالات ومراجعة المناطق المهمة. كل إضافة جديدة قد تعني عقدا جديدا، واجهة جديدة، إعدادا فنيا منفصلا، وربطا إضافيا مع LIS أو image management system.
إعلان Aiforia وPathAI في 8 تشرين الأول 2026 يتعامل مع هذه النقطة التشغيلية تحديدا. Aiforia أعلنت اتفاقا تجاريا يجعل حلولها متاحة للمختبرات عبر AISight Marketplace داخل منصة PathAI. المصدر الرسمي يذكر أن AISight Dx هو Image Management System، وأن Aiforia ستصل من خلاله إلى مختبرات تعمل أصلا ضمن منصة PathAI، خصوصا مع وجود PathAI في الولايات المتحدة وانتشار Aiforia في أوروبا مع حلول CE-IVD في الباثولوجي الرقمي.
الإعلان تجاري وتشغيلي، ولا يقدم نتائج دراسة أداء سريرية جديدة. يغيب عنه ذكر الحساسية أو النوعية أو AUC، ولا يعرض مقارنة قارئ بقارئ. لذلك تدور القراءة العملية حول سؤال واحد: أين يظهر AI model لطبيب الباثولوجي؟ هل يظهر داخل مسار مراجعة الحالة، أم في شاشة منفصلة؟ من يربط النتيجة بالـ case؟ من يدعم العقد، الفوترة، والصيانة؟ هذه الأسئلة تحدد نجاح الأداة داخل المختبر أكثر من قوة النموذج على ورقة التسويق.
ما الذي أُعلن عنه؟
بحسب بيان Aiforia، ستتوفر حلولها داخل AISight Marketplace. النص يربط بين deep learning technology لدى Aiforia وبين قاعدة مستخدمي PathAI ومنصة AISight Dx. كما يشير إلى أن Aiforia لديها مجموعة من الحلول المؤشرة CE-IVD في أوروبا للباثولوجي الرقمي، وأن الاتفاق يوسّع الوصول إلى نماذجها عبر أوروبا والولايات المتحدة.
من جانب PathAI، يذكر البيان أن إدخال حلول Aiforia داخل case review workflows سيضعها مع catalog خوارزميات PathAI، ومع ربط AISight Link لأنظمة المختبر والمستشفى. العبارة المهمة لطبيب الباثولوجي هنا هي أن الاستخدام المقصود يضع الخوارزمية داخل مسار مراجعة الحالة نفسه، بدلا من تنزيل ملف منفصل أو إرسال صورة إلى بوابة خارجية.
كما يذكر البيان أن AISight Dx حاصل على CE-IVD للاستخدام في primary diagnosis داخل EEA وCH وUK. هذه نقطة تنظيمية تخص المنصة كما وردت في المصدر. كل خوارزمية داخل marketplace تحتاج قراءة مستقلة للغرض السريري وحدود الاستخدام. كل AI model يحتاج قراءة تعليمات الاستخدام، نطاق العينة، نوع الصبغة، النسيج، وسياق التقرير قبل إدخاله في خدمة تشخيصية.
لماذا يهم هذا لطبيب الباثولوجي؟
أثناء التوقيع يتعامل الطبيب مع slide، request، history، staining quality، وربما IHC أو molecular findings لاحقة. إذا ظهر الناتج في مكان منفصل عن WSI viewer، سيزيد الحمل الذهني. وإذا ظهر داخل viewer من دون طريقة واضحة لمراجعة المنطقة التي اعتمد عليها النموذج، سيتحول إلى رقم صعب الدفاع عنه.
وجود marketplace داخل IMS قد يقلل عدد الواجهات التي يفتحها الطبيب والفريق الفني. لكنه يرفع أهمية الحوكمة داخل المختبر. من يقرر أي خوارزمية تُفعّل لأي specimen؟ هل التفعيل تلقائي حسب code في LIS، أم يطلبه الطبيب عند الحاجة؟ هل النتيجة تدخل التقرير مباشرة، أم تبقى طبقة مساعدة قابلة للمراجعة؟ هذه تفاصيل صغيرة في الشراء، لكنها كبيرة عند اعتماد الأداة في العمل اليومي.
في سرطان الثدي مثلا، قد يحتاج القسم إلى أدوات قياس أو تصنيف مرتبطة بـ ER، PR، Ki-67، HER2-low، أو تقييم مناطق معينة قبل قرار إضافي. وفي البروستات أو الرئة أو القولون، قد تختلف الحاجة بين quantification، detection، أو ترتيب الحالات حسب أولوية المراجعة. المنصة الواحدة قد تجعل الوصول إلى هذه الأدوات أسهل، بشرط أن تبقى النتيجة قابلة للتدقيق داخل سياق الحالة.
السؤال العملي داخل المختبر
قبل إضافة أي AI model عبر marketplace، يحتاج القسم إلى مسار واضح من لحظة مسح الشريحة حتى ظهور النتيجة. يبدأ ذلك من جودة WSI: focus، folds، pen marks، bubbles، tissue coverage، وتطابق barcode. النموذج الذي يعمل على صورة سيئة قد يهدر وقت الطبيب، حتى لو كان مصدره شركة معروفة.
بعد ذلك يأتي الربط مع LIS. هل يعرف النظام نوع العينة والتشخيص المطلوب؟ هل يقرأ case metadata بطريقة تمنع تشغيل نموذج خاطئ على tissue غير مناسب؟ هل توجد audit trail تبين من طلب التحليل، متى اشتغل، أي نسخة من النموذج استخدمت، ومن راجع الناتج؟ هذه الأسئلة يجب أن تكون جزءا من اختبار القبول قبل التشغيل، قبل أن تظهر المشكلات في أول أسبوع من الاستخدام.
هناك أيضا سؤال مسؤولية التقرير. AI output قد يساعد في تحديد منطقة، قياس نسبة، أو ترتيب قائمة الحالات. القرار النهائي يبقى لدى طبيب الباثولوجي. لذلك يحتاج الطبيب إلى واجهة تعرض السبب العملي للنتيجة: overlay، heatmap، ROI، أو جدول قياسات قابل للمراجعة. الطبيب يحتاج أكثر من نتيجة رقمية داخل تقرير يحمل اسمه.
ما الذي يجب طلبه من المورد؟
أي مختبر يفكر في استخدام حلول Aiforia عبر AISight Marketplace يحتاج طلب مستندات محددة. أولها intended use لكل نموذج، ونوع العينات والصبغات المدعومة، وحدود العمل مع tissue artifacts. ثانيها خطة local validation على شرائح من المختبر نفسه، لأن اختلاف fixation، scanner، staining protocol، وcase mix قد يغير الأداء العملي.
ثالثها سياسة التحديث. عندما يتغير model version، يحتاج القسم إلى معرفة ما تغير، وهل يتطلب ذلك إعادة تحقق محلية. في المختبرات التي تستخدم WSI للتشخيص الأولي، أي تحديث غير موثق قد يربك ثقة الأطباء في النتائج السابقة واللاحقة. النسخة، التاريخ، وسبب التغيير يجب أن تظهر في سجل يمكن مراجعته.
رابعها طريقة الدعم. إذا فشل تشغيل النموذج على batch كبير، أو ظهر delay في processing، أو اختلفت النتيجة بين viewer وLIS، من يتحمل الحل؟ وجود عقد واحد أو دعم موحد عبر المنصة قد يكون مفيدا، لكن القسم يحتاج تعريف SLA واضحا، خصوصا إذا كان الناتج مرتبطا بوقت توقيع الحالات.
الفرصة وحدودها
شراكة Aiforia وPathAI تشير إلى اتجاه مهم في السوق: المختبرات تفضّل أدوات AI تظهر في مكان العمل نفسه، مع ربط بالنظام، سجل واضح، ودعم يمكن محاسبته، بدلا من جزر منفصلة. هذا مناسب لطبيب الباثولوجي لأنه يقلل الاحتكاك بين قراءة الشريحة واستخدام الخوارزمية.
لكن سهولة الوصول تختلف عن سهولة الاعتماد. marketplace قد يجعل شراء النموذج وتشغيله أسرع، أما الثقة الطبية فتحتاج تحقق محلي، تعليمات استخدام مفهومة، مراجعة حالات فاشلة، وتدريب الأطباء على متى يقبلون المخرج ومتى يرفضونه. هذا هو الفرق بين AI يظهر في قائمة الأدوات وAI يدخل فعلا في sign-out workflow.
للمختبرات في منطقتنا، النقطة الأهم هي البدء من مشكلة تشغيلية واضحة. هل نحتاج تقليل وقت quantification؟ هل نحتاج توحيد قراءة biomarker معين؟ هل نحتاج ترتيب الحالات التي تتطلب مراجعة أسرع؟ إذا بدأ القرار من هذه الأسئلة، يصبح اختيار النموذج والمنصة جزءا من خطة عمل قابلة للقياس، بدلا من إضافة تقنية إلى قسم مزدحم.