Several methods can be used to uncover the information needed for populating the MDIDS.
- The Zachman Framework is a structured approach for gathering information that can help to formally define a system (example in Table 3). It provides a framework for answering the 5 “Ws” of “What, Where, When, Why, and Who” questions about the workflow. It is meant to provide additional background information for the workflow and allow a larger picture of the scenario to be understood by nonclinicians. It is a structured way for nonclinicians to interview clinicians to understand the complete clinical picture. The frameworks helps to identify entities (used in the activity diagram), system boundaries, inputs/outputs to the system, and interactions within the system
- UML activity diagrams 9 are “graphical representations of workflows of stepwise operations and actions with support for choice, iteration, and concurrency.”e Activity diagramsf provide a tool for documenting the workflow by representing the dynamic behavior of a system, including the connections between system components, the relationship between data from different parts of the system, and the data required at every step of the workflow.10 These diagrams show the relationships of the device interactions with humans and other devices.
- Data and timing analysis consists of tables at each workflow block that indicate the data and data type that are transferred and identifies the source of the data along with its properties (example in Figure 3). The timing diagram shows the relationships between components of the system with respect to time. This is the first look at the time-sensitive components, which will become important requirements in the technical development and implementation phases. For example, patient safety concerns arise if certain components actions are required to occur before others or if data at a step expire within a specific time frame.
Web-Based Tool for Clinical Scenario Capture
A Web-based tool to capture clinical scenario information has been prototyped to enable collaborative approaches outside of the typical environments. The Clinical Scenario Repository (Alonso et al12),g currently in development, is intended to enable clinicians and nonclinicians (including patients’ family members) to document actual or potential adverse events, especially related to systems issues that are caused by or can be mitigated by device integration–based technology solutions. The user interface allows navigation, selection, and entry of information describing and documenting the clinical scenario (scenario description, identified contributing factors, description of clinical environment, and equipment used) and proposals to address this scenario through changes in workflow, environment, and equipment. Scenarios are intended to mature from initial entry as the result of collaborative interaction among users before being “approved” for general access. The database will be curated by having scenarios approved (content validated), returned to the user for additional clarification, or rejected by an administrator (administrator approval includes screening for privacy and other concerns). Analysis of the clinical scenarios informs the development of the MDIDS. To illustrate the functionality of the Clinical Scenario Repository, the information for the PCA example included in this article (Figure 4) can be viewed on the example screen with details on the Current State including hazards, the actors, the equipment, and the environment.
EXAMPLE—CLINICAL SCENARIO AND CConOps—PCA SAFETY INTERLOCK
Excerpts from the clinical scenario on PCA (described in ASTM F2761 Annex B) with safety interlock and its associated CConOps are included to illustrate the clinical scenario and CConOps. The Current State (see below) illustrates the case of a patient receiving analgesic medication for pain associated with a surgical procedure, who then receives an excessive dose, experiences respiratory compromise, and dies. The Current State is succinctly described including the relevant contextual information.
Current State: “A 49-year-old woman underwent an uneventful total abdominal hysterectomy and bilateral salpingo-oophorectomy. Postoperatively, the patient complained of severe pain and received intravenous morphine sulfate in small increments. She began receiving a continuous infusion of morphine via a patient controlled analgesia (PCA) pump. A few hours after leaving the PACU [post anesthesia care unit] and arriving on the floor [hospital ward], she was found pale with shallow breathing, a faint pulse, and pinpoint pupils. The nursing staff called a “code,” and the patient was resuscitated and transferred to the intensive care unit on a respirator [ventilator]. Based on family wishes, life support was withdrawn and the patient died. Review of the case by providers implicated a PCA overdose. Delayed detection of respiratory compromise in PATIENTS undergoing PCA therapy is not uncommon because monitoring of respiratory status has been confounded by excessive nuisance alarm conditions (poor alarm condition specificity).5
The Proposed State (see below) describes how the use of “smart” monitoring, appropriate pump settings, and the associated expected reduction in nuisance alarms is likely to address the hazard identified in the Current State.
Proposed State: While on the PCA infusion pump, the PATIENT is monitored with a respiration rate monitor and a pulse oximeter. If physiological parameters move outside the pre-determined range, the infusion is stopped and clinical staff is notified to examine the PATIENT and restart the infusion if appropriate. The use of two independent physiological measurements of respiratory function (oxygen saturation and respiratory rate) enables a smart algorithm to optimize sensitivity, thereby enhancing the detection of respiratory compromise while reducing nuisance alarm conditions. 5
The associated CConOps for this clinical scenario’s Current State (below) provides additional relevant clinical and technical detail and context. The Proposed State suggests the addition of 2 independent measurements of respiratory function and the use of a smart algorithm. It identifies the benefits and risks of the Proposed State.
The patient is connected to a PCA infusion pump containing morphine sulfate, a large volume infusion pump providing a carrier line of saline, a pulse oximeter, a non-invasive blood pressure device, a respiration rate monitor and a distributed alarm system. Clinicians involved are physician, nurse, and clinical assistant. Heart rate and blood pressure, respiration rate, pain score and sedation score are collected as directed by the clinical process (eg, using an electronic context-specific smart checklist) for set-up of a PCA pump. An intravenous (IV) line assessment is also completed. The PCA infusion pump, large volume infusion pump, and pulse oximeter are attached to the integrated system. The system queries the hospital information system for the patient’s weight, age, and medication list (specifically, whether the patient is receiving sedatives or non-PCA opioids), and searches for a diagnosis of sleep apnea. The system then accesses the physician’s orders from the computerized physician order entry system for dosage and rate for the PCA and large volume infusion pump, and verifies the values programmed into the infusion pump. The patient’s SpO2 (arterial oxygen saturation measured by pulse oximetry) and respiration rate are monitored continuously.
The system uses an algorithm based on weight, age, medication list, diagnoses, SpO2, and respiration rate to determine the state of the patient. Sedation and pain scores also contribute to this algorithm. If the algorithm detects decreases in the patient’s SpO2 and/or respiration rate below the calculated or preset threshold, a command is sent to stop the PCA pump to prevent further drug overdose, and the system generates a respiratory distress medium priority alarm condition sent via the distributed alarm system. Furthermore, if the algorithm detects that both the SpO2 and respiration rate indicate distress, the system generates a “severe respiratory distress” high-priority alarm condition sent via the distributed alarm system.
Proposed State: While on the PCA infusion pump, the patient is monitored with a respiration rate monitor and a pulse oximeter. If physiological parameters move outside the predetermined range, the infusion is stopped and clinical staff is notified to examine the patient and restart the infusion if appropriate. The use of two independent physiological measurements of respiratory function (oxygen saturation and respiratory rate) enables a smart algorithm to optimize specificity to detect respiratory compromise while reducing false positive alarm conditions and false negative alarm conditions. See IEC 60601-1-8 for additional information relating to alarm systems.
Benefits of This New System
- Sensitive and specific detection of respiratory compromise before irreversible injury;
- Discontinuation of medication infusion pump to slow or stop deterioration in respiratory status; and
- Provision of early, informative, notification to the clinical staff to enable early intervention.
Risks of This New System
- Inaccuracy of information in the physician’s orders;
- Inaccuracy in the information systems;
- Inaccuracy in clinical data, which contribute to the algorithm; and
- Unnecessarily stopping the infusion pump because of a false-positive alarm condition for respiratory distress.5
The Zachman FrameworkTM (Zachman International, Inc; Table 3) is shown for 2 of the primary actors, the physician and nurse. It describes their motivations (why), their involvement in the scenario (how), the information that is known (what), the actors they interact with (who), the location of this activity (where), and the timing of events/actions (when). The clinical workflow (using UML) (Figure 5) for drug administration illustrates a portion of the total workflow in which a number of safety checks are undertaken. Data and timing analysis shown for the PCA example (Figure 3) illustrates the sequence of events for the Current State with action verbs such as check, verify, and connect and the data involved the infusion rate and bolus volume. A robust MDIDS would reflect the physiologic signals being used to monitor the patient (eg, SpO2, end-tidal CO2, and electrocardiogram), any operational settings that need to be configured (eg, filter settings for SpO2), any interactions that might occur (eg, CO2 calibrating), and any device states (eg, pump in stand-by mode, pump operational, and pump suspended).
Using Clinical Scenarios
Open platform–based medical device systems can lead to smarter and safer health care if implemented using a comprehensive system engineering process. To work toward that goal requires a thorough understanding of the elements within the system and how they interact. Documenting the clinical scenarios and the MDIDS are an important first step to identifying user needs and systems requirements.
The development of a platform-based solution should start with the consideration of a range of clinical scenarios, which involve multiple medical disciplines and clinical environments related to the use of the system under development. The interactions studied may include, for example, the use of legacy devices, plug and play capabilities, the ability to transfer settings from one clinical venue to another, closed loop control, safety interlocks, the ability of a system to capture adverse event information, time synchronization, alarms (variables and types), decision support, and workflow or checklist enforcement. The clinical environments surveyed should be as broad as possible with the intended uses of the applications that will be run on the platform in mind. Environments of use that may be considered include the operating room, intensive care unit, postanesthesia care unit, outpatient surgical or office, emergency department, transport, and home care. The goal is to explicitly bind the capabilities of each system component by describing how they are used within the system.
The literature identifies the informatics challenges of clinical systems associated with the impact of the variation of data types and sampling rates on data aggregation,13 the need to properly address the bottlenecks of human-to-human and human-to-machine interactions in the clinical environment,14 complex interactions that must be handled to achieve interoperability,15 the need for time synchronization of devices,13 and device interoperability.13–15 The limitations of these approaches are that they do not necessarily consider safety of the entire system and the solutions proposed are often narrowly scoped to facilitate the implementation at the cost of general purpose use. The approach described in this article uses clinical scenarios and CConOps in conjunction with systems engineering methods to design safe interoperable platform-based systems. Current methods usually document scenarios to develop one or more narrowly scoped use cases related to a single intended clinical activity. The intent of the approach described is to examine the commonality across a range of diverse scenarios to gather general cross-cutting requirements.
The output of the clinical scenario documentation process allows for the identification of requirements necessary for platform-based building blocks and helps to explicitly define what a component can and cannot do. Describing the limitations of each entity is as important to preventing unsafe use as describing the capabilities of each entity.
The unstructured textual descriptions of clinical scenarios and the more structured CConOps documents described are a crucial component in the system engineering process that defines the information used in the system. The information can be used by Standards Development Organizations of particular device types and the related communication/interface standards to specify the parameters communicated by a device’s functional connection16 and can serve as input to a publically shared device repository (see MDIDS).h Examples of standards with functional connections and an associated informative appendix for data interface requirements include the recently published standard for continuous positive airway pressure devices (ISO 80601-2-72) and the pulse oximeter standard (International Organization for Standardization/Committee Draft 80601-2-61) currently under development. The MDIDS information, when made available via the external interface, may allow another device to determine whether the information is suitable for its use. For example, being able to query a pulse oximeter’s accuracy specifications and current setting for averaging would allow an application to determine whether this device was appropriate for an application that is time sensitive. The MDIDS, of which a number of generic and product-specific data sheets (Table 2) need to be been developed, are intended to serve as an input for standards development organizations, manufacturers, researchers, and clinical organizations. The system diagram and CConOps show the clinical context that the MDIDS information supports to avoid misunderstanding among system developers with the platform.
Clinical scenarios can be used to provide comprehensive clinical needs such that engineering platform solutions can be developed, thereby enabling improvements in patient safety and health care efficiency. The particular work described in this article was in part driven by the objectives of facilitating open interoperable solutions as described in the National Institutes of Health Quantum project. The scenarios identify addressable problems that tend to be underreported, not recognized, or have no solutions being currently applied.17 For example, numerous deaths and other preventable adverse events (PAEs) have been identified to be related to the use of PCA.18 Suggestions for safer implementation of PCA (eg, safety interlock based on physiologic data) may not be reported by clinicians or patients to any identified national authority.19 As the Aviation Safety Reporting System allows all participants in the aviation system to submit in confidence reports when “they are involved in, or observe, an incident or situation in which aviation safety may have been compromised”,i similarly the clinical scenario is intended to document the clinical situation using deidentified data to address and identify patient safety issues regardless of the cause.
This perspective differs from the traditional injury-based reporting methodology that device manufacturers and users of their devices are accustomed to. In the United States, the Medical Device Reporting regulation (21 Code of Federal Regulations 803.1) requires that manufacturers and health professionals “report deaths and serious injuries that (a) device has or may have caused or contributed to.” These reports are used to “protect the public health by helping to ensure that devices are…safe and effective for their intended use.” The adverse event reports focus on capturing and documenting the event data (eg, date of event, date of report, and description of event), details on the medical device (eg, manufacturer, serial number) and basic patient demographics.j The perspective of the clinical scenario is to identify events and/or elicit ideas for system-level solutions that cross the boundaries of specific manufacturers, regulated and nonregulated products, diverse users, and practice variability. The process of identifying the causes of PAEs involves a systematic analysis of the interactions. Thus, the clinical scenario is intended to be especially well suited for identifying known malfunctions or failure modes of PAEs caused by technology gaps and means to prevent or avoid harms. The clinical scenario should identify known events that should be addressed by solutions that implement the future state of the scenario.
Methods for collecting information about the clinical scenario and how this information can be used to improve the safety of interoperable systems have been described. These scenarios are intended to assist the health care community to solve complex clinical system problems and improve patient safety. The collection of better and more complete information about clinical workflows and proposed solutions to actual or perceived problems can help identify opportunities to improve existing devices and create new, more effective health care delivery systems.
Name: Sandy Weininger, PhD.
Contribution: This author co-wrote the manuscript.
Name: Michael B. Jaffe, PhD.
Contribution: This author co-wrote the manuscript.
Name: Tracy Rausch, CCE.
Contribution: This author edited the manuscript and served as principal investigator for foundational research.
Name: Julian M. Goldman, MD.
Contribution: This author co-wrote the manuscript and served as principal investigator for foundational research.
This manuscript was handled by: Maxime Cannesson, MD, PhD.
We thank Dave Arney (Massachusetts General Hospital Medical Device Plug-and-Play [MD PnP]), the team at DocBox, Inc (Newton, MA), and Michael Robkin of Anakena Solutions, Inc (Tarzana, CA), for their contributions in developing the clinical scenario methodologies described in this article, and Diego Alonso of the MD PnP Program (Cambridge, MA) for his work in developing and implementing the Web-based Clinical Scenario Repository. A listing of MD PnP program collaborators can be found at www.mdpnp.org/collab.html. The ongoing research relationship with the MD PnP research community has been important to advance the vision of safe integrated medical device systems to improve health care.
a Available at: http://www.mdpnp.org/mdids.html. Accessed August 2, 2015.
b The President’s Council of Advisors on Science and Technology (PCAST) periodically convenes a working group to review the Federal Government’s coordinated program of Networking and Information Technology Research and Development Program (NITRD).
c The session was led by Dr. Goldman at which Thomas Engel, MD, proposed the General Framework.
d Per a methodology used by the Medical Device Plug-and-Play (MD PnP) research program and DocBox’s development team.
e Available at: http://www.agilemodeling.com/artifacts/activityDiagram.htm. Accessed August 2, 2015.
f Formalized in the 1990s (OMG) and later documented as an international standard.10
g Available at: www.mdpnp.org/MD_PnP_Program_CS_Reposit.php. Accessed August 2, 2015.
h Available at: www.mdpnp.org/mdids.html. Accessed August 2, 2015.
i Available at: http://asrs.arc.nasa.gov/overview/confidentiality.html. Accessed August 2, 2015.
j Available at: http://www.fda.gov/MedicalDevices/Safety/ReportaProblem/default.htm. Accessed August 2, 2015.
3. James JT. A new, evidence-based estimate of patient harms associated with hospital care. J Patient Saf 2013;9:122–8.
5. ASTM standard F2761-09:2009. Medical Devices and Medical Systems—essential safety requirements for equipment comprising the patient-centric integrated clinical environment (ICE)—part 1: general requirements and conceptual model.
6. Goldman JM, Whitehead S, Weininger S. Eliciting clinical requirements for the medical device plug-and-play (MD PnP) interoperability program. Anesth Analg 2006;102:S1–54.
7. Zachman JA. A framewiork for information systems architecture. IBM Syst J 1987;26:276–92.
9. OMG Unified Modeling Language Superstructure Specification, version 2.1.1. Document formal/2007-02-05, Object Management Group, February 2007. Available at: http://doc.omg.org/formal/2007-02-05.pdf
12. Alonso D, Plourde J, Weininger S, Goldman JM. Web-based Clinical Scenario Repository (CSR™). Anesth Analg 2014; 119(6S_suppl):64.
13. Grinspan ZM, Pon S, Greenfield JP, Malhotra S, Kosofsky BE. Multimodal monitoring in the pediatric intensive care unit: new modalities and informatics challenges. Semin Pediatr Neurol 2014;21:291–8.
14. Blaar M, Janß A, Dell’Anna J, Höllig A, Radermacher K, Clusmann H. Bottlenecks and needs in human-human and human-machine interaction—a view from and into the neurosurgical OR. Biomed Tech (Berl) 2016;61:135–46.
15. Stroetmann V, Thiel R, Stroetmann KA, Wilson P, Romao M, Strubin M. Understanding the role of device level interoperability in promoting health—lessons learned from the SmartPersonalHealth Project. Yearb Med Inform 2011;6:87–91.
16. IEC 60601-1:2005 Medical electrical equipment - Part 1: General requirements for safety and essential performance.
18. Hankin CS, Schein J, Clark JA, Panchal S. Adverse events involving intravenous patient-controlled analgesia. Am J Health Syst Pharm 2007;64:1492–9.
© 2017 International Anesthesia Research Society
19. Goldman JM. Medical device connectivity for improving safety and efficiency. ASA Newsl 2006;70:5.