Care Pathway Guide

What is a care pathway?

A care pathway is a structured plan that maps the expected steps of care for one condition or procedure, with entry criteria, timed actions, decision points and exit criteria. In software, a care pathway is a reusable definition that is applied to each enrolled patient to produce a personal care plan and the tasks behind it.

Pathways are also called clinical pathways or care maps. The name matters less than the structure: every step must say when it applies, who does it and what counts as done.

A pathway also defines when a patient leaves it: the goal is met, the patient moves to another pathway, or a clinician ends it. Without exit criteria, plans stay open and worklists fill with tasks for patients who no longer need them.

Care pathway, care plan and order set

Pathway, care plan, order set and guideline are often used as if they meant the same thing, but they sit at different levels. Getting the distinction right decides how the data model is built.

• Care pathway: A definition for a population. It describes the steps, rules and timing for every patient with the condition, and it changes only when the clinical committee revises it.
• Care plan: An instance for one patient. It records which pathway steps apply to this person, what has been done, what is due and any goals agreed with the patient.
• Order set: A group of orders signed together at one moment, such as an admission or a procedure. A pathway may call an order set as one of its steps.
• Clinical guideline: The evidence document the pathway is based on. It informs the pathway but is not executable on its own.

Software that stores pathways as care plan templates copied into each chart loses the link to the definition. When the pathway changes, nobody can tell which patients are on the old version.

How does FHIR model a pathway?

HL7 FHIR models the pathway definition with PlanDefinition and ActivityDefinition, and the patient's instance with CarePlan and related request resources. The definition and the instance stay linked by canonical URL.

• PlanDefinition: Describes groups and sequences of actions. FHIR R4 lists order-set, clinical-protocol, eca-rule and workflow-definition as its type codes. Each action can carry conditions that evaluate to true or false, triggers, timing and related actions such as before or after another step.
• ActivityDefinition: Defines one specific activity, such as a lab order, a referral or a patient questionnaire, so the same step can be reused across pathways.
• Library: Holds the formal logic a PlanDefinition references, so entry criteria and decision points are written once in a computable form rather than in code scattered across the application.
• $apply: The FHIR operation that applies a PlanDefinition to a context such as a patient. It typically produces request resources grouped in a CarePlan or RequestGroup.
• CarePlan: The patient-level plan. Its instantiatesCanonical element can point back to the PlanDefinition it came from, which keeps the version link.

Two more resources carry the daily work. Goal records targets agreed with the patient, such as a blood pressure range, and CarePlan.goal links them to the plan. Task assigns a step to a person or team with a status and a due date, so a care manager's worklist can be built from open Tasks rather than from plan text.

For computable guidelines, HL7 publishes the Clinical Practice Guidelines on FHIR (CPG-on-FHIR) implementation guide, version 2.0.0 (STU2). It defines profiles such as CPGPathwayDefinition, CPGStrategyDefinition and CPGRecommendationDefinition, and says content should use Clinical Quality Language (CQL) as described in the Using CQL With FHIR guide.

Not every EHR stores or runs PlanDefinition. Pathway products can keep the definitions in their own service and write the results into the EHR as orders, tasks or a US Core CarePlan.

How does a guideline become a pathway on the clinician's screen?

A guideline reaches the clinician's screen through six steps, and only two of them are coding. The rest is clinical agreement and testing.

• 1. Scope: The clinical committee picks one condition, the entry criteria and the outcome the pathway should change, and names an owner for the content.
• 2. Narrative pathway: Clinicians write the steps in plain language with timing, roles and exit criteria, and resolve local differences from the published guideline.
• 3. Structured definition: Engineers and informaticists turn the narrative into PlanDefinition actions and ActivityDefinitions, with each decision point written as logic in a Library.
• 4. Enrollment and apply: A rule or a clinician enrolls the patient, and the service applies the definition to create the CarePlan, tasks and draft orders.
• 5. Delivery in the workflow: Due steps appear where staff already work, such as an EHR worklist, a CDS Hooks card or a SMART on FHIR app, rather than in a separate portal.
• 6. Variance and review: Every skipped or changed step is recorded with a reason, and the committee reviews variances before the next version.

Steps 2 and 6 are the easiest to cut when deadlines slip, yet they are what make the pathway trusted enough to follow.

Which rules shape pathway software?

Pathway software that recommends care is decision support, so device, privacy and non-discrimination rules all apply. These are the provisions to check first.

• FDA: The final Clinical Decision Support Software guidance, issued 6 January 2026 and re-issued 29 January 2026, sets the criteria under which CDS for health care professionals is not a device. A pathway step that analyzes a medical image or a physiological signal falls outside that carve-out.
• Section 1557: Under 45 CFR 92.210, covered entities must not discriminate through patient care decision support tools, with compliance required from 1 May 2025. Entry criteria that use race, age or disability need review on that basis.
• HIPAA: Care plans and pathway tasks hold ePHI, so the HIPAA Security Rule safeguards in 45 CFR Part 164 Subpart C apply, including audit controls and unique user identification.
• HL7 FHIR: PlanDefinition is a Trial Use resource at maturity level 2 in FHIR R4, so expect differences between servers and test the exact behaviour of $apply on the target platform.

Where do pathway projects stall?

Pathway projects stall where clinical content and software meet, not in the code itself. This failure-point list covers the gaps that block go-live or adoption.

• No content owner: Nobody is named to approve changes, so the pathway in software drifts from what clinicians actually do.
• Logic hidden in code: Entry criteria are hard-coded in the application, so a committee change needs a release instead of a content update.
• Copied templates: Each patient's plan is a copy with no version link, so a revised pathway cannot be rolled out to patients already enrolled.
• Separate portal: Due steps live in a tool staff must log into separately, and the tasks are ignored during a busy clinic.
• Missing data at entry: Enrollment rules depend on coded diagnoses or results that may sit as free text in the chart, so eligible patients are never enrolled.
• No variance capture: Clinicians skip steps for good reasons, but the reason is never recorded, so the committee cannot tell a bad step from a bad fit.
• Overlapping pathways: A patient with several conditions is enrolled in two pathways that schedule the same test or give conflicting advice.

Most of these are design decisions rather than defects. They cost less to settle in the definition model than to patch after clinicians depend on the tool.

What to decide before the first pathway goes live

Decide where definitions live and how patients enter and leave a pathway before building screens. This decision list keeps the first release small and the second one possible.

• Definition store: Keep pathways in a FHIR server as PlanDefinitions, or in the application's own model with an export path to FHIR.
• Logic language: Write decision points in CQL, a rules engine or code, and agree who can edit them.
• Enrollment: Choose automatic rules, clinician enrollment or both, and define how a patient exits.
• Delivery channel: Pick the EHR worklist, CDS Hooks, a SMART on FHIR app or a care manager console for each role.
• Write-back: Decide which results go back to the EHR as orders, tasks, notes or a CarePlan, and through which interface.
• Versioning: Define what happens to enrolled patients when a pathway changes: stay, migrate or review case by case.
• Measures: Pick two or three process and outcome measures the committee will review at each version.

Write these decisions down on one page per pathway. That page becomes the acceptance criteria for the first release and the start of the change log for every version after it.

How Agnotic can help

Pathway software works when clinical content, logic and the EHR workflow are designed together. Agnotic Technologies builds care management software for health systems and digital health companies, including pathway definition stores, rules, care plans, task lists and the EHR integration that puts due steps in front of staff.

Agnotic models pathways as PlanDefinitions or in a client's own schema with a FHIR export, writes decision logic that the clinical team can review, and delivers steps through worklists, CDS Hooks or SMART on FHIR apps, with variance capture built in from the first release.

Sources

• HL7 FHIR R4: PlanDefinition
• HL7 FHIR R4: CarePlan
• HL7: Clinical Practice Guidelines on FHIR (CPG-on-FHIR) 2.0.0
• HL7 US Core: CarePlan profile
• FDA: Clinical Decision Support Software guidance
• 45 CFR 92.210: Patient care decision support tools
• 45 CFR Part 164 Subpart C: HIPAA Security Rule