IHE Work Item Proposal (Detailed)

pigsabusiveElectronics - Devices

Nov 29, 2013 (3 years and 8 months ago)

122 views

July 18, 2011

pigsabusive_438f28b4
-
8651
-
45b4
-
ae17
-
d1654662ec75.docx

Page
1

of
8


IHE Work Item Proposal (Detailed)

1.

Proposed Work Item:
Patient Encounter Tracking Query
<
PEQ
>

Proposal Editor:
Yutaka ANDO


(
ando_y@nirs.go.jp
)

Work item Editor:
Masayoshi SEKI

(
seki@global
-
for.com
)
,
Yuichiro
OTAKE

(
yuichiro.otake@carestream.com
)
,
Masami
MUKAI
(
m_mukai@nirs.go.jp
)

Date:
26/Oct/2011

Version:
1.0

Domain:
IT Infrastructure

2.

Summary

The Patient Encounter Tracking Query (PEQ) Integration Profile is the integration
profile in
order to find the location of patient only in a hospital, not for cross
-
referencing between
multiple hospitals.

It is difficult to monitor the location of patient and there is no standard way to find the
location of patient immediately when need
ed.

HL7 ADT message can contain not only patient’s basic demographic information but also
location of patient. Medical staffs can query and retrieve the location of patient by using HL7
message.

The Patient Encounter Tracking Query (PEQ) Integration Profil
e will manage the location of
patients and provide the real time location information to the other subsystems.

Japanese EMR vendors, radiology system vendors and RFID vendors are
much
interested in
the PEQ profile and they are willing to participate in pro
file development.

In order to collect the location of patients, multiple systems must provide the location of
patients into central location management
system
,

b
ecause

IHE integration profile can
standardize the transaction and workflow.


3.

The Problem

It is

common especially for aging patients to get consultation at multiple departments in a day.
To find the location of patients quickly is very important for productivity and use of resources
(medical staffs/devices/systems/…) in a hospital.

The Patient Encou
nter Tracking Query (PEQ) Integration Profile
has

the ability

to

track

the
whereabouts

of patients

in hospitals
.

July 18, 2011

pigsabusive_438f28b4
-
8651
-
45b4
-
ae17
-
d1654662ec75.docx

Page
2

of
8


Upon checking in at hospital reception patients are to proceed to indicated area such as
outpatient clinic, laboratory, radiological diagnosis and radiotherapy treatment room. It
sometimes happens that patient does not show up at the appointment time. By

knowing
patients whereabouts, staffs are able to utilize the resource more efficiently.

For example, when medical staffs need to search the patients, the workflow will stop at that
time for 5
-
10min, then the cost of time for medical clerks, nurses, physi
cians and the other
staffs will be increasing.

4.

Use Cases

<UseCase
-
1>

Fig. 1 shows the Use Case
-
1.
Patient
-
Tanaka
is

schedule
d

CT scan at 10:00 am. But
Patient
-
Tanaka
does
not arrive at the reception of radiology department, so medical staff cannot start
CT scan. To check patient location information, Staff of the radiology department uses the PEQ
Consumer
.

T
he information

shows

that
Patient
-
Tanaka was accepted last place outpatient
department and he does not leave yet. Staff of the radiology department

sk
ips

Patient
-
Tanaka
and
start
s

CT scan of
P
atient
-
Suzuki who has
already
been
accepted the radiology reception.




July 18, 2011

pigsabusive_438f28b4
-
8651
-
45b4
-
ae17
-
d1654662ec75.docx

Page
3

of
8


<UseCase
-
2>

Patient
-
Sato
:

scheduled to visit
internal medicine

department at 10:00 and
ophthalmology

department at 10:30.

Patient
-
Suzuki
: scheduled to visit
ophthalmology

department at 11:00.



PEQ

using RFID
(Fig. 2)

RFID
monitoring

devices

are to locate at both the lobb
ies

and the
consultation

room
s
.
P
atients always

carry the RFID
-
tag in this hospital
.


At 10:
30
, the doctor in the
ophthalmology

department checks
the location of Patient
-
Sato

with PEQ

integration prof
ile
. The doctor quickly find
s

that the
Patient
-
Sato

is
still in
the
internal medicine

department

and skips Patient
-
Sato.
T
he doctor
finds the next patient
who is waiting at the lobby and
calls
Patient
-
Suzuki for next patient
.

Patient
-
Suzuki needs not wait
for a consultation. Before introducing PEQ
,
the

ophthalmology
physician has to
stop

consultation

and m
ay
los
e

some time

to wait

Patient
-
Sato
.
Patient
-
Sato has to wait at the ophthalmology department
for a long time
.



July 18, 2011

pigsabusive_438f28b4
-
8651
-
45b4
-
ae17
-
d1654662ec75.docx

Page
4

of
8


5.

Standards & Systems

<Systems>

The
Patient Encounter Tracking Query (PEQ) Integration Profile

has three actors;
a)

Patient
Encounter Source, b)

Patient Encounter Manager , c) Patient Encounter Consumer.


Patient Encounter Supplier will be implemented with actors listed below.

Seq.

System

Integration profile

Actor

1

Patient Admission/Management system

PIR

PAM

ADT

Patient
Demographics
Supplier

2

EMR

(Electronic Medical Record)

SWF

LTW

ESI*1

OP

OP

OP

3

RIS

(Radiology Information System)

SWF

PAM

OF

Patient
Demographics
Consumer

4

LIS

(Laboratory Information System)

LTW

PAM


OF

Patient
Demographics
Consumer

5

OIS(Radiation Oncology Information system)

ESI
*1

TMS

*1) ESI

(Enterprise Schedule Integration) Integration Profile
is published by
Radiation
Oncology
Domain.


<Standards>

HL7
Message Standard Version 2.5

or later

ADT/ACK
-

Patient Departing
-

Tracking (EVENT A09)

ADT/ACK
-

Patient Arriving
-

Tracking (EVENT A10)

QBP/RSP


Query by Parameter/Segment Pattern Response (EVENTS VARY)



July 18, 2011

pigsabusive_438f28b4
-
8651
-
45b4
-
ae17
-
d1654662ec75.docx

Page
5

of
8

6.

Technical Approach













Figure
3
: Patient Encounter
Query actors and transactions


Patient Encounter Manager actor must know
p
atient
demographic information

in advance of

receiv
ing

the patient tracking information from Patient Encounter Supplier.

Therefore, Patient
Encounter Manager actor must store
p
atient
demographic information

which
f
ed

by Patient
Identity Management
[ITI
-
30]
from Patient Demographics Supplier.


Patient Encounter
Source

uses Patient Encounter Feed [PEQ
-
x01] to notify patient location
information to Patient Encounter Manager.


Patie
nt Encounter Feed is resemblance to Patient Encount
er Management
in
PAM

integration

profile,

but must be created as a new transaction by following reasons:



Temporary Patient Transfer Tracking Option
of
PAM

is optional, but it must be
mandatory in
PEQ integ
ration

Profile.



Temporary Patient Transfer Tracking Option
of
PAM

has been using A01, A03, A04,
A08, A09, A10 and A40, but Patient Encounter Query Profile would be using only
A09 and A10.


Patient Encounter Consumer uses Patient Encounter Query [PEQ
-
x02] t
o inquire patient location
information to Patient Encounter Manager. Patient Encounter Manager replies patient location
information and receive
s

notification time from Patient Encounter Supplier as the response
message.


Patient Encounter
Source

Patient Encounter
Manager

Patient
Encounter
Consumer

Patient Encounter Feed
[PEQ
-
x01]

Patient Encounter
Query [PEQ
-
x02]

Patient Demographics
Supplier

Patient Identity
Management [ITI
-
030]

July 18, 2011

pigsabusive_438f28b4
-
8651
-
45b4
-
ae17
-
d1654662ec75.docx

Page
6

of
8

New actors

Possible new actors are:



Patient Encounter Supplier



Patient Encounter Manager



Patient Encounter Consumer

Patie
nt Encounter Manager must know
p
atient
demographic

i
nformation. Therefore, Patient
Encounter Manager
has to be grouped with
Patient Demographics Consumer actor (PAM).


Existing actors

The profile may use the flowing existing actors:



Patient Demographics Supplier (PAM)



Patient Demographics Consumer (PAM)


New transactions (standards used)

PEQ

integration
profile includes:



Patient Encounter Feed



Patient Encounter Query


Existing

transactions

No e
xisting transactions are modified,

and

PEQ integration

profile use
s

the following transaction:



Patient Identity Management [ITI
-
30]


Impact on existing integration profiles

No changes are expected to existing profiles.


New
integration profiles needed

Besides the
PEQ integration

profile proposed here no new integration profiles are expected.


Breakdown of tasks that need to be accomplished

1. Scope of profile
(½p)

2. Actors and transactions
(
2
p) See e.g. Figure
3
.

3.
Options
(½p)

4. Process Flows
(1p)

5.
Patient Encounter
Feed Message
(
10
p)

July 18, 2011

pigsabusive_438f28b4
-
8651
-
45b4
-
ae17
-
d1654662ec75.docx

Page
7

of
8


5.1 Scope


5.2 Use case Roles


5.3 Referenced Standard


5.4 Message sets and options


5.5 Common HL7 Message Segments


5.6 Interactions

6
. Patient Encounter
Query Message

(
14
p)


6.1 Scope


6.2 Use case Roles


6.3 Referenced Standard


6.4 Message sets and options



6.4.1 Patient Encounter Query Request Message



6.4.2 Patient Encounter Query Response Message


6.5 Common HL7 Message Segments

6.5.1 Patient Encounter Query Reque
st Message

6.5.2 Patient Encounter Query Response Message


6.6 Interactions


7.

Risks

This task is regarded low risk as the technology is well understood and good candidate standards are
available.


8.

Open Issues

8.1 Incomplete

location information
:

We believe

that some as
sumptions are necessary for P
EQ
actor
s
. There must be some methods
to compensate and/or supplement the location between two encounters.

When PEQ consumer actor inquires PEQ manager, PEQ manager replies the last encounter
information. If this i
nformation indicates departing from location
-
A, the PEQ consumer could not
find the patient location. Some assumption is inevitable for PEQ consumer actor at receiving
incomplete information.


8.
2 Target systems to be implemented
:

When existing system supports PEQ actors, we must consider which system needs t
o be
corresponded to PEQ actors
.

July 18, 2011

pigsabusive_438f28b4
-
8651
-
45b4
-
ae17
-
d1654662ec75.docx

Page
8

of
8


To solve above open issues, we are thinking that the trial
implementation is very important.


9.

Effort Estimates

Number of pages =
25
-
30

pages

Complexity of issues = low

Overall estimate = low