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.
Storms From the Cloud
Given the analogy between actual clouds and computer clouds, it now seems appropriate to extend the concept to storms that those clouds may bring. This was illustrated recently (April 21, 2011) when Amazon had a cloud outage (a mixed metaphor no doubt) in their Amazon Web Services business. This situation was covered by the NY Times (here), and the professional computer press (here) among others. As a result of Amazon’s problems some Web sites were reported to be down for as long as 11 hours, although actual loss of previously stored information has seemingly not been part of the problem–this time. However there is a related question for any new data that was or should have been generated during the outage. Where is it, and will the gap be properly filled in retroactively?
The Amazon postmortem explanation has to be what will be a classic, if it is not already a classic. In fact I can picture a pull down menu of explanations where this would have to be one of the choices. The explanation in short: a configuration error was made during a network upgrade. A far more detailed explanation was posted by Amazon here. From a Web page perspective an interesting aspect of the posted explanation is that while it is clearly on the amazon.com Web site, it is not easily found, if it all, by starting at amazon.com, or at least I didn’t find it from there.
