charge them sooner is viewed as a fundamental

means for achieving major cost reductions. In

ANSI/IEEE 1073: addition, an increasingly high percentage (60 –
70%) of in-hospital costs are incurred in the
areas of critical care: the ICU (Intensive Care

Medical Information Unit), OR (Operating Room), and ER

(Emergency Room). These are by far the most
labor intensive areas in hospitals.

Bus (MIB) Historically, nurses in ICUs (and other hos-

pital departments) spend significant portions of
their time writing down data regarding patient
vital signs and infused drugs. The charting of
patient data is viewed as the most tedious part of
M. Glass a clinician’s job. Moreover, data entry processes
based on handwritten notes are haphazard,
prone to transcription errors, and do not
The Medical Information Bus (MIB) represents an include a reliable means for time stamping.
application of networking and information tech-
In such an environment, the person-to-per-
nology for healthcare. The purpose of MIB is to
define a standard means of connectivity between son relaying of patient data, the delays and
critical care bedside medical devices and hospital errors involved in manual transcription, their
host computers. The devices include patient moni- effect on medical decisions, and the resulting
tors, infusion pumps, ventilators, pulse oximeters immense quantities of paper records are unac-
and other devices used in operating rooms, inten-
ceptable. The use of manual patient charting
sive care units and emergency rooms.
MIB addresses the unique needs of implement- results in hundreds of page patient records. In
ing data communications in the acute care envi- practical terms, this does not provide a viable
ronment. These challenges include: (1) the means of supporting rapid clinician interven-
absolute need to guarantee patient, user and tion.
equipment safety; (2) the need for complete stan-
Inevitable inaccuracies lead to mistakes in
dardized plug-and-play operation with no user
intervention; (3) the need to provide a framework diagnosis and treatment. A critical example of
for an expandable data language; and (4) the need the need for automatic data capture is in the
to provide open system interoperability to hospital prevention of Adverse Drug Events (ADEs).
wide information systems. Studies by Brigham and Women’s and LDS
MIB is defined by the emerging family of
Hospitals have shown that each ADE adds an
ANSI/IEEE 1073 standards. The 1073 family fol-
lows the ISO OSI 7-layer model. The first two doc- average of 4.6 days to length of stay, with a cost
uments in this family, the 1073.3.1 Transport of $6000 [1].
Profile and the 1073.4.1 Physical Layer for Cable As a result, it is seen that the migration to
Connected Devices define lower layer plug-and- automated data capture (ADC) and automated
play operation for a bedside subnetwork. They
data collection is imperative. ADC is faster,
were approved as IEEE standards in December
1994; as ANSI standards in August 1995; and more efficient, and less error prone than man-
went out for ‘red cover’ pre-ballot procedure as ual data capture. Providing doctors with real
CEN European standards in April 1998. time access to automatic, comprehensive, com-
The upper layer MIB standard documents uti- puterized patient data is a means for enabling
lize mOSI, a highly streamlined subset of the full
major improvements in treatment. Automatic
OSI upper layers protocol, define optimized
encoding rules, and the Medical Device Data data capture and data collection are emerging as
Language (MDDL), an expandable framework increasingly important strategic elements for
based on object oriented technology. The MIB improving the quality of treatment in acute care
upper layer standards leverage a great deal of the while lowering costs.
work of the CEN VITAL committee in defining the
information models and nomenclature for parame-
ters, waves and alarms for specific device types.
Future 1073 standards will define internetworking
between local bedside data collection hubs and BACKGROUND
hospital wide networks.
In 1982, professionals from several leading
Mike Glass
Technical Marketing Manager medical institutions with strong medical infor-
LinkTech, Incorporated matics programs came together to work on
Lower Layers Chair
IEEE 1073 (MIB) Committee INTRODUCTION requirements for acute care data communica-
30 Orville Drive tions. These institutions included LDS
Bohemia
NY 11716, USA
Hospitals are currently under great eco- Hospital, Salt Lake City, Utah; the University
Email: nomic pressure to lower costs while improv- of California Medical Center, San Diego,
glass@[Link] ing patient care. Developing methodologies California; Cedars-Sinai Medical Center,
LinkTech Web Page:
[Link] to get patients healthier faster in order to dis- Beverly Hills, California; Phoenix Baptist
Health Informatics Journal (1998) 4, 72-83
ANSI/IEEE 1073 73

Hospital, Phoenix, Arizona; and Mayo Clinic, for guiding treatment by a bedside or remote
Rochester, Minnesota. clinician, and may result in alarms at the bed-
The goal of this group was to automate side and/or remote locations.
patient charting from bedside medical devices to Clinical pathways. An important emerging
eliminate the need for nurses to perform man- use of automatically captured data is in the
ual charting. In addition, members of this group development and deployment of computer-
were looking to use the automatically captured ized clinical pathways. Clinical pathways pro-
data for quantitative analysis, and eventually to vide a means for achieving continuous quality
allow computers to make recommendations for improvements by standardizing on patient
patient treatment. An outcome of these meet- treatment regimens. The improvements real-
ings was a proposal sent to the IEEE to form a ized lead to reduced length of stay and
committee on the Standard for Medical Device improved patient outcomes. In the develop-
Communications. In 1984, this proposal led to ment of these treatment protocols, clinicians
the formation of the IEEE 1073 Medical can determine subtle cause and effect rela-
Information Bus (MIB) committee [2]. tionships, and how these vary across subpop-
ulations of patients [1].
Alarm processing. Automatic data capture
will enable more comprehensive alarm moni-
toring systems than is offered in current sys-
APPLICATIONS OF ADC tems. This includes remote setting of alarm
setpoints; reliable, low-latency remote alarm-
The use of automatically captured data in
ing; and resetting of alarm indicators. In nurse
critical care areas of hospitals enables the inte-
call systems, alarm conditions may be com-
gration of real time patient data from bedside
municated and enunciated by means of vari-
medical devices into clinical information sys-
ous visual and audible methods, including
tems and clinical data repositories. ADC is a
nurses’ station terminals, wall displays and
key element in the creation and maintaining
pagers.
of paperless electronic patient records. Some
Closed loop control. An important future use
of the uses of this data include computerized
of ADC is in applications involving closed
patient records, alarm processing, and sched-
loop control. Examples of remote device com-
uling and usage modeling for devices.
puter control include infusion device control
Data logging. The most basic use of automat-
(e.g. for control of blood pressure), and venti-
ically captured data falls into the general cate-
lator settings control.
gory of data logging applications. An example of
Interfacing to remote systems. In many ADC
data logging is an infusion device data concen-
scenarios, patient device data is interfaced
trator. Automatic point of care data capture for
from local bedside subnetworks to remote
infused drugs can be correlated to changes in
systems. This includes links over hospital
patient vital signs, and also linked to hospital
local area networks to patient monitoring cen-
pharmacy, plus financial billing computers.
tral stations. In other scenarios, patient data is
Automatically logged data can be used as
transmitted over telephone lines and/or the
inputs to patient data management systems,
Internet as part of telemedicine or integrated
clinical data repositories and data warehouses,
delivery systems (IDS) to physicians in their
and clinical pathways systems. Such data can
offices, outside of the hospital. Home care
serve as the basis for the development of out-
represents another example involving data
comes management models. Other applica-
transfer to remote locations.
tions for automatically logged data include
Device management. Device interfaces are
anesthesia records, cardiac catheterization
also used for maintenance and configuration
labs, automatic documentation for electronic
support of the devices themselves. This entails
patient records, and accurate charging for
device tracking and scheduling, leading to
equipment utilization.
improvements in utilization, test and calibra-
Data display and decision support. A second
tion, management of battery charging, along
general area of use for ADC is for real time
with system management and diagnostics for
data display. This includes scenarios such as
communication networks. Some of the other
patient monitoring/charting systems, anesthe-
benefits of automatically captured data
sia workstations, arrhythmia workstations, real
include:
time decision support, and prenatal and neona-
tal care. Many of these applications involve the ● Improved effectiveness of outcomes man-
display of real time patient waveforms, such as agement;
ECG and respiration parameters. In real time ● Refinement of medical decisions by pro-
decision support systems, raw data, or infer- viding comprehensive data for compar-
ences drawn from the raw data, are displayed isons and trend analysis;
74 Health Informatics Journal

● Improvement in nurse utilization and job opposed to multiple cable types and/or
satisfaction, by reducing the need for adapters for specific devices. In addition, MIB
manual data capture; allows for great reductions in software devel-
● Elimination of patient transcription errors; opment and maintenance costs for device
● Improvement in patient clinical documen- manufacturers, clinical software developers,
tation; and hospital end users by specifying a com-
● Enabling of detailed analysis and research. mon data language applicable to all devices
from all manufacturers.
The MIB lower layers, along with HL7
version 2.2, were the first two ANSI standards
approved by the National Standards in Health
THE BENEFITS OF
Care Informatics. In addition, ANSI has
STANDARDIZATION approved the formation of a Health Care
Informatics Standards Board (HISB). This
Historically, the lack of standards has been an board includes representatives from all
inhibitor in the widespread implementation healthcare informatics standard development
of automated data capture in hospitals. organizations.
Conversely, many industries have reaped In addition to MIB (IEEE), these organiza-
widespread benefits by the deployment of var- tions include HL7 (an ANSI standard) for
ious standards. These include standards for hospital admission/discharge/transfer and
railroad track gages, nuts and bolts, tele- order/result transactions; DICOM (ACR/
phones, fax machines, automatic teller NEMA) for radiological imaging; ASTM for
machines, videocassette recorders, personal laboratory instrumentation; NCPCP for
computers, and all forms of data communica- pharmaceuticals; and X.12 for insurance
tion networks. transactions. The HISB is playing a leading
In each case, the standardized solution pre- role in the formation of the ISO Technical
vailed over proprietary, single-vendor method- Committee on Medical Informatics, whose
ologies. Standardization eliminates com- purpose is to foster international harmoniza-
patibility concerns among users, enabling tion for the various standards.
them to purchase products from multiple ven- The MIB lower layers standards are cur-
dors. The situation for acute care medicine, in rently in the ‘red cover’, preballot review
which patients move around; devices are con- process towards becoming CEN EN
tinually connected and disconnected; and clin- (European Norm) standards. This approval is
icians have multiple crises to deal with, anticipated for June 1998. The purpose of the
promises to be no different. MIB family of standards is to enable the auto-
matic and universal capture of clinical data
from any type of bedside device, from any
manufacturer. MIB is highly optimized for
real time device communications in an acute
MIB
care environment. Fig. 1 illustrates a generic
example of the use of ANSI/IEEE 1073 (MIB)
ANSI/IEEE Standard 1073, the Standard for for bedside device interfacing.
Medical Device Communications, or MIB, As shown, an MIB bedside subnetwork
leverages the advantages of standardization to consists of a configuration with multiple
the problem of patient-connected device inter- patient-connected devices interfacing to a
facing. In comparison to single-vendor propri- bedside hub. In MIB terminology, the hub is
etary networks, MIB comprises a truly open called the bedside communication controller,
system, public domain standard. In so doing, it or BCC. Each patient connected device inter-
provides a robust, cost effective answer to the faces by means of a device communication
need for guaranteed electrical and mechanical controller, or DCC. As shown in the figure,
safety, and data integrity. Moreover, it guaran- the DCC may be either an external converter
tees plug-and-play interoperability between all box, or an embedded implementation. The
devices from any manufacturer by specifying a purpose of an external box is to convert
common communication protocol for all between an RS-232, RS-422, RS-423, RS-485,
devices. This provides hospital users the free- 4 to 20mA, analog, parallel, or other ‘legacy’
dom to move equipment around an institu- device interface, and an MIB DCC.
tion, while eliminating any concerns regarding The single most salient feature of an MIB
interfacing compatibility. bedside subnetwork is its plug-and-play capa-
Standardization provides user simplicity, bility. That is, a bedside clinician can plug any
by enabling economies of scale in requiring MIB device from any manufacturer into any
end users to stock only one type of cable, as MIB BCC port. This results in the automatic
ANSI/IEEE 1073 75

Patient Bedside devices monitor Bedside Optional bedside

and collect clinical data. communications computer displays data for
Data converted into MIB controller collects hospital staff. Data stored
format. data. for retrospective analysis.

External
MIB converter (DCC)
Anesthesia station

Infusion pump
(Internal DCC)

Bedside
communications Remote hospital
controller host computer(s):
Pulse oximeter C.I.S., clinical data
(Internal DCC) Hospital repository, billing,
LAN pharmacy, etc.

Hospital
Patient monitor information
(Internal DCC) system

Other monitoring
devices
(Internal DCC)

Fig. 1. Typical ANSI/IEEE 1073 (MIB) Environment. information systems, optimized for the acute
care setting’. The purpose of MIB ‘to allow
establishment of device-to-hub communica- hospitals and other healthcare providers to
tion, without requiring further user interven- interface medical instrumentation to host
tion. The other significant features of MIB computer systems in a manner that is compat-
include: ible with the patient care environment’.
● The standard ensures electrical safety by
requiring DCC earth ground isolation;
● The MIB data link protocol provides
highly reliable data transfers, with built-in OVERVIEW OF THE MIB
comprehensive frame validity checking, STANDARDS
and automatic retries of failed frame
exchanges; Fig. 2 illustrates the IEEE 1073 MIB family of
● The MIB upper layers, which provide an approved and draft standards. As shown, MIB
object oriented framework and common will provide a mechanization of all seven OSI
data language applicable to all device types. layers. The first three approved standards of
the family are the 1073 Framework and
The subnetwork may operate in a standalone Overview, the ANSI/IEEE 1073.3.1 Transport
configuration. For example, a BCC could be Profile – Connection Mode, and the ANSI/
embedded in a bedside PC, in which patient IEEE 1073.4.1 Physical Layer (cable con-
data is displayed and stored. More typically, nected). It is anticipated that the P1073.1.3.1
the BCC may interface to one or more hospi- and 1073.1.3.4 Virtual Medical Device upper
tal computers over a local area network. layers for infusion pumps and pulse oximeters
Possibilities include a charting application respectively will be approved by the IEEE
running on a nurse’s station computer, pro- Standards Board in September 1998.
viding input to a clinical data repository that The P1073.1 series of standards deals with
stores a wide variety of patient data, commu- the OSI application layer in defining the
nicating with clinicians at remote locations, Medical Device Data Language (MDDL).
and interfacing with other computers This includes a domain information model,
involved in such functions as pharmacy man- which delineates a common object oriented
agement and billing. framework for defining the attributes and ser-
MIB defines a highly flexible, scalable vices for all medical devices. This includes a
standard, providing standardized connectivity common nomenclature, for delineating the
for all bedside medical devices. According the attributes from all device types.
IEEE 1073 committee, the scope of MIB is ‘to The P1073.2 series defines the upper layers
provide for open systems communications in communication services: application, presenta-
healthcare applications, primarily between tion, and session layer services. These include
bedside medical devices and patient care specialized encoding rules, and are based on
76 Health Informatics Journal

OSI 1073 Medical Device Communications Framework and Overview

Layers (approved 3/96)

Application P1073.1 Medical Device Data Language (MDDL) Framework and P1073.2 Medical Device Application Profile (MDAP) Framework
Overview and Overview (ballot approved 11/95)
P1073.1.1 MDDL Common Definitions
P1073.1.1.1 MDDL Nomenclature P1073.2.0 MDAP Base Kernel Profile
P1073.1.2 VMD Generalization P1073.2.1 MDAP Minimum Kernel Profile

P1073.1.3 VMD Specialization P1073.2.2 MDAP Basic Kernel Profile

P1073.1.3.1 VMD Specialization: Infusors

P1073.1.3.2 VMD Specialization: Monitors

P1073.1.3.3 VMD Specialization: Ventilators

P1073.1.3.4 VMD Specialization: Pulse Oximeters

P1073.1.3.5 VMD Specialization: Defibrillators

P1073.1.4 Kernel Data Format (KDF)

Presentation P1073.2.3 MDAP Extended Kernel Profile
Session

Transport 1073.3.1 Transport Profile (approved 12/94)

Network
Data Link

Physical 1073.4.1 Physical Layer (approved 12/94)

P1073.5 Internetworking: Bridges, Routers, Transport Relays, Application Gateways

Fig. 2. The IEEE 1073 (MIB) Family of Standards. standards in December 1994 and as American
National ANSI standards in August 1995.
mOSI, a streamlined subset of the full OSI MIB specifies an active star topology,
upper layers. The services include association, allowing up to 125 bedside devices with
event reporting and SET and GET operations. embedded or attached DCCs (Device
The 1073.3.1 Transport Profile standard Communication Controllers) to connect to a
encompasses the transport, network and data Bedside Communication Controller central
link layers. The MIB transport and network hub, or BCC.
layers are currently inactive. The MIB data While the 1073.3.1 transport and network
link layer defines a connection-oriented data layers are currently inactive, the MIB data link
link for a bedside subnetwork. This includes layer specifies an extensive ‘short stack’ mech-
detailed specifications for logical connection anization of the OSI lower layers, in which
establishment, deterministic polling, guaran- bandwidth allocation, a protocol in which
teed data delivery, flow control and systems each DCC/device is polled by the BCC at
management. least once per second, comprehensive frame
The 1073.4.1 Physical Layer standard spec- validity checking, acknowledgement, confir-
ifies the MIB cable, connector, three data mation, retries and flow control are all imple-
rates, electrical signaling characteristics, mented by the data link layer, rather than by
mechanisms for physical connect and discon- the transport and/or network layers.
nect sensing and provisions for ensuring elec- Two salient features of the MIB data link
trical safety. protocol are:
The P1073.5 Internetworking standards
represent future work of the MIB committee. 1. Deterministic polling, in which each device
This will entail the development of standards is polled a minimum of once per second.
to define bridges, routers, transport relays, and This serves as a communication ‘keep alive’
application gateways between MIB bedside for a device and its communication con-
subnetworks and hospital local area networks troller. For each polling cycle, the BCC
(LANs). One of these key standards in this area and/or DCC may each transmit frame sizes
will define a transport relay between an MIB of up to 1496 data bytes. This is sufficient
BCC and a TCP/IP-based hospital LAN. to provide robust support of waveform
transmission, while also allowing for a rea-
sonable amount of upper layers overhead.
2. They provide guaranteed data delivery for
all messages. That is, all messages are
MIB LOWER LAYERS acknowledged by the receiver and con-
firmed by the sender. Frame acknowledge-
The MIB lower layers are defined by two ment includes full frame validity checking,
standards: ANSI/IEEE 1073.3.1 Transport which includes a 16-bit FCS. In addition,
Profile – Connection Mode, and ANSI/IEEE MIB’s data link flow control service allows
1073.4.1 Physical Layer – Cable Connected. a local receiving station (BCC or DCC) to
These two documents were approved as IEEE ‘throttle down’ the remote station – that is,
ANSI/IEEE 1073 77

to request it to stop transmitting data – in specification for medical device safety, as well
the event that the local station has a as IEC-601-1-1, or other applicable safety stan-
resource – e.g. buffer memory and/or dards. Similarly, regarding EMC, 1073.4.1
processor bandwidth, that is temporarily states that the implementation of an MIB inter-
unavailable. face shall not interfere with the equipment’s
capability to meet the IEC-601-1-2 specifica-
Plug-and-play. In an acute care environment,
tion for EMC, or other applicable standards.
devices are moved around, patients move
The MIB physical layer includes specific
around depending on their condition, and pro-
provisions to eliminate the possibility of circu-
fessionals have many crises to deal with.
lating power ground currents in cable conduc-
Therefore, it is a requirement for the network
tors or shields. This includes specifications for
to be able to undergo frequent changes in con-
minimum dielectric withstand voltage and
figuration without the need for any manual
maximum leakage current between the MIB
intervention by the bedside clinician. This
signals and earth ground, and a minimum
being the case, the need for plug-and-play oper-
value for the 50/60Hz impedance between the
ation is the single most important requirement
cable shield and earth ground at the
for a medical device communications standard.
DCC/device end of the link.
With MIB, it is not acceptable for front line
In addition to including requirements to
healthcare professionals to need to select the
avoid power ground loops, an annex of the
correct device-specific cable, adapter and/or
P1073.4.1a draft supplement to the MIB physi-
isolator; plug a device into a specific connec-
cal layer deals with issues such as dielectric
tor on a patch panel; and/or need to enter
strength voltages and leakage currents for sig-
information about a device into a bedside
nal isolation to device electronics and mains
computer terminal. ANSI/IEEE 1073 pro-
voltages, air clearance and creepage distances,
vides true plug-and-play operation. When a
and safety labeling and documentation [3].
DCC is ready to communicate and is con-
Data rate. MIB’s physical layer supports
nected to a BCC port, the BCC detects the
three data rates: 2400 baud, 9600 baud, and
physical connection and automatically initi-
1Mb/s. A DCC/device must operate at one of
ates a logical connection establishment
these three data rates. MIB’s physical serial
sequence. Following physical connection,
data link is based on ISO/IEC-8482 (EIA-
there is no further user intervention required.
485). This provides differential signaling, and
After completion of the connection establish-
therefore a higher degree of noise immunity
ment sequence, the BCC polls the device/
than single-ended signaling. In addition,
DCC periodically, with the polling period
ISO/IEC-8482 is well suited to supporting the
requested by the DCC and confirmed by the
MIB high-speed data rate of 1Mb/s. This data
BCC. Each polling cycle allows for bidirec- rate supports physiologic waveform transmis-
tional communication. sion from such device types as patient moni-
Electrical safety. The MIB physical layer tors, ventilators and EEG monitors.
includes provisions to ensure complete elec- To allow connections with all DCC/
trical system safety. In many European coun- devices, all BCC ports are required to support
tries, a communication standard intended for all three data rates through the same physical
use as a bedside subnetwork must comply interface.
with the IEC-601-1-1 specification for medi- The low-speed MIB specifies the use of
cal device systems. For practical purposes, this binary encoding, allowing for the use of stan-
should be done in a way that eliminates the dard UARTs. This enables very low cost
need for active intervention by systems inte- implementations for medical devices with low
grators and end users. data volumes. For the 1Mb/s transmission,
Since the DCC/device end of the link will ANSI/IEEE 1073’s use of Manchester encod-
generally be patient connected, the philoso- ing simplifies clock and data recovery, and
phy taken by the MIB physical layer standard provides a high degree of noise immunity.
is to impose most of the electrical safety bur- Cable and connector. MIB specifies the use of
den on the DCC (device), rather than the a six-conductor shielded cable with a maxi-
BCC (bedside hub) end of the link. This mum length of 30 meters. Limiting the num-
reduces the cost of the BCC hub, by allowing ber of conductors to six ensures a high degree
it to meet a less stringent level of electrical of cable flexibility. The MIB connector design
safety requirements. For example, this allows is intentionally hospital-unique to prevent
standard PCs to serve as platforms for BCCs. plugging into incorrect, possibly dangerous
The ANSI/IEEE 1073.4.1 physical layer locations. Another attribute of the MIB con-
explicitly states that the implementation of an
nector is the inclusion of protected contacts,
MIB interface shall not interfere with the
to minimize the possibility of an electric
equipment’s capability to meet the IEC-601-1
78 Health Informatics Journal

shock hazard, in compliance with IEC-601-1. upper layers will provide significant additional
In addition, the MIB connector provides a value. The upper layers are comprised of two
minimum releasing force sufficient to ensure parts: the Medical Device Application Profile
against inadvertent cable disconnects. (MDAP) and the Medical Device Data
Power. The ANSI/IEEE 1073.4.1 Physical Language (MDDL).
layer standard requires that a BCC provide Application profile. The IEEE P1073.2
12V, 300mA of power from each port. For MDAP Framework and Overview document
safety reasons, each port must provide inde- specifies the use of minimal OSI (mOSI) for
pendent current limiting, with a maximum the MIB upper layer communication protocol.
current limit value of 600mA. This power is mOSI comprises a highly streamlined subset
required for a number of reasons: of the full OSI Application, Presentation, and
Session layers. While full OSI typically
1. To enable the implementation of protocol
requires more than 10 Mbytes of program
converters for ‘legacy’ (prestandardized)
code which is not practical for medical devices,
devices. Typically, these are devices with
mOSI requires only 20 to 30 Kbytes of code.
embedded ISO/IEC-2110 (RS-232), RS-
The initial (or ‘minimum’ version) of the
422/423/485, parallel, and/or analog inter-
MDAP will enable data transmission or ‘event
faces.
reporting’ by medical devices (DCCs). The
2. To facilitate the use of optical isolation for
subsequent ‘basic’ and ‘extended’ versions of
the device interface, to meet the IEC-601
the MDAP will include enhanced functional-
safety requirements.
3. Powering the communications electronics ity, including the capability to control a medi-
cal device from a host computer and
independently from the device itself pro-
eventually, functionality to provide for data
vides the capability to signal alarms for
security and perform program downloads.
device failures (e.g. low or dead batteries),
The MIB upper layers will be used over the
as well as for patient related conditions and
subnetwork configuration defined by the
events.
lower layers, as well as over hospital-wide net-
4. Externally provided power may be used to
works that interface between multiple bed-
power device communications interfaces
sides and multiple host computers.
and/or device electronics, reducing the size
The MIB presentation layer includes the
of the device power supply and/or battery.
encoding rules for translating between the
Interrupt messages. The MIB data link supports application layer abstract syntax, defined by
interrupt messages. These provide a means the ISO ASN.1 standard, and the transfer syn-
for device/DCCs to transmit alarm data prior tax of the actual data communicated across the
to the normal polling time. In addition, the bedside subnetwork and the hospital-wide
use of a special mechanism for interrupt mes- network. One of the salient features of the
saging provide a clear-cut means for distin- MIB upper layers is the Medical Device
guishing between imminent alarm data, Encoding Rules (MDER), a variation of the
which must be processed immediately, and standard ISO Basic Encoding Rules (BER)
other data that a BCC or remote host can rou- that has been optimized for use with medical
tinely place on the ‘normal’ data queue for devices. MDER greatly simplifies device soft-
subsequent processing. ware and streamlines the length of messages
Time synchronization. The MIB lower layers by utilizing fixed length integers, allowing the
provide a mechanism for multidevice time use of leading zeros to enable the use of
synchronization, with a device-to-device ‘canned’ (fixed length) messaging, and mak-
accuracy of –1ms. ing use of a common nomenclature.
System management. The MIB lower layers The MIB nomenclature, which is based
also include extensive system management primarily on the work of the CEN/TC 251
protocol, which enables control and access of Working Group 5 committee, defines a repre-
configuration, performance and diagnostic sentation of commonly used physiologic vari-
parameters for the bedside subnetwork. ables and other attributes by means of specific
16-bit codes. Each nomenclature code is asso-
ciated with a specific metric, alarm, event, or
action class of object. Attributes associated
MIB UPPER LAYERS with an MIB object include its class (e.g. met-
ric), name (e.g. temperature), state (e.g. valid
By enabling plug-and-play operation between
data), dimension (e.g. °F), and observation
systems from multiple vendors, the advent
(e.g. 100.2). An alert object is used to commu-
and availability of the MIB lower layers pro-
nicate an alarm condition.
vides a quantum leap over proprietary device
The use of a predefined nomenclature,
protocols. Taking a longer view, the MIB
along with a standardized 32-bit floating point
ANSI/IEEE 1073 79

representation for numeric data, eliminates and reusability. Rather than limiting the
the need to redundantly send ‘type’ and ‘vocabulary’ of MIB devices, this allows for
‘length’ information along with every event continued innovation by device manufacturers.
report transmission. In contrast to the ‘plain The MIB upper layers leverage a number of
vanilla’ BER, the MDER also enables highly existing ISO standards. These include
compacted representations of physiologic Common Management Information Protocol,
waveform data, as required for patient moni- or CMIP. In addition to providing capabilities
tors, ventilators, and other devices. to send messages and receive replies, CMIP
As illustrated in Fig. 3, the MIB upper lay- object management operations include get and
ers specify their own state machine to provide set objects, create and delete objects, generate
plug-and-play. This includes a remote initial- actions, and issue event reports. Another ISO
ization phase to establish upper layers com- standard leveraged by MIB is Remote
munications, followed by an operational Operations Service Element, or ROSE. ROSE
phase. The initialization phase involves deter- supports both synchronous and asynchronous
mination of the device polling parameters upper layer operation, as well as time manage-
through the lower layers, and the use of the ment through the lower layers.
ISO Association Control Service Element The development of the IEEE MIB upper
(ACSE) protocol. ACSE provides a means to layer documents has leveraged significantly on
ensure the matching of the device and host the work of the CEN TC251 Working Group
protocols, and of ensuring forward compati- 5 (now Working Group 4) committee. This
bility. Following association, a device notifies includes a Domain Information Model for
the BCC and/or remote host of what parame- devices and other subjects and objects relating
ters, alarms, scanners, and other objects that it to the acute care environment, along with a
supports by transmitting a create notification comprehensive listing of nomenclature codes.
event report. The operational phase supports The CEN/MIB upper layers are based on
event driven communication and time syn- an object oriented framework, as shown in Fig.
chronization. 4. This begins with the CEN domain informa-
IEEE P1073.1 defines the Medical Device tion model, which encompasses other subjects
Data Language (MDDL). MDDL makes use of including the MDS (Medical Device System)
object-oriented methodologies. These will System subject, a medical subject, and other
define generalized base classes of medical subjects dealing with extended services, com-
devices that are used in other MDDL special- munication, control, a patient demographic
izations. These specializations build on each subject, and an archival subject.
other by means of object-oriented inheritance, In terms of medical device interfacing, the
providing the long-term benefits of modularity most important of these subjects are the system,

disconnected

normal connection
disconnection
connected

unassociated

association association
request reject
initializing

Normal associating
disassociation
association
accept

disassociated associated

configure
association
release response
configuring
disassociating
configuration
association complete
release
request initialized
Re- config’n
done
configured
re- configuring
operation

terminating operating
termination
intention

Fig. 3. MDS finite state machine.

80 Health Informatics Journal

Top

Archival

Patient- Patient
Archive

Session- Patient
Archive Demographics

System
Extended Services

Scanner
MDS

Communication
Medical
Communication
Controller

VMD
Alarm

Control
Alert

Service+
Channel Control

Metric

Fig. 4. Subjects of the CEN/MIB domain information model. meters, is included in the body of each respec-
tive VMD standard. In addition, the VMD
medical, alarm, extended services, communica- documents include informative annexes
tion, and control subjects. The system subject which delineate the listings of all of the possi-
model is the highest level subject. It encom- ble parameters (and their nomenclature
passes a number of objects, including the bat- codes) associated with a given device type that
tery object, log object, event log objects, and are listed in the CEN document, along with
individual objects to model different types of additional parameters originating from the
MDSs for specific device types. The log object MIB IEEE committee.
is a storage container for important local system For each mode for each device type, there
notifications and events. The event log object is is an operational status finite state machine
a more general log object that stores system that delineates the different phases of opera-
information in a free text expression [4]. tion. For example, for the ‘nominal’ mode for
In terms of modeling medical devices, the an infusion pump device, there are four states,
medical subject model, shown in Fig. 5, is the with allowable defined transitions between
most important. The medical subject encom- the states. In this example, the four states are:
passes the VMD (Virtual Medical Device) ‘Off ’, ‘Standby’, ‘KVO’ (Keep Vein Open)
object, along with the alarm (or alert) object. and ‘Infusing’.
There are individual VMD standards for vari- To date, the device types considered include
ous classes of devices. The VMD standards infusion pumps (IEEE draft standard
delineate the minimum listing of modes, P1073.1.3.1), monitors (P1073.1.3.2), ventilators
operational states, and parameters for MIB- (P1073.1.3.3), pulse oximeters (P1073.1.3.4),
compliant medical devices. and defibrillators (P1073.1.3.5). There will be
For example, for a minimally compliant additional VMD standards for other device types,
infusion type device (per the draft VMD docu- including cardiac output computers, anesthesia
ment), it is necessary to report the values of machines, blood and blood gas analysers, urine
current delivery rate (flow), operational status flowmeters, perfusion machines and others.
and volume infused. For a minimally compli- A VMD may be partitioned into smaller
ant pulse oximeter device, it is necessary to components known as channels (or
report the values of pulse rate, arterial blood ‘subVMDs’). Examples of channels include
oxygen concentration, and operational status. modular plug-ins for patient monitors for
A listing of the parameters and their measuring various physical parameters, and
nomenclature codes required for a device to the separate channels for a multichannel infu-
be minimally MIB compliant, along with a sion pump. There is a set of objects associated
short listing of ‘conditional’ (optional) para- with each VMD, or each channel within a
ANSI/IEEE 1073 81

Medical MDS Session-Test

VMO
Type VMD 0,m
Label
Handle Revision
0,m
Status
1
Position
0,m

0,m 0,m 0,m

Channel
Status

0,m

0,m 0,m
Alert

1 1 0,1
0,1 0,1
0,1 0,1

Metric 0,m
Alert PM-Store
Update Mode
Update Rate
0,m
Unit Code
0,1

0,m 0,m

Sample Array Numeric Enumeration

Sa-Observed-Value Nu-Observed Value Enum-Observed Value
Sample Rate Range

RealTime-SA Time-SA Distribution-SA PM-Segment

Sweep-Speed

Fig. 5. Medical subject model. alarm levels as well as the reporting of alarm
conditions.
VMD. The two general categories of these
objects are metrics and alerts. Communication controller. The Communication
Metrics. Metrics provide the representation controller object identifies the full capabilities
for scalar, parametric data. There are four sub- of a DCC/device, in terms of the OSI 7 layers.
classes of metric objects: enumerations, This encompasses a T-profile (Transport –
numerics, sample arrays, and persistent-met- lower layers), F-profile (Format – presenta-
ric stores. tion layer; i.e. encoding rules), and A-profile
(Application – list of upper layers services
1. Enumerations, which are encoded as bit supported). The contents of this object are
strings, are used to delineate variables such communicated across the link as part of the
as modes of operation and operational sta- association process.
tus. For example, a device’s current mode Scanners. The extended services model
of operation may entail multiple modali- defines various types of scanner objects.
ties, rather than a single ‘mode’ identifier. Scanner objects provide object management
2. Numerics are used for the transmission of services for transferring information between
observed values of individual parameters devices and host computer systems by differ-
such as heart rate, oxygen concentration ent methods. There are two general types of
and volume infused. scanners: unconfigurable scanners and con-
3. Sample arrays are used for the transmission figurable scanners.
of physiologic waveforms, such as ECG, Two types of unconfigurable scanners are the
respiration volume or EEG. context scanner and the alert scanner. During
4. The Persistent-Metric Store (PM-store) initialization, a device transmits a create noti-
object provides for the storage of metric fication event report, informing a remote host of
values for subsequent bulk transmission. all parameters (enumerations, metrics, wave-
The PM-store capability provides bulk data forms and alarms) and scanner types that it sup-
upload capability for situations such as ports. An alert scanner is transmitted to inform
patient transport in which a device is of alarm conditions as they occur. There are two
unplugged from its MIB communication types of scanners that may be configured by a
link for a period of time. remote host computer: a configurable periodic
scanner and a configurable episodic scanner.
Alert object. The Alert (or alarm) object speci- The periodic scanner reports all parameter vaues
fies the functionality required for MIB com- once per every predesignated time period, while
pliant devices to report patient and device an episodic scanner is only transmitted as the
alarm conditions. This includes the setting of result of changes in parameter values.
82 Health Informatics Journal

Control subject. The control subject model a Charles River Data System (CRDS) mini-
supports device control from an external computer by means of a 19.2kbaud RS-232
computer. This capability is reserved for point-to-point data link. The CRDS computer
future use; it is not supported by the initial, is used as a multibed hub for collecting infu-
‘minimal’ version of the MIB upper layers. sion pump data from all ICU beds. There is a
As the MIB upper layers mature, they will 10BASE-T Ethernet LAN that connects
enable developers of medical application soft- between the CRDS computer and the individ-
ware to utilize high-level ‘generic’ software ual MIB bedside communication controllers
drivers capable of accessing data from (or to) (BCCs) located in each ICU patient room.
any medical device. This will provide a high McKay-Dee’s implementation of MIB uti-
degree of cost reduction for device manufac- lizes DCC converter boxes and four-port
turers, application software vendors, system ISAbus BCC cards. The converter boxes
integrators and end users. Instead of needing mount mechanically on the top of the Ivac 560
to confer, negotiate and write custom software infusion pumps, and interface by means of the
to achieve interoperability between different pumps’ RS-232 serial ports. The converter
pieces of equipment, all that will be necessary boxes dialog with the pumps using proprietary
will be compliance with a public domain, RS-232 protocol, and repackage the data to the
open system standard. built-in DCC, for transmission over the indi-
vidual plug-and-play MIB data links.
The BCC end of the link consists of three
four-port BCC boards, which are installed in
AN EXAMPLE OF ADC USING each of the Pentium computers located at the
MIB ICU room bedsides. McKay-Dee has used as
many as six MIB pumps on a patient. In the
Fig. 6 illustrates the overall block diagram of future, they are looking to purchase pumps
an automatic data capture (ADC) system with embedded DCCs, as well as to implement
using MIB. MIB for ventilators and other device types.
The diagram illustrates the overall hard-
ware configuration for automatic data collec-
tion for the HELP (Health Evaluation
Through Logical Processing) clinical hospital CONCLUSION
information system for McKay-Dee Hospital
in Ogden, Utah. McKay-Dee Hospital is part The history of technology is replete with exam-
of the 24-hospital Intermountain Healthcare ples in which open architecture standards have
chain in Utah, Idaho and Wyoming. In prevailed over proprietary standards. Auto-
McKay-Dee’s ICU, data is gathered from Ivac matic data collection from bedside devices is an
560 infusion pumps using MIB. The HELP enabling technology, multipurpose tool for the
system software (Fig. 6) runs on the Tandem support of data logging, displays, clinical path-
mainframe computer, with financial and ways implementation, alarming, device con-
billing software running on the IBM AS400 trol, telemedicine, and device management.
computer. The Tandem computer connects to With increasing demands on healthcare institu-

tandem mainframe IBM AS400

IPX/ETHERNET

19 s Kbd BEDSIDE PLC/ BEDSIDE PLC/

RS-232 TERMINAL TERMINAL

2 TERMINALS INSIDE EACH ICU ROOM

RS-232 RS-232 CHARLES RIVER DATA 1 TERMINAL OUTSIDE EACH ICU ROOM
ALPHA-SENSE
WATCHDOG TIMER BOX SYSTEMS COMUTER
PAGING
SYSTEM
TCP/IP/10 BASE-T ETHERNET

DELL PENTIUM P.C. H.P.

MIB-TO-TCP/IP CarePort
TRANSPORT RELAY
H.P.
PROPIETARY LINK
BREAKOUT BOX CABLE
(12 MIB PORTS) H.P. H.P.
MERLIN MONITOR MERLIN MONITOR

BREAKOUT BOX\
12 MIB CONNECTORS 1 MONITOR IN EACH ICU ROOM

MIB cable MIB cable

MIB DCC MIB DCC

CONVERTER BOX CONVERTER BOX

RS-232 RS-232

IVAC 560 IVAC 560

INFUSION PUMP INFUSION PUMP
Fig. 6. McKay-Dee Hospital systems diagram:
UP TO 12 MIB PUMPS an example of MIB-based data capture.
ANSI/IEEE 1073 83

tions to reduce costs, there is an imminent Netherlands: Kluwer, 1997.

[3] Glass M. ANSI/IEEE 1073 (MIB): Lower layers optimized
need for standardized automatic data collection
for acute care device communications. Presented to CEN/ISSS
from devices used in acute care, the most costly Workshop, Brussels, Belgium; October, 1997.
area of health care, to get the patient healthier [4] IEEE P1073.1.3.3 Draft of Standard for Medical Device
faster through information. Communications – Medical Device Data Language (MDDL) Virtual
ANSI/IEEE 1073, the Standard for Medical Device, Specialized – Ventilators. New York: IEEE, 1998.

Medical Device Communications, or MIB, is

the emerging standard for device interfacing. FURTHER READING
MIB is a full-stack OSI communication stan- [1] Busci E. What is MIB? And how to specify it in your RFPs?
dard, providing clinicians with simple, plug- ASHMM Reference Series. Chicago: American Society for Healthcare
and-play interfacing from any device type Materials Management of the American Hospital Association, 1996.
from any manufacturer. Some of MIB’s salient [2] Data Trap. Healthcare Technology Management 8:6, East
Providence, RI: HealthTech Publishing, 1997.
features include guaranteed electrical safety, [3] EWOS Technical Guide: Standardized Communications for
reliable data transfer, power provided to Bedside Medical Devices, European Workshop for Open Systems
devices, time synchronization, and system EWOS Secretariat, Brussels, Belgium; November 1997.
management. The MIB upper layers are based [4] Glass M, Costa L. IEEE 1073 (MIB) Stanardized Connec-
on a scalable, object oriented framework. tivity for patient connected devices. Medical Electronics. Pittsbugh, Pa:
Measurement & Data Corp., September 1996.
These specify a common data language for all [5] IEEE 1073.31.1 Standard for Medical Device Communications –
medical devices, including individual object Transport Profile – Connection Mode, New York: IEEE, 1994.
models for specific device types. This has [6] IEEE 1073.31.1 Standard for Medical Device Communications –
great advantages for clinical software develop- Transport Profile – Cable Connected, New York: IEEE, 1994.
ers, providing a common platform for a myr- [7] Kennelly R J. IEEE Standards for physical and data com-
muncations. Biomedical Instrumentation and Technology. Philadelphia,
iad of applications. PA: Hanley & Belfus, 1996.
[8] Kennelly, R J, Wittenber J. New IEEE standard enable data
collection for medical applications. JAMIA Symposium Supplement
REFERENCES SCAMC Proceedings, 1994. American Medical Informatics Associ-
ation, Philadelphia, PA: Hanley & Belfus, 1994.
[1] Kennelly R J. Real time informatics. Health Systems Review, [9] Miller A. New standard paves the way for automated data
March/April 1997. capture. ADVANCE for Health Information Professionals, April 1997.
[2] Kennelly R J, Gardner R M. Perspectives on development [10] New data collection standard waits for chance in spotlight.
of IEEE 1073: The Medical Information Bus (MIB) Standard. Report on Healthcare Information Management 3:8, Alexandria,
International Journal of Clinical Monitoring and Computing. VA: Capitol, 1996.