OHDSI Home | Forums | Wiki | Github

Creating HEDIS measures as cohort definitions in ATLAS

Researchers
#8

As I read the measures, I haven’t yet encountered anything I think can’t be directly supported within ATLAS given all of the enhancements that @Chris_Knoll has made to the standard cohort definition module.

I am not familiar with the latest changes by Chris. But to facilitate identifying potential “things that can’t be directly supported within ALTAS” I want to point out some sophisticated aspects of certain HEDIS rules. Representing these may require changes to ATLAS and/or the data model.

Utilization and risk adjusted utilization

HEDIS defines utilization using “member months” as the denominator (e.g. Visits / 1000 member months). Calculation of member months is sophisticated, and depends on administrative data reflecting membership of patients (I am not sure if it is contained in the OHDSI data model); without it, several utilization metrics in HEDIS cannot be correctly calculated.

Resource use

The resource use metrics require “standard price” and “standard cost” values to be available for various services. Factors such as payer liability, member cost sharing, etc. can complicate their calculation. My understanding is that an “average” number is often used, based on some cost algorithm, and the number is updated on some frequency. Do we have a way to store and use cost/price data in ATLAS?

Denied claims

Take the NCS metric in the “Overuse/Appropriateness” group as an example. The metric requires excluding denied claims. Does the data model have a way to represent which claims were denied? Does ATLAS have a way to account for it?

#9

@salmasian

You bring up some good points and these are very important. Scope of ATLAS we are looking into right-now is what is called a ‘Cohort-builder’, i.e. it selects a list of individuals who meet certain inclusion and exclusion criteria. These criteria may be based on demographics, procedure, conditions, visits etc.

Once a cohort has been built - then we can derive/calculated attributes to every individual in that cohort, such as ‘member months’/exposure; or (standard) costs. These are important information required to solve the full-scope of HEDIS needs, but the first step is cohort-builder.

At high-level, the steps would be: (We are at step #1 for now. )

  1. Cohort builder - identify list of person_id’s that meet the inclusion/exclusion criteria
  2. Calculate the attributes of interest for each person in the cohort (member months, costs, services, utilization etc)
  3. Use for downstream calculation, tabulation or visualization: % of individuals with low back pain that had an imaging.

Are there any measures you want to try out - we could prioritize and solve 5 to 10 measures in Atlas? My vote for the top 5 are (ofcourse, each has subsets - and so the actual list is very long):

  1. Chlamydia Screening in Women
  2. Use of Imaging Studies for Low Back Pain
  3. Controlling High Blood Pressure
  4. Immunizations for Adolescent
  5. Comprehensive Diabetes Care (Retinopathy)
#10

There are so many opportunities for the ATLAS cohort builder to assist in measure development as well as measure reporting. The limiting factor in electronic measurement in HEDIS is an ability to electronically specify “eligibility” for any particular measure. In traditional ( e.g. admin claims) HEDIS we use a combination of continuous enrollment within a certain payer as well as encounters within the measurement period. This work (sort of) when limited to claims and payer eligibility files, however the new generation of measures expected in HEDIS 2018 use only the enrollment information to define a cohort for measurement. I expect that the screening measures that currently exist in our EOC domain will likely follow suit, therefore I would love to see and active community debate on layout for attribution.

I would be happy to provide whatever other details that might help the community come to some consensus on building this type of “complex” cohort in a highly standardized fashion. The HL7 workgroup is currently working with us to define but these conversations have just started so now is a perfect opportunity.

P.S. I would vote for Adolescent Immunizations, Pneumococcal Status for older adults, any of the Depression/Chlamydia/Breast Cancer/Unhealthy Alcohol Use Screening measures. I would stay as far away from CBP as possible since there are several version currently in use and the JNC guideline update is expected over the summer which may change the spec considerably (or result in the measure’s retirement)

#11

The data collection for HEDIS Relative Resource Use measures have just been stopped. The measure specifications are still valid, however the data collection and reporting burden were deemed to high for the value of the information that the measures were providing.

#12

The VSAC does not use HEDIS definitions, only those approved for eMeasures stewarded by NCQA. We have all HEDIS value sets as a FHIR resource if you are interested.

We are specifying a select set of HEDIS measures using the CQL-HQMF format as well as convening a tooling workgroup to get these and the QDM-HQMF version to CQL-FHIR (eventually).

#13

The bug with selecting Observation Period criteria has been fixed on ohdsi.org. Version 2.0 of WebAPI will support specifying a observation period start/end date override.

#14

Awesome! Thank you version 2.0

#15

Friends:

Apart from the API, do you guys still need changes to the CDM to cover Healthcare Quality Measures? Daniella has a proposal in for that. Let’s use the upcoming face-to-face for closing out a lot of these.

#16

HEDIS measures are based on Anchor date. @Patrick_Ryan @Chris_Knoll is it possible to do the following in Atlas v2.0

Want to identify cohort of people who are between 50 to 70 years on December 31st 2010

  • Anchor date December 31st 2010. (an observation period: period start is on or Before 2010-12-31, period end is on or after 2010-12-31)
  • Age between age of 50 to 70 as of December 31st 2010: I dont think we can meet this criteria yet. Age computation options are “with age at period start between 50 and 70 (inclusive)” not “with age on 2010-12-31 between 50 and 70 (inclusive)” Would this need an enhancement to Atlas? @anthonysena

See attempt here: http://www.ohdsi.org/web/atlas/#/cohortdefinition/98077

#17

Yes, you can do that now with Atlas 2.0. I’ve made a copy of your definition with the modifications:
http://www.ohdsi.org/web/atlas/#/cohortdefinition/98078

You set your primary event to look for observation periods (as you have done) except you use the option ‘Specify start and end dates’. I set this to specify a 2010-12-31 start and 2010-12-31 end date. Next, I added an ‘Initial event inclusion criteria’ to further restrict the primary events where the person must be between 50 and 70 as of the primary event’s start date (2010-12-31).

Note, when you specify a start and end date, only observation periods that ‘cover’ those dates are returned (ie: observation period start date <= user specified start date and observation period end date >= user specified end date.

#18

Good morning

I think the community may benefit from a workgroup that creates and maintains quality measures.

Thoughts?

#19

I agree. When I first found out about OHDSI and the CDM I thought of the QDM that NQF has developed. They define eCQM in a domain specific language to reduce any ambiguity in the measure definitions. I believe NCQA uses the same measure definitions as well. One interesting opportunity would be to use the measure definition DSL to generate JSON for ATLAS.

FR

#20

I agree.

#21

Thanks for directing me towards this thread Gowtham.

I agree with this workgroup wholeheartedly. As a benefit for the wider project, I think that having an existing library of quality measures would provide considerable incentive for an organization to adopt the OMOP CDM for their data assets.

There’s a number of measures out there for consideration, and part of the fun would be compiling candidates for implementation. See for example, NICE (https://www.nice.org.uk/standards-and-indicators/quality-standards-topic-library)

I don’t think I can make the Georgia F2F, but I’m happy to help make this happen.

Evan

#22

@MauraBeaton

Good evening - would it be possible to create a workgroup that is interested in using Atlas to calculate Quality measures?

#23

Hi all,

just joining this conversation-- I work with Karthik from Columbia where I also over see a lot of our reporting, and we are in the process of building an OMOP instance one of the goals for which is to address quality reporting needs.

In general (having handled a lot of ACO reporting to CMS), the issue ends to be that many measures require specific documentation that is not standardized concepts. For the HEDIS BMI measure for instance, the eligibility and BMI are readily computable but the follow-up for abnormal BMI is difficult to compute (CMS is also recommending against using the previously recommended GPRO codes for these measures now a days). Measures like HTN control, DM control, or cervical cancer screening are readily computable though (since the data elements are already structured and well-defined in OMOP; though outside data is still an issue for many cancer screening tests).

Anyway if there is interest in a working group I would be very interested to join-- I have a strong interest in this work both from ops and research perspective.

Nice to meet everyone!

Kye

#24

Hi all -

Wondering if any of you are heading to the OHDSI symposium. That might be a good venue to coordinate a face to face meeting and possibly strike up a working group in this area. I’m happy to help try to coordinate this. Let me know either on this thread or via PM if you’re interested.

Evan

#25

Yes - @Evan_Minty happy to connect at the symposium.

Regarding Work Group – I think that is a really good idea and we have a WG http://www.ohdsi.org/web/wiki/doku.php?id=projects:workgroups:quality-measures but we have not met yet. The reason is we tried to build a measure at the OHDSI face to face spring 2017 in Atlanta - and found the exercise very difficult.

What we learnt is – that we had two options. Build measures to the detail specification of the measure stewards manual, OR to build measures the OHDSI way. E.g. the HEDIS measure specification manual would be 1,000s of pages, with some measure specification going for 100s of pages - this is difficult, mostly because of the detail. Alternative is to “approximate” it using the OHDSI, by leveraging the OMOP CDM standard vocabularies for example with the hierarchy’s. When we went thru the exercise we concluded that it is possible to build the measures using OMOP CDM, but the level of details makes it difficult and this task becomes not a scientific task, but a technical task that a voluntary community is not interested in pursuing. The general consensus was that it maybe best to do commission this as a paid service.

There were also some additional considerations. e.g. some of the measure specifications required rules like checking for a procedure in the same visit as a procedure. The OHDSI tools like Atlas did not support these rules at that time (but now do! https://github.com/OHDSI/Atlas/issues/454) .

We need a lot of new functionality like above before beginning a workgroup that implements complex specifications e.g. “Gaps in care”. i.e. an eligible Diabetic person who has a gap in HbA1c testing, then we need two cohort (denominator and numerator – and difference between them). HEDIS measure specifications will require the ability to union, intersect or subtract cohorts from each other.

#26

Interesting, thanks.
It strikes me that for ‘reporting’ , where specificity is paramount, we would struggle based on your comments.

But the development of measures that can give insight into care gaps, in a defacto standard data model, would still be of considerable value to any organization considering adoption. The main constraint being expressed here are limitations in ATLAS, as the requirements you’re mentioning could certainly be achieved with a series DB queries (I guess that’s the source of your concern with voluntary labour supply - this isn’t my strength either, but would be a great exercise to push one’s knowledge of the CDM).

I’ll fire some PM’s to the folks on this thread to see if we can find a way to sit down in a couple of weeks.
Best
Evan

#27

We are interested in mapping HEDIS measures to Atlas concept_sets. Is there any further progress on this? We are ready to contribute if others are interested.

regards,
Rajeev

t