Your questions answered: CQL & the future of quality measures webinar Q&A

During our recent webinar, CQL and the future of quality measures, we received a number of insightful questions from attendees. Our panelists, including experts from Firely and NCQA, discussed topics ranging from key challenges, real-world applications, and the future of CQL and FHIR in healthcare—for a summary, read our key takeaways.

Firely’s experts have also compiled responses to all of the questions—covering everything from AI to implementation to best practices. Take a look below!

Question #1:

European here: The adoption of FHIR and the quality of available FHIR-data greatly varies between EU countries. In some countries there’s still lot of dispersed systems, and in other countries, (parts of) data comes from data warehouses that don’t have any common data model whatsoever. This makes it hard to start moving away from SQL and start embracing FHIR+CQL. What can we do to accelerate the adoption, especially with EMR vendors? 

Response: 

We cannot force Europeans to move to FHIR, but there is a growing list of European initiatives to align across Europe—e.g. the International Patient Summary and you can also see it highlighted on the agenda at the recent HL7 Europe WGM: https://confluence.hl7.org/spaces/HEU/pages/288073881/HL7+Europe+WGM+2025+Lisbon).  

One of the unique difficulties in Europe is that every single country has its own EMR champions, which means that all of them must align and move to FHIR. In the US, it was early regulations like Meaningful Use that pushed US vendors to provide a FHIR-based API.  We’d need something like that in Europe too.

Question #2: 

Has CQL seen any wide use in Europe? 

Response: 

Frankly we don’t know. There are a few German universities using Alexander Kiehl’s CQL engine. We will all know more after FHIR DevDays 2025—there are quite a few talks on the subject from European experts. 

Question #3: 

A lot of US health IT vendors have the capability of reporting “eCQMs” electronically since they participated in Comprehensive Primary Care Plus (through the CMS Innovation Center from 2017-23). They electronically submitted the data in QRDA III format. Is anyone leveraging this capability that you know of as we transition to CQL/FHIR? 

Response: 

In a FHIR server, the result of a CQL Measure calculation is a MeasureReport FHIR resource. This resource is very similar to the QRDA 3 if run at a summary level across a list of patients. This MeasureReport can easily be converted to QRDA 3 until programs move to a full FHIR solution, which is proposed by the DEQM IG.

Question #4: 

Where do vendors like EPIC and data models (Caboodle, Clarity etc.) provided by them stand against or with CQL and FHIR? 

Response: 

The main idea of CQL and FHIR is that it is an additional train car on the already moving FHIR train that many EHR/IT vendors are already on board with. EHR vendors have FHIR which targets their data model either directly or by export. This reduces the barrier to entry into CQL. 

However, the priorities of the EHR vendor might dictate that the CQL be targeted directly to their own model, which is very possible with CQL. It may have been implied that FHIR must also be the database storage format, but that is not the case. The storage layer can be abstracted in various ways. See next response.

Question #5: 

Referring to the anonymous question above, at our organization, we are evaluating a pilot to run our CQL on an SQL engine. 

Response: 

This is possible. See SQL on FHIR which is a similar effort to flatten FHIR. The .NET engine converts CQL to C# by way of the interim language hierarchy called ELM (Expression Logical Model). The ELM in theory could be translated to many languages. 

In our own experience, this has been a bit difficult with SQL, being that it is set based. A direct conversion may not be as performant as a query that a human would write by understanding the database structure or by calling predefined SQL views/procedures/functions.

Question #6: 

What tools can we use to validate the CQL coding for syntax compliance? 

Response: 

The CQL Visual Studio Code plugin is used by many including our team at Firely.

Question #7: 

Is there any place for training or demo can provide? 

Response: 

Firely’s training team will be releasing CQL related training in the coming months. Please reach out to training@fire.ly for details. Also, Firely will be at VIVE and HIMSS with a CQL demo. Keep an eye out on our LinkedIn for announcements.

Question #8: 

Can you give some guidance on how to execute a CQL? On the internet, I can find the CQL file for BCS but how do I execute that on a FHIR server? Any guidance or GitHub library would be extremely helpful. 

Response: 

The CQL Visual Studio Code plugin will execute CQL locally, but requires some strict directory structure to store the Measures, Libraries, ValueSets, and data. We use this tool for testing all the time. 

Running a measure on a FHIR server requires that all the dependencies are loaded to the server, Measures, Libraries, ValueSets, and data. A server preloaded with your measure dependencies might be hard to come by. Please reach out to info@fire.ly to discuss more—we are always happy to help!

Question #9: 

How does CQL relate to AI tools? 

Response: 

AI is already helping the CQL ecosystem in so many ways, from writing CQL, to analyzing data accuracy, to suggesting better CQL. We imagine that AI will be used to generate CQL to help clinicians solve patterns found in healthcare data. 

In terms of executing CQL, in most cases the goal is to retrieve the same results regardless of the technology or engine implementation. This is very important for quality programs and patient care. AI models may not give the same result given the same CQL or prompts, so it is a common opinion that CQL and future analytics are here to stay, while AI will continue to be complimentary to CQL/analytics in new and exciting ways.

Question #10: 

I am in the EU, also doing my PhD with 80% CQL components within the CDSS environment. One thing I have come to learn is that EU countries have different clinical quality reporting requirements. This makes reuse of developed clinical measures quite unattainable across EU countries, but this of course presents a virgin market especially in hospitals that are still manually extracting data from HIS’s for reporting. 

Response: 

This would be a great item to bring to HL7 for discussion—and potentially form a group of like minded individuals to solve this. Some ideas are standardizing some underlying parts of the measures where there is commonality and parameterizing where it makes sense. 

While each country is solving social and health problems differently, there may be common threads and places to consolidate. The entire world was impacted by Covid, struggles with heart disease, and a number of other common human health issues.

Question #11: 

When using CQL Engines with FHIR, are there dependencies on specific FHIR versions? If so, could you provide insight into the level of complexity and the estimated time required to adapt a CQL Engine to a new FHIR version, such as the upcoming R5? 

Response: 

Ewout stated on the webinar that R4 is supported now for the most part, and he doesn’t think it is a huge lift to support more versions. He even started to theorize on areas where compatibility could be interchangeable.

Question #12: 

I came across troubleshooting taking a good amount of time in identifying issues with the CQL code. Any guidelines or tips here of any market tools available to make CQL troubleshooting easy? 

Response: 

In part, the C# .NET SDK was envisioned by NCQA to be able to debug at the finest grained detail by stepping through the C# by debugging or by adding logging. There are some demo examples of running measures in the SDK. Rich Almeida, our VP of Product Strategy & Compliance, presented an example of this during DevDays 2024: 

• Journey into CQL with CQL dotnet SDK Part 1 

• Journey into CQL with CQL dotnet SDK Part 2

Question #13: 

I understand that CQL supports basic string search functions like contains(), startswith(), and endswith(). However, I’m wondering if CQL has support for regular expressions? As a vendor working with healthcare providers, we often need to extract specific features from clinical notes, discharge summaries, and similar documents, where more advanced pattern matching could be beneficial. 

Response: 

Yes, CQL supports matching with Matches() and ReplaceMatches(). You can read more about it here.

Question #14: 

Do you anticipate measures outcomes being determined using AI/ML than specification based ? 

Response: 

Please refer to the response in Question #9: “How does CQL relate to AI tools?”

Question #15: 

CQL is essentially mandated for CMS/CCSQ measure developers for those awarded contracts under the CMS MIDS Vehicle across care settings and measure domains. Those developers also are all but required to use the MaDie tool for authoring, which checks syntax and combines prior “MAT” and “Bonnie” authoring and testing tools previously used – if I am remembering correctly.  Can you confirm? 

Response: 

Answering yes, with limited knowledge. The MADiE tool is fully self-contained, so that there is a consistency in the final output for CMS measures. We aren’t certain, but we don’t think anything prevents authoring and testing outside of MADiE, so long as the measures end up back in MADiE.

Question #16: 

Still in relation to AI, could be or act as a fail-safe or a safeguard for AI in healthcare applications, especially in contexts of CDSS? 

Response: 

In the end, clinicians must use their expertise in clinical reasoning after any software generated suggestions, be it AI or otherwise. We believe CQL is a great tool in the clinician’s toolbox to validate AI or any other software generated clinical information.

Question #17:

At scale, how performant will it be to do all the calculations on FHIR as of today? 

Response:  

Millions of patients can be run against HEDIS measures within hours instead of days, as is the case with previous solutions. Most engines compile the CQL to executable code making it very efficient.

Question #18: 

Is there a certification available for someone who is already FHIR certified? 

Response: 

No certifications programs are available today as far as we know.

Question #19: 

Has there been a successful (or failure) story on transpiling CQL to SQL? 

Response: 

The short answer is that the CQL syntax and functionality is way more complex and powerful compared to SQL. Basic CQL could be transpiled to SQL. However, at the point of using complex CQL, custom functions would need to be added. In our experience, it is easier to move to a FHIR-native system and execute CQL natively. Otherwise, at some point the CQL engine needs to be re-written in SQL.

Question #20: 

What kind of tooling is available to ensure that CQL expressions are correctly validated against FHIR resources? How significant is it a problem for CQL expressions to be correctly validated against FHIR? If the validation is not done correctly could this lead to potential errors in clinical decision support? 

Response: 

All major dQM publications currently publish next to the measures itself extensive tests to verify the validity of the measure implementations. All engines would need to go through certification (at least for HEDIS). 

Additionally, tests published by the Digital Quality Implementers Community (https://www.ncqa.org/digital-quality-implementers-community/) verify the correctness of the engines. Homegrown and unverified engines can lead to significant errors in the calculations. Depending on the interpretation of the FHIR resource, patients may be left out of important measure populations.

Question #21: 

What solutions do you have to address that different countries have varying regulations regarding data privacy and security, which can complicate international benchmarking? 

Response: 

This is where FHIR Implementation Guides can help by accommodating variation between countries, while being based on an interoperable, comparable core specification.

Question #22: 

Is CQL a clinician friendly language? 

Response: 

Yes, at least regarding reading CQL. For creating the measures, we’d recommend leaving this up to computer scientists / programmers or similar.

Question #23:  

Is there a differnce between DQM and ECQM? 

Response: 

This one is best answered here: https://www.ncqa.org/blog/3-things-to-know-about-digital-quality-measures/

Question #24: 

I suppose, in implementations there is still the curly braces hell known from the Arden syntax? 

Response: 

The syntax has definitely improved since Arden syntax. It’s not without its challenges, but more optimized to be split up into easy-to-use modules.

Question #25: 

What role do digital adaptation kits and implementation guides play in moving from FHIR to CQL? How interoperable is CQL beyond the care landscape? Could dbt models embedded in digital adaptation kits be an alternative to CQL? 

Response: 

CQL works independently of any healthcare model. In theory, it can be applied to other models as well. In a fundamental way, it is even independent of FHIR. Implementation Guides define how the FHIR data needs to look like to verify a successful execution of the measures.

Question #26: 

As the future moves to web-hosted API based calls, where quality measures may be written, coded and executed on a remote location, what is the continued benefit to CQL? Discreet, executeable measures still face distribution, versioning and maintanance challenges. 

Response: 

The challenges definitely exists. However, for CQL, there currently exist computable rules for versioning and distribution of measures and data. The main advantage of CQL is still having an executable logic. Web APIs are no replacement for encoding the complex logic of measures. CQL measures can be executed with a web API.

Question #27: 

I thought the CQL is used for implementing logic through FHIR like the old Arden Syntax? 

Response: 

CQL is a brand new HL7 standard and works independently of Arden syntax.

Question #28: 

Assuming you have a CQL engine that can query FHIR, and you have a certified EMR that exposes at least the USCDI v2 data via a FHIR endpoint as required by the ONC/CMS rules, what stands in the way of doing quality measure reporting by that route? 

Response:  

The engine should be verified by NCQA to pass all HEDIS tests. For CMS reporting, it should pass all tests published by CMS.

Question #29: 

How do vendors sign up to get access to the NCQA dQMs? 

Response:  

See https://www.ncqa.org/digital-quality-implementers-community/.

Question #30: 

Based on Evan’s statements around getting training, are there any recommendations for free CQL and/or FHIR education? 

Response: 

There are a lot of great resources about CQL and FHIR on the DevDays YouTube.

Question #31: 

I am a pharmacist with programming experience and FHIR R4 certification, trying to pursue an informatics career. Are there any certifications on CQL alone? 

Response: 

No not at the moment, as far as we are aware.

Question #32: 

As you know, CMS started the transition from QDM-based eCQM/dQMs to FHIR and QI Core started I believe in 2019-2020. Has there been a defined cutoff to when CMS/CCSQ will require only the future state FHIR/QI Core tech spec rather than developers having to maintain both QDM-CQL and FHIR/QI Core? 

Response: 

No cut-off date is published at the moment as far as we are aware.

Question #33: 

CQL and FHIR are very powerful and also challenging to implement in some ways. Change comes with a cost. What are the catalysts in the marketplace for health organizations to move in this direction? 

Response: 

Executing shareable, interoperable CQL measures could save costs compared to the manual work of writing and updating custom measures. One type of catalyst may be incentives from CMS or state-based initiatives related to quality measures and prior authorization.

Question #34: 

Does CQL come with its own set of value set dictionaries? Or do we have to point it to the external VSAC library sets always? 

Response: 

CQL on FHIR references value sets for evaluation, but the actual values are not embedded within the CQL itself. When executing CQL against a FHIR repository, the required value sets must be available in the FHIR server and/or an integrated Terminology server. This ensures that the calculation can correctly determine whether a resource contains the relevant codes within the specified value sets.

Question #35: 

CQL in the context of Clinical Decision Support Rules – is it something that we foresee payers/healthcare entities to implement part of the CMS 0057 prior auth rule, given this is ‘recommended’ language for rules and not a requirement? 

Response: 

Yes, you are correct that there will be multiple options to conform to CMS-0057F for clinical decision support, with the primary focus being on efficient FHIR-based data exchange and workflow interoperability. 

At Firely, we are actively working on enabling solutions that leverage CQL, as we believe it provides long-term maintainability and scalability. However, we recognize that many payers already have established proprietary clinical decision engines, AI-driven tools, or other legacy processes. Transitioning these to CQL could be complex and time-consuming. Additionally, while CQL is a powerful standard, there may be certain edge cases where existing systems remain more efficient. 

The “recommend” language in the regulation reflects these considerations—prioritizing seamless data exchange between payers, providers, and patients over mandating a specific decision support execution method. However, it’s important to note that many standards that start as recommendations eventually become regulatory requirements. Organizations should consider this when planning their long-term compliance and interoperability strategy.

Question #36: 

Can the panel recommend an IG that goes from a traditional relational database, to calculating a measure? Or does the assumed step ) implementation assume a FHIR resource as the data layer?  (a simple use case like discussed previously, BCS would be helpful) 

Response: 

The Digital Quality Measures CQL engine runs on FHIR. It assumes that data has been converted to FHIR already. Mapping proprietary database data to FHIR is always a major consideration for any FHIR related project. The CQL engines can run against a FHIR server’s data, a FHIR transaction bundle with the relevant data for the measure, or FHIR data stored on disk.

The open-source free SDKs (.NET or Java) can be used to transform proprietary database data into FHIR for this purpose along with other mapping tools. Please review the Quality Measure Implementation Guide and QI-Core Implementation Guide for more information.

Question #37*: 

Bryn Rhodes has a GitHub repo with information about “Cooking with CQL” with many examples of CQL code for a variety of scenarios: https://github.com/cqframework/CQL-Formatting-and-Usage-Wiki 

Response: *This is not a question, but rather helpful documentation to share. 

Want to know more? 

If you missed the webinar, be sure to watch the recording and read the key takeaways to discover how dQMs can transform your healthcare quality measurement processes. 

Want to take it a step further? Read about Firely dQM, our new digital quality measures solution that is streamlining operations and enabling real-time insights or connect with one of our experts to explore how Firely can help your organization.