জাতীয় ই-হেলথ প্ল্যাটফর্ম বিশ্লেষণ

01 / OVERVIEW

এক নজরে সিস্টেম

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

দুটি সোর্স ডকুমেন্ট একই সিস্টেমকে দুই ভিন্ন উচ্চতা থেকে বর্ণনা করে। National Digital eHealth Platform ডকুমেন্টটি নীতিনির্ধারণী স্তরের — এটি বলে সিস্টেম কী কী করবে (১০টি কনসেপ্চুয়াল লেয়ার)। deep-research-report.md কারিগরি স্তরের — এটি বলে সেগুলো কীভাবে বানানো হবে (Laravel/PHP মাইক্রোসার্ভিস, ডেটাবেস স্কিমা, API, নিরাপত্তা, বাজেট)। এই রিপোর্ট দুটোকে একত্র করে একটি সম্পূর্ণ চিত্র দেয়।

~200M

টার্গেট জনসংখ্যা

কনসেপ্চুয়াল লেয়ার (নীতি ডকুমেন্ট)

কারিগরি মডিউল/সার্ভিস

রোলআউট ফেজ (2026–2029+)

মূল ভিত্তি তিনটি: e-Health ID (NID/BRN-এর সাথে যুক্ত আজীবন স্বাস্থ্য পরিচয়), Shared EHR (সব প্রতিষ্ঠানের তথ্য একই রেকর্ডে জমা হওয়া), এবং Consent-based Access Control (রোগীর অনুমতি ছাড়া কেউ পূর্ণ তথ্য দেখতে পারবে না)।

02 / ARCHITECTURE

একীভূত আর্কিটেকচার

নিচের ডায়াগ্রামে নীতি-ডকুমেন্টের ১০টি লেয়ার এবং কারিগরি রিপোর্টের সার্ভিস-ভিত্তিক ডিজাইনকে একটি পাঁচ-স্তরের স্ট্যাকে মেলানো হয়েছে। বাম দিকের বড় কলামে মূল স্তরগুলো ওপর থেকে নিচে সাজানো (নাগরিক-অ্যাক্সেস → ইনফ্রাস্ট্রাকচার); ডানের সরু কলামটি বোঝায় Security/Consent/Audit প্রতিটি স্তরের সাথে সমান্তরালভাবে প্রযোজ্য — এটি কোনো একটি নির্দিষ্ট জায়গার মডিউল নয়, বরং পুরো সিস্টেমকে ঘিরে থাকা একটি নিয়ন্ত্রণ-স্তর।

বাম দিকের পাঁচটি স্তর ওপর থেকে নিচে দেখায় ডেটা কীভাবে নাগরিক-অ্যাক্সেস থেকে ইনফ্রাস্ট্রাকচার পর্যন্ত প্রবাহিত হয়; ডানের সরু "স্পাইন" বোঝায় নিরাপত্তা ও গভর্নেন্স কোনো এক স্তরের ফিচার নয় — এটি প্রতিটি স্তরের সাথে সমান্তরালভাবে সবসময় সক্রিয় থাকে।

LAYER 1নাগরিক ও প্রোভাইডার যেভাবে সিস্টেমে ঢোকে — পোর্টাল, অ্যাপ, ড্যাশবোর্ড
LAYER 2একটিমাত্র নিরাপদ প্রবেশদ্বার — সব রিকোয়েস্ট এখান দিয়ে যাচাই হয়ে যায়
LAYER 3আসল চিকিৎসাসেবার লজিক — EHR থেকে AI সাপোর্ট পর্যন্ত ৯টি সার্ভিস
LAYER 4বাইরের বিদ্যমান সিস্টেমের সাথে সেতুবন্ধন — DHIS2, NID, লিগ্যাসি HIS
LAYER 5প্রকৃত ডেটা যেখানে জমা ও প্রক্রিয়া হয় — DB, warehouse, cache, queue

03 / MECHANISM

সিস্টেম যেভাবে কাজ করবে — একজন রোগীর যাত্রা

নিচের ফ্লো একটি বাস্তব দৃশ্যপট দিয়ে দেখায় কীভাবে দুই ডকুমেন্টের সব উপাদান — e-Health ID, EHR, ডিজিটাল রেফারেল, রিয়েল-টাইম বেড তথ্য, অ্যাম্বুলেন্স সমন্বয়, টেলিমেডিসিন — একসাথে একটি লেনদেনে কাজ করে। রোগ নির্ণয়ের পর তিনটি সম্ভাব্য পথ তৈরি হয়: স্বাভাবিক কেয়ার, রেফারেল/জরুরি অবস্থা, অথবা দূরবর্তী চিকিৎসা — শেষে সবকিছুর তথ্যই বিলিং হয়ে জাতীয় অ্যানালিটিক্সে ফিড হয়।

একটি এনকাউন্টার শুরু হয় e-Health ID যাচাইয়ে; রোগ নির্ণয়ের পর কেস-জটিলতা অনুযায়ী তিনটি পথের যে-কোনোটিতে যায় — মাঝেরটি (কমলা রঙে হাইলাইট করা) হলো রেফারেল/জরুরি পথ, যেখানে রিয়েল-টাইম বেড ডেটা ও অ্যাম্বুলেন্স সমন্বয় সক্রিয় হয়। তিনটি পথই শেষে বিলিং হয়ে জাতীয় অ্যানালিটিক্সে মিশে যায়।

ধাপে ধাপে — ডায়াগ্রামের বর্ণনা

নিবন্ধন: নাগরিক প্রথমবার সিস্টেমে ঢোকার সময় NID/BRN দিয়ে যাচাই হয়, আর তার জন্য একটি স্থায়ী e-Health ID ইস্যু করা হয় — এটাই সারাজীবনের পরিচয়।
ফ্যাসিলিটি ভিজিট: যেকোনো হাসপাতাল বা ক্লিনিকে গেলে একটি এনকাউন্টার (encounter) তৈরি হয়, যা সাথে সাথে রোগীর EHR-এ যুক্ত হয়ে যায়।
রোগ নির্ণয়: ডাক্তার ল্যাব টেস্ট অর্ডার করেন ও প্রেসক্রিপশন লেখেন। এখানেই সিদ্ধান্ত হয় — রোগী কোন পথে যাবে।
পথ ১ — স্বাভাবিক কেয়ার: জটিলতা না থাকলে চিকিৎসা এখানেই শেষ হয় এবং প্রয়োজনে একটি ফলো-আপ অ্যাপয়েন্টমেন্ট শিডিউল হয়।
পথ ২ — রেফারেল ও জরুরি অবস্থা: জটিল কেসে একটি ডিজিটাল রেফারেল তৈরি হয়, যার সাথে সব মেডিকেল হিস্ট্রি সংযুক্ত থাকে। সিস্টেম তখন রিয়েল-টাইম বেড তথ্য (ICU/CCU/NICU) দেখে উপযুক্ত হাসপাতাল বাছাই করে এবং প্রয়োজনে অ্যাম্বুলেন্স লোকেশন অনুযায়ী সমন্বয় করে রোগী স্থানান্তর করে।
পথ ৩ — টেলিমেডিসিন: দূরবর্তী এলাকার রোগীর জন্য স্থানীয় স্বাস্থ্যকর্মী রোগীকে বিশেষজ্ঞ ডাক্তারের সাথে ভার্চুয়ালি সংযুক্ত করেন; পরামর্শ সরাসরি EHR-এ যুক্ত হয়ে যায়।
বিলিং: তিনটি পথের যেকোনোটির শেষে, প্রতিটি এনকাউন্টার থেকে স্বয়ংক্রিয়ভাবে বিলিং/ইনস্যুরেন্স এন্ট্রি তৈরি হয়।
জাতীয় অ্যানালিটিক্স: সব ইভেন্ট de-identified (ব্যক্তি-পরিচয়মুক্ত) আকারে জাতীয় স্বাস্থ্য তথ্যভাণ্ডার ও DHIS2-এ ফিড হয়, যা সরকারকে নীতিনির্ধারণে সাহায্য করে।

04 / MODULES

মডিউলভিত্তিক বিবরণ

নীতি-ডকুমেন্টের ১০টি লেয়ার আর কারিগরি রিপোর্টের সার্ভিসগুলো নিচে একীভূত করে দেখানো হলো — কোন মডিউল কী করবে, আর দুই সোর্সের কে সেটার কতটুকু বলেছে।

মডিউল	কাজ	নীতি ডকুমেন্ট	কারিগরি রিপোর্ট
EHR / SeHR	জন্ম থেকে আজীবন — history, diagnosis, prescription, lab, imaging একই রেকর্ডে জমা	Layer 1 — বিস্তারিত ফিল্ড লিস্ট	Data model + FHIR profile
e-Health ID / কার্ড	NID/BRN-লিংকড ইউনিক পরিচয়, নাগরিক নিজে দেখে/শেয়ার করে	Layer 10 — মূল ফোকাস	National ID API integration
প্রতিষ্ঠান সংযোগ	বিদ্যমান হাসপাতাল/ক্লিনিক HIS-কে জাতীয় প্ল্যাটফর্মে যুক্ত করা	Layer 2	Inter-service comms, legacy adapter
ডিজিটাল রেফারেল	primary → upazila → district → tertiary — ট্র্যাকযোগ্য রেফারেল চেইন	Layer 3 — স্টেট মেশিন সহ	উল্লেখ নেইGAP
বেড/সার্ভিস তথ্য	রিয়েল-টাইম ICU/CCU/NICU/জেনারেল বেড অ্যাভেইলেবিলিটি	Layer 4 — স্পষ্ট ফিচার	উল্লেখ নেইGAP
জরুরি ও অ্যাম্বুলেন্স	লোকেশন + নিকটতম উপযুক্ত হাসপাতাল সমন্বয়	Layer 5	উল্লেখ নেইGAP
টেলিমেডিসিন	স্থানীয় সেন্টার থেকে দূরবর্তী বিশেষজ্ঞ সংযোগ	Layer 6	TeleSvc — SaaS ইন্টিগ্রেশন
AI ক্লিনিক্যাল সাপোর্ট	ঝুঁকি নির্ণয়, প্রায়োরিটাইজেশন — সিদ্ধান্ত-সহায়ক, প্রতিস্থাপক নয়	Layer 7 — ভবিষ্যৎ ফিচার	শুধু "AI/ML analytics" হিসেবে উল্লেখPARTIAL
জাতীয় ডেটা রিপোজিটরি	De-identified aggregate ডেটায় সরকারি মনিটরিং ও পলিসি প্ল্যানিং	Layer 8	AnalyticsSvc + Data Warehouse + DHIS2 API
ল্যাব ও ইমেজিং	অটোমেটেড রেজাল্ট পোস্টিং, PACS ইন্টিগ্রেশন	Layer 1-এ উল্লিখিত	LabSvc — HL7/DICOM পার্সিং বিস্তারিত
ফার্মেসি / e-Rx	প্রেসক্রিপশন, ড্রাগ ইন্টারঅ্যাকশন অ্যালার্ট, স্টক	উল্লেখ নেইGAP	PharmSvc — সম্পূর্ণ ডিজাইনFULL
বিলিং / ইনস্যুরেন্স	এনকাউন্টার-ভিত্তিক চার্জ, SSK ইন্টিগ্রেশন-রেডি	উল্লেখ নেইGAP	BillingSvc — সম্পূর্ণ ডিজাইনFULL
নিরাপত্তা ও কনসেন্ট	Layer 9 — প্রতিটি স্তরের জন্য প্রযোজ্য	Layer 9	Auth, RBAC, encryption, audit — বিস্তারিত

GAP এই সোর্সে উল্লেখ নেই PARTIAL শুধু আংশিক/এক লাইনে উল্লেখ FULL সম্পূর্ণ ডিজাইন করা আছে

05 / STAKEHOLDER VIEW

কে কী দেখতে/করতে পারবে

দুই ডকুমেন্টের মডিউল ও নিরাপত্তা-নীতিকে একসাথে মিলিয়ে — বাস্তবে সিস্টেম ব্যবহারকারী প্রতিটি ভূমিকা (role) কোন মডিউল ছুঁতে পারবে, আর তার অ্যাক্সেস লেভেল কতটুকু, তা এখানে ম্যাপ করা হলো। এটি কোনো ডকুমেন্টেই সরাসরি নেই — মডিউল-টেবিল ও নিরাপত্তা-নীতি একত্র করে তৈরি নতুন বিশ্লেষণ।

নাগনাগরিক / রোগী

প্রধান কাজ: নিজের রেকর্ড দেখা, consent দেওয়া/প্রত্যাহার, অ্যাপয়েন্টমেন্ট বুকিং
ব্যবহৃত মডিউল: Patient Portal, e-Health Card
অ্যাক্সেস লেভেল: নিজের ডেটা — সম্পূর্ণ; অন্য কারও ডেটা — কোনোভাবেই না

ডাঃচিকিৎসক (ফ্যাসিলিটিতে)

প্রধান কাজ: এনকাউন্টার তৈরি, ডায়াগনোসিস, প্রেসক্রিপশন, রেফারেল তৈরি
ব্যবহৃত মডিউল: EHR, রেফারেল, টেলিমেডিসিন
অ্যাক্সেস লেভেল: যে রোগী দেখছেন তার রেকর্ড — সম্পূর্ণ (consent সাপেক্ষে); বাকিদেরটা রেফারেল ছাড়া নয়

নার্সনার্স

প্রধান কাজ: ভাইটালস রেকর্ড, ইমিউনাইজেশন এন্ট্রি
ব্যবহৃত মডিউল: EHR (observation/immunization)
অ্যাক্সেস লেভেল: ওয়ার্ড/ইউনিট-পর্যায়ের রোগীদের সীমিত তথ্য

ল্যাবল্যাব টেকনিশিয়ান

প্রধান কাজ: টেস্ট রেজাল্ট এন্ট্রি, ইমেজিং আপলোড
ব্যবহৃত মডিউল: Lab Service, PACS
অ্যাক্সেস লেভেল: শুধু নিজের কাছে আসা lab_order সংশ্লিষ্ট তথ্য

ফার্মাফার্মাসিস্ট

প্রধান কাজ: প্রেসক্রিপশন dispense, স্টক ব্যবস্থাপনা
ব্যবহৃত মডিউল: Pharmacy Service
অ্যাক্সেস লেভেল: শুধু প্রেসক্রিপশন-স্তরের তথ্য, পূর্ণ EHR নয়

হসহাসপাতাল অ্যাডমিন

প্রধান কাজ: বেড স্ট্যাটাস আপডেট, বিলিং ওভারভিউ, স্টাফ ব্যবস্থাপনা
ব্যবহৃত মডিউল: HIMS, বেড/অ্যাম্বুলেন্স, বিলিং
অ্যাক্সেস লেভেল: নিজের ফ্যাসিলিটি-পর্যায়ের অ্যাগ্রিগেট তথ্য

অ্যাম্বঅ্যাম্বুলেন্স অপারেটর

প্রধান কাজ: ডিসপ্যাচ গ্রহণ, লোকেশন আপডেট
ব্যবহৃত মডিউল: জরুরি ও অ্যাম্বুলেন্স সমন্বয় সার্ভিস
অ্যাক্সেস লেভেল: শুধু নিজের অ্যাসাইন করা ডিসপ্যাচ কেস

সরকাMoHFW / সরকার

প্রধান কাজ: পলিসি প্ল্যানিং, ট্রেন্ড মনিটরিং, রিসোর্স বরাদ্দ
ব্যবহৃত মডিউল: Analytics, জাতীয় স্বাস্থ্য তথ্যভাণ্ডার
অ্যাক্সেস লেভেল: শুধুই de-identified, অ্যাগ্রিগেট ডেটা — ব্যক্তি-পরিচয় নয়

06 / DATA MODEL

ডেটা মডেল — মূল এনটিটি

কারিগরি রিপোর্ট অনুযায়ী কোর স্কিমা। প্রতিটি Patient-এর সাথে Encounter, Appointment, Consent, Immunization যুক্ত; প্রতিটি Encounter থেকে Observation, Condition, Medication, Lab Order তৈরি হয়।

patientsencountersappointments providersfacilitiesconditions (ICD-10) observations (LOINC)medicationslab_orders lab_resultsbillingconsent immunizationusers / roles

একীভূত করার জন্য এই স্কিমায় যা যোগ করতে হবে: bed_status (facility_id, ward_type, total, available, updated_at), referrals (encounter_id, from_facility, to_facility, status, urgency), ambulance_dispatch (referral_id বা encounter_id, location, eta, status) — কারণ এগুলো নীতি-ডকুমেন্টের Layer 4/5-এর জন্য অপরিহার্য কিন্তু কারিগরি স্কিমায় নেই।

07 / DATABASE ARCHITECTURE

ডেটাবেস আর্কিটেকচার — পারিবারিক স্বাস্থ্য আইডি স্কিম

বাংলাদেশে ১৮ বছরের নিচে শিশুদের নিজস্ব NID নেই — তাই এই স্কিমে পরিবার প্রধানের (সাধারণত বাবা/মা) মোবাইল নম্বর ও NID মিলিয়ে একটি মাস্টার Health ID তৈরি হয়, আর পরিবারের প্রতিটি সদস্য (সন্তান, স্বামী/স্ত্রী) সেই মাস্টার আইডির সাথে একটি ক্রমিক নম্বর (১, ২, ৩...) যুক্ত করে নিজস্ব Health ID পান। ফলে একটি মোবাইল নম্বর দিয়েই পুরো পরিবার খুঁজে পাওয়া যায়।

আইডি তৈরির নিয়ম ও সার্চ আর্কিটেকচার

মোবাইল ও NID একসাথে যাচাই হয়ে পরিবার প্রধানের একটি Health ID তৈরি হয় — এটাই তাঁর কার্ডের নম্বর। পরিবারে সদস্য যোগ করলে সেই একই নম্বরের সাথে ক্রমিক সংখ্যা (-1, -2, -3...) যুক্ত হয়ে প্রতিটি সদস্যের জন্য আলাদা Health ID তৈরি হয়। সার্চের সময় শুধু মোবাইল+NID দিলেই পুরো পরিবার একসাথে দেখা যায়।

নমুনা স্বাস্থ্য কার্ড

এই দুটো কার্ড একই পরিবারের — বাঁয়েরটা পরিবার প্রধানের, ডানেরটা তাঁর প্রথম সন্তানের। দুটো কার্ডের Health ID লক্ষ করুন: সন্তানের আইডি মূলত প্রধানের আইডির শেষে "-১" যোগ করেই তৈরি। দ্বিতীয় সন্তান হলে তার আইডি হতো 9038475610-2, স্ত্রী থাকলে 9038475610-3 — এভাবে ক্রমিক নম্বর বাড়তে থাকবে।

ডেটাবেস স্কিমা

টেবিল	বিবরণ	মূল ফিল্ড
family_heads	পরিবার প্রধানের মাস্টার রেকর্ড — NID ও মোবাইল দিয়ে যাচাই	id (PK), nid (unique), mobile_number (unique), health_id (generated, unique), name, dob, address
family_members	পরিবারের প্রতিটি সদস্যের রেকর্ড, প্রধানের সাথে লিংক করা	id (PK), family_head_id (FK → family_heads.id), sequence_no (int), member_health_id (generated = health_id + '-' + sequence_no), relation, name, dob, nid (nullable)

Unique constraint: UNIQUE(family_head_id, sequence_no) — একই পরিবারে দুইজন সদস্য একই ক্রমিক নম্বর পাবে না; নতুন সদস্য যোগ হলে sequence_no স্বয়ংক্রিয়ভাবে পরবর্তী সংখ্যায় বাড়বে (MAX(sequence_no)+1)।

কেন এই ডিজাইন

১
শিশুদের NID নেই সমস্যার সমাধান — বাংলাদেশে ১৮ বছরের নিচে কারও নিজস্ব NID থাকে না; পরিবার প্রধানের NID/মোবাইল দিয়ে সন্তানদের অন্তর্ভুক্ত করাটাই বাস্তবসম্মত সমাধান।
২
কার্ড হারালেও সমস্যা নেই — হাসপাতাল রিসেপশনে শুধু মোবাইল নম্বর ও NID জিজ্ঞেস করলেই সিস্টেম পুরো পরিবারকে খুঁজে বের করে ফেলবে।
৩
ভবিষ্যৎ মাইগ্রেশন নিয়ম দরকার — কোনো সদস্য ১৮ বছর বয়সে নিজের NID পেলে, তার member_health_id-কে স্বতন্ত্র family_head-এ "প্রোমোট" করার একটা নিয়ম এখনই ডিজাইনে রাখা উচিত (নতুবা তার পরবর্তী প্রজন্মের সন্তানদের আইডি কোথা থেকে শুরু হবে তা অস্পষ্ট থেকে যাবে)।

08 / SECURITY & GOVERNANCE

নিরাপত্তা ও গভর্নেন্স

দুই ডকুমেন্টই নিরাপত্তাকে "cornerstone" বলেছে — নীতি ডকুমেন্ট নীতিগতভাবে (কী নিশ্চিত করতে হবে), কারিগরি রিপোর্ট বাস্তবায়নগতভাবে (কীভাবে)।

নিয়ন্ত্রণ	নীতিগত দাবি	কারিগরি বাস্তবায়ন
Consent	রোগীর অনুমতি ছাড়া কেউ পূর্ণ তথ্য দেখতে পারবে না	Consent টেবিল + পোর্টালে consent screen
Access Control	Role অনুযায়ী দেখার অনুমতি নিয়ন্ত্রিত	RBAC (Spatie / Laravel Gates), roles: Admin/Doctor/Nurse/LabTech/Pharmacist/Patient
Encryption	ডেটা এনক্রিপশন বাধ্যতামূলক	TLS in transit, DB encryption at rest, field-level encryption for NID
Audit Trail	অননুমোদিত অ্যাক্সেস প্রতিরোধ ও ট্র্যাকিং	প্রতিটি view/edit ইভেন্ট লগ (Laravel events → secure audit log)
Identity	e-Health Card নিরাপদ পরিচয়যাচাই	OAuth2/OIDC via Laravel Passport, NID registry verification
Law Compliance	ভবিষ্যৎ Data Protection Act মেনে চলা	Data minimization by design, DPO role, privacy notices
Emergency Access	জরুরি অবস্থায় ন্যূনতম বাধায় তথ্য পাওয়া দরকার (উহ্য)	"Break-glass" override সুপারিশ করা — কিন্তু কোনো ডকুমেন্টেই স্পষ্ট প্রসেস নেইGAP

09 / ROADMAP

রোলআউট রোডম্যাপ

PHASE 01

Planning & Pilot

Late 2026 – Mid 2027

কোর EHR + Health ID
NID সিস্টেমের সাথে ইন্টিগ্রেশন
3–5 জেলায় পাইলট

PHASE 02

Expansion

Late 2027 – 2028

টেলিমেডিসিন, ল্যাব, ফার্মেসি, বিলিং
পেশেন্ট + প্রোভাইডার পোর্টাল
DHIS2 ইন্টিগ্রেশন শুরু

PHASE 03

Scale-up Nationwide

2028 – 2029

সব সরকারি ফ্যাসিলিটি + প্রাইভেট ক্লিনিক
মাস ট্রেনিং
থার্ড-পার্টি API ওপেন করা

PHASE 04

Optimization

2029 onward

AI/ML ক্লিনিক্যাল ডিসিশন সাপোর্ট
ইনস্যুরেন্স/SSK ইন্টিগ্রেশন
বেড/অ্যাম্বুলেন্স রিয়েল-টাইম লেয়ার এখানেই বসানো উচিত

10 / NEXT STEPS

সুপারিশ — সম্পূর্ণ সিস্টেম স্পেক বানাতে

১
একটি একীভূত স্পেক ডকুমেন্ট বানান — এই রিপোর্টের মডিউল টেবিলটিকে ভিত্তি ধরে, যেখানে প্রতিটি নীতি-লেয়ারের জন্য একটি কারিগরি সার্ভিস ম্যাপ করা থাকবে।
২
BedSvc ও EmergencySvc নামে দুটি নতুন মাইক্রোসার্ভিস যোগ করুন কারিগরি আর্কিটেকচারে — bed_status ও ambulance_dispatch টেবিলসহ, যাতে নীতি-ডকুমেন্টের Layer 4/5 বাস্তবায়নযোগ্য হয়।
৩
Referral-কে একটি প্রথম-শ্রেণির এনটিটি করুন — বর্তমান স্কিমায় শুধু encounter/appointment আছে; referral টেবিল + স্টেট মেশিন (created → hospital_selected → transferred → treated → follow_up) যোগ করতে হবে।
৪
AI-CDS-কে ফেজ ৪-এ একটি সুনির্দিষ্ট এপিক করুন — কোন মডেল, কোন ডেটাসেটে ট্রেইন, কীভাবে ডাক্তারের ওয়ার্কফ্লোতে বসবে (suggestion, not autopilot) — তা এখনই খসড়া করে রাখা ভালো, যদিও বাস্তবায়ন পরে।
৫
Break-glass ইমার্জেন্সি অ্যাক্সেস প্রসেস আনুষ্ঠানিকভাবে লিখুন — কে override করতে পারবে, কী লগ হবে, কে রিভিউ করবে — এটা এখন দুই ডকুমেন্টেই উহ্য আছে।
৬
স্টেকহোল্ডার ম্যাট্রিক্স (সেকশন ৫) অনুযায়ী RBAC পারমিশন টেবিল কোড করুন — প্রতিটি role-এর জন্য কোন মডিউলে কী করতে পারবে তা এখন ডকুমেন্টেড, শুধু Spatie roles/permissions সিডে রূপান্তর বাকি।
৭
পাইলট ফেজে (2026–27) শুধু EHR + Health ID + একটি জেলায় Referral+Bed মিলিয়ে টেস্ট করুন — পুরো ১০ লেয়ার একসাথে না নিয়ে, কারণ Bed/Ambulance/AI অংশগুলো সবচেয়ে বেশি নতুন ডিজাইন দাবি করে।

জাতীয় ডিজিটাল ই-হেলথ প্ল্যাটফর্ম — সিস্টেম বিশ্লেষণ ও একীভূত রিপোর্ট