BRD – Remote X-ray Review via OTP-Secured DICOM Viewer Link
1. Purpose
Camp users will upload each digital X-ray against a beneficiary ID, and the system will send the assigned remote doctor a secure link. The doctor verifies an OTP, views the X-ray in a web DICOM viewer, and submits a report that flows back to the camp with a tracked status.
2. Background and problem statement
X-rays taken at camps stay on the laptop attached to the digital X-ray device, so no doctor outside the camp can read them. Today there is no reliable way to:
- Link each image to the right beneficiary in the central system.
- Get images to a remote doctor securely, without sharing files over personal channels.
- Capture the doctor's findings in a structured way and return them to the camp.
- Track which X-rays are still waiting for a report.
3. Objectives and success measures
Objective | Proposed measure (targets to be confirmed) |
Every camp X-ray is stored centrally and linked to a beneficiary | % of X-rays taken that are uploaded with a valid beneficiary ID |
Remote doctors can report quickly | Median time from upload to report submitted |
Only the assigned doctor sees the image | Unauthorised access incidents = 0 |
Camp users always know where each case stands | % of cases with a current status of Pending or Completed |
4. Scope
In scope
- A new desktop uploader on the X-ray laptop that uploads images to the central server, per beneficiary ID.
- Capture of the reviewing doctor's name and contact details at upload.
- Automated job that sends the doctor a secure link by WhatsApp, SMS or email.
- OTP verification on the doctor's registered mobile number before access.
- Web-based DICOM viewer for the doctor.
- Structured report entry and submission by the doctor.
- Return of the report to the camp user, with a notification.
- Status tracking per X-ray (Pending, Completed and interim states).
5. Stakeholders and user roles
Role | What they do in this module |
Camp user (radiographer / camp coordinator) | Selects beneficiary, uploads X-rays, enters doctor details, views reports and status |
Remote doctor (radiologist / physician) | Receives link, verifies OTP, views X-ray, submits report |
Camp / program supervisor | Monitors pending cases and turnaround across camps |
System administrator | Manages doctor master, message templates, link and OTP settings, audit logs |
Beneficiary | Subject of the X-ray; may receive report via the camp (not a system user) |
6. End-to-end process flow
end-to-end flow · 3 actors, 7 steps
The case moves camp → server → doctor → server → camp; the OTP check (step 4) is the only way into the images. Exceptions: a failed OTP locks the link (FR-23), and an unreadable image sends a re-take request back to camp (FR-34).
7. Functional requirements
Each original requirement statement is refined below into testable requirements. Priority: M = Must, S = Should, C = Could.
7.1 Image capture and upload (camp)
ID | Requirement | Priority |
FR-01 | A new desktop uploader installed on the X-ray device laptop shall let the camp user search and select a beneficiary by Beneficiary ID before uploading any X-ray. | M |
FR-02 | The system shall allow one or more X-ray images to be uploaded against a single beneficiary in one upload session. | M |
FR-03 | The system shall accept DICOM (.dcm) files; JPEG/PNG exports shall be accepted and wrapped as DICOM secondary capture. | M |
FR-04 | The system shall validate file type and size, and that the DICOM Patient ID matches or is mapped to the selected Beneficiary ID, and warn on mismatch. | M |
FR-05 | The camp user shall record body part / view (e.g. Chest PA) and clinical notes or reason for X-ray with each upload. | S |
FR-06 | Uploads shall resume or retry automatically on poor connectivity; images queued offline shall upload when the network returns. | M |
FR-07 | The system shall show upload progress and a success or failure message per image. | M |
FR-08 | The camp user shall be able to delete or replace an image only until a doctor has opened the case. | S |
7.2 Doctor assignment (camp)
ID | Requirement | Priority |
FR-09 | While uploading, the camp user shall enter or select the reviewing doctor: name, mobile number (mandatory), email (optional), registration number (optional). | M |
FR-10 | The system shall maintain a doctor master with each doctor's availability. The camp user assigns one available doctor per case, and all X-rays of that case go to that doctor. | S |
FR-11 | The system shall validate mobile number (10 digits, Indian format) and email format before submission. | M |
FR-12 | The camp user shall choose the delivery channel(s): WhatsApp, SMS, email; default WhatsApp + SMS. | M |
FR-13 | The camp user or supervisor shall be able to reassign a pending case to another doctor; the old link is then revoked. | S |
7.3 Notification job (central server)
ID | Requirement | Priority |
FR-14 | A scheduled or event-driven job shall pick up newly uploaded cases and send the doctor a link on the selected channels within a configurable time (target ≤ 5 minutes). | M |
FR-15 | The link shall be a unique, non-guessable token per case and doctor; it shall carry no beneficiary name or medical details. | M |
FR-16 | Messages shall use approved templates (WhatsApp Business template, DLT-registered SMS template) with camp name and case count only. | M |
FR-17 | The job shall log delivery status per channel and retry failed sends (configurable, e.g. 3 attempts). | M |
FR-18 | The link shall expire after a configurable period (e.g. 7 days) or once the report is submitted, whichever is earlier; the camp user can resend a fresh link. | M |
FR-19 | The system shall send reminders to the doctor for cases still pending past the turnaround target (configurable; value to be confirmed). The target drives reminders only, not escalation. | S |
7.4 Doctor authentication
ID | Requirement | Priority |
FR-20 | On opening the link, the doctor shall see a masked mobile number (e.g. XXXXXX4321) and request an OTP. | M |
FR-21 | The system shall send a 6-digit OTP by SMS (WhatsApp as fallback) to the mobile number recorded for that case only. | M |
FR-22 | The OTP shall be valid for 5 minutes, allow at most 3 wrong attempts, and allow resend after 30 seconds, up to 3 resends. | M |
FR-23 | After repeated failures the link shall lock for a configurable period and the camp user / admin shall be alerted. | M |
FR-24 | A verified session shall time out after a configurable idle period (e.g. 30 minutes) and require OTP again. | M |
FR-25 | A doctor who receives several cases shall be able to see all cases assigned to their mobile number after one OTP (doctor worklist). | S |
7.5 X-ray viewing (DICOM viewer)
ID | Requirement | Priority |
FR-26 | After OTP verification, the doctor shall see the case summary: Beneficiary ID, age, sex, camp, date of X-ray, view, clinical notes. The beneficiary's name and contact details shall be masked; only Beneficiary ID, age and sex identify the beneficiary. | M |
FR-27 | Images shall open in a zero-footprint web DICOM viewer (e.g. OHIF) that works in desktop and mobile browsers without installation. | M |
FR-28 | The viewer shall support zoom, pan, window/level (contrast), invert, rotate/flip, measurement, and full-screen. | M |
FR-29 | The viewer shall display prior X-rays of the same beneficiary, where available, for comparison. | C |
FR-30 | Download, print and screenshot of images shall be disabled by default; images shall be watermarked with doctor and time. | S |
7.6 Report submission (doctor)
ID | Requirement | Priority |
FR-31 | The doctor shall report on one of two templates — a TB-screening form or a general chest X-ray report — capturing: findings, impression, Normal / Abnormal flag, suspected condition (e.g. TB-suggestive), recommendation, urgency (Routine / Urgent). | M |
FR-32 | The doctor shall be able to save a draft and submit later within link validity. | S |
FR-33 | On submit, the report shall carry the doctor's sign-off — doctor name, MCI / NMC registration number, contact details (mobile, email), place, and timestamp; the report becomes read-only. | M |
FR-34 | The doctor may mark an image as not readable (poor quality) with a reason, triggering a re-take request to the camp. | M |
FR-35 | The system shall generate a PDF report with camp, beneficiary, findings and doctor sign-off. | S |
FR-36 | Corrections after submission shall be made only as an addendum, keeping the original. | S |
FR-45 | On first OTP login, the doctor shall be asked to create a profile with doctor name, MCI / NMC registration number, contact details (mobile, email) and place (city / hospital). This is a one-time activity; the profile is saved against the doctor's verified mobile number. | M |
FR-46 | For every later report, the saved profile shall auto-fill the doctor details on the report; the doctor does not re-enter them. | M |
FR-47 | The doctor shall be able to view and edit the profile at any time; changes apply to future reports only, and submitted reports keep the details they were signed with. | M |
FR-48 | A report cannot be submitted until the profile is complete; the registration number format and contact details shall be validated. | S |
7.7 Result return and notification (camp)
ID | Requirement | Priority |
FR-37 | The submitted report shall be attached to the beneficiary record in the central system and visible in the camp application. | M |
FR-38 | The camp user who uploaded the case shall be notified in-app, and optionally by SMS / WhatsApp / email, when a report is submitted. | M |
FR-39 | Reports marked Urgent or Abnormal shall be highlighted and notified to the camp user and supervisor immediately. | M |
FR-40 | The camp user shall be able to view, print or share the PDF report with the beneficiary. The system never sends reports to the beneficiary directly; they go only through the camp. | S |
7.8 Status tracking and monitoring
ID | Requirement | Priority |
FR-41 | Every case shall carry a status (see section 8), updated automatically by system events. | M |
FR-42 | The camp user shall see a worklist filterable by status, camp, date, doctor and beneficiary ID. | M |
FR-43 | A supervisor dashboard shall show counts by status, pending ageing (e.g. >24 h, >48 h) and turnaround time per doctor. | S |
FR-44 | Every action (upload, send, open link, OTP, view, submit, notify) shall be written to an audit log with user, time and IP / device. | M |
8. Status model
Camp users see two headline statuses, Pending and Completed; the detailed status underneath tells them where a pending case is stuck.
Detailed status | Headline | Set when | Visible action for camp user |
Uploaded | Pending | All images saved to the central server | — |
Link sent | Pending | Notification job delivers link on at least one channel | Resend link |
Delivery failed | Pending | All channels failed after retries | Correct contact details, resend |
Opened | Pending | Doctor verifies OTP and opens the case | — |
Draft saved | Pending | Doctor saves report without submitting | — |
Re-take requested | Pending | Doctor marks image not readable | Upload new image |
Link expired | Pending | Link validity ends with no report | Resend or reassign |
Completed | Completed | Doctor submits report | View, print, share report |
Completed – Urgent | Completed | Submitted report flagged Urgent / Abnormal | Act on referral immediately |
Status changes are system-driven only; camp users cannot set a case to Completed manually.
9. Non-functional requirements
ID | Area | Requirement |
NFR-01 | Security | All traffic over HTTPS (TLS 1.2+); images and reports encrypted at rest. |
NFR-02 | Security | Image URLs served only through the authenticated viewer session; no public or permanent file links. |
NFR-03 | Privacy and compliance | Handle data in line with the DPDP Act 2023 and ABDM / NDHM health data guidelines; record beneficiary consent for tele-consultation at the camp. |
NFR-04 | Privacy | Messages to doctors carry no personal or clinical details; minimum necessary data shown in viewer. |
NFR-05 | Standards | Store images in a DICOM-compliant archive (PACS, e.g. Orthanc / DICOMweb) with study and series metadata preserved. |
NFR-06 | Performance | First image visible in the viewer within 5 seconds on a 4G connection; OTP delivered within 30 seconds. |
NFR-07 | Connectivity | Camp upload must tolerate intermittent or low bandwidth (chunked, resumable uploads; optional compression). |
NFR-08 | Availability | Central server and viewer available 99.5% monthly. |
NFR-09 | Retention | Images and reports retained per program policy (to be confirmed); audit logs kept at least as long. |
NFR-10 | Usability | Viewer and report form usable on a smartphone; camp screens available in English and the local language. |
NFR-11 | Scalability | Support concurrent uploads from all active camps and growth in images per day without redesign. |
NFR-12 | Integration | Reuse existing beneficiary registry and messaging gateways (SMS / WhatsApp / email) through APIs. |
10. Assumptions, dependencies, risks and open questions
Assumptions
- The X-ray device can export DICOM files to the linked laptop.
- Camps have at least intermittent internet to sync uploads.
- Beneficiary IDs are created in the central system before or at the camp.
- Doctors are onboarded and have agreed to report via this channel.
Dependencies
- WhatsApp Business API account and approved message templates.
- DLT-registered SMS sender ID and templates (TRAI).
- Email service, PACS / DICOM storage, and a web DICOM viewer.
Risks and mitigations
Risk | Mitigation |
Link forwarded to someone else | OTP bound to the doctor's mobile number; short session; watermarking; audit log |
Wrong image tagged to a beneficiary | ID check against DICOM metadata (FR-04); thumbnail preview before submit |
Poor connectivity at camps delays upload | Offline queue and resumable upload (FR-06) |
Doctor does not respond | Reminders (FR-19), ageing dashboard, reassignment (FR-13) |
Message template rejection or SMS failure | Multi-channel send and delivery retries (FR-17) |
11. Acceptance criteria
- A camp user can upload 3 X-rays for one Beneficiary ID with doctor details, and all 3 appear on the central server linked to that ID.
- Within 5 minutes the doctor receives the link on each chosen channel; the message has no beneficiary details.
- Opening the link without a valid OTP shows no image or case data.
- A correct OTP opens the case; three wrong OTPs lock the link and alert the camp user.
- The doctor can view the images with zoom, contrast and measure tools on desktop and mobile browsers.
- On report submission, the status changes to Completed, the camp user is notified, and the report is visible against the beneficiary.
- An Urgent / Abnormal report triggers an immediate highlighted notification to the camp user and supervisor.
- After submission or expiry, the same link can no longer open the case.
- Every step above appears in the audit log with user and timestamp.