Clinical Decision Support and Follow-Through

A recommendation is useful only if it reaches someone who can act on it. Sometimes a link in the chart is enough. Sometimes the recommendation needs an owner and follow-up that will still be there when the chart is closed.

Clinical decision support (CDS) can provide reference material, rule-based recommendations, or predictive results. This guide covers how to bring that guidance into a care workflow and track the work it creates.

Meet the Clinician Where the Decision Happens​

Use CDS Hooks for the discovery, request, prefetch, and card contract. Use SMART App Launch when launching an external application. These integration choices do not determine the clinical approval policy.

Show the Guidance and Its Evidence​

For a Medplum-hosted CDS Hooks service, configure the Bot's cdsService hook and prefetch requirements. The client invokes the service at the intended workflow point and displays returned cards. It must implement the user interaction for suggestions and proposed actions.

Display the guidance source and relevant evidence. Handle unavailable services and incomplete context explicitly. A failure can create a manual review obligation when the clinical workflow requires one; it should not silently appear as a successful evaluation with no recommendations.

Turn Recommendations into Review Tasks​

For recommendations that need follow-through, give the reviewer a work item that survives closing the chart:

  flowchart TD
  guidance[Recommendation requiring review] --> task[Assigned review Task]
  task --> decision{Reviewer decision}
  decision -->|Accept| request[Persist authorized request]
  request --> followup[Track fulfillment separately]
  decision -->|Decline| reason[Record disposition and rationale]
  decision -->|Defer| later[Record decision and arrange later review]

Use a review Task when a recommendation requires acknowledgment, ownership, or follow-up across sessions. Populate for, an accountable owner or required performerType, and the relevant evidence in focus or input. Use a stable identifier derived from the rule and triggering event or review period so repeated evaluations do not create duplicate open work.

Record the decision in a governed local businessStatus, with an authored, timestamped rationale in note and any resulting clinical request in output. A completed review Task means review is finished. The recommendation may have been accepted, declined, or deferred according to the workflow; its clinical service is not thereby complete.

If accepted guidance leads to a referral, use a ServiceRequest and fulfillment Tasks as described in Referrals. If it changes a treatment plan, update the CarePlan through the clinical review path. Preserve patient references on every resulting resource.

Keep Evaluation Records When You Need Them​

Suppose a rule runs ten times during a week, but only one result needs review. One review Task may cover the work. Retaining all ten evaluations is a separate requirement. Some applications also need the inputs, rule/model version, evaluation result, and disposition for informational results that never create a Task.

FHIR R4 GuidanceResponse is a candidate for the evaluation result: it can identify the evaluated module, patient, occurrence time, output Parameters, and a resulting CarePlan or RequestGroup. Its status describes evaluation success or failure, not clinician acceptance. A CDS Hooks card does not automatically map to GuidanceResponse, and Medplum's CDS Hooks endpoint does not establish that persistence model for you.

Check Whether Guidance Leads to Follow-Through​

Track who maintains the rules, how versions are introduced, when repeat review is warranted, and how to recover missed work. Measure actionable reviews, accepted and declined recommendations, follow-up completion, and alert burden with clear denominators. Clinical outcomes need separate evidence.

Apply Access Policies to the service context and stored outputs.

Understand the Certification Context​

Medplum's ONC certification documentation lists the certified product and criteria, including (b)(11) Decision Support Interventions. Use that page and its linked product listing for certification scope. Building a CDS workflow on Medplum still requires evaluating the particular application, intervention, and use case.

Under HTI-1, the (b)(11) criterion replaced the legacy (a)(9) CDS criterion. The ONC Decision Support Interventions guidance describes evidence-based and predictive interventions, source information, feedback, and applicable risk-management requirements. Treat the Insights Condition as a separate reporting topic with its own applicability and measures; operational Task counts alone do not establish that reporting model.

For context-aware reference links, HL7 Infobutton is another integration option. Choose the interaction that fits the clinician's workflow, then confirm the requirements for the product being delivered.

See Automating Care Workflows for event handling and Operational Reporting for transitions and measures.