Clinical Quality Language (CQL) is the layer doing the actual work behind FHIR-based Prior Authorization medical necessity checks. The Da Vinci CRD specification depends on CQL for evaluating coverage rules at order time; the DTR specification uses CQL inside the SMART app to drive conditional questionnaire logic. A weak CQL engine means slow decisions, inconsistent logic, or rules that work in test and break under production load. Here are five CQL engines worth a serious look in 2026, plus notes on where each one fits. For broader context, more on FHIR APIs for payers covers how the CQL layer ties into the rest of the ePA stack.
1. HL7 Reference CQL Engine
The HL7 CQL reference engine, written in Java and maintained by the HL7 CQL Task Force, is the conformance baseline. Every other engine on this list either embeds it, forks it, or measures itself against it. The reference engine is open-source, well-documented, and runs locally. The trade-off is that it is not optimized for high-throughput production use; payers running heavy PA volume usually wrap it with caching or move to a tuned engine.
2. Smile CQL (within Smile CDR)
Smile Digital Health bundles a tuned CQL engine inside Smile CDR. The integration with the Smile FHIR store is the strong point; CQL rules can evaluate against live patient resources without an extra fetch step. Performance under load is competitive with anything on this list. Payers already running Smile CDR for the FHIR backbone tend to default to the embedded CQL.
3. InterSystems IRIS CDS Module
InterSystems IRIS for Health ships a clinical decision support module that supports CQL natively. The execution model integrates with the IRIS data tier, which is the same surface used for analytics and population health. For payers that already run IRIS, the CDS module is a low-friction extension. The flip side is that the CQL authoring tooling is less developer-friendly than the FHIR-native vendors.
4. 1upHealth CQL Engine
1upHealth shipped a CQL engine as part of its ePA module. The engine is FHIR-first by design and built around the developer experience the rest of the 1upHealth platform is known for. CDS Hooks integration is clean, the documentation is accessible, and the deployment model fits modern cloud-native stacks. The catch is that the rules library still depends on the payer authoring custom CQL; pre-built rule sets for common procedures are limited compared with what the integration-engine vendors ship.
5. AHRQ CDS Connect Authoring Tool (paired with reference engine)
The AHRQ CDS Connect Authoring Tool is not a runtime engine by itself; it is a visual authoring environment that produces CQL output. Paired with the HL7 reference engine or a tuned implementation, it gives payer clinical teams a way to write and edit rules without writing CQL by hand. The pattern is common at smaller plans where the medical director wants direct control over the rule set but does not have a developer to write CQL inline.
How the Choice Shapes Operational Performance
The CQL engine becomes load-bearing once Prior Auth volume crosses the threshold where humans cannot review every case. Engines that cache compiled CQL, evaluate rules in batch, and integrate cleanly with FHIR Subscriptions hit the CMS-0057-F 72-hour expedited and 7-day standard SLAs without operational heroics. Engines that re-compile CQL on each request, fetch resources serially, or lack proper indexing become bottlenecks that show up first under audit.
A useful sanity check during vendor evaluation is to ask for a CQL load test against the payer's actual rule set with realistic FHIR resource counts. The numbers reveal more than any architectural slide.
For the broader question of how the engine fits the 72-hour and 7-day decision windows, the FHIR solutions for 72-hour Prior Auth decision SLAs covers the timing-side architecture. And for the CRD integration question (CDS Hooks or direct REST), the CDS Hooks vs Direct REST for Da Vinci CRD comparison breaks down the two patterns side by side.