डिजिटल स्वास्थ्य मार्गदर्शिका

विषय 1.6 — क्लिनिकल सुरक्षा और जोखिम प्रबंधन

एक वाक्य में: क्लिनिकल सुरक्षा उन तरीकों को खोजने और उन खतरों को किसी तक पहुंचने से पहले नियंत्रित करने का अनुशासित, प्रमाणित अभ्यास है जिनसे आपकी डिजिटल प्रौद्योगिकी एक रोगी को नुकसान पहुंचा सकती है — सुरक्षा पहले स्केच से डिज़ाइन में शामिल, लाइव-गो से पहले जोड़ी नहीं गई।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

अधिकांश क्षेत्रों में एक सॉफ़्टवेयर दोष एक असुविधा है: एक पेज लोड होने में विफल होता है, एक ऑर्डर दोहराया जाता है, एक रिपोर्ट देर से आती है। स्वास्थ्य और देखभाल में दोषों की वही श्रेणी मार सकती है। एक दवा फ़ील्ड जो एक दशमलव बिंदु को काट देती है, एक परिणाम स्क्रीन जो गलत रोगी दिखाती है, एक त्रिआज एल्गोरिथम जो चुपचाप एक लक्षण को चिह्नित करना बंद कर देता है, एक एकीकरण जो चुपचाप एलर्जी रिकॉर्ड गिरा देता है — हर एक एक सॉफ़्टवेयर बग है, और हर एक एक क्लिनिकल खतरा भी है जो गंभीर नुकसान या मृत्यु का कारण बन सकता है। इसलिए क्लिनिकल सुरक्षा अच्छी इंजीनियरिंग के ऊपर परत चढ़ाई गई एक गुणवत्ता सुंदरता नहीं है; यह अपने स्वयं के मानकों, भूमिकाओं, और साक्ष्य के साथ एक अलग, विनियमित अनुशासन है।

दांव असममित और अक्सर अदृश्य हैं। जब एक डिजिटल सिस्टम काम करता है, तो कोई उस नुकसान को नहीं देखता जिसे इसने रोका; जब यह विफल होता है, तो कोई पैटर्न नोटिस करे उससे पहले नुकसान विनाशकारी, विलंबित, और हज़ारों रोगियों में वितरित हो सकता है। यह संयोजन — उच्च परिणाम, कम दृश्यता, व्यापक विस्फोट त्रिज्या — का अर्थ है कि आप समस्याओं को पकड़ने के लिए उपयोगकर्ताओं पर या आपको सब कुछ सिखाने के लिए घटनाओं पर भरोसा नहीं कर सकते। आपको तैनाती से पहले, सक्रिय रूप से नुकसान के बारे में तर्क करना होगा, और सिस्टम लाइव रहने पर इसके बारे में तर्क करना जारी रखना होगा। यूनाइटेड किंगडम में यह सक्रिय तर्क वैकल्पिक नहीं है: NHS संगठनों और उनके आपूर्तिकर्ताओं से संविदात्मक और व्यावसायिक रूप से राष्ट्रीय क्लिनिकल जोखिम प्रबंधन मानकों को लागू करने की, और अपना काम दिखाने में सक्षम होने की अपेक्षा की जाती है। इसे सही करना साक्ष्य से अविभाज्य है (देखें विषय 1.3 — साक्ष्य-आधारित निर्णय), सूचना प्रशासन और साइबर सुरक्षा से (देखें विषय 1.7 — सूचना प्रशासन, डेटा सुरक्षा और साइबर सुरक्षा), और आप सेवाओं को लाइव होने के बाद कैसे चलाते हैं इससे (देखें विषय 3.8 — सेवा प्रबंधन और लाइव संचालन)।

मुख्य अवधारणाएं#

रोगी सुरक्षा और जोखिम प्रबंधन। रोगी सुरक्षा देखभाल से रोगियों को होने वाले नुकसान की रोकथाम, कमी, रिपोर्टिंग, और विश्लेषण है। क्लिनिकल जोखिम प्रबंधन जोखिम प्रबंधन के सामान्य अनुशासन को लागू करता है — जोखिमों की पहचान करना, मूल्यांकन करना, प्राथमिकता देना, और नियंत्रित करना — इस विशिष्ट प्रश्न पर कि एक स्वास्थ्य IT सिस्टम रोगी नुकसान में कैसे योगदान दे सकता है। इंग्लैंड में इसे नियंत्रित करने वाले दो राष्ट्रीय मानक DCB0129 और DCB0160 हैं (DCB का अर्थ है Data Coordination Board; ये Standardization Committee for Care Information Standards / SCCI मानक हैं जो Health and Social Care Act 2012 के तहत अनिवार्य हैं)। DCB0129 एक स्वास्थ्य IT सिस्टम के निर्माता या आपूर्तिकर्ता पर दायित्व रखता है; DCB0160 इसे तैनात और उपयोग करने वाले स्वास्थ्य संगठन पर दायित्व रखता है। वे पूरक हैं: एक आपूर्तिकर्ता का साफ़ सुरक्षा मामला एक तैनात करने वाले ट्रस्ट के अपने कॉन्फ़िगरेशन, वर्कफ़्लो, और संदर्भ द्वारा शुरू किए गए खतरों का आकलन करने के कर्तव्य को पूरा नहीं करता।

Clinical Safety Officer (CSO)। दोनों मानकों को एक नामित, उपयुक्त रूप से योग्य और अनुभवी Clinical Safety Officer की आवश्यकता है — एक पंजीकृत, वर्तमान में अभ्यास करने वाला क्लिनिशियन जिसने मान्यता प्राप्त क्लिनिकल सुरक्षा प्रशिक्षण पूरा किया हो — जो क्लिनिकल जोखिम प्रबंधन गतिविधि का स्वामित्व रखे और व्यक्तिगत रूप से सुरक्षा मामले को अनुमोदित करे। CSO भूमिका एक क्षमता आवश्यकता है, कोई नौकरी शीर्षक नहीं जिसे आप जो भी खाली हो उसे सौंप सकें। CSO हस्ताक्षर करता है कि खतरों की पहचान की गई है और उन्हें एक स्वीकार्य स्तर तक नियंत्रित किया गया है; यह व्यावसायिक जवाबदेही ले जाने वाला एक व्यावसायिक निर्णय है।

क्लिनिकल जोखिम प्रबंधन कलाकृतियां। तीन दस्तावेज़ इस अनुशासन को लंगर डालते हैं। क्लिनिकल जोखिम प्रबंधन फ़ाइल एक सिस्टम के लिए सभी सुरक्षा साक्ष्य के लिए कंटेनर है। खतरा लॉग हर पहचाने गए खतरे, उसके कारणों, परिणामों, जोखिम रेटिंग, नियंत्रणों, और अवशिष्ट जोखिम का जीवंत रजिस्टर है। क्लिनिकल सुरक्षा मामला साक्ष्य द्वारा समर्थित संरचित तर्क है कि सिस्टम उसके इच्छित उपयोग के लिए उसके इच्छित संदर्भ में स्वीकार्य रूप से सुरक्षित है — एक सुरक्षा मामला रिपोर्ट के साथ जो अनुमोदन के लिए तर्क को संक्षेप में प्रस्तुत करती है। ये अपने आप में कागज़ी काम नहीं हैं; वे यह हैं कि सुरक्षा तर्क को स्पष्ट, समीक्षा योग्य, और टिकाऊ कैसे बनाया जाता है।

खतरा विश्लेषण: पहचान, विश्लेषण, मूल्यांकन, नियंत्रण। मूल लूप है: खतरा पहचान (व्यवस्थित रूप से कल्पना करना कि सिस्टम नुकसान में कैसे योगदान दे सकता है — कार्यशालाओं, क्लिनिकल वॉकथ्रू, विफलता-मोड विश्लेषण के माध्यम से), जोखिम विश्लेषण (नुकसान की गंभीरता और इसके होने की संभावना का अनुमान लगाना), जोखिम मूल्यांकन (अनुमानित जोखिम की स्वीकार्यता मानदंड के विरुद्ध तुलना करना), और जोखिम नियंत्रण (अस्वीकार्य जोखिम को कम करने के लिए उपाय — डिज़ाइन परिवर्तन, अलर्ट, प्रशिक्षण, प्रक्रियाएं — शुरू करना, फिर अवशिष्ट जोखिम का पुनर्मूल्यांकन करना)। जोखिम को उचित रूप से व्यावहार्य रूप से कम (ALARP) किया जाता है: आप तब तक नियंत्रित करते रहते हैं जब तक आगे की कमी प्राप्त लाभ के विपरीत घोर असंगत न हो।

चिकित्सा उपकरण विनियमन, MHRA, और Software as a Medical Device (SaMD)। कुछ डिजिटल स्वास्थ्य प्रौद्योगिकी एक विनियमित चिकित्सा उपकरण है। सॉफ़्टवेयर जिसका एक चिकित्सा उद्देश्य है — निदान, रोकथाम, निगरानी, भविष्यवाणी, उपचार — स्वयं एक चिकित्सा उपकरण हो सकता है: Software as a Medical Device (SaMD)। यूके में Medicines and Healthcare products Regulatory Agency (MHRA) चिकित्सा उपकरणों को विनियमित करता है, जिसमें SaMD शामिल है, और सॉफ़्टवेयर जीवनचक्र मानक IEC 62304 नियंत्रित करता है कि ऐसे सॉफ़्टवेयर को कैसे विकसित किया जाना चाहिए। यह तय करना कि क्या आपकी प्रौद्योगिकी एक विनियमित उपकरण है बड़े परिणामों वाला एक सीमा प्रश्न है, और यह DCB0129/0160 क्लिनिकल जोखिम प्रबंधन से अलग है — हालांकि यह इसके साथ बैठता है।

Digital Technology Assessment Criteria (DTAC)। DTAC वह राष्ट्रीय आधार रेखा है जिसका उपयोग NHS और सामाजिक देखभाल संगठन खरीद से पहले डिजिटल उत्पादों का आकलन करने के लिए करते हैं, जिसमें क्लिनिकल सुरक्षा (DCB0129 अनुपालन का साक्ष्य), डेटा सुरक्षा, तकनीकी सुरक्षा, अंतरसंचालनीयता, और उपयोगिता शामिल है। यह क्लिनिकल जोखिम प्रबंधन को प्रतिस्थापित नहीं करता; यह जांचता है कि एक आपूर्तिकर्ता ने इसे किया है।

मानव कारक और सुरक्षा संस्कृति। मानव कारक (एर्गोनॉमिक्स) इस बात का वैज्ञानिक अध्ययन है कि लोग वास्तविक परिस्थितियों में सिस्टम के साथ कैसे बातचीत करते हैं — थकान, रुकावट, संज्ञानात्मक भार, अलार्म थकान। अधिकांश डिजिटल नुकसान "गलत" कोड से नहीं बल्कि उन डिज़ाइनों से उत्पन्न होता है जो सुरक्षित कार्रवाई को कठिन और असुरक्षित कार्रवाई को आसान बनाते हैं। सुरक्षा संस्कृति बिना दोष के जोखिम को सामने लाने, रिपोर्ट करने, और उससे सीखने के लिए संगठनात्मक प्रतिबद्धता है — उस टीम के बीच का अंतर जो निकट-चूक छुपाती है और एक जो सुधार के लिए उन्हें खोदती है।

घटना रिपोर्टिंग और सीखना। इंग्लैंड में, Learn from Patient Safety Events (LFPSE) रोगी सुरक्षा घटनाओं को रिकॉर्ड करने के लिए राष्ट्रीय सेवा है, और Patient Safety Incident Response Framework (PSIRF) यह निर्धारित करता है कि NHS संगठन घटनाओं का जवाब कैसे देते हैं और उनसे कैसे सीखते हैं — दोष पर आनुपातिक, प्रणाली-आधारित मूल-कारण विश्लेषण पर ज़ोर देते हुए। लाइव सिस्टम नए खतरे उत्पन्न करते हैं, इसलिए क्लिनिकल सुरक्षा लाइव-गो के बाद घटना फीडबैक के माध्यम से खतरा लॉग में जारी रहती है।

सर्वोत्तम प्रथाएं#

  1. एक सक्षम Clinical Safety Officer नियुक्त करें और उन्हें वास्तविक अधिकार दें। दायरे में हर सिस्टम के लिए एक पंजीकृत, अभ्यास करने वाले क्लिनिशियन को मान्यता प्राप्त क्लिनिकल सुरक्षा प्रशिक्षण के साथ CSO के रूप में नाम दें, और सुनिश्चित करें कि उनका हस्ताक्षर एक वास्तविक द्वार है, लॉन्च से एक दिन पहले पहुंचा एक रबर स्टैंप नहीं। CSO को "अभी नहीं" कहने में सक्षम होना चाहिए और सुना जाना चाहिए — जिसका अर्थ है उनका समय, उनकी स्वतंत्रता, और प्रोग्राम बोर्ड के साथ उनकी स्थिति की रक्षा करना। एक CSO जिसे डिलीवरी दबाव द्वारा खारिज कर दिया जाता है एक प्रशासन कल्पना है।

  2. खतरा पहचान जल्दी करें, कमरे में क्लिनिशियनों के साथ। डिस्कवरी और डिज़ाइन में खतरा कार्यशालाएं शुरू करें, लाइव-गो से पहले नहीं, क्योंकि सबसे सस्ते और सबसे प्रभावी नियंत्रण डिज़ाइन परिवर्तन हैं जो कुछ भी बनने से पहले किए जाते हैं (देखें विषय 3.5 — डिलीवरी जीवनचक्र)। केवल विश्लेषकों को नहीं, फ्रंटलाइन क्लिनिशियनों को लाएं, क्योंकि वे जानते हैं कि काम वास्तव में कैसे होता है — रुकावटें, वर्कअराउंड, जिस तरह से एक स्क्रीन को रात के 3 बजे पढ़ा जाता है। यथार्थवादी क्लिनिकल परिदृश्यों के माध्यम से चलें और अथक रूप से पूछें: "यह सिस्टम एक रोगी को नुकसान पहुंचाने में कैसे योगदान दे सकता है?"

  3. एक जीवंत खतरा लॉग रखें, लॉन्च-दिन का दस्तावेज़ नहीं। खतरा लॉग को एक स्थायी रजिस्टर के रूप में मानें जो डिस्कवरी पर खुलता है और सिस्टम लाइव रहते कभी बंद नहीं होता। हर खतरा अपने कारणों, संभावित नुकसान, प्रारंभिक जोखिम रेटिंग, लागू नियंत्रणों, और नियंत्रणों के बाद अवशिष्ट जोखिम को दर्ज करता है। जब एक घटना, एक परिवर्तन, या एक निकट-चूक एक नया खतरा प्रकट करती है, तो यह लॉग में प्रवेश करती है और उसी लूप के माध्यम से काम की जाती है — लॉग आपके सुरक्षा तर्क की स्मृति है।

  4. तैनात करने वाले संगठन को DCB0160 का स्वामी बनाएं, भले ही आपूर्तिकर्ता अनुपालक हो। एक आपूर्तिकर्ता का DCB0129 सुरक्षा मामला उत्पाद को जैसा बनाया गया है उसे कवर करता है; यह कवर नहीं कर सकता कि आप इसे कैसे कॉन्फ़िगर करते हैं, आप इसके चारों ओर किन वर्कफ़्लो को लपेटते हैं, या आपकी किन जनसंख्याओं इसका उपयोग करती हैं। स्थानीय खतरों के लिए अपना स्वयं का DCB0160 मूल्यांकन चलाएं — आपके अन्य सिस्टमों के साथ एकीकरण, आपकी डेटा गुणवत्ता, आपके क्लिनिकल मार्ग — और अपना खुद का खतरा लॉग रखें। यह मान लेना कि आपूर्तिकर्ता का आश्वासन आपके संदर्भ को कवर करता है एक सामान्य और खतरनाक शॉर्टकट है।

  5. जोखिम नियंत्रण को आनुपातिक बनाएं और चेतावनियों पर डिज़ाइन को प्राथमिकता दें। नियंत्रणों को ताकत के अनुसार रैंक करें: खतरे को डिज़ाइन से बाहर करना (बाधाएं, डिफ़ॉल्ट, मजबूर करने वाले फ़ंक्शन) एक ऑन-स्क्रीन अलर्ट को हराता है, जो एक प्रशिक्षण मैनुअल में एक पंक्ति को हराता है। सबसे भारी आश्वासन को उच्चतम-परिणाम खतरों के लिए आरक्षित रखें और वास्तव में कम-जोखिम वाले परिवर्तनों पर हल्की, तेज़ प्रक्रिया लागू करें — आनुपातिकता ही वह है जो सुरक्षा को डिलीवरी के साथ गति बनाए रखने देती है। जोखिम को ALARP तक कम करें और रिकॉर्ड करें कि अवशिष्ट जोखिम स्वीकार्य क्यों है।

  6. मानव कारकों के लिए डिज़ाइन करें, और अलार्म थकान का सम्मान करें। मान लें कि उपयोगकर्ता व्यस्त, बाधित, और पैटर्न-मिलान कर रहे हैं, और इस तरह डिज़ाइन करें कि सुरक्षित कार्रवाई आसान, डिफ़ॉल्ट कार्रवाई हो। अलर्ट अधिभार के विरुद्ध रक्षा करें: एक अलर्ट जो बहुत बार बजता है उसे नज़रअंदाज़ किया जाता है, इसलिए हर अतिरिक्त चेतावनी को अपनी जगह अर्जित करनी चाहिए वरना यह उन चीज़ों को घटाती है जो मायने रखती हैं। यथार्थवादी परिस्थितियों के तहत उपयोगिता परीक्षण एक क्लिनिकल-सुरक्षा गतिविधि है, केवल एक डिज़ाइन सुंदरता नहीं।

  7. अपनी नियामक स्थिति सोच-समझकर निर्धारित करें। जल्दी पूछें कि क्या आपका सॉफ़्टवेयर एक चिकित्सा उपकरण या SaMD की परिभाषा को पूरा करता है, और यदि हां, तो देर से दायित्व की खोज करने के बजाय शुरुआत से MHRA आवश्यकताओं और IEC 62304 से जुड़ें। वर्गीकरण को गलत करना दोनों दिशाओं में महंगा है — एक अपंजीकृत उपकरण एक कानूनी और सुरक्षा विफलता है, जबकि एक साधारण उपकरण को अत्यधिक-वर्गीकृत करना दुर्लभ आश्वासन क्षमता बर्बाद करता है। संदेह होने पर, नियामक सलाह लें और तर्क को दस्तावेज़ीकृत करें।

  8. DTAC को एक फर्श के रूप में उपयोग करें, फिनिश लाइन नहीं। Digital Technology Assessment Criteria को किसी भी खरीदे गए डिजिटल उत्पाद के लिए न्यूनतम प्रवेश जांच के रूप में मानें, यह पुष्टि करते हुए कि क्लिनिकल सुरक्षा, डेटा सुरक्षा, सुरक्षा, अंतरसंचालनीयता, और उपयोगिता को संबोधित किया गया है। DTAC पास करने का अर्थ है कि एक आपूर्तिकर्ता ने काम किया है; इसका अर्थ यह नहीं है कि उत्पाद आपके संदर्भ में सुरक्षित है, इसलिए इसे अपने स्वयं के DCB0160 मूल्यांकन और लाइव निगरानी के साथ जोड़ें।

  9. लाइव घटनाओं से खतरा लॉग तक लूप बंद करें। अपनी घटना रिपोर्टिंग — LFPSE प्रस्तुतियां, PSIRF जांच, स्थानीय निकट-चूक रिपोर्ट — को क्लिनिकल जोखिम प्रबंधन में वापस वायर करें ताकि वास्तविक-दुनिया का नुकसान और निकट-चूक आपके खतरों और नियंत्रणों को अपडेट करें। एक सुरक्षा मामला जिसे लाइव-गो के बाद कभी फिर से नहीं देखा जाता सड़ जाता है, क्योंकि लाइव सिस्टम, एकीकरण, और क्लिनिकल अभ्यास सभी बहते हैं (देखें विषय 3.8 — सेवा प्रबंधन और लाइव संचालन)। सीखना प्रणाली-आधारित और दोष-सचेत है, किसी को दंडित करने के लिए खोज नहीं।

  10. एक न्यायसंगत, रिपोर्टिंग सुरक्षा संस्कृति बनाएं। निकट-चूक की रिपोर्ट करना और सुरक्षा आधार पर एक लॉन्च को चुनौती देना सुरक्षित और अपेक्षित बनाएं, क्योंकि जिन खतरों के बारे में आप कभी नहीं सुनते वे ऐसे खतरे हैं जिन्हें आप नियंत्रित नहीं कर सकते। नेता बुरी खबर पर दोष के बजाय जिज्ञासा और सुधार के साथ प्रतिक्रिया देकर, और CSO की सावधानी को बाधा के बजाय मूल्यवान मानकर यह स्वर सेट करते हैं। संस्कृति वह आधार है जिस पर यहां हर दूसरा अभ्यास निर्भर करता है।

आपकी टीम के साथ चर्चा करने के लिए प्रश्न#

  1. हमारे वर्तमान पोर्टफोलियो में हम कहां उन जोखिमों को कवर करने के लिए एक आपूर्तिकर्ता के सुरक्षा आश्वासन पर निर्भर हैं जो वास्तव में हमारे स्वामित्व में हैं? यह प्रश्न DCB0129/DCB0160 विभाजन की जांच करता है, जिसे टीमें नियमित रूप से धुंधला करती हैं। एक आपूर्तिकर्ता का DCB0129 सुरक्षा मामला उत्पाद को जैसे निर्मित किया गया वैसे संबोधित करता है, लेकिन जिस क्षण आप इसे कॉन्फ़िगर करते हैं, इसे अपने अन्य सिस्टमों से जोड़ते हैं, इसके चारों ओर स्थानीय वर्कफ़्लो लपेटते हैं, और इसे अपनी विशिष्ट रोगी जनसंख्या की ओर इंगित करते हैं, आप ऐसे खतरे पेश करते हैं जिनका आपूर्तिकर्ता ने कभी आकलन नहीं किया और नहीं कर सकता था। ईमानदार तनाव यह है कि अपना स्वयं का DCB0160 मूल्यांकन चलाने में दुर्लभ क्लिनिकल और विश्लेषणात्मक समय खर्च होता है, और एक आपूर्तिकर्ता के साफ़ आश्वासन और एक DTAC पास को पर्याप्त मानना आकर्षक है। एक लाइव या आसन्न तैनाती के माध्यम से काम करें और ठोस रूप से पूछें: इसके लिए हमारा नामित CSO कौन है, क्या हमारे पास अपना खुद का खतरा लॉग है, और कौन से खतरे केवल उत्पाद से नहीं बल्कि हमारे स्थानीय संदर्भ से उत्पन्न होते हैं? एक अच्छा उत्तर विशिष्ट सिस्टमों को नाम देता है जहां स्थानीय मूल्यांकन पतला है, उत्पाद खतरों को तैनाती खतरों से अलग करता है, और बाद वाले का स्वामी बनने के लिए प्रतिबद्ध होता है यह मानने के बजाय कि वे कवर हैं।

  2. हमारी क्लिनिकल सुरक्षा प्रक्रिया कितनी आनुपातिक है — क्या हम कम-जोखिम वाले परिवर्तनों को कागज़ी काम में दफना रहे हैं जबकि उच्च-परिणाम परिवर्तन गति पर फिसल जाते हैं? विषय तर्क देता है कि आश्वासन को क्लिनिकल जोखिम के साथ पैमाने पर होना चाहिए: उच्चतम-परिणाम खतरों के लिए सबसे भारी जांच, वहां हल्की और तेज़ प्रक्रिया जहां जोखिम वास्तव में कम है। यह प्रश्न परखता है कि क्या आपका संगठन वास्तव में कैलिब्रेट करता है, या एक कुंद सेटिंग लागू करता है। दोनों विफलता दिशाएं वास्तविक और महंगी हैं — एक समान रूप से भारी प्रक्रिया टीमों को क्लिनिकल सुरक्षा को एक नौकरशाही कर के रूप में देखने और इसके आसपास मार्ग बनाने का प्रशिक्षण देती है, जबकि एक समान रूप से हल्की प्रक्रिया एक दवा-खुराक गणना में परिवर्तन को एक सहायता पेज में परिवर्तन के समान प्रयास के साथ पास होने देती है। अधिक सूक्ष्म खतरा यह है कि जोखिम नहीं, गति जांच तय करती है: कार्यकारी ध्यान वाला एक प्रमुख कार्यक्रम अनिवार्यता का एक आभामंडल प्राप्त कर सकता है जो CSO को "अभी नहीं" कहने से हतोत्साहित करता है। स्पष्ट रूप से अलग जोखिम के दो या तीन हालिया परिवर्तनों की जांच करें और पूछें कि क्या खर्च किया गया प्रयास नुकसान की संभावना से मेल खाता था, और क्या किसी ने उच्च-प्रोफ़ाइल वाले को धीमा करने में सक्षम महसूस किया। एक ईमानदार उत्तर स्वीकार करता है कि प्रक्रिया किसी भी दिशा में गलत-कैलिब्रेट है, और आनुपातिकता को एक रिफ्लेक्स के बजाय एक बचाव योग्य, स्पष्ट निर्णय के रूप में मानता है।

  3. जब हमारे किसी डिजिटल सिस्टम के साथ कुछ लगभग गलत हुआ, तो वास्तव में आगे क्या हुआ — और क्या एक फ्रंटलाइन क्लिनिशियन कहेगा कि इसे उठाना सुरक्षित था? यह प्रश्न सुरक्षा संस्कृति और घटना-सीखने वाले लूप की जांच करता है, जो वह जगह है जहां बताई गई प्रतिबद्धताएं वास्तविकता से मिलती हैं। क्लिनिकल सुरक्षा निकट-चूकों के बारे में सुनने पर निर्भर करती है, लेकिन लोग तभी रिपोर्ट करते हैं जब रिपोर्टिंग सुरक्षित और सार्थक महसूस होती है, और जब वे इसे दोष के बजाय परिवर्तन की ओर ले जाते देखते हैं। तनाव यह है कि डिलीवरी और प्रतिष्ठा दबाव के तहत प्रवृत्ति एक निकट-चूक को स्पष्ट करने, इसे जल्दी बंद करने, और आगे बढ़ने की है — विशेष रूप से अगर इसे पूरी तरह से सामने लाना एक लॉन्च में देरी करेगा या एक वरिष्ठ प्रायोजक को शर्मिंदा करेगा। PSIRF का प्रणाली-आधारित, दोष-सचेत दृष्टिकोण ठीक इसलिए मौजूद है क्योंकि दोष के लिए एक व्यक्ति की खोज उस रिपोर्टिंग को दबा देती है जिसकी आपको आवश्यकता है और वास्तविक, प्रणालीगत कारणों को छोड़ देती है। चर्चा को एक विशिष्ट हालिया निकट-चूक या घटना में आधारित करें: क्या इसे लॉग किया गया, क्या यह खतरा लॉग तक पहुंचा, क्या एक आनुपातिक जांच की गई, और क्या वास्तव में कुछ बदला? एक अच्छा उत्तर इस बारे में स्पष्ट है कि क्या रिपोर्टिंग सुरक्षित महसूस हुई, वास्तविक सीखने को कागज़ी काम बंद करने से अलग करता है, और ठोस व्यवहारों को नाम देता है जिन्हें नेता अपनाएंगे ताकि अगला व्यक्ति जो एक खतरा देखता है वह बोले।

  4. क्या हमने ईमानदारी से निर्धारित किया है कि हमारे कौन से उत्पाद विनियमित चिकित्सा उपकरण हैं — और उस निर्णय के लिए कौन जवाबदेह है? नियामक स्थिति असाधारण परिणामों वाला एक सीमा प्रश्न है, और इसका उत्तर न देना छोड़ना आसान है क्योंकि इसका उत्तर देना असुविधाजनक हो सकता है। सॉफ़्टवेयर जो निदान करता है, भविष्यवाणी करता है, निगरानी करता है, या उपचार करता है वह स्वयं Software as a Medical Device हो सकता है, जो MHRA दायित्वों और IEC 62304 जीवनचक्र मानक को खींचता है — DCB0129/0160 क्लिनिकल जोखिम प्रबंधन से अलग, और उसके अतिरिक्त। तनाव दोनों तरफ चलता है: कम-वर्गीकरण आपको एक अपंजीकृत उपकरण भेजते हुए छोड़ता है, एक कानूनी और सुरक्षा विफलता जो पैमाने पर विनाशकारी रूप से सामने आ सकती है, जबकि एक साधारण प्रशासनिक उपकरण को अत्यधिक-वर्गीकृत करना दुर्लभ आश्वासन क्षमता जलाता है जिसकी आपको कहीं और आवश्यकता थी। खतरा यह है कि वर्गीकरण भूमिकाओं के बीच गिर जाता है — क्लिनिशियन मानते हैं कि इंजीनियरों ने तय किया, इंजीनियर मानते हैं कि नियामक या वाणिज्यिक टीम ने तय किया, और वास्तव में किसी ने तर्क नहीं लिखा। अपने पोर्टफोलियो में उन उत्पादों को ठोस रूप से देखें जो रेखा के सबसे करीब बैठते हैं — कोई भी चीज़ जिसमें एक त्रिआज नियम, एक जोखिम स्कोर, एक अलर्टिंग एल्गोरिथम है — और पूछें कि उपकरण निर्धारण किसने किया, किस आधार पर, और क्या यह दस्तावेज़ीकृत है और सुविधाओं के बदलने पर फिर से देखा जाता है। एक ईमानदार उत्तर सीमा-रेखा उत्पादों को नाम देता है, हर एक के लिए एक दर्ज और बचाव योग्य तर्क की ओर इशारा करता है, और स्पष्ट है कि निर्णय वास्तव में कहां कभी नहीं लिया गया।

  5. क्या हम खतरों को डिज़ाइन से बाहर कर रहे हैं, या हम चुपचाप ऐसे अलर्ट और चेतावनियां जमा कर रहे हैं जिन्हें हमारे क्लिनिशियन पहले से ही नज़रअंदाज़ करना सीख चुके हैं? विषय ताकत के अनुसार नियंत्रणों को रैंक करता है — खतरे को डिज़ाइन से बाहर करना एक ऑन-स्क्रीन अलर्ट को हराता है, जो एक प्रशिक्षण मैनुअल में एक पंक्ति को हराता है — फिर भी अलर्ट सबसे कम प्रतिरोध का मार्ग हैं, क्योंकि एक चेतावनी जोड़ना तेज़ है और ज़िम्मेदार महसूस होता है जबकि एक वर्कफ़्लो को फिर से डिज़ाइन करना धीमा और विवादित है। समय के साथ यह पक्षपात अलार्म थकान में जमा हो जाता है: इतनी सारी चेतावनियां बजती हैं कि क्लिनिशियन उन सभी को पैटर्न-मिलान करके छोड़ देते हैं, जिसमें वह भी शामिल है जो मायने रखता है, इसलिए हर नया अलर्ट वास्तव में सुरक्षा को कम कर सकता है। वास्तविक तनाव यह है कि हर अनावश्यक अलर्ट का एक प्रायोजक है जिसने इसे किसी घटना के बाद सद्भावना में जोड़ा, जो चेतावनियों को हटाना राजनीतिक रूप से कठिन बनाता है भले ही वे सिस्टम को घटा रही हों। मानव कारक यहां अनुशासन है — इस तरह डिज़ाइन करना कि सुरक्षित कार्रवाई एक व्यस्त, बाधित उपयोगकर्ता के लिए आसान, डिफ़ॉल्ट कार्रवाई हो जो रात के 3 बजे एक स्क्रीन पढ़ रहा है — और यथार्थवादी परिस्थितियों के तहत उपयोगिता परीक्षण एक क्लिनिकल-सुरक्षा गतिविधि है, एक डिज़ाइन सुंदरता नहीं। एक सिस्टम की जांच करें जिसका आपकी टीमें वास्तव में उपयोग करती हैं और पूछें कि एक क्लिनिशियन एक विशिष्ट कार्य में कितने अलर्ट का सामना करता है, उनमें से कौन वास्तव में व्यवहार बदलता है, और कहां एक मजबूर करने वाला फ़ंक्शन या एक बेहतर डिफ़ॉल्ट एक चेतावनी को पूरी तरह से बदल सकता था। एक अच्छा उत्तर एक और अलर्ट जोड़ने के रिफ्लेक्स का विरोध करता है, अलर्ट भार को अपने आप में एक मापने योग्य खतरा मानता है, और उन चेतावनियों को हटाने के लिए तैयार है जो अब अपनी जगह अर्जित नहीं करतीं।

  6. जैसे हमारे लाइव सिस्टम, एकीकरण, और क्लिनिकल मार्ग समय के साथ बहते हैं, हमें कैसे पता चलता है कि हमारा सुरक्षा मामला अभी भी टिकता है? क्लिनिकल सुरक्षा लाइव-गो पर समाप्त नहीं होती; लाइव सिस्टम नए खतरे उत्पन्न करते हैं, और एक सिस्टम के आसपास की दुनिया चलती रहती है — एक अपस्ट्रीम एकीकरण अपना डेटा बदलता है, एक क्लिनिकल मार्ग फिर से डिज़ाइन किया जाता है, एक आपूर्तिकर्ता एक अपडेट भेजता है, एक नया रोगी समूह उपकरण का उपयोग करना शुरू करता है। दो साल पहले अनुमोदित एक सुरक्षा मामला एक सिस्टम और एक संदर्भ का वर्णन करता है जो अब मौजूद नहीं हो सकता, इसलिए प्रश्न यह है कि क्या आपका खतरा लॉग एक जीवंत रजिस्टर है या एक दस्तावेज़ जिस पर एक बार हस्ताक्षर किया गया और सड़ने के लिए छोड़ दिया गया (देखें विषय 3.8 — सेवा प्रबंधन और लाइव संचालन)। तनाव यह है कि लॉन्च के बाद सुरक्षा तर्क को बनाए रखना उसी दुर्लभ CSO और क्लिनिकल समय के लिए नई डिलीवरी के साथ प्रतिस्पर्धा करता है, और बहाव क्रमिक और अदृश्य है जब तक कुछ विफल न हो जाए तब तक शायद ही कभी ध्यान आकर्षित करता है। ठोस कोणों में परिवर्तन नियंत्रण शामिल है जो कॉन्फ़िगरेशन या एकीकरण बदलने पर खतरा मूल्यांकन को फिर से ट्रिगर करता है, उच्चतम-परिणाम खतरों की आवधिक समीक्षा, और निगरानी जो वास्तव में एक नियंत्रण को चुपचाप घटते हुए पकड़ेगी। एक ऐसे सिस्टम को चुनें जो एक साल या उससे अधिक समय से लाइव है और पूछें कि इसके खतरों की आखिरी बार कब समीक्षा की गई, अनुमोदन के बाद से इसके नीचे क्या बदला है, और अगर एक मुख्य नियंत्रण काम करना बंद कर दे तो कौन नोटिस करेगा। एक ईमानदार उत्तर वास्तविक चल रहे सुरक्षा प्रबंधन वाले सिस्टमों को एक बासी सुरक्षा मामले पर चलने वाले सिस्टमों से अलग करता है, और केवल कैलेंडर के बजाय वास्तविक परिवर्तन से बंधी समीक्षा की एक आनुपातिक गति के लिए प्रतिबद्ध होता है।

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

एक एकीकृत देखभाल प्रणाली (ICS) एक साझा ई-रेफरल उपकरण तैनात कर रही है जो GP को सीधे सामुदायिक सेवाओं में रोगियों को रेफर करने देता है, जिसमें एक अंतर्निहित त्रिआज नियम समूह है जो तत्काल मामलों को एक तेज़ कतार में भेजता है। एक डिलीवरी-संचालित दृष्टिकोण आपूर्तिकर्ता का DCB0129 सुरक्षा मामला लेता, DTAC पास करता, और एक बोर्ड-वादा की गई तारीख को हिट करने के लिए लाइव हो जाता।

इसके बजाय, प्रोग्राम एक अभ्यास करने वाले GP को क्लिनिकल सुरक्षा प्रशिक्षण के साथ Clinical Safety Officer के रूप में नियुक्त करता है और डिज़ाइन की शुरुआत में एक क्लिनिकल जोखिम प्रबंधन फ़ाइल और खतरा लॉग खोलता है। GP, सामुदायिक नर्सों, और प्रशासकों के साथ शुरुआती खतरा कार्यशालाएं कई खतरे सामने लाती हैं जिन्हें आपूर्तिकर्ता के उत्पाद-स्तर के मामले ने कभी नहीं छुआ — सभी स्थानीय तैनाती से उत्पन्न। सबसे बुरा: त्रिआज नियमों को ICS की अपनी सेवा परिभाषाओं के विरुद्ध कॉन्फ़िगर किया गया था, और एक मैपिंग त्रुटि एक तत्काल त्वचा-कैंसर रेफरल को एक नियमित डर्मेटोलॉजी कतार में कई हफ्तों की प्रतीक्षा के साथ भेज सकती है। उस खतरे को उच्च गंभीरता, प्रशंसनीय संभावना रेट किया गया है।

जोखिम-नियंत्रण लूप पर काम करते हुए, टीम चेतावनियों पर डिज़ाइन को प्राथमिकता देती है। वे एक मजबूर करने वाला फ़ंक्शन जोड़ते हैं ताकि एक तत्काल क्लिनिकल फ्लैग को रूटिंग लॉजिक द्वारा चुपचाप ओवरराइड न किया जा सके, एक सामंजस्य रिपोर्ट जिसे एक क्लिनिशियन दैनिक समीक्षा करता है, और — पदानुक्रम में सबसे निचला — एक प्रशिक्षण नोट। अवशिष्ट जोखिम को फिर से रेट किया जाता है और स्वीकार्य और ALARP माना जाता है; CSO रिकॉर्ड करता है क्यों। क्योंकि उपकरण केवल रूट करता है और स्वयं निदान नहीं करता, टीम इसे SaMD सीमा को पूरा न करने के रूप में आकलित करती है, उस तर्क को दस्तावेज़ीकृत करती है, और इसे दाखिल करती है। मानव-कारक परीक्षण एक अलग समस्या पकड़ता है: एक अति-उत्सुक "डुप्लिकेट रेफरल" अलर्ट इतनी बार बजता है कि GP पहले से ही इसे नज़रअंदाज़ कर रहे हैं, इसलिए इसे केवल वास्तविक डुप्लिकेट पर ट्रिगर करने के लिए फिर से डिज़ाइन किया जाता है।

लाइव-गो पर DCB0160 सुरक्षा मामला CSO द्वारा अनुमोदित किया जाता है, प्रोग्राम निदेशक द्वारा नहीं। तीन हफ्ते बाद, एक LFPSE रिपोर्ट और एक रिसेप्शनिस्ट द्वारा चिह्नित एक निकट-चूक एक नया खतरा प्रकट करती है — एक मुक्त-पाठ फ़ील्ड का उपयोग उस तत्काल जानकारी को तस्करी करने के लिए किया जा रहा है जिसे रूटिंग कभी नहीं देखती। PSIRF के तहत, एक आनुपातिक, प्रणाली-आधारित समीक्षा चलती है, खतरा लॉग में प्रवेश करता है, एक डिज़ाइन परिवर्तन निर्धारित किया जाता है, और उसी सप्ताह एक अंतरिम नियंत्रण ब्रीफ किया जाता है। सुरक्षा मामला एक जीवंत तर्क है, और रिकॉर्ड ठीक-ठीक दिखाता है कि हर खतरे के बारे में कैसे तर्क किया गया था — जो एक निरीक्षक, एक कोरोनर, या दो साल बाद एक नए CSO को चाहिए होगा।

क्षेत्र दृष्टिकोण#

हर किसी का क्लिनिकल जोखिम को नियंत्रित करने का एक ही कर्तव्य है, लेकिन तंत्र, प्रोत्साहन, और दबाव संगठन के अनुसार तीव्रता से भिन्न होते हैं।

स्टार्टअप#

एक डिजिटल-स्वास्थ्य स्टार्टअप अक्सर क्लिनिकल सुरक्षा को खरीद द्वार के रूप में मिलता है: एक NHS खरीदार DTAC और एक DCB0129 सुरक्षा मामला मांगता है, और एक भागदौड़ होती है। जीतने वाला कदम पहले स्प्रिंट से क्लिनिकल जोखिम प्रबंधन को शामिल करना है — बैकलॉग के साथ एक खतरा लॉग, एक सुलभ Clinical Safety Officer (अक्सर नियोजित के बजाय अनुबंधित, लेकिन वास्तव में सक्षम और सशक्त) — क्योंकि एक तैयार उत्पाद पर एक सुरक्षा मामले को पूर्वव्यापी रूप से फिट करना धीमा, महंगा, और अविश्वसनीय है। संस्थापकों को SaMD प्रश्न का ईमानदारी से और जल्दी सामना भी करना चाहिए, क्योंकि मध्य-पैमाने पर यह खोज करना कि उत्पाद एक अपंजीकृत चिकित्सा उपकरण है एक अस्तित्वगत कानूनी और सुरक्षा जोखिम है। अच्छी तरह से किया गया, परिपक्व क्लिनिकल सुरक्षा कलाकृतियां एक व्यावसायिक संपत्ति बन जाती हैं जो NHS बिक्री चक्रों को छोटा करती हैं।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, एक घरेलू-देखभाल एजेंसी, एक एकल-साइट क्लिनिक, या पूर्व-राजस्व चरण से आगे एक छोटा स्वास्थ्य-तकनीक आपूर्तिकर्ता — डिजिटल सिस्टम तैनात और कॉन्फ़िगर करते समय एक बड़े ट्रस्ट के समान DCB0160 कर्तव्य उठाता है, लेकिन इसे निभाने के लिए बिना किसी अतिरिक्त क्षमता के। शायद ही कभी पेरोल पर एक समर्पित CSO या सुरक्षा विश्लेषक होता है, इसलिए व्यावहारिक मार्ग एक सक्षम, अभ्यास करने वाले क्लिनिशियन को अनुबंधित आधार पर खरीदना और एक दुबला लेकिन वास्तविक खतरा लॉग रखना है, यह दिखावा करने के बजाय कि कर्तव्य लागू नहीं होता। सबसे तीव्र स्थानीय खतरे आमतौर पर कॉन्फ़िगरेशन और वर्कफ़्लो होते हैं — साझा रिकॉर्ड कैसे सेट किया गया है, तत्काल फ्लैग कैसे संभाले जाते हैं, एक अंशकालिक प्रशासक का वर्कअराउंड एक रूटिंग जोखिम कैसे बन जाता है — ठीक वे खतरे जिन्हें एक आपूर्तिकर्ता का DCB0129 मामला कभी कवर नहीं करता। आनुपातिकता यहां छोटे प्रदाता की दोस्त है: अपने पास मौजूद थोड़े से आश्वासन समय को उच्चतम-परिणाम खतरों पर केंद्रित करें, उत्पाद चुनते समय DTAC और आपूर्तिकर्ता के सुरक्षा मामले को एक फर्श के रूप में उपयोग करें, और अकेले पूरी मशीनरी बनाने की कोशिश करने के बजाय ICS क्लिनिकल-सुरक्षा समर्थन जैसे साझा संसाधनों पर झुकें।

बड़ा संगठन#

एक NHS ट्रस्ट या ICS दोहरी जवाबदेही उठाता है: यह DCB0160 के तहत दूसरों के सिस्टम तैनात करता है और अक्सर DCB0129 के तहत अपना खुद का बनाता या भारी रूप से कॉन्फ़िगर करता है। विशिष्ट विफलता संस्थागत है — एक प्रमुख इलेक्ट्रॉनिक रोगी रिकॉर्ड कार्यक्रम जिसकी लाइव-गो तारीख का राजनीतिक भार है, इसलिए CSO की सावधानी को चुपचाप एक बाधा के रूप में माना जाता है। उपाय संरचनात्मक है: CSO को स्वतंत्रता और एक वास्तविक वीटो दें, लॉन्च-दिन के दस्तावेज़ों की एक शेल्फ के बजाय संपत्ति में एक जीवंत खतरा लॉग रखें, और LFPSE और PSIRF सीखने को क्लिनिकल जोखिम प्रबंधन में एक स्थायी प्रक्रिया के रूप में वापस वायर करें। उद्यम पैमाने पर सबसे बड़े खतरे एकीकरण और कॉन्फ़िगरेशन खतरे हैं, जिन्हें कोई आपूर्तिकर्ता आश्वासन कवर नहीं करता, इसलिए स्थानीय स्वामित्व गैर-परक्राम्य है।

सरकार#

एक राष्ट्रीय निकाय — NHS England, MHRA, DHSC, NICE — वे मानक निर्धारित करता है जिन्हें दूसरों को पूरा करना चाहिए, इसलिए इसके काम करने के तरीके पूरी प्रणाली को आकार देते हैं: DCB0129/0160, DTAC, और SaMD विनियमन जनसंख्या-पैमाने की सुरक्षा के उपकरण हैं। यहां निर्णय नियामक, संसदीय, और सार्वजनिक जांच आकर्षित करते हैं, और एक राष्ट्रीय रूप से अनिवार्य सिस्टम जो एक अव्यक्त खतरा रखता है उस नुकसान को लाखों में वितरित करता है इससे पहले कि कोई पैटर्न देखे। दायित्व हैं प्रकाशित मानकों में स्पष्ट रूप से बनाई गई आनुपातिकता, अवशिष्ट जोखिम के बारे में पारदर्शिता, और नियामक ढांचे को वर्तमान रखना क्योंकि प्रौद्योगिकी — विशेष रूप से AI — इससे आगे निकल जाती है (देखें विषय 8.4 — AI और उभरती प्रौद्योगिकी प्रशासन)। इस पैमाने पर विशिष्ट जोखिम प्रणालीगत है: पतले सुरक्षा साक्ष्य पर पूरी संपत्ति में एक प्रौद्योगिकी को अनिवार्य करना एक साथ हर जगह एक खतरे को गहरा करता है।

सामान्य विफलता मोड#

  • अंत में जोड़ी गई सुरक्षा। एक द्वार को संतुष्ट करने के लिए लाइव-गो से एक हफ्ते पहले एक सुरक्षा मामला बनाना। उपाय: डिस्कवरी पर खतरा लॉग खोलें; सबसे बड़े खतरों को डिज़ाइन से बाहर करें।
  • स्थानीय सुरक्षा के लिए गलती से समझा गया आपूर्तिकर्ता आश्वासन। एक DCB0129 मामले और DTAC पास को अपनी तैनाती को कवर करने के रूप में मानना। उपाय: अपने DCB0160 मूल्यांकन और स्थानीय खतरा लॉग का स्वामित्व लें।
  • रबर स्टैंप के रूप में CSO। एक Clinical Safety Officer जिसके पास "अभी नहीं" कहने का समय, स्वतंत्रता, या अधिकार नहीं है। उपाय: भूमिका की रक्षा करें और हस्ताक्षर को एक वास्तविक द्वार बनाएं।
  • मृत खतरा लॉग। एक दस्तावेज़ जो एक बार लिखा गया और लॉन्च के बाद कभी फिर से नहीं देखा गया। उपाय: इसे जीवंत रखें; इसमें घटनाओं और परिवर्तनों को फीड करें।
  • अलर्ट अधिभार। इतनी सारी चेतावनियां कि क्लिनिशियन उन सभी को नज़रअंदाज़ करते हैं, जिनमें महत्वपूर्ण वाली भी शामिल हैं। उपाय: मानव-कारक डिज़ाइन; हर अलर्ट को अपनी जगह अर्जित करनी चाहिए।
  • दोष संस्कृति। निकट-चूकों के लिए व्यक्तियों को दंडित करना, ताकि रिपोर्टिंग सूख जाए। उपाय: PSIRF के साथ संरेखित एक न्यायसंगत, प्रणाली-आधारित संस्कृति।
  • छूटी हुई नियामक सीमा। SaMD को इसे एक विनियमित उपकरण के रूप में पहचाने बिना भेजना। उपाय: जल्दी चिकित्सा-उपकरण स्थिति का आकलन और दस्तावेज़ीकरण करें।

परिपक्वता मॉडल#

आयाम शुरुआत विकास मानकीकरण प्रबंधन संचालन
क्लिनिकल सुरक्षा प्रशासन कोई CSO नहीं; तदर्थ CSO नामित लेकिन कम-सशक्त सक्षम CSO वास्तविक वीटो के साथ; हस्ताक्षर एक द्वार है हर रिलीज़ के विरुद्ध CSO हस्ताक्षर ट्रैक किया गया; स्वतंत्रता और निर्णय सुनिश्चित और बोर्ड को रिपोर्ट किए गए CSO स्वतंत्रता और अधिकार एम्बेडेड; सुरक्षा डिलीवरी का नेतृत्व करती है
खतरा प्रबंधन कोई खतरा लॉग नहीं लॉन्च के लिए लॉग लिखा गया, फिर स्थिर डिस्कवरी में खोला गया जीवंत लॉग, नियंत्रण लूप के माध्यम से काम किया गया खतरे मापे गए — अवशिष्ट-जोखिम रुझान, नियंत्रण स्थिति, और अतिदेय कार्रवाइयां लक्ष्य तक ट्रैक और प्रबंधित घटनाओं, परिवर्तनों, और निकट-चूकों से लॉग लगातार अपडेट
DCB0129 / DCB0160 दोनों में से कोई लागू नहीं आपूर्तिकर्ता का मामला पर्याप्त माना गया दोनों मानक लागू; स्थानीय खतरे स्वामित्व में अनुपालन सक्रिय रूप से प्रबंधित — मूल्यांकन KPI के विरुद्ध सुनिश्चित, अंतराल ट्रैक और समय पर बंद आनुपातिक, नियमित, और डिलीवरी जीवनचक्र के साथ एकीकृत
मानव कारक और डिज़ाइन केवल चेतावनियां और प्रशिक्षण कुछ उपयोगिता परीक्षण डिज़ाइन-आउट पसंदीदा; भार के लिए अलर्ट क्यूरेट किए गए लक्ष्यों के विरुद्ध अलर्ट भार और उपयोगिता परिणाम मापे गए; अलार्म थकान मात्राबद्ध और प्रबंधित यथार्थवादी मानव-कारक परीक्षण एम्बेडेड; अलार्म थकान निगरानी में
घटना सीखना और संस्कृति दोष; निकट-चूक छुपाई गई घटनाएं लॉग की गईं लेकिन फीड नहीं की गईं LFPSE/PSIRF सीखना खतरा लॉग अपडेट करता है रिपोर्टिंग और सीखना मापा गया — निकट-चूक दरें, प्रतिक्रिया समय, और कार्रवाई समापन ट्रैक और प्रशासित न्यायसंगत संस्कृति; निकट-चूक सुधार के लिए सक्रिय रूप से खोदी गईं

जांच-सूची#

  • हर सिस्टम के लिए एक सक्षम, अभ्यास करने वाला, प्रशिक्षित Clinical Safety Officer नामित है, "अभी नहीं" कहने के समय और अधिकार के साथ।
  • दायरे में हर सिस्टम के लिए एक क्लिनिकल जोखिम प्रबंधन फ़ाइल, जीवंत खतरा लॉग, और क्लिनिकल सुरक्षा मामला मौजूद है।
  • खतरा पहचान डिस्कवरी में शुरू हुई, कमरे में फ्रंटलाइन क्लिनिशियनों के साथ।
  • तैनात करने वाले संगठन ने अपना स्वयं का DCB0160 मूल्यांकन चलाया है, केवल आपूर्तिकर्ता के DCB0129 मामले को स्वीकार नहीं किया।
  • जोखिम नियंत्रण प्रशिक्षण पर अलर्ट पर डिज़ाइन-आउट को प्राथमिकता देते हैं, अवशिष्ट जोखिम को ALARP तक कम और उचित ठहराया गया।
  • चिकित्सा-उपकरण / SaMD स्थिति का आकलन और दस्तावेज़ीकरण किया गया है, और प्रासंगिक होने पर MHRA / IEC 62304 दायित्व शामिल किए गए हैं।
  • DTAC को एक फर्श के रूप में पूरा किया गया है, स्थानीय क्लिनिकल जोखिम प्रबंधन के साथ जोड़ा गया है।
  • यथार्थवादी परिस्थितियों के तहत मानव-कारक और उपयोगिता परीक्षण किया गया है; अलर्ट भार नियंत्रित है।
  • लाइव घटनाएं (LFPSE) और PSIRF सीखना एक स्थायी प्रक्रिया के रूप में खतरा लॉग में वापस फीड होते हैं।
  • निकट-चूकों की रिपोर्टिंग और सुरक्षा आधार पर एक लॉन्च को चुनौती देना दृश्यमान रूप से सुरक्षित और अपेक्षित है।

मुख्य स्रोत#

  • NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems।
  • NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems।
  • NHS England — Clinical Safety Officer training और क्लिनिकल जोखिम प्रबंधन मार्गदर्शन।
  • NHS England — Digital Technology Assessment Criteria (DTAC)।
  • MHRA — Software and Artificial Intelligence (AI) as a Medical Device मार्गदर्शन।
  • IEC — IEC 62304: Medical device software — software life cycle processes।
  • ISO — ISO 14971: Application of risk management to medical devices।
  • NHS England — Learn from Patient Safety Events (LFPSE) सेवा।
  • NHS England — Patient Safety Incident Response Framework (PSIRF)।
  • World Health Organization — Global Patient Safety Action Plan 2021–2030।

संदर्भ#

  1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
  2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
  3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
  4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
  5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
  6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
  7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
  8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
  9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
  10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
  11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
  12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
  13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
  14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
  15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
  16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
  17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
  18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
  19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
  20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan

GitHub पर इस पृष्ठ को संपादित करें — पुस्तक सत्य का स्रोत है; यह साइट इसे प्रस्तुत करती है।