Clinical Task Feature Design¶

THIS IS A DRAFT PROPOSAL - NOT YET APPROVED FOR PRODUCTION USE

Version 1.0 – July 23, 2025
Feature Status: Draft
FHIR Profile: PolarisCoreClinicalTask

Overview¶

The Clinical Task feature provides a comprehensive FHIR Task resource profile designed for clinical workflow management within EMR systems. This profile combines the foundational principles of the original Polaris Task design with enhanced MERT standard compatibility, creating a robust solution for healthcare workflow automation and clinical task management.

Key Capabilities¶

Clinical Workflow Management: Complete task lifecycle from creation to completion
Hot Potato Ownership: Ensures clear accountability with exactly one owner at all times
Conversation Threading: Integrated with PolarisCommunication for complete audit trails
AI Agent Integration: Supports AI agent ownership through PolarisDevice references
MERT Compatibility: 93% alignment with MERT standard Task requirements
Clinical Safety First: Required patient context and ownership for healthcare accountability

Context and Background¶

Clinical Problem Statement¶

Healthcare workflows involve complex coordination between multiple practitioners, systems, and processes. Traditional approaches often result in:

Lost Tasks: Work items falling through the cracks without clear ownership
Ambiguous Responsibility: Unclear who is responsible for next actions
Poor Audit Trails: Incomplete records of clinical decision-making
System Fragmentation: Tasks scattered across multiple disconnected systems
Manual Overhead: Excessive administrative burden on clinical staff

Solution Approach¶

The Clinical Task feature addresses these challenges through:

Unified Task Model: Single representation for all clinical work items
Explicit Ownership: Hot potato principle ensures clear responsibility
Complete Audit Trails: Every action timestamped and attributed
System Integration: FHIR-compliant for cross-system interoperability
AI-Ready Architecture: Native support for AI agent integration

Design Principles¶

The Clinical Task design is built on these foundational principles derived from the original Polaris Task specification:

Single Item Type: Only Tasks appear in clinical inboxes - no emails, messages, or notifications as separate entities
Unambiguous Ownership: Always exactly one person or system owns each task, never ambiguous or shared
Hot Potato Principle: The latest event determines the task's owner and state - responsibility is always crystal clear
Complete Audit Trail: Every state change, comment, and action is timestamped and attributed
Clinical Safety First: Task model provides clear audit trails and ownership accountability for patient safety

FHIR Profile Specification¶

Profile Identity¶

Profile: PolarisClinical Task
Parent: Task
Id: polaris-emr-task
Canonical: https://fhir.apps.health/StructureDefinition/polaris-emr-task

Core Requirements¶

Mandatory Fields (Clinical Safety)¶

These fields are required by the profile to ensure clinical safety and accountability:

Field	Cardinality	Rationale
`identifier`	1..* MS	Unique identification for tracking and audit
`status`	1..1 MS	Clear lifecycle state for workflow management
`intent`	1..1 MS	Fixed to "order" for clinical task clarity
`owner`	1..1 MS	Hot potato principle - exactly one responsible party
`for`	1..1 MS	Patient context required for clinical safety
`authoredOn`	1..1 MS	Creation timestamp for audit trail
`requester`	1..1 MS	Who initiated the task for accountability
`description`	1..1 MS	Clear task description prevents ambiguity

Enhanced Fields (MERT Compatibility)¶

Additional fields added for MERT standard alignment:

Field	Cardinality	Purpose
`code`	0..1 MS	Task type classification for workflow routing
`basedOn`	0..* MS	Authorization/request references
`groupIdentifier`	0..1 MS	Task batch grouping
`focus`	0..1 MS	What the task is about
`reasonCode`	0..1 MS	Coded rationale for task creation
`performerType`	0..* MS	Required performer type specification

State Machine¶

The profile supports this task lifecycle:

draft → requested/ready → in-progress → completed
  ↓                                        ↑
cancelled ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ←
  ↓
failed/error

States: - draft: Task being composed or prepared - requested/ready: Task requires attention (shown as "active" in UI) - in-progress: Task being actively worked on - completed: Task finished successfully with outcomes recorded - cancelled: Task deliberately abandoned but audit trail preserved - failed: Technical or process failure requiring intervention (shown as "error" in UI)

Hot Potato Ownership Model¶

The profile implements the hot potato principle through these mechanisms:

Owner Types¶

Individual Practitioners: Standard pattern for personal task assignment
Group Identifiers: Work-stream assignment (e.g., "NURSING_POOL") where any qualified member can claim
External System Pseudo-Users: External systems (e.g., "LAB:LifeLabs")
AI Agent Pseudo-Users: AI agents for automated processing with human oversight

Ownership Transfer Rules¶

Forwarding: Explicit transfer to another party with optional comment
Reply/Comment: Typically reassigns ownership back to previous owner
Accept/Claim: Group members can take individual ownership
Automatic: System-driven transfers based on rules and timeouts

Integration Patterns¶

Conversation Threading¶

Clinical Task integrates with PolarisCommunication resources for complete audit trails:

PolarisClinical Task (1) ← basedOn ← (many) PolarisCommunication

Each conversation entry links back to the parent task, providing: - Email-style threading using Message-ID headers - Complete attribution with timestamps and authors - Markdown support for rich clinical content - Attachment handling for documents and media

AI Agent Integration¶

Clinical Task supports AI agents through PolarisDevice references:

PolarisClinical Task.owner → PolarisDevice (AI Agent)

When an AI agent owns a task: - "Awaiting AI" status clearly indicated in UI - Human oversight required - forwarding to AI doesn't absolve clinical responsibility - Timeout handling with escalation for unresponsive agents - Audit trail preservation for all AI interactions

External System Integration¶

Clinical Task supports external system handoffs:

PolarisClinical Task.owner → Organization (External System)

External integration features: - Pseudo-user representation for external systems - Status flagging shows "External → awaiting" state - Return acknowledgment can automatically reassign ownership - Configurable rules for timeouts, escalation, and error handling

Use Cases and Workflows¶

1. Lab Result Review¶

Scenario: CBC results arrive with abnormal values requiring physician review

Workflow: 1. Lab system creates PolarisClinical Task with: - code: "lab-review" - owner: Dr. Smith (ordering physician) - reasonReference: DiagnosticReport - priority: "urgent" (abnormal values)

Dr. Smith reviews results, adds comment via PolarisCommunication
Task completed with outcome documented

Example Task:

{
  "resourceType": "Task",
  "status": "ready",
  "code": {"text": "Lab Result Review"},
  "owner": {"reference": "Practitioner/dr-smith"},
  "for": {"reference": "Patient/john-doe"},
  "reasonReference": [{"reference": "DiagnosticReport/cbc-001"}],
  "priority": "urgent"
}

2. AI-Assisted Triage¶

Scenario: Patient message requires triage with AI assistance

Workflow: 1. Patient portal creates task for message review 2. Triage nurse forwards to AI agent for initial assessment 3. AI agent (PolarisDevice) processes message, provides summary 4. Nurse reviews AI recommendation, takes appropriate action

Ownership Flow:

Patient Message → Triage Nurse → AI Agent → Triage Nurse → Final Action

3. Referral Management¶

Scenario: Cardiology referral needs processing and follow-up

Workflow: 1. Physician creates referral task 2. MOA processes referral, forwards to external system 3. External system (specialist office) acknowledges receipt 4. Appointment confirmation completes the task

Task Hierarchy:

Parent: Referral Management
├── Child: Process Referral (MOA)
├── Child: External Acknowledgment
└── Child: Appointment Booking