Epic का सेप्सिस-अलर्ट इंजन Michigan Medicine में 2021 के एक सत्यापन (validation) में विफल रहा, जिसमें उसने उन दो-तिहाई मरीजों को पहचानने में चूक कर दी जिन्हें बाद में सेप्सिस हो गया, जबकि उसने कुल प्रवेशों (admissions) में से 18% के लिए गलत अलार्म बजाए। यह चूक एक क्लासिक डेटा-लीकेज त्रुटि (data-leakage error) की ओर इशारा करती है: मॉडल ने डॉक्टर के एंटीबायोटिक ऑर्डर को एक प्रेडिक्टर (predictor) के रूप में गिना—जो कि पहले से ही इस बात का संकेत है कि संक्रमण का संदेह है—essentially उस निर्णय को ही दोहरा रहा था जो चिकित्सक पहले ही ले चुका था।
मॉडल क्यों विफल हुआ
Michigan की टीम ने 38,455 अस्पताल प्रवासों (hospital stays) की जांच की, जो कि एक विशिष्ट बहु-वर्षीय गुणवत्ता-सुधार परियोजना के आकार के बराबर है। Epic के आंतरिक बेंचमार्क ने उच्च सटीकता का वादा किया था, लेकिन स्वतंत्र परीक्षण ने इसके विपरीत परिणाम दिखाए। मॉडल के "उच्च-जोखिम" (high-risk) अलर्ट लगभग पांच में से एक मरीज में सक्रिय हुए, फिर भी दो-तिहाई वास्तविक सेप्सिस मामले बिना ध्यान दिए निकल गए। व्यवहार में, सिस्टम ने बहुत बार "सावधान" रहने की चेतावनी दी, जबकि उन घटनाओं को पकड़ने में विफल रहा जिन्हें पकड़ने के लिए इसे बनाया गया था।
इसका मूल कारण मशीन-लर्निंग एल्गोरिदम में कोई खामी नहीं थी, बल्कि उसमें फीड किया गया डेटा था। एंटीबायोटिक ऑर्डर की उपस्थिति को इनपुट के रूप में उपयोग करके, मॉडल ने चिकित्सक के पहले से लिए जा चुके निर्णय का अनुमान लगाना सीख लिया। जब एल्गोरिदम ने किसी मरीज को फ्लैग किया, तो वह अक्सर इसलिए कर रहा था क्योंकि डॉक्टर ने पहले ही एंटीबायोटिक्स का ऑर्डर दे दिया था, न कि इसलिए कि मरीज की शारीरिक स्थिति (physiology) आसन्न सेप्सिस का संकेत दे रही थी।
अस्पताल AI में एक व्यापक समस्या
Epic का सेप्सिस मॉडल वर्षों से सैकड़ों अस्पतालों में तैनात है, फिर भी लीकेज त्रुटि तब तक छिपी रही जब तक कि एक केंद्रित सत्यापन प्रयास ने इसे सामने नहीं लाया। यह घटना एक प्रणालीगत कमजोरी को दर्शाती है: अधिकांश हेल्थ-सिस्टम AI परियोजनाओं में ऐसी समस्याओं को जल्दी पकड़ने के लिए आवश्यक परिचालन जांच (operational checks) की कमी होती है।
- कोई बाहरी परीक्षण नहीं – अस्पतालों के पास कोई बाहरी परीक्षण नहीं था।
- कोई निरंतर निगरानी नहीं – उनके पास कोई निगरानी नहीं थी।
- कोई स्पष्ट स्वामित्व नहीं – डेटा गुणवत्ता और मॉडल प्रदर्शन के लिए जिम्मेदार एक नामित टीम के बिना, मुद्दे अनसुने रह जाते हैं।
ये कमियां कई AI पहलों को "पायलट पर्गेटरी" (pilot purgatory - पायलट चरण की अनिश्चितता) में फंसाए रखती हैं, जो कभी भी प्रूफ-ऑफ-कांसेप्ट चरण से आगे नहीं बढ़ पातीं।
खंडित डेटा की छिपी हुई लागत
सेप्सिस का मामला यह भी दिखाता है कि कैसे खंडित (fragmented) हेल्थ-IT इकोसिस्टम AI को बाधित करते हैं। सामान्य बाधाओं में शामिल हैं:
- पेशेंट रिकॉर्ड पुराने EHR मॉड्यूल में बंद होना जो डेटा को स्वचालित रूप से साझा नहीं करते हैं।
- इमेजिंग और प्रयोगशाला प्रणालियाँ जो एक-दूसरे से बात नहीं कर सकतीं, जिससे मैन्युअल फाइल ट्रांसफर करना पड़ता है।
- डुप्लिकेट पेशेंट आइडेंटिफायर जो एक ही व्यक्ति के डेटा को कई चार्टों में विभाजित कर देते हैं।
- क्लिनिकल नोट्स और वाइटल साइन्स अलग-अलग साइलो (silos) में संग्रहीत होते हैं, जिन्हें मॉडल प्रशिक्षण के लिए कभी मर्ज नहीं किया जाता है।
जब किसी मॉडल को एक स्वच्छ, क्यूरेटेड डेटासेट पर प्रशिक्षित किया जाता है लेकिन फिर उसे लाइव, अव्यवस्थित डेटा दिया जाता है, तो उसका प्रदर्शन चुपचाप गिरने लगता है। चिकित्सक जल्दी ही भरोसा खो देते हैं; एक नर्स जिसे कई स्क्रीन के माध्यम से अलर्ट का पीछा करना पड़ता है, वह उन्हें अनदेखा कर देगी, भले ही अंतर्निहित एल्गोरिदम तकनीकी रूप से सही क्यों न हो।
विश्वसनीय AI के लिए चार "उबाऊ" आधार
एक कार्यात्मक AI परिनियोजन (deployment) चार व्यावहारिक क्षमताओं पर टिका होता है जो शायद ही कभी सुर्खियों में आते हैं:
- इंटरऑपरेबिलिटी (Interoperability) – डेटा को बिना किसी मैन्युअल एक्सपोर्ट-इंपोर्ट चरणों के EHRs, लैब, इमेजिंग प्लेटफॉर्म और निर्णय-सहायता उपकरणों के बीच प्रवाहित होना चाहिए।
- गवर्नेंस (Governance) – एक जवाबदेह व्यक्ति या टीम को डेटा गुणवत्ता का स्वामित्व लेना चाहिए और समय के साथ मॉडल आउटपुट की निगरानी करनी चाहिए।
- वर्कफ़्लो इंटीग्रेशन (Workflow integration) – अलर्ट को चिकित्सक के मौजूदा वर्क क्यू (work queue) के भीतर दिखाई देने चाहिए; अतिरिक्त क्लिक या स्क्रीन अपनाने की दर को कम कर देते हैं।
- स्केलेबल ऑपरेशंस (Scalable operations) – मॉडल के प्रोडक्शन में पहुँचने से पहले स्वचालित निगरानी, अलर्ट-फटीग (alert-fatigue) विश्लेषण और आवधिक रिट्रेनिंग पाइपलाइन आवश्यक हैं।
इनमें से किसी भी चरण को छोड़ना किसी प्रोजेक्ट को उसी तरह की मौन विफलता के प्रति संवेदनशील बना देता है जैसा कि Epic सेप्सिस मॉडल में देखा गया।
AI समाधान खरीदने से पहले पूछने वाले प्रश्न
अस्पताल ठोस उत्तरों की मांग करके महंगी गलतियों से बच सकते हैं:
- क्या आप मॉडल द्वारा उपयोग किए जाने वाले प्रत्येक सिस्टम में एक एकल मरीज के डेटा को ट्रैक कर सकते हैं?
- डेटा गुणवत्ता बनाए रखने और मॉडल प्रदर्शन की देखरेख के लिए नाम के साथ कौन जिम्मेदार है?
- क्या अलर्ट का परीक्षण वास्तविक शिफ्ट के दौरान चिकित्सकों के साथ किया गया है, न कि केवल एक सैंडबॉक्स एनवायरनमेंट में?
- क्या कोई दस्तावेजीकृत निगरानी योजना है जो यह निर्दिष्ट करती है कि परफॉरमेंस ड्रिफ्ट (performance drift) की पहचान और समाधान कैसे किया जाएगा?
यदि विक्रेता किसी व्यक्ति, प्रक्रिया या निगरानी डैशबोर्ड की ओर इशारा नहीं कर सकता है, तो संगठन को रुकना चाहिए और पुनर्मूल्यांकन करना चाहिए।
निष्कर्ष (The take-away)
Epic सेप्सिस मॉडल इसलिए विफल नहीं हुआ क्योंकि मशीन लर्निंग अस्पतालों के लिए अनुपयुक्त है; बल्कि यह इसलिए विफल हुआ क्योंकि इसके साथ जुड़ी डेटा पाइपलाइन और गवर्नेंस संरचनाओं का अभाव था। एक ऐसा मॉडल जो डॉक्टर के स्वयं के निर्णय की भविष्यवाणी करता है, यह चेतावनी देता है कि एल्गोरिदम को नहीं, बल्कि डेटा-इंजीनियरिंग लेयर को सुधारने की आवश्यकता है। स्वास्थ्य सेवा में भरोसेमंद AI बनाने के लिए उसी "उबाऊ" बुनियादी ढांचे की आवश्यकता होती है जो किसी भी महत्वपूर्ण IT सिस्टम को सुचारू रूप से चलाने के लिए जरूरी है: स्वच्छ और आपस में जुड़े डेटा, स्पष्ट जवाबदेही, वर्कफ्लो में समाहित अलर्ट, और सक्रिय निगरानी। इनके बिना, सबसे परिष्कृत मॉडल भी अंततः गलत लोगों को गलत चेतावनियाँ ही देता रहेगा।