موتور هشدار سپسیس (Sepsis-alert) شرکت Epic در یک ارزیابی در سال ۲۰۲۱ در Michigan Medicine شکست خورد؛ این موتور دو-سوم بیمارانی را که بعداً دچار سپسیس شدند شناسایی نکرد، در حالی که برای ۱۸٪ از کل موارد بستری، هشدار بی‌مورد صادر می‌کرد. این اشتباه به یک خطای کلاسیک «نشت داده» (data-leakage) بازمی‌گردد: مدل، دستور تجویز آنتی‌بیوتیک توسط پزشک را — که خود نشانه‌ای از شک به عفونت است — به عنوان یک پیش‌بینی‌کننده در نظر گرفته بود و در واقع صرفاً تصمیمی را بازتاب می‌داد که پزشک پیش‌تر گرفته بود.

چرا مدل شکست خورد

تیم میشیگان ۳۸,۴۵۵ مورد بستری در بیمارستان را بررسی کرد که اندازه یک پروژه معمول بهبود کیفیت چندساله است. شاخص‌های داخلی Epic وعده دقت بالایی را می‌دادند، اما تست مستقل نتیجه‌ای برعکس نشان داد. هشدارهای «پرخطر» مدل در تقریباً یک‌پنجم بیماران فعال می‌شد، اما دو-سوم موارد واقعی سپسیس بدون شناسایی باقی ماندند. در عمل، سیستم بسیار بیش از حد فریاد می‌زد «مراقب باش»، در حالی که دقیقاً همان رویدادهایی را که قرار بود شناسایی کند، از دست می‌داد.

علت اصلی، نقص در خودِ الگوریتم یادگیری ماشین نبود، بلکه داده‌هایی بود که به آن تغذیه می‌شد. مدل با استفاده از وجود دستور آنتی‌بیوتیک به عنوان یک ورودی، یاد گرفته بود که انتخابِ از پیش گرفته شده توسط پزشک را پیش‌بینی کند. وقتی الگوریتم بیماری را علامت‌گذاری می‌کرد، اغلب به این دلیل بود که پزشک قبلاً آنتی‌بیوتیک تجویز کرده بود، نه به این دلیل که فیزیولوژی بیمار نشان‌دهنده سپسیس قریب‌الوقوع بود.

مشکلی گسترده‌تر در هوش مصنوعی بیمارستانی

مدل سپسیس Epic سال‌هاست که در صدها بیمارستان مستقر شده است، اما خطای نشت داده تا زمانی که یک تلاش ارزیابی متمرکز آن را آشکار نکرد، پنهان مانده بود. این اتفاق نشان‌دهنده یک ضعف سیستماتیک است: اکثر پروژه‌های هوش مصنوعی در سیستم‌های سلامت، فاقد بررسی‌های عملیاتی لازم برای شناسایی زودهنگام چنین مشکلاتی هستند.

  • عدم انجام تست‌های خارجی – بیمارستان‌ها هیچ تست خارجی انجام نداده بودند.
  • عدم نظارت مستمر – آن‌ها هیچ نظارتی نداشتند.
  • عدم وجود مالکیت مشخص – بدون وجود تیمی مشخص که مسئول کیفیت داده‌ها و عملکرد مدل باشد، مشکلات از زیر دست می‌لغزند.

این شکاف‌ها باعث می‌شود بسیاری از ابتکارات هوش مصنوعی در «برزخ پروژه‌های آزمایشی» (pilot purgatory) گیر کنند و هرگز از مرحله اثبات مفهوم (proof-of-concept) فراتر نروند.

هزینه پنهان داده‌های پراکنده

مورد سپسیس همچنین نشان می‌دهد که چگونه اکوسیستم‌های پراکنده فناوری اطلاعات سلامت، هوش مصنوعی را مختل می‌کنند. موانع رایج عبارتند از:

  • پرونده‌های بیمار که در ماژول‌های قدیمی EHR قفل شده‌اند و داده‌ها را به طور خودکار تبادل نمی‌کنند.
  • سیستم‌های تصویربرداری و آزمایشگاهی که نمی‌توانند با هم ارتباط برقرار کنند و انتقال دستی فایل‌ها را اجباری می‌کنند.
  • شناسه‌های تکراری بیمار که داده‌های یک فرد واحد را در چندین پرونده تقسیم می‌کند.
  • یادداشت‌های بالینی و علائم حیاتی که در سیلوهای (silos) جداگانه ذخیره شده‌اند و هرگز برای آموزش مدل ادغام نمی‌شوند.

وقتی یک مدل بر روی یک مجموعه داده تمیز و منتخب آموزش می‌بیند اما سپس با داده‌های زنده و نامنظم تغذیه می‌شود، عملکرد آن به صورت بی‌صدا کاهش می‌یابد. پزشکان به سرعت اعتماد خود را از دست می‌دهند؛ پرستاری که مجبور است هشدارها را از میان چندین صفحه نمایش دنبال کند، آن‌ها را نادیده خواهد گرفت، حتی اگر الگوریتم زیربنایی از نظر فنی درست باشد.

چهار پایه «کسل‌کننده» برای هوش مصنوعی قابل اعتماد

یک استقرار کاربردی هوش مصنوعی بر چهار قابلیت عملی استوار است که به ندرت در تیتر اخبار می‌آیند:

  1. تعامل‌پذیری (Interoperability) – داده‌ها باید بین EHRها، آزمایشگاه‌ها، پلتفرم‌های تصویربرداری و ابزارهای پشتیبان تصمیم‌گیری بدون مراحل دستیِ خروجی-ورودی (export-import) جریان یابند.
  2. حاکمیت (Governance) – یک فرد یا تیم مسئول باید مالکیت کیفیت داده‌ها را بر عهده داشته باشد و خروجی‌های مدل را در طول زمان نظارت کند.
  3. ادغام در گردش کار (Workflow integration) – هشدارها باید در صف کاری موجودِ پزشک ظاهر شوند؛ کلیک‌ها یا صفحات اضافی، پذیرش سیستم را از بین می‌برند.
  4. عملیات مقیاس‌پذیر (Scalable operations) – نظارت خودکار، تحلیل خستگی ناشی از هشدار (alert-fatigue) و خط لوله‌های بازآموزی دوره‌ای، پیش از اینکه مدل به مرحله تولید برسد، ضروری هستند.

نادیده گرفتن هر یک از این مراحل، پروژه را در برابر نوعی از شکست‌های بی‌صدا که در مدل سپسیس Epic دیده شد، آسیب‌پذیر می‌کند.

سوالاتی که باید پیش از خرید یک راهکار هوش مصنوعی بپرسید

بیمارستان‌ها می‌توانند با درخواست پاسخ‌های ملموس، از اشتباهات پرهزینه جلوگیری کنند:

  • آیا می‌توانید داده‌های یک بیمار واحد را در تمام سیستم‌هایی که مدل از آن‌ها استفاده خواهد کرد، ردیابی کنید؟
  • چه کسی، با ذکر نام، مسئول حفظ کیفیت داده‌ها و نظارت بر عملکرد مدل است؟
  • آیا هشدارها در طول یک شیفت واقعی با پزشکان آزمایش شده‌اند یا فقط در یک محیط آزمایشی (sandbox)؟
  • آیا یک برنامه نظارتی مستند وجود دارد که مشخص کند انحراف عملکرد (performance drift) چگونه شناسایی و رسیدگی خواهد شد؟

اگر فروشنده نتواند به یک شخص، یک فرآیند یا یک داشبورد نظارتی اشاره کند، سازمان باید مکث کرده و دوباره ارزیابی کند.

نکته کلیدی

مدل sepsis شرکت Epic به این دلیل شکست نخورد که یادگیری ماشین برای بیمارستان‌ها نامناسب است؛ بلکه دلیل شکست آن، نبودِ خط لوله داده‌ها و ساختارهای حاکمیتیِ پیرامون آن بود. مدلی که تصمیمات خودِ پزشک را پیش‌بینی می‌کند، هشدار می‌دهد که این لایه مهندسی داده است که نیاز به اصلاح دارد، نه الگوریتم. ساخت هوش مصنوعی قابل اعتماد در حوزه سلامت، نیازمند همان زیرساخت‌های «کسل‌کننده» است که هر سیستم IT حیاتی را سرپا نگه می‌دارد: داده‌های پاک و متصل، مسئولیت‌پذیری شفاف، هشدارهای ادغام‌شده در جریان کار، و نظارت فعالانه. بدون این موارد، حتی پیچیده‌ترین مدل‌ها نیز در نهایت هشدارهای اشتباه را به افراد اشتباه فریاد خواهند زد.