Modelling-Medical Device

V3DAM_DCM4MEDDEV_R1_I1_2011MAY
Detailed Clinical Model for Medical Devices

Informative
Universal Realm
Second Ballot: May 2011
April 1, 2011
© 2011 Health Level Seven, Inc.

Ann Arbor, MI
All rights reserved.
Pag e |2
Contents
Detailed Clinical Model (DCM) for Medical Devices ....................... Error! Bookmark not defined.
Authors ...................................................................................... Error! Bookmark not defined.
Change History ........................................................................... Error! Bookmark not defined.
Introduction and Objectives ....................................................... Error! Bookmark not defined.
A. Approach ............................................................................... Error! Bookmark not defined.
3. Analysis Information Model ................................................. Error! Bookmark not defined.
4. Detailed Clinical Models ...................................................... Error! Bookmark not defined.
1. Business/Clinical Use Cases .................................................... Error! Bookmark not defined.
Business Actors ....................................................................... Error! Bookmark not defined.
1.1 Intubate Patient................................................................. Error! Bookmark not defined.
1.2 Manage Patient on Ventilator ............................................ Error! Bookmark not defined.
1.3 Liberate Patient from Ventilator ........................................ Error! Bookmark not defined.
1.4 Transport Post-Operative Patient ...................................... Error! Bookmark not defined.
1.5 Included Technical Use Cases ............................................ Error! Bookmark not defined.
2. Clinical Workflows .................................................................. Error! Bookmark not defined.
2.1 Intubate Patient Workflow ................................................ Error! Bookmark not defined.
2.2 Manage Patient On Ventilator Workflow ........................... Error! Bookmark not defined.
2.3 Liberate Patient from Ventilator, Planned Workflow ......... Error! Bookmark not defined.
2.4 Post-Operative Patient Transport ...................................... Error! Bookmark not defined.
2.5 Referenced Technical Workflows ....................................... Error! Bookmark not defined.
3. Analysis Information Model .................................................... Error! Bookmark not defined.
3.1 Information Analysis .......................................................... Error! Bookmark not defined.
3.2 Medical Devices General Requirements ............................. Error! Bookmark not defined.
3.3 Intubation Clinical Note ..................................................... Error! Bookmark not defined.
3.4 Assessment........................................................................ Error! Bookmark not defined.
4. Detailed Clinical Models ......................................................... Error! Bookmark not defined.
4.1 Medical Device Settings and Configuration ........................ Error! Bookmark not defined.
4.2 Medical Device Measurements .......................................... Error! Bookmark not defined.
4.3 Medical Supplies ................................................................ Error! Bookmark not defined.
5. Data Types ............................................................................. Error! Bookmark not defined.
Annexes ..................................................................................... Error! Bookmark not defined.
Annex A: Clinical Scenarios ...................................................... Error! Bookmark not defined.
Annex B: Sample Endotreacheal Intubation Progress Notes ... Error! Bookmark not defined.
Annex C: Out-of-Scope Requirements ..................................... Error! Bookmark not defined.
Glossary .................................................................................. Error! Bookmark not defined.
HL7 Version 3 Domain Analysis Model: Detailed Clinical Models for Medical Devices, Release 1
© 2011 – Health Level Seven International. All rights reserved. Informative Ballot, May 2011
Pag e |3
Detailed Clinical Model (DCM) for Medical Devices
Authors
Co-Chairs:
John G. Rhoads, Philips Medical Systems

john.rhoads@philips.com
Todd Cooper, Breakthrough Solutions Foundry, Inc.(IEEE)

t.cooper@ieee.org
Melvin Reynolds, AMS Consulting

melvinr@AMS-Consulting.co.uk
William Goosen, Patient Care Work Group Co-chair

williamtfgoossen@cs.com
Contributors/Subject Matter Experts:
Catherine Hoang, US Department of Veterans Affairs,

catherine.hoang2@va.gov
Donna DuLong, TCoombs & Associates/US Department of Veterans Affairs

ddulong@apelon.com
Project Facilitator:
Greg Staudenmaier, US Department of Veterans Affairs,
greg.staudenmaier@va.gov
Modeling Facilitator:
Jay Lyle, JP Systems/US Department of Veterans Affairs,
jay.lyle@jpsys.com
Luigi Sison, TCoombs & Associates /US Department of Veterans Affairs,

lsison@yahoo.com
Modeling, Publishing Facilitator:

Ioana Singureanu, Eversolve, LLC / US Department of Veterans Affairs
ioana@eversolve.com
Change History
May 2011 - Informative
Pag e |4
In addition to addressing the ballot comments, this ballot includes additional use cases:
1. Post-Operative Patient Transport (from PACU to ICU)

2. Technical Use Cases
 Patient-to-device Association
 Time Synchronization for Networked Devices and for Legacy Devices
September 2010 - Draft for Comment
Initial version documenting the Domain Analysis for the following use cases:
1. Intubate Patient - Unplanned
2. Manage Patient on Ventilator
3. Liberate Patient from Ventilator, Planned
Note that a limited number of proposed Detailed Clinical Models (DCMs) have been included
in this document for comment. This ballot is intended to solicit input on the analysis
approach used to identify DCMs starting from concrete user/clinician needs documented
using business use cases.
The initial "Draft for Comment" ballot was intended to solicit input from all the
stakeholders in Patient Care, Healthcare Devices, and Patient Safety as the input of other
HL7 members interested in Detailed Clinical Models and their applicability to communicating
requirements between clinicians, application developers, interoperability solution
developers, and other stakeholders involved in improving the efficiency healthcare delivery
and increase patient safety at the same time
Introduction and Objectives
The objectives of this project is to use a Domain Analysis Model (DAM) in order to specify
the content of a set of reusable Detailed Clinical Models (DCM), The DCMs and the
associated DAM enable semantic interoperability for medical device measurements across
devices and information system.
An DAM is intended to improve communication of interoperability requirements and

workflow automation between the business stakeholders, clinicians, vendors, and
integrators (both IT and clinical engineering).
It is used in this project to identify the context and content of DCMs.
A. Approach
The intent of this model is to create and maintain Detailed Clinical Models describing the
information exchanged by medical devices in order to improve support for workflow
automation, documentation, and patient safety. Furthermore, this specification organizes
medical device data from and about medical devices in such a manner that it becomes
reusable in different domain models, standards and technologies, thus supporting
consistency of representation and semantic interoperability.
Clinicians need to be able to stipulate requirements for clinical data in a form that they can
understand, both in order to participate in the requirements definition process and in order
to ensure the quality of the resulting documentation. For a variety of reasons, existing
formalisms for data modeling have proven inadequate to this task. The premise behind a
Pag e |5
DCM is to meet that need. It is clinical in scope, so it represents the knowledge of the
clinician rather than the software developer or data modeler. It specifies with a high degree
of precision the information needed by the clinician. And, as any requirements definition
method must, it captures requirements in a consistent and rigorous formalism in order to
support the development of technical specifications.
This section defines the approach used by our project team to identify DCMs starting from
clinical scenarios and use cases representing clinicians' requirements. The methods used are
in a formative stage of development so theoretical or methodological comments from
readers are specifically invited.
The following diagram illustrates how this specification was derived: starting with a set
of business/clinical use cases, next we derived one high-level workflow per use case, and
finally documented the information require to fulfill the use case. Note that an outcome of
the analysis is to identify those DCMs that are reusable.
It is important to emphasize that the use cases and clinical workflows presented in this
document are included not to comprehensively characterize, far less to specify or codify,
medical practice in a subject area but rather to serve as tools for recognizing information
needs to support the development of system requirements and, eventually, serviceable
information systems. When a reader who is a subject matter expert in a clinical area
covered by this work is aware of a different workflow or manner of practice than what is
presented here leading to a different information requirement, it would be a helpful service
to make the authors aware of it.
The DCM criteria and methodology is the subject of ISO NIWP 13972, approved July 2009;
the methodology for HL7 Domain Analysis is documented in the HL7 Development
Framework (HDF).
Pag e |6
Figure A: Approach and Ballot Content
Glossary (Artifact)
The project glossary identifies technical and domain-specific terms that are used throughout
the document without definition.
Clinical Scenario(s) (Artifact)

The clinical scenario illustrate how the medical devices are used to support the requirements
of the stakeholders. They represent detailed description of clinical scenarios that include one
or more clinical use cases. Clinical scenarios or user stories are developed in collaboration
with the end-users and clinicians who use the medical devices.
Annex A contains a reference to sample clinical scenario illustrating the use cases analyzed
in the current model.
Pag e |7
1. Business/Clinical Use Case (UseCase)

A business use case is a high-level use case (see Glossary for a definitions of Use Case)
intended to capture the business requirements of the project stakeholders. In our case the
business use case is documented using specific clinical scenarios
2. Clinical Workflow (StructuredActivityNode)

The clinical workflow details the steps and conditions documented in the use case scenarios.
Note: The clinical workflows described in this specification are intended to provide context
and assist in identifying the information required.
3. Analysis Information Model
The Analysis Information Mode is an element of Domain Analysis Model (DAM) and it is
intended to capture the business stakeholder's perspective regarding the information
required to support the use cases. The analysis model was developed using the conventions
and best-practices developed by HL7 project teams to capture the information requirements
in terms that are familiar to the business stakeholders.
Note that the information analysis model is reusing a set of data types based on standard
(i.e. HL7 and ISO) abstract data types to bridge the differences between platform-specific
implementations.
4. Detailed Clinical Models
A separate section will contain all the DCMs identified or reused by this specification. DCM1
and DCM2 are candidate DCM specifications identified during the requirements analysis
process.
DCM1
This is example candidate Detailed Clinical Model derived from the clinician's interoperability
requirements.
DCM2
This is an example candidate Detailed Clinical Model derived from the clinician's
interoperability requirements.
1. Business/Clinical Use Cases
The following sections describe the use cases that determine the scope of the DCMs
included in this specification.
Business Actors
This section specifies the actors that participate in the business use cases. Note that one
actor may participate in more than use case. For a full description of Actor refer to the
glossary.
Pag e |8
he following diagram illustrates how the roles specified as actor definitions are inherited. For
example, an Authorized Intubator is a type of Clinician and thus this role includes the
permissions allowed to generic Clinicians but extends these permissions to include
intubation privileges.
uc 1: Business/Clinical Use Case Actors
Clinician Patient
AuthorizedIntubator
AuthorizedExtubator
CareTeamMember
RespiratoryTherapist
Transporter Nurse
Physician
Figure 1: Business/Clinical Use Case Actors
Clinician (Actor)
A person permitted to provide clinical care to a patient. This role is assumed by a device
operator. As seen in Figure 1, the Clinician is a generic actor, which includes specializations
AuthorizedExtubatlor, AuthorizedExtubator, and a CareTeamMember.
AuthorizedIntubator (Actor)
A clinician of any title who is permitted to perform an intubation procedure. This role may
be played by a physician, nurse anesthetist (CRNA), or a respiratory therapist. This role is
assigned to clinician who performs the procedure.
This actor is a type of Clinician.
AuthorizedExtubator (Actor)
This actor is a provider with authorization to order extubation. Usually this role is played by
a physician, but may be physician‘s assistant or nurse practitioner or respiratory therapist
(in smaller facilities).
This actor is a type of Clinician.
CareTeamMember (Actor)
A clinician, with or without intubation privileges who participates in the intubation procedure
Pag e |9
directly or in other, related healthcare delivery processes :

 A nurse, typically responsible for patient care who may assist with intubation process
 Respiratory Therapist, typically responsible for setting up the ventilator and modifying
settings
 A physician who may have ordered the intubation and may assist with intubation
process
 A nurse or other personnel charged with moving a patient (e.g. from post-anesthesia
recovery to the intensive care unit).
Nurse (Actor)
A nurse participating in the urgent intubation or other use cases specified in this model.This
actor is a type of CareTeamMember.
Physician (Actor)
A licensed physician participating in the urgent intubation. The physician may be involved if
the patient‘s condition either degrades to a point requiring intervention or improves to the
point of indicating a weaning trial. This actor is a type of CareTeamMember.
RespiratoryTherapist (Actor)
A respiratory therapist participating to the intubation procedure. The respiratory therapist is
responsible for ventilator configuration and settings. This actor is a type of
CareTeamMember.
Transporter (Actor)
Depending on the care setting this could be someone who simply moves the patient from
one location to the other. This actor is a type of CareTeamMember.
Patient (Actor)
While the patient has no responsibilities in the workflow, the patient is an important
participant as the subject of the procedure at the center of this use case. The patient
received the procedure described in the use case.
1.1 Intubate Patient
This section describes the contents of this use case including a use case diagram identifying
the main actors.
The following diagram identifies the roles of the participants to the clinical workflow. Each
'stick figure' represents a type of participant/role.
P a g e | 10
uc 1.1: Intubate Patient - Overview Diagram
AuthorizedIntubator
CareTeamMember
(from Business Actors)
perform procedure
participate Process steps detailed here:
Intubate Patient
Intubate Patient
«trace»
(from 2.1 Intubate Patient Workflow)

«include»
receive procedure/treatment
«include»
Patient Synchronize Time

(from Business Actors) Associate Device with a
Patient at the
Point-of-care (from 1.5.2 Time Synchronization)
(from 1.5.1 Patient to Device Association)
Figure 1.1: Intubate Patient - Overview Diagram
Intubate Patient (UseCase)

This is an interoperability use case designed to define interactions between clinicians and
ventilators and other devices and systems in the interest of developing an information
model to support those interactions. This model may contain or reference one or more
Detailed Clinical Models‖ (DCM)--a formalism for representing clinical information currently
under development. Confirming the method for using these component models is a key goal
of the project sponsoring the use case. The requirement for clinical accuracy in DCMs means
that the scope of the information model extends beyond the device interactions to other
clinical facts: these facts are bounded in this case by the VA National Template for
Intubation and by the Advanced Cardiac Life Support protocol published by the American
Heart Association.
SYSTEMS AND DEVICES
 Ventilator
 Arterial Blood Gas monitor
 Pulse Oximeter
 Electrocardiograph
 Physiological Monitor - high acuity, continuous
 Capnometer
 X-ray Imaging System
 Laryngoscope
P a g e | 11
 Electronic Health Record (local, partial, or comprehensive)
TRIGGER
In response to a deterioration in patient condition, a physician orders intubation (verbally or
in a document) and assembles a team.
Order or protocol for intubation
PRE-CONDITIONS
 Patient was admitted to the location where the devices are used
 Pre-medication may have been applied
 Respiratory and other type of assessments were performed
 Supplies for airway management on hand
 Monitoring devices are in use, as needed
POST CONDITIONS
If the use case was completed, then
 Patient condition
Endotracheal (ET) tube placement verified and secured
Patient assessed for response to intubation
 Ventilator status
Ventilator parameters are set
Equipment alarms are set
 EHR documentation
All setup readings and settings in EHR
 Ongoing monitoring
Patient observations are sent to EHR on the specified schedule
1.2 Manage Patient on Ventilator
the main actors.
P a g e | 12
uc 1.2: Manage Patient on Ventilator
RespiratoryTherapist Patient
(from Business Actors) (from Business Actors)
perform receive treatment
Manage Patient on Manage Patient on Ventilator

Ventilator «trace»
(from 2.2 Manage Patient On Ventilator Workflow)
«include» «include»
Associate Device with a

Patient at the Synchronize Time
Point-of-care
(from 1.5.2 Time Synchronization)

Figure 1.2: Manage Patient on Ventilator
Manage Patient on Ventilator (UseCase)

This use case describes the activities involved in assessing a patient on a ventilator and
making necessary adjustments to settings.
 SYSTEMS AND DEVICES

 Ventilator
 Electronic Health Record System
TRIGGER
 Periodic
 Alarm event
PRE-CONDITIONS
Patient on ventilator
POST CONDITIONS
 Patient has been assessed
 Ventilator settings have been modified, if necessary, to respond to changes in patient
P a g e | 13
condition
 Ventilator setting changes have been verified by re-assessment
SOURCES
• Clinical Scenario drafted by Donna DuLong and Catherine Hoang
• Meeting with subject matter experts, 13 July 2010
• Endotracheal Intubation Template from National, provided by Warren Rose RRT, Critical
Program Leader, Tampa, Florida
1.3 Liberate Patient from Ventilator
the main actors
uc 1.3: Liberate Patient from Ventilator
Clinician
AuthorizedExtubator
perform
order
assign device to patient
Liberate Patient from

Ventilator

«include» Patient at the
receive Point-of-care
procedure/treatment
«include»
Patient «include»
receive treatment «include»
Synchronize Time
Manage Patient on
«include»
Ventilator
(from 1.2 Manage Patient on Ventilator)
Figure 1.3: Liberate Patient from Ventilator
P a g e | 14
Liberate Patient from Ventilator (UseCase)

In response to a physician's order, a team of clinicians weans a patient from a ventilator
and removes the Endotracheal tube. The clinician performs a respiratory assessment on the
patient.
SYSTEMS AND DEVICES
The device list is not to influence the scope of the modeling effort at this time; it is a draft
list to be used in system boundary definition at a later stage.
 Ventilator
 Arterial Blood Gas monitor
 Pulse Oximeter
 Electrocardiograph
 Electronic Health Record (local, partial, or comprehensive)
TRIGGER
The patient‘s condition improves to the point where a authorized clinician decides to
evaluate for weaning and extubation.
 Provider order for extubation
 Or, Clinician determines that the patient meets protocol requirements for extubation
 Or, Clinicians agree that the patient meets protocol requirements for extubation
PRE-CONDITIONS
 Intubated patient on ventilator

 Assessment shows improvement to clinically defined level
 Intubation pre-conditions also met in case extubation failure requires re-intubation
POST CONDITIONS

 Patient condition
Patient has been successfully extubated
 Ventilation status
Ventilator has been disconnected from patient
[Ventilator is placed in appropriate state or place for cleaning and return to use
 EHR documentation
All readings and changes in settings in EHR
 Ongoing monitoring
Ventilator-specific alarms have been suspended
1.4 Transport Post-Operative Patient
The following section describes the steps required to transport a patient who relies on
medical devices for ventilation and/or monitoring of physiological parameters.
The following diagram illustrates the actors involved in the use case.
P a g e | 15
uc 1.4: Patient Transport
send patient
move patient
receive patient
Transport Post-Operative
Nurse Patient
Transporter
order transport
is «include»
relocated
«include»
Physician
(from Business Actors) Patient at the Point-of-care

Patient
Synchronize Time
Figure 1.4: Patient Transport
Transport Post-Operative Patient (UseCase)

This use case specifies the steps required to transport a patient who is connected to devices
from one (source) location to another (destination) location. The two locations may be in
the same organization (e.g PACU to ICU) and the transport may be repeated as the patient
moves across care settings.
Pre-conditions: The patient is connected to devices and may need to continue ventilation
for the duration of the transport and until the patient is transferred to another caregiver's
charge.
1.5 Included Technical Use Cases
The following section describes the technical use cases required to support the business
requirements illustrated by the business use cases.
Technical Actors
These actors represent system or device roles.

The following is a graphical representation of the relationships between the system actors
involved in the technical use cases.
P a g e | 16
uc 1.5: Technical Actors
NetworkTime Server DeviceManager
MedicalDevice
NetworkedMedicalDevice
LegacyMedicalDevice
Figure 1.5: Technical Actors
MedicalDevice (Actor)
This actor represents either a modern/networked device or a legacy/stand-alone device. In
some use cases, this aspect is not relevant.
DeviceManager (Actor)
A Device Manager is a software and hardware solution intended to connect medical devices
to specific healthcare information systems. It serves a very important purpose in enabling
interoperability for Legacy Medical Devices in particular.
The Device Manager is particularly important for dealing with Legacy Medical Devices. For
those devices, the Device Manager could provide the association with the patient record, the
device operator, and even correct time stamp issues.
LegacyMedicalDevice (Actor)
This actor represents any legacy medical device that is not capable of accessing the local
area network and relies on a DeviceManager to enable interoperability.
NetworkTime Server (Actor)

Network server that provides time synchronization on the local area network using SNTP.
The Simple Network Time Protocol (SNTP) is a protocol for synchronizing the clocks of
computer systems over packet-switched, variable-latency data networks. SNTP uses UDP
port 123 as its transport layer. It is designed particularly to resist the effects of variable
latency.
NetworkedMedicalDevice (Actor)
Any medical device capable of connecting to the Network Time Server to synchronize its
clock. This device may communicate using standard or proprietary protocols.
Nursing Flowsheet (Sequence)
P a g e | 17
The Nursing Flowsheet is an example enterprise system that used standard-based

interoperability. This system is intended to provide verification of device results from a
variety of devices assigned to the patient. This system is also responsible for documenting
the care of the patient and updating the medical record.
ADT System (Sequence)

The ADT system, where available, provides patient information and encounter updates to
departmental systems including Device Managers.
Medical Device State Transitions
The state machine of a device relative to its assignment to specific patient. This state
machine is important in understanding how the device assignment and configuration affect
the clinical workflow.
This state machine helps to illustrate the patient transfer use case. It specifies several of
the states that devices may be in at any time during the transfer.
stm 1.5.a: Device Assignment and Configuration State Machine

Free assign the device to the patient Assigned
[patient identity is verified]
break association
Figure 1.5.a: Device Assignment and Configuration State Machine
The following diagram describes how an assigned device may change its state between
active and inactive.
stm 1.5.b: Assigned Device States

[configure settings]
patient
ready
[connect patient] Active
[disconnect patient]
[connect patient]
Inactive
[configure settings] [configure setting]
patient
not
available
Figure 1.5.b: Assigned Device States
P a g e | 18
Free (State)
The device is not assigned and it is set up to default settings.
Assigned (StateMachine)
The device is assigned to a patient.
Active (State)
The patient is attached to the device and working for the patient, sending observations
referencing the patient's identity.
Inactive (State)
The medical device is not active, not connected to the patient it was assigned..
patient not available (Initial State)

If the patient is not available, the operator may configure the settings for the patient type
or personalize the settings.
patient ready (Initial State)

If the patient is available then the patient is connected to the device assigned to that
patient.
1.5.1 Patient to Device Association
The following section describes the use cases and actors required to assign a patient to a
device.
The following is a graphical illustration of the use case.
uc 1.5.1.a: Patient to Device Association
MedicalDevice
Clinician
(from Technical Actors)
assign device store patient reference

to patient informatoin
Associate Device with a Patient at

the Point-of-care
«include»
Clinician
Authentication
Figure 1.5.1.a: Patient to Device Association
P a g e | 19
Associate Device with a Patient at the Point-of-care (UseCase)

This is a basic use case which requires that the device and patient are associated with each
other in order to ensure that the measurements and/or configuration of the device may be
reported correctly and associated with the correct target patient record. This use case
assumes that the patient is associated with a point-of-care and the information about the
association flows along with the information reported by the device to nursing Flowsheet
and/or EHR-S.
The operator/clinician enters the patient's reference identifying information (e.g. using a bar
code reader, key entry). The device stores this information to use it later when reporting
device observations to the information systems.
Clinician Authentication (UseCase)

This use addresses the association of a clinician (i.e. device operator) to that device and to
the patient results.
Note: This use case is a placeholder for future Security use cases dealing with device user
authentication and authorization.
1.5.2 Time Synchronization
Maintaining time synchronization across medical devices and information systems

The following describes the use case and actors when the medical device is able to lookup
the current time over the local area network.
uc 1.5.a: Time Synchronization for Networked Devices
NetworkedMedicalDevice
NetworkTime Server
look up current time provide current time
Synchronize Time
Figure 1.5.a: Time Synchronization for Networked Devices
The following describes the use case and actors in the case when the medical device is
stand-alone, not capable of reaching a network time server.
P a g e | 20
uc 1.5.b: Time Syncrhonization for Legacy Devices
LegacyMedicalDevice
DeviceManager
correct timestamp, syncrhonize
Synchronize Time
provide current time
NetworkTime Server
Figure 1.5.b: Time Synchronization for Legacy Devices
Synchronize Time (UseCase)

This use case refers to the requirements imposed on both new devices and legacy devices
to maintain consistent time and stay synchronized with the relevant EHRS and nursing
applications that are used to display and record medical device parameters and
measurements.
Medical devices that are not networked (i.e. legacy devices) an operate as stand-alone
system will have inherent difficulty in maintaining an accurate time stamp.
 Clock drift between devices and information systems and other software that processes
the data produced by the devices
 Daylight savings time – some devices need to be set for daylight savings manually
rather than automatically. If device clock is not set, then the data my be incorrectly
stamped. In some cases this causes loss of the data at the time when the clock moves
back (one hour worth of data is effectively ignored by legacy EHR-S).
 Power loss (i.e. blinking 12:00) due to a battery outage may reset the clock of the
device and require manual intervention to set the correct time.
Patient Safety Issues:

 Device information may time stamped incorrectly and thus be reported incorrectly on
the Flowsheet or patient record
 Information may be lost completely or incorrectly associated with a procedure,
treatment, or medication
P a g e | 21
For networked devices we expect that the devices should be able to use local servers to
set up its clock automatically and synchronize with the rest of the information systems. This
would ensure that any data produced by the device will be time stamped correctly and
reported to the EHRS. The medical devices would use Simple Network Time Protocol clients
to set their clock correctly and stay in synch when restarting, after a battery is replaced, for
daylight savings.
For legacy devices we need to rely on the Device Manager System to add or correct the
time stamp to any device data. We would also need the Device Manager to be time
synchronized using SNTP . Additionally, any legacy device adapter running on the Device
Manager would have to substitute the correct time stamp. We need to ensure that the
medical device time stamp is not used to specify the parameter or measurements recorded
by the device.
2. Clinical Workflows
The scope of a DCM is delineated by a set of clinical Workflows that fulfill specific needs of
business stakeholders (i.e. clinicians).
Therefore this section specifies the scope of this specification by identifying the use cases
in-scope and the clinical Workflows that are required to fulfill the steps identified in the use
case scenarios.
The information specified in a DCM is required to support the clinical workflow therefore this
section important in setting a boundary to the analysis.
Note: Refer to Annex A: Clinical Scenarios for detailed background on the scenarios used
to develop the use case descriptions and the associated clinical Workflows.
Rationale: The workflows described in this section are intended to illustrate the typical
workflows to describe how medical devices are used to support the needs of clinicians.
They define the context of use for medical devices to enable automation and interoperability
in order to:
 Improve efficiency
 Improve quality
 Accelerate documentation of medical procedures
The clinical workflow included in this document are not intended to provide clinicians
guidance on how to practice medicine but rather to describe to other stakeholders (e.g. IT,
vendors, integrators, clinical engineering). The Business Use Cases in Section 1 and the
Clinical Workflows in Section 2 of the DCM for Medical Devices document are intended to
determine the conventions of clinical practices and to make sure that the rest of the analysis
including information and system interactions.
The following diagram summarizes the Workflows derived from the business/clinical use
cases. Each workflow is further elaborated in individual steps.
P a g e | 22
act 2: Specification Scope: Clinical Workflows
Intubate Patient
(from 2.1 Intubate Patient Workflow)
Manage Patient on
Ventilator
(from 2.2 Manage Patient On Ventilator Workflow)
Liberate Patient from

Ventilator, Planned
(from 2.3 Liberate Patient from Ventilator, Planned Workflow)
Figure 2: Specification Scope: Clinical Workflows
2.1 Intubate Patient Workflow
The following section describes the workflow as derived from the Intubate Patient use
case analysis.
Intubate Patient (Process)

This process describes the clinical workflow described by the use case: Intubate Patient.
For Confirmation: There will be more than one response team member, and they share
duties. There are typical duty assignments among nurse, physician, and respiratory
therapist: these are not illustrated here, as the participants may perform atypical tasks in
an emergent situation.
The following diagram describes the steps required to intubate a patient who needs
respiratory support.
P a g e | 23
act 2.1: Intubate Patient

:CareTeamMember :AuthorizedIntubator :Nurse
information to EHRS
Order To Intuba te 1. Assemble team
In the ICU, pul s e
[order Information] oxi metry a nd vi tal s a re
mea s ured together. The
cl i ni ci a ns a re
cons i deri ng them a s
2. Assemble Supplies joi ned functions .
7. Initiate manual
ventilation
3. Connect ventilator to the «devi ce_da ta »
appropriate power supply and oxygen Pulse Oximetry
4. Initiate
source,
Monitoring (from 3.1 Information Analysis)
6. Prepare Patient
13. Confirm ventilator self-test, «devi ce_da ta »
Position
standby Vital Signs
5. Sedate
Patient (from 3.1 Information Analysis)
9. Insert tube
8. Assess patient (Respiratory)
Verify Suction EHR-S a nd Devi ce
Available Da ta produced
10. Confirm placement duri ng the workfl ow
by breath sounds and or us ed duri ng thi s
11. Confirm placement using secondary methods
condensation workfl ow.
«EHR»
12. Order Chest X-Ray Chest X-ray Order,
Image, Interpretation
(from 3.1 Information Analysis)
15. Associate patient with monitoring devices and

[update information] «devi ce,EHR»
ventilator
Device Association

14. Set and confirm ventilator settings
[input information] «EHR»
Respiratory
Consult Order
16. Take ventilator off standby

17. Connect patient to ventilator and initiate

[update information] «devi ce_conf...
Mechanical Ventiation
Ventilator
Parameters
18. Set alarms conditions and [update information] (from 3.1 Information Analysis)
ranges
[add] «devi ce,l a b_re...

ABG
19. Optimize Ventilator
Settings [update] (from 3.1 Information Analysis)
20. Assess patient

«EHR»
Procedure
21. Record procedure documentation [update] Documentation

Document i ntuba ti on
Figure 2.1: Intubate Patient
P a g e | 24
<anonymous> AuthorizedIntubator The steps in this partition are performed by the person who play the
role of "Privileged Intubator" as described in the previous section .
Order To Intubate In response to a deterioration in patient condition, a physician orders
intubation (verbally or in a document) and assembles a team. The
physician specifies the ventilator setting in the respiratory consult.
An arterial blood gas laboratory test may also be order in advance of
the Endotracheal Intubation procedure order.
2. Assemble Is there a checklist for supplies? Are the supplies matching the order
Supplies and the preferences of the individual Privileged Intubator? Is the
Endotracheal Tube the correct size based on order and patient's
previous history with intubation?
3. Connect Connect to appropriate power supply (pneumatic, electric) and to the
ventilator to the oxygen source and set up generic settings.
appropriate power
supply and oxygen
source,
4. Initiate The patient is associated with pulse oximetry monitor and the monitor
Monitoring sends its readings to the information system. In Intensive Care
settings, the vital signs are monitored together.
5. Sedate Patient A verbal or written order from the physician would be required before
sedating a patient.
7. Initiate manual This step is also referred as "pre-oxygenation". The nurse or therapist
ventilation will use a mask and an manual bag to pre-oxygenate the patient. This
activity continues until the mechanical ventilation is initiated.
8. Assess patient This assessment is a respiratory assessment.
(Respiratory)
11. Confirm Methods of confirmation may include one or more of he following:
placement using - CO2 reading confirming expiration
secondary methods - EDD device confirming the presence of carbon dioxide in the breath.
Note: We do not assume these devices will report their readings

automatically to information but they are used by clinicians to validate
tube placement.
12. Order Chest X- A chest X-ray is order to confirm the correct placement of the tub
Ray Initially and, in some care settings, repeated on a daily basis. Note that
the X-ray may be performed after the procedure ends. The attending
physician will evaluate the X-Ray and request a change, if needed .The
physician's findings are recorded in the electronic record.
15. Associate pulse ox, vitals, tidal CO2, ventilator
patient with This step ensures that the ventilator is reporting results directly to the
monitoring devices EHR-S.
and ventilator
19. Connect This step ensures that the ventilator is reporting results directly to the
ventilator to EHR-S.
medical record
19. Optimize This set up goes beyond the starting point setting specified in the order
Ventilator Settings including ABG.
20. Assess patient Assess the patient status for discomfort and improvement. This may
include a respiratory assessment and evaluate vital signs.
21. Record -- includes difficulty (e.g. level, number of failed attempts).
procedure The documentation will include the use of disposables during the
documentation procedure. The information is automatically transferred to relevant
information system. The
Document A clinical note is created to document the Endotracheal Intubation
intubation Procedure.
2.2 Manage Patient On Ventilator Workflow
The following section describes the workflow as derived from the Manage Patient use
case analysis.
Manage Patient on Ventilator (Process)

This process describes the clinical workflow described by the Manage Patient Use Case.
P a g e | 25
The following diagram describes the steps required to manage the ventilator settings wile a
patient is intubated.
act 2.2: Manage Patient on Ventilator

Respiratory Therapist :RespiratoryTherapist Nurse or Respiratory Therapist :Clinician
Periodic or
alarm-based
1. Conduct respiratory
[information updated] «device_data»
assessment
Alarm Status
Periodic oral (from 3.1 Information Analysis)

3. Need for care
suction
[yes]
4. Apply suction
EHR-S and Device
Data produced during
Oral care the workflow or used
required during this workflow.
6. Move tube to other side of mouth
[yes]
[no]
7. Confirm tube placement
«EHR»
Respiratory Consult
Order
8. Disposable [no] (from 3.1 Information Analysis)
materials
due for change
10. Provide oral
care
[input information] [yes]
«device_data»
9. Change disposable Pulse Oximetry
materials
12. Verify continuation of order and changes 11. Check
monitors
«device_data»
Vital Signs
[use] (from 3.1 Information Analysis)

13. Optimize Ventialtor
Setting
[update] «EHR»
Procedure
Documentation
Patient judged stable, ventilator

weaning check triggered
P a g e | 26
Figure 2.2: Manage Patient on Ventilator
Respiratory RespiratoryTherapist This partition contains the activities performed by respiratory therapist
Therapist who manages the patient who is intubated.
4. Apply suction Suction and wait for patient to recover from suction, stop coughing,
etc.
5. Patient due for Also referred as "airway care"
oral care
12. Verify ... This step includes checking for any changes to the order (e.g. vent
continuation of mode).
order and changes
13. Optimize This activity describes the set of steps required to optimize the
Ventialtor Setting ventilator settings starting with those settings ordered by the ordering
physician.
2.3 Liberate Patient from Ventilator, Planned Workflow
The following section describes the workflow as derived from the Liberate Patient From
Ventilator use case analysis.
Liberate Patient from Ventilator, Planned (Process)

This process describes the clinical workflow described by the use case Liberate Patient.
The following diagram describes the steps required to terminate a patient, including
ventilator weaning.
P a g e | 27
act 2.3: Extubate Patient, Planned (includes ventilator weaning)

:Nurse :RespiratoryTherapist :AuthorizedExtubator
Maintenance
process completed
1. Assess for readiness to

wean from sedation
3. Assess patient for readiness 4. Ready to wean

2. Agitated? [no] to wean from ventilator from ventilator?
[no]
[yes] 5. Set ventilator mode and

settings for trial [yes]
[yes] 6. Distress?
EHR-S and Device Data
Patient failed, continue ventilation produced during the
[no] workflow or used
during this workflow.
8. Prepare patient 7. Assemble 9. Check previous

supplies intubation difficulty [information lookup]
10. Disconnect from [update information] «device,EHR»

ventilator Device Association

11. Provide oral care,
suction, and deflate cuff 12. Instruct patient to
cough to remove tube
14. Provide further 13. Connect oxygen 15. Place ventilator in

instructions delivery method queue for cleaning,
inspection, and reuse
16. Evaluate patient
«EHR»
17. Finish documentation [update] Procedure
Documentation
Procedure (from 3.1 Information Analysis)
Completed
Figure 2.3: Extubate Patient, Planned (includes ventilator weaning)
P a g e | 28
3. Assess patient It may include RSBI and other assessment methods based on best-
for readiness to practices.
wean from
ventilator
5. Set ventilator This is done after the assessment
mode and settings
for trial
8. Prepare patient Suction, position, explain process
9. Check previous Difficult or standard - should be part of initial intubation. In this step
intubation difficulty we check to see if additional clinicians need to be involved for a difficult
intubation.
10. Disconnect The device is disconnected from the patient and device association
from ventilator record is updated automatically.
12. Instruct patient The cough helps remove the tube.
to cough to remove
tube
16. Evaluate On-going assessment
patient
2.4 Post-Operative Patient Transport
The following section describes the workflow as derived from the Transport use case
analysis.
The following diagram details the steps required to transport a patient across the
enterprise.
P a g e | 29
act 2.4 Transport Patient

Attending :Physician PACU Nurse :Nurse :Transporter ICU Nurse :Nurse
Patient in PACU,
connected to devices
«EHR»
Transfer Order
1. Order Patient 15. ICU setup
Transfer (from 3.1 Information Analysis)
2. Get patient history, «EHR»
demographics, Patient Medical History
language
«EHR»
Risk factors
3. Get risk factors
(from 3.1 Information Analysis) 16. Set up
«EHR» Devices
4. Get allergy Allergies
«EHR»
5. Get medications Medication
(from 3.1 Information Analysis) Transfer
«device_config» completed
6. Get IV lines IV Line Information

«EHR»
7. Check disposable Flowsheet
devices (from 3.1 Information
«EHR» Analysis)
Device Characteristics
Record
8. Submit a device (from 3.1 Information Analysis)
request «device_data»
Operational Device
Settings
9. Alert «device_config»
ICU/Destination Personalized Device
Settings
10. Check the need for (from 3.1 Information Analysis)

transport device
[transport device
needed] [device will be
replaced at the
destination]
11. Transfer [device is sent
settings to the 12. Send current with the
transport device device settings patient]
13. Break device 14. Move

associations patient
Figure 2.4 Transport Patient
P a g e | 30
1. Order Patient Transfer (Activity)

A physician orders that the patient is moved from the one location to another (e.g. from
PACU to ICU).
2. Get patient history, demographics, language (Activity)

While this activity is primarily completed on paper, the updates to the medical history and
consent forms should be recorded in the health information system and in the patient
Electronic Health Record.
6. Get IV lines (Activity)

Get Intravenous Line information.
7. Check disposable devices (Activity)

This includes checking where they are connected, when it was placed.
8. Submit a device request (Activity)

This request is sent to the destination unit to have the devices available when the patient
arrives
10. Check the need for transport device (DecisionNode)

Depending on the status of the patient, the distance of the transport it may be necessary to
provide devices (e.g. ventilator) for transport, use the current device, or use manual
ventilation.
2.5 Referenced Technical Workflows
The following section elaborates the technical use cases required to support the overall user
requirements regarding intubation and other clinical needs.
System Roles
The following section details the system roles involved in the technical use cases for this
model.
2.5.1 Patient to Device Association
The Patient-to-device association workflow specifies the interactions between devices and
the information system required to establish that a device is assigned to a specific section
and ensure that the alarms and measurements transmitted by the medical device to the
EHR-S or Nursing Flowsheet where the results are later validated and reviewed by clinicians
before they are added to the patient's medical record.
he following diagram illustrates the systems interacting when a device is assigned to the
patient right at the point-of-care using either from a list drawn from known ADT records
captured by the Device Manager and made available to its devices or by entering the
patient's identifier(s) at the bed side - ideally by reading their wrist band. While other user
entry methods are plausible, a barcode reader avoids the entry errors inherent in typing
identifiers on the device.
P a g e | 31
sd 2.5.1.a Patient to Device Association
ADT System Nursing

Flowsheet
MedicalDevice DeviceManager
opt - Look up patient based on inbound ADT

1.0 ADT(A01)
[ADT is supported]
1.1 lookUpPatient(lastname)
1.2 patientInfo(name, mrn[0..1], account[..1], gender)
alt - Barcode or device input

[Barcode Reader Supported]
1.3 readPatientInfo(mrn, id)
1.4 persistPatientInfo(mrn, name[0..1], account[0..1])
1.5 perform measurements()
1.6 deviceObservation(ORU^R01)
The observation contains a reference to the
Patient Info (.e.g. HL7 Version 2.x PID segment).
(from Technical Actors) (from Technical Actors) (from Technical Actors) (from Technical Actors)
Figure 2.5.1.a Patient to Device Association
The interactions are more complex for Legacy Medical Devices as they rely more heavily on
Device Manager system and, in extreme cases, on information systems to associate the
observations of medical device with a specific patient record.
P a g e | 32
sd 2.5.1.b: Patient to Device Association (Legacy Devices)
ADT System Nursing

Flowsheet
LegacyMedicalDevice Clinician DeviceManager
opt - Configuration Assigns Device to Location
1.0 configure(bedLocation, deviceId)
1.1 managePatientEncounter(PV1, patientId, bedLocation)
1.2 assignDevice(deviceId, patienId, bedLocation)
alt - User Assigns Device to Patient
1.3 assignDevice(deviceId, patientId, patientAccount[0..1])
1.4 deviceObservations(NCCLS)
1.5 addPatientContext()
1.6 addTimeStamp()
1.7 deviceObservations(ORU^R01)

(from Business Actors) (from Technical Actors) (from Technical Actors) (from Technical Actors)
Figure 2.5.1.b: Patient to Device Association (Legacy Devices)
- Look up patient based on inbound ADT (InteractionFragment)

This option requires that the Device Manager track the ADT messages flowing in the
enterprise.
- Barcode or device input (InteractionFragment)

This alternative option is available to those devices that support bar code readers.
2.5.2 Time Synchronization
The following section elaborates how time synchronization would operate for legacy and
networked devices.
The following interaction summarized the simple network time synchronization for those
medical devices able to communicate over the local are network with other systems in the
enterprise.
P a g e | 33
sd 2.5.2.a :Time Synchronization for Networked Devices
NetworkedMedicalDevice NetworkTime Server
1.0 send(Request)
1.1 SNTPData()
1.2 updateDeviceTime()
(from Technical Actors) (from Technical Actors)
Figure 2.5.2.a : Time Synchronization for Networked Devices
ince legacy devices cannot update their clock using SNTP as seen in Figure 2.5.2.a, the
Device Manager may be used to either add an alternative time stamp to the data reported
by the device or substitute the device timestamp with its own.
As seen below, the Device manager may transform a legacy (e,g. ASTM/NCCLS) or
proprietary message structure to the standard-based specification supported by the
enterprise systems (e.g. Nursing Flowsheet).
In the process, the Device Manager may add the patient context based on the location
where the device is placed or its identity. If the device is associated with a specific bed, the
Device Manager will use the ADT information regarding patient's bed location and upon
receiving the information from the medical device.
sd 2.5.2.b Time Correction/Substitution for Legacy Devices
Nursing ADT System

Flowsheet
LegacyMedicalDevice DeviceManager NetworkTime Server
opt - DeviceManager is time synchronized

1.0 send(Request)
1.1 SNTPData()
1.2 AddPatient(ADT_A01)
1.3 deviceObservation(NCCLS)
1.4 addTimeStamp()
1.5 addPatientContext()
(from Technical Actors) (from Technical Actors) (from Technical Actors) (from Technical Actors)
Figure 2.5.2.b Time Correction/Substitution for Legacy Devices
P a g e | 34
3. Analysis Information Model
This section identifies the information required to support the clinical workflow detailed in
Section 2. The contents of this information model are based on the initial clinical scenarios
and constrained by the business use cases. Note that the analysis is intended to define the
business objects required by the clinical work flows; these are not intended to be
implementable classes but to capture the stakeholder's requirements.
3.1 Information Analysis
This section identifies the broad categories of information produced or consumed during the
clinical workflows.
The following diagram lists the information object identified during the workflow analysis.
The objects in this diagram identify high-level information exchanged between devices and
information systems.
object 3.1: Information Analysis
EHR Data
«EHR»
Device Characteristics
Record «EHR»
Medication
Device Configuration «EHR»
Respiratory Consult Order
«EHR»
«device_data»
Risk factors
Device Observations Operational Device
Settings «EHR»
Patient Medical History «EHR»
«device_data» «device_config» Procedure
Alarm Status Personalized Device Documentation
Settings Shared Objects
«EHR»
«device_data» «device_config» «device,EHR» Allergies «EHR»
Vital Signs IV Line Information Device Association Transfer Order
«EHR»
«device_data» «device_config» «device,lab_result» Chest X-ray Order, Image, «EHR»
Pulse Oximetry Ventilator Parameters ABG Interpretation Flowsheet
Figure 3.1: Information Analysis
ABG (Object)
Arterial Blood Gas results may be produced by devices or tests.
Procedure Documentation (Object)

Includes information about the difficulty of intubation illustrated, sometimes, by the number
of unsuccessful attempts.
Transfer Order (Object)

The order to transfer the patient from PACU to ICU.
P a g e | 35
Vital Signs (Object)

Vital signs, blood pressure, heart rate, temperature
Respiratory Consult Order (Object)

It specifies the ventilator settings intended by the ordering physician. It is issued by the
physician.
Allergies (Object)
Current patient allergies are relevant to many of the procedures and required when
transferring the patient between care settings.
Device Characteristics Record (Object)

It includes category of device, type, etc.
Flowsheet (Object)
Supplies management in the flowsheet is updated with details about the disposable devices.
IV Line Information (Object)

Body site, type of line (arterial, central venous)
Chest X-ray Order, Image, Interpretation (Object)

The ventilator and mobile X-Ray machine may need to be synchronized to capture the
location of the Endotracheal Tube.
Medication (Object)
The current medications including infusion.
Operational Device Settings (Object)

In addition to the device characteristics, the settings may be transferred electronically. The
device setting may be default for a type of patient and/or personalized for the patient.
Patient Medical History (Object)

Currently the patient history is documented on paper but this information along allergies,
medications, procedure consent, IV, disposables details, and medical device information
(e.g. type settings) should be available in information systems. This information includes
demographics (including preferred language of communication), medical history, risk
factors, and consents.
Device Association (Object)

Association of device with patient enables information flow to EHR-S or nursing flowsheet.
Risk factors (Object)

The Risk Factors are reviewed when a patent is transferred and include smoking, substance
abuse.
Ventilator Parameters (Object)

This information identifies device configuration parameters.
P a g e | 36
3.2 Medical Devices General Requirements
This section describes the analysis of medical devices identified during the analysis of the
clinical use cases and the associated clinical Workflows. This section is intended to capture
the specific properties and associations required to describe medical devices.
The classes documented in this section address requirements identified initially by analyzing
the Intubate Patient use case. They also support Liberate Patient from Ventilator.
At a high-level the device used to perform observations and it may be configured.
class 3.2.a: Medical Devices General Requirements - High Level
Device
{abstract}
+ deviceIdentifier: InstanceIdentifier [1..*]
+ type: CodedValue observations DeviceObservations
+ modelNumber: InstanceIdentifier
+ vendorId: Id
+ softwareVersion: Text
+configuration
DeviceConfiguration
DeviceAssignment + mode
+ assignmentTime: PointInTime
+ unassignmentTime: PointInTime
SpecialtyConfiguration
PatientReference
PersonalizedConfiguration
+ id: InstanceIdentifier [1..*]
+ account: InstanceIdentifier [0..1]
+ name: PersonName [0..1]
+ gender: CodedValue [0..1]
+ birthDate: PointInTime [0..1]
Device Configuration Derivation
Figure 3.2.a: Medical Devices General Requirements - High Level
The following diagram specifies the relationship between the device, its configuration,
observation, the operator, and verifier of the measurement.
P a g e | 37
class 3.2.b: Medical Device Analysis

Device «EHR»
{abstract} Respiratory
+ deviceIdentifier: InstanceIdentifier [1..*] Consult Order
+ type: CodedValue (from 3.1 Information Analysis)
+ vendorId: Id
+ softwareVersion: Text observations
DeviceObservations
+performance PerformanceSpecification
+configuration
1 + accuracy: CodeValueNullable [0..1]
DeviceConfiguration +observation + precision: CodeValueNullable [0..1]
* + qualityOfService: CodeValueNullable [0..1]
+ mode
DeviceMeasurement
+parameterConfiguration + code: CodedValue
+ value: PhysicalQuantity
+ effectiveTime: PointInTime ReferenceRange
ParameterConfiguration +referenceRange
+ measurementMethod: CodedValue [0..*]
+ normalRange: PhysicalQuantityInterval
+ parameterCode: CodedValue + abnormalFlag: CodedValue [0..1] 1..* + instrumentalExtremeRange: PhysicalQuantityInterval [0..1]
+ parameterValue: PhysicalQuantity + bodyPosition: CodedValue [0..1]
+ physiologicalExtremeRange: PhysicalQuantityInterval [0..1]
+ effectiveTime: PointInTime + bodySite: CodedValue [0..1]
+ patientExtremeRange: PhysicalQuantityInterval [0..1]
+ allowableRange: PhysicalQuantityInterval + correctedEffectiveTime: PointInTime [0..1]
Verification
+alarmReported
+alarmConfiguration + time: PointInTime operatedBy
ReportedAlarmStatus
AlarmEventConfiguration verfiedBy
+ severityCode: CodedValue Clinician
::Alarm ::Alarm
+ eventCode: CodedValue + id: InstanceIdentifier
+ eventCode: CodedValue + name: PersonName
+ userMessage: Text + userMessage: Text
DeviceAssignment + statusCode: CodedValue
+ statusCode: CodedValue
+ assignmentTime: PointInTime Resolution
+ unassignmentTime: PointInTime + date: PointInTime
PatientReference Alarm
{abstract}
+ id: InstanceIdentifier [1..*]
+ account: InstanceIdentifier [0..1] + eventCode: CodedValue
+ name: PersonName [0..1] + userMessage: Text
+ gender: CodedValue [0..1] + statusCode: CodedValue
+ birthDate: PointInTime [0..1]
Figure 3.2.b: Medical Device Analysis
Alarm (Class)
Abstract based class for both configured and reported alarm information.
Attribute Notes
eventCode CodedValue Reason for alarm
Public
userMessage Text User readable message indicating the reason for the error.
Public
statusCode CodedValue The alarm status (e.g.new, completed).

Public
AlarmEventConfiguration (Class)
This class describes the alarm configuration completed by device end-users.
Clinician (Class)
P a g e | 38
Clinician who operates/configures the devices or validates its measurements recorded by

the information systems (e.g. nursing flowsheet, EHR-S).
 RequirementTrace Use Case: Intubate Patient - Unplanned
This class is based primarily on the requirements Use case: Intubate Patient - Unplanned but
it support Manage Patient on Ventilator and Liberate Patient.
Attribute Notes
id InstanceIdentifier Operator's unique identifier assigned by an organization.
Public
name PersonName Operator's name

Public
Device (Class)
This class identifies a core set of identifying traits of a generic medical device. It identifies
the relationship to classes of objects including EHR order information (e.g. Respiratory
Consult Order).
Note: This is not intended as an exhaustive list of label and identifying traits. Those
interested in the
 RequirementTrace Intubation Use Case
This class and its associations were derived from requirements identified in the Intubation
Use case.
 RequirementTrace Use Cases: Intubate, Manage on Ventilator, Liberate
Attribute Notes
deviceIdentifier Unique device identifier. Currently this identifier is assigned by a manufacturer,
InstanceIdentifier wholesaler, or provider organization but in the future national regulatory agencies
Public will take a more active role in assigning unique identifiers to medical devices
including supplies/consumable devices.
[1..*]
Reference: US FDA Unique Device Identification project.
type CodedValue This attribute is intended to specify a type of device using a code system.
Public
modelNumber This attribute specifies the model number of the device.

InstanceIdentifier
Public
vendorId Id This attribute is used to identify the manufacturer of the device.

Public
softwareVersion Text This attribute is used to specify the firmware version used by the device. This
Public information may affect the interoperability capabilities of a device.
DeviceAssignment (AssociationClass)
P a g e | 39
This association class describes the attributes required to describe the patient-to-device or
device-to-patient association.
Attribute Notes
assignmentTime The date/time when the Device was associated to the Patient
PointInTime
Public
unassignmentTime The date/time when the association between the device and the patient is broken.
PointInTime
Public
DeviceConfiguration (Class)
This class organizes the device configuration options: parameter settings, modes, alarms,
etc.
Attribute Notes
mode Device mode
Public
DeviceMeasurement (Class)
This class is used to describe a generic device observation or parameter. This may be a vital
sign measurement, a glucose value, a ventilator setting, etc.
Attribute Notes
code CodedValue This attribute specifies the code of the observation using a standard code system
Public (e.g. LOINC, 11073).
value PhysicalQuantity This attribute is used to specify the value and including units of measure.
Public
effectiveTime This attribute specifies the date/time when the parameter was measured. This is
PointInTime the time reported by the device.
Public
measurementMethod This attributes specifies the method (e.g. measured or calculated) that was used.
CodedValue This attribute is optional since LOINC provides different codes for measured and
Public calculated parameters.
[0..*]
abnormalFlag The abnormal flag indicating that the observation value if out of range.
CodedValue
Public
[0..1]
bodyPosition CodedValue
Public
[0..1]
P a g e | 40
Attribute Notes
bodySite CodedValue The body site where the measurement is taken (e.g. axillary).
Public
[0..1]
correctedEffectiveTime This optional attribute may be added by the Device Manager System if the legacy
PointInTime system is not networked in thus unable to keep its clock synchronized over time.
Public
[0..1]
DeviceObservations (Class)
This class groups the alarms and observations produced by a device.
ParameterConfiguration (Class)
This class is used to describe a generic device parameter. This may be used to express a
ventilator parameter.
Attribute Notes
parameterCode This attribute specifies the name of the configuration parameter using a standard
CodedValue code system.
Public
parameterValue This attribute is used to specify the value and including units of measure.
PhysicalQuantity
Public
effectiveTime This attribute specifies the date/time when the configuration was set.
PointInTime
Public
allowableRange This configuration parameter allows the end user to change the
PhysicalQuantityInterval default/manufacturer's reference range for the parameter.
Public
PatientReference (Class)
This class contains the attributes used typically to associate a patient with a device. Note
that this list of patient identifying traits is not comprehensive and, depending on the
accuracy of the identifiers, some demographic traits are redundant.
Attribute Notes
id InstanceIdentifier Patient Identifier (e.g. Medical Record Number).
Public
[1..*]
account InstanceIdentifier The patient account number is sometimes used in addition to the medical record
Public number.
[0..1]
name PersonName Patient name
Public
[0..1]
P a g e | 41
Attribute Notes
gender CodedValue
Public
[0..1]
birthDate PointInTime
Public
[0..1]
PerformanceSpecification (Class)
The performance specification associated with the medical device is intended to be
interpreted by the information system (e.g. nursing flowsheet, EHRS).
The list of attributes is not exhaustive.
Attribute Notes
accuracy As how correct value is? how close we are to truth
CodeValueNullable
Public
[0..1]
precision How well
CodeValueNullable
Public
[0..1]
qualityOfService This refers to the quality of the service. It may be affected by the
CodeValueNullable
Public
[0..1]
PersonalizedConfiguration (Class)
A medical device may be further personalized for a specific patient.
ReferenceRange (Class)
This class captures the various reference supported by devices:
 instrumental extreme,
 physiological extreme,
 normal and
 extreme ranges for different categories of patients, etc.
Attribute Notes
normalRange Built-in reference range based on manufacturer-designated normal range.
PhysicalQuantityInterval
Public
instrumentalExtremeRa
nge
Public
[0..1]
P a g e | 42
Attribute Notes
physiologicalExtremeRa
nge
Public
[0..1]
patientExtremeRange This is range specific to a type of patient.
Public
[0..1]
ReportedAlarmStatus (Class)
Device alarm and their configuration are very important to the clinicians who use a medical
device. This class describes the information reported when an alarm condition occurs.
Attribute Notes
severityCode CodedValue The severity of the alarm event.
Public
SpecialtyConfiguration (Class)
A medical device may be configured for a specific care setting or specialty.
Verification (AssociationClass)
This association class is intended to capture the date/time when the observation is validated
by a clinician and persisted in the EHR-System.
Attribute Notes
time PointInTime Date/time when a clinician verified the device observation entered in the
Public information system.
3.3 Intubation Clinical Note
This section details reusable classes describing an intubation procedure clinical note; these
classes were identified during the analysis of the clinical use cases and the associated
clinical Workflows.
This section is based on the sample clinical note application described in Annex B.
The following diagram shows the structure of the Intubation procedure including sample
value sets for coded concepts (e.g. the urgency of the procedure is defined by the
ProcedureUrgencyType).
P a g e | 43
class 3.3.a: Endotracheal Intubation Procedure Details
EndotrachealIntubationProcedure
+ priorityCode: UrgencyCode +confirmationImaging ChestXRayOrder
+ insertionSite: TubeInsertionSiteCode 0..1
+ procedureDateTime: PointInTime
+ tubePlacementConfirmation: ConfirmationMethodCode [0..*]
+ cormackLehaneScale: CodedValue
+ laryngoscopyAttempts: IntegerNullable
+ intubationConfirmationMethod: ConfirmationMethodCode
+ accesInstrument: Instrumentation [0..1] +complication Complication
+ difficultyOfPlacement: DifficultyCode
+ recommendation: Text *
+ status: CodedValue = 'completed'
+ reintubationIndicator: Boolean
«use»
«use» «use» «use»
«enumeration»
«enumeration» «enumeration»
«enumeration» Instrumentation
ConfirmationMethodCode CormackLehaneScale
«use» UrgencyCode Macintosh
Carbon dioxide Full glottic view «use»
Elective Miller
End-tidal capnography Only posterior glottis seen
Urgent Fiberoptic endoscope
Esophageal Detection Device (EDD) Only epiglottis seen
Emergent Videolaryngoscope
Supra-Sternal Tube-Tip Palpation (SSTTP) Epiglottis not seen Lighted stylet
Retrograde wire
«enumeration» None (blind)
«enumeration»
DifficultyCode LMA
TubeInsertionSiteCode
Routine
Difficult Nasal
Oral
Extremely difficult
Figure 3.3.a: Endotracheal Intubation Procedure Details
The following diagram specifies the information captured in a clinical note for a typical
Endotracheal Intubation Procedures.
P a g e | 44
class 3.3.b: Endotracheal Intubation Clinical Note

DisposableMedicalDevice
EndotrachealIntubationProcedure «DCM»
4.3 Medical Supplies::Endotracheal Tube
+ priorityCode: UrgencyCode
+ insertionSite: TubeInsertionSiteCode + diameter: PhysicalQuantity
+ procedureDateTime: PointInTime ::DisposableMedicalDevice
+ tubePlacementConfirmation: ConfirmationMethodCode [0..*] + lotNumber: InstanceIdentifier [0..1]
+ cormackLehaneScale: CodedValue + expirationDate: PointInTime [0..1]
+ laryngoscopyAttempts: IntegerNullable ::Device
+ intubationConfirmationMethod: ConfirmationMethodCode tubeUsed + deviceIdentifier: InstanceIdentifier [1..*]
+ accesInstrument: Instrumentation [0..1] + type: CodedValue
+ difficultyOfPlacement: DifficultyCode + modelNumber: InstanceIdentifier
+ recommendation: Text + vendorId: Id
+ status: CodedValue = 'completed' + softwareVersion: Text
+ reintubationIndicator: Boolean
constraints
{Diameter expressed in millimeters}
{Intubate Use Case}
+confirmationImaging +order
+complication ParameterConfiguration
* 0..1
4.1 Medical Device Settings and Configuration::
Ventilator
Complication ChestXRayOrder ProcedureOrder
+ modeCode: VentilatorModeCode = PressureControl
settings * + waveformType: WaveformType = DescendingRamp
::ParameterConfiguration
+ parameterCode: CodedValue
+orderingProvider + parameterValue: PhysicalQuantity
+orderingProvider + effectiveTime: PointInTime
+ allowableRange: PhysicalQuantityInterval
3.2 Medical Devices
General Requirements::
Clinician
+ id: InstanceIdentifier
+ name: PersonName
Figure 3.3.b: Endotracheal Intubation Clinical Note
Complication (Class)
Complication that may occur as a result of a procedure.
ChestXRayOrder (Class)
A chest X-Ray is ordered to validate the tube placement and it reoccurs every 24 hours.
ConfirmationMethodCode (Enumeration)
Type of method to verify the correct placement of the tube in the patient's airway. This
enumeration provides example code values. Actual implementation will use standardized
terminology based on LOINC and SNOMED-CT.
 RequirementTrace Endotracheal Intubation Progress Note, US Department of Veterans Affairs
Attribute Notes
P a g e | 45
Attribute Notes
Carbon dioxide
Public
End-tidal capnography
Public
Esophageal Detection
Device (EDD)
Public
Supra-Sternal Tube-Tip Used to validate placement of tube in infants, toddlers and children.
Palpation (SSTTP) (clinicaltrials.gov)
Public
CormackLehaneScale (Enumeration)
Indicates the classification according to the Cormack Lehane Scale.
This is an example value set. Actual implementation will use standardized terminology
provided by LOINC.
Attribute Notes
Full glottic view
Public
Only posterior glottis

seen
Public
Only epiglottis seen

Public
Epiglottis not seen

Public
DifficultyCode (Enumeration)
The degree of difficulty in placing the endotracheal tube in the patient's airway.
This is an example value set. Actual implementation will use standardized terminology (e.g.
LOINC)
Attribute Notes
P a g e | 46
Attribute Notes
Routine
Public
Difficult
Public
Extremely difficult
Public
Instrumentation (Enumeration)
A type of device used to provide access, illumination, and allow observation or manipulation
of body cavities, hollow organs, and canals. (Standard Product Nomenclature)
LOINC)
Attribute Notes
Macintosh
Public
Miller
Public
Fiberoptic endoscope (SNOMED 257216002)

Public
Videolaryngoscope
Public
Lighted stylet
Public
Retrograde wire
Public
None (blind)
Public
LMA
Public
TubeInsertionSiteCode (Enumeration)
This is an example value set. Actual implementation will use standardized terminology. The
P a g e | 47
actual implementation will use a subset of LOINC body site codes to indicate the insertion
site for tube.
Attribute Notes
Nasal
Public
Oral
Public
UrgencyCode (Enumeration)
LOINC)
Attribute Notes
Elective
Public
Urgent
Public
Emergent
Public
3.4 Assessment
This section describes a reusable classes identified during the analysis of the clinical use
cases and the associated clinical Workflows. This section is intended to capture clinician
assessments.
Note to the reviewer: This section is a very early draft and it relies on references to
externally-defined DCMs.
.
P a g e | 48
class 3.4: Patient Assessments

«choice»
Assessment
RespiratoryAssessment
PhysicalAssessment NeurologicalAssessment
+ respirationPresent: boolean
+ qualityOfRespiration: CodeValueNullable
1..*
This model would reuse
height and weight DCMs ArterialBloodGas::
defined in the DCM Arterial Blood Gas
Informative ballot. Panel
Figure 3.4: Patient Assessments
Assessment (Class)
This class represents an abstract, choice of one or more assessment that may be
administered to a patient during intubation.
NeurologicalAssessment (Class)
This class is a placeholder for a neurological assessment. In the case of intubation,
however, the most important type of assessment is a respiratory assessment.
PhysicalAssessment (Class)
A physical assessment to evaluate the condition of a patient is an important element in
determining the need to perform an intubation procedure.
RespiratoryAssessment (Class)
This type of assessment represents a pre-condition for intubation as a start of the case. This
class represents the result of the assessment performed by a clinician.
Attribute Notes
respirationPresent
boolean
Public
qualityOfRespiration
CodeValueNullable
Public
4. Detailed Clinical Models
The following section describes candidate DCMs derived from the business use cases and on
the Analysis Information Model. Unlike the classes and associations included in the Analysis
P a g e | 49
Information Model, a DCM will provide precise semantics and structure including standard-
based data types.
 RequirementTrace Use Case Analysis
4.1 Medical Device Settings and Configuration
This section describes a set of reusable DCMs identified during the analysis of the clinical
use cases and the associated clinical Workflows.
This DCM package describes devices intended to provide treatment (e.g. ventilator, infusion
pump) as well as their settings.
Note to reviewers: Please comment both on the content and representation of the DCMs
in this package.
The following diagram identifies some of the devices used provide therapy to patients.
The classes listed here were based on the use cases specified in this document.
P a g e | 50
class 4.1.a: Medical Device Information Context and Associated DCMs

Information Analysis Context
«enumeration»
«enumeration»
WaveformType
VentilatorModeCode
Rectangular
VolumeControl 3.2 Medical Devices General Requirements::
Sinusoidal
PressureControl Device
AscendingRamp
DescendingRamp {abstract}
«use» + type: CodedValue
«use» + modelNumber: InstanceIdentifier
+ vendorId: Id
Ventilator + softwareVersion: Text
+ modeCode: VentilatorModeCode = PressureControl

+ waveformType: WaveformType = DescendingRamp
configured
1..*
VentilatorSetting
::ParameterConfiguration 3.2 Medical Devices General Requirements::
+ parameterCode: CodedValue ParameterConfiguration
+ parameterValue: PhysicalQuantity
+ effectiveTime: PointInTime + parameterCode: CodedValue
+ allowableRange: PhysicalQuantityInterval + parameterValue: PhysicalQuantity
+ effectiveTime: PointInTime
constraints + allowableRange: PhysicalQuantityInterval
{'parameterCode' is encoded using LOINC}
{Use Cases}
«DCM» «DCM»
«DCM»
PositiveExpiratoryEndPressure FractionInspiredOxygen
TidalVolume
::ParameterConfiguration ::ParameterConfiguration
::ParameterConfiguration
+ parameterCode: CodedValue + parameterCode: CodedValue
+ parameterCode: CodedValue
+ parameterValue: PhysicalQuantity + parameterValue: PhysicalQuantity
+ parameterValue: PhysicalQuantity
+ effectiveTime: PointInTime + effectiveTime: PointInTime
+ allowableRange: PhysicalQuantityInterval + allowableRange: PhysicalQuantityInterval
+ allowableRange: PhysicalQuantityInterval
constraints constraints
constraints
{'parameterCode' is encoded and fixed to '20077-4'} {'parameterCode' is fixed as '19996-8'.}
{'parameterValue' is expressed in "cmH2O"} {'parameterValue' is expressed as a percentage} {'parameterValue' expressed in mL}
::VentilatorSetting ::VentilatorSetting {'parameterCode' is set as '20113-7'}
::VentilatorSetting
{ 'parameterCode' is encoded using LOINC } { 'parameterCode' is encoded using LOINC }
{ Use Cases } { Use Cases } { 'parameterCode' is encoded using LOINC }
{ Use Cases }
«DCM»
PressureSupport «DCM» «DCM»
::ParameterConfiguration RespiratoryRate InspiratoryRate
+ parameterCode: CodedValue ::ParameterConfiguration ::ParameterConfiguration
+ parameterValue: PhysicalQuantity + parameterCode: CodedValue + parameterCode: CodedValue
+ effectiveTime: PointInTime + parameterValue: PhysicalQuantity + parameterValue: PhysicalQuantity
+ allowableRange: PhysicalQuantityInterval + effectiveTime: PointInTime + effectiveTime: PointInTime
constraints
{'parameterCode' is encoded and fixed to '20079-0'} constraints constraints
{'parameterValue' is expressed in ...} {'parameterValue' is expressed in beats per minute} {'parameterCode' is fixed as '19931-5'}
{Not applicable if ventilator is set to volume control mode} {'parameterCode' is fixed as '19834-1'} {'parameterValue' is expressed in liters per minute}
::VentilatorSetting ::VentilatorSetting ::VentilatorSetting
{ 'parameterCode' is encoded using LOINC } { 'parameterCode' is encoded using LOINC } { 'parameterCode' is encoded using LOINC }
{ Use Cases } { Use Cases } { Use Cases }
«DCM»
InspiratoryTime
Only the constraint
introduced by
constraints InspiratoryTime are visible.
{'parameterCode' is fixed to '19973-7'}
{'parameterValue' is expressed in seconds}
Figure 4.1.a: Medical Device Information Context and Associated DCMs
P a g e | 51
The following are a set of candidate DCMs intended to specify the ventilator settings
required to support the Intubate Patient Use Case, Manage Patient on Ventilator, and
Liberate Patient from Ventilator.
Note that each parameter applies a different set of constraints to the generic ventilator
setting.
class 4.1.b: DCMs representing Ventilator Settings

VentilatorSetting VentilatorSetting
«DCM» «DCM»
PressureSupport FractionInspiredOxygen
{'parameterCode' is encoded and fixed to '20079-0'} {'parameterCode' is fixed as '19996-8'.}
{'parameterValue' is expressed in ...} {'parameterValue' is expressed as a percentage}
{Not applicable if ventilator is set to volume control mode} ::VentilatorSetting
::VentilatorSetting { 'parameterCode' is encoded using LOINC }
{ 'parameterCode' is encoded using LOINC } { Use Cases }
{ Use Cases }
«DCM» «DCM»
InspiratoryRate PositiveExpiratoryEndPressure
{'parameterCode' is fixed as '19931-5'} {'parameterCode' is encoded and fixed to '20077-4'}
{'parameterValue' is expressed in liters per minute} {'parameterValue' is expressed in "cmH2O"}
::VentilatorSetting ::VentilatorSetting
{ Use Cases } { Use Cases }
VentilatorSetting
«DCM»
InspiratoryTime
constraints
«DCM» {'parameterCode' is fixed to '19973-7'} «DCM»
RespiratoryRate {'parameterValue' is expressed in seconds} TidalVolume
{'parameterValue' is expressed in beats per minute} {'parameterValue' expressed in mL}
{'parameterCode' is fixed as '19834-1'} {'parameterCode' is set as '20113-7'}
::VentilatorSetting ::VentilatorSetting
{ Use Cases } { Use Cases }
Figure 4.1.b: DCMs representing Ventilator Settings
P a g e | 52
VentilatorSetting (Class)
This class specifies the generic ventilator setting including their identity and value. Note that
in addition to its attributes this class specifies a constraint on code system used to specific
the parameter's name. Typically, in an analysis model this level of detail is sufficient.
Similarly in design or platform-specific models this would constitute a sufficient detail.
The primary code system used to specify code for the parameterCode is LOINC. This class is
the base class for a set of specific DCM candidates..
 OCL 'parameterCode' is encoded using LOINC
inv: self.parameterCode.codeSystemName = 'LOINC'
 RequirementTrace Use Cases
FractionInspiredOxygen (Class)
This class is used to capture the fraction of inspired oxygen (FiO2) reported by a ventilator.
This class inherits the attributes specified in DeviceParameter class and the constraints
added by the VentilatorSetting class.
 OCL 'parameterValue' is expressed as a percentage
inv: parameterValue.unit = '%'
 OCL 'parameterCode' is fixed as '19996-8'.
inv: self.parameterCode.code= '19996-8'
InspiratoryRate (Class)
This class represents the gas flow peak value setting; its value varies by protocol and
patient. It represents the rate of change of volume per unit of time. This class inherits the
attributes specified in DeviceParameter class and the constraints added by the
VentilatorSetting class.
 OCL 'parameterCode' is fixed as '19931-5'
inv: self.parameterCode.code = '19931-5'
 OCL 'parameterValue' is expressed in liters per minute
inv: parameterValue.unit = 'l/min'
InspiratoryTime (Class)
The class is used to specify the inspiration setting number of seconds. This class inherits the
 OCL 'parameterCode' is fixed to '19973-7'
 OCL 'parameterValue' is expressed in seconds
inv: parameterValue.unit = 's'
PositiveExpiratoryEndPressure (Class)
This class is used to specify the details of PEEP. This class inherits the attributes specified
in DeviceParameter class and the constraints added by the VentilatorSetting class.
 OCL 'parameterCode' is encoded and fixed to '20077-4'
 OCL 'parameterValue' is expressed in "cmH2O"
inv: self.parameterValue.unit = 'cmH2O'
PressureSupport (Class)
Pressure Support is not applicable to Assist-Control ventilator mode. This class inherits the
P a g e | 53
 OCL 'parameterCode' is encoded and fixed to '20079-0'
inv: self.parameterCode.code =' 20079-0'
 OCL 'parameterValue' is expressed in ...
inv: self.parameterValue.unit = '...'
 Pre-condition Not applicable if ventilator is set to volume control mode
pre: Ventilator.mode <> 'Control'
RespiratoryRate (Class)
This setting specifies a desired respiratory rate (RR), it may be set as target EtCO2 level in
a closed loop system. This class inherits the attributes specified in DeviceParameter class
and the constraints added by the VentilatorSetting class.
 OCL 'parameterValue' is expressed in beats per minute
inv: self.parameterValue.unit = 'min'
 OCL 'parameterCode' is fixed as '19834-1'
TidalVolume (Class)
The class represent a Tidal Volume (Vt) setting. Its value varies by protocol or patient. This
class inherits the attributes specified in DeviceParameter class and the constraints added by
the VentilatorSetting class.
 OCL 'parameterValue' expressed in mL
inv: self.parameterValue.unit = 'l/min'
 OCL 'parameterCode' is set as '20113-7'
Ventilator (Class)
This class represents the properties of a ventilator and extends the generic Device class.
A medical ventilator is a device designed to provide mechanical ventilation to a patient.
Ventilators are chiefly used in intensive care medicine, home care, and emergency medicine
(as standalone units) and in anesthesia (as a component of an anesthesia machine). In its
simplest form, a ventilator consists of a compressible air reservoir, air and oxygen supplies,
a set of valves and tubes, and a disposable or reusable patient set. The air reservoir is
pneumatically compressed several times a minute to deliver an air/oxygen mixture to the
patient; when overpressure is released, the patient will exhale passively due to the lungs '
elasticity. The oxygen content of the inspired gas can be set from 21 percent (ambient air)
to 100 percent (pure oxygen). Pressure and flow characteristics can be set mechanically or
electronically. Ventilators may also be equipped with monitoring and alarm systems for
patient-related parameters (e.g. pressure and flow) and ventilator function.
Attribute Notes
modeCode The ventilator mode is a represented as a code. The mode affects required settings
VentilatorModeCode of the ventilator.
Public
PressureControl
waveformType This attribute specifies the waveform setting.

WaveformType
Public DescendingRamp
P a g e | 54
VentilatorModeCode (Enumeration)
This enumeration is a list of the most relevant ventilator modes - applicable to intubation
and other use cases. This list is not exhaustive but representative of relevant values.
Attribute Notes
VolumeControl Assist-Control (AC), a mode of mechanical ventilator operation based on volume
Public control. The choice of mode affects other required settings.
PressureControl Pressure control is a ventilator function designed to overcome resistance introduced

Public by the ETT.
WaveformType (Enumeration)
This enumeration is intended to list the waveform types relevant to setting up a patient
during intubation and managing the patient over time.
Attribute Notes
Rectangular Rectangular waveform
Public
Sinusoidal Sinusoidal waveform

Public
AscendingRamp Ascending Ramp waveform

Public
DescendingRamp Descending Ramp waveform

Public
4.2 Medical Device Measurements
This section describes the information identified as a result of analyzing the clinical use
cases and the associated clinical Workflows in this specification. This section describes a
type of devices used to measure physiological parameters during an intubation procedure,
in order to prepare or wean the patient.
The following diagram is describing candidate DCMs derived from classes identified as a
result of analyzing the information requirements documented in the business use cases.
P a g e | 55
class 4.2.a: Monitoring Device Information Context and Associated DCMs

Information Analysis Context
3.2 Medical Devices General Requirements::

Device 3.2 Medical Devices General Requirements::
{abstract} DeviceMeasurement
+ deviceIdentifier: InstanceIdentifier [1..*] + code: CodedValue

+ value: PhysicalQuantity
+ type: CodedValue
+ modelNumber: InstanceIdentifier + effectiveTime: PointInTime
+ vendorId: Id
+ softwareVersion: Text + abnormalFlag: CodedValue [0..1]
+ bodyPosition: CodedValue [0..1]
+ bodySite: CodedValue [0..1]
+ correctedEffectiveTime: PointInTime [0..1]
MonitoringDevice
PhysiologicalMonitor
+ mode PulseOximeter ECGMonitor
1.. +measurementDevice
+measurement 1..* 1 +device 1
PhysiologicalMeasurement +device
::DeviceMeasurement +measurement
1..*
+ code: CodedValue
+ value: PhysicalQuantity ElectroCardiogramWaveform
+ waveformImage: EncapsulatedData
+ waveformData: PhysicalQuantity [1..*]
+ abnormalFlag: CodedValue [0..1]
+ effectiveInterval: TimeInterval
+ bodyPosition: CodedValue [0..1]
+ bodySite: CodedValue [0..1]
+measurement
constraints
{Use Case: Intubate Patient - Unplanned}
1..*
«DCM»
«DCM» SaturationOfPeripheralOxygen
BodyTemperatureMeasurement ::DeviceMeasurement
::DeviceMeasurement + code: CodedValue
+ code: CodedValue + value: PhysicalQuantity
+ value: PhysicalQuantity + effectiveTime: PointInTime
+ effectiveTime: PointInTime + measurementMethod: CodedValue [0..*]
+ measurementMethod: CodedValue [0..*] + abnormalFlag: CodedValue [0..1]
+ abnormalFlag: CodedValue [0..1] + bodyPosition: CodedValue [0..1]
+ bodyPosition: CodedValue [0..1] + bodySite: CodedValue [0..1]
+ bodySite: CodedValue [0..1] + correctedEffectiveTime: PointInTime [0..1]
constraints
constraints {'parameterCode' is fixed as' 59408-5'}
{'parameterCode' is encoded in LOINC and fixed as '11289-6'} {'parameterValue' is expressed as a percentage}
{'parameterValue' is expressed in degrees Fahrenheit or Celsius} {'parameterCode' is encoded using LOINC}
::PhysiologicalMeasurement {Use Case: Intubate Patient - Unplanned}
{ Use Case: Intubate Patient - Unplanned }
Figure 4.2.a: Monitoring Device Information Context and Associated DCMs
P a g e | 56
The following are a set of candidate DCMs intended to specify the parameters measured by
monitoring devices; these measurements are required to support the requirements specified
in Intubate Patient Use Case, Manage Patient on Ventilator, and Liberate Patient from
Ventilator Use Case.
class 4.2.b: DCMs representing the Body Temperature and SpO2 measurements
PhysiologicalMeasurement DeviceMeasurement
«DCM» «DCM»
BodyTemperatureMeasurement SaturationOfPeripheralOxygen
::DeviceMeasurement ::DeviceMeasurement
+ code: CodedValue + code: CodedValue
+ value: PhysicalQuantity + value: PhysicalQuantity
+ measurementMethod: CodedValue [0..*] + measurementMethod: CodedValue [0..*]
+ abnormalFlag: CodedValue [0..1] + abnormalFlag: CodedValue [0..1]
+ bodyPosition: CodedValue [0..1] + bodyPosition: CodedValue [0..1]
+ bodySite: CodedValue [0..1] + bodySite: CodedValue [0..1]
+ correctedEffectiveTime: PointInTime [0..1] + correctedEffectiveTime: PointInTime [0..1]
{'parameterCode' is encoded in LOINC and fixed as '11289-6'} {'parameterCode' is fixed as' 59408-5'}
{'parameterValue' is expressed in degrees Fahrenheit or Celsius} {'parameterValue' is expressed as a percentage}
::PhysiologicalMeasurement {'parameterCode' is encoded using LOINC}
{ Use Case: Intubate Patient - Unplanned } {Use Case: Intubate Patient - Unplanned}
Figure 4.2.b: DCMs representing the Body Temperature and SpO2 measurements
BodyTemperatureMeasurement (Class)
This class is a candidate DCM and a specialization of VitalSignMeasurement and
DeviceParameter. This candidate DCM is intended to specify the constraints required to
represent the patient's body temperature as measured by a vital sign monitor.
This is a candidate DCM intended to capture the details of collecting and sharing
interoperable data.
 OCL 'parameterCode' is encoded in LOINC and fixed as '11289-6'
 OCL 'parameterValue' is expressed in degrees Fahrenheit or Celsius
inv: self.parameterValue.unit = 'C' or self.parameterValue.unit = 'F'
SaturationOfPeripheralOxygen (Class)
Saturation of Peripheral Oxygen - SPO2- measured by a pulse Oximeter. This class inherits
all the attribute and association of DeviceParameter.
This is a candidate DCM for conveying the details of an oximeter result.
 OCL 'parameterCode' is fixed as' 59408-5'
 OCL 'parameterValue' is expressed as a percentage
inv: self.parameterValue.unit = '%'
 OCL 'parameterCode' is encoded using LOINC
ElectroCardiogramWaveform (Class)
This class is intended to specify an electrocardiogram. This version of this class intended to
P a g e | 57
capture only a small set of representative attributes.

The waveform data, even if it is not of diagnostic quality, it may be relevant to the medical
record (e.g. document an episode of arrhythmia).
Attribute Notes
waveformImage This attribute represents the ECG strip as an image.
EncapsulatedData
Public
waveformData This attribute represents the data points.

PhysicalQuantity
Public
[1..*]
effectiveInterval This attribute specifies the start and end of the waveform snippet.
TimeInterval
Public
MonitoringDevice (Class)
This class is intended to capture the properties of monitoring devices and extends the
generic medical device class.
PhysiologicalMonitor (Class)
This class is used to describe the properties of a vital sign monitor. It is a specialization of
MonitoringDevice class and thus it inherits its attributes.
Attribute Notes
mode Continuous or spot-check.
Public
PulseOximeter (Class)
This class is intended to capture the properties specific to a pulse Oximeter. It is a
specialization of MonitoringDevice class and thus it inherits its attributes.
PhysiologicalMeasurement (Class)
This class intended to capture the constraints required to represent vital sign results.
This class inherits the attributes specified in the DeviceParameter class.
P a g e | 58
4.3 Medical Supplies
This section describes a single candidate DCM identified during the analysis of the clinical
use cases and the associated clinical Workflows. This section describes the consumable
medical devices required by the use cases.
The following diagram specifies a set of proprieties common to all consumable devices and
those that are specific to an Endotracheal Tube.
This diagram also shows some of the representative data types that are used to convey the
semantics of the DCM.
class 4.3: Disposable Device DCM

Information Analysis Context Data Types
3.2 Medical Devices General Requirements:: Id

Device 5. Data Types::InstanceIdentifier
{abstract} + assigningAuthorityName: String [0..1]
+ deviceIdentifier: InstanceIdentifier [1..*] + extension: String [0..1]
«use» ::Id
+ type: CodedValue
+ modelNumber: InstanceIdentifier + root: OID
+ vendorId: Id
DisposableMedicalDevice
{abstract}
+ lotNumber: InstanceIdentifier [0..1]
+ expirationDate: PointInTime [0..1]
«DCM»
Endotracheal Tube
+ diameter: PhysicalQuantity 5. Data Types::PhysicalQuantity
::DisposableMedicalDevice
+ nullFlavor: NullFlavor [0..1]
+ lotNumber: InstanceIdentifier [0..1]
«use» + value: Real [0..1]
+ expirationDate: PointInTime [0..1]
+ unit: CodedValue [0..1]
::Device
+ type: CodedValue
+ vendorId: Id
constraints
{Diameter expressed in millimeters}
{Intubate Use Case}
Figure 4.3: Disposable Device DCM
Endotracheal Tube (Class)

This class is used to describe the properties of a tube (e.g. Endotracheal Tube). As seen in
the associated diagram, this class is a specialization of Device and ConsumableDevice and
inherits attributes from both.
P a g e | 59
Note that the attributes of this class are constrained using OCL and the requirements are
based on the Intubate Use Case.
 OCL Diameter expressed in millimeters
inv: self.diameter.unit = 'mm'
 RequirementTrace Intubate Use Case
This class is based on requirements specified in the Intubate Use Case.
Attribute Notes
diameter PhysicalQuantity This attribute is used to specify the size of a tube as a physical quantity (a numeric
Public value and a units of measure)
DisposableMedicalDevice (Class)
This class is intended to capture the properties of a consumable medical device. This class
supports additional attributes intended to specify the device and, if applicable, its expiration
date.
Attribute Notes
lotNumber The lot number is used to track a device for quality control purposes.
InstanceIdentifier
Public
[0..1]
expirationDate This attribute is used to specify the expiration date, if applicable.
PointInTime
Public
[0..1]
5. Data Types
The following section specifies a set of reusable data types based on the HL7 Version 3
abstract data types. These data types have been constrained to support the analysis
process required to derive a set of DCMs.
Note: The following is a technical specification, it supports the modeling effort but is not
required to understand the high-level information requirements.
Address (Class)
A physical address at which the person resides or may be contacted.
Attribute Notes
addressType Indicates the kind of address that is contained within this class. Examples include
AddressType primaryHome, Work, etc. Note that in HL7 V3, this concept is part of the Address
Public data type (the "use code"). This concept is made explicit in this Address class,
because this is a platform-independent model - non V3 implementations will need
other mechanisms to deal with the type.
effectiveDateRange int The time period for which the address is a valid location for the person or
Public organization. The data type is a TimeInterval, which includes both a start date and
end date, either of which may be empty.
P a g e | 60
Attribute Notes
line1 String The first line of a mailing address. Unlike HL7, we have chosen not to break up the
Public parts of each line.
[0..1]
line2 String The second line of a mailing address. Unlike HL7, we have chosen not to break up
Public the parts of each line.
[0..1]
line3 String The third line of a mailing address. Unlike HL7, we have chosen not to break up the
Public parts of each line.
[0..1]
city String An Address Part (ADXP) that contains the name of the city, town, village, or other
Public community or delivery center.
[0..1]
county County A region created by territorial division for the purpose of local government. In the
Public United States, a county (or parish in Louisiana) is the largest administrative district
within a state. This property is used primarily for statistical and pricing information
(i.e., the same service may be more expensive in an affluent section of the country
than in a less-affluent portion).
postalCode String An Address Part (ADXP) that contains a postal code designating a region defined by
Public the postal service.
[0..1]
country CodedValue An Address Part (ADXP) that contains the Country of the address.
Public
[0..1]
AddressType (Enumeration)
This enumeration describes types of Addresses at which a person or organization exists or
can be reached.
Attribute Notes
mobileContact A telecommunication device that moves and stays with its owner. May have
AddressType characteristics of all other use codes, suitable
Public
for urgent matters, not the first choice for routine business.
pager AddressType A paging device suitable to solicit a callback or to leave a very short message.
Public
primaryHome The primary home, to reach a person after business hours.

AddressType
Public
temporaryAddress Thetemporaryaddresswhereapersonresides.Anaddressthatisdifferentfromtheperman
AddressType entaddress,butatwhichthepersonisresidingforalimited,definedperiodoftime.
Public
Note that for military personnel, this address may represent a location at which the
person is temporarily assigned or
deployed.
P a g e | 61
Attribute Notes
vacationHome A vacation home, to reach a person while on vacation
AddressType
Public
workPlace AddressType An office address. First choice for business related contacts during business hours.
Public
Any (Class)
This abstract class is used to represent a data type that is not known at the logical model
level, but rather will be substituted with a (set of) real data type(s) when transformed to a
given platform.
BirthAddress (Class)
A refinement of AD that contains only a city,state,and country,all of which are optional.
Attribute Notes
city String An Address Part (ADXP) that contains the name of the city, town, village, or other
Public community or delivery center.
[0..1]
state String An Address Part (ADXP) that contains a sub-unit of a state or province. A sub-unit
Public of a country with limited sovereignty in a federally organized country.
[0..1]
country CodedValue An Address Part (ADXP) that contains the Country of the address.
Public
[0..1]
Boolean (Class)
This data type specifies a boolean that may be null and a reason for the null value is
specified as a NullFlavor.
Attribute Notes
nullFlavor NullFlavor "An indicator of a data value's exceptional status, sometimes also denoting the
Public manner and rationale for that status.Null values are also known as exceptional
values. This is to denote that the information contained in the value is an exception
[0..1] to the expected value domain that applies to the type. The information may either
be missing or partially present, or even completely present but not valid with
respect to the constraints imposed by the Constraining Model" (HL7 Version 3
Abstract Data types)
value boolean Boolean value

Public
[0..1]
CodeValueNullable (Class)
This data type specifies a coded value that may be null and the reason for the null code is
specified as a NullFlavor.
P a g e | 62
Attribute Notes
CodedValue (Class)
Code class was created to support the generic coded attributes (e.g coded descriptors).
Attribute Notes
code String The plain code symbol defined by the code system. For example, "784.0" is the
Public code symbol of the ICD-9 code "784.0" for headache.
codeSystem OID Specifies the code system that defines the code.
Public
codeSystemVersion
String
Public
codeSystemName String The common name of the coding system.

Public
displayName String name or title for the code, under which the sending system shows the code value to
Public its users.
County (Class)
Indicates a county or parish within a State of the United States of America. This class is not
to be used for non-US locations.
Attribute Notes
county CodedValue Indicates a county or parish within a State of the United States of America.
Public
EncapsulatedData (Class)
Data that is primarily intended for human interpretation or for further machine processing
outside the scope of HL7. This includes unformatted or formatted written language,
multimedia data, or structured information in as defined by a different standard (e.g., XML-
signatures.) Instead of the data itself, an ED may contain only a reference (see TEL.) Note
that ST is a specialization of the ED where the mediaType is fixed to text/plain.
Attribute Notes
P a g e | 63
Attribute Notes
mediaType CodedValue Identifies the type of the encapsulated data and identifies a method to interpret or
Public render the data.
binary Binary object

Public
Id (Class)
Generic Identifier Class
Attribute Notes
root OID A unique identifier that guarantees the global uniqueness of the instance identifier.
Public The root alone may be the entire instance identifier. This string should be one of
the following RUID, OID or UUID
InstanceIdentifier (Class)
This data type is a constraint of the HL7 Version 3 II data type.
Attribute Notes
assigningAuthorityNam A human readable name or mnemonic for the assigning authority. The Assigning
e String Authority Name has no computational value. The purpose of a Assigning Authority
Public Name is to assist an unaided human interpreter of an II value to interpret the
authority. Note: no automated processing must depend on the assigning authority
[0..1] name to be present in any form.
extension String A character string as a unique identifier within the scope of the identifier root.
Public
[0..1]
IntegerInterval (Class)
An interval of integer numbers stating the minimal and maximal number of repetitions of
the Act.
Attribute Notes
low Integer The minimal number of repetitions of the Act.
Public
high Integer The maximal number of repetitions of the Act.

Public
[0..1]
IntegerRatio (Class)
A ratio (numerator : denominator) specifying the relative quantities of the Entity playing the
Role in the Entity scooping the Role, used for Roles that represent composition relationships
between the scooping and playing Entities.
Attribute Notes
P a g e | 64
Attribute Notes
numerator Integer The quantity that is being divided in the ratio. The default is the integer number 1
Public
denominator Integer The quantity that divides the numerator in the ratio. The default is the integer
Public number 1 (one.) The denominator must not be zero.
Money (Class)
Indicates the monetary amount to be transferred from the debit to the credit account.
Attribute Notes
currency CodedValue Currencies are the units in which monetary amounts are denominated in different
Public economic regions.
value Real The amount of money in some currency.

Public
NonUsMailingAddress (Class)
This data type extends the Address to specify a jurisdiction.
Attribute Notes
jurisdiction String
Public
NullFlavor (Enumeration)
This enumeration specifies the null flavors specified for HL7 Version 3 data types.
Attribute Notes
NI NullFlavor No Information, this is the default null flavor/reason.
Public
INV NullFlavor Invalid

Public
OTH NullFlavor Other

Public
NINF NullFlavor Negative Infinity

Public
PINF NullFlavor Positive Infinity

Public
P a g e | 65
Attribute Notes
UNC NullFlavor Unencoded
Public
DER NullFlavor Derived

Public
UNK NullFlavor Unknown

Public
ASKU NullFlavor Asked but unknown

Public
NAV NullFlavor Temporarily unavailable

Public
QS NullFlavor Sufficient quantity

Public
NASK NullFlavor Not asked

Public
TRC NullFlavor Trace

Public
MSK NullFlavor Masked

Public
NA NullFlavor Not applicable

Public
PersonName (Class)
The name of the person. Uses the VHIM-constrained Person Name data type.
Attribute Notes
prefix String "A prefix has a strong association to the immediately following name part. A prefix
Public has no implicit trailing white space (it has implicit leading white space though).
Note that prefixes can be inverted" (HL7)
[0..*] A Person Name Prefix is usually an academic or nobility title. An Academic title
includes a prefix like "Dr." There are still people with nobility titles (aristocrats).
German "von" is generally a nobility title, not a mere voorvoegsel. Others are "Earl
of" or "His Majesty King of..." etc. Rarely used nowadays, but some systems do
keep track of this.
given String "Given name (don't call it "first name" since this given names do not always come
Public first)" (HL7)
[0..*]
P a g e | 66
Attribute Notes
nickname String "A callme name is (usually a given name) that is preferred when a person is directly
Public addressed." (HL7)
[0..1]
family String "Family name, this is the name that links to the genealogy" (HL7)
Public
suffix String "A suffix has a strong association to the immediately preceding name part. A prefix
Public has no implicit leading white space (it has implicit trailing white space though).
Suffices can not be inverted" (HL7)
[0..*]
initials String
Public
[0..1]
PhysicalQuantity (Class)
The amount that was or is to be supplied
Attribute Notes
value Real Value of the quantity

Public
[0..1]
unit CodedValue The unit of measure specified in the Unified Code for Units of Measure (UCUM)
Public
[0..1]
PhysicalQuantityInterval (Class)
The amount of the therapeutic agent or other substance given at one administration event.
Attribute Notes
lowValue Real The magnitude of the quantity measured in terms of the unit.
Public
lowUnit CodedValue The unit of measure specified in the Unified Code for Units of Measure (UCUM) [].
Public
highValue Real The magnitude of the quantity measured in terms of the unit.
Public
P a g e | 67
Attribute Notes
highUnit CodedValue The unit of measure specified in the Unified Code for Units of Measure (UCUM)
Public
PointInTime (Class)
A quantity specifying a point on the axis of natural time. A point in time is most often
represented as a calendar expression.
Semantically, however, time is independent from calendars and best described by its
relationship to elapsed time (measured as a physical quantity in the dimension of time.) A
point in time plus an elapsed time yields another point in time. Inversely, a point in time
minus another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as the amount of time
that has elapsed from some arbitrary zero-point, called an epoch. Because there is no
absolute zero-point on the time axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time is - absolutely speaking
- "twice as late" as another point in time.)
Given some arbitrary zero-point, one can express any point in time as an elapsed time
measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-
offset form is used as a semantic representation here, without implying that any system
would have to implement the TS data type in that way. Systems that do not need to
compute distances between points in time will not need any other representation than a
calendar expression literal
A data type containing date/time information.&nabs; This data type is a placeholder, as
various platforms have differing
built-in date/time data types.&nabs; It is anticipated that this data type will be replaced by
a different data type when
transforming to a particular implementation platform.
Attribute Notes
literal String For the default Gregorian calendar the calendar expression literals of this
Public specification conform to the constrained ISO 8601 that is defined in ISO 8824
(ASN.1) under clause 32 (generalized time) and to the HL7 version 2 TS data
format.
Range (Class)
This data type is used to specify reference ranges as in interval between two numeric values
(low and high).
Attribute Notes
P a g e | 68
Attribute Notes
low Real Low value of the range.

Public
[0..1]
high Real High value of the range.
Public
[0..1]
unit CodedValue The unit of measure specified in the Unified Code for Units of Measure (UCUM)
Public
[0..1]
RateQuantity (Class)
Identifies the speed with which the substance is introduced into the subject. Expressed as a
physical (extensive) quantity over elapsed time (e.g., examples are 100 mL/h, 1 g/d, 40
mmol/h, etc.)
Attribute Notes
low PhysicalQuantity This is the low limit of the interval.
Public
high PhysicalQuantity This is the high limit of the interval.

Public
period TimeQuantity A time duration specifying as a reciprocal measure of the frequency at which the
Public periodic interval repeats.
Ratio (Class)
A quantity constructed as the quotient of a numerator quantity divided by a denominator
quantity. Common factors in the numerator and denominator are not automatically
cancelled out. The RTO data type supports titers (e.g., "1:128") and other quantities
produced by laboratories that truly represent ratios. Ratios are not simply "structured
numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios. In
many cases the REAL should be used instead of the RTO.
Ratios are different from rational numbers, i.e., in ratios common factors in the numerator
and denominator never cancel out. A ratio of two real or integer numbers is not
automatically reduced to a real number.
Attribute Notes
P a g e | 69
Attribute Notes
numerator Real The quantity that is being divided in the ratio. The default is the integer number 1
Public (one.)
denominator Real The quantity that divides the numerator in the ratio. The default is the integer
Public number 1 (one.) The denominator must not be zero.
Real (Class)
A data type containing non-whole numbers. This data type is a placeholder, as various
platforms have differing built-in floating-point data types. It is anticipated that this data
type will be replaced by a different data type when transforming to a particular
implementation platform.
Attribute Notes
value Real Real number absolute value

Public
[0..1]
Telecommunications (Class)
A collection of electronic addresses at which the person may be reached. This includes
telephones, email addresses, etc.
Attribute Notes
addressType Indicates the kind of communications address that is contained within this class.
AddressType Examples include primaryHome, Work, etc. Note that in HL7 V3, this concept is
Public part of the Telecom data type (the "use code"). This concept is made explicit in
this Telecommunications class, because this is a platform-independent model - non
V3 implementations will need other mechanisms to deal with the type.
effectiveDateRange int The time period for which the phone number or communications address is valid for
Public the person or organization. The data type is a TimeInterval, which includes both a
start date and end date, either of which may be empty.
universalResourceId Represents a telecommunications address at which the person or organization may

String be reached. Note that this property is a simply a string, the formatting of which will
Public depend on the type of communications address employed.
Text (Class)
P a g e | 70
This class is used to specify string values that may be null.
Attribute Notes
value String Text string

Public
[0..1]
TimeInterval (Class)
An interval of time specified as an interval between two date/time (high and low).
Attribute Notes
low PointInTime This is the low limit of the interval.
Public
[0..1]
high PointInTime This is the high limit of the interval.
Public
[0..1]
width TimeQuantity The difference between high and low boundary. The purpose of distinguishing a
Public width property is to handle all cases of incomplete information symmetrically. In
any interval representation only two of the three properties high, low, and width
[0..1] need to be stated and the third can be derived.
TimeQuantity (Class)
A length of time specified as a Physical Quantity, e.g., 5 minutes, 2.5 hours.
Attribute Notes
value Real Value of the number of time units
Public
unit CodedValue The unit of measure specified in the Unified Code for Units of Measure (UCUM).
Public
UsMailingAddress (Class)
A specialization of Address that is used for U.S. addresses. Note that the state attribute
may only contain a code for a U.S. State, territory, or a PO box.
Attribute Notes
state CodedValue An Address Part (ADXP) that contains a sub-unit of a state or province. A sub-unit
Public of a country with limited sovereignty in a federally organized country.
P a g e | 71
Annexes
Annex A: Clinical Scenarios
This section includes the clinical scenarios developed with the subject matter experts:
http://gforge.hl7.org/gf/download/docmanfileversion/5782/7424/VentilatorClinicalScenario_
_1_rev4.docx
The use cases derived from the detailed scenario are available at:
http://gforge.hl7.org/gf/project/dcmmd/docman/?subdir=256
Annex B: Sample Endotreacheal Intubation Progress Notes
The following section illustrates the information required to document an Endotracheal

Intubation Procedure. This information is based on a application deployed by the US
Department of Veterans Affairs.
http://gforge.hl7.org/gf/download/docmanfileversion/5784/7426/EndotrachealIntubation-
ApplicationExample.pptx
Annex C: Ventilator Modes and Voumentric Delivery
This annex identifies future areas of analysis to elaborate the workflows and information
analysis.
A number of views of information models supporting and inter-relating DCM‘s are developed
at appropriate points in the discussion, as characterized in Figure C..
In general, the views support DCM procedural/process content for clinical decision support
(CDS) and supervisory and automatic control and data acquisition (SCADA), observation,
and reporting purposes. The main components/views identified in the figure include [but
are not limited to):
1. an information base/model and DCM-related views of control and observation
variables;
2. an ontology and related [set of] template[s] for specifying ventilator modal behavior;
3. a finite state model (FSM) characterizing selected breath delivery; and
4. and a [set of] model[s] depicting [co-]optimization of key variables related to
ventilation and oxygenation.
In the figure, the relational attributes at the top characterize a virtual “timeline” in which
significant “vectors” can be identified for detailed clinical modeling, initially through the
DCM4MD use case procedural/process diagram and subsequently through relevant views. It
is expected that the set will be highly reusable across DCM’s in this domain and may provide
or be provided information from other DCM’s (for example, ABG).
P a g e | 72
class Annex C: Ventilator Modes and Voumentric Delivery
Ventilator Modes
changing over time
Figure Annex C: Ventilator Modes and Volumetric Delivery
P a g e | 73
Glossary
Term Type Description
Activity and Technical An activity in Unified Modeling Language (UML) is a major task
Activity that must take place in order to fulfill an operation contract.
Diagram Activities can be represented in activity diagrams
An activity can represent:


 the invocation of an operation,
 a step in a business process, or
 an entire business process.
Activities can be decomposed into sub-activities, until at the
bottom where we find atomic actions.
Actor Technical An actor in the Unified Modeling Language (UML) "specifies a role
played by a user or any other system that interacts with the
subject."
"An Actor models a type of role played by an entity that interacts
with the subject (e.g., by exchanging signals and data), but
which is external to the subject."
Association Technical A relationship between two or more entities. Implies a connection
of some type - for example one entity uses the services of
another or one entity is connected to another over a network
link.
Balloting Business Multiple domains or infrastructure committees may be involved in
strategy a project. The project plan should include a plan for engagement
of impacted committees and a plan for advancing new or refined
content into processes/ballots that are already underway in those
committees.
BP Business Blood Pressure
Candidate Business Executing the Candidate Standard validation approach. HL7 will
Standard have a modified open approach to candidate standard validation.
validation All those participants that made a non-binding commitment in
step (5) will be included if they choose to honor the commitment.
Others may be added to achieve a balance or for other
necessities for validation. The previous notwithstanding, HL7 will
limit the number of participants to ensure a manageable process
and reasonable time frame.
Candidate Business A project step that ensures that the Candidate Standard is
Standard validated by external industry resources before it is finalized as a
validation normative standard. Where the standard is for interoperability, it
approach is expected that the validation will include at least two
independent entities (vendors, user organizations, etc.) building
trial implementations and testing them together. Where the
standard serves another purpose the validation approach will
involve a trial effort to use the draft standard in the manner for
which it was created. At the planning stage the entities willing to
test must make a non-binding declaration of their intent to
participate in validation. Without such a declaration the project
should not be initiated. Comment: This is expected to be a
significant hurdle for new project initiation. At the same time it
helps to assure that HL7 member resources will be concentrated
on efforts that have a good shot at industry adoption.
Class Technical A logical entity encapsulating data and behavior. A class is a

template for an object - the class is the design, the object the
runtime instance.
P a g e | 74
Conformance Technical A conformance statement is a claim that the behavior of an

Statement application or application module agrees with the constraints
stated in one or more profiles.
A Conformance Statement is documentation of the degree to
which a particular application conforms to the specification. Part
of that document will be a profile expressing the requirements
relevant to a particular standard. Standard Profiling is based
upon the consistent application of constraints to a set of base
specifications. This document outlines the processes that govern
the definition of profiles and conformance statements.
DAM Technical See Domain Analysis Model.
DCM Technical See "Detailed Clinical Model".
Detailed Clinical Technical A Detailed Clinical Model (DCM) is an information model of a
Model (DCM) discrete set of precise clinical knowledge which can be used in a
variety of contexts.
Detailed Clinical Models (DCM) are descriptions of items of clinical

information that include the clinical knowledge on the concept,
the data specification, a model and where possible, technical
implementation specifications. A DCM is a conceptual
specification of the semantics of discrete structured clinical
information. It provides the data elements and attributes,
including the possible values and types of the attributes, needed
to convey the clinical reality in a fashion that is understandable to
both clinical domain experts and modelers. This includes the
potential for use in health care information and communication
technology, for example in EHR, Telehealth applications,
messages, medical devices, computer algorithms, and deductive
reasoning, decision support, among others. It provides
unambiguous detail which is intended to be cross domain and
cross discipline and standardized and reusable over domains,
purposes, standards and implementations. DCM work currently
includes clinical content analysis, quality assurance, information
modeling, and repositories. DCM include the structural model.
Dynamic models are handled elsewhere, but some aspects of
dynamics might be in the DCM.
"Detailed Clinical Models are small items of clinical, preventive

and care information that are well defined and for which
knowledge, data definition, vocabulary binding, and information
model for use in information and communication technology are
standardized and reusable over domains, purposes, standards
and implementations." [ISO 13972 draft]
Domain Analysis Technical A Domain Analysis Model (DAM) is an abstract representation of a
Model subject area of interest designed to provide a generic
representation of a class of system or capability and to suggest a
set of approaches to implementation. In HL7 a DAM is complete
enough to enable the development of downstream platform-
independent models: HL7 RIM-based information and service
models. A DAM may also be used to constrain other standards for
use in healthcare (e.g. to constrain access control markup
standards). The process used to create a DAM is documented in
the HL7 Development Framework (HDF).
Framework (HDF).
EDD device Business Esophageal intubation detection device using a rubber bulb to
detect the that air may be introduced into the lungs using the
Endotracheal tube.
EHR-S Business Electronic Health Record System
EKG Business Electrocardiogram
P a g e | 75
Endotracheal Business Endotracheal means "inside the trachea/windpipe".

EtCO2 Business End tidal carbon dioxide, a partial pressure measured in exhaled
breath
ETT Business Endotracheal tube
Extends Technical A relationship between two use cases in which one use case
Relationship 'extends' the behavior of another. Typically this represents
optional behavior in a use case scenario - for example a user may
optionally request a list or report at some point in a performing a
business use case.
Extubation Business This term is used to describe the removal of a device from a
hollow organ.
FiO2 Business Fraction of inspired oxygen, a percentage of inhaled gas
HL7 Profile Technical An HL7 profile is an unambiguous specification of one or more
HL7 standards that have been analyzed for a particular use case.
It prescribes a set of precise constraints upon one or more
standard HL7 artifacts.
An HL7 profile is conformant, in all aspects, with the HL7 defined
specification used in the profile according to the constraints or
extension rules. It may specify constraints on the standard HL7
definition. An implementation profile fully describes an
interoperability interaction between two or more systems through
the combination of the following:
a) one use case analysis,
b) one or more dynamic definitions, and
c) one or more static definitions.
HL7 Project Technical A project is a work effort that has the following characteristics:
 has an objective (statement of what is going to be produced),
 will have a finite existence (the end date to be determined by
the resources available and the start date), and
 if additional funding is required, it will have a budget
(including resources and funding sources)
 will have at least one participant available to contribute and
must have a project leader, if only an interim to get the
project started
 will have at least two implementers (unless the project is
intended to support the HL7 infrastructure)
 will have an estimated schedule including deliverables and
milestones.
HL7 project Business HL7 projects shall:

criteria • Be consistent with Board strategic direction or, if a hosted
project, approved as an exception project
• Include appropriate project documentation - project charter,
scope, resources, timelines, assumptions, constraints, planned
deliverables, etc. per PMO methodology
• Be aligned with market demand
• Be sponsored by stakeholders intending to implement the
product produced by the project
• Define a reasonable balloting strategy to meet market
demand and implementation timelines
• Define how the project will engage with other impacted
committees
• Follow project approval protocols to ensure appropriate
project socialization and sign-off has taken place
HR Business Heart rate in beats per minute
I:E Business Inspiration-to-expiration ratio, a ratio of durations
P a g e | 76
Includes Technical A relationship between two use cases in which one use case
Relationship 'includes' the behavior. This is indicated where there a specific
business use cases which are used from many other places - for
example updating a train record may be part of many larger
business processes.
Industry Business Depending on the goals of the project this may be as little as a
outreach set of announcements of work going on in HL7 targeted at the
impacted stakeholder communities. For some projects it may
involve scheduling out-of-cycle meetings, scheduling meetings
jointly with other stakeholder organizations or some kind of
―Town Hall‖ meetings similar to those used for the EHR Functional
Requirements DSTU.
Intubation Business Introduction of a tube into a hollow organ to restore or maintain
patency if obstructed. It is differentiated from CATHETERIZATION
in that the insertion of a catheter is usually performed for the
introducing or withdrawing of fluids from the body.
Reference: MeSH
Intubation - Business Endotracheal intubation is a medical procedure in which a tube is
endotracheal placed into the windpipe (trachea), through the mouth or the
nose. In most emergency situations it is placed through the
mouth.
Endotracheal intubation is done to open the airway to give
oxygen, medication, or anesthesia, and to help with breathing. It
may also be done to remove blockages (foreign bodies) from the
airway or to allow the clinician to examine the upper airway.
ISO/IEEE Technical Within this standard nomenclature codes are defined, these give
11073-10101 the possibility to clearly identify objects and attributes in relation
Nomenclature to the so-called OID-Code). The nomenclature is divided in
partitions, to demarcate codes with regards to content and
functional.
Laryngoscope Business Device for viewing larynx & intubation; also called
'Fiberoptic' or 'Glide'.
LOINC Technical Logical Observation Identifiers Names and Codes (LOINC®)
LOINC: A data set of universal identifiers for laboratory and other
clinical observations to facilitate exchange and storage of clinical
results or vital signs for healthcare.
The purpose of LOINC® is to facilitate the exchange and pooling
of clinical results for clinical care, outcomes management, and
research by providing a set of universal codes and names to
identify laboratory and other clinical observations. The
Regenstrief Institute, Inc, an internationally renowned healthcare
and informatics research organization, maintains the LOINC
database and supporting documentation, and the RELMA mapping
program.
loinc.org
Medical Device Business Any instrument, apparatus, implement, machine, appliance,
implant, in vitro reagent or calibrator, software, material or other
similar or related article:
1) intended by the manufacturer to be used, alone or in
combination, for human beings for one or more of the specific
purpose(s) of:
 diagnosis, prevention, monitoring, treatment or alleviation of
disease,
 diagnosis, monitoring, treatment, alleviation of or
compensation for an injury,
 investigation, replacement, modification, or support of the
P a g e | 77
anatomy or of a physiological process,

 supporting or sustaining life,
 control of conception,
 disinfections of medical devices,
 providing information for medical or diagnostic purposes by
means of in vitro examination of specimens derived from the
human body;
and
2) which does not achieve its primary intended action in or on the
human body by pharmacological,
immunological or metabolic means, but which may be assisted in
its intended function by such means.‖
Reference: GHTF/SG1/N29R16:2005 published by the Global

Harmonization Task Force, (2005):
Message Profile Technical Definition: An HL7 message profile is an unambiguous
specification of one or more standard HL7 messages that have
been analyzed for a particular use case. Each message profile
may have a unique identifier as well as publish/subscribe topics.
NIF Business Negative inspiratory force, a measure of pulmonary mechanics

used to assess readiness to wean
Non-volunteer Business Beyond the routine support, HL7 headquarters provides for
resources balloting, etc., additional support may be required to assess
potential funding requirements. Hosted projects will be expected
to provide associated funding.
NTP Technical (Simple) Network Time Protocol - See SNTP.
PaCO2 Business Partial pressure of carbon dioxide in the blood. Critical in
regulating breathing levels and maintaining body pH.
PACU Business Post Anesthesia Care Unit
PaO2 Business Partial pressure of oxygen in the blood.
pH Business The acidity of a solution, approximately the negative log10 of the
molar concentration of hydronium ions.
Project Business The PMO is staffed by HL7 to provide support for committees
Management executing projects. The PMO is responsible for oversight of
Office (PMO) project methodology, and tracking the status of HL7 projects.
The PMO does not directly manage product related projects.
Protocol Technical Protocol specifications encompass the following work products
Specifications developed and supported by HL7: all Versions of the HL7
messaging standard; the Clinical Document Architecture (CDA);
Arden Syntax; CCOW specifications; Service Oriented
Architecture (SOA) standards; any other normative standards
subsequently released by HL7; various functional models,
implementation guides, and Implementation Technology
Specifications (ITS); the Reference Information Model (RIM); and
those informative documents initiated and balloted by the various
Work Groups.
Quality Criteria Business A project commitment to a measure of the quality for each step
of the project cycle. It is expected that most projects will use or
possibly adapt boiler-plate quality criteria developed as part of
HL7‘s methodology.
Quality Review Business An evaluation of whether the work products of a step meet the
pre-established quality criteria. At most steps the project team
will self-assess against these criteria and take a vote (not a
ballot) to move ahead to the next step.
Rosetta Technical The Rosetta Terminology Mapping (RTM) ) IHE PCD Profile is
P a g e | 78
Terminology focused on identifying a core set of semantics that are shared

Mapping between multiple devices within the same modality (e.g.,
physiological monitors, ventilators, infusion pumps, etc.) and
then mapping them to a standard terminology. The RTM mapping
effort will initially include numeric parameters and their
associated units of measurement and enumerated values.
http://wiki.ihe.net/index.php?title=PCD_Profile_Rosetta_Terminol
ogy_Mapping
References:
 ISO/IEEE 11073-10101 Health informatics — Point-of-care
medical device communication — Part 10101: Nomenclature,
First edition, 2004-12-15. ISO and IEEE, 2004.
 The ‗Unified Code for Units of Measure‘ (UCUM).
RR Business Respiration rate, in breaths per minute

RSBI Business Rapid shallow breathing index, as Vt/RR, used to assess
readiness to wean from ventilator
RTM Technical See "Rosetta Terminology Mapping".
SaO2 Business The saturation level of oxygen in hemoglobin, as measured by
samples obtained from arterial puncture.
Sequence Technical UML Sequence diagrams are a dynamic modeling technique, as
Diagram are collaboration diagrams and activity diagrams. UML sequence
diagrams are typically used to:
1. Validate and flesh out the logic of a usage scenario. A usage
scenario is exactly what its name indicates – the description of a
potential way that your system is used. The logic of a usage
scenario may be part of a use case, perhaps an alternate course;
one entire pass through a use case, such as the logic described
by the basic course of action or a portion of the basic course of
action plus one or more alternate scenarios; or a pass through
the logic contained in several use cases, for example a student
enrolls in the university then immediately enrolls in three
seminars.
2. Explore your design because they provide a way for you to
visually step through invocation of the operations defined by your
classes.
3. To detect bottlenecks within an object-oriented design. By
looking at what messages are being sent to an object, and by
looking at roughly how long it takes to run the invoked method,
you quickly get an understanding of where you need to change
your design to distribute the load within your system. In fact
some CASE tools even enable you to simulate this aspect of your
software.
4. Give you a feel for which classes in your application are
going to be complex, which in turn is an indication that you may
need to draw state chart diagrams for those classes
Service Technical System interfaces are also known as "application roles" or
Interface "service interfaces".
SME Business Subject Matter Expert or Domain Expert: a person with domain
knowledge that represent the users of IT systems and their
business needs.
SNTP Technical Simple Network Transport Protocol
References to SNTP client implementations:
P a g e | 79
Java
 Apache (open-source)
 NTP client connect to the NTP server using a standard-based
protocol - SNTP
 UDP implementation of a client for the Network Time Protocol
(NTP) described in RFC 1305 as well as the Simple Network
Time Protocol (SNTP) in RFC-2030.
 http://www.docjar.com/docs/api/org/apache/commons/net/n
tp/package-index.html
 Network Time Protocol (NTP) timestamp as defined in RFC-
1305 and SNTP (RFC-2030).
.NET
 http://www.codeproject.com/KB/datetime/SNTPClient.aspx
SpO2 Business The saturation level of oxygen in hemoglobin; can be determined
by noninvasive method of pulse oximetry.
Stakeholder Business A person or a company that requests a new standard, a technical
correction to an existing standard, or an enhancement.
Substantive Technical A change that requires ballot. The Architectural Review Board
Change (ARB) provides criteria to determine whether or not a change is
substantive.
HL7 Definition of Substantive
The ARB considers that a change to the standard is substantive if
it would cause an interface sender or receiver to have its
interface fail when a newly specified message was received or
attempted to be sent. This is similar to, but more expansive than,
the definition of backwards compatibility. In general, for
backwards compatibility, a message receiver is expected to
receive a new message and be able to ignore added material. On
the other hand, if there is new material that needs to be parsed
in order to process the message given its new definition, the
change is substantial. On the other hand, if a change would
create a backwards compatibility problem (as defined in Chapter
2), it is substantive by definition.
Substantive Technical According to the American National Standards Institute (ANSI) a
Change (re:HL7 substantive change is one that directly and materially affects the
Ballot) use of the standard. The ANSI definition includes changes that
would break solutions that were implemented using the
specification as it existed before the change. It is important to
note that, as an ANSI Standards Development Organization
(SDO), HL7 SHALL be guided by the ANSI definition. Another way
to express this concept is to note that substantive changes are
those which modify the standard by adding or removing
capabilities. In addition any change that changes the meaning of
the message – whether by adding, subtracting or modifying
content - is a substantive change. A change that materially
affects the content of exchanged messages is substantive. For
example, the addition of a new Trigger Event is substantive;
adding attributes to an existing Message Type is Substantive. On
the other hand, the correction of a typographical error, or the
addition of an example message is not substantive.
When the ARB considers the matter of substantiveness, it
generally uses the following test: a proposed change to the
standard is treated as substantive if an interface would fail when
a message is built, sent or received. This approach is similar to,
but more expansive than, the definition of backwards
P a g e | 80
compatibility However, a change that creates a backwards

compatibility problem is substantive by definition.
Timeline Business A GANNT chart or other project diagram that expresses the
estimated times required to complete the steps of the project,
synchronized with the dates of HL7 trimester meetings.
UCUM Technical The Unified Code for Units of Measure is a code system intended
to include all units of measures being contemporarily used in
international science.
www.unitsofmeasure.org/
UML Business Unified Modeling Language (UML) is a standardized general-
purpose modeling language in the field of software engineering.
The standard is managed, and was created by, the Object
Management Group.
UML includes a set of graphic notation techniques to create visual

models of software-intensive systems.
Use Case Technical A Use Case represents a discrete unit of interaction between a
user (human or machine) and the system. A Use Case is a single
unit of meaningful work; for example creating a train, modifying
a train and creating orders are all Use Cases.
Each Use Case has a description which describes the functionality
that will be built in the proposed system. A Use Case may
'include' another Use Case's functionality or 'extend' another Use
Case with its own behavior.
Use Cases are typically related to 'actors'. An actor is a human or
machine entity that interacts with the system to perform
meaningful work.
Ventilator Business Techniques for effecting the transition of the respiratory-failure
Weaning patient from mechanical ventilation to spontaneous ventilation,
while meeting the criteria that tidal volume be above a given
threshold (greater than 5 ml/kg), respiratory frequency be below
a given count (less than 30 breaths/min), and oxygen partial
pressure be above a given threshold (Oxygen Pressure - PaO2
greater than 50 mm Hg).
Weaning studies focus on finding methods to monitor and predict
the outcome of mechanical ventilator weaning as well as finding
ventilator support techniques which will facilitate successful
weaning. Present methods include intermittent mandatory
ventilation, intermittent positive pressure ventilation, and
mandatory minute volume ventilation.
Nursing Interventions
Reference: MeSH/A0132038
Classification/A10934189 Assisting the patient to breathe
without the aid of a mechanical ventilator
Vt Business Tidal volume; the volume of air inhaled and exhaled in mL
WNL Business Within normal limits

Modelling-Medical Device

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelling-Medical Device

Uploaded by

Copyright:

Available Formats

V3DAM_DCM4MEDDEV_R1_I1_2011MAY

Detailed Clinical Model for Medical Devices

Second Ballot: May 2011

© 2011 Health Level Seven, Inc.

Detailed Clinical Model (DCM) for Medical Devices

John G. Rhoads, Philips Medical Systems

Todd Cooper, Breakthrough Solutions Foundry, Inc.(IEEE)

Melvin Reynolds, AMS Consulting

William Goosen, Patient Care Work Group Co-chair

Contributors/Subject Matter Experts:

Catherine Hoang, US Department of Veterans Affairs,

Donna DuLong, TCoombs & Associates/US Department of Veterans Affairs

Luigi Sison, TCoombs & Associates /US Department of Veterans Affairs,

Modeling, Publishing Facilitator:

May 2011 - Informative

1. Post-Operative Patient Transport (from PACU to ICU)

September 2010 - Draft for Comment

Introduction and Objectives

An DAM is intended to improve communication of interoperability requirements and

Figure A: Approach and Ballot Content

Clinical Scenario(s) (Artifact)

1. Business/Clinical Use Case (UseCase)

2. Clinical Workflow (StructuredActivityNode)

3. Analysis Information Model

4. Detailed Clinical Models

1. Business/Clinical Use Cases

uc 1: Business/Clinical Use Case Actors

Figure 1: Business/Clinical Use Case Actors

directly or in other, related healthcare delivery processes :

1.1 Intubate Patient

uc 1.1: Intubate Patient - Overview Diagram

(from 2.1 Intubate Patient Workflow)

Patient Synchronize Time

(from 1.5.1 Patient to Device Association)

Figure 1.1: Intubate Patient - Overview Diagram

Intubate Patient (UseCase)

SYSTEMS AND DEVICES

 Electronic Health Record (local, partial, or comprehensive)

Order or protocol for intubation

1.2 Manage Patient on Ventilator

uc 1.2: Manage Patient on Ventilator

Manage Patient on Manage Patient on Ventilator

(from 2.2 Manage Patient On Ventilator Workflow)

Associate Device with a

(from 1.5.2 Time Synchronization)

Figure 1.2: Manage Patient on Ventilator

Manage Patient on Ventilator (UseCase)

 SYSTEMS AND DEVICES

1.3 Liberate Patient from Ventilator

uc 1.3: Liberate Patient from Ventilator

Liberate Patient from

Associate Device with a

Figure 1.3: Liberate Patient from Ventilator

Liberate Patient from Ventilator (UseCase)

SYSTEMS AND DEVICES

 Intubated patient on ventilator

If the use case was completed, then

1.4 Transport Post-Operative Patient

uc 1.4: Patient Transport

(from 1.5.1 Patient to Device Association)

(from 1.5.2 Time Synchronization)

Figure 1.4: Patient Transport

Transport Post-Operative Patient (UseCase)