Consumer Connectivity Issues
From time to time, patients or family members leave comments about problems they’ve had. This is not a consumer oriented site, and most patient’s are not in a position to avail themselves of assistance from me or another industry consultants. But I do welcome and respond to consumer oriented inquiries. Unfortunately, these situations rarely result in simple straight forward replies that solve the problems.
Here’s a query I received this week:
I have been reading about connectivity of medical devices, of which I know nothing, because I am a teacher and am having signal issues, while at work, with my wireless Omnipod Insulin Pump. The alarm sounds and it stops delivering insulin. The support team at Insulet Corp. says that there is some sort of “fluck” going on. This answer does not satisfy me. My classroom has been known to have what our tech people call, “dead zones.” If you don’t mind, can you, or others, offer some insight into this situation? Thanks. My doctor is at Tufts in Boston. He’s just great.
Here’s my reply:
Workflow Impacts Choice of Connectivity Solution
The Medical Device Connectivity group on LinkedIn has some interesting discussions from time to time (you can join here). This week, Muhammad Siddiqui, a clinical analyst at the Cleveland Clinic, Abu Dhabi, asked:
I’m looking for some feedback. Why would any healthcare organization choose to go with Capsule if they have 90% Philips bedside solutions? Why would they not consider Philips as the nutural choice for device integration? I want to know and your feedback will be greatly appreciated.
As usual, there were numerous insightful responses discussing how the two approaches – connectivity enabled by medical device makers and that provided by vendor agnostic manufacturers – differed. What struck me was that there was no discussion about the workflow that the connectivity was supposed to provide. Since patient monitoring is mentioned, is the desired workflow remote surveillance or alarm notification? Perhaps the need is for clinical documentation from patient monitors to the patient’s chart in an EMR? Another common application is data aggregation in high acuity areas like the OR or ICU. While each of these workflow applications is enabled by an MDDS, they are often provided by different sets of vendors.
Developing a Regulatory Strategy Workshop
I have an opportunity to conduct a post-conference workshop at this year’s Healthcare Unbound conference. This year’s event is in San Diego, July 11-12 at the Manchester Grand Marriott. The title for the workshop is, Developing a Regulatory Strategy for Your Healthcare Unbound Product. The workshop will be conducted the afternoon of July 12th. You can read the workshop description at the end of this PDF document.
The rationale behind the workshop is the need to clear up confusion on the part of many product developers regarding regulatory issues like,
- Is my product a regulated medical device?
- What does it mean to be regulated?
- If I don’t want to be regulated, can I avoid regulation – and if so, how?
Ideally, we can structure the workshop around attendees actual products and situations. This, of course, will depend on folks registering in advance with sufficient lead time to actually prepare some content around their unique situations. Using participant’s products as case studies should be more engaging and relevant for everyone. If you’re registered for the workshop and want to provide a case study, let me know by completing this contact form.
Is My Product a MDDS?
I’ve been getting a lot of questions about this. Here’s the latest:
I am hoping you can answer this question for me. Would [redacted company name] a data storage company come under the MDDS final Ruling? Are hw/sw services all types of companies including medical.
Unfortunately, where the FDA is concerned, very little is black or white. Short to-the-point questions usually don’t result in meaningful answers.
One unambiguous issue we can get out of the way is that the FDA regulates products through their regulation of manufacturers. All regulatory questions revolve around the product, but it is the manufacturer of the product that has to jump through the regulatory hoops. A manufacturer may chose to have one set of policies and procedures that conform to the FDA regulations for their medical device, and another for unregulated products.
Connectivity, With or Without a Server
Many medical device makers contemplating connectivity for the first time, prefer to build everything into the embedded system device rather than using a server to implement most of the connectivity features. This design approach is rarely taken, but why? The following is a quick look at the strengths and weaknesses of building connectivity into the embedded device and using a server.
Before we launch into the pro’s and con’s, let’s identify the basic functional requirements for connectivity:
- You must have the ability to get machine readable data out of your medical device. Most all electronic devices have this ability, provided by a serial port. Alternatively, the device can use an Ethernet and/or Wi-Fi (or perhaps some other wireless technology).
- Next the proprietary data format from the medical device must be parsed and converted into something the target system understands, typically HL7.
- At some point the medical device data must be associated with patient from whence it came. There are many ways to do this, but the key is to make it as automated and reliable as possible.
