CMS HCC Payment Risk Score Weighting by Member Months #453
Conversation
…ment_risk_score by member months
|
Workflow has finished with the following statuses:
|
There was a problem hiding this comment.
Hi @pfehlinger, I'm sorry for the delayed review while I was out on PTO. This is looking really good! This solution makes a lot of sense, and I like how you calculated the member months for the total year.
I appreciate your comments about creating a dependency between CMS HCC and Financial PMPM. I'm not super concerned about this. We have other marts that have dependencies as well. We use the data type variables (claims_enabled / clinical_enabled) to help control this. In theory, someone has to have claims in order to run both CMS HCC and Financial PMPM.
I left two comments with requests for changes. I am running the CI testing as well to make sure the syntax works in the other data warehouses we support.
| patient_id | ||
| , cast(substr(year_month, 1, 4) as integer) as eligible_year | ||
| , COUNT(1) as member_months | ||
| from {{ ref('financial_pmpm__member_months') }} |
There was a problem hiding this comment.
One of our design patterns is to include an ephemeral staging model for every data mart. You can think of this as an "input layer" for the data mart. This helps with documentation and mapping.
You can see in the staging folder for this mart that we are referencing models from Core. Can you add a new staging model for financial_pmpm__member_months? You can then replace your reference in this CTE with the staging model. I would name it something like cms_hcc__stg_financial_pmpm__member_months.
| , cast(substr(year_month, 1, 4) as integer) as eligible_year | ||
| , COUNT(1) as member_months | ||
| from {{ ref('financial_pmpm__member_months') }} | ||
| group by |
There was a problem hiding this comment.
Can you add a payment_year filter to ensure that the member months being used in this calculation are from the correct date range? You can see how we do this in the intermediate model for eligibility. You can include the Jinja code for payment year at the top and then add a where clause to make sure your eligible_year matches the payment_year.
|
Workflow has finished with the following statuses:
|
|
Workflow has finished with the following statuses:
|
Describe your changes
This resolves #337 by adding two new columns to
cms_hcc.patient_risk_scores:member_monthsandpayment_risk_score_weighted_by_months. The member months are derived from the finanicial_pmpm mart, specifically financial_pmpm.member_months, utilizing payment year eligibility. Weighting is simply multiplying thepayment_risk_scorebymember_months. This enables easier membership aggregations as a "population risk score" would now besum(payment_risk_score_weighted_by_months)/sum(member_months). If a member does not have eligibility in the payment year, both fields are NULL.I chose to link to financial_pmpm at the suggestion of @sarah-tuva (thank you!). I am calling this out explicitly in case there are concerns about dependencies between two marts.
The weighting occurs prior to rounding, thus there is a loss of accuracy due to rounding. Technically, the rounding for the score calculations today do not align with CMS rounding, namely rounding to the third decimal after each step. See pg. 11ff. If there is a desire to align with CMS, I would be happy to adjust the code to follow that methodology and update my weighting to align as well.
How has this been tested?
The tuva-demo data does not have 2019 eligibility which is necessary for this implementation. As such, I updated
enrollment_end_datefor patient_id10013incore.eligibilityto be '2019-12-31'. I then executed dbt run --select tag:financial_pmpm and then dbt run --select tag:cms_hcc to confirm the value of 12 was showing formember_monthsand that the multiplication was correct.Reviewer focus
Checklist before requesting a review
(Optional) Gif of how this PR makes you feel
Loom link