The Other Side of Wireless - Connecting Medical Devices with Mobile, Cloud Computing and Analytics to Improve Health Economic Outcomes

Editor's Notes

• #22: I’ve grouped them in a few areas. System Challenges (for the complete thing) Challenges around the hardware components Software Challenges Users Regulatory Challenges And Market Challenges
• #23: I am not a hardware expert, we work with partners like Insight Product Development on the hardware side. Other folks earlier today and yesterday have covered a lot of this in much greater detail. Actual Environment and Pattern of Use. Especially if it’s used by patients, like a lot of these. This can make a big difference. Adding a wireless sensor to an inhaler – the Propeller example. Can’t interfere with the inhaler’s function. It gets put in a purse, might get wet. So you need to be robust. People are likely to forget to charge it, so small sensors, low power consumption are strong considerations. Make them do as little as possible, as dead simple as possible. Battery tradeoffs. Interference and compatibility are things you need to take into consideration – other speakers have talked about this in much more depth. In the VG Bio example, some of the folks are wearing pacemakers, so shielding to prevent unwanted interference is another consideration.
• #24: This is a more complex system, with more moving parts, and more things that can go wrong: hardware, software stack, integrations, data and algorithms. There are a lot of dependencies there. Integrations are points of failure * Data loss, distributed systems, transmission Latency can be a problem - example – neurostimulation implant used for accelerating stroke rehab. Button pressed by clinician. There was unanticipated lag in the wireless transmission. Had to do a whole new animal trial to see if the lag time was clinically important. If you have connected systems, you have security risks and privacy risks. HIPAA compliance includes security and privacy considerations. You also need to think about business associates agreements. This also includes any analytics. Google analytics, others not. Need this. FDA has cybersecurity guidance documents – others have talked about this at the conference in much more detail. They’ve put in place a lab for fuzz testing, will be a greater point of emphasis If some of what you need to do involves apps in app stores – be careful which ones you put them in, because what comes out may not be what you put in. One of our clients asked us to run a test on this for android app stores. We built and submitted a very small app in such a way that it was easy to reverse engineer what the app stores did to them. I can’t really name names here, but in some cases it was harmless. In others they put a lot of extra things into the apps.
• #25: third party platforms Speed of change of those platforms. Maintenance   Software can change faster, consumer driven device change is faster. So it will.   - Smartphones and tablets from individual vendors change once a year. Major releases of operating systems are once a year, with point releases every few months, and patches potentially every few days.   Other elements of the stack also change quickly.   You have to think of releases in terms of months, not years. Some folks have adjusted to this, and are developing and releasing the software in shorter cycles.
• #26: Users are tricky. If you remember that we’re all wireless that adds more complexity – there are more users of the systems than you think – potentially clinicians, technicians, patients, caregivers, etc. For patients – don’t have training, depending on patients, very varied abilities and knowledge. Children, elderly, etc. Real world issues. Not just use error, but usability important (EU, need to take that into consideration.) Real World Issues are what’s important here.
• #27: As we alluded to earlier, the market is changing – for everyone. In the new market, the questions you need to be able to answer – do you have real world data to prove it? Once it’s out in the market, can you continue to improve outcomes and value? Can you do this fast. Some can, some can’t.
• #28: The more different, new risks you combine – the greater your regulatory risk/challenges. Looking more at evidence, less me-too. Can you prove your claims? Evolves… A few years ago for a mobile app, part of a class II medical device, a submission was sent back with feedback that the manufacturer hadn’t validated that users would be able to go to the app store, download and install the app. Not so much of an issue now. Some of this deals with individual reviewers. Many of them dealing with what they just got trained on, so they’re going to look at this most thoroughly. The patterns for review – guidance document, feedback, gearing up and training to test. There are a number of recent guidance documents, some are starting to get ready. The mobile medical apps one – pretty straightforward (saw earlier from Fish and Richardson) Wireless Devices – recent Human Factors and Usability – looking at formative and summative usability testing, not just lip service. For the EU, you also need to look at usability, not just use error. Cybersecurity – they are now putting in place a cybersecurity lab to do fuzz testing. Will start to be more of a point of emphasis in the next year. One I’m keeping my eye on for the future – UDIs and integration with EMRs – pilot project Aster-D with medsun. Emphasis on post-market surveillance. HIPAA – separately …
• #29: So there are a couple of common themes – achieving speed
• #30: A series of things that you can do to manage these risks