25 KiB
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:
- Source evidence
- Draft/extracted data
- Verified data
- Approved clinical data
- 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 draftAlt + N— next documentAlt + P— previous documentAlt + F— flag/rejectAlt + V— submit for verification+/-— zoomR— 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.