Logic

Translating Clinical Knowledge into Logic

Your clinical expertise and established best practices form the basis of your evaluation's logic. In this stage, you translate that knowledge into concrete business rules that the platform can execute. The goal is to encode clinical decision-making into visibility rules and formula expressions that produce accurate, repeatable results.

Map Your Logic Before Building

Before you write your first formula, map out the complete logic model. Diagramming your decision paths and scoring algorithms on paper or in a flowchart helps you:

• Identify gaps where inputs do not connect to outputs
• Spot contradictions between rules
• Discover edge cases that need special handling
• Communicate your approach to colleagues during peer review

Thorough logic mapping before building saves you from chasing bugs in a complex web of formulas after the fact.

Two Types of Logic

The platform supports two distinct types of logic that work together to power your evaluation:

Visibility Rules

Visibility rules control which elements appear on screen based on conditions you define. Use them to create adaptive experiences where users see only the questions relevant to their situation.

You configure visibility rules using two approaches:

• AND/OR conditions -- Combine multiple criteria to determine whether an element displays. For example, show a follow-up question only when the patient's age is over 65 AND they reported a specific symptom.
• Formula-based expressions -- Write expressions that evaluate to true or false. When the expression returns true, the element appears. This approach gives you full flexibility for complex conditional logic.

Visibility rules keep your evaluation streamlined by hiding irrelevant content, reducing the number of questions a user must answer for any given path.

Formula Expressions

Formula expressions perform calculations and produce results. You write them using spreadsheet-style syntax that supports standard functions:

• Conditional functions -- IF, IFS, SWITCH for branching logic
• Logical functions -- AND, OR, NOT for combining conditions
• Mathematical functions -- SUM, AVERAGE, MIN, MAX, ROUND for numerical calculations
• Text functions -- CONCATENATE, LEFT, RIGHT for string manipulation

Combine these functions to build scoring algorithms, risk classifications, and clinical recommendations.

Reference Data with Keywords

Use the labels you assigned to your data elements as keywords within your formulas. When you write a formula like IF(systolic_bp > 140, 1, 0), the keyword systolic_bp pulls the user's input directly into the calculation. This approach keeps your formulas readable and tied directly to the data model you planned in the previous stage.

Break Up Complex Formulas with Named Expressions

When a formula grows long or involves multiple nested functions, break it into smaller pieces using named expressions. Create an intermediate expression with a descriptive name, then reference that name in your final formula.

For example, instead of writing one massive formula that calculates a composite risk score, create named expressions for each risk component -- cardiac_risk, metabolic_risk, lifestyle_risk -- and then combine them in a final expression. This approach makes your logic modular, testable, and easier for reviewers to follow.

Create Test Scenarios

Test scenarios validate that your logic produces correct results for every possible path through the evaluation. For each scenario, define:

• A specific set of input values
• The expected output or result
• A descriptive name that captures what the scenario tests

Work through your logic map systematically and create scenarios that cover:

• Typical cases -- The most common input combinations your users will encounter.
• Boundary cases -- Inputs at the threshold between two results (e.g., a score of exactly 10 when the cutoff is 10).
• Edge cases -- Unusual but valid combinations, such as all minimum values, all maximum values, or unexpected input patterns.

Consider Edge Cases

Ask yourself what happens in extreme or unexpected situations:

• What result does the evaluation produce when all inputs are at their minimum values?
• What happens when all inputs are at their maximum values?
• How does the evaluation behave when a user leaves optional fields empty?
• Do boundary values trigger the correct classification or score?

Testing these edge cases before you publish prevents surprises when real users interact with your evaluation in ways you did not anticipate.

Document Your Logic Model

Write down your logic model in a format that others can review. Include:

• The mapping between inputs, calculations, and outputs
• The rationale behind scoring thresholds and decision rules
• Any clinical references or guidelines that informed your logic

Documentation supports peer review by giving reviewers the context they need to evaluate whether your logic accurately reflects clinical best practices. It also serves as a reference when you need to update the evaluation in the future.