GithubHelp home page GithubHelp logo

Comments (9)

msberends avatar msberends commented on September 27, 2024 1

Btw, I love this so much!

Thanks for the amazing work adding increased support for veterinary microbiology.

It’s been out there for less than 2 weeks! Already being noticed by users! Many thanks for using the package, I’m always open to suggestions!

from amr.

msberends avatar msberends commented on September 27, 2024 1

I implemented NI alongside S/I/R (see #151) and the CLSI 2024 guidelines. Would you please have a look?

Didn't look at the <= logic yet, just took over the breakpoints of CLSI 2024 'verbatim'.

from amr.

samueljpearce avatar samueljpearce commented on September 27, 2024

Another issue (perhaps not specific to veterinary breakpoints but maybe where most of the problem lies) is that many breakpoints are not actually interpretable at this time. CLSI breakpoints are below the minimum boundary for automated AST systems. Would there be a way to identify these and describe them separately?
They are currently interpreted as resistance making antibiogram interpretation very difficult. Perhaps having a method for minimum breakpoints interpretation limits and then a not interpretable output in the antibiogram?

Also sorry for cluttering the github issues, I would be happy to move this to the discussions if you prefer.

from amr.

msberends avatar msberends commented on September 27, 2024

Thanks for bringing this up! CLSI 2024 is not yet in the WHONET tables that we use for import. So we’ll await that (they are normally quite fast with implementing).

The minimum setting for MICs will be very hard, as the breakpoints are just defined… From my medical point of view, it seems they are artificially keeping the breakpoints low, i.e., that it’s not about the in vivo use, but rather political to discourage treatment. Animal breakpoints are insanely low, especially compared to humans. But maybe I don’t understand enough about veterinary medicine, could be!

Also sorry for cluttering the github issues, I would be happy to move this to the discussions if you prefer.

Not at all!! I’m very happy that you’re putting it out here, I’ll find my way :)

from amr.

samueljpearce avatar samueljpearce commented on September 27, 2024

No worries, hopefully WHONET are on it!

I'm not sure I explained the minimum breakpoints well. There is a lot of controversy (in the UK at least) about the new CLSI breakpoints but there is pressure to create and use antibiograms regardless and these are, by default, the best we have. My suspicion is that they are so low due to limited PK/PD information and comparatively lower antimicrobial dosages. I hope it's not political as it mostly applies to our first-line low priority antimicrobials!

My point relates to how we interpret these isolates - as in our institution, we use a VITEK2 which simply cannot measure low enough to meet even the resistant breakpoint! But that doesn't mean these samples are resistant, merely that we cannot interpret the results (the isolate may still have an MIC below the sensitive breakpoint, but we cannot measure it!). Therefore, I think it would be useful if there were a way to separate these out as "not interpretable", rather than interpreting them as resistant (because we actually don't know if they are S, I or R).

I appreciate this is not a simple task by any means and would essentially require knowledge of each AST systems minimum measurable MICs or to allow user created minimum MIC measurements. These can then be used to mark isolates where the R breakpoint is lower than the minimum as "not interpretable". I think that I can make a work around for my use-case but I suspect this will be an issue for a long time while our breakpoints get updated once more information exists. So I thought I'd mention it in case you thought it was worth working into the package :)

from amr.

samueljpearce avatar samueljpearce commented on September 27, 2024

There's also another odd change with the 2024 breakpoints that may affect the package weirdly. For some reason, they have included sensitive dose dependent (SDD) breakpoints as separate to intermediate breakpoints, so now there is S, SDD, I and R. This might affect the antibiogram(combine_SI = ...) argument. Just a heads up!

from amr.

msberends avatar msberends commented on September 27, 2024

Ah, I think I see now. Then maybe it's worth it to implement something that checks for less-than-or-equals (<=) MIC values? The upper breakpoint could be higher than what was returned by Vitek 2, so interpretation is very hard indeed. I'll try to think about something.

There's also another odd change with the 2024 breakpoints that may affect the package weirdly. For some reason, they have included sensitive dose dependent (SDD) breakpoints as separate to intermediate breakpoints, so now there is S, SDD, I and R. This might affect the antibiogram(combine_SI = ...) argument. Just a heads up!

Yes, great comment. Absolutely true, they do this for humans already. That's why we did this:

AMR::as.sir("SDD")
#> Class 'sir'
#> [1] I
#> Warning message:
#> in as.sir(): 'SDD' (susceptible dose-dependent, coined by CLSI) was interpreted as 'I' to comply with EUCAST's 'I' 

SDD will be transformed to I to make it equal to EUCAST. It would have been better in EUCAST also introduced this as a new category. I thought about adding it as a separate category for the AMR package, but it will mean a lot more overhead code and interpretation issues... What do you think, should be do anything we can do preserve SDD where possible?

from amr.

samueljpearce avatar samueljpearce commented on September 27, 2024

Ah, I think I see now. Then maybe it's worth it to implement something that checks for less-than-or-equals (<=) MIC values? The upper breakpoint could be higher than what was returned by Vitek 2, so interpretation is very hard indeed. I'll try to think about something.

Yes I think this would work and it could return NI (not interpretable) rather than SIR. Just not sure how to then report than with the antibiogram. It would be useful to present it together but I suspect it would be easiest to leave this to the user to report the two metrics with each other, than incorporating it into one output.

Yes, great comment. Absolutely true, they do this for humans already.

Ah, sorry I didn't realise they reported it like this for humans, I had only read the EUCAST changes where it's incorporated together.

What do you think, should be do anything we can do preserve SDD where possible?

I'm not sure there's any benefit to having them separate at the moment. I'm not a clinical microbiologist, but am collaborating with some, so I'm trying to get their opinion on this currently. From my understanding, the two are technically different, but I struggle to see the clinical difference, other than having more confidence of a likely clinical response in SDD breakpoints over intermediate breakpoints when using higher antimicrobial doses.

from amr.

samueljpearce avatar samueljpearce commented on September 27, 2024

Finally taking a look at this. Thanks for adding NI as a factor. Just so I understand fully, there is no way that AST results will be interpreted as NI yet by as.sir(), but this just allows implementation after the fact? Not a problem if so, I can create my own logic for my specific dataset to convert them to NI after the fact.

I don't have an answer for my next question, so I'm curious as to what your thoughts are. I see that when running antibiogram(), NI values are still used in the final %S calculation. Do you think it would be better to leave these out of the %S calculation as we have no way of telling whether they are S, I, R or SDD?

from amr.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.