Archive for the ‘Medical Devices’ Category

Interoperability: Arrested Progress

Sunday, July 28th, 2013

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.

The Importance of Software Development in Medical Device Industry Growth

Saturday, May 18th, 2013

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

Sunday, February 24th, 2013

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.

Medical Device Innovation Consortium

Wednesday, December 5th, 2012

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.

When Open-source can Kill or Cure

Wednesday, June 6th, 2012

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.

Building Safety into Medical Device Software

Saturday, January 7th, 2012

The article Build and Validate Safety in Medical Device Software takes a critical look at the current processes for medical device software and concludes:

The complexity of the software employed in many medical devices has rendered inadequate traditional methods (testing) for demonstrating their safety.

The article then provides examples of the types of analyses that can be performed to better ensure safety.

Interesting read.

Here are some references:

BohrBug: Not necessarily easy to find, but once discovered is reproducible.

Heisenbug: The ever-annoying bug that can not be reliably reproduced.

Spin: An open-source software tool for formal verification of distributed software systems.

Guest Article: RFID Systems in Healthcare Institutions

Tuesday, October 25th, 2011

Patient, medication, and equipment asset tracking are critical functions for any healthcare organization.  Yedidia Blonder of Vizbee RFID Solutions, a company providing RFID solutions for healthcare applications and other industries, provides an introduction to RFID technology and its benefits.

What healthcare executive wouldn’t want a system that:

  • Helps nurses locate necessary equipment in seconds?
  • Ensures that only the mother of a newborn or a nurse could remove that baby from the nursery?
  • Makes sure patients don’t wander into staff only areas?
  • Lists inventory of all the medications in a large medicine storage area in minutes?
  • Ensures even equipment distribution across wings and prevents theft?
  • Tracks disinfection patterns of employees?

Enter RFID.

RFID (radio frequency identification) is a technology in which radio waves emitted from electronic tags identify them uniquely. The tags are often used to pinpoint the location of the object, or person, to which the tag is attached. This is different than barcode technology, which is usually used to identify an object as belonging to a larger category without individual identification. Barcodes also need to be read one-by-one from very close proximity, whereas RFID readers can read many tags with a single pass of an RFID reader a few meters away.

How does RFID work?

First you need the tags. RFID tags can be split into two main categories: active tags and passive tags. The active tags are battery operated and transmit their data periodically to readers. Their reading distance varies between a few meters to hundreds. Passive tags are much smaller (sometimes like a paper sticker) and do not transmit their data until being interrogated by a reader in their proximity. The passive tags' reading distance can reach 2-3 meters. Passive tags are usually used for inventory purposes.

The readers consist of an RFID antenna connected to an RFID reader. They receive the data from the tags and then, in order to have a functioning system which will do all the above tasks, transmit the data to a software system which manages the received data.

When the system receives the data, it will both store it for immediate or later review by the healthcare staff, as well as act according to predefined rules set by the administrator. For example, in the case of preventing equipment theft, a rule could be set that if tags attached to pieces of expensive lab equipment go past the reader stationed near the exit to the lab, its signal will set off an alarm, alert important staff members, and lock the exits to that wing of the hospital.

How can RFID help a healthcare institution?

Keeping in mind the stunning figure of 15% of hospital equipment stolen annually as well as the damage that improper maintenance causes, RFID tracking can significantly diminish losses and increase efficient use of equipment. It can ensure that only the right person uses or moves any given piece of equipment, guarantee the correct quantities of a certain apparatus in a designated zone, enable the immediate and accurate location of any item, indicate which item is in use or available, and the list goes on.

RFID can also provide an accurate and comprehensive picture of the total amount of the organization’s inventory, including expiry dates and amount of usage, and provide real-time data on parameters such as temperature and moisture levels, providing alerts in the case of inappropriate conditions that could damage equipment and medications.

Add to this the capacity to track patient and staff movement and interactions with other people and objects - and your RFID healthcare system gives you your entire hospital at a glance, and alerts you to problems.

Implementing RFID systems.

RFID technology is also getting easier to customize. In the past, often RFID hardware would be programmed to work only with specific software. Recently, there have been advances in RFID technology enabling administrators to choose hardware and software independently according to the unique needs of each project. Parameterization tools built into the software can customize applications to specific projects while enabling the implementation of RFID projects in a very short time (days to weeks). You no longer have the time, expense and risk that come with developing software just for your project.

With RFID systems, managing healthcare institutions is getting easier, safer and more efficient.

UPDATE (9/8/2012) : Tim has written an excellent article on the subject:  RFID RTLS Update – Where to Start

Open Source Medical Device Connectivity

Sunday, October 2nd, 2011

In The Case for Open Source Healthcare IT John Zaleski uses the VistA open source software as a model for improving the medical device data gathering in order to produce a "more robust end product".  On the whole, I could not agree more. Achieving this in such a diverse and fragmented community would be a real challenge, but it may indeed be a worthwhile path to pursue.

There was one item I'd like to comment on:

The challenge is, of course, regarding regulatory management of open source frameworks. To a large degree open source software is anathema to the FDA regulatory process–and it relates to control and management of access.

OSS detested or loathed by the FDA? I don't think so. The open source framework itself would not be subject to regulatory control.  The FDA does not really care where any specific software component comes from.  Also, security and  access management are certainly important, but I'm not sure of their applicability at the device connectivity level.

The FDA cares about intended use, efficacy, and safety of medical devices. All FDA regulated software is subject to the same design controls (§820.30) -- design, risk analysis, verification, validation, etc. I.e. any company that included these open source software components would ultimately be responsible for proving these processes are followed.

Shahid N Shah's OSCon 2011 Talk: The implications of open source technologies in safety critical medical device platforms does a good job of detailing these points (Will the FDA accept open source in safety-critical system? Yes!) as well as presenting an OSS connectivity software architecture.

Third Annual Medical Device Connectivity Conference

Sunday, August 14th, 2011

This year’s Medical Device Connectivity Conference is less than a month away. It's being held Sept. 8-9, 2010 in Boston.


In addition to the post-conference workshops, there is also a special preconference event: an open house at the Medical Device Plug and Play Interoperability program’s lab. September 7, from 4pm to 6pm attendees can tour the lab, interact with various demonstrations and chat with program staff.

Tim has put together another great conference.

Discomfort with Computerized Medical Devices

Monday, April 11th, 2011

Here are some thoughts regarding the article: I feel a little uncomfortable about computerized medical devices, and here's why.

  • Just about all medical devices are computerized these days. Most will not harm or kill you if their software fails (Class I & II), but that's no excuse for writing crappy code.
  • As pointed out, the mission critical nature of mass transit systems (airplanes, subways, etc.) affords those industries a much higher level of scrutiny then cars or medical devices ever will. But that's still no excuse for writing crappy code.

Even through drugs and airplanes need advance approval from authorities before being brought to the market, medical devices and software do not, at least in the United States.

  • This statement is not correct. All medical devices, including diagnostic and therapeutic software-only products, require FDA clearance to be sold in the US market (see the Class I & II link above).  There are many exemptions, but a 510k pre-market approval is generally a minimum requirement. After you receive approval the FDA can pull your device off the market (the dreaded “recall”) at any time due to complaints or unsatisfactory audit results.
  • The FDA QSR Subpart C (§ 820.30) looks a lot like DO-178B as quality system design controls go, but I'm sure the aviation standard enforcement is far more rigorous (well, at least I hope it is). It's true, there are no coding standards for medical device software.  Good companies set their own development standards and practices -- some even use static analysis! It's all the other companies that don't bother to do anything that you have to worry about.

I'm certain that static analysis technology has improved vastly in the four years since some of the articles below were written.  The challenge is that the complexity of medical device software and the systems they run on has also increased tremendously during that time. In particular, the explosion of high bandwidth wireless networks along with advances in handheld computing power and graphics capability (think iPhone/iPad, of course) is fundamentally changing the way medical devices will be developed and delivered to the market in the future.

Static analysis will remain a valuable tool for identifying critical software defects, but new methods will have to be developed for rooting out risks in the new network-connected, multi-touch world.

It's sad to say, but you should probably be more than "a little uncomfortable."

Other static analysis articles:

A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World
More Software Forensics and Why Analogies Suck
Medical Device Software Forensics
Pascal's 3 part static analysis series that starts here:
Guest Article: Static Analysis in Medical Device Software (Part 1) — The Traps of C