Quality leaders with a vendor bill
Stop paying $300–$4,000 per provider, per year for calculation you can run in-house. Compute eCQMs against your own FHIR data and see the population counts — and the patients — behind every result.
Patient data never leaves your organization
Lenny is a free, open-source orchestration layer between your FHIR data and a standards-compliant measure engine. Point it at your data, run the measure, and get population counts and per-patient results your team can read — no vendor required.
Open source · DEQM-aligned
Lenny is a free utility for calculating FHIR-based digital quality measures. Upload a Measure bundle, pick a period, click Calculate — and get population counts plus per-patient drill-down with the resources that drove every result.
Vendor-neutral · FHIR-native
Lenny sits in the middle of the DEQM workflow — pulling patients from your clinical data repository, handing them to a measure calculation service, and turning the report into something you can actually inspect.
Why Lenny
If you’re an ACO or health system paying per-provider fees for measure calculation, Lenny turns a pure cost center into capability you own — compute, validate, and inspect digital quality measures against your own FHIR data, no vendor stack required.
Stop paying $300–$4,000 per provider, per year for calculation you can run in-house. Compute eCQMs against your own FHIR data and see the population counts — and the patients — behind every result.
Run calculations without waiting on a vendor ticket queue. Plain-language, per-patient output you can interpret without an engineer in the room.
A free, FHIR-native engine you control and can stand up across provider networks — a vendor-neutral foundation to build your own delivery workflows on.
What you can do
Upload a Measure bundle, pick a measurement period, optionally filter by FHIR Group, click Calculate. Lenny pulls patients from your CDR, evaluates the measure on a HAPI-based engine, and stores the results.
Aggregate population counts — initial population, denominator, numerator, exclusions, and the derived performance rate — with per-patient drill-down that shows the resources that drove each result.
Upload a test bundle that declares expected population membership; Lenny re-runs the measure per patient and reports pass/fail. Built for data validation and certification workflows. (Opt-in via Settings.)
Configure several clinical data repositories (CDRs) and measure calculation services (MCSs); switch the active one with one click. Verify connectivity per server, including a Verify with sample evaluate probe that exercises engine measure resolution.
Quality measures and sample patients ship pre-loaded, so your team can run a complete calculation on day one.
$ cp .env.example .env $ docker compose up [+] Running 5/5 ✓ Container lenny-postgres Started ✓ Container lenny-hapi-cdr Started ✓ Container lenny-hapi-measure Started ✓ Container lenny-api Started ✓ Container lenny-web Started → Open http://localhost:3001
Where Lenny fits
Lenny sits amongst the various FHIR servers involved in the dQM workflow specified in the DEQM IG. The CDR and MCS are intentionally separate and both are user-replaceable.
Web · API · Postgres · HAPI CDR · HAPI Measure Engine. The CDR and MCS are intentionally separate and user-replaceable.
Fernet-encrypted credential storage, bearer-token API auth, SSRF protection on every outbound URL, per-connection request timeouts, read-only flag for shared CDRs.
5 containers · 8–16 GB RAM · 4 cores · 20 GB disk. Stack: React + FastAPI + async SQLAlchemy + PostgreSQL + HAPI FHIR.
Roadmap & known limitations
We’re building in the open. Here’s what’s next.
Seven of the twelve target connectathon measures ship ready-to-run today. The remaining five are slated for debugging and inclusion in future updates.
Refinement of the output UI is underway to deliver more digestible summaries and clearer drill-down for both successful and failed calculations.
Automatically refresh the available measures list when the active Measure Calculation Service changes.
Native support for Terminology Servers, Measure Repositories, and Receiving Systems
(issues #280–#282) — moving beyond current
localized or pending implementations.
Transitioning from expensive $everything fetches to a precision
$gather approach based on data requirements. Support for FHIR Bulk Data
and invited-pull workflows is under consideration.
Try the live instance, or run it locally with a single docker compose up.