For providers, payers, and quality regulators

Guidelines to quality care plans.

Clinical practice guidelines, payer coverage policies, and quality requirements all describe what good care looks like, and all of them were written to be read, not run. Carewright reads them, drafts a care plan for a specific patient, and puts a clinician in charge of approving it. Every line in the plan traces back to the guideline or policy it came from.

Built by Red Hat. Runs on Red Hat OpenShift AI in your environment. Apache 2.0 licensed.

Decision table · Hypertension pathwayextracted from the guideline
# Systolic Diastolic T2DM Pathway
1< 130< 80-"monitor"
2[130..140)[80..90)false"lifestyle"
3[130..140)[80..90)true"medication"
4>= 140--"medication"
5->= 90-"medication"
inputs from the patient recordoutput → care planruns the same way every time

Illustrative. The crisp parts of a guideline become tables like this one: an informaticist checks them against the source text, and a rules engine runs them the same way every time.

The problem

The best knowledge in medicine is locked in PDFs.

A clinical practice guideline can run hundreds of pages. A patient with three chronic conditions has three of them, and none of the three knows the other two exist. Reconciling them for this patient, in a fifteen-minute visit, is work that happens in the clinician's head.

The same is true of a hospital's own protocols, a payer's coverage policies, and a quality program's measures. All of it was written for people to read. None of it was written for a computer to act on.

How it works

Carewright does the reading. People make the decisions.

Source documents are read by AI, reviewed by an informaticist, and stored as decision tables, recommendations and processes. The patient's record and that knowledge feed a drafting engine. A clinician reviews and approves the draft, it is written to the EHR as a FHIR CarePlan, and reviewers later audit the plan against the care delivered. KNOWLEDGE read once, reviewed once PATIENT fresh for every plan CARE PLAN approved by a clinician Source documents Clinical practice guidelines, your protocols, payer policy Read AI extracts rules, judgment and workflows from the text Review An informaticist checks it against the source text PEOPLE DECIDE KNOWLEDGE BASE Decision tables Recommendations Processes Patient record Read from the EHR in FHIR, when a plan is asked for Draft A rules engine runs the decision tables against the record, matching recommendations are gathered, and conflicts between sources are flagged draft plan Approve The clinician edits, declines, and approves the plan PEOPLE DECIDE In the EHR A FHIR CarePlan, labeled AI-assisted, clinician-verified Audit Reviewers compare the plan with the care delivered later, for quality the system a person decides documents and records the result

Read

AI reads the authoritative document and pulls out three kinds of knowledge. The crisp parts ("if blood pressure is above this threshold and the patient has diabetes, then…") become decision tables a computer can run the same way every time. The judgment and context become recommendations in a knowledge base. Workflows become business processes.

Review

An informaticist checks the extracted tables and recommendations against the source text, side by side, and approves them. Nothing is published without that sign-off.

Draft

At the right time, the system takes the patient's record (in FHIR, the standard language of health data), runs the decision tables in a rules engine, gathers the matching recommendations, and drafts a care plan with goals and activities. Where two or more sources overlap or disagree, it flags the conflict instead of quietly picking one.

Approve

The clinician reviews the draft, changes what they want, declines what they don't, and approves. The plan lands in the patient's record as a standard FHIR CarePlan, labeled as AI-assisted and clinician-verified.

Design choice 1

Clinical decisions come from decision tables running in a rules engine, not from a language model guessing.

Design choice 2

People sit at both gates. An expert approves what the system learned; a clinician approves what it proposes.

Why "actionable"

Most care plans are documentation. Ours is built to do work.

The plan carries process definitions alongside its goals and activities, so the routine parts (ordering the labs, scheduling the follow-up, enrolling the patient in a program) can be handed to automation.

Executing those processes is the next stage of the project, and it is where we most want partners at the table.

Where it stands

A working prototype, not a product.

It runs end to end today on Red Hat OpenShift AI: guideline in, reviewed knowledge out, patient record in, approved plan into the EHR, with the AI agents sandboxed and every step traced. An earlier version was shown at HIMSS 2026.

It is built on open standards (FHIR, DMN, BPMN) so any piece can be swapped, and the code is public. What comes next will be shaped by the people who build it with us.

From where you sit

The questions we hear first

"Isn't this what OpenEvidence or UpToDate already does?"

Those tools are very good at answering "what does the evidence say?" when a clinician asks. This is a different job, in two ways.

It knows your organization. A reference tool gives the same answer in every hospital. This system ingests your own protocols alongside the published guidelines: your formulary, your referral pathways, which imaging you can do in house, how your clinics like to follow up. The plan it drafts is your organization's plan, not a generic one.

It produces something that does work. A reference tool gives you a paragraph to read and then re-type as orders. This gives you a plan in the patient's record, with activities detailed enough to drive orders, follow-ups, and outreach. Reference tools stay useful for reading. This is the layer that turns evidence and your own policies into the plan.

"Will it actually help, or is this another pop-up?"

It doesn't pop up. It drafts a plan when you ask for one, for the patient you're seeing, with all of that patient's guidelines considered at once. The tighter blood pressure target because of the kidney disease. The metformin note because of the eGFR. The follow-up interval your own protocol calls for. Click any activity and you see the sentence in the guideline it came from. Where two sources disagree, you see that too, with the reasoning, and you decide.

The gap between what guidelines recommend and what patients actually receive is well documented. The problem was never that clinicians don't know the guidance. It's that reconciling six hundred pages per patient doesn't fit in the visit. This is meant to give that time back to the patient.

"Is it going to decide for me?"

No, and it's built so it can't. Decisions come from reviewed decision tables in a rules engine, not from a language model's opinion. Nothing reaches a patient's record without a clinician approving it, and the record carries that approval, following the HL7 AI Transparency on FHIR standard. The system drafts. You decide. The plan is yours, and the record says so.

"Is it going to work in our environment?"

It runs on Red Hat OpenShift AI in your environment, on premises or in your cloud, with your choice of models, including models that never leave your walls. Patient data is not sent to a vendor.

Each AI agent runs in a kernel-level sandbox with a strict allow list, so the piece that talks to the language model physically cannot reach the patient record, and the piece that reads the record cannot reach the model. Every connection is logged. The clinician's view opens inside the EHR through SMART on FHIR, so there is no second login and no second system to live in.

What it would take from you

We're looking for a provider organization to be a development partner.

That means a modest amount of informaticist time to review what the system extracts from real guidelines and your own protocols, clinicians willing to put drafts in front of real or realistic cases and tell us what's wrong, and a seat at the table for what automation should look like.

We bring the engineers, the platform, and an open source project you can see all of. You would be shaping a tool that knows how your organization practices medicine, rather than buying one that doesn't.

For engineers

How it is built

Everything below is for the people who will run, extend, or contribute to the system. Open standards at each boundary: DMN for decision logic, FHIR for patient data and the care plan, BPMN for the processes. Any runtime can be swapped without changing the components next to it.

Components

What's in the repository

Four application components plus shared platform services. Each sits behind a standard interface.

DirectoryPurposeBuilt with
cpg-ingester/Parses CPG documents and produces DMN decision tables plus recommendations for the acp-writer's vector store. Includes an upload, progress and human-in-the-loop review UI, and a FastAPI BFF between the UI and SonataFlow/MinIO.Docling · PatternFly 6 · React 19 · FastAPI
acp-writer/Composes patient-specific care plans by invoking DMN decision services, retrieving recommendations and integrating FHIR patient data. Outputs FHIR CarePlans and BPMN. Includes the clinician review UI.Drools/Kogito · SMART on FHIR
automation/Executes BPMN process definitions produced by the acp-writer. The runtime is pluggable.Ansible · SonataFlow
mock-EHR/Mock EHR for development and demos, with a clinical-facing "CareView EHR" UI and an IPS Viewer SMART app.Medplum · FHIR R4 · OAuth
platform/Shared infrastructure services consumed by multiple components. Platform capabilities on OpenShift AI; local equivalents for dev.MaaS · MLflow · LiteLLM
shared/Shared contracts and utilities, used sparingly to prevent coupling.Python
deploy/Helm charts per component and the OpenShift install script.Helm · OpenShift
docs/User-facing documentation: architecture, security, deployment guides.–
dev_docs/Internal design docs, spikes and the project plan. Point-in-time references.–
Introduction series

Ten short videos, one idea each

A high-level tour of the parts and concepts in the project, not an in-depth treatment. Open the full playlist.

These videos were shot at a point in time; the project may have changed since. The repository is the source of truth.

Documentation

Design documentation

Getting started

Run the whole pipeline locally

CPG PDF, parse, extract DMN, deploy decisions, generate a care plan. The repo ships a synthetic hypertension guideline and two patient bundles so you can see both pathways.

  1. Configure credentials: copy platform/litellm/deploy/.env.example and add your OpenAI key.
  2. Start infrastructure with podman-compose up -d (Kogito, ACP Writer, MLflow).
  3. Parse the CPG with Docling.
  4. Extract DMN tables and deploy them to acp-writer.
  5. Register the CPG so the guideline resolver can match patient conditions.
  6. Post a FHIR patient bundle and get a CarePlan back.
Prerequisites Podman (preferred) or Docker with compose Python 3.11+ OpenAI API key for LLM-driven extraction

Full walkthrough in the README. Every step is traced in MLflow when running locally.

Parse and extract
cd cpg-ingester
python3 -m venv .venv && source .venv/bin/activate
pip install -e . -e ../shared

cpg-parse data/synthetic-hypertension-cpg.pdf -o output
cpg-extract-dmn output/synthetic-hypertension-cpg.md -o output \
  --deploy --acp-writer-url http://localhost:8082
Generate a care plan
# Hypertension + diabetes → medication path
curl -X POST http://localhost:8082/api/v1/careplans \
  -H "Content-Type: application/fhir+json" \
  -d @mock-EHR/data/patient-bundle-medication.json

# Mild hypertension only → lifestyle path
curl -X POST http://localhost:8082/api/v1/careplans \
  -H "Content-Type: application/fhir+json" \
  -d @mock-EHR/data/patient-bundle-lifestyle.json
Or deploy to OpenShift
NAMESPACE=my-carewright ./deploy/install.sh
Standards versions

Pinned on purpose

DMN 1.4

Latest version Drools/Kogito supports at conformance level 3. Namespace DMN/20191111/MODEL. Moves to 1.5 when Kogito does.

FHIR R4

Via the Medplum FHIR server. IPS bundles in; CarePlan, Provenance and AI-transparency resources out.

BPMN 2.0

The contract between acp-writer and automation. Phase 4 of the project plan.