# 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.**
