Trusted Composition of Internet of Medical Things over Imperfect Networks

Abstract

The Internet of Medical Things (IoMT) represents a specialized domain within the Internet of Things, focusing on medical devices that require regulatory approval to ensure patient safety. Trusted composition of IoMT systems aims to ensure high assurance of the entire composed system, despite potential variability in the assurance levels of individual components. Achieving this trustworthiness in IoMT systems, especially when using less-assured, commercial, off-the-shelf networks like Ethernet and WiFi, presents a significant challenge. To address this challenge, this paper advocates a systematic approach that leverages the Architecture Analysis & Design Language (AADL) along with Behavior Language for Embedded Systems with Software (BLESS) specification and implementation. This approach aims to provide high assurance on critical components through formal verification, while using less-assured components in a manner that maintains overall system determinism and reliability. A clinical case study involving an automated opioid infusion monitoring IoMT system is presented to illustrate the application of the proposed approach. Through this case study, the effectiveness of the systemic approach in achieving trusted composition of heterogeneous medical devices over less-assured networks is demonstrated.

1. Introduction

An Internet of Things (IoT) is a collection of inter-connected programmable things with the ability to collect and exchange data [1]. Depending on the application domain, the things may include anything ranging from temperature sensors, cameras, smart phones, home appliances, cars, to medical devices, and so on. IoT systems combine functions of individual devices, communicating over a network, to perform operations impossible with individual devices. Such integration of heterogeneous things enables access from anywhere, anytime, and by anything through networks that span from Body Area Networks (BAN) to networks stretching across the globe.

The term “Internet of Medical Things” (IoMT) refers to a composition of medical devices, applications, and healthcare IT systems that are connected through computer networks. Medical devices equipped with interoperable interfaces along with the communication network form the basis of IoMT. Under the purview of IoMT, medical device composition extends data sharing for electronic health records [2,3] with therapeutic medical devices [4,5]. The application of IoMT to control patient therapy has regulatory requirements in most countries where simply storing patient monitoring in electronic health records does not.

The safety and effectiveness of IoMT systems requires both the correct functionality of individual devices and their communication with one another. Different wired and wireless technologies and protocols establish the network that provides communication between the medical devices. Common networking technologies include cellular networks (LTE, 3G, 4G, 5G, etc.), local and personal area networks (WiFi, Bluetooth), low-power wide area networks (LoRaWAN), and mesh networks (Zigbee, RFID). As non-regulated, commercial-grade networks are mostly used for availability and cost effectiveness, composition of IoMT must accommodate unreliable communication, yet still be at least safe.

A network used for IoMT may become unreliable as a result of connecting devices from various manufacturers interacting in heterogeneous environments [6]. Vulnerabilities related to security, privacy, and confidentiality present in the individual devices also affect the integrated network. Several studies, like [7,8,9], have explored different trust issues in IoMT systems. Even correctly working networks can lose packets due to contention by wire or radio, and devices can be disconnected deliberately or inadvertently.

The existing literature on the composition of medical devices for IoMT system design mostly focus on data and device interoperability assuming a secure and trusted network. Studies like [2,4,10] typically presume a trustworthy and reliable communication network when considering the safe interoperability of medical devices for application platforms and integrated clinical settings.

In the United States, safety-critical devices are regulated as Class II (i.e., infusion pumps) or Class III (i.e., implanted cardiac defibrillators). Such devices require controlled and documented designs using medical-grade components, which have stringent tracing and reporting requirements. These requirements drive up medical device costs, exacerbated by liability insurance if patients are harmed. This paper describes the means of using high-quality, yet commercial-grade, networks to achieve medical-grade safety of IoMT.

The trusted composition of IoMT aims to achieve high assurance of the system as a whole, even though certain components of the system may have lower assurance. Therefore, if we cannot verify that every execution is correct (as we can with rigorous formal verification), we can at least verify that each particular use of commercial-off-the-shelf (COTS) software and hardware is correct using loop-back. Every message is looped back to the sender to be compared with the original. If it does not match, or does not arrive in time, the sender can take other action to assure safety. In this case, an audible alarm to alert a healthcare provider that high assurance of correct interaction of interconnected medical devices has been lost.

1.1. Contributions

The major contributions of this study are as follows.

• We present a systematic approach for achieving high assurance in IoMT systems by integrating high-assurance software with lower-assurance counterparts, thereby ensuring overall system reliability and safety.
• We demonstrate the application of Architecture Analysis & Design Language (AADL) in facilitating the trusted composition of medical devices within IoMT systems over imperfect networks. Specifically, we address uncertainties related to the timely and reliable exchange of information among devices on a communication-to-communication basis.
• We illustrate the use of the Behavior Language for Systems with Software (BLESS) for behavior specification, implementation, and verification of an IoMT system consisting of pulse oximeter, respiration monitor, patient-controlled analgesic (PCA) pump, and a control application, communicating over a network.

1.2. Outline

A summary of the related work is provided in the following section. The relevant background is detailed in Section 3. Section 4 presents clinical use case of an IoMT for system of monitoring of the patient-controlled opioid infusion. Section 5 describes the structural modeling of the clinical IoMT, while Section 6 details the behavior specification with BLESS properties. Behavior implementation using BLESS annex subclause is presented in Section 7. Section 8 discusses behavior verification conditions, and Section 9 covers the behavior correctness proof. Section 10 discusses the importance and effectiveness of the advocated design principles, and Section 11 concludes the study.

2. Related Work

Several studies explore the integration of medical devices for IoMT systems from different perspectives. For example, Jayavel et al., investigated various security vulnerabilities [11] and possible solution for IoMT thread scenarios. A thorough analysis of the advancement and development of IoMT is provided in [12], and the IoMT application along with enabling technologies for different deployment domains is reviewed in [13]. IoMT literature is also examined in [14] for the purpose of developing a smart healthcare system for early diagnosis and spread prevention. Investigation of the IoMT requirements, and challenges with respect to Healthcare 4.0, are also reported in [15]. A three-layer design framework for Healthcare Internet of Things (H-IoT) networks is provided in [16]. Important supporting technologies for IEEE 802.11 wireless real-time communication protocol [17] are also listed, along with the QoS requirements.

Virtual integration for medical device interoperability is presented in [5]. A medical device integration approach based on the IoT is described in [2]. Common features of the devices and a single protocol for data integration are discussed. In [4], Arney et al. provide a model-driven approach to the design and validation of closed-loop medical device systems. A considerable number of studies, like [18,19,20], have explored security and sustainability perspectives in the design of IoMT systems. Different Artificial Intelligence (AI) and Blockchain-based design techniques, for effective communication among medical devices and data analysis, are investigated [21,22,23]. Ding et al., in [24], present a multi-mode medical data transmission approach based on the Industrial Internet of Things (IIoT). Design of an IoMT-based healthcare monitoring system is presented in [25], while an ontology-based service for composition and interoperability of medical devices is investigated in [26].

The related studies described above generally assume a dependable and trustworthy communication network when addressing the safe interoperability and architectural specifications for medical device application platforms and integrated clinical environments. However, our study adopts a more realistic approach for the composition of medical devices, and takes into account the unreliability of the communication networks. Such imperfect networks can further intensify the challenges of security vulnerabilities and network disruptions. Our approach of achieving trusted composition in IoMT systems ensures high assurance in essential functional components while accommodating lower assurance communication infrastructure.

3. Background

The Architecture Analysis & Design Language (AADL) is SAE International standard AS5506D, and was created for systems engineering of cyber-physical systems [27]. AADL has well-defined semantics for components and their composition. In particular, AADL component types describe everything visible from outside the component (features, ports, parameters, and accesses), while component implementations describe their internals. Each component type may have several component implementations. Component implementations may be composite components containing subcomponents and connections between them, or may be hardware and/or software not further partitioned.

In AADL, logical architectures (software) are modeled with process, data, subprogram, thread, and thread group components. Process components model the protected memory space shared among thread subcomponents, which model active software which can issue and respond dynamically to events. Data components model types, persistent values directly accessible by multiple threads. Subprogram components model procedures and functions, which must be invoked by threads or other subcomponents.

Physical architectures, in AADL, are modeled with processor, memory, bus, and device components. Hardware that executes software is modeled with processor components. Memory components model data storage. Device components model other physical entities like actuators and sensors or custom logic. Bus components model the physical connections (i.e., wires) between execution platform components.

AADL also provides system components to model composition of logical and physical components, and abstract components to model interfaces without further elaboration. The Open Source AADL Tool Environment (OSATE) [28] is an IDE with analysis tools built on Eclipse to implement AADL for the modeling and analysis of real-time embedded systems.

The core AADL standard only provides support for structural modeling of embedded computing systems, and nothing related to detailed behavior of the software and physical processes which are controlled by the software can be modeled. The Behavior Language for Embedded Systems with Software (BLESS) is an annex sublanguage of AADL that augments the core architecture language to define specification and behavior implementations [29]. A BLESS plugin to OSATE allows program development and transforms programs with proof outlines into deductive proofs.

BLESS annex sublanguage uses five domain-specific languages (DSLs) edited with a plugin extension to OSATE. Each DSL is used in AADL subclauses, libraries, or properties. An Assertion language to make assertions (statements of fact), a Typedef language to define types and units, a Unit language to specify measure units, a State Machine language to express thread behavior, and an Action language to express imperative control-flow computation.

The BLESS proof assistant transforms program proof outlines into deductive proofs, given human selection of proof tactics. For more details, refer to the BLESS reference and proof assistant guide [30].

AADL facilitates system engineering to minimize problems discovered during systems integration when they are most costly to remedy. Architecture-Centric Virtual Integration (ACVI) is a design methodology for using AADL to preclude system integration issues [31]. ACVI was adapted for use to compose interoperable medical devices as medical device virtual integration (MDVI) in [5]. With MDVI, systems engineers use AADL’s property mechanism to attach assertions (predicates or expressions) to component features, expressing what is guaranteed to be true (for outputs) or assumed to be true (for inputs). Connections between features give rise to assume-guarantee contracts, which can be formally verified before the components are designed. Additionally, components may have invariants, much like loop invariants. Invariants for composite components are implied by invariants of their subcomponents.

4. Clinical Example System

To demonstrate how the trusted composition of IoMT may be achieved across an imperfect network, a clinical use case is presented in this section, and will be used throughout the paper. The use case involves automated monitoring of a patient-controlled opioid infusion after a surgical procedure. As depicted in Figure 1, the patient is connected to a respiration monitor to measure breathing rate, and a pulse oximeter to measure blood oxygen (SpO2) and heart rate. In order to administer opioids for pain management, the patient is attached to a patient-controlled analgesic (PCA) infusion pump through an infusion, usually set into a vein on the back of a hand. With a PCA pump, a patient receives opioid infusion at a basal rate, but can also request an additional bolus by pressing a button connected to the PCA pump. The typical PCA pump operates as a stand-alone device.

Overdoses are possible, even with the built-in hazard mitigation. One of the main causes of these overdoses is the PCA pump’s ignorance of the patient’s vital signs, which are tracked by devices like a pulse oximeter and respiration monitor. When the monitoring devices do not communicate with the PCA pump, infusion may continue even if the patient’s health is entering respiratory depression.

Several studies have investigated the integration of medical devices in a closed-loop with a controlling application to coordinate among the monitoring devices and the PCA pump [4,5]. Opioid infusion can be reduced or halted based on vital signs monitored by devices like a pulse oximeter or respiration monitor. However, these studies assume devices communicate through a perfect communication network. The IoMT-based automated opioid infusion system we are considering also takes into account the fact that there is a potential for data loss, unauthenticated access, and information delay due to imperfect communication networks.

5. Structural Modeling Using AADL

The goal of trusted composition of IoMT is to attain a high level of assurance within the system, acknowledging the potential presence of certain components with lower assurance. This goal is pursued by prioritizing high assurance for safety-critical components of the system and then integrating lower assurance components in a manner that upholds the overall system’s safety.

Figure 2 shows the top-level AADL model of the clinical example use case explained in the previous section. This IoMT-based automated monitoring of opioid infusion, modeled as an AADL system SysIoMT, is composed of four sub-systems and a communication network. Each system is connected to an imperfect communication network, which is modeled with an AADL virtual bus. A Patient is modeled as an abstract component. Alarms due to patient vital signs (low heart rate, respiration rate, or blood oxygenation) and warnings that assurance has been lost are sent to a Nurse_Station for human intervention. High assurance for the system as a whole is achieved by loop-back communication between formally verified threads. Although any single message will not be assured, when the sender receives a correct copy of its message back, it is assured that these two messages (original and confirmation) have been performed correctly. Pairs of connections using loop-back are shown in red in Figure 2.

Figure 3 shows the containment hierarchy of all components in the model plus bus access connections. Formally verified components have a light green background color; less-assured components, have a light yellow background. The Respiration_Monitor component models the respiration monitoring system attached to the patient for monitoring the respiration rate. It determines respiration rate from a respiration sensor usually strapped around a patient’s chest. If the respiration rate is lower than the minimum respiration rate, Respiration_Monitor sends RM_Alarm(true) to the control application Coordinator, otherwise it sends RM_Alarm(false). The RespirationMonitor then waits for message confirmation response, either RM_Alarm_Echo(true) or RM_Alarm_Echo(false). If the response is not received within the specified time limit (indicating a delay or data loss) or the received response is different from the sent notification (indicating message corruption), the Respiration_Monitor sends a lost confirmation signal through the Lost_Confirmation outgoing event port to the Nurse_Station. The Respiration_Monitor can also make a sound indicating a low respiration rate alarm or lost confirmation.

The patient’s heart rate and blood oxygenation (SpO2) are monitored by the pulse oximeter, which is modeled by the Pulse_Oximeter system component. The Pulse_Oximeter receives values of the SpO2 and heart rate from the pulse oximeter sensor attached to the patient body. Through the PO_Alarm outgoing event data port, the Nurse_Station is alerted if any of these two parameters falls below minimum limits. Additionally, the Coordinator also receives the alarm. Next, the Pulse_Oximeter waits at PO_Alarm_Echo incoming event data port for the confirmation response from the Coordinator. Nurse_Station is notified through Lost_Confirmation outgoing event data port if the response is not received within the allotted time limit.

The Coordinator system component represents the control application executed by a processor on the network (not shown). The Coordinator notifies the PCA_Pump to reduce infusion to the minimal keep-vein-open (KVO) rate when it receives alarm signals from the Pulse_Oximeter or Respiration_Monitor through PO_Alarm or RM_Alarm, respectively. The acknowledgments are sent to Pulse_Oximeter and Respiration_Monitor through PO_Alarm_Echo and RM_Alarm_Echo ports. Nurse_Station receives notification through Lost_Confirmation outgoing event data port if the response is not received within a specified time frame or does not match the notification.

PCA_Pump models the PCA pump used to infuse drug into the patient. Because patients respond to opioids so differently, a steady basal rate of drug flow can be augmented by a patient-requested bolus by pressing the bolus request button. This puts the patient in-the-loop for their pain management. Too much opioid can cause respiratory depression, which may lead to brain damage or death.

Nurse_Station system models the nursing station with human caregivers. It receives alarms and lost confirmation notifications on Patient_Alarm and Patient_Lost_Confirmation ports, respectively. Modeling the detailed functionality of the nursing station is beyond the scope of this study.

When PCA_Pump receives Pause_Infusion(true) from the Coordinator, it reduces infusion to a KVO rate until it receives Pause_Infusion(false) to resume basal rate infusion. Every message received on Pause_Infusion is sent back on Pause_Infusion_Echo.

As shown in Listing 1, the BLESS invariant << IS_SAFE() >> in the properties section of the SysIoMT system type specifies the main safety property of the systems to be proved correct. Invariant IS_SAFE() expresses that in the event that the heart rate, SpO2, or respiration rate fall below the minimal threshold, the pump infusion will be adjusted to the KVO rate or will be halted. Section 6 provides further details on the assertions and Section 9 presents the proof details of this invariant.

Listing 1. System type for IoMT system-of-systems.

Listing 2 presents a partial specification of IoMT system implementation classifier. The subcomponents section of the SysIoMT.impl (system implementation) defines contained subsystems, while the connections section specifies the appropriate connections between them. Connections are functional communication pathways allocated to physical components, which actually transmit messages by Actual_Connection_Binding properties.

Listing 2. A partial specification of the IoMT system implementation.

6. Behavior Specification Using BLESS Properties

Behavior of an AADL component can be completely expressed by BLESS::Assertion and BLESS::Value properties on its ports and a BLESS::Invariant property of the component as a whole.

BLESS::Assertion properties are predicates defining what is true about the value sent or received by a port. Similarly, BLESS::Value properties are expressions what is true about values sent or received by a port. Outgoing ports guarantee what is true about values sent; incoming ports assume what is true about values received. The BLESS::Invariant property of a composite component must be implied by the conjunction of BLESS::Invariant properties of its subcomponents.

Thread component behavior is implemented by a state-transition machine. That the thread’s behavior upholds its specification requires a verification condition for each state and transition. Respiration Monitor system is used for illustration of verification conditions for threads.

Respiration Monitor

As depicted in Figure 4, Respiration_Monitor contains a Respiration_Sensor device to measure the respiration rate and a Respiration_Monitor_Process process (protected address space) which has two threads, Respiration_Monitor_Thread and RM_Communication_Thread.

RM_Communication_Thread models COTS software such as a TCP/IP stack and device drivers. As such, RM_Communication_Thread is less assured. Respiration_Monitor_Thread performs a safety-critical function, so is formally verified with a deductive correctness proof. The type classifier of Listing 3 declares the interfaces, in terms of in and out ports, of the Respiration_Monitor_Thread.

Listing 3. Respiration Monitor thread type.

BLESS::Assertion properties define predicates within << >>, which must match the values of boolean-typed ports. Therefore, port RM_Alarm outputs true when << RM_ALARM() >> holds and false otherwise. Because RM_Alarm is an out port, thread Respiration_Monitor_Thread guarantees its BLESS::Assertion property. Conversely, BLESS::Assertion of an in port is assumed. Connections from out ports to in ports have assume-guarantee verification conditions (further explained in Section 8). BLESS::Value properties define expressions which must match the values sent or received on data ports and event data ports. Port RP_Rate expects a value of type brpm with value RESPIRATION_RATE, which is a ghost variable. Ghost variables represent the actual values sent or received by ports.

7. Behavior Implementation Using BLESS State-Transition Machine

In AADL, component implementations are separate from component types. Multiple implementations of the same component type with distinct identifiers are permitted by AADL. The names of implementations are the identifier of the type classifiers followed by a period, then the identifier of the component implementation. For example, Respiration_Monitor_Thread.impl is an implementation of the thread type Respiration_Monitor_Thread.

Inside a component implementation, a BLESS state-transition machine is written within a BLESS annex subclause. AADL allows definition of annex subclauses with the reserved word annex, followed by the identifier of the annex, the body of the annex subclause between {** and **};. OSATE can be extended with plugins to provide parsers, syntax highlighting, and error markers for an annex sublanguage in the body of an annex subclause. To include a BLESS annex subclause to express thread implementation by a state-transition machine, the annex language name BLESS must be the identifier of the annex subclause.

7.1. Invariant, Variables, and States

Listing 4 shows the assertion, invariant, and variable specification of the Respiration_Monitor_Thread. An assertion defined in the invariant section must be true whenever the thread suspends or dispatches.

The states section declares behavior states, which may have assertions which are true when the state-transition machine is in that state. There are four kinds of states: initial, final , complete, or execution if not otherwise indicated. Execution starts in the initial state and ends in a final state (if any). Computation suspends upon entering a complete state (execution is complete) until the thread is next dispatched. Execution states are transitory.

Listing 4. Repiration Monitor invariant, variables, and states sections.

Local variables that hold persistent values are declared in the variables section. Variable declarations may include an assertion that defines the meaning of the variable.

7.2. Transitions

Transitions have a label, a source state, a transition condition, a destination state and, optionally, an action. Transitions leaving execution states have boolean expression for transition conditions, while transitions leaving complete states have dispatch conditions. Listing 5 shows transitions implementing the Respiration_Monitor_Thread depicted in Figure 5.

Listing 5. Repiration Monitor transitions section.

• Transition go, with empty execute condition being true, changes state from start to run.
• Transition got_rp, with dispatch condition on dispatch, leaves the run state periodically (every 20 s), performs an action, then changes state to check_echo. Its action reads the current respiration rate, sends an alarm (true) if less than the minimum respiration rate, otherwise sends alarm false.
• Transition got_echo, with dispatch condition on dispatch RM_Alarm_Echo, leaves the check_echo state when an event is received on port RM_Alarm_Echo, performs an action, then changes state to run. Its action compares the boolean value of RM_Alarm_Echo with the alarm value sent during the action of transition got_rp, and sends an event out port Lost_Confirmation if different.
• Transition late_echo also leaves check_echo state, and changes state to run after sending an action out port Lost_Confirmation, but only if its timeout dispatch condition is met. The timeout starts when a value is sent from port RM_Alarm. If RM_Alarm_Echo has not been received within RM_Echo_Limit seconds later, the dispatch condition has been met.

Thus, Respiration_Monitor_Thread.impl employs three different kinds of dispatch triggers in its dispatch conditions.

8. Verification Conditions

Verification conditions are theorems that express what must be true for system behavior to meet its specification. Verification conditions are either for correctness of individual threads, or for compositions of subcomponents. Proving all verification conditions for a system constitutes correctness proof of the system.

Of course, verification conditions may be incorrectly generated, or incomplete, which would invalidate a correctness proof. Arguments that the verification conditions are both correct and complete can be found in [30].

Each verification condition (and all other theorems in a correctness proof) are Hoare triples in the form of

$$\ll P\gg S\ll Q\gg$$

where P is a precondition, S is an action, and Q is a postcondition. When there is no action, the verification condition reduces to $P\to Q$.

8.1. Thread Verification Conditions

For threads, a verification condition is generated for each state (except final states) and a verification condition is generated for each transition.

For each complete state, its assertion must imply the thread invariant. The invariant for Respiration_Monitor_Thread.impl is << RA() and MRPA() >>. State run has the the same assertion. So, the verification condition for complete state run is a tautology, as shown in Listing 6.

Listing 6. Verification condition for run complete state.

For each execution state, its assertion must imply the disjunction of the transition conditions of all transitions for which that state is its source.

For each transition, a verification condition is generated as

$$\ll P\wedge b\gg S\ll Q\gg$$

where P is the assertion of the source state, Q is the assertion of the destination state, b is the transition condition, and S is the action of the transition. The verification condition for transition go is generated as shown in Listing 7.

Listing 7. Verification condition for transition go.

Numbers in the square brackets are the line numbers in the program. Within IoMTwin.aadl, line 426 has definition of the start state, and line 427 has definition of the destination state run. The transition go is defined at line 431 without any behavior action.

Transitions leaving complete states have dispatch conditions which makes the transition condition b more complex. The dispatch condition holds when dispatched at time now, and dispatch has not happened since the time-of-previous-dispatch, tops. The precondition for the verification condition generated for got_echo (shown in Listing 8) includes RM_Alarm_Echo@now, which means event arrival at the RM_Alarm_Echo port in the present instant. After which, several “not exists” terms express that no other transition leaving state check_echo occurred since the thread was last dispatched. In some cases, those additional terms are pertinent; here, they are not.

Listing 8. Verification condition for transition got_echo.

8.2. Composition Verification Conditions

The behavior of a system-of-systems, such as the IoMT in our case study, can be proved correct to meet its specifications based on the proved-correct specifications of its subsystems. As a result, verification conditions are generated for each connection implying assume-guarantee contracts among subsystems. Additionally, the conjunction of subcomponents’ invariants must imply the invariant of the system-of-systems.

Listing 9 presents a verification condition generated for connection rm_alarm between Respiration_Monitor and Coordinator subsystems (see Listing 2). In almost all circumstances, the source and destination of a connection have same assertions, hence generating a tautology.

Listing 9. Verification condition for connection rm_alarm.

Verification condition generated for the IoMT system property << ISSAFE() >>, specified in Listing 1, is shown in Listing 10. It states that the conjunction of invariants of subsystems implies the invariant of system-of-systems (IoMT in our case study). For each verification condition and theorem, the Why created: part states the reason for generating this verification condition and the Solved by: part (only in theorems) states the proof tactics used to solve this verification condition.

Listing 10. Verification condition for system property IS_SAFE().

9. Proof of Verification Conditions

Behavior correctness proof requires solving all of the verification conditions generated based on assertion specifications with ports, states, transitions, and behavior actions. The BLESS proof tool produces the formal proof of the behavior correctness as a list of theorems when all the verification conditions are solved. Each theorem is either a tautology, given, or derived from earlier theorems by applying inference rules. Like other interactive theorem provers, the BLESS proof tool requires human intervention to select proof tactics. Complete proof of the SysIoMT requires 332 theorems. Below, we present some of the proof theorems used to solve verification conditions generated for the Respiration_Monitor_Thread, and for the composition of the system-of-systems. Complete proof of the SysIoMT system with all the subsystems, processes, and threads is available as a GitHub repository at [32].

9.1. Thread Verification Condition Proof

Table 1. Respiration Monitor thread verification conditions and theorems.

	Identifier	Verification Conditions	Proof Theorems
States	start	1013	94
	run	1012	93
	check_echo	1011	92
Transitions	go	1014	95
	got_rp	1015	96–131
	got_echo	1016	132–153
	late_echo	1017	154–159

presents verification conditions along with proof theorems generated for each state and transition for Respiration_Monitor_Thread. For example, for complete state run verification condition [serial 1012] (shown in Listing 6) is generated and proof theorem (93) is used to solve it.

Similarly, for transition go, verification condition [serial 1014] is generated and theorem (95) is used to solve it as a tautology. For a relatively complex transition got_echo, verification condition [serial 1016] (shown in Listing 8) is generated, which becomes theorem (153), and is proven by theorems (132) to (152), which are used to solve it. Listing 11 presents a couple of sample theorems for transition got_echo.

Listing 11. First (132) and the last (153) proof theorem for transition got_echo.

9.2. Composition Verification Condition Proof

For the assume-guarantee relationships on connections, the verification conditions (like the one presented in Listing 9) are easily solved as tautologies. In order to show what is true about the IoMT, the system-of-systems is derived from what is true about its subsystems. The compositional verification condition generated for the system property IS_SAFE() (presented in Listing 10) is solved using the three theorems (600), (601), and (602), as shown in Listing 12.

Listing 12. Proof theorems for system property IS_SAFE().

10. Discussion

Suppose a regulator of medical devices asked manufacturers of medical devices using software seeking pre-market approval (PMA) two questions:

• What fraction of the software state space have been tested?
• What evidence is provided that the untested state space will be safe and effective?

Because even diligent testing can only cover a tiny fraction of software state space, the answer to the first question is “minuscule”. Software errors that cause medical device recalls invariably occur in the untested state space—otherwise the error would have been detected and fixed. Because manufacturers can give no evidence for untested state space, regulators do not ask the second question.

A manufacturer using the design principles advocated in this paper could answer thus:

• For the software performing medical function that must be safe and effective, we have formally verified that every possible execution will conform to its safety and effectiveness specification. Here are the verification artifacts as evidence.
• Our design conforms to an architecture that compels components to only interact through well-defined interfaces. By this (and separation kernel enforcement), we ensure that errors in only tested software cannot compromise our formally verified software.
• The only tested software either performs functions that do not affect safety and effectiveness, or are used in such a way that failures are evident so their risk can be mitigated acceptably.

By using these design principles, the extra effort of formal verification can be focused on the small fraction of software that is truly safety-critical, minimizing the cost of formal verification while maximizing its effect.

11. Conclusions

The Internet of Medical Things (IoMT) integrates medical devices, applications, and IT systems through communication networks, enabling comprehensive monitoring and control capabilities. However, this convergence poses challenges, notably security vulnerabilities and network disruptions, due to reliance on imperfect communication networks. Crucially, achieving a trusted composition in IoMT systems involves prioritizing high assurance in critical functional components while accommodating a lower-assured communication infrastructure. Integration of AADL with BLESS behavior specification is investigated to offer a systematic approach to ensure trusted composition of heterogeneous medical devices over such imperfect networks. This approach emphasizes formal verification techniques and a message-confirmation protocol to establish assume-guarantee relationships and enhance safety properties at both individual device and system levels. A case study demonstrates the application of the proposed approach in an IoMT system of a patient-controlled opioid infusion comprising a pulse oximeter, respiration monitor, PCA pump, and coordinator application. Despite the presence of an imperfect communication network, the study illustrates the feasibility of safe and correct information exchange towards a trusted composition. Enhancing trusted composition techniques can improve IoMT system scalability and dependability, ultimately leading to better healthcare delivery. Future work is directed towards applying the proposed approach for trustworthy medical device composition to other IoMT use cases.