Readit NewsMaking every future MRI worse is of large concern, especially if there are other nonmetallic contrasts.
I view the rise of these tools and particularly efficacy in programming as an indictment against modern programming. The modern web is both amazing and horrific. If bureaucratic is "using or connected with many complicated rules and ways of doing things" (Britannica), then modern programming may be the ultimate poster child. Sure, we love to slap this on "civil institutions", but the fact that I need an automaton, answers based on probability, to guide me in how to navigate doing some of the simplest things, is pretty sad (IMO).
I used to counsel aspiring new programmers, "It's not about knowing a certain language or framework. Your single most important asset will be an aptitude to constantly keep relearning. Some trends will stand out along the way, but you'll never quit learning new tools and languages".
Maybe it's just my age, but it feels like we've overflowed at some point.
Early programming was too electrical, too mathematical, so pioneers sought to close the gap between coding and human think. And yet, after years of speculative funding, what we're left with, is a whole different set of problems.
Sorry, but in the absence of general limiting principles that rule out such a scenario, that's how it's going to shake out. Visual models are too good at exactly this type of work.
Are there systematic reasons why radiologists in hospitals are inaccurately assessing the AI's output? If the AI models are better than humans in testing novel data then, well, the thing that has changed in a hospital situation compared to the AI-Human testing environment is not the AI, it is the human, under less controlled constraints, additional pressures, workloads, etc. Perhaps the AI's aren't performing as poorly as thought. Perhaps this is why they performed better to begin with. Otherwise, production ML systems are generally not as highly regarded as these models when they perform as significantly below test data sets in production. Some is expected, but "struggle to replicate" implies more.
>"Most tools can only diagnose abnormalities that are common in training data"
Well yes, training on novel examples is one thing. Training on something categorically different is another thing all together. Also there are thresholds of detection. Detecting nothing, or with a a lower confidence, or unknown anomaly, false positive, etc. How much of the inaccuracy isn't wrong, but simply something that is amended or expanded upon when reviewed? Some details here would be useful.
I'm highly skeptical when generalized statements exclude directly relevant information to which an is referring. The few sources provided don't at all cover model accuracy, and the primary factor cited as problematic with AI review, lack of diversity in study composition for women, ethnic variation, children, links to a a meta study that was not at all related to the composition of models and their training data sets.
The article begins as what appears to be a criticism of AI accuracy with the thinness outlined above but then quickly moves on to a "but that's not what radiologists do anyway", and provides a categorical % breakdown of time spent where Personal/Meetings/Meals and some mixture of the others combine to form at least a third that could be categorized as "Time where the human isn't necessary if graphs are being interpreted by models."
I'm not saying there aren't points here, but overall, it simply sounds like the hand-wavy meandering of someone trying to gatekeep a profession whose services could be massively more utilized with more automation, and sure-- perhaps at even higher quality with more radiologists to boot-- but perfect is the enemy of the good etc. on that score, with enormous costs and delays in service in the meantime.
Clinical AI also has to balance accuracy with workflow efficiency. It may be technically most accurate for a model to report every potential abnormality with associated level of certainty, but this may inundate the radiologist with spurious findings that must be reviewed and rejected, slowing her down without adding clinical value. More data is not always better.
In order for the model to have high enough certainty to get the right balance of sensitivity and specificity to be useful, many many examples are needed for training, and with some rarer entities, that is difficult. It also inherently reduces the value of the model it is only expected to identify its target disease 3 times/year.
That’s not to say advances in AI won’t overcome these problems, just that they haven’t, yet.
AI is going to augment radiologists first, and eventually, it will start to replace them. And existing radiologists will transition into stuff like interventional radiology or whatever new areas will come into the picture in the future.
Building mainly to power the next generation of pacsbin.com, but may offer as a standalone service as well.
Most recently, I wanted to implement 2FA w/ TOTP. I figure I'll use 1 cookie for the session, and another cookie as a TOTP bypass. If the user doesn't have a 2FA bypass cookie, then they have to complete the 2FA challenge. Great, so user submits username & password like normal, if they pass but don't have the bypass cookie the server sends back a JWT with 10 minute expiry. They have to send back the JWT along with OTP to complete the login.
I figure this is OK, but not optimal. Worst case, hacker does not submit any username/password but attempts to forge the JWT along with OTP. User ID is in clear text in the JWT, but the key only exists on the server so it's very difficult to crack. Nevertheless, clients have unlimited attempts because JWT is stateless and they can keep extending the expiry or set it to far future as desired. Still, 256 bits, not likely they'll ever succeed, but I should probably be alerted to what's going on.
Alternative? Create a 2FA challenge key that's unique after every successful username/password combo. User submits challenge key along with OTP. Same 256 bit security, but unique for each login attempt instead of using global HMAC key. Also, now it's very easy to limit attempts to ~3 and I have a record of any such hacking attempt. Seems strictly better. Storage is not really a concern because worse case I can still prune all keys older than 10 minutes. Downside I guess is I still have to hit my DB, but it's a very efficient query and I can always move to a key-value store if it becomes a bottleneck.
I don't know, what's the use-case? Server-server interaction? Then they still need to share a key to validate the JWT. And probably all but the user-facing server doesn't need to be exposed to public internet anyway so why the hoopla adding JWT? I haven't looked into it much because I don't believe in this microservice architecture either, but if I were to go down that road I'd probably try gRPC/protobufs and still not bother with JWT.
Even if you have an MR machine with a very low strength primary fields you'll still need to consider safety issues related to the gradients and coils.