Las Imágenes

When the term “device interconnectivity” is used in the medical domain, its precise defi- nition is rarely made explicit; rather, it is typically understood to mean “interoperability.” Work in the field of simulation theory has led to the proposal of different “types” or “levels” of interoperability, but most recognize at a minimum the distinction between two compo- nents being able to “interconnect” (e.g., use a similar communication protocol, data format, etc.) and to “interoperate” (e.g., shared understanding of assumptions and semantics).

Petty and Weisel (who focus on simulation systems, though we believe their definitions work in this domain as well) discuss composability, which they define as “the capability to select and assemble. . . components in various combinations into valid. . . systems.” They further explain that there are two perspectives from which composability can be understood: the engineering perspective, which focuses on syntactic composability (i.e., “whether the components can be connected”) and the modeling perspective, which focuses on semantic composability (i.e., whether the computation of the composed system is semantically valid”) [20].

Syntactic Interoperability

The primary concern of syntactic interoperability is the connection between two devices, or between a single device and some middleware. Unfortunately efforts in this area have not yet converged onto a single technology or style. Early work, like the first versions of the MDCF, used the Java Messaging Service (JMS) [18], which is an API that describes a peer-to-peer messaging service; JMS has both open-source and hardened commercial implementations [21]. Modern implementations of the MDCF can be configured to use either a purpose-built message-bus provided by MIDAS or the Data Distribution Service (DDS) [19, 22]. Some commercial MAP implementations (e.g., Docbox) use DDS, while others (e.g., Dr¨ager) use a purpose-built web-service framework [23].

were in general well suited to publish-subscribe (pub-sub) architectures. Pub-sub works well because a number of MAP apps may be operating on the same patient at the same time, so allowing multiple apps to efficiently read from the same physiological monitoring device efficiently was a high priority. See, for example, [18] for a discussion of the performance aspects of a JMS implementation of the MDCF in various fan-in and fan-out topologies using a range of message sizes and types. Typical MAP implementations use an explicit invocation style of pub-sub, in that the underlying networking middleware routes messages to particular components, but those components themselves are responsible for implementing handlers for event or message arrival. Another advantage of pub-sub is the decoupling of data producers from consumers [11] (all but a necessity in a compositional plug-and-play system like MAPs), though competing concerns like data privacy and security can, at times, require some level of coupling.

While pub-sub works well for reading physiological data from a number of sensors, it is less straightforward to use in more advanced MAP apps that require device control. Since it is unnecessary (or possibly even inappropriate) to have commands sent from a logic module to a specific device broadcast widely, point-to-point communication is, in these cases, preferable to pub-sub. While it is possible to have per-device topics (a strategy employed by, e.g., the MDCF); one advantage of Dr¨ager’s web-service architecture is the explicit inclusion of point-to-point (discussed in their work as request-response) style connections for private communications and device control [23].

Semantic Interoperability

The issue of semantic interoperability, or the challenge of ensuring equivalency between similar values and concepts across disparate components (e.g., medical devices, app logic modules, etc.), is one best addressed by domain (i.e., medical) experts. To that end, we have looked to relevant medical standards—in particular, IEEE 110732_{—which has two goals: to}

2_{Note that while IEEE 11073 contains specifications for both semantic and syntactic interoperability,}

“provide real-time plug-and-play interoperability for patient-connected medical devices” and to “facilitate the efficient exchange of vital signs and medical device data, acquired at the point-of-care, in all health care environments.” [24]

At a high level, the standard focuses on two topics: nomenclature and the “domain information model” (DIM). As the name implies, the nomenclature sections of the standard give a semantic coding for a range of physiological categorizations (e.g., alerts, body sites, metrics, etc.). The DIM, on the other hand, “is an object-oriented model that consists of objects, their attributes, and their methods, which are abstractions of real-world entities in the domain of. . . medical devices.” [25]. The full family of standards includes refinements for specific device families (e.g., pulse oximeters) and is broadly split into those devices used for personal health and those used at the point of care.

While our examples draw inspiration from—and where possible align with—IEEE 11073, we do not use it outright for two main reasons. First, device interconnectivity is only a part of the full MAP vision, and IEEE 11073 does not include facilities for, e.g., hosting/execution of application logic. Second, and more practically, the standard follows an object-oriented, dynamic discovery style of capability description, which both prevents static knowledge (and thus static analysis) of a system and makes makes the creation of robust application logic more complex. That is, applications will have to be responsible for implementing a potentially large number of code paths, depending on the result of the various dynamic capability queries.