Skip to main content
Feature ID: CL-22
Status: ✅ Implemented
Spec: CL-22-vital-signs-biometric-tracking.md
Last Updated: 2026-02-23
Last Verified: 2026-02-23

​
Overview

CL-22 provides vital signs and biometric tracking for behavioral health: standardized capture, longitudinal trending, metabolic monitoring, and CDS/FHIR integration. Integration is within CL (chart, CDS, lab, outcomes, FHIR, consent) and Platform Foundation; no cross-core dependencies outside PF.

​
Quick Reference

​
Decision Tree

  1. Is the operation standard vitals/biometrics read/write under TPO?
    • Yes → apply org/chart RLS and permission checks.
  2. Is the record tied to SUD/sensitive behavioral-health context?
    • Yes → enforce CL-11 consent helper before access.
  3. Is downstream alerting required?
    • For MVP: compute status on read.
    • Post-MVP: publish event contracts once defined.

​
Pattern Library

  • Tenant-scoped CRUD pattern: always include organization_id + chart scoping in mutations/queries.
  • Consent-conditional RLS pattern: apply CL-11 helper for sensitive monitoring contexts.
  • Contract-driven integration pattern: document CL-08/CL-10/CL-16 consumption paths before implementation.

​
Common Mistakes

​
Pre-Flight Checklist

  • CRUD paths enforce org + chart scoping.
  • RLS policies include SECURITY DEFINER helper usage and UPDATE WITH CHECK.
  • Consent enforcement paths reviewed for sensitive monitoring data.
  • CL-08/CL-10/CL-16 integration assumptions documented and validated.

​
Integration Points (from Spec)

​
API Contracts

​
Vitals/Biometrics CRUD

Organization- and chart-scoped CRUD via Supabase client with RLS enforcement. No public REST API for MVP.

​
CL-08 CDS Contract

CL-22 exposes a threshold evaluation service that CL-08 may consume:
  • Input: Vital sign type (e.g., systolic_bp), value, chart_id, captured_at
  • Output: Out-of-range flag with severity (e.g., critical, warning, normal)
  • Pattern: CL-08 subscribes to vitals writes or calls threshold evaluation on chart load
  • Implementation: Deferred to Phase 4 (T13); CL-08 extension pattern must be verified

​
CL-16 FHIR Observation Mapping

Contract for mapping cl_vital_signs / cl_biometrics to FHIR Observation resources. Documentation-only for MVP (CL-16 is “Not Started”). To be expanded in CL-16 integration doc when implemented.

​
CL-10 Outcomes Inputs

CL-22 provides consumable aggregates for CL-10 quality metrics:
  • Vitals summary by chart/period
  • Metabolic monitoring completion rate
  • Documentation-only for MVP (CL-10 is “Not Started”)
  • Standard vital signs (e.g. blood pressure, heart rate, temperature, weight, height) are generally covered by Treatment, Payment, and Health Care Operations (TPO) and do not require separate CL-11 consent for read/write via the vitals/biometrics CRUD endpoints.
  • Sensitive / behavioral health data in cl_vital_signs, cl_biometrics, and cl_metabolic_monitoring_events that relate to behavioral health (e.g. SUD, psych medication metabolic monitoring) or sensitive conditions (e.g. HIV, hepatitis) must enforce 42 CFR Part 2 / explicit consent per CL-11 before access. Examples: metabolic monitoring events tied to antipsychotic or MAT regimens; biometrics or vitals linked to SUD or HIV/hepatitis context. RLS policies must call the CL-11 consent enforcement mechanism (e.g. cl_check_sud_consent or equivalent SECURITY DEFINER helper) for those rows or contexts; API layer must not bypass consent checks. See CL-11 Consent Integration.
  • Example for implementers: Behavioral-health context that triggers CL-11 checks includes vitals captured during a SUD counseling visit, or metabolic monitoring in cl_metabolic_monitoring_events linked to a MAT/antipsychotic prescription; for such rows, enforce access via cl_check_sud_consent (or equivalent) before any read/write on cl_vital_signs, cl_biometrics, or cl_metabolic_monitoring_events.
RLS Implementation: The cl_metabolic_monitoring_events SELECT policy MUST include cl_check_sud_consent(chart_id, 'metabolic_monitoring', auth.uid()). Standard vitals and biometrics SELECT policies use cl_has_org_access only (TPO-covered).

​
Event Contracts

MVP Strategy: No events are published for CL-22 MVP. Metabolic monitoring overdue/due status is computed on read (query-time) rather than via cron or event publishing. This aligns with CL-21’s deferred event strategy. Future (post-MVP): If CL-22 publishes events (e.g., cl_vital_sign_out_of_range, cl_metabolic_monitoring_overdue), they will be documented in EVENT_CONTRACTS.md.

​
Platform Integration Layer Usage

  • CL-22 is owned by CL core; no direct imports from other cores. All integration with CL-01, CL-08, CL-09, CL-10, CL-16, CL-11 is within CL or via existing platform/CL contracts.

​
Security and RLS

  • Protected tables: cl_vital_signs, cl_biometrics, cl_metabolic_monitoring_events; all contain PHI.
  • RLS: Organization and chart access enforced via SECURITY DEFINER helpers.
  • WITH CHECK: UPDATE policies must include WITH CHECK per constitution §5.2.4.
  • PHI: All data in these tables is PHI; handle accordingly.
  • CL-11 consent: Standard vitals (TPO) do not require separate Part 2 consent; cl_metabolic_monitoring_events SELECT policy requires cl_check_sud_consent for behavioral health / SUD / sensitive-condition metabolic monitoring events—see PHI Consent Enforcement section above.
  • Soft delete: Intentionally omitted; clinical measurements are immutable once captured (see spec Soft Delete Decision).

​
CL-22-EN-02 — vitals + metabolic-monitoring block adapters (CL-75, shipped 2026-07-02)

Vitals and metabolic-monitoring ship as CL-75 typed blocks (vitals-adapter, metabolic-adapter) over cl_vital_signs and cl_metabolic_monitoring_events (PR #2210), resolved onto documentation surfaces via getResolvedSurfaceBlocks — no duplicate storage; this doc’s CL-22 tables stay the single source.