Comments (9)
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.
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.
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.
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.
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.
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.
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.
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.
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)
- AMR HOT 3
- Group isolates HOT 7
- Not all mo_transforms work with antibiogram HOT 1
- Check groups for antibiotics: aminoglycosides all right? HOT 1
- as.sir reports invalid results as coming from wrong columns HOT 2
- extra factor level in class SIR (as.sir/is.sir) HOT 5
- `as.mo()`: give preference to species if subspecies is non-existent
- Add denominators to each antibiotic in antibiogram HOT 5
- Acknowledge data availability when using `first_isolate(method = "phenotype)`
- Error when antibiogram empty HOT 4
- Teleomorph vs anamorph ID of yeasts HOT 3
- scale_y_percent HOT 1
- AMR 3.0: let reverse dependencies know HOT 1
- scale_x_mic not working HOT 2
- suppress information 'warning' with as.mo mo_gramstain etc HOT 2
- Turn off information as.mo mo_gramstain etc HOT 3
- uti is false bug? HOT 4
- Some organisms not in database HOT 2
- Extrapolating breakpoints for animals in line with CLSI VET09 document HOT 5
- as.sir() hangs in latest beta if unknown column present HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from amr.