The Internet of Medical Devices

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.

The Zigzag Career

I agree with Udi Dahan’s Thoughts on a career in software development premise that developers will eventually be faced with a management “opportunity” at some point in their career.

It’s too bad that this is usually a “fork in the road” decision. I don’t think companies are necessarily trying to pigeonhole developers, but they certainly have specific roles (with associated job descriptions) they are trying to fill.  It makes sense though. For large software projects, being a manager (and probably a scrum master) is a full time job.  Put another way, if you try to split your time between being a contributor and a manager, you’ll probably do both jobs poorly.

My advise is to make this type of decision with your eyes open. If you have a management opportunity and it’s something you’re interested in, take it. Treat it like the career change that it is. Get the additional training and improve your skills just like you would be doing if you were learning a new technology. Management isn’t easy. It takes time and work get good at it.

Also, good companies do not pigeonhole technical managers. You will probably have the ability to switch back to a development or architect role as business needs and priorities change in the future.  This could mean moving to a different company, but both you and your current employer know this.  Switching from management back to a technical track will require yet another skills learning curve and a mindset change.

The way to create a Zigzag career is to go with the flow.

Whether you experience success, failure, or somewhere in between, each one of these transformations involves significant personal and professional growth.  Also, no matter what you do always stay at the top of your game: Continuous Learning: 14 Ways to Stay at the Top of Your Profession.

Brain-Inspired Computing

zeroth-npuBringing artificial intelligence to mobile computing is a significant challenge. That’s the goal of Qualcomm’s new Zeroth Processors.

Mimicking the human nervous system and brain to allow computers to learn about their environment and modify their behavior based on this information has long been the goal of artificial neural networks.  Whatever computing model is used to achieve this capability the real problem is one of scale. The human brain is estimated to have 100 billion neurons — with 100 trillion connections. That is at least 1,000 times the number of stars in our galaxy.

These computational models can be implemented in software (e.g. Grok), but the ability to scale to the levels required for even simple human-like interactions is severely limited by conventional computing platforms.  The Zeroth Neural Processing Unit (NPU) is a hardware implementation of the brain’s spiking neural networks (SNN) method of information transmission. Integrating the NPU into computing platforms at the chip level would begin to address the computational and power requirements for these types of applications.

The goals of the Zeroth* platform are:

  1. Biologically Inspired Learning
  2. Enable Devices To See and Perceive the World as Humans Do
  3. Creation and definition of an Neural Processing Unit—NPU

Achieving “human-like interaction and behavior” is an ambitious goal, but it seems like this is a good first step.

UPDATE (25-Oct-13): Good overview here: Chips ‘Inspired’ By The Brain Could Be Computing’s Next Big Thing.

UPDATE (1-Jan-14): CES 2014: Intel launches RealSense brand, aims to interface with your brain in the long run
___________

* The name Zeroth comes from the science fiction Three Laws of Robotics. The First law was that “A robot may not harm a human being.”

Asimov once added a “Zeroth Law”—so named to continue the pattern where lower-numbered laws supersede the higher-numbered laws—stating that a robot must not harm humanity.

We’ll have to wait and see, but let’s hope so!

FDA Regulation of Mobile Medical Apps

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

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):

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

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.

Subscribe

Categories

Twitter Updates