<bio-checkin>

A patient-reported outcome (PRO) check-in widget that presents a step-by-step questionnaire and submits responses as observations. Supports both static configuration (via attributes) and profile-driven mode (auto-configured from the user's episode profile).

<bio-checkin question-types='["readiness","confidence","worry"]'></bio-checkin>

How It Works

When <bio-checkin> receives context from a parent <bio-provider>:

1. Resolves configuration — in profile-driven mode, reads question types, schedule, and questionnaire ID from the SDK config; in static mode, parses the question-types attribute
2. Fetches prior scores — calls GET /api/v1/observations/latest for each biosignal to show the user's last response
3. Presents questions one at a time — renders a scale (1–5 or 1–10 depending on question type) with step counter
4. Submits all answers — sends a single POST /api/v1/episodes/:id/questionnaire-response containing all items
5. Shows results with trends — the server compares each answer to the most recent prior observation and returns a trend (increasing, decreasing, or stable)
6. Supports updates — an "Update" button lets the user re-submit, and the next trend comparison will use the previous submission as the baseline

Modes

Static Mode

Pass question types directly as an attribute. You control which questions appear:

<bio-checkin
  question-types='["readiness","confidence"]'
  episode-id="ep_abc123">
</bio-checkin>

Profile-Driven Mode

Omit question-types and let the widget auto-configure from the user's episode profile. The profile's spec.sdk.checkin section defines available check-in contexts (e.g., weekly, daily), each with its own question types, schedule, and questionnaire ID.

<bio-checkin context_type="weekly"></bio-checkin>

In profile-driven mode, the widget also reads the check-in status from the SDK config. If the check-in is already completed for the current period, it renders a summary view instead of the questionnaire form.

Attributes

Events

Trend Indicators

After submission, each result row can display a trend arrow comparing the current score to the most recent prior observation for that biosignal:

Trends are computed server-side in the questionnaire-response handler. When no prior observation exists, the trend field is null and no indicator is shown.

CSS Classes

The widget renders with semantic CSS classes for styling. No Shadow DOM — standard CSS selectors work.

CSS Custom Properties

Code Examples

Profile-Driven Weekly Check-in

<bio-provider
  api-key="org_your_key"
  project-key="proj_your_key"
  xuser-id="user-123">

  <bio-checkin context_type="weekly"></bio-checkin>

</bio-provider>

The widget reads the weekly entry from the profile's spec.sdk.checkin map. If the user has already completed the weekly check-in, it shows the summary with scores and trends. Otherwise it opens the questionnaire.

With Event Handling

<bio-checkin id="checkin" context_type="weekly"></bio-checkin>

<script>
  document.addEventListener('anybio:checkin:submit', (e) => {
    const { observations, episodeId } = e.detail;
    observations.forEach(obs => {
      console.log(`${obs.biosignal}: ${obs.value_quantity} (${obs.trend})`);
    });
  });

  document.addEventListener('anybio:checkin:dismiss', () => {
    console.log('Check-in dismissed');
  });
</script>

Custom Styling

/* Match your app's design system */
bio-checkin {
  --bio-primary: #1a73e8;
  --bio-radius-lg: 16px;
  --bio-trend-improving: #34a853;
  --bio-trend-declining: #ea4335;
}

/* Style the scale buttons */
.bio-checkin-scale-btn {
  width: 48px;
  height: 48px;
}

/* Customize the summary card */
.bio-checkin-summary {
  border: 1px solid var(--bio-border);
}

Static Mode with All Options

<bio-checkin
  question-types='["readiness","confidence","worry","energy","pain"]'
  episode-id="ep_abc123"
  questionnaire-id="pre_op_weekly">
</bio-checkin>

Roadmap

• Submission cooldown — Wire up the backend policy cooldown system to enforce frequency limits (e.g., one weekly check-in per 7-day window). The infrastructure exists in the policy engine; it needs to be connected to the questionnaire-response endpoint.