Medical Devices Are Being Transformed into Information Appliances
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.
As A Manufacturer, You Probably Have Questions
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?"
Take Your Next Step to the Best Connectivity Solution for You and Your Customers
We will review your current situation, short and mid term objectives, and discuss next steps for moving you towards your goal.
Use Cases are the Key to Requirements and Design
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.
Patient Context
A network enabled medical device must tag patient data going out onto the network with a patient identifier. This is a patient safety requirement to ensure that the patient's device data is correctly associated with the patient's identity in other systems such as EMRs, central stations, remote monitoring and other systems that are consuming that medical device data. There are many ways to establish and maintain patient context, depending on the medical device use model, the environment in which it is used, and the level of workflow automation to be provided for users. The "quick solution" to patient context is to provide a UI so caregivers can manually enter the patient name and/or ID. Increasingly, prospective users are saying, "We won't do that." Some degree of workflow automation is required.
Clinical Documentation
If data from your device is documented in a clinical record of any kind, this is likely the connectivity feature most often requested. Writing down data read from a medical device, and typing it into a software application is both inefficient and subject to human error. Monitoring, therapeutic and some point-of-care diagnostic devices commonly fall under this requirement. Many elements go into this use case: data elements and labeling, communications protocols, determination of what data to chart, potential data validation prior to displaying in the patient's chart, frequency of exporting data for charting and the degree of workflow automation that will be provided to users.
Surveillance
There are many scenarios where surveillance of medical device data is valuable. Surveillance can complement the medical device in the patient room with larger or better positioned duplicate displays. Middle distance surveillance may be needed at the nursing station or wherever a supervisory clinician is monitoring patient care or status. Long distance surveillance is needed for remote ICUs and clinician access to data from their offices, at home or on the go.
Central Station Monitoring
More than just surveillance, central station monitoring includes a plethora of additional workflows. This use case often includes alarm notification, measuring waveforms, data analysis, and temporary storage of real time device data for retrospective analysis and review. Applied to therapeutic devices, this can include therapy delivery status, not just at the nursing station, but also in ancillary departments like pharmacy or respiratory therapy.
Alarm Notification
Alarm notification continues to be a patient safety challenge in many care delivery areas. Minimizing false positive and nuisance alarms is part of the solution. Remote alarm annunciation to central monitoring techs or to the responsible caregiver are the rest of the solution. Some alarm notification solutions come from the medical device manufacturer, some are available from third party alarm notification solutions.
Data Analysis and Visualization
Medical device and sensor manufacturers focus on data analysis and visualization to add value and provide competitive advantages. The analysis of physiological data combined with innovative visualization techniques continue to result in novel ways to predict or diagnose adverse patient conditions. Physiological data combined with therapy delivery data offers another realm of clinical insight. Diagnostic modalities offer the most mature data analysis and display, often combined with diagnostic report generation.
Device Specific Workflows
Besides use cases shared by most or all medical devices, some use cases are specific to a category of devices. These are use cases with workflow that requires they be implemented on an information system connected to the medical device, rather than implemented in the medical device itself. Most device specific use cases can be divided into diagnostic, monitoring or therapeutic categories. Infusion pump drug error reduction systems (DERS) , and the QA use cases for point of care testing and diagnostic imaging are examples of device specific use cases.
Patient Generated Data
Patient generated data is the result of data recorded or captured by the patient rather than a caregiver or clinician. Data may be passively captured after sensor application by the patient or caregiver. Complexity ranges from straightforward remote monitoring to complex chronic disease management scenarios. Many of the systems in this category are challenged by connectivity and deployment logistics, low sensor quality of consumer devices, variable patient technique in applying sensors and taking readings, and the ability to separate artifact from accurate data. Increasingly, these challenges are being overcome.
The 5 Pillars of Connectivity
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
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.
Data Security
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.
Architecture, Technology Selection and Design
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.
Verification Testing
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
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.
Phases of a Connectivity Engagement
Roadmap Planning
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.
Regulatory Strategy
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.
Requirements Elicitation
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.
Technology Selection & Design
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
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.
Business Delivery System Gap Analysis
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.
Increase your connectivity IQ
The following articles provide some background, analysis and a bit of prognostication on medical device connectivity.
Tim Gee
Principal
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.
Take Your Next Step to the Best Connectivity Solution for You and Your Customers
We will review your current situation, short and mid term objectives, and discuss next steps for moving you towards your goal.
