Monday, December 23, 2024

2018: A Health IT Odyssey

In this month’s article, Mike Farahbakhshian returns from a month off to find… well, this. His response is to gird his loins and prepare you for the disruptors that will rock Federal Health IT in 2018 and beyond. What lies over the horizon will shock you. It’s going to be a rough year.

Read time: 14 minutes. Suggested drink pairing: a snifter of Jeppson’s Malört, sipped with a straight face.

Also Spracht Farahbakhshian

Hello friends! It’s been a while. I took off in December to enjoy friends, family and enough eggnog to kill a moose. But I’m back for the New Year. 2018! Finally, the dumpster fire that is 2017 can be put behind us. We can finally relax. Take a deep breath. Take stock.

It’s a New Year! A fresh start! The air is thick with boundless optimism. (And eggnog toots.) The future is bright!

Yeah, right.

Of course, I’d come back to a bigger dumpster fire in progress. Let’s see where we are as of today:

We aren’t even ten days into the New Year. I have milk I bought in 2017 that’s still good! So, one week into the New Year, we ask ourselves this question:

Pro Tip: Yes.

Will 2018 Be As Crazy As 2017?

Well, it looks like I can’t take my “gloom and doom” hat off quite yet. With that said, let’s discuss.

THINGS TO WORRY ABOUT IN 2018 AND BEYOOOOOOOOOND…

Don’t worry, this won’t be a retread of the same old buzzwords. IoT already happened and Blockchain’s bubble is about to burst. So, let’s talk what’s coming: next-generation, over-the-horizon technological threats and opportunities. I live at the intersection of buzzword and science fiction and I interpret “disruptor” a little differently than most.

And now, so do you.

Disruptor Number One: Hardware/Firmware Infrastructural Threats

In the past, vulnerabilities were software based and easily fixed. As a young hacker in the mid-nineties, I remember working on exploits for UNIX binaries like lpr and su, and sharing them in BBS “zines.”

We will never speak of this again.

We got away with this because back then, software patching was a scheduled, more so than a continuous activity. Open Source software was nascent, but gaining ground as having a shorter release cycle. The biggest vulnerability twenty years ago was consumer desktop software, which was often poorly maintained and never patched.

In the past two decades, auto-patching of software, combined with always-on connections, has helped close this gap significantly. As much as we malign Windows Update or unattended-upgrades forcing us to reboot at the worst times (halfway through this article, for example), we can at least take comfort in the knowledge that as end users, we have one less thing to worry about with our computers.

Before Patch Tuesday, there was Mom’s Malware Mitigation Monday.

Yet there’s a new threat now. In a world of connected network, storage and medical devices, we now are dealing with vulnerabilities that cannot easily be “patched and pushed”: hardware instruction sets and firmware-encoded accounts. I’ve covered the issues with the Intel Management Engine in great detail in my November article. The Spectre and Meltdown vulnerabilities are independent, as are the issues with Western Digital NAS devices. There are three types of challenges in mitigating issues with hardware and firmware:

  1. You can’t just make a fix and release a new version, because the old version will still be operational in the field for a long time.
  2. You can make a fix, but there’s no vector to push the fix: you will have to hope that sysadmins will patch it themselves.
  3. You can make a fix, and push it out, and now performance or timing issues break connectivity between systems.

I’ll cover each of the challenges below.

You Can’t Fix It

Issues with microprocessors, like CPUs and GPUs, fall under #1. When researchers found out how to decrypt 4096-bit RSA encryption using a microphone, they were taking advantage of a physical property of the CPU. Intel or AMD might be able to fix the issue in future versions of their hardware, but the old version can never be fixed. This is a huge issue in data centers, where servers and network appliances have to be operational for quite some time to meet their ROI. It’s an even bigger issue in the Health IT arena. Medical devices are often incredibly expensive, especially anything radiological or related to nuclear medicine. They cannot be “swapped out” every time a fundamental flaw in the hardware or firmware architecture is discovered.

This is not something we can gloss over. Hospitals are now prime malware targets; and since a large portion of Federal Health IT is military operational medicine, we can safely assume that enemies will target our military medical devices’ fundamental architectural flaws as a method of getting into the DoD and VA networks. Suddenly, a compliance issue has become a patient safety and a national security issue.

With “you can’t fix it” problems, the best one can do is isolation: isolation networks like Med-COI or MDIA exist for Federal Health IT networks. However, as more and more health networks are integrated through programs like Community Care, the isolation network will have to be so large and inclusive as to be fundamentally meaningless; or a series of isolation networks linked by gatekeeper devices will need to be established. The problem is, many of these gatekeeper devices have similar CPU and firmware based flaws!

You Can Fix It, But You Can’t Push It

With the increased attention to IoT, this should hopefully be a thing of the past, but right now there are categories of firmware patches that can be fixed, but these patches cannot be pushed. Changes to BIOS or Lights-Out Management are chief among these. They require a system administrator to manually download the patch to some sort of removable media and “flash” the firmware. There are some inherent risks in this activity. First, there is a time and labor cost of having a human make these updates. In the case of medical devices, this downtime will result in a lack of access to critical medical equipment, which can precipitate capacity or patient safety issues. The flash is risky, as any interruption (like a power loss) can “brick” the hardware and render it useless. Bricking a cheap Linksys router might be nothing, but try bricking a CT scanner or MRI.

It may be by Piter’s will alone that he set his mind in motion, but House Harkonnen lost because they switched to decaf.

Having a human perform the upgrades opens up another risk vector in the form of human error. Imagine: If your sysadmin didn’t have enough coffee that day, he or she can brick your ridiculously expensive medical device. These devices can include infusion pumps; CT scanners; EHRs; or even a breeder reactor, like the one recently decommissioned at an Omaha VA Medical Center.

 

You Can Fix It, You Can Push It, But Whoops, You Broke Something

In the Health IT realm, Spectre and Meltdown also fall under this category. Many medical devices are connected via the IoT and can be remotely patched. That’s a good thing. Yet, these patches have incipient performance issues. For medical devices, this can be serious as some interfaces are time sensitive. Any patch that affects CPUs at the instruction set or clock level will result in a performance hit. This performance hit can be critical, especially as most hospitals operate on a mixture of proprietary real-time operating systems (RTOS) and general-purpose operating systems (like Windows, Linux or MacOS) which are not real-time.

Ah, the 90’s. Also when most of these embedded RTOS’s were written. And last updated.

Explaining what an RTOS is stretches a bit out of the scope of this article, but the Cliffs Notes version is that an RTOS, or embedded system, aims for deterministic times to execute tasks. If it will take ten clicks of the clock to do a job, you can be assured it will be done within those ten clicks, versus a general purpose multitasking OS like Windows, where the operating system makes a best effort – but the task can be done in one click or never depending on other competing tasks. Embedded systems that interface with each other, as in IoT, or with general purpose OSes, could have a ripple of cascading issues if we alter the fundamental meaning of what a “click” is.

The good news is that embedded RTOS devices are less likely to be directly impacted by Meltdown and Spectre as they are less likely to perform speculative instructions. The bad news is that many of these embedded systems will be interfacing with, and depending on, general-purpose systems which do.

The Big Take-Away

Health IT is an ecosystem and just because you’re not directly affected by a vulnerability, you might experience downstream effects from other systems. This goes double for fixes.

Disruptor Number Two: VA-DoD Single Identity Service

Contrary to the previous disruptor, this one seems pretty simple to achieve in principle, but the devil is in the details and edge cases. Now that both DoD and VA are moving to the Cerner EHR backend, there is a need to have one authoritative source of a service member or Veteran’s identity. Unfortunately, over the years, both VA and DoD have come up with different ways to identify a service member or Veteran. The Defense Enrollment Eligibility Reporting System (DEERS), authoritative identity source for the DoD, uses the electronic data interchange personal identifier (EDIPI) as a unique identifier. This applies to active duty service members, reservists, and beneficiaries. VA, on the other hand, has a variety of identifiers, as it has identified Veterans over the years. The ICN is the general identifier used to identify all Veterans, and it is informed by the Veterans Health ID Card (VHIC) number, as well as VistA-specific identifiers like DFN, or identifiers for MyHealtheVet (IEN) and Beneficiary Identity and Record Locator System (BIRLS) numbers. The result looks like this:

Unrelated: I think I’ll have spaghetti for dinner. Yummy, yummy spaghetti.

There are various edge cases that prevent us from simply mapping DoD EDIPI to ICN and calling it a day, which include:

  • Veterans who separated before EDIPI came into use.
  • Foreign Nationals in the U.S. Military who, until recently used a different identification.
  • Non-US Citizens who are being treated by VA because they were a US territory at the time (i.e., in the Philippines).
  • Beneficiaries of Veterans born after the service member separated from the military.

Here, the problem isn’t technological; the problem is process based. Do we as the Federal Healthcare IT Community develop an effort to true up MVI ICN and DEERS EDIPI? Do we rely on a commercial service like ID.me, working in concert with DSLogon, to true up identities? How do we resolve edge cases without spinning up ancillary cases? How can you make this exchange work over competing isolation networks? DoD uses Med-COI and VA uses MDIA within the bounds of the DHS TIC, but Veterans and military may be accessing these systems from commercial networks.

A Revolutionary Way of Addressing It

The simplest and lowest-risk way of seeing this work would be the most disruptive from a cultural standpoint. There are currently 42 Areas of Operation (AOs) under CYBERCOM. DHA is one of them. From a perspective of risk reduction, it would make the most sense to have VA be a 43rd AO. This of course means VA adopting DoD cyber posture and working hand-in-glove with DoD to ensure smooth identity management. Yet this raises questions: what if VA wants to diverge from DoD? Would DoD take on responsibility for identities of non-service members and their beneficiaries? Would having VA as an AO under CYBERCOM violate the Posse Comitatus Act? These are the questions that smarter and more empowered people than I need to resolve before the Cerner implementations are fully underway.

The Big Take-Away

2018 will be a year of policy disruption as well as technological disruption. Big waves will need to be made to get this small but simple boat moving.

Disruptor Number Three: Generative Adversarial Networks

Oh, boy, oh, boy. I have been waiting to discuss this one for a while. Forget about Blockchain – if you aren’t a Blockchain kajillionaire, you aren’t going to be one. You missed the boat. It’s worthless to you. Generative Adversarial Networks are where it’s at.

What is a Generative Adversarial Network? The Wikipedia page made my eyes glaze over.

Yeah, don’t read that. This page is a good start, but if you don’t want to get in the weeds, know this:

Generative: traditional neural networks are “discriminative,” which means they look at training data and point out whether the datum they are looking at matches the training data. This is the neural network equivalent of playing Twenty Questions, where you can only answer “yes” or “no.” A generative network doesn’t care about yes or no; it gives you something that closely matches what you train it on. This is the neural network equivalent of “Bring me a Rock.”

Adversarial: Instead of having a human being train this generative network, we put a generative network against a traditional discriminative neural network. The generative network’s goal is to fool the discriminator and the discriminator’s goal is to not be fooled by the generator. This makes training move at the speed of computation, which is pretty bloody fast.

Network: It’s a network. More nodes, more power, more speed. This is Skynet, people.

So, in short, a Generative Adversarial Network is like the Flash and Quicksilver playing the world’s fastest game of Bring Me a Rock.

Oddly accurate.

My, that sounds dangerous.

Damn Skippy, it is. One primary use of Generative Adversarial Networks is for poisoning image recognition algorithms. Things like biometrics can be completely ruined by using a Generative Adversarial Network to create false associations. I don’t mean poisoning the well with garbage. I mean consistently creating a false association. Essentially, a Generative Adversarial Network can mis-educate your friendly AI.

Let me tell you the parable of the “Adversarial Turtle.”

Once upon a time, researchers figured out how to use a Generative Adversarial Network to reverse engineer Google’s image recognition algorithm. They were able to identify what aspects of light and reflectivity Google seized upon to recognize things.

Then they hacked the !@#$ out of it.

A Zen koan: What rifle has shells but no bullets?

They created a 3D printed image of a turtle. From any reasonable distance or angle, any human would look at it and say, “Wow. That’s a boring old box turtle.” But Google, consistently, would identify it as a rifle. Every. Single. Time.

Do you feel so safe about Amazon drones or Google self-driving cars right now? You know all those CAPTCHAS you fill out that say “Please identify all squares of this image with traffic signs” or similar? Google uses this to train self-driving cars. Just know that in mere moments, an AI can completely foul that up and train those self-driving cars or drones to attack anyone, or anything they please. Furthermore, thanks to games like Ingress and Pokémon Go, this potential kamikaze swarm has been fed and trained on a 3D map that includes foot trails and building interiors.

Or, if you want to keep your panic constrained to Healthcare IT, understand that there is someone out there who wants to take all the accumulated medical insight that Watson Health has and alter or weaponize it. Maybe they’ll do it because of political reasons. Maybe they’ll do it for the money. Maybe they’ll do it just to watch the world burn. Whatever the reason, know this: the creepy auto-generated YouTube Kids’ videos was just the first test run. When this weaponized AI is unleashed on Healthcare IT, patient safety is going to be under the biggest systemic threat since the invention of medicine.

Skynet exists, it has been trained, and all it takes is a Generative Adversarial Network to turn it evil. Let this sink in for a second.

Damn, I’m scared. Is there any upside to Generative Adversarial Networks?

I’m glad you asked. I can’t speak to the robot apocalypse, but I can say this: There are many good applications to use a Generative Adversarial Network in Healthcare. There are two major applications: data set creation and image segmentation.

Data Set Creation: A Generative Adversarial Network can be used to create massive, realistic looking data sets. These data sets can be used for EHR testing, deep learning (DL) or even some research applications (as a control group, for example). Right now, as it stands, human beings run CPU-intensive obfuscation scripts against live EHR data, much of which is riddled with input errors to begin with, to create a subset of “fake users.” From my experience overseeing the MHS data warehouse and reporting applications, I can tell you that these obfuscated data sets are often too small to perform comprehensive testing against all use cases. With a Generative Adversarial Network, we can finally achieve the holy grail of creating practically unlimited sets of unique, configurable, yet 100% HIPAA-compliant fake data. We reduce human error, CPU and memory consumption along the way.

i.e., as long as the TSA is marveling at my junk, I’d like a free cancer check every time I fly.

Image Segmentation: A Generative Adversarial Network to properly segment a medical image – i.e., define the boundaries of a tumor. Right now, this is time intensive and requires expert clinicians (and even then, they can make mistakes), but an AI can pour through a huge volume of images from multiple angles and planes and be able to discern the boundaries of normal and anomalous data. This can also be used as a tool to directly identify anomalies such as tumors or lesions. This is a quantum leap for radiology and can easily be implemented into any sort of teleradiology/teledermatology protocol. Having an AI work to identify and highlight anomalies will decrease the human load of diagnosis and can be incorporated into other scanning technologies.

The Big Take-Away

Generative Adversarial Networks will be the Healthcare IT disruptor of 2018, both for good and ill. Stop caring about Blockchain and start caring about this, before you’re left adding the term to your company name in an attempt to puff up your market value. Money will have no value in the robot apocalypse anyway.

Open the Pod Bay Doors, HAL!

Sorry, guys, I can’t do that. The can of worms has been opened and 2018 is going to be just as chaotic a year as 2017. Perhaps more. The future is here, and it’s already broken. (If you click on no other link in this article, click on that one and read it fully.) The best we can do is use our knowledge of human – and now artificial intelligence – psychology to fix it, bit by bit, and piece by piece. Like nuclear power in the 20th Century, artificial intelligence can be used for great destruction or great benefit. As citizens and professionals, we must work with the Government and hold it accountable to ensure that these great disruptors are handled responsibly and for the benefit of all humankind. Hopefully this article will spark thought and open minds and allow us all to keep our progress on the rails.

Postscript

Now that’s the kind of disruptor I can get behind. Happy 2018.

With all this talk of disruptors, I’d be remiss if I didn’t take time to thank Sara Byrd of Intelligent Waves for crafting the greatest housewarming present ever. You know those chintzy cross-stitches that say “Bless this mess” ? Well, I wanted one, but with a sufficiently nerdy twist. I asked if she could make a cross-stitch of this scene from Star Trek, and she delivered. Thank you Sara, for giving me the greatest disruptor of 2018. ?

For more Meaningless Use, click here.

 

 

[related-post]

LEAVE A REPLY

Please enter your comment!
Please enter your name here

FedHealthIT Xtra – Find Out More!

Recent News

Don’t Miss A Thing

FORUM Editor
FORUM Editorhttps://insights.govforum.io
Content Analyst for FORUM and Author on the Daily Take Newsletter for G2Xchange Health and FedCiv.

Subscribe to our mailing list

* indicates required