Increasing automation in health care is transforming standalone medical devices into information appliances connected to the enterprise network. Virtually all electronic medical devices face this connectivity market requirement, including devices like weight scales, urine meters, laryngoscopes, and virtually any monitoring, therapeutic or diagnostic medical device.
You're here for a reason. Perhaps driven to seek out connectivity by market demand or competitive pressure. Perhaps you're curious and more inclined to take the jump instead of waiting to be pushed. Adding connectivity means going beyond the normal limits of the embedded system device. New territory. You might be asking yourself:
"What exactly do we have to do to have connectivity?"
"What's the minimal viable product solution for connectivity?"
"Are there opportunities for competitive advantage and new revenue?"
"Can't we just outsource all the connectivity?"
"What's the best way to navigate this territory?"
Henry Ford, in response to what horse owners said they wanted in an automobile, "If I asked them, they'd say they wanted a faster horse."
For the users of a standalone embedded system medical device, connectivity is new territory as much as it is for manufacturers. Traditional requirements gathering using voice-of-the-customer and other interview techniques are poor tools for disruptive and totally new kinds of features.
In our experience eliciting connectivity requirements for different medical devices, we have seen many different use cases. These use cases often come in three variations, based on differnt use models for monitoring, therapeutic and diagnostic medical devices.
The following are a selection of common medical device connectivity use cases.
These 5 pillars, taken together, represent the "whole product solution" for medical device connectivity. Skipping all or part of one of these pillars will result in unsatisfied customers and higher costs -- for remediation and unanticipated services.
Each domain contains related tasks and their own set of challenges. How each of these domains is implemented differs by manufacturer based on the capabilities of the medical device, the skillsets, experience and organization of your company, and your strategic objectives for connectivity.
Use cases greatly impact the scope of requirements that result in usable workflow and meaningful data for clinicians. Besides the example use cases described above, patient context is an almost universal use case for connectivity features. Some devices include use cases unique to that device, such as Drug Error Reduction Systems for infusion pumps, and perfusionist documentation and calculations for heart lung machines. Use cases also define the actors or personas using or enabling your workflows, required data elements, and what systems integration (EMR, messaging systems, or third party medical device systems) is required to enable your use cases. This pillar also includes use models describing the locations and methods of use of your device. Common use models include stationary, portable and mobile -- each of which comes with its own set of system requirements. These issues remain, even if you are using a smartphone or tablet for connectivity.
When considering the scope of effort for data security, there are two key tasks: 1) integrate robust data security controls into your quality system (or review the ones you have to ensure they pass FDA muster), and, 2) ensure the proper artifacts of those data security controls are created and included in your 510k submission. The connected medical device, plus any client/server applications that support the above use cases would be included in any data security effort. Ideally, data security will be part of your quality system prior to starting your IoMT design project, so that it can be built into your solution from the ground up. Adding security after the fact and backfilling the required documents is common, but is a poor option for mitigating data security risks.
Connectivity transforms an embedded system medical device into an information appliance intended to operate on the customer's enterprise network. The design approach shifts from the embedded approach of reducing options and variables in a tightly controlled environment to creating a product for a heterogeneous IT environment with lots of variables and options. With your use case pillar completed, this pillar describes the key design components of your connectivity solution. Components include system and application software architectures to be used to implement those use cases, types of network connections, any standards based protocols and configuration profiles to be supported, and any client applications that might be needed to run on PCs, tablets or smartphones.
Wireless testing — a review of the FDA’s guidance document on the wireless enablement of medical devices indicates that the FDA requires testing that substantially exceeds typical EMC and EMI testing. We use a wireless test protocol developed specifically for wireless medical devices that has resulted in FDA clearance in more than 30 different wireless medical devices. Specific testing protocols are driven by the radio(s) selected above.
Business delivery system — wireless connectivity creates numerous operational requirements beyond that of a standalone embedded system device, which can vary considerably between acute and ambulatory environments. Connectivity will impact the company's finance, engineering, verification test, installation, customer support, and sales departments. Both startups and established firms new to connectivity have gaps in these areas, especially if your team lacks the operational experience deploying wireless medical devices in provider environments. Commercial success requires an assessment to identify those gaps and address them, in alignment with your product launch. The alternative is to react to issues as they arise which will impact customer satisfaction, result in unanticipated costs and perhaps, delay revenue recognition.
Before any project can begin, a detailed plan or roadmap is needed to clearly define scope and the specific steps to be taken to achieve the goals of the engagement. This is usually a two day process. Project Roadmapping can be broken out as a separate project from the overall engagement, or included as the first phase of an engagement.
Unlike traditional medical device accessories, different regulatory paths can be taken for connectivity features. The optimal strategy is defined to minimize regulatory burden at market introduction and reduce ongoing sustaining engineering costs. Applicable data security controls are also incorporated into your Quality System.
On-site observation of device users and patients, and interviews is used to create formal use cases to facilitate accurate translation into software. The scope of requirements exceeds direct interactions with the medical device and includes workflows associated with actions before, during and after the use of the device.
Recommendations on architecture and technologies are formulated to support feature objectives and minimize development costs and time-to-market. This phase can also include risk management and systems integration.
Verification testing requirements for connectivity features are unlike those for embedded system devices. Testing capabilities are specified that focus on networking, wireless and systems integration testing. Recommendations are made for testing resources brought in-house and those that are better suited for outsourcing.
A gap analysis identifies connectivity operational requirements that need to be addressed. Recommendations can include job descriptions, head count requirements, required equipment and infrastructure, and policy and procedure development across all areas of the company impacted by connectivity.
The following articles provide some background, analysis and a bit of prognostication on medical device connectivity.
My work in medical device connectivity started in the 1980s with the integration of cath lab recorders and software applications to automated cath study data analysis and diagnostic report generation. I didn't realize it at the time, but this integrating medical devices with information systems became the focus of my career. Since the cath lab, I've worked on projects across cardiology, diagnostic imaging and other diagnostic modalities, multi parameter and highly specialized single parameter monitoring devices, and numerous therapeutic devices, from heart lung machines to cardiac rhythm management.
Over the years I've learned that simply adding a network port to a medical device transforms it from a standalone embedded system device into an information appliance. This transformation entails many new requirements and responsibilities for device manufacturers and is embodied in the 5 pillars of medical device connectivity.
Unlike other consultants who focus on one connectivity pillar, we address the full scope required to develop and launch a successful connectivity solution. As a consultant for 10+ years, we've helped dozens of manufacturers make the transition from standalone device to information appliance.