JSTRO
Integrating the Healthcare Enterprise

IHE-Japan Radiation Oncology
Technical Framework
Volume 2 - Transactions
Supplement Proposal for Enterprise
Schedule Integration

Draft
May 12, 2009

削除: March 12, 2009
削除: March 2, 2009February 27,
2009

Copyright © 2008-2009: JSTRO/ASTROIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Contents1

Preface to Volume 2.................................................................................................................4
1.1 Intended Audience ............................................................................................................ 4
1.2 How this Document is Organized ..................................................................................... 4
1.3 Conventions Used in this Volume .................................................................................... 4
1.3.1
The Generic IHE Transaction Model .......................................................................4
1.4 Copyright Permissions ...................................................................................................... 6
1.5 Comments ......................................................................................................................... 6
2 Introduction ..............................................................................................................................7
2.1 Relationship to Standards ................................................................................................. 7
2.2 Relationship to Product Implementations......................................................................... 8
2.3 Relation of this Volume to the Technical Framework...................................................... 8
2.4 HL7 Profiling Conventions............................................................................................... 9
2.5 HL7 Implementation Notes............................................................................................. 10
2.5.1
Network Guidelines................................................................................................10
2.5.2
Message Control.....................................................................................................10
2.5.3
Acknowledgement modes ......................................................................................11
2.5.4
HL7 Versioning......................................................................................................12
2.5.5
Use of Coded Entities and Coding Schemes ..........................................................13
3 IHE Transactions....................................................................................................................14
3.1 Patient registration .......................................................................................................... 14
3.1.1
Scope ......................................................................................................................14
3.1.2
Use Case Roles.......................................................................................................14
3.1.3
Referenced Standards.............................................................................................15
3.1.4
Interaction Diagram................................................................................................15
3.1.4.1 Admit/Register Patient .......................................................................................15
3.1.4.2 Cancel Admit/Register Patient ...........................................................................19
3.2 RO-ESI-01: Create Radiotherapy Parent Order.............................................................. 19
3.2.1
Scope ......................................................................................................................19
3.2.2
Use Case Roles.......................................................................................................20
3.2.3
Referenced Standards.............................................................................................20
3.2.4
Interaction Diagram................................................................................................20
3.2.4.1 Create Radiotherapy Parent Order .....................................................................21
3.3 RO-ESI-02: Create Radiotherapy Delivery Child Order ................................................ 29
3.3.1
Scope ......................................................................................................................29
3.3.2
Use Case Roles.......................................................................................................29
3.3.3
Referenced Standards.............................................................................................29
3.3.4
Interaction Diagram................................................................................................29
3.3.4.1 Create Radiotherapy Delivery Child Order........................................................30
3.4 RO-ESI-03: Modify Radiotherapy Child Order ............................................................. 35
3.4.1
Scope ......................................................................................................................35
3.4.2
Use Case Roles.......................................................................................................35

DRAFT___________________________________________________________________
2
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,

削除: 14
削除: 14
削除: 18
削除: 19
削除: 19
削除: 19
削除: 20
削除: 28
削除: 28
削除: 28
削除: 28
削除: 28
削除: 28
削除: 34
削除: 34
削除: 34
削除: 04/9/2009
削除: 03/12/2009

削除: 34

IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

削除: 34
削除: 34
削除: 40
削除: 403.4.3
Referenced Standards.............................................................................................35
3.4.4Interaction Diagram................................................................................................36
3.4.4.1 Modify Radiotherapy Child Order .....................................................................36
3.5 RO-ESI-04: Cancel Radiotherapy Child Order .............................................................. 41
3.5.1
Scope ......................................................................................................................41
3.5.2
Use Case Roles.......................................................................................................41
3.5.3
Referenced Standards.............................................................................................41
3.5.4
Interaction Diagram................................................................................................41
3.5.4.1 Cancel Radiotherapy Child Order ......................................................................42
3.6 RO-ESI-05: Update Radiotherapy Child Order Status ................................................... 46
3.6.1
Scope ......................................................................................................................46
3.6.2
Use Case Roles.......................................................................................................46
3.6.3
Referenced Standards.............................................................................................46
3.6.4
Interaction Diagram................................................................................................47
3.6.4.1 Update Radiotherapy Child Order Status...........................................................47
3.7 RO-ESI-06 Update Radiotherapy Parent Order Status................................................... 52
3.7.1
Scope ......................................................................................................................52
3.7.2
Use Case Roles.......................................................................................................52
3.7.3
Referenced Standards.............................................................................................52
3.7.4
Interaction Diagram................................................................................................53
3.7.4.1 Update Radiotherapy Parent Order Status .........................................................53
3.8 RO-ESI-07: Cancel Radiotherapy Parent Order ............................................................. 58
3.8.1
Scope ......................................................................................................................58
3.8.2
Use Case Roles.......................................................................................................58
3.8.3
Referenced Standards.............................................................................................58
3.8.4
Interaction Diagram................................................................................................58
3.8.4.1 Cancel Radiotherapy Parent Order.....................................................................59
3.9 RO-ESI-08: Unsolicited Create Radiotherapy Parent Order .......................................... 63
3.9.1
Scope ......................................................................................................................63
3.9.2
Use Case Roles.......................................................................................................63
3.9.3
Referenced Standards.............................................................................................63
3.9.4
Interaction Diagram................................................................................................63
3.9.4.1 Create Radiotherapy Parent Order .....................................................................64
3.10 RO-ESI-09: Unsolicited Cancel Radiotherapy Parent Order.......................................... 69
3.10.1
Scope ......................................................................................................................69
3.10.2
Use Case Roles.......................................................................................................69
3.10.3
Referenced Standards.............................................................................................69
3.10.4
Interaction Diagram................................................................................................69
3.10.4.1
Unsolicited Cancel Radiotherapy Parent Order .............................................70
4 Open Issues ............................................................................................................................75

DRAFT

削除: 40
削除: 40
削除: 40
削除: 40
削除: 44
削除: 44
削除: 44
削除: 44
削除: 44
削除: 44
削除: 49
削除: 49
削除: 49
削除: 49
削除: 49
削除: 49
削除: 54
削除: 54
削除: 54
削除: 54
削除: 54
削除: 55
削除: 59
削除: 59
削除: 59
削除: 59
削除: 59
削除: 59
削除: 65
削除: 65
削除: 65
削除: 65
削除: 65
削除: 66
削除: 71
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
3
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

1 Preface to Volume 2
1.1 Intended Audience
The intended audience of this document is:• Technical staff of vendors planning to participate in the IHE initiative• IT departments of healthcare institutions• Experts involved in standards development• Anyone interested in the technical aspects of integrating healthcare information systems

1.2 How this Document is Organized
Section 1 is the preface, describing the intended audience, related resources, and organizations
and conventions used within this document.
Section 2 provides an overview of the concepts of IHE actors and transactions used in IHE todefine the functional components of a distributed healthcare environment.

DRAFT

Section 3 defines transactions in detail, specifying the roles for each actor, the standards
employed, the information exchanged, and in some cases, implementation options for thetransaction.
Section 4 defines a set of payload bindings with transactions.

Section 5 defines the high level content specifications used for the payloads of the transactions.
Section 6 defines the reusable sections of content payloads.
Section 7 defines the lower level building blocks used in various sections.

1.3 Conventions Used in this Volume
This document has adopted the following conventions for representing the framework concepts
and specifying how the standards upon which the IHE Technical Framework is based should beapplied.
1.3.1 The Generic IHE Transaction Model
Transaction descriptions are provided in section 4. In each transaction description, the actors, theroles they play, and the transactions between them are presented as use cases.
The generic IHE transaction description includes the following components:• Scope: a brief description of the transaction.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
4
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________•

Use case roles: textual definitions of the actors and their roles, with a simple diagram relating
them, e.g.:
Actor

Actor

Transaction••

Referenced Standards: the standards (stating the specific parts, chapters or sections thereof) to
be used for the transaction.
Interaction Diagram: a graphical depiction of the actors and transactions, with related
processing within an actor shown as a rectangle and time progressing downward, similar to:

DRAFT
Actor

Actor

Actor

MSG1

MSG2

MSG3

•

The interaction diagrams used in the IHE Technical Framework are modeled after thosedescribed in Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling
Language User Guide, ISBN 0-201-57168-4. Simple acknowledgment messages areomitted from the diagrams for brevity.
Message definitions: descriptions of each message involved in the transaction, the events thattrigger the message, its semantics, and the actions that the message triggers in the receiver.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
5
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

1.4 Copyright Permissions
Health Level Seven, Inc., has granted permission to the IHE to reproduce tables from the HL7
standard. The HL7 tables in this document are copyrighted by Health Level Seven, Inc. All
rights reserved.
Material drawn from these documents is credited where used.

1.5 Comments
The IHE sponsors welcome comments on this document and the IHE initiative. They should
be directed to the discussion server at http://forums.rsna.org or to:

Director of Research
American Society for Therapeutic Radiology and Oncology (ASTRO)
8280 Willow Oaks Corporate Drive, Suite 500
Fairfax, VA 22031
ihero@astro.org

DRAFT

Co-Chair of IHE-Japan RO committee
Integrating the Healthcare Enterprise-Japan
504, Monteberude Dai-2-Todaimae
6-2-9, Hongo, Bunkyo,
Tokyo, 113-0033, Japanro-info@ihe-j.org

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
6
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

2 Introduction
This document, the IHE Radiation Oncology Technical Framework (RO-TF), defines specificimplementations of established standards. These are intended to achieve integration goals that
promote appropriate exchange of medical information to coordinate the optimal patient careamong care providers in different care settings. It is expanded annually, after a period of public
review, and maintained regularly through the identification and correction of errata. The latest
version of the document is always available via the Internet at
http://www.ihe.net/Technical_Framework/index.cfm , where the technical framework volumes
specific to the various healthcare domains addressed by IHE may be found.
The IHE Radiation Oncology Technical Framework identifies a subset of the functional
components of the healthcare enterprises and health information networks, called IHE actors, andspecifies their interactions in terms of a set of coordinated, standards-based transactions.
The other domains within the IHE initiative also produce Technical Frameworks within theirrespective areas that together form the IHE Technical Framework. Currently, the following IHE
Technical Framework(s) are available:

DRAFT• IHE IT Infrastructure Technical Framework• IHE Cardiology Technical Framework• IHE Eye Care Technical Framework• IHE Laboratory Technical framework• IHE Radiology Technical Framework• IHE Patient Care Coordination Technical Framework
Where applicable, references are made to other technical frameworks. For the conventions onreferencing other frameworks, see the preface of this volume.

2.1 Relationship to Standards
The IHE Technical Framework identifies functional components of a distributed healthcare
environment (referred to as IHE actors), solely from the point of view of their interactions in thehealthcare enterprise. At its current level of development, it defines a coordinated set oftransactions based on standards (such as HL7, IETF, ASTM, DICOM, ISO, OASIS, etc.) in orderto accomplish a particular use case. As the scope of the IHE initiative expands, transactions basedon other standards may be included as required.
In some cases, IHE recommends selection of specific options supported by these standards.
However, IHE does not introduce technical choices that contradict conformance to thesestandards. If errors in or extensions to existing standards are identified, IHE’s policy is to reportthem to the appropriate standards bodies for resolution within their conformance and standards
evolution strategy.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
7
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
IHE is therefore an implementation framework, not a standard. Conformance claims for products
must still be made in direct reference to specific standards. In addition, vendors who have
implemented IHE integration capabilities in their products may publish IHE Integration
Statements to communicate their products’ capabilities. Vendors publishing IHE Integration
Statements accept full responsibility for their content. By comparing the IHE Integration
Statements from different products, a user familiar with the IHE concepts of actors andintegration profiles can determine the level of integration between them. See
http://www.ihe.net/Resources/upload/ihe_integration_statements.pdf for the format of IHE
Integration Statements.

2.2 Relationship to Product Implementations
The IHE actors and transactions described in the IHE Technical Framework are abstractions of
the real-world healthcare information system environment. While some of the transactions are
traditionally performed by specific product categories (e.g. HIS, Clinical Data Repository,
Electronic Health record systems, Radiology Information Systems, Clinical Information Systems
or Cardiology Information Systems), the IHE Technical Framework intentionally avoids
associating functions or actors with such product categories. For each actor, the IHE Technical
Framework defines only those functions associated with integrating information systems. The
IHE definition of an actor should therefore not be taken as the complete definition of any productthat might implement it, nor should the framework itself be taken to comprehensively describe
the architecture of a healthcare information system.

DRAFT

The reason for defining actors and transactions is to provide a basis for defining the interactions
among functional components of the healthcare information system environment. In situations
where a single physical product implements multiple functions, only the interfaces between the
product and external functions in the environment are considered to be significant by the IHE
initiative. Therefore, the IHE initiative takes no position as to the relative merits of an integrated
environment based on a single, all-encompassing information system versus one based on
multiple systems that together achieve the same end.

2.3 Relation of this Volume to the Technical Framework
The IHE Technical Framework is based on actors that interact through transactions.
Actors are information systems or components of information systems that produce, manage, or
act on information associated with operational activities in the enterprise.
Transactions are interactions between actors that transfer the required information throughstandards-based messages.
The implementation of the transactions described in this volume support the specification ofIntegration Profiles defined in Volume 1. The role and implementation of these transactions
require the understanding of the Integration profile they support.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
8
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
削除: IHE Usage Conventions(included for reference)

2.4 HL7 Profiling Conventions
The HL7 tables included in this document have been modified from the HL7 2.5 standard
document. Such a modification is called a profile. Refer to the HL7 2.5 standard for the meaningsof specific columns in the table.
The profiling tables in this document leverage the ongoing HL7 profile definition. To maintainthis specification at a generic level, the following differences have been introduced:•

Message specifications do not indicate the cardinality of segments within a message.

•

For fields composed of multiple components, there is no indication of the size of eachcomponent.

•

Where a table containing enumerated values is referenced from within a segment
profile table, the enumerated values table is not always present.

•

The number of times a repeating field can repeat is not indicated.

•

The conditions that would require inclusion of conditional fields are not defined when
they depend on functional characteristics of the system implementing the transaction
and they do not affect data consistency.

書式変更 : 箇条書きと段落番号

DRAFT

The following terms refer to the OPT column, which has been profiled:R

Element required (always present)

R2This is an IHE extension. If the sending application
has data for the field, it is required to populate thefield. If the value is not known, the field may not be
sent.

O

Element optional (can be empty)

C

Element conditionally present (depending on
presence or values of other elements)

B

Element used for backward compatibility (shallcontain the same information as the new element
defined in HL7)

For some HL7 transactions described in this document, IHE has strengthened the requirements on
the use of selected attributes. These situations are explicitly documented in section 3 and in the
appendices.

コメント [JW1]: True?
削除: 4
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
9
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

2.5 HL7 Implementation Notes
2.5.1 Network Guidelines
The HL7 2.5 standard does not define a network communications protocol. The HL7 2.1 standard
defines lower layer protocols in an appendix. These definitions were moved to the
Implementation Guide in 2.2 and subsequent versions, but are not HL7 requirements. The IHE
Framework makes these recommendations:
1. Applications shall use the Minimal Lower Layer Protocol defined in Appendix C of the
HL7 Implementation Guide.
2. An application that wants to send a message (initiate a transaction) will initiate a network
connection to start the transaction. The receiver application will respond with an
acknowledgement or response to query but will not initiate new transactions on thisnetwork connection.
2.5.2 Message Control
According to the HL7 standard, each message shall begin with the MSH (message header)segment. Table 2.5-1 identifies all required fields in this message. This table shall be interpreted
according to the HL7 Standard unless otherwise noted in section 2.4

DRAFT
Table 2.5-1 IHE Profile – MSH Segment

SEQ

LEN

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

1
4
227
227
227
227
26
40
15
20
3
60
15
180
2
2

17

3

DT

OPT

ST
ST
HD
HD
HD
HD
TS
ST
MSG
ST
PT
VID
NM
ST
ID
ID

R
R
R
R
R
R
O
O
R
R
R
R
O
O
O
O

ID

O

TBL#

ITEM#

Element Name

0155
0155

00001
00002
00003
00004
00005
00006
00007
00008
00009
00010
00011
00012
00013
00014
00015
00016

0399

00017

Field Separator
Encoding Characters
Sending Application
Sending Facility
Receiving Application
Receiving Facility
Date/Time Of Message
Security
Message Type
Message Control ID
Processing ID
Version ID
Sequence Number
Continuation PointerAccept Acknowledgment Type
Application Acknowledgment
Type
Country Code

0361
0362
0361
0362

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
10
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
18
19
20

16
250
20

ID
CE
ID

C
O
O

0211
0356

00692
00693
01317

Character Set
Principal Language Of Message
Alternate Character Set
Handling Scheme

Adapted from the HL7 Standard version 2.5

The IHE Technical Framework requires that applications support HL7-recommended values forthe fields MSH-1 Field Separator and MSH-2 Encoding Characters.
Field MSH-18 Character Set shall only be valued if the message utilizes character sets other thanISO IR-6, also known as ASCII. For Japan, this field shall be valued as a repeating field
designating ASCII and ISO IR87 (JIS X 0208 : Kanji, hiragana and katakana). Specifically, thefield will be valued, as ASCII~ISO IR87.
2.5.3 Acknowledgement modes
Applications that receive HL7 messages shall send acknowledgments using the HL7 Original
Mode (versus Enhanced Acknowledgment Mode).
The IHE Technical Framework provides for each HL7 message to be acknowledged by theappropriate HL7 acknowledgement message sent by the receiver of an HL7 message to its sender.
Patient demographic (ADT) messages will receive an HL7 ACK message acknowledgement andorder (OMG) messages will receive an ORG acknowledgement.

DRAFT

The segments of the ACK message listed below are required, and their detailed descriptions areprovided in tables 2.5-1, 2.5-2 and corresponding notes. The ERR segment is optional and may
be included if the MSA-1 Acknowledgement Code field identifies an error condition.
ACK

Acknowledgement Message

MSH
MSA
[ERR]

Message Header
Message Acknowledgement
Error Comments

Chapter in
HL7 2.52
2
2

The segments of the ORG message listed below are required and their detailed descriptions areprovided in tables 2.5-1, 2.5-2 and corresponding notes. The ERR segment is mandatory will be
included if the MSA-1 Acknowledgement Code field identifies an error condition.
ORG(Success)
MSH
MSA

General Order Message
Message Header
Message Acknowledgement

Chapter in
HL7 2.5
2
2

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
11
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________ORG(Error)
MSH
MSA
ERR

General Order Message
Message Header
Message Acknowledgement
Error

Chapter in
HL7 2.52
2
2

Table 2.5-1 IHE Profile – MSA Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

1
2
3
4
5
6

2
20
80
15
1
100

ID
ST
ST
NM
ID
CE

R
R
O
O
O
O

0008

00018
00010
00020
00021
00022

Acknowledgment Code
Message Control ID
Text Message
Expected Sequence Number
Delayed Acknowledgment Type
Error Condition

0102
00023

DRAFT

Adapted from the HL7 Standard version 2.5

Field MSA-2 Message Control ID shall contain the Message ID from the MSH-10 Message
Control ID of the incoming message for which this acknowledgement is sent.
Table 2.5-2 IHE Profile – ERR Segment

SEQ

LEN

1

80

DT

OPT

ID

R

TBL#

ITEM#

Element Name

00024

Error code and location

Adapted from the HL7 Standard version 2.5

2.5.4 HL7 Versioning
The selection of a particular version of HL7 for any given HL7 based transaction within theTechnical Framework is based upon a number of factors. These include:• Whether the version of HL7 provides the functionality needed for the transaction.
• How widely the version of HL7 is supported at the time of specification
Since the transactions are self-contained communications, the implementation of each HL7
transaction may use a different version of HL7.
An application implementing an IHE transaction which uses HL7 messaging must comply withthe message structure and contents defined by the specified version of HL7 and the Technical
Framework. It is acceptable if the version (MSH-12) is higher than that specified in the
Framework as long as the message structure and contents meet the requirements of thespecification.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
12
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
2.5.5 Use of Coded Entities and Coding Schemes
IHE does not produce, maintain or otherwise specify a coding scheme or other resource forcontrolled terminology (coded entities). Where applicable, coding schemes required by the HL7
and DICOM standards take precedence. In the cases where such resources are not explicitly
identified by the standards, implementations may utilize any resource (including proprietary or
local) provided any licensing/copyright requirements are satisfied.

コメント [JW2]: This is aninteresting statement of IHE-RAD.
We may want to consider peitioning
SNOMED for appropriate codes fornominal dose, treatment type, etc.
削除: <#>Abbreviations used in
HL7 tables

DRAFT

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
13
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3 IHE Transactions
This section defines each IHE transaction in detail, specifying the standards used, and theinformation transferred.
書式変更 : 箇条書きと段落番号

3.1 Patient registration
3.1.1 Scope
This transaction involves the patient information, including demographics, captured at the point of
encounter. This may occur when the visit is scheduled, if that precedes patient arrival at the institution.
This transaction is used for both in-patients (i.e., those who are assigned a bed at the facility) andoutpatients (i.e., those who are not assigned a bed at the facility).
書式変更 : 箇条書きと段落番号

3.1.2 Use Case Roles
Diagram TBD

DRAFT
ADT

TMS

Patient Registration

Actor: ADT
Role: Adds and modifies patient demographic and encounter information.
Actor: Order Placer
Role: Receives patient and encounter information for use in order entry.
Actor: Department System/TMS
Role: Receives and stores patient and encounter information for use in fulfillingorders by the Department System Scheduler.
Actor: MPI
Role: Receives patient and encounter information from multiple ADT systems.
Maintains unique enterprise-wide identifier for a patient.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
14
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
書式変更 : 箇条書きと段落番号

3.1.3 Referenced Standards
HL7 2.5 Chapter 4

書式変更 : 箇条書きと段落番号

3.1.4 Interaction Diagram
Diagram TBD
ADT

TMS

ADT^A01
or
ADT^A04
or
ADT^A05

DRAFT

書式変更 : 箇条書きと段落番号

3.1.4.1 Admit/Register Patient
3.1.4.1.1 Trigger Events

ADT – Patient Administration Message for TMS

削除: OMG – The Order Placer
places a new order for the TMS

3.1.4.1.2 Message Semantics
A01 – Admission of an in-patient into a facility
A04 – Registration of an outpatient for a visit of the facility
A05 – Pre-admission of an in-patient (i.e., registration of patient information ahead of actual
admission).

書式変更 : 箇条書きと段落番号書式変更 : 箇条書きと段落番号

3.1.4.1.2.1 EVN Segment
Table 3.1-1 identified required and optional fields of the EVN segment.
SEQ

Table 3.1-1 IHE Profile – EVN Segment
OPT TBL# ITEM#
Element Name

LEN

DT

1

3

ID

O

00099

Event Type Code

2

26

TS

R

0003

00100

Recorded Date/Time

3

26

TS

O

00101

Date/Time Planned Event

4

3

IS

O

00102

Event Reason Code0062

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
15
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

5

250

XCN

O

6

26

TS

O

0188

00103

Operator ID

01278

Event Occurred

Adapted from the HL7 standard, version 2.5
Field EVN-1 Event Type Code is optional; however, if present, its value shall be equal to the second
component of the field MSH-9 Message Type.

書式変更 : 箇条書きと段落番号

3.1.4.1.2.2 PID Segment
Table 3.1-2 identified required and optional fields of the PID segment.
Table 3.1-2 IHE Profile – PID Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

1

4

SI

O

00104

Set ID - PID

2

20

CX

O

00105

Patient ID

3

250

CX

R

00106

Patient Identifier List

4

20

CX

O

00107

Alternate Patient ID - PID

5

250

XPN

R

00108

Patient Name

6

250

7

26

8

1

9

250

10

250

11

250

DRAFT
XPN

O

00109

Mother’s Maiden Name

TS

R2

00110

Date/Time of Birth

IS

R

XPN

O

CE

O

XAD

O

0001

0005

0289

00111

Administrative Sex

00112

Patient Alias

00113

Race

00114

Patient Address

12

4

IS

O

00115

County Code

13

250

XTN

O

00116

Phone Number - Home

14

250

XTN

O

00117

Phone Number - Business

15

250

CE

O

0296

00118

Primary Language

16

250

CE

O

0002

00119

Marital Status

17

250

CE

O

0006

00120

Religion

18

250

CX

C

00121

Patient Account Number

19

16

ST

O

00122

SSN Number - Patient

20

25

DLN

O

00123

Driver's License Number - Patient

21

250

CX

O

00124

Mother's Identifier

22

250

CE

O

00125

Ethnic Group

23

250

ST

O

00126

Birth Place

24

1

ID

O

00127

Multiple Birth Indicator

25

2

NM

O

00128

Birth Order

26

250

CE

O

00129

Citizenship

0189

0136

0171

コメント [JW3]: IHE-J to resolve

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
16
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

27

250

CE

O

0172

00130

Veterans Military Status

28

250

CE

O

0212

00739

Nationality

29

26

TS

O

00740

Patient Death Date and Time

30

1

ID

O

0136

00741

Patient Death Indicator

31

1

ID

O

0136

01535

Identity Unknown Indicator

32

20

IS

O

0445

01536

Identity Reliability Code

33

26

TS

O

01537

Last Update Date/Time

34

241

HD

O

01538

Last Update Facility

35

250

CE

O

0446

01539

Species Code

36

250

CE

O

0447

01540

Breed Code

37

80

ST

O

01541

Strain

38

250

CE

O

0429

01542

Production Class Code

39

250

CWE

O

0171

01840

Tribal Citizenship

Adapted from the HL7 standard, version 2.5

Explanatory text TBD.

DRAFT

書式変更 : 箇条書きと段落番号

3.1.4.1.2.3 PV1 Segment

Table 3.1-3 identified required and optional fields of the PID segment.
Table 3.1-2 IHE Profile – PV1 Segment

SEQ

LEN

DT

1

4

2

OPT

SI

O

1

IS

R

3

80

PL

C

4

2

IS

O

5

250

CX

6

80

7
8

TBL#

ITEM#

Element Name

00131

Set ID - PV1

00132

Patient Class

00133

Assigned Patient Location

00134

Admission Type

O

00135

Preadmit Number

PL

O

00136

Prior Patient Location

250

XCN

O

0010

00137

Attending Doctor

250

XCN

O

0010

00138

Referring Doctor

9

250

XCN

O

0010

00139

Consulting Doctor

10

3

IS

O

0069

00140

Hospital Service

0004

0007

11

80

PL

O

00141

Temporary Location

12

2

IS

O

0087

00142

Preadmit Test Indicator

13

2

IS

O

0092

00143

Re-admission Indicator

14

6

IS

O

0023

00144

Admit Source

15

2

IS

O

0009

00145

Ambulatory Status

16

2

IS

O

0099

00146

VIP Indicator

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
17
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

17

250

XCN

O

0010

00147

Admitting Doctor

18

2

IS

O

0018

00148

Patient Type

19

250

CX

C

00149

Visit Number

20

50

FC

O

0064

00150

Financial Class

21

2

IS

O

0032

00151

Charge Price Indicator

22

2

IS

O

0045

00152

Courtesy Code

23

2

IS

O

0046

00153

Credit Rating

24

2

IS

O

0044

00154

Contract Code

25

8

DT

O

00155

Contract Effective Date

26

12

NM

O

00156

Contract Amount

27

3

NM

O

00157

Contract Period

28

2

IS

O

0073

00158

Interest Code

29

4

IS

O

0110

00159

Transfer to Bad Debt Code

30

8

DT

O

00160

Transfer to Bad Debt Date

31

10

IS

O

00161

Bad Debt Agency Code

32

12

33

12

34

1

35

8

36

3

37

47

38

250

39
40

0021

コメント [JW4]: To be resolved by
IHE-RO-J

DRAFT
NM

O

00162

Bad Debt Transfer Amount

NM

O

00163

Bad Debt Recovery Amount

IS

O

00164

Delete Account Indicator

DT

O

00165

Delete Account Date

IS

O

0112

00166

Discharge Disposition

DLD

O

0113

00167

Discharged to Location

CE

O

0114

00168

Diet Type

2

IS

O

0115

00169

Servicing Facility

1

IS

B

0116

00170

Bed Status

41

2

IS

O

0117

00171

Account Status

42

80

PL

O

00172

Pending Location

43

80

PL

O

00173

Prior Temporary Location

44

26

TS

O

00174

Admit Date/Time

45

26

TS

O

00175

Discharge Date/Time

0111

Adapted from the HL7 standard, version 2.5
Explanatory text tbd.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
18
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
書式変更 : 箇条書きと段落番号

3.1.4.1.2.4 Expected Actions
3.1.4.2 Cancel Admit/Register Patient
3.1.4.2.1 Trigger Events
The following events will trigger one of the Admit/Register messages:• A11 – Admission of an in-patient into a facility or registration of an outpatient for avisit of the facility has been cancelled due to error in the information or the decision
not to admit/register patient after all.
• A38 – Pre-admission of an in-patient (i.e., registration of patient information ahead of
actual admission) has been cancelled due to error in the information or the decision
not to admit/register patient after all.

書式変更 : 箇条書きと段落番号書式変更 : 箇条書きと段落番号

3.1.4.2.2 Message Semantics
TBD

DRAFT

書式変更 : 箇条書きと段落番号

3.1.4.2.2.1 PID Segment

3.1.4.2.2.2 EVN Segment
3.1.4.2.2.3 PV1 Segment

3.1.4.2.2.4 Expected Actions
TBD

3.2 RO-ESI-01: Create Radiotherapy Parent Order
3.2.1 Scope
This transaction is used by the Order Placer to place a new order with the TMS.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
19
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
3.2.2 Use Case Roles
Order
PlacerTMS

Order Placed

Actor: Order Placer
Role: Places Radiotherapy parent orders
Actor: TMS

DRAFT

Role: Receives and processes Radiotherapy parent orders.
3.2.3 Referenced Standards
HL7 2.5 Chapter 4

3.2.4 Interaction Diagram

Diagram TBD

Order Placer

TMS

OMG^O19

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
20
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.2.4.1 Create Radiotherapy Parent Order
3.2.4.1.1 Trigger EventsOMG – The Order Placer places a new order for the TMS
ORG –The TMS acknowledges receipt of the parent order.
3.2.4.1.2 Message Semantics
HL7 2.5 Chapter 4 OMG message. Refer to HL7 Standard for general message semantics.
The order start date is required to be sent if known in the TQ1, ORC, and OBR segments. (TQ17, ORC-7 and OBR-27).
Note: Additional qualifications to the level of specification and HL7 profiling are stated in
section 2.5.
Required segments are listed below. Other segments are optional.
OMG
MSH
PID
PV1
ORC
OBR

DRAFT
General Order Message

Message Header
Patient Identification
Patient Visit
Common Order
Order Detail

Chapter in
HL7 2.52
3
3
4
4

The OBX segment is an optional repeating segment that is required if nominal dose and /ortreatment intent are known. If this segment is present, it is mandatory to follow certain rules (seesection 3.2.4.1.2.6).
OMG

General Order Message

OBX

Observation/Result

削除: following

削除: XX

Chapter in
HL7 2.5
7

The TQ1 segment is an optional segment that is required if the desired start date is known. If thissegment is present, it is mandatory to follow certain rules (see section 3.2.4.1.2.7).
削除:
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
21
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Each message shall be acknowledged by the HL7 ORG message sent by the receiver of the ordermessage to its sender. See section 2.5.3 “Acknowledgement Modes” for definition and discussionof the ORG message.

書式変更 : 箇条書きと段落番号

3.2.4.1.2.1 MSH Segment
MSH segment shall be constructed as defined in the section 2.5.2 “Message Control”.

削除: X.X.X

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of “OMG”; the second component shall have value of O19. The third component is
optional; however, if present, it shall have a value of OMG_O19.
Each message shall be acknowledged by the HL7 ORG message sent by the receiver of OMG
message to its sender. See section 2.5.3“Acknowledgement Modes” for definition and discussionof the ORG message.
3.2.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table 3.2-1. See section
3.1.4.1.2.2 for the list of all fields of the PID segment.
SEQ
3
5
18

LEN
250
250
250

DRAFT
Table 3.2-1. IHE Profile – PID segment
DT
OPT TBL# ITEM#
Element Name
CX
R
00106
Patient Identifier List
XPN
R
00108
Patient Name
CX
C
00121
Patient Account Number

Adapted from the HL7 Standard, version 2.5

コメント [SS5]: These need to be
specified as per IHE-J requirements(similar to IHE-J RAD) for Country
Code and Character Set.
Jeff: Country Code is not required
because currency or other countryspecific data is included. Character
set is included in MSH section.
削除: MSH-17 through MSH-19
削除: X.X.X
書式変更 : 箇条書きと段落番号
削除:
削除: XXX
削除: .
削除: 3.1.4.1.2.3 (insert crossreference here)
削除: 1
コメント [JK6]: What is thecondition that this field is filled.
This is a question for the Japanesestakeholders

3.2.4.1.2.3 PV1 Segment
All of the fields in PV1 segment are optional, except those listed in table 3.2-2 (immediately
below, insert cross reference). See sec. 3.1.4.1.2.3 for the list of all fields of the PV1 segment.

コメント [SS7]: Optionality needs
to be resolved

Table 3.2-2. IHE profile - PV1 Segment
SEQ
2
8
19
51

LEN
1
250
250
1

DT
IS
XCN
CX
IS

OPT
R
R2
C
C

TBL#
0004
0010
0326

ITEM#
00132
00138
00149
01226

Element Name
Patient Class
Referring Doctor
Visit Number
Visit Indicator

コメント [SS8]: Optionality needs
to be resolved
コメント [SS9]: Optionality needs
to be resolved
コメント [SS10]: Optionality
needs to be resolved
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
22
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued. Additional requirements for the presence of value in these fields may be documented inregional or national appendices to the IHE Technical Framework.
The national requirements for Japan are…
Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.

コメント [SS11]: Need todetermine if this text is needed, andif so, further clarification of Japaneserequirements.
書式変更 : 箇条書きと段落番号

3.2.4.1.2.4 ORC Segment
ORC segment conveys common order information.
削除: XX.XX

Table 3.2-3. IHE Profile – ORC Segment
SEQ
1

LEN
2

DT
ID

OPT
R

TBL#
0119

ITEM#
00215

Element Name
Order Control

2

22

EI

C

00216

Placer Order Number

3

22

EI

C

00217

Filler Order Number

4

22

EI

O

00218

Placer Group Number

5

2

ID

O

0038

00219

Order Status

6

1

7

200

0121

8

200

9

26

TS

R

00223

Date/Time of Transaction

10

250

XCN

O

00224

Entered By

11

250

XCN

O

00225

Verified By

DRAFT
ID

O

00220

Response Flag

TQ

R

00221

Quantity/Timing

EIP

O

00222

Parent

12

250

XCN

R

00226

Ordering Provider

13

80

PL

O

00227

Enterers Location

XTN

O

00228

Callback Phone Number

00229

Order Effective Date/Time

00230

Order Control Code Reason

14

250

15

26

TS

O

16

250

CE

O

削除: R
削除: O
削除: C

削除: B
削除: O

Field ORC-1 Order Control must be valued as “NW”
This field is required to be valued if the Order Placer places the parent order. If the TMS places theparent order, the Filler Order number shall be used (see RO-ESI-08). The Field ORC-2 Placer Order
Number shall be unique within the Order Placer and will be used by all Child Orders to reference thisparent order.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
23
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Field ORC-3 Filler Order Number shall not be present when the Order Placer places the order..
Field ORC-5 Order Status shall not be present.
The fourth component, Start Date/Time in Field ORC-7 Quantity/Timing shall contain the earliest
date/time that the first child order can be scheduled for (default: date/time of this transaction). This
field will contain the same value as TQ1-7 Start DateTtime.
Field ORC-8 Parent shall not be present.
The action to be performed in the OMG message is defined by the Order Control code passed as partof the message. HL7 defines a number of Order Control codes.
The order control codes below shall be supported.
Supported Order Control Codes

Value
NW

Description
New order
書式変更 : 箇条書きと段落番号

3.2.4.1.2.5 OBR Segment

DRAFT
Table 3.2-4 IHE Profile – OBR Segment

SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

1

4

2

22

3

22

4

250

5

2

6

26

TS

B

00240

Requested Date/Time

7

26

TS

O

00241

Observation Date/Time #

SI

O

00237

Set ID – OBR

EI

C

00216

Placer Order Number

削除: R

EI

C

00217

Filler Order Number

削除: O

CE

R

00238

Universal Service Identifier

ID

B

00239

Priority – OBR

8

26

TS

O

00242

Observation End Date/Time #

9

20

CQ

O

00243

Collection Volume *

10

250

XCN

O

11

1

ID

O

12

250

CE

13

300

ST

00244

Collector Identifier *00245

Specimen Action Code *

O

00246

Danger Code

O

00247

Relevant Clinical Information

0065

14

26

TS

B

00248

Specimen Received Date/Time *

15

300

SPS

B

00249

Specimen Source

16

250

XCN

O

00226

Ordering Provider

17

250

XTN

O

00250

Order Callback Phone Number

18

60

ST

O

00251

Placer Field 1

19

60

ST

O

00252

Placer Field 2___________________________________________________________________
24
Draft
HIMSS

削除: XX.XX

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,

削除: 04/9/2009
削除: 03/12/2009

IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

20

60

ST

O

00253

Filler Field 1 +

21

60

ST

O

00254

Filler Field 2 +

22

26

TS

C

00255

Results Rpt/Status Chng - Date/Time +

23

40

MOC

O

00256

Charge to Practice +

24

10

ID

O

0074

00257

Diagnostic Serv Sect ID

25

1

ID

C

0123

00258

Result Status +

26

400

PRL

O

00259

Parent Result +

27

200

TQ

B

00221

Quantity/Timing

28

250

XCN

O

00260

Result Copies To

29

200

EIP

O

00261

Parent00262

Transportation Mode

30

20

ID

O

31

250

CE

O

0124

00263

Reason for Study

32

200

NDL

O

00264

Principal Result Interpreter +

33

200

NDL

O

00265

Assistant Result Interpreter +

34

200

NDL

O

00266

Technician +

35

200

36

26

37

4

38

250

39

250

40

250

41

30

コメント [JW12]: R2?

DRAFT
NDL

O

00267

Transcriptionist +

TS

O

00268

Scheduled Date/Time +

NM

O

01028

Number of Sample Containers *

CE

O

01029

Transport Logistics of Collected Sample *

CE

O

01030

Collector's Comment *

CE

O

01031

Transport Arrangement Responsibility

ID

O

0224

01032

Transport Arranged

0225

01033

Escort Required

42

1

ID

O

43

250

CE

O

44

250

CE

O

45

250

CE

46

250

CE

01034

Planned Patient Transport Comment

0088

00393

Procedure Code

O

0340

01316

Procedure Code Modifier

O

0411

01474

Placer Supplemental Service Information

Field OBR-4 Universal Service Identifier shall be populated with a JJ1017 code specific toradiation oncology.

コメント [JW13]: This needs
additional details to be provided by
IHE-RO-J after JJ1017 codes areissued..

Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in thefollowing table contain the same information.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
25
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Identical Element Mappings between ORC and OBR Segments
ORC Segment
Element

Element NameOBR Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

削除: Element Name... [1]TQ1 Segment
Element

TQ1-7

書式変更 : 箇条書きと段落番号

3.2.4.1.2.6 OBX Segment
The OBX segment will be used to transmit nominal dose and treatment intent if available. Theremay be 0,1, or 2 OBX segments.
Table 3.2-5. IHE Profile – OBX Segment
SEQ

LEN

DT

1

4

2

2

3

250

4

20

5

99999

6

250

7

60

1

OPT

SI

O

ID

R

CE

TBL#

ITEM#

Element Name

00569

Set ID – OBX

00570

Value Type

R

00571

Observation Identifier

ST

O

00572

Observation Sub-ID

variesR

00573

Observation Value

CE

C

00574

Units

ST

O

00575

References Range

00576

Abnormal Flags

DRAFT
0125

0078

8

5

IS

O

9

5

NM

O

10

2

ID

O

11

1

ID

R

12

26

TS

O

00580

Effective Date of Reference Range

13

20

ST

O

00581

User Defined Access Checks

00577

Probability

0080

00578

Nature of Abnormal Test

0085

00579

Observation Result Status

14

26

TS

O

00582

Date/Time of the Observation

15

250

CE

O

00583

Producer's ID

16

250

XCN

O

00584

Responsible Observer

17

250

CE

O

00936

Observation Method

18

22

EI

O

01479

Equipment Instance Identifier

19

26

TS

O

01480

Date/Time of the Analysis

a)

1

削除: C
削除: C

削除: 04/9/2009

The length of the observation field is variable, depending upon value type. See OBX-2 value type.
___________________________________________________________________
26

Draft
HIMSS

削除: XX.XX

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,

削除: 03/12/2009

IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

Nominal dose will always be communicated with a unit of measurement of Gray and a data type of
NM. Treatment intent will be one of the three following values: PALLIATIVE, CURATIVE, or
PROPHYLACTIC and a data type of ST.
Each OBX segment in a message will have a unique observation identifier.
Field OBX-11 Result status shall be valued as F [Final].
Sample:OBX|1|NM|Nominal Dose||60|Gy|||||F||||||||
OBX|2|ST|Treatment Intent||PALLIATIVE ||||||F||||||||
削除: <#>For use later on:

3.2.4.1.2.7 TQ1 Segment

書式変更 : 箇条書きと段落番号

The following TQ1 segment was introduced with HL7 Version 2.5 and conveys timing andschedule information.
Table 3.2-6. IHE Profile – TQ1 Segment
SEQ

LEN

DT

1

4

2

20

3

540

4

20

5

20

6

20

7

OPT

TBL#

ITEM#

Element Name

DRAFT

削除: This segment is optional, but
if it is present then the intormation in
the elements “Quantity” (TQ1-2)
together with “Start date/time”(TQ1-7) shall be identical to theinformation in ORC and OBR
segments “Quantity/Timing” (ORC7 and OBR-27).

SI

O

01627

Set ID - TQ1

CQ

O

01628

Quantity

RPT

O

01629

Repeat Pattern

TM

O

01630

Explicit Time

CQ

O

01631

Relative Time and Units

CQ

O

01632

Service Duration

26

TS

R

01633

Start date/time

削除: O

8

26

TS

O

01634

End date/time

削除: 2

0335

9

250

CWE

O

01635

Priority

10

250

TX

O

0485

01636

Condition text

11

250

TX

O

01637

Text instruction

12

10

ID

C

01638

Conjunction

13

20

CQ

O

01639

Occurrence duration

14

10

NM

O

01640

Total occurrence's

0427

削除: XX.XX

Field ORC-7 Quantity/Timing shall contain the earliest date/time that the first child order can bescheduled for (default: date/time of this transaction). The information in the element TQ1-7 Start
date/time shall be identical to the information in the fourth component, Start Date/Time in ORC-7
Quantity/Timing.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
27
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
3.2.4.1.2.8 Expected Actions
The TMS shall accept the order information for fulfillment. If error in data prevents it from fulfillingthe order, it shall notify the Order Placer by returning proper information in the ORG message.

DRAFT

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
28
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.3 RO-ESI-02: Create Radiotherapy Delivery Child Order
3.3.1 Scope
This transaction is used by the TMS to inform the Order Placer that a radiation treatment has
been scheduled. Each treatment fraction is represented in an individual ORC/OBR/TQ1 triplet
combination of segments, but multiple ORC/OBR/TQ1 triplets combined segments may beplaced in one child order. Scheduling signifies that a precise time assignment has been made forthe radiation treatment. Scheduling of other oncology events is out of the scope of thistransaction.

コメント [JW14]: Josia proposesthat the TQ1 segment be removed
from the main body of theframework.

3.3.2 Use Case Roles
Diagram TBD

Order Placer

TMS

DRAFT
Create Radiotherapy
Delivery Child Order

Actor: Order Placer
Role: Receives and displays scheduled radiation treatment information from the
TMS
Actor: TMS
Role: Schedules radiation treatment procedures
3.3.3 Referenced Standards
HL7 2.5 Chapter 4
3.3.4 Interaction Diagram
Diagram TBD
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
29
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

Order Placer

TMS

OMG^O19

3.3.4.1 Create Radiotherapy Delivery Child Order
3.3.4.1.1 Trigger EventsOMG – The TMS schedules a treatment

DRAFT

ORG –The Order Placer acknowledges receipt of the child order.

3.3.4.1.2 Message Semantics
The TMS uses the OMG message to convey necessary scheduled treatment information.

削除: d

OMG message. Refer to HL7 2.5 Chapter 4 for general message semantics.

削除: HL7 2.5 Chapter 4

ORG message. Refer to HL7 Chapter 4 for general message semantics. See section. 2.5.2 and 2.5.3 ofthis document for MSH and MSA segment definition.

Note: Additional qualifications to the level of specification and HL7 profiling are stated in
section 2.5..

削除: Standard
削除:
See sec. xx of this document for
削除: MSH. HL7 2.5 Chapter 4
削除: Standard
削除: xxRequired segments are listed below. Other segments are optional.
OMG

General Order Message

MSH
PID
PV1
ORC
OBR
TQ1

Message Header
Patient Identification
Patient Visit
Common Order
Order Detail
Timing/Quantity

Chapter in
HL7 2.5
2
3
3
4
4
4

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
30
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
コメント [JW15]: I think the TQ1
needs to stand.

Each message shall be acknowledged by the HL7 ORG message sent by the receiver of the ordermessage to its sender. See section 2.5.3 “Acknowledgement Modes” for definition and discussionof the ORG message.

削除:
ORG Success
ORG(Success)... [2]
書式変更 : 箇条書きと段落番号

3.3.4.1.2.1 MSH Segment

削除: X.X.X

MSH segment shall be constructed as defined in the section 2.5.2 “Message Control”.

コメント [JW16]: Need to do ORG
message specification with RO-ESI01. We could refer to this in a toplevel Implementation section as does
IHE RAD.

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of “OMG”; the second component shall have value of O19. The third component is
optional; however, if present, it shall have a value of OMG_O19.
Each message shall be acknowledged by the HL7 ORG message sent by the receiver of OMG
message to its sender. See section 2.5.3“Acknowledgement Modes” for definition and discussionof the ORG message.

DRAFT

3.3.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table 3.3-1. See section.
3.1.4.1.2.2 for the list of all fields of the PID segment.
Table 3.3-1. IHE Profile – PID segment

SEQ
3
5
18

LEN
250
250
250

DT
CX
XPN
CX

OPT
R
R
C

TBL#

ITEM#
00106
00108
00121

Element Name
Patient Identifier List
Patient Name
Patient Account Number

The TMS will use the PID-3 Patient Identifier List to convey the Patient ID uniquely identifying the patient.

All of the fields in PV1 segment are optional, except those listed in table 3.3-2 (immediately
below. See sec. 3.1.4.1.2.3 for the list of all fields of the PV1 segment.
Table 3.3-2. IHE profile - PV1 Segment
LEN
1

DT
IS

書式変更 : 箇条書きと段落番号
削除: XXX
削除: xxx (insert cross reference
here)
コメント [SS17]: Japan intends to
use PAM at some point, which may
affect the entire approach to patient
identification
コメント [JW18]: I don’t think that
PAM comes into play here since thisis not patient administrative
management so much as patient
identification. However, theframework is lacking in patient
administration management (patientregistration, changes, merge, etc) andI think this needs to be addressed
before public comment. I propose wefollow IHE-RAD. The patientregistration section is my proposal.
コメント [JK19]: Describe“condition” under which this willappear. Responsibility:IHE-RO-J.

3.3.4.1.2.3 PV1 Segment

SEQ
2

削除:
<#>MSA Segment and ORG
message definition

OPT
R

TBL#
0004

ITEM#
00132

Element Name
Patient Class

削除: Alternatively, thefollowing could be required by
the HIS... [3]
コメント [JW21]: IHE profiles
generally specify the origin of thispatient identifier. This is donein the...
[4]
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
31
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
19
51

250
1

CX
IS

C
C

0326

00149
01226

Visit Number
Visit Indicator

コメント [SS22]: Optionality
needs to be resolved
コメント [SS23]: Optionality
needs to be resolved

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued. Additional requirements for the presence of value in these fields may be documented inregional or national appendices to the IHE Technical Framework.
Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.

コメント [SS24]: Optionality
needs to be resolved
コメント [SS25]: Need todetermine if this text is needed, andif so, further clarification of Japaneserequirements.

3.3.4.1.2.4 ORC Segment
ORC segment conveys order information. A parent order ORC segment is not required, and theOrder Placer shall not rely on its presence. The child order ORC conveys common orderinformation about the treatment schedule events (child orders) and contains a reference to theparent order (ORC-8).
All of the fields in ORC segment are optional, except those listed in table 3.3-3 immediately
below. See sec. 3.2.4.1.2.4 for the list of all fields of the ORC segment.

DRAFT

削除: XX.XX

Table 3.3-3 IHE Profile – ORC Segment

SEQ
1
3
5

LEN
2
22
2

DT
ID

OPT
R

EI

R

ID

R

TBL#
0119

0038

ITEM#
00215

Element Name
Order Control

削除: 2... [5]00217

Filler Order Number

削除: 4... [6]

Order Status

削除: 6... [7]

削除: 9... [8]

00219

7

200

TQ

B

00221

Quantity/Timing

8

200

EIP

R

00222

ParentEach radiation treatment scheduled in response to a single radiotherapy parent order is represented by
an ORC-OBR-TQ1 triplet.
Field ORC-1 Order Control for each child order must be valued as “CH”.

削除:

Field ORC-2 Placer Order Number shall be omitted.
Field ORC-3 Filler Order Number shall be present in each child ORC in the OMG message, and eachFiller Order Number shall be unique within the TMS.
Field ORC-5 Order Status shall be valued as an “SC” for each child ORC in the OMG message.
The fourth component of Field ORC-7 Quantity/Timing, Start Date/Time, shall contain the scheduled
date/time of the scheduled appointment. The information shall be identical to the information in
TQ1-7 Start date/time.

削除: quantity/
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
32
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Field ORC-8 Parent shall be the Order Number from the Parent Order. If the Order Placer created theparent order, the placer order number shall be in ORC-8:1. If the TMS created the parent order, thenthe filler order number shall be in ORC-8:2. The parent order number shall be present in each child
ORC in the OMG message describing the parent order to which the scheduled treatments events
belong.

削除:
削除: Placer
削除: It

The action to be performed in the OMG message is defined by the Order Control code passed as partof the message. HL7 defines a number of Order Control codes.
The order control codes below shall be supported.
Supported Order Control Codes

Value
CH

Description
Child Order

Supported Order Status Codes

Value
SC

Description
In Process, Scheduled

DRAFT

書式変更 : 箇条書きと段落番号

3.3.4.1.2.5 OBR Segment

Table XX.XX IHE Profile – OBR Segment

SEQ

LEN

DT

OPT

TBL#

ITEM#

削除: 1

... [9]

削除: 5... [10]

Element Name

2

22

EI

O

00216

Placer Order Number

3

22

EI

R

00217

Filler Order Number

4

250

CE

R

00238

Universal Service Identifier

13

300

ST

R2

00247

Relevant Clinical Information

削除: O

27

200

TQ

B

00221

Quantity/Timing

削除: 14... [11]

29

200

EIP

O

00261

Parent

削除: 28... [12]Field OBR-4 Universal Service Identifier shall be populated with a JJ1017 code specific toradiation oncology.
Field OBR-13 Relevant Clinical Info shall be populated if patient record contains any medical alerts
or patient instructions (e.g. empty bladder prior to treatment) that may be relevant to the order and, inparticular, need to be communicated to the technologist or patient.

削除: 30... [13]
コメント [JW26]: This needs
additional details. Is this true for thechild order as it is for the parent?
Need to confirm.

Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in thefollowing table contain the same information.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
33
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Identical Element Mappings between ORC and OBR Segments
ORC Segment
Element

Element NameOBR Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

削除: Element Name... [14]

TQ1 Segment
Element

TQ1-7

書式変更 : 箇条書きと段落番号

3.3.4.1.2.6 TQ1 Segment
The following TQ1 segment was introduced with HL7 Version 2.5 and conveys timing andschedule information. This segment is optional, but if it is present then the intormation in theelements “Quantity” (TQ1-2) together with “Start date/time” (TQ1-7) shall be identical to theinformation in ORC and OBR segments “Quantity/Timing” (ORC-7 and OBR-27).
Table XX.XX IHE Profile – TQ1 Segment
SEQ

LEN
7

26

DT

OPT

TS

R2

TBL#

ITEM#

Element Name

削除: 1... [15]

Start date/time

削除: 2... [16]

DRAFT
01633

削除: TQ1 conveys schedule
information for each child order.

Field TQ1-7 Start date/time shall contain both the date and the time of the scheduled radiotherapy
delivery.

3.3.4.1.2.7 Expected Actions
The Order Placer shall accept the scheduled treatment events/child order information for
fulfillment. If an error in the data prevents it from accepting any one of the child orders, it shallreject the message and notify the TMS by returning proper information in the ORG message.

削除: 3... [17]
コメント [JW27]: I believe thatdate/time is required to be present.
Need to discuss with Josia.
削除: 8... [18]
書式変更 : 箇条書きと段落番号

コメント [JW28]: Need to specify
how discrete this should be.
Probably should make use of the full
ORG message capabilities. The
current draft mandates only an MSA
and ERR segment.
書式変更 : 箇条書きと段落番号

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
34
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.4 RO-ESI-03: Modify Radiotherapy Child Order
3.4.1 Scope
This transaction is used by the TMS to modify a scheduled treatment child order previously sent
to the Order Placer.

削除: with
書式変更 : 箇条書きと段落番号

3.4.2 Use Case Roles
Diagram TBD

Order Placer

TMS

Modify Radiotherapy
Delivery Child Order

DRAFT

削除:

Actor: TMS

Role: Changes the date/time or content of a Radiotherapy scheduled treatment.

削除: Modifies
削除: child order

Actor: Order Placer

Role: Receives update and changes the referenced Radiotherapy Child Order.

削除: Modifies

書式変更 : 箇条書きと段落番号

3.4.3 Referenced Standards
HL7 2.5 Chapter 4

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
35
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

書式変更 : 箇条書きと段落番号

3.4.4 Interaction Diagram
Diagram TBD
Order Placer

TMS

OMG^O19

DRAFT

書式変更 : 箇条書きと段落番号

3.4.4.1 Modify Radiotherapy Child Order

3.4.4.1.1 Trigger Events
1. A Modify Radiotherapy Child Order transaction is triggered in the case when the TMS(Therapy Management System) re-schedules or modifies characteristics of the scheduled
treatment child order it previously scheduled and transmitted to the OP (Order Placer) via a
Create Radiotherapy Child Order transaction (Transaction RO-ESI-02).

削除:

3.4.4.1.2 Message Semantics
The Modify Radiotherapy Child Order transaction is conveyed by the HL7 OMG message
formatted according to the rules described in chapter 4 of HL7 2.5.

削除: sec. 3.1.

Note: Additional qualifications to the level of specification and HL7 profiling are stated in
section 2.5.
Required segments are listed below. Other segments are optional.
OMG

General Order Message

MSH
PID
PV1
ORC

Message Header
Patient Identification
Patient Visit
Common Order

Chapter in
HL7 2.52
3
34___________________________________________________________________
36
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,

削除: 04/9/2009
削除: 03/12/2009

IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Order Detail
Timing/Quantity

OBR
TQ1

4
4

Each message shall be acknowledged by the HL7 ORG message sent by the receiver of OMG
message to its sender. See section 2.5.3 “Acknowledgement Modes” for definition and discussionof the ORG message.
Only procedural information that is conveyed in the ORC, OBR and TQ1 segments of themessage may be changed. Any updates of patient or visit information shall be performed bystandard ADT messages.
Only the ORC, OBR, TQ1 segment triplet that was part of the original Create Radiotherapy
Child Order message and that contains modified information shall be present .
The ORC and OBR elements given in tables 3.3-3 and 3.3-4 shall not be altered after the initial
Create Radiotherapy Child Order (section 3.2), regardless of the type of control code.

DRAFT

OMG
削除: OBX,
削除: ORC
削除: pairPlacer Order Number

OBR-2, ORC-2

Filler Order Number

OBR-3, ORC-3

削除: (plus optional thecorresponding TQ1 segment)

Parent

ORC-8, OBR-29

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of “OMG”; the second component shall have value of O19. The third component is
optional; however, if present, it shall have a value of OMG_O19.
3.4.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table XXX See sec.
3.1.4.1.2.2 for the list of all fields of the PID segment.
Table 3.X-1. IHE Profile – PID segment
DT
OPT TBL# ITEM#
Element Name
CX
R
00106
Patient Identifier List
XPN
R
00108
Patient Name
CX
C
00121
Patient Account Number

コメント [SS30]: Is this approachnecessary for the OP (HIS), or can
we just use the segment pairs(triplets, actually with TQ1) that are
being changed.
削除: All (ORC, OBR) segment
pairs sent in the Create Radiotherapy
Child Order message shall bepresent in the Modify Radiotherapy
Child Order message, not only... the[20]
削除: x.xx-x
削除: . x.x
削除: Any other elements in the
OBR or ORC segments may...
be [21]
書式変更 : 箇条書きと段落番号
削除: X.X.X
削除: 3.1.4.1.2.3 (insert crossreference here)
削除: 1
コメント [JW31]: Optionality
needs to be resolved.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
37
Draft
HIMSS

... [19]

削除: X.X.X

Element Number(s)MSH segment shall be constructed as defined in the section 2.5.2 “Message Control”.

LEN
250
250
250

削除: The following is an optional
repeating segment that is required if
nominal dose and /or treatment intent
are known. If this segment is present,
it is mandatory to follow certain
rules (see section XX).

Element Name

3.4.4.1.2.1 MSH Segment

SEQ
3
5
18

コメント [JW29]: Since nominal
dose and treatment intent are not
attributes of the child order, it does
not seem plausible that that it can be
modified here. If it is desired tochange these attributes of the
PARENT order, it would be donewith the cancel new parent ordertransactions. So I deleyed the OBX
reference.

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

Adapted from the HL7 Standard, version 2.5

3.4.4.1.2.3 PV1 Segment
All of the fields in PV1 segment are optional, except those listed in table 3.XX-2 (immediately
below, insert cross reference). See sec. 3.1.4.1.2.3 for the list of all fields of the PV1 segment.

削除: 1

Table 3.X-2.IHE profile - PV1 Segment
SEQ
2
19
51

LEN
1
250
1

DT
IS
CX
IS

OPT
R
C
C

TBL#
0004
0326

ITEM#
00132
00149
01226

Element Name
Patient Class
Visit Number
Visit Indicator

コメント [SS32]: Optionality
needs to be resolved
コメント [SS33]: Optionality
needs to be resolved

DRAFT

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued. Additional requirements for the presence of value in these fields may be documented inregional or national appendices to the IHE Technical Framework.

コメント [SS34]: Optionality
needs to be resolved

The national requirements for Japan are…

コメント [SS35]: Optionality
needs to be resolved

Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.
3.4.4.1.2.4 ORC Segment

コメント [SS36]: Need todetermine if this text is needed, andif so, further clarification of Japaneserequirements.
書式変更 : 箇条書きと段落番号

ORC segment conveys common order information.
削除: XX.XX

Table 3.XX-3 IHE Profile – ORC Segment
SEQ
1

LEN
2

DT
ID

OPT
R

2

22

EI

O

3

22

EI

R

5

2

ID

O

7

200

TQ

8

200

EIP

TBL#
0119

ITEM#
00215

Element Name
Order Control

00216

Placer Order Number

00217

Filler Order Number

00219

Order Status

B

00221

Quantity/Timing

R

00222

Parent0038

Field ORC-2 Placer Order Number shall be omitted.
___________________________________________________________________
38
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,

削除: 04/9/2009
削除: 03/12/2009

IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Field ORC-3 Filler Order Number is used to identify what Child Order is to be modified.
Field ORC-7 Quantity/Timing shall have the modified information.
Field ORC-8 Parent shall be the Placer Order Number from the Parent Order. If the Order Placer
created the parent order, the placer order number shall be in ORC-8:1. If the TMS created the parent
order, then the filler order number shall be in ORC-8:2. This value shall not be changed.

削除: and

The action to be performed in the OMG message is defined by the Order Control code passed as partof the message. HL7 defines a number of Order Control codes.
The following Order Control Codes and Order Statuses are applicable for use in the ORC-1 andORC-5 fields respectively.

ORC-1
value

ORC-1 description

Originator

ORC-5
value

XO

Change child order, order is still scheduled orin progress

TMS

SC

XO

Change child order, order has been completed

TMS

CM

DRAFT

The value of the field ORC-5 Order Status shall reflect status of the underlying order. If the orderis changed and is still scheduled or in progress, ORC-1 is set to ‘XO’ and ORC-5 will be valued
as ‘SC’.
If the order is changed and has been completed, ORC-1 is set to ‘XO’ and ORC-5 will be valued
as ‘CM’.
書式変更 : 箇条書きと段落番号

3.4.4.1.2.5 OBR Segment
Table 3.XX-4 IHE Profile – OBR Segment
SEQ

LEN
2

DT
22

EI

OPT

TBL#

O

ITEM#

Element Name

00216

Placer Order Number

3

22

EI

R

00217

Filler Order Number

4

250

CE

R

00238

Universal Service Identifier

13

300

ST

R2

00247

Relevant Clinical Information

27

200

TQ

B

00221

Quantity/Timing

29

200

EIP

R

00261

ParentField OBR-4 Universal Service Identifier shall be populated with a JJ1017 code specific toradiation oncology.

削除: XX.XX

コメント [JW37]: This needs
additional details.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
39
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Field OBR-13 Relevant Clinical Info shall be populated if patient record contains any medical alerts
or patient instructions (e.g. empty bladder prior to treatment) that may be relevant to the order and, inparticular, need to be communicated to the technologist or patient.
Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in thefollowing table contain the same information.
Identical Element Mappings between ORC and OBR Segments
ORC Segment
Element

Element NameOBR Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29TQ1 Segment
Element

TQ1-7

DRAFT

3.4.4.1.2.6 TQ1 Segment

The following TQ1 segment was introduced with HL7 Version 2.5 and conveys timing andschedule information.
Table XX.XX IHE Profile – TQ1 Segment

SEQ

LEN
7

26

DT

OPT

TS

R2

TBL#

ITEM#
01633

Element Name
Start date/time

This segment is optional, but if it is present then the intormation in the elements “Quantity”(TQ1-2) together with “Start date/time” (TQ1-7) shall be identical to the information in ORC andOBR segments “Quantity/Timing” (ORC-7 and OBR-27).

3.4.4.1.2.7 Expected Actions
The Order Placer shall modify corresponding scheduled treatment child order information using
the ORC-3 Filler Order Number as a unique key of the child order in question. Information from
PID and PV1 segments shall not be used to update patient or visit information.

コメント [JW38]: I deleted the
OBX. It seems to me that sending ofdelivered dose will occur only on acomplete child order transaction.
削除: <#>OBX Segment
The OBX segment will be used totransmit Prescribed dose for thefraction, Delivered Dose for thefraction,Total delivered dose (for theparent order), Number of performed
fractions (from children of the parent
order), Number of planned (total)
fractions (from the parent order).
See Appendix X.X.X for detailregarding the OBX contents.
There may be 1 or more OBX
segments.
Table XX.XX IHE Profile – OBX
Segment
SEQ... [22]
書式変更 : 箇条書きと段落番号
コメント [JW39]: I believe thatdate/time is required to be present.
Need to discuss with Josia.
削除: <#>
削除: Each OBX segment in a
message will have a uniqueobservation identifier.
Field OBX-11 Result status shall bevalued as F [Final].
書式変更 : 箇条書きと段落番号
コメント [JW40]: Where is“resource” passed? As currently
constituted, the only information on
the child order is:
Date/time
Procedure code
Clinical observations
If we want to add other data, weneed to add that to the create childorder transaction.
... [23]
削除: is expected to perform thefollowing actions based on the valueof the field ORC-1 Order Control... [24]
削除:
書式変更 : 箇条書きと段落番号
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
40
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.5 RO-ESI-04: Cancel Radiotherapy Child Order
3.5.1 Scope
This transaction is used by the TMS to cancel a child order with the Order Placer.

書式変更 : 箇条書きと段落番号

3.5.2 Use Case Roles
Diagram TBD

Order Placer

TMS

Cancel Radiotherapy
Delivery Child Order

削除:

DRAFT

Actor: TMS

Role: Cancel a Radiotherapy child order.
Actor: Order Placer

Role: Cancels the referenced Radiotherapy Child Order.

書式変更 : 箇条書きと段落番号

3.5.3 Referenced Standards
HL7 2.5 Chapter 4

書式変更 : 箇条書きと段落番号

3.5.4 Interaction Diagram
Diagram TBD
Order Placer

TMS

OMG^O19

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
41
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
書式変更 : 箇条書きと段落番号

3.5.4.1 Cancel Radiotherapy Child Order
3.5.4.1.1 Trigger Events
2. A Cancel Radiotherapy Child Order transaction is triggered in the case when the TMS(Therapy Management System) cancels the child order it previously scheduled andtransmitted to the OP (Order Placer) via a Create Radiotherapy Child Order transaction(Transaction RO-ESI-02).
3. This may happen in response to a Cancel Radiotherapy Parent Order (RO-ESI-07) if childorders were already created for the parent order.

書式変更 : 箇条書きと段落番号

3.5.4.1.2 Message Semantics
HL7 2.5 Chapter 4 OMG message. Refer to HL7 Standard for general message semantics.
The Cancel Radiotherapy Child Order transaction is conveyed by the HL7 OMG message
formatted according to the rules described in sec. 2.5.

削除: 3.1

DRAFT

Note: Additional qualifications to the level of specification and HL7 profiling are stated in
section 2.5.
Required segments are listed below. Other segments are optional.
OMG
MSH
PID
PV1
ORC
OBR

General Order Message

Message Header
Patient Identification
Patient Visit
Common Order
Order Detail

Chapter in
HL7 2.52
3
3
4
4Each message shall be acknowledged by the HL7 ORG message sent by the receiver of OMG
message to its sender. See 2.5.3 “Acknowledgement Modes” for definition and discussion of the
ORG message.

削除: section X.X.X

Only procedural information that is conveyed in the OBR and ORC segments of the message may
be canceled. Any updates of patient or visit information shall be performed by standard ADT
messages.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
42
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
3.5.4.1.2.1 MSH Segment

書式変更 : 箇条書きと段落番号

MSH segment shall be constructed as defined in the section 2.5.2“Message Control”.

削除: X.X.X

Field MSH-9 Message Type shall have at least two components. The first component shall have avalue of “OMG”; the second component shall have value of O19. The third component is
optional; however, if present, it shall have a value of OMG_O19.
3.5.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table XXX See sec.
3.1.4.1.2.3 (insert cross reference here) for the list of all fields of the PID segment.

削除: MSH-17 through MSH-19
書式変更 : 箇条書きと段落番号

Table 3.1-1. IHE Profile – PID segment

SEQ
3
5
18

LEN
250
250
250

DT
CX
XPN
CX

OPT
R
R
C

TBL#

ITEM#
00106
00108
00121

Element Name
Patient Identifier List
Patient Name
Patient Account Number

DRAFT

コメント [JW41]: Outstanding
issue.

Adapted from the HL7 Standard, version 2.5

書式変更 : 箇条書きと段落番号

3.5.4.1.2.3 PV1 Segment

All of the fields in PV1 segment are optional, except those listed in table 3.1-2 (immediately
below, insert cross reference). See sec. XXX for the list of all fields of the PV1 segment.
IHE profile - PV1 Segment
SEQ
2
19
51

LEN
1
250
1

DT
IS
CX
IS

OPT
R
C
C

TBL#
0004
0326

ITEM#
00132
00149
01226

Element Name
Patient Class
Visit Number
Visit Indicator

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall bevalued. Additional requirements for the presence of value in these fields may be documented inregional or national appendices to the IHE Technical Framework.
The national requirements for Japan are…
Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit Number ispresent. May be omitted otherwise.

コメント [SS42]: Optionality
needs to be resolved
コメント [SS43]: Optionality
needs to be resolved
コメント [SS44]: Optionality
needs to be resolved
コメント [SS45]: Optionality
needs to be resolved
コメント [SS46]: Need todetermine if this text is needed, andif so, further clarification of Japaneserequirements.
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
43
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
書式変更 : 箇条書きと段落番号

3.5.4.1.2.4 ORC Segment
ORC segment conveys common order information.
Table XX.XX IHE Profile – ORC Segment
SEQ
1

LEN
2

DT
ID

OPT
R

2

22

EI

3

22

8

200

TBL#
0119

ITEM#
00215

Element Name
Order Control

O

00216

Placer Order Number

EI

R

00217

Filler Order Number

EIP

R

00222

Parent削除: 5... [25]

Field ORC-1 Control Code shall have a value of “CA”
Field ORC-2 Placer Order Number shall be omitted.
Field ORC-3 Filler Order Number is used to identify what Child Order is to be canceled.

DRAFT

削除:

Field ORC-8 Parent shall be the Placer Order Number from the Parent Order.

書式変更 : 箇条書きと段落番号

3.5.4.1.2.5 OBR Segment

Table XX.XX IHE Profile – OBR Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

2

22

EI

O

00216

Placer Order Number

3

22

EI

R

00217

Filler Order Number

Field OBR-4 Universal Service Identifier shall be populated with a JJ1017 code specific toradiation oncology.

削除: 4

コメント [JW51]: This needs
additional details.

Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in thefollowing table contain the same information.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
44
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,... [26]

IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Identical Element Mappings between ORC and OBR Segments
Element Name

ORC Segment
Element

OBR Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

削除: Element Name... [27]

TQ1 Segment
Element

TQ1-7

書式変更 : 箇条書きと段落番号

3.5.4.1.2.6 Expected Actions
The OP is expected to perform the following actions based on the value of the field ORC-1 Order
Control Code:CA – Child Order has been cancelled, the Order Provider shall inactivate corresponding childorder information using ORC-3 Filler Order Number as a unique key of the child order inquestion.
書式変更 : 箇条書きと段落番号

DRAFT

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
45
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.6 RO-ESI-05: Update Radiotherapy Child Order Status
3.6.1 Scope
This transaction is used by the TMS to notify the Order Placer when a treatment delivery has
been completed (including a “partial delivery” of the fraction).

書式変更 : 箇条書きと段落番号

3.6.2 Use Case Roles
Diagram TBD

Order Placer

TMS

Update Radiotherapy
Delivery Child Order
StatusDRAFT

Actor: TMS

Role: Update the status of a Radiotherapy child order.
Actor: Order Placer

Role: Update the status of the referenced Radiotherapy Child Order.
書式変更 : 箇条書きと段落番号

3.6.3 Referenced Standards
HL7 2.5 Chapter 4

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
46
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

書式変更 : 箇条書きと段落番号

3.6.4 Interaction Diagram
Diagram TBD

Order Placer

TMS

OMG^O19

DRAFT

書式変更 : 箇条書きと段落番号

3.6.4.1 Update Radiotherapy Child Order Status

3.6.4.1.1 Trigger Events
4. An Update Radiotherapy Child Order Status transaction is triggered in the case when the
TMS (Therapy Management System) changes the status of the child order it previously
scheduled and transmitted to the OP (Order Placer) via a Create Radiotherapy Child Ordertransaction (Transaction RO-ESI-02).

コメント [JW52]: Change to“completes a scheduled treatment
child order”. I advocate that this be
the only status change supported.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
47
Draft
HIMSS

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA,IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

書式変更 : 箇条書きと段落番号

3.6.4.1.2 Message Semantics
The Update Radiotherapy Child Order Status transaction is conveyed by the HL7 OMG
message formatted according to the rules described in sec. 3.1.
Note: Additional qualifications to the level of specification and HL7 profiling are statedin section 2.5.
Required segments are listed below. Other segments are optional.
OMG

General Order Message

MSH
PID
PV1
ORC
OBR

Message Header
Patient Identification
Patient Visit
Common Order
Order Detail

Chapter in
HL7 2.5
2
3
3
4
4

DRAFT

Each message shall be acknowledged by the HL7 ORG message sent by the receiver of
OMG message to its sender. See section 2.5.3“Acknowledgement Modes” for definitionand discussion of the ORG message.

削除: {OBX}... [28]

コメント [SS53]: Find proper
section
削除: X.X.X
書式変更 : 箇条書きと段落番号

3.6.4.1.2.1 MSH Segment
MSH segment shall be constructed as defined in the section 2.5.2 “Message Control”.

削除: X.X.X

Field MSH-9 Message Type shall have at least two components. The first component
shall have a value of “OMG”; the second component shall have value of O19. The third
component is optional; however, if present, it shall have a value of OMG_O19.
削除: MSH-17 through MSH-19

3.6.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table XXX See sec.

書式変更 : 箇条書きと段落番号
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
48
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
3.1.4.1.2.3 (insert cross reference here) for the list of all fields of the PID segment.
Table 3.1-1. IHE Profile – PID segment

SEQ
3
5
18

LEN
250
250
250

DT
CX
XPN
CX

OPT
R
R
C

TBL#

ITEM#
00106
00108
00121

Element Name
Patient Identifier List
Patient Name
Patient Account Number

コメント [JW54]: To be reolved.

Adapted from the HL7 Standard, version 2.5
書式変更 : 箇条書きと段落番号

3.6.4.1.2.3 PV1 Segment
All of the fields in PV1 segment are optional, except those listed in table 3.1-2(immediately below, insert cross reference). See sec. XXX for the list of all fields of thePV1 segment.

DRAFT
IHE profile - PV1 Segment

SEQ
19
51

LEN
250
1

DT
CX
IS

OPT
C
C

TBL#
0326

ITEM#
00149
01226

Element Name
Visit Number
Visit Indicator

コメント [SS55]: Optionality
needs to be resolved
コメント [SS56]: Optionality
needs to be resolved

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shallbe valued. Additional requirements for the presence of value in these fields may be
documented in regional or national appendices to the IHE Technical Framework.

コメント [SS57]: Optionality
needs to be resolved

The national requirements for Japan are…

コメント [SS58]: Optionality
needs to be resolved

Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit
Number is present. May be omitted otherwise.
3.6.4.1.2.4 ORC Segment

コメント [SS59]: Need todetermine if this text is needed, andif so, further clarification of Japaneserequirements.
書式変更 : 箇条書きと段落番号

ORC segment conveys common order information.
Table XX.XX IHE Profile – ORC Segment
SEQ
1

LEN
2

DT
ID

OPT
R

2

22

EI

O

TBL#
0119

ITEM#
00215

Element Name
Order Control

00216

Placer Order Number

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
49
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
3

22

EI

R

5

2

ID

R

0038

00217

Filler Order Number

00219

Order Status

削除: 7... [29]

Field ORC-1 Order Control shall have a value of “SC”
Field ORC-2 Placer Order Number shall be omitted.
Field ORC-3 Filler Order Number is used to identify the Child Order whose status is being
updated.

Field ORC-5 Order Status will contain the reason for the status change. The reason shallbe one of the following:
Order Status codes
Value

Description

CM

Order is completed

DC

Order is discontinued

DRAFT

Adapted from the HL7 Standard, version 2.5
CA (Cancel) is not supported with this transaction. To cancel, the TMS will use theCancel Child Order transaction.
.

Table XX.XX IHE Profile – OBR Segment
LEN

DT

コメント [JW61]: The filler ordernumber will fully identify the order.
The parent is not required in myunderstanding.
削除: Field ORC-8 Parent shall be
the Placer Order Number from the
Parent Order

3.6.4.1.2.5 OBR Segment
SEQ

コメント [JW60]: TMS systems do
not support a DC function to myknowledge. I advocate that weremove this.

ITEM#

Element Name

2

22

EI

OPT
O

TBL#

00216

Placer Order Number

3

22

EI

R

00217

Filler Order Number

削除: shall have the value of thePlacer Order Number used in the
Parent Order of the Child Order
whose status is being updated.
書式変更 : 箇条書きと段落番号
削除: 4... [30]
コメント [JW62]: This needs
additional details.

3.6.4.1.2.6 OBX Segment

書式変更 : 箇条書きと段落番号

The OBX segment is not required. It shall be used to transmit (e.g.) Prescribed dose for thefraction, Delivered Dose for the fraction, Total delivered dose (for the parent order), Numberof performed fractions (from children of the parent order), Number of planned (total)
fractions (from the parent order). See Appendix X.X.X for detail regarding the OBX
contents.

コメント [JW63]: These fields are
not necessary for a cancel transaction
削除: The OBX segment will be
used to削除:
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
50
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
There may be 1 or more OBX segments.

コメント [JW64]: I think thisshould read that 5 OBX segments are
required, one for each field.

Table XX.XX IHE Profile – OBX Segment
SEQ

LEN
11

DT
1

ID

OPT

TBL#

ITEM#

R

0085

00579

Element Name
Observation Result Status

Each OBX segment in a message will have a unique observation identifier.
Field OBX-11 Result status shall be valued as F [Final].

コメント [JW65]: We need tominimally give suggested values forthese.
書式変更 : 箇条書きと段落番号

3.6.4.1.2.7 Expected Actions
TMS shall provide Order Placer with status updates on the child order. At least thefollowing events shall be noted:• Completed – when the delivery child order has completed.
• Discontinued – when a partial delivery has taken place and the intent of the TMS is to
not deliver any more dose against the child order. How the TMS is to addresscompletion of a partial delivery is outside the scope of this transaction.

DRAFT

コメント [JW66]: Since TMS’s donot support a discontinue action, I
think that partial delivery will be
implied by the dose delivered partsof the complete child order message.
書式変更 : 箇条書きと段落番号

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
51
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.7 RO-ESI-06 Update Radiotherapy Parent Order Status
3.7.1 Scope
This transaction is used by the TMS to inform the Order Placer of a change in status of aparent order, namely that the order is in-progress or is completed.
3.7.2 Use Case Roles

削除: (including in progress, as wellas complete)This section corresponds toTransaction RO-ESI-06 of the IHE
Technical Framework. Transaction
RO-ESI-06 is used by the Order
Placer and TMS actors.
削除: about the

Diagram TBD
Order Placer

TMS

コメント [SS67]: This conflicts
with the idea of having a status
update from CM to IP. The questionof flow of control for that use case is
open.
削除: s

Update Radiotherapy
Parent Order Status

Actor: TMS

DRAFT

削除: it has completed and thoseparent orders
削除: Update Parent Order Status
message cannot be used to request an
action, for example, cancellation or
discontinuation of a parent order.
削除:
書式変更 : 箇条書きと段落番号

Role: sends notifications of order status to the Order Placer.
Actor: Order Placer

Role: Receives and updates the Order Status

削除: updates from TMS.

書式変更 : 箇条書きと段落番号

3.7.3 Referenced Standards
HL7 2.5 Chapter 4

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
52
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

書式変更 : 箇条書きと段落番号

3.7.4 Interaction Diagram
Diagram TBD

Order Placer

TMS

OMG^O19

DRAFT

書式変更 : 箇条書きと段落番号

3.7.4.1 Update Radiotherapy Parent Order Status
3.7.4.1.1 Trigger EventsOMG – TMS updates a parent order status (control code = SC)

書式変更 : 箇条書きと段落番号

3.7.4.1.1.1 Status “in progress”
The first scheduled treatment event (child order) has begun (parent order status becomesin progress).

書式変更 : 箇条書きと段落番号

3.7.4.1.1.2 Status “Complete”
The treatment is completed in the TMS (what constitutes completion is defined by theTMS).
3.7.4.1.1.3 Change status from “Complete” to “In progress”
The treatment was previously completed by the TMS but it has been decided to continue
treatment against the parent order. For example, the original order was carried out but
subsequent evaluation led to a decision to add 3 more radiation treatments.

コメント [JW68]: I added this after
seeing the case expressed in the ORC
section below.
書式変更 : 箇条書きと段落番号書式変更 : 箇条書きと段落番号

3.7.4.1.2 Message Semantics
HL7 2.5 Chapter 4 OMG message. Refer to HL7 Standard for general message semantics.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
53
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Note: Additional qualifications to the level of specification and HL7 profiling are statedin section 2.5.
Required segments are listed below. Other segments are optional.
OMG

General Order Message

MSH
PID
PV1
ORC
OBR

Message Header
Patient Identification
Patient Visit
Common Order
Order Detail

Chapter in
HL7 2.523344

書式変更 : 箇条書きと段落番号

3.7.4.1.2.1 MSH Segment

DRAFT

MSH segment shall be constructed as defined in the section X.X.X “Message Control”.
Field MSH-9 Message Type shall have at least two components. The first component
shall have a value of “OMG”; the second component shall have value of O19. The third
component is optional; however, if present, it shall have a value of OMG_O19.
3.7.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table XXX See sec.
3.1.4.1.2.3 (insert cross reference here) for the list of all fields of the PID segment.
Table 3.x-x. IHE Profile – PID segment

SEQ
3
5
18

LEN
250
250
250

DT
CX
XPN
CX

OPT
R
R
C

コメント [SS69]: These need to be
specified as per IHE-J requirements(similar to IHE-J RAD) for Country
Code and Character Set.
削除: MSH-17 through MSH-19
書式変更 : 箇条書きと段落番号

TBL#

ITEM#
00106
00108
00121

Element Name
Patient Identifier List
Patient Name
Patient Account Number

コメント [JW70]: To be resolved
by IHE-RO-J.

Adapted from the HL7 Standard, version 2.5
書式変更 : 箇条書きと段落番号

3.7.4.1.2.3 PV1 Segment
All of the fields in PV1 segment are optional, except those listed in table 3.1-2(immediately below, insert cross reference). See sec. XXX for the list of all fields of thePV1 segment.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
54
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

IHE profile - PV1 Segment
SEQ
2
19
51

LEN
1
250
1

DT
IS
CX
IS

OPT
R
C
C

TBL#
0004
0326

ITEM#
00132
00149
01226

Element Name
Patient Class
Visit Number
Visit Indicator

コメント [SS71]: Optionality
needs to be resolved
コメント [SS72]: Optionality
needs to be resolved

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shallbe valued. Additional requirements for the presence of value in these fields may be
documented in regional or national appendices to the IHE Technical Framework.

コメント [SS73]: Optionality
needs to be resolved

The national requirements for Japan are…

コメント [SS74]: Optionality
needs to be resolved

Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit
Number is present. May be omitted otherwise.
3.7.4.1.2.4 ORC Segment

コメント [SS75]: Need todetermine if this text is needed, andif so, further clarification of Japaneserequirements.
書式変更 : 箇条書きと段落番号

ORC segment conveys common order information.

DRAFT

Table XX.XX IHE Profile – ORC Segment
SEQ
1

LEN
2

DT
ID

OPT
R

2

22

EI

3

22

5
16

TBL#
0119

ITEM#
00215

Element Name
Order Control

C

00216

Placer Order Number

EI

C

00217

Filler Order Number

2

ID

R

00219

Order Status

250

CE

C

00230

Order Control Code Reason

0038

削除: R
削除: O
削除: 4

... [31]

削除: 6... [32]

削除: 8... [33]

削除: 9... [34]

Field ORC-1 Order Control must be valued as “SC”.
If the Order Placer sent the original order, field ORC-2 Placer Order number is required andfield ORC-3 Filler Order number shall not be present. If the TMS placed the parent order,
the Filler Order number shall be used and field ORC-2 Placer Order number shall not bepresent (see RO-ESI-08).

削除: F
削除: .
F
削除:

Field ORC-5 Order Status will contain the reason for the status change. The reason shallbe one of the following:
Order Status codes
Value

Description

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
55
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

CM

Order is completed

IP

Order is in progress

Adapted from the HL7 Standard, version 2.5
Neither CA (Cancel), nor DC (Discontinue) is supported in this transaction. To cancel ordiscontinue the OP will use the Cancel Parent Order transaction.
Field ORC-16 Order Control Code Reason must contain a value when the Order Statuschanges from CM to IP (the Parent Order was previously considered complete, but forsome reason the patient needs to continue treatment under the Parent Order).

削除: Field ORC-8 Parent shall not
be present

書式変更 : 箇条書きと段落番号

3.7.4.1.2.5 OBR Segment
Table XX.XX IHE Profile – OBR Segment
SEQ

LEN
2

22

3

22

27

200

削除: 1

DRAFT
DT

OPT

TBL#

ITEM#

Element Name

EI

C

00216

Placer Order Number

削除: R

EI

C

00217

Filler Order Number

削除: O

TQ

B

00221

Quantity/Timing

削除: 4... [36]

削除: 28... [37]

削除: 29... [38]

Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in
the following table contain the same information.
Identical Element Mappings between ORC and OBR Segments
Element Name... [35]

ORC Segment
Element

OBR Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29TQ1 Segment
Element

削除: 30... [39]
削除: Field OBR-4 Universal
Service Identifier shall be populatedwith a JJ1017 code specific toradiation oncology.

TQ1-7
削除: Identical Element Mappings
between ORC and OBR Segments
Element Name... [40]
書式変更 : 箇条書きと段落番号

3.7.4.1.2.6 Expected Actions
TMS shall provide Order Placer with status updates on the order. At least the following
events shall be noted:• In Progress – when the first delivery child order status is updated to “In-progress”(Order Status code of “IP”).

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
56
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________••In Progress - if a previously completed Parent Order needs to be returned to “Inprogress” status, e.g. patient needs more treatment under the Parent Order (Order
Status code of “IP”).
Completed – when all delivery child orders are completed (Order Status code of“CM”).

削除: (
削除: )

削除: TMS shall send one Order
Status Update message with theOrder Status code of “CM”.
TMS shall use the Order Status
Update message with the Order
Status code of “IP ”, to facilitate
synchronization of order handlingwith the Order Placer, for example,
to prevent cancellation of an parent
order in progress.
書式変更 : 箇条書きと段落番号

DRAFT

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
57
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.8 RO-ESI-07: Cancel Radiotherapy Parent Order
3.8.1 Scope
This transaction is used by the Order Placer to cancel an existing parent order with the
TMS.

書式変更 : 箇条書きと段落番号

3.8.2 Use Case RolesOP

TMS

Order Canceled
or Discontinued

Actor: Order Placer

DRAFT

Role: Cancels an Existing Radiotherapy parent order
Actor: TMS

Role: Receives and processes cancelation of Radiotherapy parent order.
書式変更 : 箇条書きと段落番号

3.8.3 Referenced Standards
HL7 2.5 Chapter 4

書式変更 : 箇条書きと段落番号

3.8.4 Interaction Diagram
OP

TMS
OMG

Order Canceled
by OP

or
OMG

Order Discontinuedby OP

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
58
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
書式変更 : 箇条書きと段落番号

3.8.4.1 Cancel Radiotherapy Parent Order
3.8.4.1.1 Trigger EventsOMG – Order Placer cancels a parent order (control code = CA).
OMG – Order Placer discontinues (attempts to stop) an ongoing parent order (control
code = DC).

書式変更 : 箇条書きと段落番号

3.8.4.1.2 Message Semantics
HL7 2.5 Chapter 4 OMG message. Refer to HL7 Standard for general message semantics.
Note: Additional qualifications to the level of specification and HL7 profiling are statedin section 2.5.
Required segments are listed below. Other segments are optional.
OMG
MSH
PID
PV1
ORC
OBR

General Order Message
Message Header
Patient Identification
Patient Visit
Common Order
Order Detail

Chapter in HL7 2.5
2
3
3
4
4

DRAFT

書式変更 : 箇条書きと段落番号

3.8.4.1.2.1 MSH Segment

MSH segment shall be constructed as defined in the section X.X.X “Message Control”.
Field MSH-9 Message Type shall have at least two components. The first component
shall have a value of “OMG”; the second component shall have value of O19. The third
component is optional; however, if present, it shall have a value of OMG_O19.
3.8.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table XXX See sec.
3.1.4.1.2.3 (insert cross reference here) for the list of all fields of the PID segment.

削除: MSH-17 through MSH-19
書式変更 : 箇条書きと段落番号

Table 3.1-1. IHE Profile – PID segment

SEQ
3
5
18

LEN
250
250
250

DT
CX
XPN
CX

OPT
R
R
C

TBL#

ITEM#
00106
00108
00121

Element Name
Patient Identifier List
Patient Name
Patient Account Number
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
59
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Adapted from the HL7 Standard, version 2.5
書式変更 : 箇条書きと段落番号

3.8.4.1.2.3 PV1 Segment
All of the fields in PV1 segment are optional, except those listed in table 3.1-2(immediately below, insert cross reference). See sec. XXX for the list of all fields of thePV1 segment.
IHE profile - PV1 Segment
SEQ
2
19
51

LEN
1
250
1

DT
IS
CX
IS

OPT
R
C
C

TBL#
0004
0326

ITEM#
00132
00149
01226

Element Name
Patient Class
Visit Number
Visit Indicator

コメント [SS76]: Optionality
needs to be resolved
コメント [SS77]: Optionality
needs to be resolved

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shallbe valued. Additional requirements for the presence of value in these fields may be
documented in regional or national appendices to the IHE Technical Framework.

コメント [SS78]: Optionality
needs to be resolved

The national requirements for Japan are…

コメント [SS79]: Optionality
needs to be resolved

DRAFT

Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit
Number is present. May be omitted otherwise.
3.8.4.1.2.4 ORC Segment

コメント [SS80]: Need todetermine if this text is needed, andif so, further clarification of Japaneserequirements.
書式変更 : 箇条書きと段落番号

ORC segment conveys common order information.
削除: (To be described)

Table XX.XX IHE Profile – ORC Segment
SEQ
1

LEN
2

DT
ID

OPT
R

2

22

EI

3

22

15

26

TBL#
0119

ITEM#
00215

Element Name
Order Control

C

00216

Placer Order Number

削除: O

EI

C

00217

Filler Order Number

削除: 5... [41]

TS

C

00229

Order Effective Date/Time

削除: 9... [42]

削除: R

削除: 8

Field ORC-1 Order Control must be valued as “CA” or “DC”
The action to be performed in the OMG message is defined by the Order Control code passed
as part of the message. HL7 defines a number of Order Control codes.
The order control codes below shall be supported.

... [43]
コメント [SS82]: If the Order
Status is DC, this would determine
whether a fraction is delivered before
the effective date/time. Optionality
TBD by analysis of IHE-J RO
削除: 16
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
60
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSS... [44]IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Supported Order Control Codes

Value
CA

Description
Cancel order request

DC

Discontinue Order request

If the Order Placer sent the original order, field ORC-2 Placer Order number is used to
identify the parent order and the filler order number shall not be present. If the TMS
placed the parent order, the Filler Order number shall be used. If the Order Placer sent theoriginal order field ORC-3 Filler Order number shall not be present.

Field ORC-15 Order effective Date/Time is required and shall determine if a child order
may still be performed when this parent order is discontinued.
3.8.4.1.2.5 OBR Segment
Table XX.XX IHE Profile – OBR Segment
LEN
1

4

2

22

3

22

4

250

DRAFT
DT
SI

OPT
O

EI

削除: F
削除:
削除: F
削除: Field ORC-5 Order Status
shall not be present.

Field ORC--8 Parent shall not be present.

SEQ

削除:

TBL#

ITEM#
00237

Element Name
Set ID – OBR

C

00216

Placer Order Number

EI

C

00217

Filler Order Number

CE

R

00238

Universal Service Identifier

Field OBR-4 Universal Service Identifier shall be populated with a JJ1017 code specific
to radiation oncology.

コメント [JW84]: I don’t know
about this. If the treatments isscheduled for 10am but hasn’t
started and at 1pm the order iscancelled, I would argue that theorder ought be cancelled. It is not
being cancelled at a particular startdate/time; it is being cancelled as ofnow.
書式変更 : 箇条書きと段落番号
削除: R
削除: O
コメント [JW85]: This needs
additional details.

Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in
the following table contain the same information.
Identical Element Mappings between ORC and OBR Segments
Element Name

ORC Segment Element

OBR
Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3
書式変更 : 箇条書きと段落番号
削除: discard the record of theparent order

3.8.4.1.2.6 Expected Actions
After receiving the OMG message with the order status code CA, the TMS shall update theparent order and the unconsummated related child order(s) and shall not attempt to scheduleor otherwise to fulfill them. If the TMS has already scheduled the treatment deliveries (child

削除: and
削除: it
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
61
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
orders) corresponding to this parent order, it has to perform Transaction RO-ESI-04 Cancel
Radiotherapy Delivery Child Order (see sec. X.XX) to notify the OP of child ordercancellation.
Order Placer shall not cancel parent order that has already been started, i.e., the one for which
TMS transmitted the “In-Progress” status (see sec. X.X.X). However, if the TMS receives thecancellation message after it has sent the Child Status Update message (for example, INPROGRESS), TMS shall not accept order cancellation and return respond acknowledgmentwith an error.

If the Parent Order status is in “IN PROGRESS”, Order Placer will utilize the OMG
message with the order status code of DC. When TMS receives a message to discontinue
the order, TMS shall discard the remaining related child order(s) using RO-ESI-04
Cancel Radiotherapy Delivery Child Order.
書式変更 : 箇条書きと段落番号

DRAFT

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
62
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.9 RO-ESI-08: Unsolicited Create Radiotherapy Parent Order
3.9.1 Scope
This transaction is used by the TMS to place a new order with the Order Placer.

書式変更 : 箇条書きと段落番号

3.9.2 Use Case Roles
Diagram TBD

Order Placer

TMS

Unsolicited Create
Radiotherapy Parent
Order

Actor: TMS

削除:

DRAFT

Role: Places Radiotherapy parent orders
Actor: Order Placer

Role: Receives and processes Radiotherapy parent orders.

書式変更 : 箇条書きと段落番号

3.9.3 Referenced Standards
HL7 2.5 Chapter 4

書式変更 : 箇条書きと段落番号

3.9.4 Interaction Diagram
Diagram TBD
Order Placer

TMS

OMG^O19

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
63
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
書式変更 : 箇条書きと段落番号

3.9.4.1 Create Radiotherapy Parent Order
3.9.4.1.1 Trigger EventsOMG – The TMS places a new order for the Order Placer

書式変更 : 箇条書きと段落番号

3.9.4.1.2 Message Semantics
HL7 2.5 Chapter 4 OMG message. Refer to HL7 Standard for general message semantics.
Note: Additional qualifications to the level of specification and HL7 profiling are statedin section 2.5.
Required segments are listed below. Other segments are optional.

OMG

MSH
PID
PV1
ORC
OBR

General Order Message

Chapterin HL7
2.5

DRAFT
Message Header

2

Patient Identification

3

Patient Visit

3

Common Order

4

Order Detail4

The following is an optional repeating segment that is required if nominal dose and /ortreatment intent are known. If this segment is present, it is mandatory to follow certain
rules (see section XX).
OMG

General Order Message

Chapterin HL7
2.5

OBX

Observation/Result7

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
64
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Each message shall be acknowledged by the HL7 ORG message sent by the receiver of
OMG message to its sender. See section X.X.X “Acknowledgement Modes” fordefinition and discussion of the ORG message.

書式変更 : 箇条書きと段落番号

3.9.4.1.2.1 MSH Segment
MSH segment shall be constructed as defined in the section X.X.X “Message Control”.
Field MSH-9 Message Type shall have at least two components. The first component
shall have a value of “OMG”; the second component shall have value of O19. The third
component is optional; however, if present, it shall have a value of OMG_O19.
MSH-17 through MSH-19 {{[[ ToDo: This should be further described by IHE-J RO,
defining the correct values to reference Japanese language, character set, etc. ]]}}

書式変更 : 箇条書きと段落番号

3.9.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table XXX See sec.
3.1.4.1.2.3 (insert cross reference here) for the list of all fields of the PID segment.
Table 3.1-1. IHE Profile – PID segment

DRAFT

SEQ

LEN

DT

OPT

3

250

CX

5

250

18

250

TBL#

ITEM#

Element Name

R

00106

Patient Identifier List

XPN

R

00108

Patient Name

CX

C

00121

Patient Account Number

Adapted from the HL7 Standard, version 2.5
書式変更 : 箇条書きと段落番号

3.9.4.1.2.3 PV1 Segment
All of the fields in PV1 segment are optional, except those listed in table 3.1-2(immediately below, insert cross reference). See sec. XXX for the list of all fields of thePV1 segment.
IHE profile - PV1 Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
65
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

2

1

IS

R

0004

00132

Patient Class

8

250

XCN

R2

0010

00138

Referring Doctor

19

250

CX

C

00149

Visit Number

51

1

IS

C

01226

Visit Indicator0326

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shallbe valued. Additional requirements for the presence of value in these fields may be
documented in regional or national appendices to the IHE Technical Framework.
The national requirements for Japan are…
Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit
Number is present. May be omitted otherwise.

書式変更 : 箇条書きと段落番号

3.9.4.1.2.4 ORC Segment

DRAFT

ORC segment conveys common order information.

Table XX.XX IHE Profile – ORC Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

1

2

ID

R

0119

00215

Order Control

2

22

EI

O

00216

Placer Order Number

削除: R

3

22

EI

R

00217

Filler Order Number

削除: O

5

2

ID

O

00219

Order Status

8

200

EIP

O

00222

Parent

0038

削除: 9

... [45]

Field ORC-1 Order Control must be valued as “NW”
Field ORC-2 Placer Order Number shall not be present.
Field ORC-3 Filler Order Number is used to identify this parent order.

削除: is used to identify this parent
order.
削除: shall not be present.

Field ORC-5 Order Status shall not be present.
Field ORC-8 Parent shall not be present.
The action to be performed in the OMG message is defined by the Order Control code passed aspart of the message. HL7 defines a number of Order Control codes.

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
66
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________The order control codes below shall be supported.
Supported Order Control Codes

Value

Description

NW

New order

書式変更 : 箇条書きと段落番号

3.9.4.1.2.5 OBR Segment
Table XX.XX IHE Profile – OBR Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

1

4

SI

O

00237

Set ID – OBR

2

22

EI

R

00216

Placer Order Number

3

22

EI

O

00217

Filler Order Number

4

250

CE

R

00238

Universal Service Identifier

DRAFT

Field OBR-4 Universal Service Identifier shall be populated with a JJ1017 code specific
to radiation oncology.
Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in thefollowing table contain the same information (if present).

Identical Element Mappings between ORC and OBR Segments
Element Name

ORC Segment Element

OBR
Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

削除: Quantity/Timing

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
67
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSS... [46]

IHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
書式変更 : 箇条書きと段落番号

3.9.4.1.2.6 OBX Segment
The OBX segment will be used to transmit nominal dose and treatment intent if available. Theremay be 0,1, or 2 OBX segments. See Appendix X.X.X for detail regarding the OBX contents.

Table XX.XX IHE Profile – OBX Segment
SEQ
11

LEN
1

DT

OPT

TBL#

ITEM#

Element Name

ID

R

0085

00579

Observation Result Status

Nominal dose will always be communicated with a unit of measurement of Gray and a data typeof NM. Treatment intent will be one of the three following values: PALLIATIVE, CURATIVE,
or PROPHYLACTIC and a data type of ST.
Each OBX segment in a message will have a unique observation identifier.
Field OBX-11 Result status shall be valued as F [Final].

DRAFT

書式変更 : 箇条書きと段落番号

3.9.4.1.2.7 ERR Segment

ERR segment in the ORG (Error) message shall be constructed as defined in the section x.x.x“Acknowledgement Modes”.
Field ERR-1 Error code and location in ORG (Error) shall have the Error code value of 204(Unknown Key Identifier).

コメント [SS86]: Insert proper
section

書式変更 : 箇条書きと段落番号

3.9.4.1.2.8 Expected Actions
The Order Placer shall accept the order information for fulfillment. If error in data prevents itfrom fulfilling the order, it shall notify the TMS by returning proper information in the ORG
message.

If the Order Placer accepts and registers order information transmitted from the TMS in
the OMG message, it shall assign its unique number to it and convey that number to the
TMS in the ORG (Success) message. In turn, the TMS shall register received Order
Placer number and include it into the subsequent communication of order status with
Order Placer.
書式変更 : 箇条書きと段落番号

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
68
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.10 RO-ESI-09: Unsolicited Cancel Radiotherapy Parent Order
3.10.1 Scope
This transaction is used by the TMS to cancel an existing parent order with the OP.

書式変更 : 箇条書きと段落番号

3.10.2 Use Case RolesOP

TMS

Order Canceled
or Discontinued

Actor: TMS

DRAFT

Role: Cancels an Existing Radiotherapy parent order
Actor: Order Placer

Role: Receives and processes cancelation of Radiotherapy parent order
書式変更 : 箇条書きと段落番号

3.10.3 Referenced Standards
HL7 2.5 Chapter 4

書式変更 : 箇条書きと段落番号

3.10.4 Interaction Diagram
OP
Order Canceled

TMS
OMG

by TMS
Order Discontinued

OMG

by TMS

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
69
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
3.10.4.1 Unsolicited Cancel Radiotherapy Parent Order
3.10.4.1.1

書式変更 : 箇条書きと段落番号

Trigger EventsOMG – TMS cancels a parent order (control code = CA).
OMG – TMS discontinues (attempts to stop) an ongoing parent order (control code =DC).

書式変更 : 箇条書きと段落番号

Message Semantics
3.10.4.1.2
HL7 2.5 Chapter 4 OMG message. Refer to HL7 Standard for general message semantics.
Note: Additional qualifications to the level of specification and HL7 profiling are statedin section 2.5.
Required segments are listed below. Other segments are optional.
OMG
MSH
PID
PV1
ORC
OBR

General Order Message
Message Header
Patient Identification
Patient Visit
Common Order
Order Detail

Chapter in HL7 2.5
2
3
3
4
4

DRAFT

書式変更 : 箇条書きと段落番号

3.10.4.1.2.1 MSH Segment

MSH segment shall be constructed as defined in the section X.X.X “Message Control”.
Field MSH-9 Message Type shall have at least two components. The first component
shall have a value of “OMG”; the second component shall have value of O19. The third
component is optional; however, if present, it shall have a value of OMG_O19.
コメント [SS87]: These need to be
specified as per IHE-J requirements(similar to IHE-J RAD) for Country
Code and Character Set.

MSH-17 through MSH-19

3.10.4.1.2.2 PID Segment
All of the fields in PID segment are optional, except those listed in table XXX See sec.
3.1.4.1.2.3 (insert cross reference here) for the list of all fields of the PID segment.

書式変更 : 箇条書きと段落番号

Table 3.1-1. IHE Profile – PID segment

SEQ
3
5

LEN
250
250

DT
CX
XPN

OPT
R
R

TBL#

ITEM#
00106
00108

Element Name
Patient Identifier List
Patient Name

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
70
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
18

250

CX

C

00121

Patient Account Number

Adapted from the HL7 Standard, version 2.5
書式変更 : 箇条書きと段落番号

3.10.4.1.2.3 PV1 Segment
All of the fields in PV1 segment are optional, except those listed in table 3.1-2(immediately below, insert cross reference). See sec. XXX for the list of all fields of thePV1 segment.
IHE profile - PV1 Segment
SEQ
2
19
51

LEN
1
250
1

DT
IS
CX
IS

OPT
R
C
C

TBL#
0004
0326

ITEM#
00132
00149
01226

Element Name
Patient Class
Visit Number
Visit Indicator

DRAFT

コメント [SS88]: Optionality
needs to be resolved
コメント [SS89]: Optionality
needs to be resolved

At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shallbe valued. Additional requirements for the presence of value in these fields may be
documented in regional or national appendices to the IHE Technical Framework.

コメント [SS90]: Optionality
needs to be resolved

The national requirements for Japan are…

コメント [SS91]: Optionality
needs to be resolved

Field PV1-51 Visit Indicator shall be valued with value “V” if the field PV1-19 Visit
Number is present. May be omitted otherwise.

コメント [SS92]: Need todetermine if this text is needed, andif so, further clarification of Japaneserequirements.
書式変更 : 箇条書きと段落番号

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
71
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.10.4.1.2.4 ORC Segment
ORC segment conveys common order information.
Table XX.XX IHE Profile – ORC Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

1

2

ID

R

0119

00215

Order Control

2

22

EI

C

00216

Placer Order Number

削除: R

3

22

EI

C

00217

Filler Order Number

削除: O

5

2

ID

O

00219

Order Status

8

200

EIP

O

00222

Parent

15

26

0038

DRAFT

TS

C

00229

Order Effective Date/Time

削除: Place

削除: 9
削除: 26
削除: TS
削除: R
削除: 00223

Field ORC-1 Order Control must be valued as “CA” or “DC”

削除: Date/Time of Transaction

If the Order Placer sent the original order, field ORC-2 Placer Order number is used to
identify the parent order and the filler order number shall not be present. If the TMS
placed the parent order, the Filler Order number shall be used. If the Order Placer sent theoriginal order field ORC-3 Filler Order number shall not be present.

削除: 16

Field ORC-5 Order Status shall not be present.
Field ORC--8 Parent shall not be present.

Field ORC-15 Order effective Date/Time shall determine if a child order may still be
performed when this parent order is discontinued.

... [47]

削除: Field ORC-2 Placer Order
Number is used to identify the parent
order.
Field ORC-3 Filler Order number
shall not be present.

The action to be performed in the OMG message is defined by the Order Control code passed
as part of the message. HL7 defines a number of Order Control codes.
The order control codes below shall be supported.
Supported Order Control Codes

Value
CA

Description
Cancel order request

DC

Discontinue Order request

書式変更 : 箇条書きと段落番号
削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
72
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

3.10.4.1.2.5 OBR Segment
Table XX.XX IHE Profile – OBR Segment
SEQ

LEN

DT

OPT

TBL#

ITEM#

Element Name

1

4

SI

O

00237

Set ID – OBR

2

22

EI

R

00216

Placer Order Number

3

22

EI

O

00217

Filler Order Number

4

250

CE

R

00238

Universal Service Identifier

Field OBR-4 Universal Service Identifier shall be populated with a JJ1017 code specific
to radiation oncology.

DRAFT

Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in thefollowing table contain the same information.

Identical Element Mappings between ORC and OBR Segments
Element Name

ORC Segment Element

OBR
Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

書式変更 : 箇条書きと段落番号

3.10.4.1.2.6 Expected Actions
In the Enterprise Schedule Integration profile, an OP generally issues the parent order andgenerally issues any cancellation of that order. This Unsolicited Cancel Radiotherapy
Parent Order reverses the issuer and receiver of the Cancel Radiotherapy Parent Ordermessage.
After receiving the OMG message with the order status code “CA”, the Order Placer
shall discard the record of the parent order. If the TMS has already scheduled thetreatment deliveries (child orders) corresponding to this parent order, it has to perform

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
73
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
Transaction RO-ESI-04 Cancel Radiotherapy Delivery Child Order (see sec. X.XX) to
notify the OP of child order cancellation.
TMS shall not cancel parent order that has already been started, i.e., the one for which
TMS transmitted the “In-Progress” status (see sec. X.X.X), or for which one or more“Completed” status transactions have been performed.
If OP has “IN-PROGRESS” status of the parent order, OP shall not accept parent ordercancellation and perform acknowledgment with an error.
If the Parent Order status is in “IN PROGRESS”, TMS will utilize the OMG message
with the control code of DC.
When the Order Placer receives a message to discontinue the order, the Order Placershould expect to receive RO-ESI-04 Cancel Radiotherapy Delivery Child Ordertransactions to discard the remaining related child order(s). The TMS is responsible for
issuing the Cancel Radiotherapy Delivery Child Order messages.

DRAFT

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
74
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________

4 Open Issues
1. Should we follow IHE-RAD for putting the national Japanese extension (e.g. message
header MSH-16-18) into a separate volume? [Note: the current draft includes
Japanese extensions within the document.]
2. Should first example of HL7 segments include all fields or just profile-specific fields?
[Draft includes all].
3. Patient registration. Current draft states ADT functions. Alternative: To state: “As apre-requisite the patient administration must have taken place beforehand. Please see
IHE-RAD rev8 for details with the exception that HL7 version 2.5 is required.”
4. Should the profile mandate TQ1 when start date/time is required? [Current draft
requires it].
5. PID-18 Account number PV1-19 Visit Number and PV1-51 Visit Indicator: Need todecide whether to include as conditional or required.
6. Filler and Pacer Order Number: Should we alternatively use filler or placer ordernumber depending on whether the placer or filler places the order? [This is what thedraft uses.].

DRAFT

7. Other items may need to be represented the OBX for parent order: e.g. site, technique,modality, fraction, others? Additional ones may be needed on the child order? Shall
we specify each one? [The current draft specifies treatment intent and nominal doseand nothing else.]
8. Should we be using hard-coded code representation for these OBX field codes?
[Current draft has nominal dose and treatment intent hard-coded].
9. Should DICOM attributes when known be mentioned in this document? Should they
be required or recommended?
10. We have examples for order parent OBX. Shall we provide segment examples within
scope of the profile or separately?
11. JJ1017 needs to completed and reviewed and explained.
12. IHE-RAD r8 v2 Table B-1 lists HL7-DICOM mapping. It would appear thatmapping of OBR-34 Technician to DICOM Scheduled Performing Physician Name,might apply to the new child order.
13. Should child order status support a separate discontinue order transaction? None of
the known TMS systems support this action. [Draft has DC included].
14. Cancel parent order, order effective date/time. What are the conditions under which
this would happen? Does the HIS have a special date/time when an order is to beconsidered cancelled? Proposal: to remove (Jeff). Draft still has].

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
75
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSIHE-J RO Supplement Technical Framework Enterprise Schedule Integration: Draft________________________________________________________________________
15. Need to insert use case role and interaction diagrams, complete all references.

書式変更 : 箇条書きと段落番号

DRAFT

削除: 04/9/2009
削除: 03/12/2009___________________________________________________________________
76
Draft

05/12/2009 Copyright ©2008-2009: ASTRO, AAPM, RSNA, HIMSSページ 26: [1] 削除

Jeff West

Element Name

2009/03/13 18:08:00

ORC Segment Element

Placer Order Number

ORC-2

OBR
Segment
Element
OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

ページ 31: [2] 削除

Jeff West

2009/03/05 9:51:00

ORG Success
General Order Message

ORG

Chapter in
HL7 2.5(Success)
MSH

Message Header

2

MSA

Message Acknowledgement

2

ORG

General Order Message

Chapter in
HL7 2.5

MSH

Message Header

2

MSA

Message Acknowledgement

2

ERR

Error

2

(Error)ページ 31: [3] 削除

Josia Kammler

2009/03/02 9:19:00

Alternatively, the following could be required by the HIS
SEQ
LEN
DT
OPT TBL# ITEM#
3
250
CX
R
00106
5
250
XPN
R
00108
7
26
TS
R2
00110

Element Name
Patient Identifier List
Patient Name
Date/Time of Birth

8

1

IS

R

00111

Administrative Sex

11
18

250
250

XAD
CX

R2
C

00114
00121

Patient Address
Patient Account Number[JW1]

ページ 31: [4] コメント [JW21]

0001

Jeff West

IHE profiles generally specify the origin of this patient identifier. This is done in the patient demographictransactions and referred to here. It is generally the MPI.

ページ 32: [5] 削除

2Jeff West

22

EI

O

ページ 32: [6] 削除

4

00216

Placer Order Number

Josia Kammler

22

EI

C

00218

ページ 32: [7] 削除

6

2009/03/05 10:38:00

2009/03/02 9:40:00

Placer Group Number

Josia Kammler

1

ID

O

ページ 32: [8] 削除

0121

00220

2009/03/02 8:58:00

Response Flag

Josia Kammler

2009/03/02 8:58:00

9

26

TS

R

00223

Date/Time of Transaction

10

250

XCN

O

00224

Entered By

11

250

XCN

O

00225

Verified By

12

250

XCN

O

00226

Ordering Provider

13

80

PL

O

00227

Enterers Location

14

250

XTN

O

00228

Callback Phone Number

15

26

TS

O

00229

Order Effective Date/Time

16

250

CE

O

00230

Order Control Code Reason

ページ 33: [9] 削除
1

4

Josia Kammler
SIO

ページ 33: [10] 削除

00237

2009/03/02 8:57:00
Set ID – OBR

Jeff West

2009/03/05 17:43:00

5

2

ID

B

00239

Priority – OBR

6

26

TS

B

00240

Requested Date/Time

7

26

TS

O

00241

Observation Date/Time #

8

26

TS

O

00242

Observation End Date/Time #

9

20

CQ

O

00243

Collection Volume *

10

250

XCN

O

00244

Collector Identifier *

11

1

ID

O

00245

Specimen Action Code *

12

250

CE

O

00246

Danger Code0065

ページ 33: [11] 削除

Jeff West

2009/03/05 17:44:00

14

26

TS

B

00248

Specimen Received Date/Time *

15

300

SPS

B

00249

Specimen Source

16

250

XCN

O

00226

Ordering Provider

17

250

XTN

O

00250

Order Callback Phone Number

18

60

ST

O

00251

Placer Field 1

19

60

ST

O

00252

Placer Field 2

20

60

ST

O

00253

Filler Field 1 +

21

60

ST

O

00254

Filler Field 2 +

22

26

TS

C

00255

Results Rpt/Status Chng - Date/Time +

23

40

MOC

O

00256

Charge to Practice +

24

10

ID

O

0074

00257

Diagnostic Serv Sect ID

25

1

ID

C

0123

00258

Result Status +

26

400

PRL

O

00259

Parent Result +ページ 33: [12] 削除
28

250

Josia Kammler
XCN

O

ページ 33: [13] 削除

00260

2009/03/02 8:57:00
Result Copies To

Josia Kammler

30

20

ID

O

31

250

CE

32

200

33

0124

2009/03/02 8:57:00

00262

Transportation Mode

O

00263

Reason for Study

NDL

O

00264

Principal Result Interpreter +

200

NDL

O

00265

Assistant Result Interpreter +

34

200

NDL

O

00266

Technician +

35

200

NDL

O

00267

Transcriptionist +

36

26

TS

O

00268

Scheduled Date/Time +

37

4

NM

O

01028

Number of Sample Containers *

38

250

CE

O

01029

Transport Logistics of Collected Sample *

39

250

CE

O

01030

Collector's Comment *

40

250

CE

O

01031

Transport Arrangement Responsibility

41

30

ID

O

0224

01032

Transport Arranged

42

1

ID

O

0225

01033

Escort Required

43

250

CE

O

01034

Planned Patient Transport Comment

44

250

CE

O

0088

00393

Procedure Code

45

250

CE

O

0340

01316

Procedure Code Modifier

46

250

CE

O

0411

01474

Placer Supplemental Service Information

ページ 34: [14] 削除

Jeff West

Element Name

2009/03/13 18:10:00

OBR
Segment
Element

ORC Segment Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

ページ 34: [15] 削除
1

4Josia Kammler
SI

O

01627

ページ 34: [16] 削除
2

20

2009/03/02 9:00:00
Set ID - TQ1

Jeff West
CQ

OR2

ページ 34: [17] 削除

2009/03/05 10:52:00
01628

Quantity

Josia Kammler

3

540

RPT

O

4

20

TM

5

20

6

20

01629

Repeat Pattern

O

01630

Explicit Time

CQ

O

01631

Relative Time and Units

CQ

O

01632

Service Duration

ページ 34: [18] 削除

0335

2009/03/02 9:00:00

Josia Kammler

8

26

TS

O

9

250

CWE

O

10

250

TX

11

250

12

2009/03/02 9:00:00
01634

End date/time

01635

PriorityO

01636

Condition text

TX

O

01637

Text instruction

10

ID

C

01638

Conjunction

13

20

CQ

O

01639

Occurrence duration

14

10

NM

O

01640

Total occurrence's

ページ 37: [19] 削除

0485

0427

Jeff West

2009/03/05 17:06:00

The following is an optional repeating segment that is required if nominal dose and /ortreatment intent are known. If this segment is present, it is mandatory to follow certain
rules (see section XX).
[JW2]OMG

General Order Message

Chapter inHL7 2.5
7

Observation/Result

OBX

ページ 37: [20] 削除

Josia Kammler

2009/03/02 10:24:00

All (ORC, OBR) segment pairs sent in the Create Radiotherapy Child Order message
shall be present in the Modify Radiotherapy Child Order message, not only the pairs
introducing a change.

ページ 37: [21] 削除

Jeff West

2009/03/05 17:19:00

Any other elements in the OBR or ORC segments may be changed when the Order
Control Code = XO.

ページ 40: [22] 削除

Jeff West

2009/03/06 9:50:00

OBX Segment
The OBX segment will be used to transmit

Prescribed dose for the fraction, Delivered

Dose for the fraction,Total delivered dose (for the parent order), Number of performed
fractions (from children of the parent order), Number of planned (total) fractions (from theparent order). See Appendix X.X.X for detail regarding the OBX contents.

There may be 1 or more OBX segments.

Table XX.XX IHE Profile – OBX Segment[JW4]SEQ
11

LEN

DT
1

ID

ページ 40: [23] コメント [JW40]

OPT

TBL#

ITEM#

R

0085

00579

Element Name
Observation Result Status

Jeff West

Where is “resource” passed? As currently constituted, the only information on the child order is:
Date/time
Procedure code

Clinical observations
If we want to add other data, we need to add that to the create child order transaction.

See Table B-1. HL7 Order Mapping to DICOM MWL in IHE-RAD ref8 v2 for physician,location or whatever we can use.

ページ 40: [24] 削除

Jeff West

2009/03/06 11:05:00

is expected to perform the following actions based on the value of the field ORC-1
Order Control Code:
XO – Child Order-related information (including scheduled date/time and/or
resource[JW5]) has been changed. The TMS shallページ 44: [25] 削除

52Jeff WestID

R2[JK7][JW8]

ページ 44: [26] 削除

2009/03/12 9:25:00

0038

00219

Order Status

Jeff West

2009/03/06 17:00:00

4

250

CE

R

00238

Universal Service Identifier

27

200

TQ

B

00221

Quantity/Timing

29

200

EIP

R

00261

Parent [JW9]ページ 45: [27] 削除

Jeff West

Element Name

ORC Segment Element

2009/03/13 18:10:00

OBR
Segment
Element

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

ページ 48: [28] 削除{OBX}

Josia Kammler

Observation/Result

2009/03/02 16:01:00

7

ページ 50: [29] 削除

Jeff West

2009/03/06 17:05:00

7

200

TQ

B

00221

Quantity/Timing

8

200

EIP

R

00222

Parentページ 50: [30] 削除

Jeff West

2009/03/06 17:11:00

4

250

CE

R

00238

Universal Service Identifier

27

200

TQ

B

00221

Quantity/Timing

29

200

EIP

R

00261

ParentField OBR-4 Universal Service Identifier shall be populated with a JJ1017 code
[JW10]specific to radiation oncology.
Per the HL7 Standard, IHE recommends that the fields in ORC and OBR segments given in
the following table contain the same information.

Identical Element Mappings between ORC and OBR Segments
Element Name

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

ページ 55: [31] 削除

4

22Josia Kammler

EI

C

ページ 55: [32] 削除

1

ID

O

7

200

TQ

B

ページ 55: [33] 削除

200

26

Placer Group Number

0121

2009/03/02 16:15:00

00220

Response Flag

00221

Quantity/Timing

Jeff West

EIP

O

ページ 55: [34] 削除

9

00218

2009/03/02 16:15:00

Josia Kammler

6

8

OBR
Segment
Element

ORC Segment Element

00222

Josia Kammler

TS

R

00223

2009/03/08 23:24:00

Parent2009/03/02 16:15:00

Date/Time of Transaction

10

250

XCN

O

00224

Entered By

11

250

XCN

O

00225

Verified By

12

250

XCN

O

00226

Ordering Provider

13

80

PL

O

00227

Enterers Location

14

250

XTN

O

00228

Callback Phone Number

15

26

TS

O

00229

Order Effective Date/Time

ページ 56: [35] 削除
1

4Josia Kammler
SIO

ページ 56: [36] 削除

00237

2009/03/02 16:14:00
Set ID – OBR

Josia Kammler

2009/03/02 16:14:00

4

250

CE

R

00238

Universal Service Identifier

5

2

ID

B

00239

Priority – OBR

6

26

TS

B

00240

Requested Date/Time

7

26

TS

O

00241

Observation Date/Time #

8

26

TS

O

00242

Observation End Date/Time #

9

20

CQ

O

00243

Collection Volume *

10

250

XCN

O

00244

Collector Identifier *

11

1

ID

O

00245

Specimen Action Code *

12

250

CE

O

00246

Danger Code

13

300

ST

O

00247

Relevant Clinical Information

14

26

TS

B

00248

Specimen Received Date/Time *

15

300

SPS

B

00249

Specimen Source

16

250

XCN

O

00226

Ordering Provider

17

250

XTN

O

00250

Order Callback Phone Number

18

60

ST

O

00251

Placer Field 1

19

60

ST

O

00252

Placer Field 2

20

60

ST

O

00253

Filler Field 1 +

21

60

ST

O

00254

Filler Field 2 +

22

26

TS

C

00255

Results Rpt/Status Chng - Date/Time +

23

40

MOC

O

00256

Charge to Practice +

24

10

ID

O

0074

00257

Diagnostic Serv Sect ID

25

1

ID

C

0123

00258

Result Status +

26

400

PRL

O

00259

Parent Result +ページ 56: [37] 削除
28

250

0065

Josia Kammler
XCN

O

00260

2009/03/02 16:14:00
Result Copies To

ページ 56: [38] 削除
29

200

Jeff West
EIP

O

ページ 56: [39] 削除

2009/03/08 23:17:00
00261

ParentJosia Kammler

30

20

ID

O

31

250

CE

32

200

33

00262

Transportation Mode

O

00263

Reason for Study

NDL

O

00264

Principal Result Interpreter +

200

NDL

O

00265

Assistant Result Interpreter +

34

200

NDL

O

00266

Technician +

35

200

NDL

O

00267

Transcriptionist +

36

26

TS

O

00268

Scheduled Date/Time +

37

4

NM

O

01028

Number of Sample Containers *

38

250

CE

O

01029

Transport Logistics of Collected Sample *

39

250

CE

O

01030

Collector's Comment *

40

250

CE

O

01031

Transport Arrangement Responsibility

41

30

ID

O

0224

01032

Transport Arranged

42

1

ID

O

0225

01033

Escort Required

43

250

CE

O

01034

Planned Patient Transport Comment

44

250

CE

O

0088

00393

Procedure Code

45

250

CE

O

0340

01316

Procedure Code Modifier

46

250

CE

O

0411

01474

Placer Supplemental Service Information

ページ 56: [40] 削除

0124

2009/03/02 16:14:00

Jeff West

2009/03/13 18:11:00

Identical Element Mappings between ORC and OBR Segments
Element Name

Placer Order Number

ORC-2

OBR-2

Filler Order Number

ORC-3

OBR-3

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

ページ 60: [41] 削除

5

2Jeff West

ID

O

ページ 60: [42] 削除

9OBR
Segment
Element

ORC Segment Element

26

0038

00219

Josia Kammler

TS

R

00223

2009/03/12 9:48:00

Order Status

2009/03/02 16:21:00

Date/Time of Transaction

ページ 60: [43] 削除

8200

Jeff West

EIP

O

ページ 60: [44] 削除

16

00222

Josia Kammler

250

O

CE

ページ 66: [45] 削除

00230

Josia Kammler

2009/03/08 23:46:00

Parent2009/03/02 16:21:00

Order Control Code Reason

2009/03/02 16:27:00

9

26

TS

R

00223

Date/Time of Transaction

12

250

XCN

R

00226

Ordering Provider

15

26

TS

O

00229

Order Effective Date/Time

16

250

CE

O

00230

Order Control Code Reason

ページ 67: [46] 削除

Josia Kammler

Quantity/Timing

ORC-7

OBR-27

Parent

ORC-8

OBR-29

ページ 72: [47] 削除

16

2009/03/02 16:31:00

250

Josia Kammler

CE

O

00230

2009/03/02 16:36:00

Order Control Code Reason