Get Latest Final Year Projects in your Email

Your Email ID:
PA Subs

Assuring the Safety of On-Demand Medical Cyber-Physical Systems (Computer Project)

Download Project:

Fields with * are mandatory

ABSTRACT

We present an approach to establish safety of on demand medical cyber-physical systems which are assembled to treat a patient in a specific clinical scenario. We treat such a system as a virtual medial device (VMD) and propose a model-based framework that includes a modeling language with formal semantics and a medical application platform (MAP) that provides the necessary deployment support for the VMD models.

MOTIVATING EXAMPLE

We first describe a specific clinical scenario where the patient is provided pain management through a therapy called patient controlled analgesia (PCA). In PCA therapy the patient is administered an opioid pain medication using an infusion pump. The pump is equipped with a button that allows the patient to request an additional dose of medication called bolus.

A well-known hazard of administering opioids is that an overdose can lead to a respiratory failure, which may be fatal to the patient. To mitigate this hazard, the scenario also includes monitoring of the patient’s respiratory function using a vital sign sensor, either directly (using capnography sensors) or indirectly (via blood oxygen saturation, measured by a pulse oximeter).

PROPOSED APPROACH

Fig. 1: VMD safety assurance

Fig. 1: VMD safety assurance.

Because the MAP enforces correct instantiation, we claim that properties verified from a VMD model must hold for any instantiation (see Figure 1). This approach imposes a number of requirements on both the modeling formalism (which we discuss next) and on the MAP itself.

MODELING LANGUAGE

Fig. 2: PCA infusion VMD architecture specification.

Fig. 2: PCA infusion VMD architecture specification.

The architecture specification has separate sections for device modules, logic modules, and data flows. We illustrate the architecture specification using the PCA infusion scenario, shown in Figure 2. It contains two device modules, the infusion pump and the pulse oximeter, and a logic module for the interlock that works as the controller of the pump.

Fig. 3: PCA infusion VMD architecture.

Fig. 3: PCA infusion VMD architecture.

Fig. 5: Pulse-oximeter device requirements specification.

Fig. 5: Pulse-oximeter device requirements specification.

Figure 3 shows a graphical representation of the architecture view, visually separating ports of network interfaces of modules from ports of patient interfaces. The latter are represented as icons reflecting the physical nature of the ports. Similarly, the top part of Figure 5 shows the interfaces of the pulse oximeter device. Here, the difference between the patient interface and network interface is especially vivid: the input from patient is the actual blood oxygen saturation in the body, the output of the device is the sensor reading that is imperfect and is delivered with a variable delay.

Fig. 6: Graphical representation of the PCA pump requirements specification.

Fig. 6: Graphical representation of the PCA pump requirements
specification.

It takes up to two time units to activate the pump motor, but is also allowed to activate immediately. Time progress is measured by clock t2. Once the motor is active, the pump sets the desired rate and transitions to mode p = 3, in which clock t3 measures the duration of bolus. Figure 6 represents pump behavior graphically, where must and may transitions are shown as solid and dashed lines, respectively.

MEDICAL APPLICATION PLATFORM

Fig. 8: MAP architectural view

Fig. 8: MAP architectural view.

Our MAP prototype decomposes the above responsibilities into a number of platform components ( Figure 8). The functions of the Application Database, Device Database, Clinician & Adminstrative Services and Data- Logger are beyond the scope of this paper. We describe the Application Manager, Resource Manager, and Message Bus in more detail as they are directly involved in the correct instantiation of a VMD.

DISCUSSION & CONCLUSION

In this paper we have described an approach to ensuring the safety of a specific class of Medical Cyber-Physical Systems, called Virtual Medical Devices (VMD). The approach involves a specification language that allows us to model both architectural and behavioral aspects of the system. A Medical Application Platform (MAP) was then used as a trusted base to facilitate the correct instantiation of VMD. We argue that this allows us to check properties of a VMD at the modeling level and that those properties will transfer to any instance allowed by the MAP.

We acknowledge that our proposal is a different way of reasoning about safety-critical systems. This is primarily due to the nature of on demend medical systems: they do not exist physically until the user assembles them. The current trend of medical system development indicates that these types of system will become more prevalent and we will, as a community, have to develop new engineering principles and techniques to address these systems.

There are some challenges that must be addressed before safety critical on-demand medical systems become practical. It remains to be seen whether the proposed model-based approach offers a valid pathway for the regulatory approval of a VMD. Extensive consultations with regulators to inform them of these ideas and gauge their response are necessary before one can attempt to use this approach to a real MCPS. Next, one may notice that the models shown in this paper deal with the nominal behaviors of the devices. Of course, assessing faulty behaviors that a device may exhibit is a crucial part of the safety assessment.

While the modeling language presented here is capable of capturing fault models of medical devices using normal state transitions, it is not clear if faulty behavior should be syntactically or semantically distinguished. Additionally, we would like to note that it is not clear how current medical device risk management practices can be adapted for VMD: No matter how accurate a model may be, there is always a possibility, however unlikely, that an implementation may exhibit a behavior not predicted by a model. A safety argument for the device has to take this possibility into account, using some kind of risk management strategy specificically designed to take into account how VMD will be used and deployed.

Source: University of Pennsylvania
Authors: Andrew L. King | Lu Feng | Oleg Sokolsky | Insup Lee

Download Project

Download Project:

Fields with * are mandatory