Good afternoon, my name is Amira Elhagmusa with ESAC/Battelle. Thank you for joining this webinar titled:
"A Side-by-Side Comparison of an eCQM for Eligible Professionals and Eligible Clinicians Using Clinical Quality Language (or CQL)".
Today's session will be presented by Shanna Hartman from CMS and Bryn Rhodes with ESAC, Incorporated.
Just a few administrative notes: today's meeting is being recorded. Attendees are muted. At the end of the session,
a feedback form will appear. Please take a few minutes and tell us how we did. We appreciate your feedback.
Throughout the session, you can use the question and answer feature of WebEx to submit questions.
A question and answer period will occur at the end of the session. I'd like to now turn it over to Shanna Hartman from CMS. Thank you.
Thanks, good afternoon everyone and welcome.
Thanks for joining us today for our webinar for Eligible Professionals and Eligible Clinicians eCQMs using CQL.
After I provide a brief overview of CQL, I'll be passing the presentation off to Bryn Rhodes
who will be giving a walkthrough of two measures – CMS 68 Documentations of Current Medications in the Medical Record
and CMS 124 Cervical Cancer Screening using the CQL expression and comparing the same measures logic using QDM.
Next slide please.
Next slide please.
CQL is a Health Level Seven International (HL7) standard
and aims to unify the expression of logic for electronic clinical quality measures and Clinical Decision Support.
CQL provides the ability to better express logic defining measure populations to improve the accuracy and clarity of eCQMs.
Benefits of CQL are listed below. Improved expressivity. More precise and unambiguous. Can share logic between measures.
Can share logic with decision support. Can be used with multiple information data models and simplifies calculation engine implementation.
Next slide please.
Next slide please.
As of November 2017, following more than one year of testing and input from the vendor and implementer communities,
eCQMs in CMS quality programs will be transitioned to use the CQL standard for logic expression.
The transition to reporting CQL-based measures will begin with the calendar year 2019 reporting period
for Eligible Hospitals and Critical Access Hospitals, and calendar year 2019 performance period
for Eligible Professionals and Eligible Clinicians participating in the following programs:
the Hospital Inpatient Quality Reporting Program (or IQR),
the Medicare Electronic Health Record (EHR) Incentive Program for Eligible Hospitals and Critical Access Hospitals,
the Medicaid EHR Incentive Program for Eligible Professionals, Eligible Hospitals, and Critical Access Hospitals
as well as the Quality Payment Program: the Merit-based Incentive Payment System (MIPS) and Alternative Payment Models.
To support this transition, CMS will be publishing CQL-based eCQMs in Spring 2018.
Next slide please.
Next slide please.
This illustration is one of the ways we represent the evolution of the current standard
using and creating the electronic specifications for the eCQMs.
On the left is the Health Quality Measure Format (HQMF) which is the basic electronic specification for the measure.
The Quality Data Model (QDM) provides information to help finalize the HQMF and is divided into two parts:
the data model and the logic. That is the current standard on the left through calendar year 2018.
Now that we're moving to CQL, the HQMF will continue to provide the metadata and population structure,
and the QDM will still provide the data model, but CQL will represent the logic used in the HQMF
depicted in the picture on the right beginning calendar year 2019.
depicted in the picture on the right beginning calendar year 2019.
Next slide please.
Next slide please.
This is a general timeline that CMS and our stakeholders are looking at through 2020.
During this time, we will be creating eCQMs with CQL and have an expanded testing and development process of CQL and tools.
As part of the education and outreach about CQL, we want to engage you all about this standard and we continue to incorporate
the standard into the measures.
Thank you and I will now pass it on to Bryn to continue the presentation and provide a more in-depth review.
Thank you and I will now pass it on to Bryn to continue the presentation and provide a more in-depth review.
Thank you, Shanna.
Thank you, Shanna.
Alright, so I'd like to start today by answering this question "What is Clinical Quality Language?"
Alright, so I'd like to start today by answering this question "What is Clinical Quality Language?"
And to start this, we'll come at this from the perspective of quality measurement.
And so, if you look at the current health quality measures format normative specification,
it defines a quality measure as a quantitative tool to assess performance related to a specific clinical process or outcome.
it defines a quality measure as a quantitative tool to assess performance related to a specific clinical process or outcome.
So, there are lots of quality measures, and lots of different kinds of quality measures that have been used through these programs.
Some of them are based on current processes and chart abstracted measures.
We are focused here on electronic clinical quality measures, specifically those measures that we can represent
represent in an electronic format that can be imported and as much as possible,
automatically computed from the information available in the health information systems.
So, narrative descriptions of the quality measures are good, but electronic representations are better
in that they more precisely describe the intent of the measure both in terms of the data involved,
and the relationship and criteria defined for those data.
and the relationship and criteria defined for those data.
So, looking at CMS 68, the description, it's a fairly straightforward description
involving a percentage of visits for patients aged 18 years and older
where the eligible professional documents current medications.
where the eligible professional documents current medications.
So again, that's a narrative description that's fairly broad
and there's a lot of information packed into that.
A lot of information about context and process of care that are going on.
So, to represent this electronically, we break this information down into different categories.
Questions about the description, who said it, when did they say it,
what evidence supports it, these are metadata.
Questions about the content of the description, what kinds of things does it talk about,
so it's talking about prescriptions, talking about patient visits and what do those things look like.
What attributes and properties do medications have.
Those questions we described as or categorize as the data model,
the things that are in the measure, and then what are the relationships between them.
So, a prescription was documented at a patient visit. What criteria applied to them
and this occurred at all visits that happened during this measurement period.
And those kinds of questions and relationships we describe as the logic.
And those kinds of questions and relationships we describe as the logic.
So, looking at these three categories of information,
and thinking about how we represent this physically,
in the current specifications that we're using through calendar year 2018,
the health quality measures format is used to represent the metadata
and then we use the quality data model version 4.3 currently
to represent both the data model, the things that we talked about in the measure
and the logic, the relationships between those things.
and the logic, the relationships between those things.
So, what we've done is evolve the logic portion of the quality data model
into a separate specification called clinical quality language.
into a separate specification called clinical quality language.
HQMF in the new specifications beginning calendar year 2019
is still used to represent the metadata,
and quality data model is still used to represent the data model,
the things that we're talking about.
the things that we're talking about.
So, throughout this presentation,
we use the term current specifications to refer to the current stack or QDM based,
and the term new specifications for CQL based to refer to the updated specification.
HQMF normative released clinical quality language STU release 2
and quality data model v5.3.
and quality data model v5.3.
So just a brief overview of how we represent the data model.
The quality data model is conceptual information model.
So, broadly speaking it allows us to talk about clinical statements.
So, the first step there is to categorize those statements
so we can talk about things like laboratory tests and diagnostic studies.
And then we can introduce a context where we can say was it performed or was it ordered.
So, we can say a laboratory test was performed or a medication was administered.
And then we further refine that as a data element
by binding it to a terminology like LOINC or SNOMED.
So, we can say a particular kind of laboratory test was performed
or a particular medication as identified by a RXNorm code was administered.
And then finally, QDM defines the attributes that are available in the properties,
so for a laboratory test we may have the results or for a location arrival time,
sorry, for an encounter performed, we may have a location arrival time.
So, looking at, for example, encounter performed
this is the 5.3 QDM version of encounter performed,
these are the attributes then that are available and the description from QDM
of the kind of data elements that would meet this criteria.
So, we can see there things happening like the admission source and the diagnoses.
Note that we have relevant period and this is different than
the fourth reversion of encounter performed in that
relevant period is an interval value so it has a start and a stop.
You'll see that kind of change throughout the QDM 5.3 version,
and the reason is that CQL supports direct interval operations
and so having them modeled as intervals makes
the expression of logic simpler for some comparisons.
Note also there are plural attributes, so
a diagnoses, an encounter performed may have multiple diagnoses associated with it.
And you can also reference the IGs
so you can talk about a specific instance of the data element
and you can talk about a code including the ability to us direct reference codes
from terminologies, we'll look more at that later in the presentation.
So then, looking at the logic and how we then represent that logic so it can be shared and distributed,
within QDM in the current version, we specified the logic as part of the model.
With CQL we've broken that logic out into a separate specification,
by doing that, we can isolate the impact of changes to those specifications for example, we can introduce new operations into the logic,
without having to change QDM and we can introduce changes into QDM without having to change the logic specification.
And in the same way that QDM is independent of the terminology, the logic specification can reference any terminology.
So with that as kind of background, then we say that CQL is a standard language for expressing clinical knowledge that is readable,
a domain expert should be able to look at it, read and understand what a given CQL expression is saying.
It's shareable in that it can be distributed from machine to machine and understood. And it's computable in that
a machine can understand the semantics of the expression, the meaning of the expression and actually evaluate
and calculate the measure without a developer having to build the logic to do that.
So, we'll start the measure tours.
These will be side-by-side reviews of current eCQM specification using 4.3
and the new eCQM specification using QDM 5.3 and Clinical Quality Language
and as Shanna mentioned, we'll tour two measures: CMS 68 and CMS 124.
We'll just note that these draft eCQM specifications are not intended for submission
of 2017 or 2018 performance reporting programs.
Updated eCQM information is available on the eCQI Resource Center website.
[No audio on slide 17]
So, the first thing we'll look at is the measure package.
When you have the measure, the eCQM distributed comes in a package that can change multiple files.
For the QDM-based measure, we have the HTML which is the human readable, that's the webpage that you typically look at
to see a description of the measure, and you have the dot-xml which is the health quality measure format document,
that's the actual machine-readable version, and then you have simple XML which is a simplified version of that
of the logic involved, that's intended to help implementers. For the CQL-based, you still have the human readable, that's the HTML.
that's the HTML, we'll look at some examples of those. Then the XML, the HQMF document is still present,
but the logic portions are referenced from the HQMF and they point to expressions that are defined in the CQL
and the expression logical model which is a machine-readable rendering analogous to the simple XML from the previous specifications,
And we make those machine-readable specifications available in both XML and JSON.
Note that CQL also includes a libraries feature so that measure logic can be shared between measures
and when a measure uses libraries, it will include the CQL and ELM artifacts for all the libraries that it references.
Another note that file naming conventions, which in these measure packages are still being finalized,
those will be posted to the eCQI Resource Center once they are available.
So, they might not look exactly like that, but they will be, generally those are the files that will be available in a measure package.
So, looking at the human-readable, the metadata for the measure
is largely the same between the current specifications and the new.
There are very few changes in the metadata.
For the measure contents, we have in the QDM-based,
the population criteria and the data criteria supplemental data and risk adjustment. For the CQL-based,
we still have the population criteria. We'll look at that next. But the data criteria section is now a definitions section
that contains the expression definitions that are used throughout the measure. The function section contains any
functions that are defined and used by the measure and then a terminology section that captures
all of the terminology referenced throughout the measure whether it's within a data criteria, or down to an attribute comparison
or direct reference codes. The data criteria section is largely the same.
And then there are some changes to the supplemental data elements and risk adjustment variables
that allow us to express those more selectively and we will look at those.
So, this is side-by-side of the QDM-based and the CQL-based for this measure for the population criteria.
So, you can see they have the same kinds of populations. We didn't change anything about that, that's still specified by the HQMF.
So, for each kind of measure, you have the appropriate populations specified, initial population, denominator, and so on.
The human readable, note, has some new formatting and it's a new feature, it's a collapse and expand.
And you'll also see some new constructs like this function "AgeInYearsAt" where we use parentheses to denote a function.
You'll see expression definitions so, encounters during measurement period. And you'll also see queries so,
the use of aliases like encounter here, and we will dig more into those in subsequent slides.
So, this is the declaration section for the CQL library for this measure. It provides the name of the library and the version of it.
It says what data model we're using, in this case QDM. All of the measures in this particular program will use QDM version 5.3.
And then it lists the value sets involved. You can also see the parameter of measurement period.
This is so that the logic can reference the measurement period and parameters expected to be provided
as part of the reporting execution. And then you can see the context to patient meaning all the expressions in this library will be
written from the patient perspective, from the perspective of a single patient.
So digging into the initial population, uh, comparing the QDM-based and the CQL-based.
You can see encounters during measurement period is reference to an expression definition. We'll look at that more on the next slide.
We also use, uh, we introduce comparisons and the same types of comparisons that you would expected to see.
You can see it's quite similar in terms of the general description of that initial population. Know that this returns, a list of encounters,
not a yes or no. This is typical of episode of care or encounter based measures where the measure,
the members of the population are actually encounters rather than patients. So in this case,
the description of the measure begins as percentage of visits,
as opposed to a patient base measure description that would begin with percentage of patients.
So this is an example of the types of expressions you can use within CQL. You can, you'll see logical expressions,
um, I can say A and B are both true. I can perform comparisons of values like numbers and strings
and I can perform a arithmetic. Note that the order of precedence that you'd expect applies. So this A plus B times C for example,
um, will be evaluated as B times C and then plus A in the standard mathematical approach.
So digging deeper then into encounters during measurement. Um, the QDM-based representation of this
Occurrence A of encounter performed in the medications encounter code set during the measurement period.
The CQL-based is very similar. We just say encounter performed in the medications encounter code set.
Uh, and we use a query to introduce this encounter alias and that allows us to talk about the relevant period of the encounter
and say that it's during the measurement period. We'll look at, we'll hit that a little bit more later.
And, in this slide, we want to point out, um, in CQL, specific occurrences are no longer required
because we just referenced the expression definition that identifies the instance we want to talk about.
And so wherever we need to reference that, then we use that expression, that same expression definition.
So digging deeper into the actual data elements here, encounter performed medications encounter code set,
this has data criteria from the current QDM but within CQL you'll see it limited to using the square bracket.
So anytime you see the square brackets around a data type name like this, uh, you know that what we're doing is actually
asking the information system for that data. There are two components of that data criteria, the first is the type,
so based on the data model that we're using, you specify a particular type, encounter performed in this case
and then the second part of that is the value set or the terminology. In this case, it's a reference to a value set
but CQL does allow you to specify a direct reference code there, or you can just use a single code from a terminology.
So the result then of this retrieve, is the set of data elements of that type that have a code that matches terminology.
So, coming back out to the encounters during the measurement period. This is again a set of encounters as opposed to yes, no.
And so if we want to combine sets of encounters, we use intersect and union, um, you've seen those in QDM logic
but this is, as opposed to criteria, true or false, which are combined with the logical operators and and or.
This is also a query so digging into that a little bit. The query is introduced with this encounter alias right after the retrieve.
What that does is provide an identifier that we can use to then reference the data elements that come back from this retrieve.
So you can think of this as saying for every encounter performed in the medications encounter code set,
tests whether the relevant period of that encounter is during the measurement period.
And only return that encounter if that test is true.
So digging into that where clause just a little further. The property that we're able to access here is defined by the quality data model,
so the fact that we can say relevant period here is because quality data model says that encounters performed
have a relevant period property. Note that we said that that was interval valued meaning that the relevant period has a start and a stop.
And because it's an interval, we can use an interval operation during, to compare it to the measurement period, which is also an interval
from the start of the year to the end of the year.
There are other, other timing operations we can we can perform with CQL so we'll dig a little bit into those.
Specifically, we can perform comparisons between uh, two date time values. So I can ask if the author date time is less than
the author date time of an assessment. Um, I can also ask if a date time value is during an interval.
Um, I can also compare intervals with the date time, so I can ask whether this interval of a relevant period
includes an author date time assessment. and I can also compare interval two intervals directly.
as, as we saw in the encounters during measurement period. And this says that this relevant period interval
is entirely included in this measurement period interval.
Other examples of, of timing and intervals that you'll see in CQL are, one, the full set from QDM,
So you can say things like starts before start, and those will be familiar from the QDM logic. You can also use timing phrases
So I can say starts three days before start or starts within three days of the start. And then, uh,
there are direct interval comparison operators. So in addition to during, you can say things like meets and overlaps.
You can also access the boundaries so the start of the end of an interval. And you can also do membership testing with the ends
so I can ask if some value is in an interval. And, note that it is possible to represent, um, integer intervals or decimal intervals
or even quantity intervals within CQL.
So then looking at the numerators. Uh, again the results of the numerator expression here is a list of encounters.
So, because this is an encounter-based measure, all of the top level population criteria have to return a list of encounters.
Nope, we're still evaluating the inpatient context, so this expression is written from the perspective of a single patient.
And this is different from QDM in that the return type is important because it informs how the expression can be used later on.
In QDM the return type was not as clear.
So looking at the denominator exceptions for this measure. Uh, again, we start with encounters during the measurement period.
So rather than using a current day like we are doing with QDM here, we start with the same set of measures that we use to define
initial population and the denominator. Uh, and then we use a width, which is a way within CQL to define the relationship between two
sources. So, this is saying the encounters during the measurement period with medications not documented
for medical reason. So this is in reference to another definition. Such that the meds author date time
is during the encounter's relevant period. So again, we're using in the medication is not documented for medical reason
a retrieve of procedures not performed in current medications documented SNOMED value set.
This is different than the way that negation was represented in QDM. QDM uses procedure performed, not done
for medical or other reason for current medications documented. For consistency with the other procedure performed
with the positive expressions, um, we use the same approach, we just include the modifier not,
so this is procedure not performed in the value set. And then we use the negation rationale attribute
of that procedure to indicate medical or other reason not done.
of that procedure to indicate medical or other reason not done.
So looking at the data criteria section, um in the QDM-based, we specify all the data criteria.
In the CQL-based we do the same except we also include data criteria that are used in defining supplemental data elements.
We will look at those a little bit later. Note that in the QDM-based, there were issues of attributes.
Those are no longer referenced in the data criteria sections, so if you've seen those in the QDM,
those are referenced in the terminology section, which is only present in the CQL
and this contains all of the value sets that are referenced by the measure as well as any direct reference codes.
So for example, the medical or other reason not done value set, is only referenced within the logic, it's not referenced in a data criteria.
So it shows up in this terminology section to make sure that we have a complete picture
in human readable of the terminology as referenced by the measure.
So looking at the supplemental data section. As we mentioned, we include the data criteria, uh, in the data criteria section
and then in the supplemental data we reference expressions, just like we do with all of the other population criteria.
And this allows us to be more flexible about how we define what the supplemental data is for a measure.
So these can be any expression then gives us more flexibility in collecting additional information with the measure itself.
And risk adjustment variables use the same mechanism so we can use expressions and all the flexibility of CQL
to describe what risk factors are associated with the measure and how those should be gathered.
So then looking at CMS 124.
So this one is a patient-based measure versus an encounter-based, uh, and this is evident from the description of the measure
where the patient-based CMS 124 says percentage of women 21 to 64 years of age were screened
whereas the encounter-based has percentage of visits for patients 18 or older for which the eligible professional attests.
So we're changing how we calculate the percentage and that's reflected in the return type of the expressions used.
So in the QDM-based, we defined the demographics and then made sure that we had an encounter,
a qualifying encounter during the measurement period.
So in the CQL-based version of that, we break those up into a yes, no for, are they in the demographics,
and that uses the age in years at and the patient characteristic female, and then we define that a valid encounters, that is the
union, of all of those, um, encounters performed and then ensure that those are all during the measurement period.
So again, this is, these are all returning at the initial population. This is returning a yes, no rather than a list of encounters.
So for the exclusions for this measure, we're looking for the evidence of hospice. So, in the encounter inpatient, we have
discharge status, uh, in discharged to home for hospice. Or we're looking for interventions ordered or performed
during that, that overlaps the measurement period for hospice care.
So, this is the CQL expression of that. You will notice this denom exclude, Hospice Exclusions.
What this means is this is a library expression. Expression of hospice exclusions is then used across different measures
and is included here, by the use of a library. You can also see the comparison of the discharge disposition. So,
we can say the encounters performed where their discharged disposition is in this value set or that value set
and that they end during the measurement period. Or that there are hospice care, ambulatory intervention orders
during or ambulatory, uh, interventions performed overlapping the measurement period.
And then we define a hysterectomy procedure and we combine those because hospice exclusions is yes, no,
and hysterectomy procedure is returning a list of procedures combine that using an exist. Say are there any hysterectomy procedures,
yes or no, and then we can combine that logic.
So, measure libraries then allow these definitions to be shared among measures using libraries.
So, the hospice library to find these exclusions and rather than in QDM where we had to, uh, duplicate that logic
between each different measure, we can now share that.
And note again that measure packages will include the artifacts for any libraries that they reference.
So, looking at the numerator for this one, of the QDM representation, and note that it, we have to express it in terms of the data criteria
and specific occurrences. And you can, you can parse out from this what what's going on.
In the CQL-based version, we use the expression definitions to actually name those results
so that it's clear what the intent of each expression is actually looking for. So the numerator then reads
exists a pap test within three years or exists a pap test with HPV within five years.
And then we can dig into what those expressions actually look like, pap test with results
where the relevant period is three years or less before the end of the measurement period, and pap test with results defined as
a laboratory tests performed in the pap test value set. It has a lab test result. And the same with HPV within five years.
That's a pap test with results with an HPV test with results that's the papv test starts within one day of the start of the pap test.
And the patient's age at the start of the pap test is over is 30 or over
and the pap test is five years or less before the end of the measurement period.
and the pap test is five years or less before the end of the measurement period.
So, this is a set of available resources. CQL specification itself is available from HL7 at that link,
CQL-based HQMF IG which provides implementation guidance for how to use CQL and HQMF together with QDM
to represent electronic clinical quality measures and the eCQI Resource Center one stop shop for the most current resources
to support electronic clinical quality improvement. You can find current versions of the QDM specification
as well as CQL related tools and resources and educational events.
Some further tools that are available, there's a CQL formatting and usage wiki, this has contents, there are Q&As,
there are discussion topics and content that's been developed throughout the process of, of, transitioning.
There are also tools repositories for implementers, as well as the measure authoring tool and the bonnie testing tool
and to submit issues for CQL visit, the ONC project tracking JIRA site.
So at this point we will start looking at questions at that time.
For more infomation >> Shapiro: Media outlets acting as propaganda arm for Hamas - Duration: 7:30. 
For more infomation >> 14 rodzajów pochwy, które najprawdopodobniej napotkasz-Healthy For Life 24h - Duration: 6:12. 
For more infomation >> Wineries announce plans for old Red Hook site - Duration: 1:40. 
For more infomation >> How to get TOTS PARTEY for COMPLETELY FREE! (FIFA 18) - Duration: 10:13. 
For more infomation >> Phipps Hosting Fun Camps For Kids - Duration: 4:12. 
For more infomation >> Gift ideas for teachers - Duration: 4:47. 
Không có nhận xét nào:
Đăng nhận xét