IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

日本語訳版_________________________________________________________________________________________

1
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

目次
前書き.......................................................................................................................................4
解決済みの問題.........................................................................................................................4
第一巻－
30

プロファイル...........................................................................................................5

収集後業務流れプロファイル（Post-Acquisition Workflow Profile） ...............................5

付録 ........................................................................................................................................28
アクタ定義のまとめ................................................................................................................28
トランザクション定義のまとめ ..............................................................................................28
用語集.....................................................................................................................................29
第二巻－

トランザクション ..............................................................................................30

第三巻－

トランザクション ..............................................................................................32

4.80 UPS 作業項目の生成 [RAD-80]（Create UPS Workitem） ....................................................32
4.81 UPS 作業項目の問合わせ[RAD-81] （Query UPS Workitems） ............................................35
4.82 UPS 作業項目の取得要求[RAD-82]
4.83 UPS 作業項目内容取得（Claim UPS Workitem）...........................................40[RAD-83] （Get UPS Workitem Contents） ..................................43

4.84 UPS 作業項目の更新 [RAD-84] （Update UPS Workitem）..................................................45
4.85 UPS 作業項目完成 [RAD-85] （Complete UPS Workitem）................................................48
4.86 UPS 通知受信予約管理 [RAD-86] （Manage UPS Subscription） .......................................50
4.87 UPS 通信の通知 [RAD-87] （Send UPS Notification） ..........................................................53
4.88 UPS 作業項目キャンセル要求 [RAD-88] （Request UPS Workitem Cancelation） .............55
4.89 アプリケーション開始 [RAD-89] （Start Application） ...........................................................57
4.90 アプリケーション停止 [RAD-90] （Stop Application）..............................................................60
4.91 アプリケーション前面配置 [RAD-91] （Bring Application Front） .........................................62
4.92 業務開始 [RAD-92]（Start Task）..............................................................................................64
4.93 業務詳細取得 [RAD-93]（Get Task Details）............................................................................68
4.94 業務データ取得 [RAD-94]（Get Task Data） ............................................................................72
4.95 業務状態通知 [RAD-95]（Notify Task Status） ........................................................................75
4.96 業務結果通知 [RAD-96]（Notify Task Results） ......................................................................77
4.97 業務結果取得 [RAD-97]（Get Task Results） ...........................................................................79
4.98 業務完了通知 [RAD-98]（Notify Task Complete）...................................................................82
4.99 業務終了 [RAD-99]（Finalize Task） .........................................................................................84
4.100 業務の取り消し [RAD-100]（Cancel Task） .............................................................................86
4.101 アプリケーション一時停止 [RAD-101]（Suspend Application） ..............................................90_________________________________________________________________________________________

2
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________
4.102 アプリケーション再開 [RAD-102]（Resume Application）.......................................................92
付録 W: 生成中の UPS 作業項目属性値入力..................................................................................96
付録 V:

UPS と結果生成物の複合 IOD の整合 ............................................................................98

日本語訳
日本 IHE 協会 放射線企画委員会 本田憲業
2013/4/8_________________________________________________________________________________________

3
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

前書き
本書は、放射線テクニカルフレームワーク11版の補遺です。それぞれの補遺はパブリックコメ
ントを受けたのち、試験実装をテクニカルフレームワーク書に組み入れる前に行っています。
この補遺は2012年6月15日に試験実装として出版され、以降のIHEコネクタソンでの試験用に使用できます。この補遺は、試験結果にもとづき修正されます。試験に成功すると、これは放射線テクニカルフレームワークに組かまれます。コメントを歓迎しますので、
http://www.ihe.net/radiology/radiologycomments.cfmに送ってください。

解決済みの問題（略）_________________________________________________________________________________________

4
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

第一巻－

プロファイルVolume 1 - Profiles
30

収集後業務流れプロファイル（Post-Acquisition Workflow Profile）

QAの実施、追加の画像再構成、コンピュータ支援検出、臨床解析アプリケーション、3次元表
面画像の様な画像処理または視覚化のような、典型的な後処理段階を予定し、協働させ、進捗を監視する必要を、収集後業務流れプロファイルは扱います。このような作業項目を含む業
務一覧を生成し、問い合わせ可能にしたうえで、作業項目の選択を可能とし、結果オブジェク
トの進捗状態を、業務執行システムから業務管理システムへ戻し、関心のある他のシステムへ通知します。
個々の作業項目は、最初は行うべき作業を記述でき、必要なあるいは割り当てられた資源を記述でき、期待される予定、処理パラメータ、および、特定された入力への参照を記述することもできます。作業が行われると、作業項目の内容が更新され、実施された作業が記述され、使用された資源と出力への参照が作成されます。
収集後業務流れプロファイルは、予定業務流れ(SWF)統合プロファイルの続きであり、スタディ・オーダー・検査を同じようにモデル化しています(RAD TF-1:3.4.1)。
収集後業務流れプロファイルは、ホスト役システム(例えば、PACS、ワークステーション、あるいは、臨床アプリケーションサーバ）への配下処理アプリケーションの統合も扱います。作業項目に記述された業務は、配下アプリケーション、PAWFアクタ、トランザクション、内容モジュールで実行可能です。
図30.1-1に、PAWFプロファイルに直接含まれるアクタとこれらの間の関連するトランザクションを示します。状況によっては、他の関連するプロファイルへ参加しているために間接的に含まれる他のアクタは、点線で示されます。一括化が必須のアクタは接合した箱で示されます。

_________________________________________________________________________________________

5
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

図 30.1-1: PAWF アクタ図
表 30.1-1 に、PAWFに直接含まれる個々のアクタに対するトランザクションを示します。このプロファイルが可能と主張するには、アクタの実装では、必須のトランザクション("R")が実行できねばならず、オプションのトランザクション("O")は使用できて良いです。アクタの一括化は
30.3節に詳述されます。

_________________________________________________________________________________________

6
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

表 30.1-1: PAWFプロファイル - アクタとトランザクション_________________________________________________________________________________________

7
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)___________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

注: 1. 作業項目実施役は、該当の作業項目で作成あるいは使用されるタイプのオブジェ
クトの取得と保存トランザクションのみが必須です。
2. 配下アプリケーションは作業の実行にデータが必要なら、業務データ取得（Get Task
Data）のみ使用可能であれば良いです。もし保存あるいは通信されるデータを生成するな
ら、業務結果通知（Notify Task Result）と業務結果取得（Get Task Result）のみが必須です。
3. アプリケーションにはAPIの装備が必須ですが、一時中止や再開の要求に応えるのは、必須ではありません。
30.1.1 アクタ記述とアクタ要求項目
規範的な要求事項は第2および3巻 (トランザクション）にあります。一部の統合プロファイルにはトランザクション、データ、および・または、振る舞いを連携するために必須の要求事項があります。これらのプロファイルの要求事項はこの節で、規範的要求("SHALL"1)と、記されています。この節の多くのトランザクションは、DICOM Unified Procedure Step SOP Classes に属します。
このテクニカルフレームワークでは、このSOPクラスが使用可能で、DICOM PS 3.3, PS 3.4とPS
3.17に記されたようにアクタを実装している、ものとしています。IHEが上記の様に定める要求項目でDICOMの範囲外にあるものは、明白に特定されます。
このテクニカルフレームワークのアクタの簡便な定義は、IHEテクニカルフレームワークの全般
的紹介部のアクタ定義まとめを参照してください。
以下のアクタは、追加の特定の詳細を有しています。

30.1.1.1 作業項目管理役 （Workitem Manager Actor）

1

訳者注： 本書では「ねばなりません」と訳します。

_________________________________________________________________________________________

9
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

作業項目の生成
作業項目管理役は、その内部論理にしたがって、作業項目を生成することが許されています（さらに、ある実装では、新しい作業項目の源にもなれます）。
作業項目管理役は、作業項目を内部的に生成するときは、UPS作業項目生成トランザクション（Create UPS Workitem [RAD-80]）を使用するとはされていませんが、作成された作業項目は、[RAD-80] トランザクション通信文の意味に合致し、予期された動作をおこない、記載された
保安面考慮に合致しなければなりません。
入力可用性
多くの後処理作業段階は、入力インスタンス（画像のほか、SR書類、切り出し物のようなインスタンス）に働きます。UPS作業項目は入力情報順列（Input Information Sequence(0040,4021)）と入力準備状態（Input Readiness State (0040,4041)）を含んでおり、それぞれ、作業項目の入力一覧として使用されたり、一覧が完全か、取得可能か、を示したりします。
UPS作業項目生成（Create UPS Workitem）トランザクション [RAD-80]は、入力準備状態（Input Readiness State）が"READY"でないと作業項目を生成しません。”READY”は入力情報順列（Input Information Sequence）のリストが完全で、挙げられたインスタンスが使用可能であることを示します。
作業項目管理役が自身で内部論理に従い生成する作業項目について、入力インスタンスの可用性をきめるのは、作業項目管理役の責任です。作業項目管理役が使用する方法は、入力情報順列の一覧を使用可能にする方法に依拠します。
DICOM取得では、一覧に挙げたインスタンスの可用性を確認するため、作業項目管理役は、
画像可用性問合わせ（Images Availability Query）とインスタンス可用性通知（Instance
Availability Notification）トランザクションを可能とせなばなりません。
注: 作業項目管理役が画像管理役・画像保管庫と一括されているときは、可用性の判定に内部論理を使用して良いですが、インスタンスが別のシステムに保存されることがあり得るので、n内部論理に加えて、可用性のトランザクションを使用可能であることが要求されます。UPS入力
情報順列（UPS Input Information Sequence）内の、XDS取得や媒体取得は、このプロファイル
では扱いません。
作業項目管理役が入力可用性を監視しつづけて、もしいくつかのインスタンスが使用不能となったとき、入力準備状態（Input Readiness State）を"READY"から"UNAVAILABLE"に変えることは許されていますが、期待される動作ではありません。
負荷均衡
作業項目管理役の動作内部論理の記載はこのプロファイルの範囲外です。作業項目管理役が使用できるツールについては、予定ステーション名コード順列（Scheduled Station Name
Code Sequence (0040,4025)）の設定により、予定作業項目を特定のシステムに割り付け、再割り付けができます。取得要求済みだが未完成、あるいはキャンセルされた作業項目の実行済_________________________________________________________________________________________

10
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

ステーション名コード順列（Performed Station Name Code Sequence (0040,4028)）を調べると、他の作業項目実施役の作業負荷を知ることができます。
作業項目実施役は、他のシステムに特異的に割り当てられた作業項目の取得を要求することは禁じられているので、不合理な時間にわたって取得要求されない、あるいは、キャンセルされない作業項目を他のシステムに再割り付けするのは、作業項目管理役の責任です。
業務一覧維持作業項目管理役の実装者は、DICOM UPS仕様を注意深く読む必要があります。作業項目
実施役が業務不能となる可能性や、削除ロックを解除できない監視役の可能性のような実際的な問題が通知され、作業項目管理役が応急措置をとる許可を与えられることが必要です。
30.1.1.2 作業項目実施役 （Workitem Performer Actor）
実行システムの特定取得要求した作業項目で作業を始める前に、作業項目実施役は実行済ステーション名コード
順列（Performed Station Name Code Sequence）を、RAD TF-3: 4.84.4.1.2.1に記さされた様に、自己を特定してもらうために、更新しなければなりません。
出力情報
DICOM最終段階要求項目（final state requirement）によれば、作業項目が”COMPLETED”
あるいは "CANCELED"状態に移行する前に、作業項目実施役は作業項目の出力情報順列（Output Information Sequence (0040,4033)）を更新して、取得すべき全てのインスタンスの一覧を更新せねばなりません。
ある想定業務手順では、作業項目実施役が出力をすべて実際に取得源に保存するまで待つのは、作業項目完了情報のタイムリー性を不必要に低下させ、業務流れを遅くすることがあります。従って、実際に保存が完了する前に、作業項目実施役が、出力情報順列（Output
Information Sequence）の一覧を作成し、作業項目を”COMPLETED” あるいは"CANCELED"状態に移行できるようにすることに注意してください。しかし、作業項目実施役
は、一覧に挙げた全てのインスタンスを取得可能としてはなりません。これは、DICOM撮影済
検査段階（Modality Performed Procedure Step）とは異なっています。後者では、取得可能か否かにかかわらず、全てのインスタンスが含まれます。
生成されるインスタンス
作業項目実行の結果生成されたDICOMインスタンスのある種の属性の値は、作業項目の内容と合致せねばなりません。特定の要求事項は、RAD TF-3: 付録Wを参照してください。
30.1.1.3 ホスト役システムアクタ （Hosting System Actor）
配下アプリケーションの選択 Hosted Application Selection
ホスト役システムは、複数の配下アプリケーションを含むと思われます。ホスト役システムは与_________________________________________________________________________________________

11
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

えられた作業項目にどの配下アプリケーションが必要か決めねばなりません。この決定はホスト役システムが作業項目に取得要求を出すか、もし取得要求を出したら、その作業項目を完成させるのにどのアプリケーションを使うかを決めます。
これには、施設特有のコードやパターンについて、作業項目生成役と、一括化されたホスト役
システムとの間で、合意がいります。
典型的には、予定作業項目コード順列（Scheduled Workitem Code Sequence (0040,4018)）の作業項目コードの一覧を定めるか、適用します。これは、作業項目に使用されるアプリケーショ
ンを特定する程度まで詳細なこともありますし、単に、行うべき一般的業務を定めるだけのこともあります。
予定ステーションクラスコード順列（Scheduled Station Class Code Sequence (0040,4026)）で使用されるステーションクラスコードを施設で作成したり適用したりします。これはまた、特定の配下アプリケーションを特定する程度まで詳細なこともありますし、単に、もっと一般的であったり、削除されたりします。
予定処理パラメータ順列（Scheduled Processing Parameters Sequence(0074,1210)）内の一個以上のパラメータ内容は、どの配下アプリケーションが作業項目に適切かに影響することがあります。
ホスト役システムは、作業項目コード、ステーションクラスコード、および、一個以上の処理パラ
メータのパターン一致、のあらゆる組み合わせとホスト役システムが抱える配下アプリケーショ
ンとの対応付けが、設定可能で無ければなりません。ホスト役システムはこのような対応付けを複数持つことができねばなりません。
30.2 PAWFアクタのオプション PAWF Actor Options
この統合プロファイルに選択可能なオプションを、それが適応されるアクタとともに、表 30.2-1に示します。オプション間の依存が注に記されます。
表 30.2-1: PAWF - アクタとオプション

30.3 一括化が必要なPAWFアクタ （PAWF Actor Required Groupings）_________________________________________________________________________________________

12
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

他のアクタと一括されねばならないアクタを、この節に挙げます。一括化されるアクタはこのプ
ロファイルからのことも、異なった領域やプロファイルからのこともあります。このプロフィイルのアクタ（列 1）は、このプロファイルに必須のトランザクション全てに加え、表に挙げられた、一括化プロファイル・アクタに必須のトランザクション（列2）も実装しなければなりません。
Section 30.7 節には、実装者の興味を引くオプションの一括化が記載されています。
表 30.3-1: PAWF - アクタと必須の一括化

注 1:
一括化は双方向的ではありません。ホスト役システムは作業項目実施役と一括化
されねばなりません。これにより、ホスト役システムは作業項目を取得し、完了を配下アプリケーションのために、通知できます。作業項目実施役には配下アプリケーションを使うことなく、独自に作業項目を完成するものもあるので、作業項目実施役はホスト役システムと一体化される必要はありません。作業項目
実施役や他のシステムは、作業項目に追跡されない、DICOMアプリケーションホスティングを業務の実行に使うこともできます。この使用法はこのプロファイルの範囲外です。

実装パターン－作業項目管理 （Implementation Patterns – Workitem Management）
このプロファイルは、予期される数個の実装パターンとともに設計されています：・ 作業項目管理役はRISに実装され（すなわち、部門システム・オーダ実行役と一括化されます）、監視役はPACSに実装され（すなわち、画像管理役・画像保管庫と一括化されます）、よく看視され業務流れを促進させるようにします（たとえば、作業
項目生成時に入力の事前の取得、あるいは事前の押し出し）。
・ 作業項目管理役はPACSに実装され（すなわち、画像管理役・画像保管庫と一括化されます）、監視役はRISに実装され（すなわち、部門システム・オーダ実行役と一括化されます）、後処理の進行と後処理段階の出力を看視したり、おそらく、この情報を元にレポート業務を予定したり変更したりできるようにします。
・作業項目管理役は、別の後処理協調システムに実装されます。RISとPACSの両者
または、一方が作業項目生成役を実装し、業務一覧上の作業項目を直接加えた
り、変更したりします。
_________________________________________________________________________________________

13
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

一個以上の作業項目監視役が一施設に装備される可能性があります（たとえば、PACSとRISの両方がこの様な機能を提供します）。これは、作業項目実施役と監視役を作業項目管理役に向かせる様設定して扱えます。作業項目管理役は作業項目生成役を実装して、必要に応じて、もう一つの作業項目管理役に業務を代表させることも考えられます。代わりに、管理役の間で業務を分割し、一つの一セットの検査コードを割り当て、残りをもう一方の管理役が扱う様に設定することもできます。検査が二つの間で重なったりせず、相補的であるのを確保するのは、施設の責任です。このパターンは本プロファイルではこれ以上議論しません。

実装パターン － 作業項目生成 （Implementation Patterns – Workitem Creation）
このプロファイルは、相互排他的でない、予期される、数個の実装に沿って設計されています。
実装のそれぞれは自動的なことも、生成する作業項目を使用者が決めることもあります：・ 作業項目の生成は、作業項目生成役とは独立に、作業項目管理役により内部的に処理されます。
・ 作業項目生成役は、部門予定作成の内部論理に基づいて作業項目を生成する
RISに実装されます（すなわち、部門システム予定・オーダ実施役と一括化されます。
・ 作業項目生成役は、取得するデータに基づいて作業項目を生成する撮影装置に実装されます（すなわち、撮影装置と一括化されます）。
・ 作業項目生成役は、受け取るデータに基づいて作業項目を生成する画像管理役・画像保管庫に実装されます。ときには、作業項目生成役を実装するシステム
が、作業項目の進捗と完成を看視する監視役も実装することもあります。

30.4 PAWF 書類内容モジュール （PAWF Document Content Module）
適応できません。
30.5 PAWF概観 （PAWF Overview）
30.5.1 概念
収集後処理作業流れプロファイルと関連するトランザクションは一部、DICOM Unified
Procedure Step (UPS) サービスとSOP クラスに依存しています。読者は、関連する情報と以下の話題について、DICOM PS 3.17 Annex GGGを閲覧するよう推奨します。収集後処理作業
流れプロファイルはDICOM アプリケーション Hostingにも依存しています。読者は、関連する情報について、DICOM PS 3.17 Annex XXとDICOM PS 3.19を閲覧するよう推奨します。
押出業務流れと引寄業務流れ （Pull Work Flow and Push Work Flow）
効果的な業務流れの集積には多数のパターンがあります。このパターンの2つの重要な面は、作業項目をどこで管理するかと、作業項目実施役が作業せねばならない関連作業項目をい_________________________________________________________________________________________

14
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

かに知るか、です。
「引寄業務流れ」は、業務実施役が、作業項目を管理する中央システムに、検索フィルタを指定して（たとえば、本日予定されている心臓血管分析の業務）、業務一覧の問い合わせを行うものです。業務一覧を閲覧し、作業対象の作業項目を「取得要求」し、業務の完全な詳細を取得するため作業項目の内容を取得します（予定業務流れプロファイルの撮影装置作業項目一
覧の使用は、引寄せ作業の一型です）。下記の3D画像使用例は引寄業務の一例です。
「押出し業務流れ」は、作業項目を特定の実施役への割り付けを決定するシステムを含みます。
30.5.6 節に示すCAD使用例は、押出し業務流れの一例です。
DICOM UPSは、実施役が使用する出力を作成する他のシステムで、行われた業務通知の監視に基づいて、個々の実施役が自身で出力を生成することを、許しています。これによりいく
つかの興味ふかいパターンが可能となりますが、作業項目と複数システムの業務論理との分
配は、部門活動の設定と監視を困難にし得ます。これらの理由により、このプロファイルでは一個あるいは少数の作業項目管理役が作業項目と大部分の業務論理を中央集権化することを前提にしています。
通知受信予約 （Subscription-based Notification）
UPSは、作業項目の、たとえば、生成、変更、完成、キャンセルなどの、状態の通知を望むシス
テムを許容します。この通知は、下記の使用例に示される業務流れパターンでは、通常関連するトランザクションと交互に行われます。説明の簡易さと読みやすさのため、多くの使用例か
ら通知取得の機構は除かれ、通知受信予約使用例に示します。
作業項目のキャンセル （Cancelation of a Workitem）
作業項目実施役は作業項目自体をキャンセルできますが、UPSは他のシステムが作業項目キ
ャンセル要求を出すのを許します。キャンセル要求の通知は実行側のシステムへ送られますが、このシステムはこの通知に従うことも、従わないこともできます。もし、作業項目がキャンセルされると、通知受信予約をしているシステムもこの事実を受け取ります。キャンセルの例は別の使用例として示されますが、他のどの使用例とも組み合わせできます。
配下アプリケーション （Hosted Applicastions）
DICOM Part 19 は、配下アプリケーションのためにDICOMインスタンスを取得し保存するホスト役システムと配下アプリケーションとが交信するインターフェースを導入しました。取得後処理業務流れでは、自身が処理を行う代わりに作業項目実施役が適切な配下アプリケーションを立ち上げるのを許します。作業項目実施役は外部との業務流れ通信には責任を持ち続けます。これは、ホスト役システムと一体化された作業項目実施役のプロファイルに記されます。配下アプリケーション使用は別の使用例で示されますが、配下アプリケーション使用はどの使用
例にも適応できます。
以下の使用例は、画像を主な入出力とする作業項目を示します。
同じパターンは、切り出しオブジェクト、キー画像注釈、表示条件、構造化レポート、その他の_________________________________________________________________________________________

15
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

書類を入力あるいは出力として使う作業項目にも適応されます。
30.5.2

3D画像使用例 （3D View Use Case）

30.5.2.1 3D画像使用例の記述
撮影装置での検査（たとえば、心臓CT検査）の画像が撮影され再構成されます。再構成された画像は、画像切り出し、3次元画像と血管分析の後処理に使用されます。
この例では、画像管理役・画像保管庫からのインスタンス可用性通知（Instance Availability
Notification）をきっかけに、作業項目管理役が内部論理に基づいて作業項目が生成されます（たとえば、データを調べ、検査コードに従い後処理を予定します）。作業項目管理役は、作業
項目コード（行うべき業務を特定）と処理パラメータを設定し、作業項目の入力情報順列（Input
Information Sequence）内の再構成された画像セットの一覧を作成し、入力準備状況（Input
Readiness Status）を”READY”にします。
代わりの例（示しませんが）では、PACSまたはRISが作業項目生成役を実装し、MPPS通信文の内容やその他の情報に基づいて、代わりに作業項目生成（Create Workitem）通信文を送ります。
作業項目実施役は、自動機構あるいは使用者により、業務一覧を問い合わせ（引寄業務流れ）、選択した作業項目を取得要求し、重要な詳細（すなわち、入力一覧、処理コード、パラメ
ータなど）を得るために作業項目内容を取得し、インスタンスを取得して、業務を行い、出力を保存し、レポートを完成します。作業項目の状況あるいは・または出力に関心のあるシステム（たとえば、レポート業務流れ管理役や医事会計システム）が作業項目の進捗と出力を看視する方法の詳細については通知使用例（30.5.3節）をみてください。
30.5.2.2

3D 画像処理流れ （3D View Process Flow）_________________________________________________________________________________________

16
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

図 30.5.2.2-1: PAWFプロファイルでのProfile 3D画像処理流れ
30.5.3 通知使用例 （Notification Use Case）
30.5.3.1通知使用例説明
作業項目は予定され最終的に実行されます。監視役は作業項目の進捗と完成を看視し、出力を使用します。作業項目の生成を最初に要望したシステムがこれを行います。あるいは、計
器盤2、作業完成をまって活動すると期待されるシステム、たとえば、読影業務用に3次元画像を整頓してインスタンスの一覧に入れようとするレポート業務流れ管理役、がこれを行います。

2

訳者注： 原語は”dashboard”。メニュー項目のクリックで望みのアプリケーションを呼び出し時候ｄけいる様な、ユーザインターフェースを提供す機能です。

_________________________________________________________________________________________

17
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

この例では、監視役は作業項目管理役が管轄するインスタンスの全てに対する全般的通知受
信予約を使用します。特定のインスタンスに対する通知受信予約、あるいは、通知受信予約取り消しを行うこともできます。要求されてはいませんが、初回生成の通知に引き続いて作業
項目の詳細をここでは、取得する様に示されています。この時点で、監視役は作業項目が関心の対象か否か評価し、もし関心が無いなら、その作業項目の通知受信予約を取り消し、以後、通知を受けないようにします。以下の流れでは、監視役は通知受信予約の保持を選択します。
この例では、削除ロックを使用する監視役は、監視役が通知受信予約を取り消すまで、作業項目を削除しないように作業項目間利益に要求します。これにより、監視役に、作業項目が完成したあと、関心のある詳細情報、たとえば、作業項目実施役が生成したインスタンスの一覧
や実際に行った作業（作業は時に要望されたものとは異なる場合があります）を示すコードな
ど、を取得する時間的余裕が与えられます。
別の監視役は、削除ロックを使用せず、広範に通知受信予約を誓うことをもあります。この例では、監視役は、作業項目単位で、特定の興味ある作業項目に削除ロックを掛けるよう決めることができます。この例では、監視役のみが、実行された作業項目に削除ロックを掛けるられることを前提としています。これは、作業項目管理役は、監視役が作業項目の通知受信予約を取り消し、削除ロックを外したあとは、作業項目管理役は自由に作業項目を削除できることを意味します。もし、他の監視役が削除ロックを使っている場合は、その作業項目の通知受信予約を取り消すまで、待たねばなりません。結果オブジェクトの作用完了前の保存については、ここでは示しません。詳細は3次元画像使用例を見てください。監視役は生成された結果オブジェ
クトの詳細を利用でき、最後のUPS作業項目取得（Get UPS Workitem） を実行した時にどこで結果オブジェクトを得るかを知っています; しかし、この例では、監視役は単に情報を（例えば、レポート業務に）流すのみで、オブジェクトを実際に取得する必要はありませんが、取得が禁止されているわけでは無いです。
通知の通信文は進捗情報モジュールからの基本的作業項目状態の詳細を含んでいます。監視役に有用であれば、監視役が追加の詳細や内容をGet UPS Workitemトランザクションにより、いつでも取得することができます。
以下の図で、作業項目実施(Workitem Performance)トランザクションは状況と順列を示します
が、（3次元画像使用例から）作業項目通知トランザクションを目立たせるために、灰色で書いています。
30.5.3.2 通知処理流れ （Notification Process Flow）_________________________________________________________________________________________

18
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

図 30.5.3.2-1: PAWFプロファイルでの通知処理流れ
30.5.4 キャンセル使用例
30.5.4.1 キャンセル使用例の説明_________________________________________________________________________________________

19
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

作業項目が予定されました；しかし、監視役はそれのキャンセル要求を出したいと思います。
作業項目を最初に要望したシステムがこれに当たり、（同じ検査（study）に別の作業項目を予定するため）要求を撤回したいと思います。あるいは、患者や事例の情報をもつ他のシステム化もしれません。この例では、監視役はこの作業項目を、作業項目を生成、通知受信予約、あるいは問い合わせのいずれかにより、知っていることを前提としています。 この例では、作業
項目実施役はすでに作業項目の取得要求を出しています。もし作業項目が取得請求されていないなら、作業項目管理役は自らキャンセル要望を処理できます。作業項目はここでは取得要求済みですので、作業項目管理役は通知を出すのみで、作業項目実施役に決定は任されます。作業項目実施役は途中で業務を辞めることができない場合があるので、作業項目実
施役の自己最良に完全に任されます。キャンセルの要求は、理由とキャンセル要求した人の連絡先を含むことを指摘しておきます。作業項目実施役はこの詳細を使用することも使用しな
いこともあります。作業項目実施役は、キャンセル要求者の名前、理由、を人間の操作者に表示して判断を仰ぐか、内部論理によって作業項目実施役が自動的に判断するかします。業務の性質や作業項目実施役の進捗状況により、作業項目に部分結果を記録することがあります。
詳細はDICOM PS 3.17 GGG.3.1 を見てください。
この例では、作業項目実施役がキャンセルのまえにいかに作業を始末したかの詳細は、監視役は関知しません。監視役が関知したいなら、Get UPS Workitem が使用できます。
30.5.4.2 キャンセル処理流れ_________________________________________________________________________________________

20
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

図 30.5.4.2-1: PAWF プロファイルでのキャンセル処理流れ

30.5.5 未予定使用例 （Unscheduled Use Case）
30.5.5.1 未定使用例の説明
作業項目実施役は、業務一覧にまだ予定検査として載っていない業務を実行したいと思っています。作業項目実施役が作業項目を生成したあとは、残りの業務流れと通知（下図では灰色）は、通知使用例の予定の例に同じです。
この使用例では、監視役（たとえばRIS）は作業項目管理役に全般的に通知受信予約をしており、追加の業務が行われたことを通告され続けることを前提としています。
30.5.5.2 未予定業務処理流れ_________________________________________________________________________________________

21
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

図 30.5.5.2-1: PAWFプロファイルの処理流れ

この使用例の2つの変法は、UPS関係モジュール（UPS Relationship Module）の詳細を通知する方法が異なるだけです。UPSインスタンスの属性値と連携するDICOMオブジェクトの間の必要な通信の詳細については、RAD TF-3:付録 Vを参照してください。
手短には、未予定業務流れの2変法は：・追加 – 作業項目実施役が新しい作業項目を既存の作業項目に追加します。
・特別 –作業項目実施役が新しい作業項目を既存の検査（Study）に関連付けます
が、既存の実施済作業項目とは関連つけしません。
作業項目実施役は関連する作業項目を、作業項目の実施、問い合わせ、通知の受け取り、により、認知します；しかし、いかにして、作業項目実施役が関連する作業項目、検査（Study）、患者を認知するかの記載は、このプロファイルの範囲外です。
30.5.6 コンピュータ支援検出使用例 （Computer aided Detection USe Case）
30.5.6.1 コンピュータ支援検出使用例の説明
撮影（例えば胸部CT）が行われ、CAD処理が画像に行われます（たとえば、肺結節の候補表示）。画像とCAD結果は一緒に読影医師により閲覧ワークステーションにて解釈されます。
この例では、作業項目生成役は、入力画像を取得する撮影装置と一括化されています。撮影
装置は、撮影業務一覧の検査コードや他の詳細にもとづいて、あるいは、操作者の入力にもとづいて、CAD作業項目を作成し作業項目コードを設定します。作業項目の入力情報順列（Input Information Sequence）内の画像インスタンス一覧は、データ取得に伴って撮影装置で生成されたMPPS内の一覧の一部であることに注意してください。
この例では、撮影装置が、予定ステーション名称コード順列（Scheduled Station name Code
Sequence）内で、CADシステムに特異なAEタイトルを同定します。作業項目管理役がきっかけを受け、要求を受けたシステムに通知が送られ、そのシステムは業務が割り付けられたことを知ります（押出型業務流れ）。
この例では、撮影装置は画像のコピーを特定のCADシステムに保存し、CADシステムのAEタ
イトルを入力情報順列（Inout Information Sequence）内インスタンスの取得AEタイトル（Retrieve
AE Title）として撮影装置に含みます。代わりに、画像はPACSあるいは現場のキャッシュに保存され入力情報順列（Inout Information Sequence）内で一覧されます。
以下の図では、前記の使用例と基本的に同じ作業項目実施（workitem performance）トランザ
クションは灰色で示し、強調のため、異なった点を黒色で示します。
30.5.6.2 CAD 処理流れ_________________________________________________________________________________________

22
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

図 30.5.6.2-1: PAWFプロファイルでのCAD処理流れ

UPS作業項目は一過性のオブジェクトですが、行った処理の詳細や失敗か成功かの記録は、
長期保存出力として、作業項目実施中に、エビデンス書類等として、記録されます
30.5.7 アプリケーションホスティング使用例
30.5.7.1 アプリケーションホスティング使用例の説明
ホスト役システムは、その配下にある配下アプリケーションを立ち上げて、作業項目の一部ある
いは全部を実行させます。簡略化のため、一括化された作業項目実施役・ホスト役システムは作業項目実施役と、この使用例では記します。
作業項目が、特定の配下のアプリケーション、あるいは、アプリケーションのクラスを指定あるいは示唆することがあります（例えば、Scheduled Workitem Code Sequence (0040,4018),
Scheduled Processing Parameters Sequence (0074,1210), Scheduled Station Class Code
Sequence (0040,4026)）。 このような作業項目を取得すると、作業項目実施役は、指定された、_________________________________________________________________________________________

23
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

配下アプリケーション、あるいは、配下アプリケーションクラスの使用を同意したことになります。
作業項目が使用する配下アプリケーションを指定しなくても、作業項目実施役が一個以上の配下アプリケーションを、作業実施のため、選択します。
この例では、作業項目実施役は作業項目の存在を知っているとしています（例えば、問い合
わせの実行、通知の受け取り、作業項目自体の生成、などによる）。
この例では、必要な配下アプリケーションのインスタンスはすでに立ち上がっており、IDLE状
態にあります。作業を終わった後も立ち上がったまま、としています。そうでない場合には、作業項目実施役は、アプリケーション開始（Start Application [RAD-89] ）やアプリケーション終了（Stop t Application [RAD-90]）トランザクションを適切に使用します。
この例では、作業項目実施役は入力インスタンスを配下アプリケーションが要望するとおりに、”要望に応じて”（on-demand）受け取ります。代わりに、作業項目実施役は現場保存庫にある全ての入力インスタンスを配下アプリケーションが要望する前から、さらには、業務開始（Start Task [RAD-92]）前から取得しておくこともできます。
この例では、配下アプリケーションは全ての入力を一回でもらうよう要求するとします。代わりに、必要に応じ繰り返し要求しても良いです（例えば実行時のメモリ節約のため）。
この例では、入力と出力はすべて画像です。代わりに、業務はレポートの使用や生成、表示条
件、キー画像注釈、等を使うことがあります。
この例では、配下アプリケーション結果をまとめて一回で出力するとします。代わりに、一個終
わるごとに一個の結果を出すこともできます。
この例では、配下アプリケーション作業項目通知を受けたら直ぐに結果を取得し保存するものとします。代わりに、業務が完全に終わるまで待つことも、取得して業務が成功するまで保存を待つこともできます。
この例では、作業項目実施役は、配下アプリケーションがIDEL状態になってから、作業項目を完成する前まで待つことにします。代わりに、業務完成（Complete Task）直後に、配下アプリ
ケーションの業務は既に無いため、業務項目を完成することもできます。
以下の図では、トランザクションの意図した関係と順序が示されており、アプリケーションホステ
ィングトランザクションは黒で、UPS業務流れとDICOM 保存・取得は灰色で示されています。

30.5.7.2 アプリケーションホスティング処理流れ_________________________________________________________________________________________

24
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

図 30.5.7.2-1: PAWFプロファイルにおけるアプリケーションホスティング処理流れ

30.6 PAWFの保安面考慮 （PAWF Security Considerations）
取得後処理流れの保安面考慮は、予定業務流れ（これは画像の取得に主眼があります）の保安面考慮と基本的に同じですが、取得後処理流れの間、患者は通常、装置の場にいないという点が予定業務流れとは違います。
取得後処理流れの業務一覧とデータオブジェクトは、予定業務流れで使用されるとほとんど同
じ患者情報をふくみ、同じローカルネットワークの上で動作します。予定業務流れアクタへの負荷以上に、取得後処理流れアクタに負荷を与えないように、ATNAを使用可能とし一体化_________________________________________________________________________________________

25
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

することは必須としていませんが、有用な機能として考慮するように30.7節で推奨しています。
施設をまたいでの使用はこのプロファイルでは特に扱われていません。このプロファイルのアクタは安全なネットワークを共有することとされています。
30.7 PAWF相互プロファイル配慮 （Cross Profile Considerations）
取得後処理流れプロファイルを他のIHEプロファイルと効果的に組み合わす方法はいくつかあります。
SWF予定業務流れ（SWF — Scheduled Workflow）
予定業務流れの部門システム予定役・オーダ実施役は作業項目生成役と一体化可能で、撮影に関連させて後処理を予定することができます。
予定業務流れの撮影装置は、作業項目生成役と一体化して、終了したばかりの撮影に適する
引き続きの検査段階を予定するのに役立ちます。
予定業務流れの部門システム予定役・オーダ実施役、あるいは画像管理役・画像保管庫は作業項目管理役と直接に一体化して、取得後処理の作業項目を管理できます。
予定業務流れ(SWF)の一括化については、30．3節 実装パターンを参照してください。
予定業務流れの撮影済検査段階管理役（MPPS Manager）は、作業項目管理役、あるいは、
作業項目生成役と一括化し、撮影業務流れの情報を取得後業務流れで利用できる可能性があります。
予定業務流れの撮影済段階管理役（MPPS Manager）は、また、作業項目管理役や作業項目
実施役と一括化して、MPPSの内容と同じUPSインスタンスを生成するのに使用できる可能性があります。これにより、監視役がデータ取得と取得後処理とを、容易に監視できるようになります（たとえば、部門の計器盤機能（望む業務に直ぐいける）や業務性能測定データ収集システ
ムなど）。MPPSインスタンス内容と意味を、UPSインスタンスに割り当てることは、ここでは扱いません。
施設間画像連携 （XDS-I.b — Cross-Enterprise Document Sharing for Imaging）
作業項目実施役は、XDS-Ibの画像文書消費役と一体化が可能で、UPS作業項目の入力情報順列で特定された画像を、XDSに基づく取得と同様に、取得することができるようになります。
これは、また、画像文書ソースと一体化あるいは通信して、XDS-I.bを使用したオブジェクトの保存と登録を行い、UPS作業項目の出力情報順列に従って、記録できる可能性があります。
可搬画像記憶媒体（PDI— Portable Data for Imaging
作業項目実施役は、PDIの画像表示役や可搬媒体読み込み役と一体化して、UPS作業項目の入力情報順列で特定された媒体から直接に、媒体による画像取り込みと同様に、画像を取得できる可能性があります。これは、また、可搬媒体作成役と一体化して、UPS作業項目の出力情報順列に従って、出力オブジェクトを媒体に保存し記録することができます。
_________________________________________________________________________________________

26
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

課金情報通知（CHG — Charge Posting）
監視役は、部門システム予定役・オーダ実施役、あるいは、会計処理役と一体化して、どの取得後処理の作業が実際にいつ完了したかの詳細をCHGが受け取るようにし、請求できるものを抽出します。
監査追跡と拠点認証 （ATNA — Audit Trail and Node Authentication (ITI Profile))
取得後処理の全アクタはATNAの保安拠点あるいは保安アプリケーションと一体化することができ、PAWFアクタ間の安全な接続を確立し、保安とプライバシ保護のために、監査結果通信
文を中央監査登録所へ寄稿することができます。

_________________________________________________________________________________________

27
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

付録

Appendices
アクタ定義のまとめ
以下の用語を、IHE TF一般導入名称空間アクタ一覧に加えてください:
作業項目生成役（Workitem Creator）: 作業項目を管理または実行するシステムに新しい業
務項目を生成するよう、要求します。
作業項目管理役（Workitem Manager）: 業務一覧にある、作業項目を管理し、問い合わせし、通知します。
監視役（Watcher）: 作業項目に関連する事象（変更、キャンセル、完成、など）の通知を受け取るよう予約し、通知をうけとります。
作業項目実施役（Workitem Performer）: 作業項目管理役が管轄する作業項目を問い合わせし、取得を要求し、作業項目を実行します。
ホスティングシステム（Hosting System）: アプリケーションを配下に置き、実行環境を与え、資源との協働を調整するシステムです。
（訳者注：本書では「ホスト役システム」とも訳す。）

配下アプリケーション（Hosted Application）: ホスティングシステムのもとで動くアプリケーショ
ン（プログラム）

トランザクション定義のまとめ
以下の用語を、IHE TF一般導入名称空間トランザクション一覧に加えてください:
UPS作業項目生成（Create UPS Workitem） [RAD-80]: UPS作業項目生成の要求
UPS作業項目問合わせ（Query UPS Workitems） [RAD-81]: 検索条件に合致する作業項
目一覧の要求UPS作業項目取得要求（Claim UPS Workitem） [RAD-82]: UPS作業項目の所有を要求
UPS作業項目取得（Get UPS Workitem）[RAD-83]: UPS作業項目の内容を要求
UPS作業項目更新（Update UPS Workitem）[RAD-84]: UPS作業項目の内容変更を要求
UPS作業項目完了（Complete UPS Workitem） [RAD-85]: UPS作業項目を完成させる要求
UPS通知受信予約管理（Manage UPS Subscription） [RAD-86]: UPS作業項目インスタンスに関連する事象の通知開始と通知中止の要求
UPS通知送付（Send UPS Notification） [RAD-87]: UPS作業項目への、変更や完成などの、_________________________________________________________________________________________

28
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

変更の通知を送る
UPSキャンセル要求（Request UPS Cancelation): キャンセルの要求
アプリケーション開始（Start Application） [RAD-89]: 配下アプリケーションを開始し指示に応える準備をするよう要求
アプリケーション停止（Stop Application） [RAD-90]: 配下アプリケーションを停止する要求.
アプリケーション前面移動（Bring Application Front） [RAD-91]: 配下のアプリケーションのウィンドウを前面に持ってくる要求.
業務開始（Start Task） [RAD-92]: 配下アプリケーションが処理業務を始めるよう要求.
業務詳細取得（Get Task Details） [RAD-93]: ホスティングシスシステムからの作業項目業務
内容の要求
業務データ取得（Get Task Data） [RAD-94]: ホスティングシスシステムからの入力データ要業務状態通知（Notify Task Status） [RAD-95]: 業務状態変更の通知を送る
業務結果通知（Notify Task Results） [RAD-96]: 業務結果の可用性通知を送る要求
業務結果取得（Get Task Results）[RAD-97]: 業務結果オブジェクトの要求
業務完了通知（Notify Task Complete） [RAD-98]: 業務完了の通知を送る要求
業務終了（Finalize Task） [RAD-99]: 配下アプリケーションが業務詳細を手放し、待ち受け状態にする要求
業務取り消し（Cancel Task） [RAD-100]: 配下アプリケーションに業務の処理をやめるよう要
求アプリケーション業務一時中止（Suspend Application Task）[RAD-101]: 配下アプリケーショ
ンに一時的な休止を要求
アプリケーション業務再開（Resume Application Task） [RAD-102]: 配下アプリケーションに一時的な休止状態の業務の再開を要求

用語集

Glossary
以下の用語を IHE テクニカルフレームワーク一般導入用語週に追加します。

（追加無し）_________________________________________________________________________________________

29
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

第二巻－

トランザクション

Volume 2 – Transactions
あたらしいアクタ・役割について、以下の様にします：
Add
Workitem Performer to the Use Case Diagram in 4.10.2“Y節の役割Xの一覧に「作業項目実施役（Workitem
Performer）」を加えます。
Add the following to section 4.10.2 after Evidence Creator:
使用例図4.10.2に作業項目実施役を加えます。
4.10.2節に、エビデンス生成役のあと、以下を追加します。
アクタ：作業項目実施役（Workitem Performer）
役割： 画像管理役に画像保存完了済（Storage commitment)トランザクションを要求する。（このトランザクションの残りでは、エビデンス生成役への参照は作業項目実施役にも同様に適用されます。）
使用例図4.16.2に作業項目実施役を加えます。
画像表示役のあと、4.16.2節に、以下を追加します。
アクタ：作業項目実施役（Workitem Performer）
役割：画像保管庫から要求した画像をうけとります。（このトランザクションの残りでは、画像表
示役への参照は作業項目実施役にも同様に適用されます。）
使用例図4.17.2に作業項目実施役を加えます。
画像表示役のあと、4.17.2節に、以下を追加します。
アクタ：作業項目実施役（Workitem Performer）
役割：白黒画像表示条件オブジェクトを参照された画像データとともに取得し、表示条件に示される変換を適用します。この装置はQuery/Retrieve SOPクラスを、SCUの役割として。実装します。（このトランザクションの残りでは、画像表示役への参照は作業項目実施役にも同様に適用されます。）
使用例図4.18.2に作業項目実施役を加えます。
4.18.2節に、エビデンス生成役のあと、以下を追加します。
アクタ： 作業項目実施役（Workitem Performer）
役割：生成した画像データを画像保管庫に送ります。（このトランザクションの残りでは、エビデンス生成役への参照は作業項目実施役にも同様に適用されます。。）
使用例図4.29.2に作業項目実施役を加えます。
4.29.2節に、エビデンス生成役のあと、以下を追加します。
アクタ： 作業項目実施役（Workitem Performer）_________________________________________________________________________________________

30
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

役割：キー画像注釈を生成して”重要画像”とのフラグを付け、キー画像注釈保存済トランザク
ションを画像保管庫に送ります。（このトランザクションの残りでは、エビデンス生成役への参照
は作業項目実施役にも同様に適用されます。）(In
the rest of this transaction,
使用例図4.31.2に作業項目実施役を加えます。
references
to Evidence Creator apply equally to Workitem Performer.)
4.31.2節に、画像表示役のあと、以下を追加します。
アクタ：作業項目実施役（Workitem Performer）
役割：画像保管庫から要求されたキー画像注釈をうけとります。（このトランザクションの残りでは、画像表示役への参照は作業項目実施役にも同様に適用されます。）_________________________________________________________________________________________

31
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

第三巻－

トランザクション

Volume 3 – Transactions
使用例図4.43.2に作業項目実施役を加えます。
4.43.2節に、エビデンス生成画役のあと、以下を追加します。
アクタ：作業項目実施役（Workitem Performer）
役割：エビデンス書類中の非画像のエビデンス情報を記録し、画像保管庫に保管します。（このトランザクションの残りでは、エビデン生成役への参照は作業項目実施役にも同様に適用されます。）
使用例図4.45.2に作業項目実施役を加えます。
4.45.2節に、画像表示役のあと、以下を追加します。
アクタ：作業項目実施役（Workitem Performer）
役割：画像保管庫から要求されたエビデンス書類をうけとります。（このトランザクションの残りでは、画像表示役への参照は作業項目実施役にも同様に適用されます。）
4.80節を追加します（全く新しいトランザクションです）
4.80

UPS 作業項目の生成[RAD-80]（Create UPS Workitem）

4.80.1 範囲
このトランザクションは新しい作業項目を生成します。
作業項目の内容は、実装すべき業務と、入力データへの参照、業務に関連するインスタンスの順番やアクセッション番号、の様なこれに関連する情報の両者を記述します。
典型的な「引寄せ型業務流れ」では、このトランザクションで、作業項目生成役（例えば、RIS、部門業務流れ管理役）が作業項目管理役（Workitem Manager）に新しい作業項目を業務一覧に加えるよう、指揮できる様になります。管理役がその内部論理で作業項目を業務一覧に加えた時には、実装には通信文を送らないとはいえ、このトランザクションの意味と完全に準拠しなければなりません。
未予定または追加例では、このトランザクションで、作業項目実施役が新しい未予定または追加の業務項目が生成され、作業項目実施役にて実行中であることを管理役に教えられる様になります。この UPS N-CREATE 命令は、未予定のデータ取得業務に使用される、MPPS
N-CREATE と同類です（構造も似ています）。
4.80.2 使用例の役割
このトランザクションの役割は、以下の表に示され、ここに示される実施役で行われます：_________________________________________________________________________________________

32
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときのみ、特定されます。
4.80.3 参照する標準DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.3: Unified Procedure Step Information Object
DICOM 2011 PS 3.17: Unified Worklist and Procedure Step - UPS (Informative)

4.80.4相互作用図

4.80.4.1 UPS生成通信文の要求 Request UPS Creation Message
要求役は、新しい作業項目である、新しいUPSインスタンスを生成する要求を、管理役に送ります。要求には要求する作業項目の詳細を含んでいます。
_________________________________________________________________________________________

33
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

管理役は一個以上の要求役からの通信文を扱えねばなりません。要求役は一個以上の管理役を、要求生成のために、選択し使用可能とすることがあります。
4.80.4.1.1 きっかけ事象
要求役の使用者あるいは自動実行機能が、新しい作業項目が必要と判断します。要求役は、
新しい作業項目の生成要求を、入力インスタンスの完全な一覧があり、これらが取得可能であるとき以外は、行ってはなりません。
4.80.4.1.2 通信文の意味
この通信文は、DICON USP Push SOP classのN-CREATE 命令です。要求役がSCUで管理悪がSCPです。
4.80.4.1.2.1 UPS属性の要求事項
DICOM PS 3.4に記載のUPS N-CREATE 要求事項に加え、要求役は、以下の要求事項に合致せねばなりません。
予定業務項目コード順列(0040,4018) は、実行すべき業務を特定する一個のコードを持たねばなりません。要求役が要求できる業務に使用するコードを施設が設定できる様にせねばなりません。
注：DICOM CID 9231 は手に余る量の一般的コードを提供します。

要求役は予定ステーション名称コード順列(0040,4025)を流布して、実行するシステムを特定することがあります。コード値 (0008,0100)は、指名するシステムのAEタイトルを 含まねばなりません。コード意味(0008,0104)は、指名するシステムのAEタイトルまたは見読性のある名称にせねばなりません。
注： コード化法指示(0008,0102)は、"L"、あるいは、"99"で始まる値をもちます。DICOM PS3.3、8.2節を参照して下さい。

入力準備状況（Input Readiness State (0040,4041) ）は、入力情報順列(0040，4021)が完全で取得可能であるときには、"READY"でなければなりません。
未予定のUPSインスタンスと、連携している DICOM オブジェクトとの間の、属性値対応の詳細は付録 W を参照してください。
4.80.4.1.2.2 属性使用の例
要求役は、予定処理パラメータ順列(0074,1210)内に、処理用パラメータの一覧を提供することがあります；しかし、パラメータの協調と値のコード化はこのトランザクションの範囲外です。作業項目の業務一覧生成役作業項目実施役がもたらす書類から詳細を探さねばなりません。
4.80.4.1.3 予期される動作管理役は、DICOM PS 3.4 Annex CC に記された様に、要求されたUPS インスタンスの生成を試み、要求役に「成功」、ないし、「失敗」のコードを送らねばなりません。
_________________________________________________________________________________________

34
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.80.5 保安に関する考慮
どのような使用者やシステムが作業項目を生成する権限を持つか、現場の運用方針で決め、適切に設定せねばなりません。
4.80.5.1 安全監査の考慮
このトランザクションはATNAのきっかけ事象にはなりません。.
4.81節を加えます
4.81

UPS 作業項目の問合わせ[RAD-81]（Query UPS Workitems）

4.81.1 範囲
このトランザクションは関心のある作業項目を見いだすために使用します。
作業項目の内容は行うべき業務と、業務と関係した入力への参照、オーダ番号、アクセッショ
ン番号、などの関連情報です。
典型的には、作業項目は作業項目管理役が予定し、問合わせシステムが一個以上の作業項
目を選択、取得要求します。業務一覧上の作業項目には、コンピュータ支援検出、臨床顔図
解析・測定、3次元画像の生成、等が含まれます。
問合わせシステムは、作業状況通知の受信を予約した、関心対象の作業項目を選ぶための監視役にもなります。
このトランザクションは検索の絞り込みや選択に必要な属性に焦点を絞っています。一致キーの値は、管理役で検索を行うのに使用されます。返答キーの値は、要求側での追加の絞り込
み検索や並べ替えを行うのに使用します。いったん、関心のある作業項目が選択されると、UPS作業項目（Get UPS Workitem ）[RAD-83]トランザクションは、業務項目の全ての詳細を手にできます。
4.81.2 使用例の役割
このトランザクションの役割は以下の表の様に定義され、ここに示されるアクタで実行されます：_________________________________________________________________________________________

35
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときだけ、特定されます。
4.81.3 参照する標準DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.3: Unified Procedure Step Information Object
4.81.4 相互作用図

4.81.4.1 UPS作業項目問合わせ通信文 Query for UPS Workitems Message
要求役は、作業項目であるUPSインスタンスを管理役に問い合わせます。
管理役は、複数の実施役からのこのような通信を扱えねばなりません。
4.81.4.1.1 きっかけ事象
要求役の使用者あるいは自動化された機能が、関心のある作業項目を同定し、作業項目に関連する詳細を得ようとします。
_________________________________________________________________________________________

36
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.81.4.1.2 通信文の意味
通信文は、DICOM UPS Pull SOPクラス（DICOM UPS Pull SOP Class）のC-FIND要求です。
The m要求役がSCUで、管理役がSCPです。詳細は DICOM PS 3.4 Annex CC を参照してください。
4.81.4.1.2.1 一致キーと返答キー Matching Keys and Return Keys
要求役は以下の問い合せ型が可能でなければなりません。
注： 以下の問い合わせの種々の組み合わせが使用者には有益と思われます。実装する会社はこのような組み合
わせを考慮するのを推奨します。

1. 患者指向問合わせ：特定の患者に関連する業務の問合わせ。要求役は表4.81.4.1.2.1-1に示される全ての一致キー属性を問合わせに使用可能でなければなりません。キー一個か組み合わせかは、要求役の裁量に任されます。
表 4.81.4.1.2.1-1: 患者指向業務項目問合わせ用の UPS キー

注： UPSインスタンスは、患者ID値の発行者の値を空白のまま、生成されるのが許されています。空白の値は、現場施設に一致することが前提になっています。

2. 処理指向問合：特定の処理に関連した作業項目の問合わせ。
要求役は表4.81.4.1.2.1-2に示される全ての一致キー属性を問合わせに使用可能でなければなりません。キー一個か組み合わせかは、要求役の裁量に任されます。斜体で示される順列
属性は、一致キーではありませんが、問合わせに含まれる属性の値を伝えるため、問合わせに含まねばなりません。
表 4.81.4.1.2.1-2: 処理指向作業項目問合わせ用UPSキー_________________________________________________________________________________________

37
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

3. ワークステーション指向問合わせ：特定のワークステーションに関連した作業項目の問合わせ。
要求役は表4.81.4.1.2.1-3に示される全ての一致キー属性を問合わせに使用可能でなければなりません。キー一個か組み合わせかは、要求役の裁量に任されます。斜体で示される順列
属性は、一致キーではありませんが、問合わせに含まれる属性の値を伝えるため、問合わせに含まねばなりません。予定ステーション名称コード順列のコード値は、値を入れる場合には、要求役のUPS SCUのAEタイトルでなければなりません。
表 4.81.4.1.2.1-3: ワークステーション指向業務項目問合わせUPSキー

4. クラス指向問合わせ：特定のワークステーションクラスに関連した業務項目の問合わせ
要求役は表 4.81.4.1.2.1-4 に示される全ての一致キー属性を問合わせに使用可能でなければなりません。キー一個か組み合わせかは、要求役の裁量に任されます。斜体で示される順列
属性は、一致キーではありませんが、問合わせに含まれる属性の値を伝えるため、問合わせに含まねばなりません_________________________________________________________________________________________

38
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

表 4.81.4.1.2.1-4: クラス指向作業項目問合わせ用UPSキー

追加の絞り込み検索 Additional Filtering
必須ではありませんが、要求役の実装では、関心のある作業項目の検索に有用な属性について、DICOM PS 3.4 表 CC.2.5-3にあげられた使用可能な一致キーと返答キーの全リストを参照することを奨励します。
いくつかの可能性としては：予定完成日時（Expected Completion DateTime (0040,4011)）、 期
限日時（Expiration DateTime）、予定処理段階優先度(0074,1200)）、処理段階名称（Procedure Step Label (0074,1204)）、業務一覧名称（Worklist Label (0074,1202)）、予定ワー
クステーション設置位置コード順列（Scheduled Station Geographic Location Code Sequence(0040,4027)）、予定実行者順列（Scheduled Human Performers Sequence (0040,4034)）、患者
生年月日（Patients Birth Date (0010,0030)）、患者性別（Patients Sex (0010,0040)）、入院ID（Admission ID (0038,0010))、入院ID発行者順列（Issuer of Admission ID Sequence(0038,0014)）、要求サービス（Requesting Service (0032,1033)）、置換処理段階順列（Replaced
Procedure Step Sequence (0074,1224)）。
4.81.4.1.2.2 一致キー属性の使用例
・予定処理段階開始日時は、当日業務の問合わを可能にします。
・予定業務項目コード順列は、特定タイプのCAD業務の問合わを可能にします。
・予定ワークステーション名称コード順列は、このワークステーションの業務の問合わを可能にします
・予定処理段階開始日時、予定業務項目コード順列、予定ワークステーション名称
コード順列の全てで、当日の3D再構成ワークステーションの3次元画像作成業務の問い合わせを可能にします。
注：要求役は構造化された患者名の構成成分の最後にワイルドカード"*" を追加して、構造化氏名でも、非構造化
氏名でも、検索を容易にします。

4.81.4.1.3 予期される動作管理役は、問合わせに一致したUPS作業項目を、問合わせを出した要求役へ、DICOM PS
3.4に記載の様に送らねばなりません。
4.81.4.2 UPS作業項目返答通信文
管理役は、問合わせに合致する作業項目を返します。
_________________________________________________________________________________________

39
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.81.4.2.1 きっかけ事象
管理役が作業項目の問い合わせを受けます。
4.81.4.2.2 通信文の意味
通信文は、DICOM UPS Pull SOP クラスからのC-FIND応答の組です。
要求役はSCU、管理役はSCPです。
C-FIND応答の詳細は、ある目的のために、絞り込み検索と作業項目選択を容易にすることです。作業項目自身が、作業項目の実施に影響する、あるいは、観察用のアプリケーションには有用な、追加の詳細を持っています。このような詳細は、UPS内容取得（Get UPS Contents）ト
ランザクションで取得可能です。
4.81.4.2.3 予期される動作
要求役は典型的には、業務一覧を使用者に提供して、選択した作業項目にある詳細にもとづいて作業するか、選択して自動的に処理をするか、します。要求役は、使用者に業務一覧を提示する前に、「要求側（"client-side"）」検索を行うことが許されています。この検索は、返答キーの値、アクセス制限、その他の論理にもとづき行われます。
4.81.5 保安上の考慮
4.81.5.1 安全性監査の考慮 Security Audit Considerations
ATNA プロファイルを使用可能とする管理役は、このトランザクションを監査しなければなりません。このトランザクションは情報問合わせATNAのきっかけ事象に該当します。
4.82節を追加します (古いトランザクションの変更です）
4.82

UPS 作業項目の取得要求[RAD-82]（Claim UPS Workitem）

4.82.1 範囲
このトランザクションは選択した作業項目の状態を「IN PROGRESS」にして、「所有権」を（実施役に）渡すよう、管理役システムに伝えます。これにより、その作業項目に取得要求が出されており、他の業務一覧使用者が取得要求したり変更できず、他者から隔離されていることを伝える様にできます。作業項目はまだ管理者の元にありますが、作業項目の更新を許されるのは、「所有権」のある実施役のみです。ある想定業務手順では、ひとつのシステムが管理役と実施役を兼ねています。
4.82.2 使用例の役割
このトランザクションの役割は以下の表の様に定義され、ここに示されるアクタで実行されます：_________________________________________________________________________________________

40
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときだけ、特定されます。
4.81.3

参照する標準DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.17: Unified Worklist and Procedure Step - UPS (Informative)
4.82.4 相互作用図

4.82.4.1 UPS 状態変更通信文 Change UPS State Message
実施役は、UPSインスタンスの管理役に、作業項目の状態を「INPROGRESS」にするよう、要求します。
管理役は、一個以上の実施役からのこのような通信文を扱えねばなりません（しかし、通常、そ_________________________________________________________________________________________

41
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

れぞれの作業項目はこの通信文を一個の実施役からのみ受け取ります）。
実施役は複数の管理役にある作業項目と協働する様にもできます。
4.82.4.1.1 きっかけ事象
実施役の使用者、あるいは、自動実行機能が、作業項目を制御して作業を始めるか変更したりします。
実施役は、予定ワークステーション名称コード順列（Scheduled Station Name Code Sequence(0040,4025)）の内容で、その実施役が使うよう意図されていない作業項目に取得要求を出してはなりません。この順列をひろめる詳細については、.4.80.4.1.2.1節を見てください。
実施役は、入力準備状態（Input Readiness State）がINCOMPLETE」持つ作業項目に取得要求してはなりません。このようにすると、残りの入力が入力情報順列に追加されなくなります。
注：もし、入力情報順列のリストが不完全な作業項目で作業を開始し、それが実施役に有益なら、作業項目取得要
求でなくUPS作業項目取得（Get UPS Workitem (RAD-83)）トランザクションが使えます。

実施役は、入力準備状態（Input Readiness State）がUNAVAILABLE値を持つ作業項目に取得要求できますが、入力情報順列にあるインスタンスがいつ使用可能なるか実施役が決めねばなりません。いったん取得要求を出せば、UPSのロック用UIDの特徴により、取得要求を出した実施役と管理役のみが、内容を変更したり、UPS作業項目の状態を変更したりできます。しかし、他のシステムも状態を内容を見ることはできます。
4.82.4.1.2 通信文の意味
この通信文は、DICOM UPS Pull SOPクラスのUPS状態変更N-ACTION要求（Change UPS
State N-ACTION reques）です。実施役がSCUで、管理役がSCPです。
実施役は、DICOM PS 3.4 Annex CC 記載の様に、ロック用UIDを生成し、UPS状態を「IN
PROGRESS」とするよう要求せねばなりません。ロック用UID は、Transaction UID (0008,1195)
属性の中で、伝達されます。
実施役は、ロック用UID をこの作業項目の将来のトランザクションに備えて保持せねばなりません。この作業項目に対する将来の変更は、正しいロック用UIDが与えられないと、管理役に拒否されます（DICOM PS 3.4 参照）。
作業項目の取得要求を行うと、実施役はその作業項目を、予定作業項目コード順列（Scheduled Workitem Code Sequence (0040,4018)）に含まれるコードで定義された業務を行う
責任を持ちます。実施役が行いうる種々の業務に対応するコードを、施設が割り付けられる様に、実施役は設定できねばなりません。実施役は、業務を直接執行したり、他のシステムの業
務の実行と協調させて行うこともできます（たとえば、業務の全部または一部を下請けに出すか、配下アプリケーションに委託して実行するなど）。
4.82.4.1.3 予期される動作管理役は、N-ACTION状態変更要求をDICOM PS 3.4 Annex CC 記載の様に扱い、成功か
失敗かの適切なコードを要求役に返さねばなりません。管理役がUPS通知トランザクションを_________________________________________________________________________________________

42
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

送るようにすることが必要な場合には、通知文予約の状態に応じて、UPS生成の通知を送るとのDICOM要求事項が、これに含まれます。
4.82.5 保安の考慮
現場の方針で、どの使用者やシステムが作業項目の取得要求ができるか決め、適切に設定せねばなりません。
4.82.5.1 安全性監査の考慮
このトランザクションはATNAきっかけ事象と関連していません。
4.83節を追加します。（一部、実行済み作業状態更新から導入）
4.83

UPS 作業項目内容取得[RAD-83] （Get UPS Workitem Contents）

4.83.1 範囲
This transaction is used to retrieve the contents (i.e., values of a requested list of attributes) froma workitem.
4.83.2 使用例の役割
このトランザクションの役割は以下の表の様に定義され、ここに示されるアクタで実行されます：

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときだけ、特定されます。
4.83.3 参照する標準_________________________________________________________________________________________

43
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.3: Unified Procedure Step Information Object
DICOM 2011 PS 3.17: Unified Worklist and Procedure Step - UPS (Informative)
4.83.4 相互作用図

4.83.4.1

UPS内容要求通信文 Request UPS Contents Message

要求役は、UPSインスタンスの管理役に特定のUPSインスタンスの特定の属性のセットの値を提供する要求を送ります。
管理役は、複数の実施役からのこのような通信を扱えねばなりません。要求役は一個以上の管理役に要求を送ることもできます。
4.83.4.1.1 きっかけ事象
要求役の使用者あるいは自動化機能が、作業項目の属性値を要求します。
典型的な2つの用法は以下です。
・ 作業項目実施役が作業開始前に作業項目の全内容を取得する
・ 監視役が、作業項目内容変更の通知を受けた際、関心のある内容物を取得する
4.83.4.1.2

通信文の意味

この通信文は、DICOM UPS Pull SOP Class （あるいは、DICOM UPS Watch SOP Class）の、
N-GET要求です。要求役がSCUで、管理役がSCPです。
注：2つのSOPクラスのN-GET要求は同価です。DICOM PS 3.4の、SOP Class UID、連携交渉(Association Negotiation)と DIMSE Implications for UPSの議論に特に注意を払ってください。
4.83.4.1.2.1 UPS 属性の要求事項
UPS インスタンスと連携するDICOMオブジェクトの属性値間での対応については、RAD
TF-3: 付録 V を参照してください。
_________________________________________________________________________________________

44
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

予定処理パラメータ順列 (0074,12120)、DICOM で規定されている以上のことについて、IHE
は何の制限もしません。作業項目実施役がこれを取得し使用するなら、作業項目生成役がこれを実行できる様に設定するための詳細な書類を提供するのは、作業項目実行役の責任です。
4.83.4.1.3

予期される動作

管理役は、要求を扱い、Return UPS Contentsで応答します。
4.83.4.2

UPS内容返送通信文 Return UPS Contents Message

管理役は、UPSインスタンスから要求された値を、要求役に返します。
4.83.4.2.1 きっかけ事象
管理役は、UPS内容返送通信文（Return UPS Contents Message）を受けます。
4.83.4.2.2 通信文の意味
この通信文は、Primitive of the DICOM UPS Pull SOP Class（これは、Primitive of the DICOMUPS Watch SOP Class のN-GET返答と同価です）のN-GET返答です。要求役がSCUで、管理役がSCPです。
4.83.4.2.3 予期される動作管理役は、能力の許す限り要求された属性を提供し、適切な「成功」、「失敗」のコードを返さ
ねばなりません。
4.83.5 保安の考慮
現場の方針で、どの使用者やシステムが作業項目の取得要求ができるか決め、適切に設定せねばなりません。
4.83.5.1 安全性監査の考慮
このトランザクションはATNAきっかけ事象と関連していません。

4.84節を追加します (古いトランザクションの変更)

4.84

UPS 作業項目の更新 [RAD-84]（Update UPS Workitem）

4.84.1 範囲_________________________________________________________________________________________

45
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

このトランザクションは、管理役が有する作業項目の内容を管理役に変更してもらう要求を、作業項目実施役が出す時に使用されます。
これは通常、作業項目完了の前に、進捗状況の詳細の更新や、終了処理のために行われます。
システムが、実行中のUPS インスタンスの管理をしている場合は、このトランザクションを使用するよりは、直接にインスタンスを更新します。
4.84.2 使用例の役割
このトランザクションの役割は以下の表の様に定義され、ここに示されるアクタで実行されます：

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときだけ、特定されます。
4.84.3 参照する標準DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.3: Unified Procedure Step Information Object
DICOM 2011 PS 3.17: Unified Worklist and Procedure Step - UPS (Informative)
4.84.4 相互作用図_________________________________________________________________________________________

46
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.84.4.1

UPS更新要求通信文（Request UPS Update Message）

実施役は、UPSインスタンスの属性更新要求を管理役に、送ります。
管理役は、複数の実施役からのこのような通信を扱えねばなりません。要求役は一個以上の管理役に要求を送ることもできます。
4.84.4.1.1 きっかけ事象
実施役の使用者や自動機能が、作業項目の属性値を更新します。
作業項目に実際の作業を始めると、実行済処理段階開始時間（Performed Procedure Step
Start DateTime (0040,0244)）と実行済ワークステーション名称コード順列（Performed Station
Name Code Sequence (0040,4028)）の内容を更新する様、UPS更新要求（Request UPS pdate）
通信を出さねばなりません。
一般に、他の更新の頻度と適切なタイミングは、プロファイルに記載が無い限り、実施役に任されています。使用者が頻度を決めるよう設定できる実装なら便利と思われます（例えば、5分に設定すると、UPSインスタンスの情報はすべて5分以内の最新情報です）。
これは、実施役が作業しているか決める有用な”心拍動”機構になります。
4.84.4.1.2

通信文の意味

この通信文は、DICOM UPS Pull SOP Class のN-SET命令です。実施役はSCU。管理役はSCUです。
DICOM PS 3.4に記載の様に、実施役はUPSインスタンスにロック用UIDを持たねばなりません。
さもなければ、管理役はN-SET要求を拒否します。ロック用UID は、Transaction UID(0008,1195)属性内で伝達されます。RAD-82を使用して作業項目に取得要求すると一般的に実施役はロック用UID を生成します。しかし、他のアクタと一括化されているため、あるいは別の方法で、ロック用UIDを持つことが可能です。
_________________________________________________________________________________________

47
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.84.4.1.2.1 UPS属性要求事項 UPS Attribute Requirements
DICOM PS 3.4 記載のUPS N-SET 要求事項に加え、SCUはここに定める要求事項に沿わねばなりません。
実施者順列（Actual Human Performers Sequence (0040,4035) ）は、ヒトが作業項目に作業す
るなら、値を持たねばなりません。
実行済ワークステーション名称コード順列（Performed Station Name Code Sequence(0040,4028) ）は以下の様に、コード化せねばなりません。
Code Value (0008,0100) は、該当システムのAEタイトル、Code Meaning (0008,0104)は、該当
システムのAEタイトル、または、見読性のある名称。もしシステムが複数のAEタイトルを持つな
ら、USP通知送信（Send UPS Notification）トランザクションが取得できるAEタイトルを反映する
値で無ければなりません（例えば、キャンセル要求がきたことを通知する）。
注：コード化方式指定役（The Coding Scheme Designator (0008,0102)）は通常、"L"あるいは"99"で始まる値を持ちます。DICOM PS3.3の8.2節を参照してください。

UPSインスタンスと連携したDICOMオブジェクトの属性値間の必用な対応については、RAD
TF-3: 付録 V を参照してください。
4.84.4.1.2.2 属性の使用例
統一検査段階進捗情報モジュール（Unified Procedure Step Progress Information Module）使用のガイドは、DICOM PS3.3 C.30.1にあります。
作業項目内容の部分完成を反映した更新や、要求とはことなる何かを実行したときについての情報は、DICOM PS3.17 GGG.3.1にあります。
4.84.4.1.3 予期される動作管理役は、要求された様に（また、DICOM PS 3.4に記載された様に）インスタンスを更新し、適切な、失敗、成功のコードを実施役に送ります。
4.84.5 保安の考慮
4.84.5.1 安全性監査の考慮
このトランザクションはATNAきっかけ事象と関連していません。
4.85節を追加します。 (古いトランザクションの変更)
4.85

UPS 作業項目完成[RAD-85]（Complete UPS Workitem）

4.85.1 範囲
このトランザクションは、作業実施役がシステム管理役（たとえば、後処理管理役）に、選択された作業項目の内容（たとえば、結果オブジェクトへの参照）が完了し、最終状態をCOMPLETE
またはCANCELEDに変更せねばならないことを伝えます。最終状態に一旦なると、作業項目_________________________________________________________________________________________

48
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________の更新を許されません。
4.85.2 使用例の役割
このトランザクションの役割は以下の表の様に定義され、ここに示されるアクタで実行されます：

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときだけ、特定されます。
4.85.3 参照する標準DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.17: Unified Worklist and Procedure Step - UPS (Informative)
4.85.4 相互作用図

4.85.4.1

UPS状態変更通信文 Change UPS State Message

実施役はUPSインスタンスの管理役に、作業項目に対する業務が完了したこと、UPSを更新したこと、管理役がUPS状態をCOMPLETED、（Performer for the Procedure Step State_________________________________________________________________________________________

49
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________(0074,1000)が与える値にもとづき）または、CANCELED、にすることを通知します。
管理役は、複数の実施役からのこのような通信を扱えねばなりません（が、この通信文の個々の作業項目は典型的には一個の実施役からのみこの通信をうけます）。要求役は一個以上の管理役に要求を送ることもできます。
4.85.4.1.1 きっかけ事象
実施役の使用者または自動機能は、作業項目の意味する業務が完成ないしキャンセルされたこと、および、DICOM PS 3.4 表 CC.2.5-3Aに記されている最終状態の要求事項を満たしていることを、決めます。
UPSインスタンスは生成された出力への参照、利用可能場所を含むことから、および、UPSイン
スタンスはいったん完成したら更新できないことから、このトランザクションが発動される前に、結果を成功裏に保管するよう、推奨されています。
4.85.4.1.2

通信文の意味

この通信は、DICOM UPS Pull SOP ClassのUPS 状態変更N-ACTION 要求（Change UPS
State N-ACTION request）です。 実施役が SCU、管理役が SCUです。
実施役は、生成した全てのインスタンスがあれば、その一覧を出力情報順列（Output
Information Sequence (0040,4033)）に入れ、最終状態の要求事項を満たさないうちは、
N-ACTION 要求を送ってはいけません。
4.85.4.1.3 予期される動作
DICOM PS 3.4 Annex CC に記載の様に、管理役は、N-Action 状態変更要求を扱い、要求役に、成功、失敗のコードを要求役に送らねばなりません。これには、通知受信予約の状態に応じて、UPS完成通知を送出する、DICOM要求事項を含んでいます。管理役が、残された削除ロックと最終状態になったインスタンスを強制削除する内部論理を持つ場合には、削除の前に少なくとも24時間待てねばなりません。この機能は設定可能で無ければなりません。
4.85.5 保安の考慮
4.85.5.1 安全性監査の考慮
このトランザクションはATNAきっかけ事象と関連していません。

4.86 節を追加します (新しいトランザクション)

4.86

UPS 通知受信予約管理[RAD-86]（Manage UPS Subscription）

4.86.1 範囲
このトランザクションは、一個以上の作業項目の通知に関心のあるアクタに使用されます。
_________________________________________________________________________________________

50
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

アクタが作業項目の通知受信予約をすると、作業項目が意味する業務のUPSインスタンスの、状態および内容の変更の際、アクタは通知を受けます（RAD-87参照）。特定のインスタンスの通知受信予約に加え、全てのインスタンスの通知受信予約を、別の実行役の管理のもと、行うことができます。アクタは、「削除ロック」を通知受信予約にかけることができます。これにより、
UPSインスタンスがCOMPLETED、CANCELED 状態になったとき、通知受信予約をしている
アクタが最終的な詳細を受けるための余裕を与えます。詳細は、DICOM PS 3.4とPS 3.17を参照してください。
4.86.2 使用例の役割
このトランザクションの役割は以下の表の様に定義され、ここに示されるアクタで実行されます：

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときだけ、特定されます。
4.86.3 参照する標準DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.17: Unified Worklist and Procedure Step - UPS (Informative)
4.86.4相互作用図Interaction Diagram_________________________________________________________________________________________

51
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.86.4.1

UPS通知受信予約・予約解除 Subscribe/Unsubscribe UPS Message

予約役は管理役に、通知受信予約状態の変更を要求します。通知受信予約ありの場合は、作業項目の状態や内容が変化したら、管理役から通知を受け取ります。
管理役は複数の予約役からのこの様な通信文を扱えねばなりません。予約役は複数の管理役にある作業項目との協働を可能とすることもできます。
DICOM PS 3.4に記載の様に、通知受信予約または解除は、個別の作業項目に対して、あるいは、要求が送られる相手の管理役が管轄する全ての作業項目に対して、行えます(DICOM PS 3.4 and PS 3.17の全体通知受信予約(Global Subscription)を参照してください。
DICOM PS 3.4に記載の様に、通知受信予約役は作業項目に削除ロックをかけることができます。作業項目がCOMPLETED、あるいは、CANCELED 状態になると通常は管理役が、削除します。しかし、管理役は、削除ロックが取り除かれるのを遅らせ、通知受信予約役に作業項
目の最終内容の詳細を取得する時間を与えます。
4.86.4.1.1 きっかけ事象
通知受信予約役の使用者、あるいは、自動機能が、一個以上の作業項目（UPSインスタンス）に関連する通知の受信の開始、ないしは、停止をするかを決めます。同様、通知受信予約役の使用者、あるいは、自動機能が、一個以上の作業項目に削除ロックをかけるかを決めます。
DICOM PS 3.4を参照してください。
4.86.4.1.2 通信文の意味
この通信文は、DICOM UPS Watch SOP Class のUPS事例レポート受信予約・予約解除
N-ACTION（Subscribe/Unsubscribe to Receive UPS Event Reports N-ACTION）です。通知」
予約役はSCUで、管理役はSCPです。
削除ロックと全通知受信予約の意味は、DICOM PS3.4 CC.2.3に吉舎愛されています。
管理役は、削除ロックと全通知受信予約を使用可能とせねばなりません。実施役による削除ロ
ックと全通知受信予約の使用は、アプリケーションの性質によります。
_________________________________________________________________________________________

52
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.86.4.1.3 予期される動作管理役は、DICOM PS 3.4 に記された様に、N-ACTION要求に応答し、通知受信予約役に、
成功、失敗の適切なコードを送らねばなりません。
4.86.5 保安の考慮
どの使用者やどのシステムが、作業項目の通知を予約受信する許可を受けるかを現場施設の方針で考慮し、適切に設定できる様にしなければなりません。
4.86.5.1 安全査察の考慮
ATNAプロファイルが使用可能である管理役は、このトランザクションを監査せなばなりません。
この通信は、情報問合わせATNAのきっかけ事象です。
4.87 節を追加します (実行済み作業状態更新トランザクションの変更と拡張）
4.87

4.87.1

UPS 通信の通知[RAD-87]（Send UPS Notification）

範囲

このトランザクションは、任意のUPS作業項目の状態や内容を、通知するのに使用されます。
4.87.2 使用例の役割
このトランザクションの役割は以下の表の様に定義され、ここに示されるアクタで実行されます：

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときだけ、特定されます。
_________________________________________________________________________________________

53
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.87.3 参照する標準DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.17: Unified Worklist and Procedure Step - UPS (Informative)
4.87.4 相互作用図

4.87.4.1 UPS通知送出通信文 Send UPS Notification Message
管理役は通知受信予約役に任意の作業項目が変更されたことを通知します。通知は、基本的な状態と進捗状況を提供します。詳細情報については、通知受信予約役は、UPSインスタ
ンスの内容を取得せねばなりません。
管理役は、一個以上の通知受信予約役のそれぞれに、このような通信を送れなければなりません。通知受信予約役は、通信相手として設定された管理役から、このような通信文を受け取れなければなりません。
DICOM PS 3.4に記された様に、全通知受信予約を通知受信予約役がすることになっている
場合には、個別の通知受信予約が無い作業項目についても、通知を受け取れる様に用意しなければなりません。通知受信予約役は、生成を通知されたときには、特定のイン素担津の津売り受信予約を取り消すこともできます。
同様に、作業項目実施役は、個別の通知受信予約が無い作業項目についても、作業項目実
施役に新しい作業項目が割り当てられたとき、作業項目実施役が取得要求した作業項目のキ
ャンセルの要求がある時、通知を受け取れる様に用意しなければなりません。
4.87.4.1.1

きっかけ事象

数個のきっかけ事象が、UPS通知送出通信文（Send UPS Notification Message）のきっかけになります。
・作業項目の状態と内容が管理役により変更されます。通知が必要な変更にの詳細については、DICOM PS 3.4を参照してください。
・通知受信予約役が、新しい作業項目インスタンス（RAD TF3: 4.86参照）の通知受信を新しく予約したとき。管理役は最初の通知を送り、作業項目の_________________________________________________________________________________________

54
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

現在状況の情報を提供します。
・実行中の作業項目のキャンセル要求を受け付けます。（RAD TF3: 4.88節を参照）。管理役は、通知受信予約役と作業項目の実施役に、キャンセル
要求を通知します。この通知は、以前実施役がこの作業項目の通知受
信予約をしていたかに依存しません。
・作業項目が特定の実施役に（作業項目生成役、あるいは、予定ワークステー
ション名称コード順列の値を設定した管理役により）割り付けられたとき。管理役は割り付けられた実施役に通知します。この通知は、以前実施役がこの作業項目の通知受信予約をしていたかに依存しません。通知を受けた実行役は作業項目取得要求を出せますが、必須ではありません。
4.87.4.1.2

通信文の意味

この通信文は、DICOM UPS Event SOP ClassのUPS状態内レポート変更N-EVENT-REPORT（Report a Change in UPS Status N-EVENT-REPORT）です。
4.87.4.1.3

予期される動作

通知受信予約役は、通知を受けても特別の行動を取る必要はありません。キャンセル要求の通知文の場合には、特に、実行役はキャンセル要求を受け入れる必要はありません。UPSキャ
ンセルについての詳細は、DICOM PS 3.4とPS 3.17ごご覧ください。
通知文に含まれる端的な情報を越える詳細なUPS作業項目内容を取得するために、通知受
信予約役は、Get UPS Workitem Contents を使うこともできます。
4.87.5.1 安全性監査の考慮
このトランザクションはATNAきっかけ事象と関連していません。
4.88節を追加します。（新しいトランザクション）
4.88

UPS 作業項目キャンセル要求 [RAD-88]（Request UPS Workitem Cancelation）

4.88.1 範囲
このトランザクションは、関心を持つアクタが作業項目のキャンセルを要求するのに使用します。
作業項目を実施しているシステムが成功裏にキャンセル要求の通知を受ける保証はありませんし、キャンセルを受け入れる可能性もありません。
作業項目キャンセルの要求を出すシステムは、キャンセル要求に関連する可能なかぎりの詳細を提供することが、推奨されています。キャンセル要求は非同期なため、要求を出すシステ
ムは、自己の要求の結果を知りたい場合には、該当の作業項目に通知することが推奨されています。このトランザクションは、作業項目を実行しているシステムには使用されませんが、これはUPS作業項目完成（Complete UPS Workitem）トランザクション[RAD-85]を使用して作業項
目をキャンセル済状態に変更できるからです。
_________________________________________________________________________________________

55
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.88.2 使用例の役割
このトランザクションの役割は以下の表の様に定義され、ここに示されるアクタで実行されます：

トランザクションの文言はそれぞれの役割の振る舞いを特定します。特定のアクタの振る舞い
は、一般的な役割を越える役割があるときだけ、特定されます。
4.88.3参照する標準DICOM 2011 PS 3.4: Unified Procedure Step Service and SOP Classes
DICOM 2011 PS 3.17: Unified Worklist and Procedure Step - UPS (Informative)
4.88.4 相互作用図

4.88.4.1 UPSキャンセル要求通信文 Request UPS Cancelation Message_________________________________________________________________________________________

56
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

要求役はUPSインスタンスの管理役に、作業項目キャンセルの要求を送ります。この動作は、
どのシステムが問題の作業項目を実施しているかによります。
予定済（SCHEDULED）状態にある作業項目については、管理役がこのキャンセル要求を、
DICOM PS 3.4 Annex CCの様に扱います（すなわち、典型的には、作業項目をIN
PROGRESSにしてから、属性に適切な調整を行いCANCELEDにします。しかし、内部論理によりキャンセル要求を無視することも許されています。）
IN PROGRESS状態の作業項目については、管理役は、UPS通知送出（Send UPS
Notification [RAD-87]）通信文を使用して、作業項目実施役に作業項目のキャンセル要求を通知しようとします。
すでに、CANCELED、あるいは、COMPLETED状態では、要求は失敗します。要求役は、どのシステムが実際に作業しているかを、知る必要はありません。
管理役は複数の要求役からのこの様な通信文を扱えねばなりません。要求役は複数の管理役と作業項目との協働を可能とすることもできます。
4.88.4.1.1 きっかけ事象
要求役の使用者、あるいは、要求役の自動実行機能が、作業項目をキャンセルしたいと思います。
4.88.4.1.2 通信文の意味
DICOM UPS Push SOP Class のUPSキャンセル要求N-ACTION（Request UPS Cancel
N-ACTION）です。要求役がSCUで、管理役がSCPです。
通信文の成功裏の完了は、要求が受信されたことを意味しますが、作業項目がキャンセルされたことを、必ずしも、意味しません。
作業項目がキャンセルされないにせよ、キャンセルされるにせよ、時間がかかります。キャンセ
ルされると、要求役は、作業項目の通知受信予約をしていれば、UPS通知送出通信文（Send
UPS Notification）の形でキャンセルの報告をうけます (RAD TF-3: 4.87節を参照)。
4.88.4.1.3 予期される動作管理役は、DICOM PS 3.4 CC.2.2.3 に記された様に、N-ACTION要求で返答し、要求役に、
成功または失敗のコードを送らねばなりません。管理役は作業項目実施役に4.83節の様に通知せねばなりません。
4.88.5

保安の考慮

現場の方針で、どの使用者やシステムが作業項目の取得要求ができるか決め、適切に設定せねばなりません。
4.89

アプリケーション開始 [RAD-89]（StartApplication）

4.89.1 範囲_________________________________________________________________________________________

57
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

このトランザクションは配下アプリケーションを開始するのに使用されます。
4.89.2

使用例役割

4.89.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for アプリケーション Hosting
DICOM 2011 PS 3.19: アプリケーション Hosting
4.89.4 相互作用図

4.89.4.1 アプリケーション開始通信文 Launch Appicaltion Message
この通信文はアプリケーション開始を先導します。
ホスト（ホスト役システム）は複数のアプリケーションを開始することもできます（同じアプリケーシ
ョンで複数のインスタンスを扱うのを含む）。アプリケーションのインスタンスは一個のホストとしか通信しません。
4.89.4.1.1 きっかけ事象 きっかけ事象
ホストは通常、アプリケーションに割り付けたい業務があるため、アプリケーションを開始したい_________________________________________________________________________________________

58
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________と思います。これは、使用者の要求への返答、内部論理によるきっかけ、ホストと一体化された作業項目実施役が取得要求した作業項目を実行するため、です。
4.89.4.1.2

通信文の意味

この通信文は、DICOM PS3.19に記載された初期化法に従って、アプリケーションの実行ファ
イルを開始する意味を持ちます。
複数の業務を並行実行するために、ホストは複数のアプリケーションの複数のインスタンスを開始することができます；しかし、業務は互いに反応することはありません。
ホストはアプリケーションのそれぞれのインスタンスに対して異なったホストURLを提供する（例
えば、URLに一意のアプリケーションIDを埋め込む）ことがあります。この機構により、ホストはどのインスタンスが接触しているかが簡単にわかります。
4.89.4.1.3 予期される動作
アプリケーションは初期化して、処理に備え、IDLE状態になります。
4.89.4.2

状態通知 ー IDLE通信文

アプリケーションはホストに、処理を行う準備ができたことを伝えます。
ホストは、開始する全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受けられねばなりません。アプリケーションのインスタンス
は一個のホストとのみ通信します。
4.89.4.2.1 きっかけ事象
アプリケーションが初期化を完了します。.
4.89.4.2.2

通信文の意味

この通信文では、DICOM PS3.19に記載されたホストインターフェースのnotifyStateChange()法がアプリケーションにより引き起こされます。
Stateパラメータの値はIDELでなければなりません。
4.89.4.2.3 予期される動作無し
4.89.5保安の考慮

このトランザクションには、DICOM PS 3.19の記載と、4.89.5.1節にあげる監査に関する考察と_________________________________________________________________________________________

59
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________を越える、特別の保安に関する考慮はありません。
4.89.5.1 安全監査の考慮
通常、アプリケーションは監査に関与する必要はなく、責任はホストにあります。
このトランザクションを実行するたびに、「アクタ開始」通信文を生成できねばなりません。
Add section 4.90
4.90

アプリケーション停止 [RAD-90]（Stop Application）

4.90.1 範囲
このトランザクションは配下アプリケーション（hosted Application)を停止するのに使用します。
4.90.2 使用例役割

4.90.3 参照する標準参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for アプリケーション Hosting
DICOM 2011 PS 3.19: Appicaltion Hosting
4.90.4 相互作用図_________________________________________________________________________________________

60
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.90.4.1 要求の状態－終了通信文

Request State - EXIT Message

ホストはアプリケーションを停止する様、要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）を停止できねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.90.4.1.1 きっかけ事象
ホストは通常、アプリケーションに割り付ける業務がないことを予見しているため、IDLE状態の
アプリケーションを停止したいと思います。
4.90.4.1.2

通信文の意味

この通信文では、DICOM PS3.19に記載されたホストインターフェースのsetState()法がアプリケーションにより引き起こされます。Stateパラメータの値はEXITでなければなりません。
4.90.4.1.3 予期される動作
アプリケーションはすべての停止準備を終え、EXIT状態に移行します。
4.90.4.2

状態の通知 － EXIT通信文 Notify State – EXIT Message

ホストに、アプリケーションは停止手続き中であることを知らせます。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.90.4.2.1

きっかけ事象 きっかけ事象_________________________________________________________________________________________

61
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

アプリケーションがEXIT状態に入ります。
4.90.4.2.2 通信文の意味
この通信文では、DICOM PS3.19に記載されたホストインターフェースのnotifyStateChange()法がアプリケーションにより引き起こされます。
Stateパラメータの値はEXITでなければなりません。
4.90.4.2.3予期される動作
アプリケーションは動作を停止します。.
4.90.5 保安の考慮
このトランザクションには、DICOM PS 3.19の記載と、4.90.5.1節にあげる監査に関する考察とを越える、特別の保安に関する考慮はありません。
4.90.5.1 安全監査の考慮
通常、アプリケーションは監査に関与する必要はなく、責任はホストにあります。
このトランザクションを実行するたびに、「アクタ停止」通信文を生成できねばなりません。
4.91節を追加
4.91

アプリケーション前面配置 [RAD-91]（Bring Application Front）

4.91.1 範囲
このトランザクションは、配下アプリケーションにそのグラフィックユーザインターフェース(GUI)のウィンドウを前面に出し（ワークステーションのGUI上で、他のウィンドウで隠されていない状態）、焦点を取得し（使用者入力が制御できる状態にする）、必要に応じて大きさを変更できる
ように、要求します。
4.91.2

使用例の役割_________________________________________________________________________________________

62
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.91.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for アプリケーション Hosting
DICOM 2011 PS 3.19: アプリケーション Hosting 1610
4.91.4 相互作用図

4.91.4.1 前面移動通信文 Bring to Front Message
ホストは、アプリケーションに、主GUIウィンドウの大きさ変更、焦点の取得、典型的には、GUI
ウィンドウの最前面への移動、を要求します。
4.91.4.1.1 きっかけ事象
ホストがアプリケーションの主GUIウィンドウの大きさを変更し、焦点を取得したいと思います。
4.91.4.1.2 通信文の意味 通信文の意味
この通信文では、DICOM PS3.19に記載されたアプリケーションインターフェースのbringToFront()法がホストにより引き起こされます。
_________________________________________________________________________________________

63
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.91.4.1.3

予期される動作アプリケーションがGUIウィンドウを表示した場合、bringToFront()呼び出しで要求されたように、
ウィンドウの大きさを変更し、ウィンドウ重ね順の最上位に持ち出し、GUIの焦点取得できねばなりません。
4.91.5 保安の考慮
このトランザクションには、DICOM PS 3.19の記載と、4.91.5.1節にあげる監査に関する考察とを越える、特別の保安に関する考慮はありません。
4.91.5.1 安全監査の考慮
このトランザクションには監査通信文はありません。
4.92節を追加
4.92

業務開始 [RAD-92]（Start Task）

4.92.1 範囲
このトランザクションは配下アプリケーションに業務を開始するよう指示するのに使用されます。
4.92.2

使用例役割

4.92.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting 1640
DICOM 2011 PS 3.19: APplication Hosting
4.92.4 相互作用図_________________________________________________________________________________________

64
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.92.4.1 要求状態 - INPROGRESS通信文 Request State – INPROGRESS Message
ホストはアップリケーションに業務を開始するよう要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの要求を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
ホストは複数の業務を並行して開始できますが、個々の業務は互いに関係しません。
4.92.4.1.1 きっかけ事象
ホストと一体化された作業項目実施役が作業項目の取得要求をし、作業項目を完成させるのに必要な業務を執行するに適したアプリケーションを、ホストが選択します。ホストが選択した
アプリケーションは、ホストと一体化されている作業項目実行役が提供する詳細に依存します。
詳細は、RAD TF-1:30.1.1.3を参照してください。
4.92.4.1.2

通信文の意味

この通信文では、DICOM PS3.19に記載されたアプリケーションインターフェースのnotifyState()法がアプリケーションにより引き起こされます。
Stateパラメータの値は、INPROGRESSです。
4.92.4.1.3 予期される動作
DICOM PS3.19に記載された制限の中で、アプリケーション業務を遂行する用意をせねばなり_________________________________________________________________________________________

65
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

ません。
アプリケーションの任意の一インスタンスは同時に一個の業務しか行いません。
。
4.92.4.2 状態通知－ 進行中通信文 Notify State – INPROGRESS Message
アプリケーションはホストに、処理が始まったことを知らせます。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.92.4.2.1 きっかけ事象
アプリケーションはホストからの状態をINPROGRESSに変更する要求を受けます。
4.92.4.2.2

通信文の意味

この通信文では、DICOM PS3.19に記載されたホストインターフェースのnotifyStateChange()法がアプリケーションにより引き起こされます。
Stateパラメータの値は、INPROGRESSです。
4.92.4.2.3 予期される動作
ホストはアプリケーションに送信する、使用可能な一連のデータを用意し、アプリケーションが業務を実行するのに必要なあらゆるデータを通知しなければなりません。
ホストと一体化された作業項目実施役はUPS作業項目更新（Update UPS Workitem）[TAD-84]トランザクションを用いて、作業項目を更新せねばなりません。少なくとも、作業項目
実施役は、実行済検査段階開始日時（Performed Procedure Step Start DateTime(0040,0244)）と実行ワークステーション名コード順列（Performed Station Name Code Sequence）の値を入れねばなりません。
4.92.4.3 データ可用通信文 Notify Data Available Message
ホストは、アプリケーションに必要と予期するあらゆるデータを、アプリケーションに通知します。
4.92.4.3.1 きっかけ事象
ホストは、アプリケーションがINPROGRESS状態にあるとの通知を受けます
ホストはこの通信文を、業務の処理のあいだ必要なだけ繰り返して、リスト上の処理すべきデータをアプリケーションに伝えます。
_________________________________________________________________________________________

66
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.92.4.3.2

通信文の意味 通信文の意味

この通信文では、DICOM PS3.19に記載されたデータ交換インターフェースのnotifyDataAvailable()法がホストにより引き超されます。
業務のきっかけとなった統一検査段階SOP（Unified Proceudure Step SOP）インスタンスを参照
するオブジェクト記述子を、一連のAvailableData の根本レベルに、含まねばなりません。オブ
ジェクト記述子のMime 型は "アプリケーション/dicom"、そのClassUID は、“1.2.840.10008.5.1.4.34.6.1”, すなわち、Unified Procedure Step - Push SOP Class UID に、せ
ねばなりません。
追加のオブジェクト記述子は、UPS SOP Instanceの入力情報順列（Input Information
Sequence (0040,4021))にあげられたすべてのインスタンスを参照せねばなりません。
この通信文は、アプリケーションからのgetData要求にホストが応答する用意ができていることを示します。これは、ホストがすべての必要なデータを既に取得し、現場に有していることを必ずしも示しません。ホストはアプリケーションがデータを要求するでまってから、データを取得し、アプリケーションにデータを提供できるようにすることがあります。
4.92.4.3.3 予期される動作
アプリケーションは参照されたオブジェクトを必要なとき、利用します（たとえば、業務詳細取得（Get Task Details ）[RAD- 93] あるいは、業務データ取得（Get Task Data [RAD-94]）。
4.92.4.4 画面通信文取得 Get Screen Message
アップリケーションは、割り当てられた業務の実行のためGUIを持っていることをホストに知らせ、ホストがアプリケーションのGUIのための余白を残しておく様要求します。
4.92.4.4.1 きっかけ事象
アプリケーションは開始した業務の遂行にGUIを使用します。アプリケーションに使用者が活動するGUIやコマンドウィンドウがない場合、アプリケーションはこの通信文を送る必要がありません。
4. 92.4.4.2 通信文の意味
この通信文では、DICOM PS3.19に記載されたホストインターフェースのnotifyDataAvailable()法がアプリケーションにより引き起こされます。
アプリケーションはホストにそれの好みの大きさのウィンドウを提供せねばなりません。
4. 92.4.4.3 予期される動作
ホストは業務にはGUIがあると知り、getAvailableScreen()呼び出しで渡されたヒントを考慮に入_________________________________________________________________________________________

67
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

れて、ふさわしい大きさと位置の業務のGUIをアプリケーションに戻さねばなりません。
アプリケーションは、getAvailableScreen() 呼び出しでホストに返したウィンドウの大きさと位置に、主ウィンドウを設定せねばなりません。
4.92.5 保安の考慮
このトランザクションには、DICOM PS 3.19の記載と、3.92.5.1節にあげる監査に関する考察とを越える、特別の保安に関する考慮はありません。
（訳者注：3.92.5.1節でなく、4.92.5.1節の誤りと思われる）
4.92.5.1 安全監査の考慮
このトランザクションには監査通信文はありません。
4.93節を加えます。
4.93

業務詳細取得 [RAD-93]（Get Task Details）

4.93.1 範囲
このトランザクションは、アプリケーションホスティングのインターフェースを使用してUPS（Unified Procedure Step）インスタンスの内容を取得します。
4.93.2 使用例役割

4.93.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting 1740
DICOM 2011 PS 3.19: Application Hosting
4.93.4 相互作用図_________________________________________________________________________________________

68
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.93.4.1 モデル通信文としてのUPS取得 Get UPS as Model Message
アプリケーションは、業務のきっかけとなった、取得したUPS作業項目からデータを提供する用
意をするよう、ホストに要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの要求を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.93.4.1.1

きっかけ事象アプリケーションが、割り当てられた業務の詳細を必要とします。
4.93.4.1.2 通信文の意味
この通信文では、DICOM PS3.19に記載されたデータ交換インターフェースのgetAsModel()法がアプリケーションにより引き起こされます。
objectUUIDの一連は、UPS SOPインスタンスを参照するオブジェクト記述子の（以前にホストから供給された）UUIDを含まねばなりません。すなわち、オブジェクト記述子のClassUIDは、“1.2.840.10008.5.1.4.34.6.1”に設定されます。
getAsModels() 呼び出しにアプリケーションが与えるclassUIDは、“1.2.840.10008.7.1.1”でなけ
ればなりません。これは、DICOM PS 3.19 Annex A.1に記さされた、原始DICOMモデルのClass UIDです。
注：DICOM PS 3.19は、 原始DICOMモデル以外の方法で、ホスト役システムにデータの提供を配下ア
プリケーションが要求することを禁じていません。たとえば、配下アプリケーションがファイルでデータを要求することがあります。ホスト役システムはこのような要求に応えねばなりません。特に、このプロファイ
ルを知らない配下アプリケーションをホスト役システムに設定する時に必要です。

_________________________________________________________________________________________

69
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

アプリケーションはこのインターフェースを複数回呼び出して、UPSモデルに複数の着手点を取得します。
4.93.4.1.3 予期される動作
ホスト役システムは参照されたUPSインスタンスに ModelSetDescriptors を返し、このモデルに対する問い合わせに応答します。
4.93.4.2 UPSモデル通信文
アプリケーションは、UPS SOPインスタンスから、業務パラメータの様な業務の詳細を要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの要求を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.93.4.2.1 きっかけ事象
UPS SOPインスタンスに在る、ある種の情報を必要とします。
アプリケーションが、getAsModels()呼び出しで戻ったUPS SOPインスタンスのModelSetDescriptor を受け取ることが前提条件です。
4.93.4.2.2 通信文の意味
この通信文では、DICOM PS3.19に記載された、ホスト上のデータ交換インターフェースのqueryModel()法、あるいは、queryInfoset()法がアプリケーションにより引き起こされます。
アプリケーションは、queryModel()、queryInfoset()、あるいは両者を使用可能とすることがあります。ホストは両者を使用可能とせねばなりません。 任意の実施について、アプリケーションのqueryModel() か queryInfoset()かの選択は、getAsModels()呼び出しにより戻された
ModelSetDescriptors内のInfosetType に依存します。
アプリケーションは、UPS SOPに対するモデルのModelSetDescriptorのUUIDと、アプリケーションが探した正確な情報を特定するXPath 宣言文と、を提供します。XPath 宣言文は、DICOM
データセットの根本レベルにある属性を特定するのみとせねばなりません。Get Unified
Procedure Step Information (N-GET)とDICOM PS 3.4 Annex CCに定めるDIMSE Service
Groupにより許可されたものです。
アプリケーションは、アプリケーションに割り付けた業務の実行中に、ホストからの事前データ取得に必要なだけ、この通信文を繰り返すことができます。
4.93.4.2.3 予期される動作_________________________________________________________________________________________

70
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

ホストは要求された情報を、queryModel()インターフェース呼び出しへの返答として、USP SOP
インスタンスから戻せねばなりません。
注

1: ホストと一体化された作業項目実施役は、現場で利用可能な必要な情報を持つことも、 持たないこともあります。たとえば、要求された情報を取得するため、UPS業務項目取得（Get UPS Workitem）[RAD-83]を使用する必要があることもあります。
2. DICOM PS 3.19 は配下アプリケーションがXPath宣言文で要求することを制限していません。たとえば、このトランザクションに合致しない配下アプリケーションは、一個のスラッシュ文字（"/"）
をXPath宣言文に入れ、配下アプリケーションにUPS SOPインスタンスのすべてを取得したいとの要求を暗示的に出すか、DICOMデータセットの根本レベル以下の特定データを要求するか、します。DICOM PS 3.19はまた、配下アプリケーションが原始DICOMモデルを使用することも 制限していません。このトランザクションに合致しない配下アプリケーションは、USP SOPインスタンスをファイルとして要求することもあります。したがって、ホストがこのトランザクションに合致しないアプリケーシ
ョンを採用するなら、ホストはこのような合致しない要求に応答する準備をしなければなりません。UPS SOPインスタンス全体の要求に応える方法には、ホストと一体化された作業項目管理
役がUPS作業項目取得（Get UPS Workitem）[RAD-83]を使用して、UPS IODの最上位属性をすべてリストにし、この情報を、この通信文の応答として、転送する方法があります。

4.93.4.3 UPSモデル解放 Release UPS Model
アプリケーションはホストにモデル内容の利用を終了したことを知らせます。
アプリケーションは別の時期にホストのUPS作業項目の他のモデルを要求することができます。
4.93.4.3.1 きっかけ事象
アプリケーションはUPSモデルのこの着手点を終えます。
4.93.4.3.2 通信文の意味
この通信文では、DICOM PS3.19に記載された、ホスト上のデータ交換インターフェースのreleaseModels()法がアプリケーションにより引き起こされます。
アプリケーションは、解放されるUPS SOPインスタンスのModelSetDescriptor のUIDを提供せ
ねばなりません。
4.93.4.3.3 予期される動作
ホストは、UPSモデルを解放し、モデルに使用されていたすべての資源を解放せねばなければなりません。
4.93.5 保安の考慮
このトランザクションには、DICOM PS 3.19の記載と、4.93.5.1節にあげる監査に関する考察と_________________________________________________________________________________________

71
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________を越える、特別の保安に関する考慮はありません。
4.93.5.1 安全監査の考慮
通常、アプリケーションは監査通信文に関与する必要は在りません。責任はホストにあります。
4.94節を加えます
4.94

業務データ取得 [RAD-94]（Get Task Data）

4.94.1 範囲
このトランザクションはホスト役システムからデータを取得するのに使用します。
4.94.2 使用例役割

4.94.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting
DICOM 2011 PS 3.19: Appication Hosting
4.94.4 相互作用図_________________________________________________________________________________________

72
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.94.4.1 ホストデータ取得通信文 Get Host Data Message
アプリケーションはホストから、アプリケーション業務開始（Start アプリケーション Task）[RAD-92]トランザクションの間に主催役が与えたAvailableData 構造から得た情報で、データを要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの要求を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.94.4.1.1 きっかけ事象
アプリケーションは割り付けられた業務を実施するのに、データを必要とします。 neeアプリケーションが、データのModelSetDescriptorsを主催役から、たとえば、業務開始の時に（Start
Task [RAD-92]を参照してください）、受け取ることが前提条件です。
4.94.4.1.2 通信文の意味
DICOM PS 3.19に記載されたあらゆるデータ交換方法（すなわち、モデル基盤法とファイル基盤法）を使ってこの通信文を実行できます:・アプリケーションは、ホストとアプリケーションの両方が使用可能なモデルクラスで、DICOM PS3.19に記載のように、ホストのgetAsModels() インターフェースを呼び出します・アプリケーションは、ホストから要望するデータを取得する必要があるので、DICOM PS 3.19に記載の様に、ホストのため、 queryModel() 、あるいは、
queryInfoset() インターフェースを呼び出します。
・アプリケーションは、DICOM PS3.19に記載のように、ホストのgetData()インター
フェースを呼び出します。
アプリケーションは複数のインスタンスを取得するため、上記のインターフェースどれかを複数回呼び出し、制限無しにデータ交換法を混在させることもできます。 DICOMでは、ホストがこ_________________________________________________________________________________________

73
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________の3つのインターフェースのすべてを使用可能とし、アプリケーションが選択する方法を使うのを許しています。
A given logical instance of an アプリケーションの任意の論理的インスタンスは、一度に一個の業務しか実行できません。このため、業務と関連するデータを要求するのみです。
4.94.4.1.3 予期される動作
ホストは要求されたデータを、DICOM PS 3.19に記載の様に、インターフェースの呼び出しに応じてアプリケーションに提供せねばなりません。
4.94.4.2

ホストデータ解放通信文 Release Host Data Message

アプリケーションは、Get Host Data通信文で要求したモデルやデータポインタをもはや必要としないことをホストに知らせます。
アプリケーションは、アプリケーションが割り当てられた業務を完成するまで（すなわち、トラン
ザクションがCOMPLETED状態になるまで）の間、しばらく後に再度データを要求することができます。
4.94.4.2.1 きっかけ事象
アプリケーションは、データ参照やモデルの仕様を終えます。
4.94.4.2.2 通信文の意味
この通信文では、DICOM PS3.19に記載されたホストのデータ交換インターフェースのreleaseData()法、あるいは、releaseModels()法がアプリケーションにより引き起こされます。
データを解放するためアプリケーションは、解放するデータ参照のUUIDを提供し、
releaseData() 法を実施しなければなりません。
モデルを解放するためアプリケーションは、解放するモデルのUUIDを提供し、releaseModel()法を実施しなければなりません。
アプリケーションが単一の業務に対してIDLE状態に入り、暗黙的なモデルとデータ参照の解放まで、アプリケーションは待つこともあります。通常、「善良な市民」は、資源の消費を最小にするために、モデルとデータ参照をできる限り早く解放すると思われます。
4.94.4.2.3 予期される動作
ホストは、すべてのモデルとデータ参照を解放し、使用している資源を自由にしなければなりません。
4.94.5 保安の考慮
このトランザクションには、DICOM PS 3.19の記載と、4.94.5.1節にあげる監査に関する考察とを越える、特別の保安に関する考慮はありません。
_________________________________________________________________________________________

74
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.94.5.1 安全監査の考察
アプリケーションは、監査通信文に関与する必要はなく、責任はホストにあります。
ホストは、必要なデータ利用とデータ保存を扱う監査通信文をすべて生成できねばなりません。
4.95節を追加
4.95 業務状態通知

4.95.1[RAD-95]（Notify Task Status）

範囲

このトランザクションは、割り付けられた業務の処理中に起こった注目すべき事象をホスト役シ
ステムに知らせます。
事象は、進捗状況報告の様な情報であったり、警告、エラー報告であったりします。
4.95.2

使用例役割

4.95.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting 1915
DICOM 2011 PS 3.19: Application Hosting
4.95.4 Interaction Diagram_________________________________________________________________________________________

75
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.95.4.1 業務状態通知通知文
アプリケーションは、割り付けた業務の処理中に起こった注目すべき事象をホスト役システムに知らせます。
4.95.4.1.1 きっかけ事象
アプリケーションに、ホストに知らせるべき事象があります。この様な事象には、進捗状況報告、
エラー報告、割り当てられた業務の中止などがあります。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの要求を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.95.4.1.2 通信文の意味
状態通知通信文は、DICOM PS 3.19に記載されたように、下記のアプリケーションホスティングの相互作用を含みます：・アプリケーションが与えられた業務を処理するとき、進捗状況や、ホストに意味のありそうな他の事象を、DICOM PS 3.19 notifyStatus()インターフェースを通じて、周期的に報告します。
・アプリケーションが業務の処理を完成できないとき（すなわち、業務の中止）、業務を完成できない理由を示す状態とともに、notifyStatus()呼び出しをホストに送らねばなりません。次いで、DICOM PS 3.19の要求に従い、CANCELED状態、最後にIDLE状態に移行します。
4.95.4.1.3 予期される動作
ホストは、必要に応じて、状態を記録、あるいは・または、使用者に通知します。
ホストと一体化された作業項目実施役は、UPS作業項目更新[RAD-84]トランザクションを使用
し、受信した状態情報に基づいて、UPS作業項目を必要に応じて更新します。
_________________________________________________________________________________________

76
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

もしアプリケーションが業務を中止（すなわち、アプリケーションがエラー状態通知を発行し、
CANCELED状態からIDEL状態に移行）すると、ホストと一体化された作業項目実施役は、自身の裁量で、作業項目取得要求をキャンセル（すなわち、UPS作業項目完了[RAD-85]トランザクションを使って）します。あるいは、作業項目を完成させるべく、他のアプリケーションで業務を開始するなどの、別の適切な行動をとります。
4.95.5 保安の考慮
このトランザクションには、DICOM PS 3.19の記載と、4.95.5.1節にあげる監査に関する考察とを越える、特別の保安に関する考慮はありません。
4.95.5.1 安全監査の考慮
アプリケーションは、監査通信文に関与する必要はなく、責任はホストにあります。
ホストは、アプリケーションがCACELED状態に移行したときには、アクタ停止（Actor Stop）の監
査通通信文を生成できる能力がなければなりません。ついで、状態通知（Notify Status）後にIDLE状態に移行します（すなわち、エラーのため、アプリケーショが中止されます）。
4.96節を追加します。
4.96

4.96.1

業務結果通知 [RAD-96]（Notify Task Results）

範囲

このトランザクションは、配下アプリケーションが自身に割り付けられた業務を処理して生成し、保存に使えるデータを持つことを、ホスト役システムに知らせるのに使います。
4.96.2 使用例役割_________________________________________________________________________________________

77
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.96.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting
DICOM 2011 PS 3.19: Application Hosting
4.96.4 相互作用図

4.96.4.1

データ可用通知通信文 Notify Data Available Message

アプリケーションは、アプリケーションが業務を処理して出力データを作成し、ホストがこの出力を取得するのを待っていることを、ホストに知らせます。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.96.4.1.1 きっかけ事象
アプリケーションは業務を処理して出力データを用意し、ホストが取得できる状態にあります。
4.96.4.1.2 通信文の意味
この通信文では、DICOM PS3.19に記載されたホストのデータ交換インターフェースのnotifyDataAvailable()法がアプリケーションにより引き起こされます。
アプリケーションは、AvailableData構造を結果データへの参照で埋めねばなりません。
アプリケーションは、ホストへ送るデータを準備するなかで、ホストインターフェースのgenerateUID()法、あるいは、getOutputLocation()法 を引き起こすことができます。
アプリケーションは、これらの方法を、notifyDataAvailable()の前でも後でも引き起こせます。
アプリケーションは、業務の実行中に何回でも notifyDataAvailable()法を使えます。
4.96.4.1.3 予期される動作_________________________________________________________________________________________

78
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

ホストは、アプリケーションから受けたAvailableData構造のデータ参照の記録をとらねばなりません。
ホストには、参照されたデータの全てを（Get Task Results [RAD-97]を使って）取得し保存する
責任があります。しかし、取得するタイミングはホストに任されています。
4.96.5保安の考慮

このトランザクションには特別の保安に関する考慮はありません。
4.96.5.1 安全監査の考慮
このトランザクションには、監査通信文は予期されていません。
4.97節を加えます。
4.97

4.97.1

業務結果取得 [RAD-97]（Get Task Results）

範囲

このトランザクションは、ホスト役システムが配下アプリケーションからデータを取得するのに使います。
4.97.2

使用例の役割

4.97.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting
DICOM 2011 PS 3.19: Application Hosting
4.97.4 相互作用図_________________________________________________________________________________________

79
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.97.4.1 アプリケーションデータ取得通信文
ホストはアプリケーションに要求してデータをアプリケーションから受け取ります。
アプリケーションの論理的インスタンスは、同時には一個の業務しか実行できないため、その業務に関連するデータしか提供できません。
ホストは、アプリケーションの複数のインスタンスを同時に開始して複数の業務を並行して実行できるため、これらのすべての業しかし、からデータを引き寄せ、並び替え、保存できるよう備
えねばなりません。しかし、これらの業務はお互いに相互作用することはありません。
4.97.4.1.1 きっかけ事象
ホストは出力データを取得し保存する準備ができています。
ホストはアプリケーションから使用可能な出力データの記載を受け取っている（すなわち、一個以上の業務結果通知（Notify Task Results）[RAD-96] トランザクションによる）ことが前提です。
4.97.4.1.2 通信文の意味
アプリケーションが使用可能とする、DICOM PS 3.19に記載されたデータ交換方法の、どれを使用しても（すなわち、モデル基盤法、あるいは、ファイル基盤法）、以下が実行できます。；
・ホストは、アプリケーションのgetAsModels()インターフェースを、ホストとアプリケーシ
ョンの両者が使用可能な、どのモデルクラスについても、DICOM PS 3.19に記載された様に、呼び出します。
・ホストは、アプリケーションのqueryModel()、あるいは、queryInfoset()インターフェースを必要に応じ、DICOM PS 3.19に記載された様に呼び出して、要望するデータをホストから取得します。
・ホストは、アプリケーションのgetData() インターフェースを必要に応じ、DICOM PS
3.19に記載された様に呼び出して、モデルのひとかたまりのデータないしはフィイル
基盤データをホストから取得します。
ホストは、これらのインターフェースのどれでも複数回呼び出してデータの複数のインスタンスを取得しますが、アプリケーションが、使用可能にするデータ交換方法を混ぜて使うことがあり_________________________________________________________________________________________

80
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

ます。DICOM PS 3.19によれば、アプリケーションはこれらの方法のをどれか一つを使用可能とすれば良いですが、アプリケーションでどの方法が使用できるかを見極めるのはホストに任されています。ホストはこれら三つの方法を使用可能である必要があります。
4.97.4.1.3 予期される動作
アプリケーションは、DICOM PS 3.19に記載された様に、インターフェースの呼び出しに応答して、要求されたデータをホストに提供せねばなりません。データを生成あるいは用意している
間に、アプリケーションは、必要に応じて、ホストのgenerateUID()、あるいは、
getOutputLocation() インターフェースを呼び出すことができます。
ホストと一体化された作業項目実施役は、データを受けたら、保存する責任があります（たとえば、エビデンス書類保存済（Evidence Documents Stored ）[RAD-43] トランザクション、あるいは、生成役書類保存済（Creator Images Stored）[RAD-18] トランザクションを使って）。しかし保存のタイミングは作業項目実施役に任されます。
ホストと一体化された作業項目実施役は、UPS作業項目のOutput Information Sequence(0040,4033) を、保存されたデータの取得情報で更新する責任もあります。
4.97.4.2 アプリケーションデータ解放通信文
ホストはアプリケーションに、Get Application Data通信文で要求したモデルやデータポインタがもはや必要でないことを、知らせます。
ホストは、いったんアプリケーションデータを解放した後では、アプリケーションのデータを要求しないように、設計されねばなりません。
4.97.4.2.1 きっかけ事象
ホストはデータ参照やモデルの使用を終えます。
4.97.4.2.2 通信文の意味
通信文は、アプリケーションのデータ交換インターフェースのreleaseData() 方法、あるいは、
releaseModels() 方法を、DICOM PS 3.19に記載された様に、ホストが引き起こします。
データを解放するには、ホストは解放するデータ参照のUUIDを提供し、releaseData()方法を引き起こします。
モデルを解放するには、ホストは解放するモデルのUUIDを提供し、releaseModel()方法を引き起こします。
ホストは、アプリケーションが単純な業務でIDLE状態に入ると、ホストは全てもモデルとデータ
参照の暗示的解放を待つことがあります。通常、「善良な市民」はモデルとデータを可能な限り早く解放して、資源の使用を最小限に保ちます。これは、業務執行の間に大量のデータを生_________________________________________________________________________________________

81
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

成するアプリケーションでは、ことにそうです。
4.97.4.2.3 予期される動作
アプリケーションは、モデルとデータ参照を解放して、使用されたあらゆる資源を解放せねばなりません。
4.97.5 保安の考慮
このトランザクションには、DICOM PS 3.19の記載と、4.97.5.1節にあげる監査に関する考察とを越える、特別の保安に関する考慮はありません。
4.97.5.1 安全監査の考慮
アプリケーションは、監査通信文に関与する必要はなく、責任はホストにあります。
ホストは、データ利用とデータ保存を扱う、必要な監査通信文をすべて生成できねばなりません。

4.98節を加えます。
4.98

業務完了通知 [RAD-98]（Notify Task Complete）

4.98.1 範囲
このトランザクションは、配下アプリケーションがその割り当てられた業務を完成したことをホスト役システムに伝えます。
4.98.2

使用例役割

4.98.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting 2090
DICOM 2011 PS 3.19: Application Hosting_________________________________________________________________________________________

82
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.98.4 相互作用図

4.98.4.1 状態変更通知–COMPETED通信文 Notify State Change – COMPLETED Message
アプリケーションは、業務の処理を完成した（ホストが出力データの取得の完了待っている）ことをホストに伝えます。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受けとれねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.98.4.1.1 きっかけ事象
アプリケーションは処理を終了し、ホストから追加のデータが来ないとの指示をホストから受けています。
アプリケーションが割り当てられた業務の処理中に出力を生成したら、アプリケーションは業務結果通知（Notify Task Results） [RAD-96] トランザクションを実行し、さらに、
notifyDataAvailable()インターフェース呼び出しのlastDataflagをTRUEにすることを前提にしています。
4.98.4.1.2 通信文の意味
この通信文では、ホストインターフェースのnotifyStateChange() 方法が、DICOM PS 3.10に記載された様に、アプリケーションにより引き起こされます。
Stateパラメータの値は、COMPETEDでなければなりません。
4.98.4.1.3 予期される動作
ホストは、アプリケーションをIDLEにする（業務終了（Finalize Task）[RAD-99]）トランザクションを使用）責任を持ちます。しかし、実施のタイミングはホストの任意です。アプリケーションを
IDLEにするとアプリケーションはデータをできなくするため、ホストは、最初に、残っている結果を取得する(業務結果取得（Get Task Results） [RAD-97] トランザクション使用)必要がある
こともあります。
_________________________________________________________________________________________

83
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

業務の完成が、関連する作業項目を終了させる場合は、ホストと一体化された作業項目実施
役には、作業項目管理役に通知する（UPS作業項目完了（Complete UPS
Workitem）[RAD-85]トランザクションを使用）責任があります。しかし、タイミングは作業項目実施役に任されます。作業項目実施役は結果を保存、および・または、作業項目内容を更新する必要があることがあります。
4.98.5保安の考慮

このトランザクションには、特別の保安に関する考慮はありません。
4.98.5.1 安全監査の考慮
このトランザクションには監査通信文はありません。
4.99節を加えます。

4.99

業務終了 [RAD-99]（Finalize Task）

4.99.1 範囲
このトランザクションは、アプリケーションに残っている、業務で使われた資源をすべて解放し、IDLE状態にする様要求するのに使用されます。
4.99.2

使用例役割

4.99.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting
DICOM 2011 PS 3.19: Application Hosting
4.99.4

相互作用図_________________________________________________________________________________________

84
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.99.4.1 状態要求 ― IDLE 通信文

Request State – IDLE Message

ホストは、アプリケーションに業務の終了処理を行うよう要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）に要求を送れねばなりません。アプリケーションのインスタンスは一個のホ
ストとのみ通信します。
4.99.4.1.1 きっかけ事象
ホストは、he Host has received notification that the アプリケーションの業務がCOMPLETED状態との通知(トランザクション[RAD-98]) を受けとり、ホストは業務の処理からの関連する出力を取得します。
4.99.4.1.2 通信文の意味
この通信文では、アプリケーションインターフェースのsetState() 方法が、DICOM PS 3.19に記載された様に、ホストにより引き起こされます。
State パラメータの値は、IDLEでなければなりません。
4.99.4.1.3 予期される動作
アプリケーションは、業務の処理に使用された資源を解放し、次の業務処理の要求を受けられる様に、準備せねばなりません。
アプリケーションは IDLE状態に入り（ホストにそのように伝えます）、次の業務要求を待ちます。
4.99.4.2

状態の通知― IDEL通信文 Notify State – IDLE Message

アプリケーションは、業務の終了処理を終え、追加の業務を受ける準備ができていることを、ホストに知らせます。
_________________________________________________________________________________________

85
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受けとれねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.99.4.2.1 きっかけ事象
アプリケーションは IDLE 状態になります。
4.99.4.2.2 通信文の意味
この通信文では、ホストインターフェースのnotifyStateChange()方法が、DICOM PS 3.19に記載された様に、アプリケーションにより引き起こされます。
Stateパラメータは IDLE でなければなりません。
4.99.4.2.3 予期される動作
ホストは:・アプリケーションが他の業務（たとえば、ホストと一体化した作業項目実施役が取得要求した他のUPS作業項目）を行う様、要求します、・将来の業務要求に備えてアプリケーションを予約し抱えておきます、あるいは、・アプリケーションに、アプリケーション停止（Stop Application）[RAD-90] トランザクシ
ョンを使って、抜け出るよう要求します
4.99.5保安の考慮

このトランザクションには、DICOM PS 3.19の記載と、4.99.5.1節にあげる監査に関する考察とを越える、特別の保安に関する考慮はありません。
4.99.5.1 安全監査の考慮
アプリケーションは、監査通信文に関与する必要はなく、責任はホストにあります。
ホストは、データ利用とデータ保存を扱う、必要な監査通信文をすべて生成できねばなりません。
4.99.5.1 安全監査の考慮
このトランザクションには監査通信文はありません。

4.100節を加えます。
4.100

業務の取り消し [RAD-100]（Cancel Task）

4.100.1 範囲_________________________________________________________________________________________

86
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

このトランザクションは、配下アプリケーションでの業務処理を取り消すのに使われます。
4.100.2

使用例の役割

4.100.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting
DICOM 2011 PS 3.19: Application Hosting
4.100.4 相互動作図

4.100.4.1 状態要求― CANCELED通信文 Request State – CANCELED Message
ホストは、アプリケーションに業務を取り消すよう要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの取り消しを実行できねばなりません。アプリケーションのインスタンス
は一個のホストとのみ通信します。
_________________________________________________________________________________________

87
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

t4.100.4.1.1 きっかけ事象
ホストは業務の処理を中止したいと思います。プリケーションは、 INPROGRESS、または、
SUSPENDED状態であることが前提です。
これは、たとえば、使用者の要求に応えて、あるいは、ホストと一体化された作業項目実施役が受信したUPS通知送信（Send UPS Notification） [RAD-87] トランザクションに応えて、作業
項目の取り消しが要求されたことを示すことができます。この様な要求に応えるかどうかは作業
項目実施役に任されています（すなわち、ホストは必ずしも要求状態―中止（Request State –CANCELED）通信文を送る様に強制されない）。
4.100.4.1.2 通信文の意味
この通信文では、アプリケーションインターフェースのsetState() 方法が、DICOM PS 3.19に記載された様に、ホストにより引き起こされます。
Stateパラメータは CANCELEDでなければなりません。
4.100.4.1.3 予期される動作
アプリケーションは、業務の執行を止め、CANCELED 状態にし（ホストにも同様に通知）、資源を解放し、IDLE状態に移動しなければなりません。
アプリケーションが、ホストのCANCELEDから適宜IDLE状態への移動要求に応えない場合、ホストは自身の裁量で、言うことを聞かないアプリケーションを他の動作をとって止めます。この動作の本質は実装によります。
4.100.4.2

状態通知―

CANCELED 通信文 Notify State – CANCELED Message

このアプリケーションは、業務の執行を中止する処理を行っていることをホストに知らせます。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受けとれねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.100.4.2.1 きっかけ事象
このアプリケーションは CANCELED 状態に入ります。
4.100.4.2.2 通信文の意味
この通信文では、ホストインターフェースのnotifyStateChange()方法が、DICOM PS 3.19に記載された様に、アプリケーションにより引き起こされます。
_________________________________________________________________________________________

88
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

Stateパラメータの値はCANCELEDでなければなりません。
4.100.4.2.3 予期される動作ありません。
4.100.4.3 状態通知 ― IDEL通信文

Notify State – IDLE Message

このアプリケーションは、要求されれば、別の業務を始める準備ができていることをホストに知らせます。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受け取れねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.100.4.3.1 きっかけ事象
アプリケーションは IDLE 状態に入ります。
4.100.4.3.2 通信文の意味
この通信文では、ホストインターフェースのnotifyStateChange()方法が、DICOM PS 3.19に記載された様に、アプリケーションにより引き起こされます。
State パラメータの値は IDLEでなければなりません。.
4.100.4.3.3 予期される動作
ホストは；・request that the アプリケーションが（たとえば、ホストと一体化された作業項目実施
役が取得要求した他のUPS作業項目から）他の業務を処理するよう、要求する、
・アプリケーションを、将来の業務処理依頼に備えて、予約し抱えておく、あるいは、・アプリケーションに、アプリケーション停止（Stop Application）[RAD-90] トランザクシ
ョンを使って、抜け出るよう依頼する
ホストと一体化された作業項目実施役が、取得要求した作業項目の処理を完成させるため、業務を再スタートさせる計画が無いなら、作業項目をCANCELED（すなわち、UPS作業項目
完了[RAD-85]トランザクション）にせねばなりません。T作業項目実施役は、DICOM最終状態
要求事項（Final State Requirements）を満たすため、最初にUPS作業項目更新（Update UPS
Workitem）[RAD-84] トランザクションを使用する必要があることがあります。
4.100.5 保安の考慮
このトランザクションには、DICOM PS 3.19の記載と、4.100.5.1節にあげる監査に関する考察とを越える、特別の保安に関する考慮はありません。
_________________________________________________________________________________________

89
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.100.5.1 安全監査の考慮
このトランザクションには監査通信文は在りません。
アプリケーションは、監査通信文に関与する必要はなく、責任はホストにあります。

4.101節を加えます。
4.101 アプリケーション一時停止[RAD-101]（Suspend Application）

4.101.1 範囲
このトランザクションは動いているアプリケーションを一時停止するのに使用します。このトランザクションはホストがINPROGRESS状態の時のみ、起こります。
4.101.2

使用例役割

4.101.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Application Hosting
DICOM 2011 PS 3.19: Application Hosting
4.101.4 相互関係図_________________________________________________________________________________________

90
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.101.4.1 状態要求 － 一時停止通信文 Request State – SUSPENDED Message
ホストは、アプリケーションが業務の処理を一時停止するよう要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）へ要求を送れねばなりません。アプリケーションのインスタンスは一個のホ
ストとのみ通信します。
4.101.4.1.1 きっかけ事象
ホストは処理中の業務の一時停止をしたいと思います。
これは、たとえば、使用者の一時停止要求への、応答のことがあります。あるいは、他のアプリ
ケーションで行う、より優先度の高い業務のために、業務を止めて資源を解放するために起こることもあります。
4.101.4.1.2 通信文の意味
この通信文では、アプリケーションインターフェースのsetState()方法が、DICOM PS 3.19に記載された様に、ホストにより引き起こされます。
Stateパラメータの値は、SUSPENDEDでなければなりません。
4.101.4.1.3 予期される動作
アプリケーションは、できる限り速く、業務執行の論地的中止点を見つけ、SUSPENDED状態
を挿入せねば在りません。アプリケーションは、SUSPENDED状態にいる間、一時停止の部位から業務を再開のため必要な状況を失うことなく、可能な限り多くの資源を解放せねばなりま
せん。
アプリケーションがINPROGRESS状態であることが前提です。
アプリケーションの任意のインスタンスは同時に一個の業務のみを一時停止にします。
_________________________________________________________________________________________

91
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

アプリケーションは業務を、可能な限り少量の資源を使用して、ホストが再開（Resume
Application）[RAD-102]トランザクション）、あるいは、取り消す（業務キャンセル（Cancel Task）[RAD-100]トランザクション）まで、SUSPENDED状態に保ちます。
4.101.4.2 状態通知 – 一時停止通信文 Notify State – SUSPENDED Message
アプリケーションはホストに、業務の処理を一時停止したことを知らせます。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）からの通知を受けられねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.101.4.2.1 きっかけ事象
アプリケーションはSUSPENDED 状態に入ります。
4.101.4.2.2 通信文の意味
この通信文では、ホストインターフェースのsetState()方法が、DICOM PS 3.19に記載された様に、アプリケーションにより引き起こされます。
Stateパラメータの値、SUSPENDEDでなければなりません。
4.101.4.2.3 予期される動作
None, although the Workitem Performer grouped with the Host might choose to update theprogress details of the associated workitem to reflect that work is currently suspended.
2315
4.101.5 保安の考慮
このトランザクションには、特別の保安に関する考慮はありません。
4.101.5.1 安全監査の考慮
このトランザクションには監査通信文はありません。
4.102節を加えます。
4.102

アプリケーション再開 [RAD-102]（Resume Application）

4.102.1 範囲
このトランザクションは、一時停止されている、配下アプリケーションでの業務の処理を再開するのに使われます。
4.102.2

使用例役割_________________________________________________________________________________________

92
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

4.102.3 参照する標準DICOM 2011 PS 3.17: Annex XX Use Cases for Hosting 2330
DICOM 2011 PS 3.19: Application Hosting
4.102.4 相互関係図

4.102.4.1 状態要求 － INPROGRESS通信文 Request State – INPROGRESS Message
ホストは、一時停止された業務の再開を要求します。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）へ要求を送られねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.102.4.1.1 きっかけ事象
ホストは、一時停止になっている業務を再開したいと思います。
これは、たとえば、操作者の要求への応答であることがあります。
4.102.4.1.2 通信文の意味_________________________________________________________________________________________

93
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

この通信文では、アプリケーションインターフェースのsetState()方法が、DICOM PS 3.19に記載された様に、ホストにより引き起こされます。
Stateパラメータの値は、INPRORESSでなければなりません。
4.102.4.1.3 予期される動作
アプリケーションは、INPROGRESS状態に入り、業務の執行を再開せねばなりません（必要に応じ、業務データの再入手が含まれます）。
It is a pre-requisite that the アプリケーションがSUSPENDED 状態であるのが前提です。
4.102.4.2

状態通知 – INPROGRESS 通信文

Notify State – INPROGRESS Message

アプリケーションは、ホストに、業務の処理を再開したことを知らせます。
ホストは開始した全てのアプリケーションの全てのインスタンス（同じアプリケーションの複数のインスタンスを含む）へ要求を送られねばなりません。アプリケーションのインスタンスは一個のホストとのみ通信します。
4.102.4.2.1 きっかけ事象
アプリケーションが、INPROGRESS 状態に入ります。
4.102.4.2.2 通信文の意味
この通信文では、ホストインターフェースのnotifyStateChange()方法が、DICOM PS 3.19に記載された様に、アプリケーションにより引き起こされます。
Stateパラメータの値は、INPRORESSでなければなりません。
4.102.4.2.3 予期される動作ありません。しかし、ホストと一体化された作業項目実施役は、関連する作業項目の進捗の詳細を、作業が再開されたことを反映するため、更新することもあります。
4.102.5 保安の考慮
このトランザクションには特別の保安に関する考慮はありません。
4.102.5.1 安全監査の考慮
このトランザクションには監査通信文は在りません。
_________________________________________________________________________________________

94
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)___________________________________________________________________________________________________________________________________________________________________________________________________________________________________

95
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

以下の新しい付録を加えます。
付録 W: 生成中の UPS 作業項目属性値入力

Populating UPS Workitem Attributes during Creation
この付録は、UPS作業項目をいくつかの状況で生成するとき、以下に属性値を入れるかを記
載します：
・追加 – 新しい作業項目は、古い既存UPS作業項目に作業を追加したものです。
一部の新作業項目の新しい属性値は、関連する古い作業項目からコピーしたものです。
・特別 – 新しい作業項目は、関連する既存の検査（Study）と関連し、既存の作業項
目とは関連のないものです。新しい作業項目の一部の属性は、関連する入力データからコピーされたものです。
以下の表に、すべての1型属性と、多くの重要な2型属性を列挙します。
空白の欄は、該当する列の先頭においたソースに存在する値からは得られません。
表 W-1: 生成された作業項目の属性値
Table W-1: Populating UPS Workitem Attributes during Creation_________________________________________________________________________________________

96
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

注1:

新しい作業項目が以前のUPS業務の繰り返し、連続、あるいは、追加データの処理、を含む場
合は、予定業務項目コード順列（cheduled Workitem Code Sequence）をコピーするのが適切なことがあります。

2. このプロファイルは、入力準備状態（Input Readiness State）が、生成時にはREADYであるよう制限しています。
3. 入力情報順列（Input Information Sequence）は、作業項目の入力として使われるDICOM インスタン
スのリストであるため、選択・処理されたデータのインスタンスUID属性から、技術的にコピーされます。
4. 一般に、これらの値をコピーするのは合理的です。しかし、コピーする値に数個の可能性がある場合があります。（たとえば、予定業務流れ群化ケース（Scheduled Workflow Group Case）、ある
いは、特別業務が複数検査からの入力をまとめる場合）。アプリケーションはこのような例をどう扱うかについて、明白にせねばなりません（たとえば、操作者に尋ねる、新しい検査を生成するとか最新の入力検査を使うなどの内部論理、例外として停止する、など）。

_________________________________________________________________________________________

97
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

以下の新しい付録を加えます。
付録 V:

UPS と結果生成物の複合 IOD の整合

Attribute Consistency between UPS and Resulting Composite IODs
この付録は、取得後業務流れ（Post-Acquisition Workflow）プロファイルで生成された結果オ
ブジェクトの属性に値を入れる際の要求事項を提供します。特に、実行される作業項目から生成するオブジェクトの属性に、UPSから提供される属性のどれを変更しないで入れるかを特定します。
表に、要求事項やガイドが提供されている属性が、列挙されています。ガイドが提供されない
属性は表から省かれていますが、省かれている属性を結果のインスタンスから省略すべきことを意味しません。
“ソース（Source）”は、属性値の源を示します。”コピー(Copy)”は、属性値がコピーされる先のオブジェクトをしまします。もし同じ列・属性からコピーされない場合、欄はどこからコピーする
かをより細かに指示します。“イコール(Equal)” は、列の両方の欄は、作業項目実施役（Workitem Performer）により埋められ、両者同じ値でなければなりません。もし同じ列・属性にに等しくない場合は、欄はどの属性に等しいかをより詳細に示します。
UPS作業項目（UPS Workitem）から属性値をコピーするのが、以下に示すように、大部分の重要な属性に対して定められた振る舞いです。源のUPS作業項目（UPS Workitem）で値の無い属性の場合は、実装では、入力情報順列（Input Information Sequence (0040,4021)）にあげられた適切なインスタンスから対応する値をコピーすることを考慮します。
表V-1: UPS属性と結果のIODとの対応付け
Table V-1: Mapping UPS attributes to Resulting IODs_________________________________________________________________________________________

98
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)___________________________________________________________________________________________________________________________________________________________________________________________________________________________________

99
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)___________________________________________________________________________________________________________________________________________________________________________________________________________________________________

100
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________

注

1: Other Patient IDs (0010,1000) は、Other Patient IDs Sequence (0010,1002) と冗長で、個々のPatient IDに発行権限者の伝達を許さないので、不十分です。これに対応して、Other Patient IDs
Sequence (0010, 1002) のみが、UPS作業項目インスタンスに存在します。
2. Study Instance UID (0020,000D) はこの表で2回出現します。単純な例では両者は同じですが、それでも、必要な際には両者が異なることは許されています。たとえば、群化撮影例（訳者注：複数オーダをまとめて、一回の撮影で済ませた例）に属するデータセットに後処理を行う、などです。参照要求順列（Referenced Request Sequence）内で入れ子になっている値は、源泉の要求から取られたものです。入
れ子でない値は、結果オブジェクトが割り付けられる検査（study）を示します。
3. Zero-Lenght Accession Number （DICOM PS 3.17 Annex Jで提案されたオプションのひとつです）は、
信頼の置ける値がこの属性について、手にはいらないとき使用せねばなりません。信頼できる値とは、用手入力以外の方法で伝達できる値のことです。たとえば、UPS作業項目を通して作業項目管理役から受け取った値（アクセッション番号（Accession Number）を含む）、撮影機機器業務一覧（Modality
Worklist）を通してオーダ実行役から、あるいは、バーコードリーダから受け取った値、です。
4. 実行済ステーション名コード順列（Performed Station Name Code Sequence (0040,4028)）内にある、_________________________________________________________________________________________

101
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework Supplement – Post-Acquisition Workflow (PAWF)__________________________________________________________________________________________________________________________________________
作業項目のコード意味（Code Meaning）を、ステーション名（Station Name (0008,1010)に対応付けます。
5. コード順列の構造は等しくありませんが、対応付けは自明です。
6. UPSインスタンスのSOP Instance UID は、UPS N-Create 通信文のAffected SOP Instance UID(0000,1000)のなかと、および、UPS N-Set あるいはUPS N-GET通信文のRequested SOP Instance UID(0000,1001)のなかと、で送られます。C-FIND応答識別子（C-FIND Response Identifier）のReferenced
SOP Instance UID (0008,1155)のなかにもあります。SOP Instance UID (0008,0018) は使用してはなりま
せん。

_________________________________________________________________________________________

102
Rev. 1.1 – 2012-06-15

Copyright © 2012: IHE International, Inc.