Ottehr EHR

When sending a fax, the system generates a single merged PDF called a fax packet. You cannot select individual documents; the entire visit package is sent. The merge order is fixed by FAX_DOCUMENT_ORDER and follows this sequence:

1. Cover sheet
2. Visit/Progress Note (Always included)
3. Discharge Summary (Included if a DocumentReference with ID discharge-summary exists)
4. Lab Results (Included if there is $\ge 1$ reviewed result with DocumentReference LOINC 11502-2 and docStatus === 'final')
5. Radiology Results (Included if $\ge 1$ result is found via searchRadiologyResultDocRefs over the encounter's ServiceRequests)
6. Patient Education (Included if $\ge 1$ document exists and no discharge summary is present in the packet)

Note: Prescriptions and Patient Instructions are treated as sections within the Visit/Progress Note and are not sent as standalone documents. Additionally, if a Discharge Summary is included, Patient Education documents are automatically dropped to prevent duplication.

Config-aware testing allows E2E tests to adapt to different application configurations (like feature flags or UI options) without hardcoding expectations. This is achieved by injecting configuration overrides into the browser context before navigation.

Implementation Pattern

1. Inject Config: Use injectTestConfig() to pass overrides via window[CONFIG_KEY] using Playwright's addInitScript().
2. Timing: You must call injectTestConfig() before calling page.goto().
3. Consumption: The application uses a Proxy object that checks the window for these test overrides at runtime. If no override is found, it falls back to the default application configuration.

Benefits

• Isolation: Each test can have its own unique configuration via addInitScript().
• Adaptability: Tests automatically adjust to changes in ottehr-config or instance-specific defaults.ts files.

import { CONFIG_INJECTION_KEYS } from 'utils';
import { injectTestConfig } from '../config/injectTestConfig';

// 1. Inject booking config overrides BEFORE navigation
await injectTestConfig(page, CONFIG_INJECTION_KEYS.BOOKING, bookingOverrides);

// 2. Navigate to the page
await page.goto('/home');

// The application's BOOKING_CONFIG proxy will now use the overrides

The Billing Report Refresh Framework uses a task/subscribe pipeline to compute, cache, and serve reports without overloading the HTTP layer.

Core Workflow:

1. HTTP Request: The get-billing-report zambda serves a cached snapshot and a refresh status. It never computes data itself.
2. Task Queuing: If a refresh is requested, the HTTP zambda queues an asynchronous FHIR Task.
3. Worker Execution: A subscription worker (sub-refresh-billing-report) picks up the Task, runs the report's compute() method, and streams progress back to the Task.
4. Caching: The worker writes the resulting payload and optional drilldown datasets as gzipped JSON objects to the billing-app Z3 bucket.
5. Frontend Consumption: The frontend polls the HTTP endpoint for status. When ready, it uses a short-lived presigned URL to download the payload directly from Z3, bypassing the HTTP zambda to ensure high performance for large datasets.

Key Invariants:

• The FHIR Task is the single source of truth for refresh state.
• The Z3 cache objects are the single source of truth for report data.

Ottehr uses a custom 'visit status' workflow layered over standard FHIR Appointment.status and Encounter.status. This custom status is displayed on the staff dashboard and is synchronized across Encounter.statusHistory and Appointment audit-log meta tags.

For walk-in urgent care, the lifecycle follows this sequence: arrived → ready → intake → ready for provider → provider → discharged → completed → (signed)

Key Behaviors:

• Target Status: In synthetic scenarios, you can set visit.targetStatus to any valid state (e.g., 'intake', 'provider'). The pipeline will truncate the workflow at that state. If the target is not 'completed', the visit remains unlocked (no APPOINTMENT_LOCKED tag).
• Clinical Phases: Clinical data entry (chart data, orders, etc.) occurs independently of the dashboard status. A chart can be fully populated even if the visit is in an early lifecycle stage (e.g., intake).

The project uses a structured approach to separate workflow testing, infrastructure, and UI abstractions.

EHR Application Structure

• apps/ehr/tests/e2e/specs/*.spec.ts: Primary test scenarios and user workflow validation.
• apps/ehr/tests/e2e/page/: Page Object Models (POMs) including abstract base classes and specific pages (e.g., in-person, telemed).
• apps/ehr/tests/e2e/e2e-utils/: Helper utilities like ResourceHandler for FHIR resource management.
• apps/ehr/tests/e2e/login/: Authentication establishment logic.
• apps/ehr/tests/e2e/seed-data/: Auto-generated test data (the resources/ directory is git-ignored).

Intake Application Structure

• apps/intake/tests/specs/: Primary test scenarios (e.g., in-person or telemed booking tests).
• apps/intake/tests/utils/: Test utilities.
• apps/intake/tests/login/: Authentication establishment.
• apps/intake/playwright/: Playwright configuration.
• apps/intake/playwright-report/: Test reports.