FDA Recognition of Medical Device Standards for Interoperability

This is a follow-up to Interoperability: Arrested Progress.

The FDA has recognized voluntary interoperability standards for medical devices: Improving Patient Care by Making Sure Devices Work Well Together.

The FDA and HHS has (my highlight):

published a list of recognized standards for interoperability intended to assist manufacturers who elect to declare conformity with consensus standards to meet certain requirements for medical devices.

The standards are searchable here: Recognized Consensus Standards. The Software/Informatics area currently lists 54 items.

Some consider this a “landmark announcement” (see here) but “voluntary” and “elect to declare” just seem like more of #1 (same old, same old) to me.

UPDATE (9/4/2013): More here: FDA Updates List of Recognized Standards, Confusion Ensues

Interoperability: Arrested Progress

When it comes to the state of interoperability in the medical device industry there couldn’t be a better metaphor than Arrested Development*.  A dysfunctional family made up of eccentric well-meaning personalities each doing their own thing, oblivious to each other and the rest of the world.

Healthcare Un-Interoperability has long been one of my favorite subjects. Let’s review where things are these days.

The article Health IT Interoperability: How Far Along Are We? provides a nice summary of the current state of HIT interoperability. This is particularly important because:

hospitals using basic EHR systems tripled from 12.2 percent in 2009 to 44.4 percent in 2012

For better or worse, it’s the monetary incentives of the Affordable Care Act that push doctors to electronic medical records and is the primary reason for the accelerated rate of EHR adoption. The goal of having more electronic health records is to improve the quality of patient care. Reduction of medication-related errors is a great example: Lack of Interoperability has Ownership for Medication ErrorsThe rapid uptake of these systems can also present problems. For example, in Emergency Departments: EHR systems pose serious concerns, report says.

Nevertheless, it’s clear that electronic medical records is the future in healthcare data management. The down-side of this growth from an interoperability point of view is that there are that many more systems out there that don’t talk to each other!

Initiatives like CommonWell and Healtheway are moving in the right direction but are just getting off the ground. Also, these types of efforts are often far removed from the medical device industry and have little impact on software development and interface decision making.

Let’s step back and look at the HIMSS definition of Interoperability:

  1. Foundational: Data exchange with no interpretation.
  2. Structural:  Allows identification of data structure (fields) but not necessarily data content.
  3. Semantic: Data structuring and codification (interpretation) of the data.

For all practical purposes only #3 (semantic) has value when in comes to the exchange of data with a medical device. As noted in Interoperability: Not a non-issue:

Semantic interoperability continues to be a major challenge and, if not addressed, will have a serious impact on the quality of care.

The same point is made here: Interoperability vs Health Information Exchange: Setting the Record Straight.  Just because you can send it (exchange) doesn’t mean the recipient can understand it (interoperability).

One area that is always part of this discussion are standards. It’s unfortunate that due to technical and (mostly) non-technical reasons the following is often true:

standards-vs-interoperability

Even more disheartening is when you read that a standards-based organization (OpenStack in this case) can’t necessarily make interoperability magically happen:

… success depends upon a single large vendor assuming leadership. Interoperability will follow, but it won’t be designed by committee.

The distress of a well-focused cloud computing API involving a hand-full of vendors makes the outlook for HIT interoperability look particularly bleak.  To make matters worse, the use of OSS in FDA regulated products face additional challenges that are not even seen in most other industries (see Open Source Medical Device Connectivity)

This is all good news for businesses that provide products and services that fill the connectivity gap. Companies like CapsuleiSirona, and Nuvon are many times the only effective way to provide an integration solution to a large number of customers.

I should note that there are some bright spots in the interoperability landscape. For example, the Continua Health Alliance has successfully pulled together over 200 companies to create a vision for inter-operable personal connected health solutions.  Also, the West Health Institute is building standardized communication protocols into their embedded software for medical devices. These and numerous other successes provide hope, but are still just the tip of a very large iceberg.

Dr. Julian Goldman sums up the current situation in Medical Device Interoperability: A ‘Wicked Problem’ of Our Time:

Our years of work on medical device interoperability have led us to see the barriers (including technical, business, liability, standards, and regulatory factors) as “wicked problems,” in which there is little agreement about “the problem,” no agreement on a solution, and problem solving is complex because of external constraints.

Others (Is HIT interoperability in the nature of healthcare?) see the proprietary business model of major HIT companies as the primary culprit.

So what are some possible scenarios for the future?

  1. Same old, same old.  This is essentially Einstein’s definition of insanity: doing the same thing over and over again and expecting different results.
  2. Federally enforced standards and regulations.  Dr. Goldman’s suggestion to require manufacturers to fully disclosure their communication interfaces?   Given the current anti-regulatory environment and budget restrictions, this seems unlikely to happen.
  3. A hegemon, like OpenStack above?  The healthcare industry is too diverse and complex. There is no single player that could even begin to tip the scales.

At least for the foreseeable future it looks like #1 (insanity) is going to prevail. If I’m missing some huge game-changer, please let me know.

In the mean time, let another episode begin!

                                             
*No deep meaning here. Certainly not like Arrested Criticism.  I’m just comparing the medical device industry to a bunch of fictional crazy people.

VirtualBox Ubuntu Guest Auto Re-size Display Problem

Oracle-VM-VirtualBoxOracle VirtualBox version 4.2.12 was released on 12-Apr-2013 and caused the following problem: VirtualBox Guest Additions 4.2.12 breaks Ubuntu 12.04 guest. The solution of reverting back to GA 4.2.10 allowed the VM to run but I lost the ability to re-size the guest display.

On 21-Jun-2013 version 4.2.14 was released with a fix to this problem.

GA 4.2.14 does not cause graphics problems but it did not resolve the re-size issue for me. The Ubuntu VM starts up okay, but the display would still not re-size when the host (Windows 7 x64) window size was changed.

The solution to this problem was to change /etc/X11/xorg.conf back to its original configuration (this is the complete un-commented file content):

 Section "Device"
  Identifier "Configured Video Device"
 EndSection
 Section "Monitor"
   Identifier "Configured Monitor"
 EndSection
 Section "Screen"
   Identifier "Default Screen"
   Monitor "Configured Monitor"
   Device "Configured Video Device"
 EndSection

The xorg.conf this replaced had device/monitor/screen sections with specific driver details, e.g.:

 Section "Device"
   Identifier "Configured Video Device"
   Boardname "vesa"
   Busid "PCI:0:2:0"
   Driver "vboxvideo"
   Screen 0
 EndSection

I’ve been using this VM for a number of years and I suspect that older versions of the guest additions made this change.  Apparently newer GAs no longer require this.

Anyway, if you’re having a Ubuntu guest display re-size problem give this a try.

The Importance of Software Development in Medical Device Industry Growth

The bottom line of the article Software Development Must Be Overhauled to Drive Growth in the Medical Device Industry is summed up by this:

The power and reach of converging IT trends means that business leaders need to understand the implications of a software-driven, connected-everything world.

The context of this statement is broad (“Technology Vision”), but it is still a driving force for the Medical Device industry.  Certainly connected-everything, i.e. interoperability, has been an elusive goal (I’m being kind) for medical devices and data systems.

The Accenture report notes the following three Medical Device Industry market trends:

  1. Complexity of medical devices and how software has become a key differentiating success factor.
  2. Growing demand for mobile access to patient data and clinical systems.
  3. The importance and complexity of global markets when creating appropriate software for medical equipment products.

The use of Waterfall vs. Agile methodologies and other software development operating models (“Software Factories”, Outsourcing, etc.) is really dependent on an organization’s culture.  The biggest challenge any company has in this regard is change. Even after the business recognizes the need to “restructure” operations, this is usually easier said than done.

A good example of Medical Device Open Source software is the West Health Institute Medical Device Interoperability project which is developing Standards-based embedded software.  The OSS, Cloud, and “Module Care” sections only touched briefly on regulatory issues. For FDA regulated software there are significant design, risk, testing, and validation requirements that must taken into consideration when incorporating any 3rd party software. Further discussion is here: Open Source Medical Device Connectivity.

Just like many other industries, software is a critical component in Healthcare related products. I think most Medical Device companies already know this. Making software development more efficient (cost-effective) and flexible (to meet ever-changing market needs) while maintaining quality, performance, and security requirements is a difficult balancing act.

Robot Doctors

drrobotThe Atlantic article The Robot Will See You Now is a good read. There’s a lot of discussion about how the AI technology developed for IBM Watson could benefit the health care system. Also, advanced computing combined with the use of smart phones for physiological data collection and transmission has real potential:

As sensors shrink and improve, they will increasingly allow health to be tracked constantly and discreetly—helping people to get over illnesses faster and more reliably—and in the best of cases, to avoid getting sick in the first place.

The preventative component of continuous monitoring could have a significant impact in the effectiveness of healthcare delivery.

The economics and psychology of “Health 2.0″ will be an evolutionary process. The movement towards less skilled healthcare professionals equipped with “clinical support” tools is inevitable.  Hopefully that will be as close as we get to having to visit a robot doctor.

Brain Health Device

MuseHeadbandThe latest incarnation of EEG-based devices comes from Muse – The Brainwave Sensing Headband.

Just like other BCI claims, How Mind-Controlled Games Work – And Why It’s Way, Way Bigger Than That  is a new approach to consumer brain monitoring applications. From the Muse site (my highlighting):

Our early apps will be focused on building the core of your mind to improve intellectual skills such as memory and concentration, or emotional skills like maintaining composure in high stress situations. Other Muse apps would be just plain fun stuff so you could paint or compose music with your mind or play video games using your mind as the game controller.

The FAQ assures you they’re not mind reading and that it’s not a mind control device.

Taking the “brain heath” approach, see CES 2013: InteraXon debuts Muse along with Brain Health System application, is an interesting twist.  I’m a big fan of EEG-based technology. The research efforts and advancements in the BCI field have the potential to improve many lives.

InteraXon is probably doing great things (e.g. the headband is very clever) and they appear to be active in the BCI community. My only issue is with the marketing claims being made.  Just like the mind control game controllers that have come before (see Turning the Mind Into a Joystick), the reality of the current technology is still not able to live up to most people’s expectations.  This seems especially true when it comes to something as subjective as concentration or stress.  Also, painting with your mind — really?

InteraXon raised over $287,000 through Crowdfunding at Indiegogo: MUSE: The Brain-Sensing Headband that lets you control things with your mind. Many of the contributions levels included receiving a device and the brain fitness app.  They also expect to provide developers with a SDK by mid-year. That might be fun to play with.

Medical Device Innovation Consortium

The FDA has announced the Medical Device Innovation Consortium (MDIC)  which aims to help medical device companies get their products to market faster. See FDA, Private Groups Team Up to Speed Device Approval.

The term Regulatory Science is used 12 times on the single page MDIC Web site so it must be important.  The FDA has been using regulator science in other health related areas since early 2010: see Advancing Regulatory Science.

This consortium is part of a much broader strategy (see the strategic plan) to improve both innovation and safety in  FDA-regulated products. The MDIC site talks about subcommittees and projects but it’s unclear what specific medical device topics will be addressed.  It will be interesting to follow their growth and progress.

Hacking Your Brain

BCI research is important work (see here). The availability of reasonably priced hardware and general purpose APIs has made it easy to investigate many aspects of how EEG processing of can be used to control the external environment.

The extrapolation of this work into the concept of mind reading software appears to be inevitable, but even after all these years, is still annoying. The latest incarnation of this is based on reputable work at Universities of Oxford and Geneva, and the University of California, Berkeley:  Hackers backdoor the human brain, successfully extract sensitive data.

To start with, finding a correlation between P300 responses and a person’s image recognition — by 15% – 40% compared to random guessing — isn’t exactly earth shattering.  Also, note that P300 is an average of multiple evoked responses. This requires many repetitions of the stimulus (16 times in this study) to reduce the noise enough and see the signal at all.  As a practical matter, this is a really long way from brain malware.

Checkout Computers can read your mind. Still amazing!

UPDATE 8/21/12:

Here’s the graphic from Hacking the Human Brain? Not As Impossible As You Think about the same research:

I didn’t realize there was a whole website for “NEWS ABOUT BRAIN-COMPUTER INTERFACES (BCI), MIND-CONTROLLED GADGETS & BIOFEEDBACK” — interesting stuff.

Controlling a Computer with EMG

Microsoft has applied for a patent for using finger flexing to control a computer.

I’ve talked many times in the past about the use of EEG technology for computer control (brain-computer interface, BCI).

As discussed in the RWW article, there are many challenges to making this work. Just like with EEG, calibration of the EMG sensors and training will require innovative solutions.

It seems to me that this type of gesture-based control has quite a bit more potential than what can be obtained through the interpretation of EEG signals.  In either case, the big benefit of advancements in these human-computer interface (HCI) technologies is that they could ultimately improve communications capabilities for the disabled.

When Open-source can Kill or Cure

The use of open-source software in medical devices has been a topic of discussion for many years. The Economist article Open-source medical devices: When code can kill or cure highlights continuing activity in the academic community and interest by the FDA in developing processes around its use.

One of the big unknowns in this area is how a community might be formed (Dreaming of Flexible, Simple, Sloppy, Tolerant in Healthcare IT  has some thoughts on this).

From the article:

Eventually, medical devices might evolve into collections of specialised (and possibly proprietary) accessories, with the primary computing and safety features managed by an open-source hub.

This is in reference to both hardware and software, but in either case one major challenge will be how to incentivize contributions.  Open-source means free to use and modify. If there is no financial gain to be had, other benefits for contributing need to be developed.  Also, proprietary and open-source in the same sentence seems like an oxymoron, so I’m not sure how that’s going to work.

Another barrier would be liability risk. Let’s say you contributed software to this hub and that component ended up in a device that harmed or killed someone.  All of the legal waivers, disclaimers, and releases in world wouldn’t necessarily keep you out of a court room.

I don’t think the basic arguments discussed in Open Source Medical Device Connectivity have changed a great deal.  At the end of the day the medical device manufacturer will ultimately be responsible for ensuring the safety and efficacy of their device.

Subscribe

Categories

Twitter Updates