Harmony Healthcare Demo Application

Create a polished example healthcare application using the Harmony Design System. The app should feel like a realistic Optum-style internal product and should demonstrate how Harmony components, navigation patterns, forms, and supporting UI elements work together in a coherent workflow.

Use the current Harmony assets in OTC AWESOME LLM instead of inventing patterns from scratch. Prefer the exact demo skill and templates when the goal is to recreate the current Harmony healthcare demo experience.

Required Harmony Assets

Use these repo assets as the primary source of truth:

• Demo app skill: ../skills/harmony-create-simple-app/SKILL.md
• Setup guidance: ../instructions/harmony.instructions.md
• Harmony overview: ../instructions/harmony-overview.instructions.md
• Foundations guidance: ../instructions/harmony-foundation.instructions.md
• Component guidance: ../instructions/harmony-components.instructions.md
• App shell pattern skill: ../skills/harmony-app-layout-pattern/SKILL.md
• Form pattern skill: ../skills/harmony-form-pattern/SKILL.md
• Modal pattern skill: ../skills/harmony-modal-pattern/SKILL.md

If package discovery is needed, also use:

• Harmony SDK discovery skill: ../skills/harmony-sdk-discovery/SKILL.md
• Harmony version management skill: ../skills/harmony-version-management/SKILL.md
• Node/npm install skill: ../skills/node-npm-install/SKILL.md

Preferred Build Path

When the request is to build or recreate this healthcare demo, use ../skills/harmony-create-simple-app/SKILL.md first.

That skill already contains:

• exact page templates
• the current app shell
• the current mocked healthcare data
• the CSS needed for viewport sizing and shell scrolling

Do not replace those templates with newly invented page structures unless the user explicitly asks for a redesign.

Bootstrap And Install

If the target folder does not already contain a working React app:

1. Create or initialize the app first so a valid package.json exists.
2. Install the base React toolchain before copying the demo templates.
3. Follow ../instructions/harmony.instructions.md to install Harmony packages correctly.
4. If Optum Artifactory access or npm behavior is blocking installation, use ../skills/node-npm-install/SKILL.md.

At minimum, the target app should end up with:

• a valid package.json
• React and the chosen app runtime/build tooling
• @uhg-harmony/foundations
• @uhg-harmony/react
• @uhg-harmony/icons-react
• styled-components@^5.3.11

Do not assume Harmony is already installed. Verify dependency setup before copying or running the templates.

Goal

Build an example healthcare app that clearly showcases these three concepts:

1. Eligibility
2. Claims
3. Remittance

The application should demonstrate how a user can navigate between these domains and complete realistic UI tasks using Harmony patterns.

Experience To Build

Create a small React app with a professional Harmony shell and mocked data. The app should not depend on a real backend. Use realistic healthcare wording, but keep the implementation self-contained and demo-friendly.

Recommended Information Architecture

• Dashboard
  • Summary cards for eligibility checks, pending claims, remittance volume, and recent activity
• Eligibility
  • Search or intake workflow for member eligibility verification
  • Include demographic and coverage-oriented form fields
• Claims
  • Claims queue, claim search/filter, and claim detail or claim-entry workflow
  • Include a DetailPane experience for inspecting a selected claim from the queue
  • Show claim status, amounts, dates, and member/provider information
• Remittance
  • Remittance summary view with payment or adjustment details
  • Include a DetailPane experience for inspecting remittance line details, adjustments, or denial rationale
  • Show adjudication outcome concepts such as paid, denied, adjusted, or pending follow-up

Navigation Expectations

Use the current Harmony demo shell pattern:

• Harmony Masthead
• official Harmony Sidebar
• a bounded main content area with independent scrolling

The final demo should have clean navigation across Dashboard, Eligibility, Claims, and Remittance. Router-based navigation is optional; parity with the current demo shell is preferred over adding routing complexity.

UI Expectations

Use Harmony components and patterns to demonstrate a credible design system implementation. Include a meaningful mix of:

• Layout shell components and navigation primitives
• Forms and form controls
• Panels, cards, headings, labels, helper text, badges, and buttons
• Search and filtering interactions
• ReadOnlyFieldValueList for read-only detail summaries where appropriate
• InlineNotification for success, denial, or adjustment explanations where appropriate
• At least one modal interaction for a focused workflow

Good modal examples include:

• Confirm claim submission
• View denial rationale
• Display remittance adjustment details

Use DetailPane for side-panel record review workflows where the user should stay in context on the main page while drilling into claim or remittance detail.

Form Expectations

Use the Harmony form skill templates and the harmony-create-simple-app templates as the base for realistic workflows. Adapt carefully only where the target app needs different labels or data.

Examples:

• Eligibility page
  • Member ID
  • Date of birth
  • Coverage type
  • Service date
  • Plan / payer
• Claims page
  • Claim ID or member search
  • Date range filters
  • Claim type
  • Status
• Remittance page
  • Payment date filters
  • Payer
  • Remittance status
  • Adjustment category

Implementation Guidance

• Start from current Harmony instructions and skills in this repo, not outdated examples.
• Prefer the exact templates from harmony-create-simple-app when parity with the current demo is the goal.
• If the target app does not exist yet, bootstrap a working React project and dependency set first so the copied templates have a valid package.json and runtime.
• Use mocked domain data and realistic labels so the app demonstrates business concepts clearly.
• Keep the implementation consistent with Harmony layout, spacing, typography, and component guidance.
• Prefer controlled React state for form interactions.
• Keep the app accessible and enterprise-oriented.
• Avoid unrelated third-party UI frameworks.
• If dependency installation is blocked or version resolution fails in the Optum environment, use the node-npm-install skill alongside Harmony setup/version guidance.

Harmony Gotchas

• Notification is not a valid export from @uhg-harmony/react. Use InlineNotification instead.
• The known-good demo dependency baseline includes @uhg-harmony/foundations; include it when recreating the current demo stack.
• Pin styled-components to ^5.3.11 for Harmony 1.5.0 compatibility. Installing styled-components v6 can cause runtime failures such as n.h3 is not a function.
• If package exports are unclear and Node cannot load Harmony directly, inspect node_modules/.vite/deps/@uhg-harmony_react.js to confirm the actual pre-bundled exports in the running app.
• Heading and Text are valid Harmony exports and can be used in the demo where appropriate.
• Do not enable the Harmony global grid casually. Its .row class can collide with internal Harmony component markup such as Label and ReadOnlyFieldValueList.

Deliverables

Create or update the app so that it includes:

• A Harmony-wrapped React application
• Navigation across Dashboard, Eligibility, Claims, and Remittance
• At least one substantial form experience
• At least one search/filter experience
• At least one modal-based workflow
• DetailPane workflows in both the Claims and Remittance experiences
• Harmony ReadOnlyFieldValueList usage for read-only detail summaries in claims and remittance flows
• Harmony InlineNotification usage for eligibility success and denial or adjustment messaging where appropriate
• Mocked healthcare data that makes the demo understandable

Acceptance Criteria

The output should satisfy all of the following:

• The app clearly showcases eligibility, claims, and remittance concepts
• Navigation uses the current Harmony masthead/sidebar app shell pattern
• Forms use current Harmony form patterns and components
• Claims and Remittance both demonstrate DetailPane usage as part of the Harmony workflow experience
• Read-only summary content uses current Harmony-friendly patterns instead of custom label/value blocks where practical
• The design reads as a coherent healthcare product demo rather than isolated component examples
• The implementation references and follows the current Harmony skills and instructions available in OTC AWESOME LLM

Notes For The Agent

• If the goal is parity with the existing demo, start with the harmony-create-simple-app skill and copy its templates before making targeted changes.
• If Harmony dependencies are not installed, use the setup guidance in harmony.instructions.md.
• If there are version or package discovery issues, use the Harmony SDK discovery and version management skills.
• If npm install behavior, package curation, or blocked package versions become an issue, use the node-npm-install skill.
• If the user wants a fast, polished demo, optimize for clarity and cohesion over feature count.
• At the end of the implementation, double-check the final experience by launching the app and using openBrowserPage in the integrated browser to visually review navigation, forms, DetailPane workflows, modals, and overall page composition.