This tracks with my own bias as an ER doc. I do feel that the risk of c-spine injuries from mountain biking is understated. As they said in the article, you are especially vulnerable to a hangmans fracture when thrown over the handlebars. I wonder if the ergonomics or geometry of a bicycle could be modified to better protect a rider’s neck.
> I wonder if the ergonomics or geometry of a bicycle could be modified to better protect a rider’s neck.
There has been a huge trend in this direction in recent years! For example in 2000 the head tube angle on a typical “trail bike” was something like 71 degrees, but today it’s more like 65 degrees, meaning the front wheel is a lot farther out in front of you. Bikes have also just gotten longer, especially in the front end which adds to this effect. This all means that (assuming you don’t ride more difficult terrain to compensate) it’s way harder to crash “over the bars” on a modern mountain bike than in the past.
There are sections of trail that I would almost always OTB (over the bars) on when attempted on my old 1998 hard tail. After finally upgrading in 2018, I almost never go OTB because of the longer and slacker geometry.
One ride on a double black rated tech trail nearby, the air shaft in my fork seized up so I lost all front compression. Even without front suspension, I was able to complete the ride and even keep up with my group, my arms were just toast after that. Modern bikes are just that capable based upon geometry alone.
That said, I now ride at significantly higher speeds and ride much harder terrain. But even still, my crashes are different and more to the side than directly over the bars.
The more downhill oriented a mountain bike is, the more it resembles a dirtbike — more suspension travel (up to around 220mm, where the suspension starts to work against you and makes the bike too mushy for something that light and human powered) , higher and wider handlebars and more space above the seat (nowadays the seats actually move out of the way and come back when needed, operated by a lever on the handlebars).
I'd say that most honest to god OTB accidents happen on slower, gnarly, downhill stuff, where it's easy for the (still relatively light) mountain bike to get stuck and unable to roll over an obstacle in time (before the rider arrives), or for the obstacle to slap your steering to the side, which again suddenly stops the bike.
Dirtbikes are much heavier compared to bikes and the weight of the rider, and you generally ride them a bit faster and not necessarily downhill.
Over the years the geometry has slackened, size of wheels length of wheelbase and size of cockpit have increased. Suspension has also evolved dramatically. This makes the bikes much safer and more stable at higher speeds. The bigger cockpit area has less responsive pitch and yaw, giving riders an increased sense of security. So the bikes are "safer". But this just means riders are going faster. The style of trail has evolved with this as well. Well manicured, wide bike park trails have got much faster with massive jumps. These types of trails are generally easier to ride than slower, more technical terrain and give maximum thrill at higher velocities. Amateur riders today are doing stuff even the best pro's could barely attempt 25 years ago.
I would like to see complimentary stats for age and years of experience riding, as it wouldn't surprise me if a lot of these folks are starting downhill as a midlife crisis and the modern bikes make them feel invincible. Everyone trying to do this sport at a higher level is going to get hurt at some point though.
They mention the costs, but what about the overall benefits to health, wellbeing and the economy.
Downhill is my main passion in life, it's so much more than just a thrill, and it's such a privilege to be able to enjoy it.
I mean, you can avoid going over the bars by riding a recumbent, but that's not going to be a viable solution for riding singletrack. The real trick is teaching people how to fall. I had a coach back in the 90's who was big on that, and it's become instinctual enough where the last time I went over the bars (mid-2023), I was able to manage my landing where I hobbled away with a massive bruise on my thigh, and not much else. I don't know that I've ever seen an MTB skills class that teaches you how to fall properly.
Yes mate. In my 20+ years of riding dh I've never broken a collar bone, let alone my spine. I put this down to learning to fall properly doing breakfall drills in jujitsu. Side fall, and diving front roll being the main falls used in mtb. Side fall involves not putting hand out and distributing impact across whole side; good for loss of traction fall on corners, skidding out sideways. Diving front roll like a commando roll for going out front over the bars.
Even moderate experience with martial arts goes a long way in instinctively managing falls - probably saved my bones a number of times in MTB and skating... The scars always in the same locations and on the same axis show it is a reproducible technique !
When I was a kid I thought I was going to be a stuntman, and falling down in various dramatic ways, sometimes off of tall things such as balconies, ladders and garages. In the decades since I've fallen off of bikes hundreds of times, I've taken many more falls skateboarding, snowboarding and rock climbing. I've suffered many bumps and bruises. A helmet, however has never had the opportunity to come in handy for me.
The funny things is that in sports such as skateboarding (or BMX) participants fall and crash regularly. There's no point in mentioning to them that falling is a skill, they already know. In the world of road cycling, where participants take a hard slam once every couple seasons or so, it's hard to convince them that skill is a factor.
Of course, with downhill mountain biking even if one is exceptionally agile in the event of a wipeout there is still a good chance they will smash themselves up.
MotoX riders wear a device which prevents the neck from unnatural extension. I wonder if medical doctors could champion their adoption among MB riders.
Edit: some controversy of the effectiveness of neck braces in motox
These became popular for mtb, some riders still use them. REason for not using them is the 2 main designs either transfer load to collar bone, or further down the spine. Many rider complained of getting a worse injury for the velocity of impact.
Michael J. Vandeman was arrested by UC Berkeley police on May 28 after he allegedly attacked a bicyclist with a handsaw on a fire trail above the UC Berkeley campus weeks earlier.
The system crashed while my coworker was running a code (aka doing CPR) in the ER last night. Healthcare IT is so bad at baseline that we are somewhat prepared for an outage while resuscitating a critical patient.
The second largest hospital group in Nashville experienced a ransomware attack about two months ago. Nurses told me they were using manual processes for three weeks.
It takes a certain type of a criminal a55hole to attack hospitals and blackmail them. I would easily support life or death penalty for anyone attempting this cr@p.
Yes. And I was told by multiple nurses at St. Thomas Midtown that the hospital did not have manual procedures already in place. In their press release they refer to their hospitals as "ministries" [0], so apparently they practice faith-based cyber security (as in "we believe that we don't need backups") since it took over 3 weeks to recover.
As a paramedic, there is very little about running a code that requires IT. You have the crash cart, so not even stuck trying to get meds out of the Pyxis. The biggest challenge is charting / scribing the encounter.
I used to work in healthcare IT. Running a code is not always only CPR.
Different medications may be pushed (injected into the patient) to help stabilize them. These medications are recorded via a bar code and added to the patients chart in Epic. Epic is the source of truth for the current state of the patient. So if that is suddenly unavailable that is a big problem.
Okay,not having historical data avaliable to make decision on what to put into a patient is understandable - but maybe also print critical stuff per patient once a day? - but not being able to log an action in realtime should not be a critical problem.
It is a critical problem if your entire record of life-saving drugs you've given them in the past 24 hours suddenly goes down. You have to start relying on people's memories, and it's made worse by shift turn-overs so the relevant information may not even be reachable once the previous shift has gone home.
There are plenty of drugs that can only be given in certain quantities over a certain period of time, and if you go beyond that, it makes the patient worse not better. Similarly there are plenty of bad drug interactions where whether you take a given course of action now is directly dependent on which drugs that patient has already been given. And of course you need to monitor the patient's progress over time to know if the treatments have been working and how to adjust them, so if you suddenly lose the record of all dosages given and all records of their vital signs, you've lost all the information you need to treat them well. Imagine being dropped off in the middle of nowhere, randomly, without a GPS.
That's why there's a sharpie in the first aid kit. If you're out of stuff to write on you can just write on the patient.
More seriously, we need better purpose build medical computing equipment, that runs on it's own OS, and only has outbound network connectivity for updating other systems.
I also think of things like the old school "check list boards" that used to be literally built into the yolk of the airplane they were made for.
I’m afraid the profitability calculation shifted it in favor of off-the-shelf OS a long time ago. I agree with you, though, that a general purpose OS has way too much crap that isn’t needed in a situation like this.
> It is a critical problem if your entire record of life-saving drugs you've given them in the past 24 hours suddenly goes down.
Will outages like this motivate a backup paper process? The automated process should save enough information on paper so a switch over to paper process at any time is feasible. Similar to elections.
Maybe if all the profit seeking entities were removed from healthcare that money could instead go to the development of useful offline systems.
Maybe a handheld device for scanning in drugs or entering procedure information that stores the data locally which can then be synced with a larger device with more storage somewhere that is also 100% local and immutable which then can sync to online systems if that is needed.
A good system is resilient. Paper process could take over when system is down. Form my understanding healthcare systems undergo recurrent outages for various reasons.
Many place did revert back to paper processes. But, it’s a disaster model that has to tested to make sure everyone can still function when your EMR goes down. Situations like this just reinforce that you can’t plan for if IT systems go down, it is when they go down.
My experience with internet outages affecting retail is the ability to rapidly and accurately calculate bill totals and change is not practiced much anymore. Not helped by things like 9.075 % tax rates to be sure.
Real paper is probably as much about breaking from the "IT culture" as it's about the physical properties. E-ink display would probably help with power outage, but happily display BSOD in an incident like this.
Honestly if you were designing a system to be resilient to events like this one, the focus would be on distributed data and local communication. The exact sort of things that have become basically dirty words in this SaaS future we are in. Every PC in the building, including the ones tethered to equipment, is presently basically a dumb terminal, dependent on cloud servers like Epic, meaning WAN connection is a single point of failure (I assume that a hospital hopefully has a credible backup ISP though?) and same for the Epic servers.
If medical data were synced to the cloud but also stored on the endpoint devices and local servers, you’d have more redundancy. Obviously much more complexity to it but that’s what it would take. Epic as single source of truth means everyone is screwed when it is down. This is the trade off that’s been made.
> synced to the cloud but also stored on the endpoint devices and local servers
That's a recipe for a different kind of disaster. I actually used Google Keep some years ago for medical data at home — counted pills nightly, so mom could either ask me or check on her phone if she forgot to take one. Most of the time it worked fine, but the failure modes were fascinating. When it suddenly showed data from half a year ago, I gave up and switched to paper.
I don't think it is historical data required to make a decision, it is required to store the action for historical purposes in the future. This is ultimately to bill you and to track that a doctor isn't stealing medication, improperly treating the patient, and to track it for legal purposes.
Some hospitals require you to input this in order to even get physical access to the medications.
Although a crash cart would normally have common things necessary to save someone in an emergency, so I would think that if someone was truly dying they could get them what they needed. But of course there are going to be exceptions and a system being down will only make the process harder.
Of course the real backup plan should be designed based on the actual needs, perhaps the whole system needs an "offline mode" switch. I assume they already run things locally, in case the big cable seeker machine arrives in the neighborhood.
Most printers in these facilities run standalone on an embedded Linux variant.They actually can host whole folders of.data for reproduction "offline". Actually all scan/print/fax multi function machines can generally do that these days. If the IT onsite is good though the usb ports an storage on devices should be locked down.
Oh yes. This would be a contingency measure, just to keep the record in a human readable form while requiring little manual labor. Printed codes could be scanned later into Epic and, if you need to transfer the patient, tear the paper and send it with them.
It is not necessarily crowdstrike's responsibility, but it should be someone's.
If I go to Home Depot to buy rope for belaying at my rock climbing center and someone falls, breaks the rope and dies, then I am on the hook for manslaughter.
Not the rope manufacturer, who clearly labeled the packaging with "do not use in situations where safety can be endangered". Not the retailer, who left it in the packaging with the warning, and made no claim that it was suitable for a climbing safety line. But me, who used a product in a situation where it was unsuitable.
If I instead go to Sterling Rope and the same thing happens, fault is much more complicated, but if someone there was sufficiently negligent they could be liable for manslaughter.
In practice, to convict of manslaughter, you would need to show an individual was negligant. However, our entire industry is bad at our job, so no individual involved failed to perform their duties to a "reasonable" standard.
Software engineering is going to follow the path that all other disciplines of meatspace engineering did. We are going to kill a lot of people; and every so often, enough people will die that we add some basic rules for safety critical software, until eventually, this type of failure occuring without gross negligence becomes nearly unthinkable.
Its on whoever runs the hospitals computer systems - allowing a ring 0 kernel driver to update ad-hoc from the internet is just sheer negligence.
Then again, the management that put this in are probably also the same idiots that insist on a 7 day lead time CAB process to update a typo on a brochure ware website "because risk".
This patient is dead. They would not have been if the computer system was up. It was down because of CrowdStrike. CrowdStrike had a duty of care to ensure they didn't fuck over their client's systems.
I'm not even beyond two degrees of seperation here. I don't think a court'll have trouble navigating it.
If that really were how it worked, I don’t think that software would really exist at all. Open Source would probably be the first to disappear too — who would contribute to, say, Linux, if you could go to jail for a pull request you made because it turns out they were using it in a life or death situation and your code had a bug in it. That checks all the same boxes that your scenario does: someone is dead, they wouldn’t be if you didn’t have a bug in your code.
Now, a tort is less of a stretch than a crime, but thank goodness I’m not a lawyer so I don’t have to figure out what circumstances apply and how much liability the TOS and EULAs are able to wash away.
When I read something like this that has such a confident tone while being incredibly incorrect all I can do is shake my head and try to remember I was young once and thought I knew it all as well.
I don't think you understand the scale of this problem. Computers were not up to print from. Our Epic cluster was down for placing and receiving orders. Our lab was down and unable to process bloodwork - should we bring out the mortar and pestle and start doing medicine the old fashioned way? Should we be charged with "criminal negligence" for not having a jar of leeches on hand for when all else fails?
I was advocating for a paper fall back. That means that WHILE the computers are running, you must create a paper record, eg “medication x administered at time y”, etc., hence the receipt printers, which are cheap and low-dependency.
The grandparent indicated that the problem was that when all tow computers went down, they couldn’t look up what had already been done for the patient. I suggested a simple solution for that - receipt printers.
After the computers fail you tape the receipt to the wall and fall pack to pen and paper until the computers come back up.
I completely understand the scale of the outage today. I am saying that it was a stupid decision and possibly criminally negligent to make a life critical process dependent on the availability of a distributed IT application not specifically designed for life critical availability. I strongly stand by that POV.
> I suggested a simple solution for that - receipt printers.
Just so I understand what you are saying you are proposing that we drown our hospital rooms in paper receipt constantly. In the off chance the computers go down very rarely?
Do you see any possible drawbacks with your proposed solution?
> possibly criminally negligent to make a life critical process dependent on the availability of a distributed IT application
What process is not “life critical” in a hospital? Do you suggest that we don’t use IT at all?
Modern medicine requires computers. You literally cannot provide medical care in a critical care setting with the sophistication and speed required for modern critical care without electronic medical records. Fall back to paper? Ok, but you fall back to 1960s medicine, too.
Why would you ever need to move a patient from one hospital room containing one set of airgapped computers into another, containing another set of airgapped computers?
Why would you ever need to get information about a patient (a chart, a prescription, a scan, a bill, an X-Ray) to a person who is not physically present in the same room (or in the same building) as the patient?
Local area networks air gapped from the internet don't need to be air gapped from each other. You could have nodes in each network responsible for transmitting specific data to the other networks.. like, all the healthcare data you need. All other traffic, including windows updates? Blocked. Using IP still a risk? Use something else. As long as you can get bytes across a wire, you can still share data over long distances.
In my eyes, there is a technical solution therr that keeps friction low for hospital staff: network stuff, on an internet, but not The Internet...
Edit: I've since been reading the other many many comment threads on this HN post which show the reasons why so much stuff in healthcare is connected to each other via good old internet, and I can see there's way more nuance and technicality I am not privy to which makes "just connect LANs together!" less useful. I wasn't appreciating just how much of medicine is telemedicine.
I think wiring computers within the hospital over LAN, and adding a human to the loop for inter-hospital communication seems like a reasonable compromise.
Yes there will be some pain, but the alternative is what we have right now.
> nobody wants to do it.
Tough luck. There's lots of things I don't want to do.
A hospital my wife worked at over a decade ago didn't use EMR's, it was all on paper. Each patient had a binder. Per stay. And for many of them it rolled into another binder. (This was neuro-ICU so generally lengthy patient stays with lots of activity, but not super-unusual or Dr House stuff, every major city in America will have 2-3 different hospitals with that level of care.)
But they switched over to EMR because the advantages of Pyxis[1] in getting the right medications to the right patients at the right time- and documenting all of that- are so large that for patient safety reasons alone it wins out over paper. You can fall back to paper, it's just a giant pain in the ass to do it, and then you have to do the data entry to get it all back into EMR's. Like my wife, who was working last night when everyone else in her department got Crowdstrike'd, she created a document to track what she did so it could be transferred into EMR's once everything comes back up. And the document was over 70 pages long! Just for one employee for one shift.
1: Workflow: Doctor writes prescription in EMR. Pharmacist reviews charts in EMR, approves prescription. Nurse comes to Pyxis cabinet and scans patient barcode. Correct drawer opens in cabinet so the proper medication- and only the proper medication- is immediately available to nurse (technicians restock cabinet when necessary). Nurse takes medication to patient's room, scans patient barcode and medication barcode, administers drug. This system has dramatically lowered the rates of wrong-drug administration, because the computers are watching over things and catch humans getting confused on whether this medication is supposed to go to room 12 or room 21 in hour 11 of their shift. It is a great thing that has made hospitals safer. But it requires a huge amount of computers and networks to support.
Why would a Pyxis cabinet run Windows? I realize Windows isn't even necessarily at fault here, but why on earth would such a device run Windows? Is the 90s form of mass incompetence in the industry still a thing where lots of stuff is written for Windows for no reason?
I don't know what Pyxis runs on, my wife is the pharmacist and she doesn't recognize UI package differences with the same practiced eye that I do. And she didn't mention problems with the Pyxis. Just problems with some of their servers and lots of end user machines. So I don't know that they do.
For relying on windows to run this kind of stuff and not doing any kind of staged rollout but just blindly applying untested kernel driver 3rd party patching fleet wide? yeah honestly. We had safer rollouts for cat videos than y'all seem to have for life critical systems. Maybe some criminal liability would make y'all care about reliability a bit more.
Staged rollout in the traditional sense wouldn't have helped here because the skanky kernel driver worked under all test conditions. It just didn't work when ot got fed bad data. This could have been mitigated by staging the data propagation, or by fully testing the driver with bad data (unlikely to ever have been done by any commercial organization). Perhaps some static analysis tool could have found the potential to crash (or the isomorphic "safe language" that doesn't yet exist for NT kernel drivers).
A QR code can store 3 KB of data. Every patient has a small QR Sticker printer on their bed. Whenever EPIC updates, print a new small QR sticker. Patient being moved tear of sticker and stick to their wrist tag.
This much of patients state will be carried on their wrist. Maybe for complex cases you need two stickers. Have to be judicious in encoding data, maybe just last 48 hours.
Handheld qr readers, off line that read and display QR data strings.
You need to document everything during a code arrest. All interventions, vitals and other pertinent information must be logged for various reasons. Paper and pen work but they are very difficult to audit and/or keep track of. Electronic reporting is the standard and deviating from the standard is generally a recipe for a myriad of problems.
We chart all codes on paper first and then transfer to computer when it's done. There's a nurse whose entire job is to stay in one place and document times while the rest of us work. You don't make the documenter do anything else because it's a lot of work.
And that's in the OR, where vitals are automatically captured. There just aren't enough computers to do real-time electronic documentation, and even if there were there wouldn't be enough space.
I chart codes on my EPCR, in the PT's house, almost everyday with one hand. Not joking about the one hand either.
Its easier, faster, and more accurate than writing in my experience. We have a page solely dedicated to codes and the most common interventions. Got IO? I press a button and its documented with timestamp. Pushing EPI, button press with timestamp. Dropping an I-Gel or Intubating, button press... you get the idea.
The details of the interventions can be documented later along with the narrative, but the bulk of the work was captured real-time. We can also sync with our monitors and show depth of compressions, rate of compressions and rhythms associated with the continuous chest compression style CPR we do for my agency.
Going back to paper for codes would be ludicrous for my department. The data would be shit for a start. Hand writing is often shit and made worse under the stress of screaming bystanders. Depending on whether we achieved ROSC or not would increase the likelihood of losing paper in the shuffle
The idea is to have the current system create a backup paper trail from which you practice resuming from for when computers go down. Nothing about current process for you need change only that you be familiar with falling back to paper backups when computers are down.
Which means that you have to be operating papered before the system goes down. If you aren't, the system never gets to transition because it just got CrowdStruck.
Correct. We use paper receipts for shopping and paper ballots for voting. Automation is fast and efficient, but there must be a manual fallback when power fails or automation is unreliable.
This wisdom is echoed in some religious practices that avoid complete reliance on modern technology.
You can do CPR without a computer system, but changing systems in the middle of resuscitation where a delay of seconds can mean the difference between survival and death is absolutely not ideal. CPR in the hospital is a coordinated team response and if one person can’t do their job without a computer then the whole thing breaks down.
If you're so close to death that you're depending on a few seconds give or take, you're in God's hands. I would not blame or credit anyone or any system for the outcome, either way.
Judgement is always part of the process, but yeah running a routine code is pretty easy to train for. It's one of the easiest procedures in medicine. There are a small number of things that can go wrong that cause quick death, and for each a small number of ways to fix them. You can learn all that in a 150 hour EMT class.
Hello, I'm a journalist looking to reach people impacted by the outage and wondering if you could kindly connect with your ER colleague. My email is [email protected]. Thanks!
I mean if they're finding sources through the comment and then corroborating their stories via actual interviews, it's completely fine practice. As long as what's printed is corroborated and cross-referenced I don't see a problem.
If they go and publish "According to hackernews user davycro ..." _then_ there's a problem.
CPR shouldn’t work on someone dead from a traumatic injury. For example chest compressions will only hurt someone dead from having their chest crushed against a steering wheel in a car accident. What happened to you is a true miracle and far outside the norm.
I’ve always wanted to have an MRI. I want to know how it feels to have all of my protons reoriented by a giant magnet. Would I be the same person after?
The MRI didn’t feel like anything. It wasn’t until the neurologist showed me images of my brain with my eyeballs right there in the front that I felt like I was going to have a panic attack. I have no idea how regular people just laugh off stuff like that. Awful existential crisis level dread seeing my mental meat.
For anyone wanting to relive that experience, you should know that (in the US at least) you can go to the imaging department at the hospital and get all of that data on a CD, and there's some good free software to render it. I've got a 3D print of my head somewhere that I made from a CT scan.
I think it can handle a few other formats as well. Once they are .nii(.gz) files, then mricrogl (https://www.nitrc.org/projects/mricrogl) should be able to render it - of course, for a brain scan - this would be your whole head. Brain extraction is performed by more specialized software, but that would get you started.
When I did it, I got the guy in the office next to me to put his DVD drive on a file share so I could copy to modern media. That was probably at least four years ago, so not sure if I could do the same now.
I had a similar feeling when the doctor showed the MRI images going progressively deeper into my brain. It was truly bizarre and made me squirm in discomfort. I hadn't expected to feel that way.
Former epileptic, I've had dozens of MRs and CTs. It's rote for me to see and I never had a visceral reaction and in fact I find it pretty fascinating. The one that I do have that's a standout and quite shocking is my first post-lobeectomy MRI. There's a very noticeable void where my right temporal lobe (+amygdala, cerebellum and hippocampus) were resected. Great conversation starter.
Having to hold perfectly still (possibly in an uncomfortable pose) in a giant machine that's making loud, uncanny noises for 20+ minutes is indeed a very bizarre, meditative experience. It is interesting, but, in my opinion, you're probably going to be happier not having the health concerns that lead to getting an MRI in the first place!
I had a MRI in college as part of a psychology experiment.
If you can get into one of those studies, it's a free way to get a picture of your brain!
I think I may have skewed their results, though. MRI is a very meditative experience and I'm pretty sure I fell asleep for brief moments when I was (supposed to be) memorizing and recalling pictures and words they were showing me on a monitor as part of the university experiment.
Your protons are also oriented by the Earth's magnetic field, and the magnets in your phone speakers. Larmor precession (the effect) occurs in low fields just as in high fields. The energy state differences from Earth's field are generally too small to be useful for MRI with enough quality in a reasonable time, but low-field MRI is a research area.
I actually felt a strong sensation when I had a high resolution brain MRI for research, and I rather enjoyed it. It switched on and off a few times during the scan, and it felt a bit like having a back massage, or significant mechanical vibrations in my back, or that feeling like gentle electric currents during some therapies, except for switching on and off abruptly.
I asked about this after the scan because I had been told you don't feel anything. Surely it wasn't just my imagination, from the noises? Was it from machine vibrations? I didn't have any metal in my body except amalgam fillings, and they said those wouldn't affect it. And, if I could feel something, perhaps it wasn't as harmless as they made out.
They explained after, some people feel a stimulation of their peripheral nervous system when the RF is on, from the tens of kW of microwave energy beamed through the body. For a few people this sensation is too much, even painful, and they have to stop which is one reason for the patient having the mechanical alert button. But most people don't feel anything at all from the MRI, just psychological feelings associated with the strange noises and confinemnt.
They said it's a peripheral nerve stimulation sensation, a kind of phantom feeling, rather than a physical effect on the body being sensed by the nerves. Don't ask me why I felt it in my back given it was a head and neck scan.
I enjoyed how it felt when I didn't know what it was, as it felt like it might loosen up my back a bit. I was a bit disappointed to not feel anything the next time I had a head MRI, for a medical reason (thankfully nothing found). The research scan had twice the field strength of the medical scan, and presumably different RF settings. Perhaps that made the difference.
Not just a research area! Recently on the DXMP mailing list someone was asking about QA procedures for their 0.064 tesla scanner. You can buy permanent magnets that strong without much trouble. I was very surprised since I wasn't aware they were in production — even searching Web results for "low-field MRI" in due diligence for this comment, I still only find papers and projections. Nonetheless, the Hyperfine Swoop exists, and you can buy it today:
I've had a couple. Proton alignment is an imperceptible state. You're experiencing more significant neurological changes reading this message than having your protons reoriented.
My wife works on MRI sequencing and has pretty long (> 1 hour) MRI scans quite often (2/3 times a week) as they all test each others research on themselves. She mentioned there are some scans where you actually do feel them and it's quite uncomfortable.
If you had nanoparticle contrast (ferumoxytol) it very well could have stuck around for weeks. Gadolinium chelate contrast is supposed to wash out in a few days, though.
This is incorrect - all of the protons align along the static (the strong 1.5, 3 , 9.4 etc Tesla) field, some point one way, and some the other - but they have all shifted so that they line up. The excite portion is a separate step, distinct from the static (B0) field. edit: distinct in some ways - the strength of the static field determines the RF used to flip the protons out of alignment.
You are mixing up a few things here, but they are all missing the point. At normal body temperatures, their thermal energy distribution prevents most protons in a human from aligning parallel or antiparallel with the static field, even at MRI field level strengths of several Tesla. The excitation by the varying field, which only affects another one-in-a-million of those aligend protons, is indeed another step, meaning that even fewer protons actually get to experience the precession effect. So about one in a million protons gets aligned with the static field and less than one in a trillion gets to produce a measurable signal. But since there are so many of them, (~10^20 per mm^3 for water), you still get enough (about 1000 protons or so per voxel) to measure a signal at 2 Tesla. With higher field strengths you can get a bit more and thus more resolution but even at 10 Tesla you won't align all of your protons - not even close.
I've felt a bit of heat from the radio waves, especially during the fMRI sequence. Personally, I get a bit claustrophobic during brain MRIs because of the restricting face coils, and you have to go pretty deep into the tube. No idea why people get weirded out by seeing pictures of their brain. I've never felt that. I think its cool.
In the hospital where I went a few times, they show a relaxing video while the MRI is taken. You look at a projection via a tilted mirror close to your eyes. Once it was featuring pandas, it is really nice to experience the panda effect inside the machine. I've never been anxious about the scan.
I've had a few. There is definitely a weird feeling I get inside of them at specific certain points in the process, but I don't know if it is from the magnetic field, or if it is from some really high pitch vibrations/sounds that come off the machine.
This is the most stupidest comment I ever seen. No, it's not fun to be at a hospital. No, you shouldn't want to be at a hospital. And yes, it's a bit masochist.
I presume this is intended for wounds in areas with poor circulation, like a diabetic foot or a walled off abscess. The bloodstream is damn good at delivering antibiotics and immune cells to infected areas.
One of the problems is that the bloodstream is good at delivering antibiotics everywhere, which encourages resistance and many of the side effects of antibiotics.
That, plus wounds with poor circulation, or as the article notes, infections that are protected by biofilms.
Received mine this week for a service address on the Navajo Nation. I imagine the wait is shorter for less populated rural areas, which should correlate with need. My old isp charged $60 a month for 1.5 Mb/s down and 750kb/s up. This should be a great improvement.
My relatives are in a similar situation -- only satellite available in their area, so ~800ms latency and speeds around 1 MBps, but half a mile away there is literally fiber available, so it's going to be a long time before it gets opened up for them because they aren't considered to be in an underserved area.
I've been on it since February of last year. My day job uses a remote desktop and I'm on video conference calls 4+hrs a day. Starlink was unusable until late summer because I would see 50+ outages of 3 seconds or more during the day. (3 second blips are where it seems to really interrupt zoom and vdi)
It really started coming together in the fall and I would say since November it has been very usable. I would say it's easily as stable if not more stable than the 10/.7M dsl it replaces.
This is exactly my experience. Also got it last January or February. I had to keep my DSL line for a few months, but it got good enough for me to finally drop that thing.
The issues I have with connectivity are probably 99% trees.
When I first started it seemed to need a total view of the sky to get consistent. As the software/flotilla have improved vastly, I use it for zoom and once every couple hours of zooming I may risk a 10 second blip.
I think they are getting better software wise of detecting the usable area of visible sky and utilizing satellites better.
I would think more satellites, more tree tolerance. I currently have my dishy too close to the road since I get the best view that way, I might try moving it back to the backyard this spring to see if it can work well there without worrying about teenagers using it for batting practice or some disgruntled cable employee or it getting stolen.
If you have an unobstructed view of the sky, it should be functionally as reliable as cable internet.
