Claims and prescriptions
Connect Prescription AI to OPD document capture, with an operator check before a reading can affect a claim amount.
Product
Roadmap
Implemented work stays separate from what comes next
Phases 1 and 2 are committed engineering. Phase 3 mixes product scale with research. Phase 4 depends on demonstrated need and funding. Nothing on this page is a description of a vulnerability or a workaround.
Capability status
Labels follow the implementation matrix. Security-hardening items are described only as workstreams, not as findings.
| Capability | Module | Status |
|---|---|---|
| Beneficiary registration, verification, package allocation | IMP core | Implemented |
| Claims submission, adjudication, calendar-year balances | IMP core | Implemented |
| Web role-based access | IMP core | Implemented |
| Provider directory and doctor appointments | IMP core | Implemented |
| Payment-gateway disbursement | IMP core | Proposed |
| Multi-tenant isolation | IMP core | Partial |
| Beneficiary and partner app, claim wizard, secure token storage | Mobile | Implemented |
| Push notifications for claim status | Mobile | Implemented |
| Bengali and English interface localisation | Mobile | Proposed |
| Offline claim queue | Mobile | Proposed |
| Partner profile screen | Mobile | Implemented |
| Core schema for enrolment, packages, claims, directory | Database | Implemented |
| Prescription upload, transcription, catalog match, dosage parsing | Prescription AI | Implemented |
| Human verification API | Prescription AI | Implemented |
| Operator verification workbench | Prescription AI | Partial |
| Prescription AI inside the mobile OPD claim form | Prescription AI | Proposed |
| Fraud and anomaly detection | Analytics | Future / Research |
| Loss ratios and programme-split analytics | Analytics | Proposed |
Phase 1 — critical hardening
Immediate. Protect credentials, claims access, referential integrity, and recovery.
- 1Credentials and sessions
Move password storage to a modern password hash, reset sessions, and keep a single active API session model that can be revoked.
- 2Data handling
Encrypt and restrict database dumps, remove expired API tokens, and mask personal data outside production.
- 3Access control
Require authentication on every claims read, turn on CSRF protection for web forms, and rate-limit login.
- 4Integrity and recovery
Enforce uniqueness on Insurance ID and mobile number, enforce the link from claim documents to claims, and run an encrypted backup with a tested restore.
Phase 2 — finish the product
Mobile completeness
Bengali and English localisation, and an offline claim queue. Push notifications and the partner profile are already implemented.
Mobile
Data cleanliness
Use utf8mb4 for beneficiary names, real date types, and strict SQL mode so zero-dates and blank values cannot linger.
Database
Test and release
Expand automated tests across the four layers, including a claims path on a staging environment.
Engineering
Phase 3 — scale
Prescription intelligence, claims assistance, and research that is not a shipped feature.
Formal confidence calibration, Bengali-capable local OCR, and PDF rasterisation extend Prescription AI. Automated claims assistance would check whether a file is complete and pre-fill a claim from a verified prescription.
Fraud and anomaly detection is future research. It needs a labeled claims history and is not a current control. Payment disbursement, object storage for claim files, a reporting replica, and a larger hospital and diagnostic directory are the scale items around that research.
Phase 4 — platform
Only after the beneficiary base, and the funding, justify it.
Analytics
Loss ratios, claim trends, and SWAPNO versus TCCF comparisons on the central data model.
Reporting
Health records
A real dependants model in place of repeating child columns, package versioning, and telemedicine prescriptions flowing back into IMP.
Records
Network growth
Expand hospitals and diagnostic centres using where claims actually occur.
Providers
A harder platform
Managed schema migrations, column-level protection for National ID and bKash data, disaster-recovery tests, a backward-compatible API v2, and later alignment with DGDA medicine codes and hospital interoperability.
Architecture
Phase boundaries follow section 14 of IMP System Overview v2.0. The status table is the authority when an older roadmap line disagrees with it.