Applying Medical Device Informatics to Enable Safe and Secure Interoperable Systems: Medical Device Interface Data Sheets

Abstract

This article describes the concept of Medical Device Interface Data Sheets (MDIDSs) to document and characterize medical device interface data requirements, the processes for creating MDIDSs, and its role in supporting patient safety and cybersecurity of current systems while enabling innovation in the area of next-generation medical Internet of Things (IoT) platforms for integrating sensors, actuators, and applications (apps).

An ecosystem of interoperable medical devices holds the promise of enabling the deployment of systems of devices, platforms, sensors, actuators, and software applications (or “apps”) to improve patient safety, reduce development times and operating costs, and facilitate widespread innovation in health care. The current medical technology ecosystem is populated with noninteroperable systems that inhibit these goals. Modern medical devices range from very simple single-parameter devices to increasingly complex multiparameter, multiple-function devices with closed-loop control and interfaces intended for communicating physiological and contextual data with other systems. Achieving safety requires that heterogeneous interoperable devices, which are intended to be effective “citizens” as part of a coordinated system, can interface using known device characteristics that are agreed on by all stakeholders.^1,2 Developing a sufficiently complete set of safety- and security-related medical device interface characteristics to facilitate reliable and seamless interaction between different components of medical electrical equipment systems remains difficult, expensive, and elusive. A common, well-defined shared vision for what information should be communicated for potential use by all stakeholders is essential.

The Medical Device Plug-and-Play (MD PnP) Interoperability and Cybersecurity program based at the Massachusetts General Hospital has prototyped a collection tool and repository for capturing, analyzing, and archiving information for safety derived from clinical scenarios^a that can be communicated via a device’s electronic data interface (EDI) in support of safe and secure interoperability. The clinical scenario process³ identifies the entities and interactions within the integrated clinical environment, the boundaries to the external system, and the information that crosses the boundaries or is transmitted internally. As part of a 5-year National Institutes of Health (NIH)-funded Quantum Medical Device Interoperability (QMDI) grant, a number of clinical scenarios were identified that described interactions that support safe and secure operation.⁴ These were analyzed in depth to produce requirements relating to the system behavior and necessary information to be communicated within the system.³ Hazardous situation information and proposed risk control measures were identified to improve existing device capabilities and interoperability and support a “Learning Health System” to improve health care delivery.³ Together with the repository, this information forms the foundation of the Medical Device Interface Data Sheets (MDIDSs).

Figure 1.: Inputs and outputs of Medical Device Interface Data Sheets (MDIDSs).

The inputs for MDIDSs (Figure 1) include data drawn from published manufacturer specifications, existing device and communication standards, 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. MDIDSs may include interface requirements for clinical scenarios that are envisioned but may not yet be possible to implement due to limitations of current interfaces and devices. The aggregated consensus MDIDS content can be used to update health information technology (HIT) informatics and medical device standards, product specification, and equipment procurement requirements (Figure 1). This article describes the concept of MDIDS, the processes for creating, managing, and sharing MDIDS, and its role in improving patient safety and cybersecurity.

DEVELOPING MDIDS

Concept of an MDIDS

MDIDS serves as an approach to identify and document current and desired medical device data inputs and outputs. In this model, measurable quantities (eg, physiological parameters) are considered data and information about these parameters (eg, time of recording, configuration, settings) is metadata. The MDIDS content reflects information relating to internal states and clinical context, hazardous situations resulting from workflows, product usability, data integration, and medical device–HIT system integration. MDIDS includes descriptions and rationale for why each data element is important. An MDIDS may 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, robust cybersecurity, and more efficient clinical use.

Exposing the published specification and current settings on the device interface promotes safety by enabling connected devices and apps to determine whether the interacting devices are appropriate for the intended app. For example, are the pulse oximeter’s specifications and settings and associated interoperability specifications appropriate for use by a neonatal monitoring app? Does the oximeter have an appropriately fast averaging time for a sleep apnea diagnostic app? Does a noninvasive blood pressure (NIBP) monitor have a stat mode to enable rapid and continuous monitoring of blood pressure (BP) changes for closed-loop BP control or tracking the progress of resuscitation?

MDIDS is intended to help facilitate securability by exposing the information necessary to support improved security and privacy and provides the metadata that can allow external entities to judge the trustworthiness of the device. MDIDS can contain information related to establishing trust of a connected device, the device’s identity using device identifiers, compatibility with applicable safety and security standards/architectures, and compliance to regulatory and safety norms.⁵

The simplest elements to be captured in the MDIDS are the data and metadata which are outputted by the EDI (referred to as a functional connection in International Electrotechnical Commission [IEC] 60601-1). Examples of these outputs include physiological parameters, waveforms, and device settings. MDIDS can describe characteristics of each signal, such as the dynamic range of the BP sensor, sample rate of a photoplethysmogram from pulse oximeters, flow, volume and pressure modes from lung ventilators, the filter setting of an electrocardiogram (ECG), and metrics for data quality and quality of service (QoS). To complete the information set, any aspect of the device’s user interface that the clinician can interact with (eg, alarm volumes or controls on the front panel for stopping and starting therapy³) would be included.

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 because these behaviors may not be observable. Internal state can reflect, for example, whether the device is in standby mode, is operational, or is undergoing calibration. Operational capabilities include the ability of a device to be controlled (eg, to be started, stopped, or restarted) via the EDI. The clinical context and app are key determinants of the data and metadata needed for connected devices. MDIDS can capture functional metadata such as whether a pulse oximeter has enhanced motion rejection, whether a heart rate monitor has high-resolution diagnostic capabilities, or whether an intravenous infusion pump can auto-restart after a transient flow obstruction. Relevant clinical context indications such as the patient’s physical activity status, body position or relative location on the body of different devices, sensors, or catheters may need to be captured as well as the operators’ interactions with the devices (eg, button pushes). Interactions can arise based on where a device is located relative to another device, such as an oximeter applied to an ipsilateral limb distal from a BP cuff. Other contextual information could indicate mode status such as when physiological data are not available, during a calibration cycle of a CO₂ respiratory gas analyzer, at which time CO₂ concentration cannot be measured.

Structure

Each MDIDS includes basic content reflecting a core set of generic device capabilities and more complex information reflecting extended or optional device- or implementation-specific characteristics. The structure of an MDIDS includes the generic information identifying the device and components, its settings, power source, and other information that is not device-type specific. In addition to the generic content, there is device-specific content related to the core medical device capability (sensor or actuator). Representative elements of a generic sheet for a single parameter device (Table 1) include information identifying the device and components, its setting and configuration, location, and operating condition. The MDIDS for a multiparameter monitor would be composed of multiple single-parameter “sheets” and additional information relating to interactions between these components as well as shared characteristics of the device as a whole.

Table 1. - Summary of MDIDS for Oximeter With Generic and Specific Data Elements

Element Type	Example(s)	Data Type(s)
Generic
Device identification data	Serial Number, FDA UDI	Numeric or string
Data encoding for device-specific data elements/ontology	IEEE 11703	Numeric or string
Software/firmware versionsa	Firmware versions of each component	Numeric or string
Patient identificationb	Unique identifier	Numeric or string
Location information/clinical context?	ICU/cold and shivering	Enum or string
Operating conditions of the device	On, calibrating, paused; battery, line operated	Enum or string
Configuration	Network address	Enum or string
Authentication	Hash-based message authentication code	Numeric or string
Certificates of interoperability/security conformance	Digital certificate from appropriate Certificate Authority	String
Pulse oximeter device specific
Measured physiological variables	Spo 2, pulse rate, pleth	Numeric (single value or waveform)
Measured technical variables	Calibration time/time to first measurement	Numeric
Calculated physiological variable	Perfusion index	Numeric
Use settingsc	Signal quality indicator, averaging time	Numeric or enum
Alarm limitsc	Spo 2 low limit	Numeric
Alarm configuration settingsc	Alarms	Enum or boolean
Physiological alarm condition	Spo 2 high	String
Technical alarm condition	No sensor	String

Abbreviations: Enum, enumerated type; FDA, Food and Drug Administration; ICU, intensive care unit; IEEE, Institute of Electrical and Electronics Engineers; MDIDS, Medical Device Interface Data Sheet; pleth, plethysmogram; Spo₂, oxygen saturation; UDI, Unique Device Identification.

^aMay include Cybersecurity Bill of Materials (https://www.phe.gov/Preparedness/planning/CyberTF/Documents/report2017.pdf).

^bProtected health information.

^cMay be as a function of patient type or sensor connected.

The structure of an MDIDS can be organized into groupings representing (1) data outputs; (2) data inputs (including adjustment of alarm thresholds and control of device functions via the EDI), device control functions; (3) technical information; and (4) device states. Device control functions could include interface-based adjustment of any operator-settable functions (eg, ability to pause an infusion pump, initiate or terminate a BP cuff inflation cycle, set ventilator tidal volume of inspired oxygen setting). Technical information includes QoS, security controls (eg, encryption, authentication), and data constraints (eg, allowable ranges). Device state includes status information on the device’s different component parts (eg, sensing, power, actuators) such as sensor states (eg, warming up, ready, calibrating).

An MDIDS for a monitoring or therapeutic device may include the following:

• listing of required and optional variables including waveforms, parameters, and settings for each physiological sensor, other sensors, and actuators;
• the datatype for the parameter;
• options and state of units of measure;
• indications as to whether the parameter, variable, or setting is required or optional;
• International Organization for Standardization (ISO)/Institute of Electrical and Electronics Engineers (IEEE) 11073 Part 10101 (https://www.iso.org/standard/77338.html);
• list of alarm conditions^7,8; and
• any clinical rationale that can help use the signals safely.

Portions of the device-specific elements for a pulse oximeter (Table 1) illustrate the wide range of elements that should be considered for inclusion. Draft MDIDS has been developed for devices including the pulse oximeter, anesthesia workstation, defibrillator, and dialysis machine.⁹

How to Capture

The process of populating the MDIDS consists of collecting and analyzing clinical scenarios and associated information (eg, product manuals and standards) to identify context, assumptions, and other information.

Clinical context of the device includes the clinical environments where the device might be used and the patient populations on which it may be used. MDIDS derived from a series of clinical scenarios from a highly supervised environment such as the operating room may reflect different information attributes than scenarios from less supervised environments such as the general floor or home care. Similarly, clinical scenarios for a device intended to be used solely on adult intensive care patients would likely generate different requirements than a device solely used in a neonatal intensive care unit. The use of the required Unique Device Identification (UDI)¹⁰ in the United States holds the promise of allowing these devices to be easily differentiated and provides benefits in terms of enabled interoperability and security.

To provide support and greater clarity with respect to the inclusion of the specific data components, the MDIDS can include links to references such as publications that provide the rationale for the required data and any existing standards or regulatory guidance. A web-based tool, the Clinical Scenario Repository, has been prototyped to assist the process of populating MDIDS and allows for the distributed capture and collaborative assessment of clinical scenario content.¹¹

Using the 4 clinical scenarios in Table 2, inputs and outputs from the pulse oximeter can be identified and related to the hazardous situation. Note that in this example nearly all the outputs from the pulse oximeter have been previously identified and included in existing devices, but the inputs have not. One of these inputs, cuff inflation status, derives from a clinical scenario in which a finger pulse oximeter and BP cuff are placed on the same arm resulting in artifactual values from the pulse oximeter during the time the cuff is inflated, occluding the brachial artery. The impact of this cuff-induced hypoperfusion on the disappearance and reappearance of accurately measured saturation values must be accounted for. Coordinating the operation of the pulse oximeter and BP cuff inflation supports the safe operation of the system, especially in regard to interpreting the pulse oximeter values. With knowledge from the MDIDS, artifactual oxygen saturation (Spo₂) measurement made during inflation of the cuff can be identified and avoided.

A similar device to device interaction that can avoided by using information from the MDIDS is an NIBP with intravenous (IV) infusion pump interaction where NIBP cuff inflation increases IV backpressure triggering a downstream occlusion alarm on the pump. A closed-loop control system that is administering IV fluid boluses to maintain BP could decrease fluid administration rate during the period of cuff inflation.

DISCUSSION

Access

To facilitate conceptual interoperability,² a library of MDIDS would be available electronically and curated by a neutral third-party organization. This approach is analogous to the “one-stop” approach applied to the database of approximately 3500 graphical symbols for use on equipment, a collection of the graphical symbols in IEC 60417 and ISO 7000. As the MDIDS library develops, additional variables, alarms, and other data can be incorporated. These data items will come both from existing devices on the market, medical device recalls and adverse event analysis, and research activities. The initial focus should be on key safety use cases, such as those related to safe IV opioid medication infusion using a patient-controlled analgesia (PCA) pump. Devices relevant to these scenarios include PCA pumps, pulse oximeters, ECGs, noninvasive BP devices, and capnographs.

Stakeholders

MDIDS is intended to be living documents used by a range of stakeholders (Figure 2). Stakeholders for such information include standards development organizations (SDOs), manufacturers, clinical users (ie, health delivery organizations [HDOs]), researchers, cross-domain interoperability and cybersecurity working groups, and regulators. MDIDS highlights aspects of the device needing standardization and can guide SDOs with these efforts. MDIDS can be used to document aspirational device capabilities as derived from clinical scenarios, such as communication of IV pump back pressure for use by an app to monitor IV catheter functional integrity. MDIDS can provide a common reference point for the manufacturer to inform its product development. This may avoid or reduce duplicative or conflicting information models (eg, conflicting semantics within the ventilator community) and confusion in the market place.

Figure 2.: Virtuous cycle of stakeholders. EHR indicates electronic health record; MDIDS, Medical Device Interface Data Sheet; SDO, Standards Development Organization.

Standards committees can develop interface specifications and may be diverse with regard to their scope. Some committees focus on data communication for HIT (eg, ISO TC 215), and others deal with basic safety and essential performance of medical devices (eg, ISO TC 121. AAMI A/R, IEC 62D). These committees have liaison functions, and although they may have some overlap with respect to experts, they may not be working from the same clinical needs and safety concerns playbook. Standards development experts of device-specific and communication standards committees could use MDIDS by matching data elements to existing standards and help identify standards gaps that need to be addressed, particularly as each document undergoes review and revision. The efforts at adopting elements of MDIDS into particular device safety and performance standards have been expanding in the last few years. Within ISO technical committee 121 on anesthesia and respiratory equipment, an associated informative annex for data interface requirements has been drafted by experts, including authors of this article, on these committees for several published and draft standards. These standards include the published international standard for sleep apnea breathing therapy equipment (ISO 80601-2-72) and the draft standards for pulse oximeters (ISO 80601-2-61) and respiratory gas monitors (ISO/IEC 80601-2-55). MDIDS is now under consideration for key standards development including current standards work related to defining requirements to promote safe interoperability (eg, Association for the Advancement of Medical Instrumentation [AAMI] Interoperability Working Group and AAMI-UL 2800).

Device manufacturers, in addition to contributing expertise during the development of the respective horizontal and device standards, and using those standards during product development, need to consider the latest relevant MDIDSs to support future system interoperability.

HDOs can utilize MDIDS to guide procurement decisions and can contribute interface capabilities that will support more effective device-to-EHR integration, innovative clinical care, and more effective clinical management.

Researchers can propose concepts, terms, and identify workflows that should be mined for information to be included in the MDIDS.

Regulators can use MDIDS to understand the breadth of capabilities a new device could offer.

Prototyping

Information to populate an MDIDS can be collected in a variety of ways, including clinical scenario analysis and domain expert consultations. Table 2 illustrates populating a proposed MDIDS of a pulse oximeter using the outputs from 4 clinical scenarios, all with a pulse oximeter in common, and includes the required information content to address the identified hazards.³ The methods for collecting and analyzing scenarios were prototyped at a preconference workshop for NIH/IEEE EMBS Wireless Health 2016.¹²

Table 2. - Example of Identifying MDIDS Attributes From Clinical Scenarios⁵

Devices → MDIDS Attribute↓	Pulse Oximeter Used for Sleep Screening	PCA Pump With Safety Interlock	Finger Pulse Oximeter and BP Cuff on Same Arm	EHR and Medical Device Data
Summary of clinical scenario	Patient with obstructive sleep apnea has repeated oxygen desaturations during the night. Averaging time of pulse oximeter must be set correctly to accurately capture transient desat events.	Patient sedated with opioids—at risk for respiratory depression. Averaging time of pulse oximeter must be set correctly to accurately detect transient desat events.	Inflation of cuff interferes with monitoring of Spo 2 at same time on same limb. State of NIBP not made known to app so that it can ignore the Spo 2 data during and immediately after cuff inflation.	Monitored patient on floor has repeated rapid oxygen desaturations occurring faster than time resolution captured by the EHR. Clinically relevant events may not be captured in EHR.
Hazardous situation	Averaging time in a pulse oximeter is usually user-selectable, and setting may not be visible to the user or diagnostic app.	Architecture/device defect; device not capable of acknowledging, no feedback signal was architected into the platform.	False low Spo 2 alarms. Erroneously low Spo 2 data may activate safety interlock and stop opioid when not warranted.	Missed desaturation events could impact clinical care decisions.
System requirement	App needs to know averaging time.	Pump state needs to be available to confirm stop command.	NIBP should communicate the status of cuff inflation.	Device state and clinical context need to be captured by EHR—including clinical data with sufficient time resolution.
MDIDS Entries to address hazardous situation with Device 1—Pulse Oximeter	averaging time, Spo 2 value	Spo 2 value, averaging time	Spo 2 value	Spo 2 value, averaging time, EHR integration sampling parameter
Device 2	n/a	Infusion pump: PCA pump state	NIBP: Cuff inflation status	EHR: vital sign data resolution

Abbreviations: App, application; BP, blood pressure; EHR, electronic health record; MDIDS, Medical Device Interface Data Sheet; n/a, not applicable; NIBP, noninvasive blood pressure; PCA, patient-controlled analgesia; Spo₂, oxygen saturation.

Table 3. - Event Sequences Used for Workshop Input

Initiating Event, Clinical Workflow	Pivotal Event or Intermediate Condition	Outcome or Result	Hazard, Consequence, or Comment	Data/Metadata or Risk Control Measure
Student E needs to check her asthma status; she is feeling ill/displaying symptoms	Student E powers up devices A and B.	Devices A and B make Bluetooth LE connection with Student E smartphone.	Device does not have valid certificate to connect.	Certificate that comes with devices A and B so you know the pedigree of the device.
			RF interference affecting measurement.	Use of open standards to connect devices to phone.
				Smartphone records location and time.
			School policy may prohibit use of smartphone.	Nurse’s identity is “recorded.”
	Can teacher initiate measurement?		Record context of use: home spirometer, school device?	Physical position of patient.
	Corollary for home use?
	Smartphone walks thru measurement process as reminder.		School spirometer might be swapped—not clear instructions or open standard used.	Training and usability. Does the school have a trained nurse? Does the school have an acceptable spirometer—is it connected to the SmartPhone?
				List of acceptable devices—certification.
				Interoperability/PnP to swap devices—what type of architecture is needed.
				Status of device? Dropped, dirty? Personal device required?
				Self-test looking for proper function of app and platform and connected devices.
	Smartphone queries device A for Spo 2 reading and device B for flow curve.	Smartphone evaluates flow curve for appropriate metrics.	Data accuracy and dependability.	Measures of performance to assure device were used correctly.
				Manually note error in use/annotation of conditions of measurement.
				External error button.
				Air quality from wrong location or out of date.
App detects decrease in Spo 2 and exhaled peak volume	Alerts student and School Nurse.	Nurse informs parents and updates health record.	What are the risks of the decision?	Calibration and maintenance.
			Independence of measurement data.	Semantic interoperability.
				Build intolerance/age of data.
				Use of air quality is from an unknown source (confidence).
				Consider how to react in the presence of low confidence data.
				Track activity and location and food and medication of student to know what triggers events.
			What we can control versus what we cannot.	Does school have the equipment or just the student? How to correctly match equipment data with correct patient?
				How much of the data can/should be shared and with whom?
App makes a recommendation	Informs parent and EHR		Can principal override decision?	What to do if any of the permissions or devices are not available?
			What if parents cannot contact nurse/student?	Is there an escalation path built into app (green, yellow, red)? And fall back modes (what happens when data or devices are unavailable)?
			What is the intent of the app and how does the data support that app? Does it change the risk of using the data?	Looking at single event or over multiple events/days

Abbreviations: App, application; PnP, Plug-and-Play; RF, radiofrequency.

Figure 3.: Initial workshop scenario with actors, devices, and questions. CDS indicates Clinical Decision Support; PHI, protected health information.

At the Workshop, a clinical scenario based on the use of wireless platforms and involving the use of a personal medical device was constructed for investigating the information necessary for the primary care physician to properly understand what level of trust to place in data collected with these types of devices. The scenario considered an adolescent using a pulse oximeter for asthma assessment and explored what data should be included in the MDIDS for this type of clinical scenario. Starting with an initial scenario and questions (Figure 3), a modified event tree analysis was used to analyze what data and metadata would be needed at each event stage (Table 3). Event tree analysis presents the clinical workflow elements in chronological order that allows one to examine a series of subsequent events or consequences. This process includes consideration of possible outcomes of an initiating event and data or metadata needed to control risk. The systemic consequences of events and combinations of causal factors and probabilities are also considered. Attendees assisted in the initial construction of robust use cases that helped identify hazards, root causes, and risks; context and state of devices, patient, and the environment; governance and procedures; and possible risk control measures (see Supplemental Digital Content, Table 1, https://links.lww.com/AA/C842). This work remains to be completed but still provides important information to help populate an MDIDS, as well as support clinical study design, Institutional Review Board (IRB) considerations, device interoperability, and regulatory approval.

CONCLUSIONS

The authors propose the development of a repository of medical device interface data sheets that is curated, extensible, and readily available to support safe interoperability. The initial MDIDS work to date is intended to be augmented with additional scenarios and devices. These efforts will require working with medical device manufacturers, clinicians (especially for input on future clinical needs for device data), and biomedical engineers. MDIDS is intended to be shared with applicable standards groups such as ISO TC 121,^b AAMI Interoperability Working Group, AAMI-UL 2800, and IEEE 11073 members for input and feedback to ensure the results are appropriate for use with their respective standards. The plan for future work is to analyze equipment user and service documentation, data from devices in the Massachusetts General Hospital (MGH) MD PnP Interoperability Lab, and additional device data obtained in meetings with device manufacturers. As MDIDS libraries develop, additional variables, alarms, and other data will be added. These data items will come both from existing devices on the market, as capabilities are surveyed, and an analysis of the future device capabilities necessary to support the clinical scenarios being considered. MDIDS sheets for devices studied in clinical scenarios will be made available with the documentation that explains the MDIDS concept and how to use the MDIDS sheets. A community-funded sustainability model is being explored.

A comprehensive set of MDIDS will provide standards developers, medical device manufacturers, researchers, regulators, and the health care organization community with a compendium of medical device interface capabilities and data elements that can be used for product and standards development and device procurement. This reference compendium and MDIDS methodology could enable more complete, effective, and safe device integration and will provide a baseline of what is known today to build on for future iterations.

ACKNOWLEDGMENTS

We wish to thank Tracy Rausch (DocBox, Inc, Newton, MA), Steve Dain, MD (Western University, London, Canada), Pratyusha Mategunta and Dave Arney (MGH Medical Device Plug-and-Play Program [MD PnP]) and Jennifer Jackson (the Brigham and Women’s Hospital) for their collaboration on developing the Medical Device Interface Data Sheet (MDIDS) concept and prototype MDIDS for several devices.

DISCLOSURES

Name: Julian M. Goldman, MD.

Contribution: This author helped provide the data, cowrite the manuscript, and served as principal investigator (PI) for foundational research.

Name: Sandy Weininger, PhD.

Contribution: This author helped analyze the data and write the manuscript.

Name: Michael B. Jaffe, PhD.

Contribution: This author helped analyze the data and write the manuscript.

This manuscript was handled by: Maxime Cannesson, MD, PhD.