Medical necessity criteria follow specific logic. A patient needs to meet all requirements, or any one of several options, or a minimum number from a list. Indication blocks capture this logic explicitly.
When you write coverage criteria or ingest existing policies, the platform converts requirements into indication blocks rather than leaving them as plain text paragraphs. Indication blocks display as structured criteria in UM review workflows, where they become checkboxes reviewers mark as met or not met. The logic you define determines whether the authorization approves.
Each indication block has a logic operator—ALL, ANY, NOT ANY, or AT LEAST. These operators define how criteria within that block relate to each other. "Knee arthroplasty is considered appropriate if ALL of the following is TRUE" means every listed criterion must be satisfied. "ANY of the following is TRUE" means meeting just one criterion is sufficient.
Logic operators can nest. A parent block might require ALL criteria, while a child block within it requires ANY of its sub-criteria. This matches how policies are actually written: "Patient must meet ALL of: failed conservative treatment AND (ANY of: distal femur fracture OR malignancy OR failed previous osteotomy)."
Set the logic operator using the dropdown that appears when you click an indication block. The system displays the current operator and lets you switch between ALL, ANY, NOT ANY, or AT LEAST. For AT LEAST, specify the minimum number required—"at least 2 of the following must be true."
NOT ANY handles exclusions and contraindications. Instead of writing "patient must not have any of the following," you structure it as a NOT ANY block containing the disqualifying conditions. If any item in a NOT ANY block is true, the criteria fail.
The logic you define here determines automated decision-making. When policies feed into UM systems via API, the logic operators tell the system how to evaluate clinical documentation. ALL means every criterion must appear in the medical record. ANY means finding one is enough. This prevents ambiguity that comes from prose descriptions of requirements.
Indication blocks show policy writers the actual decision logic reviewers will apply. No interpretation gap between what the policy says and how it gets implemented.