Skip to main content

Test Your Knowledge

warning

RehabAlpha is still under active development. It is not yet HIPAA compliant and should only be used with dummy data.

This page helps you check your understanding of RehabAlpha schemas.

You can use it:

  • after reading the overview
  • after writing your first schema
  • when training teammates on schema authoring

Try answering each question before looking at the explanation.


Quick check

1. What is the root node of a RehabAlpha form?

A. group
B. template
C. text
D. conditional

Answer

B. template

A template is the root node of a form. It defines the form label, which document type it applies to, and the top-level child structure.


2. Which node type stores reusable option lists?

A. text
B. templateDefaults
C. options
D. group

Answer

C. options

options stores reusable arrays of choices for selection-based inputs such as selectInput and multiSelectInput.


3. Which property is used for the false branch of a conditional?

A. fallbackChildren
B. alternativeChildren
C. hiddenChildren
D. elseChildren

Answer

D. elseChildren

If a conditional's when evaluates to false, RehabAlpha traverses elseChildren, if provided.


4. Which of the following may a selection input use for options?

A. An inline array of strings
B. An inline array of { label, value } objects
C. A string ID that points to an options node
D. All of the above

Answer

D. All of the above

Selection inputs support all three patterns.


5. Which node type is not rendered directly?

A. textInput
B. group
C. options
D. conditional

Answer

C. options

It supplies reusable option data, but it is not displayed directly in the form UI.


6. Which operator should you use when the field value is an array and you want to check whether it contains one specific value?

A. equals
B. isIn
C. includes
D. doesNotEqual

Answer

C. includes

Use includes when the field value is an array, such as a multiSelectInput field or *payorTypes.


7. True or false: A template may be nested inside a group.

Answer

False

A template must be a root node. It cannot appear as a child of another node.


8. True or false: Two inputs may share the same ID if they are in different parts of the tree.

Answer

False

Every node ID must be unique. RehabAlpha also rejects visible trees where the same input ID would render more than once at the same time.


9. How is the default template chosen for a document type?

A. The first matching template always wins
B. The template with the longest children array wins
C. The matching template with the highest numeric priority wins
D. The matching template whose showIf is true wins

Answer

C. The matching template with the highest numeric priority wins

RehabAlpha finds the templates whose appliesTo matches the current document type, then picks the one with the highest numeric priority.

Important details:

  • templates without a numeric priority are ignored for default selection
  • if two matching templates tie, the earlier one in schema order wins
  • showIf does not participate in template selection

10. What does hydration do?

Answer

Hydration resolves references in the flat schema and turns them into a nested runtime tree. This includes resolving children, elseChildren, branches[].children, fallbackChildren, and options references.


11. What does showExplicitNone do?

Answer

showExplicitNone is supported on selectInput and multiSelectInput.

It allows RehabAlpha to distinguish:

  • unanswered
  • explicitly none

Persisted meanings:

  • for selectInput, null means unanswered and '' means explicitly none
  • for multiSelectInput, null means unanswered and [] means explicitly none

Spot the issue

Read each snippet and identify what is wrong.


1. Missing reference target

{
id: "pt_eval_template",
type: "template",
label: "PT Evaluation",
appliesTo: "evaluation",
children: ["pain_level_input"]
}

What is wrong?

Answer

The template references pain_level_input, but that node is not defined anywhere in the snippet.

This would fail reference validation.


2. Invalid template placement

{
id: "history_group",
type: "group",
children: [
{
id: "nested_template",
type: "template",
label: "Nested Template",
appliesTo: "evaluation"
}
]
}

What is wrong?

Answer

A template must be a root node and cannot be nested as a child of another node.


3. Invalid options reference

{
id: "pain_level_input",
type: "selectInput",
label: "Pain Level",
options: "history_group"
}

What is wrong?

Answer

The options property must reference an options node if it uses a string ID. Referencing a group node is invalid.


4. Wrong operator for array field

{
id: "medicare_logic",
type: "conditional",
when: { field: "*payorTypes", isIn: ["medicarePartA"] },
children: ["pdpm_group"]
}

What is wrong?

Answer

*payorTypes is an array, so isIn is the wrong operator here.

You should use includes instead:

{
id: "medicare_logic",
type: "conditional",
when: { field: "*payorTypes", includes: "medicarePartA" },
children: ["pdpm_group"]
}

5. Wrong assumption about template selection

;[
{
id: 'eval_template_a',
type: 'template',
label: 'Evaluation A',
appliesTo: 'evaluation',
children: ['group_a'],
},
{
id: 'eval_template_b',
type: 'template',
label: 'Evaluation B',
appliesTo: 'evaluation',
priority: 1,
children: ['group_b'],
},
]

What is the issue if you expect eval_template_a to be the default?

Answer

eval_template_a has no numeric priority, so it is ignored for default selection.

eval_template_b would become the default evaluation template because it has a numeric priority.


Mini scenarios

Scenario 1

You have three different fields that all ask for the affected side:

  • in evaluation
  • in treatment
  • in discharge

What is the best pattern?

Suggested answer

Create one reusable options node, such as side_options, and point each selection input to it.

That keeps the choices consistent and easier to maintain.


Scenario 2

A field should only appear for PT users in SNF settings.

What feature should you use?

Suggested answer

Use a conditional with special context variables such as:

  • *disciplineId
  • *facilityType

Example:

{
id: "pt_snf_logic",
type: "conditional",
when: {
all: [
{ field: "*disciplineId", equals: "PT" },
{ field: "*facilityType", equals: "SNF" }
]
},
children: ["mobility_group"]
}

Scenario 3

A clinician should see follow-up questions only if they answered “Yes” to a prior question.

What pattern should you use?

Suggested answer

Use a conditional whose when references the earlier field, and place the follow-up questions inside children.


Scenario 4

You need to distinguish between:

  • the clinician has not answered the field yet
  • the clinician is explicitly saying none apply

What pattern should you use?

Suggested answer

Use showExplicitNone: true on a selectInput or multiSelectInput.

That lets RehabAlpha preserve the difference between unanswered and explicit none.


Two hands-on challenges

These are practical exercises you can do on paper or in your schema editor.


Challenge 1: Build a tiny pain assessment template

Write a schema that includes:

  • one template for evaluation
  • one selectInput asking whether pain is present
  • one conditional
  • one numberInput for pain level shown only when pain is present

A possible solution:

;[
{
id: 'yes_no_options',
type: 'options',
items: [
{ label: 'Yes', value: 'yes' },
{ label: 'No', value: 'no' },
],
},
{
id: 'pain_eval_template',
type: 'template',
label: 'Pain Evaluation',
appliesTo: 'evaluation',
priority: 1,
children: ['pain_present_input', 'pain_logic'],
},
{
id: 'pain_present_input',
type: 'selectInput',
label: 'Is pain present?',
options: 'yes_no_options',
flavor: 'buttons',
},
{
id: 'pain_logic',
type: 'conditional',
when: { field: 'pain_present_input', equals: 'yes' },
children: ['pain_level_input'],
},
{
id: 'pain_level_input',
type: 'numberInput',
label: 'Pain Level (0-10)',
min: 0,
max: 10,
isInteger: true,
},
]

Things to notice:

  • the template is the root
  • priority controls default template selection
  • the conditional references the earlier input by ID
  • the follow-up input appears only when needed

Challenge 2: Refactor repeated options into a reusable list

Suppose you start with this:

;[
{
id: 'affected_side_input',
type: 'selectInput',
label: 'Affected Side',
options: ['Left', 'Right', 'Bilateral'],
flavor: 'buttons',
},
{
id: 'dominant_side_input',
type: 'selectInput',
label: 'Dominant Side',
options: ['Left', 'Right', 'Bilateral'],
flavor: 'list',
},
]

Refactor it so both inputs share one reusable options node.

A possible solution:

;[
{
id: 'side_options',
type: 'options',
items: ['Left', 'Right', 'Bilateral'],
},
{
id: 'affected_side_input',
type: 'selectInput',
label: 'Affected Side',
options: 'side_options',
flavor: 'buttons',
},
{
id: 'dominant_side_input',
type: 'selectInput',
label: 'Dominant Side',
options: 'side_options',
flavor: 'list',
},
]

Things to notice:

  • the option list is defined once
  • both inputs stay consistent
  • future edits happen in one place

Self-review checklist

After working through the exercises, ask yourself:

  • Can I explain the difference between template, group, and conditional?
  • Do I know when to use includes vs isIn?
  • Can I explain why options is useful?
  • Do I understand how priority determines the default template?
  • Do I know what hydration means?
  • Can I recognize a broken reference or visible duplicate-input risk?
  • Do I understand when showExplicitNone is useful?

If yes, you are in strong shape.


Where to go next

Now that you have tested yourself, the best next pages are:

  • Schemas Overview
  • Frequently Asked Questions
  • Tips & Tricks
  • Writing Your Own Schema
  • Writing Schemas with AI
  • Schema Library