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.
| # | 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" |
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.
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.
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.
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.
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.
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.
Clinical decisions come from decision tables running in a rules engine, not from a language model guessing.
People sit at both gates. An expert approves what the system learned; a clinician approves what it proposes.
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.
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.
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.
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.
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.
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.
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.
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.
Four application components plus shared platform services. Each sits behind a standard interface.
| Directory | Purpose | Built 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. | – |
A high-level tour of the parts and concepts in the project, not an in-depth treatment. Open the full playlist.
PART 1Overview: goals and parts of the project
PART 2CPG: Clinical Practice Guidelines
PART 3DMN: Decision Model and Notation
PART 4Recommendations: modeling the narrative
PART 5FHIR: Fast Healthcare Interoperability Resources
PART 6Care Plan: what an ACP contains
PART 7BPMN: Business Process Model and Notation
PART 8UI: the interfaces the system needs
PART 9Future: where the project is headed
PART 10Code: a tour of the project structure
These videos were shot at a point in time; the project may have changed since. The repository is the source of truth.
dev_docs/. Point-in-time references.
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.
platform/litellm/deploy/.env.example and add your OpenAI key.podman-compose up -d (Kogito, ACP Writer, MLflow).Full walkthrough in the README. Every step is traced in MLflow when running locally.
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# 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.jsonNAMESPACE=my-carewright ./deploy/install.shLatest version Drools/Kogito supports at conformance level 3. Namespace DMN/20191111/MODEL. Moves to 1.5 when Kogito does.
Via the Medplum FHIR server. IPS bundles in; CarePlan, Provenance and AI-transparency resources out.
The contract between acp-writer and automation. Phase 4 of the project plan.