- Ontario द्वारा healthcare providers के लिए अनुमोदित 20 AI Scribe सिस्टमों में अहम जानकारी छूटना, गलत जानकारी जोड़ना, और ऐसी बातें बना देना जो कही ही नहीं गई थीं, पाया गया
- प्रोक्योरमेंट मूल्यांकन में नकली doctor-patient recordings और AI-जनित clinical notes की medical experts द्वारा तुलना की गई, और 9 सिस्टमों ने treatment plan सुझाव तक गढ़ दिए
- 12 सिस्टमों ने गलत दवा संबंधी जानकारी डाली, और 17 सिस्टमों ने रिकॉर्डिंग में मौजूद मरीज के मानसिक स्वास्थ्य से जुड़ी अहम जानकारी छोड़ दी
- OntarioMD ने डॉक्टरों को AI नोट्स की मैन्युअल समीक्षा करने की सलाह दी, लेकिन अनुमोदित सिस्टमों में accuracy confirmation को अनिवार्य करने वाली सुविधा किसी में नहीं थी
- मूल्यांकन स्कोर में Ontario के भीतर स्थानीय उपस्थिति का वजन 30% था, जबकि medical note accuracy सिर्फ 4% थी; bias control और threat·risk·privacy evaluation को 2%-2% मिला
ऑडिट रिपोर्ट और मूल्यांकन का तरीका
- Canada के Office of the Auditor General of Ontario की public services में AI उपयोग की स्थिति पर रिपोर्ट में Ontario Ministry of Health के AI Scribe प्रोग्राम का मूल्यांकन शामिल है
- यह प्रोग्राम डॉक्टरों, nurse practitioners और अन्य healthcare professionals के लिए AI note-taking tools की खरीद से संबंधित है
- प्रोक्योरमेंट प्रक्रिया में नकली doctor-patient recordings का इस्तेमाल किया गया, और medical experts ने मूल रिकॉर्डिंग और AI-जनित clinical notes की तुलना करके accuracy का आकलन किया
पाई गई गलतियां
- 20 सिस्टमों में से 9 ने रिकॉर्डिंग में चर्चा ही नहीं हुई बातों को गढ़ा और मरीज के treatment plan के सुझाव भी बना दिए
- नमूना रिपोर्टों में “कोई mass नहीं मिला” या “मरीज चिंतित था” जैसी संभावित रूप से गंभीर गलत जानकारी शामिल थी, जबकि ऐसी बातें रिकॉर्डिंग में चर्चा में नहीं थीं
- 20 सिस्टमों में से 12 ने मरीज के नोट्स में गलत दवा संबंधी जानकारी जोड़ी
- 20 सिस्टमों में से 17 ने रिकॉर्डिंग में शामिल मरीज की मानसिक स्वास्थ्य से जुड़ी अहम जानकारी छोड़ दी
- 6 सिस्टमों ने मरीज की मानसिक स्वास्थ्य समस्याओं को पूरी तरह या आंशिक रूप से छोड़ दिया, या अहम विवरण गायब कर दिए
मैन्युअल समीक्षा और सुरक्षा उपाय
- डॉक्टरों को नई तकनीक अपनाने में मदद करने और AI Scribe प्रोक्योरमेंट प्रक्रिया में शामिल OntarioMD ने डॉक्टरों को AI द्वारा बनाए गए नोट्स की accuracy को मैन्युअल रूप से जांचने की सलाह दी
- ऑडिट रिपोर्ट के मुताबिक, अनुमोदित AI Scribe सिस्टमों में से किसी में भी यह अनिवार्य पुष्टि सुविधा नहीं थी कि डॉक्टर ने accuracy की जांच की है
मूल्यांकन वेटेज की समस्या
- कमजोर प्रदर्शन का बड़ा हिस्सा evaluation weighting की समस्या से जुड़ा है
- प्लेटफ़ॉर्म मूल्यांकन स्कोर का 30% Ontario के भीतर स्थानीय उपस्थिति पर दिया गया, जबकि medical notes की accuracy पूरे स्कोर का सिर्फ 4% थी
- Bias control पूरे मूल्यांकन स्कोर का 2% था, threat·risk·privacy evaluation 2% थी, और SOC 2 Type 2 compliance का हिस्सा 4% था
- ऐसे वेटेज का नतीजा ऐसे vendors के चयन में निकल सकता है जो गलत या biased medical records बना सकते हैं, या संवेदनशील personal health information की सुरक्षा के लिए पर्याप्त उपाय नहीं रखते
Ontario स्वास्थ्य मंत्रालय की प्रतिक्रिया
- The Register ने Ontario Health Ministry से रिपोर्ट पर उसकी स्थिति और क्या वह AI Scribe प्रोग्राम संबंधी सिफारिशों का पालन करेगा, इस बारे में पूछा, लेकिन तुरंत कोई जवाब नहीं मिला
- मंत्रालय के एक प्रवक्ता ने बुधवार को CBC से कहा कि Ontario में 5,000 से अधिक डॉक्टर AI Scribe प्रोग्राम में भाग ले रहे हैं, और इस तकनीक से जुड़ी मरीज-हानि की कोई ज्ञात रिपोर्ट नहीं है
1 टिप्पणियां
Hacker News टिप्पणियाँ
मौजूदा AI तकनीक के भविष्य को लेकर मेरा रुख कुल मिलाकर निराशावाद से आशावाद की ओर बदला है, लेकिन मॉडल बहुत आगे बढ़ने के बावजूद बुनियादी तथ्यगत गलतियाँ बनी रहना अब भी बहुत खटकता है
Claude Opus से पसंद और flavor के हिसाब से recipe बनवाओ तो जादू जैसा लगता है, लेकिन जैसे ही वह tablespoon और teaspoon जैसे basic unit conversion में गलती करता है, सारा भरोसा टूट जाता है
यह वैसा एहसास है जैसे किसी फिल्म का किरदार लगभग सामान्य व्यवहार कर रहा हो, फिर अचानक कुछ अजीब लगे और पता चले कि वह zombie था; यह note-writing case भी प्रभावशाली ढंग से लगभग काम करता है, लेकिन अहम details पर फेल हो जाता है
ऐसी विफलताएँ देखकर यह शक और बढ़ता है कि मौजूदा पीढ़ी का AI अच्छे प्रबंधन में बढ़िया काम तो कर सकता है, लेकिन क्या यह वास्तविक बुद्धिमत्ता तक जाने का सही रास्ता है भी या नहीं
AI इंडस्ट्री मानो लगातार यह बात धुंधली करती रहती है कि capability और reliability मूल रूप से अलग गुण हैं। “सटीक” और “भरोसेमंद” को अक्सर एक ही अर्थ में इस्तेमाल किया जाता है, लेकिन कोई मॉडल benchmark अच्छे से पार कर ले, तब भी वह production environment में जोखिम बन सकता है
METR के ताज़ा नतीजे भी capability improvement पर ज़ोरदार प्रतिक्रिया दिखाते हैं, लेकिन कम चर्चा इस बात की होती है कि उसका measurement 50% success rate मानक पर है। 80% success rate वाले supplementary metric में task time range बहुत छोटी हो जाती है: https://metr.org/
मैं enterprise AI systems implement करता हूँ, और 80% reliability तो दूर, 50% reliability स्वीकार करने वाली कोई कंपनी मैंने नहीं देखी
जब LLM लगभग खुद अपने prompt और context डिजाइन करते दिखते हैं, तो नहीं लगता कि उन्हें हमेशा मानव guidance की ज़रूरत रहेगी
जिन सरल, fact-based tasks की एक ठोस methodology होती है, उनके लिए LLM सही tool नहीं है; और ऐसे tasks को पहचानकर अधिक deterministic tools को handoff न कर पाना, मेरी नज़र में harness की failure है
जैसे ज़रूरत पड़ने पर “skills” का इस्तेमाल किया जाता है, वैसे ही कुछ tasks tools या specialized “brains” को सौंपने चाहिए
पहला general intelligence शायद एक single brain नहीं, बल्कि कई LLMs, harnesses, skills, और domain/task-specific subsystems से जुड़ा composite system होगा
Australian tablespoon 4 teaspoons/20mL होता है, जबकि American वाला 3 teaspoons/15mL, इसलिए इस error को कुछ हद तक real-world complexity से समझाया जा सकता है
लेकिन अगर वह 3.14 teaspoons या 2 teaspoons कह रहा हो, तो फिर कहना मुश्किल है
अब वह समस्या लगभग सुलझ चुकी है, और आजकल तो वे ऐसे videos भी बना रहे हैं जिन्हें reality से अलग करना मुश्किल है
इसलिए मुझे विश्वास होता है कि ऐसी सूक्ष्म गलतियाँ भी लगातार घटेंगी और आखिरकार लगभग हर task में पकड़ना मुश्किल हो जाएँगी
प्रेरणा तो मिली, लेकिन उसने बहुत बुनियादी चीज़ें भी गलत समझ लीं। हो सकता है यह मेरी usage skill की समस्या हो, इसलिए मैं पूरी तरह निश्चित नहीं हूँ
हम काम पर meetings के लिए LLM note-taker इस्तेमाल करते हैं, और हाल ही में CIO इतना नाराज़ हो गया कि vendor ने जो वादा किया था उसे निभाया नहीं, इसलिए मुझे बीच में आना पड़ा
CIO उस meeting में था ही नहीं जिसमें वह “वादा” हुआ बताया जा रहा था, लेकिन मैं था; असल में कोई वादा हुआ ही नहीं था, और चर्चा LLM के detailed summary से कहीं ज़्यादा nuanced थी
जब discussion linear नहीं होती, तब भी यह भटक जाता है। उदाहरण के लिए SOC team के साथ recent alerts/incident response पर आगे-पीछे की बात हो, तो यह gist तो पकड़ लेता है, लेकिन अगर आप accuracy पर निर्भर हों, तो यह बहुत बुरी तरह गलत हो सकता है
अस्पताल में पहली nurse visit की तरह chief complaint, weight, height, और recent changes का summary बनाने में यह ठीक हो सकता है, लेकिन doctor के साथ detailed और technical Q&A के लिए मैं इस पर भरोसा नहीं करूँगा
compliance के लिहाज़ से भी, मुझे लगता है अस्पताल edited record से ज़्यादा transcript रखना चाहेंगे, हालांकि पक्का नहीं कह सकता
उस रात माँ ने वापस कॉल किया, थोड़ी बात हुई, फिर उन्होंने सावधानी से पूछा, “तो... क्या तुम्हें मुझे कुछ ज़रूरी बताना था?” और मैं पूरी तरह चौंक गया
बाद में पता चला कि call notification के LLM summary ने उस voicemail के 75% हिस्से, जो बस सामाजिक नरमी और मानवीय cushioning थी, उसे एक ठंडे और ज़रूरत से ज़्यादा औपचारिक office-style sentence में बदल दिया, जिससे एक अशुभ सा माहौल बन गया
“बात करना चाहता हूँ”, “कब समय है पूछना” जैसी अलग-अलग अभिव्यक्तियों को उसने जरूरत से ज़्यादा महत्व दे दिया, जिससे वह संदेश ऐसा लगने लगा जैसे मैं कोई महत्वपूर्ण लेकिन अस्पष्ट और समय-संवेदनशील बात कहने वाला हूँ
नतीजा यह हुआ कि माँ थोड़ी चिंतित हो गईं, और मुझे गुस्सा आया कि एक स्नेहभरे संदेश का अंतिम रूप ऐसा बना। लगता है अब हर चीज़ में आधा-पका LLM summary ठूँसना ज़रूरी समझा जा रहा है
summary record को हमेशा तुरंत जाँचें, और अगर समस्या हो तो जितनी जल्दी हो सके doctor से संपर्क करें
आमतौर पर doctor खुद उसे ठीक कर सकते हैं, और सबसे अच्छा तब होता है जब सबको वह बात अभी याद हो
खासकर अगर लंबे transcript को आगे भी refer किया जाना है, तो जहाँ इंसान को ज़रूरत लगे वहाँ उसके साथ manual summary साथ-साथ मार्क की जा सकती है
मेरे अनुभव में ऐसी interactions में आम तौर पर बहुत ज़्यादा ऐसा शोर नहीं होता जिसे यूँ ही फ़िल्टर कर देना चाहिए, और details काफ़ी मायने रखती हैं
“बहुत अच्छा” वाली बात यह है कि कई commercial settings में continuous transcription पर रोक होती है। वजह यह कि कुछ specific details एक ऐसे record में रह जाती हैं जो आसानी से discovery का हिस्सा बन सकती हैं और business risk बढ़ा सकती हैं
minutes या summary में sensitive discussions हटाई जा सकती हैं या बिना specifics के सिर्फ agreement दिखाया जा सकता है, और “strategic ambiguity” के साथ interpretation defense भी मिलता है
“पर्याप्त अच्छा नहीं” वाली बात यह है कि speech recognition भी अब भी probabilistic है। असली evaluation output में चुने गए शब्दों जितना ही alternate words/phrases data भी हो सकता है, जिससे न बोले गए शब्दों को दर्शाने या अलग impression बनाने की गुंजाइश रहती है
लोग speech-recognition transcript को authoritative record मान लेते हैं, और यही बात समस्या को और बढ़ाती है
उसके ऊपर summary जैसी generative inference बैठा दें, तो दोनों समस्याएँ और बढ़ जाती हैं। Legal counsel के नज़रिए से ऐसा summary ज़्यादा स्वीकार्य लग सकता है जिसमें specific searchable terms कम हों और liability व specificity धुंधली हो जाए
यह मैंने हाल ही में सच में झेला है। मुझे runner’s knee diagnose हुआ था, लेकिन AI summary में osteoporosis diagnosis, hip pain, और चलने में दिक्कत लिखी हुई थी, जबकि ऐसी कोई बात न कही गई थी, न संकेतित
transcript हमेशा जाँचना चाहिए। खासकर LLM transcriber अक्सर ऐसे common symptoms जोड़ देते हैं जो असल में थे ही नहीं, या कुछ details से मेल खाने वाला लेकिन बाकी से न मिलने वाला common diagnosis ठोक देते हैं
गलत record आगे की treatment और cost पर गहरा असर डाल सकता है, इसलिए इसे ज़रूर ठीक कराना चाहिए
कुछ सरल और common मामलों को छोड़ दें, तो मुझे मिले “AI” summaries में लगभग 50% किसी न किसी रूप में गलत थे। आम तौर पर वे गैर-मौजूद symptoms जोड़ देते हैं, और कभी-कभी, जैसे इस बार, उससे भी गंभीर fabrication कर देते हैं
LLM साधारण speech-to-text software नहीं हैं, और उनके साथ वैसा व्यवहार नहीं होना चाहिए। वे अक्सर पूरे के पूरे वाक्य जोड़ देते हैं जो वास्तव में कभी बोले ही नहीं गए, और medical records में यह बिल्कुल स्वीकार्य नहीं है
meeting में मौजूद न रहने वाले एक दूसरे व्यक्ति ने बाद में वह summary पढ़ी और बड़ा विवाद खड़ा हो गया, क्योंकि वह विषय कंपनी के अंदर चल रही बहस के कारण उसके लिए संवेदनशील था
सभी attendees ने पुष्टि की कि वह गलती थी, लेकिन timing ऐसी थी कि उस व्यक्ति के लिए इसे स्वीकार करना मुश्किल था। summary ने बात को ऐसे पेश किया जैसे वह पहले से मौजूद कुछ attendees की चिंता की पुष्टि कर रही हो, जिसे पहले कम करके दिखाया जा रहा था
मामला इतना बढ़ा कि management ने independent verification के बिना generative output पर भरोसा न करने की policy बना दी, तो कम से कम कोई सबक तो मिला
लेकिन इंसान खुद कितने accurate हैं? मैंने पिछले 5 साल के medical record printouts मँगवाए थे, और वे किताब जितने मोटे निकले
मुझे नहीं लगता कि कोई इंसान वह सब पढ़कर कुछ meaningful कर पाएगा
AI tools उन्हें skim करें तो वे निश्चित रूप से गलती कर सकते हैं या बिना आधार के निष्कर्ष पर कूद सकते हैं, लेकिन जल्दी से verify करके अजीब हिस्सों को challenge करना और सही जवाब तक पहुँचना, nurse या doctor के साथ किसी भी meeting से तेज़ हो सकता है
सिर्फ इसकी अपूर्णताओं की ओर इशारा करने के बजाय, हमें इस पर ध्यान देना चाहिए कि ऐसे tools का उपयोग कैसे किया जाए और अजीब या गलत हिस्सों को कैसे challenge किया जाए, ताकि अधिक काम हो सके
काम पर जो AI note-taker हम इस्तेमाल करते हैं, वह meeting रिकॉर्ड भी करता है, और हर note के साथ recording की उसी जगह पर ले जाने वाला timestamp link जोड़ता है ताकि सीधे verify किया जा सके
HIPAA environment में ऐसा समाधान ज़्यादा जटिल होगा, लेकिन healthcare जैसे critical domains में ऐसा approach ज़रूरी है
यह trust, reliability, compliance जैसी चीज़ों का मुख्य तत्व है
अगर कोई software system ऐसे LLM output शामिल करता है, लेकिन साथ ही output का स्रोत इतना स्पष्ट नहीं करता कि इंसान उसका मूल्यांकन और verification कर सके, तो अच्छे से अच्छा वह खराब user experience है और सबसे बुरे हाल में खतरनाक
accuracy चाहिए तो आखिरकार सब सुनना ही पड़ेगा
या कोई पूरा meeting recording सुनकर सभी notes verify करे, जिसमें बहुत समय और manpower लगे; या attendees अपनी याददाश्त से notes verify करें, जो errors के लिए संवेदनशील है; या attendees अपने notes से cross-check करें, जिससे AI note-taker का मतलब ही खत्म हो जाता है
व्यवहारिक रूप से, किसी भी ऐसे context में जहाँ accuracy महत्वपूर्ण है, AI का उपयोग किसी भी रूप में स्वीकार्य नहीं होना चाहिए, लेकिन लोगों से यह मनवाना मुश्किल है
एक Canadian होने के नाते, मैं इस संभावना को लेकर उत्साहित हूँ कि AI doctors का समय बचा सकता है और healthcare system का बोझ कम कर सकता है, लेकिन यह डरावना है
हम अभी वहाँ तक नहीं पहुँचे हैं। आगे चलकर doctors के लिए AI education की ज़रूरत पड़ सकती है
कुछ condo complexes में पहले से medical provider-owned iPad के जरिए online doctor visits होती हैं, और इससे family doctor appointment process की झंझट कुछ हद तक bypass हो जाती है
innovation की दिशा मुझे सही लगती है, लेकिन समय चाहिए। कभी-कभी लगता है AI को बहुत जल्दी launch कर दिया गया
doctor का समय बचाने के उदाहरण में, patient visits अक्सर बिखरी हुई होती हैं; patient कई समस्याएँ एक साथ बोलता है, और doctor के पास कम समय होता है, साथ ही regulatory explanation duties भी होती हैं जिनके तहत उसे treatment-impacting बातें समझानी पड़ती हैं
perfect transcript हो तब भी यह ढाँचा सबके लिए खराब है, और LLM perfect नहीं हो सकता, वह बस autocomplete करता है
मैं ऐसी तस्वीर सोचता हूँ जहाँ patient intake AI के साथ interact करे, जो घंटों की उलझी हुई बात या anxiety attack के दौरान कही बात भी सुन सके, और doctor को caregiver-verified need summary तथा प्रासंगिक triage information दिखा सके
उस बिंदु पर medication access या insurance policy जैसी उपयोगी जानकारी भी doctor verification के बाद पेश की जा सकती है, और patient बिना समय के दबाव के system की समझ को व्यवस्थित व पूरक कर सकता है
दिशा यह होनी चाहिए कि बातचीत की quality बेहतर हो ताकि doctor patient पर ज़्यादा ध्यान दे सके, और patient की संवाद-संबंधी ज़रूरत treatment पर हावी न हो। Healthcare में forms और checklists बहुत होते हैं, और autocomplete उनके निष्पादन को अधिक efficient बना सकता है
मैं Toronto में हूँ, और मेरे doctor हमेशा पूछते हैं कि क्या AI note-taker इस्तेमाल करना ठीक है, और मैं अनुमति दे देता हूँ
appointment के अंत में doctor notes को देखता और सुधारता है, और अक्सर शिकायत करता है कि उसे computer से मुझसे ज़्यादा बात करनी पड़ती है
अच्छा doctor है, इसलिए शुक्र है कि वह यह post-hoc verification करता है, लेकिन इससे यही impression मिलता है कि doctors चाहें या न चाहें, यह उन पर थोपा जा रहा है
आजकल meetings में शामिल लोगों को ऊँची आवाज़ में यह कहना चाहिए: “सूचना: इस meeting में AI द्वारा व्याख्यायित वक्तव्य सटीक नहीं भी हो सकते हैं”
मैं हर meeting में यह करता हूँ
लिंक की गई report लगभग बेकार लगती है। इसमें error rate या sample size के बारे में कुछ नहीं कहा गया, इसलिए यह समझना मुश्किल है कि 20 systems में से 9 ने “जानकारी में हेरफेर की और patient care plan में सुझाव दिया” का मतलब दस में दस बार है या हज़ार में एक बार
अगर system error rate सच में ऊँचा है, तब भी सवाल है कि इन्हें अपनाया क्यों जा रहा है
testing बहुत आसान लगती है, इसलिए अगर चीज़ इतनी खराब है तो doctors, hospitals, या government को ठगकर बेच पाना मुश्किल होना चाहिए
accuracy असल में evaluation का मुख्य बिंदु ही नहीं थी; यानी Ontario ने उसे खास महत्व नहीं दिया
कहा जाता है कि यह खास तौर पर Ontario Ministry of Health द्वारा doctors, nurse practitioners, और broader health sector के अन्य medical professionals के लिए शुरू किए गए AI Scribe program को कवर करता है, और इससे यह सोचने पर मजबूर होना पड़ता है कि ministry किस quality का software आगे बढ़ाएगी
शायद requirements का ज़्यादातर हिस्सा SOC जैसी qualifications पर आधारित होगा
approved vendors की list शायद इस लिंक पर है: https://www.supplyontario.ca/vor/software/tender-20123-artif...