Whitepaper IHE PCD MEM Device Management and Configuration

flutheronioneyedSoftware and s/w Development

Dec 13, 2013 (3 years and 3 months ago)

225 views

IHE PCD Whitepaper


Device Management and Configuration

Version 1.0


22⁊ 氠2013

1

of
7

ꤠ2013⁉ 䔠䥮瑥牮慴aon慬


Whitepaper

Device Management and Configuration

(
DMC
)

Organization


Integrating the Healthcare Enterprise (IHE)

Domain


Patient Care Devices (PCD)

Working Group


Medical Equipment Management (MEM)

Project


Device Management and Configuration

(
DMC
)

Lead



Monroe Pattillo (IHE PCD PC co
-
chair)


Practical Health Interoperability, LLC

Date


26

Jul 2013

Purpose

The purpose
of the Working Group

activity
wa
s to identify a means of communicating the
detailed
identification of the device (manufacturer, model,
serial number, H/W version, and S/W version), power
status (on mains or on battery), and battery detailed identification (manufacturer, model, serial number,
H/W version, and S/W version), battery status (charging, available capacity or duration) and the
c
onditions under which it is sent in an unsolicited manner (startup, upon destination actor
configuration, upon self
-
test pass or fail, or upon error when in operation or association with a patient)
.

Goals

The primary goal is communication of the
detailed
identification

of
an

object in an HL7 v2.6 message.
An object can be equipment
,
implemented in a mix of hardware and software or purely in software
.

Non
-
Goals

Creating a normative standard for communication of
detailed identification

information is not a goal

of
the

effort.

Use Cases

The following are the defined use cases for the working group effort.

The means of communicating
identification, s
tatus, and error observations is

the
same
data set
across the listed use cases.



Use Case
#1


Device initialization

(when the equipment or software is powered up, starts, or is
reset)



Use Case #2


Device actor destination configuration



Use Case #3



Upon completion of self
-
test

whether the result is pass or fail whether the test is
self
-
initi
ated or manually initiated



Use Case #4


Upon detected equipment
or battery
error condition

Scope

F
or the

IHE development
cycle the scope
is
narrowed to achieve an initial end result of
pre
-
qualification
testing over the Internet either virtually using interactive systems or through the exchange of message
IHE PCD Whitepaper


Device Management and Configuration

Version 1.0


22⁊ 氠2013

2

of
7

ꤠ2013⁉ 䔠䥮瑥牮慴aon慬


瑥硴s⁷楴i⁴h攠
慮瑩捩t慴ad end

牥獵r琠b敩eg⁡
n⁉ N⁐CM

New Directions demonstration at HIMSS’14
within the HIMSS IHE North America Int
eroperability Showcase.

Not in Scope

This effort knowingly does not handle management of other than basic configuration, such as medical
device profiles and modes.

Constraints

Compromises are
required to achieve
a
New Directions demo
nstration

in a limited
time frame, without
the
development of new IHE profiles or actors, and with limited modification of existing equipment
hardware and software implementation
. Avoid the

constrained

implementation
as
b
eing identified as
normative

(industry standards approved
)
.


Deliverables

The following are the deliverables of this effort.



This
whitepaper on
project definition and
use of PCD messaging

to communicate
the
information



Sample

HL7 v2.6
message content

capable of being used as
these

observation
s

in PCD
profile messages

Definitions

These are
only the definitions
outside the normal IHE and IHE PCD set of definitions

CMMS



Computerized Maintenance Management System

MIC



Management Information Consumer actor

MIO



Management Information Observatio
n transaction

MIR



Management Information Reporter

actor

References

None.

IHE Profiles

The existing listed IHE PCD profiles

were utilized.



Device to Enterprise Communication (
DEC
)



Alert Communication Management (
ACM
)



Point of care Infusion Verification
(PIV)



Infusion Pump Event Communication (
IPEC
)

IHE PCD Whitepaper


Device Management and Configuration

Version 1.0


22⁊ 氠2013

3

of
7

ꤠ2013⁉ 䔠䥮瑥牮慴aon慬


IHE Profile Actors

The existing listed
IHE PCD profile

actors

were utilized.



Device Observation Reporter (
DOR
)



Device Observation Consumer (
DOC
)



Alert Reporter (
AR
)



Alert Manager (
AM
)



Alert Communicator (
AC
)



Infusion Order Programmer (IOP)



Infusion Order Consumer (IOC)

The following new actors were identified for
use in this document and for
possible inclusion in a future
profile. They were defined for cross IHE Profile use
in this document
without identifyin
g all possible PCD
actors at each reference to the function of the actor.

The name
s

and acronym
s

have not been validated
for IHE
-
wide uniqueness.



Management Information

Reporter (
MIR
)
refers to IHE actors
DOR, AR,
and
IOC



Management Information

Consumer (
MIC
)
refers to IHE actors
DOC, AM,
and
IOP

IHE PCD Transactions

The existing listed
IHE PCD
transactions were utilized.



PCD
-
01


Device Observation (
MI
R to
MI
C
)



PCD
-
03


Infusion Order (
MI
R to
MI
C
)



PCD
-
04


Report Alert (
MI
R to
MI
C
)



PCD
-
10


Infusion Event

(
MI
R to
MI
C
)

The following new transaction
s were

identified for
use in this document and for
possible inclusion in a
future profile. It was defined for cross IHE Profile use in this document without identifying all possible
PCD transactions at each refer
ence to the function of the actor. The name and acronym have not been
validated for IHE
-
wide uniqueness.



Management Information
Observation (
MI
O) (
MI
R to
MI
C)

Security

Given that th
is makes use of

existing PCD profiles, connectivity authentication and d
ata transfer security
are as per
the
PCD
Technical Framework (
TF
)
understanding

between the IHE ITI and the IHE PCD
domains
.

Where practicable this effort makes use of
IEEE
11073 prior efforts.

IHE PCD Whitepaper


Device Management and Configuration

Version 1.0


22⁊ 氠2013

4

of
7

ꤠ2013⁉ 䔠䥮瑥牮慴aon慬


What we have

E
xisting messaging to which we can add
configuration and status
related information

for the device, its
power status, its battery identification, battery status, and test status.

What we need

We need a

means of communication of
the identification and status information
in a
manner

common
to all

PCD messaging (OBX
and other segment
field and format for
all the information
).

Equipment
and Battery Sub
-
Component Reporting Cardinality

A single communication of an
equipment identification or status
observation may include the
information for multiple
sub
-
components or batteries within a single piece of equipment.

Reporting Message Content for Observation of Equipment
Identification

It is assumed that a

single

IEEE 11073 DIM MDS object is the source for communication of the
observation information and

t
hat it can be traced back to one unique

serial number identification.


Therefore i
n
a single report
of equipment
information

there is at most one reported
piece of equipment

per message.



Protocol



HL7 version 2.6


Definitions and requirements



Definit
ion and requirements indications for common HL7 message fields
and components are documented in the HL7 standard, the shared IHE PCD Technical Framework, or a
specifically utilized IHE PCD Profile are not listed here. What are listed here are the fields a
nd
components specific to
equipment and status reporting
.


Segment



OBX


The HL7 Observation segment shall be the segment used to report the
identification and status of
a
piece of equipment (a device). There shall be at most one
piece of equipment
obser
vation per piece of
equipment for which the
identification or status

observation is being reported. As there can be multiple
observations (OBR collections of OBX segments) per HL7 message there can be multiple
equipment
identification and status

reports p
er message, but they must be under individual OBR groupings.

Table
1

-

HL7 OBX
Segment Attribute Table
for Equipment
Identification or Status

Observation

SEQ

LEN

DT

OPT

RP/#

TBL#

ITEM#

ELEMENT NAME

2

2

ID

C


0125

00570

Value Type

3

250

CWE

R



00571

Observation Identifier

4

20

ST

RE



00572

Observation Sub
-
ID

5

99999

V
aries

C

Y/2


00573

Observation Value

11

1

ID

R


0085

00579

Observation Result Status

14

26

TS

CE




Observation Date/Time

18

22

EI

CE

Y


01479

Equipment Instance

Identifier

IHE PCD Whitepaper


Device Management and Configuration

Version 1.0


22⁊ 氠2013

5

of
7

ꤠ2013⁉ 䔠䥮瑥牮慴aon慬



OBX
-
2 Value Type



Table
2

-

H
L7
Sub
-
Component Table
-

EI
-

Entity Identifier

SEQ

LEN

DT

OPT

TBL#

SUB
COMPONENT

NAME

1

199

ST

CWE


Entity Identifier

2

20

IS

CWE

0363

Namespace ID

3

199

ST

CWE


Universal
ID

4

6

ID

CWE

0301

Universal ID Type


xxx
x


Sub
-
component 1 Entity Identifier

(ST)

xxxx

Sub
-
component 2

Namespace ID

(IS)

xxxx

Sub
-
component 3 Universal ID

(ST)

This sub
-
component c
o
ntains
a world unique value that identifies the
producer

of the
N
am
espace ID

value
.

In the world of IHE PCD this would be the EUI
-
64 value that identifies the
equipment or software
vendor
.

For more information on world unique identification by EUI
-
64 value please see the IHE PCD Technical
Framework.

Su
b
-
component 4 Universal ID Type

(ID)

This sub
-
component contains the
type of the value in s
ub
-
component 3
Universal ID
.

At this time t
he
use of EUI
-
64 cataloged values is
strongly recommended

by th
e IHE PCD Technical Framework and so
the value of this sub
-
component would be
EUI
-
64
.

OBX
-
3 Observation Identifier

(CWE)

This field contains the MDC code identifying the
identification or status

observation as
for a piece of
equipment
.


The syntax template is


<MDC code>,<MDC string>,MDC

IHE PCD Whitepaper


Device Management and Configuration

Version 1.0


22⁊ 氠2013

6

of
7

ꤠ2013⁉ 䔠䥮瑥牮慴aon慬


周攠晩敬f v慬a攠fo爠
塘塘

ob獥牶a瑩tn⁦o爠r⁰楥捥f⁥qu楰m敮琠楳


0,MDC_ATTR_
XXXX
_
XXXX
_
XXXX
,MDC


OBX
-
4 Observation Sub
-
ID

(ST)

The content of this field is as per the IHE PCD Technical Framework and is typically referred to as the
containment hierarchy dot notation.

It is used t
o identify the hierarchical source of an observation
value within a medical device system.

OBX
-
5 Observation Value

(PL)

Th
is field contains the value of the observed
equipment identification or status
.


Syntax
Template
and
Value
Examples

OBX
-
5 Value for

xxxx observations
.


Syntax

<
xxxx
>,<
xxxx
>,<
xxxx
>


Example



xxxx,xxxx,xxxx

OBX
-
11 Observation Result Status

(ID)

T
he conveyed observation
value
is not subject to
later
review or correction
. If the value changes it
is

conveyed through additional observation reports. T
he value of this field is
therefore
always indicated as
Final
using an ID of
F
.

OBX
-
14 Observation Date/Time

(DTM)

The field contains the date and time stamp
in 24
-
hour clock notation
as of the
time of th
e
hardware or
software

capture of the
equipment or status

information for conveying as a report.

The field syntax template for the data type is

YYYY[MM[DD[HH[M
M[SS[.S[S[S[S]]]]]]]]][+/
-
ZZZZ]

A value example for
12/31/2013 at 10:15:27 PM GMT would be


20131231221527
-
0000

For more information on the HL7 DTM Date/Time data format see HL7 2.6 2.A.22 DTM


date/time.

IHE PCD Whitepaper


Device Management and Configuration

Version 1.0


22⁊ 氠2013

7

of
7

ꤠ2013⁉ 䔠䥮瑥牮慴aon慬


OBX
-
18 Equipment Instance Identifier

(EI)

The value of this field identifies the equipment for which the
identification or status is being rep
orted.

HL7 Message Examples

MSH

PID

PV1

OBR

OBX

OBX


Futures

In the future it is possible to develop
profile(s) for request/response interactions (including poss
ible new
actors) and
adding data for NIST verification (RTMMS, MDC/11073, HL7, etc.).

Futur
e efforts are left to evaluate the use of standards other than EUI
-
64 for identification of
equipment.