Skip to main content

Care Plan Service — Service Overview

Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template · 03 platform-services · 02 DDD

Purpose

The care-plan-service owns longitudinal, multidisciplinary care planning for every patient in the platform. It manages the full lifecycle of CarePlan, Goal, CareTeam, and Activity/Intervention records, including chronic disease management programs, post-acute follow-up plans, and preventive care protocols.

It is an optional licensed add-on (entitlement: ehr.care_plans). Unlicensed tenants receive 403 MODULE_NOT_LICENSED on all write endpoints.

Bounded Context Responsibilities

In scopeOut of scope
CarePlan CRUD with versioning and review workflowClinical orders and CPOE (orders-service)
Goal management — status, coded targets, due datesMedication prescribing (medication-service)
Activity/intervention tracking — assignment and completionLab/imaging task orchestration (orders-service)
CareTeam composition per planPopulation-level program aggregation (population-health-service)
FHIR R4 read/search surface: CarePlan, Goal, Task, CareTeamFHIR write via FHIR HTTP (out of scope, REST-first write model)
Optimistic concurrency via version fieldCase management system integration (backlog)
Tenant-isolated storage with RLSDirect payer reporting

Upstream Dependencies

ServiceWhy
registration-servicePatient identity (patientId) validation
scheduling-serviceEncounter link (encounterId?) on plan creation
identity-serviceJWT claims, tenantId, RBAC roles
terminology-serviceCoded goals (SNOMED CT, ICD-10-CM, LOINC)
audit-serviceProvenance and clinical audit pipeline
provider-directory-serviceCareTeam practitioner identities

Downstream Dependents

ServiceDependency
patient-chart-serviceActive care plan summaries for chart view
patient-portal-serviceRead-only projection of active care plans for patients
population-health-serviceAggregated goal achievement metrics via NATS events
communication-serviceNotifications on goal overdue / plan review due

Key Architectural Decisions

  1. REST-first writes, FHIR read surface. All create/update operations use /api/v1/care-plans/*. The FHIR R4 read surface (CarePlan, Goal, Task, CareTeam) is served via fhir-gateway. FHIR write interactions are explicitly out of scope until a platform release scopes them.
  2. Optimistic concurrency. Mutating requests carry and return version; stale writes return 409 Conflict.
  3. Transactional outbox. Domain events are reliably published to NATS JetStream via outbox; no events lost on process crash.
  4. Tenant isolation via RLS. All tables contain tenant_id; Postgres RLS policies enforce zero cross-tenant reads.
  5. Coded clinical concepts. Goals and activities reference terminology-service codings; free-text fallback is permitted.

Architecture Diagram

Slice Involvement

SliceRole
S1 — Clinical data captureCare plan and goal creation
S2 — Team-based careCareTeam coordination, multidisciplinary updates
S3 — Chronic care programsDisease program templates (backlog)
S4 — Patient engagementPortal read projection via fhir-gateway

Source Reconciliation

Source: services/care-plan-service/_sources/care-plans/ — single module CLIN-CAREPLAN v1.2. No multi-module merge required. Legacy FR prefix FR-CP-* is preserved alongside new FR-CAREPL-* in the FR mapping table.