One of the biggest challenges for medical device makers developing connectivity solutions is to look beyond the connection itself and design an overall solution that provides good workflow. Medical device connectivity is workflow automation through the integration of medical devices and information systems. It is the scope and quality of the workflow automation in a connectivity solution that impacts users, and not just how the connections are technically implemented.
Besides meeting a growing list of market requirements, connectivity aims to deliver certain features and benefits. Typical examples include:
- Reduced user error by automating previously manual tasks - this can improve patient safety and outcomes
- Automating certain tasks make the resulting data available as it's generated, rather than when users can get around to manually documenting it (if they don't forget)
- Automated oversight, where the connectivity solution monitors and reports on the episode of care associated with the medical device can also improve patient safety and outcomes as well as improve staff productivity
- Making it efficient and simple to review retrospective and current medical device data to better make a diagnosis or gauge the efficacy of a therapeutic intervention
Medical device manufacturers are experts in the workflows related to the direct use of their medical device. This is what I refer to as knobology, and includes applying the device to the patient (or taking a sample from the patient), powering on and configuring the medical device for use with the patient, use of the device while it is attached to the patient (e.g., remote surveillance, alarm management, adjusting therapy delivery, etc.) and finally, removal of the the device from the patient. In addition to automating manual knobology workflows, connectivity requires the automation of workflows that surround the use of the medical device but are removed from knobology. This is where manufacturers get out of their comfort zone as they seldom concern themselves with workflows that are not associated with the direct use of their device.
Any manual workflow associated with the use of a medical device has a certain number of steps required to complete a task. Good workflow automation delivers all the benefits of the connectivity solution, with fewer or at worst, no additional workflow steps required by users to complete their tasks. Bad workflow is where connectivity benefits are offset by making the user complete a greater number of workflow steps for your "automated" solution than they had to complete when everything was manual.
Like any other suboptimal product bought by a hospital, a bad workflow solution will suffer poor adoption and will likely end up hidden in the back of a drawer or cabinet, dropped in the toilet, moved to a junk closet, or simply turned off. (Every hospital has junk closets, or medical device graveyards, where poorly adopted products are hidden from sight.)
There are three categories of medical devices associated with connectivity workflows: monitoring, diagnostic and therapeutic devices. A given medical device system can include one or more of these three categories. And each category has its own inherent workflows and requirements.
The data that is acquired and managed in a connectivity solution can include:
- Spot numeric data (i.e., a value captured at a point in time), often displayed simply as a number, or trended with other readings over time;
- Continuous numeric data (e.g., a physiological parameter such as EKG, pressure or blood oxygen), often displayed as a moving waveform, and from which a spot data sample can be selected;
- Derived data where the data is the result of data analysis (e.g., arrhythmia analysis) or a calculation applied to acquired data (e.g., calculating a valve area from pressure data);
- Spot visible light data (i.e., diagnostic imaging, dermatology or pathology) where individual reference images are produced and selected, often for diagnostic purposes;
- Continuous visible light data (e.g., a cardiac cycle captured via echocardiography); and
- Derived data from images resulting from image analysis and auto detection (e.g., wall motion analysis, automated analysis of microscopy images, automated lesion detection in mamograms).
Diagnostic modalities were among the first to receive workflow automation. Due to high patient volumes of many diagnostic tests, connectivity can greatly improve patient throughput, resulting in higher device utilization (doing more tests with the same equipment) and making the diagnostic results available more quickly (both reducing the time to final report and making access to the report quicker and easier). Most diagnostic areas are dominated by a small number of medical devices - think endoscopy or cath lab. The most obvious example is diagnostic imaging and PACS.
Another device category to receive early workflow automation was patient monitoring. Here patient safety was the driver, as manufacturers extended the functionality of their devices with central stations to provide remote surveillance and alarm notification. Connectivity solutions for therapeutic devices have lagged for a variety of reasons, but mostly due to complexity and lower utilization levels - even ventilators aren't used on that many patients, let alone intra aortic balloon pumps or dialysis.
Here is a list of the common workflows that will be discussed in subsequent blog posts. As the posts are completed, I'll come back here and add a link to the subsequent post.
- Patient management
- Patient context
- Scheduling
- Order workflow
- Data acquisition
- Data analysis
- Report generation
- Data management
- Clinical documentation
- Surveillance
- Event review
- Messaging
- Device specific workflows
- Clinically specific workflows
The objective of this list is to capture all of the basic workflows that apply to multiple types of medical devices. The last two as categories are intended to contain the more highly specialized workflows. Let me know how you might revise this list.
Tim:
In your proposed list of workflows, I think it is important enough to call out alarm notification as a separate workflow. I know this probably fits under your “messaging” category (#12 on your list) - but messaging is very broad and there is so much focus on managing alarms that this should be considered separately. Just something to consider.
Brian
Thanks a lot for your interesting articles Tim! I’m really looking forward for the ones to Data acquisition and Data analysis because these are my favourites of your list. Data aquisition is an interesting topic and there are a lot of mistakes that can be made. Is there any date fix when they will be published?