Overview
Engineering overview of the Integration Dashboard — event-driven integration execution, observability, and retry system for all third-party data exchanges.
Integration Dashboard
The Integration Dashboard is the central observability layer for all data exchanges between LiveHealth/Crelio and external third-party systems. It does not execute integration logic itself — it records what happened, when it happened, and whether it succeeded.
The actual execution pipeline is event-driven: a core business action (e.g., bill generation) triggers a domain function, which evaluates the labIntegration config, constructs a payload, queues an async Fusion task, and dispatches it to a third-party endpoint. The dashboard's role is to produce a structured, queryable log of every such event — both inbound API calls (captured via decorator) and outbound webhook dispatches (captured via decorator on the internal handler).
IntegrationDirectoryLogger and WebhookIntegrationDirectoryLogger are decorators — passive logging wrappers, not orchestrators. They do not route requests, queue tasks, or make integration decisions. They only observe the function they wrap and persist a structured record of what occurred.
Core Entities
Event Definitions
actionCategory— the broader business category (e.g., Billing, Sample Lifecycle).actionCategoryList— the concrete event (e.g., Bill Generation, Report Signed, Sample Receive, New Patient Registered).
Runtime Configuration
developerAuthentication— the integration root record. Stores the auth key, developer details, and feature flags.labIntegration— the action-level runtime config. Stores the endpoint URL, request type, headers, and flags likeis_batchandis_auto_retry.
Observability Models
IntegrationDirectory— the structured log document for every API call or webhook execution. Stores request/response data, status, execution metadata, and business references (lab, bill, patient, LRR, report).IntegrationRetryLog— one document per retry attempt, linked back toIntegrationDirectoryviaintegration_directory_id.
Business Flows Covered
Integrations are organized around business-event families, not vendor-specific paths:
| Category | Example Events |
|---|---|
| Billing & Orders | Bill generation, cancellation, settlement, outsource billing |
| Sample Lifecycle | Sample receive, redraw, dismiss, uncollect, collect |
| Reporting & Results | Report signed, report submitted, fax delivery, patient portal |
| Registration | Patient profile create, demographic update |
| Appointments & Home Collection | Booking, confirmation, dismissal, HC scheduling |
| Mirth / HL7 Handoff | HL7 data push via TCP socket through Mirth |
Sections
Workflow Guide
Step-by-step execution sequences for configuration, outbound triggers, bulk dispatch, inbound capture, retries, and Mirth handoff
Frontend
Component hierarchy, state management, Pusher real-time sync, and the retry modal flows
Backend
Trigger functions, logging decorators, Fusion queueing, Mirth handoff, and retry mechanics
Design Decisions
Why Action IDs, why common functions, why DocumentDB, why decorator-based logging, why Fusion workers