← Back to use cases

Secure and Compliant Scheduling, Tracking, and Alerting for Patient Questionnaires with Fire Arrow

A practical reference architecture for patient questionnaire surveillance on top of FHIR. Covers questionnaire authoring, reusable monitoring protocols, CarePlan-based scheduling, Task materialization, completion tracking, response-based alerting, and access control.

Executive Summary

Healthcare teams often want to monitor patients with recurring questionnaires: PHQ-9 every two weeks, KCCQ-12 every month, post-surgical recovery checks at predefined milestones, or study-specific symptom surveys throughout a trial. The workflow sounds simple at first. In practice, it is not.

A reliable implementation must answer several questions at once:

  • Which instrument is being used, and is it standardized?
  • How is the schedule defined once and reused consistently?
  • How are reminders triggered at the right time for each patient?
  • How are completions tracked in a way that remains clinically and operationally auditable?
  • How are worsening responses detected and escalated?
  • How do patients, practitioners, and services see only the data they are allowed to see?

The common failure pattern is to split these concerns across too many places. The questionnaire lives in one frontend form builder. Scheduling logic lives in custom jobs. Alerting logic lives in a separate service. Access control is patched in later. The result is brittle, hard to audit, and difficult to evolve when the protocol changes.

The central design principle of this paper is simple: patient questionnaire surveillance should be modeled as a governed clinical workflow, not as a collection of reminders. In Fire Arrow, a questionnaire can be authored or imported in the Web UI, linked to a reusable PlanDefinition, applied to individual patients as CarePlans, materialized into Task resources on a rolling schedule, and connected to reminder and alert webhooks without moving security responsibility out of the server.

This paper describes how Fire Arrow uses Questionnaire, PlanDefinition, CarePlan, Task, QuestionnaireResponse, and Subscription together; how the Web UI supports authoring and rollout; how the CarePlan event engine turns protocol timing into operational Tasks; and how authentication and authorization remain the control plane for safe and compliant execution.

The goal is not to claim that every questionnaire workflow is automatically compliant. The goal is to show how to build such workflows on a FHIR-native backend so that standardization, scheduling, auditability, least privilege, and operational control are present from the start.

1. Audience and Scope

This paper is intended for:

  • CTOs, CIOs, and technical product leaders building digital health products with recurring patient follow-up workflows.
  • Solution and platform architects responsible for backend design, workflow orchestration, and data governance.
  • Clinical and research application teams implementing standardized instruments such as PHQ-9, KCCQ-12, or custom protocol questionnaires.
  • Security, privacy, and compliance stakeholders reviewing how reminder and alert workflows interact with protected health information.

In scope

This paper covers:

  • recurring questionnaire surveillance using reusable FHIR-native protocol definitions,
  • questionnaire authoring and import in the Fire Arrow Web UI,
  • CarePlan-based scheduling and Task materialization,
  • reminder webhooks for due questionnaire administrations,
  • completion tracking and trend review,
  • response-based alerting patterns,
  • authentication and authorization controls around the entire workflow.

Out of scope

This paper does not:

  • provide legal advice or make blanket regulatory claims,
  • define clinical escalation thresholds for every questionnaire instrument,
  • prescribe one frontend implementation for patient delivery,
  • claim that alerting logic should always run inside the FHIR server,
  • recommend bypassing access control for convenience.

2. The Problem

There is real demand for structured patient follow-up outside the one-time visit:

  • mental health programs want repeated PHQ-9 screening,
  • cardiology teams want periodic symptom and quality-of-life questionnaires,
  • surgical pathways want milestone-based recovery tracking,
  • research teams want protocol-bound remote outcome collection.

These programs have a shared requirement: the questionnaire is not just a form. It is part of an ongoing clinical or study workflow.

The implementation creates several problems.

2.1 The instrument must be defined correctly

If a team uses a standardized instrument, they usually want the published structure, codes, and answer options rather than a loosely re-created local copy. In practice, teams often manually rebuild instruments in a form builder, losing the original LOINC codes and answer-set structure along the way. Once that happens, comparability between clinicians, programs, or downstream systems starts to break down.

2.2 The schedule must be reusable

In many programs, the protocol is the same for every eligible patient. For example, every depression patient may receive PHQ-9 every two weeks for six months. Building each patient schedule manually is inefficient and error-prone. When schedule logic lives in custom application code, a protocol change (different frequency, different instrument) requires a code change and a redeployment rather than a data update.

2.3 Operational work must be explicit

A surveillance protocol is not actionable until it becomes concrete work. Someone or something needs to know that a questionnaire is due today for a particular patient. Without an operational representation, teams fall back to custom cron jobs and background workers that compute due dates from scratch. These jobs tend to accumulate subtle bugs over time, especially around timezone handling, DST transitions, and edge cases in recurrence rules.

2.4 Completion and non-completion both matter

A safe system must record not only that a questionnaire exists, but whether it became due, whether the patient completed it, and whether follow-up actions were triggered. The workflow needs both scheduling state and response state. In conventional implementations, responses are stored in a proprietary format, disconnected from the schedule that triggered them, which makes completion tracking a manual reconciliation exercise.

2.5 Alerting belongs to a governed pipeline

A worsening score can require a review, a message, an in-app alert, or a direct clinician intervention. But alerting thresholds and actions are often organization-specific. The system needs a clean place to observe completed responses and route them into the organization’s escalation logic. Building a separate service that polls custom response tables is common but fragile.

2.6 Access control cannot be bolted on later

The same workflow touches multiple audiences and resource types:

  • patients may need to see only their own due questionnaires and their own responses,
  • practitioners may need to author questionnaires and protocols and review patient trends,
  • services may need tightly scoped access to read due Tasks or evaluate completed responses,
  • research or sponsor users may require filtered or blinded views in some deployments.

If these access patterns are not designed into the architecture early, reminder and alert workflows become a source of accidental data exposure. In practice, authentication and authorization are often designed and implemented as a separate project late in the development cycle.

2.7 Data leaves the system in a proprietary format

When questionnaire data eventually needs to reach a clinical system, an EHR, or a study database, someone builds an export step, maps fields manually, and often imports them into the target system by hand. Every connection point is a custom integration maintained by the development team. The data format was chosen for the application, not for interoperability.

The answer is not to avoid questionnaire automation. The answer is to implement it as a FHIR-native workflow with the server remaining the place where schedule semantics, identity, authorization, and operational events are enforced.

3. The Conventional Approach

When a team sets out to collect electronic patient-reported outcome measures, the first instinct is to assemble a stack from general-purpose components. A typical implementation looks roughly like this:

  1. Questionnaire creation. A clinical team defines the instrument in a spreadsheet, a PDF, or a form builder. If a standardized instrument like PHQ-9 exists, someone manually recreates it in the form builder, often losing the original LOINC codes and answer-set structure in the process.
  2. Backend. The team stands up a backend in Firebase, Supabase, or a similar headless platform. The data model is custom: questionnaire definitions, patient assignments, schedule entries, and responses all live in application-specific tables.
  3. Scheduling. A developer writes cron jobs or background workers that compute which patients are due. Timezone handling, deadline transitions, and missed-window logic are implemented from scratch.
  4. Delivery. The questionnaire is rendered in a custom frontend tightly coupled to the backend. Changing the delivery channel (push notification, SMS, a different app) requires reworking the integration.
  5. Data collection. Responses are stored in a proprietary format. When the data needs to reach a clinical system, an EHR, or a study database, someone builds an export step, maps fields manually, and often imports them into the target system by hand.
  6. Alerting. If worsening scores need to trigger an intervention, a separate service polls response tables and applies threshold logic.
  7. Authentication and authorization. Patient and practitioner access controls are designed and implemented separately, often late in the project.
  8. Protocol changes. When the monitoring protocol changes, the change requires code modifications and a redeployment.

Each of these layers works in isolation. The questionnaire format is disconnected from the schedule, the schedule is disconnected from the response data, and the response data is disconnected from the clinical system that ultimately needs it. Every connection point is a custom integration maintained by the development team.

The result is a system that works for one specific program but is expensive to change, difficult to audit, and hard to reuse for the next program. The remaining sections of this paper walk through how each of these concerns maps to FHIR resources and Fire Arrow’s workflow engine.

4. Design Principles

4.1 Define the protocol once, apply it many times

If the monitoring logic is standardized across patients, model it as a reusable protocol rather than manually building patient schedules one by one.

4.2 Keep protocol semantics in FHIR resources

Questionnaire structure belongs in Questionnaire. Reusable monitoring logic belongs in PlanDefinition. Patient-specific execution state belongs in CarePlan, Task, and QuestionnaireResponse.

4.3 Turn schedule semantics into operational work

The system should materialize concrete Task instances from care-plan timing rather than expecting external services to re-implement scheduling rules from scratch.

4.4 Keep security inside the server boundary

Identity resolution, authorization rules, request validation, and search narrowing must stay in the backend control plane. Reminder and alert services should consume already-authorized events, not become the primary policy engine.

4.5 Separate reminder delivery from alert evaluation

“Patient has a due questionnaire” and “patient submitted a clinically concerning score” are related but distinct events. They should be modeled separately so that reminder workflows and escalation workflows can evolve independently.

4.6 Make higher-risk actions explicit

Threshold evaluation may be automated. Clinical escalation actions may need review, acknowledgment, or organizationally specific workflow steps. The architecture should support both without forcing unsafe defaults.

4.7 Preserve auditability end to end

A governed workflow should let teams answer concrete questions later: when was a questionnaire scheduled, when did it become due, when was the patient notified, when was it completed, what score was produced, and what follow-up action was triggered?

5. Reference Architecture

5.1 How the architecture works

  1. A practitioner authors or imports the questionnaire in the Fire Arrow Web UI.
  2. The practitioner creates a reusable PlanDefinition that points to that questionnaire and defines the repeat timing.
  3. The organization applies that plan to a patient, creating a patient-specific CarePlan.
  4. Fire Arrow’s CarePlan event engine materializes scheduled occurrences into Task resources within a rolling future horizon.
  5. When a Task becomes due, Fire Arrow transitions it and emits a webhook notification.
  6. The patient-facing application retrieves the due Task, renders the linked questionnaire, and submits a QuestionnaireResponse.
  7. The application or patient flow marks the Task as completed.
  8. Practitioners review completed responses and trends over time.
  9. A separate subscription can watch for new QuestionnaireResponse resources and pass them into threshold-evaluation logic for alerting.
  10. Throughout the flow, Fire Arrow authenticates the caller, resolves identity to a FHIR resource, applies authorization rules, narrows search results, and optionally filters fields where appropriate.

5.2 Why this architecture matters

The key difference from a custom reminder stack is that the clinical definition, the patient-specific schedule, and the operational Task stream stay connected. The questionnaire is not treated as a detached frontend artifact. The workflow stays rooted in FHIR resources, and access control is enforced before data reaches user interfaces or automation services.

The frontend reduces to a thin layer: render the questionnaire, submit the response, display due Tasks. The backend handles the protocol semantics, scheduling, delivery events, data storage, and access control.

6. Core FHIR Building Blocks

6.1 Questionnaire: the form definition

Questionnaire defines the instrument itself: questions, answer options, item types, and scoring-related structure. Standardized instruments such as PHQ-9 can be imported directly from LOINC through the built-in questionnaire tooling, preserving published codes and answer lists. When no standard instrument exists, teams can build a custom questionnaire in the same UI. Either way, the result is a FHIR Questionnaire from the start, not a proprietary form definition that requires conversion when the data needs to move to another system.

6.2 PlanDefinition: the reusable surveillance protocol

PlanDefinition fits when the same surveillance logic applies to many patients. In the PHQ-9 example, the organization defines the schedule once and then uses $apply to generate patient-specific execution plans. The protocol is a versioned FHIR resource, not application code. Changing the frequency, the instrument, or the duration is a data change, not a code deployment.

6.3 CarePlan: the patient-specific schedule

CarePlan represents the individualized protocol instance for one patient. It is the statement that this patient should complete this questionnaire on this recurring timeline. The generated CarePlan connects the reusable protocol to operational execution for one patient. Every scheduled occurrence and every completed response traces back to this CarePlan and its source PlanDefinition.

6.4 Task: the operational occurrence

Task is where scheduled intention becomes actionable work. Fire Arrow materializes individual Task resources for future questionnaire administrations and transitions them when they become due. Each Task links back to its source activity in the CarePlan, providing full traceability for every individual piece of work. Patient-facing apps, reminder systems, and operational dashboards react to specific Task occurrences rather than re-computing schedules themselves.

6.5 QuestionnaireResponse: the completed form

QuestionnaireResponse stores the patient’s completed answers in FHIR format. Where the questionnaire defines scoring, the response can also carry the calculated result. These responses appear on the clinical timeline, where teams can review progress over time. Because the format is FHIR, the data can be fed to other systems (EHRs, study databases, analytics platforms) without a manual export or conversion step.

6.6 Subscription: the event bridge

Subscription connects the server to the organization’s delivery and escalation layer. One subscription pattern handles due questionnaire Tasks. Another can handle completed questionnaire responses that need threshold evaluation. Reminder delivery and alert handling stay observable and separate from each other.

7. Authoring the Workflow in Fire Arrow

The core workflow can be authored directly in the Fire Arrow Web UI.

7.1 Import or create the questionnaire

Fire Arrow’s Questionnaire Builder imports instruments from the LOINC Clinical Tables Search Service. The practitioner opens Tools > Questionnaires, selects Import from LOINC, searches for PHQ-9, and imports the “PHQ-9 quick depression assessment panel” (LOINC 44249-1). Fire Arrow creates the draft questionnaire with the imported item structure and answer options.

The LOINC import replaces the manual transcription step where a clinical team recreates an instrument in a form builder or spreadsheet and then converts it to whatever format the backend expects. The imported questionnaire is already a FHIR resource with the correct LOINC codes. Where no standard form exists, the same builder can create a custom instrument, which is also stored as a FHIR Questionnaire from the start.

7.2 Publish the questionnaire as an active canonical artifact

Before a questionnaire can be referenced by a protocol, it needs an active status and a canonical URL. The protocol should point to a stable definition, not to an ad hoc local draft.

7.3 Define the protocol in the PlanDefinition editor

The next step is to create a PlanDefinition in Tools > Plan Definitions. In the PHQ-9 example, the plan is titled “Depression Monitoring - PHQ-9 Biweekly,” typed as a clinical protocol, linked to the questionnaire through definitionCanonical, and configured with a repeating timingTiming pattern of once every two weeks for six months.

In conventional implementations, this monitoring logic lives in application code: a cron schedule, a configuration file, or hardcoded intervals in a backend service. A protocol change requires a developer, a code change, and a redeployment. With a PlanDefinition, the protocol is data. A clinician or administrator can update the frequency, the instrument, or the duration without touching code.

7.4 Apply the protocol to the patient

The protocol is applied to a specific patient via $apply, which generates a patient-specific CarePlan. Three parameters matter here:

  • subject to identify the patient,
  • _persist=true to save the result,
  • _startDate and _timezone to anchor the schedule correctly.

The timezone is important. Without it, Tasks can still be created, but they will not automatically transition at the correct local time for due-event notifications.

7.5 Activate materialization and due-event notifications

The $subscribe-due-events operation on CarePlan handles this in a single call. It adds the scheduling opt-in tag to the CarePlan, creates the corresponding subscription, and triggers initial Task materialization within the configured horizon.

The same action is also available in the Web UI through the Care Plan editor’s materialization flow.

8. Scheduling and Task Materialization

8.1 How Task materialization works

Fire Arrow’s CarePlan event engine automatically schedules CarePlan activities into Task resources and notifies the application when those Tasks become due. The engine does three things:

  1. materializes CarePlan activities into individual Task resources up to a configurable time horizon,
  2. transitions Tasks to ready status when they become due,
  3. notifies the application via webhooks when Tasks are ready.

The CarePlan event engine replaces the custom cron jobs and background workers that conventional implementations require for scheduling. Timezone handling, DST transitions, deadline logic, and recurrence computation that would otherwise need to be built and maintained by the development team are handled by the server.

8.2 The scheduling horizon is explicit

Fire Arrow does not generate every future Task for the full lifetime of a protocol at once. Instead, it maintains a rolling horizon (default 30 days) and continues materializing occurrences as time advances. The configuration exposes horizon-duration and check-interval under fire-arrow.careplan-events.scheduling, plus max-occurrences-per-activity to cap how many Tasks exist at once.

Bounded Task generation keeps the system predictable and avoids accumulating large numbers of far-future Tasks that may never be needed.

8.3 Timezone handling is not optional

If _timezone is omitted during $apply, Tasks may still be created but will not automatically transition from requested to ready at the correct local time. For recurring patient communication workflows, correct wall-clock timing is a core requirement. Fire Arrow resolves the timezone from the CarePlan extension (set during $apply) or from the Patient resource, and applies DST-aware scheduling.

Timezone and DST bugs are a common source of errors in custom scheduler implementations. They are handled once in the server rather than re-implemented per application.

8.4 Due-event notifications are per CarePlan instance

The $subscribe-due-events operation creates a properly configured subscription for a specific CarePlan. The organization can treat the patient-specific plan as the scope for reminder delivery without having to handcraft the corresponding subscription resource every time.

8.5 Delivery is decoupled from the target system

Task materialization is completely independent of how the patient is reached. When a Task becomes due, Fire Arrow emits a webhook notification. The downstream consumer can be a mobile app sending push notifications, a web dashboard, a call center system, or a messaging integration (WhatsApp, SMS, email). Any system that can receive a webhook or poll for due Tasks can participate.

The decoupling means the same backend serves different delivery channels without changes to the protocol, the scheduling, or the data model. Adding a new channel is a new webhook consumer, not a new backend.

9. Tracking, Completion, and Data Format

9.1 The patient completes the questionnaire through the app

When a Task becomes due, the patient app receives the webhook, fetches the Task, and presents the linked questionnaire form. The patient then submits a QuestionnaireResponse.

9.2 Task completion remains explicit

After questionnaire submission, the Task is marked completed. This keeps operational completion state separate from form content while still linking both back to the same patient-specific surveillance plan. Every completed (or missed) Task traces to its source activity in the CarePlan, giving a full operational audit trail.

Practitioners can open the patient’s clinical data view and see QuestionnaireResponse resources on the clinical timeline, including completion date and score where scoring is defined. Over time, the care team gets a trend line rather than a set of disconnected form submissions. Longitudinal change is visible in the same clinical context where the rest of the patient’s data lives, reducing the need for custom dashboards or separate reporting software.

9.4 Data is in FHIR format from the start

All questionnaire data (definitions, schedules, tasks, responses) is stored as FHIR resources. There is no proprietary intermediate format and no manual export or conversion step when the data needs to reach another system.

FHIR-capable systems (EHRs, study databases, analytics platforms, registries) can consume the data directly via the FHIR API. Systems that are not FHIR-native still receive data in an open, fully specified format rather than a custom schema that requires bespoke mapping. The data is also portable: it is not locked to Fire Arrow or to the application that collected it.

10. Alerting and Escalation Patterns

10.1 Reminders and alerts are separate concerns

A due questionnaire reminder is driven by Task state. A clinical alert is driven by response content. The two are handled separately:

  • Task subscriptions and $subscribe-due-events handle reminders for work that has become due.
  • A standard Subscription on QuestionnaireResponse handles score-based evaluation after submission.

Schedule orchestration and clinical escalation stay decoupled.

10.2 Response-based alerting

The PHQ-9 example creates a Subscription with criteria on QuestionnaireResponse for the relevant questionnaire canonical URL. The webhook handler fetches the submitted response, calculates the total score, and triggers an alert if the score crosses a threshold.

The example demonstrates two bands:

  • a critical threshold at PHQ-9 score 20 or above,
  • a moderate-severe threshold at 15 or above.

The specific threshold values are less important than the pattern. The subscription acts as a structured event boundary: the organization’s escalation logic runs in its own webhook handler, without depending on polling or custom database triggers.

Where automated scoring is needed, the FHIR Clinical Quality Language (CQL) infrastructure can be used for evaluation and post-processing, keeping scoring logic standardized and separate from application code.

10.3 Why threshold evaluation often belongs outside the FHIR server

Different organizations will have different rules for what happens next:

  • send an in-app message,
  • create a clinician task,
  • notify a call center or care coordinator,
  • escalate to a practitioner dashboard,
  • require a same-day review.

By using subscriptions and webhooks, the clinical event stream stays standardized while the downstream response policy remains configurable per organization.

10.4 Controlled write-back can be introduced later

Some deployments may later choose to write alert outcomes back into FHIR as Task, Flag, CommunicationRequest, or other resources. That can be appropriate, but it should be treated as a deliberate design step, not as a default shortcut.

11. Security and Authorization Model

The workflow only remains safe if scheduling, completion, and alerting stay under strong access control. In Fire Arrow, authentication and authorization are part of the server. They do not need to be designed and implemented as a separate project.

11.1 Authentication resolves callers to FHIR identities

Fire Arrow authenticates requests using JWTs through OAuth 2.0 / OIDC or API tokens. After token validation, it resolves the caller’s identity to a FHIR resource using identifier lookup, email fallback, and optional auto-create. The resolved identity is always represented as one of the FHIR identity resource types such as Patient, Practitioner, RelatedPerson, or Device.

Patients, practitioners, and automation services can all participate in the same backend model without inventing a parallel authorization layer.

11.2 Authorization is rule-based and deny-by-default

Fire Arrow’s authorization pipeline authenticates the request, resolves identity, builds the matching rule set, checks blocked parameters, narrows searches, and validates the result. The recommended default validator is Forbidden, which follows least privilege: access is granted intentionally rather than assumed.

11.3 Patient and practitioner access stay cleanly separated

The questionnaire surveillance workflow includes a concrete authorization split:

  • patients can read and search their own CarePlan, Task, and QuestionnaireResponse resources and create their own responses,
  • practitioners can manage Questionnaire and PlanDefinition, read and search relevant CarePlan, Task, and QuestionnaireResponse resources, and create subscriptions.

The recommended practitioner validator is LegitimateInterest, which scopes access to patients where an active PractitionerRole exists within the managing organization. Patient-scoped access uses PatientCompartment.

11.4 Search narrowing matters for safe workflow views

When a client performs a search, Fire Arrow narrows the query itself so the database returns only resources the client is allowed to see, rather than filtering results after retrieval.

For questionnaire workflows, search narrowing applies whenever the patient app searches for outstanding Tasks, or a practitioner searches for questionnaire responses across their patient population.

11.5 Identity filters and property filters provide additional control tiers

Identity filters let rules apply only to subsets of users within a role, based on FHIRPath conditions evaluated against the identity resource. Property filters let Fire Arrow redact or randomize selected fields after authorization succeeds.

These features need to be used deliberately. Response-time redaction does not automatically close search-based side channels. The safest pattern for filtered access is often read by ID rather than broad search, or a carefully restricted GraphQL read pattern where references are resolved by ID.

Some deployments may later want blinded or sponsor-facing views of responses. The building blocks for that exist, but the authorization surface still needs careful design.

11.6 Services should stay narrowly scoped

Webhook consumers and alert evaluators usually do not need broad access. They should use narrowly scoped service identities that can read exactly the Task or QuestionnaireResponse resources required for their function and nothing more.

The correct pattern is not “automation superuser.” The correct pattern is a service identity with only the exact resource and operation permissions needed for a defined step in the workflow.

12. Operational Considerations

12.1 Horizon and check interval

Task materialization is controlled by horizon-duration (default P30D) and check-interval (default PT1H). These should be chosen based on operational needs: how far ahead the application wants upcoming work instantiated, and how frequently the server should check for new materializations.

The due-task transition job runs separately on a shorter interval (default PT1M), checking whether materialized Tasks have reached their start time and should move to ready status.

12.2 Subscription lifetime

CarePlan event subscriptions require an end date, and Fire Arrow enforces a maximum TTL (configurable via subscriptions.max-ttl). This prevents forgotten subscriptions from accumulating indefinitely. Subscriptions that exceed the TTL can be rejected or truncated depending on the excess-end-action setting.

$renew-due-events extends an active subscription without rebuilding it, and $unsubscribe-due-events handles clean teardown.

12.3 Webhook delivery is part of the real system

A reminder or alert pipeline is only as reliable as its delivery behavior. Fire Arrow tracks consecutive delivery failures per subscription and can disable subscriptions after a configurable threshold (delivery.max-consecutive-failures) or after a duration without any successful delivery (delivery.disable-after-no-success). Teams should still design webhook endpoints to be idempotent, monitored, and able to handle transient failures safely.

12.4 Scaling to many patients

The $apply operation can be called programmatically for each eligible patient, applying the same PlanDefinition across a population. The intended scaling model is: define the protocol once, then roll it out repeatedly rather than manually rebuilding patient schedules.

In multi-node deployments, Fire Arrow uses distributed locking (JDBC-based) for CarePlan materialization and subscription processing, so that Task creation and due-event transitions remain consistent under concurrent execution.

12.5 Auditability and observability

Because the workflow is modeled through FHIR resources and subscriptions, teams can inspect the state directly:

  • which protocol exists,
  • which patient-specific CarePlans were created,
  • which Tasks have been materialized,
  • which Tasks are due or completed,
  • which QuestionnaireResponses were submitted,
  • which subscriptions feed reminder and alert endpoints.

The resource-based model makes workflow state directly inspectable rather than hidden in background jobs and custom tables.

13. Example Deployment Patterns

13.1 Depression monitoring

PHQ-9 every two weeks for depression follow-up. Fire Arrow’s questionnaire surveillance guide covers this end-to-end: LOINC import, protocol definition, due reminders, trend review, and threshold-based escalation.

13.2 Cardiology symptom surveillance

Monthly KCCQ-12 administration where worsening scores trigger follow-up review or appointment scheduling. The same PlanDefinition and CarePlan pattern applies with different timing and a different questionnaire instrument.

13.3 Post-surgical recovery tracking

Questionnaires at fixed milestones such as 2, 6, and 12 weeks after an operation. The PlanDefinition timing can use event-based offsets rather than repeating intervals, anchoring each occurrence to the procedure date.

13.4 Clinical studies and remote monitoring

Study workflows where questionnaire schedules must be standardized, execution must be auditable, and downstream access may differ between operational staff, investigators, and sponsors. Property filters and identity filters can restrict views by role without rebuilding the core workflow.

14. Conclusion

A recurring questionnaire program should not be implemented as a fragile mix of frontend forms, timer jobs, and sidecar scripts. It should be implemented as a governed workflow.

Questionnaire surveillance is often underestimated. Teams think they are building forms and reminders. They are building a longitudinal clinical workflow with recurring operational events, patient-facing interactions, completion tracking, and risk-based escalation. That workflow needs proper backend support.

In Fire Arrow, the workflow maps to FHIR-native building blocks:

  • the instrument is a real Questionnaire, imported from LOINC or built in the UI,
  • the protocol is a reusable PlanDefinition that can change without code deployments,
  • the patient schedule is a CarePlan with full traceability to its source protocol,
  • the operational occurrences are Task resources, each linked back to its source activity,
  • the completed forms are QuestionnaireResponse resources in an open, portable format,
  • the reminder and alert boundaries are Subscription-driven events, decoupled from any specific delivery channel,
  • authentication and authorization are part of the server, not a separate implementation.

The engineering effort reduces to a thin patient-facing frontend and any organization-specific escalation logic. The protocol definition, scheduling, timezone handling, task delivery, data storage, trend review, and access control come from the server. Data stays in FHIR format throughout, avoiding proprietary lock-in and manual conversion steps when it needs to reach other systems.

References

  1. Fire Arrow Docs: Patient Surveillance Questionnaires. https://docs.firearrow.io/docs/server/how-to/patient-surveillance-questionnaires

  2. Fire Arrow Docs: CarePlan Events. https://docs.firearrow.io/docs/server/careplan-events

  3. Fire Arrow Docs: Subscriptions. https://docs.firearrow.io/docs/server/subscriptions

  4. Fire Arrow Docs: Questionnaire Builder. https://docs.firearrow.io/docs/server/web-ui/questionnaires

  5. Fire Arrow Docs: PlanDefinition Editor. https://docs.firearrow.io/docs/server/web-ui/plandefinitions

  6. Fire Arrow Docs: Care Plans. https://docs.firearrow.io/docs/server/web-ui/careplans

  7. Fire Arrow Docs: Authorization Concepts. https://docs.firearrow.io/docs/server/authorization/concepts

  8. Fire Arrow Docs: Patient Compartment Validator. https://docs.firearrow.io/docs/server/authorization/validators/patient-compartment

  9. Fire Arrow Docs: Legitimate Interest Validator. https://docs.firearrow.io/docs/server/authorization/validators/legitimate-interest

  10. Fire Arrow Docs: Property Filters. https://docs.firearrow.io/docs/server/authorization/property-filters

  11. Fire Arrow Docs: Custom Operations. https://docs.firearrow.io/docs/server/fhir-rest/custom-operations

  12. Fire Arrow Docs: Configuration Reference. https://docs.firearrow.io/docs/server/configuration