- 1.1 Introduction and Motivation
- 1.2 System Description and Operational Scenarios
- 1.3 Key Design Drivers and Quality Attributes
- 1.4 Practitioners' Implications
- 1.5 Summary and Open Challenges
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 System Description and Operational Scenarios
MCPS are safety-critical, smart systems of interconnected medical devices that are collectively involved in treating a patient within a specific clinical scenario. The clinical scenario determines which treatment options can be chosen and which adjustments of treatment settings need to be made in response to changes in the patient’s condition.
Traditionally, decisions about the treatment options and settings have been made by the attending caregiver, who makes them by monitoring patient state using individual devices and performing manual adjustments. Thus, clinical scenarios can be viewed as closed-loop systems in which caregivers are the controllers, medical devices act as sensors and actuators, and patients are the “plants.” MCPS alter this view by introducing additional computational entities that aid the caregiver in controlling the “plant.” Figure 1.1 presents a conceptual overview of MCPS.
)
Figure 1.1: A conceptual overview of medical cyber-physical systems
© 2012 IEEE. Reprinted, with permission, from Proceedings of the IEEE (vol. 100, no. 1, January 2012).
Devices used in MCPS can be categorized into two large groups based on their primary functionality:
Monitoring devices, such as bedside heart rate and oxygen level monitors and sensors, which provide different kinds of clinic-relevant information about patients
Delivery devices, such as infusion pumps and ventilators, which actuate therapy that is capable of changing the patient’s physiological state
In MCPS, interconnected monitoring devices can feed collected data to decision support or administrative support entities, each of which serves a different, albeit complementary, purpose. For example, caregivers can analyze the information provided by these devices and then use delivery devices to initiate treatment, thereby bringing the caregiver into the control loop around the patient. Alternatively, the decision support entities might utilize a smart controller to analyze the data received from the monitoring devices, estimate the state of the patient’s health, and automatically initiate treatment (e.g., drug infusion) by issuing commands to delivery devices, thereby closing the loop.
Most medical devices rely on software components for carrying out their tasks. Ensuring the safety of these devices and their interoperation is crucial. One of the more effective strategies to do so is to use model-based development methods, which can ensure device safety by enabling medical device verification. This strategy also opens the door for eventually certifying the devices to meet certain safety standards.
1.2.1 Virtual Medical Devices
Given the high complexity of MCPS, any such system has to be user-centric; that is, it must be easy to set up and use, in a largely automated manner. One way to accomplish this is to develop a description of the MCPS workflow and then enforce it on physical devices. MCPS workflow can be described in terms of the number and types of devices involved, their mutual interconnections, and the clinical supervisory algorithm needed for coordination and analysis of data collected by the system. Such a description defines virtual medical device (VMD). VMDs are used by a VMD app and instantiated during the setup of actual medical devices—that is, as part of a virtual medical device instance.
The devices in a VMD instance are usually interconnected using some form of interoperability middleware, which is responsible for ensuring that the inter-device connections are correctly configured. The principal task of the VMD app, therefore, is to find the medical devices in a VMD instance (which may be quite large), establish network connections between them, and install the clinical algorithm into the supervisor module of the middleware for managing the interactions of the clinical workflow and the reasoning about the data produced. Basically, when the VMD app is started, the supervisor reads the VMD app specification and tries to couple all involved devices according to the specification. Once the workflow has run its course, the VMD app can perform the necessary cleanup to allow another workflow to be specified using a different combination of medical devices in the VMD instance.
1.2.2 Clinical Scenarios
Each VMD supports a specific clinical scenario with a detailed description of how devices and clinical staff work together in a clinical situation or event. Here, we describe two such scenarios: one for X ray and ventilator coordination and another for a patient-controlled analgesia (PCA) safety interlock system.
One example that illustrates how patient safety can be improved by MCPS is the development of a VMD that coordinates the interaction between an X-ray machine and a ventilator. Consider the scenario described by [Lofsky04]. X-ray images are often taken during surgical procedures. If the surgery is being performed under general anesthesia, the patient breathes with the help of a ventilator during the procedure. Because the patient on ventilator cannot hold his or her breath to let the X-ray image be taken without the blur caused by moving lungs, the ventilator has to be paused and later restarted. In some unfortunate cases, the ventilator was not restarted, leading to the death of the patient.
Interoperation of the two devices can be used in several ways to ensure that patient safety is not compromised, as discussed in [Arney09]. One possibility is to let the X-ray machine pause and restart the ventilator automatically. A safer alternative, albeit one presenting tighter timing constraints, is to let the ventilator transmit its internal state to the X-ray machine. There typically is enough time to take an X-ray image at the end of the breathing cycle, between the time when the patient has finished exhaling and the time he or she starts the next inhalation. This approach requires the X-ray machine to know precisely the instance when the air flow rate becomes close enough to zero and the time when the next inhalation starts. Then, it can decide to take a picture if enough time—taking transmission delays into account—is available.
Another clinical scenario that can easily benefit from the closed-loop approach of MCPS is patient-controlled analgesia. PCA infusion pumps are commonly used to deliver opioids for pain management—for instance, after surgery. Patients have very different reactions to the medications and require distinct dosages and delivery schedules. PCA pumps allow patients to press a button to request a dose when they decide they want it, rather than using a dosing schedule fixed by a caregiver. Some patients may decide they prefer a higher level of pain to the nausea that the drugs may cause and, therefore, press the button less often; others, who need a higher dose, can press the button more often.
A major problem with opioid medications in general is that an excessive dose can cause respiratory failure. A properly programmed PCA system should prevent an overdose by limiting how many doses it will deliver, regardless of how often the patient pushes the button. However, this safety mechanism is not sufficient to protect all patients. Some patients may still receive overdoses if the pump is misprogrammed, if the pump programmer overestimates the maximum dose that a patient can receive, if the wrong concentration of drug is loaded into the pump, or if someone other than the patient presses the button (PCA-by-proxy), among other causes. PCA infusion pumps are currently associated with a large number of adverse events, and existing safeguards such as drug libraries and programmable limits are not adequate to address all the scenarios seen in clinical practice [Nuckols08].