2370 lines
25 KiB
Markdown
2370 lines
25 KiB
Markdown
# VigilCare Records — UI/UX Design Specification
|
||
|
||
## 1. Product Design Direction
|
||
|
||
### Product character
|
||
|
||
VigilCare Records should feel:
|
||
|
||
* Clinical, but not sterile
|
||
* Enterprise-grade, but not visually heavy
|
||
* Trustworthy and controlled
|
||
* Optimized for repetitive daily workflows
|
||
* Extremely clear about data state
|
||
* Conservative around destructive or irreversible actions
|
||
* Fast for trained operators
|
||
* Understandable for occasional clinical users
|
||
|
||
The interface should communicate one central idea:
|
||
|
||
**Nothing becomes clinical truth until it has passed the required human review.**
|
||
|
||
The product should therefore visually distinguish:
|
||
|
||
1. Source evidence
|
||
2. Draft/extracted data
|
||
3. Verified data
|
||
4. Approved clinical data
|
||
5. Promoted/live data
|
||
|
||
These states should never become visually ambiguous.
|
||
|
||
---
|
||
|
||
# 2. Core Visual System
|
||
|
||
## 2.1 Overall visual language
|
||
|
||
Use a modern flat enterprise interface with:
|
||
|
||
* White primary surfaces
|
||
* Very light cool-gray application background
|
||
* Dark navy navigation
|
||
* Strong blue primary actions
|
||
* Restrained semantic colors
|
||
* Rounded but not excessively rounded containers
|
||
* Minimal shadows
|
||
* Thin borders
|
||
* High information density without appearing cramped
|
||
|
||
Avoid:
|
||
|
||
* Excessive gradients
|
||
* Glassmorphism
|
||
* Large decorative illustrations inside operational pages
|
||
* Purple-heavy AI/SaaS aesthetics
|
||
* Excessive pill-shaped UI
|
||
* Floating cards everywhere
|
||
* Oversized typography
|
||
* Large amounts of animation
|
||
|
||
VigilCare should look like software designed for a hospital workstation rather than a consumer productivity app.
|
||
|
||
---
|
||
|
||
# 3. Color System
|
||
|
||
## Primary
|
||
|
||
### VigilCare Navy
|
||
|
||
`#08254A`
|
||
|
||
Used for:
|
||
|
||
* Sidebar
|
||
* Logo backdrop
|
||
* Strong structural navigation
|
||
* Selected dark-mode elements
|
||
|
||
### Primary Blue
|
||
|
||
`#155EEF`
|
||
|
||
Used for:
|
||
|
||
* Primary CTA
|
||
* Selected navigation item
|
||
* Links
|
||
* Focus states
|
||
* Progress indicators
|
||
* Active tabs
|
||
|
||
### Primary Blue Hover
|
||
|
||
`#0B4FD6`
|
||
|
||
### Soft Blue
|
||
|
||
`#EEF4FF`
|
||
|
||
Used for:
|
||
|
||
* Selected rows
|
||
* Informational panels
|
||
* Active filters
|
||
* Non-critical status backgrounds
|
||
|
||
---
|
||
|
||
## Neutral
|
||
|
||
### Page Background
|
||
|
||
`#F7F9FC`
|
||
|
||
### Surface
|
||
|
||
`#FFFFFF`
|
||
|
||
### Strong Text
|
||
|
||
`#101828`
|
||
|
||
### Body Text
|
||
|
||
`#344054`
|
||
|
||
### Secondary Text
|
||
|
||
`#667085`
|
||
|
||
### Disabled Text
|
||
|
||
`#98A2B3`
|
||
|
||
### Border
|
||
|
||
`#E4E7EC`
|
||
|
||
### Strong Border
|
||
|
||
`#D0D5DD`
|
||
|
||
---
|
||
|
||
## Semantic colors
|
||
|
||
### Success
|
||
|
||
Foreground: `#079455`
|
||
Background: `#ECFDF3`
|
||
|
||
Use for:
|
||
|
||
* Verification passed
|
||
* Promotion complete
|
||
* Valid records
|
||
* Healthy service state
|
||
|
||
### Warning
|
||
|
||
Foreground: `#DC6803`
|
||
Background: `#FFFAEB`
|
||
|
||
Use for:
|
||
|
||
* Low-confidence OCR
|
||
* Approaching SLA
|
||
* Validation warning
|
||
* Uncertain comparison
|
||
|
||
### Error
|
||
|
||
Foreground: `#D92D20`
|
||
Background: `#FEF3F2`
|
||
|
||
Use for:
|
||
|
||
* Rejection
|
||
* Validation failure
|
||
* Critical discrepancy
|
||
* Failed upload
|
||
|
||
### Critical Clinical
|
||
|
||
Foreground: `#B42318`
|
||
Background: `#FEE4E2`
|
||
|
||
Reserve stronger red treatment for actual clinical urgency.
|
||
|
||
This distinction matters:
|
||
|
||
**A workflow error is not automatically a clinical emergency.**
|
||
|
||
---
|
||
|
||
# 4. Typography
|
||
|
||
## Font family
|
||
|
||
Primary:
|
||
|
||
**Inter**
|
||
|
||
Fallback:
|
||
|
||
`Inter, "Segoe UI", Roboto, Helvetica, Arial, sans-serif`
|
||
|
||
For JSON/code:
|
||
|
||
**JetBrains Mono** or **Roboto Mono**
|
||
|
||
---
|
||
|
||
## Type scale
|
||
|
||
### Page title
|
||
|
||
28 px
|
||
Weight: 650–700
|
||
Line height: 34 px
|
||
|
||
Examples:
|
||
|
||
* Data Entry
|
||
* Verification
|
||
* Clinical Approval
|
||
* Patient History
|
||
|
||
---
|
||
|
||
### Major section heading
|
||
|
||
20 px
|
||
Weight: 600
|
||
Line height: 28 px
|
||
|
||
---
|
||
|
||
### Card heading
|
||
|
||
16 px
|
||
Weight: 600
|
||
Line height: 24 px
|
||
|
||
---
|
||
|
||
### Field/section label
|
||
|
||
14 px
|
||
Weight: 600
|
||
|
||
---
|
||
|
||
### Primary body
|
||
|
||
14 px
|
||
Weight: 400
|
||
Line height: 20–22 px
|
||
|
||
---
|
||
|
||
### Secondary/meta text
|
||
|
||
12 px
|
||
Weight: 400–500
|
||
Line height: 18 px
|
||
|
||
---
|
||
|
||
### Table heading
|
||
|
||
12 px
|
||
Weight: 600
|
||
Uppercase should generally be avoided.
|
||
|
||
---
|
||
|
||
### Large metric
|
||
|
||
28–32 px
|
||
Weight: 650
|
||
|
||
Used only for:
|
||
|
||
* Queue counts
|
||
* Throughput
|
||
* Accuracy
|
||
* Important dashboard numbers
|
||
|
||
---
|
||
|
||
## Typography rule
|
||
|
||
Clinical values should have more visual weight than labels.
|
||
|
||
Example:
|
||
|
||
BP
|
||
**138/88 mmHg**
|
||
|
||
not:
|
||
|
||
**BP**
|
||
138/88 mmHg
|
||
|
||
---
|
||
|
||
# 5. Spacing System
|
||
|
||
Use an 8 px base grid.
|
||
|
||
Core values:
|
||
|
||
* 4 px — micro spacing
|
||
* 8 px — related items
|
||
* 12 px — compact controls
|
||
* 16 px — standard component gap
|
||
* 24 px — card padding
|
||
* 32 px — section separation
|
||
* 40–48 px — large page separation
|
||
|
||
Default page gutter:
|
||
|
||
**24–32 px**
|
||
|
||
---
|
||
|
||
# 6. Border Radius
|
||
|
||
Avoid excessive softness.
|
||
|
||
### Small controls
|
||
|
||
6 px
|
||
|
||
### Inputs/buttons
|
||
|
||
8 px
|
||
|
||
### Cards
|
||
|
||
10 px
|
||
|
||
### Large containers
|
||
|
||
12 px
|
||
|
||
Avoid 20–30 px consumer-style card radii.
|
||
|
||
---
|
||
|
||
# 7. Shadow System
|
||
|
||
Cards should rely mainly on borders.
|
||
|
||
Default card:
|
||
|
||
`border: 1px solid #E4E7EC`
|
||
|
||
Optional:
|
||
|
||
`box-shadow: 0 1px 2px rgba(16, 24, 40, 0.04)`
|
||
|
||
Dialogs:
|
||
|
||
`0 8px 24px rgba(16,24,40,0.12)`
|
||
|
||
---
|
||
|
||
# 8. Application Shell
|
||
|
||
## Sidebar
|
||
|
||
Desktop width:
|
||
|
||
**208–224 px**
|
||
|
||
Background:
|
||
|
||
VigilCare Navy.
|
||
|
||
### Structure
|
||
|
||
Logo
|
||
|
||
Main workspace:
|
||
|
||
* Dashboard
|
||
* Intake
|
||
* Cover Sheets
|
||
* Data Entry
|
||
* Verification
|
||
* Clinical Approval
|
||
* Live Capture
|
||
* Patient History
|
||
|
||
Supervision:
|
||
|
||
* Supervisor Dashboard
|
||
* Workload / Queues
|
||
* Reports
|
||
|
||
Administration:
|
||
|
||
* Users
|
||
* Master Data
|
||
* FHIR Explorer
|
||
* Configuration
|
||
* Audit Logs
|
||
|
||
Items should be conditionally shown based on permissions.
|
||
|
||
Do not show inaccessible features disabled unless there is a strong reason.
|
||
|
||
---
|
||
|
||
## Selected item
|
||
|
||
Background:
|
||
|
||
`#155EEF`
|
||
|
||
Text:
|
||
|
||
white
|
||
|
||
Icon:
|
||
|
||
white
|
||
|
||
Border radius:
|
||
|
||
6–8 px
|
||
|
||
---
|
||
|
||
## Header
|
||
|
||
Height:
|
||
|
||
64 px
|
||
|
||
Contains:
|
||
|
||
* Global search
|
||
* Alerts
|
||
* Help
|
||
* Current user
|
||
* Role
|
||
* Facility/site selector where applicable
|
||
|
||
Keep headers thin because most users need vertical workspace.
|
||
|
||
---
|
||
|
||
# 9. Global Interaction Principles
|
||
|
||
## Autosave
|
||
|
||
For entry workflows:
|
||
|
||
Display a subtle state:
|
||
|
||
`Saved 10:24:31`
|
||
|
||
Do not show repeated success notifications.
|
||
|
||
States:
|
||
|
||
* Saving…
|
||
* Saved
|
||
* Save failed
|
||
|
||
Failure must become visually prominent.
|
||
|
||
---
|
||
|
||
## Keyboard support
|
||
|
||
Data-entry users should be able to complete most tasks without the mouse.
|
||
|
||
Recommended:
|
||
|
||
* `Ctrl/Cmd + S` — save draft
|
||
* `Alt + N` — next document
|
||
* `Alt + P` — previous document
|
||
* `Alt + F` — flag/reject
|
||
* `Alt + V` — submit for verification
|
||
* `+/-` — zoom
|
||
* `R` — rotate when document viewer has focus
|
||
|
||
---
|
||
|
||
## Status labels
|
||
|
||
Use semantic labels consistently.
|
||
|
||
Examples:
|
||
|
||
* Uploaded
|
||
* In Entry
|
||
* Pending Verification
|
||
* Verification Rejected
|
||
* Pending Approval
|
||
* Approved
|
||
* Promoted
|
||
* Superseded
|
||
* Failed
|
||
|
||
Never use several different names for the same state.
|
||
|
||
---
|
||
|
||
# 10. LOGIN
|
||
|
||
## Objective
|
||
|
||
Authenticate the user and route them automatically according to authorization.
|
||
|
||
---
|
||
|
||
## Important correction
|
||
|
||
**Remove the role selector from the generated Login concept.**
|
||
|
||
The backend should determine roles through authentication/JWT claims.
|
||
|
||
A user should not select:
|
||
|
||
> Data Entry Operator / Verifier / Clinician
|
||
|
||
before authentication.
|
||
|
||
If a user possesses multiple authorized roles, role switching can happen **after login**.
|
||
|
||
---
|
||
|
||
## Layout
|
||
|
||
Two-column desktop layout.
|
||
|
||
### Left — Brand panel
|
||
|
||
Approximately 45%.
|
||
|
||
Dark navy.
|
||
|
||
Contains:
|
||
|
||
VigilCare Records logo
|
||
|
||
Headline:
|
||
|
||
**Digitize. Verify. Trust.**
|
||
|
||
Subtext explaining that scanned clinical records become governed structured data.
|
||
|
||
Optional restrained illustration:
|
||
|
||
Paper record → verified digital record.
|
||
|
||
Avoid feature marketing clutter.
|
||
|
||
---
|
||
|
||
### Right — Authentication
|
||
|
||
Centered card around 420–460 px wide.
|
||
|
||
Fields:
|
||
|
||
Username/email
|
||
Password
|
||
|
||
Optional:
|
||
|
||
Remember device
|
||
|
||
Actions:
|
||
|
||
**Sign In**
|
||
|
||
Secondary:
|
||
|
||
Forgot password
|
||
|
||
Hospital SSO, if actually supported.
|
||
|
||
---
|
||
|
||
## Typography
|
||
|
||
Headline: 38–42 px
|
||
|
||
Login heading: 28 px
|
||
|
||
Input labels: 14 px / 600
|
||
|
||
---
|
||
|
||
## Visual emphasis
|
||
|
||
The authentication form should dominate the right side.
|
||
|
||
No dashboard UI should be displayed prominently enough to distract from authentication.
|
||
|
||
---
|
||
|
||
# 11. DASHBOARD
|
||
|
||
## Objective
|
||
|
||
Answer:
|
||
|
||
**What work requires my attention right now?**
|
||
|
||
This should change depending on role.
|
||
|
||
---
|
||
|
||
## Top metrics
|
||
|
||
Examples:
|
||
|
||
* My Assignments
|
||
* Awaiting Verification
|
||
* Awaiting Approval
|
||
* Promoted Today
|
||
|
||
Supervisor roles may instead see:
|
||
|
||
* Total queue
|
||
* Oldest batch
|
||
* Rejection rate
|
||
* Throughput
|
||
|
||
---
|
||
|
||
## Main content
|
||
|
||
Recommended structure:
|
||
|
||
### Left 65%
|
||
|
||
My Queue / Batch Queue
|
||
|
||
Columns:
|
||
|
||
Batch ID
|
||
Type
|
||
Track
|
||
Progress
|
||
Status
|
||
Priority
|
||
Age / SLA
|
||
|
||
### Right 35%
|
||
|
||
My workflow status
|
||
|
||
Recent activity
|
||
|
||
Quick actions
|
||
|
||
---
|
||
|
||
## Avoid
|
||
|
||
Do not fill the dashboard with system infrastructure monitoring.
|
||
|
||
API/Postgres/Redis status belongs in administration or monitoring unless failures affect current work.
|
||
|
||
---
|
||
|
||
# 12. INTAKE
|
||
|
||
## Objective
|
||
|
||
Turn incoming scans into a valid digitization batch.
|
||
|
||
---
|
||
|
||
## Layout
|
||
|
||
Two-column layout.
|
||
|
||
### Main — 70%
|
||
|
||
Upload area
|
||
|
||
Batch configuration
|
||
|
||
### Right — 30%
|
||
|
||
Recent uploads
|
||
|
||
---
|
||
|
||
## Upload zone
|
||
|
||
Large bordered drop target.
|
||
|
||
Supports:
|
||
|
||
PDF
|
||
JPEG
|
||
PNG
|
||
|
||
Display:
|
||
|
||
Max 25 MB
|
||
|
||
Primary:
|
||
|
||
**Upload Files**
|
||
|
||
Secondary:
|
||
|
||
Drag and drop
|
||
|
||
Do not use three equally prominent upload CTAs.
|
||
|
||
---
|
||
|
||
## Batch Details
|
||
|
||
Fields:
|
||
|
||
### Batch Type
|
||
|
||
Examples:
|
||
|
||
* Registration
|
||
* Vitals
|
||
* Labs
|
||
* Medications
|
||
* Allergies
|
||
* Mixed Chart
|
||
|
||
### Track
|
||
|
||
Radio/select:
|
||
|
||
**Backfill**
|
||
|
||
Historical or archival document workflow.
|
||
|
||
**Live Capture**
|
||
|
||
Documents generated as part of current bedside workflows.
|
||
|
||
### Patient Link
|
||
|
||
Optional.
|
||
|
||
Search:
|
||
|
||
MRN
|
||
Name
|
||
|
||
### Cover Sheet Code
|
||
|
||
Optional.
|
||
|
||
Barcode/QR scan automatically fills compatible metadata.
|
||
|
||
---
|
||
|
||
## Right panel
|
||
|
||
Recent uploads.
|
||
|
||
Columns:
|
||
|
||
File
|
||
Batch
|
||
Status
|
||
Uploaded
|
||
Operator
|
||
|
||
---
|
||
|
||
## States
|
||
|
||
Uploading
|
||
|
||
Processing
|
||
|
||
Ready
|
||
|
||
Failed
|
||
|
||
Duplicate detected
|
||
|
||
Barcode recognized
|
||
|
||
---
|
||
|
||
## Styling
|
||
|
||
The upload zone should be approximately the largest visual element.
|
||
|
||
Blue dashed border only during empty/drop state.
|
||
|
||
Once files are selected, transition into a file list rather than keeping a huge empty drop zone.
|
||
|
||
---
|
||
|
||
# 13. COVER SHEETS
|
||
|
||
## Objective
|
||
|
||
Generate physical/digital separators that reliably reconnect scanned paper to system metadata.
|
||
|
||
---
|
||
|
||
## Layout
|
||
|
||
Top section:
|
||
|
||
50 / 50 split.
|
||
|
||
Left:
|
||
|
||
Generation form
|
||
|
||
Right:
|
||
|
||
Live preview
|
||
|
||
Bottom:
|
||
|
||
Existing cover sheet table
|
||
|
||
---
|
||
|
||
## Generation form
|
||
|
||
Fields:
|
||
|
||
Quantity
|
||
|
||
Batch/document type
|
||
|
||
Track
|
||
|
||
Patient — optional
|
||
|
||
Entry clerk — optional
|
||
|
||
Primary CTA:
|
||
|
||
**Generate Cover Sheets**
|
||
|
||
---
|
||
|
||
## Preview
|
||
|
||
Show an accurate printable representation.
|
||
|
||
Include:
|
||
|
||
VigilCare logo
|
||
|
||
QR code
|
||
|
||
Human-readable batch identifier
|
||
|
||
Barcode if applicable
|
||
|
||
Document type
|
||
|
||
Track
|
||
|
||
Patient identifier when supplied
|
||
|
||
Generation timestamp
|
||
|
||
---
|
||
|
||
## Existing cover sheets
|
||
|
||
Filters:
|
||
|
||
Search
|
||
|
||
Used / unused / partially used
|
||
|
||
Type
|
||
|
||
Track
|
||
|
||
Date
|
||
|
||
Actions:
|
||
|
||
Download PDF
|
||
|
||
Batch download
|
||
|
||
Regenerate only if business rules permit
|
||
|
||
---
|
||
|
||
## Styling
|
||
|
||
The preview should resemble real paper.
|
||
|
||
White canvas
|
||
|
||
Thin gray border
|
||
|
||
Minimal UI decoration
|
||
|
||
---
|
||
|
||
# 14. DATA ENTRY
|
||
|
||
This is one of the application's most important screens.
|
||
|
||
## Objective
|
||
|
||
Allow operators to accurately transcribe scanned records with minimal context switching.
|
||
|
||
---
|
||
|
||
# Layout
|
||
|
||
Three working regions:
|
||
|
||
### Left — Batch/document queue
|
||
|
||
Approx. 20%
|
||
|
||
### Center — Source document viewer
|
||
|
||
Approx. 35–40%
|
||
|
||
### Right — Structured data entry
|
||
|
||
Approx. 40–45%
|
||
|
||
On smaller desktop screens the queue may collapse.
|
||
|
||
---
|
||
|
||
# Queue
|
||
|
||
Tabs:
|
||
|
||
Uploaded
|
||
|
||
In Entry
|
||
|
||
Rejected
|
||
|
||
Each item shows:
|
||
|
||
Batch ID
|
||
|
||
Facility
|
||
|
||
Document count
|
||
|
||
Progress
|
||
|
||
Assigned operator
|
||
|
||
Status
|
||
|
||
Reason when rejected
|
||
|
||
Selected row:
|
||
|
||
Soft blue background + blue border.
|
||
|
||
---
|
||
|
||
# Document Viewer
|
||
|
||
Must support:
|
||
|
||
Zoom
|
||
|
||
Pan
|
||
|
||
Rotate
|
||
|
||
Fit width
|
||
|
||
Fit page
|
||
|
||
Fullscreen
|
||
|
||
Page thumbnails
|
||
|
||
Page forward/back
|
||
|
||
Optional contrast enhancement if later supported.
|
||
|
||
Document should remain visually neutral.
|
||
|
||
Do not apply decorative shadows beyond a subtle page shadow.
|
||
|
||
---
|
||
|
||
# Data Entry Form
|
||
|
||
Group logically:
|
||
|
||
Patient
|
||
|
||
Encounter
|
||
|
||
Observations
|
||
|
||
Labs
|
||
|
||
Medications
|
||
|
||
Allergies
|
||
|
||
Other required sections based on `fieldRequirements`.
|
||
|
||
---
|
||
|
||
## OCR treatment
|
||
|
||
OCR must appear as an assistant, not an authority.
|
||
|
||
Examples:
|
||
|
||
`OCR 98%`
|
||
|
||
Use small confidence badges beside values.
|
||
|
||
Recommended rules:
|
||
|
||
95–100%
|
||
Subtle green
|
||
|
||
80–94%
|
||
Amber
|
||
|
||
<80%
|
||
Red/strong warning
|
||
|
||
Never automatically imply verification because confidence is high.
|
||
|
||
---
|
||
|
||
## Required fields
|
||
|
||
Small red asterisk.
|
||
|
||
Validation occurs:
|
||
|
||
* inline
|
||
* on blur
|
||
* on submission
|
||
|
||
Avoid waiting until submission to display obvious errors.
|
||
|
||
---
|
||
|
||
## Bottom action bar
|
||
|
||
Sticky.
|
||
|
||
Left:
|
||
|
||
Flag / reject document
|
||
|
||
Center:
|
||
|
||
Save Draft
|
||
|
||
Primary:
|
||
|
||
**Submit for Verification**
|
||
|
||
Right:
|
||
|
||
Next document
|
||
|
||
---
|
||
|
||
## Design principle
|
||
|
||
Users should visually scan:
|
||
|
||
**source → field → source → field**
|
||
|
||
with as little eye travel as possible.
|
||
|
||
---
|
||
|
||
# 15. VERIFICATION
|
||
|
||
This screen requires stronger evidence comparison.
|
||
|
||
## Objective
|
||
|
||
Answer:
|
||
|
||
**Does the draft accurately represent the source document?**
|
||
|
||
---
|
||
|
||
# Layout
|
||
|
||
### Left
|
||
|
||
Verification queue
|
||
|
||
### Center
|
||
|
||
Source scan
|
||
|
||
### Right
|
||
|
||
Entered draft with validation markers
|
||
|
||
---
|
||
|
||
# Separation of Duties
|
||
|
||
Prominent but restrained information banner:
|
||
|
||
**Separation of Duties Enforced**
|
||
|
||
Entered by:
|
||
Arjun Menon
|
||
|
||
Current verifier:
|
||
Priya Nair
|
||
|
||
If same user:
|
||
|
||
Disable verification.
|
||
|
||
Show:
|
||
|
||
**You cannot verify a batch you entered.**
|
||
|
||
Do not allow the user to proceed until another batch is selected.
|
||
|
||
---
|
||
|
||
# Field comparison states
|
||
|
||
### Match
|
||
|
||
Green check.
|
||
|
||
### Warning / uncertain
|
||
|
||
Amber.
|
||
|
||
### Mismatch
|
||
|
||
Red.
|
||
|
||
### Missing
|
||
|
||
Blue/neutral missing state.
|
||
|
||
Avoid relying only on color.
|
||
|
||
Add icons/text.
|
||
|
||
---
|
||
|
||
# Field interaction
|
||
|
||
Verifier should be able to click a field and:
|
||
|
||
* See corresponding source region if OCR coordinates exist
|
||
* Mark correct
|
||
* Mark incorrect
|
||
* Add comment
|
||
|
||
---
|
||
|
||
# Verification decision
|
||
|
||
Sticky bottom area.
|
||
|
||
Options:
|
||
|
||
Pass
|
||
|
||
Reject
|
||
|
||
Reject requires:
|
||
|
||
Reason
|
||
|
||
Optional comment
|
||
|
||
Example rejection reasons:
|
||
|
||
* Incorrect transcription
|
||
* Missing required data
|
||
* Wrong patient
|
||
* Poor scan quality
|
||
* Incorrect document classification
|
||
* Incomplete chart
|
||
|
||
---
|
||
|
||
## Primary CTA
|
||
|
||
When Pass selected:
|
||
|
||
**Pass Verification**
|
||
|
||
When Reject selected:
|
||
|
||
**Return for Rework**
|
||
|
||
Avoid generic “Submit Decision.”
|
||
|
||
---
|
||
|
||
# 16. CLINICAL APPROVAL
|
||
|
||
## Objective
|
||
|
||
Provide clinical oversight only where policy requires it.
|
||
|
||
This screen should feel meaningfully different from ordinary verification.
|
||
|
||
---
|
||
|
||
## Top metrics
|
||
|
||
Keep limited.
|
||
|
||
Useful:
|
||
|
||
Awaiting Approval
|
||
|
||
Overdue
|
||
|
||
Approved Today
|
||
|
||
Average Review Time
|
||
|
||
Avoid vanity metrics.
|
||
|
||
---
|
||
|
||
# Layout
|
||
|
||
Queue
|
||
|
||
Source
|
||
|
||
Verified Draft
|
||
|
||
Clinical Risk / Summary
|
||
|
||
---
|
||
|
||
## Clinical summary sidebar
|
||
|
||
Show:
|
||
|
||
Patient
|
||
|
||
Encounter
|
||
|
||
High-stakes values
|
||
|
||
Reason approval is required
|
||
|
||
Examples:
|
||
|
||
Critical observation
|
||
|
||
Medication
|
||
|
||
Allergy
|
||
|
||
Clinical rule
|
||
|
||
High-risk document type
|
||
|
||
---
|
||
|
||
## Clinical flags
|
||
|
||
Use red carefully.
|
||
|
||
Example:
|
||
|
||
Temperature 38.2°C
|
||
|
||
Antibiotic recorded
|
||
|
||
Critical lab
|
||
|
||
These are **clinical signals**, unlike workflow validation errors.
|
||
|
||
---
|
||
|
||
## Retroactive Alerts
|
||
|
||
If supported:
|
||
|
||
Toggle:
|
||
|
||
**Run alert evaluation after promotion**
|
||
|
||
Supporting copy:
|
||
|
||
May generate alerts for clinical criteria represented in historical records.
|
||
|
||
It should not sound like alerts occurred contemporaneously.
|
||
|
||
---
|
||
|
||
## Approval actions
|
||
|
||
Approve
|
||
|
||
Reject
|
||
|
||
Approval confirmation should clearly state:
|
||
|
||
> Approval will promote the verified records into live clinical tables.
|
||
|
||
Primary:
|
||
|
||
**Approve & Promote**
|
||
|
||
Destructive:
|
||
|
||
**Reject Batch**
|
||
|
||
Rejection requires reason.
|
||
|
||
---
|
||
|
||
## Promotion result
|
||
|
||
After successful action display:
|
||
|
||
Patient records promoted
|
||
|
||
Encounter promoted
|
||
|
||
Observations promoted
|
||
|
||
Alerts generated: X
|
||
|
||
Audit event recorded
|
||
|
||
---
|
||
|
||
# 17. LIVE CAPTURE
|
||
|
||
## Objective
|
||
|
||
Provide a much lighter bedside workflow than backfill entry.
|
||
|
||
This should **not** look like the full Data Entry screen.
|
||
|
||
---
|
||
|
||
# Layout
|
||
|
||
Top:
|
||
|
||
Patient / encounter selection
|
||
|
||
Main:
|
||
|
||
Observation table
|
||
|
||
Bottom:
|
||
|
||
Attestation + authentication
|
||
|
||
Right:
|
||
|
||
Submission outcome / alert results
|
||
|
||
---
|
||
|
||
# Patient / Encounter
|
||
|
||
Choice:
|
||
|
||
New encounter
|
||
|
||
Existing encounter
|
||
|
||
Patient search:
|
||
|
||
MRN
|
||
Name
|
||
|
||
Once selected, display a compact patient banner.
|
||
|
||
---
|
||
|
||
# Observation table
|
||
|
||
Columns:
|
||
|
||
Time
|
||
|
||
Type
|
||
|
||
Value
|
||
|
||
Unit
|
||
|
||
Notes
|
||
|
||
Source
|
||
|
||
Actions
|
||
|
||
Use keyboard-friendly row creation.
|
||
|
||
Primary inline action:
|
||
|
||
**+ Add Observation**
|
||
|
||
---
|
||
|
||
# Attestation
|
||
|
||
Required:
|
||
|
||
> I attest that the information entered above accurately reflects the observations captured at the point of care.
|
||
|
||
Capture:
|
||
|
||
Clinician
|
||
|
||
Role
|
||
|
||
Location
|
||
|
||
Timestamp
|
||
|
||
---
|
||
|
||
# Password confirmation
|
||
|
||
Keep visually separate from normal data input.
|
||
|
||
Purpose:
|
||
|
||
Explicit clinical attestation.
|
||
|
||
---
|
||
|
||
# Submission
|
||
|
||
Primary:
|
||
|
||
**Submit Encounter**
|
||
|
||
After success:
|
||
|
||
Do not simply return to an empty page.
|
||
|
||
Show outcome panel.
|
||
|
||
---
|
||
|
||
# Critical alerts
|
||
|
||
If downstream scoring generates alerts, display them immediately.
|
||
|
||
Examples:
|
||
|
||
MEWS score elevated
|
||
|
||
Fever
|
||
|
||
NEWS2 threshold reached
|
||
|
||
Use high-visibility clinical alert presentation.
|
||
|
||
---
|
||
|
||
# 18. PATIENT HISTORY
|
||
|
||
## Objective
|
||
|
||
Explain the complete lineage of structured clinical information.
|
||
|
||
---
|
||
|
||
# Search
|
||
|
||
MRN
|
||
|
||
Patient name
|
||
|
||
Date filters
|
||
|
||
---
|
||
|
||
# Patient summary
|
||
|
||
Compact horizontal panel.
|
||
|
||
MRN
|
||
|
||
Name
|
||
|
||
DOB
|
||
|
||
Sex
|
||
|
||
Status
|
||
|
||
Record count
|
||
|
||
Active versions
|
||
|
||
Superseded versions
|
||
|
||
---
|
||
|
||
# Timeline
|
||
|
||
Recommended event types:
|
||
|
||
Uploaded
|
||
|
||
Entered
|
||
|
||
Verified
|
||
|
||
Rejected
|
||
|
||
Approved
|
||
|
||
Promoted
|
||
|
||
Corrected
|
||
|
||
Superseded
|
||
|
||
Use consistent icons.
|
||
|
||
---
|
||
|
||
# Timeline styling
|
||
|
||
Vertical or chronological table hybrid.
|
||
|
||
Timestamp on left.
|
||
|
||
Event in middle.
|
||
|
||
Actor / facility on right.
|
||
|
||
Status tag.
|
||
|
||
Expandable details.
|
||
|
||
---
|
||
|
||
# Corrections
|
||
|
||
Corrections must clearly show:
|
||
|
||
Original value
|
||
|
||
New value
|
||
|
||
Reason
|
||
|
||
Corrected by
|
||
|
||
Time
|
||
|
||
Superseded version
|
||
|
||
Example:
|
||
|
||
Hemoglobin
|
||
|
||
13.2 g/dL
|
||
→
|
||
13.6 g/dL
|
||
|
||
Never visually imply the old record disappeared.
|
||
|
||
---
|
||
|
||
# Audit detail panel
|
||
|
||
Selecting an event opens a right panel containing:
|
||
|
||
Event
|
||
|
||
Actor
|
||
|
||
Role
|
||
|
||
Timestamp
|
||
|
||
Batch
|
||
|
||
Reason
|
||
|
||
Related version
|
||
|
||
Audit events
|
||
|
||
---
|
||
|
||
# 19. SUPERVISOR DASHBOARD
|
||
|
||
## Objective
|
||
|
||
Help supervisors identify:
|
||
|
||
* queue buildup
|
||
* aging work
|
||
* quality problems
|
||
* staffing imbalance
|
||
* bottlenecks
|
||
|
||
It is an operational dashboard, not an executive BI product.
|
||
|
||
---
|
||
|
||
# Metric row
|
||
|
||
Total in queues
|
||
|
||
Intake
|
||
|
||
Data Entry
|
||
|
||
Verification
|
||
|
||
Approval
|
||
|
||
On Hold
|
||
|
||
---
|
||
|
||
# Priority information
|
||
|
||
### Queue age
|
||
|
||
Highlight oldest age more strongly than average.
|
||
|
||
Example:
|
||
|
||
Verification
|
||
**18h 32m**
|
||
|
||
---
|
||
|
||
# Operational analytics
|
||
|
||
Useful charts:
|
||
|
||
Queue aging
|
||
|
||
Rejection trend
|
||
|
||
Throughput
|
||
|
||
Cycle time
|
||
|
||
Stage distribution
|
||
|
||
---
|
||
|
||
# Bottleneck table
|
||
|
||
Columns:
|
||
|
||
Queue
|
||
|
||
Batch
|
||
|
||
Problem
|
||
|
||
Age
|
||
|
||
Priority
|
||
|
||
Assigned to
|
||
|
||
Records
|
||
|
||
Action
|
||
|
||
This may be the most useful element on the page.
|
||
|
||
---
|
||
|
||
# Team workload
|
||
|
||
Per-user:
|
||
|
||
In progress
|
||
|
||
Completed today
|
||
|
||
SLA performance
|
||
|
||
Open assignments
|
||
|
||
Avoid using simplistic leaderboards.
|
||
|
||
Healthcare operations should not encourage employees to optimize speed at the expense of accuracy.
|
||
|
||
---
|
||
|
||
# Refresh
|
||
|
||
Auto-refresh:
|
||
|
||
30 sec / 1 min / 5 min
|
||
|
||
Manual:
|
||
|
||
Refresh Now
|
||
|
||
Never refresh the page in a way that destroys the user's context.
|
||
|
||
---
|
||
|
||
# 20. FHIR EXPLORER
|
||
|
||
## Objective
|
||
|
||
Provide administrators and integration staff a safe, read-only way to inspect exposed FHIR R4 resources.
|
||
|
||
It should feel somewhat more technical than the rest of the application.
|
||
|
||
---
|
||
|
||
# Resource search
|
||
|
||
Resource type:
|
||
|
||
Patient
|
||
|
||
Encounter
|
||
|
||
Observation
|
||
|
||
Then dynamic parameters based on the selected resource.
|
||
|
||
---
|
||
|
||
# Workspace
|
||
|
||
Three columns:
|
||
|
||
### Left
|
||
|
||
Search results
|
||
|
||
### Center
|
||
|
||
FHIR resource
|
||
|
||
### Right
|
||
|
||
Human-readable summary
|
||
|
||
---
|
||
|
||
# Tabs
|
||
|
||
Resource Details
|
||
|
||
Raw JSON
|
||
|
||
Tree View
|
||
|
||
`$everything`
|
||
|
||
CapabilityStatement
|
||
|
||
---
|
||
|
||
# Raw JSON
|
||
|
||
Font:
|
||
|
||
JetBrains Mono
|
||
|
||
13 px
|
||
|
||
Line height:
|
||
|
||
20 px
|
||
|
||
Basic syntax highlighting.
|
||
|
||
Do not over-style like an IDE.
|
||
|
||
---
|
||
|
||
# Read-only indication
|
||
|
||
Always visible:
|
||
|
||
🔒 Read Only
|
||
|
||
This is important enough that the status should remain visible when scrolling.
|
||
|
||
---
|
||
|
||
# CapabilityStatement
|
||
|
||
Present both:
|
||
|
||
Human-readable capability summary
|
||
|
||
Raw resource
|
||
|
||
---
|
||
|
||
# 21. Navigation by Role
|
||
|
||
Navigation should be permission-based.
|
||
|
||
## Intake Operator
|
||
|
||
Dashboard
|
||
|
||
Intake
|
||
|
||
Cover Sheets
|
||
|
||
---
|
||
|
||
## Data Entry Operator
|
||
|
||
Dashboard
|
||
|
||
Data Entry
|
||
|
||
Patient History if authorized
|
||
|
||
---
|
||
|
||
## Verifier
|
||
|
||
Dashboard
|
||
|
||
Verification
|
||
|
||
Patient History
|
||
|
||
---
|
||
|
||
## Clinical Approver
|
||
|
||
Dashboard
|
||
|
||
Clinical Approval
|
||
|
||
Patient History
|
||
|
||
---
|
||
|
||
## Clinician
|
||
|
||
Dashboard
|
||
|
||
Live Capture
|
||
|
||
Patient History
|
||
|
||
---
|
||
|
||
## Supervisor
|
||
|
||
Dashboard
|
||
|
||
Supervisor Dashboard
|
||
|
||
Queues
|
||
|
||
Workload
|
||
|
||
Reports
|
||
|
||
History
|
||
|
||
---
|
||
|
||
## Administrator
|
||
|
||
Everything appropriate plus:
|
||
|
||
Users
|
||
|
||
Master Data
|
||
|
||
Configuration
|
||
|
||
Audit Logs
|
||
|
||
FHIR Explorer
|
||
|
||
---
|
||
|
||
# 22. Page Density
|
||
|
||
VigilCare is primarily desktop workstation software.
|
||
|
||
Recommended minimum:
|
||
|
||
1280 × 800
|
||
|
||
Optimized:
|
||
|
||
1440 × 900 and above
|
||
|
||
Entry and Verification particularly benefit from:
|
||
|
||
1920 × 1080
|
||
|
||
---
|
||
|
||
## Density modes
|
||
|
||
Potential future feature:
|
||
|
||
Comfortable
|
||
|
||
Compact
|
||
|
||
Operators working through hundreds of records may prefer Compact.
|
||
|
||
---
|
||
|
||
# 23. Forms
|
||
|
||
Input height:
|
||
|
||
36–40 px
|
||
|
||
Do not use oversized 48–56 px consumer inputs.
|
||
|
||
Labels stay above the fields.
|
||
|
||
Long forms should use grouped sections rather than floating forms inside unrelated cards.
|
||
|
||
---
|
||
|
||
# 24. Tables
|
||
|
||
Header:
|
||
|
||
44 px
|
||
|
||
Rows:
|
||
|
||
48–56 px
|
||
|
||
Selected row:
|
||
|
||
Soft blue.
|
||
|
||
Hover:
|
||
|
||
Very subtle gray/blue.
|
||
|
||
Numeric values should align consistently.
|
||
|
||
Tables should support:
|
||
|
||
Sorting
|
||
|
||
Filtering
|
||
|
||
Pagination
|
||
|
||
Keyboard row navigation where appropriate
|
||
|
||
---
|
||
|
||
# 25. Icons
|
||
|
||
Use a single icon library.
|
||
|
||
Recommended:
|
||
|
||
Lucide
|
||
|
||
or
|
||
|
||
Phosphor
|
||
|
||
Outline weight around:
|
||
|
||
1.5–2 px
|
||
|
||
Avoid mixing:
|
||
|
||
Filled icons
|
||
|
||
Emoji
|
||
|
||
Multiple icon families
|
||
|
||
---
|
||
|
||
# 26. Empty States
|
||
|
||
Empty states should be operational.
|
||
|
||
Bad:
|
||
|
||
> Nothing here yet!
|
||
|
||
Better:
|
||
|
||
> No batches are waiting for verification.
|
||
|
||
> New batches appear here after data entry is submitted.
|
||
|
||
CTA where relevant:
|
||
|
||
**Return to Dashboard**
|
||
|
||
---
|
||
|
||
# 27. Loading
|
||
|
||
Prefer:
|
||
|
||
Skeleton rows
|
||
|
||
Inline loaders
|
||
|
||
Specific component loading
|
||
|
||
Avoid blocking the entire application with a spinner.
|
||
|
||
---
|
||
|
||
# 28. Error States
|
||
|
||
Errors must explain:
|
||
|
||
What happened
|
||
|
||
What was preserved
|
||
|
||
What the user should do
|
||
|
||
Example:
|
||
|
||
**Upload failed**
|
||
|
||
`records_042.pdf` could not be stored.
|
||
|
||
Your batch settings were preserved.
|
||
|
||
[Retry Upload]
|
||
|
||
---
|
||
|
||
# 29. Confirmation Dialogs
|
||
|
||
Only use confirmation for meaningful actions.
|
||
|
||
Examples:
|
||
|
||
Approve & Promote
|
||
|
||
Reject Batch
|
||
|
||
Supersede Record
|
||
|
||
Delete unsubmitted upload
|
||
|
||
Do not confirm harmless navigation.
|
||
|
||
---
|
||
|
||
# 30. Audit Visibility
|
||
|
||
Wherever a governance transition occurs, show:
|
||
|
||
Actor
|
||
|
||
Role
|
||
|
||
Timestamp
|
||
|
||
Previous state
|
||
|
||
New state
|
||
|
||
Reason if applicable
|
||
|
||
Transitions should feel traceable throughout the product.
|
||
|
||
---
|
||
|
||
# 31. Accessibility
|
||
|
||
Target:
|
||
|
||
WCAG 2.1 AA
|
||
|
||
Requirements:
|
||
|
||
Minimum text contrast 4.5:1
|
||
|
||
Visible keyboard focus
|
||
|
||
Semantic labels
|
||
|
||
ARIA descriptions
|
||
|
||
Do not communicate state by color alone
|
||
|
||
Minimum interactive target around 36–40 px
|
||
|
||
Tables navigable by keyboard
|
||
|
||
Document viewer controls accessible
|
||
|
||
---
|
||
|
||
# 32. Responsive Behavior
|
||
|
||
VigilCare is primarily desktop software.
|
||
|
||
Do not force complex Entry and Verification workflows into a phone layout.
|
||
|
||
Suggested support:
|
||
|
||
### Desktop
|
||
|
||
Full functionality
|
||
|
||
### Tablet
|
||
|
||
Supervisory, history, approval and live capture supported
|
||
|
||
### Mobile
|
||
|
||
Primarily:
|
||
|
||
Patient history
|
||
|
||
Notifications
|
||
|
||
Simple live capture
|
||
|
||
Approval review where appropriate
|
||
|
||
Avoid full backfill transcription on mobile.
|
||
|
||
---
|
||
|
||
# 33. Motion
|
||
|
||
Keep extremely subtle.
|
||
|
||
Allowed:
|
||
|
||
150–200 ms hover
|
||
|
||
Panel expand/collapse
|
||
|
||
Toast appearance
|
||
|
||
Modal transition
|
||
|
||
Avoid:
|
||
|
||
Bouncing elements
|
||
|
||
Animated gradients
|
||
|
||
Large transitions
|
||
|
||
Dashboard count animations
|
||
|
||
Healthcare software should feel stable.
|
||
|
||
---
|
||
|
||
# 34. Most Important Screen Hierarchy
|
||
|
||
The visual hierarchy of the application should reflect workflow risk.
|
||
|
||
### Level 1 — Source evidence
|
||
|
||
Original scanned document
|
||
|
||
### Level 2 — Entered structured information
|
||
|
||
Draft data
|
||
|
||
### Level 3 — Verification status
|
||
|
||
Human verification results
|
||
|
||
### Level 4 — Clinical approval
|
||
|
||
Clinical decision when required
|
||
|
||
### Level 5 — Promotion
|
||
|
||
Live clinical record
|
||
|
||
This hierarchy should remain recognizable across every workflow.
|
||
|
||
---
|
||
|
||
# 35. Recommended Final Sidebar
|
||
|
||
For consistency, I would use these exact labels:
|
||
|
||
**WORKSPACE**
|
||
|
||
Dashboard
|
||
Intake
|
||
Cover Sheets
|
||
Data Entry
|
||
Verification
|
||
Clinical Approval
|
||
Live Capture
|
||
Patient History
|
||
|
||
**SUPERVISION**
|
||
|
||
Supervisor Dashboard
|
||
Queues
|
||
Workload
|
||
Reports
|
||
|
||
**ADMINISTRATION**
|
||
|
||
Users
|
||
Master Data
|
||
FHIR Explorer
|
||
Configuration
|
||
Audit Logs
|
||
|
||
Navigation is filtered by role and permission.
|
||
|
||
---
|
||
|
||
# 36. Corrections to the Generated Concepts
|
||
|
||
Several adjustments should be made before treating the screenshots as implementation references.
|
||
|
||
### Login
|
||
|
||
Remove the role selector.
|
||
|
||
Roles come from authentication.
|
||
|
||
---
|
||
|
||
### Data Entry naming
|
||
|
||
Use **Data Entry** consistently.
|
||
|
||
Do not alternate between “Entry” and “Data Entry.”
|
||
|
||
---
|
||
|
||
### Approval naming
|
||
|
||
Use **Clinical Approval** consistently.
|
||
|
||
Do not simultaneously show:
|
||
|
||
Clinical Approval
|
||
and
|
||
Approvals
|
||
|
||
as separate navigation items unless they actually represent different concepts.
|
||
|
||
---
|
||
|
||
### Dashboard infrastructure metrics
|
||
|
||
Move detailed:
|
||
|
||
PostgreSQL
|
||
|
||
Redis
|
||
|
||
MinIO
|
||
|
||
FHIR API
|
||
|
||
service health into Administration.
|
||
|
||
The normal operator dashboard should prioritize work.
|
||
|
||
---
|
||
|
||
### OCR
|
||
|
||
Do not label extracted values as inherently correct.
|
||
|
||
OCR confidence represents machine confidence, not clinical correctness.
|
||
|
||
---
|
||
|
||
### Verification
|
||
|
||
The source scan and entered value should dominate the page.
|
||
|
||
Analytics are secondary.
|
||
|
||
---
|
||
|
||
### Patient History
|
||
|
||
Promotion should normally identify the user who performed the approval/promotion action according to actual backend workflow. Do not assume the data-entry operator promoted the record.
|
||
|
||
---
|
||
|
||
### Clinical Approval
|
||
|
||
Use the strongest semantic color only for clinical risks and irreversible actions.
|
||
|
||
Routine workflow warnings should use amber.
|
||
|
||
---
|
||
|
||
# 37. Overall Visual Personality
|
||
|
||
VigilCare Records should sit visually somewhere between:
|
||
|
||
A modern hospital information system
|
||
|
||
A high-quality enterprise data workstation
|
||
|
||
A regulated document-processing platform
|
||
|
||
It should **not** look like:
|
||
|
||
A generic AI dashboard
|
||
|
||
A marketing SaaS template
|
||
|
||
A consumer health app
|
||
|
||
A traditional gray hospital EMR from 2008
|
||
|
||
The resulting identity should be:
|
||
|
||
**calm, structured, trustworthy, fast, and visibly governed.**
|