This summer, FDA proposed lifting regulations from certain currently regulated medical devices. This unprecedented policy shift targets devices known as Medical Device Data Systems (MDDS) and is intended to benefit the mobile app industry and companies like Google, Apple and others. The current regulatory burden for MDDS devices is Class I, 510(k) exempt. This means manufacturers have to follow a basic quality system (i.e., design controls) on par with ISO9001, and report instances of patient injury or death in addition to any product recalls to FDA.
The following is a guest blog post embodied in an abridged version of a comment submitted to FDA in response to their draft guidance.Read More
Developing and launching a competitive product, and getting initial traction in the market are not inconsiderable milestones. And yet for the entrepreneur and their investors, this is just the beginning. What was record setting last quarter is barely acceptable this quarter, and next quarter had better be back on track.
Developing a solid plan for growth depends on two things: a good understanding of the basic means to drive growth, and a deep understanding of the market. This post seeks to combine both of these in a brief survey of the key factors to drive messaging middleware revenue growth in health care. We’re going to consider three basic growth strategies: organic growth, product line extension, and the roll-up strategy.Read More
The previous post in this series suggested a set of characteristics to define the messaging middleware market and described the typical product architecture for these systems. In this post, we’ll look at ways the market may be segmented and how the market is adopting these systems.
Market segmentation is the dividing of a broader market into subsets of potential buyers who have common market requirements who then become the target for your product, sales and marketing. Using my favorite market adoption model, Geoffrey Moore’s Crossing the Chasm, this is the bowling alley strategy. Software developers in the messaging middleware market are currently pursuing a variety of market segments or bowling alleys.Read More
The recent recall (links below) for McKesson’s Anesthesia Care system raises interesting questions about potential information system failure modes as well as what system/software functions cross the imaginary line between unregulated EHRs and regulated medical devices.
First the facts. The FDA announced McKesson’s voluntary recall of its Anesthesia Care system in several on-line (here, here and here) postings. This trio of postings is interesting because the first links only to the second, the second does not link to either of the other two. The third also does not link to the other two, and was not part of any of the announcements, but it is the most complete.
The statement of the reason for the recall is that, “There was an occurrence where the patient case data did not match the patient data when the case was recalled in the anesthesia care record (ACR) in that it included data from another case.” It was further noted that, “Use of this affected product may cause serious adverse health consequences, including death.” In the third link the FDA identifies the product as,Read More
We are encountering many hospital which are still based on wired LAN technology for medical device connectivity. Many have mentioned their gripes and major concerns about using Wi-Fi technology for patient monitoring and drug delivery monitoring in the OR as well as ICU departments.
Many hospitals are still using WMTS telemetry in their more critical patient monitoring areas. This is very expensive and maintenance for such a system is costly.
Can you tell us what are the major criteria to ensure a reliable safe and secure Wi-Fi network for medical devices?
If a hospital decides to use Wi-Fi technology, what are the proper guidelines to which they must adhere, to ensure that their current and future Wi-Fi network will be stable, reliable, safe and secure? What are the important features they should consider seriously before embarking on using this type of technology?
Great questions. Here we go with some answers:Read More
Some time ago Tim Gee pointed out that a major vendor for an in hospital communication system included the following statement in its documentation:
“This product is not intended for use with patient monitoring devices or other patient care devices. Do not use this product as the primary communications tool in health care environments, as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment.”
Of course “primary communication” was exactly why the product was being purchased, and arguably what it was being sold for.
When discussing Clinical Decision Support (CDS) (here) I have pointed that it is common for CDS creators to in essence say that one should not rely on the output of the product, but instead always second guess the advice provided. This perhaps approaches a warning that I proposed for a product that I thought was seriously defective: DO NOT USE THIS PRODUCT. Maybe I was being facetious.
These examples may pale in comparison to the following disclaimer for medical image processing software:Read More