WHONET interpretations when MIC is > about amr

[antunderwood]

Sorry posted too soon. See updated message above

[antunderwood]

Is it possible to have a 'conservative' option for as.rsi

as.rsi(....., conservative = FALSE)

[msberends]

Ah, but WHONET is actually wrong there I think.

Fact is, we don't know if the MIC is 4 since it was capped at >=2. If you as a professional would treat it as a potential 4, that's up to you (or your colleagues). I can of course as an epidemiologist imagine why they would treat it as R, but for this function to work reliably and sustainably, we have to treat the data 'as is'.

Imagine your lab result would be >2 and the breakpoint for R would be >=8, how would you then treat it? If that's a clear S or I, should we take into account log2 calculations to determine the difference between those values? That's quite a horrible way of interpreting raw results. What we could do, is treat >=2 as 2, and >2 as 2 * 2 (= 4). But then that would become a problem in lower MICs, where the steps may not be powers of 2, but rather e.g. 0.0125 < 0.0188 < 0.0250.

Is it possible to have a 'conservative' option for as.rsi
as.rsi(....., conservative = FALSE)

That I do like. But then perhaps something a bit more clear, like maintain_capped_values, treat_capped_as_maximum, ... Not sure yet. We could then say: if the raw input value is something like ">.." (but not ">=.."), it should always be R since it would surpass the breakpoint anyway. Same with "<..", that should then be S. What do you think of that?

[msberends]

Something like this?

# MIC clearly greater than 2, but at default is treated as 2, since we don't know the 'real' value
data.frame(mo = "A.baumanii",
           CIP = ">2") %>%
  as.rsi(guideline = 'CLSI 2019')
#>           mo CIP
#> 1 A.baumanii   I


# MIC clearly greater than 2, but now treated as R regardless of the number 2
data.frame(mo = "A.baumanii",
           CIP = ">2") %>%
  as.rsi(guideline = 'CLSI 2019', conserve_capped_values = TRUE)
#>           mo CIP
#> 1 A.baumanii   R


# MIC greater than or equal to 2, will be treated as 2, also with conserve_capped_values = TRUE
data.frame(mo = "A.baumanii",
           CIP = ">=2") %>%
  as.rsi(guideline = 'CLSI 2019', conserve_capped_values = TRUE)
#>           mo CIP
#> 1 A.baumanii   I

[antunderwood]

That looks perfect.
I have been talking to my colleagues in the Philippines who run the national AMR program. The MIC values are coming from a Vitek machine and depending on the card used different values are reported. For instance for CIP with K.pneumo it report >=4 and >=8 whereas for E.coli it reports >2. The former values are define positions on the log2 scale, whereas the latter is a truly a value somewhere/anywhere above 2 so should be interpreted as worse case scenario i.e R

[msberends]

Awesome, then we'll keep it this way! Many thanks!

[antunderwood]

An update

In the case of ABA and CIP the breakpoints are 1 and 4

2 should be reported as R since the next log2 increment from 2 is 4

1 WHONET reports as NS since it could be I or R

Could the change be made that for conserve_capped_values
if the X in >X is above the lower breakpoint but the next log2 increment is below the upper breakpoint it reports NS else if the next log2 increment above X matches or exceeds the upper breakpoint it reports R.

I understand if you want to leave as is since this breaks the simple R, I , S tri state paradigm

[msberends]

Oof, that's hard. We had to choose a 'truth' to go by when it comes to interpretation to R/SI. We chose to follow EUCAST, which means that I is not NS to us, but rather susceptible (albeit 'Susceptible, increased exposure'): please see our website https://msberends.github.io/AMR/reference/as.rsi.html#interpretation-of-r-and-s-i.

From our colleagues in Sweden we understood last year that the WHO (including WHONET, EARS-Net) were also to adopt this idea. A quick internet search brought me to the AMR Reporting Protocol 2020 from the ECDC, where I found on page 13:

I think it's wise to leave it as is. Unfortunately, the tri state paradigm is more complicated then we can capture in one methodology. Hopefully, being transparant and clear about our choices helps our users to understand how and why our package works the way it works.

But I'll keep thinking about it. If it seems more appropriate in a later phase to change the behaviour of as.rsi() the way you suggest, we'll implement it of course immediately.

[antunderwood]

Many thanks - totally understand. I think it is a clearer with the tri state paradigm

[msberends]

Fix released to official R repository

Just a small notice: we released a new software version, containing the fix to this issue. Please update your version using either the user interface of your software, or by running:

install.packages("AMR")