বিষয় 1.6 — ক্লিনিক্যাল নিরাপত্তা ও ঝুঁকি ব্যবস্থাপনা

এক বাক্যে: ক্লিনিক্যাল নিরাপত্তা হলো আপনার ডিজিটাল প্রযুক্তি যেসব উপায়ে একজন রোগীর ক্ষতি করতে পারে তা খুঁজে বের করার এবং সেই বিপদগুলো কারও কাছে পৌঁছানোর আগেই নিয়ন্ত্রণ করার শৃঙ্খলাবদ্ধ, প্রমাণসমৃদ্ধ চর্চা, অর্থাৎ প্রথম স্কেচ থেকে নকশায় অন্তর্ভুক্ত নিরাপত্তা, গো-লাইভের আগে জুড়ে দেওয়া নয়।

স্বাস্থ্য ও পরিচর্যায় কেন এটি গুরুত্বপূর্ণ#

বেশির ভাগ খাতে একটি সফটওয়্যার ত্রুটি একটি অসুবিধা: একটি পাতা লোড হয় না, একটি অর্ডার নকল হয়, একটি রিপোর্ট দেরিতে আসে। স্বাস্থ্য ও পরিচর্যায় একই শ্রেণির ত্রুটি প্রাণ নিতে পারে। একটি ওষুধের ঘরে দশমিক বিন্দু ছেঁটে ফেলা, একটি ফলাফল স্ক্রিনে ভুল রোগী দেখানো, একটি ট্রিয়াজ অ্যালগরিদম নীরবে একটি উপসর্গ চিহ্নিত করা বন্ধ করা, একটি ইন্টিগ্রেশন নীরবে অ্যালার্জির রেকর্ড ফেলে দেওয়া, প্রতিটিই একটি সফটওয়্যার বাগ, এবং প্রতিটিই গুরুতর ক্ষতি বা মৃত্যু ঘটাতে সক্ষম একটি ক্লিনিক্যাল বিপদ। সে কারণেই ক্লিনিক্যাল নিরাপত্তা ভালো প্রকৌশলের ওপর স্তরিত মানের সৌজন্য নয়; এটি নিজস্ব মান, ভূমিকা ও প্রমাণসহ একটি স্বতন্ত্র, নিয়ন্ত্রিত শৃঙ্খলা।

ঝুঁকি অসমমিত এবং প্রায়ই অদৃশ্য। যখন একটি ডিজিটাল সিস্টেম কাজ করে, কেউ দেখে না সে কোন ক্ষতি ঠেকিয়েছে; যখন ব্যর্থ হয়, ক্ষতি ভয়াবহ হতে পারে, বিলম্বিত এবং কেউ নকশা লক্ষ করার আগে হাজার হাজার রোগী জুড়ে ছড়ানো। এই সংমিশ্রণ, উচ্চ পরিণাম, নিম্ন দৃশ্যমানতা, প্রশস্ত বিস্ফোরণ-ব্যাসার্ধ, মানে আপনি সমস্যা ধরতে ব্যবহারকারীদের ওপর বা সবকিছু শেখাতে ঘটনার ওপর নির্ভর করতে পারেন না। আপনাকে ক্ষতি নিয়ে সক্রিয়ভাবে যুক্তি করতে হবে, মোতায়েনের আগে, এবং সিস্টেম লাইভ থাকাকালীনও তা করে যেতে হবে। যুক্তরাজ্যে এই সক্রিয় যুক্তি ঐচ্ছিক নয়: NHS প্রতিষ্ঠান ও তাদের সরবরাহকারীদের চুক্তিগতভাবে ও পেশাগতভাবে জাতীয় ক্লিনিক্যাল ঝুঁকি ব্যবস্থাপনা মান প্রয়োগ করতে এবং নিজেদের কাজ দেখাতে সক্ষম হতে প্রত্যাশা করা হয়। এটি ঠিক করা প্রমাণ (বিষয় 1.3 — প্রমাণ-চালিত সিদ্ধান্ত দেখুন), তথ্য গভর্ন্যান্স ও সাইবার নিরাপত্তা (বিষয় 1.7 — তথ্য গভর্ন্যান্স, ডেটা সুরক্ষা ও সাইবার নিরাপত্তা দেখুন), এবং সেবা লাইভ হওয়ার পর কীভাবে চালান তা (বিষয় 3.8 — সেবা ব্যবস্থাপনা ও লাইভ অপারেশন্স দেখুন) থেকে অবিচ্ছেদ্য।

মূল ধারণা#

রোগী নিরাপত্তা ও ঝুঁকি ব্যবস্থাপনা। রোগী নিরাপত্তা হলো পরিচর্যা থেকে রোগীদের ক্ষতির প্রতিরোধ, হ্রাস, প্রতিবেদন ও বিশ্লেষণ। ক্লিনিক্যাল ঝুঁকি ব্যবস্থাপনা ঝুঁকি ব্যবস্থাপনার সাধারণ শৃঙ্খলা, ঝুঁকি চিহ্নিত, মূল্যায়ন, অগ্রাধিকার ও নিয়ন্ত্রণ করা, প্রয়োগ করে একটি স্বাস্থ্য IT সিস্টেম কীভাবে রোগীর ক্ষতিতে অবদান রাখতে পারে সেই নির্দিষ্ট প্রশ্নে। ইংল্যান্ডে এটি শাসন করা দুটি জাতীয় মান হলো DCB0129 ও DCB0160 (DCB-র অর্থ Data Coordination Board; এগুলো Health and Social Care Act 2012-এর অধীনে বাধ্যতামূলক Standardization Committee for Care Information / SCCI মান)। 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. একটি জীবন্ত বিপদ-লগ রাখুন, লঞ্চের দিনের নথি নয়। বিপদ-লগকে একটি স্থায়ী রেজিস্টার হিসেবে দেখুন যা ডিসকভারিতে খোলে এবং সিস্টেম লাইভ থাকাকালীন কখনো বন্ধ হয় না। প্রতিটি বিপদ তার কারণ, সম্ভাব্য ক্ষতি, প্রাথমিক ঝুঁকি রেটিং, প্রয়োগ করা নিয়ন্ত্রণ এবং নিয়ন্ত্রণের পর অবশিষ্ট ঝুঁকি লিপিবদ্ধ করে। যখন একটি ঘটনা, পরিবর্তন বা প্রায়-দুর্ঘটনা একটি নতুন বিপদ প্রকাশ করে, তা লগে ঢোকে এবং একই চক্রে কাজ করা হয়: লগ হলো আপনার নিরাপত্তা-যুক্তির স্মৃতি।

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. আমরা কি বিপদ নকশা থেকে বাদ দিচ্ছি, নাকি নীরবে এমন সতর্কতা ও সাবধানবাণী জমা করছি যা আমাদের চিকিৎসকরা ইতিমধ্যে উপেক্ষা করতে শিখেছেন? বিষয়টি শক্তি অনুযায়ী নিয়ন্ত্রণগুলো সাজায়: বিপদ নকশা থেকে বাদ দেওয়া একটি স্ক্রিন-সতর্কতাকে হারায়, যা প্রশিক্ষণ ম্যানুয়ালের একটি লাইনকে হারায়, তবু সতর্কতা হলো সবচেয়ে কম বাধার পথ, কারণ একটি সাবধানবাণী যোগ করা দ্রুত ও দায়িত্বশীল মনে হয় অথচ একটি কর্মপ্রবাহ নতুন করে নকশা করা ধীর ও বিতর্কিত। সময়ের সঙ্গে এই ঝোঁক সতর্কতা-ক্লান্তিতে জমে: এত সাবধানবাণী বাজে যে চিকিৎসকরা সবগুলো, গুরুত্বপূর্ণটিসহ, প্যাটার্ন-মিলিয়ে পার করে যান, তাই প্রতিটি নতুন সতর্কতা আসলে নিরাপত্তা কমাতে পারে। প্রকৃত টানাপোড়েন হলো প্রতিটি অপ্রয়োজনীয় সতর্কতার একজন পৃষ্ঠপোষক আছেন যিনি কোনো ঘটনার পর সদ্ভাবে তা যোগ করেছিলেন, যা সাবধানবাণী সরানো রাজনৈতিকভাবে কঠিন করে এমনকি যখন তা সিস্টেমকে ক্ষয় করছে। এখানে মানবিক উপাদান হলো শৃঙ্খলা, এমনভাবে নকশা করা যাতে ব্যস্ত, বিঘ্নিত ব্যবহারকারী রাত ৩টায় একটি স্ক্রিন পড়ার সময় নিরাপদ কাজ সহজ, ডিফল্ট কাজ হয়, এবং বাস্তবসম্মত অবস্থায় ব্যবহারযোগ্যতা পরীক্ষা একটি ক্লিনিক্যাল-নিরাপত্তা কার্যক্রম, নকশার সৌজন্য নয়। আপনার দলগুলো আসলে ব্যবহার করে এমন একটি সিস্টেম পরীক্ষা করুন এবং জিজ্ঞাসা করুন একটি সাধারণ কাজে একজন চিকিৎসক কতগুলো সতর্কতার মুখোমুখি হন, তার কোনগুলো সত্যিই আচরণ বদলায়, এবং কোথায় একটি বাধ্যকারী ফাংশন বা ভালো ডিফল্ট একটি সাবধানবাণীকে সম্পূর্ণ প্রতিস্থাপন করতে পারত। ভালো উত্তর আরেকটি সতর্কতা যোগ করার প্রতিবর্ত প্রতিহত করে, সতর্কতার ভারকে নিজেই একটি পরিমাপযোগ্য বিপদ হিসেবে দেখে, এবং যে সাবধানবাণী আর নিজের জায়গা অর্জন করে না তা সরাতে ইচ্ছুক।

6. আমাদের লাইভ সিস্টেম, ইন্টিগ্রেশন ও ক্লিনিক্যাল পথ সময়ের সঙ্গে সরে গেলে, আমাদের নিরাপত্তা কেস এখনো টিকে আছে তা আমরা কীভাবে জানব? ক্লিনিক্যাল নিরাপত্তা গো-লাইভে শেষ হয় না; লাইভ সিস্টেম নতুন বিপদ তৈরি করে, এবং সিস্টেমের চারপাশের জগৎ সরতেই থাকে: একটি উজানের ইন্টিগ্রেশন তার ডেটা বদলায়, একটি ক্লিনিক্যাল পথ নতুন করে নকশা হয়, একজন সরবরাহকারী একটি আপডেট পাঠায়, একটি নতুন রোগী কোহর্ট হাতিয়ারটি ব্যবহার শুরু করে। দুই বছর আগে অনুমোদিত একটি নিরাপত্তা কেস এমন একটি সিস্টেম ও প্রেক্ষাপট বর্ণনা করে যা হয়তো আর নেই, তাই প্রশ্ন হলো আপনার বিপদ-লগ একটি জীবন্ত রেজিস্টার, নাকি একবার সই করে পচতে ফেলে রাখা নথি (বিষয় 3.8 — সেবা ব্যবস্থাপনা ও লাইভ অপারেশন্স দেখুন)। টানাপোড়েন হলো লঞ্চের পর নিরাপত্তা-যুক্তি রক্ষণাবেক্ষণ একই দুষ্প্রাপ্য CSO ও ক্লিনিক্যাল সময়ের জন্য নতুন ডেলিভারির সঙ্গে প্রতিযোগিতা করে, এবং বিচ্যুতি ক্রমিক ও অদৃশ্য এমনভাবে যে কিছু ব্যর্থ না হওয়া পর্যন্ত তা কদাচিৎ মনোযোগ দাবি করে। মূর্ত কৌশলগুলোর মধ্যে আছে কনফিগারেশন বা ইন্টিগ্রেশন বদলালে বিপদ মূল্যায়ন পুনঃসূচনাকারী পরিবর্তন নিয়ন্ত্রণ, সর্বোচ্চ-পরিণামের বিপদের পর্যায়ক্রমিক পর্যালোচনা, এবং একটি নিয়ন্ত্রণ নীরবে ক্ষয় হলে আসলে তা শনাক্ত করবে এমন পর্যবেক্ষণ। এক বছর বা তার বেশি সময় ধরে লাইভ থাকা একটি সিস্টেম বেছে নিন এবং জিজ্ঞাসা করুন তার বিপদ সর্বশেষ কখন পর্যালোচিত হয়েছিল, অনুমোদনের পর থেকে তার নিচে কী বদলেছে, এবং একটি মূল নিয়ন্ত্রণ কাজ করা বন্ধ করলে কে লক্ষ করবে। সৎ উত্তর প্রকৃত চলমান নিরাপত্তা ব্যবস্থাপনাসহ সিস্টেমকে বাসি নিরাপত্তা কেসে ভেসে চলা সিস্টেম থেকে আলাদা করে, এবং কেবল ক্যালেন্ডার নয়, প্রকৃত পরিবর্তনের সঙ্গে যুক্ত পর্যালোচনার একটি আনুপাতিক ছন্দে প্রতিশ্রুতিবদ্ধ হয়।

বাস্তবে: স্বাস্থ্য ও পরিচর্যার একটি উদাহরণ#

একটি সমন্বিত পরিচর্যা ব্যবস্থা (ICS) একটি ভাগ করা ই-রেফারাল হাতিয়ার মোতায়েন করছে যা জিপিদের সরাসরি কমিউনিটি সেবায় রোগী রেফার করতে দেয়, একটি অন্তর্নির্মিত ট্রিয়াজ নিয়ম-সেটসহ যা জরুরি কেসগুলোকে একটি দ্রুততর সারিতে পাঠায়। একটি ডেলিভারি-চালিত পদ্ধতি সরবরাহকারীর DCB0129 নিরাপত্তা কেস নিত, DTAC পাস করত, এবং বোর্ডের প্রতিশ্রুত তারিখ ধরতে লাইভ হতো।

তার বদলে, প্রোগ্রাম ক্লিনিক্যাল নিরাপত্তা প্রশিক্ষণসহ একজন অনুশীলনরত জিপিকে Clinical Safety Officer হিসেবে নিয়োগ দেয় এবং নকশার শুরুতে একটি ক্লিনিক্যাল ঝুঁকি ব্যবস্থাপনা ফাইল ও বিপদ-লগ খোলে। জিপি, কমিউনিটি নার্স ও প্রশাসকদের সঙ্গে প্রাথমিক বিপদ কর্মশালা এমন কয়েকটি বিপদ প্রকাশ করে যা সরবরাহকারীর পণ্য-স্তরের কেস কখনো স্পর্শ করেনি, সবই স্থানীয় মোতায়েন থেকে উদ্ভূত। সবচেয়ে খারাপ: ট্রিয়াজ নিয়ম ICS-এর নিজস্ব সেবা-সংজ্ঞার বিপরীতে কনফিগার করা হয়েছিল, এবং একটি ম্যাপিং ত্রুটি একটি জরুরি ত্বকের-ক্যানসার রেফারালকে কয়েক সপ্তাহের অপেক্ষাসহ একটি রুটিন ডার্মাটোলজি সারিতে পাঠাতে পারত। সেই বিপদ উচ্চ তীব্রতা, বিশ্বাসযোগ্য সম্ভাবনা হিসেবে রেট করা হয়।

ঝুঁকি-নিয়ন্ত্রণ চক্রে কাজ করে দল সাবধানবাণীর চেয়ে নকশাকে প্রাধান্য দেয়। তারা একটি বাধ্যকারী ফাংশন যোগ করে যাতে একটি জরুরি ক্লিনিক্যাল পতাকা রাউটিং যুক্তি দ্বারা নীরবে অগ্রাহ্য করা না যায়, একটি সমন্বয় রিপোর্ট যা একজন চিকিৎসক প্রতিদিন পর্যালোচনা করেন, এবং, স্তরক্রমে সবচেয়ে নিচে, একটি প্রশিক্ষণ নোট। অবশিষ্ট ঝুঁকি পুনরায় রেট করা হয় এবং গ্রহণযোগ্য ও ALARP বিবেচিত হয়; CSO কেন তা লিপিবদ্ধ করেন। যেহেতু হাতিয়ারটি কেবল রাউট করে এবং নিজে রোগ নির্ণয় করে না, দল একে SaMD সীমা পূরণ করে না বলে মূল্যায়ন করে, সেই যুক্তি নথিবদ্ধ করে এবং ফাইল করে। মানবিক-উপাদান পরীক্ষা একটি আলাদা সমস্যা ধরে: একটি অতি-উৎসাহী "নকল রেফারাল" সতর্কতা এত ঘন ঘন বাজে যে জিপিরা ইতিমধ্যে তা উপেক্ষা করছেন, তাই তা কেবল প্রকৃত নকলে ট্রিগার করার জন্য নতুন করে নকশা করা হয়।

গো-লাইভে DCB0160 নিরাপত্তা কেস অনুমোদন করেন CSO, প্রোগ্রাম পরিচালক নন। তিন সপ্তাহ পরে, একটি LFPSE প্রতিবেদন ও একজন রিসেপশনিস্টের চিহ্নিত প্রায়-দুর্ঘটনা একটি নতুন বিপদ প্রকাশ করে: একটি ফ্রি-টেক্সট ঘর ব্যবহার করে জরুরি তথ্য ঢুকিয়ে দেওয়া হচ্ছে যা রাউটিং কখনো দেখে না। PSIRF-এর অধীনে একটি আনুপাতিক, ব্যবস্থা-ভিত্তিক পর্যালোচনা চলে, বিপদটি লগে ঢোকে, একটি নকশা পরিবর্তন নির্ধারিত হয়, এবং একই সপ্তাহে একটি অন্তর্বর্তী নিয়ন্ত্রণ জানানো হয়। নিরাপত্তা কেস একটি জীবন্ত যুক্তি, এবং নথি ঠিক দেখায় প্রতিটি বিপদ নিয়ে কীভাবে যুক্তি করা হয়েছিল, যা একজন পরিদর্শক, একজন করোনার, বা দুই বছর পরে একজন নতুন CSO-র প্রয়োজন হবে।

খাতভিত্তিক দৃষ্টিকোণ#

ক্লিনিক্যাল ঝুঁকি নিয়ন্ত্রণের একই দায়িত্ব সবার, কিন্তু যন্ত্র, প্রণোদনা ও চাপ প্রতিষ্ঠান অনুযায়ী তীক্ষ্ণভাবে ভিন্ন।

স্টার্ট-আপ#

একটি ডিজিটাল-স্বাস্থ্য স্টার্ট-আপ প্রায়ই ক্লিনিক্যাল নিরাপত্তার মুখোমুখি হয় একটি ক্রয় গেট হিসেবে: একজন NHS ক্রেতা DTAC ও একটি DCB0129 নিরাপত্তা কেস চান, এবং একটি হুড়োহুড়ি লাগে। বিজয়ী পদক্ষেপ হলো প্রথম স্প্রিন্ট থেকে ক্লিনিক্যাল ঝুঁকি ব্যবস্থাপনা গড়া, ব্যাকলগের পাশে একটি বিপদ-লগ, একজন সহজলভ্য Clinical Safety Officer (প্রায়ই নিযুক্ত নয়, চুক্তিভিত্তিক, কিন্তু সত্যিই সক্ষম ও ক্ষমতায়িত), কারণ একটি সমাপ্ত পণ্যে নিরাপত্তা কেস পরে জুড়ে দেওয়া ধীর, ব্যয়বহুল ও অবিশ্বাস্য। প্রতিষ্ঠাতাদেরও SaMD প্রশ্নের মুখোমুখি হতে হবে সততার সঙ্গে ও আগেভাগে, কারণ মাঝপথে বড় মাপে আবিষ্কার করা যে পণ্যটি একটি অনিবন্ধিত মেডিক্যাল ডিভাইস তা একটি অস্তিত্বগত আইনি ও নিরাপত্তা ঝুঁকি। ভালোভাবে করা হলে, পরিপক্ব ক্লিনিক্যাল নিরাপত্তা নিদর্শন একটি বাণিজ্যিক সম্পদ হয়ে NHS বিক্রয়-চক্র ছোট করে।

ক্ষুদ্র ব্যবসা#

একটি প্রতিষ্ঠিত ছোট প্রদানকারী, যেমন একটি জিপি প্র্যাকটিস, কমিউনিটি ফার্মেসি, কেয়ার হোম, গৃহভিত্তিক পরিচর্যা সংস্থা, একক-স্থানের ক্লিনিক, বা রাজস্ব-পূর্ব পর্যায় পেরোনো একটি ছোট স্বাস্থ্য-প্রযুক্তি সরবরাহকারী, ডিজিটাল সিস্টেম মোতায়েন ও কনফিগার করার সময় একটি বড় ট্রাস্টের মতো একই 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-কে নিয়ন্ত্রিত ডিভাইস হিসেবে চিনতে না পেরে পাঠানো। প্রতিষেধক: মেডিক্যাল-ডিভাইস অবস্থা আগেভাগে মূল্যায়ন ও নথিবদ্ধ করুন।

পরিপক্বতা মডেল#

চেকলিস্ট#

• প্রতিটি সিস্টেমের জন্য একজন সক্ষম, অনুশীলনরত, প্রশিক্ষিত 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