The core boundary
The system preserves a clear boundary between decision support and medical action.
AI agents flag, interpret as decision support, and route. They never prescribe and never make a clinical decision. Treatment eligibility logic produces clinician-required flags, not authorizations.
What a treatment flag means
A treatment flag is not a recommendation to treat. It is a structured signal that a clinician may need to review a possible pathway. It indicates possible relevance (patient data matches a reviewed pathway condition), is structured (from deterministic schema logic), evidence-linked, safety-limited (suppressions, contraindications, and hardening rules may block or route the case), clinician-required, traceable, and not final. The GLP-1 flow uses this model directly: if conditions are met, a clinician-required flag is raised, never an authorization. The same pattern applies to every treatment-adjacent pathway.General pathway structure
Every treatment pathway follows a controlled sequence. This keeps the engine useful without letting it become autonomous.1
Collect intake facts
Avoids pathway evaluation from incomplete context.
2
Normalize clinical data
Prevents unit, alias, or format errors.
3
Compute derived values
Supports structured interpretation.
4
Apply calibrations if relevant
Prevents misclassification where context changes meaning.
5
Evaluate pathway criteria
Produces an advisory flag only.
6
Apply suppressions
Blocks interpretation when context makes it unsafe.
7
Apply hardening rules
Prevents over-diagnosis or premature conclusions.
8
Screen contraindications
Surfaces safety blockers.
9
Assign review state
Routes ambiguity to a clinician.
10
Clinician reviews
The medical decision remains human.
11
Record decision trace
Creates auditability.
12
Monitor follow-up
Supports ongoing safety.
Pathway categories
Consensus Engine can support multiple pathway types, but each remains under physician governance. The engine may help identify which pathway deserves attention; it does not decide which treatment the patient receives.Protocol linkage
A protocol is different from a rule. A rule detects a condition; a protocol defines how clinicians evaluate and manage a pathway. The architecture identifies treatment and protocol linkage tables such asTREATMENTS, TREATMENT_*, and PROTOCOL_*.
Required pathway inputs
No pathway should run on incomplete data if missing facts materially change interpretation. Each pathway defines required, optional, blocking, review, and longitudinal inputs.Contraindication governance
Treatment-adjacent pathways must include contraindication handling. A contraindication screen is a clinical safety input, not a simple form field.
The GLP-1 workflow includes contraindication screening for conditions such as MTC, MEN2, and pancreatitis before any clinician-required advisory flag can be evaluated safely. Other pathways follow the same pattern: collect safety context first, then route to clinician review.
Patient-facing language
Treatment-related language must be especially cautious. The patient should never see “You are eligible,” “The AI recommends this medication,” “You should start this protocol,” “Your treatment is approved,” or “Your result means you need this intervention.”
Patients never see “eligible.” They see “possible candidate, requires medical evaluation.” That wording standard is generalized across all treatment pathways.
Clinician-facing view
The clinician sees the full reasoning behind any pathway flag: raw values, normalized values, derived values, runtime facts, criteria matched, criteria not met, the safety screen, suppression rules, hardening rules, the calibration trace, the evidence trace, lifecycle status, a patient-language draft, and the decision ID. For treatment pathways, this trace protects both the clinician and the patient.Pathway approval lifecycle
Treatment-related logic moves through the same clinical lifecycle as other rules, but with stricter review. Treatment pathways should be among the most tightly controlled objects in the schema.Pathway validation
Every pathway needs validation before activation, and for treatment pathways validation failures should be release blockers.Monitoring after activation
Treatment pathways require monitoring after release to answer whether the pathway is clinically useful, too sensitive, too narrow, or unsafe in practice. Suggested metrics: advisory flags generated, flags reviewed by clinicians, flags rejected by clinicians, missing-data blocks, contraindication blocks, patient-language incidents, treatment starts after review, adverse event review triggers, protocol deviations, rule override frequency, and outcome follow-up completeness.Handling clinician disagreement
Clinician disagreement is a signal, not a failure. If clinicians frequently reject a pathway flag, the rule may be too broad, missing context, or using weak criteria. If clinicians often override a negative decision, the rule may be too narrow.
Because decisions are traceable, these patterns can be studied rather than guessed.
Pathway retirement
A pathway should be retired when it is no longer clinically appropriate, safe, or supported. Triggers include evidence changes, protocol changes, an emerging safety issue, high clinician rejection, poor monitoring performance, changed regulatory guidance, changed partner requirements, or a better pathway replacing it. The lifecycle statesDEPRECATED and RETIRED ensure outdated logic does not remain active indefinitely.
AI-agent role in treatment pathways
AI agents can make treatment pathways easier to operate, but only within strict boundaries. This keeps AI operational, not clinical-authoritative.Decision trace for pathways
Every pathway evaluation produces a structured trace that proves the system did not silently prescribe or authorize care: pathway ID, patient facts, biomarker values, derived values, criteria result, safety gates, calibration, evidence or protocol source, lifecycle status, output (advisory flag, insufficient data, blocked, or review state), visibility, clinician decision and rationale, and follow-up plan.Recommended pathway governance standard
Every treatment pathway should meet the following standard before patient exposure. This turns treatment governance into an auditable checklist.Deterministic criteria, evidence source, protocol owner, Medical Director review, contraindication screen, suppression and hardening rules, patient-language approval, clinician-required review, golden test cases, boot validator pass, runtime trace, monitoring plan, and rollback plan — all present.