@sarah-tuva I plan on working on this as an entry point to contributing to tuva and learning the repository. I want to restate my understanding of the flow of the code and where I think this information will need to be injected to ensure I am on the right path.

1. Eligibility is aggregated up in the _int_members model for the payment year. So an additional column to track months would need to be added to it.
2. In the patient_risk_scores model, a new reference would need to be added to the int_member model to pull in the eligible months and compute a weighted score where we take the score and multiply it by the eligible months. Eligible months would be added as a column to this table.

Questions:

1. There are currently 5 scores represented in the mart model for scores: v24_risk_score, v28_risk_score, blended_risk_score, normalized_risk_score, payment_risk_score. Is the intent to make 10 scores now, a weighted by months for each score? Or just perform for a subset?
2. It appears the code is using the latest eligibility information in the payment year to represent the member's state, was this done to reduce complexity? Asking as how it works at CMS is there isn't a "member level score" per se, but a "member month level score" so sometimes a member can have a full 12 months of eligibility in the payment year but demographic factors or population factors split part way thru. So not sure if this code is intended to handle that edge case or not.

Hey @pfehlinger, this would be a great issue to work on! Thanks for your interest. I just assigned it to you so we know not to grab it.

I think you might want to look at the Financial PMPM mart. We are already calculating member months. It might be nice to join these tables instead of calculating months separately. Let me know what you think.

Answers to your other questions:

1. This is a good point. I think that might be overwhelming. How about just creating a weighted risk score for the final payment score?
2. You are absolutely right. We created a custom "latest eligibility concept" in this mart to simplify things. This is only used to determine a member's demographic risk segment. We do still look at eligible months to determine if a member is a "new enrollee" or "continuing enrollee".

Hey @sarah-tuva I did some work on this and can submit a pull request, however I have a couple of questions and wasn't sure if I should put them on the PR or here:

1. Tuva demo data doesn't have eligibility in 2019 or forward. The payment year used in the demo is 2019 and the way weighted member months work is by using the payment year eligibility, not the collection year eligibility. Thus the demo data is insufficient to be able to truly QA and execute this change. Do you have any recommendations about how to handle this issue? I don't have the ability to use business data, and I am concerned about attempting to generate my own synthetic data and cause issue due to ignorance of all the dependencies.
2. The change would tie the cms_hcc marts to the financial pmpm marts so that one couldn't exist without the other. How does tuva feel about that from a methodology and architecture standpoint? As an external end user, it wouldn't be intuitively obviously to me that the mart wouldn't work, thus my question.

Hi @pfehlinger! Apologies for the delayed response while I was out on PTO. I reviewed your PR and left a few comments. Thanks for calling out the issues with the synthetic data. This has been on our roadmap to improve. We have real datasets that we can test running the PR on. I'll let you know how it goes!