Moving Toward Semantic Interoperability of Medical Devices 

John J. Garguilo, john.garguilo@nist.gov

Sandra Martinez, sandra.martinez@nist.gov

Richard Rivello, richard.rivello@nist.gov

Maria Cherkaoui, maria.cherkaoui@nist.gov

Abstract 

NIST researchers are collaborating with medical device 

experts to facilitate the development and adoption of 

standards for medical device communications 

throughout the healthcare enterprise as well as 

integrating it into the electronic health record. NIST 

researchers have developed a tool and corresponding 

electronic representation of an international standard’s 

information model that provides several important 

capabilities leading toward device semantic 

interoperability. We describe our XML schema and tool 

developed which is built upon the medical device 

communication standard ISO/IEEE 11073. Central to 

this approach is a capability of the tool to develop and 

produce implementation conformance statements (ICSs). 

Users execute the tool to produce statements disclosing 

details of a specific implementation and specifying 

features provided by a particular medical device. 

Device ICSs can subsequently be compared and utilized 

across device interfaces to help overcome the semantic 

interoperability problem that is so prevalent today and 

has prevented proliferation of plug-and-play 

interoperable solutions. 

1. Introduction 

In a recent survey conducted by Healthcare Information 

and Management Systems Society (HIMSS)[1], the 

respondents identified “cross enterprise sharing of patient 

care device data” as one of their highest priorities. Goals 

established to meet this priority include shortening decision 

time, increasing productivity, minimizing transcription 

errors, and investing in and developing ways to correctly 

define and interpret the data exchanged. To meet such 

goals intercommunication among medical devices and 

clinical information systems is necessary as point-of-care 

devices are often the primary source (or destination) of 

patient care information and data. Conformance and 

interoperability testing of medical device data 

communication is essential leading to long term value 

propositions which include: 

• Integrity of data – automatic population of all 

information systems – reducing medical errors, 

• Automating systems to capture clinical data into 

Electronic Health Records (EHRs) thus saving 

time for clinicians, 

• Improving agility of enterprises to meet varied 

patient loads, 

• Improving life-cycle cost of ownership, 

• Access to patient data across devices and systems 

so custom communication interfaces can be 

eliminated thus allowing for best of breed and 

even plug-and-play devices. 

This paper describes a standards-based schema and test 

tool developed by NIST researchers to assist medical 

device domain experts. Central to this approach is a 

standard information model that represents medical devices 

and Implementation Conformance Statements (ICS) used 

to capture device implementation details by specifying 

exactly which features are implemented. Conformance 

statements, produced by device manufactures and 

implementers, provide an effective way to increase the 

likelihood of communicating data correctly. Data must be 

consistently represented syntactically and semantically for 

the successful interpretation of medical devices over 

varying makes and models. 

2. Background 

The Information Technology Laboratory (ITL) within 

the Department of Commerce’s National Institute of 

Standards and Technology (NIST) is collaborating with the 

International Organization for Standardization/Institute of 

Electrical and Electronics Engineers, Inc. (ISO/IEEE) 

11073 Medical Device Communications and the Integrated 

Health Enterprise - Patient Care Devices (IHE-PCD) 

domain working groups. NIST/ITL is engaged with the 

medical device industry and is developing conceptual 

information-based frameworks and test tools to ensure 

device implementations are conformant to medical device 
standards. This effort ultimately contributes to high 

priority needs to reduce medical errors, promote patient 

safety and provide accurate information into electronic 

medical and health record systems. 

2.1 ISO/IEEE 11073 Standard 

A single communication standard is desirable to address 

the medical device plug-and-play interoperability problem. 

The reality, however, is that several standards were 

developed for specific applications to address the layers or 

levels needed to allow communication between medical 

devices and medical systems. Furthermore, the main 

medical device manufacturers have developed proprietary 

solutions. 

Over the past several years the primary international 

standards development organizations (i.e., ISO, IEEE, and 

the European Committee for Standardization (CEN)) have 

harmonized to avoid competition and work together on a 

single set of standards. The international standard 

ISO/IEEE 11073 Health informatics – Point of care 

medical device communication (here after referred to as 

‘x73’) is intended to enable communication among medical 

devices and healthcare information systems. The x73 

family of standards, while parts are still in draft form, have 

been developed with a high level of international 

participation. The standard is targeted at acute and 

continuing care devices, such as patient monitors, 

ventilators, infusion pumps, ECG devices, etc. x73 is 

comprised of a family of standards that can be layered 

together to provide optimal connectivity for the specific 

devices being interfaced. x73 is based on the International 

Organization for Standardization’s Open Systems 

Interconnection (ISO-OSI) seven layer communications 

model[2]. 

The x73 family of standards is complex and allows for a 

high degree of flexibility in its application. The standard 

defines the information model for specific devices 

including device attributes, value ranges, and access. Data 

(e.g., measurement and state) is modeled using the Unified 

Modeling Language[3] (UML) in the form of information 

objects that can be accessed and manipulated via an object 

access service protocol. 

3. Scope 

The context of a medical device for the work defined in 

this paper is derived from the x73 standard: A device, 

apparatus, or system used for patient monitoring, 

treatment, or therapy, which does not normally enter 

metabolic pathways[4]. The scope of medical devices in 

this context is further limited to patient-connected medical 

devices that provide support for electronic 

communications. Examples of data captured and 

exchanged by devices include communication of 

physiologic waveform data, time critical alerts, and 

open/closed loop control. A key requirement is that the 

semantics of the data which is communicated is not a 

function of the communication method. 

The problem domain spans two primary levels of data 

communication: device and enterprise. The device level 

relates to data captured and emitted via periodic reports 

often many times per minute and aperiodic reports for 

event type information; and the enterprise level which is 

typically synopsis or filtered reports derived at the device 

data level and communicated via observations within 

electronic health records. 

Our objectives include addressing device-level 

conformance leading to interoperability across devices and 

at the enterprise level (to meet IHE-PCD goals). Our work 

attempts to contribute to achieving primary objectives of 

the standard of providing plug-and-play interoperability for 

patient-connected medical devices; and facilitating the 

efficient exchange of vital signs and medical device data, 

acquired at the point-of-care, in all health environments. 

Scope is limited to the identification of upper layer (i.e., 

application) functionality of patient care devices and not in 

describing the syntax and semantics of the communicated 

data stream emitted and received between devices. Device 

functionality regarding time-based exchange of data (i.e., 

asynchronous [non real-time] versus isosynchronous [neartime] versus synchronous [real-time]) is also outside the 

scope of work. 

The term “implementer” represents a device 

manufacturer or vendor while the term “user” represents 

the individual(s) executing the tool described in the 

following sections. 

4. Problem Description 

Schrenker and Cooper[5] present the typical scenario of 

“... the plethora of medical devices surrounding the 

patients in a hospital intensive care unit (ICU). A patient 

connected to one or more vital-signs monitors may also be 

receiving drugs or other fluids under the control of an 

infusion pump. More-acutely-ill patients may have some of 

their physiological processes supported by devices such as 

ventilators – in addition to the monitors and pumps just 

mentioned. And other devices are brought to the bedside 

to address chronic or acute conditions; these would 

include hemodialysis machines and defibrillators. Finally, 

voluminous data records are being created for each patient 

from the output of all these machines. Vital-signs 

measurements, along with any changes in the therapeutic 

regimen, need to be captured in the patient record and 

often communicated elsewhere, such as the pharmacy.” 
They state for two or more interfacing devices to 

communicate that “the devices must be able to understand 

the format and content of the messages they communicate 

to each other; that is, they must speak the same language, 

both grammatically and semantically.”[5] This leads to 

what IHE PCD Technical Framework describes as the core 

of the so-called plug-and-play interoperability problem: 

“In order to achieve semantic interoperability each class 

of device must use the same terminology and data 

organization or modeling for common information.”[6] 

HL7 

Test Messages

X73 

Test Messages

DIM

XSchema

Compare 

Devices

HL7/OBX

Mapping

(XML)

Device UML Diagram

ISO/IEEE 11073

DIM

Part 20101

Nomenclature

Part 10101

ICSGenerator

Figure 1. High level system model 

Standards are vital to the deployment of information 

technologies for interoperable healthcare systems and 

information exchange. However, standards are not enough 

to ensure interoperability. In fact standards are only 

meaningful if implemented in a consistent and correct way. 

To help ensure that implementations adhere to the 

standard(s), requirements must be identified and a 

determination made that the implementation conforms. To 

support interoperability of medical devices, specific details 

about the way definitions of the x73 standard are applied to 

an implementation must be captured. Thus, to increase the 

likelihood of medical device interoperability implementers 

are required to provide specific details about their device 

by declaring statements of conformance. 

Accurately and clearly defined conformance 

requirements together with implementation statements of 

conformance will aid the state of device communication 

standardization, which to date, has not matched the 

proliferation of the telecommunications industry mainly 

because such IT standards “are inadequate to fully address 

the needs of the clinical IT domain, particularly at the 

patient bedside.”[5]

5. NIST’s Approach: Conformance Leading 

Toward Interoperability 

Information models and test tools are being developed at 

NIST to help device manufactures make the determination 

that requirements are implemented according to the 

standard. Conformance testing is a way to determine 

directly or indirectly that relevant requirements are 

fulfilled. Systems which conform to the same standard 

increase the likely-hood that those systems or components 

are interoperable and thus exchange, interpret, and apply 

information correctly and consistently. Defining device 

implementation features based on a recognized standard’s 

information model and naming conventions are a critical 

step to obtaining conformance; moving toward syntactic 

and semantic interoperability within the point of care 

medical device communication arena. 

5.1 Implementation conformance statements 

Implementers provide specific details about a device by 

issuing an Implementation Conformance Statement (ICS). 

The ICS is a form of data sheet that discloses details of a 

specific implementation and specifies which features are 

provided. The ICS provides a consistent means to describe 

device features spanning manufactures or various makes 

and models. ICSs can effectively narrow the scope of 

device interfaces by defining supported features thus 

leading to a reduction (and ultimately elimination) of the 

need to have unique interfaces for each connecting or 

communicating device. Through collaboration with the 

x73 committee, NIST has developed an XML schema and 

ICS generation tool providing device manufacturers a 

systematic approach to define device specialization. The 

result of this approach are ICSs (in the form of tables as 

required by the standard) based on the x73 standard’s 

domain information model and terminology convention 

known as nomenclature. 

While ICSs provide understanding of the details of an 

implementation, they are not sufficient to promote 

interoperability of devices or applications. In addition to, 

or as replacement of the ICS, detailed application or 

functional communication profiles (e.g., medical device 

interoperability profiles) providing more specific 

conformance requirements are needed. Such additional 

specifications or standards are necessary to fully enable an 

implementation or a system using the x73 standard. 

5.2 High level system model 

NIST has developed an XML schema (hereafter referred 

to as XSchema) and a corresponding ICSGenerator tool 

(Figure 1). The XSchema is essentially an electronic 

representation of the x73 standard’s medical device 

information model implemented in the ICSGenerator tool. 

ICSs may be created to specialize scope of implemented 

features supported by a device as intended by the 
manufacturer and defined by, and in, a standard 

representation. ICSs therefore define device functionality 

in an unambiguous manner such that other devices (or 

device manufactures) can clearly interpret the feature 

definitions leading to increased likelihood of device 

interoperability. 

5.3 NIST XML Schema 

The x73 family of standards contains parts based on an 

object-oriented systems management paradigm (objects 

and their interactions) used to describe objects shared 

between devices through a communication link. Part 

10101: Nomenclature defines the set of attributes used to 

name and term information objects and Part 10201: 

Domain Information Model (DIM) of x73 defines the 

overall set of information objects as well as the attributes, 

methods, and access functions which are abstractions of 

real-world entities in the domain of medical devices and 

device communication. This information model is the 

prerequisite for interoperability of medical devices and 

device systems. 

Taking advantage of the object-oriented modeling 

method, an XML schema was developed as a metagrammar for electronically defining the syntactic structure 

and partial semantics of the x73 DIM. The XSchema

addresses the requirements of the standard’s detailed 

specification. The XSchema provides information 

modeling capabilities and maintains the integrity of the 

structure and vocabulary set by the standard. The 

XSchema was augmented to represent the complete UML 

model used by the x73 DIM, including: 

• Object definition, 

• Containment relationship (class instance), 

• Attribute definition, 

• Attribute groups, 

• Behavior definition, 

• Notification definition, and 

• Inheritance among object types. 

Features implemented in the XSchema to satisfy the 

requirements identified in the x73 standard include 

capabilities to: 

• Represent common data types, 

• Ensure DIM object definition (attributes, 

behaviors and notifications), 

• Ensure containment association, 

• Represent attributes/notification/behavior 

inheritance, 

• Represent the service model for communicating 

systems, 

• Ensure object cardinality, 

• Ensure term codes (Managed Objects, attributes, 

behaviors and notifications), and 

• Allow for future extensions of the model. 

NIST developed a tool, called ICSGenerator that is 

based on the x73 DIM. ICSGenerator utilizes the 

XSchema to provide the parsing capabilities necessary to 

assure that manufacturers are defining the information 

required by the x73 standard. Furthermore, manufacturers 

may adopt this public domain XML schema to contribute 

to their own implementation development goals. Adoption 

of the schema into a manufacturer implementation 

information model maintains integrity of the structure and 

vocabulary as defined by the x73 standard. 

Figure 2. ICSGenerator tool screen shot 

5.4 ICSGenerator 

The ICSGenerator[7] tool enables users to define a 

specific medical device implementation and specify which 

features are provided. ICSGenerator characterizes a 

device by the x73 DIM objects it implements. 

5.4.1 Device specialization (DIM XML) 

ICSGenerator processes an XML instance file based on 

the x73 DIM. The XML instance file is validated against 

the XSchema which contains all the managed objects, 

object relationships and associated information. Using the 

ICSGenerator tool’s interface, a user specifies a medical 

device to produce a graphical containment tree 

representation of the device (Figure 2: middle left panel 

showing DIM, Simple_MDS, VMD, Channel, etc.). Each 

object is identified using nomenclature from the standard 
by name, type ID, label, and a reference to the clause in the 

standard where the object is defined. Additional 

information such as restrictions, application guidance, 

attribute access, and value ranges may also be entered 

(Figure 2: upper center panel). Mandatory attributes are 

automatically populated as users dynamically create their 

device containment. 

Capabilities of the tool include adding, removing, and 

updating managed objects, including associated attributes, 

behaviors, and notifications. The tool meets requirements 

established by the x73 DIM by allowing creation of XML 

instance files which are compliant to the x73 standard, as 

validated against the XSchema. Validation against the 

XSchema includes checking constraints such as 

containment relationship, cardinality, object ID, and 

attribution. Post processing the resultant saved XML 

instance files provides users with the capability to produce 

ICS and device comparison reports, generate device object 

UML diagrams, and to map the x73 device defined 

information to HL7 observation message segments (see 

Figure 1). 

Users may describe private and external extensions using 

the tool, however such extensions are denoted (via a color 

code) as outside the standard’s information model (and 

therefore not validated against the XSchema). As device 

capabilities change over time the saved XML instance file 

may be reloaded into ICSGenerator and subsequently 

modified to reflect those changes. 

5.4.2 ICS Reports 

ICSGenerator addresses a key requirement of the x73 

DIM conformance model by producing ICS reports. The 

resultant conformance statements are in the form of tables 

mirroring the standard’s identified templates. Generally, 

the column headers of an ICS table contain the following 

information: 

• Index, which is an identifier (e.g., a number) of a 

specific feature, 

• Feature, which briefly describes the characteristic 

for which a conformance statement must be made, 

• Reference, which is a reference to the definition of 

the feature (may be empty), 

• Status, which specifies the conformance 

requirement (i.e., the requirements for a 

conforming implementation regarding the 

feature). In some cases, the standard does not 

specify conformance requirements, but a 

definition of the status of a particular feature is 

still required, 

• Support, which is filled out by the implementer 

and specifies the characteristics of the feature in 

the implementation, and 

• Comment, which contains additional information 

provided by the implementer. 

A device conformance statement is composed of general 

information, the services supported, the managed medical 

objects (not base classes) used by the implementation 

referred to as the managed object class (MOC), and MOC 

attributes, behavior and notifications. The ICSGenerator

tool allows a user to create seven different ICS reports: 

General, Service Support, Transport, DIM MOC, MOC 

Attribute, MOC Behavior, and MOC Notification. 

• The General ICS contains information specifying what 

versions/revisions are supported by the device and also 

some high-level system behavior definitions. Features 

captured by the General ICS include Conformance 

Deviation, Object Containment Tree, Private and 

External Objects, and Private Nomenclature 

Extensions. 

• The Service Support ICS describes what services are 

implemented in the service model. Only 

communicating devices should supply a Service 

Support ICS. Features captured by Service Support 

ICS include services supported by the device such as 

the “GET”, “SET”, “EVENT REPORT”, “ACTION”, 

“CREATE”, and “DELETE” services. 

• The Transport ICS captures the transport profile used 

by the device. To date, the tool allows conformance 

statements about Infrared Data Association (IrDA) 

cable connected devices to be identified by users. 

Device features supported can be obtained for the 

IrDA link access, IrDA link management, and the tiny 

transport protocols. 

• A DIM MOC ICS contains object information as well 

as specific restrictions about the object 

implementation. 

• The MOC Attribute ICS defines attributes used and/or 

supported as well as corresponding attribute value 

ranges, restrictions for attribute access, attribute 

availability, and information. 

• The MOC Behavior ICS contains all implemented 

object methods that can be invoked by the “ACTION” 

service. 

• The MOC Notification ICS specifies all implemented 

notifications (typically in form of the “EVENT” and 

“REPORT” services) that are emitted by the supported 

objects. 

5.4.3 Comparing Devices 

ICSGenerator provides a methodology to quickly select 

and compare two or more device representations based on 

derived source XML instance files validated against the 

XSchema. Object, attribute, behavior, and notification 

reports are produced documenting common characteristics. 

Refer to the ICSGenerator User’s Guide[7] for criteria 

used to determine what constitutes common objects, 

attributes, behaviors and notifications between devices. 

Resultant comparison reports can be viewed from an 

object characteristic level, including object attributes, 
behavior, and notifications. Comparison reports include 

highlighted commonalities and differences of selected 

device representations. Reports produced using 

ICSGenerator are derived from the standard as 

implemented in the XSchema. The reports serve an 

important step toward semantic interoperability by 

providing implementers a way of determining exactly what 

features are supported across devices thus focusing 

attention on specific functionality and intention. 

Therefore, the desired meaning of the data communicated 

will likely persist between devices and/or be correctly 

integrated into electronic health records. 

5.4.4 Producing Device UML Diagrams 

The ICSGenerator provides the capability of 

automatically producing a UML class diagram describing 

the device data model based on the DIM XML. Thus, each 

device may be specified in a commonly adopted 

representation for modeling software artifacts[3]. This 

capability benefits manufacturers by enabling an easy 

mechanism to create electronic descriptions of a device 

which may be used as an aid in interoperability testing. 

5.4.5 Mapping IEEE x73 information objects to HL7 

observations 

Functionality has been included in ICSGenerator to 

apply device specific information into the Health Level 7 

(HL7) messaging standard used throughout the healthcare 

enterprise. It is anticipated that transformations into orders 

and observations can occur by providing the capability of 

specializing medical devices. Defining device 

containment, information objects, associated attributes, and 

data based on information entered about point of care 

medical devices is necessary to achieve this functionality. 

ICSGenerator is used to produce an XML instance file. 

Post-processing is applied to this file to map particular 

device attributes to observation segments in HL7 

messaging formats. HL7[8] (Version 2.5, chapter 7) 

Observation Reporting (specifically “OBX” segments) 

defines the syntax and coding requirements used for patient 

care device data communications in the IHE-PCD 

Technical Framework. 

HL7 segments produced from the tool may subsequently 

be used to derive HL7 profiles, messages, and test suites, 

further leading to device interoperability and integration 

into healthcare systems. This functionality also contributes 

to the workflow of orders being filled by medical devices 

with resultant data captured in the electronic health record, 

which is a primary goal of the IHE-PCD. 

6. Related Work: Validating Medical Device 

PDUs 

NIST is collaborating with the x73 Medical Device 

Communications working group in developing a test tool 

which validates basic syntax and structure of medical 

device message protocol data units (PDUs) being 

exchanged. Information is initially defined in an abstract 

syntax such as Abstract Syntax Notation One (ASN.1) 

(ISO/IEC 8824) or medical device data language. 

Typically for efficiency in the form of integers, the 

information is then mapped to and interchanged through a 

transfer syntax, e.g., basic encoding rules (BER) or 

medical device encoding rules (MDER). However, 

abstract syntax languages are generally unsuitable for highprecision human understanding, especially of medical 

terms. Objects described in ASN.1, as defined in the x73 

standard, have been converted into XML schema 

definitions. The XML schema definitions will be used to 

validate XML wrapped messages derived from PDUs 

exchanged between medical devices. The NIST prototype 

ValidatePDU tool[7] will flag incorrect syntax and data 

type errors. Future functionality is to include performing 

semantic checking in addition to syntactic checking to help 

ensure that communicating entities can correctly exchange 

and interpret medical device data. Validation of data 

entered by the user into the ICSGenerator interface is 

based in part on the common ASN.1 data types defined in 

the x73 DIM and as used by ValidatePDU. 

7. Summary 

The need for a widely adopted medical device message 

communication standard is essential to the process of 

medical device and system integration. However, use of 

standards alone does not ensure system interoperability. 

Creation of an XML schema and ICSGenerator tool 

provides several important capabilities leading toward 

semantic interoperability of medical devices and the 

information exchanged between those devices. At the core 

of the NIST developed ICSGenerator tool is an 

information model based on an instantiation of the 

ISO/IEEE 11073 domain information model (DIM). The 

tool processes the electronic instance of the DIM described 

in XML and validated against the NIST XSchema to 

graphically represent the DIM containment relationship. 

The tool provides users an easy to use interface to 

manipulate the standard’s information model by adding 

and/or removing objects; including the object’s attributes, 

behavior, and notifications. The abstract representation of 

a device is created by a user, validated by the tool against 

the XSchema, and saved in XML format. The resultant 

XML files therefore define a device which are x73 DIM 

compliant described using the x73 standard’s 

nomenclature. 

The XSchema and ICSGenerator tool promote semantic 

interoperability in several ways. The ability to produce 

ICSs which define in a report format a device’s general, 

service support, transport, and managed medical object 
information is an important contribution helping clinical 

engineers, device manufacturers, and vendors. Device 

conformance statements identifying specific implemented 

features are useful when comparing such devices across 

multiple makes and models. Furthermore, reports showing 

device objects graphically represented in a common 

modeling language (i.e., UML) lead to consistent and 

precise device descriptions more readily available without 

underlying object content information. Together, these 

capabilities enable manufacturer’s to define device 

interfaces in such a way that increase the likelihood of 

interoperating with other device models or manufacturers. 

NIST is working directly with the IEEE Health Informatics 

- Point of care medical device - Domain information model 

- XML schema format working group under sponsorship of 

the IEEE Engineering in Medicine and Biology Society 

11073 Committee (EMB/11073). The proposed NIST 

DIM XSchema project plan was submitted and is under 

consideration for approval by the IEEE New Standards 

Committee (NESCOM). NIST will continue to participate 

with the IEEE working group to move the DIM XSchema

forward as a normative part of the x73 standard 

(specifically P11073-10202 - Standard for Health 

informatics - Point-of-care medical device communication 

- Domain information model (DIM) - XML schema 

format). 

NIST also continues to actively participate with the ongoing work of the IHE-PCD working group to map x73-

based device information into HL7 observation messaging 

formats. Post-processing the ICSGenerator produced 

XML files will directly support testing efforts of 

manufacturers planning to participate in the second year 

IHE-PCD interoperability demonstrations known as the 

“Connectathon” and at the 2008 Health Information and 

Management Systems Society[1] (HIMSS) Conference. 

These demonstrations are a realization of manufacturers 

coming together to exchange medical device data based on 

real-life scenario use cases. This work contributes to 

development of IHE-PCD Integration Profiles and 

Transactions in year two and beyond. This work, in 

conjunction with profile builder tools, facilitates the 

creation of IHE-PCD Integration Profiles from a device 

specialization perspective. In the future, enhancements 

may potentially eliminate the need to use more complicated 

general profile builder tools which work nicely across all 

IHE and HL7 message domains. However, unlike the 

profile building tools, XSchema and ICSGenerator are 

focused on the complex device information model to 

produce device-derived physiologic information 

observations. 

References 

 [1] Healthcare Information and Management Systems 

Society (HIMSS), web: http://www.himss.org, 2007. 

 [2] "Information Technology - Open Systems 

Interconnection - Basic Reference Model: The Basic 

Model, ISO/IEC 7498-1," Geneva: International 

Organization for Standardization, 1994. 

 [3] Object Management Group (OMG), Unified Modeling 

Language (UML), web: http://www.omg.org/uml, web: 

http://www.uml.org, 2007. 

 [4] "ISO/IEEE 11073-10201 Health infomatics - Point-ofcare medical device communication - Part 10201: Domain 

information model," (Institute of Electrical and 

Electronics Engineers Standards Association, Manager, 

Standards Intellectual Property, 444 Hoes Lane, 

Piscataway, NJ 08854, Email: stds.ipr.ieee.org, web: 

http://www.ieee.org). 

 [5] R. Schrenker and T. Cooper, "Building the Foundation for 

Medical Device Plug-and-Play Interoperability," 

MD&DI's Medical Electronics Manufacturing, April 

2001, page 10, web: 

http://www.devicelink.com/mem/archive/01/Spring/MESp

r01_Schrenker.html. 

 [6] "IHE Patient Care Device Technical Framework Year 1: 

2005-2006, Volume II Transactions," Revision 6.0, Trial 

Implementation Version, Copyright 2005-2006: ACC, 

ACCE, HIMSS, and RSNA, 08/15/2006. 

 [7] NIST Medical Device Testing Project Website, web: 

http://www.nist.gov/medicaldevices. 

 [8] Health Level 7 (HL7), web: http://www.hl7.org.