Archive for the ‘Medical Devices’ Category

Bioimpedance Analysis to Detect Sleep Apnea

Tuesday, February 11th, 2020

The company I worked for over 10 years ago, CardioDynamics*, manufactured an impedance cardiography (ICG) diagnostic device. The technology behind ICG and the Onera Bioimpedance Patch to Detect Sleep Apnea is called thoracic electrical bioimpedance (TEB).

It's no surprise that Onera has leveraged research on monitoring lung resistivity with this technology (e.g. here and here) and is applying AI for automated respiratory event detection. Since electrode placement is important for reliable data acquisition, the patch is a good design choice, but it doesn't look like it would be that comfortable to wear to sleep.

Another review, Wearable Patch Uses Machine Learning to Detect Sleep Apnea, notes that assessing sleep apnea requires additional physiological signals to be monitored and that more work needs to be done to combine this technology with these other signals.

………………………………………………

*Purchased by SonoSite in 2009. SonoSite has since stopped manufacturing the BioZ DX.

The Real Impediment to Interoperability

Tuesday, February 7th, 2017

Medical device interoperability is one of my favorite subjects. With the meteoric rise of  IoT, there's more and more discussion like this: Why we badly need standardization to advance IoT.

The question for me has always been: Why is standardizing communications so hard to achieve?  Healthcare providers, payors, EMR vendors, etc. have their own incentives and priorities with respect to interoperability.  The following is based on my experiences as a medical device developer and has many similarities to the IoT world.  As such, these observations are probably not applicable to many parts of the healthcare domain.

The Standard API

Let's use a simple home appliance scenario to illustrate why interoperability is so important. Let's say you have a mobile application that wants to be able to control your dishwasher. It may want to start/stop operation, show wash status, or notify you when a wash is complete.  An App without and with interoperability are shown here:

Notes:

  • Without a standard API: The application has to write custom code for each dishwasher vendor. This is a significant burden for the App developer and prevents its use by a wider customer base.
  • With a standard API: New dishwasher models that implement the "dishWasher API" will just work without having to change the application (ideally anyway).  At the very least, integration of a new model is much easier.

Having a standard API that every App (and as importantly, other devices) can use to interoperate is critical for IoT (appliances and medical devices) growth. Besides all of the obvious benefits, in the healthcare industry the stakes are even higher (from Center for Medical Interoperability -- Need for Change):

It will improve the safety and quality of care, enable innovation, remove risk and cost from the system and increase patient engagement.

The other important thing to note is that the API communication shown above requires full Semantic interoperability. This is the most rigorous type of interoperability because the App must understand the full meaning of the data in order to function properly. E.g., knowing that a temperature is in ºF as opposed to ºC has significant consequences.

Let me also point out that even though semantic interoperability is not easy, the barriers to achieving it are generally not technical. There may be points of contention on protocols, units of measure, API signatures, and functional requirements, etc., but when you're working within a specific discipline these can usually be worked out.  Non-healthcare industries (telecom, banking, etc.) have proven it can be done.

Cost of Standards

There are a number of adoption hurdles for using standards (e.g. HL7, FHIR, etc.). The cost of implementing and maintaining compliance with a standard are non-trivial.

  • The additional development and testing overhead required. On the development side, these interfaces are many times not ideal for internal communication and can have a performance impact.
  • Some standards have a certification process (e.g. Continua Certification Process) that require rigorous testing and documentation to achieve.
  • If you have a data element that the standard does not currently cover, you may be faced with having to deal with the standard's approval process which can take a significant amount of time. For example, see the FHIR Change Request Tracking System which currently has thousands of entries. Again, this is not a technical issue. Having to deal with bureaucracy is just part of the overhead of conforming to a standard.

Company Motivations

Now let's try to understand what's important to a company that's trying to develop and market a product:

  1. Product differentiation. Provide vendor-unique features (a "niche") that are not available from competitors.
  2. Time to market. Being there first is critical for brand recognition and attracting customers.
  3. One-stop shop (multi-product companies). "If you use our product family your experience will be seamless!"

The last item is particularly important. Following the appliance theme:

This strategy is of course how Apple became the largest company in the world. In most industries, the big companies have the largest market share. This "walled garden" approach is the most natural way to lock out both large and small competitors.

The First Hint of Problems

Notice that the cost of interoperability can affect all three of the market goals a company is trying to achieve. Standards are:

  1. A "me too" feature.
  2. They take time to implement.
  3. They punch holes in the desirable closed platform.

The actual impact depends on a lot of factors, but it can be significant.

The Real Impediment

But the real elephant in the room is this: Return on Investment:

The ROI on interoperability is inherently very low and often negative (Gain < Cost). This is because:

  1. As noted above, conforming to an external standard has a significant cost associated with it.
  2. Lack of demand. Interoperability is not something a customer is willing to pay extra for (zero Gain).

I think companies really do care about patient safety, quality of care, and healthcare cost reduction. This is what motivates their business and drives innovation. The reality is that ROI is also a factor in every product decision.

Side note: If conforming to a standard was mandated as a regulatory requirement, then the ROI becomes moot and the expense would just be part of the cost of doing business.

I'm sure that interoperability is on every company's feature backlog, but it's not likely to become a primary actionable priority over all of the other higher ROI functionality. Those other features also contribute to improving healthcare, but the bottom line is hard to ignore.

Contributing resources and putting a logo on a standards organization's sponsor website is not the same thing as actually implementing and maintaining real interoperability in a product.

Apologies for the cynicism. It's just frustrating that nothing has really changed after all these years. Interoperability: Arrested Progress is close to four years old, and same old, same old (insanity) still prevails.

I think the reasons outlined here are a plausible explanation of why this is so. We're all still waiting for that game-changer.

Empires of Medical Devices

Monday, August 10th, 2015

Even the IoT (Internet of Things) world is concerned about interoperability: Do We Really Want Empires of Connected Things?

Here are a couple of key quotes:

...little hope for open standards or a universal language for how they do that. It's time for regulatory guidance to make that happen.

...one analyst observed that the industry seems to be forming "walled gardens" rather than a coherent network that encourages openness and interoperability.

Sound familiar? This is the same medical device interoperability struggle that has been going on for over 25 years.  The IoT is still in its infancy and I sure hope they have better luck developing a "common carrier" than we did.

Software Doesn’t Have An MD

Sunday, January 25th, 2015

Core O.S., core, Photo: Alex Washburn / WIREDI got a kick out of this Andreessen Horowitz piece: Digital Health/SOFTWARE DOESN'T HAVE AN MD.

I'm sure 'the kid in the garage without a degree' is no dummy, but this premise:

And so that large percentage of medicine that is effectively being practiced by non-MDs is going to expand.

is simply ludicrous.

There's a big difference between creating health and wellness appliances and mobile applications and diagnosing and treating patients. The distinction is outlined in FDA clarifies the line between wellness and regulated medical devices.  If you claim your product acts like a doctor (treat or diagnose) or doesn't fall into the "low risk" category, then your company will have to follow FDA regulatory controls.

An Unhealthy Lack Of Standards

Tuesday, June 3rd, 2014

apple-healthkitThe reality of healthcare interoperabilty is going mainstream: Apple Launches HealthKit To Share Vital Stats With Nike, Mayo Clinic:

The problem Apple will run into: No one agrees on how to measure even very simple health metrics, ...

TL;DR:  iOS 7.1 to iOS 8.0 API Differences (search for 'HealthKit' on the page).

UPDATE (8/18/14);  Apple - iOS 8 - Health

Interoperable Healthcare

Tuesday, March 25th, 2014

icu-interopThis is a good read: Healthcare Innovation Day 2014: Igniting an Interoperable Healthcare System (warning: PDF).

Healthcare is the one industry that’s been the slowest to adopt the intelligent methods we have in most other parts of our lives. How did the communications revolution that transformed industries such as banking, entertainment and telecom somehow leave healthcare behind?

Great question!

Here's the 'Call to Action' list:

  1. Recognize that the lack of interoperability is a crisis and advocate for rapid change.
  2. Frame the interoperability problem correctly: Everyone is in the business of gathering and sharing data to best serve patients.
  3. Accelerate the full adoption of unambiguous, open standards for interoperability.
  4. Align stakeholder incentives to drive interoperability.
  5. Ensure validity, privacy, and security of data.
  6. Reduce technical complexity for hospitals, health systems, and healthcare workers.
  7. Develop new ways to use data streams that will result from interoperability to drive an adaptive system that will improve patient health.
  8. Guarantee secure access to data for patients, researchers.

There is a lot to do...

Services, Not Sensors

Sunday, March 9th, 2014

internetofthingsThe Internet Of Things: The Real Money Is The Internet, Not The Things (my highlight):

The trick will be whether hardware companies will push hard enough for standardization so they can capitalize on services revenue. Companies that see themselves as pure hardware manufacturers are likely doomed, but those that see beyond the "things" to instead focus on the services built on the "Internet," the future is very bright.

Is this the new reality for the medical device industry as well?  If data and interoperability are the future, maybe it should be!

The Internet of Medical Devices

Sunday, January 19th, 2014

iotThe Internet of Things (IoT) is being propelled by the dramatic reduction in size, power consumption, and cost of networking and computing capability.  Many of the devices listed in the Wolfram Connected Devices Project are health related. "Things" like weight scales and thermometers can make measurements from many objects, but when that object is a human body, they effectively become medical devices. The sensors that come standard on smart phones also fit into this category. All of these network-connected devices that record data from humans make up the Internet of Medical Devices (IoMD).

In most ways the invasion of technology in Healthcare is no different than how mobile digital capability is changing that way we all live. For Healthcare though, the potential benefits of applying these technologies to solve both the cost problem and to improve patient safety and outcomes are tremendous.

The number of technologies and innovations (health tracking apps and devices, home monitoring, medication management, etc.) that are contributing to these goals are too numerous to count. From a medical device perspective there are four primary areas of concern that need to be addressed as the IoMD grows.

1. Interoperability
As I've written about many times (e.g. Interoperability: Arrested Progress), health data interoperability is a key factor in realizing both cost reductions and improved patient outcomes. Unfortunately, medical data is notoriously complex, which makes effective communication between systems very difficult.

Another significant barrier to interoperability are EHR interfaces. The issue is that each EMR vendor has a propitiatory interface for consuming device data and associating it with a patient record.  Without a direct device interface, data has to be manually transcribed into the record which is expensive and error prone.

This is a particular problem in the ambulatory EMR market because there are literally hundreds of vendors.  Even if they all used a standard like HL7 there is still interfacing work that has to be done for each one.  It is prohibitively expensive for any device company to develop and maintain that many interfaces.

2. Patient Safety
Because proper handling and presentation of medical data pose a safety risk the FDA has recently stepped in:

Most medical software applications, like the ones you might download to your Apple or Android phone, will not be affected by these regulations.

3. Privacy
Even though PHI (Protected Health Information) is protected by Health Information Privacy (HIPAA) laws most people consider their health a very private issue.  Privacy concerns are a significant psychological barrier that must be overcome before sharing of medical data becomes commonplace.

4. Security

Reports like the one described in The Internet Of Things Has Been Hacked, And It's Turning Nasty are not encouraging:

Pinging one device brought up a login screen that said: Welcome To Your Fridge. She typed in a default password—something like “admin” or "adminadmin," Knight said—and suddenly had access to the heart of someone's kitchen.

The IoMD is not immune from this. Hacking Insulin Pumps And Other Medical Devices From Black Hat was big news last year. <TongueInCheek>If we're not careful search engines like Shodan will soon be discovering pace makers near real hearts!</TongueInCheek>

Final Notes

  1. The interoperability issue is not a technical problem per se. It reminds me of the challenges associated with an object-relational impedance mismatch ("Deceptive Similarities, Subtle Differences").  Also, not only are our models of human-derived data imperfect, but two models created for the same thing will most likely be different.
  2. The IoMD must convince the public that their data is safe and secure.
  3. If mobile medical applications and connected health monitoring devices are going to contribute to a more effective Healthcare delivery system they must be able to reliably and securely communicate the data they collect to an appropriate care provider.

UPDATE (1/25/14): Also see: Digital Health In 2014: The Imperative Of Connectivity

UPDATE (2/19/14): I like “Medical Internet of Things” (mIOT) too: Keeping medical device designs relevant in a big data world migrating to outcomes-driven payment models.

FDA Regulation of Mobile Medical Apps

Monday, September 23rd, 2013

fda-logoThe FDA has issued their final guidance on mobile medical applications: Keeping Up with Progress in Mobile Medical Apps. The guidance document (PDF) will "give mobile app creators a clear and predictable roadmap to help them determine whether or not their products will be the focus of FDA's oversight. "

The regulatory approach is as you would expect (my highlight):

FDA intends to apply its regulatory oversight to only those mobile apps that are medical devices and whose functionality could pose a risk to a patient’s safety if the mobile app were to not function as intended.

There are six categories of mobile applications listed that the FDA intends to exercise enforcement discretion:

  1. Help patients/users self-manage their disease or condition without providing specific treatment suggestions;
  2. Provide patients with simple tools to organize and track their health information;
  3. Provide easy access to information related to health conditions or treatments;
  4. Help patients document, show or communicate potential medical conditions to health care providers;
  5. Automate simple tasks for health care providers; or
  6. Enable patients or providers to interact with Personal Health Records (PHR) or Electronic Health Record (EHR) systems.

If a mobile application is considered a medical device it will be classified as such -- class I (general controls), class II (special controls in addition to general controls), or class III (premarket approval) -- and the manufacturer will be required to follow Quality System regulations (which includes good manufacturing practices, §820.30) in the design and development of that application.

For any organization that is not already under FDA regulatory control, this is a big deal. Given that there are 1000's of medical applications already out there, even this limited scope approach will likely affect many companies. More information is here: Mobile Medical Applications.

The guidance includes many examples (including mobile apps that are not medical devices) and an FAQ.

Also see:

 

FDA Recognition of Medical Device Standards for Interoperability

Sunday, August 11th, 2013

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