The Need to Apply Medical Device Informatics in Developing Standards for Safe Interoperable Medical Systems

Abstract

Medical device and health information technology systems are increasingly interdependent with users demanding increased interoperability. Related safety standards must be developed taking into account this systems perspective. In this article we describe the current development of medical device standards and the need for these standards to address medical device informatics. Medical device information should be gathered from a broad range of clinical scenarios to lay the foundation for safe medical device interoperability. Five clinical examples show how medical device informatics principles, if applied in the development of medical device standards, could help facilitate the development of safe interoperable medical device systems. These examples illustrate the clinical implications of the failure to capture important signals and device attributes. We provide recommendations relating to the coordination between historically separate standards development groups; some which focus on safety and effectiveness, and others that focus on health informatics. We identify the need for a shared understanding among stakeholders and describe organizational structures to promote cooperation such that device-to-device interactions and related safety information are considered during standards development.

Introduction

The failure of medical devices to communicate with each other in the clinical environment has caused patient harm¹ and has impeded the implementation of solutions to prevent patient harm. For example, the problem of respiratory depression associated with the use of patient-controlled analgesia without the monitoring of respiratory status and use of a safety interlock is well known and well characterized². Manually pausing lung ventilation for a radiograph procedure followed by diverted attention of the anesthesiologist, has led to delays in the resumption of patient ventilation with adverse outcomes³. The failure of converting weight measured in pounds into kilograms, has led to significant dosing errors⁴. Unintended documentation of a change due to the recording of an artifactual signal and missed documentation of a significant transient event in the electronic medical record (EMR) are more subtle and less dramatic examples of problems with potential negative consequences. These examples (Table 1) illustrate the clinical implications of the failure to capture important signals and device attributes, which can be addressed, in part, through standards. These standards and technology gaps have inhibited the commercialization of more effectively integrated medical devices and interoperable platform-based apps for data analysis ^5,6.

Table 1.

Examples of opportunities for medical device informatics

	Examples	Observed General Problem	Information needed for safety
1	Loss of pulse oximeter data during cuff inflation due to ipsilateral placement of blood pressure cuff and the pulse oximeter finger sensor.	Unintended documentation in EMR of artifactual data change	Blood pressure device –transmits changes in blood pressure cuff status (e.g. off, inflation start, deflation completed) Pulse oximeter – receives information regarding blood pressure status and location on patient (e.g. ipsilateral arm) to be used in data screening algorithm
2	Failure to record lowest saturation of a transient event.	Failure to record lowest value of a transient event due to data sampling methodology and time resolution of data recorded of EMR	Pulse oximeter – receives contextual information on patient type to be used in data algorithm
3	Transient desaturation improperly or not recorded in EMR	Failure to record clinically significant event in the EMR due to mismatched data time resolution.	Pulse oximeter transmits averaging algorithm’s filter settings (meta-data) to EMR.
4	Erroneous pulse rate value recorded in EMR	Absence of the waveform in the EMR inhibits signal validation	Pulse oximeter plethysmographic waveform stored and time- synchronized with ECG heart rate values
5	Spuriously inverted T wave.	Filter setting spuriously inverted the T wave	ECG device transmits filter settings.

Medical device and health information technology (IT) systems are increasingly interdependent. Hence, related safety standards must be developed from this system perspective. This paper describes the current development of medical device standards and the need for these standards to effectively address informatics aspects including medical device inter-communication and integration. Medical device information should be gathered from a broad range of clinical scenarios to lay the foundation for safe medical device interoperability. Medical devices are interoperable when they are intended by their manufacturer to exchange and use information through an electronic data interface (EDI) with another medical device, product, technology, or system. This paper provides recommendations relating to the coordination between historically separate development groups; some that focus on safety and effectiveness, and others that focus on health informatics. It identifies the need for a shared understanding among stakeholders and describes organizational structures to promote cooperation such that the device-to-device interactions and related safety information are considered during standards development.

These issues historically did not receive a great deal of attention by the manufacturer or purchaser when data from a medical device were viewed only on the device display. When device data were acquired from the EDI via an analog connection or serial data connection they were usually customized for a research application. Modern medical devices increasingly incorporate EDIs to meet customer demands that they interface to health IT systems or interact with other medical devices. More recently designed medical devices include significant improvements in connectivity using wired and wireless connections to local and remote health information networks. With the rapid advancement of networks and connected medical devices, the responsibilities and roles of various stakeholders have become more complex. To try to address the connectivity needs of these stakeholders, standards developers are defining interface requirements and protocols for the transfer of information between medical devices (e.g. HL7, IEEE 11073). Medical device informatics is the area of Biomedical Informatics concerned with the measurement, communication and use of medical device data for health care, including patient monitoring, clinical decision-making, remote monitoring, device control, equipment management, and research. The scope of medical device informatics includes the capabilities of the EDI, safety and performance of networked medical devices, safe and secure integration of clinical environments, the accessibility of medical device meta-data, and the interoperability of medical devices with other devices and health information systems.

Given the increasing demands for improved connectivity and interoperability, it is important to consider both traditional aspects of medical device safety, as defined by basic safety and essential performance, and medical device informatics. Most current medical device and health IT standards are prepared by a subgroup of relevant stakeholders with a perspective focused primarily on a particular aspect of safety and performance.

Challenges in the Development of Medical Device and Interface Standards

The language and processes of standards development as well as understanding the applicability of published standards can be daunting. It is a challenge to stay current even for standards professionals given that the landscape of standards is in continuous flux and subject to renewal cycles, political influences of stakeholders, efforts at global harmonization, and changes in technology.

Standards development organizations (SDOs) are varied and relationships with stakeholders are both country and industry-dependent. The complete name for cited SDOs with their respective websites shown may be found in the abbreviation section of Table 2. With respect to medical device standards, the standards that each stakeholder has an interest in is dependent on whether the stakeholder functions as a manufacturer, an operator, a user, a regulatory agency (e.g. Food and Drug Administration (FDA), an SDO (e.g. ASTM, AAMI) or a test laboratory (e.g. UL). Standards may be categorized⁷ as: product standards with safety or performance parameters and test methods; process standards including those addressing quality or risk management (e.g. ISO 14971^a); installation and environmental standards including system standards for the proper and safe interconnection of multiple devices into a single system, (e.g. IEC 80001-1); and in-service standards including routine in-service testing standards to ensure that the safety of a device is maintained over the useful life of the equipment⁸. Some standards families (e.g. the general standard IEC 60601-1^b) are structures of standards with a top-level general standard, collateral standards and particular standards. Collaterals add additional information to the general standard while the particular standards refine the general standard by making additions, deletions and changes to respective parts of the general standard to address the needs of a specific medical device type.

Table 2.

Selected Standards Developing Organizations (SDOs), Scope, Respective Committees and Standards

SDO	Scope	Selected Committee(s) and Scope	Selected Standard example
ISO	International (ANSI*, CEN**)	TC 121 SC1-3– standardization of anesthetic and respiratory equipment	ISO/IEC 80601-2-61:2011– Pulse Oximeter (developed within a ISO/IEC JWG 5)
IEC	International (ANSI*, CENELEC**)	TC 62, SC 62A–D – electrical equipment used in medical practice	IEC 60601-2-51 – electrocardiographs (developed within a IEC TC62D JWG22)
ASTM	International (US based)	F29 on Anesthetic and Respiratory Equipment	ASTM F2761-09, - Integrated Clinical Environment
IEEE	International (US based)	11703 - Point-of-care medical device communication	11073-10201:2004(E) Domain information model
HL7	International (US based)	Technical Steering Committee’	HL7 Fast Healthcare Interoperability Resources Specification (FHIR™),
AAMI UL	US	AAM/UL 2800- family of safety standards for. Medical Interoperability.	In development

^*Respective American SDO

^**Respective European SDO

Abbreviations: AAMI - Association for the Advancement of Medical Instrumentation (www.aami.org ) ; ANSI - American National Standards Institute (www.ansi.org); ASTM- American Society for Testing and Materials (now ASTM International)(www.astm.org); CEN- Comité Européen de Normalisation (European Committee for Standardization) (www.cen.eu), CENELEC- Comité Européen de Normalisation Électrotechnique (European Committee for Electrotechnical Standardization) (www.cenelec.eu) HL7 - Health Level Seven International (www.hl7.org). IEC-International Electro-technical Commission (www.iec.ch); IEEE- Institute of Electrical and Electronics Engineers (www.ieee.org); ISO- International Organization for Standardization (www.iso.org), JWG – joint working group, TC- technical committee, CD-committee draft, UL - Underwriters Laboratories. (www.ul.com)

The ecosystem of medical device standards contains many stakeholders and SDOs (Table 2) with scopes of responsibility for a given product area that sometimes are overlapping or ill-defined. Assuring sufficient levels of cooperation among the different SDOs can be challenging, especially with competing national approaches to harmonization⁹ despite current efforts to address these differences (see http://www.imdrf.org/). The key stakeholders in the medical device sector are usually manufacturers, regulators, health care providers, purchasers and maintainers, and clinicians. Ideally, an SDO seeks a balanced mix of stakeholder participation, by apportioning voting membership in its bylaws or providing budgetary support for selected members, such as clinicians and technical subject matter experts who may not receive travel support for standards participation from their respective employers. To achieve meaningful standards, it is essential to receive input and have involvement from all of the stakeholders to develop standards that can reasonably promote patient safety and improve care.

The process of standards development is now more than ever cross-functional. The efforts may span multiple committees and SDOs (e.g. ISO/TC 210, 215; IEC/TC 62, ISO/IEEE 11073, AAMI/UL 2800, AAMI Interoperability Working Group)^c. To help improve cooperation between the European medical device standards community, CEN and CENELEC, and their respective international counterparts, ISO and IEC, agreements have been signed and have been in place since the 1990s to provide a framework of cooperation and mechanisms for exchanging information¹⁰. Less formal methods of cooperation and collaboration have been forged both between different SDOs and between SDOs and other organizations (e.g. governmental, test laboratories) as in the form of a Memorandum of Understanding (e.g. ANSI – NIST^d) or Joint Development Agreement¹¹.

The diversity of incompatible standards has exacerbated the challenge of achieving safe interoperability. New approaches to better coordinate the development of these standards are needed. Device models^e and standards to help assure safer systems need independent organizations to coordinate the development process as we move towards a more interconnected, and interoperable ecosystem of medical equipment.

Although manufacturers and test laboratories participate in the development of standards, they may have differing interpretations of the meaning of the requirements and test methods. Language translations can be problematic and although the original version of the standard is typically English, not all translations are accurate. Although the misinterpretation of improperly translated standards is difficult to accurately gauge, a number of corrigendum (corrections) have been published to correct translation errors in standards (e.g. Corrigendum to DIN EN 61000-4-20 (VDE 0847-4-20):2011-07). This issue is of particular concern in the European Union where standards may have to be translated into all of the official languages (24 as of 2015). The translation efforts can be quite significant given all of the specific idiosyncrasies between the source and target languages.¹² Many of these standards may not adequately address issues of safety and performance when these devices are part of a larger system of medical and health IT equipment. Therefore, increased cooperation among SDOs and adequate consideration of medical device safety and informatics by all parties involved is necessary.

Relevant medical device and health IT standards

The standards which address safe medical device development took form over the last 3 decades within different committees of different SDOs. This included the general standard for electrical medical devices, IEC 60601-1, and the standard for medical device risk management ISO 14971. The General Standard is composed of horizontal requirements for the field of medical device electrical safety which lies in the main part (Part 1: General Requirements for Basic Safety and Essential Performance) and is augmented by additional collateral parts (e.g. Part 1–2: Electromagnetic compatibility, Part 1–8: Alarms, Part 1–10 for Physiological Closed Loop Controllers, etc.). This structure and hierarchy make the body of knowledge more manageable to use. As referenced earlier, the General Standard is further refined using vertically specialized requirements standards that address particular medical devices¹³. Note that representatives from both of the respective ISO and IEC committees often collaborate in the development of these standards, bringing a broad array of stakeholders to the same table.

The 3rd edition of IEC 60601-1 introduced the concepts of essential performance and risk management as key components of medical electrical device standards. This provided the users of this standard greater clarity and the opportunity to address whether a medical device performed adequately to be considered safe. However, this viewpoint was generally from a single stand-alone medical device perspective. It did not necessarily include interactions with other devices or health IT systems. If interactions outside of the stand-alone medical device are intended, then aspects of interoperability must be carefully considered when addressing a medical device’s essential performance and managing the associated risk.

Concurrently, there was a great push to develop health IT that enabled the reliable exchange of health information, mostly in the form of EMRs. The strengthening of the bridge between these two worlds, health IT and medical devices, is considered critical to creating safe, robust, secure and useful systems (e.g. meaningful use of electronic health record systems)^{14, f,g}. The growing convergence of medical devices and health information systems is leading to new risks and challenges¹⁵. Incomplete or erroneous data in EMRs can impede the application of “big data” analytics for obtaining new population-level clinical insights^16,17. The EDI, the information that the interface conveys, and the performance and safety of the medical device are essential for achieving this goal.

The General Standard does not specify what information to exchange nor aspects of the device related to the safety of the exchange. Recent revisions of particular standards (under the IEC 60601-1 umbrella) have taken the first steps at integrating interface requirements and the safe operation of the device^13,18, and have begun to seriously address what information needs to be transferred via the “functional connection.” ¹⁹

The informatics standards defining some aspects of the medical device functional connection have been developed outside of the traditional medical device safety committees. The most well-known “informatics” standard, the medical information bus originated in the late 1970s as an extension of the standard digital interface for programmable instrumentation (IEEE 488²⁰) to medical devices. The vision was that medical devices could be controlled from a central point and their data exchanged electronically as was done with test and measurement equipment. This 30+ year effort, originally envisioned as encompassing standards covering the physical through the application layer of the ISO Open Systems Interconnection model²¹, was first standardized as IEEE 1073, and later ISO/IEEE 11073 (a joint effort between ISO TC 215, Health Informatics, and IEEE Engineering and Medicine in Biology Society). The IEEE 11073 point of care family of standards and associated device profiles are informatics standards that define a domain information model and nomenclature to facilitate communication between devices. The 11073 family also includes device specializations for specific medical devices, such as personal health device communication -- Part 10404: Device specialization -- Pulse oximeter. Another approach divides the health care space into domains. One such domain, the Integrating the Healthcare Enterprise (IHE)^h Patient Care Device (PCD) [http://www.ihe.net/Technical_Frameworks/] domain uses existing standards such as HL7 [http://www.hl7.org/] and clinical language vocabularies such as Logical Observation Identifiers Names and Codes (LOINC)ⁱ [loinc.org], to provide a framework for integrating medical devices into the health care enterprise.

Clinical needs and other drivers

Clinical needs should be the primary driver for requirements intended to achieve medical device interoperability. However, economic and regulatory drivers are often the primary drivers for medical device interoperability. Many requirements relate directly to aspects of patient safety, data privacy/security, and the ecosystem that emerges from interconnected medical devices. This ecosystem includes system architecture requirements, interface specifications, nomenclatures and test methods. To achieve safe and effective interoperability ²², these requirements should be applied to all of the components in the medical device ecosystem. A “blueprint” or “roadmap,” developed by a broad coalition, is needed to connect the existing patchwork of standards that try to address those needs. This effort should be achieved with the aim of preventing new holes in the patchwork and avoiding duplicate efforts. The ICE Alliance^j has recently been formed to achieve some of these goals.

Clinical scenarios with robust descriptions of workflow, human-device interactions, and device-device interactions, should be developed to drive standards development. For example, with the clinical scenario of patient-controlled analgesia with associated respiratory depression, a comprehensive solution requires high levels of interoperability involving the respiratory monitors, the infusion pump and the clinical staff^k.

Cybersecurity components, when connected, may automatically share capabilities, context and other information as necessary to allow them to seamlessly interoperate with the other system components, in a manner widely available on smartphone and computer peripherals. The security of the medical device information, along with the security of the medical device, needs to be considered by inclusion of the applicable IT security expertise in the development of both the medical device and the related informatics standards. The publication of several high profile papers including one on pacemaker vulnerabilities²³ has highlighted this need and helped drive medical device cybersecurity awareness. This is evidenced by the publication of the FDA draft guidance on the management of cybersecurity in medical devices,²⁴ post-market management of cybersecurity in medical devices²⁵ and the establishment of the AAMI Device Security Working Group whose work program includes the development of a technical report on medical device information security risk management²⁶.

Regulatory/Economic Drivers

The promise of medical device interoperability and electronic health record portability has spurred development in the medical device world and the health IT industries. In the United States, the American Reinvention and Recovery Act provided $2B US to create standards for a national health network that enable the exchange of electronic health records. Even though this program did not focus on how the information was to be collected or how to assure that quality data populated the EMRs, it did provide mechanisms such as the meaningful use objectives, rolled out in several stages, with financial incentives to help drive adoption. Stage 1 and 2 meaningful objectives included requirements for the record demographic and certain vital sign information.^l Stage 3 objectives include additional requirements that encourage medical device manufacturers to make data available for use in populating EMRs.

Illustrating the need for medical device informatics –Examples

The examples highlight the extent of the problem, and the need to address medical device informatics principles in order to develop safe interoperable systems.

Figure 1 illustrates the unintended documentation in the EMR of an artifactual pulse oximeter data change due to the loss of the SpO₂ signal during cuff inflation,²⁷ which results from the ipsilateral placement of the blood pressure cuff and the pulse oximeter finger sensor. Note that the single low saturation value shown in the EMR includes data from a time interval in which data were lost and as such did not accurately reflect the clinical state. Additionally, although a desaturation is apparent, there is no suggestion of the underlying cause. The artifactual desaturation could lead to a misdiagnosis and additional clinical evaluation. The invalid pulse oximetry value was acquired from the oximeter and recorded independently of other measurements in the EMR without access to the time of the noninvasive blood pressure cuff inflation/deflation. These recorded values lack the state and context (meta-data) of the measurement and their data set is incomplete in the EMR. Cuff inflation status information should be communicated via its EDI, so that the pulse oximeter can be programmed to ignore data generated during cuff inflation.

Figure 1.

Illustration of the unintended documentation in the EMR of an artifactual pulse oximeter data change due to the loss of the SpO₂ signal resulting from the inflation of a blood pressure cuff on the ipsilateral arm to which the pulse oximeter finger sensor is placed. From the upper image, an EMR screen capture, a single low saturation value circled in red can be observed whereas all of the other saturation values are all in the 90s. From the lower images one can observe (a) the baseline oxygen saturation of 96% and a good quality pulse oximeter photoplethysmographic waveform (the lowest tracing on the screen); (b) the loss of pulsatility of the pulse oximeter waveform during blood pressure cuff inflation indicates a loss of blood flow to the fingertip; and (c) the onset of blood flow return to the finger evidenced by the onset of pulsatility and the output of an invalid calculation of SpO₂ performed during a period of instability of the measurement of SpO₂ in the finger. (Images courtesy of JM Goldman, MD and William Driscoll, Director of Perioperative Clinical Engineering & Anesthesia IT Systems at Massachusetts General Hospital)

Figure 2 illustrates the failure to record the saturation nadir of a transient event due to data sampling methodology and time resolution of data recorded. This sampling mismatch demonstrates the limitation of using the EMR as a high-fidelity data repository. The need to provide a more complete patient record with access to waveforms and images has long been recognized^28,29. The recording of physiologic waveforms in the EMR³⁰, or recording relevant waveform features in the EMR³¹ at the time of the lowest value in the last 60 seconds could help remedy this problem. Addressing this type of problem would require configuring the recording of the data as a function of its purpose. The respective device standards could include requirements so that devices such as pulse oximeters could be more context sensitive. For example, many devices can determine and transmit the sensor type via the device’s EDI. If included in the EMR, these meta-data data would be useful for clinical care and forensic analysis.

Figure 2.

Illustration of a failure to record the lowest saturation of a transient event in the EMR due to data sampling methodology, data averaging of the device ‘s data output, and EMR data resolution. (a) The upper image from the EMR shows the SpO₂ values (as vertical blue ticks) at one minute intervals. Examination of the depth of these ticks illustrates only SpO₂ values in the high 90s.(b) The lower image from the patient monitor shows the occurrence of a low SpO₂ alarm event at 14:07 (2:07 PM) (value circled red) with no evidence of an 84% SpO₂ value in the upper image. (Images courtesy of JM Goldman, MD)

Figure 3 illustrates the possible saturation values due to the uncertainty in when a signal is sampled and transmitted to the EMR. This simulated pulse oximeter saturation curve depicts a transient desaturation, typical of sleep apnea³² or manual intervention of airway patency in an anesthetized patient³³. Missed transient desaturation is of particular concern in the neonatal population ³⁴ where desaturation rates exceeding 4.3% per second have been documented during isolated apneas³⁵. An additional contributor to clinical measurement uncertainty is potentially undocumented pulse oximeter averaging algorithm behavior which can “smooth” transient saturation changes. In addition to recording waveforms or waveform features in the EMR, the availability of the averaging algorithm’s filter settings should also be transmitted via the EDI, to support improved clinical interpretation and applications such as smart alarms.

Figure 3.

Illustration of possible values of oxygen saturation recorded in an EMR due to variations in the timing of the data sample. The nadir of this waveform is at 70% and depending on where the sample is taken the recorded SpO₂ may be between the nadir or 70% and the 98% level. Additionally, signal averaging is often performed as data is exported from the device. To the EHR (Images courtesy of JM Goldman, MD)

Figure 4 illustrates an algorithmic error (e.g. improper pulse counting) that leads to incorrectly recorded data and false alarms stored in the EMR thereby highlighting the need to store waveform data to evaluate the event later. Only observation of these aberrant waveforms would lead to the proper conclusion that the paroxysmal tachycardia, which would, if real, be a cause for concern, was an artifact. Interoperable solutions, driven by requirements in the respective device standards, that can effectively address this issue include assuring the time synchronization of the clocks of the respective devices to allow data fusion with signals such as the electrocardiogram (ECG) (e.g. pulse rate from pulse oximeter and heart rate from ECG) and contextual awareness of the clinical environment and patient to be able to better assess the likelihood of an algorithmic error ³⁶.

Figure 4.

Illustration of an error in a pulse oximeter’s pulse rate calculation leading to incorrect data recorded in the EMR. Each monitor image (figures a and b) shows two ECG leads, the pulse oximeter photoplethysmogram and computed values for heart rate from the ECG (topmost), blood pressure values (NBP) and pulse rate and oxygen saturation (SpO₂). Data from this anesthetized immobile patient showing atypical photoplethysmograms. (a) Shows values for heart and pulse rate of 69 and 79 beats/min, respectively. (b) Shows values of 60 and 170 beats/min, respectively. (c) The EMR green dotted trend line shows abrupt changes in pulse rate. Note the stability of the ECG-derived heart rate compared to the pulse oximeter-derived pulse rate, supporting an algorithmic etiology for the pulse rate instability. Waveform data is not stored in the EMR, inhibiting post-hoc analysis of the cause of the rate discrepancy. This data supports the need to log time-aligned data in a clinical black box recorder for forensic analysis. (Images courtesy of JM Goldman, MD)

Figure 5 illustrates the need to record meta-data to differentiate valid clinical events from artifact. In this case, ECG filter settings are shown to influence clinical interpretation ³⁷ due to the improper behavior of a filter algorithm. When the ECG data are algorithmically interpreted, this interpretation may be erroneous without knowledge of the filter setting. The algorithm should identify the flipped T wave, and present the information to the clinician along with the filter setting.

Figure 5.

Inverted T waves (red circle) caused by MAXIMUM ECG filter setting artifact. (a). The right hand portion of the tracing (b) reveals the return of a normal T wave (red circle), once the filter setting was changed to MONITORING. (c) The menu of available options for the ECG filter are shown. The arrow and green spike indicate where the filter was manually changed to demonstrate the effect. If the ECG was not analyzed with filter setting data, it would not be possible to relate the spurious inverted T wave to the filter setting. This example illustrates the need to record meta-data describing ECG filter settings to enable the analysis of spurious data. (Images courtesy of JM Goldman, MD)

Recommendations

A consistent view of which data and functions a medical device can contribute in an interoperable system must be shared across stakeholders and embodied in a device model. This view should include both an overall architectural framework for interactions between components of the system and an accessible data structure of each component representing the capabilities and current state (i.e. device model). As such, the system must be designed with the intended uses in mind. A consistent view requires cooperation among stakeholders and a robust, transparent process for the capture and definition of the biomedical device informatics models under the auspices of a formal organization. These efforts may be hampered by the failure to have a consistent view among stakeholders; and the lack of agreement on the intended use and use environments.

Organizational structures that promote cooperation among manufacturers with respect to medical device interoperability, as well as provide vendor-neutral interoperability testing services can help accelerate and ease the transition to safe and effective interoperable systems. Regulators and governmental policies can help encourage this coordination but these efforts may be complicated by competing SDOs, national rivalries, and politics.

It is critical that robust and comprehensive clinical scenarios be considered when developing what information should be communicated and how the medical device should function given the interactions enabled by its interface. The medical device standards to date capture information considered basic to each medical device’s essential performance (e.g. pulse oximetry, ventilator, and respiratory gas monitor) (Table 3) as deemed by the participants in the standards development processes. These standards usually require that this information should be available in either the instructions for use or technical description. The inclusion in device standards of medical device informatics principles, device and data models, and other information important for interoperability has begun, and manufacturers’ continued adoption of this approach is imperative to support clinical system innovation. Manufacturers need to base their development on robust clinical scenarios and should be cognizant of the need to match the scope of the scenarios with the intended applications in order to avoid emergent hazardous situations.

Table 3.

Selected Particular Medical Device Standards and Examples of Basic Information Reported

Medical Device	Relevant Particular Standard	Examples of Basic Information Reported or Essential Performance Requirements
Pulse Oximeter	ISO 80601-2-61	Default averaging interval, alarm settings
Critical Care Ventilator	ISO 80601-2-12	Alarm limits for oxygen level, airway pressure, expired volume
Respiratory Gas Monitor	ISO 80602-2-55	Accuracy, alarm settings

The use and development of integrated standards and standard families can allow a consistent understanding of devices/technology across the lifecycle of a medical device (i.e. development to deployment to end of life)³⁸. Standards are needed to guide medical device life cycle activities for all stakeholders (e.g. developers and users) for interoperable platforms and the applications that run on them. This is a challenging activity because it aims to control the scope and activities of platform developers, and components used in and applications that run on the platform.

Conclusions

As the role of medical device informatics increases and the realization of the importance of interoperable medical devices become widespread, the impetus to explicitly demonstrate how to safely manage the range of possibly interconnected medical devices grows. A consistent and shared view of a medical device’s capabilities as embodied in a device model standard is critical to achieving a safe and effective interoperability. Shared understanding of clinical scenarios and their context are needed to identify elements that support safety. Interoperability is like a lock and a key designed and implemented to reliably work together. Better mechanisms for improved coordination among SDOs such as road maps or blueprints need to be implemented to achieve interoperability, safety, and minimal duplication of effort. These maps can illustrate how both safety and informatics are handled, what needs to be developed and widely disseminated with the role of each stakeholder (SDO, test laboratory, manufacturer, regulator, purchaser, and user) explicitly and clearly defined. Organizational structures to promote cooperation among manufacturers and medical device users need to be recognized, funded, and staffed. In today’s highly interconnected world, a diverse group of people is needed to develop standards: clinicians for the medical aspects, engineers for the basic safety and performance aspects, and informaticists for the communication and nomenclature issues.