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