Epic-এর সেপসিস-অ্যালার্ট ইঞ্জিন ২০২১ সালে Michigan Medicine-এ একটি যাচাইকরণে (validation) ব্যর্থ হয়েছে; এটি সেই সমস্ত রোগীদের দুই-তৃতীয়াংশ শনাক্ত করতে ব্যর্থ হয়েছে যাদের পরবর্তীতে সেপসিস হয়েছিল, অথচ মোট ভর্তির ১৮% ক্ষেত্রে এটি অ্যালার্ম বাজিয়েছিল। এই ভুলটি একটি ধ্রুপদী ডেটা-লিকেজ (data-leakage) ত্রুটির দিকে নির্দেশ করে: মডেলটি একজন চিকিৎসকের অ্যান্টিবায়োটিক অর্ডারকে—যা ইতিমধ্যে সংক্রমণের সন্দেহের একটি লক্ষণ—একটি প্রেডিক্টর (predictor) হিসেবে গণনা করেছিল, যা মূলত চিকিৎসকের নেওয়া সিদ্ধান্তকেই কেবল পুনরাবৃত্তি করছিল।
মডেলটি কেন ব্যর্থ হয়েছিল
Michigan-এর দল ৩৮,৪৫৫টি হাসপাতালে ভর্তির ঘটনা পরীক্ষা করেছে, যা একটি সাধারণ বহুবর্ষব্যাপী মানোন্নয়ন প্রকল্পের (quality-improvement project) আকারের সমান। Epic-এর অভ্যন্তরীণ বেঞ্চমার্কগুলো উচ্চ নির্ভুলতার প্রতিশ্রুতি দিলেও, স্বাধীন পরীক্ষা তার উল্টোটা দেখিয়েছে। মডেলটির "উচ্চ-ঝুঁকি" (high-risk) অ্যালার্ট প্রায় এক-পঞ্চমাংশ রোগীর ক্ষেত্রে সক্রিয় হয়েছিল, তবুও প্রকৃত সেপসিস আক্রান্ত রোগীদের দুই-তৃতীয়াংশ নজর এড়িয়ে গেছে। বাস্তবে, সিস্টেমটি যে ঘটনাগুলো ধরার কথা ছিল সেগুলো মিস করে বারবার "সাবধান" বলে চিৎকার করছিল।
মূল কারণটি মেশিন-লার্নিং অ্যালগরিদমের কোনো ত্রুটি ছিল না, বরং এতে সরবরাহ করা ডেটা ছিল। অ্যান্টিবায়োটিক অর্ডারের উপস্থিতি ইনপুট হিসেবে ব্যবহার করার ফলে, মডেলটি একজন চিকিৎসকের ইতিমধ্যে নেওয়া সিদ্ধান্তটিকেই অনুমান করতে শিখে ফেলেছিল। যখন অ্যালগরিদম কোনো রোগীকে ফ্ল্যাগ করত, তখন সেটি প্রায়শই এজন্যই করত কারণ ডাক্তার ইতিমধ্যে অ্যান্টিবায়োটিক অর্ডার করেছিলেন, রোগীর শারীরিক অবস্থা আসন্ন সেপসিস নির্দেশ করছিল বলে নয়।
হাসপাতাল এআই (AI)-তে একটি বৃহত্তর সমস্যা
Epic-এর সেপসিস মডেলটি বছরের পর বছর ধরে শত শত হাসপাতালে মোতায়েন করা হয়েছে, তবুও এই লিকেজ ত্রুটিটি ততক্ষণ পর্যন্ত লুকিয়ে ছিল যতক্ষণ না একটি নিবিড় যাচাইকরণ প্রচেষ্টা এটি সামনে এনেছে। এই ঘটনাটি একটি পদ্ধতিগত দুর্বলতা প্রকাশ করে: বেশিরভাগ হেলথ-সিস্টেম এআই (AI) প্রকল্পের এমন অপারেশনাল চেক (operational checks) থাকে না যা এই ধরনের সমস্যাগুলো দ্রুত ধরতে পারে।
- কোনো বাহ্যিক পরীক্ষা নেই – হাসপাতালগুলোর কোনো বাহ্যিক পরীক্ষা ছিল না।
- কোনো চলমান পর্যবেক্ষণ নেই – তাদের কোনো পর্যবেক্ষণ ব্যবস্থা ছিল না।
- কোনো স্পষ্ট মালিকানা নেই – ডেটা কোয়ালিটি এবং মডেল পারফরম্যান্সের জন্য কোনো নির্দিষ্ট দল বা দায়িত্ব না থাকায় সমস্যাগুলো সমাধান না হয়েই থেকে যায়।
এই ঘাটতিগুলোর কারণে অনেক এআই (AI) উদ্যোগ "পাইলট পারগেটরি" (pilot purgatory)-তে আটকে থাকে, যা কখনোই প্রুফ-অফ-কনসেপ্ট (proof-of-concept) পর্যায়ের বাইরে যেতে পারে না।
খণ্ডিত ডেটার লুকানো খরচ
সেপসিসের এই ঘটনাটি আরও দেখায় যে কীভাবে খণ্ডিত হেলথ-আইটি (health-IT) ইকোসিস্টেম এআই (AI)-কে বাধাগ্রস্ত করে। সাধারণ বাধাগুলোর মধ্যে রয়েছে:
- লিগ্যাসি EHR মডিউলে আটকে থাকা রোগীর রেকর্ড যা স্বয়ংক্রিয়ভাবে ডেটা আদান-প্রদান করতে পারে না।
- ইমেজিং এবং ল্যাবরেটরি সিস্টেম যা একে অপরের সাথে যোগাযোগ করতে পারে না, ফলে ম্যানুয়াল ফাইল ট্রান্সফার করতে হয়।
- ডুপ্লিকেট পেশেন্ট আইডেন্টিফায়ার যা একজন ব্যক্তির ডেটাকে একাধিক চার্টের মধ্যে বিভক্ত করে ফেলে।
- ক্লিনিকাল নোট এবং ভাইটাল সাইনগুলো আলাদা সাইলোতে (silos) সংরক্ষিত থাকে, যা মডেল প্রশিক্ষণের জন্য কখনোই একত্রিত করা হয় না।
যখন একটি মডেলকে একটি পরিচ্ছন্ন ও কিউরেটেড ডেটাসেটের ওপর প্রশিক্ষণ দেওয়া হয় কিন্তু পরে যখন এতে লাইভ ও অগোছালো ডেটা সরবরাহ করা হয়, তখন এর পারফরম্যান্স নিঃশব্দে হ্রাস পায়। চিকিৎসকরা দ্রুত আস্থা হারিয়ে ফেলেন; একজন নার্স যাকে একাধিক স্ক্রিনের মাধ্যমে অ্যালার্ট খুঁজতে হয়, তিনি সেগুলো উপেক্ষা করবেন, এমনকি যদি অন্তর্নিহিত অ্যালগরিদমটি প্রযুক্তিগতভাবে সঠিকও হয়।
নির্ভরযোগ্য এআই (AI)-এর জন্য চারটি "একঘেয়ে" ভিত্তি
একটি কার্যকর এআই (AI) মোতায়েন চারটি ব্যবহারিক সক্ষমতার ওপর নির্ভর করে যা খুব কমই শিরোনামে আসে:
- ইন্টারঅপারেবিলিটি (Interoperability) – ম্যানুয়াল এক্সপোর্ট-ইম্পোর্ট ধাপ ছাড়াই EHR, ল্যাব, ইমেজিং প্ল্যাটফর্ম এবং ডিসিশন-সাপোর্ট টুলের মধ্যে ডেটা প্রবাহিত হতে হবে।
- গভর্ন্যান্স (Governance) – একজন দায়বদ্ধ ব্যক্তি বা দলকে ডেটা কোয়ালিটির মালিকানা নিতে হবে এবং সময়ের সাথে সাথে মডেলের আউটপুট পর্যবেক্ষণ করতে হবে।
- ওয়ার্কফ্লো ইন্টিগ্রেশন (Workflow integration) – অ্যালার্টগুলো চিকিৎসকের বিদ্যমান কাজের তালিকার (work queue) মধ্যেই উপস্থিত হতে হবে; অতিরিক্ত ক্লিক বা স্ক্রিন ব্যবহারের বাধ্যবাধকতা গ্রহণ কমিয়ে দেয়।
- স্কেলেবল অপারেশনস (Scalable operations) – মডেলটি প্রোডাকশনে পৌঁছানোর আগে স্বয়ংক্রিয় পর্যবেক্ষণ, অ্যালার্ট-ফ্যাটিগ অ্যানালাইসিস এবং পর্যায়ক্রমিক রিট্রেনিং পাইপলাইন অপরিহার্য।
এই ধাপগুলোর যেকোনো একটি বাদ দিলে প্রকল্পটি Epic-এর সেপসিস মডেলের মতো নীরব ব্যর্থতার শিকার হতে পারে।
এআই (AI) সমাধান কেনার আগে যে প্রশ্নগুলো করা উচিত
হাসপাতালগুলো সুনির্দিষ্ট উত্তর দাবি করার মাধ্যমে ব্যয়বহুল ভুল এড়াতে পারে:
- মডেলটি যে সমস্ত সিস্টেম ব্যবহার করবে, তার প্রতিটি সিস্টেম জুড়ে আপনি কি একজন রোগীর ডেটা ট্র্যাক করতে পারেন?
- ডেটা কোয়ালিটি বজায় রাখা এবং মডেল পারফরম্যান্স তদারকি করার জন্য নির্দিষ্টভাবে কার নাম দায়ী?
- অ্যালার্টগুলো কি কেবল একটি স্যান্ডবক্স এনভায়রনমেন্টে (sandbox environment) নয়, বরং বাস্তব ডিউটির সময় চিকিৎসকদের সাথে পরীক্ষা করা হয়েছে?
- সেখানে কি একটি নথিভুক্ত মনিটরিং প্ল্যান আছে যা নির্দিষ্ট করে বলে যে পারফরম্যান্স ড্রিফট (performance drift) কীভাবে শনাক্ত এবং সমাধান করা হবে?
যদি ভেন্ডর কোনো ব্যক্তি, প্রক্রিয়া বা মনিটরিং ড্যাশবোর্ডের কথা উল্লেখ করতে না পারে, তবে সংস্থার উচিত কার্যক্রম স্থগিত করা এবং পুনরায় মূল্যায়ন করা।
সারসংক্ষেপ
Epic সেপসিস মডেলটি ব্যর্থ হয়নি কারণ মেশিন লার্নিং হাসপাতালের জন্য অনুপযুক্ত; বরং এটি ব্যর্থ হয়েছে কারণ এর সাথে সংশ্লিষ্ট ডেটা পাইপলাইন এবং গভর্নেন্স কাঠামো অনুপস্থিত ছিল। একটি মডেল যা একজন চিকিৎসকের নিজস্ব সিদ্ধান্তই অনুমান করে, তা আসলে সতর্ক করে দিচ্ছে যে অ্যালগরিদম নয়, বরং ডেটা-ইঞ্জিনিয়ারিং লেয়ারের উন্নতি প্রয়োজন। স্বাস্থ্যসেবায় নির্ভরযোগ্য AI তৈরি করতে সেই একই "একঘেয়ে" অবকাঠামোর প্রয়োজন যা যেকোনো গুরুত্বপূর্ণ আইটি সিস্টেমকে সচল রাখে: পরিচ্ছন্ন ও সংযুক্ত ডেটা, স্পষ্ট জবাবদিহিতা, কাজের প্রবাহের (workflow) সাথে যুক্ত অ্যালার্ট এবং প্রোঅ্যাক্টিভ মনিটরিং। এগুলো ছাড়া, এমনকি সবচেয়ে উন্নত মডেলটিও ভুল মানুষের কাছে ভুল সতর্কতা প্রদান করবে।