Second Annual Medical Device Connectivity Conference

This year's Medical Device Connectivity Conference is being held Sept. 28-29, 2010 in San Diego.

From the press release Tim Gee says:

The only conference devoted to the topic of medical device connectivity, the program will offer a unique opportunity to get immersed into every aspect of connectivity, workflow automation and enabling technologies. The keynotes and panel discussions on the first day frame the conference's focus on connectivity and tackle two of the biggest issues facing health care: industry standards and regulatory issues. Program tracks on the second day provide a survey of connectivity applications, clinical capabilities and outcomes, and explore the gap between regulated vendor-managed systems and the customer-managed and controlled environments in which these systems are used.

Here are just a few of the topics I'm particularly interested in:

  • EMERGING PROBLEMS AND RISING AWARENESS OF MEDICAL DEVICE SYSTEMS ON ENTERPRISE NETWORKS
  • LOOKING BEYOND CONNECTIVITY IN HOSPITALS TO HOME HEALTH AND MOBILITY
  • OPEN EHR MANIFESTSO: OPPORTUNITIES FOR MEDICAL DEVICE COMPANIES
  • INTEROPERABLE MEDICAL DEVICE SYSTEM ARCHITECTURES

Looks like another great conference!

Posted in Interoperability, Medical Devices | Tagged , | Leave a comment

Closer to Launch: Healthcare IT Q&A

The reverse psychology I used in Failure to Launch: Healthcare IT Q&A is finally starting to work. The question definitions are complete and the commitment phase has begun:

Go over and sign up today.

Posted in General | Tagged , , | 3 Comments

A Threat Analysis of Networked Medical Devices

Here's an interesting analysis of security threats within a Windows-based hospital network for embedded medical devices: A threat analysis of critical patient monitoring medical devices.

The threat models are fairly complex and clearly a product of wider enterprise network IT security needs. I've discussed some of the other issues of putting medical devices on an institutional network in Networked Medical Devices. Security threats were not covered and this is an important topic for every hospital network.

There are a couple of items in this article worth commenting on.

The top five unmitigated threats were found to be:

The corrective action for the top threat (T002) was (my highlight):

After it was decided to remove all ePHI from the medical device data storage, the risk assessment changed and the threat of the medical device infecting the hospital enterprise network (T017) then became our primary concern.

This may be the "most effective countermeasure possible for HIPAA compliance and protecting patient privacy", but it is a not practical solution in the real world. Many medical devices store patient demographics. Because the benefits of patient identification outweigh the security risks, this practice is not likely to change in the future.

On these questions:

  1. Can the medical devices be infected from the enterprise network?
  2. Can the medical devices be infected via removable media?
  3. Can infected medical devices propagate malicious software back into the enterprise network?

I generally agree with the conclusions for the device under analysis. The challenge for a hospital is how do you ensure that every networked medical device follows these best practices (communications integrity, hardened OS, clean distribution media, etc.)?

Posted in HIPAA, Medical Devices, Microsoft | Tagged , | 2 Comments

Technical Debt in Medical Software

Software development is software development. Most of the life cycle and quality issues faced in medical software are the same challenges for any software product. Technical Debt in Medical Software points out what technical debt is:

  • Complexity
  • Code Duplication
  • Documentation Debt
  • Testing Debt
  • Architectural Debt

A Martin Fowler article is referenced that nicely identifies the source of technical debt:

The benefits of paying down the debt are:

  • Increased R&D efficiency and improved time to market
  • Hitting commitment dates
  • Performance and technology upgrades

Of course if you don't want to pay it off, there's always the option to go bankrupt. This may have long-term advantages, but it will surely be a more expensive route. There is one statement in this regard that I think needs some qualification:

In this case the technical debt can be retired along with the legacy system, and like filing Chapter 11, you are no longer responsible to address all the sins of the past.

I know this refers to code sins, but just because you decide to do a re-write doesn't mean you no longer have responsibility for the legacy product. You still have customers using the old software that you're obligated to continue to support.  For FDA approved medical software, this is a legal requirement. Most of the time this means that the legacy code will need to be maintained and periodically updated in the field, sometimes even after the "new" product is released. This just makes the cost of bankruptcy even higher.

Posted in FDA, Programming, Software Quality | Tagged , , | 2 Comments

Failure to Launch: Healthcare IT Q&A

It seems like a great concept (to me anyway). Grow a community of like-minded Healthcare IT geeks that want to participate in an on-line Q&A site which rewards contribution and facilitates constructive dialog. As of today, it appears unlikely this will happen anytime soon.

Even after being endorsed on HISTalk News 6/25/10 less than 900 people have visited the site.

The attraction that programmers have for Stack Overflow just doesn't translate for this group of professionals. I suppose it's the nature of the business.

  1. Programming, like Food and Cooking, have a much larger audience. Since only a small percentage of the interested population will actively participate or become community leaders, the numbers game is critical.
  2. Even though Healthcare IT seems like a broad topic, the number of non-subjective questions that could be asked is probably fairly limited.  The .NET Framework and bread recipes have tons of facts.
  3. Maybe HIT experts are a shy bunch?  The activity level also seems surprising low on Chris Paton's Health Informatics Forum site which has over 4000 members.

Anyway, it's really too bad there isn't a way for a site like this to gain traction. It would be a valuable HIT resource if it could get off the ground.

Posted in General | Tagged , , , , | 1 Comment

ISO 62304: The Harmonized Standard for Medical Device Software Development

The FDA approved ISO 62304 as a recognized software development standard in 2009. Developing Medical Device Software to ISO 62304 gives a nice overview.

Besides providing a globally accepted development process one of the other practical components is the assignment of a safety class to individual software items and units:

  • Class A: No injury or damage to health is possible
  • Class B: Non-serious injury is possible
  • Class C: Death or serious injury is possible

Each classification changes the required documentation for the assigned software.

These standards will become more widely known as the FDA moves to regulate the proliferation of medical applications for personal and home use, most notably software that runs on mobile devices. I've discussed this before in When Cell Phones Become Medical Devices. As noted more recently in FDA oversight may extend throughout health IT:

... an FDA director stated flatly: "Under the Federal Food, Drug and Cosmetic Act, HIT software is a medical device."

Broad FDA oversight at the QSR/62304 level will probably not happen, but change is certainly coming for many HIT companies.

The Elsmar Cove Forum IEC 62304 - Medical Device Software Life Cycle Processes has a lot of discussion on this topic. This is where I found a document checklist that is useful for understanding the process scope:

IEC62304_Checklist.xls (Excel spreadsheet)

UPDATE (9/9/10): IEC 62304 – The Basics

Posted in FDA, Medical Devices, Software Quality | Tagged | 7 Comments

The Software Quality Balancing Act

Andrew Dallas's article Caution: V&V May Be Hazardous to Software Quality touches on a number of good points regarding software quality best practices.

Medical device software development V&V (also see here) and the documentation that goes with it have substantial costs. Any strategy that can reduce this overhead and still meet the necessary quality standards should be seriously considered.

The use of "incremental" software development approaches really refers to Agile methodologies.  I've talked about the use of Agile for medical device software development several times:

Most of the discussion revolves around the risks associated with this approach. The benefits of any process change have to be weighed against the possible risks that might be introduced.

Besides the importance of understanding what V&V documentation the FDA actually wants to see, Andrew makes a great point about producing quality software versus the V&V process (my highlight):

V&V is not software testing. Verification testing ensures specified requirements have been fulfilled. Validation testing ensures that particular requirements for a specific intended use can be consistently fulfilled.

Following the required FDA V&V processes alone is not sufficient to ensure software quality. You also have to adhere to software development best practices at all levels. For example, in addition to non-functional requirements there are many software quality factors that require careful design considerations and testing that you may decide are outside the scope of FDA reporting.  Deciding what to report and what to leave out is the balancing act.

Posted in Agile, FDA, Medical Devices, Software Quality | Tagged , | 1 Comment

Interoperability is a Big Word!

There was a statement in one of the HIStalk Readers Write 5/10/10 articles in that I haven't been able to get out of my mind. In Digging for Gold in your HIT Applications, Ron Olsen writes:

One of the most over-used buzz words in healthcare IT is “interoperability,” a is really a big word that self-important people use to describe data transfer.

OMG, I've been using that word for a long time...

All joking aside, for the most part Mr Olsen's advise to get more out of existing IT tools is a reasonable suggestion. Unfortunately, interoperability means a lot more than just "data transfer" (see Healthcare IT Interoperability Defined), and is where the advise breaks down.

Scripting tools can manipulate those files, turning them into almost any format imaginable. With the correct format, data can be transferred to disparate systems, individually or concurrently, via a data stream.

The fundamental flaw in this statement is the oversimplification (sorry, another big word) of the problem. Simple scripts are good for simple tasks. Communicating medical data reliably and securely between disparate systems is not a simple task.

I would also encourage all HIT professionals to fully understand the tools at their disposal in order to improve the efficiency and effectiveness of their organizations.  There may be a few nuggets, I'm not so sure that there will be a whole lot of gold to be found when it comes to  interoperability.

Posted in EMR, Interoperability | Tagged , | 1 Comment

To Validate and Verify: Software Issues Solved

Yours truly was interviewed for this article:

To Validate and Verify: Software Issues Solved

"V&V" is one of those topics that should be simple to understand, but for some reason is the source of a lot of confusion. This is evident in the comments on Software Verification vs. Validation.

It is also interesting to note that the differing interpretations of these definitions results in a wide variety of V&V strategies and plans. From a regulatory point of view there is no single right or wrong way to do it. It's similar to the implementation of quality systems in general.  If you say you are going to do something you need to be able to prove that you're actually doing it.

Posted in FDA, Software Quality | Tagged | 1 Comment

Personal EEG-based Communications Device

The IntendiX (by g.tec) is a BCI device that uses visual evoked potentials to "type" messages on a keyboard.

The system is based on visually evoked EEG potentials (VEP/P300) and enables the user to sequentially select characters from a keyboard-like matrix on the screen just by paying attention to the target for several seconds.

P300 refers to the event related averaged potential deflection that occurs between 300 to 600 ms after a stimuli. This is a BCI research platform that has been made into a commercial reality.  The system includes useful real-life features:

Besides writing a text the patient can also use the system to trigger an alarm, let the computer speak the written text, print out or copy the text into an e-mail or to send commands to external devices.

I'm usually skeptical of "mind reading" device claims (e.g. here), but P300-based technology has many years of solid research behind it. It may be pricey ($12,250) and typing 5 to 10 characters per minute may not sound very exciting, but this device would be a huge leap for disabled patients that have the cognitive ability but no other way of communicating.

(hat tip: medGadget)

UPDATE (3/24/10): Mind Speller Lets Users Communicate with Thought

Posted in EEG, HCI | Tagged , , , , | 2 Comments