বিষয় 4.1 — প্ল্যাটফর্ম ও ভাগ-করা সেবা

এক বাক্যে: স্বাস্থ্য ও পরিচর্যায় একটি ভাগ-করা প্ল্যাটফর্ম খরচ-সাশ্রয়ের সুবিধা নয়, বরং নিরাপত্তা, ন্যায্যতা ও আস্থাকে পুনরাবৃত্তিযোগ্য করার একটি উপায়, যাতে প্রতিটি দল সেগুলো প্রায়ই খারাপভাবে নতুন করে আবিষ্কার না করে উত্তরাধিকারসূত্রে পায়।

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

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

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

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

মূল ধারণা#

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

এর নিচে বেশ কিছু সম্পর্কিত ধারণা আছে। ভাগ-করা সেবা হলো একটি সামর্থ্য প্রতিটি অংশে নকল না করে একটি প্রতিষ্ঠানের অনেক অংশের জন্য একবার সরবরাহ করার পুরোনো প্রাতিষ্ঠানিক ধরন। ডিজিটাল পাবলিক অবকাঠামো এটি একটি পুরো সমাজের স্তরে প্রসারিত করে, ভাগ-করা, পুনঃব্যবহারযোগ্য, আন্তঃকার্যক্ষম বিল্ডিং ব্লক (পরিচয়, পেমেন্ট, ডেটা বিনিময়) যার ওপর সরকারি ও বেসরকারি সেবা গড়া হয়। "প্ল্যাটফর্ম হিসেবে সরকার", Tim O'Reilly-র তৈরি করা এবং বিশ্বজুড়ে ডিজিটাল-সরকার দলগুলোর গ্রহণ করা একটি বাক্যাংশ, রাষ্ট্রে একই যুক্তি প্রয়োগ করে: সরকার সাধারণ উপাদান দেয়, এবং বিভাগগুলো প্রত্যেকে পুরো স্ট্যাক গড়ার বদলে সেগুলো থেকে সেবা গঠন করে।

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

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

বিশেষভাবে স্বাস্থ্যে, জাতীয় ভাগ-করা সেবা ইতোমধ্যে দৃশ্যপটের অংশ। NHS Connecting for Health-এর মতো ঐতিহাসিক কর্মসূচি NHS Spine প্রতিষ্ঠা করেছিল, Personal Demographics Service-এর মতো মূল ডেটা বহনকারী জাতীয় সেবার একটি সেট। আধুনিক সমতুল্যের মধ্যে আছে জাতীয় API, নাগরিক প্রমাণীকরণের জন্য NHS login, এবং বার্তা পাঠানোর জন্য NHS Notify, যে সামর্থ্য এমনভাবে দেওয়া হয় যাতে পৃথক সেবাকে সেগুলো নতুন করে গড়তে না হয়। যেখানে একটি প্ল্যাটফর্ম কেউ কে তা প্রমাণ করার একটি সাধারণ উপায় দেয়, তা প্রায়ই সিঙ্গল সাইন-অন উন্মুক্ত করে যাতে একজন চিকিৎসক বারবার নয়, একবার প্রমাণীকরণ করেন। এই বিষয় এমন প্ল্যাটফর্ম কীভাবে গড়বেন ও চালাবেন তা নিয়ে; আপনি কে এবং কী করার অনুমতি আছে তার বিবরণ বিষয় 4.2 — পরিচয় ও অ্যাক্সেস ব্যবস্থাপনায়, এবং সিস্টেমগুলোকে ডেটা বিনিময় করতে দেওয়া মান বিষয় 4.3 — আন্তঃকার্যক্ষমতা ও ডেটা মানে।

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

1. প্ল্যাটফর্মকে একটি পণ্য হিসেবে দেখুন, প্রকল্প হিসেবে নয়। একটি প্ল্যাটফর্মের একটি রোডম্যাপ, একজন পণ্য ব্যবস্থাপক, চলমান অর্থায়ন এবং যাদের সন্তুষ্টি আপনি মাপেন এমন ব্যবহারকারী আছে, একটি শেষ তারিখ ও হস্তান্তর নয়। প্রকল্প শেষ হয় ও ক্ষয় পায়; প্ল্যাটফর্ম অনির্দিষ্টকাল চালাতে হয় কারণ দলগুলো এর ওপর নির্ভরশীল হয়ে পড়ে। সেই অনুযায়ী অর্থায়ন ও জনবল দিন, এবং এটি যে পরিচালনগত শৃঙ্খলা বোঝায় তার জন্য বিষয় 5.0 — পণ্য-চালিত কাজ দেখুন।

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

3. পাকা রাস্তাকে সহজ রাস্তা করুন। একটি প্ল্যাটফর্ম গ্রহণ অর্জন করে সমর্থিত পথকে নিজের গড়ার চেয়ে দ্রুততর ও সরলতর করে, স্ব-সেবা অনবোর্ডিং, স্পষ্ট নথি, স্যান্ডবক্স এবং ক্লিনিক্যাল নিরাপত্তা ও অ্যাক্সেসিবিলিটি অন্তর্নির্মিত বিচক্ষণ ডিফল্টের মাধ্যমে। প্ল্যাটফর্ম ব্যবহার করা তা এড়িয়ে যাওয়ার চেয়ে ধীর বা কষ্টকর হলে দলগুলো তা এড়িয়ে যাবে, এবং আপনি একটি বাধা তৈরি করতে অর্থ খরচ করবেন। ডেভেলপারের প্রথম ঘণ্টা ও তাঁর সবচেয়ে খারাপ দিনের জন্য নকশা করুন।

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

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

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

7. প্ল্যাটফর্ম দল স্পষ্ট দায়িত্ব ও সীমানা সহ চালান। একটি নিবেদিত প্ল্যাটফর্ম দলের চারপাশে সংগঠিত করুন যার কাজ স্ব-সেবার মাধ্যমে স্ট্রিম-সংগত সরবরাহ দলগুলোকে সক্ষম করা, যেমনটি বিষয় 7.0 — দলের কাঠামো, ভূমিকা ও দায়িত্বের Team Topologies প্যাটার্নে বর্ণিত। প্ল্যাটফর্ম ও ভোক্তাদের মধ্যকার ইন্টারফেস স্পষ্ট রাখুন, প্ল্যাটফর্ম কী প্রতিশ্রুতি দেয়, কী দেয় না এবং কীভাবে সহায়তা পাবেন, যাতে প্ল্যাটফর্ম দ্বাররক্ষার বদলে সক্ষম করে।

8. শুরু থেকেই মাল্টি-টেন্যান্সি, বিচ্ছিন্নতা ও নিরাপত্তার জন্য নকশা করুন। অনেক প্রতিষ্ঠান একটি প্ল্যাটফর্ম ভাগ করলে, তাদের ডেটা, কনফিগারেশন ও ব্যর্থতা ডোমেইনের পৃথকীকরণ একটি মৌলিক প্রয়োজন, পরবর্তী ফিচার নয়। স্বাস্থ্য ও পরিচর্যায় এটি একটি তথ্য-গভর্ন্যান্স ও ক্লিনিক্যাল-নিরাপত্তা প্রয়োজনও: এক টেন্যান্টের ঘটনা অন্যের রোগীদের প্রকাশ বা বিপদে ফেলবে না। বিচ্ছিন্নতা, প্রতি-টেন্যান্ট পর্যবেক্ষণযোগ্যতা এবং DCB0129-এর অধীনে প্ল্যাটফর্মের নিজস্ব একটি ক্লিনিক্যাল-নিরাপত্তা কেস গড়ে তুলুন।

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

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

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

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

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

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

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

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

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

একটি বিশাল ICS প্ল্যাটফর্ম কমিশন করার বদলে তারা পাতলা থেকে শুরু করে। তারা একটি একক ভাগ-করা সেবা দাঁড় করায় যা একটি কাজ ভালোভাবে করে: এটি NHS login এবং জাতীয় Personal Demographics Service একটি পরিষ্কার, নথিবদ্ধ API-র পেছনে একটি স্যান্ডবক্সসহ মুড়ে দেয়, যাতে যেকোনো দল একটি সমর্থিত পথে একজন নাগরিকের পরিচয় যাচাই ও একটি নিশ্চিত জনতাত্ত্বিক রেকর্ড পুনরুদ্ধার করতে পারে। পাঁচজনের একটি ছোট প্ল্যাটফর্ম দল এটিকে একটি পণ্য হিসেবে দেখে। তারা একটি পাকা-রাস্তা নির্দেশিকা প্রকাশ করে, স্ব-সেবা অনবোর্ডিং দেয়, এবং একটি লক্ষ্য নির্ধারণ করে যে একটি নতুন দল একদিনের মধ্যে তার প্রথম সফল কল করবে। গুরুত্বপূর্ণভাবে, তারা এটি বাধ্যতামূলক করে না। তারা এটিকে সহজতম বিকল্প করে এবং ভার্চুয়াল-ওয়ার্ড দলকে প্রথম ইচ্ছুক গ্রহণকারী হতে দেয়।

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

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

স্টার্ট-আপ#

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

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

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

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

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

সরকার#

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

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

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

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

চেকলিস্ট#

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

মূল উৎস#

• GOV.UK Service Manual এবং প্ল্যাটফর্ম হিসেবে সরকার ও সাধারণ উপাদান নিয়ে Government Digital Service-এর লেখা।
• Matthew Skelton ও Manuel Pais, Team Topologies — প্ল্যাটফর্ম দল, সবচেয়ে পাতলা কার্যকর প্ল্যাটফর্ম এবং জ্ঞানীয় ভার।
• NHS England ডেভেলপার ও API নির্দেশিকা (NHS login, NHS Notify, জাতীয় API এবং Spine সেবা)।
• স্বাস্থ্য IT সিস্টেমের জন্য DCB0129 ও DCB0160 ক্লিনিক্যাল ঝুঁকি ব্যবস্থাপনা মান।
• ডিজিটাল পাবলিক অবকাঠামো ও পুনঃব্যবহারযোগ্য সরকারি বিল্ডিং ব্লক নিয়ে World Bank ও United Nations-এর লেখা।
• Tim O'Reilly, "Government as a Platform", Open Government (O'Reilly Media)-এ।

তথ্যসূত্র#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation