Adds options for 2020-2022 AHRQ Elixhauser versions #52
Conversation
ensure fork is up to date
add icd10cm_2020_1 ahrq maintenance files add icd10cm_2021_1 ahrq maintenance files add 2021 ahrq function delete duplicate files update directory references in for 2020 convert-sas.R update directory references in make-data.R streamline ahrq 2020 lofregex and add 2021 formats add formats directory for ahrq versions add directory for sas parsing scripts add parameters for 2021 ahrq remove extaneous options ahrq 2021 remove maintenance dir, replace with sas-parse/sas-formats update mapping reference to list produced in get_mappings rename elixhauser_ahrq option to elixhauser_ahrq_2020 update internal data fix ahrq labels in .check_output fix drg_id class = factor error fix ahrq_2020 assertions, add assertions for ahrq_2021, add ahrq_2021 to .check_output add total score column isolate internal/external score calculations and add ahrq2021 support roxygen2 upgrade calculate ahrq using discrete functions fixes POA required with not present logic fix class assertions for tibbles w/spec_tbl_df subclass add assertion for ic10cm_vers values fix exempt matching fixes missing columns error when poa=F fix icd10cm_vers assertion remove missing columns references when poa=F fix cbvd exemptions update documentation update documentation remove testing scripts fix id name error add elixhauser 2021 examples to README
|
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. Alessandro |
|
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 |
|
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
> <#52 (comment)>,
> 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:
> ***@***.***>
>
|
|
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 |
|
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
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGIXMBN5ISH246XJDMKSQOTVPQ3SZANCNFSM5QET6VVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@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. |
|
Hi @fiksdala and @salmasian, |
|
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
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGIXMBIQGGC3RM7R67WLLQ3VTPNMZANCNFSM5QET6VVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi @fiksdala, Alessandro |
|
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
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGIXMBKA77ZRNLR5LZVIJRLVVKN55ANCNFSM5QET6VVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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? |
|
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
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGIXMBOLI6FY33ABZNQHD5LVZNECRANCNFSM5QET6VVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi @fiksdala, first of all, sorry for the late response! Alessandro |
|
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
<#52 (comment)>,
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:
***@***.***>
|
|
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
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGIXMBKALNZEHBZ65YSCHP3V4342RANCNFSM5QET6VVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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