Share this article on:

Capturing Essential Information to Achieve Safe Interoperability

Weininger, Sandy PhD; Jaffe, Michael B. PhD; Rausch, Tracy CCE; Goldman, Julian M. MD

doi: 10.1213/ANE.0000000000001351
Technology, Computing, and Simulation: Special Article

In this article, we describe the role of “clinical scenario” information to assure the safety of interoperable systems, as well as the system’s ability to deliver the requisite clinical functionality to improve clinical care. Described are methods and rationale for capturing the clinical needs, workflow, hazards, and device interactions in the clinical environment. Key user (clinician and clinical engineer) needs and system requirements can be derived from this information, therefore, improving the communication from clinicians to medical device and information technology system developers. This methodology is intended to assist the health care community, including researchers, standards developers, regulators, and manufacturers, by providing clinical definition to support requirements in the systems engineering process, particularly those focusing on development of Integrated Clinical Environments described in standard ASTM F2761. Our focus is on identifying and documenting relevant interactions and medical device capabilities within the system using a documentation tool called medical device interface data sheetsa and mitigating hazardous situations related to workflow, product usability, data integration, and the lack of effective medical device-health information technology system integration to achieve safe interoperability. Portions of the analysis of a clinical scenario for a “patient-controlled analgesia safety interlock” are provided to illustrate the method. Collecting better clinical adverse event information and proposed solutions can help identify opportunities to improve current device capabilities and interoperability and support a learning health system to improve health care delivery. Developing and analyzing clinical scenarios are the first steps in creating solutions to address vexing patient safety problems and enable clinical innovation. A Web-based research tool for implementing a means of acquiring and managing this information, the Clinical Scenario Repository™ (MD PnP Program), is described.

Published ahead of print July 5, 2016.

From the *Office of Science and Engineering Laboratories, Food and Drug Administration/Center for Devices and Radiological Health, Silver Spring, Maryland; MD PnP Program, Massachusetts General Hospital, Boston, Massachusetts; DocBox, Newton, Massachusetts; §Department of Anesthesia, Critical Care, and Pain Medicine, Massachusetts General Hospital, Boston, Massachusetts; and Partners HealthCare System, Boston, Massachusetts.

Published ahead of print July 5, 2016.

Accepted for publication March 17, 2016.

Funding: Supported, in part, by the National Institutes of Health (grant no. 5U01EB012470-03), National Science Foundation (grant no. IIS-1239242), and Department of Defense (grant nos. W81XWH- 09-1-0705, W81XWH-12-C-0154, W81XWH-11C-077, and W81XWH-13C-0107).

The authors declare no conflicts of interest.

This report was previously presented, in part, at the Innovations and Applications of Monitoring Perfusion, Oxygenation and Ventilation, October 4, 2015 (Tokyo, Japan).

Reprints will not be available from the authors.

Address correspondence to Sandy Weininger, PhD, Office of Science and Engineering Laboratories, Food and Drug Administration/Center for Devices and Radiological Health, 10903 New Hampshire Ave, Silver Spring, MD 20993. Address e-mail to

Medical devices are generally designed to deliver adequate performance for a population, rather than performance tailored for the needs of an individual patient in a specific setting, thereby potentially exposing patients to unsafe conditions or less effective care. Determining how to optimize devices and algorithms for specific patients, disease states, or practice settings is prohibitively expensive for any single manufacturer because available data sets are often limited in size and scope, and the cost to research all potential subpopulations would be commercially prohibitive. Implementing proposed device or algorithm customizations or “personalizations” by the health care provider is complicated by current device designs and proprietary business practices often prevent algorithm customization. Proposed approaches, such as data fusion and other computational techniques that require real-time access to data from multiple devices, are especially difficult or impossible in the current environment because of the lack of interoperability between medical devices and between devices and health information technology systems. Where there is interoperability, the electronic health record is likely to store a small subset of patient and medical device data. Therefore, manufacturers, academic researchers, and clinicians have an overly complex, expensive, and inefficient path to researching and developing medical applications.

As noted in the information technology and health section of the 2015 review from the President’s Council of Advisors on Science and Technology Networking and Information Technology R&D Working Group,b health care innovation is hampered by the nature of many of the innovations that “do not fit naturally into either clinical or basic science methodologies”1 and the difficulty of translating innovations into the health care setting. This report included several findings that highlighted the need for new approaches, platforms, and tools to help address the current problems faced in health care innovation.

These barriers to innovation contribute to preventable medical errors, considered to be the third leading cause of death in America.2,3 Some of these errors stem from measurement errors when devices that are designed to work on the “average adult person in a typical setting” are used on individual patients with specific conditions, different characteristics, or atypical settings (eg, pediatrics, elderly, and shivering). Errors can stem from the incorrect use of the devices, which are often in need of improved human-centered design. As evidenced by the remarkable success of application development for smartphones, an open platform-based solution that enables the stakeholders closest to the problem to propose and develop solutions may help, in part, by reducing the time for iteration and aligning solutions with clinical needs. The clinical scenario is the first step toward that solution.

Table 1

Table 1

With a view toward embracing future-integrated open-health platforms as a means of leveraging interoperable solutions, a systematic approach to capturing information about the clinical environment is needed to ensure that the emerging platform-based technologies will support the clinical needs. This information is essential for understanding the interactions among devices, patients, and caregivers and among devices within the system. In this article, we describe a method for collecting information necessary to design and support the safe operation of platform-based interoperable systems of medical devices and the associated systems engineering process of medical device and applications development. The processes described in this article are included as the first 3 stages of the clinical concept of operations (CConOps) processes (Table 1) and require the input of clinicians and clinical engineers. The overall approach includes a high-level description of the “clinical scenario” to capture the broad intended clinical application and a detailed CConOps to capture the entities and interactions within the integrated clinical environment (ICE) and boundaries to the external system. This CConOps process enables the collection of a comprehensive and robust set of user needs and system requirements. These needs and requirements, which are related to phases 0 and 1 of traditional engineering design processes, are often not adequately captured by these methods (Table 1). The terms “clinical scenario” and “CConOps” were developed in the course of research we performed via the Medical Device Plug-and-Play (MD PnP) Research Program and documented in international consensus standard ASTM F2761(09),5 “Medical Devices and Medical Systems—Essential safety requirements for equipment comprising the patient-centric ICE—Part 1: General requirements and conceptual model.”

Back to Top | Article Outline


Clinical information capture is the first step toward identifying the system behavior and potential hazardous situations that need to be addressed. The term clinical scenario, as used in this article, is a description of a clinical situation with a focus on the hazardous situations that may arise because of interactions between entities in the system. The CConOps builds on this information to lay the foundation for robust system development.

ASTM F27615 defines a clinical scenario as a brief description of a clinical situation or event usually written by a clinician to provide background and illustrate the need for the development of a technical solution. Documenting a clinical scenario helps to: (a) identify current opportunities to improve patient care and safety, (b) understand what functions the system has to provide to address the clinical problem, and (c) identify entities, interactions, and hazardous situations within the system. To address the desired clinical problem, both the current and future states need to be documented. The Current State, sometimes called “as is,” shows what problem is being addressed and documents existing hazards. The current clinical scenario is the current workflow, equipment, and environment with identified technical/process issues and hazardous situations. The Current State describes a situation where devices that are not interoperable may result in an adverse event or place the patient at greater risk than had the devices been part of a smarter “ICE,” and the lack of interoperability may limit the efficient implementation of an effective solution. The Current State can also describe a clinical event where efficiency could be greatly improved but where a new system design is required for improvement. The future state clinical scenario, sometimes called “to be,” describes the vision of an integrated solution, specifically, the system changes needed to result in improved safety, effectiveness, or efficiency (ie, the Proposed State). The future state is analyzed for 2 reasons: to determine how to successfully implement it and to uncover system requirements and hazards that may result from the future system. The latter aspect is the focus of this article. The changes described in the Proposed State include the technical and process changes (eg, workflow, training) intended to address the Current State’s identified hazards, risks, and inefficiencies. As such, a complete and robust identification of these user needs and systems requirements are central to assess the Current State and implement a safer, improved Proposed State, which meets the clinicians and patients needs for improvements in clinical care.

Back to Top | Article Outline


The development of platform-based solutions in health care requires that the proposed range of clinical applications the platform supports be known and documented, so that the platforms and their respective components can be designed, integrated, and operated appropriately. A key benefit of a platform is the ability to develop new applications and use new sensors and actuators. The range of applications proposed for the hazard analysis described above cannot cover the scope of all future applications. Therefore, the selection of clinical applications to perform a platform-applicable hazard analysis is vital and has been investigated under a National Institutes of Health–sponsored cooperative agreement. The creation of this supporting documentation requires clearly defining the entities involved and their interactions. Detailed technical specifications or the CConOps governing the operation and performance of the system have to be agreed upon by all stakeholders in the system to achieve safe operation of a platform-based solution.

A CConOps describes how the devices and clinical staff interact in the current or Proposed State. This description may include details on the hardware and software (eg, medical devices, nonmedical equipment, and applications), the associated clinical processes, staff (clinical or otherwise), associated hazards/risk analysis for both the Current and Proposed States, and proposed changes to the equipment or workflow that could potentially improve safety and effectiveness.5,6 The detailed description of the clinical scenario and its associated CConOps allows developers to explicitly know the context, state, and the state transitions of the entities within the larger clinical system and the conditions and context under which the technologies can be used safely.

Figure 1 illustrates a system diagram for a CConOps describing a patient-controlled analgesia (PCA) system with a safety interlock that responds to respiratory depression. It shows the entities involved and their interactions including the medical devices (as part of the device suite) with the key measurement and control variables, the human entities (the patient and clinician), controlling software safety application, and system-level functionality that an ICE would provide (eg, system data logger and access to an external network such as a health information technology system). This diagram helps delineate interfaces and what is in and out of scope of the system as well as what is under the control of the system developer.

Figure 1

Figure 1

A well-documented clinical scenario and its associated CConOps include the following elements:

  • Clinical workflow
  • Contextual information (eg, state of the patient and customizable device settings)
  • Intended use of the system
  • Boundaries of the clinical application
  • The information that flows across these boundaries and within
  • Entities (eg, medical devices, information technology (IT) infrastructure, humans, and other equipment)
  • Functions that occur within and outside the boundaries
  • Any interactions between these entities
  • Hazardous situations perceived or documented via literature or clinician input
  • Performance demands of each entity necessary to achieve safety and effectiveness of the system.
Back to Top | Article Outline


The information needed to support safe interoperability is dictated by the intended use of the system. Establishing a common set of interface specifications linked to the intended use as defined by the clinical scenarios can facilitate development (Figure 2). One of the key outputs of the CConOps process is the data and metadata that are required to be communicated across the system. Medical device interface data sheets (MDIDS) are an approach to identify and document the current and proposed device data outputs and data inputs for all devices intended to be networked. The MDIDS data can include information from the published specification, interactions between the user and the device, accessible internal device states, context of use, and desired data elements that might be needed for safe system performance but are not uniformly available from currently available devices. MDIDS usually describe the information content from a semantic level of interoperability.

Figure 2

Figure 2

The simplest data to capture in the MDIDS are the data stream from the external electronic data interface port (referred to as a functional connection by International Electrotechnical Commission (IEC) 60601-1, the governing electrical safety standard). This includes the physiologic variable stream at a particular rate or on-demand basis (polled) and device settings, if available.

A more complete information set would include any aspect of the device user interface that the clinician can interact with (eg, alarm volumes or controls on the front panel for stopping and starting therapy). More challenging aspects to document include the internal state of the device, the clinical context of use, and the interactions with other entities in the system that may or should occur. Internal state can reflect, for example, whether the device is in stand-by mode, is operational, or is undergoing calibration. Operational capabilities, such as in the case of an infusion pump, the ability to be stopped or restarted, should be captured. Relevant clinical context indications such as the patient’s physical activity status or body position may need to be captured as well as the operators’ interactions with the devices (eg, button pushes). This could influence the validity of the data and requirements for the connected devices (eg, whether a pulse oximeter with enhanced motion rejection is needed, data from a jumping patient’s blood pressure cuff should be rejected, and averaging time was changed on the device interface). Interactions can include where a device is used relative to another device, such as an oximeter applied to an ipsilateral site distal from a blood pressure cuff. Other contextual information could indicate that device data are not available, such as during a calibration cycle of a carbon dioxide (CO2) gas analyzer when CO2 concentration is not being measured.

A general framework for medical device communication was proposed at a medical device interoperability working group led by one of the authors at an annual meeting of the Society for Technology in Anesthesia.c The general framework states:

  1. All data displayed to the medical device operator must be made available through the electronic data interface. (Note—This requirement excludes proprietary manufacturer data that are not displayed to the operator/clinician.)
  2. The state and change in state of any operator-adjustable setting must be made available through the electronic data interface (eg, alarm settings, signal averaging time, and computation constants).
  3. Important device attributes, such as software and firmware revisions, time of last clock update, and equipment maintenance–related data.
Table 2

Table 2

The MDIDS are intended to be a living document and evolve as new clinical scenarios are analyzed. MDIDS are intended to be available as a library in electronic form with new information added as new devices and technologies are introduced. An example structure for an MDIDS is shown in Table 2.

Back to Top | Article Outline


The clinical scenario documentation process includes preparing a high-level description of the clinical scenario, a description of the clinical workflows, and an in-depth textual description for the subset of scenarios of particular interest. Hazard analysis on the workflows should be performed to identify where the devices interact with other devices or humans, platforms connected with networks (IT infrastructure), or the patient/operator. Information identifying key device attributes (eg, hardware and software versions), connected accessories, and information on certain aspects of the “internal” operation of a device should be recorded. The determination of information to be included can be made by studying the environment in which the device is used and questioning the operators/clinicians to capture this information. Changes in the device state (eg, context-related configuration changes such as operating room versus intensive care unit) are a source of hazards and should be comprehensively documented.

This approachd (Table 1) helps ensure that technology solutions are based on practical clinical needs and involve the appropriate domain experts. This methodology plugs directly into traditional systems engineering methodologies but provides a more detailed description of how clinical data can be derived and organized to develop a clinically accurate and comprehensive CConOps.

Back to Top | Article Outline

Clinical Concept of Operations

The CConOps documents include clinical workflows, activity diagrams, and data/timing diagrams.

Back to Top | Article Outline

Clinical Workflow Diagrams.

The clinical workflow can be captured using a modeling language such as Business Process Model and Notation or Unified Modeling Language (UML). The clinical workflow diagram represents how technology fits into these processes. A clinical workflow describes the tasks performed, but these may be done in a different order depending on circumstances, such as clinical or health care delivery organizations’ preferences or policies. Areas where medical errors can or have been known to occur are identified and included to drive the risk analysis.

Analysis of the workflows provides additional insight into the system-level requirements. The objectives of the analysis of workflows for the Current State and the Proposed (improved) State are the following: (1) provide answers to the big picture questions using a system architecture methodology (eg, Zachman7 framework); (2) document 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; and (3) document the relationships between components of the system with respect to behavior or time.

Table 3

Table 3

Figure 3

Figure 3

Several methods can be used to uncover the information needed for populating the MDIDS.

  1. 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
  2. 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.
  3. 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.
Back to Top | Article Outline

Web-Based Tool for Clinical Scenario Capture

Figure 4

Figure 4

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.

Back to Top | Article Outline


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

  1. Sensitive and specific detection of respiratory compromise before irreversible injury;
  2. Discontinuation of medication infusion pump to slow or stop deterioration in respiratory status; and
  3. Provision of early, informative, notification to the clinical staff to enable early intervention.

Risks of This New System

  1. Inaccuracy of information in the physician’s orders;
  2. Inaccuracy in the information systems;
  3. Inaccuracy in clinical data, which contribute to the algorithm; and
  4. Unnecessarily stopping the infusion pump because of a false-positive alarm condition for respiratory distress.5
Figure 5

Figure 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).

Back to Top | Article Outline


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.

Back to Top | Article Outline


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.

Back to Top | Article Outline


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.

Back to Top | Article Outline


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 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.

Back to Top | Article Outline


a Available at: 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).
Cited Here...

c The session was led by Dr. Goldman at which Thomas Engel, MD, proposed the General Framework.
Cited Here...

d Per a methodology used by the Medical Device Plug-and-Play (MD PnP) research program and DocBox’s development team.
Cited Here...

e Available at: Accessed August 2, 2015.
Cited Here...

f Formalized in the 1990s (OMG) and later documented as an international standard.10
Cited Here...

g Available at: Accessed August 2, 2015.
Cited Here...

h Available at: Accessed August 2, 2015.
Cited Here...

i Available at: Accessed August 2, 2015.
Cited Here...

j Available at: Accessed August 2, 2015.
Cited Here...

Back to Top | Article Outline


1. Report to the President and Congress ensuring leadership in federally funded research and development in information technology. Executive Office of the President President’s Council of Advisors on Science and Technology, August 2015. Available at:
2. Blumenthal D, Stremikis K., Getting Real About Healthcare Value. Harvard Business Review, September 17, 2013. Available at:
3. James JT. A new, evidence-based estimate of patient harms associated with hospital care. J Patient Saf 2013;9:122–8.
4. Clinical Scenario #1—Patient Controlled Analgesia—Part 1: Narrative Description, Part 2: Workflow Diagrams, Part 3: Analysis of Current State Workflow—Working Draft Version 5.1 Quantum Medical Device Interoperability (QMDI) Project, August 2012. Available at:
    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.
    8. Clinical Scenario #1—Patient Controlled Analgesia—Part 2: Workflow Diagrams Working Draft Version 5.1 Quantum Medical Device Interoperability (QMDI) Project, August 2012. Available at:
      9. OMG Unified Modeling Language Superstructure Specification, version 2.1.1. Document formal/2007-02-05, Object Management Group, February 2007. Available at:
      10. ISO/IEC 19501:2005—Information technology—Open Distributed Processing—Unified Modeling Language (UML) Version 1.4.2.Available at:
      11. Clinical Scenario #1—Patient Controlled Analgesia—Part 3: Analysis of Current State Workflow—Working Draft Version 5.1 Quantum Medical Device Interoperability (QMDI) Project, August 2012. Available at:
        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.
        17. Adverse Event Reporting For Medical Devices. Department of Health and Human Services. Office of Inspector General, OEI-01-08-00110, October 2009. Available at:
        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.
        19. Goldman JM. Medical device connectivity for improving safety and efficiency. ASA Newsl 2006;70:5.
        © 2017 International Anesthesia Research Society