Please visit the eCQI Resource Center CQL page Connect tab for instructions on how to register for upcoming CQL sessions.

You can find information on data access in the Clinical Quality Language (CQL) Measure Implementers presentation on the eCQI Resource Center CQL Educational Resources page.

There are currently no in-person classes available. However, CQL presentations are often provided at conferences such as the CMS Quality Conference. Updates are posted to the eCQI Resource Center as available. You can find recordings and slides from past presentations on the eCQI Resource Center CQL Educational Resources page.

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.

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. There are no publicly available examples. However, a pilot in the Clinical Quality Framework (CQF) initiative built a translator from CQL to Drools.

A Clinical Quality Language (CQL) library is text document (.cql, .xml, and .json) that contains CQL expressions, definitions, functions and other declarations that can be used across measures. Each electronic clinical quality measure (eCQM) contains a primary library that defines the criteria used by the populations of the measure. The Health Quality Measure Format (HQMF) document references this library and defines the populations by identifying which expressions in the CQL library define each population (e.g., Inpatient Encounter, terminologies). Measures may include references to a shared library, which can be either referenced throughout a single measure or across different measures (and even clinical decision support rules) to share definitions and functions like "Hospitalization". This library sharing minimizes efforts both with measure implementation and development.

For more information on libraries, refer to the Using Libraries to Shared Logic section of the CQL Implementation Guide.

CQL implementation is designed to address many of the issues encountered with previous eCQM specifications (using Quality Data Model (QDM)-based logic). It allows for increased precision (reduced ambiguities) and improved specificity, provides the ability to share between decision support rules and quality measures, and improves the ease of building language processing applications. CQL-based eCQMs are intended to provide as much opportunity for automated interpretation as possible. QDM-based logic measures have often been manually translated for implementation, which results in ongoing costs as measure specifications are updated annually. While programmatic implementation and interpretation of CQL-based eCQMs has an initial cost, that cost is then significantly reduced for ongoing maintenance, as systems will only have to ingest any updated specifications.

To learn more, refer to the Benefits of CQL.

The “with” and “without” operations in Clinical Quality Language (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.

Measures may include references to a shared library, which can be either referenced throughout a single measure or across different measures (and even clinical decision support rules) to share definitions and functions like "Hospitalization". This library sharing minimizes efforts both with measure implementation and development.

For more information on libraries, refer to the Using Libraries to Shared Logic section of the Clinical Quality Language (CQL) Implementation Guide.

There are also at least two open source engine implementations of CQL that evaluate the measures and supporting logic.

JavaScript Open Source Engine

Java Open Source Engine

CQL Specification, available from Health Level Seven International (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.

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

Reusability was part of the goal, but also for ease in implementation. CQL's use of libraries enables sharing of logic expressions, definitions, functions, and other declarations between different measures and clinical decision support rules and provides the same language for data from different models.

It depends on the degree to which vendor’s existing code evaluates logic. In Quality Data Model (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 is 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.

Functions take arguments passed to them and return a value. The Clinical Quality Language (CQL) Style Guide provides more information about best practices and standards for functions. For example, 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 Emergency Department (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.

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

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.

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

CQL is designed to enable the description and distribution of electronic clinical quality measures (eCQMs), but it also can be a basis for evaluation. There are at least two open source engine implementations of CQL that evaluate the measures and supporting logic. Refer to the CQL for Implementers presentation for additional guidance.

JavaScript Open Source Engine

Java Open Source Engine

No, the approach to representing negation with Clinical Quality Language (CQL) and Quality Data Model (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 Clinical Quality Language (CQL) with Quality Data Model (QDM), refer to the CQL Formatting and Usage Wiki.

Using declaration within a Clinical Quality Language (CQL) library specifies the version of the data model being used. For example, using QDM version 5.4.

The Quality Data Model (QDM) specification will continue to define this information. For more information and to review the most current versions of the QDM specification, visit the QDM page on the eCQI Resource Center.

1) When using observations with different dates

2) For an episode of care

3) When using the same encounter from two different expressions

Health Quality Measure Format (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 Implementation Guide (IG) for examples and the CQL Formatting and Usage Wiki: Specifying Population Criteria.

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 Health Quality Measure Format (HQMF) Implementation Guide (IG), as well as the currently under-development Clinical Quality Framework-on-Fast Healthcare Interoperability Resources Implementation Guide (CQF-on-FHIR IG).

The ANTLR parse tree will be a direct representation of the input Clinical Quality Language (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 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. Refer to the CQL for Measure Developers presentation for additional guidance.

Yes, it is possible and we do provide a CQL ANother Tool for Language Recognition (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 advantage is that the ELM representation is focused on implementation and machine processing, as opposed to the CQL representation, which is focused on high level, human readable, and natural language expression of timing, and clinical concepts. Rather than CQL representation, which is focused on high level representation that’s human readable and natural language expression of timing, and clinical concepts. Refer to the CQL for Measure Developers presentation for additional guidance.

Yes, the human readable that’s currently part of the Hyper Text Markup Language (HTML) for each measure and uses Quality Data Model (QDM), will actually use CQL now. Measures with CQL are published so you can see the HTML on the 2019 Eligible Professional/Eligible Clinician and Eligible Hospital/Critical Access Hospital pages. There are also examples in the Side-by-Side presentations on the CQL Education page. Refer to the Guide for Reading eCQMs for additional guidance.

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.

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 Implementation Guide (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.

eCQMs are still distributed using Health Quality Measure Format (HQMF), but the logic involved is contained in separate Clinical Quality Language (CQL) and Expression Logical Model (ELM) documents distributed along with the HQMF and the criteria in the HQMF document reference expressions defined in the CQL/ELM library.

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

As of Clinical Quality Language (CQL) version 1.2, the use of the distinct keyword with unions is not required because duplicates are automatically eliminated by the union.

Yes. You can find further information about this example on the Clinical Quality Language (CQL) Formatting and Usage Wiki - Cooking with CQL examples.

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). Refer to the Electronic Clinical Quality Measure (eCQM) Logic and Guidance document for more details.

In this expression, it is entered as a definition, but you could also define a gestational age at birth function. define "Estimated Due Date": Last( ["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

You can find further information about this example on the Clinical Quality Language (CQL) Formatting and Usage Wiki - Cooking with CQL examples.

Each “with” needs a “such that” to describe the relationship of the “with” source to the “primary” source. You can find further information about this example on the Clinical Quality Langugae (CQL) Formatting and Usage Wiki - Cooking with CQL examples.

Because the timing phrase in 1.1 doesn’t have a way to say, “less than 30 days”, only “29 days or less”. As of CQL 1.2 the timing phrase supports exclusive comparison, so the comparison can be "less than 30 days."

a) Define “Encounter With ED Visit Less Than Two Days”: “Encounter with Ischemic Stroke” E with “ED visit” ED And b) Define “ED Visit Less Than Two Days”: “ED Visit” ED with “Encounter With Ischemic Stroke” E

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.

You can find further information about this example on the Clinical Quality Language (CQL) Formatting and Usage Wiki - Cooking with CQL examples.

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>.

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.

Because length of stay is an attribute of the encounter, it doesn’t work for defining the overall length of stay in the case where we want to consider the encounter immediately prior to the Emergency Department (ED) visit. Using the CQL expression is more general and it allows you to handle that case transparently. The length of stay attribute of Encounter, performed can be used to define the time from admission to discharge for a specific encounter. However, if the measure developer needs to express the time from admission to a previous, but related encounter (i.e., an Emergency Department visit), the length of stay attribute would not be sufficient and a CQL expression provides such ability. Note, that to determine the arrival time at the previous Emergency Department visit, the measure needs to address the Encounter, Performed location attribute.

The hospitalization function has been considered as an approach to identifying an encounter plus the time immediately prior to the Emergency Department (ED) visit. In a lot of the current hospital measures, they are looking for that pattern because there is an inpatient encounter with an immediately prior ED visit. In previous logic, those cases had to be considered independently. The hospitalization function gives us the duration, the interval from the start to the end of either the encounter or the immediately prior ED visit. It collapses that logic for determining what the overall duration of the hospitalization is, and by using this function, then we pass an encounter and it tells us from admission to discharge. Note, to determine arrival time within the hospitalization function requires use of the Encounter, Performed location attribute. Refer to the Clinical Quality Language (CQL) Style Guide for additional guidance.

Yes.

The Quality Data Model (QDM) supports the description of an allergy/intolerance to provide more detailed information than is available in a Diagnosis alone. However, this flexibility means there is the potential for underlying systems to provide the data as both a Diagnosis or as an Allergy/Intolerance. Measure authors can express the allergy in both ways to cover this possibility. For example, to address the type of reaction that meets the measure criteria, the measure can indicate “Diagnosis: Anaphylactic reaction to penicillin” using a precoordinated SNOMED CT concept, or use a post-coordinated approach “Allergy/Intolerance: Penicillin (type: anaphylaxis).” The latter approach may be more consistent with the way an allergy or intolerance is managed using non-measure transactions in Health Level Seven International (HL7) V2, V3, and Fast Healthcare Interoperability Resources (FHIR), except that FHIR uses the metadata element “reaction” to address the QDM attribute “type.”

Each diagnosis should be described separately. The expression using union won’t work because it will produce results if either one or both diagnoses are present. If the use case requires both, then the “and” expression is required.

define 'Single Live Birth Encounter or Gestational Diabetes':

    'Inpatient-Encounter” Encounter

           where exists (Encounter.diagnoses Diagnosis

                 where Diagnosis in 'Single Live Birth'

                       or Diagnosis in Gestational Diabetes'

)

No, because it indicates you want any diagnosis in the inpatient encounter that has a diagnosis code of “Single Live Birth” and “Gestational Diabetes”. The single code cannot satisfy both those requirements at the same time.

    Interval

     [

         First(Encounter.facilityLocations Location

                Return start of Location.locationPeriod sort ascending),

        Last(Encounter.facilityLocations location

                Return end of Location.locationPeriod sort ascending)

    ]

The interval would return a full Datetime, e.g., the first return would be locationPeriod: 10:30..11:21.

If there is a need to distinguish different results that have the same types of values, then yes, there would need to be some way to map that content from the source system. However, for cases that do not need to distinguish different results (e.g., because the result values are pre-coordinated, so no two components could have the same result value), then the code layer can be ignored. It depends on the use case. The structure and logic support both approaches. You can find further information about this example on the Clinical Quality Language (CQL) Formatting and Usage Wiki - Cooking with CQL examples.

Yes, within 60 days can be before or after. 

Parameters are external values that are provided when the measure is evaluated, whereas definitions are used to organize criteria within the measure.

Yes, the age criteria is independent of the other conditions here, so it could be moved to a separate definition, especially if the intent was to reuse that component in other definitions. Review the full expression in the Clinical Quality Language (CQL) Formatting and Usage Wiki.

CQL takes a different approach to representing what specific occurrences were achieving, namely identifying a specific instance and associating criteria with that instance. Because CQL can describe queries and their results, and then use those results in subsequent operations, specific occurrences are not required to tie the different appearances of a data element together throughout the measure definition. Rather, with CQL, additional criteria are applied to specific instances of a data element by referencing the same expressions. For more information and examples, see the Specific Occurrences topic in the Formatting and Usage Wiki.

In the example

define "Hepatitis B Immunizations or Procedures":

( ["Immunization, Administered": "Hepatitis B Vaccine"]

union ( ["Procedure, Performed": "Hepatitis B Vaccine Administered"] Procedure

return "Immunization, Administered" { authorDatetime: start of Procedure.relevantPeriod }

) ) HepBVaccination

where AgeInDaysAt(HepBVaccination.authorDatetime)>= 1

and AgeInDaysAt(HepBVaccination.authorDatetime)<= 730

it is a definition. Value set declarations are defined in the CQL header and are local identifiers for value sets stored in a terminology service like the Value Set Authority Center (VSAC). Definitions are defined in the body of the CQL library and specify chunks of logic that can be used throughout the library or within the measure as population criteria.

The Coalesce function takes a list of expressions and returns the first one that results in a value. For Procedure, Performed, we have both an authorDatetime and a relevantPeriod, but for Immunization, Administered, we only have an authorDatetime, so the Coalesce in this case is saying “Use the start of the relevantPeriod if it’s present, otherwise use the authorDatetime.”

In this example, the definition is "Hepatitis B Immunizations or Procedures", and it references two data criteria, one "Immunization, Administered": "Hepatitis B Vaccine", and one "Procedure, Performed": "Hepatitis B Vaccine Administered". In these criteria, "Immunization, Administered" and "Procedure, Performed" are Quality Data Model (QDM) Data Types, and "Hepatitis B Vaccine" and "Hepatitis B Vaccine Administered" are value set references.

The example can be found here.

It depends how often the definition needs to be used in subsequent logic. If the definition is used often, and the Coalesce pattern is required for each usage, then it makes sense to use a return clause to shape the different results so that they have the same attributes. This allows subsequent expressions to just reference a single attribute, rather than having to use the Coalesce pattern to choose a value from among different attributes.

When referencing only a subset of the codes from an existing value set, this can be done two ways

• define another value set with only that code in it
• reference a specific code

In general, if the use case clearly identifies a specific code to reference, you can use it as a direct reference code. However, if there are multiple codes necessary, a new value set is needed.

Note that although Clinical Quality Language (CQL) does provide set operations that could be used to compute the subset of a value set using some expressive criteria, performing calculations involving value sets is not recommended for several reasons:

Terminology operations, such as membership, are communicated in the machine-readable file in specific ways that enable implementations to make use of terminology servers. Performing calculations on value sets requires the use of expansion, which is not required for membership testing when that testing is done by the terminology server. As a result, using value sets in calculation would impose an additional implementation burden on vendors consuming the measure.

The definition of terminology is by design a separate aspect of quality measure development. This separation of concerns has multiple benefits, including that the maintenance and governance of value sets can be performed independent of the maintenance and governance of the measures.

Value set definition often involves operations that are specific to the terminologies involved, so there is a great deal of variability in the way that these expressions are represented.

Example can be found here.

No, the measure specifications don't indicate whether boundaries are closed are open because that is an aspect of the value, not the type. The systems providing the information indicate whether they are giving an interval that has closed or open boundaries.

let procedure: (

        “Total Hip Total Knee Procedure” (QualifyingEncounters) P

        where P.ordinality in “Principal”

       )

No, the “where” clause in a query will not change the result type of the query. You can find further information about this example on the Clinical Quality Language (CQL) Formatting and Usage Wiki - Cooking with CQL examples.

No, it is true for both patient-based and non-patient based measures. However, for non-patient based measures, because the criteria expression has to return the same type as the rest of the measure population criteria, it is often easiest to just reference the “Initial Population”.

The attribute component is the list of results. For example, a diagnostic study performed may have a single result or a result and a code. It is a way to represent both components within the Quality Data Model (QDM) datatype. You can find further information about this example on the Clinical Quality Language (CQL) Formatting and Usage Wiki - Cooking with CQL examples.

"Most or Moderately Effective Contraception Provided" Contraception

                Return Contraception.code

A. The supplemental data element definition returns the code even though it will, in general, return multiple different types of contraceptives. For each actual instance, the specific code in the reporting system will be returned. In a summary report, these would be aggregated by code. In an individual report, the data for this individual would be returned.

The “union” in this question is referring to the common use of unions to bring together encounters from different value sets in to a single expression for consideration. With option 1, because the observation status is determined by looking at a facility code, the encounter codes are still used in the way that they are now (e.g., to represent the type of encounter: inpatient, outpatient). With option 2, however, “Observation” is represented as another type of encounter, so you wouldn’t be able to distinguish other types of encounters within Observation.

Yes, because there would be no observation or Emergency Department (ED) visit. The outpatient visit can be compared to the start of the encounter’s relevant period.

Yes, in that case, you would use the Hospitalization with Observation function rather than the Hospitalization with Outpatient function. In addition, measures that did not consider observation status to be part of the episode of care would continue to use the current Hospitalization function.

For blood pressure, there is a physical exam result or components result and the challenge depends on what you're looking for. It is a single observation, but it depends on how it is recorded.

If the frequency is available, then the QDM medication elements calculation would work, but if you are using the supply and the relevant periods to back into a daily value, that might not work because there is no certainty that supply is correlated with the relevant period. Refer to the Clinical Quality Language (CQL) Formatting and Usage Wiki - Cooking with CQL examples for examples on how to calculate using both methods.

That's correct because when you don't have an end to the prevalence period and it’s characterized with a closed brace, which is typically how they are characterized, then that means it goes to the end of time. So, when we intersect that with the measurement period, we only get the portion of the prevalence period that is entirely within the measurement period. For example, if you have a diagnosis that starts in March and another that starts in April and they both have no end-date then you'll just get one result.

No, risk adjustment variables can return any value. They are presented in the context of the patient and can return anything. For example, consider this risk adjustment variable definition from the TestRiskAdj_CQL example measure from the Clinical Quality Language (CQL)-Based Health Quality Measure Format (HQMF) Implementation Guide (IG): 

define "Bilirubin Test": ["Laboratory Test, Performed": "Bilirubin"] L

    with "CABG_Open and Endoscopic During Encounter" C

      such that L.relevantPeriod starts before start of C.relevantPeriod

    with "Encounter Inpatient 365" E

      such that L.relevantPeriod starts during E.relevantPeriod

    where L.result as Quantity > 2 'mg/dL' 

This returns all Bilirubin Tests for the patient that occurred during an Open and Endoscopic Coronary Artery Bypass Graft (CABG) during a qualifying encounter and with a result > 2 'mg/dL'.

No, CQL does not replace HQMF. HQMF uses Clinical Document Architecture (CDA) templates based on Quality Data Model (QDM) and also defines logic. CQL does not describe the structure of a measure or data model involved. The CQL-based HQMF Implementation Guide (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.

You must be registered in VSAC as an author in order to create a new value set. Go to the Author Registration Section when logged in and search for the concepts you want in the terminology. Then identify and create a value set. Once the value set is defined in VSAC, you can use Retrieve by Object Identifier (OID) to access it in the Measure Authoring Tool (MAT).

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

Yes, within Clinical Quality Language (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.

There is currently tooling to support authoring, parsing, and validation of CQL. There are open source tools available to evaluate Expression Logical Model (ELM) for both the JavaScript and Java platforms. There is also a .NET toolkit for ELM that can support translation and evaluation.

Developing the measures in Java, C#, or any other commercially supported language would not achieve the goal of sharing the measure logic in a platform independent way, nor would it serve as a vehicle for communicating the intent of the measures in the way that CQL/ELM does. Traditional programming languages do not support the required set of operations for expressing measure logic, and traditional query languages, though closer to the mark, still do not support important aspects like terminology and interval-based timing. Refer to the GitHub tooling repository for additional guidance.

Yes, available at the GitHub tooling repository. Also review:

JavaScript Open Source Engine

Java Open Source Engine

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.

Clinical Quality Language (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.

CQL writes 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 Quality Data Model (QDM) element.

While measure developers can write text documents using the CQL library, they are encouraged to use tooling to support CQL development. The MAT provides the structure to make writing easy beyond having a text document. It helps with available operations and acceptable attributes from the Quality Data Model (QDM) element.

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 Extensible Markup Language (XML) or JSON. There is tooling in the GitHub repository 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.

If a user creates Clinical Quality Language (CQL) statements freeform in the 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 the MAT to create the intervals, then the tool will insert the CQL logic with appropriate syntax and styling.

The MAT exports CQL, Expression Logical Model (ELM), and JavaScript Object Notation (JSON) file artifacts. Refer to the MAT User Guide for additional MAT-specific questions.

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.

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

Yes, it is. Specifically, in this Clinical Quality Language (CQL) Formatting and Usage Wiki source. In addition, the function is available as part of the MAT Global Common Functions library in the MAT and in the CQL Style Guide.

The ability to do this is currently in the MAT by creating a standalone Clinical Quality Language (CQL) library and including this function within it. Also calling it out as needed. The current Global Common Library includes a LengthInDays function for this purpose.

This editor is called Atom, a desktop general purpose editor. We built a syntax highlighter editor for it. It works well, does not give validations, but the Measure Authoring Tool (MAT) has that functionality embedded.

Measure developers maintain and publish terminologies to the Value Set Authority Center (VSAC). They are distributed with measure definitions as part of the overall process. Those value sets are updated not just when the measures are published, but also periodically to capture additional terminology changes.

LOV means List of Values and is another name for value sets. However, value set is the appropriate term. The Value Set Authority Center (VSAC) maintains the value set definitions including codes involved and versions of the terminology those codes came from, hence extensions are determined with versioning in mind.

The CQL specification defines the high level CQL grammar as well as the schema for Expression Logical Model (ELM). For source code, we have reference implementations in production use in the Measure Authoring Tool (MAT) and Bonnie testing tool. The source code for the CQL-to-ELM translator is available in the Clinical Quality Framework (CQF) GitHub repository. For evaluation, a JavaScript CQL interpreter is used to evaluate the measures within the Bonnie testing tool. There is also a .NET-based framework that was built as part of the Heath eDecisions initiative. It is a little outdated but provides a general framework for language processing applications for ELM.

The Clinical Reasoning Module provides guidance on using CQL with FHIR in general, as well as how to use the quality-related resources (Measure, PlanDefinition, ActivityDefinition) to express, share, and evaluate quality-improvement artifacts in FHIR.

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 Health Level Seven International (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.