Epic کا سیپسس الرٹ انجن (Sepsis-alert engine) 2021 میں Michigan Medicine میں ہونے والی ایک ویلیڈیشن میں ناکام رہا، جس میں اس نے ان مریضوں میں سے دو تہائی کو نظر انداز کر دیا جن میں بعد میں سیپسس کی علامات ظاہر ہوئیں، جبکہ تمام داخل ہونے والے مریضوں میں سے 18 فیصد کے لیے یہ بلاوجہ الرم بجاتا رہا۔ یہ غلطی ایک کلاسیکی ڈیٹا لیکج (data-leakage) کی غلطی کی طرف اشارہ کرتی ہے: ماڈل نے ڈاکٹر کے اینٹی بائیوٹک آرڈر کو ایک پیش گوئی (predictor) کے طور پر شمار کیا—جو کہ پہلے سے ہی اس بات کی علامت ہے کہ انفیکشن کا شبہ ہے—جو کہ بنیادی طور پر اسی فیصلے کی بازگشت تھی جو طبیب پہلے ہی لے چکا تھا۔
ماڈل کیوں ناکام ہوا
Michigan کی ٹیم نے 38,455 ہسپتال میں قیاموں کا جائزہ لیا، جو کہ ایک عام کئی سالہ کوالٹی امپروومنٹ پروجیکٹ کے برابر ہے۔ Epic کے اندرونی معیار (benchmarks) نے اعلیٰ درستگی کا وعدہ کیا تھا، لیکن آزادانہ ٹیسٹ نے اس کے برعکس نتائج دکھائے۔ ماڈل کے "ہائی رسک" الرٹس تقریباً پانچ میں سے ایک مریضوں میں بج اٹھے، لیکن سیپسس کے حقیقی کیسز میں سے دو تہائی نظر انداز ہو گئے۔ عملی طور پر، سسٹم نے بہت زیادہ بار "احتیاط کریں" کی پکار لگائی جبکہ ان واقعات کو پکڑنے میں ناکام رہا جنہیں پکڑنے کے لیے اسے بنایا گیا تھا۔
اس کی بنیادی وجہ مشین لرننگ الگورتھم میں کوئی نقص نہیں تھا بلکہ وہ ڈیٹا تھا جو اس میں ڈالا گیا تھا۔ اینٹی بائیوٹک آرڈر کی موجودگی کو بطور ان پٹ استعمال کر کے، ماڈل نے طبیب کے پہلے سے کیے گئے فیصلے کی پیش گوئی کرنا سیکھ لیا۔ جب الگورتھم نے کسی مریض کو فلیگ کیا، تو وہ اکثر اس لیے کرتا تھا کیونکہ ڈاکٹر پہلے ہی اینٹی بائیوٹکس کا آرڈر دے چکا تھا، نہ کہ اس لیے کہ مریض کی جسمانی حالت (physiology) سیپسس کے قریب ہونے کا اشارہ دے رہی تھی۔
ہسپتالوں کے AI میں ایک وسیع تر مسئلہ
Epic کا سیپسس ماڈل برسوں سے سینکڑوں ہسپتالوں میں استعمال ہو رہا ہے، لیکن ڈیٹا لیکج کی یہ غلطی تب تک چھپی رہی جب تک کہ ایک توجہ مرکوز ویلیڈیشن کوشش نے اسے سامنے نہیں لایا۔ یہ واقعہ ایک نظامی کمزوری (systemic weakness) کو ظاہر کرتا ہے: زیادہ تر ہیلتھ سسٹم AI پروجیکٹس میں ایسے آپریشنل چیکس کی کمی ہوتی ہے جو ایسے مسائل کو جلد پکڑ سکیں۔
- کوئی بیرونی ٹیسٹنگ نہیں – ہسپتالوں کے پاس کوئی بیرونی ٹیسٹنگ نہیں تھی۔
- کوئی مسلسل نگرانی نہیں – ان کے پاس کوئی مانیٹرنگ نہیں تھی۔
- کوئی واضح ذمہ داری نہیں – ڈیٹا کے معیار اور ماڈل کی کارکردگی کے لیے ایک نامزد ٹیم کے بغیر، مسائل نظر انداز ہو جاتے ہیں۔
یہ خامیاں بہت سے AI اقدامات کو "پائلٹ پرگیٹری" (pilot purgatory) میں پھنسا دیتی ہیں، جہاں وہ کبھی بھی پروف آف کانسیپٹ (proof-of-concept) کے مرحلے سے آگے نہیں بڑھ پاتے۔
بکھرے ہوئے ڈیٹا کی پوشیدہ قیمت
سیپسس کا یہ کیس یہ بھی ظاہر کرتا ہے کہ کس طرح بکھرے ہوئے ہیلتھ-آئی ٹی (health-IT) ایکو سسٹم AI کو نقصان پہنچاتے ہیں۔ عام رکاوٹوں میں شامل ہیں:
- مریضوں کے ریکارڈ ایسے پرانے EHR ماڈیولز میں بند ہیں جو ڈیٹا کا خودکار تبادلہ نہیں کرتے۔
- امیجنگ اور لیبارٹری کے نظام جو ایک دوسرے سے بات نہیں کر سکتے، جس کی وجہ سے فائلوں کو دستی طور پر منتقل کرنا پڑتا ہے۔
- مریضوں کے دوہرے شناختی نمبر جو ایک ہی شخص کے ڈیٹا کو متعدد چارٹس میں تقسیم کر دیتے ہیں۔
- کلینیکل نوٹس اور وائٹل سائنز الگ الگ حصوں (silos) میں محفوظ ہوتے ہیں، جنہیں ماڈل کی ٹریننگ کے لیے کبھی یکجا نہیں کیا جاتا۔
جب ایک ماڈل کو صاف ستھرے اور ترتیب شدہ ڈیٹا سیٹ پر تربیت دی جاتی ہے لیکن پھر اسے لائیو اور بکھرے ہوئے ڈیٹا کے ذریعے چلایا جاتا ہے، تو اس کی کارکردگی خاموشی سے گر جاتی ہے۔ طبیبوں کا اعتماد تیزی سے ختم ہو جاتا ہے؛ ایک نرس جسے متعدد اسکرینوں کے ذریعے الرٹس کا پیچھا کرنا پڑے گا، وہ انہیں نظر انداز کر دے گی، چاہے بنیادی الگورتھم تکنیکی طور پر کتنا ہی درست کیوں نہ ہو۔
قابل اعتماد AI کے لیے چار "بورنگ" بنیادیں
ایک فعال AI کا استعمال چار عملی صلاحیتوں پر منحصر ہے جو شاذ و نادر ہی شہرت پاتی ہیں:
- انٹر آپریبلٹی (Interoperability) – ڈیٹا کو EHRs، لیبز، امیجنگ پلیٹ فارمز اور فیصلہ سازی کے ٹولز کے درمیان دستی ایکسپورٹ-امپورٹ کے بغیر بہنا چاہیے۔
- گورننس (Governance) – ایک ذمہ دار شخص یا ٹیم کو ڈیٹا کے معیار کا مالک ہونا چاہیے اور وقت کے ساتھ ساتھ ماڈل کے نتائج کی نگرانی کرنی چاہیے۔
- ورک فلو انٹیگریشن (Workflow integration) – الرٹس کو طبیب کے موجودہ ورک کیو (work queue) کے اندر نظر آنا چاہیے؛ اضافی کلکس یا اسکرینز اسے اپنانے کے عمل کو روک دیتے ہیں۔
- اسکیل ایبل آپریشنز (Scalable operations) – ماڈل کے پروڈکشن میں پہنچنے سے پہلے خودکار نگرانی، الرٹ تھکاوٹ (alert-fatigue) کا تجزیہ، اور وقتاً فوقتاً ری ٹریننگ پائپ لائنز ضروری ہیں۔
ان میں سے کسی بھی مرحلے کو چھوڑنا کسی پروجیکٹ کو اسی طرح کی خاموش ناکامی کے خطرے میں ڈال دیتا ہے جیسا کہ Epic کے سیپسس ماڈل میں دیکھا گیا۔
AI حل خریدنے سے پہلے پوچھے جانے والے سوالات
ہسپتال ٹھوس جوابات کا مطالبہ کر کے مہنگی غلطیوں سے بچ سکتے ہیں:
- کیا آپ ایک ہی مریض کے ڈیٹا کا سراغ ہر اس سسٹم میں لگا سکتے ہیں جسے ماڈل استعمال کرے گا؟
- ڈیٹا کے معیار کو برقرار رکھنے اور ماڈل کی کارکردگی کی نگرانی کرنے کے لیے نام کے ساتھ کون ذمہ دار ہے؟
- کیا الرٹس کا تجربہ طبیبوں کے ساتھ حقیقی شفٹ کے دوران کیا گیا ہے، نہ کہ صرف ایک سینڈ باکس (sandbox) ماحول میں؟
- کیا وہاں مانیٹرنگ کا کوئی دستاویزی منصوبہ موجود ہے جو یہ بتاتا ہو کہ کارکردگی میں تبدیلی (performance drift) کی نشاندہی اور اس کا حل کیسے نکالا جائے گا؟
اگر وینڈر کسی شخص، عمل، یا مانیٹرنگ ڈیش بورڈ کی نشاندہی نہیں کر سکتا، تو تنظیم کو رک جانا چاہیے اور دوبارہ جائزہ لینا چاہیے۔
خلاصہ
Epic sepsis ماڈل اس لیے ناکام نہیں ہوا کہ مشین لرننگ ہسپتالوں کے لیے موزوں نہیں ہے؛ بلکہ یہ اس لیے ناکام ہوا کیونکہ اس کے گرد ڈیٹا پائپ لائن اور گورننس کے ڈھانچے موجود نہیں تھے۔ ایک ایسا ماڈل جو ڈاکٹر کے اپنے فیصلے کی پیش گوئی کرتا ہے، یہ خبردار کرتا ہے کہ ڈیٹا انجینئرنگ کی تہہ (layer) کو کام کرنے کی ضرورت ہے، نہ کہ الگورتھم کو۔ صحت کی دیکھ بھال میں قابلِ اعتماد AI کی تعمیر کے لیے اسی "بورنگ" انفراسٹرکچر کی ضرورت ہوتی ہے جو کسی بھی اہم IT سسٹم کو چلائے رکھتا ہے: صاف ستھرا اور مربوط ڈیٹا، واضح جوابدہی، ورک فلو میں شامل الرٹس، اور فعال نگرانی۔ ان کے بغیر، انتہائی جدید ترین ماڈل بھی غلط لوگوں کو غلط وارننگز دینے کے سوا کچھ نہیں کر پائے گا۔