Connected operational workflows
Built patient, appointment, queue, consultation and billing APIs with shared TypeScript contracts and role-aware workspaces. The interface reads real persisted state instead of decorative dashboard metrics.
Hospital Management Platform
Connecting each step of a patient visit.
abox connects patient registration, appointments, queue coordination, consultation notes and billing through a Next.js workspace and a NestJS/PostgreSQL API.
Healthcare administration / independent engineering project
Next.jsNestJSPostgreSQLDrizzle ORMRole-based access
Who it is for
Administrative staff coordinating patient records, appointments, queues and billing; the local showcase uses fictional patient records only.
The problem it solves
An appointment, a queue position, a clinical note and a payment record describe different parts of the same visit. Keeping them connected requires explicit transitions, role boundaries, persistent records and interfaces that make the next action clear.
What I personally built
Built patient, appointment, queue and billing workflows, PostgreSQL data paths, revocable cookie sessions, server-side role checks and mutation audit trails; integrated supplied abox branding and prepared delivery infrastructure.
Protected state changes
Added transactional queue coordination, server-side role and session checks, mutation audit records, and explicit restrictions around completed visits and paid charges.
Reproducible delivery
Organized the pnpm/Turbo application, Docker packages and PostgreSQL migrations. Prepared a separate EC2/Compose path with a nonpublishing image workflow and backup/restore safeguards; historical Kubernetes and monitoring configurations remain source evidence.
How the product works
6 inspectable stepsFresh captures from the current abox production frontend, a local API container and isolated migrated PostgreSQL 17. Login, records, queue transitions and payment persistence use real application paths. All patient records are fictional. The consultation image is retained from the prior Phase 5 capture and is labeled separately. No cloud runtime is implied.
Choose a detail step to use zoom and dimming.
Three demo appointments coexist with two waiting visits and one in care. These are different measures, not interchangeable counts or real clinical activity.
Guided inspection
Step 1 of 6
Coordinate the visit
The administration dashboard combines today's schedule and queue state with links to patient registration and billing. The visible counts reflect actual records created through the local API.
Authentic application captures. These controls explore screenshot evidence; they do not operate the app. Use Zoom to evidence, dim the surroundings, or open the full-resolution image. The text transcript below works without JavaScript.
Read every walkthrough step as text
1. Coordinate the visit
The administration dashboard combines today's schedule and queue state with links to patient registration and billing. The visible counts reflect actual records created through the local API.
Three demo appointments coexist with two waiting visits and one in care. These are different measures, not interchangeable counts or real clinical activity.
Inspect corresponding screenshot (opens in a new tab)2. Find the patient record
The patient directory provides search and explicit links into queue and consultation workflows. Contact and demographic details remain collapsed until requested.
Add to Queue and Consult target the selected patient. This is a fresh capture of the current abox application, not the earlier Pulse Medical interface.
Inspect corresponding screenshot (opens in a new tab)3. Schedule the next visit
Appointments keep the patient, clinician, time, reason and explicit visit state together. These three confirmed visits were created through the real API and loaded from PostgreSQL.
Scheduling and queue status are separate workflows. Confirmation does not mean the patient is already in care; polling refreshes the mounted schedule every five seconds.
Inspect corresponding screenshot (opens in a new tab)4. Move from waiting to care
The fresh queue separates waiting visits, care in progress and completed visits. Two fictional visits are waiting in this capture. Foreground polling refreshes the mounted view every five seconds.
Call Next and per-patient actions belong to the actual queue. This capture shows the waiting state; the separate earlier transition evidence and transaction design remain inspectable.
Inspect corresponding screenshot (opens in a new tab)5. Inspect the consultation
A doctor-session API request created this SOAP note. The administration session can inspect its subjective, objective, assessment and plan sections; the captured view correctly shows read-only access.
Every section contains fictional verification text. The screenshot demonstrates persisted structure and the admin reading state, not a real clinical assessment or doctor-form submission.
Inspect corresponding screenshot (opens in a new tab)6. Record a payment received
The browser confirmed Mark paid on the synthetic consultation charge. The record changed to PAID, the outstanding amount became PHP 750, and the paid state survived a page reload.
This records a payment received by staff. It does not charge a card or connect to a payment processor. The remaining overdue charge stays outstanding.
Inspect corresponding screenshot (opens in a new tab)
Review a fictional administrative visit
Local standalone abox frontend and cached Phase 3A API; real cookie session and disposable migrated PostgreSQL. All patients, appointments and charges are fictional.
Recording transcript
- Read the administration dashboard, then inspect fictional patient records.
- Review appointment scheduling and queue management.
- Open billing and confirm a synthetic charge as paid.
- Reload billing and verify the PAID state persists in PostgreSQL.
Read the Phase 5D capture and verification report
Inspect the mobile captures (390 × 844)
Difficult engineering decisions
Keep linked records consistent
Patient, appointment, queue and billing records cross workflow boundaries. Server-side relationship validation and authorization complement the interface; a convenient UI alone cannot enforce them.
Represent money and refresh honestly
Billing distinguishes legacy amounts requiring review from explicit PHP minor units. The captured frontend refreshes by five-second polling; gateway source does not prove WebSocket use.
Separate infrastructure from operation
Historical Kubernetes, Terraform, CI/CD and monitoring definitions remain source evidence. The newer EC2/Compose preparation adds file secrets, bounded services and backup/restore tooling, but the intended deployment environment has not passed its eligibility gate. No running AWS or Kubernetes system is claimed.
Architecture behind the interface
A session boundary at the API
Login establishes an HttpOnly cookie. Cookie-authenticated mutations validate the browser origin, while backend role guards enforce access beyond the frontend navigation.
apps/backend/src/auth/session.ts (opens in a new tab)Queue transitions inside transactions
Adding a patient uses an advisory transaction lock to allocate the next queue number and reject a duplicate active visit. Calling next locks the selected waiting row and skips rows already claimed by another transaction.
apps/backend/src/queue/queue.service.ts (opens in a new tab)Persisted changes with an audit trail
The Drizzle database service commits each audited mutation and its audit event together. Audit details record changed field names while filtering password/token names rather than copying clinical contents or credentials.
apps/backend/src/database/database.service.ts (opens in a new tab)Delivery and recovery boundaries
The new Compose path isolates database access, loads file secrets, bounds services and makes migration/backup/restore steps explicit. Local amd64 preparation does not verify the intended cloud account, ARM64 runtime or full instance recovery.
deploy/aws-demo/README.md (opens in a new tab)Evidence, with boundaries
Read Phase 5 verification reportUpstream results below are attributed to their recorded checks. This portfolio change does not rerun every application suite.
Fresh database-backed capture
Seven abox screens/states were captured from the real local application. The synthetic PHP 1,250 charge changed to PAID and stayed paid after reload. The isolated PostgreSQL fixture contained four patients, three appointments, one note and 17 audit events. These are test records, not adoption metrics.
Recorded workflow and branding checks
The Phase 1A report records 32 backend unit tests, 42 PostgreSQL end-to-end tests and eight browser cases including all six roles. The later branding report records 19 rendering states using synthetic API stubs; those establish branding only. Frontend lint/format wrapper failures and the successful direct Biome fallback remain documented.
Prepared infrastructure, no deployment
The current preparation report records offline safety tests, Compose checks, amd64 image builds and a disposable local runtime/restore rehearsal. The intended account eligibility gate is unresolved; native ARM64, remote bootstrap, live HTTPS and full instance recovery are not established.
What remains unverified
Working implementation and release readiness have different evidence requirements.
- Fictional records and a disposable local database establish selected application paths, not clinical use, regulatory compliance or production readiness.
- The frontend build contains a loopback API origin. During capture, browser requests were forwarded to the isolated real API on an unused port; no API responses, sessions or database writes were mocked. Capture details are recorded in the Phase 5 report.
- The current app uses supplied abox assets. Earlier Pulse screenshots are retained in the before evidence; branding-only upstream captures used API stubs and are not presented as product workflow verification.
- Application suites were not rerun for this portfolio task. Prior checks have their own scope: frontend wrapper lint/format startup failures, an existing sidebar warning, and Chromium/physical-device gaps remain documented.
- AWS deployment remains blocked by its intended-environment prerequisites. Historical Kubernetes/Terraform and monitoring files, local amd64 builds and a limited restore rehearsal do not establish a running cluster, ARM64 behavior or disaster-recovery objectives.
- The captured queue/scheduling views use five-second polling. Billing records money received by staff and does not charge a payment processor; legacy amount review needs its separate explicit workflow.
Follow the source
Open repository (opens in a new tab)Source links use inspected revision 21d9b79. The workflow screenshots were recaptured for this portfolio change with genuine sessions and a disposable database. Branding-only stub captures and historical infrastructure reports are identified separately.
Workflow and database verification (opens in a new tab)abox brand provenance and rendering-only checks (opens in a new tab)Latest deployment preparation and unresolved gates (opens in a new tab)Production Compose and recovery runbook (opens in a new tab)Backend ownership and role boundaries (opens in a new tab)Existing real multi-session browser tests (opens in a new tab)