বিষয় 7.0 — দলের কাঠামো, ভূমিকা ও দায়িত্ব

এক বাক্যে: ডিজিটাল স্বাস্থ্য সরবরাহ সফল বা ব্যর্থ হয় আপনি দলগুলোর মধ্যে সীমানা কীভাবে আঁকেন এবং কে কী করে তা কতটা স্পষ্টভাবে নাম দেন তার ওপর, তাই মূল্যের দ্রুত, নিরাপদ প্রবাহের জন্য দল সাজান, বহুশাস্ত্রীয়ভাবে কর্মী দিন, এবং দায়িত্ব স্পষ্ট করুন।

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

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

NHS ও সামাজিক পরিচর্যায় আপনি সরকারি অর্থও ব্যয় করছেন এবং বিধিবদ্ধ দায়িত্ব বহন করছেন: DCB0129/DCB0160-এর অধীনে ক্লিনিক্যাল নিরাপত্তা, UK GDPR ও গোপনীয়তার সাধারণ-আইন দায়িত্বের অধীনে তথ্য গভর্ন্যান্স, এবং অ্যাক্সেসিবিলিটি বাধ্যবাধকতা। এই দায়িত্বগুলো শেষে জুড়ে দেওয়া যায় না। এগুলোকে দলের ভেতরে প্রতিনিধিত্ব করতে হবে, নামধারী মানুষদের দ্বারা যাদের তা পালনের কর্তৃত্ব ও সময় আছে।

কাঠামো ঠিক করুন এবং বহুশাস্ত্রীয় দল এমন কার্যকর সফটওয়্যার সরবরাহ করে যা চিকিৎসকরা বিশ্বাস করেন এবং রোগীরা ব্যবহার করতে পারেন। ভুল করুন এবং আপনি পাবেন ব্যস্ত বিশেষজ্ঞরা নিজেদের সাইলো অপ্টিমাইজ করছে যখন পুরো সেবা থেমে আছে, দেরি, বাজেট-অতিরিক্ত এবং নীরবে পরিত্যক্ত ডিজিটাল কর্মসূচির পেছনের ক্লাসিক ধরন।

মূল ধারণা#

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

টিম টপোলজি। একটি মডেল (Skelton ও Pais) যা কার্যকর দল নকশাকে চারটি মৌলিক ধরন ও তিনটি মিথস্ক্রিয়া মোডে সংকুচিত করে, সবই মূল্যের দ্রুত প্রবাহের সেবায়:

• স্ট্রিম-সংগত দল, কাজের একটি একক মূল্যবান ধারা (একটি সেবা, একটি ব্যবহারকারী যাত্রা, একটি পণ্য) ঘিরে সংগঠিত এবং এন্ড-টু-এন্ড এর মালিক। এটি ডিফল্ট দল ধরন; বেশির ভাগ মানুষের একটিতে থাকা উচিত।
• প্ল্যাটফর্ম দল, অভ্যন্তরীণ স্ব-সেবা সামর্থ্য সরবরাহ করে (ভাগ-করা অবকাঠামো, একটি ইন্টিগ্রেশন ইঞ্জিন, একটি লগইন সেবা, একটি শেয়ার্ড কেয়ার রেকর্ড API) যাতে স্ট্রিম-সংগত দলগুলো সেগুলো পুনরাবিষ্কার না করে দ্রুত যায়।
• সক্ষমকারী দল, বিশেষজ্ঞদের একটি সময়-সীমাবদ্ধ দল (যেমন ক্লিনিক্যাল নিরাপত্তা, অ্যাক্সেসিবিলিটি, টেস্ট অটোমেশন) যা একটি সামর্থ্য উন্নীত করতে অন্যদের কোচিং দেয়, তারপর সরে যায়।
• জটিল-উপব্যবস্থা দল, গভীর বিশেষজ্ঞ জ্ঞান প্রয়োজন এমন একটি অংশের মালিক (একটি ঝুঁকি-স্কোরিং অ্যালগরিদম, একটি NHS Spine ইন্টারফেস) যা একটি সাধারণ দলকে অতিভারাক্রান্ত করত।

তিনটি মিথস্ক্রিয়া মোড নিয়ন্ত্রণ করে যেকোনো দুটি দল কীভাবে সম্পর্কিত: সহযোগিতা (একটি সংজ্ঞায়িত সময়কালে ঘনিষ্ঠভাবে কাজ, উচ্চ-ব্যান্ডউইথ, জিনিস আবিষ্কার করতে কিছু অদক্ষতা সহ্য), X-as-a-service (একটি দল ন্যূনতম ঝামেলায় অন্যের সামর্থ্য ব্যবহার করে, মাপে নিম্ন-ঘর্ষণ ডিফল্ট), এবং সহায়ক (একটি দল অন্যটিকে শিখতে সাহায্য করে)। মোডের নাম দেওয়া দেরি ও দোষ লালন করা অস্পষ্টতা প্রতিরোধ করে।

জ্ঞানীয় ভার। একটি দল মাথায় কেবল এতটুকুই ধরে রাখতে পারে। টিম টপোলজি যুক্তি দেয় আপনার প্রতিটি দলের মালিকানাধীন ডোমেন এমন পরিসরে সীমিত করা উচিত যা সে নিরাপদে যুক্তি করতে পারে, ডোমেন ক্লিনিক্যাল হলে একটি নির্ণায়ক নীতি।

কনওয়ের সূত্র ও বিপরীত কনওয়ে কৌশল। যেহেতু স্থাপত্য প্রতিষ্ঠান কাঠামো অনুসরণ করে, একটি সামাজিক-প্রযুক্তিগত ব্যবস্থা দৃষ্টি যা দল ও প্রযুক্তিকে একটি নকশা হিসেবে দেখে, আপনি যে স্থাপত্য চান তা তৈরি করতে সুচিন্তিতভাবে দল আকার দিন। আপনি যদি একটি মডুলার, আন্তঃকার্যক্ষম পরিচর্যা রেকর্ড চান, এটি একটি একক পাথুরে দল দিয়ে গড়বেন না।

শ্রেষ্ঠ চর্চা#

1. প্রতিটি সেবার চারপাশে একটি পূর্ণ বহুশাস্ত্রীয় দল গঠন করুন। ন্যূনতমে, একজন পণ্য ব্যবস্থাপক, একজন সরবরাহ ব্যবস্থাপক, একজন ব্যবহারকারী গবেষক, একজন সেবা/মিথস্ক্রিয়া নকশাকার, প্রকৌশলী, এবং একটি ডেটা/বিশ্লেষণ সামর্থ্য, সঙ্গে নামধারী ক্লিনিক্যাল নিরাপত্তা ও তথ্য গভর্ন্যান্স ইনপুট অন্তর্ভুক্ত করুন। একটি শাস্ত্র-বিহীন দল হয় অন্য কারও জন্য অপেক্ষা করবে অথবা সেই কাজ এড়িয়ে যাবে, এবং স্বাস্থ্যে এড়িয়ে যাওয়া কাজ সাধারণত নিরাপত্তা, অ্যাক্সেসিবিলিটি বা গভর্ন্যান্স।

2. বেশির ভাগ দলকে স্ট্রিম-সংগত করুন এবং তাদের এন্ড-টু-এন্ড মালিকানা দিন। একটি প্রযুক্তি স্তর ঘিরে নয় (যেমন "ডেটাবেস দল"), একটি ব্যবহারকারীর যাত্রা ঘিরে সংগঠিত করুন (যেমন "আউটপেশেন্ট রেফারেল")। এন্ড-টু-এন্ড মালিকানা ফিডব্যাক লুপ ছোট করে এবং হ্যান্ড-অফ ফাঁক থামায় যেখানে ক্লিনিক্যাল ঝুঁকি জমে।

3. প্ল্যাটফর্মকে পণ্য হিসেবে গড়ুন, সেবা হিসেবে ব্যবহার করুন। আপনার ইন্টিগ্রেশন ইঞ্জিন, পরিচয় সেবা বা শেয়ার্ড কেয়ার রেকর্ড API-কে নিজস্ব দল, রোডম্যাপ ও ব্যবহারকারীসহ একটি অভ্যন্তরীণ পণ্য হিসেবে দেখুন। এটি "as-a-service" প্রকাশ করুন যাতে স্ট্রিম-সংগত দলগুলো টিকিট তুলে অপেক্ষা করার বদলে স্ব-সেবা নেয়।

4. দুষ্প্রাপ্য দক্ষতা জমানোর জন্য নয়, ছড়াতে সক্ষমকারী দল ব্যবহার করুন। ক্লিনিক্যাল নিরাপত্তা কর্মকর্তা, অ্যাক্সেসিবিলিটি বিশেষজ্ঞ ও নিরাপত্তা প্রকৌশলী বিরল। সেগুলো সরবরাহ দলকে উচ্চতর মানে কোচিং দিতে এবং তারপর এগিয়ে যেতে নিয়োজিত করুন, একটি স্থায়ী বোতলের গলা হয়ে ওঠার বদলে যার পেছনে প্রতিটি দল সারিবদ্ধ।

5. প্রতিটি ভূমিকা ও এর সিদ্ধান্ত অধিকার স্পষ্টভাবে নাম দিন। গুরুত্বপূর্ণ সিদ্ধান্তের জন্য একটি দায়িত্ব মডেল ব্যবহার করুন, RACI (Responsible, Accountable, Consulted, Informed) বা একটি সরলতর "সিদ্ধান্তদাতা/উপদেষ্টা" বিভাজন: ক্লিনিক্যাল নিরাপত্তা স্বাক্ষর, গো-লাইভ, তথ্য গভর্ন্যান্স অনুমোদন, ব্যয়। এখানে অস্পষ্টতাই জবাবদিহিতা বাষ্পীভূত হওয়ার জায়গা।

6. ক্লিনিক্যাল নিরাপত্তা কর্মকর্তাকে প্রকৃত কর্তৃত্ব ও প্রকৃত সময় দিন। DCB0129/0160 একজন নামধারী, যথাযথভাবে প্রশিক্ষিত ক্লিনিক্যাল নিরাপত্তা কর্মকর্তা দাবি করে যিনি একটি রিলিজ থামাতে পারেন। ভূমিকাটি দলে স্পষ্ট করুন, এর সময় রক্ষা করুন, এবং নিশ্চিত করুন এটি না বলতে পারে, কেবল নামে CSO একটি গভর্ন্যান্স ব্যর্থতা যা একটি ঘটনা দ্বারা আবিষ্কৃত হওয়ার অপেক্ষায়।

7. ডোমেন সীমিত করে জ্ঞানীয় ভার পরিচালনা করুন। একটি দল যদি অনেক বেশি সেবা বা অতি জটিল ক্লিনিক্যাল ডোমেনের মালিক হয়, তাকে ভাগ করুন। সংকেত লক্ষ্য করুন: যে দল আর আত্মবিশ্বাসের সঙ্গে নিজস্ব পরিবর্তনের নিরাপত্তা তাৎপর্য ব্যাখ্যা করতে পারে না সে অতিভারাক্রান্ত।

8. বিপরীত কনওয়ে কৌশল সুচিন্তিতভাবে প্রয়োগ করুন। আপনি যে স্থাপত্য ও আন্তঃকার্যক্ষমতা চান তার সঙ্গে মেলাতে দলের সীমানা আঁকুন, মডুলার, মান-ভিত্তিক (যেমন HL7 FHIR) সিস্টেমের জন্য মডুলার দল। একটি আকস্মিক সংগঠন চার্টকে আপনার পরিচর্যা রেকর্ড নকশা করতে দেবেন না।

দলের সঙ্গে আলোচনার প্রশ্ন#

1. আমাদের বর্তমান সংগঠন চার্ট কোথায় ইতোমধ্যে আমাদের জন্য আমাদের স্থাপত্য নকশা করছে, এবং সেটি কি আসলে আমরা যে স্থাপত্য চাই? কনওয়ের সূত্র ঐচ্ছিক নয়: আমাদের দলের আকার যাই হোক, সিস্টেম তা প্রতিফলিত করবে, তাই সৎ প্রথম পদক্ষেপ হলো আমাদের ইতোমধ্যে থাকা পরিচর্যা রেকর্ড, ইন্টিগ্রেশন ও হ্যান্ড-অফ দেখা এবং জিজ্ঞাসা করা কোন দলের সীমানা প্রতিটি সংযোগস্থল তৈরি করেছে। স্বাস্থ্য ও পরিচর্যা পরিবেশে সেই সংযোগস্থলগুলোই ক্লিনিক্যাল ঝুঁকি লুকানোর জায়গা, একটি খণ্ডিত রেকর্ড, একটি ভঙ্গুর Spine ইন্টারফেস, একটি নিরাপত্তা কেস যা কোনো একক দলের মালিকানাধীন নয়, তাই এটি একটি রোগী-নিরাপত্তা আলোচনা, নান্দনিক নয়। বিতর্কের টানাপোড়েন হলো আমরা যে স্থাপত্য চাই তা পেতে দলের সীমানা পুনঃআঁকা (বিপরীত কনওয়ে কৌশল) বিঘ্নকর, প্রতিষ্ঠিত জমিদারির জন্য হুমকি, এবং আমরা পুরোপুরি নিয়ন্ত্রণ করি না এমন অর্থায়ন ও লাইন-ব্যবস্থাপনা কাঠামো কেটে যায়। আপনার সবচেয়ে বেদনাদায়ক দুই-তিনটি ইন্টিগ্রেশন প্রতিটি প্রান্তের মালিক দলগুলোর সঙ্গে ফিরে মানচিত্রিত করুন, এবং জিজ্ঞাসা করুন একটি স্ট্রিম-সংগত সীমানা হ্যান্ড-অফ পুরোপুরি সরিয়ে দিত কি না। একটি ভালো উত্তর অন্তত একটি মূর্ত সীমানার নাম বলে যা আপনি সরাবেন, কে প্রতিরোধ করবে ও কেন সে বিষয়ে সৎ, এবং বিঘ্নের যোগ্য পরিবর্তন ও যেখানে একটি as-a-service ইন্টারফেস ঘর্ষণ আরও সস্তায় সমাধান করত তা আলাদা করে।

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

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

4. আমাদের কোন ভাগ-করা সামর্থ্য প্ল্যাটফর্ম হিসেবে as-a-service ব্যবহারের জন্য চালানো উচিত, এবং আমরা কি আসলে সেভাবে সম্পদ দিচ্ছি, নাকি কেবল একটি টিকিট কিউয়ের নাম বদলাচ্ছি? একটি প্ল্যাটফর্ম দলের প্রতিশ্রুতি হলো স্ট্রিম-সংগত দলগুলো একটি ইন্টিগ্রেশন ইঞ্জিন, একটি পরিচয় সেবা বা একটি শেয়ার্ড কেয়ার রেকর্ড API স্ব-সেবা নেয় একটি টিকিট তুলে অপেক্ষা না করে, যাতে পুরো ব্যবস্থা দ্রুততর হয়; ব্যর্থতা হলো কোনো কিছুকে "প্ল্যাটফর্ম" বলা যখন এটি একটি কর্মী-অপর্যাপ্ত কেন্দ্রীয় ফাংশন থাকে যার পেছনে সবাই এখনো সারিবদ্ধ। ট্রেড-অফ প্রকৃত: একটি সামর্থ্য প্রকৃত অভ্যন্তরীণ পণ্য হিসেবে গড়া মানে এটিকে নিজস্ব দল, রোডম্যাপ, ডকুমেন্টেশন ও ব্যবহারকারী দেওয়া, যা একটি গুরুতর বিনিয়োগ যা ব্যবহারকারী-মুখী ফিচার সরবরাহের সঙ্গে প্রতিযোগিতা করে, এবং একটি নগদ-সীমিত NHS পরিবেশে সেই বিনিয়োগ অনির্দিষ্টকালের জন্য বিলম্বিত করা সহজ। স্বাস্থ্য ও পরিচর্যায় ঝুঁকি তীক্ষ্ণ কারণ ভাগ-করা সামর্থ্য প্রায়ই নিরাপত্তা-সংকটপূর্ণগুলো, ব্যক্তি-মেলানো সূচক, FHIR ইন্টারফেস, অডিট ট্রেইল, যেখানে একটি পাতলা প্ল্যাটফর্ম দল এর ওপরের প্রতিটি সেবার জন্য একক ব্যর্থতার বিন্দু হয়। ইতোমধ্যে কয়েকটি দল যার ওপর নির্ভরশীল সেই সামর্থ্য দেখুন এবং প্রতিটির জন্য জিজ্ঞাসা করুন মিথস্ক্রিয়া সত্যিই নিম্ন-ঘর্ষণ X-as-a-service নাকি লুকানো অপেক্ষাসহ ছদ্মবেশী সহযোগিতা। একটি সৎ উত্তর নাম বলে কোন সামর্থ্য এখন বনাম পরে প্রকৃত প্ল্যাটফর্ম বিনিয়োগের যোগ্য, কে অর্থায়ন ও কর্মী দেয় সে বিষয়ে স্পষ্ট, এবং কোনো পণ্য মালিক, রোডম্যাপ বা স্ব-সেবা পথ নেই এমন একটি প্ল্যাটফর্ম ঘোষণার প্রলোভন প্রতিরোধ করে।

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

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

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

একটি ইন্টিগ্রেটেড কেয়ার সিস্টেম (ICS) অ্যাকিউট, কমিউনিটি, মানসিক স্বাস্থ্য, প্রাইমারি কেয়ার ও সামাজিক পরিচর্যা জুড়ে একটি শেয়ার্ড কেয়ার রেকর্ড চালু করছে।

প্রবৃত্তি হলো একটি বড় "শেয়ার্ড কেয়ার রেকর্ড দল" তৈরি করা। এর বদলে ICS টিম টপোলজি প্রয়োগ করে। একটি প্ল্যাটফর্ম দল শেয়ার্ড রেকর্ডের মূলের মালিক: ব্যক্তি-মেলানো সূচক, FHIR API, এবং ইন্টিগ্রেশন ইঞ্জিন, স্ব-সেবা সামর্থ্য হিসেবে প্রকাশিত। বেশ কয়েকটি স্ট্রিম-সংগত দল প্রত্যেকে এর ওপরে একটি প্রকৃত ব্যবহারকারী যাত্রার মালিক, "A&E-তে একজন রোগীর রেকর্ড দেখুন", "সমাজকর্মী সুরক্ষা দৃশ্য", "জিপি ওষুধ মেলানো", এবং প্ল্যাটফর্ম as-a-service ব্যবহার করে। একটি জটিল-উপব্যবস্থা দল সম্ভাব্যতাভিত্তিক রোগী-মেলানো অ্যালগরিদমের মালিক, যেখানে একটি ভুল মিল একটি প্রকৃত নিরাপত্তা ঘটনা। ক্লিনিক্যাল নিরাপত্তা ও অ্যাক্সেসিবিলিটি বিশেষজ্ঞদের একটি সক্ষমকারী দল স্ট্রিম-সংগত দলগুলোর মধ্য দিয়ে আবর্তিত হয়, তাদের জন্য করার বদলে নিজস্ব DCB0160 হ্যাজার্ড ওয়ার্কশপ চালাতে কোচিং দেয়।

প্রতিটি দলের একজন নামধারী পণ্য ব্যবস্থাপক, সরবরাহ ব্যবস্থাপক ও ক্লিনিক্যাল নিরাপত্তা কর্মকর্তা আছে, এবং একটি RACI স্পষ্ট করে যে গো-লাইভ জ্যেষ্ঠ দায়িত্বপ্রাপ্ত মালিকের কাছে জবাবদিহিকারী কিন্তু CSO ও IG স্বাক্ষর ছাড়া এগোতে পারে না। যখন A&E দলের একটি নতুন ডেটা ক্ষেত্র দরকার, মিথস্ক্রিয়া মোড স্পষ্ট: ছয় সপ্তাহের সহযোগিতা নয়, একটি নথিবদ্ধ API অনুরোধের মাধ্যমে প্ল্যাটফর্ম দল থেকে X-as-a-service। সরবরাহ দ্রুততর এবং, গুরুত্বপূর্ণভাবে, প্রতিটি যাত্রার নিরাপত্তা কেস যে দল এটি সরবরাহ করে তার মালিকানাধীন।

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

স্টার্ট-আপ#

দশ-জনের একটি ডিজিটাল-স্বাস্থ্য স্টার্ট-আপ চার আলাদা দল ধরন কর্মী দিতে পারে না, এটি সাধারণত একটি একক স্ট্রিম-সংগত দল যেখানে একজন ব্যক্তি কয়েকটি টুপি পরেন (একজন প্রকৌশলী যিনি ব্যবহারকারী গবেষণাও চালান, একজন চিকিৎসক-প্রতিষ্ঠাতা যিনি বাস্তবিক ক্লিনিক্যাল নিরাপত্তা কর্মকর্তা)। অগ্রাধিকার হলো পুরো দলকে একটি ভাগ-করা জ্ঞানীয় স্থানের ভেতরে রাখা যাতে সিদ্ধান্ত দ্রুত হয়; সবাই একই ঘরে থাকলে একটি আনুষ্ঠানিক RACI অতিরিক্ত। প্রকৃত ঝুঁকি হলো প্রতিষ্ঠাতা-বোতলের গলা: ক্লিনিক্যাল নিরাপত্তা ও তথ্য গভর্ন্যান্স একজন ব্যস্ত ব্যক্তির ওপর বসে, এবং DCB0129/0160 বাধ্যবাধকতা বিলম্বিত করা সহজ। কোম্পানি যখন প্রথম NHS চুক্তি জেতে, প্রথম বিশেষজ্ঞ নিয়োগ হওয়া উচিত যারা সেই গেটের ঝুঁকি কমায়, একজন নামধারী CSO ও একজন IG নেতা, প্রকৌশল হেডকাউন্ট বাড়ানোর আগে।

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

একটি প্রতিষ্ঠিত ছোট প্রদানকারী, একটি জিপি প্র্যাকটিস, কমিউনিটি ফার্মেসি, কেয়ার হোম বা একক-স্থানের ক্লিনিক, এর প্রকৃত রোগী ও চলমান পরিচালনা আছে কিন্তু কদাচিৎ একটি নিবেদিত ডিজিটাল বা IT দল, তাই নকশা করার কোনো "টিম টপোলজি" নেই; প্র্যাকটিস ব্যবস্থাপক বা একজন ক্লিনিক্যাল নেতা কার্যত তাঁদের দৈনন্দিন কাজের পাশাপাশি পুরো সরবরাহ সামর্থ্য। বাস্তবসম্মত পদক্ষেপ প্ল্যাটফর্ম ও সক্ষমকারী দল গড়া নয়, আপনার ইতোমধ্যে থাকা মানুষদের ওপর দায়িত্ব স্পষ্টভাবে নাম দেওয়া, আপনি যে সিস্টেম মোতায়েন করেন তার ক্লিনিক্যাল নিরাপত্তা কর্মকর্তা কে, তথ্য গভর্ন্যান্সের মালিক কে, একটি পরিবর্তন কে স্বাক্ষর করেন, এগুলো মুষ্টিমেয় কর্মীর খণ্ডকালীন টুপি হলেও। যেহেতু একটি বড় ট্রাস্টের মতো একই বিধিবদ্ধ দায়িত্ব (DCB0129/0160, UK GDPR, অ্যাক্সেসিবিলিটি) প্রযোজ্য, ব্যবহারিক ধরন হলো সেগুলো পুনরাবিষ্কারের বদলে আপনার সরবরাহকারীদের ও আপনার ICS-এর ভাগ-করা প্ল্যাটফর্ম ও সক্ষমকারী সহায়তার ওপর ভর দেওয়া, সরবরাহকারীদের জবাবদিহিতায় ধরার যথেষ্ট বুদ্ধিমান-ক্লায়েন্ট সামর্থ্য ধরে রেখে। একক বৃহত্তম ঝুঁকি হলো একজন-ব্যক্তির বোতলের গলা: ক্লিনিক্যাল সিস্টেম বোঝেন এমন একমাত্র ব্যক্তি চলে গেলে নিরাপত্তা ও ধারাবাহিকতা উভয়ই তাঁর সঙ্গে বেরিয়ে যায়, তাই RACI লেখা এবং দ্বিতীয় একজনকে ক্রস-প্রশিক্ষণ দেওয়া এখানে যেকোনো আনুষ্ঠানিক দল মডেলের চেয়ে বেশি গুরুত্বপূর্ণ।

বৃহৎ প্রতিষ্ঠান#

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

সরকার#

একটি জাতীয় সংস্থা (NHS England, DHSC) বা স্থানীয় কর্তৃপক্ষ সেই মান নির্ধারণ করে যার বিপরীতে অন্যরা কর্মী দেয়, Government Digital and Data সামর্থ্য কাঠামো, Service Standard, DCB0129/0160, এবং অর্থ কীভাবে দল সামর্থ্য কেনে সে বিষয়ে সংসদ ও জনগণের কাছে জবাবদিহিকারী। এখানে কাঠামো ক্রয় ও অর্থায়ন নিয়ম দ্বারা আকারিত: বেশির ভাগ সরবরাহ সরবরাহকারীদের কাছে চুক্তিতে দেওয়া, তাই ঘরোয়া ধরে রাখার জন্য গুরুত্বপূর্ণ ভূমিকা হলো বুদ্ধিমান-ক্লায়েন্ট ভূমিকা (পণ্য মালিকানা, প্রযুক্তিগত আশ্বাস, ক্লিনিক্যাল নিরাপত্তা স্বাক্ষর) যা সামর্থ্য ফাঁপা হওয়া প্রতিরোধ করে। জবাবদিহিতা আনুষ্ঠানিক ও নিরীক্ষণযোগ্য, একজন নামধারী জ্যেষ্ঠ দায়িত্বপ্রাপ্ত মালিক, প্রকাশিত ব্যয় নিয়ন্ত্রণ, স্বচ্ছতা দায়িত্ব, তাই দায়িত্ব মডেল সরকারি রেকর্ডের বিষয়, ঐচ্ছিক স্বাস্থ্যবিধি নয়। বৈশিষ্ট্যসূচক ঝুঁকি হলো কাঠামো স্থায়ী কর্মসূচি বোর্ড ও গেটে জমে যা প্রবাহ গলা টিপে ধরে; পাল্টা চাল হলো সরবরাহকারীদের কর্মী-বৃদ্ধি বডি-শপের বদলে স্ট্রিম-সংগত, ফলাফল-মালিক দলে ধরে রাখা।

ব্যর্থতার সাধারণ ধরন#

• উপাদান দলের ফাঁদ। প্রযুক্তি স্তর অনুযায়ী ভাগ করা দল ("ফ্রন্ট-এন্ড দল", "ডেটাবেস দল") প্রতিটি ফিচারে হ্যান্ড-অফ তৈরি করে এবং কোনো ফলাফলের মালিক নয়। মূল্যের ধারা ঘিরে পুনর্গঠন করুন।
• কার্গো-কাল্ট Spotify। অন্তর্নিহিত স্বায়ত্তশাসন, সংগতি ও প্ল্যাটফর্ম বিনিয়োগ ছাড়া "squads, tribes, chapters, guilds" লেবেল হিসেবে নকল করা। Spotify মডেল ছিল এক সময়ে এক কোম্পানির একটি স্ন্যাপশট, এমনকি Spotify নিজেও এগিয়ে গেছে। নীতি ধার করুন, সংগঠন চার্ট নয়।
• বীরোচিত বোতলের গলা। একজন CSO, একজন স্থপতি বা একজন IG নেতা সবকিছুতে পরামর্শিত পক্ষ, তাই প্রতিটি দল অপেক্ষা করে। তাঁদের একটি সক্ষমকারী সামর্থ্যে পরিণত করুন যা সবার দক্ষতা উন্নত করে।
• পরে-ভাবা বিষয় হিসেবে গভর্ন্যান্স। ক্লিনিক্যাল নিরাপত্তা ও IG এম্বেড-করা দলের সদস্যের বদলে বাহ্যিক গেট হিসেবে প্রতিনিধিত্ব, তাই তাদের উদ্বেগ সস্তায় ব্যবস্থা নেওয়ার জন্য অতি দেরিতে আসে।
• সীমাহীন দল। একটি দল সেবা শোষণ করতে থাকে যতক্ষণ না কেউ পুরোটা বোঝে না। জ্ঞানীয় অতিভার ধীর সরবরাহ ও ক্ষয়ে-যাওয়া নিরাপত্তা আত্মবিশ্বাস হিসেবে দেখা দেয়।
• স্থায়ী সহযোগিতা। দুটি দল অনির্দিষ্টকাল "সহযোগিতা" করা সাধারণত একটি অনুপস্থিত সীমানা। সহযোগিতা সময়-সীমাবদ্ধ করুন এবং একটি পরিচ্ছন্ন as-a-service ইন্টারফেসে যান।

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

চেকলিস্ট#

• প্রতিটি সেবার একটি স্ট্রিম-সংগত দল আছে যা এটি এন্ড-টু-এন্ড মালিকানা রাখে।
• প্রতিটি দলে পণ্য, সরবরাহ, গবেষণা, নকশা, প্রকৌশল, ডেটা, ক্লিনিক্যাল নিরাপত্তা ও তথ্য গভর্ন্যান্স আছে, বা নামধারী অ্যাক্সেস আছে।
• প্রতি দলে একজন নামধারী, প্রশিক্ষিত ক্লিনিক্যাল নিরাপত্তা কর্মকর্তার রক্ষিত সময় এবং একটি রিলিজ থামানোর কর্তৃত্ব আছে।
• ভাগ-করা সামর্থ্য (ইন্টিগ্রেশন, পরিচয়, পরিচর্যা রেকর্ড API) as-a-service ব্যবহৃত অভ্যন্তরীণ প্ল্যাটফর্ম হিসেবে চালানো।
• দুষ্প্রাপ্য বিশেষজ্ঞরা স্থায়ী বোতলের গলা নয়, সময়-সীমাবদ্ধ সক্ষমকারী দলের মাধ্যমে কাজ করেন।
• ক্লিনিক্যাল স্বাক্ষর, গো-লাইভ, IG অনুমোদন ও ব্যয়ের জন্য একটি RACI (বা সমতুল্য) আছে, এবং আসলে ব্যবহৃত।
• প্রতিটি ক্রস-দল নির্ভরতার একটি নামধারী মিথস্ক্রিয়া মোড আছে (সহযোগিতা / X-as-a-service / সহায়ক)।
• দলের ডোমেন একটি পরিচালনাযোগ্য জ্ঞানীয় ভারে সীমিত; অতিভারাক্রান্ত দল ভাগ করা।
• দলের সীমানা আপনি যে স্থাপত্য ও আন্তঃকার্যক্ষমতা চান তা তৈরি করতে সুচিন্তিতভাবে বাছা।

মূল উৎস#

• Team Topologies, Matthew Skelton ও Manuel Pais (চারটি দল ধরন, তিনটি মিথস্ক্রিয়া মোড, জ্ঞানীয় ভার): teamtopologies.com
• NHS Digital Service Standard ও NHS Service Manual, বহুশাস্ত্রীয় দলের ভূমিকা ও কাজের উপায়
• GOV.UK Service Manual (GDS), "Set up a service team" ও চটপটে সরবরাহ নির্দেশিকা
• Government Digital and Data (পূর্বে DDaT) Profession Capability Framework, ভূমিকা সংজ্ঞা: ddat-capability-framework.service.gov.uk
• ক্লিনিক্যাল ঝুঁকি ব্যবস্থাপনা মান DCB0129 (উৎপাদন) ও DCB0160 (মোতায়েন), NHS Digital, ক্লিনিক্যাল নিরাপত্তা কর্মকর্তার ভূমিকা
• কনওয়ের সূত্র, Melvin Conway, "How Do Committees Invent?" (1968)
• Spotify engineering culture (Henrik Kniberg), squads/tribes/chapters/guilds, একটি নির্দিষ্ট-সময়ের মডেল হিসেবে সমালোচনামূলকভাবে পড়ুন

তথ্যসূত্র#

1. Conway's law — Wikipedia — https://en.wikipedia.org/wiki/Conway%27s_law
2. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
3. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
4. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
5. Sociotechnical system — Wikipedia — https://en.wikipedia.org/wiki/Sociotechnical_system
6. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais — https://teamtopologies.com
8. NHS Service Manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk
9. Service Manual — Government Digital Service (GDS), GOV.UK — https://www.gov.uk/service-manual
10. Government Digital and Data Profession Capability Framework — GOV.UK — https://ddat-capability-framework.service.gov.uk
11. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
12. "How Do Committees Invent?" (1968) — Melvin E. Conway — http://www.melconway.com/Home/Committees_Paper.html

আরও দেখুন বিষয় 7.2 — কর্মীবাহিনী পরিকল্পনা, বিষয় 7.3 — কর্মীবাহিনী কৌশল, বিষয় 7.5 — মানুষ ও প্রাতিষ্ঠানিক উন্নয়ন, এবং বিষয় 8.1 — পরিবর্তন ব্যবস্থাপনা।