Event & API Reference

​

Events

​

ce_lead_converted_to_patient

{
  lead_id: string;        // UUID
  contact_id: string;     // UUID
  organization_id: string; // UUID
  correlation_id: string;  // Format: "{lead_id}_to_{type}_{timestamp}"
  converted_to_type: string;
  converted_to_id?: string;
  converted_by: string;    // UUID (user)
  converted_at: string;    // ISO 8601
}

​

ce_lead_converted_to_resident

​

ce_lead_converted (deprecated)

​

Audit Table: ce_lead_conversions

​

Permissions

​

Idempotency Rules

1. Each conversion generates a unique correlation_id in format {lead_id}_to_{conversion_type}_{timestamp}. The correlation_id is created once per user intent and must be reused unchanged across retries or double-submits — it is not regenerated on each attempt.
2. For lead_to_both, two audit records are inserted (one per type) with distinct correlation IDs
3. Downstream subscribers (PM-01, RH-01) MUST check correlation_id before creating entities
4. Duplicate delivery with same correlation_id returns success without creating a second record (enforced by UNIQUE constraint on (organization_id, lead_id, conversion_type, correlation_id))

​

References

• Full Spec: specs/ce/specs/CE-29-lead-to-patient-conversion-pipeline.md
• Integration Doc: docs/architecture/integrations/CE-29-LEAD-CONVERSION-INTEGRATION.md
• Event Contracts: docs/architecture/integrations/EVENT_CONTRACTS.md
• CE-17 (deprecated): specs/ce/specs/CE-17-ce-rh-admission-handoff.md