Governance principle
No clinical content should affect a patient unless it has passed review, validation, release control, and physician-governed activation.
The role of the Medical Director
The Medical Director is the clinical authority over the engine’s medical logic. The role is not to manually interpret every raw data transformation, but to govern the clinical rules that determine how interpretation happens:- Rule review — confirm that clinical logic is medically appropriate.
- Calibration review — confirm evidence, applies-when logic, and safety posture.
- Safety review — validate suppressions, hardening rules, and escalation pathways.
- Evidence review — confirm that sources are suitable for the interpretation.
- Patient-language review — prevent overstatement or diagnostic language.
- Release approval — decide which clinical content is eligible to go live.
- Deprecation — retire or replace outdated clinical logic.
- Incident review — reassess rules if a safety concern emerges.
- Outcomes learning — use reviewed outcomes to improve future rules.
Licensed clinician decision-making
The engine supports clinical review, but it does not make final medical decisions. In patient care workflows, licensed clinicians review the relevant intake, calibrated labs, rule output, safety context, and decision trace. Treatment eligibility logic produces clinician-required flags, not authorizations.
This preserves a clear boundary between decision support and medical practice.
Operator physician versus clinical responsibility
The system may involve operator physicians or community-facing clinical guides, especially in partner or operator settings. Clinical responsibility sits with Consensus Center’s licensed clinical team under its habilitación, while the operator physician is the community-facing guide.
The product should never blur these roles. Clear role separation is part of clinical safety.
Clinical lifecycle
Clinical content moves through a controlled lifecycle. Runtime behavior depends on it.
Rules do not run unless their lifecycle state permits it, enforced by a boot validator.
Existence in the schema is not the same as permission to run.
Why lifecycle control matters
Without lifecycle control, a clinical engine can fail silently: a draft threshold might reach patients, a calibration might apply before evidence review, a pattern might activate before safety testing, a treatment flag might surface before clinician approval, or a deprecated rule might continue to influence decisions.
This makes governance technical, not informal.
Medical sign-off queue
A physician-governed engine needs a structured sign-off process. The queue lets the Medical Director and reviewing clinicians see exactly what needs review, why it matters, and what decision is required. It includes the item ID, item type, clinical domain, current lifecycle state, proposed change, evidence source, evidence grade, safety impact, patient visibility, required clinician action (approve, revise, reject, defer, or request more evidence), reviewer, timestamp, and release dependency. This avoids vague review. The clinician is not simply asked to “approve the engine.” The clinician reviews defined clinical objects.Release gates
Approval and release are related but not identical. A rule can be medically approved and still not be ready for production. Release gates ensure clinical approval, technical validation, and safety checks all pass before patient exposure. A release gate requires:- Medical Director approval recorded
- Evidence trace attached and reviewable
- Runtime fact coverage — all referenced facts exist
- Operator coverage — all JSON operators registered
- Unit validation from a single source of truth
- Message validation — patient-facing templates resolve correctly
- Golden test coverage — expected outputs pass representative cases
- Safety review — suppression and hardening interactions checked
- Visibility review — patient-facing output is safe
- Version record — rule and calibration versions recorded
- Rollback plan — prior version can be restored or the rule disabled
Boot-time enforcement
The engine runs boot-time validators before serving, checking internal integrity before any patient can receive output:
Governance should not depend only on people remembering the process. The runtime enforces it.
Governance of calibrations
Calibrations require special governance because they can alter interpretation based on sensitive context. A calibration requires a defined mechanism, applies-when logic, an evidence grade, Medical Director review, patient-visibility control, versioning, a runtime trace, monitoring, and a deprecation path. This prevents calibration from becoming an unreviewed personalization layer.Governance of treatment flags
Treatment-related logic requires an even stricter boundary. The engine may identify a possible candidate for a clinical intervention, but it must not authorize the intervention. For GLP-1 care, the Coordinator agent can collect intake facts, consolidate records, and run advisory candidacy flagging; if conditions are met, the engine raises a clinician-required flag. Treatment governance enforces no automatic eligibility language, no prescription by agent, a collected and reviewed contraindication screen, hardening rules applied before flagging, clinician-required review of all treatment flags, protocol linkage for prescribing, and a decision trace recording rule, source, calibration, and clinician decision. The patient journey can be efficient without becoming automated prescribing.Governance of AI agents
AI agents are governed differently from clinical rules, but they remain constrained by them. Clinical logic changes go through the Medical Director lifecycle, not through model updates, and agent behavior in clinical pathways is constrained by engine rules and review states. A model update should not change clinical meaning.
The model can help explain and organize. It cannot redefine clinical logic.
Governance of patient-facing language
Patient-facing language is part of clinical governance. The words shown to a patient can create anxiety, false reassurance, or perceived diagnosis, so they should be reviewed and controlled.
A preventive system should be calm, precise, and limited. It should not use diagnostic language unless a licensed clinician has made that determination.
Governance audit trail
Every governance action should leave an audit trail covering rule creation (author, date, version, rationale), evidence attached (source, grade, reviewer), medical review completed, rule approved, rule activated, rule changed (diff, rationale, reviewer), rule deprecated, rule retired, patient-facing output generated, clinician case review, and incidents (related decision IDs and corrective action). The decision record is the unit of auditability for runtime interpretations. Clinical content governance and runtime decision traceability must work together.Change management
Clinical knowledge changes over time, and the system must change safely. A change management process defines how to handle a new biomarker, new threshold, new calibration, new pattern, new treatment flag, new AI-agent behavior, new patient-facing message, evidence update, and safety incident.Rollback and retirement
A safe system must be able to undo or retire clinical logic. Rollback may be needed when a rule produces unexpected output, evidence changes, clinician review identifies unsafe wording, a calibration over-applies, a test case fails, a safety incident occurs, or a model provider changes behavior. The lifecycle statesDEPRECATED and RETIRED make this explicit. Outdated content should not remain active by default.