Consider patients who are unconscious (or awake but unreliable) due to head trauma, stroke, etc. You can't do a proper MR safety screening interview to find out if they have ferrous metal or other conductive objects in their head. The magnetic field can potentially torque an old aneurysm clip or piece of shrapnel, and the radio frequency excitation field can cause heating and burns if there are antenna-like conductors present.
MRI is slow and the images are easy to ruin if the subject moves around too much during the long acquisition time, so bouncing around in the back of an ambulance isn't the ideal setting. A 3D volume with whole head coverage and suitably fine spatial resolution can take several minutes to acquire, versus just a few seconds for X-ray CT. The MRI signal to noise ratio is also proportional to field strength, so low field systems like this are at a disadvantage for image quality. On the plus side, low field does mean less risk of moving ferrous material inside the subject.
> According to the guideline, diffusion MRI should be considered more useful than a CT scan for diagnosing acute ischemic stroke within 12 hours of a person’s first stroke symptom. In one large study, among others, that was reviewed for the guideline, stroke was accurately detected 83 percent of the time by MRI versus 26 percent of the time by CT.
Main thing they need to know is stroke vs aneurism and accuracy is really important.
Are we really not capable of detecting such dangers externally without patient input? It seems like detecting even small pieces of metal would be relatively trivial.
1) Speed.
2) Depiction of bone (less relevant if it's not a trauma case with suspected broken bones).
?) Risk to patient in case of internal metal.
Some MRI suites are set up with airport style metal detectors to prevent people from accidentally bringing metal into the magnet room. I haven't heard of metal detectors being used to screen non-responsive patients, though.
It's a reasonable question, but I think that even if some instantaneous metal detector with a false negative rate of 0 could be made, emergency docs would rather scan for five seconds to get a CT than five minutes to get an MRI that has coarser resolution, poor bone depiction, and a chance that the whole image is ruined if the patient moves.
What I'm saying is, why isn't there a sensitive enough metal detector which outputs a binary value of whether or not a dangerous level of metal is present? You need to check for two things I imagine: ferrous objects which could be pulled by the magnet, and conductive objects which would heat up when absorbing the MRI RF pulses. Both seem possible to do with a bedside device.
I'm speculating, but probably not. The images would be blurry and unusable if taken in a busy ambulance on road to the hospital. Could do more harm than good.
Having this in a stable home would be awesome on the other hand, but there is too much vibration and everybody trying to grasp handlebars and keep equilibrium when you are in an ambulance on duty.
I could be wrong. I do not master this technology, but if you need absolutely remain motionless in the big machines, I assume than smaller ones would have the same requisite. Ambulances are not stable by default. Everything bounce.
This technology will mostly end up in imaging centers, improving throughput.
Still, an ER MRI is wildly unlikely. “Possible evolving emergency” and “an hour in a tube where we can’t see you” don’t play well together. Any chance you’re confusing CT scan for MRI? Cause -that- we would do for a head trauma like 1000% of the time.
I think the combination of weird blood work + medical mystery + stabilized meant I got an MRI. wish they'd gotten to the bottom of it..
If you solve or alleviate those issues it becomes more attractive. There is a fair bit of research around potential trial benefits if the contrast provided for some emergency procedures already.
Ugh, I just wrote this long-ass post and lost it. Whatever, here's the short version:
Stroke is a clinical diagnosis, not a radiologic one.
CT will catch hemorrhages or large infarcts just fine. That's the important stuff: big infarcts cause big tissue damage. Tiny infarcts cause tiny tissue damage. MRI's superiority over CT is in that it catches smaller infarcts, and catches infarcts early. If I see a patient that screams "stroke" and the noncontrast CT is negative for hemorrhage, it's ischemic until proven otherwise. I don't need an MRI at the less than six hour stage and, while having one would be nice for malpractice reasons, whatever, I don't actually need one for your care. I may follow-up with an MRI if it's less certain that it's a stroke: tumors, infection, etc. that look like strokes. But, key - those aren't pressing, time-wise, the way a stroke is, if they look like a stroke ("look like" implies things about the nature of the underlying condition.)
After 6 hours we've passed the TPA stage and we're looking at clot removals. Here we need to know the exact territory of the infarct. If I'm bothering with imaging, yes, MRI/MRA, but that's not about finding the kind of stroke - it's about telling the interventionalist where to go.
The method that works where I didn't accidentally close the last tab associated with a particular renderer process (or, TL;DR, didn't close any tabs), is to promptly figure out which renderer process is behind the tab in question via chrome's task manager, quickly attach to it with gdb, then `generate-core-file (filename)`, and grep through the result for my text. (Usually `grep -aC100`.)
Alternatively, hibernating generally seems to always(?) save the disregarded bytes to disk (the associated memory regions immediately get used for something else, so they stay in in the pagemap); then I can reboot the machine, carefully prevent it from resuming, boot to Linux, mount the FS readonly as appropriate (since it was never unmounted cleanly), then go through the hibernation/swap image. (Bonus points for then resuming once you're done.) I recovered a family member's lost draft email this way once (TIL Gmail encodes emails in both HTML _and_ HTML-inside-JSON O.o).)