Workflows & Events Explained
The Medecision Platform is architected as a dynamic, event-driven system, where data updates, user actions, and system logic all act as events that trigger workflows across care management, utilization management, clinical intelligence, digital engagement, and appeals & grievances. This section provides a comprehensive technical explanation of how workflows are initiated, managed, and resolved within the platform.
What is a Workflow in Medecision?
A workflow in Medecision refers to the automated or manual sequence of actions that respond to a defined event, ultimately completing a specific process tied to a member.
Each workflow can span multiple modules and consists of:
An initiating event (user action, rule evaluation, data feed)
Evaluation of logic (via Rules Builder or system triggers)
Generation of system actions (task, request, letter, update, outreach)
Tracking and audit of all actions and decisions
Workflow Categories
Transactional workflows: e.g., submitting a UM request, reviewing an appeal
Clinical workflows: e.g., enrolling a member in a transitional care program after hospital discharge
Engagement workflows: e.g., sending outreach to members overdue for screenings
Administrative workflows: e.g., triggering TAT escalation or letter generation
Workflow Initiators (Event Types)
The platform supports both synchronous (real-time) and asynchronous (batch or delayed) events. These events initiate workflows when they meet predefined rule conditions.
Common Event Sources:
Event Source | Description |
Inbound Data Feeds | ADT alerts, claims, labs, eligibility, SDOH, assessments |
User Actions | Completing a task, submitting an intake form, resolving a request |
System Timers | TAT deadlines, follow-up windows, scheduled evaluations |
API Calls | External systems triggering workflow via FHIR or REST (e.g., provider EMR sends prior auth request) |
Builder Logic | Rules evaluated against event payloads triggering downstream actions |
Workflow Execution Logic
Once an event is ingested, workflow execution follows this lifecycle:
Event Capture
The platform logs the source and payload of the event (e.g., ADT message with admit date, diagnosis, location)
Rule Evaluation
Rules Builder evaluates whether the event matches any configured triggers (e.g., if Dx = CHF AND Admit Type = IP)
Workflow Creation
If matched, workflows are executed: programs created, tasks assigned, correspondence triggered, or intake initiated
Tracking & Logging
Each workflow instance is logged at the member level, and each system action is tied back to the original triggering event
System Actions Triggered by Workflows
Action Type | Examples |
Program Creation | Auto-enroll into Care Transition, Asthma Management, or LTSS program |
Task Assignment | Assign follow-up call to care manager, flag for peer review |
Assessment Launch | Trigger PHQ-9 or functional screen based on age/claims |
Outreach Campaigns | Send nudge via SMS or email to complete health screening |
Request Updates | Change status, escalate for review, reassign queue |
Correspondence | Auto-generate member letters or denial notices |
Rules Builder in Workflow Design
Rules Builder is a visual configuration tool used to define:
Triggers: what event types should start the workflow
Conditions: which filters apply (e.g., age, Dx, program status)
Actions: what to execute (task, program, request update, correspondence)
Example Rule Logic:
IF Member Age > 65 AND Event = ADT Admit AND Dx = PneumoniaTHEN Create Transitional Care Program AND Assign CM Outreach Task
Each rule is version-controlled and testable before deployment. Rules can call other rules, enabling complex decision pathways.
Workflow Chaining and Dependencies
Workflows can be chained together to support multi-step logic.
Example:
ADT alert triggers Program A
Completing Task A1 in Program A triggers a referral to Program B
Completing an assessment in Program B triggers outreach campaign to caregiver
These chains are logged and auditable to ensure transparency and reduce duplicate interventions.
Real-Time vs Batch Workflow Timing
Timing | Description | Use Case Examples |
Real-Time | Triggered immediately upon event ingestion | Auto-create program on ADT Admit |
Batch | Evaluated on schedule (e.g., hourly, nightly) | Re-check member eligibility against population criteria |
Delayed | Queued by system logic or user scheduling | Send reminder 7 days after program enrollment if task not started |
Timeline Integration
All workflow actions are recorded in the Member Timeline:
View includes tasks, requests, assessments, programs, letters, and engagement
Filters allow sorting by event type, source, or priority
Clicking an entry opens full audit and decision trace
Workflow Design Best Practices
Use population builder to define eligible groups
Avoid unnecessary branching in assessment logic — use rules for workflow branching
Leverage version control in builders to avoid overwriting in-use workflows
Use labels and categories to organize tasks and requests for staff
Consider hybrid event strategies: real-time for admits, batch for screenings
External System Integration
Workflows can be triggered from external systems via:
FHIR API: Provider EMRs submit requests or assessments
REST API: CRM or analytics platforms send event data
Webhooks: Medecision can push data out as workflows progress (e.g., notify provider of auth decision)
All workflow results and data updates can be returned to external systems for bidirectional integration.
This document serves as the authoritative guide for understanding how workflows operate across the Medecision platform. For technical implementation guidance, refer to the API, Builders, or Module-specific documentation.