Clinical Quality Language (CQL) Qs&As

Getting Started

Q. Where is the eCQI Resource Center?


Q. Is this available in the eCQI Resource Center as a document? How can I get the slides for this session?

A. Yes, the PowerPoint and recording for all sessions are posted on the eCQI Resource Center eCQM Standards Education page. Please check back frequently for this and other news and event information related to electronic clinical quality improvement.

Q. How do we sign up for the CQL measure development workgroups? How do I sign up for the upcoming CQL events?

A. Please visit the eCQI Resource Center CQL page to register for upcoming CQL sessions.

Q. How does a person get involved in the CQL project-testing, developing measures in CQL?

A. Please visit the eCQI Resource Center CQL page to register for upcoming CQL sessions. Education announcements will also be sent through the various email lists. The CQL page also lists several workgroups where CQL is discussed.

Q. Could we please have a glossary of all the abbreviations for those of us that are novices?

A. Many of the acronyms are found on the eCQI Resource Center Glossary of eCQI Terms. We will be updating and adding new terms such as CQL in the near future.

Q. Is the April 13, 2016 webinar recording available yet? Will it be available any time soon?

A. It is available on the CQL Educational Resources page on the eCQI Resource Center.

Q. Is the slide deck going to be made available? Where will the slides and recording be posted?

A. Yes, the slides are posted on the eCQI Resource Center. You can access them at or from the CQL Educational Resources link on

Q. Is the CQL formatting and usage Wiki on the CQL page in the Resource Center?

A. The link to the Wiki is on the CQL page.

Q. Where can I find the presentation that talks about setting up the data access layer?

A. On the eCQI Resource Center Educational Resources, specifically, the Clinical Quality Language Measure Implementers session.

Back to top

General Clinical Quality Language

Q. How does CQL simplify (more) than other traditional query languages?

A. CQL has dedicated constructs for the clinical domain, native support for intervals, and high level phrasing around temporal relationships. This allows for as close to natural language expressions as possible without ambiguity.

Q. Does CQL support the open-world assumption for data that is missing in the domain model?

A. Yes, CQL supports both the open- and closed-world assumptions because this is really an aspect of the model being used and interpretation of the results of any given query.

Q. How does CQL compare to DROOLS?

A. DROOLS is a production rule language, whereas CQL is a functional language designed for expressing queries. Translators have been written to translate CQL to DROOLS, but they are not open source. Tooling exists to aid the translation of CQL to any target format in both the Java and .NET platforms.

Q. Can you clarify what a library is? Does it import something from another measure?

A. The library is a text document containing CQL. Here you can reference other logic libraries to incorporate. A measure will have an associated library to reference and the HQMF can point to expressions within that.

Q. What is the driving benefit of CQL in eCQMs and does it justify extensive vendor resources to re-write parsing tools?

A. Accuracy, ability to share between decision support rule and quality measures, and easier to build language processing applications.

Q. In the multi-source example shown in slide 23, what is the result type?

A. The query in question is:

define "Emergency Department Encounters":
                ["Encounter, Performed": "Emergency Department Visit"] ED
                                with "Inpatient Encounters" E
                                                such that ED.dischargeDateTime 1 hour or less before E.admissionDateTime

The “with” and “without” operations in CQL do not change the result type of the query, so it remains "Encounter, Performed". These operators only filter the results based on the presence or absence of a related record (using the “such that” criteria to determine existence). They are equivalent to “semijoin” and “semiminus” in a relational query language.

Q. What's the purpose of the library02 here? Is this something you're creating for reuse in other measures?

A. Yes, libraries can be used to organize CQL logic so that it can be reused in multiple places.

Q. Where can I find more detailed description on the temporal operators used by CQL?

A.The Clinical Quality Language Specification, available from HL7, has a complete description of all the operations and functions available in CQL. For the temporal operators specifically, section 2.5.5 of the Clinical Quality Language Specification provides a discussion of the available operators, and sections 9.8 and 9.9 of the reference define detailed semantics.

Q. User comment: In the evolving big data technology, there is already one CQL (Cassandra Query Language) and we have one more on the healthcare side (CQL- Clinical Quality Language). We will have to call it out when we are looking for people knowledgeable on these.

A. Agreed, there are several potential clashes with other technologies that will need to be addressed, the glossary page would be a good starting point for that.

Q. Will educational materials include instruction on how to approach constructing the logic phrases, rather than only having examples to refer to? Having a more fundamental understanding will be helpful to being able to specify measures using CQL.

A. Thank you for this good feedback. The upcoming Cooking with CQL series will address this by taking measures under development through the various logic phrases. First session will be held on April 28th and a whiteboard session will be available for questions. There will be additional CQL education sessions in the future. Visit the CQL page calendar on the eCQI Resource Center for more information. You can request CQL space membership and receive notifications when updates are made to the page.

Q. Is the CQL Author's guide part of the HL7 documentation? Or where can this be accessed?

A. Yes, it's part of the CQL specification available on the HL7 site.

Q. Was the goal to encourage modularity for re-usability?

A. Not only for reusability, but also for ease in implementation. The goal was to build modularity for CQL to have libraries that enable sharing between different measures and provide same language for data from different models.

Q. Do you see this conversion impacting how vendors will need to write their code to extract the data elements?

A. Assuming that the conversion is referring to the change to move logic out of QDM, then it depends on the degree to which vendor’s existing code is tied up with evaluating that logic. In QDM, the data elements and the logic to write queries with them are specified together, making a clean separation between those two functions difficult, and preventing them from evolving at different rates. A primary design goal of CQL was to enable that separation at the specification level, and the reason for the approach taken of moving only the logic portion to CQL while retaining the QDM data model representation was to allow vendors to pivot their architectures as well. If a given architecture already drew a line between the data access layer and the logic evaluation, that architecture will be less impacted by this change than one that implemented the logic and retrieval together.

Q. Will comments be included for reference when Bryn posts updated measure examples to the WIKI?

A. Yes, the comments will be included in the updated examples.

Q. What is function? What does it do and when should it be used in a measure?

A. Functions take arguments passed to them and return a value. In the case of a hospitalization function:

define “Hospitalization” (Encounter “Encounter, Performed”)
singleton from (
[“Encounter, Performed”: “Emergency Department Visit SNOMEDCT Value Set”] EDVisit
where EDVisit ends 1 hour or less before start of Encounter
) X
return if X is null then Encounter.relevantPeriod
else Interval[start of X.relevantPeriod, end of Encounter.relevantPeriod]

Computation is done with a value of type encounter to find an encounter that ends before the ED visit and if it’s not there, return the encounter as a relevant period; otherwise return an interval constructed from the start of the emergency department period to the end of the encounter’s relevant period.

Q. For medication order, is authorDatetime a timestamp or is it a period?

A. authorDatetime is a single timestamp, the time when the record was authored.

Q. To compare a timestamp and relevant Period, is the comparison based on the start or end of the period?

A. It depends whether you are asking for a before or after relationship. If you say, “timestamp before period”, then it’s based on the start of the period, but if you say, “timestamp after period”, then it’s based on the end of the period.

Q. Where is the encounter defined in the Hospitalization function?

A. The encounter is passed as an argument to the function, so the logic operates on whatever encounter is passed in.

Back to top

Quality Data Model

Q. Is there a conversion from QDM to CQL?

A. Yes, there is a process to translate an arbitrary QDM expression into CQL. However, one of the primary design goals of CQL was to make it easier to express complex relationships that were difficult or impossible to express in QDM. As a result, it is often the case that the best approach will be a manual translation of the intent of any given query, rather than an automated translation.

Q. Clarify from the first slide if every query requiring the 'negationRationale' is null/not null check OR if it is only required if the measure is concerned about whether or not the clinician documented a 'negation'.

A. No, the approach to representing negation with CQL and QDM has changed based on feedback from and discussion with the CQL community. The negationRationale null check is no longer required. Instead, a “Not” modifier is used as part of the QDM data element description within the CQL retrieve. If this modifier is present, the result will be negated data elements, otherwise, only positive data elements will be returned.

For example:

define "Antithrombotic Administered":

  ["Medication, Administered": "Antithrombotic Therapy"]

The above expression will return all Antithrombotic Therapy Medication Administrations that were performed. To retrieve medications that were not administered, use the “Not” modifier:

define "Antithrombotic Not Administered":

    ["Medication, Not Administered": "Antithrombotic Therapy"] NotAdministered

        where NotAdministered.negationRationale in "Medical Reason"


Note that this is a negative assertion; results will only be returned if the reporting systems actually record these types of assertions (that a particular medication was not administered). There is no expectation that reporting systems would be required to infer that a given medication was not administered in order to return results from a query such as the above.

For a more detailed discussion of the representation of negation in CQL with QDM, refer to the following page:

Q. How do you know which version of the QDM you are using?

A. The using declaration within a CQL library specifies the version of the data model being used. For example, using QDM version 4.2.

Q. Where do we find what attributes exists for a particular element like Encounters, Performed?

A. The data model for QDM specification will specify that information. For more information, visit the QDM page on the eCQI Resource Center.

Q. What version of QDM will this be based on? 4.2 or 5.0?

A. Yes, it’s on the timeline. The 5.0 is still draft and going through the various processes to get it in place, but there are specific changes that have been made as a result of wanting to take advantage of some of the functionality that is provided in CQL as well as trying to make sure there is a smooth transition. Authors that are familiar with 4.2 will be very comfortable seeing the way it is represented within 5.0 and in CQL.

Back to top

Measure Representation

Q. Are we going to get a chance to see examples of how current measures look in CQL? Is that something you'll cover during the Measure Developer training on the 27th?

A. Yes, this will be covered in the next CQL training session and in the Cooking with CQL sessions beginning on April 28th.

Q. Are there any examples of measures that are already defined using CQL?

A. Yes, we have many example measures and are working to develop more. Examples are posted on the CQL Formatting and Usage Wiki: Example Measures

Q. There are no working models where CQL has actually been modeled with an existing eCQM even though it's a DSTU approved standard?

A. We have several measures that we have expressed with CQL. There are numerous examples posted with the specification on the HL7 CQL page and the CQL Formatting and Usage Wiki: Example Measures

Q. How does CQL capture the concepts of Initial Patient Population or numerator and denominator?

A. HQMF specifies the population criteria, but instead of defining that within the HQMF as previously executed, it points to CQL. Refer to the CQL-based HQMF IG for examples and the CQL Formatting and Usage Wiki: Specifying Population Criteria.

Q. Are CQL specifications defining eCQM measure sets?

A. The CQL specification itself does not define how measures are to be expressed, it only provides a mechanism to describe logic related to the quality domains of decision support and quality measurement. Additional guidance describing how CQL is used to create measures is provided in the CQL-Based HQMF IG, as well as the currently under-development CQF-on-FHIR IG.

Q. Use of CQL in relation to eCQMs.

A. Benefits of CQL discussed at HIMSS included; modularity, computability, flexible data model, robust logic expression and reduced duplicative work for vendors and developers. From now through fall 2017, CMS and contracting partners will work with measure developers, implementers, vendors and owners of the various eCQM tools to test, develop and evolve the CQL standard to be most effective with eCQMs. Visit the eCQI Resource Center for more information and to sign up for workgroup sessions.

Q. For execution, what is the advantage of using ELM versus the ANTLR parse tree?

A. The ANTLR parse tree will be a direct representation of the input CQL. You will have to do type verification and type inference and operator resolution in order to support that type verification. You would also have to do the implicit conversions and generic type extension. There are a lot of things that the CQL supports, higher level constructs like timing phrases that are translated into a representation in ELM that is focused on implementation so that you don’t have to worry about those pieces within ELM. There is nothing that says you couldn’t do all that yourself but for implementation, using ELM takes each of those pieces off an implementer’s plate. Individually each of those aren’t terribly difficult but when you put them all together and add them all up, together with the fact that it’s maintained as a part of this whole infrastructure, it’s a significant advantage to be able to use the ELM directly rather than have to start directly from a parser.

Q. If both CQL and ELM are available, is it possible to build parsing logic around the CQL instead of the ELM?  Is that not recommended?

A. Yes, it is possible and we do provide a CQL ANTLR grammar just like on the previous question. The ANTLR tooling is great. It provides easy to use generated visitor and/or listener code depending on which mode you use it in. In fact the CQL-ELM translator is implemented using a generated ANTLR visitor. The advantages are those uses that I’ve mentioned, you’ve got the ELM representation that’s focused on implementation. Rather than CQL representation, which is focused on high level representation that’s human readable and natural language expression of timing, and clinical concepts.

Q. Do the CQL changes impact the human readable specifications currently published with each eCQM?  If yes, where can we go to understand the changes?  Is there an example available that shows current and future?

A. Yes, the human readable that’s currently part of the HTML for each measure and uses QDM, will actually use CQL now. There are examples within the CQL formatting and usage Wiki that show some of that. That’s our current approach.

Q. Do you imagine that ELM would be used to exchange eCQM between organizations?  It seems that CQL would be better since it is more human readable.

A. That depends on the target of the sharing. I agree that if your intent is to share between clinicians or human readers or even eventually integrators, if the readers are human CQL would be a better way to share that, but if the intent is to automate sharing of that measure definition, then CQL introduces another level of functionality and the ELM that is underneath provides an easy way to get to that more machine friendly representation. There is nothing that says you couldn’t share at the CQL level even for integration, it’s a formal language and it supports accurate and computable representation of the measure logic. It’s just that the CQL to ELM translator and that representation provides an easy way to get past all of those traditional hurdles of building a new compiler or interpreter.

Q. Can you speak to the relationship between the ELM and HQMF?  Will ELM be nested inside of an HQMF? 

A. There is a release 1.2 of HQMF that extends this standard in a very simple way to be able to reference an external document. And the way that the CQL based HQMF IG then uses that extension for HQMF is to specify that the logic for the criteria expressed within the HQMF is actually specified in the ELM document. That document is a library just like the example we showed in the ELM library that actually contains the logic and then the HQMF will be the criteria that will actually point to an expression to find in that ELM document. So no, it won’t be nested inside the HQMF, it will just be referenced as a separate document and then each criteria will point to specific expressions within the ELM.

Q. Currently we use eCQMs for measure specifications. Will we get measure specifications in a different method?

A. eCQMs will still be distributed using HQMF, but the logic involved will be contained in separate CQL and ELM documents distributed along with the HQMF, and the criteria in the HQMF document will reference expressions defined in the CQL/ELM library.

Q. When can we expect a sample of the measure using the CQL?

A. There are lots of examples in the Formatting and Usage wiki.

Q. In the example for the encounter with lab test performed during the encounter. Is during the appropriate comparator?

A. Potentially no. A more clinically relevant example can use ordered during the encounter relevant period if that element is available.

Q. What are you doing to "compile it"?

A. By specifying configurations and running it through the CQL to ELM translator, which is a Java Package available through the Maven Repository. Right now, you can use command-line or call it directly from Java.

Q. Does union return a unique code for both diagnosis of asthma and other illness?

A. Yes, in the new version of CQL 1.2, distinctions will not be necessary because duplicates will be automatically eliminated.

Q. Is measure 72, which defines exceptions for antithrombotic therapy, an example that could be simplified in logic to reference an episode of care?

A. Yes, it could reference an episode of care where the exclusions were associated with any encounter in that episode of care.

Q. Why is measure EDHI test31: denominator exclusion giving an error such as ‘could not resolve all the operators’?

A. ["Encounter, Performed": "Encounter Inpatient" ] Encounter
without "Newborn Hearing Screening Left" Left
such that Left.relevantPeriod during Encounter.relevantPeriod
without "Newborn Hearing Screening Right" Right
such that Right.relevantPeriod during Encounter.relevantPeriod
where "Encounter.dischargeDisposition" in "Patient Expired"

Q. The first problem is that the screening results are being returned as “yes/no” answers instead of as results, so they can’t be used in a without clause like this. Instead, return the diagnostic study performed during the relevant period and use a ‘without’ to define the relationship between the newborn hearing screening and the encounter:

A. // behavior of with/without is additive
["Encounter, Performed": "Encounter Inpatient"] Encounter
without "Newborn Hearing Screening Left" Left
such that Left.relevantPeriod during Encounter.relevantPeriod
without "Newborn Hearing Screening Right" Right
such that Right.relevantPeriod during Encounter.relevantPeriod
where Encounter.dischargeDisposition in "Patient Expired"
The second problem is that because without clauses are additive in a query, the encounter will only be
returned if it has neither a left nor a right screening, which isn’t the intent of the measure. Instead,
define them separately and use a union to combine them:
define "Encounters Without Left":
["Encounter, Performed": "Encounter Inpatient"] Encounter
without "Newborn Hearing Screening Left" Left
such that Left.relevantPeriod during Encounter.relevantPeriod
define "Encounters Without Right":
["Encounter, Performed": "Encounter Inpatient"] Encounter
without "Newborn Hearing Screening Right" Right
such that Right.relevantPeriod during Encounter.relevantPeriod
define "Encounters Without Screening":
"Encounters Without Left" union "Encounters Without Right"

*Note – Don’t put double quotes around the whole qualified identifier, it will not find the identifier. E.g., use Encounter.dischargeDisposition and not “Encounter.dischargeDisposition”.

Q. In the estimated due date example, do you take the return of a record, within physical exam performed estimated due date codes that would have access to all the actual fields and cast it to datetime?

A. Yes.

Q. Does gestational period of 32 weeks and 1 day truncate to 32 weeks?

A. Yes, time durations in CQL are always in terms of a single duration. If it was necessary to say 32 weeks and 1 day, you would define it in days (or use addition to add 32 weeks + 1 day).

Q. When define “gestational age at birth”: 280 – (days between “Estimated Due Date” and “Time of Delivery”) div 7 is entered into the MAT, is it entered as a function or a definition?

A. In this expression, it is entered as a definition, but you could also define a gestational age at birth function.
define "Estimated Due Date":
["Physical Exam, Performed": Vx."Estimated Due Date"] Exam
sort by start of relevantPeriod
).result as DateTime

define "Gestational Age in Days at Birth":
(280 - (duration in days between "Estimated Due Date" and "Birth Date")) div 7

Q. When using “with” in the “such that” expression, do you have to put it before all the such that’s or is there a significance to the order?

A. Each “with” needs a “such that” to describe the relationship of the “with” source to the “primary” source.

Q. Explain why, if the timing is less than 30 days, 29 days is used in the CQL expression?

A. Because the timing phrase in 1.1 doesn’t have a way to say, “less than 30 days”, only “29 days or less”. The 1.2 version of CQL will introduce the ability to say, “less than 30 days”.

Q. What is the difference in the query order between:
a) Define “Encounter With ED Visit Less Than Two Days”:
“Encounter with Ischemic Stroke” E
with “ED visit” ED
b) Define “ED Visit Less Than Two Days”:
“ED Visit” ED
with “Encounter With Ischemic Stroke” E

A. Query (a) is returning the inpatient encounters, not the ED visits. What should be counted in this measure is inpatient encounters. We are interested in a case where there was a prior ED visit to consider as part of the encounter. Query (b) is returning the ED visits immediately following an inpatient encounter.

Q. In the example below, does using exist have any impact when also using the union to define the numerator? Define “Numerator”:
“Encounter With Antithrombotic Therapy”
union “Encounter With ED Visit With Antithrombotic Therapy”

A. Yes, and it depends on whether we are defining a patient-based or encounter-based measure. For an encounter based measure, what we are returning from all the criteria are lists of encounters. In a patient-based measure, what we are returning from all the criteria is true or false. So, in a patient-based measure you use exist to get a list to be true or false. In an episode-based measure, we are returning lists, so we don’t use exist.

Q. You used the definition called “Inpatient Encounters” throughout the measure, but I thought it only had the length of stay and end string measurement period?

A. That’s correct, it’s better to use “AMI Encounter” because it has all the necessary criteria.

Q. We tried to use “Inpatient Encounters” and intersect it with something else, but it would not work. Why is that?

A. The Intersect operator takes two lists and returns only those elements that are in both lists, so the lists should have the same kinds of values, such as lists of encounters. You cannot intersect encounters and orders.

Back to top


Q. Is there any intention of incorporating CQL into the Measure Authoring Tool?

A. Yes, not only into the Measure Authoring Tool, but also various tools used to create electronic specifications such as Bonnie for test cases.

Q. When is this CQL going to be introduced to be in effect?

A. CQL is available now as a draft. The timeline for incorporating it in specifications is in process.

Q. Is CQL to replace HQMF for writing eCQMs?

A. Currently HQMF uses CDA templates based on QDM and also defines logic. CQL does not describe the structure of a measure or data model involved. The CQL-based HQMF IG is using CQL to express the logic portions but still referencing QDM for the data element and HQMF to represent the structure of the measure and metadata involved.

Q. Do you foresee major changes to CQL by the end of next year?

A. No, the specification has been in DSTU for over a year, and has undergone very little change. There is a 1.1 release in process, but after working with CQL to express a broad array of measures, the language has proven to be an effective platform for the expression of quality-related logic.

Q.  When would I expect to see the CQL authoring tools available for use? When would the MAT start to output CQL-based measures?

A. The Measure Authoring Tool (MAT) will be available to use in a test environment in the fall of 2016 for users that want to test and try creating measures using CQL. No firm date has been established. Please refer to “Proposed Timeline For Updating Standards” on slide 6 of the Clinical Quality Language (CQL) for Measure Developers presentation.

Q. When are the eCQMs written w/ CQL becoming available?

A. They will be available for testing as per the detailed timeline when tools are ready. Please see the “Proposed Timeline For Updating Standards” on slide 6 of the Clinical Quality Language (CQL) for Measure Developers presentation.

Q. Incorporating into what specs and when?

A. It will depend on when the tools are ready.

Q. Do you expect the CQL standards to be called out in this year’s rule making process?

A. Yes, the transition to CQL is mentioned in the FY 2017 IPPS Proposed Rule.

Q. Many of the HEDIS measures in existence have some clauses which are difficult to represent in the QDM. Has there been work with HEDIS measure developers to help with synergy here?

A. Yes, there is collaboration with multiple organizations to help with the synergy of HEDIS measures. 

Q. What occurs in the phase "Testing eCQM using CQL-QDM-HQMF 2.1: measure development and testing in a simulated environment" beginning in fall 2017, versus what is described in the previous testing phase?

A. ‘Testing eCQM using CQL-QDM-HQMF 2.1,’ will be the final testing phase before implementation of CQL. It will have the final draft of CQL with tools updated and the full measure entered into the measure authoring tool.

Q. In the slide that has the CQL timeline, it lists integration testing- can you speak to that a little more and describe what that would entail?

A. Please refer to the CQL page on the eCQI Resource Center for more information about signing up for CQL workgroups that will go over the timeline planning process and where you can provide testing feedback. This fluid process will involve reviewing CQL measure standards measure specifications as they are developed. The workgroups meet on Fridays.

Q. What is the vision for what integration testing will consist of?

A. This will involve a coordinated effort between the various groups producing CQL tooling (MAT, Bonnie, additional tooling) to test that measures produced from the MAT can be evaluated within Bonnie against patient data produced there. In addition, the effort will involve pilot implementations with measure evaluation vendors (including EHRs and reporting providers) to ensure the measure calculation can be performed correctly.

Q. Are there plans to integrate CQL into Bonnie in order to query the test case data?

A. Yes, there are Bonnie branches that are able to evaluate CQL expressions. 

Q. What is the timeline? When will the MAT be updated and be able to produce the CQL HQMF?

A. The plan at this point is to release a user acceptance test version of MAT that’s putting out bare bone CQL-HQMF around October 2016 when measure developers and others who are part of that UAT cycle can start crafting their measures and seeing how things operate and work within that particular environment. As the timeline shows on slide 6, the plan at this point is to at some point within fall 2017 have a version of MAT that will be available in a production environment that users could create their CQL logic in.

Back to top


Q. What is the relationship between CQL and SNOMED?

A. CQL only defines the notion of a value set and code system so that it can be referenced from within the logic.

Q. Can value sets be referenced by URL rather than by OID?

A. Yes, within CQL, a “value set” is just a local identifier and can be any string. It is up to the evaluation and authoring environments to define the format and interpretation of that string.

Back to top

Tooling and Implementation

Q. Can you provide an overview of current or future-planned CQL execution tooling, i.e., SQL execution, or XML execution engines?

A. There is currently tooling to support parsing and validation of CQL and development of tooling to support authoring and execution is in progress. Please visit the eCQI Resource Center CQL page for upcoming CQL sessions which will cover more on this and other CQL topics.

Q. Are there open source implementations or parsers available?

A. Yes, available at the GitHub tooling repository.

Q. What "software" does this run inside? What's running or interpreting the CQL statements?

A. CQL is translatable to different environments with system engines that support its execution such as .NET, Java, and JavaScript. The open source tooling provides reference implementations that can be used as-is, or as a starting point for a custom implementation.

Q. What technology is this language used with?

A. CQL is intended to provide a means to accurately and easily share the logic involved, and can be used with any technology platform. Open source tooling exists to facilitate usage in Java, .NET, and Java-Script.

Q. Is there an opens source execution engine for CQL?

A. Yes, there is a JavaScript engine at the GitHub tooling repository.

Q. Will CQL have any effect on the MAT?

A. Yes, as part of the effort to support CQL, the MAT tool is being updated to allow measure authors to write logic using CQL.

Q. Will measure developers be writing CQL directly, as opposed to using tools like the MAT?

A. Yes, they can write text documents using the CQL library. MAT tools provide the structure to make writing easy beyond having a text document. The MAT tools help with available operations and acceptable attributes from the QDM element.

Q. Will these changes be incorporated into the measure authoring tool and when?

A. Yes, the process of getting CQL into the MAT and having the tooling available to help a measure author describe and build a measure in CQL is in progress as outlined on the proposed timeline slides.

Q. Is there/will there be a relationship with CQL to JSON or other scripting language?

A. Yes, CQL is both a high level syntax expressed in text, as well as an equivalent lower level representation of the logic involved focused on language processing application. This lower-level format is defined as a schema and can be rendered in XML or JSON. There is tooling in the repository link to translate from the text representation of CQL to this lower-level representation (Expression Logical Model, or ELM) for XML or JSON rendering.In addition, the repository currently has an engine that can evaluate ELM expressions, there is a JavaScript engine that can run ELM representation.

Q. Can the MAT help with issues like the square brackets versus parenthesis issue for intervals?

A.  If a user creates CQL statements freeform in MAT then the user is required to know the syntax but it is possible validations will occur if it is not correct.   If the user is using advanced functionality in MAT to create the intervals then the tool will insert the CQL logic with appropriate syntax and styling.

Q. Will the MAT generate ELM?

A. Yes, we plan on allowing users to export both the CQL and ELM files. MAT packages will be provided, there is a file for each export artifact.

Q. How fully will the MAT tool be able to utilize the "library" aspect of CQL, or the ability to re-use snippets across multiple measures?

A. About reusability, there will be at some future point the ability to share libraries and reuse the definitions within. We are targeting a future release that will have that functionality but at this point and time, there has not been a decision made as to when that functionality will be available. It will definitely be available for the fall 2017 timeframe but we cannot commit at this point that it will be available for the first UAT cycle.

Q. What data set is sitting behind your CQL execution? Is it hitting a relational database, JSON flat file?

A. CQL is designed to allow logic to be written against any data model. The specification defines an abstract data access layer that is responsible for retrieving data from the underlying systems, and that layer can provide access via a traditional relational database system, or JSON flat files, whatever is appropriate for the environment. For more information, refer to the CQL presentation Training for Measure Implementers about the implementation and design of CQL, and how it enables use of the same language across different models and platforms at the eCQI Resource Center Educational Resources.

Q. On a previous WebEx, not Cooking but another CQL WebEx, it was mentioned that there was some open source code to implement this with .NET and SQL server. GitHub has a 2-year-old code for .NET and I didn't see an ODBC/SQL setup. Can you direct me to this?

A. Unfortunately the .NET reference implementation tooling for CQL is lagging so that code is viable, but would need to be updated. The SQL implementation path provided is to translate the CQL to SQL. Here’s a link to the HeD schema framework which works with CQL 1.0.

Q. Can measures be shared to use as examples?

A. Measures in the Measure Library can only be shared by the owner. However, users of the MAT can see all shared measures and look them up by title or CMS ID.

Back to top


Q. How to relate FHIR to CQL?

A. The CQF-on-FHIR Implementation Guide currently in development provides guidance on how to use CQL within FHIR in general, as well as how to use CQL within the quality-related resources (DecisionSupportRule, Measure, OrderSet, etc.) to describe, distribute, and evaluate quality-related knowledge assets.

Q. Can you speak to relationship between CQL and FHIR at this time, and how this relationship might change in the future?

A. CQL is currently a standalone specification. It was designed form the start to be independent of any data model. We want to make sure that we preserve that and think it’s an important part of being able to share logic and be able to keep those touch points between the data model and the terminology as independent as possible and to define clear interfaces between those touchpoints. So the different pieces of architecture can change at different rates.

We support using the generic structural definition provided by the model info and we support the use of FHIR directly within CQL. There is a FHIR 1.4 model info in the DSTU update branch of the Clinical Quality Language repository and that lets you write directly against FHIR but there is a caveat in that the FHIR structures are exposed as is. So when you have an integer element for example in a FHIR resource, the integer element itself has a “value” attribute that is the actual integer. Within FHIR that approach enables functionality like extending on primitives, so there are good reasons for the way it is built, but those are all going to be exposed directly so that if you had say a Patient in FHIR, to get to the gender, you have to say patient.gender.value. Within HL7 there’s a project to look at how to smooth out some of those rough edges so that CQL can be used even more effectively with FHIR.

Back to top