IEEE P11073-102011.1 Draft Standard for Health informatics Point-of-care medical device communication Part 10201: Domain information model

mustardpruneΔίκτυα και Επικοινωνίες

23 Οκτ 2013 (πριν από 3 χρόνια και 8 μήνες)

136 εμφανίσεις

IEEE P11073
-
10201/D1.1, November 2010

Copyright © 2010 IEEE. All rights reserved.

This is an
unapproved IEEE Standards Draft, subject to change.

IEEE P
11073
-
10201
™/D
1.1

1

Draft

Standard

for
Health informatics
2



Point
-
of
-
care medical device
3

communication


Part 10201:
4

Domain information model

5

Sponsor

6

IEEE 11073 Standards

Committee

7

of the

8

IEEE Engineering in Medicine and Bio
logy

Society

9

Approved <
XX
M
ONTH

20XX
>

10

IEEE
-
SA Standards Board

11


12

Copyright ©
2010

by the Institute of Electrical and Electronics Engineers, Inc.

13

Three Park Avenue

14

New York, New York 10016
-
5997, USA

15

All rights reserved.

16

This document is an unapproved draft of

a proposed IEEE Standard. As such, this document is subject to
17

change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be
18

utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards
19

C
ommittee participants to reproduce this document for purposes of international standardization
20

consideration. Prior to adoption of this document, in whole or in part, by another standards development
21

organization, permission must first be obtained from the

IEEE Standards Activities Department
22

(stds.ipr@ieee.org). Other entities seeking permission to reproduce this document, in whole or in part, must
23

also obtain permission from the IEEE Standards Activities Department.

24

IEEE Standards Activities Department

25

4
45 Hoes Lane

26

Piscataway, NJ 08854, USA

27

28

IEEE P11073
-
10201/D1.1, November 2010

Copyright © 2010 IEEE. All rights reserved.

This is an
unapproved IEEE Standards Draft, subject to change.

Abstract:

Within the context of the ISO/IEEE 11073 family of standards for point
-
of
-
care (POC)
1

medical device communication (MDC), this standard provides an abstract object
-
oriented domain
2

information model that spec
ifies the structure of exchanged information, as well as the events and
3

services that are supported by each object. All elements are specified using abstract syntax
4

(ASN.1) and may be applied to many different implementation technologies, transfer syntaxes
,
5

and application service models. Core subjects include medical, alert, system, patient, control,

6

archival, communication, and extended services. Model extensibility is supported, and a
7

conformance

model and statement template is provided.

8


9

Keywords:

abst
ract syntax, alarm, alert, ASN.1, information model, medical device
10

communications, medical information bus, MIB, point
-
of
-
care, POC, object
-
oriented, patient,
11

remote control

12


13



14

15




The Institute of Electrical and Electronics Engineers, Inc.

3 Park Av enue, New York, NY 1001
6
-
5997, USA

Copy right © 20XX by the Institute of Electrical and Electronics Engineers, Inc.

All rights reserv ed. Published
<XX M
ONTH

20XX>
. Printed in the United States of America.


IEEE is a registered trademark in the U.S. Patent & Trademark Of f ice, ow
ned by the Institute of Electrical and Electronics

Engineers, Incorporated.


PDF:

ISBN 978
-
0
-
XXXX
-
XXXX
-
X

STDXXXX
X

Print:

ISBN 978
-
0
-
XXXX
-
XXXX
-
X

STDPDXXXX
X


IEEE prohibits discrimination, harassment and bullying. For more information, visit
http://www.ieee.org/web/aboutus/whatis/policies/p9
-
26.html
.

No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written pe
rmission
of the publisher.

IEEE P11073
-
10201/D1.1, November 2010

Copyright © 2010 IEEE. All rights reserved.

This is an
unapproved IEEE Standards Draft, subject to change.

IEEE Standards

documents are developed within the IEEE Societies and the Stan
dards Coordinating Committees of
1

the IEEE Standards Association (IEEE
-
SA) Standards Board. The IEEE develops its standards through a consensus
2

development process, approved by the American National Standards Institute, which brings together volunteers
3

repr
esenting varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the
4

Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote
5

fairness in the consensus

development process, the IEEE does not independently evaluate, test, or verify the accuracy
6

of any of the information

or the soundness of any judg
ments co
ntained in its standards.

7

Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability f
or any personal injury, property or other
8

damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly
9

resulting from the publication, use of, or reliance upon this, or any other IEEE Standard document
.

10

The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly
11

disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific
12

purpose, or that the use

of the material contained herein is free from patent infringement. IEEE Standards documents
13

are supplied “
AS IS
.”

14

The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase,
15

market, or provide other g
oods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint
16

expressed at the time a standard is approved and issued is subject to change brought about through developments in the
17

state of the art and comments received from users

of the standard.
Every IEEE Standard is subjected to review at least
18

every five years for

revision or reaffirmation, or every ten years for stabilization. When a document is more than five
19

years old and has not been

reaffirmed, or more than ten years old
and has not been stabilized, it is reasonable to
20

conclude that its contents, although still

of some value, do not wholly reflect the present state of the art.

Users are
21

cautioned to check to determine that they have the latest edition of any IEEE Standard.

22

In publishing and making this document available, the IEEE is not suggesting or rendering professional or other
23

services for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other
24

person or entity to anot
her. Any person utilizing this, and any other IEEE Standards document, should rely
upon
his or
25

her independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the
26

advice of a competent professional in determi
ning

the appropriateness of a given IEEE standard.

27

Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to
28

specific applications. When the need for interpretations is brought to the attention of IE
EE, the Institute will initiate
29

action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is
30

important to ensure that any interpretation has also received the concurrence of a balance of interests. For t
his reason,
31

IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant
32

response to interpretation requests except in those cases where the matter has previously received formal consideration.
33

A statement,

written or oral, that is not processed in accordance with the IEEE
-
SA Standards Board Operations Manual
34

shall not be considered the official position of IEEE or any of its committees and shall not be considered to be, nor be
35

relied upon as, a formal inter
pretation of the IEEE.
At lectures, symposia, seminars, or educational courses, an
36

individual presenting information on IEEE standards shall make it clear that his or her views should be considered the
37

personal views of that individual rather than the form
al position, explanation, or interpretation of the IEEE.

38

Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation
39

with IEEE. Suggestions for changes in documents should be in the form of a proposed

change of text, together with
40

appropriate supporting comments.
Recommendations to change the status of a stabilized standard should include a
41

rationale as to why a

revision or withdrawal is required. Comments and recommendations on standards, and requests

42

for interpretations should be

addressed to:

43

Secretary, IEEE
-
SA Standards Board

44

445 Hoes Lane

45

Piscataway, NJ 08854

46

USA

47

Authorization to photocopy portions of any individual standard for internal or personal use is granted by

T
he Institute
48

of Electrical and

Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center.
49

To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood
50

Drive, Danvers, MA 01923 USA; +1 978 7
50 8400. Permission to photocopy portions of any indi
vidual standard for
51

educational c
lassroom use can also be obtained through the Copyright Clearance Center.

52

IEEE P11073
-
10201/D1.1, November 2010

iv

Copyright © 2010 IEEE. All rig
hts reserved.

This is an unapproved IEEE Standards Draft, subject to change.

Introduction

1

This introduction is not part of IEEE P
11073
-
10201
/D
1.1
, Draft

Standard

for
Health informatics


Point
-
of
-
care
2

medical device communication


Part 10201: Domain information model
.

3

ISO/IEEE 11073 standards enable communication between medical devices and external computer
4

systems. They provide automatic and detailed electronic data capture of patient vital s
igns information and
5

device operational data. The primary goals are to:

6



Provide real
-
time plug
-
and
-
play interoperability for patient
-
connected medical devices

7



Facilitate the efficient exchange of vital signs and medical device data, acquired at the point
-
o
f
-
8

care, in all health care environments

9

“Real
-
time” means that data from multiple devices can be retrieved, time correlated, and displayed or
10

processed in fractions of a second. “Plug
-
and
-
play” means that all the clinician has to do is make the
11

connection


the systems automatically detect, configure, and communicate without any other human
12

interaction.

13

“Efficient exchange of medical device data” means that information that is captured at the point
-
of
-
care
14

(e.g., patient vital signs data) can be archived, r
etrieved, and processed by many different types of
15

applications without extensive software and equipment support, and without needless loss of information.
16

The standards are especially targeted at acute and continuing care devices, such as patient monitors
,
17

ventilators, infusion pumps, ECG devices, etc. They comprise a family of standards that can be layered
18

together to provide connectivity optimized for the specific devices being interfaced.

19

Notice to users

20

Laws and regulations

21

Users of these documents sho
uld consult all applicable laws and regulations. Compliance with the
22

provisions of this standard does not imply compliance to any applicable regulatory requirements.
23

Implementers of the standard are responsible for observing or referring to the applicable
regulatory
24

requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in
25

compliance with applicable laws, and these documents may not be construed as doing so.

26

Copyrights

27

This document is copyrighted by the IEEE. I
t is made available for a wide variety of both public and
28

private uses. These include both use, by reference, in laws and regulations, and use in private self
-
29

regulation, standardization, and the promotion of engineering practices and methods. By making th
is
30

document available for use and adoption by public authorities and private users, the IEEE does not waive
31

any rights in copyright to this document.

32

IEEE P11073
-
10201/D1.1, November 2010

v

Copyright © 2010 IEEE. All rig
hts reserved.

This is an unapproved IEEE Standards Draft, subject to change.

Updating of IEEE documents

1

Users of IEEE standards should be aware that these documents may be superseded
at any time by the
2

issuance of new editions or may be amended from time to time through the issuance of amendments,
3

corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
4

document together with any amen
dments, corrigenda, or errata then in effect. In order to determine whether
5

a given document is the current edition and whether it has been amended thro
ugh the issuance of
6

amendments,
corrigenda, or errata, visit the IEEE Standards Association web

site
at
7

http://ieeexplore.ieee.org/xpl/standards.jsp
, or contact the IEEE at the address listed previously.

8

For more information about the IEEE Standards Association or the IEEE standards development pr
ocess,
9

visit the IEEE
-
SA web

site at
http://standards.ieee.org
.

10

Errata

11

Errata, if any, for this and all other standards can be accessed at the following URL:

12

http://standards.ieee.org/reading/ieee/updates/errata/index.htm
l
. Users are encouraged to check this URL

13

for errata periodically.

14

Interpretations

15

Current interpretations can be accessed at the following URL:

http://standards.ieee.org/reading/ieee/interp/

16

index.html
.

17

Patents

18

[If the IEEE has not received letters of assurance prior to the time of publication, the following notice
19

shall appear:]

20

Attention is cal
led to the possibility that implementation of this

standard

may require use of subject matter
21

covered by patent rights. By publication of this

standard
, no position is taken with respect to the existence
22

or validity of any patent rights in connection therewith. The IEEE is not responsible for id
entifying
23

Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity
24

or scope of Patents Claims or determining whether any licensing terms or conditions provided in
25

connection with submission of a Letter o
f Assurance, if any, or in any licensing agreements are reasonable
26

or non
-
discriminatory. Users of this

standard

are expressly advised that determin
ation of the validity of any
27

patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further
28

information may be obtained from the IEEE Standards Association.

29

[The following notice shall appear when the IEEE receive
s assurance from a known patent holder or
30

patent applicant prior to the time of publication that a license will be made available to all applicants
31

either without compensation or under reasonable rates, terms, and conditions that are demonstrably free
32

of a
ny unfair discrimination.]

33

Attention is called to the possibil
ity that implementation of this

standard

may require use of subject matter
34

covered by
patent

rights. By publication of this

standard
, no position is taken with respect to the existence
35

or validity of any patent rights in connection th
erewith. A patent holder or patent applicant has filed a
36

statement of assurance that it will grant licenses under these rights without compensation or under
37

reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair
38

dis
crimination to applicants desiring to obtain such licenses. Other Essential Patent Claims may exist for
39

IEEE P11073
-
10201/D1.1, November 2010

vi

Copyright © 2010 IEEE. All rig
hts reserved.

This is an unapproved IEEE Standards Draft, subject to change.

which a statement of assurance has not been received. The IEEE is not responsible for identifying Essential
1

Patent Claims for which a license may be req
uired, for conducting inquiries into the legal validity or scope
2

of Patents Claims, or determining whether any licensing terms or conditions provided in connection with
3

submission of a Letter of Assurance, if any, or in any licensing agreements are reasona
ble or no
n
-
4

discriminatory. Users of this

standard

are expressly advised that determination of the validity of any patent
5

rights, and the risk of inf
ringement of such rights, is entirely their own responsibility. Further information
6

may be obtained from the IEEE Standards Association.

7

8

IEEE P11073
-
10201/D1.1, November 2010

vii

Copyright © 2010 IEEE. All rig
hts reserved.

This is an unapproved IEEE Standards Draft, subject to change.

Participants

1

At the time this draft

standard

was
submitted to the IEEE
-
SA Standards Board for approval
, the
Point
-
of
-
2

Care Devices

Working Group had the following membership:

3

Todd Cooper
,

Chair

4

Jan Wittenber
,
Vice Chair

5


6

Wolfgang Bleicher

7

Francis Cantraine

8

Thomas Canup

9

Mats Cardell

10

Michael Chil
bert

11

Michael Flötotto

12

Ken Fuchs

13

Kai Hassing

14

Gunther Hellmann

15

16

Jörg Kampmann

17

Ron Kirkham

18

Michael Krämer

19

Alberto Macerata

20

Simon Meij

21

Angelo Rossi Mori

22

Thomas Norgall

23

Daniel Nowicki

24

Thoma
s Penzel

25

Francesco Pinciroli

26

27

Melvin Reynolds

28

Paul Rubel



29

Lief Rystrom



30

Paul Schluter



31

Michael Spicer



32

Alpo Värri


33

Jan Wittenber



34

Paul Woolman

35

Christoph Zywietz



36


37


38

The following members of the individual balloting committee voted on this

standard
. Balloters may have
39

voted for approval, disapproval, or abstention.

40


41

Thomas Canup

42

Michael Chilbert

43

Keith Chow

44

Todd H. Cooper

45

Grace Esche

46

Ken
neth Fuchs

47

48

John Grider

49

Kai Hassing

50

Tom Kannally

51

Robert Kennelly

52

Randall Krohn

53

Yeou
-
Song Lee

54

Daniel Nowicki

55

56

Melvin Reynolds

57

Michael Spicer

58

Richard Schrenker

59

M. Michael Shabot

60

Lars Steubesand

61

Gin
-
shu Young
62


63


64

When the IEEE
-
SA Standards Board approved this

standard

on
24 June 2004
, it had the following
65

membership:

66

Don Wright
,

Chair

67

Steve M. Mills
,

Vice Chair

68

Judith Gorman
,

Secretary

69


70

Chuck Adams

71

H. Step
hen Berger

72

Mark D. Bowman

73

Joseph A. Bruder

74

Bob Davis

75

Roberto de Marca Boisson

76

Julian Forster*

77

Arnold M. Greenspan

78

79

Mark S. Halpin

80

Raymond Hapeman

81

Richard J. Holleman

82

Richard H. Hulett

83

Lowell G. Johnson

84

Joseph L. Koepfinger*

85

Hermann Koch

86

Thomas J. McG
ean

87

Daleep C. Mohla

88

89

Paul Nikolich

90

T. W. Olsen

91

Ronald C. Petersen

92

Gary S. Robinson

93

Frank Stone

94

Malcolm V. Thaden

95

Doug Topping

96

Joe D. Watson

97

*Member Emeritus

98


99


100

Also included are the following nonvoting IEEE
-
SA Standards Board liaisons:

101

Satish K. Agg
arwal
,

NRC

Representative

102

Richard DeBlasio
,

DOE

Representative

103

Alan Cookson
,
NIST

Representative

104

IEEE P11073
-
10201/D1.1, November 2010

vii

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.


1

Don Messina

2

IEEE Standards Program Manager,
Document

Development

3


4

<Name>

5

IEEE Standards Program Manager, Technical Program Development

6


7

8

IEEE P11073
-
10201/D1.1, November 2010

viii

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

Contents

1

1.

Scope

................................
................................
................................
................................
................................
.............

1

2

2. Normat ive references
................................
................................
................................
................................
..................

1

3

3. Definit ions

................................
................................
................................
................................
................................
....

4

4

4. Abbreviations an
d acronyms

................................
................................
................................
................................
.....

8

5

5. General requirements
................................
................................
................................
................................
..................

9

6

6. DIM
................................
................................
................................
................................
................................
..............

10

7

6.1 General
................................
................................
................................
................................
................................
.

10

8

6.2 Package diagram

overview

................................
................................
................................
.............................

13

9

6.3 Model
for the Medical Package
................................
................................
................................
.......................

14

10

6.4 Model for the Alert Package

................................
................................
................................
............................

18

11

6.5 Model for the System Package

................................
................................
................................
........................

20

12

6.6 Model for the Control Package
................................
................................
................................
........................

23

13

6
.7 Model for the Extended Services Package

................................
................................
................................
....

26

14

6.8 Model for the Communication Package
................................
................................
................................
.........

29

15

6.9 Model for the Archival Package
................................
................................
................................
......................

31

16

6.10 Model for the Patient Package
................................
................................
................................
.......................

34

17

6.11 DIM

dynamic model
................................
................................
................................
................................
....

34

18

7. DIM object definitions

................................
................................
................................
................................
.............

39

19

7.1 General
................................
................................
................................
................................
................................
.

39

20

7.2 Top Object
................................
................................
................................
................................
...........................

49

21

7.3 Objects in the
Medical Package

................................
................................
................................
......................

50

22

7.4 Objects in the Alert Package
................................
................................
................................
............................

87

23

7.5 Objects in the System Package

................................
................................
................................
........................

93

24

7.6 Objects in the Control Package

................................
................................
................................
.....................

112

25

7.7 O
bjects in the Extended Services Package

................................
................................
................................
..

128

26

7.8 Objects in the Communication Package

................................
................................
................................
......

140

27

7.9 Objects in the Archival Package

................................
................................
................................
...................

149

28

7.10 Objects in the Patient Package

................................
................................
................................
....................

156

29

8. Service model for communicating systems

................................
................................
................................
........

160

30

8.1 General
................................
................................
................................
................................
...............................

160

31

8.2 Communicat ing systems
................................
................................
................................
................................
.

160

32

8.3 General service model overview

................................
................................
................................
...................

160

33

8.4 General object management services definit ion

................................
................................
.........................

163

34

9. MDIB nomenclature

................................
................................
................................
................................
...............

169

35

10. Conformance model
................................
................................
................................
................................
..............

169

36

10.1 Applicability

................................
................................
................................
................................
...................

169

37

10.2 Conformance specification

................................
................................
................................
..........................

170

38

10.3 ICSs
................................
................................
................................
................................
................................
..

171

39


40


41

IEEE P11073
-
10201/D1.1, November 2010

1

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

Draft

Standard

for
Health informatics
1



Point
-
of
-
care medical device
2

communication


Part 10201:
3

Domain information model

4

IMPORTANT NOTICE: This standard is not intended to
ensure

safety, security, health, or
5

environmental

protection
. Imple
menters of the standard are responsible for determining appropriate
6

safety, security, environmental, and health practices or regulatory requirements.

7

This IEEE document is made available for use subject to important notices and legal disclaimers.

8

These no
tices and disclaimers appear in all publications containing this document and may

9

be found under the heading “Important Notice” or “Important Notices and Disclaimers

10

Concerning IEEE Documents.”
They can also be obtained on request from IEEE or viewed at
11

http://standards.ieee.org/IPR/disclaimers.html
.

12

1.

Scope

13

Within the context of the ISO/IEEE 11073 family of standards, this standard addresses the definition and
14

structuring of information that

is communicated or referred to in communication between application
15

entities.

16

This standard provides a common representation of all application entities present in the application
17

processes within the various devices independent of the syntax.

18

The definit
ion of association control and lower layer communication is outside the scope of this standard.

19

2.

Normative references

20

The following referenced documents are indispensable for the application of this document (i.e., they must
21

be understood and used, so each
referenced document is cited in text and its relationship to this document is
22

explained). For dated references, only the edition cited applies. For undated references, the latest edition of
23

the referenced document (including any amendments or corrigenda) a
pplies.

24

IEEE P11073
-
10201/D1.1, November 2010

2

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

CEN EN 1064, Medical informatics


Standard communication protocol


computer
-
assisted
1

electrocardiography.
1

2

CEN ENV 12052, Medical informatics


Medical imaging communication (MEDICOM).

3

IEEE Std 1073™, IEEE Standard for Medical Device Communi
catio
ns

Overview and Framework.
2


4

IETF RFC 1155, Structure and Identification of Management Information for TCP/IP
-
Based Internets.
3

5

ISO 639
-
1, Code for the representation of names of languages


Part 1: Alpha
-
2 code.
4

6

ISO 639
-
2, Codes for the representation of

names of languages


Part 2: Alpha
-
3 code.

7

ISO 3166
-
1, Codes for the representation of names of countries and their subdivisions


Part 1: Country
8

codes.

9

ISO 3166
-
2, Codes for the representation of names of countries and their subdivisions


Part 2: Count
ry
10

subdivision code.

11

ISO 3166
-
3, Codes for the representation of names of countries and their subdivisions


Part 3: Code for
12

formerly used names of countries.

13

ISO 8601, Data elements and interchange formats


Information interchange


Representation of da
tes
14

and times.

15

ISO 15225, Nomenclature


Specification for a nomenclature system for medical devices for the purpose
16

of regulatory data exchange.

17

ISO/IEC 646, Information technology


ISO 7
-
bit coded character set for information interchange.
5

18

ISO/IEC 2022
, Information technology


Character code structure and extension techniques.

19

ISO/IEC 5218, Information technology


Codes for the representation of human sexes.

20

ISO/IEC 7498
-
1, Information technology


Open systems interconnection


Basic reference model


21

Part 1: The basic model.

22

ISO/IEC 7498
-
2, Information processing systems


Open systems interconnection


Basic reference
23

model


Part 2: Security architecture.

24

ISO/IEC 7498
-
3, Information processing systems


Open systems interconnection


Basic referenc
e
25

model


Part 3: Naming and addressing.

26




1

CEN publications are available from the European Committee for Standardization (CEN), 36, rue de Stassart, B
-
1050 Brussels,
Belgium (http://www.cenorm.be).

2

IEEE publications are available from the Institute of Electrical and

Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854,

USA (http://www.standards.ieee.org/).

3

Internet requests for comment (RFCs) are available from the Internet Engineering Task Force at http://www.ietf.org/.

4

ISO publications are available from
the ISO Central Secretariat, Case Postale 56, 1 rue de Varembé, CH
-
1211, Genève 20,
Switzerland/Suisse (http://www.iso.ch/). ISO publications are also available in the United States from the Sales Department,
American

National Standards Institute, 25 West
43rd Street, 4th Floor, New York, NY 10036, USA (http://www.ansi.org/).

5

ISO/IEC documents can be obtained from the ISO office, 1 rue de Varembé, Case Postale 56, CH
-
1211, Genève 20, Switzerland/

Suisse (http://www.iso.ch/) and from the IEC office, 3 rue
de Varembé, Case Postale 131, CH
-
1211, Genève 20, Switzerland/Suisse

(http://www.iec.ch/). ISO/IEC publications are also available in the United States from the Sales Department, American Nation
al
Standards Institute, 25 West 43rd Street, 4th Floor, New Yo
rk, NY 10036, USA (http://www.ansi.org/).

IEEE P11073
-
10201/D1.1, November 2010

3

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

ISO/IEC 7498
-
4, Information processing systems


Open systems interconnection


Basic reference
1

model


Part 4: Management framework.

2

ISO/IEC 8649, Information processing systems


Open systems interconnection


Ser
vice definition for
3

the Association Control Service Element.

4

ISO/IEC 8650
-
1, Information technology


Open systems interconnection


Connection
-
Oriented
5

Protocol for the Association Control Service Element


Part 1: Protocol.

6

ISO/IEC 8650
-
2, Information te
chnology


Open systems interconnection


Protocol Specification for
7

Association Control Service Element


Part 2: Protocol Implementation Conformance Statements (PICS)
8

proforma.

9

ISO/IEC 8824
-
1, Information technology


Abstract Syntax Notation One (ASN.1)



Part 1:
10

Specification of basic notation.

11

ISO/IEC 8824
-
2, Information technology


Abstract Syntax Notation One (ASN.1)


Part 2: Information
12

object specification.

13

ISO/IEC 8859
-
n, Information processing


8
-
bit single
-
byte coded graphic character sets


Part 1 to Part
14

15: Various alphabets.

15

ISO/IEC 9545, Information technology


Open systems interconnection


Application layer structure.

16

ISO/IEC 9595, Information technology


Open systems interconnection


Common management
17

information service definition.

18

ISO/IEC 9596
-
1, Information technology


Open systems interconnection


Common Management
19

Information Protocol


Part 1: Specification.

20

ISO/IEC 10040, Information technology


Open systems interconnection


Systems management
21

overview.

22

ISO/IEC 10164
-
1, In
formation technology


Open systems interconnection


Systems management


23

Part 1: Object management function.

24

ISO/IEC 10164
-
2, Information technology


Open systems interconnection


Systems management


25

Part 2: State management function.

26

ISO/IEC 10164
-
3,

Information technology


Open systems interconnection


System management


27

Part 3: Attributes for representing relationships.

28

ISO/IEC 10164
-
4, Information technology


Open systems interconnection


Systems management


29

Part 4: Alarm reporting function.

30

ISO/IEC 10164
-
5, Information technology


Open systems interconnection


Systems management


31

Part 5: Event management function.

32

ISO/IEC 10164
-
6, Information technology


Open systems interconnection


Systems management


33

Part 6: Log control function.

34

ISO
/IEC 10164
-
7, Information technology


Open systems interconnection


Systems management


35

Part 7: Security alarm reporting function.

36

IEEE P11073
-
10201/D1.1, November 2010

4

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

ISO/IEC 10164
-
8, Information technology


Open systems interconnection


Systems management


1

Part 8: Security audit trail

function.

2

ISO/IEC 10164
-
9, Information technology


Open systems interconnection


Systems management


3

Part 9: Objects and attributes for access control.

4

ISO/IEC 10164
-
10, Information technology


Open systems interconnection


Systems management


5

Part
10: Usage metering function for accounting purposes.

6

ISO/IEC 10164
-
11, Information technology


Open systems interconnection


Systems management


7

Part 11: Metric objects and attributes.

8

ISO/IEC 10164
-
12, Information technology


Open systems interconnect
ion


Systems management


9

Part 12: Test management function.

10

ISO/IEC 10164
-
13, Information technology


Open systems interconnection


Systems management


11

Part 13: Summarization function.

12

ISO/IEC 10164
-
14, Information technology


Open systems interconne
ction


Systems management


13

Part 14: Confidence and diagnostic test categories.

14

ISO/IEC 10165
-
1, Information technology


Open systems interconnection


Structure of management
15

information


Part 1: Management information model.

16

ISO/IEC 10165
-
2, Informati
on technology


Open systems interconnection


Structure of management
17

information


Part 2: Definition of management information.

18

ISO/IEC 10646
-
1, Information technology


Universal multiple
-
octet coded character set (UCS)


Part
19

1: Architecture and basic

multilingual plane.

20

ISO/IEEE 11073
-
10101, Health informatics


Point
-
of
-
care medical device communication


Part
21

10101: Nomenclature.

22

ISO/IEEE 11073
-
20101, Health informatics


Point
-
of
-
care medical device communication


Part
23

20101: Application profiles


Base standard.

24

NEMA PS 3, Digital imaging and communications in medicine (
DICOM
).
6

25

3.

Definitions

26

As of June 2009, please use the fo
llowing introductory paragraph and
there is no
27

requirement to number definitions. Please refer to the 2009 Style Manual for
28

updates (
http://standards.ieee.org/guides/style/2009_Style_Manual.pdf
).

29

To format terms and definitions in the IEEE
-
SA word template, you may NOW
30

simply bold the "term:" and us
e regular body text (IEEEStds Paragraph style) for
31

the definitions. DO NOT USE the IEEEStds Definitions or IEEEStds
32

DefTerms+Numbers style. However,
if the definitions have already been
33

numbered
with the template tool, STAFF will remove the numbering duri
ng the
34




6

NEMA publications are available from Global Engineering Documents, 15 Inverness Way East, Englewood, Colorado 80112, USA
(http://global.ihs.com/).

IEEE P11073
-
10201/D1.1, November 2010

5

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

publication process. (NOTE: There are instances when a draft will need to
1

number terms
-

please consult with an IEEE
-
SA editor). A new version of the
2

template is being designed and tested to deal with the new definitions options.
3

(2.2010).

4


5


6

For the

purposes of this document, the following terms and definitions apply.
The
IEEE Standards
7

Dictionary: Glossary of Terms & Definitions

should be referenced for terms not defined in this clause.
7


8

agent
: Device that provides data in a manager
-
agent communica
ting system.

9

alarm
: Signal that indicates abnormal events occurring to the patient or the device system.

10

alert
: Synonym for the combination of patient
-
related physiological alarms, technical alarms, and equip
-
11

ment
-
user advisory signals.

12

alert monitor
: Obje
ct representing the output of a device or system alarm processor and as such the overall
13

device or system alarm condition.

14

alert status
: Object representing the output of an alarm process that considers all alarm conditions in a
15

scope that spans one or mor
e objects.

16

archival
: Relating to the storage of data over a prolonged period.

17

association control service element (ACSE)
: Method used to establish logical connections between
18

medical device systems (MDSs).

19

channel
: Umbrella object in the object model that
groups together physiological measurement data and
20

data derived from these data.

21

class
: Description of one or more objects with a uniform set of attributes and services including a
22

description of how to create new objects in the class.

23

communication contro
ller
: Part of a medical device system (MDS) responsible for communications.

24

communication party
: Actor of the problem domain that participates in the communication in that
25

domain.

26

communication role
: Role of a party in a communication situation defining th
e party’s behavior in the
27

communication. Associated with a communication role is a set of services that the party provides to other
28

parties.

29

data agent
: As a medical device, a patient data acquisition system that provides the acquired data for other
30

device
s.

31

data format
: Arrangement of data in a file or stream.

32

data logger
: A medical device that is functioning in its capacity as a data storage and archival system.

33

data structure
: Manner in which application entities construct the data set information result
ing from the
34

use of an information object.

35




7

The

IEEE Standards Dictionary: Glossary of Terms & Definitions

is available at
http://shop.ieee.org/
.

IEEE P11073
-
10201/D1.1, November 2010

6

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

dictionary
: Description of the contents of the medical data information base (MDIB) containing vital signs
1

information, device information, demographics, and other elements of the MDIB.

2

discrete parameter
: Vital s
igns measurement that can be expressed as a single numeric or textual value.

3

domain information model (DIM)
: The model describing common concepts and relationships for a
4

problem domain.

5

event
: A change in device status that is communicated by a notificatio
n reporting service.

6

event report
: Service [provided by the common medical device information service element (CMDISE)] to
7

report an event relating to a managed object instance.

8

framework
: A structure of processes and specifications designed to support the

accomplishment of a
9

specific task.

10

graphic parameter
: Vital signs measurement that requires a number of regularly sampled data points in
11

order to be expressed properly.

12

host system
: Term used as an abstraction of a medical system to which measurement devi
ces are attached.

13

information object
: An abstract data model applicable to the communication of vital signs information and
14

related patient data. The attributes of an information object definition describe its properties. Each
15

information object definition

does not represent a specific instance of real
-
world data, but rather a class of
16

data that share the same properties.

17

information service element
: Instances in the medical data information base (MDIB).

18

instance
: The realization of an abstract concept or s
pecification, e.g., object instance, application instance,
19

information service element instance, virtual medical device (VMD) instance, class instance, operating
20

instance.

21

intensive care unit (ICU)
: The unit within a medical facility in which patients are
managed using multiple
22

modes of monitoring and therapy.

23

interchange format
: The representation of the data elements and the structure of the message containing
24

those data elements while in transfer between systems. The interchange format consists of a data

set of
25

construction elements and a syntax. The representation is technology specific.

26

interoperability
: Idealized scheme where medical devices of differing types, models, or manufacturers are
27

capable of working with each other, whether connected to each o
ther directly or through a communication
28

system.

29

latency
: In a communications scenario, the time delay between sending a signal from one device and
30

receiving it by another device.

31

lower layers
: Layer 1 to Layer 4 of the International Organization for Stand
ardization (ISO)/open systems
32

interconnection (OSI) reference model. These layers cover mechanical, electrical, and general
33

communication protocol specifications.

34

manager
: Device that receives data in a manager
-
agent communicating system.

35

manager
-
agent mod
el
: Communication model where one device (i.e., agent) provides data and another
36

device (i.e., manager) receives data.

37

IEEE P11073
-
10201/D1.1, November 2010

7

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

medical data information base (MDIB)
: The concept of an object
-
oriented database storing (at least) vital
1

signs information.

2

medical devi
ce
: A device, apparatus, or system used for patient monitoring, treatment, or therapy, which
3

does not normally enter metabolic pathways. For the purposes of this standard, the scope of medical
4

devices is further limited to patient
-
connected medical devices

that provide support for electronic
5

communications.

6

medical device system (MDS)
: Abstraction for system comprising one or more medical functions. In the
7

context of this standard, the term is specifically used as an object
-
oriented abstraction of a device
that
8

provides medical information in the form of objects that are defined in this standard.

9

monitor
: A medical device designed to acquire, display, record, and/or analyze patient data and to alert
10

caregivers of events needing their attention.

11

object
: A con
cept, an abstraction, or a thing with crisp boundaries and a meaning for the problem at hand.

12

object attributes
: Data that, together with methods, define an object.

13

object class
: A descriptor used in association with a group of objects with similar propert
ies (i.e.,
14

attributes), common behavior (i.e., operations), common relationships to other objects, and common
15

semantics.

16

object diagram
: Diagram showing connections between objects in a system.

17

object method
: A procedure or process acting upon the attribut
es and states of an object class.

18

object
-
oriented analysis
: Method of analysis where the problem domain is modelled in the form of objects
19

and their interactions.

20

open system
: A set of protocols allowing computers of different origins to be linked together
.

21

operation
: A function or transformation that may be applied to or by objects in a class (sometimes also
22

called service).

23

problem domain
:

The field of health care under consideration in a modeling process.

24

protocol
: A standard set of rules describing the
transfer of data between devices. It specifies the format of
25

the data and specifies the signals to start, control, and end the transfer.

26

scanner
: An observer and “summarizer” of object attribute values.

27

scenario
: A formal description of a class of business

activities including the semantics of business
28

agreements, conventions, and information content.

29

service
: A specific behavior that a communication party in a specific role is responsible for exhibiting.

30

syntax
(i.e., of an interchange format):

The rules f
or combining the construction elements of the
31

interchange format.

32

system
: The demarcated part of the perceivable universe, existing in time and space, that may be regarded
33

as a set of elements and relationships between these elements.

34

timestamp
: An attribu
te or field in data that denotes the time of data generation.

35

IEEE P11073
-
10201/D1.1, November 2010

8

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

top object
: The ultimate base class for all other objects

belonging to one model.

1

upper layers
: Layer 5 to Layer 7 of the International Organization for Standardization (ISO)/open systems
2

interc
onnection (OSI) reference model. These layers cover application, presentation, and session
3

specifications and functionalities.

4

virtual medical device (VMD)
: An abstract representation of a medical
-
related subsystem of a medical
5

device system (MDS).

6

virtual

medical object (VMO)
: An abstract representation of an object in the Medical Package of the
7

domain information model (DIM).

8

vital sign
: Clinical information, relating to one or more patients, that is measured by or derived from
9

apparatus connected to the
patient or otherwise gathered from the patient.

10

waveform
: Graphic data, typically vital signs data values varying with respect to time, usually presented to
11

the clinician in a graphical form.

12

4.

Abbreviations and acronyms

13

ACSE

association control service elem
ent

14

ASN.1

Abstract Syntax Notation One

15

BCC

bedside communication controller

16

BER

basic encoding rules

17

BMP

basic multilingual plane

18

CMDIP

Common Medical Device Information Protocol

19

CMDISE

common medical device information service element

20

CMIP

Common Manageme
nt Information Protocol

21

CMISE

common management information service element

22

DCC

device communication controller

23

DICOM

digital imaging and communications in medicine

24

DIM

domain information model

25

ECG

electrocardiogram

26

EEG

electroencephalogram

27

EBWW

eyeball an
d wristwatch

28

FSM

finite state machine

29

GMDN

Global Medical Device Nomenclature

30

GMT

Greenwich mean time

31

IANA

Internet Assigned Numbers Authority

32

ICS

implementation conformance statement

33

ICU

intensive care unit

34

ID

identifier or identification

35

IEEE P11073
-
10201/D1.1, November 2010

9

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

LAN

local area n
etwork

1

LSB

least significant bit

2

MDIB

medical data information base

3

MDS

medical device system

4

MEDICOM

medical imaging communication

5

MIB or Mib

management information base

6

MOC

managed object class

7

OID

object identifier

8

OR

operating room

9

OSI

open systems int
erconnection

10

PC

personal computer

11

PDU

protocol data unit

12

PM

persistent metric

13

SCADA

supervisory control and data acquisition

14

SCP ECG

Standard Communications Protocol [for computer
-
assisted] Electrocardiography

15

SNMP

Simple Network Management Protocol

16

SNTP

S
imple Network Time Protocol

17

UML

unified modeling language

18

UTC

coordinated universal time

19

VMD

virtual medical device

20

VMO

virtual medical object

21

VMS

virtual medical system

22

5.

General requirements

23

The ISO/IEEE 11073 family of standards is intended to enable medi
cal devices to interconnect and inter
-
24

operate with other medical devices and with computerized healthcare information systems in a manner
25

suitable for the clinical environment.

26

The ISO/IEEE 11073 family is based on an object
-
oriented systems management par
adigm. Data (e.g.,
27

measurement, state) is modeled in the form of information objects that can be accessed and manipulated
28

using an object access service protocol.

29

The domain information model (DIM) defines the overall set of information objects and their a
ttributes,
30

methods, and access functions needed for medical device communication.

31

The top
-
level user requirements a
re defined in IEEE Std 1073,
8

which also defines the user scenarios
32

covered by the ISO/IEEE 11073 family of standards.

33

As a part of the ISO/I
EEE 11073 family of standards, the primary requirements for the DIM are as follows:

34




8

Information on references can be found in Clause 2.

IEEE P11073
-
10201/D1.1, November 2010

10

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.



Define an object
-
oriented model representing the relevant information (i.e., data) and functions
1

(e.g., device controls) encountered in the problem domain of medical device

communication,
2

including measurement information, contextual data, device control methods, and other relevant
3

aspects.

4



Provide detailed specification of the information objects defined in the object
-
oriented model,
5

including their attributes and methods.

6



Define a service model for communicating medical devices that provides access to the information
7

objects, their attributes, and their methods.

8



Use the nomenclature defined in ISO/IEEE 11073
-
10101 to identify all data elements in the model.

9



Be usable for th
e definition of data communication protocols as well as for the definition of file
10

storage formats.

11



Define conformance requirements.

12



Be extensible and expandable to incorporate future needs in the defined modeling framework.

13

6.

DIM

14

6.1

General

15

6.1.1

Modeling concept

16

Th
e DIM is an object
-
oriented model that consists of objects, their attributes, and their methods, which are
17

abstractions of real
-
world entities in the domain of (vital signs information communicating) medical
18

devices.

19

The information model and the service m
odel for communicating systems defined and used in this standard
20

are conceptually based on the International Organization for Standardization (ISO)/open systems
21

interconnection (OSI) system management model. Objects defined in the information model are con
sidered
22

managed (here, medical) objects. For the most part, they are directly available to management (i.e., access)
23

services provided by the common medical device information service element (CMDISE) as defined in this
24

standard.

25

For communicating systems,

the set of object instances available on any medical device that complies with
26

the definitions of this standard forms the medical data information base (MDIB). The MDIB is a structured
27

collection of managed medical objects representing the vital signs inf
ormation provided by a particular
28

medical device. Attribute data types, hierarchies, and behavior of objects in the MDIB are defined in this
29

standard.

30

The majority of objects defined here represent generalized vital signs data and support information.
31

Spec
ialization of these objects is achieved by defining appropriate attributes. Object hierarchies and
32

relations between objects are used to express device configuration and device capabilities.

33

Example
: A generalized object is defined to represent vital signs

in the form of a real
-
time waveform.
34

A set of object attributes is used to specify a particular waveform as an invasive arterial blood pressure.
35

The position in the hierarchy of all objects defines the subsystem that derives the waveform.

36

Figure 1

shows the relation between managed medical objects, MDIB, CMDISE, application processes, and
37

communication systems.

38

IEEE P11073
-
10201/D1.1, November 2010

11

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.


1

Figure 1


MDIB in communicating s
ystems

2


3

In the case of communicating systems, managed medical objects are accessible only th
rough services
4

provided by CMDISE. The way that these objects are stored in the MDIB in any specific system and the
5

way applications and the CMDISE access these objects are implementation issues and as such not
6

normative.

7

In the case of a vital signs archi
ved data format that complies with the definitions in this standard, object
8

instances are stored, together with their dynamic attribute value changes, over a certain time period on
9

archival media. Attribute data types and hierarchies of objects in the arch
ival data format are again defined
10

in this standard.

11

Figure 2

shows the relationship between managed medical objects, the data archive, and archive access
12

services.

13

In the case of the archived data format, the way managed medic
al objects are stored on a medium is the
14

subject of standardization. The access services are a local implementation issue and as such are not
15

intended to be governed by this standard.

16

IEEE P11073
-
10201/D1.1, November 2010

12

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.


1

Figure 2


Managed m
e
dical objects in a vital signs a
rchive

2


3

6.1.2

Scope of the DIM

4

6.1.2.1

Ge
neral

5

Vital signs information objects that are defined in this standard encompass digitized biosignals that are
6

derived by medical measurement devices used, for example, in anaesthesia, surgery, infusion therapy,
7

intensive care, and obstetrical care.

8

Biosi
gnal data within the scope of this standard include direct and derived, quantitative and qualitative
9

measurements, technical and medical alarms, and control settings. Patient information relevant for the
10

interpretation of these signals is also defined in t
he DIM.

11

6.1.2.2

Communicating systems

12

Communicating systems within the scope of this standard include physiological meters and analysers,
13

especially systems providing real
-
time or continuous monitoring. Data processing capabilities are required
14

for these systems.

15

Information management objects that provide capabilities and concepts for cost
-
effective communication
16

(specifically data summarization objects) and objects necessary to enable real
-
time communication are also
17

within the scope of the information model in t
his standard.

18

Interoperability issues, specifically lower communication layers, temporal synchronization between
19

multiple devices, etc., are outside the scope of this standard.

20

6.1.2.3

Archived vital signs

21

Context information objects that describe the data acquisi
tion process and organize a vital signs archive are
22

within the scope of this standard.

23

IEEE P11073
-
10201/D1.1, November 2010

13

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

6.1.3

Approach

1

For the object
-
oriented modeling, the unified modeling language (UML) technique is used. The domain is
2

first subdivided into different packages, and this subdiv
ision permits the organization of the model into
3

smaller packages. Each package is then defined in the form of object diagrams. Objects are briefly
4

introduced, and their relations and hierarchies are defined in the object diagram.

5

For the object definition
s, a textual approach is followed. Attributes are defined in attribute definition
6

tables. Attribute data types are defined using Abstract Syntax Notation One (ASN.1). Object behavior and
7

notifications generated by objects are also defined in definition tab
les. These definitions directly relate to
8

the service model specified in Clause
8
.

9

6.1.4

Extension of the model

10

It is expected that over time extensions of the model may be needed to account for new developments in the
11

area of medica
l devices. Also, in special implementations, there may be a requirement to model data that
12

are specific for a particular device or a particular application (and that are, therefore, not covered by the
13

general model).

14

In some cases, it may be possible to us
e the concept of external object relations. Most objects defined in
15

this standard provide an attribute group (e.g., the Relationship Attribute Group) that can be used to supply
16

information about related objects that are not defined in the DIM. Supplying su
ch information can be done
17

by specifying a relation to an external object and assigning attributes to this relation (see
7.1.2.20
).

18

In other cases, it may be necessary to define completely new objects or to add new attributes,
new methods,
19

or new events to already defined objects. These extensions are considered private or manufacturer
-
specific
20

extensions. Dealing with these extensions is primarily a matter of an interoperability standard that is based
21

on this standard on vital
signs representation.

22

In general, in an interoperability format, objects, attributes, and methods are identified by nomenclature
23

codes. The nomenclature code space (i.e., code values) leaves room for private extensions. As a general
24

rule, an interoperabili
ty standard that is based on this DIM should be able to deal with private or
25

manufacturer
-
specific extensions by ignoring objects, attributes, etc., with unknown identifiers (i.e.,
26

nomenclature codes).

27

6.2

Package diagram

overview

28

The package diagram organize
s the problem domain into separate groups. It shows the major objects inside
29

each package and defines the relationships between these packets.

30

The package diagram depicted in
Figure 3

contains only a small subset of all objects

defined in the DIM.
31

Common base objects except the Top object are not shown in this diagram. Also, not all relations are
32

shown between the different packages. Refer to the detailed package diagrams for more information.

33

The numbers in the packages refer t
o the corresponding subclauses in this clause about models and in
34

Clause
7

about the object definitions.

35

The Top object is an abstract base class and at the same time the ultimate base class for all objects defined
36

in the model
. For editorial convenience, the modeling diagrams in this standard do not show this
37

inheritance hierarchy.

38

The more detailed models for these packages are contained in
6.3

through
6.10
.

39

IEEE P11073
-
10201/D1.1, November 2010

14

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

6.3

Model for t
he Medical Package

1

The Medical Package deals with the derivation and representation of biosignals and contextual information
2

that is important for the interpretation of measurements.

3

Figure 4

shows the object model of the Medic
al Package.

4


5

Figure 3


Pa
ckages of the DIM

6


7


8

IEEE P11073
-
10201/D1.1, November 2010

15

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.


1

Figure 4


Medical Package m
odel

2


3

NOTE

Instances of the Channel object and the PM
-
Store object shall be contained in exactly one superior object
4

instance. Refer to the Alert Package for information about alarm
-
related objects.

9

5

The Medical Package model contains the objects described in
6.3.1

through
6.3.13
.

6

6.3.1

VMO (i.e., virtual medical object)

7

The VMO is the base class for all medical
-
related objects in the model. It pro
vides consistent naming and
8

identification across the Medical Package model.

9

As a base class, the VMO cannot be instantiated.

10

6.3.2

VMD (i.e., virtual medical device) object

11

The VMD object is an abstraction for a medical
-
related subsystem (e.g., hardware or even

pure software) of
12

a medical device. Characteristics of this subsystem (e.g., modes, versions) are captured in this object. At
13

the same time, the VMD object is a container for objects representing measurement and status information.

14




9

Notes in text, tables, and figures are given for information only, and do not contain requirements needed to implement the

standard.

IEEE P11073
-
10201/D1.1, November 2010

16

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

Example
: A modular pati
ent monitor provides measurement modalities in the form of plug
-
in
1

modules. Each module is represented by a VMD object.

2

6.3.3

Channel object

3

The Channel object is used for grouping Metric objects and, thus, allows hierarchical information
4

organization. The Chann
el object is not mandatory for representation of Metric objects in a VMD.

5

Example
: A blood pressure VMD may define a Channel object to group together all metrics that deal
6

with the blood pressure (e.g., pressure value, pressure waveform). A second Channel
object can be
7

used to group together metrics that deal with heart rate.

8

6.3.4

Metric object

9

The Metric object is the base class for all objects representing direct and derived, quantitative and
10

qualitative biosignal measurement, status, and context data.

11

Special
izations of the Metric object are provided to deal with common representations (e.g., single values,
12

array data, status indications) and presentations (e.g., on a display) of measurement data.

13

As a base class, the Metric object cannot be instantiated.

14

6.3.5

Nume
ric object

15

The Numeric object represents numerical measurements and status information, e.g., amplitude measures,
16

counters.

17

Example
: A heart rate measurement is represented by a Numeric object.

18

NOTE


A compound Numeric object is defined as an efficient mod
el, for example, for arterial blood pressure, which
19

usually has three associated values (i.e., systolic, diastolic, mean). The availability of multiple values in a single
20

Numeric (or other Metric) object can be indicated in a special structure attribute in

the Metric object.

21

6.3.6

Sample Array object

22

The Sample Array object is the base class for metrics that have a graphical, curve type presentation and,
23

therefore, have their observation values reported as arrays of data points by communicating systems.

24

As a base

class, the Sample Array object cannot be instantiated.

25

6.3.7

Real Time Sample Array object

26

The Real Time Sample Array object is a sample array that represents a real
-
time continuous waveform. As
27

such, it has special requirements in communicating systems, e.g.,
processing power, low latency, high
28

bandwidth. Therefore, it requires the definition of a specialized object.

29

Example
: An electrocardiogram (ECG) real
-
time wave is represented as a Real Time Sample Array
30

object.

31

IEEE P11073
-
10201/D1.1, November 2010

17

Copyright © 2010 IEEE. All rights r
eserved.

This is an unapproved IEEE Standards Draft, subject to change.

6.3.8

Time Sample Array object

1

The Time Sample Arr
ay object is a sample array that represents noncontinuous waveforms (i.e., a wave
2

snippet). Within a single observation (i.e., a single array of sample values), samples are equidistant in time.

3

Example
: Software for ST segment analysis may use the Time Sam
ple Array object to represent
4

snippets of ECG real
-
time waves that contain only a single QRS complex. Within this wave snippet,
5

the software can locate the ST measurement points. It generates a new snippet, for example, every 15
6

s
econds
.

7

6.3.9

Distribution Samp
le Array object

8

The Distribution Sample Array object is a sample array that represents linear value distributions in the form
9

of arrays containing scaled sample values. The index of a value within an observation array denotes a
10

spatial value, not a time po
int.

11

Example
: An electroencephalogram (EEG) application may use a Fourier transformation to derive a
12

frequency distribution (i.e., a spectrum) from the EEG signal. It then uses the Distribution Sample
13

Array object to represent that spectrum in the MDIB.

14

6.3.10

En
umeration object

15

The Enumeration object represents status information and/or annotation information. Observation values
16

may be presented in the form of normative codes (that are included in the nomenclature defined in this
17

standard or in some other nomencl
ature scheme) or in the form of free text.

18

Example
: An ECG rhythm qualification may be represented as an Enumeration object. A ventilator
19

may provide information about its current ventilation mode as an Enumeration object.

20

6.3.11

Complex Metric object

21

In special
cases, the Complex Metric object can be used to group a larger number of strongly related Metric
22

objects in one single container object for performance or for modeling convenience. The Complex Metric
23

object is a composition of Metric objects, possibly recu
rsive.

24

Example
: A ventilator device may provide extensive breath analysis capabilities. For each breath, it
25

calculates various numerical values (e.g., volumes, I:E ratio, timing information) as well as enumerated
26

information (e.g., breath type classificati
on, annotation data). For efficiency, all this information is
27

grouped together in one Complex Metric object instance, which is updated upon each breath.

28

6.3.12

PM
-
Store (i.e., persistent metric) object

29

The PM
-
Store object provides long
-
term storage capabilities f
or metric data. It contains a variable number
30

of PM
-
Segment objects that can be accessed only through the PM
-
Store object. Without further
31

specialization, the PM
-
Store object is intended to store data of a single Metric object only.

32

Example
: A device store
s the numerical value of an invasive blood pressure on a disk. It uses the PM
-
33

Store object to represent this persistent information. Attributes of the PM
-
Store object describe the
34

sampling period, the sampling algorithm, and the storage format. When the la
bel of the pressure
35

measurement is changed (e.g., during a wedge procedure), the storage process opens a new PM
-
36

Segment to store the updated context data (here: the label).

37

IEEE P11073
-
10201/D1.1, November 2010

18

Copyright © 2010 IEEE. All rights r