Bob on Medical Device Software

Tim Gee’s EMR Connectivity for Medical Devices Is a Mess post is right on target. I’ve also expressed my opinion (”total chaos”) on this, but as you’ll see I’m coming from a different perspective.

The HealthLeaders Technology article primarily focuses on the challenges of interfacing medical devices in the hospital environment. I think the situation in a physician’s private practice or small group office is even worse.

The needs for medical device connectivity in both environments are essentially the same:

• Reduction in medical errors.
• Decrease in paperwork.
• Increased staff productivity.
• Timely delivery of clinical results.

Hospitals have the advantage of working with big EMR vendors who in turn can provide connectivity solutions for a larger variety of medical devices. Also, large hospital chains have enough clout to be able to mandate performance criteria from their vendors that include interoperability.

The typical physician’s office uses a smaller EMR provider (or even worse, a ‘home brew’ system) where in many cases connectivity with external devices is an afterthought, if it exists at all. Even when you work with mid-sized EMR companies, each has their own proprietary external data interface. Very few of these smaller stand-alone EMR management systems provide standard interfaces (e.g. HL7) for external device data capture.

The interoperability problem is not a technical one. The issue is the time and resources it takes to implement and validate a given medical device interface. The real hope of a MD PnP-like solution is that the cost of that interface can be significantly reduced.

So, here’s my perspective. As a medical device manufacturer, when we take our device into a private practice physician that has an existing (or planned) EMR system the first requirement is pretty much always the same. It’s simply that the diagnostic results from our device automatically appear in a patient’s record in their EMR system. To make this happen, they have to choose between three possibilities:

1. Pay the medical device manufacturer (us) to interface with their EMR system.
2. Pay their EMR vendor to do the interface.
3. Find a third party vendor or contractor that will provide or build the custom interface.

The problem with #1 is that we don’t have the resources to build each unique interface required to satisfy all of our customers. Plus that, our business is building medical devices, not EMR solutions.

#2 might not work out because unless the EMR company has a lot of customers with our devices they will either charge a large custom engineering fee or may just say they won’t do it at all. The third option is doable, but is also potentially costly.

Notice that all of the choices require additional investment by the physician. I wonder if these types of issues may be one of the contributing factors for the low adoption rate of EMR for office-based physicians.

Not being able to provide cost-effective EMR integration is bad for everyone involved. It’s bad for a medical device manufacturer (like us) because it makes it that much harder to sell systems. It’s bad for the physician’s office because without EMR integration they’ll end up with a less effective paper-based solution. It’s also bad for the EMR companies because they won’t be able to take advantage of the future opportunities that a fully integrated medical office would provide.

The reasons may be different, but my conclusion about EMR connectivity with medical devices is the same as Tim’s: “It’s a mess.”

UPDATE (7/21/08): Ran across this MIT Technology Review post about the MD PnP program:
“Plug and Play” Hospitals (Medical devices that exchange data could make hospitals safer).

I spent quite a few years developing diagnostic Electroencephalography (EEG) systems and software. I always get a kick out of articles with titles like this one: Microsoft Working On Mind-Reading Software. It’s the mind-reading part that gets me because your first impression is that Microsoft is developing technology that will allow it to somehow detect what you’re thinking. This, of course, will not be happening in the near or foreseeable future.

The work that Microsoft Research is doing in this area (see here) is fundamental research on the Human-Computer Interface (HCI). The Using a Low-Cost EEG for Task Classification in HCI Research article uses standard frequency domain EEG features (delta, theta, alpha, etc.) as classifiers in a Bayesian Network for differentiating three mental tasks. What was interesting to me was that they recognized the limitations of using EEG technology alone as a human-computer interface. The understanding and use of other physiological data (e.g. motor activity) along with EEG will have to be explored as a way to improve task detection.

Not only is this type of work important for meeting the needs of the physically disabled, as the Wii and Surface have shown, innovative HCI systems can have a dramatic affect on how we all interact with computers.

‘Thought-reading’ system controls wheelchair and synthesizes speech is another one. The system processes larynx nerve signals for speech synthesis and wheelchair control. The technology looks very cool and has the potential to improve the lives of handicapped individuals. I suppose you could consider motor neuron activity as the output of thought, but ‘thought-reading’ just feels like a misnomer. Maybe it’s just me.

Another ‘mind-reading’ technique is the use of Evoked Potentials (EP). One that got a lot of press is a few years back was Brain Fingerprinting (also see here). I’m sure there’s still on-going research in the P300 area, but nothing has grabbed much attention since.

Also, checkout Computers can read your mind. Amazing!

UPDATE:

I found some companies that appear to be trying to use EEG processing algorithms for HCI. Both are focused on the gaming industry. They provide no details on how their products work, so it’s hard not to be skeptical about their functionality claims.

NeuroSky

Emotiv

Also, Smart BrainGames provides more classical biofeedback development systems. All are mentioned here.

UPDATE-2:

Here’s another interesting technology: Functional near-infrared spectroscopy (fNIRS) is an emerging non-invasive, lightweight imaging tool which can measure blood oxygenation levels in the brain. Check out the article here.

UPDATE-3 (15-Oct-2007):

Here’s the Microsoft patent application: Using electroencephalograph signals for task classification and activity recognition (via here).

UPDATE-4 (13-Nov-2007):

Check out Brain2Robot Project which uses EEG signal processing (my highlighting):

Highly efficient algorithms analyze these signals using a self-learning technique. The software is capable of detecting changes in brain activity that take place even before a movement is carried out. It can recognize and distinguish between the patterns of signals that correspond to an intention to raise the left or right hand, and extract them from the pulses being fired by millions of other neurons in the brain. These neural signal patterns are then converted into control instructions for the computer.

If they can do this reliably, that’s quite an accomplishment.

In this months IEEE Spectrum magazine there’s an interesting article about Microsoft’s efforts in robotics called Robots, Incorporated by Steven Cherry.

The article describes the team that created Microsoft Robotics Studio, how the group came to be, some of the software technologies, and an overview of the Microsoft’s strategy in the Robotics marketplace.

What prompted this post is an example of how robotics might be used for medical purposes:

Imagine a robot helping a recovering heart-attack patient get some exercise by walking her down a hospital corridor, carrying her intravenous medicine bag, monitoring her heartbeat and other vital signs, and supporting her weight if she weakens.

Also, in the discussion about multi-threaded task management:

Or there might arise two unrelated but equally critical tasks, such as walking beside a hospital patient and simultaneously regulating the flow of her intravenous medications.

It’s clear that these are just illustrative examples and there’s no attempt to delve into the complexities of how to achieve these types of tasks. What I think is enlightening is that it provides examples of what the expectations are for robotics in medicine.

There are many research efforts in this area, but there’s not really a lot of commercialization yet. There are numerous efforts in Robotic Surgery and robotic prosthetics (e.g. see iWalk) hold a lot of promise for improving lives. It’s not exactly robotics, but the integration of an insulin pump with real-time continuous glucose monitoring for diabetes management (see the MiniMed device) can certainly be considered the application of “intelligent” technology.

I think that the expectations for the future use of robots for medical purposes are as realistic as any other potential use. There are some areas where the technological hurdles are very high, e.g. neural interfacing (see BrainGate), but many practical medical uses will have the same set of challenges as any other robotic application. Human safety will have to become a primary issue anytime a robot is interacting with people. Manufacturers of medical devices have the advantage that risk analysis and regulatory requirements are already part of their development process. Cost is certainly the other major challenge for the use of robots in both the consumer and medical markets. No matter how good the solution is, it must still be affordable.

There’s a lot going on and keeping track of the latest developments can be a challenge. Here are a few sites that I’ve found to be informative and up-to-date:

MedGadget.com
Medical Devices News
Medical Device Link
DoctorsGadgets.com

If you are aware of other good sources, please let me know.

With all of the Apple iPhone hype lately, the Medical Images on an iPhone post caught my eye. Privacy and HIPAA concerns don’t worry me nearly as much as the thought of a Radiologist reading an x-ray while he’s driving to work. Seriously though, improvements in both display resolution and user interface capabilities have come a long way. Apple is not the first to provide this type of functionality. PDA-based medical record applications and image viewers have been around for a long time.