Adds options for 2020-2022 AHRQ Elixhauser versions

[fiksdala]

Hi @ellessenne,

Our team at Brigham and Women's Hospital (principally myself, @kravvaz, and @salmasian) have been developing a fork of this package that can replicate the functionality of AHRQ's SAS program for computing Elixhauser comorbidities (see https://www.hcup-us.ahrq.gov/toolssoftware/comorbidityicd10/comorbidity_icd10.jsp for their work). We have been using this fork in our internal work since mid-2020, and think it is now in a state where we can pursue a formal pull request. In short, these modifications allow for replicating the mappings for the 2020, 2021, and 2022 versions of the AHRQ Elixhauser SAS programs, and scoring algorithms for the 2022 version (separate scoring programs do not exist for 2020 and 2021).

While we have prepared our code such that it is mergeable and fully functional (as far as we know) with your project and its updated API, it is a substantial PR. As the package author, we want to make this process as easy as possible for you. As such, if you'd prefer to discuss this "offline" prior to moving forward with the PR, we'd be more than happy to do so. Any feedback on the code we've put together or requests for alterations are of course very welcome as well.

If you have any other questions as you review this PR, please do not hesitate to get in touch.

Kind regards, Alex Fiksdal

[ellessenne]

HI @fiksdala, @kravvaz, @salmasian: first of all, thanks for the massive amount of work behind this. I will review this in the next few days, so please bear with me just a little longer. In the meantime, after a quick skim through the PR, it looks like this follows the "old" logic behind the scenes, so it likely will require some adjustments (which I can work on, no problem). I had been thinking about how to effectively implement the AHRQ algorithms for a while now, actually, and given that it is not simply an ICD-based score anymore (using all sorts of other information) I was wondering if it would be better to have a separate ahrq() function, calling the same internal scoring functions that are used by comorbidity(), still returning a comorbidity-like object to be used, e.g., with score(). What do you think about it? Happy to have a quick chat if that works better for you all. Thanks,

Alessandro

[ellessenne]

Hi everyone, just wanted to let you know that I forked this PR, where I'll be reviewing/editing: https://github.com/ellessenne/comorbidity/tree/updated_elixhauser

[fiksdala]

Hi @ellessenne,

Thanks again for reviewing this PR and for your feedback. I'd like to check in again on this and see if you have any more thoughts on the best path forward. If reconfiguring the package to use a separate ahrq() function to handle the AHRQ releases still seems like the best option, I'd be happy to have our team get started on that right away. I just want to make sure you haven't already been working on that approach before we assign the time/resources. Happy to chat about other options as well if you'd like.

Thanks! Alex

On Tue, Mar 8, 2022 at 11:26 AM Alex Fiksdal @.***> wrote:

Hi @ellessenne,

Thanks for your quick response! Yes, while I have adjusted the code to be compatible with the new API, because the AHRQ algorithms are not based on simple ICD-matching it cannot fully mimic the approach used with Charlson in comorbidity(), for example. I think your suggestion of using a separate ahrq() function makes complete sense in light of these complexities and will make maintenance easier as new AHRQ versions are released annually. If it makes things easier, we'd be happy to make that change, just let me know.

Thanks! Alex

On Tue, Mar 8, 2022 at 1:58 AM Alessandro Gasparini < @.***> wrote:

HI @fiksdala https://github.com/fiksdala, @kravvaz https://github.com/kravvaz, @salmasian https://github.com/salmasian: first of all, thanks for the massive amount of work behind this. I will review this in the next few days, so please bear with me just a little longer. In the meantime, after a quick skim through the PR, it looks like this follows the "old" logic behind the scenes, so it likely will require some adjustments (which I can work on, no problem). I had been thinking about how to effectively implement the AHRQ algorithms for a while now, actually, and given that it is not simply an ICD-based score anymore (using all sorts of other information) I was wondering if it would be better to have a separate ahrq() function, calling the same internal scoring functions that are used by comorbidity(), still returning a comorbidity-like object to be used, e.g., with score(). What do you think about it? Happy to have a quick chat if that works better for you all. Thanks,

Alessandro

— Reply to this email directly, view it on GitHub https://github.com/ellessenne/comorbidity/pull/52#issuecomment-1061467870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIXMBPRZPX5GLP2ZHSIGUTU633BJANCNFSM5QET6VVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[ellessenne]

Hi @fiksdala, sorry for being slow – I've actually had very little time to work on this.

I have some early feedback though: for what I've seen, the current PR simply wraps the old API for AHRQ. I think that should be recoded to use the new internal functions, rather than using the old ones, as (1) it would be very hard to maintain and (2) the new API is actually faster than the old one. Do you think you would be able to recode your implementation to do that?

The matching algorithm is now abstracted out as the internal .matchit() function: in my head, it should be possible to call this function to both ICD and DRG codes first, with appropriate mappings (something added to the .maps internal list, see e.g. here), and then combining the results in a single "matrix" of results. What do you think?

[fiksdala]

Hi @ellessenne,

Thanks for this feedback, very helpful.

I like the idea of this approach, but given that recent AHRQ mappings are not necessarily 1:1 (in the sense of 1 ICD always translating to 1 comorbidity), I'm not sure if using the internal mapping functions in their current form is possible. In the 2020 AHRQ version, for example, some ICD -> comorbidity mappings depend not only on single ICDs and DRG but also the presence or absence of other ICDs. In the 2022 version, the mappings appear somewhat more straightforward, but also depend on POA status and involve the computation (and eventual collapsing) of intermediary "comorbidities" that are not included in the final output. From what I understand of the current internal mapping functions, they utilze regex methods to make 1:1 mappings of ICDs to comorbidities, which is not conducive to the sort of logic employed by recent AHRQ releases.

I'll need to take some time to investigate this further to determine if we can leverage existing internal mapping functions for recent AHRQ releases. If not, perhaps some dedicated methods for AHRQ releases may be required to ease maintenance and simplify the code.

I'll get started on this and let you know what we come up with.

Thanks, Alex

On Fri, Jun 17, 2022 at 4:47 AM Alessandro Gasparini < @.***> wrote:

Hi @fiksdala https://github.com/fiksdala, sorry for being slow – I've actually had very little time to work on this.

I have some early feedback though: for what I've seen, the current PR simply wraps the old API for AHRQ. I think that should be recoded to use the new internal functions, rather than using the old ones, as (1) it would be very hard to maintain and (2) the new API is actually faster than the old one. Do you think you would be able to recode your implementation to do that?

The matching algorithm is now abstracted out as the internal .matchit() function: in my head, it should be possible to call this function to both ICD and DRG codes first, with appropriate mappings (something added to the .maps internal list, see e.g. here https://github.com/ellessenne/comorbidity/blob/master/data-raw/make-mapping.R), and then combining the results in a single "matrix" of results. What do you think?

— Reply to this email directly, view it on GitHub https://github.com/ellessenne/comorbidity/pull/52#issuecomment-1158647410, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIXMBN5ISH246XJDMKSQOTVPQ3SZANCNFSM5QET6VVQ . You are receiving this because you were mentioned.Message ID: @.***>

[salmasian]

@fiksdala here is what I suggest to facilitate this discussion: if you could provide a few examples of those non-linear relationships between ICD codes and comorbidities in the AHRQ 2020 definition, that could help.

As for the POA piece, obviously, you can first eliminate the ICD codes that are not matching the POA logic, and only then pass the remaining list to the mapping function, but again, if these mappings are non-linear (and involve intermediary logic that cannot be handled by the new API) you should provide some examples.

[ellessenne]

Hi @fiksdala and @salmasian, Thanks for the feedback. With other scores, there is already a 1:n relationship between ICD codes and comorbidity in some settings (e.g., a single ICD code that is used by two domains), so that would not be a problem I think. The rest of the AHRQ algorithm, however, seems to deviate much more from the standard comorbidity approaches. Maybe a separate function/implementation for the AHRQ scores might be the best solution here?

[fiksdala]

Hi @ellessenne,

I agree that a separate function for AHRQ scores is the best solution. My bandwidth is going to be significantly limited for the next few weeks, but I should be able to start work on this by the end of August. I'll reach out again when the updated code is ready for feedback.

Thanks, Alex

On Mon, Jul 11, 2022 at 4:46 AM Alessandro Gasparini < @.***> wrote:

Hi @fiksdala https://github.com/fiksdala and @salmasian https://github.com/salmasian, Thanks for the feedback. With other scores, there is already a 1:n relationship between ICD codes and comorbidity in some settings (e.g., a single ICD code that is used by two domains), so that would not be a problem I think. The rest of the AHRQ algorithm, however, seems to deviate much more from the standard comorbidity approaches. Maybe a separate function/implementation for the AHRQ scores might be the best solution here?

— Reply to this email directly, view it on GitHub https://github.com/ellessenne/comorbidity/pull/52#issuecomment-1180129112, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIXMBIQGGC3RM7R67WLLQ3VTPNMZANCNFSM5QET6VVQ . You are receiving this because you were mentioned.Message ID: @.***>

[ellessenne]

Hi @fiksdala, No problem at all, my bandwidth is also unfortunately limited. I wonder if we should brainstorm a bit on how to implement this functionality before spending time on coding, actually? Thanks,

Alessandro

[fiksdala]

Hi @ellessenne,

Apologies for the long delay. I'd be happy to brainstorm and map out our approach. Do you have a preference for when and how we go about doing that? I'd be happy to set up a call, but I know we'd have to be mindful of our time zone differences (I am located in Boston, MA USA) and busy schedules. If you'd like to chat, please let me know your availability and we can get started on the scheduling. If you'd prefer a more asynchronous approach, we could certainly do that as well.

Thanks, Alex

On Fri, Jul 22, 2022 at 9:21 AM Alessandro Gasparini < @.***> wrote:

Hi @fiksdala https://github.com/fiksdala, No problem at all, my bandwidth is also unfortunately limited. I wonder if we should brainstorm a bit on how to implement this functionality before spending time on coding, actually? Thanks,

Alessandro

— Reply to this email directly, view it on GitHub https://github.com/ellessenne/comorbidity/pull/52#issuecomment-1192568333, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIXMBKA77ZRNLR5LZVIJRLVVKN55ANCNFSM5QET6VVQ . You are receiving this because you were mentioned.Message ID: @.***>

[ellessenne]

No worries @fiksdala! I think setting up a call will make things easier at the beginning, but I won't be able until later this month (at the earliest), unfortunately. Time difference should be manageable if we set something for, say, 10 am Boston time (4 pm here in Sweden if I am not mistaken).

After a call, I think it would be easier (and more effective) to proceed asynchronously. How does that sound?

[fiksdala]

Hi @ellessenne,

That sounds great! I'm also quite busy the rest of this month. Maybe we can shoot for sometime early-ish September? That far out I can make most days at 10:00am Boston time work. Could you send a few dates that would work for you?

Thanks! Alex

On Tue, Aug 16, 2022 at 4:09 AM Alessandro Gasparini < @.***> wrote:

No worries @fiksdala https://github.com/fiksdala! I think setting up a call will make things easier at the beginning, but I won't be able until later this month (at the earliest), unfortunately. Time difference should be manageable if we set something for, say, 10 am Boston time (4 pm here in Sweden if I am not mistaken).

After a call, I think it would be easier (and more effective) to proceed asynchronously. How does that sound?

— Reply to this email directly, view it on GitHub https://github.com/ellessenne/comorbidity/pull/52#issuecomment-1216290730, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIXMBOLI6FY33ABZNQHD5LVZNECRANCNFSM5QET6VVQ . You are receiving this because you were mentioned.Message ID: @.***>

[ellessenne]

Hi @fiksdala, first of all, sorry for the late response! About possible dates, would Sep 13/14 work? 10:00 am Boston time would be okay for me. Otherwise I will have more time from the 27 onwards. Thanks!

Alessandro

[fiksdala]

Hi @ellessenne,

Thanks for your quick response! Yes, while I have adjusted the code to be compatible with the new API, because the AHRQ algorithms are not based on simple ICD-matching it cannot fully mimic the approach used with Charlson in comorbidity(), for example. I think your suggestion of using a separate ahrq() function makes complete sense in light of these complexities and will make maintenance easier as new AHRQ versions are released annually. If it makes things easier, we'd be happy to make that change, just let me know.

Thanks! Alex

On Tue, Mar 8, 2022 at 1:58 AM Alessandro Gasparini < @.***> wrote:

HI @fiksdala https://github.com/fiksdala, @kravvaz https://github.com/kravvaz, @salmasian https://github.com/salmasian: first of all, thanks for the massive amount of work behind this. I will review this in the next few days, so please bear with me just a little longer. In the meantime, after a quick skim through the PR, it looks like this follows the "old" logic behind the scenes, so it likely will require some adjustments (which I can work on, no problem). I had been thinking about how to effectively implement the AHRQ algorithms for a while now, actually, and given that it is not simply an ICD-based score anymore (using all sorts of other information) I was wondering if it would be better to have a separate ahrq() function, calling the same internal scoring functions that are used by comorbidity(), still returning a comorbidity-like object to be used, e.g., with score(). What do you think about it? Happy to have a quick chat if that works better for you all. Thanks,

Alessandro

— Reply to this email directly, view it on GitHub https://github.com/ellessenne/comorbidity/pull/52#issuecomment-1061467870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIXMBPRZPX5GLP2ZHSIGUTU633BJANCNFSM5QET6VVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[fiksdala]

Hi @ellessenne,

No problem at all with your response times, as you can tell from my own late responses things are quite busy for me as well so I completely understand (and apologies for my own delays here). I think the rest of this month will likely be too busy for me, but October should be much better. Would Tuesday October 4th at 10:00am EST/ 4:00pm CET work for you?

Thanks! Alex

On Tue, Sep 6, 2022 at 4:17 AM Alessandro Gasparini < @.***> wrote:

Hi @fiksdala https://github.com/fiksdala, first of all, sorry for the late response! About possible dates, would Sep 13/14 work? 10:00 am Boston time would be okay for me. Otherwise I will have more time from the 27 onwards. Thanks!

Alessandro

— Reply to this email directly, view it on GitHub https://github.com/ellessenne/comorbidity/pull/52#issuecomment-1237813212, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIXMBKALNZEHBZ65YSCHP3V4342RANCNFSM5QET6VVQ . You are receiving this because you were mentioned.Message ID: @.***>