The Ultrasound That Found My Clots

The Waiting Room

I was in the middle of a routine check-up, just another appointment on a Tuesday afternoon. I'd been feeling a little off, a persistent ache in my leg, but I chalked it up to training. I've pushed my body hard for years; a little discomfort is normal. This wasn't normal.

She kept the probe on my calf, moving it slowly, her eyes fixed on the screen. The silence in the room stretched. I tried to make a joke, but my voice felt tight. She just nodded, still not speaking, and then she left the room to get the doctor.

That's when I knew. The doctor came back in, a different expression on her face, and told me they found blood clots. Multiple. Deep vein thrombosis. My mind immediately went to all the races, all the training, all the times I'd pushed through pain, wondering if this was it, if I'd finally broken something for good.

And I remember saying back, I don't.

I lived. Obviously, or you wouldn't be reading this.

The Device That Found Them

What actually diagnosed me was a Doppler ultrasound. A medical device. A box on a cart with a probe and a screen, wheeled into a curtained bay by a tech who had clearly done this thousands of times and was already mentally onto the next patient.

That device had to work. Reliably. Accurately. In the moment my life depended on it.

It had to render the right image. Apply the right algorithms. Connect to the right system. Hand off the right data to the doctor who would make the call. It had to not be down for maintenance. It had to not be running a corrupted firmware build. It had to not be sitting on the wrong side of a ransomware event that had taken the hospital's imaging systems offline that morning; the kind of event that is no longer a hypothetical at U.S. hospitals.

I didn't think about any of that at the time. Patients never do. That's exactly why someone else has to.

Twenty Feet On A Numb Foot

For months after, I couldn't run.

I tried once. The photo on this post is from that morning. I laced up, drove out to a trail, walked maybe twenty feet onto the pavement, felt my left foot go numb, and turned around. That was the whole run. Twenty feet. I sat in the grass and took the picture because I wanted to remember exactly where I quit, in case I came back to the same spot later and made it farther. I did, eventually. Not that day.

The months between the ER and the trail changed how I think about the work.

Medical devices stopped being abstract.

What Medical Devices Actually Are

In a 510(k) submission, a medical device is paperwork. Predicate comparisons. Risk matrices. Software bills of materials. Cybersecurity documentation that has gotten dramatically more rigorous since the FDA's 2023 guidance went into effect.

In real life, a medical device is:

The ultrasound that found my clots in St. Louis.

The pump that kept my grandmother comfortable in the last week of her life so she could be present for the people in the room instead of for her pain.

The pacemaker someone reading this post right now has in their chest. The insulin pump on a thirteen-year-old at summer camp. The chemotherapy pump in an oncology unit at 2 a.m. The continuous glucose monitor that lets a parent sleep through the night for the first time in a year.

Every one of those devices runs on software.

Every one of them can be designed, built, tested, and deployed with cybersecurity treated as a patient safety issue; or with it treated as a documentation exercise to get past a regulator.

Those two paths produce very different devices.

The Compliance Checkbox Problem

The most expensive mistake I see medical device manufacturers make isn't technical. It's framing.

They frame cybersecurity as a regulatory hurdle. Something to get through. A section of the submission. A line item in the project plan that has to be checked off before launch.

When you frame it that way, you get exactly what you incentivized. You get the minimum work required to pass review. You get penetration tests scoped narrowly enough to be passable. You get SBOMs that are technically present and practically useless. You get threat models that don't survive contact with a motivated attacker. You get postmarket plans that fall apart the first time a real vulnerability lands.

And then the device ships. And then it sits in a hospital. And then a patient depends on it.

The manufacturers who treat cybersecurity like a checkbox aren't gambling with their submission timeline. They're gambling with someone's life. Usually someone whose name they will never know.

Why Blue Goat Cyber Exists

That's the gap Blue Goat Cyber was built to close.

We focus exclusively on medical device cybersecurity. Premarket submissions, postmarket monitoring, SBOMs, threat modeling, penetration testing of the actual device, FDA cybersecurity documentation that holds up to real review. The whole arc of what the FDA, MDR, and MDCG now expect; and what good engineering would expect even if the regulators didn't.

The number we get asked about is 250+ submissions, zero rejections.

The number isn't the point. The number is a side effect.

The point is that on the other end of every one of those submissions is a device. And on the other end of every one of those devices is a person. Someone in a curtained bay in an ER who doesn't yet know what's wrong with them. Someone in hospice. Someone in a school nurse's office. Someone in their own kitchen, holding their phone, looking at a glucose reading.

I'm still here because one of those devices worked.

That's not abstract to me. It will never be abstract to me.

That's the work.