YasinVirani

Reporting workflow

Every report starts from one of 670+ templates and moves through a fixed pipeline, with the patient's history alongside.

1. Draft
2. Review
3. Signed off

Access & audit

Role-based access, Keycloak single sign-on over OIDC, JWT, and an IHE ATNA-style audit trail.

• Admin
• Doctor
• Technologist
• Viewer

1. Technologist stored a study
2. Doctor signed a report
3. Admin provisioned a user
4. Viewer opened a study

Accessible by design

Light and dark themes, text scaling, high-contrast and grayscale modes. These buttons work:

Clinic integration

A dedicated external API lets referring clinics retrieve signed-off reports and images.

// illustrative
GET /external/reports/{id}
Authorization: Bearer <jwt>

200 { status: "signed", images: […] }

Stock that can't double-count

Issues and returns lock the rows they touch, so two counters working at once always leave the right balance.

-- illustrative
BEGIN;
SELECT qty FROM stock
  WHERE item_id = $1
  FOR UPDATE;
-- issue, then
COMMIT;

Config-driven reports

Each report is a registry entry served through one API, so a new report needs no new endpoint.

// illustrative
opd_daily: {
  sql: "SELECT …",
  params: ["from", "to"],
  pdf: "landscape"
}

Encrypted in transit

Request and response bodies are AES-256-CBC encrypted between client and server, on top of JWT authentication and per-hospital data scoping.

// illustrative
POST /api/opd/register
Authorization: Bearer <jwt>

{ payload: "9f2c…e71a" }

On-premise AI

A local Llama 3.2 model served by Ollama. Patient data never leaves the hospital network.

• Clinical suggestions
• Discharge summaries
• ICD-10 coding
• Lab summaries
• Radiology summaries
• Prescription safety
• Voice dictation

National health network

ABDM integration for health IDs, health-record linking and consent-based sharing, plus a payment gateway and Firebase push notifications.

1. Counter verified an ABHA ID
2. Scheduler linked an OPD record
3. Patient granted consent
4. Audit logged the attempt

The hospital's own codes

Each machine names its tests its own way. A mapping turns them into the hospital system's codes and converts units, so results land correctly in patient records.

// illustrative
GLU: { code: "<hospital code>",
  unit: "mg/dL", factor: 18 }

All or nothing

Every save runs in a PostgreSQL transaction over a connection pool. Partial or repeated records never reach patient data.

1. Sample new, saved
2. Sample duplicate, skipped
3. Write failed, rolled back
4. Sample new, saved

Runs unattended

Errors are caught at three levels, so one bad message or dropped connection doesn't stop the service.

• Socket
• Parse
• Process

1. Socket dropped, waiting to reconnect
2. Parse bad record, logged
3. Process error caught, still running

One executable

Packaged with pkg as a standalone Windows executable, so a lab workstation needs nothing else installed.

// illustrative
C:\Lab> lis-interface.exe
› listening on the lab network
› lab machine connected
› result saved