Clarification around OREC="3" fix

[shackbarth]

Hello maintainers! We're very excited about this project, and have been checking the hccpy output against the official SAS version Everything matches up great except for the circumstance where the OREC is "3".

For example,

he = HCCEngine(version="28")
rp = he.profile(["E1169", "I5030", "I509", "I211", "I209", "R05"], 
    age=86, sex="M", elig="SNPNE", 
    orec="3", medicaid=True) 
print(rp["risk_score"])
# output is 2.573 but should be 2.403

When we revert the diff from #32 then the misalignment gets fixed. That change was certainly deliberate and there was a fair amount of conversation that went into it. But the existing code certainly seemed to be able to handle the orec="3" and the SAS code does not have a similar tweak:

hccpy/hccpy/data/AGESEXV2.TXT

Line 72 in 8b52cae

ORIGDS = (&OREC = '1')*(DISABL = 0);

Can you clarify the rationale behind this update? @kevinbuchanjr 's paragraphs in the PR are (I believe) more like caveats than an explanation about what inspired the fix in the first place.

[sethclaw]

Hi @shackbarth, Just a fellow user who is also currently testing the package. I see that you are testing the v28 model but based on their orec value of 3 (Beneficiary insured due to disability and current ESRD), shouldn't they be on the ESRD model and not v28?

I was under the impression that orec in ('2','3') do not come into play with the non-ESRD model.

[shackbarth]

I think in theory a patient could have an "original reason" of ESRD, but after a successful kidney transplant they don't actually have ESRD anymore and should just get run through the v28 model. But, sure, even if that's how the rules are set up, it would be rare.

In any case, even within the ESRD model, the SAS model gives ORIGDS = 1 only when OREC = 1, so this same bug still holds, if it is a bug. We're finding it a bit more difficult to do an apples-to-apples between SAS and hccpy on the ESRD model in general tho.

[sethclaw]

I think in theory a patient could have an "original reason" of ESRD, but after a successful kidney transplant they don't actually have ESRD anymore and should just get run through the v28 model.

Pretty sure they would actually get a post-graft risk score from the ESRD model. You can verify which model a member score was calculated by looking at the risk adjustment factor type code on their MMR record. (C3-C8, I3-I9 are some of the post-graft community score types.)

In any case, even within the ESRD model, the SAS model gives ORIGDS = 1 only when OREC = 1, so this same bug still holds. We're finding it a bit more difficult to do an apples-to-apples between SAS and hccpy on the ESRD model in general tho.

Agreed and would say that this is a symptom of a bigger issue. ESRD is essentially not implemented for hccpy for and only works for those on the Dialysis Model without any Medicaid, original ERSD status (as indicated by OREC in 2,3) or LTI interactions.

I've built out the package for ESRDv24 but intend to clean it up before doing a pull request.

[dr00b]

@shackbarth, thanks for bringing this to our attention. To be honest, I don't recall the rationale you seek. I will try to understand this in more detail and get back to you. If folks are running the model using incorrect assumptions re: OREC, perhaps it makes sense to match the CMS implementation exactly and throw an error message to warn.

@sethclaw Sounds great and thanks for your contributions!

[Short-N]

@shackbarth I agree that it is a bug on CMS's side. I think '3' should be included in the ESRD logic. But until then, aligning with CMS seems the route to go.

[marci660]

any updates on the package for ESRDv24 @sethclaw? 🙏