হেলথকেয়ার ERP সিস্টেম ডিজাইন: হাসপাতাল, ক্লিনিক ও ডায়াগনস্টিক সেন্টার ডেটাবেজ আর্কিটেকচার

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

১. হেলথকেয়ার ERP কেন আলাদা

হেলথকেয়ার প্রতিষ্ঠানের এমন কিছু অনন্য সিস্টেম চাহিদা রয়েছে যা প্রচলিত বাণিজ্যিক ERP পণ্যগুলো প্রায়ই দুর্বলভাবে সামলায়:

• রোগী শনাক্তকরণ ব্যবস্থাপনা: একজন রোগী, বছরের পর বছর ধরে হয়তো বহুবার আসছেন — সিস্টেমকে ডুপ্লিকেট বা ভুল সংযুক্তি ছাড়াই প্রতিটি এনকাউন্টার সঠিক ব্যক্তির সাথে যুক্ত রাখতে হবে
• ক্লিনিক্যাল ডেটার জটিলতা: রোগনির্ণয়, প্রেসক্রিপশন, ল্যাব ফলাফল, ভাইটাল সাইন, ইমেজিং রিপোর্ট — অসংগঠিত ও সংগঠিত ডেটা মিশে থাকে, কঠোর ইন্টিগ্রিটি চাহিদাসহ
• রিয়েল-টাইম উপলব্ধতা: ল্যাব ফলাফলের অপেক্ষায় থাকা একজন ডাক্তার ধীরগতির ডেটাবেজ কোয়েরির জন্য অপেক্ষা করতে পারেন না। জরুরি বিভাগে আসা রোগীর তাৎক্ষণিকভাবে তার মেডিক্যাল ইতিহাস প্রয়োজন
• রেগুলেটরি কমপ্লায়েন্স: রোগীর ডেটা গোপনীয়তা, প্রেসক্রিপশন রেকর্ড এবং নিয়ন্ত্রিত ওষুধ বিতরণ — সবই নিয়ন্ত্রিত, বাংলাদেশে DGDA ও স্বাস্থ্য মন্ত্রণালয়ের নির্দেশনার অধীনে
• মাল্টি-ডিপার্টমেন্ট ইন্টিগ্রেশন: OPD, IPD, ফার্মেসি, ল্যাবরেটরি, রেডিওলজি, বিলিং এবং প্রশাসন — সবাইকে রিয়েল-টাইমে একটি একক রোগী রেকর্ড থেকে কাজ করতে হবে
• ২৪/৭ পরিচালনা: হাসপাতাল কখনও বন্ধ হয় না — সিস্টেম সারাক্ষণ উপলব্ধ থাকতে হবে, পরিকল্পিত রক্ষণাবেক্ষণ কেবল নির্ধারিত কম-কার্যক্রমের সময়ের মধ্যেই সম্ভব

২. হেলথকেয়ারের জন্য মূল ERP মডিউল

একটি সম্পূর্ণ হেলথকেয়ার ERP সিস্টেম আটটি কার্যকরী মডিউল অন্তর্ভুক্ত করে। প্রতিটি মডিউলের নিজস্ব ডেটা চাহিদা আছে, তবে সবাইকে একটি ঐক্যবদ্ধ রোগী মাস্টার রেকর্ড শেয়ার করতে হবে।

২.১ রোগী রেজিস্ট্রেশন ও মাস্টার ইনডেক্স (EMR কোর)

Patient Master Index (PMI) হলো সম্পূর্ণ সিস্টেমের ভিত্তি। বাকি প্রতিটি মডিউল এটিকে রেফারেন্স করে।

-- Patient Master table — foundation of healthcare ERP
CREATE TABLE patients (
  patient_id       NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  patient_mrn      VARCHAR2(20) UNIQUE NOT NULL,  -- Medical Record Number
  full_name        VARCHAR2(200) NOT NULL,
  date_of_birth    DATE NOT NULL,
  gender           CHAR(1) CHECK (gender IN ('M','F','O')),
  blood_group      VARCHAR2(5),
  national_id      VARCHAR2(20),
  mobile           VARCHAR2(20),
  emergency_contact VARCHAR2(200),
  address          VARCHAR2(500),
  allergies        CLOB,                  -- Free text, critical for pharmacy
  chronic_conditions VARCHAR2(1000),
  registration_date DATE DEFAULT SYSDATE,
  active_flag      CHAR(1) DEFAULT 'Y',
  created_by       VARCHAR2(50) NOT NULL,
  created_at       TIMESTAMP DEFAULT SYSTIMESTAMP,
  CONSTRAINT chk_mrn CHECK (REGEXP_LIKE(patient_mrn,'^[A-Z]{2}[0-9]{8}$'))
);

রোগী মাস্টারের জন্য মূল ডিজাইন সিদ্ধান্তগুলো:

• Medical Record Number (MRN): প্রতিটি রোগীর জন্য একটি অনন্য, স্থায়ী শনাক্তকারী — কখনও পুনঃব্যবহার নয়, কখনও পুনঃবরাদ্দ নয়। ফরম্যাটে রেজিস্ট্রেশনের স্থান ও তারিখ এনকোড করা উচিত
• অ্যালার্জি রেকর্ডিং: রেজিস্ট্রেশনের সময় অবশ্যই বাধ্যতামূলক হতে হবে — একটি NULL অ্যালার্জি ফিল্ড আর "কোনো পরিচিত অ্যালার্জি নেই" এক জিনিস নয়। সিস্টেমকে "কোনো অ্যালার্জি রেকর্ড করা হয়নি" এবং "কোনো পরিচিত অ্যালার্জি নেই"-এর মধ্যে পার্থক্য করতে হবে
• ডুপ্লিকেট প্রতিরোধ: ডুপ্লিকেট রোগী রেকর্ড তৈরি হওয়ার আগেই তা রুখতে name + DOB + address-এর ওপর ম্যাচিং লজিক প্রয়োগ করুন

২.২ আউটপেশেন্ট ডিপার্টমেন্ট (OPD)

-- OPD visit and consultation structure
CREATE TABLE opd_visits (
  visit_id        NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  patient_id      NUMBER NOT NULL REFERENCES patients(patient_id),
  visit_date      DATE NOT NULL,
  visit_time      TIMESTAMP NOT NULL,
  department_id   NUMBER NOT NULL REFERENCES departments(department_id),
  doctor_id       NUMBER NOT NULL REFERENCES doctors(doctor_id),
  visit_type      VARCHAR2(20) CHECK (visit_type IN ('NEW','FOLLOWUP','EMERGENCY')),
  chief_complaint VARCHAR2(1000),
  visit_status    VARCHAR2(20) DEFAULT 'WAITING',
  queue_number    NUMBER,
  token_time      TIMESTAMP,
  seen_time       TIMESTAMP,
  created_by      VARCHAR2(50) NOT NULL
);

-- Doctor's consultation/prescription
CREATE TABLE consultations (
  consultation_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  visit_id        NUMBER NOT NULL REFERENCES opd_visits(visit_id),
  presenting_complaints CLOB,
  examination_findings  CLOB,
  diagnosis       VARCHAR2(2000),
  icd10_code      VARCHAR2(20),     -- International disease classification
  advice          CLOB,
  followup_date   DATE,
  referred_to     VARCHAR2(200),
  created_by      VARCHAR2(50) NOT NULL,
  created_at      TIMESTAMP DEFAULT SYSTIMESTAMP
);

২.৩ ইনপেশেন্ট ডিপার্টমেন্ট (IPD)

-- Inpatient admission and ward management
CREATE TABLE admissions (
  admission_id    NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  patient_id      NUMBER NOT NULL REFERENCES patients(patient_id),
  admission_date  TIMESTAMP NOT NULL,
  admission_type  VARCHAR2(20) CHECK (admission_type IN
                  ('PLANNED','EMERGENCY','TRANSFER')),
  admitting_doctor NUMBER NOT NULL REFERENCES doctors(doctor_id),
  ward_id         NUMBER NOT NULL REFERENCES wards(ward_id),
  bed_id          NUMBER NOT NULL REFERENCES beds(bed_id),
  diagnosis_on_admission VARCHAR2(1000),
  discharge_date  TIMESTAMP,
  discharge_type  VARCHAR2(30),
  discharge_summary CLOB,
  total_days      NUMBER GENERATED ALWAYS AS
                  (ROUND(SYSDATE - CAST(admission_date AS DATE))) VIRTUAL,
  status          VARCHAR2(20) DEFAULT 'ADMITTED'
);

-- Bed management — real-time occupancy
CREATE TABLE beds (
  bed_id          NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  ward_id         NUMBER NOT NULL REFERENCES wards(ward_id),
  bed_number      VARCHAR2(10) NOT NULL,
  bed_type        VARCHAR2(30),    -- GENERAL, PRIVATE, ICU, HDU, CABIN
  daily_rate      NUMBER(10,2),
  status          VARCHAR2(20) DEFAULT 'AVAILABLE',
  current_patient NUMBER REFERENCES patients(patient_id),
  CONSTRAINT uq_bed UNIQUE (ward_id, bed_number)
);

২.৪ ফার্মেসি মডিউল

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

-- Prescription with mandatory allergy cross-check
CREATE TABLE prescriptions (
  prescription_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  visit_id        NUMBER REFERENCES opd_visits(visit_id),
  admission_id    NUMBER REFERENCES admissions(admission_id),
  patient_id      NUMBER NOT NULL REFERENCES patients(patient_id),
  prescribing_doctor NUMBER NOT NULL REFERENCES doctors(doctor_id),
  prescribed_at   TIMESTAMP DEFAULT SYSTIMESTAMP,
  CONSTRAINT chk_pres_source CHECK (
    (visit_id IS NOT NULL AND admission_id IS NULL) OR
    (visit_id IS NULL AND admission_id IS NOT NULL)
  )
);

CREATE TABLE prescription_lines (
  line_id         NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  prescription_id NUMBER NOT NULL REFERENCES prescriptions(prescription_id),
  drug_id         NUMBER NOT NULL REFERENCES drugs(drug_id),
  dose            VARCHAR2(50) NOT NULL,
  frequency       VARCHAR2(50) NOT NULL,  -- BD, TDS, QID, OD, SOS
  duration_days   NUMBER NOT NULL,
  route           VARCHAR2(30),           -- ORAL, IV, IM, SC, TOPICAL
  instructions    VARCHAR2(500),
  allergy_checked CHAR(1) DEFAULT 'N',    -- Must be Y before dispensing
  dispensed_flag  CHAR(1) DEFAULT 'N'
);

-- Drug dispensing — double verification for high-risk drugs
CREATE TABLE drug_dispensing (
  dispensing_id   NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  line_id         NUMBER NOT NULL REFERENCES prescription_lines(line_id),
  dispensed_by    VARCHAR2(50) NOT NULL,
  verified_by     VARCHAR2(50),           -- Required for controlled substances
  dispensed_at    TIMESTAMP DEFAULT SYSTIMESTAMP,
  quantity        NUMBER NOT NULL,
  batch_number    VARCHAR2(50),
  expiry_date     DATE
);

২.৫ ল্যাবরেটরি মডিউল

-- Lab test ordering and results
CREATE TABLE lab_orders (
  order_id        NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  patient_id      NUMBER NOT NULL REFERENCES patients(patient_id),
  ordered_by      NUMBER NOT NULL REFERENCES doctors(doctor_id),
  order_date      TIMESTAMP DEFAULT SYSTIMESTAMP,
  priority        VARCHAR2(10) DEFAULT 'ROUTINE'
                  CHECK (priority IN ('STAT','URGENT','ROUTINE')),
  sample_collected TIMESTAMP,
  sample_type     VARCHAR2(50),
  status          VARCHAR2(20) DEFAULT 'PENDING'
);

CREATE TABLE lab_order_tests (
  order_test_id   NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  order_id        NUMBER NOT NULL REFERENCES lab_orders(order_id),
  test_id         NUMBER NOT NULL REFERENCES lab_tests(test_id),
  result_value    VARCHAR2(500),
  result_unit     VARCHAR2(50),
  reference_range VARCHAR2(100),
  result_flag     VARCHAR2(10),       -- HIGH, LOW, CRITICAL, NORMAL
  resulted_by     VARCHAR2(50),
  resulted_at     TIMESTAMP,
  verified_by     VARCHAR2(50),       -- Pathologist verification
  verified_at     TIMESTAMP,
  report_text     CLOB,               -- Narrative pathology report
  critical_notified CHAR(1) DEFAULT 'N' -- Critical values must be notified
);

২.৬ বিলিং ও রেভিনিউ সাইকেল

-- Patient billing — unified across OPD, IPD, pharmacy, lab
CREATE TABLE patient_bills (
  bill_id         NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  patient_id      NUMBER NOT NULL REFERENCES patients(patient_id),
  visit_id        NUMBER REFERENCES opd_visits(visit_id),
  admission_id    NUMBER REFERENCES admissions(admission_id),
  bill_date       DATE DEFAULT TRUNC(SYSDATE),
  bill_type       VARCHAR2(20),    -- OPD, IPD, LAB, PHARMACY, RADIOLOGY
  subtotal        NUMBER(12,2) NOT NULL,
  discount_pct    NUMBER(5,2) DEFAULT 0,
  discount_amount NUMBER(12,2) DEFAULT 0,
  tax_amount      NUMBER(12,2) DEFAULT 0,
  total_amount    NUMBER(12,2) NOT NULL,
  paid_amount     NUMBER(12,2) DEFAULT 0,
  balance         NUMBER(12,2) GENERATED ALWAYS AS
                  (total_amount - paid_amount) VIRTUAL,
  payment_status  VARCHAR2(20) DEFAULT 'UNPAID',
  insurance_id    NUMBER REFERENCES insurance_providers(insurance_id),
  created_by      VARCHAR2(50) NOT NULL
);

CREATE TABLE bill_line_items (
  item_id         NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  bill_id         NUMBER NOT NULL REFERENCES patient_bills(bill_id),
  service_code    VARCHAR2(20) NOT NULL,
  service_name    VARCHAR2(200) NOT NULL,
  quantity        NUMBER DEFAULT 1,
  unit_price      NUMBER(10,2) NOT NULL,
  line_total      NUMBER(12,2) GENERATED ALWAYS AS (quantity * unit_price) VIRTUAL,
  source_type     VARCHAR2(20),    -- CONSULTATION, LAB, PHARMACY, BED, PROCEDURE
  source_id       NUMBER           -- FK to source record
);

৩. হেলথকেয়ার ERP-এর জন্য ডেটাবেজ আর্কিটেকচারের মূলনীতি

৩.১ একক রোগী মাস্টার — কোনো ডুপ্লিকেশন নয়

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

৩.২ অপরিবর্তনীয় ক্লিনিক্যাল রেকর্ড

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

-- Enforce immutability on finalized clinical records using triggers
CREATE OR REPLACE TRIGGER trg_protect_finalized_results
BEFORE UPDATE OR DELETE ON lab_order_tests
FOR EACH ROW
BEGIN
  IF :OLD.verified_at IS NOT NULL THEN
    RAISE_APPLICATION_ERROR(-20001,
      'Verified lab results cannot be modified or deleted. Create an amendment record.');
  END IF;
END;
/

৩.৩ অডিট ট্রেইল — প্রতিটি ক্লিনিক্যাল ক্রিয়া লগ করা

-- Generic audit trail for all clinical tables
CREATE TABLE clinical_audit_log (
  audit_id        NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  table_name      VARCHAR2(50) NOT NULL,
  record_id       NUMBER NOT NULL,
  action          VARCHAR2(10) NOT NULL,  -- INSERT, UPDATE, DELETE
  changed_by      VARCHAR2(50) NOT NULL,
  changed_at      TIMESTAMP DEFAULT SYSTIMESTAMP,
  old_values      CLOB,   -- JSON representation of previous values
  new_values      CLOB,   -- JSON representation of new values
  session_info    VARCHAR2(200)   -- IP, terminal, application
) ORGANIZATION HEAP
  TABLESPACE audit_data;  -- Separate tablespace, restricted access

৩.৪ রেফারেন্স ডেটা ম্যানেজমেন্ট

হেলথকেয়ার সিস্টেমে বিস্তৃত রেফারেন্স ডেটা থাকে — ICD-10 রোগনির্ণয় কোড, ড্রাগ ফর্মুলারি, ল্যাব টেস্ট ক্যাটালগ, ফি শিডিউল। এগুলো অবশ্যই ভার্সন-কন্ট্রোল্ড হতে হবে: যখন কোনো ওষুধের দাম বদলায় বা ফি শিডিউল হালনাগাদ হয়, পুরনো বিলগুলোতে অবশ্যই সেবার সময় কার্যকর থাকা রেট প্রতিফলিত থাকতে হবে।

-- Version-controlled fee schedule
CREATE TABLE fee_schedules (
  fee_id          NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  service_code    VARCHAR2(20) NOT NULL,
  service_name    VARCHAR2(200) NOT NULL,
  category        VARCHAR2(50),
  price           NUMBER(10,2) NOT NULL,
  effective_from  DATE NOT NULL,
  effective_to    DATE,
  CONSTRAINT uq_fee_date UNIQUE (service_code, effective_from)
);

-- Always look up historical price at time of service
SELECT service_name, price
FROM fee_schedules
WHERE service_code = :service_code
  AND effective_from <= :service_date
  AND (effective_to IS NULL OR effective_to >= :service_date);

৪. রোগীর ডেটা সুরক্ষা

রোগীর স্বাস্থ্য তথ্য সবচেয়ে সংবেদনশীল ব্যক্তিগত ডেটার অন্যতম। ডেটাবেজকে অবশ্যই একাধিক স্তরে কঠোর অ্যাক্সেস কন্ট্রোল আরোপ করতে হবে।

৪.১ রোল-ভিত্তিক অ্যাক্সেস কন্ট্রোল

-- Healthcare roles with appropriate data access
CREATE ROLE doctor_role;
CREATE ROLE nurse_role;
CREATE ROLE lab_technician_role;
CREATE ROLE billing_staff_role;
CREATE ROLE pharmacy_role;
CREATE ROLE admin_role;

-- Doctors: full clinical read, own-patient write
GRANT SELECT ON patients TO doctor_role;
GRANT SELECT, INSERT ON consultations TO doctor_role;
GRANT SELECT, INSERT ON prescriptions TO doctor_role;
GRANT SELECT ON lab_order_tests TO doctor_role;

-- Billing staff: no clinical data, billing only
GRANT SELECT ON patients TO billing_staff_role;
GRANT SELECT, INSERT, UPDATE ON patient_bills TO billing_staff_role;
GRANT SELECT, INSERT ON bill_line_items TO billing_staff_role;
-- Billing cannot see prescriptions, lab results, diagnoses

৪.২ সংবেদনশীল ডেটার জন্য কলাম-লেভেল মাস্কিং

-- Mask sensitive patient information from non-clinical staff
-- Billing staff sees patient name but not diagnosis or prescriptions
CREATE OR REPLACE VIEW billing_patient_view AS
SELECT patient_id, patient_mrn, full_name,
       mobile, address,
       -- Sensitive clinical data hidden from billing view
       '***' AS allergies,
       '***' AS chronic_conditions
FROM patients;

GRANT SELECT ON billing_patient_view TO billing_staff_role;

৫. ল্যাবরেটরি ইন্টিগ্রেশন

আধুনিক ডায়াগনস্টিক সেন্টার HL7 বা প্রোপ্রাইটারি প্রোটোকল ব্যবহার করে ল্যাবরেটরি অ্যানালাইজারকে সরাসরি ERP-এর সাথে যুক্ত করে। যখন একটি ব্লাড অ্যানালাইজার একটি CBC টেস্ট সম্পন্ন করে, ফলাফল কোনো ম্যানুয়াল এন্ট্রি ছাড়াই সরাসরি ল্যাব মডিউলে চলে আসে — ট্রান্সক্রিপশন ভুল দূর করে।

-- Interface staging table for analyzer result feeds
CREATE TABLE lab_interface_staging (
  staging_id      NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  analyzer_id     VARCHAR2(50) NOT NULL,
  raw_message     CLOB NOT NULL,       -- Raw HL7 or CSV from analyzer
  patient_id_ext  VARCHAR2(50),        -- Patient ID from analyzer (may differ)
  test_code       VARCHAR2(50),
  result_value    VARCHAR2(200),
  result_unit     VARCHAR2(50),
  received_at     TIMESTAMP DEFAULT SYSTIMESTAMP,
  processed_flag  CHAR(1) DEFAULT 'N',
  matched_order   NUMBER REFERENCES lab_order_tests(order_test_id),
  error_message   VARCHAR2(500)
);

-- Automated matching procedure (runs every 2 minutes)
CREATE OR REPLACE PROCEDURE process_analyzer_results AS
BEGIN
  FOR rec IN (
    SELECT * FROM lab_interface_staging
    WHERE processed_flag = 'N'
    ORDER BY received_at
  ) LOOP
    -- Match to pending lab order by barcode/test code
    -- Update result if match found
    -- Flag for manual review if no match
    NULL; -- implementation specific to analyzer protocol
  END LOOP;
END;
/

৬. রিপোর্টিং ও ম্যানেজমেন্ট অ্যানালিটিক্স

হেলথকেয়ার ম্যানেজমেন্টের দরকার একইসাথে অপারেশনাল রিপোর্ট (আজকের OPD সংখ্যা, বেড অকুপেন্সি, রেভিনিউ) এবং ক্লিনিক্যাল অ্যানালিটিক্স (রোগের প্যাটার্ন, ওষুধ ব্যবহার, ল্যাব টার্নঅ্যারাউন্ড টাইম)।

৬.১ মূল অপারেশনাল রিপোর্ট

-- Daily dashboard queries

-- 1. Today's OPD volume by department
SELECT d.department_name,
       COUNT(*) AS total_visits,
       SUM(CASE WHEN v.visit_status = 'COMPLETED' THEN 1 ELSE 0 END) AS completed,
       SUM(CASE WHEN v.visit_status = 'WAITING' THEN 1 ELSE 0 END) AS waiting,
       ROUND(AVG(EXTRACT(MINUTE FROM (v.seen_time - v.token_time))),0) AS avg_wait_min
FROM opd_visits v
JOIN departments d ON v.department_id = d.department_id
WHERE TRUNC(v.visit_date) = TRUNC(SYSDATE)
GROUP BY d.department_name
ORDER BY total_visits DESC;

-- 2. Real-time bed occupancy
SELECT w.ward_name, w.total_beds,
       SUM(CASE WHEN b.status = 'OCCUPIED' THEN 1 ELSE 0 END) AS occupied,
       SUM(CASE WHEN b.status = 'AVAILABLE' THEN 1 ELSE 0 END) AS available,
       ROUND(SUM(CASE WHEN b.status = 'OCCUPIED' THEN 1 ELSE 0 END)/w.total_beds*100,1) AS occupancy_pct
FROM wards w
JOIN beds b ON w.ward_id = b.ward_id
GROUP BY w.ward_name, w.total_beds
ORDER BY occupancy_pct DESC;

-- 3. Revenue summary today
SELECT bill_type,
       COUNT(*) AS bill_count,
       SUM(total_amount) AS gross_revenue,
       SUM(paid_amount) AS collected,
       SUM(balance) AS outstanding
FROM patient_bills
WHERE bill_date = TRUNC(SYSDATE)
GROUP BY bill_type
ORDER BY gross_revenue DESC;

৭. ক্লিনিক্যাল ডিসিশন সাপোর্টে Oracle 26ai

Oracle 26ai-এর ভেক্টর সার্চ এবং ইন-ডেটাবেজ AI ফিচার হেলথকেয়ার ERP-এর জন্য শক্তিশালী নতুন সম্ভাবনা খুলে দেয় — একইসাথে সংবেদনশীল রোগী ডেটা হাসপাতালের নিজস্ব সার্ভারের ভেতরে রাখে।

৭.১ AI-চালিত ড্রাগ ইন্টারঅ্যাকশন চেকিং

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

-- Drug interaction knowledge base with vector embeddings
CREATE TABLE drug_interaction_kb (
  kb_id           NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  drug_combo      VARCHAR2(500),
  interaction_text VARCHAR2(2000),
  severity        VARCHAR2(20),
  interaction_vec VECTOR(512, FLOAT32)
);

-- Find similar drug interactions using vector similarity
SELECT di.drug_combo, di.severity, di.interaction_text,
       VECTOR_DISTANCE(di.interaction_vec, :query_vec, COSINE) AS similarity
FROM drug_interaction_kb di
WHERE VECTOR_DISTANCE(di.interaction_vec, :query_vec, COSINE) < 0.25
ORDER BY similarity ASC
FETCH FIRST 5 ROWS ONLY;

৭.২ সাধারণ ভাষায় ক্লিনিক্যাল কোয়েরি

Oracle 26ai Select AI ব্যবহার করে ডাক্তার ও প্রশাসকরা রোগী ডেটাবেজ নিয়ে সাধারণ ভাষায় প্রশ্ন করতে পারেন:

• "এই মাসে কতজন রোগী ডেঙ্গু জ্বর নিয়ে ভর্তি হয়েছেন?"
• "এই সপ্তাহে কোন ডাক্তারের OPD রোগীর সংখ্যা সবচেয়ে বেশি?"
• "CBC টেস্টের গড় ল্যাব টার্নঅ্যারাউন্ড টাইম কত?"
• "কোন ওয়ার্ডগুলো ৩ দিনের বেশি সময় ধরে ৯০%-এর বেশি অকুপেন্সিতে রয়েছে?"

সব কোয়েরি Oracle-এর ভেতরে চলে, ব্যবহারকারীর অ্যাক্সেস অনুমতি স্বয়ংক্রিয়ভাবে প্রয়োগ করে বাস্তব হাসপাতাল ডেটা থেকে উত্তর ফিরিয়ে দেয়।

৮. বাস্তবায়ন পদ্ধতি

হেলথকেয়ার ERP বাস্তবায়ন বিগ-ব্যাং গো-লাইভ হতে পারে না। ঝুঁকি অনেক বেশি। আমি একটি পর্যায়ভিত্তিক পদ্ধতি সুপারিশ করি:

পর্যায় ১ — ভিত্তি (মাস ১–২)

• ডুপ্লিকেট প্রতিরোধসহ Patient Master Index সেটআপ
• OPD রেজিস্ট্রেশন ও কিউ ম্যানেজমেন্ট
• ডাক্তারের কনসালটেশন ও মৌলিক প্রেসক্রিপশন
• ইউজার রোল ও অ্যাক্সেস কন্ট্রোল কনফিগারেশন
• বিদ্যমান রোগী রেজিস্টার থেকে ডেটা মাইগ্রেশন

পর্যায় ২ — ক্লিনিক্যাল মডিউল (মাস ৩–৪)

• টেস্ট ক্যাটালগসহ ল্যাবরেটরি মডিউল
• ড্রাগ ফর্মুলারি ও ডিসপেন্সিং ওয়ার্কফ্লোসহ ফার্মেসি
• IPD ভর্তি, ওয়ার্ড ম্যানেজমেন্ট ও বেড ট্র্যাকিং
• রেডিওলজি অর্ডার ম্যানেজমেন্ট
• মৌলিক বিলিং ও পেমেন্ট কালেকশন

পর্যায় ৩ — অ্যানালিটিক্স ও ইন্টিগ্রেশন (মাস ৫–৬)

• ম্যানেজমেন্ট ড্যাশবোর্ড ও অপারেশনাল রিপোর্ট
• ল্যাব যন্ত্রপাতির জন্য অ্যানালাইজার ইন্টারফেস (HL7 ইন্টিগ্রেশন)
• ইনস্যুরেন্স ও থার্ড-পার্টি বিলিং
• ক্লিনিক্যাল ডিসিশন সাপোর্টের জন্য Oracle 26ai AI ফিচার
• ডাক্তারদের জন্য মোবাইল অ্যাক্সেস (ওয়ার্ড রাউন্ড সাপোর্ট)

৯. বাংলাদেশে সাধারণ হেলথকেয়ার ERP ব্যর্থতা

বাংলাদেশজুড়ে হাসপাতাল ও ক্লিনিক সিস্টেমে কাজ করে এগুলোই সবচেয়ে ঘন ঘন যে ডিজাইন ও বাস্তবায়ন ভুল আমি দেখি:

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

শেষ কথা

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

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

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