JAHIS
Integrating the Healthcare Enterprise

IHE 消化器内視鏡
テクニカルフレームワーク
Year 1: 2005-2006（上部消化管）
Volume I
統合プロファイル
本書は、IHE 循環器テクニカルフレームワーク第 1.0 版トライアルインプリメント版を雛形として IHE-J 内視鏡プロジェクトのためにプロジェクトメンバー有志により作成したものである。作成に際しては、出来るだけ既存 IHE テクニカルフレームワークと合わせるよう心がけ
たが、分野適応で必ずしも共通でない場合などもある。疑問点については、分野比較による十分な確認をお願いしたい。

第 1.0 版
パブリックコメント版
公開日: 2005 年 12 月 28 日

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
目次
まえがき.........................................................................................................................................3
1 序文..........................................................................................................................................4
1.1 テクニカルフレームワークの概要 ............................................................................... 4
1.2 Volume I の概要 ............................................................................................................... 4
1.3 対象読者 ........................................................................................................................... 4
1.4 標準との関係 ................................................................................................................... 5
1.5 実際のアーキテクチャとの関係 ................................................................................... 5
1.6 表記規則 ........................................................................................................................... 6
1.6.1 アクタおよびトランザクションの図と表 ................................................................... 6
1.6.2 プロセスフロー図 ........................................................................................................... 6
1.6.3 テクニカルフレームワークの規約的内容と参考的内容 ........................................... 6
1.6.4 テクニカルフレームワークの参照 ............................................................................... 7
1.6.5 トランザクションの参照 ............................................................................................... 7
1.7 IHE 内視鏡分野の今年度の範囲.................................................................................... 7
1.8 コメント ........................................................................................................................... 7
1.9 著作権 ............................................................................................................................... 8
1.10 IHE テクニカルフレームワークの開発および保守のプロセス................................ 8
1.10.1 新規開発 - 既存テクニカルフレームワークの拡張............................................ 9
1.10.2 既存テクニカルフレームワークの内容の保守..................................................... 9
1.10.3 テクニカルフレームワークの使用....................................................................... 10
2 統合プロファイル................................................................................................................11
2.1 統合プロファイル間の依存関係 ................................................................................. 11
2.2 統合プロファイルの概要 ............................................................................................. 122.2.1 上部消化管検査ワークフロー (ENDO) ..................................................................... 13
2.3 アクタの説明 ................................................................................................................. 13
2.4 トランザクションの説明 ............................................................................................. 15
2.5 製品の実装 ..................................................................................................................... 18
3 上部消化管検査ワークフロー (ENDO)............................................................................20
3.1 アクタ/トランザクション ............................................................................................ 20
3.2 上部消化管検査ワークフロー統合プロファイルのオプション ............................. 23
3.3 予約済プロセスフロー ................................................................................................. 24
3.4 上部消化管検査ワークフローのユースケース ......................................................... 29
3.4.1 ケース C1: ADT で患者登録が行われ Order Placer で処置オーダーが出される30
3.4.2 ケース C2: ADT で患者登録されて DSS/OF で処置オーダーされる..................... 33
3.4.3 ケース C3: ADT で登録され処置がオーダーされていない患者 ............................ 35
3.4.4 ケース C4: DSS/OF で登録されて処置がオーダーされた患者 ............................... 37
3.4.5 ケース C5: 未登録の患者 ............................................................................................ 39
3.4.6 ケース C6: 処置中に更新された患者 ........................................................................ 41
3.4.7 ケース C7: 検体採取無しによる病理オーダー無し ................................................ 43
3.4.8 ケース C8: 処置の中断・中止 .................................................................................... 45
Appendix A: 内視鏡検査処置の概要 ......................................................................................47__________________________________________________________________________
1
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Appendix B: 内視鏡検査におけるワークフロー管理の課題 ..............................................50
B.1 臨床的背景：診断とインターベンション処置 ......................................................... 50
B.2 ワークフローの確立：要求処置と処理ステップ ..................................................... 50
B.3 マルチモダリティと Ad Hoc（予定外）スケジュール ............................................ 50
B.3.1 未予約のケース ............................................................................................................. 51
B.4 モダリティ処置ステップ完了／中断 ......................................................................... 52
B.5 処置の開始と終了 ......................................................................................................... 52
B.6 グループ処置 ................................................................................................................. 53
B.6.1 グループ化処置とは ..................................................................................................... 53
B.6.2 マルチモダリティ検査でグループ化されたケースが問題になる理由 ................. 53
B.7 IHE 内視鏡で採用されている方法.............................................................................. 53
Appendix C: IHE 統合ステートメント...................................................................................55
C.1 IHE 統合ステートメントの構造と内容...................................................................... 55
C.2 IHE 統合ステートメントのフォーマット.................................................................. 56
Appendix D: 用語集 ..................................................................................................................58
Appendix E: セキュリティ環境に関する考慮 ......................................................................61__________________________________________________________________________
2
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

まえがき
IHE (Integrating the Healthcare Enterprise : 医療施設の統合)は、現在の医療施設で使用されている情報シ
ステムの統合を促進するために企画された構想である。その基本的な目的は、患者を治療するために医療従事者が治療方針を決定するための必要なすべての情報を正しく利用できるようにすることである。
IHE イニシアチブは統合作業を促進するための手段であり討議の場である。IHE では特定の臨床的目標をするメッセージ交換規約を実装するためのテクニカルフレームワークを定義している。また、IHE には、このフレームワークを実装した上での厳密なテストプロセスも含まれている。さらに、IHE では、
このフレームワークの利点を立証し、業界やユーザが、IHE を採用しやすくするために、医療関係者の会議で教育セッション、展示会を開催している。
IHE では、新しい標準を開発することではなく、HL7、DICOM、IETF、およびその他の既存の標準を、それぞれが適切な分野で統合して使用し、必要に応じて構成の選択肢を定義することである。IHE では、
既存の標準で明確化しなければならないときや拡張が必要な場合には、該当する標準化団体に推奨事項を提示することにしている。
この構想のために、多くの医療分野や地域、スポンサーやサポート組織がある。北米での主なスポンサ
ーは、American College of Cardiology (ACC)、Healthcare Information and Management Systems Society(HIMSS)、および Radiological Society of North America (RSNA)であり、IHE Canada も設立されている。
IHE Europe (IHE-EUR)は、European Society of Cardiiology (ESC)、European Association of Radiology (EAR)と European Congress of Radiologists (ECR)、Coordination Committee of the Radiological and Electromedical
Industries (COCIR)、Deutsche Röntgengesellschaft (DRG)、EuroPACS Association、Groupement pour laModernisation du Système d'Information Hospitalier (GMSIH)、Société Francaise de Radiologie (SFR)、および
Società Italiana di Radiologia Medica (SIRM)の大きな連合によって支援されている。
日本における IHE(以下 IHE-J と記す)は、IHE-J 運営委員会（委員長；石垣武夫）を中心として、経済産業省(METI)、厚生労働省、MEDIS-DC、および日本画像医療システム工業会(JIRA)、保健医療福祉情報システム工業会(JAHIS)、日本医学放射線学会(JRS)、日本放射線技術学会(JSRT)、日本医療情報学会(JAMI)などが協力し推進されている。消化器内視鏡分野における IHE は、その活動母体を JAHIS とし、
JAHIS 内の画像システム委員会下に設置された内視鏡 IHE-WG が担当している。
さまざなま分野(IT インフラストラクチャ、循環器科、検査室、放射線科など)における、IHE テクニカ
ルフレームワークは、その統合目標を実現するために、既に確立されている標準を利用して定義する。
このような統合により、患者の最前の治療を支援するために、適切な医療情報を共有できるようになる。
これらは、公開レビューの期間の後、毎年拡張され、誤りを訂正し定期的に保守される。これらのテクニ カ ル フ レ ー ム ワ ー ク の 最 新 バ ー ジ ョ ン は 、 www.acc.org 、 www.rsna.org/IHE 、 ま た は
http://www.himss.org/IHE から入手できる。
IHE テクニカルフレームワークでは、IHE アクタと呼ばれる医療機関の機能コンポーネントのサブセットを規定し、組み合わされた標準に沿ったトランザクションのセットに関する相互作用が規定されている。テクニカルフレームワークでは、このトランザクション本体を段階的に詳細化して記述されている。
このボリューム I では、IHE 機能の概要レベルのビューが提供され、特定の臨床ニーズの対応能力に焦点を当てた統合プロファイルと呼ばれる機能単位として編成されたトランザクションが示されている。
以降のボリュームでは、各 IHE トランザクションの詳細な技術的説明が提供されている。
この IHE 消化器内視鏡テクニカルフレームワーク 1 年度は、2005 年 12 月に発表されたスケジュールに従って、2006 年 5 月までのパブリックコメント用として提出された。

IHE Endoscopy Technical Committee (IHEEndoscopy TC)は、送られたコメントを検討し、2006 年 5 月に変更されたバージョンを公開する。

__________________________________________________________________________
3
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

1 序文
1.1 テクニカルフレームワークの概要
本書『IHE 内視鏡テクニカルフレームワーク』 (IHE ENDO-TF)では、内視鏡分野に関する統合目標を達成するために既に規定された標準・規格の具体的な実装について定義する。これらを統合することで、最善の患者治療を支援するために適切な医療情報の共有を目指すものである。
ENDO-TF は、公開レビューの期間の後、毎年拡張定義し、誤り等を訂正し定期的に保守される。現在のバージョンである第 1.0 版では、2005 年 12 月時点で定義および実装される IHE トランザクションが規定されている。資料の最新バージョンは、保健医療福祉情報システム工業会（以下 JAHIS と言う）
を通して利用可能である。
ENDO-TF では、IHE アクタと呼ばれる医療機関の機能コンポーネントのサブセットが指定され、組み合わされた標準に基づいたトランザクションに関するそれらの相互関連が規定されている。このトランザクション本体は、段階的に詳細化し記述されている。現在のボリューム I では、IHE 機能の上位の観点から概要が示され、特定の臨床ニーズへ焦点を当てた統合プロファイルと呼ばれる機能単位としてまとめられたトランザクションが示されている。ボリューム II は、内視鏡分野に固有の各 IHE トランザ
クションの詳細な技術的説明が記述されている。
ENDO-TF は、関連する IHE テクニカルフレームワークのセットの一部であり、次のような分野固有の文書で構成されている。
•

IHE 内視鏡テクニカルフレームワーク•

IHE 循環器テクニカルフレームワーク•

IHE IT 基盤テクニカルフレームワーク•

IHE 放射線テクニカルフレームワーク•

IHE 検査室テクニカルフレームワーク

IHE 内視鏡分野統合プロファイルは、これらの他の IHE テクニカルフレームワーク文書で定義されているトランザクションに大きく依存し、これらを参照している。他のフレームワークの参照に関する規則については、このボリュームの 1.6.4 節を参照していただきたい。

1.2 Volume I の概要
以降の第 1 節では、テクニカルフレームワークの一般的な性質、目的、および機能について説明する。
第 2 節では、テクニカルフレームワークを構成する IHE 統合プロファイルの概念について説明する。
本書の第 3 節以降では、適用する臨床問題、及び関連する IHE アクタやトランザクションなどを含む
各統合プロファイルについて詳細に説明する。
付録では、統合プロファイルに関連する具体的な問題、および使用されている専門語と略語の用語集を示す。

1.3 対象読者
本書の想定される対象読者は次のとおりである。

__________________________________________________________________________
4
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________•

医療情報システムの統合の技術的側面に興味のある医師•

IHE イニシアチブに参加するベンダの技術スタッフ•

医療機関の IT 部門•

標準作成に関係する専門家

1.4 標準との関係
IHE テクニカルフレームワークでは、医療機関での相互関係の観点だけから分散医療環境の機能コンポーネント(IHE アクタと呼ばれる)を特定する。現時点での開発レベルでは、HL7、DICOM、および各種
Web 標準に基づいて構成されたトランザクションのセットが定義されている。IHE イニシアチブの範囲が拡大すると共に、他の標準に基づくトランザクションも必要に応じて組み込まれるものである。
状況によっては、IHE は、これらの標準がサポートする特定のオプションも推奨しているが、これらの標準と矛盾する技術的な選択を、IHE は推奨することはない。IHE の方針としては、既存の標準に問題があったり、標準を拡張しなければならない場合には、各標準化団体に、それぞれの適合性あるいは各
標準進化戦略内での解決を依頼することとしている。
つまり、IHE は、規格ではなく実装するためのフレームワークである、つまり IHE を規格として参照することは適切ではない。製品が規格に準拠していると宣言するには、個別の標準を直接参照する必要がある。さらに、IHE 統合機能を実装したベンダは、IHE 統合ステートメントを使用して、IHE テクニカ
ルフレームワークの仕様に製品が準拠していることを記述しなければならない。IHE 統合ステートメン
トの目的は、IHE 機能の設計時にサポート対象とされていることを、統一された方法でユーザに伝えることである。IHE 統合ステートメントを発行するベンダは、その内容に関する全責任を負わなければな
らない。IHE のアクタと統合プロファイルの概念を理解しているユーザは、IHE 統合ステートメントと他の実装を比較することで、製品間の通信がサポートされているか否か、あるいはどの程度サポートされているかを判断することができる。IHE 統合ステートメントのフォーマットについては付録 C を参照
すること。IHE は、実装者に対し、IHE テクニカルフレームワークに従って実装された製品が、IHE の基になっている標準の完全な要件も満たすことを推奨している。またこれにより、その製品が、各規約に準拠して実装されてはいるが IHE テクニカルフレームワークには完全に従っていない他の製品と、統合の下位レベルでは対話可能である。

1.5 実際のアーキテクチャとの関係
IHE テクニカルフレームワークで記述されている IHE アクタとトランザクションは、現実の医療情報シ
ステム環境を抽象化したものである。従来、各トランザクションは特定の製品カテゴリー毎(HIS、電子
カルテ、RIS、PACS、臨床情報システム、画像モダリティなど)に実行されるが、IHE テクニカルフレームワークでは、あえてそのような機能やアクタを上記の製品カテゴリと関連させることを避けている。
各アクタについて、IHE テクニカルフレームワークでは、統合する情報システムと関連のある機能だけが定義されている。したがって、アクタの IHE 定義を、アクタを実装する製品の完全な定義と考えてはならず、また、フレームワーク自体を、医療情報システムのアーキテクチャを包括的に記述するものと見なしてはならない。
アクタとトランザクションを定義する理由は、医療情報システム環境の機能コンポーネント間の相互作用を定義するための基礎を提供することである。単一の物理的な製品が複数の機能を実装するような状況においては、製品と環境の外部機能との間のインターフェイスのみが重要であると、IHE イニシアチ
ブは考える。したがって、IHE イニシアチブは、すべてを含む単一の情報システムに基づく統合環境と、協力して同じ目標を実現する複数のシステムに基づく統合環境を比較したときの相対的なメリットに__________________________________________________________________________
5
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
関しては、いかなる立場もとらない。ただし、IHE テクニカルフレームワークの可能性を効果的に示す
ため、IHE のデモンストレーションでは、IHE テクニカルフレームワークに基づく複数ベンダのシステ
ムの統合が強調されている。

1.6 表記規則
この文書では、以下の表記規則を使用して、フレームワークの概念を表し、IHE テクニカルフレームワークの基になる標準を適用する方法を指定する。

1.6.1 アクタおよびトランザクションの図と表
個々の統合プロファイルは、トランザクションを通して相互作用する一連のアクタによってサポートされる現実の機能を表したものである。アクタは、情報システムまたは情報システムのコンポーネントであり、施設の運営活動が必要とする情報カテゴリーを生成、管理、および操作する。トランザクション
は、標準ベースのメッセージを通して必要な情報を転送するアクタ間の相互作用である。
第 3〜5 節で示されているアクタとトランザクションの表は、特定のプロファイルの各アクタがサポートする必要のあるトランザクションを表している。
状況によっては、プロファイルが、正しく機能し、有用であるために、前提となるプロファイルに依存する場合がある。例えば、循環器 TF における心カテワークフローは、前提条件として実装される
Consistent Time Profile (IHE IT インフラストラクチャフレームワークから)に依存する。このような依存関係は、表 2-1 で目的のプロファイルを探し、必要な前提条件としてリストされているプロファイルを調べることでわかる。アクタは、目的のプロファイルだけでなく、前提条件のプロファイルにおいて必要なすべてのトランザクションを実装する必要がある。

1.6.2 プロセスフロー図
以下の統合プロファイルの説明には、関連するアクタ間のトランザクションのシーケンスとしてプロフ
ァイルが機能する方法を示す、プロセスフロー図が含まれている。
これらの図は、"概要"を提供するように意図されており、全体的なワークフローを背景にトランザクシ
ョンを見ることができる。IHE によって詳細に定義されていない特定のトランザクションとアクティビ
ティは、これらの図ではイタリック体で示されており、関連する IHE トランザクションが医療情報システムの広いスキームのどこに組み込まれるのかに関する追加背景を提供している。
これらの図は、可能性のある唯一のシナリオを示すためのものではない。多くの場合、違う方法でのアクタのグループ化が可能であり、他のプロファイルからの相補的なトランザクションが存在する可能性がある。
場合によっては、トランザクションのシーケンスに柔軟性があり、そのような場合には、普通、可能なバリエーションを示す注が記載されている。
これらの図では、トランザクションに対する線の矢印は、トランザクションを開始するアクタから宛先のアクタを指している。

1.6.3 テクニカルフレームワークの規約的内容と参考的内容
テクニカルフレームワークのほとんどの部分では、統合プロファイル、アクタ、およびトランザクショ
ンの必須またはオプションの特性が示されて、これらは規約的な内容である。文章の理解を助けるため、
テクニカルフレームワークには、参考情報として図表が含まれる。

__________________________________________________________________________
6
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________IETF RFC 2119 に従い、特定の表現は、テクニカルフレームワークの特定の内容が規約的かどうかを示す。そして必須か("する必要がある"、"しなければならない"など)オプションか("してもよい"、"推奨される"など)ということを示している。参考的内容には、このようなキーワードはない。

1.6.4 テクニカルフレームワークの参照
同じテクニカルフレームワークボリューム内の節を参照する場合は、節番号自体が使用される。他のボ
リュームまたは他の分野のテクニカルフレームワークを参照する場合は、次の形式が使用される。
<domain designator> TF-<volume number>: <section number><domain designator>は、
IHE の分野を示す短い指定文字である(ITI = IT インフラストラクチャ、RAD = 放
射線、CARD=循環器、LAB=臨床検査、ENDO=内視鏡)。
<volume number>は、特定のテクニカルフレームワーク内の該当するボリュームである(1、2、3 など)。
<section number>は、該当する節の番号である。
例えば、ITI TF-1: 3.1 は、IHE IT インフラストラクチャテクニカルフレームワークのボリューム 1 の 3.1
節を示し、RAD TF-3: 4.33 は、IHE 放射線テクニカルフレームワークのボリューム 3 の 4.33 節を示す。

1.6.5 トランザクションの参照
トランザクションに関して参照される場合は、次の形式が使用される。
<domain designator>-<transaction number><domain designator>は、
IHE の分野を示す短い指定文字である(ITI = IT インフラストラクチャ、RAD = 放
射線、CARD=循環器、LAB=臨床検査、ENDO=内視鏡)。
<transaction number>は、特定の IHE の分野のテクニカルフレームで指定されているトランザクション番号である。
トランザクションは名前で指名される事も可であるが、それはトランザクション名が特定の IHE 分野に属する事とトランザクション番号がそのドキュメント内にあることが確認された後である。

1.7 IHE 内視鏡分野の今年度の範囲
この文書では、IHE 内視鏡分野構想の 1 年目を示す。現在の IHE 内視鏡分野テクニカルフレームワーク
では、以下の基本機能が扱われている。
•

上部消化管検査統合プロファイルでは、内視鏡部門上部消化管検査の内視鏡室におけるワークフロ
ーを管理及び分散させる方法について説明する。

1.8 コメント
JAHIS は、この文書に関するコメントを歓迎する。コメントは、検討組織である IHE-J（Integrating
Healthcare Enterprise Japan）の担当宛メールアドレスまでお送りいただきたい。
IHE-J
http://www.ihe-j.org/index.html
担当事務局組織 （社）日本画像医療システム工業会__________________________________________________________________________
7
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
コメント事務局
e-mail : akamatsu@jira-net.or.jp

1.9 著作権
Health Level Seven, Inc.は、IHE に対して、HL7 規格の表の複製を許可している。本書に掲載されている
HL7 の表は、Health Level Seven, Inc.が著作権を保有し、無断複写・複製・転載を禁ず。
National Electrical Manufacturers Association (NEMA)は、DICOM 規格の一部を IHE が使用することを許可している。
これらの文書から引用されている資料については、使用箇所においてその旨を示す。

1.10 IHE テクニカルフレームワークの開発および保守のプロセス
テクニカルフレームワークは、内視鏡分野技術委員会としての JAHIS（保健医療福祉情報 システム工業会）における内視鏡 IHE-WG が他の分野の IHE-J における技術委員会と協力して、継続的に拡張および保守を行う。フレームワークの開発および保守のプロセスは、ベンダとユーザが IHE 互換製品を指定、開発、および購入する際に信頼できるように仕様を安定させるため、多くの原則に従っている。
プロセスは、以前に定義された統合プロファイルおよびアクタに準拠すると宣言する実装をサポートするため、フレームワーク定義の旧版互換性を維持しながら、拡張、明確化、および訂正のニーズに対応する必要がある。
IHE テクニカルフレームワークの安定を維持するため、新規開発と保守という管理された 2 つのパスのいずれかに従って、定期的な年間サイクルで変更が行われる(図 1.10-1を参照)。
New
Development

Publish for
Public Comment

Publish for
Trial Implementation

Publish as
Final Text

Publishnext version
Existing Technical
Framework fromprevious annual cycle

Propose & Draft
New Supplement

Supplement
PC

Final Text
Supplement

Supplement
TI

Public Comments
considered& Supplement updated
Issues raised inprevious version ofTechnical Framework

Change Proposal
submitted& accepted

Change Proposal
submitted& accepted

Final Text
ChangeProposal

Final Text
ChangeProposalTechnical
Framework(next version)

Continue as requiredin the next annual cycle

図 1.10-1. この図は、年間サイクルにおけるテクニカルフレームワークの開発と保守のプロセスを示したものである。
破線の矢印は、テキストの結合(マージ)を表している。

__________________________________________________________________________
8
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
1.10.1 新規開発 - 既存テクニカルフレームワークの拡張
毎年、IHE 内視鏡企画委員会が開発する新規機能を規定し、技術委員会は必要な分析と設計作業を行って、テクニカルフレームワークの新しい文章を作成する。
通常、新規機能は補足という形で公開される。補足の範囲は、テクニカルフレームワークに対して次のいずれかを追加することである。
•

新しい統合プロファイル: 普通、新しいアクタとトランザクションの導入が含まれる。

•

既存の統合プロファイル内の新しいアクタ: テクニカルフレームワークのどこかで以前に定義されていたアクタ、またはまだ定義されていない新しいアクタである。新アクタがこのプロファイルにおいてどういう責任を持つかを定義するトランザクションを同定または定義し、必須またはオプシ
ョンとして指定できる。そのプロファイルを既に実装しているシステムで互換性の問題が発生するのを防ぐため、プロファイル内の既存のアクタに対しては、新しい必須トランザクションは追加されない。

•

既存統合プロファイル中の新しいオプション: 普通は、プロファイル内の既存のアクタに対するオ
プションのトランザクションの追加、または既存トランザクションに対するオプション機能の追加である。

•

概念の大きな変更: 既存の統合プロファイルの振る舞いは変更しないが、将来におけるアクタまたはトランザクションに対する変更または追加を意味する場合がある。

公開プロセスは一定のフェーズによって構成され、各文書において明確に示されている。
最初に、テキストはパブリックコメント(Public Comment:”PC"と表記)用に公開される。パブリックコメ
ントの期間中(通常は 30 日)、テキストおよびコメント提出用の手段が、IHE の Web サイトにおいて提供される。この期間の後、技術委員会はコメントをレビューする。
その後、受け取ったコメントに基づく変更が加えられた更新版の補足テキストが試用版実装(Trial
Implementation:"TI"と表記)用に公開される。
IHE は、IHE のアクタと統合プロファイルの試用版実装仕様の実装をテストするためのプロセスを、ベンダに提供する。IHE テストプロセスは、コネクタソン(Connect-a-thon)という名前のマルチパーティ相
互作用テストイベントであり、ベンダに対して、有用なフィードバックと、実装の準拠状況の判断基準となる指示を提供する。また、試用版実装仕様の技術的アプローチの妥当性検査としての役割も果たす。
試用版実装によって新しい機能が十分に使用されたものと判断され(たとえば、コネクタソンからの経験により)、文章が十分に安定したと考えられるようになったなら、新しい文書を最終文書(Final Text:"FT"と表記)として公開する。
最終テキストの補足は、年間開発サイクルの終了時にテクニカルフレームワークの現行バージョンに組み込まれ、バージョン番号が更新された新しいバージョンのテクニカルフレームワークとなる。

1.10.2 既存テクニカルフレームワークの内容の保守
技術委員会は最善の努力を払うが、それでも、公開された最新バージョンのテクニカルフレームワーク
または試用版実装の文書には、正しくない部分、不完全な部分、または不明確な部分が含まれる場合がある。このような問題は、変更提案として処理され、次のものが対象となる。
•

訂正: 実装の相互運用性を損なう原因となる技術的問題は、安定した統合プロファイルの機能を変更しないで修正される。

•

明確化: 誤解されるおそれのある部分、または曖昧な部分については、技術的な変更は行わずに、理解しやすくしたり、曖昧さを排除したりする。

__________________________________________________________________________
9
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
公開プロセスは訂正も明確化も同じで、試用版実装に対する変更と、テクニカルフレームワークの現行バージョンに対する変更の両方が扱われる。
提出済変更提案は、試用版実装や最終テキスト実装プロファイルあるいはコネクタソンにおける経験な
どから、ユーザ、ベンダ、または技術委員会メンバーが提起した問題に基づく。作成される変更提案文
書では、以下のことが明確に記述されていなければならない。
•

テクニカルフレームワークの中で変更が求められている部分

•

問題の説明

•

変更が必要であると考えられる理由•問題に対する解決策または対応策

技術委員会は、定期的に変更提案を検討し、受理または棄却する。
棄却された変更提案は、変更が適当ではない理由についての技術委員会の説明を添えて公開される。
受理された変更提案は、適切な明確化または訂正を施すことを目的としてさらに調査を行うための作業
項目として、技術委員会のメンバーに割り当てられる。作成されたテキストは、再び、承認される前に技術委員会によるレビューを受ける。
承認されたなら、技術委員会によって最終文書変更提案が公開され、効力を発したものと見なされる。
この提案は、年間開発サイクルの終了時に、次バージョンのテクニカルフレームワークに組み込まれる。
最終テキスト変更提案または最終テキスト補足に対して変更提案を提出することはできない。
1.10.3 テクニカルフレームワークの使用

テクニカルフレームワークの現行バージョンは、基本的な参照文書と見なされる。現在の年間サイクルにおける最終テキスト補足および最終テキスト変更提案は、この文書を補足する。過去の最終テキスト
は、テクニカルフレームワークの以前のバージョンまたは補足の試用版実装バージョンとの違いの簡便な要約として保持される。
年間開発および保守サイクルにおいては、実装に対してテクニカルフレームワーク文書を次のように使用することが推奨される。
•

製品の実装
試用版実装文書に基づいて実装された製品については、以降の最終文書をレビューし、必要に応じて製品を更新することが望ましい。さらに、ベンダは、最終文書変更提案を監視し、関連のある変更を遅れることなく製品に対して行うことが望まれる。

•

コネクタソンの実装
コネクタソンでのテストは、該当する IHE 分野に対するテクニカルフレームワークの現行バージョン、および試用版実装と最終文書変更提案に対する関連するすべての補足に基づいて行われる。

__________________________________________________________________________
10
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

2 統合プロファイル
図 2-1 で示されている IHE 内視鏡統合プロファイルは、医療専門家とベンダが製品を開発するための要件の伝達において使用できる共通の言語を提供する。統合プロファイルでは、現実世界でのシナリオ、または統合されたシステムの具体的な機能セットが記述されている。統合プロファイルは、指定された
アクタのセットに対して適用され、各アクタに対し、これらの機能をサポートするために必要なトランザクションを指定している。
統合プロファイルは、ユーザとベンダの両方に対し、IHE テクニカルフレームワークに記述されている機能のサブセットを参照するための簡単な方法を提供する。統合プロファイルを使用すれば、全体的なIHE サポートを単に要求または約束するよりも、IHE テクニカルフレームワークによって定義されている IHE アクタとトランザクションに関して、手間を掛けて表現しなおさずに、より具体的に指定することが可能になる。

ES Workflow
Manage multi-modality synchronized procedurefrom admission to reporting, including unidentified
patients

Consistent Time
Synchronized clocks on all
equipment(IHE IT Infrastructure)

Scheduled Workflow

Patient Info
Reconciliation

ReportingWorkflow

Admit, order, schedule, worklist, status;
create, manage, store, display images(IHE Radiology)

Unidentified patients, update andmerge demographics(IHE Radiology)(IHE Radiology)

図 2.1. IHE 内視鏡分野統合プロファイルとその依存関係

2.1 統合プロファイル間の依存関係
一般に、IHE 統合プロファイルは単独では機能せず、あるプロファイルに対する有用な入力となるオブジェクトが、別のプロファイルを実装した結果として生成される場合がある。
図 2-1 (前図)は、統合プロファイル間の依存関係を表したものである。図の矢印は、依存するプロファ
イルから依存されるプロファイルを指している。塗りつぶされた矢印は実装の依存関係を示しており、依存するプロファイルのアクタは、サポートするプロファイルを実装する必要がある。塗りつぶされて__________________________________________________________________________
11
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________いない矢印は定義の依存関係を示しており、依存するプロファイルのトランザクションは、サポートするプロファイルのトランザクションに基づく。これは参考のためにのみ記述されており、サポートする
プロファイル自体は使用されず、そのサブセットのみが使用される。
特に、サポートするプロファイルは他の IHE ドメインのものであることに注意すること。
表 2.1-1は、統合プロファイル間の必要な依存関係を定義したものである。

当然のことながら、これとは異なるプロファイルの組み合わせが実装されていると、他の有用な依存関係も存在するが、表 2.1-1ではそれについては示されていない。例えば、さまざまな内視鏡プロファイルのアクタは、ユーザ認証、監査のためのログ、患者 ID 相互参照、時間整合などのために、IT インフラストラクチャ分野のプロファイルを実装する場合がある。

表 2.1-1. 内視鏡統合プロファイルの依存関係

Integration Profile
Endo Workflow

Depends on
ITI-TF Consistent Time

RAD-TF Scheduled Workflow
RAD-TF Patient Information
Reconciliation

Dependency Type

Comments

The DSS/Order Filler andAcquisition Modality actors
are required to be groupedwith Time Client actors
Definitional

ベンダの製品は、第 3〜5 節の統合プロファイルで概要が示されているように、適切なアクタトランザ
クションを実装することで統合プロファイルをサポートする。1 つの製品が、複数のアクタおよび複数の統合プロファイルを実装できる。
アクタは、目的のプロファイルのトランザクションに加えて、前提条件のプロファイルにおいて必要なすべてのトランザクションを実装する必要がある。
アクタ(2.2節を参照)は、施設の運営アクティビティに関連のある情報を生成、管理、または操作する情報システムまたはそのコンポーネントである。
トランザクション(2.3節を参照)は、標準規格に準じたメッセージを通して必要な情報を転送するアクタ間の相互作用である。

2.2 統合プロファイルの概要
この文書では、次の情報によって各 IHE 統合プロファイルを定義する。
•

関係する IHE アクタ•

各 IHE アクタに必要な特定の IHE トランザクションのセット

これらの要件は、統合プロファイルをサポートする各アクタに必要なトランザクションの表の形式で表現される。複数の統合プロファイルをサポートするアクタは、サポートされる各統合プロファイルに必要なトランザクションをすべてサポートする必要がある。また、統合プロファイルが別の統合プロファ
イルに依存するときには、依存する統合プロファイルに必要なすべてのトランザクションが表に示されている。

__________________________________________________________________________
12
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
IHE 統合プロファイルは標準規格に対する準拠の表明ではなく、また IHE が認定団体ではないことに留意しなければならない。ユーザは、ベンダに DICOM や HL7 などの関連規約に対する準拠の表明をするよう要求し続ける必要がある。各規約に準拠することは、IHE 統合プロファイルを採用するベンダの前提条件である。
また、IHE では扱えないが、うまく運用されているいかなる統合プロジェクトにも重要なニーズがある
ことにも留意すべきである。さらに、システムの統合を成功させるには、混乱を最低限にしてフェール
セーフ戦略を記述するプロジェクト計画、具体的で相互に理解されたパフォーマンス目標、明確に定義されたユーザインターフェイス要件、明確に識別されたシステムの境界、詳細化されたコスト目標、保守とサポートの計画などが必要である。

2.2.1 上部消化管検査ワークフロー
上部消化管検査は、ワークフローの観点から特に複雑である。エビデンス収集アクティビティは、オー
ダーが出される前に始まる場合がある。実際に急患では上部消化管検査処置のオーダーが作成されないことがある。関連する全ての処置や画像、検査、レポートに同一患者ＩＤで確実に行われなければならない。加えて前後の処置、診断、診療あるいは治療的な観点から所要時間が長くなったりする場合がある。
上部消化管検査ワークフロー統合プロファイルでは、上部消化管検査処置の前後関係の基本的な患者データの継続性と完全性が確立される。このプロファイルでは、特に、患者 ID と患者基本データの一貫した処理を取り扱う。これには、検査手技の開始後まで、さらには検査手技が終了してから長い時間が経過するまで、患者の本当の身元がわからない急患のものも含まれる。また、さまざまな画像、測定、解析システム間における検査手技データの予約と調整、および以降のワークフローステップ(レポートなど)をサポートできるところからアーカイブへの確実な保管も指定されている。さらに、複数フェーズ(診断と治療)になる可能性のある検査手技のステップの完了ステータスの集中的な調整も行う。

2.3 アクタの説明
アクタとは、その施設での運営アクティビティに関連のある情報を生成するか管理するか、あるいは作用する情報システム自身かその構成要素である。以下は IHE によって定義されているアクタであり、この文書の他の部分および他の分野のテクニカルフレームワーク文書において参照されるものである。
アクタ名称の修飾子として使用される用語は、その使用方法に一貫性がないとされている (例えば、Image Manager (イメージマネージャ)は画像以外のオブジェクトも管理する)。現時点では、一貫性のために広範な名前変更を行うメリットより、複数の分野で共有される多くの既存アクタの名前を変更する
ことによってもたらされる大きな混乱のリスクの方が重大である。したがって、以下の定義のままとなっている。
Acquisition Modality (アクイジションモダリティ) –内視鏡 TF では内視鏡システムを指し、患者がいる間に医学的な画像または波形を収集および作成するシステム。モダリティは、測定値を含む SR（Structured Report）文書などの他のエビデンスオブジェクトを作成する場合もある。
ADT

患者の基本情報および受診情報を追加および/または更新するシステム。特にオーダー発注
および部門システムに新しい患者を登録する。

DSS/OF（Department System Scheduler/OrderFiller） (部門システムスケジューラ/オーダー受注側)– 外部システムや部門システムから受け取ったオーダーの管理に関する機能を提供する、部
門ベース(内視鏡分野や放射線分野など)の情報システム。内視鏡に向けた拡張機能として、病理部門に対する検体検査の依頼に関するオーダー発行情報も含む。同拡張機能として、内__________________________________________________________________________
13
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
視鏡検査における前処置や後処置に関する状態もオーダー進捗情報として Order Placer に返す。
Image Archive (イメージアーカイブ) – 画像、表示状態、キー画像ノート、エビデンス文書などのエビデンスオブジェクトの長期間保存を提供するシステム。
Image Creator (画像生成装置) – 画像処理を行い、新たな画像生成を行うシステム。通常の内視鏡検査では画像処理を行わないため SWF では含まないが、画像処理を行う場合は他のプロフ
ァイルにて対応するものとする。
Image Display (画像表示装置) – 患者の検査を表示するためのシステム。さらに、画像セット、提示
状態、キー画像ノート、エビデンス文書などを含む、選択したエビデンスオブジェクトの検索と表示をサポートする場合もある。
Image Manager (イメージマネージャ) – エビデンスオブジェクトの安全な保管と管理に関する機能を提供するシステム。これらのオブジェクトに関する利用可能性情報を DSS に提供する。
Order Manager (オーダーマネージャ) – 採取した生検を病理部門で検査を行ってもらうための検
査依頼オーダーの発行依頼を行う。
Order Placer (オーダー発注) – さまざまな部門に対するオーダーを生成し、それを正しい部門に配布する、病院または施設の全体に関わるシステム。内視鏡に向けた拡張機能として、内視鏡室から病理部門に対する検体検査の依頼に関するオーダーも含む。同拡張機能として、前処置や後処置等の内視鏡検査に関する進捗状態をオーダー進捗情報として受け取る。
PPSM（Performed Procedure Step Manager） (実施済み処理ステップマネージャ) – アクイジショ
ンモダリティからのモダリティ実施済み処理ステップ情報を DSS/OF（部門システムスケジ
ューラ/オーダーフィラー）およびイメージマネージャに再配布するシステム。内視鏡に向けた拡張機能として、内視鏡室から病理部門に対する検体検査の依頼に関するオーダー及び、前処置や後処置等の内視鏡検査に関する進捗状態も含む。
Report Creator (レポートクリエータ) – 構造化レポートの作成を行う。
Report Manager (レポートマネージャ) – 構造化レポートの管理を行い、Repository に保存する。
Report Repository (レポート保管装置) – 構造化レポートを保管管理し、検索要求に応じて出力する。
Report Reader (レポートリーダ) – 構造化レポートの検索取得表示を行う。
Specimen Manager (検体番号生成) – 検査中に取得した生検サンプルを病理部門へ検査依頼を出すに当たって、各生検サンプル個別の番号を生成する。
次の表は、どの統合プロファイルでどのアクタが使用されるのかを示したものである。
表 2.3-1. 統合プロファイルのアクタ

Integration Profile

ENDO

Actor
Acquisition ModalityX

ADT Patient RegistrationX

DSS/OFX

Image Archive

X

Image Creator
Image Display

X

Image Manager
Order Manager

X
X__________________________________________________________________________
14
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order Placer

X

Performed Procedure Step Manager
Report Creator
Report Manager
Report Repository
Report Reader
Specimen Manager

X
X
X
X
X
X

注:タイムクライアントアクタは、正式には内視鏡検査ワークフロープロファイルの一部ではないが、このプロファイルの特定のアクタとグループ化する必要がある。

2.4 トランザクションの説明
トランザクションは、標準規格に準じたメッセージを通して必要な情報を転送するアクタ間の相互作用である。IHE では以下のトランザクションが定義されており、この文書の他の部分で参照される。これ
らのトランザクションが他の分野のテクニカルフレームワーク文書において指定されている場合は、分野の ID とトランザクション番号で示される。
Patient Registration (患者登録) – 患者情報の登録。ADT システムは、患者の登録および/または受け入れを行い、他の情報システムに情報を転送する。 [RAD-1]
Placer Order Management (オーダー発行管理) – Order Placer からの検査依頼の登録，取消。オーダー発行側は、オーダー受注側に対し、オーダーの開始または取り消しを通知する。Placer/Filler
Order Management トランザクションは、新規オーダーの開始時には“-New”と示され、既存オーダーの取り消し時には“-Cancel”と示される場合がある。[RAD-2]
Filler Order Management (オーダー受信管理) – Order Filler からの検査依頼の登録，取消。オーダー
受注側は、オーダー発行側に対し、開始、取り消し、またはオーダーの状態の変化を通知する。Placer/Filler Order Management トランザクションは、新規オーダーの開始時には“-New”と示され、既存オーダーの取り消し時には“-Cancel”と示されることがある。内視鏡に向けた拡張機能として、病理オーダーの発行及び前処置や後処置等の内視鏡検査に関する進捗状態
もオーダーの状態の変化の過程の一部として通知する。[RAD-3]
Procedure Scheduled (予約済処置) – Image Manager に対して検査が予約されたことを通知する。スケジュール情報が、DSS/OF からイメージマネージャに送信される。[RAD-4]
Modality Worklist Provided/Query Modality Worklist (モダリティワークリストクエリー) – Modality
からの検査依頼の検索・取得。データ取込みモダリティで入力されたクエリーに基づき、クエリーを満たすすべての項目を一覧したモダリティワークリストが生成される。選択された
患者基本情報の SPS(Scheduled Procedure Steps)のこのリストは、アクイジションモダリティに返される。[RAD-5]
Modality Procedure Step In Progress (モダリティ処理ステップ処理中) – 内視鏡検査が開始されたことを通知する。内視鏡向け拡張として内視鏡検査そのものの前後における前処置や後処置を含めた検査に関連する進捗を通知する。アクイジションモダリティは、新しい PS（Procedure Step）の開始を実施処理ステップ管理(PPSM)に通知し、PPSM は DSS/OF とイメージマネージャに通知する。[ENDO-7、RAD-6 より派生]
Modality Procedure Step Completed (モダリティ処理ステップ完了) – 内視鏡検査が完了したことを通知する。内視鏡向け拡張として後処置まで含めた検査が完了したことを通知する。アクイ
ジションモダリティは、PS の完了を PPSM に通知し、PPSM は DSS/OF とイメージマネー
ジャに通知する。[RAD-7]__________________________________________________________________________
15
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Modality Images Stored (モダリティ画像/エビデンス格納済み) – 内視鏡画像の保存。アクイジショ
ンモダリティは、収集または生成された画像をイメージアーカイブ送信する。[ENDO-8、RAD-8 および RAD-43 から派生]
Modality Presentation State Stored (モダリティ画像表示状態情報の保存) – 内視鏡画像の表示状態
情報の保存。アクイジションモダリティは、収集または生成された画像の表示状態情報をイ
メージマネージャに送信する。[RAD-9]
Storage Commitment (保存委託) – 内視鏡画像データなどの保存の保証の確認。要求元(アクイジションモダリティ)はエビデンス文書、要求元がイメージアーカイブシステムに格納した指定の DICOM オブジェクト(画像)に対する所有権をイメージマネージャが確認することで、イ
メージマネージャが所有するようになったこれらのオブジェクトを送信側が削除できるよ
うにすることを要求する。[ENDO-9、RAD-10 から派生]
Image Availability Query (指定画像確認) – 指定した画像が存在するかどうかの確認。イメージマネ
ージャは指定された画像が存在することの確認を返す。[RAD-11]
Patient Update (患者更新) – 患者情報が更新されたことを通知。ADT 患者登録システムは、OP お
よび DSS/OF に対し、特定の患者に対する新しい情報を通知する。DSS(部門スケジュール
管理システム)は、さらにそれをイメージマネージャに通知する場合がある。[RAD-12]
Procedure Update (処理更新) – 内視鏡検査オーダーが更新されたことを通知。DSS/OF は、イメー
ジマネージャに対し、オーダーまたは処理の更新された情報を送信する。[RAD-13]
Query Images (画像問合わせ) – 内視鏡検査画像の検索。画像表示装置は、イメージアーカイブシス
テムに対し、患者、検査、シリーズ、またはインスタンスを指定して、画像を表すエントリ
ーのリストを問合わせする。[RAD-14]
Query Presentation State (画像表示状態情報検索) – 内視鏡画像の表示状態情報の検索。画像表示状
態情報（GSPS）の問合せを行う。[RAD-15]
Retrieve Images (画像参照) – 内視鏡検査画像の取得。画像表示装置は、イメージアーカイブシステ
ムに特定の画像または画像の組合わせを要求して取得する。[ENDO-10、RAD-16 から派生]
Retrieve Presentation State (画像参照) – 内視鏡画像の表示状態情報の検索。画像表示状態情報（GSPS）の検索結果を返す。[RAD-17]
Creator Image Stored (画像保存) – 新しい画像データの保存。イメージアーカイブシステムに新しい画像データを保存する。[RAD-18]
Creator Presentation State Stored (画像表示状態情報保存) – 内視鏡画像の表示状態情報の保存。画
像表示状態情報（GSPS）を保存する。[RAD-19]
Creator Procedure Step Progress (画像処理開始通知) – イメージクリエータは、PPS マネージャへ特定の画像の画像処理を開始したことを通知する。[RAD-20]
Creator Procedure Step Completed (画像処理完了通知) – イメージクリエータは、PPS マネージャへ
特定の画像の画像処理が完了したことを通知する。[RAD-21]
Report Submission (レポート送信) – レポートを Report Creator から Report Manager へ送信する。
[RAD-24]
Report Ready (レポート作成可能通知) – レポート作成可能状態を Report Manager から ReportCreator へ通知する。 [RAD-24]
Report Issuing (承認済みレポート送信) – 画像データを含めた承認済みレポートのレポートリポジ
トリへの送信を行う。[RAD-25]
Query Reports (レポート検索) – レポート読み込みのための検索を行う。[RAD-26]
Retrieve Reports (検索されたレポートの取得) – 検索されたレポートの取得を行う。[RAD-27]__________________________________________________________________________
16
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Patient Status (患者状況) – Modality を用いる検査以外の前後処置における検査依頼に基づく進捗状
況の検索・取得。モダリティ以外でのワークリストが生成される。Worklist の拡張として
PPS マネージャに渡される。[ENDO-1]
Report Status Ready (レポート開始準備) – 内視鏡オーダーの発生に伴い、Report Manager に対してレポート作成が可能でる旨の情報を引き渡す。 [ENDO-2]
Path. Order ID Ready (病理オーダー準備) – 病理部門に対して生検の検査依頼のためのオーダー準
備を Order Manager に促す。 [ENDO-3]
Path. Order ID Request (病理オーダー番号取得) – 検体採取後、病理オーダー番号の取得を行う。
[ENDO-4]
Path. Specimen ID Request (検体 ID 番号取得) –各検体の ID 番号の生成と取得を行う。 [ENDO-5]
Report Status Completed (レポート開始準備) – 内視鏡検査のレポートが完了したことを通知する。
[ENDO-6]
Path. Specimen Counts (検体数情報取得) –Specimen Manager から Order Manager に格納された検体数
情報の取得を行う。 [ENDO-7]
表 2.4-1は、どの統合プロファイルでどのトランザクションが使用されるのかを示したものである。

表 2.4-1. 統合プロファイルのトランザクション

Integration Profile ENDO
Transaction
Patient Registration

X[RAD-1]

Placer Order Management [RAD-2]

X

Filler Order Management [RAD-3]

X

Procedure Scheduled [RAD-4]

X

Modality Worklist Provided/Query Modality Worklist [RAD-5]

X

Modality Procedure Step In Progress [ENDO-7、RAD-6 より派生]

X

Modality Procedure Step Completed [RAD-7]

X

Modality Images Stored [ENDO-8、RAD-8 および RAD-43 から派生]

X

Modality Presentation State Stored [RAD-9]

X

Storage Commitment [ENDO-9、RAD-10 から派生]

X

Image Availability Query [RAD-11]

X

Patient Update [RAD-12]

X

Procedure Update [RAD-13]

X

Query Images [RAD-14]

X

Query Presentation State [RAD-15]

X

Retrieve Images [ENDO-10、RAD-16 から派生]

X

Retrieve Presentation State [RAD-17]
Creator Image Stored [RAD-18]
Creator Presentation State Stored [RAD-19]

X
X
X__________________________________________________________________________
17
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________X

Creator Procedure Step Progress [RAD-20]

X

Creator Procedure Step Completed [RAD-21]

X

Report Submission [RAD-24]
Report Issuing [RAD-25]

X

Query Reports [RAD-26]

X

Retrieve Reports [RAD-27]

X

Patient Status [ENDO-1]

X

Report Status Ready [ENDO-2]

X

Path. Order ID Ready [ENDO-3]

X

Path. Order ID RequestX[ENDO-4]

Path. Specimen ID Request [ENDO-5]

X

Report Status Completed [ENDO-6]

X

Path. Specimen Counts [ENDO-7]

X

注:時刻管理トランザクションは、正式には内視鏡ワークフロープロファイルの一部ではないが、時刻クライアントアク
タがこのプロファイルの特定のアクタとグループ化されるために必要である。

2.5 製品の実装
開発者には、製品の実装に IHE アクタとトランザクションを実装する際にいくつかのオプションがある。決定には 4 レベルのオプションがある。
•

システムのレベルでは、組込むアクタを選択する。1 つのシステムに対して複数のアクタが許される。

•

各アクタのレベルでは、アクタが参加する統合プロファイルを選択する。

•

各アクタ-プロファイルのレベルでは、実装するオプションのトランザクションを選択する。サポー
ト対象のプロファイルに対して必須のトランザクションは、すべて実装しなければならない。(3-5
節の統合プロファイルの表を参照)•

最後に、各トランザクションのレベルでは、サポートするオプション機能を選択する。(ENDO-TF
ボリューム II または該当する分野の TF のトランザクションの説明を参照)

実装者は、特定の製品に組み込まれている IHE アクタ、IHE 統合プロファイル、オプショントランザク
ション、およびオプション機能を示す文書を提供しなければならない。このような文書の推奨される形式については、付録 C を参照していただきたい。
一般に、製品の実装には、任意の一つのアクタまたはアクタの組合わせを組み込むことができる。ただし、以下の場合には、1 つのアクタを実装に際し、それ以外の 1 つ以上のアクタを実装しなければならない。
•

イメージアーカイブサーバはイメージマネージャとグループ化する必要があり、またイメージマネ
ージャはイメージアーカイブシステムとグループ化しなければならない。

•

内視鏡上部消化管ワークフローの統合プロファイルに参加するイメージマネージャは、PPSM とグ
ループ化する必要がある。グループ化された PPSM は、構成を通して無効にできなければならない。

__________________________________________________________________________
18
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________•

内視鏡上部消化管ワークフローに参加する DSS/OF は、PPSM とグループ化する必要がある。グループ化された PPSM は、構成を通して無効にできなければならない。

•

内視鏡上部消化管ワークフロー統合プロファイルに参加する DSS/OF アクタと取り込みアクタは、
時間整合プロファイルのタイムクライアントアクタとグループ化する必要がある。

単一製品の実装で複数のアクタをグループ化する場合は、サポートされる各アクタで開始または終了するすべてのトランザクションをサポートする必要がある(つまり、IHE トランザクションは外部製品インターフェイスで提供する必要がある)。このルールに対する例外は、上で定義されている必須のグループ化におけるアクタの間で定義されているトランザクションである。
例えば、PPSM とイメージマネージャを単一のシステムでグループ化する場合は、これらの間の処理ス
テップ処理中/完了トランザクションをサポートする必要はない。
2 つ以上のアクタをグループ化する場合、アクタ間の内部通信は、それらの機能をサポートするために必要な情報フローの実現に十分であるものと見なされる。例えば、イメージマネージャは、イメージア
ーカイブシステムがその問い合わせ/取得機能をサポートするために必要な情報更新を提供する。このような内部通信の厳密なメカニズムは、IHE テクニカルフレームワークの対象外である。

__________________________________________________________________________
19
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

3 上部消化管検査ワークフロー
内視鏡上部消化管検査ワークフロー統合プロファイルでは、内視鏡検査手技の背景における基本的な患者データの連続性と整合性が確立される。このプロファイルは、特に、患者 ID と患者基本データの一貫した処理を取り扱う。これには、検査手技の開始後まで、さらには検査手技が終了してから長い時間が経過するまで、本当の身元がわからない急患のものも含まれる。また、さまざまな画像、測定、解析
システム間における検査手技データのスケジューリングと調整、および以降のワークフローステップ(報告など)をサポートするためのデータ収集場所でのデータのアーカイブへの確実な保管も指定されている。さらに、複数フェーズ(診断と治療)になる可能性のある検査手技のステップの完了ステータスの集中的な調整も行う。
このプロファイルは、IHE 放射線予約済ワークフロー、患者情報の整合性確保(Patient Information
Reconciliation :PIR)、およびエビデンス文書の各統合プロファイルとよく似ているが、複数モダリティの調整および内視鏡分野に固有のデータ要件がいっそう明示的に扱われている。HL7 メッセージおよびDICOM 情報オブジェクトに対する IHE テクニカルフレームワークによって採用されている統合ワーク
フローデータモデルについては、Rad TF-1: 3.4 を参照すること。このデータモデルは、ワークフロー
に対する 3 つの主要な制御レベルを提供する。
•

オーダー: 部門サービスに対する依頼。

•

依頼済検査処置: 体系化された請求可能な行為が関連付けられた、1 つ以上の報告が生成される作業の単位。

•

予約済みおよび実行済みの検査処置ステップ: ワークフロー内の作業の最小単位で、予約済
み(実施すべき作業)または実行済み(実施された作業)である。

ワークフローのデータモデルの明確な理解は、内視鏡上部消化管ワークフロー統合プロファイルを解釈するために非常に重要である。
内視鏡上部消化管ワークフローの主要なケースについては以下の節で説明するが、放射線部門の対応するワークフローも見ておくと役に立つ。Rad TF-1: 3.3 では、既知の患者に対してデータモデルの 3 つの制御レベルすべてを完全に利用したときの"通常の"予約済みワークフローについて説明されており、Rad TF-1: 4.3 と 4.4 では、患者が未知の場合および/またはオーダーと予約のプロセスが省略されている場合(例えば急患のケース)のワークフローについて説明されている。

3.1 アクタ/トランザクション
図 1.10-1は、
このプロファイルに関係するアクタと、アクタ間のトランザクションを示したものである。

__________________________________________________________________________
20
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________ADT

Pt. Registration [Rad-1] ↓Patient Updae [Rad-12] ↓↓ Pt. Registration [Rad-1]↓ Patient Updae [Rad-12]← Placer Order Management [Rad-2]→ Filler Order Management [Rad-3]

Order Placer

Order Filler↓ Modality
Worklist
Provided[Rad-5]↑ Modality PPS in Progress [Rad-6]↑ Modality PPS Completed [Rad-7]↓ Pt. Status [Endo-1]
Path Order ID Ready [Endo-3] ↓Path Order ID Request [Endo-4] ↑PPS Manager← Modality PPS in Progress [Rad-6]← Modality PPS Completed [Rad-7]↓ Procedure Scheduled [Rad-4]↓ Patient Updae [Rad-12]↓ Procedure Updae [Rad-13]↑ Image Availability Query [Rad-11]

Image Manager

Image Archive

StorageCommitment[Rad-10] ↓↑ Modality Image Stored [Rad-8]↑ Modality Presentation
State Stored [Rad-9]

Acquisition Modality← Modality PPS in Progress [Rad-6]← Modality PPS Completed [Rad-7]→ Modality PPS in Progress [Rad-6]→ Modality PPS Completed [Rad-7]

Query Images[Rad-14] ↓Query Presentation State [Rad-15] ↓Retrieve Images[Rad-16] ↓Retrieve Presentation State [Rad-17] ↓Order Manager→ Path Order ID Ready [Endo-3]← Path Order ID Request [Endo-4]↑ Path Specimen Counts [Endo-7]

Path Specimen ID Request [Endo-5] ↓Report Creator

Image Display

Specimin Manager
Path Order ID Request [Endo-4]↓
Report Status Completed [Endo-6] ↑→ Modality PPS in Progress [Rad-6]→ Modality PPS Completed [Rad-7]← Report Status Completed [Endo-6]↓ Report Submission [Rad-24]↑ Report Status Ready [Endo-2]

Report Manager↓ Report Issuing [Rad-25]
Report Repository↓ Query Report [Rad-26]↓ Retrieve Report [Rad-27]
Report Reader

図 3.1-1. 内視鏡上部消化管ワークフローの図

定義の整合性を保つため、この図では放射線部門テクニカルフレームワーク(Rad-TF)で指定されている
アクタ名とトランザクション名が使用されていることに注意すること。
表 3.1-1 は、内視鏡上部消化管ワークフロー統合プロファイルに直接含まれる各アクタに対するトランザクションのリストである。この統合プロファイルをサポートする実装は、必須のトランザクション__________________________________________________________________________
21
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________("R"のラベルが付いているもの)を実行する必要がある。"O"というラベルが付いているトランザクショ
ンはオプションである。この統合プロファイルで定義されていて、実装がサポートできるオプションの
完全なリストについては、3.2 節を参照すること。

表 3.1-1. 内視鏡上部消化管ワークフロー - アクタとトランザクション

ActorsADT Patient
Registration
Order Placer

DSS/OF

Acquisition Modality

Image Manager/
Image Archive

Performed Procedure
Step Manager

Image Display

Transactions

Optionality

SectionPatient Registration [Rad-1]

R

RAD-TF 2: 4.1

Patient Update [Rad-12]

R

RAD-TF 2: 4.12

Patient Registration [Rad-1]

R

RAD-TF 2: 4.1

Patient Update [Rad-12]

R

RAD-TF 2: 4.12
RAD-TF 2: 4.2

Placer Order Management [Rad-2]

R

Filler Order Management [Rad-3]

R

RAD-TF 2: 4.3

Patient Registration [Rad-1]

R

RAD-TF 2: 4.1

Placer Order Management [Rad-2]

R

RAD-TF 2: 4.2

Filler Order Management [Rad-3]

R

RAD-TF 2: 4.3

Procedure Scheduled [Rad-4]

R

RAD-TF 2: 4.4

Query Modality Worklist [Rad-5]

R

RAD-TF 2: 4.5

Modality Procedure Step In Progress [Rad-6]

R

RAD-TF 2: 4.1

Modality Procedure Step Completed [Rad-7]

R

RAD-TF 2: 4.7

Patient Update [Rad-12]

R

RAD-TF 2: 4.12

Procedure Updated [Rad-13]

R

RAD-TF 2: 4.13

Pt. Status [ENDO-1]

R

ENDO-TF 2: 4.1

Path Order ID Ready [ENDO-3]

R

Path Order ID Request [ENDO-4]

R

Query Modality Worklist [Rad-5]

R

RAD-TF 2: 4.5

Modality Procedure Step In Progress [Rad-6]

R

RAD-TF 2: 4.6

Modality Procedure Step Completed [Rad-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [Rad -8]
Modality Presentation State Stored [RAD-9]
Storage Commitment[RAD-10]

R
R
R

RAD -TF 2: 4.2
ENDO-TF 2: 4.9
ENDO-TF 2: 4.10

Procedure Scheduled [Rad-4]

R

RAD-TF 2: 4.4

Modality Procedure Step In Progress [Rad-6]

R

RAD-TF 2: 4.6

Modality Procedure Step Completed [Rad-7]

R

RAD-TF 2: 4.7

Patient Update [Rad-12]

R

RAD-TF 2: 4.12

Procedure Updated [Rad-13]

R

RAD-TF 2: 4.13

Query Images [Rad-14]
Query Presentation State [RAD-15]
Retrieve Images [RAD-16]
Retrieve Presentation State [RAD-17]

R
R
R
R

RAD-TF 2: 4.14
RAD-TF 2: 4.15
RAD-TF 2: 4.16
RAD-TF 2: 4.17

Modality Procedure Step In Progress [Rad-6]
Modality Procedure Step Completed [Rad-7]

R
R

RAD-TF 2: 4.6
RAD-TF 2: 4.7

Pt. Status [ENDO-1]
Report Status Completed [ENDO-6]
Query Images [Rad-14]

R
R
R

ENDO-TF 2: 4.1
ENDO-TF 2: 4.6
RAD-TF 2: 4.14__________________________________________________________________________
22
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Order Manager

Specimen Manager
Report Creator
Report Manager

Report Repository

Report Reader

Retrieve Images [ENDO-10]
Modality Procedure Step In Progress [ENDO-7]
Modality Procedure Step Completed [Rad-7]
Path Order ID Ready [ENDO-3]
Path Order ID Request [ENDO-4]
Path Specimen ID Request [ENDO-5]
Report Status Completed [ENDO-6]
Path Specimen ID Request [ENDO-5]
Report Submission [Rad-24]
Modality Procedure Step Completed [Rad-7]
Report Submission [Rad-24]
Report Issuing [Rad-25]
Report Status Ready [ENDO-2]
Path Order ID Request [ENDO-4]
Report Status Completed [ENDO-6]
Report Issuing [Rad-25]
Query Report [Rad-26]
Retrieve Report [Rad-27]
Query Report [Rad-26]
Retrieve Report [Rad-27]

R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R

ENDO-TF 2: 4.4
ENDO-TF 2: 4.1
RAD-TF 2: 4.7

RAD-TF 2: 4.7

このプロファイルに対する前提条件となる可能性のある他のプロファイルについては、表 2.1-1を参照すること。

3.2 上部消化管検査ワークフロー統合プロファイルのオプション
多くのアクタは幅広い分野の対応に必要な実装のバリエーションに適応する為、オプションが定義されている。表３．２−１に、この統合プロファイルに対して選択できるオプションを、それを適用できる
アクタ毎に示す。特定のオプションの幾つかはこのプロファイルのアクタの実装に必須である（他のプロファイルにおいては本当にオプションであっても）。

表 3.2-1 予約済ワークフロー - アクタとオプション

Actor

Option Name

Optionality

Vol & Section

ADT Patient Registration

No options defined

-

-

OP
DSS/Order Filler

No options defined--

Multi-modality Procedure Update

R

Acquisition Modality

ENDO-TF 2: 4.1

PPS Exception Management

O

RAD-TF 2: 4.7

Patient Based Worklist QueryO

RAD-TF 2: 4.5R(See note)

RAD-TF 2: 4.5

PPS Exception Management

Broad Worklist QueryO

RAD-TF 2: 4.7

PPS Exception Management

O

RAD-TF 2: 4.7

Intermittently Connected Modality

R

ENDO-TF 2: 4.3

ENDOScopic CathR

ENDO-TF 2: 4.2

Image Display

No options defined--

Performed Procedure Step Manager

No options defined--

Image Manager/ Image Archive__________________________________________________________________________
23
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
注: Broad Worklist Query はケース C7 のサポートのために必須である。また、マルチモダリティ環境ではワークフローの効率的運用のためにも必要である。
アクイジションモダリティおよびイメージマネージャ/イメージアーカイブシステムは、さまざまな
DICOM SOP クラスをサポートする可能性がある。このレベルのオプション性は、IHE 統合ステートメ
ントの参照により文書化することが望ましい(付録 C を参照)。

3.3 予約済プロセスフロー
各プロセスフローはエンドユーザの問題（”臨床的背景”）と本テクニカルフレームワークで採られているアプローチ（”IHE 背景”）とともに紹介されている。
臨床的背景: このプロセスフローは、放射線部門の検査と同様に、患者が施設に受付され、内視鏡検査
処置がオーダーおよび予約されている状況を反映している。放射線部門ではスケジュールド（予約済み）
ワークフローは正常な、または予想される状況であるが、現状では内視鏡検査においては例外的ケースが発生する場合が有ることに注意すること。内視鏡検査処置および全体的な治療状況に対するその関係については、付録 A も参照すること。
IHE 背 景 : こ の 節 で は 、 IHE デ ー タ モ デ ル の 3 レ ベ ル の 制 御 (order, requested procedure, andscheduled/performed procedure steps)をすべて完全に利用して既知の患者に対する処置を要求する場合の、"通常の"予約済ワークフローについて説明する。実際には、急患があり得るという性質のため、内視鏡検査処置に対してはオーダーが作成されない場合があるが、このプロセスフローは、3.4 節で説明されている特定のユースケースを理解するための基本を示している。実際、このワークフローと患者情報修正（PIR）ステップが 3.4 節のケース C1 となっている。
放射線部門と比較するには、RAD-TF 1:3.3 を参照していただきたい。
注：Order Change Flow (RAD-TF 1:3.3.3)と Exception Management Workflow (RAD-TF 1:3.3.4)をそこに説明されている通り使用しても良い。この内視鏡テクニカルフレームワークではそれ以上説明はしない。
それらのデータフローの機能性は特定のトランザクションにより起動される事が ENDO-TF で明記されている。

__________________________________________________________________________
24
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________PPSManager

Order
Filler

Order
Placer

ADT

IM/IA

ReportManager

Order
Manager

SpecimenManager

RegisterJ.Doe
Patient Registration [RAD-1][RAD-1]Create Order
Placer OrderManagement
New [RAD-2]

Trace
Study
[OR ^R01]

Schedule
Procedure
患者受付

Start
Procedure
Pt.Status[ENDO-1]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]

図 3.3-1 スケジュールド（予約済）ワークフロー: 管理プロセスフロー

管理プロセスフローに関しては、次のことに注意する必要がある。
•

患者登録: Patient Registration のデータは、OP や DSS/OF などの複数のシステムにブロードキャストされる。

•

オーダー生成: OP は、患者に関するすべてのオーダーの施設全体でのリポジトリである。
処置予約: DSS/OF は、オーダーと、オーダーを満たすために実行する必要のある 1 つ以上の Request•

Procedure を関連付ける。各 Request Procedure では、アクイジションモダリティによって実行される必要のあるいくつかの動作が記述されている。動作は、タイミングとシーケンスおよびモダリティに基づいて、SPS において指定されている。SPS は予約され、つまり時間スロットと実行リソース(モダリティ)が割り当てられ、モダリティワークリストクエリーで利用できるようになる。
•

処置開始: DSS/OF には、内視鏡検査手技を開始するためのオプション機能が存在する場合がある。
これは、普通、検査手技に明確に結び付けられてはいるが、特定のモダリティの範囲には含まれない患者データを収集できるようにするためである。これにより、例えば、関連する SPS において__________________________________________________________________________
25
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________“Arrived (到着)”ステータスが設定される場合がある。このアクションの目的は、モダリティ以外のアクタから検査手技を開始することである。
•

モダリティワークリスト問い合わせ: モダリティワークリスト(MWL)クエリーは、範囲が広い場合も(その中から 1 つを選択するための予約済検査手技のリストを取得する)、患者固有の場合も(1 人の患者に対する予約済検査手技を取得するために十分なクエリーキーを提供する)ある。後者の場合
は、リストバンドのバーコードの患者 ID を MWL クエリーに入力することで容易になる(施設の内視鏡検査室の標準運営手順として)。

•

患者選択: MWM への応答が単一の SPS の場合、モダリティは患者選択機能を最適化して、それ以•Order Filler から PPS Manager, IM/IA, Report Manager, Order Manager, Specimen Manager へまとめて出されるこれら電文は Procedure Scheduled [RAD-4]と全て同一のトランザクションとなる。

•

管理プロセスでは、検査後のレポート記載に向けた準備も考慮して Procedure Scheduled [RAD-4]はReport Manager, Specimen Manager にも必要となる。

上明示的なユーザクションがなくても SPS を選択できる。

Order
PlacerPPSManager

Order
FillerAcquisition
Modality

IM/IA

ReportManager

Order
Manager

Report Creater/ImageDisplay

SpecimenManager

ReportRepository

前処置開始
処理
進捗：
前処置開始
[RAD-6]

Trace
Study
拡張
[RAD-3]

前処置完了
処理

進捗：
前処置完了
[RAD-6]

Trace
Study
拡張
[RAD-3]Modality Worklist [RAD-5]

Perform
Acquisition

Modality Procedure Step In Progres[RAD-6][RAD-6]

画像受信の準備
Modality Procedure Step
In Progres [RAD-6]

検査開始(study in progress)を以てレポート作成をEnableとする

Modality Procedure Step In Progres [RAD-6]
レポート作成指示
Report Status Ready [ENDO-2]

Study In Progressが出ていることが必須条件

Modality Procedure Step In Progres [RAD-6]
Modality Procedure Step In Progres [RAD-6]
生検標本ID発行
病理オーダ発行依頼（検体IDを受けて）生検発生の準備(手動）

Path. Specimin Request [ENDO-5]

Path. Order ID Request [ENDO-4][RAD-3]
病理オーダ番号取得[RAD-2]

Path. Order ID Ready [ENDO-3]

病理オーダ発行

病理オーダ番号をRMへ通知
Path. Order ID Request [ENDO-4]
病理オーダ番号をRCに通知
Report Status Ready [ENDO-2]

図 3.3-2-1. スケジュールド（予約済）ワークフロー: 処置実施プロセスフロー(1/3)__________________________________________________________________________
26
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Order
PlacerPPSManager

Order
FillerAcquisition
Modality

Study Comleted[RAD-7]

IM/IA

ReportManager

Order
Manager

Report Creater/ImageDisplay

SpecimenManager

ReportRepository

検査完了

Modality PPS Completed [RAD-7][RAD-7]
Modality PPS Completed [RAD-7]
Modality PPS Completed [RAD-7]
Study Comleted [RAD-7]
Modality PPS Completed [RAD-7][RAD-7]

トータル検体数通知（フラグをリリース）
Path. Specimin Request [ENDO-5]

検体数情報取得[RAD-3]（取りに行く；実装は自動又は人系）
Path. Specimin Counts [ENDO-7][RAD-8]Modality Image Stored（画像保存）[RAD-9] Modality Presentation State Stored（画像取得情報保存）[RAD-10]Storage Commitment（保存委託）
レポートマネージャへ画像参照が出来るようになった事を通知
画像完了 Image Availability Query [RAD-11]

Query Image [RAD-14]
Query Presentation State [RAD-15]
Retrieve Images [RAD-16]
Retrieve Presentation State [RAD-17]

画像完了[RAD-3][Rad-14]Query Images, [Rad-16]Retroeve Images

画像取得
レポート作成レポート作成完了
オーダ完了（内視鏡下生検、後処置薬剤の集計が出来ていれば、会
ダ 完
Report Status Completed [ENDO-6]

Report Submission [RAD-24]
レポート登録Query Report [RAD-26]
Retrieve Report [RAD-27]

オーダ完了[RAD-7]

オーダ完了[RAD-3]

図 3.3-2-2. スケジュールド（予約済）ワークフロー: 処置実施プロセスフロー(2/3)__________________________________________________________________________
27
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Order
PlacerOrder
FillerPPSManager

Acquisition
Modality

ReportManager

Order
Manager
レポート作成完了

正式病理オーダ依頼

Report Status Completed [ENDO-6]

Path Order ID Request [ENDO-4]（Order Placerは）この後、病理のOrder Fillerにオーダ（を）発行（する）[RAD-3]

リカバリ開始（手動）

リカバリ情報？？

リカバリ開始[RAD-6][RAD-3]

リカバリ情報？？
[RAD-3]

リカバリ完了（手動）リカバリ完了[RAD-7]

図 3.3-2-3. スケジュールド（予約済）ワークフロー: 処置実施プロセスフロー(3/3)

処置実施プロセスフローに関しては、次のことに注意する必要がある。
•

モダリティ処理ステップ処理中(MPPS in Progress)およびスケジュール更新: 検査の最初の予約が曖昧であったり(時刻や内視鏡検査室が明確に指定されていない)、予約されたものとは別の検査室で検査処置が実行されたりする場合がある。DSS/OF が処置を開始していない場合は、内視鏡検査室に対する最初の MPPS In Progress を受け取った時点で(これには、患者の ID/名前およびモダリティ
Station AE Title が含まれており、特定の内視鏡検査室とリンクできる)、DSS/OF は、現在アクティ
ブなケースを反映するように、同じ内視鏡検査室内のすべてのモダリティに対する SPS を更新する(つまり、最初の MPPS が"現行患者/検査室選択"としての役割を果たす)。

•

モダリティワークリスト問い合わせ: 予約更新プロセスに続いてその内視鏡検査室内のモダリティ
からの MWL 問合わせでは、現行患者に対する単一の SPS のみの MWL 応答を返す十分なリクエス
トキーによる広範な問合わせを使用して、モダリティの起動を最適化できる。

•

アクイジション実施: 各モダリティは、イメージマネージャ/アーカイブシステムに格納されるさま
ざまな画像や他のエビデンス(波形や分析レポートなど)を生成できる。イメージマネージャ/アーカ
イブシステムは、ENDO Option (ENDO-TF 2:4.2.1 参照)にある通り、画像だけでなく、これらのオブジェクトをすべてサポートする必要がある。

•

モダリティ処理ステップ完了(MPS:Modality Procedure Step Complete)、処理終了（End Procedure）:
MPS 完了には、MPS 中止も含まれる。マルチステップ処置（診断･インターベンション）やマルチ
モダリティの相互関係があるため、単に完了または中止の通知だけではモダリティが使用可能になった事を示さない。これは、DSS/OF が検査室内のモダリティ資源を他の検査に使用できるようになったかを判断するための機能である。

•

データ保存委託: イメージマネージャ/イメージアーカイブシステムは格納された画像とエビデン
スに対する責任を受け継ぎ、モダリティがローカルストレージからデータを削除できるようにする。

__________________________________________________________________________
28
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
イメージマネージャ/アーカイブシステムは、トロリー移動型のような移動式装置をサポートする必要がある。このような装置は、断続的にネットワークに接続され、一時的に保存委託メッセージを受信できなくなる場合がある。
•

フィラーオーダー管理−ステータス更新: 最初の MPS 処理中および最後の MPS 完了の後の更新のみが示されているが、ステータス更新トランザクションはワークフロー内の複数のポイントにおいて OP に送信される場合がある。

•

PPS Manager から IM/IA, Report Manager, Order Manager, Specimen Manager へまとめて出されるこれ
ら電文は Modality PPS Completed [RAD-7]と全て同一のトランザクションとなる。

•

処置プロセスフローとして生検標本が発生した場合のフローを示している。生検標本が発生しなかった場合には、これにまつわるいくつかのトランザクションは省略されることになり、次項からのユースケースで説明する。

•

内視鏡における検査では、レポート作成が必須事項となり検査あるいは処置の終了直後に行われ、このレポート作成終了及び患者のリカバリ終了までを処置プロセスとする点において、放射線と異なることに注意する必要がある。

3.4 上部消化管検査ワークフローのユースケース
この節では、上部消化管内視鏡検査ワークフロープロファイルに対して定義されている具体的なユース
ケースとプロセスフローについて説明する。
臨床的背景: 現在、内視鏡検査を実施する最も一般的なシナリオは、診察を行った主治医が、患者に内視鏡検査を受けるように勧め、電話で処置を手配するというものである。これは、内視鏡検査室に関する単純なロジスティックな手配であり、正式な電子的予約作業が含まれる場合もある(この機能は、ユビキタスな"ホワイトボード"によって代わりに提供される)。この時点では、3 つのパスのいずれかを使用できる。つまり、オーダーエントリーシステムにおいて検査手技をオーダーする、部門システムで検査手技をオーダーする、または内視鏡検査室でのオーダーなしで検査手技を開始する、のパスである。
現在の典型的な内視鏡検査室の慣習では（存在したとしても）部門システムと病院の OP システムとの連携では統一性は少ない。IHE における目指すゴールの 1 つとしてこの二つの世界のより積極的な統合であり、それにより、OP システムが均一化されたシステムとして各部門にオーダー管理を提供できるようになる事である。内視鏡検査ワークフロープロファイルの臨床的背景は、現在の慣習からより高度な統合された病院全体のワークフローへの進化への促進である。
IHE 背景: ユースケースの多くには、患者情報の事後更新に必要なトランザクションのセットが含まれている。放射線部門のテクニカルフレームワークでは、これは独立した患者情報の整合性確保（PIR:Patient Information Reconciliation）プロファイルで指定されているが、内視鏡検査ワークフローではケースのいくつかでこの処理を行う必要があるため、患者の更新は基本的な内視鏡検査ワークフロー
プロファイルに含まれている。ただし、このような整合に対する特定のデータフローは、プロセスフロ
ー図では青色で示されている。
これらのユースケースは、放射線分野における PIR プロファイル (RAD-TF 1:4.4)に相当する。RAD-TFに詳しい読者が容易に比較できるよう、以下の各章で放射線分野と内視鏡分野のプロセスフロー図の違いを緑色で示してある。
内視鏡検査ワークフローに対しては６つの、C1 から C6、具体的なユースケースが定義されている。患者が登録されているかどうか、またその場所、およびオーダーが出されているかどうか、またその場所に基づいて、バリエーションが発生する。次の表はこのバリエーションを示したものである。内視鏡検査ユースケース C1 から C6 は RAD-TF PIR ユースケース 1 から 6 に密接に対応している。

__________________________________________________________________________
29
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
内視鏡検査オーダーのユースケース以外の追加ユースケースである「ケース C7: 検体採取無しによる病理オーダー無し」と「ケース C8:処置の中断・中止」は表には示されていない。
表 3.4-1.内視鏡検査ワークフローのケース

Order
Placement

Order Placed atOrder Placer

Order Placed atOrder Filler

Order Not Placed

Patient
Registration
Patient Registered at ADT

Case C1

Case C2

Case C3

Patient Registered in the
Department (see note)

Not Applicable - theOrder Placer requires
the patientregistration from the
ADT system

Case C4

Case C5

Case C6

Case C6

Case C6

Patient Updated

注: 患者は、DSS/OF システムの部門で、または手動で(紙上で一時的な ID が割り当てられ、モダリティに手入力されている)登録されている。

注： モダリティ画像/エビデンス格納済みと格納委託のトランザクションは下記の章には記載されていない。オーダーステータス更新トランザクションも記載されていない。これらのトランザクシ
ョンはプロセスコントロールワークフローには影響を与えない。幾つかの選択された“モダリティ N”（複数の追加される検査室内のモダリティ）のみ、マルチモダリティの性質を表すためのみ記載されている。
プロセスフロー図に記載されている実施済み処理ステップマネージャは表現のために記されているのであり、実際は Image Manager（IM）にまとめられている。実際のインプリメンテーション
では DSS/OF にまとめられる事もあり、PPS のフローの変化に対応し IM と DSS/OF 間のトランザクションに関係している。

3.4.1 ケース C1: ADT で患者登録が行われ Order Placer で処置オーダーが出される
臨床的背景: これは、従来の放射線部門の構造化されたワークフローに対応し、内視鏡検査のオーダー
が病院のオーダーリングシステムにおいて出される。また、患者に対して急患 ID が作成される特殊な状況も考慮されている(患者が ADT に登録され、固有の ID が割り当てられるよう)。オーダーは処置が開始する前に出されるので、共通の ID を使用して、内視鏡検査に関係するすべての情報の整合された表示と電子的な配信が可能である。
IHE 背景: このケースには、IHE データモデルの 3 レベルの制御(order, requested procedure, andscheduled/performed procedure steps)オーダーをすべて完全に利用して処置を依頼する場合の、完全なス
ケジュールド（予約済）ワークフローが含まれる(3.3 節を参照)。
患者は、完全な患者基本情報を持つ既知の患者としても、患者 ID と一時的な名前だけが割り当てられているまったく身元不詳の患者のケースを含む不完全な患者基本情報を持つ患者としても、ADT シス
テムにおいて登録することができる。内視鏡検査ワークフローの後続のサブシステムにとって、完全な__________________________________________________________________________
30
For Public Comment

Copyright © 2005: JAHIS

書式変更 : フォント : 10.5
pt, コンプレックス スクリプト用のフォント : 10.5 pt

IHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
患者基本情報がわかっているか否かは、処置の実行に無関係である。したがって本ケースには、身元が分かっているあるいは分かっていない患者の両方に対し、ADT で登録され、オーダーが OP で生成され、DSS/OF によって処置が予約される。
身元不明の患者の場合は、ADT システムが、施設内で患者を整合する単一のポイントである。患者の実際の身元がわかるときには、ADT は、自身の記録を整合するだけでなく、対応する変更について OP
および DSS/OF に通知する。ADT は、OP と DSS/OF の両方に患者更新メッセージを送信する。DSS/OFは、患者更新メッセージをイメージマネージャに送信する。

図中、波線により省略されているプロシージャは図 3.3-1，図 3.3-2-1，図 3.3-2-2 及び図 3.3-2-3 で示した内容と同じである。

__________________________________________________________________________
31
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order
PlacerADTPPSManager

Order
FillerAcquisition
Modality

IM/IA

ReportManager

Order
Manager

Report Creater/ImageDisplay

SpecimenManager

ReportRepository

RegisterJ.Doe
Patient Registration [RAD-1][RAD-1]Create Order
Placer OrderManagement
New [RAD-2]

Schedule
Procedure

Trace
Study
[ORU^R01]

患者受付

Start
Procedure
Pt.Status[ENDO-1]
Procedure
Scheduled[RAD-4]進捗：
前処置完了[RAD-6]

Trace
Study
拡張
[RAD-3]

Perform
Acquisition

Modality Worklist [RAD-5]

Modality Procedure Step In Progres[RAD-6][RAD-6]

画像受信の準備
Modality Procedure Step
In Progres [RAD-6]

検査開始(study in progress)を以てレポート作成をEnableとする

Modality Procedure Step In Progres [RAD-6]
レポート作成指示
Report Status Ready [ENDO-2]

Study In Progressが出ていることが必須条件

Modality Procedure Step In Progres [RAD-6]
Modality Procedure Step In Progres [RAD-6]

レポート作成完了フラグ
正式病理オーダ依頼

Report Status Completed [ENDO-6]

Path Order ID Request [ENDO-4]（Order Placerは）この後、病理のOrder Fillerにオーダ（を）発行（する）[RAD-3]

リカバリ開始（手動）
リカバリ開始リカバリ情報？？ [RAD-6][RAD-3]

リカバリ完了（手動）リカバリ情報？？
[RAD-3]

リカバリ完了[RAD-7]

図 3.4-1. ADT で登録され、OP でオーダーされた患者−ケース C1__________________________________________________________________________
32
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
重要なトランザクション:•

患者情報の整合を取るため、ADT は、新しい患者を登録し、一時的な患者と正しい患者をマージし、患者登録 [Rad-1]トランザクションと患者更新 [Rad-12] (マージ)トランザクションを OP
および DSS/OF に送信できる。

•

恒久的な患者 ID が割り当てられた場合には、ADT は、適切な情報を含む患者更新 [Rad-12]ト
ランザクションのみを送信してよい。

3.4.2 ケース C2: ADT で患者登録されて DSS/OF で処置オーダーされる臨床的背景: このシナリオはケース C1 とよく似ているが、オーダーは従来の病院オーダーシステムで出されるのではなく、部門システムが処置情報の入力後、情報を病院オーダーシステムに送信する。通常、このワークフローは多数の施設で典型的なものであり、部門または内視鏡検査室にオーダーエント
リーシステム(HIS)を置く必要が軽減される。
IHE 背景: このケースは、ケース C1 が基になっている。ただし、この状況では、登録済の患者に対する処置オーダーは、DSS/OF によって生成され、OP に対して送信される。処置は普通に予約され、収集システムはモダリティワークリストを使用する。
患者情報が後で整合を必要とする場合には、ADT は OP と DSS/OF の両方に患者更新メッセージを送信する。DSS/OF は、ケース C1 と同様に、イメージマネージャに患者更新メッセージを送信する。

__________________________________________________________________________
33
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________PPSManager

Order
Filler

Order
PlacerADT

Acquisition
Modality

IM/IA

ReportManager

RegisterJ.Doe
Patient Registration [RAD-1][RAD-1]

Fillerr OrderManagement
New [RAD-3]

Schedule
Procedure

Start
Procedure
Pt.Status[ENDO-1]
Procedure
Scheduled[RAD-4]

正式病理オーダ依頼

Report Status Completed [ENDO-6]

Path Order ID Request [ENDO-4]（Order Placerは）この後、病理のOrder Fillerにオーダ（を）発行（する）[RAD-3]

リカバリ開始（手動）

リカバリ情報？？

リカバリ開始[RAD-6][RAD-3]

リカバリ完了（手動）リカバリ情報？？
[RAD-3]

リカバリ完了[RAD-7]

図 3.4-2. ADT で登録され DSS/OF でオーダーされるーケース C2

重要なトランザクション:•

フィーラオーダー管理 (新規オーダー)トランザクション[Rad-3]は、DSS/OF から OP に送信される。

__________________________________________________________________________
34
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
3.4.3 ケース C3: ADT で登録され処置がオーダーされていない患者
臨床的背景: このシナリオはケース C2 に似ているが、部門システムでは入力されない(時間的な制約などにより)。したがって、関係するモダリティの 1 つが、共通の処置 ID を作成するプロセスを開始する必要がある。ID は、処置を開始した最初のモダリティ(通常は内視鏡システム)によって実行されたアクションに基づいて、部門システムにおいて作成される。作成された ID は、以降のモダリティで共有できる。詳細な検査手技情報は、最初のモダリティによって提供されるものに限られる。例えば、符号化された検査手技タイプを提供できない場合は、“generic endo procedure” (一般内視鏡検査手技)と示される。可能な場合には常に、ケース C1 または C2 のプロセスフローを使用することが望ましい。
IHE 背景: ケース C1 および C2 と同様に、登録済みの患者(身元判明/身元不明)に対して ADT が生成す
る恒久的な患者 ID を使用する。ただし、アクイジションモダリティが検査手技を開始する前にオーダー入力または予約は行われない。恒久的患者 ID はアクイジションモダリティにおいて入力される(一般的には患者のリストバンドから。バーコードリーダーを使用すればデータ入力エラーは少なくなるかも知れない)。
このケースは、放射線分野の対応するケースとは異なる。内視鏡検査手技は本質的にシングルモダリテ
ィであるが、稀にマルチモダリティの場合もあるので、患者と検査に対してすべての装置が共通の IDセットを使用することが重要である。したがって、最初の MPS 処理中(Modality Procedure Step In
Progress)を受け取ったなら、DSS/OF は、最初の MPS 処理中によって提供される検査 UID を利用して、内視鏡検査に対する処置要求と、同じ内視鏡検査室におけるすべてのモダリティに対する関連する
SPS(Scheduled Procedure Steps)を自動的に作成する。その後、その検査室内の他のモダリティは、モダ
リティ問い合わせワークリストトランザクションを使用して調整された ID を取得できる。
詳細は Appendix B を参照のこと。
処理要求が自動的に作成されると、ケース C2 と同様に、DSS/OF は汎用的な内視鏡検査処置コードを使用しオーダーを生成して OP に送信した後、イメージマネージャに処置予約済みを送信する。
注:１．放射線部門の TF との違いは、DSS/OF による処置要求の作成が、MPPS (Modality Performed
Procedure Step)完了メッセージではなく、MPPS 処理中 (N-CREATE)メッセージで行われることである。これにより、マルチモダリティは同じ処置要求に対して同期できる。
２．また、内視鏡検査室において時間が重視されるマルチモダリティの起動を可能にするための SPS の迅速な作成が遅れる可能性があるため、DSS/OF は、オーダープレーサ番号オーダーを含む応答を OP が返すのを待たずに、処置要求を作成する。

患者情報が後で整合を必要とする場合には、ADT は OP と DSS/OF の両方に患者更新メッセージを送信する。DSS/OF は、ケース C1 と同様に、イメージマネージャに患者更新メッセージを送信する。

__________________________________________________________________________
35
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order
Filler

Order
PlacerADTPPSManager

Acquisition
Modality

IM/IA

ReportManager

Order
Manager

Report Creater/ImageDisplay

SpecimenManager

RegisterJ.Doe
Patient Registration [RAD-1][RAD-1]Modality Procedure Step In Progres[RAD-6]

Perform
Acquisition
Auto create
Procedure
画像受信の準備
Modality Procedure Step
In Progres [RAD-6]

検査開始(study in progress)を以てレポート作成をEnableとする

Modality Procedure Step In Progres [RAD-6]
レポート作成指示
Report Status Ready [ENDO-2]

Study In Progressが出ていることが
必須条件

Modality Procedure Step In Progres [RAD-6]
Modality Procedure Step In Progres [RAD-6]

レポート作成完了フラグ
正式病理オーダ依頼

Report Status Completed [ENDO-6]

Path Order ID Request [ENDO-4]（Order Placerは）この後、病理のOrder Fillerにオーダ（を）発行（する）[RAD-3]

リカバリ開始（手動）
リカバリ開始リカバリ情報？？ [RAD-6][RAD-3]

リカバリ完了（手動）リカバリ情報？？
[RAD-3]

リカバリ完了[RAD-7]

図 3.4-3. ADT で登録され処置がオーダーされていない患者−ケース C3

重要なトランザクション:•

最初のアクイジションモダリティから見たときの、このケースとケース C1 および C2 との間の違いは、MWL 問い合わせ(示されていない)が現在の患者に対する応答を返さないことである。
予約されていない処置実施済みステップを作成する必要がある。

•

MPS(Modality Procedure Step)処理中 [ENDO-1]を受け取ると、DSS/OF は、それを未予約のケースとして認識するが、患者 ID を以前に受け取った ADT 情報と対応させることができる。

•

患者 ID とモダリティステーション名を含む MPPS トランザクションからの情報を使用して、
DSS/OF は新しい要求済み処置を作成し、同じ内視鏡検査室のすべてのモダリティに対するSPS(Scheduled Procedure Steps)も作成して、現在のアクティブなケースを反映する。患者は登録されているので、DSS/OF は患者 ID に関連付けられている患者基本情報を受け取ることに注意すること。

__________________________________________________________________________
36
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________•DSS/OF は、OP にフィラーオーダー管理 (新規オーダー)トランザクション[Rad-3]を送信し、フィラーオーダー管理（ステータス更新）が処理中を示し、イメージマネージャに処置予約済み
トランザクション[Rad-4]を送信する。

•

この内視鏡検査室の装置からの以降のモダリティワークリスト問い合わせ[Rad-5]は、必要な患者/検査 ID を含む適切な SPS を受け取る。

•

モダリティによって実行されたアクションに基づき ID が作成されるため、モダリティを用いる
以前の前処置プロセスフローは、システムとしては省略されることになる。

3.4.4 ケース C4: DSS/OF で登録されて処置がオーダーされた患者
臨床的背景: 部門でオーダーが出されるケース C2 のバリエーションである。これには、病院システムに患者を登録するのに十分な時間がない場合、または ADT システムが利用できない場合(時間外など)の緊急ケースが含まれる。ただし、このシナリオでは、患者 ID は病院 ADT からは入手できない。一時的な患者 ID が部門レベルで作成され、処置情報を入力できる。オーダーエントリーシステムはまだ通知できない(患者 ID がまだ一時的であるため)。しばらくの後、ADT システムにおいて登録が行われ、その時点で一時的患者 ID との整合を行うことができる(部門システムにおいて手動で)。その後、オーダーエントリーシステムにも通知できる。
IHE 背景: このケースでは、ADT システムからの DSS/OF では有効な患者 ID を利用できない。DSS/OF
は、一時的な患者 ID と名前を割り当て、必要な検査手技を予約する。一時的患者 ID による予約済検査
手技は、イメージマネージャに送信される。
注:

DSS/OF は、割り当てる一時的患者 ID がスコープ内で一意であることを保証する必要がある。

ただし、ケース C2 とは異なり、一時的な患者 ID が OP の ADT ドメインスコープの範囲外なので、要求済み処置が作成された時点で、DSS/OF はフィラーオーダー管理 (新規オーダー)トランザクションをOP に送信しない。同様に、MPPS 処理中または完了に基づいてオーダーステータス更新トランザクシ
ョンが送信されることもない。
モダリティにおける処置の実行は、モダリティワークリストに基づいて普通に行われる。
患者の情報がわかると、ADT システムは、新しい患者情報を、OP と DSS/OF の両方に送信する。DSS/OFは(普通は手動プロセスを使用して)、受信した患者情報と、一時的患者 ID に関連付けられた情報を整合し、恒久的な患者記録と一時的記録をマージして、患者更新トランザクションをイメージマネージャに送信する。同時に、DSS/OF は、恒久的患者 ID を使用してオーダーを生成して OP に送信した後、オーダーに対するオーダープレーサ番号オーダーでイメージマネージャを更新する。

__________________________________________________________________________
37
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order
PlacerADTPPSManager

Order
FillerAcquisition
Modality

IM/IA

ReportManager

Order
Manager

Report Creater/ImageDisplay

Assign J.Doe
Temp Patient ID
Schedule
Procedur
Pt.Status[ENDO-1]

リカバリ開始（手動）

リカバリ情報？？

リカバリ開始[RAD-6][RAD-3]

リカバリ情報？？
[RAD-3]

リカバリ完了（手動）リカバリ完了[RAD-7]

RegisterJ. Smith
Patient Registration [RAD-1]

Patient Reconciliation
J.Doe->
J. Smith[RAD-1]

Patient Update/Merge [RAD-Filler Order Management New [RAD-3]

Patient Update/Merge [RADPatient Update/Merge [RAD-Filler Order Management
Status Update [RAD-3]

Patient Update/Merge [RAD-図 3.4-4. DSS/OF で登録されて処置がオーダーされた患者−ケース C4

重要なトランザクション:•

患者情報は、ADT からの患者登録を使用して、DSS/OF によって内部的に整合される。

•

DSS/OF は、患者更新トランザクション[Rad-12]と処置更新トランザクション[Rad-13]をイメー
ジマネージャに送信する。

•

DSS/OF は、フィーラオーダー管理 (新規オーダー)トランザクション[Rad-3]を OP に送信する。

__________________________________________________________________________
38
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
3.4.5 ケース C5: 未登録の患者
臨床的背景: ケースC3とC4 (前記)を組み合わせたものである。このケースでは、患者はADTシステムにおいて登録されておらず、かつ、それより前にオーダーエントリーまたは部門システムにおいてオーダーは出されていない。このようなケースは、使用できる患者情報がない、または患者情報を収集するための十分な時間がないような、救急状況において発生する場合がある。また、ADTまたは他の重要な
HISコンポーネントが利用できないような、緊急性の低い状況でも発生する。ケースC3とC4のすべてのアクティビティが実行される必要がある。部門によって割り当てられた一時的患者IDが、検査手技を開始するために最初のモダリティにおいて入力される。そのモダリティは、患者と検査手技の情報を、他のモダリティと共有するために、部門システムに転送する。この検査手技情報は、オーダーエントリー
システムにはまだ送信できない。有効なIDがADTから利用できるようになると、部門システムは、患者IDの整合とオーダーエントリーシステムへの通知の処理を完了できる。
IHE 背景: このケースでは、DSS/OF が ADT システムから利用できる有効な患者 ID はなく、処置が実施される前にオーダーまたは予約は行われていない。一時的な ID と名前はモダリティにおいて入力される(患者リストバンドは、有効な ADT システム患者 ID であり、ケース C3 でカバーされるので、ここでは使用されない)。患者 ID と名前は、ローカルに定義されているルールに従って選択される。例えば、定義済みの"患者 ID - 患者名"ペアのプールから選択する。一時的な患者 ID を選択するルールでは、
DSS/OF のスコープ内での一意性が保証されていなければならない。
ケース C3 と同様に、患者と検査に対してすべての装置が共通の ID セットを使用することが重要である。したがって、最初の MPS(Modality Procedure Step)処理中を受け取ったなら、DSS/OF は、最初のMPS 処理中によって提供される検査 UID を利用して、内視鏡検査に対する要求済み処置と、同じ内視鏡検査室におけるすべてのモダリティに対する関連する SPS を自動的に作成する。その後、その検査室内の他のモダリティは、問い合わせモダリティワークリストトランザクションを使用して調整されたID を取得できる。
注:

最初のモダリティからの MPS 処理中と、モダリティワークリストで SPS を利用できるようになるまでの間には、時間差が存在する事に関しては Appendix B を参照すること。

ただし、ケース C4 と同様に、一時的な患者 ID が OP の ADT ドメインスコープの範囲外なので、要求済み処置が作成された時点で、DSS/OF はフィーラオーダー管理(新規オーダー)トランザクションを OPに送信しない。
注:

放射線部門の TF との違いは、DSS/OF による要求済み処置の作成が、MPPS 完了メッセージではなく、MPPS 処理中 (N-CREATE)メッセージで行われることである。これにより、マルチモ
ダリティは同じ要求済み処置に対して同期できる。

患者の情報がわかると、ADT システムは、新しい患者情報を、OP と DSS/OF の両方に送信する。ケー
ス C4 と同様に、DSS/OF は(普通は手動プロセスを使用して)、受信した患者情報と、一時的患者 ID に関連付けられた情報を整合し、恒久的な患者記録と一時的記録をマージして、患者更新トランザクショ
ンをイメージマネージャに送信する。同時に、DSS/OF は、恒久的患者 ID を使用してオーダーを生成して OP に送信した後、オーダーに対するオーダープレーサ番号オーダーでイメージマネージャを更新する。

__________________________________________________________________________
39
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order
PlacerADT

OrderFillerPPSManager

Acquisition
Modality

ReportManager

IM/IA

Order
Manager

Report Creater/ImageDisplay

SpecimenManagerEnter J.Doe
Temp Patient ID

Modality Procedure Step In Progres [RAD]Perform
Acquisition
Auto create
Procedure
画像受信の準備
Modality Procedure Step
In Progres [RAD-6]

検査開始(study in progress)を以てレポート作成をEnableとする

Modality Procedure Step In Progres [RAD-6]
レポート作成指Report Status Ready
示 [ENDO-

Study In Progressが出ていることが必須条件

Modality Procedure Step In Progres [RAD-6]
Modality Procedure Step In Progres [RAD-6]

リカバリ開始（手動）

リカバリ情報？？

リカバリ開始[RAD-6][RAD-3]

リカバリ情報？？
[RAD-3]

リカバリ完了（手動）リカバリ完了[RAD-7][RAD-3]

RegisterJ. Smith
Patient Registration [RAD-1]

Patient Reconciliation
J.Doe->
J. Smith[RAD-1]
Filler Order Management New [RAD-3]

Patient Update/Merge [RADPatient Update/Merge [RADPatient Update/Merge [RAD-Filler Order Management
Status Update [RAD-3]

Patient Update/Merge [RAD-図 3.4-5. 未登録の患者−ケース C5

重要なトランザクション:•

最初のアクイジションモダリティから見たときの、このケースとケース C3 との違いは、MWL
クエリー(示されていない)が現在の患者に対する応答を返さず、ADT システムが発行した患者
ID がないことである。
ローカルに作成した患者 ID を使用して、予約されていない PPS(Performed
Procedure Step)を作成する必要がある•

MPS(Modality Procedure Step)処理中トランザクション[ENDO-1]を受け取ると、DSS/OF はそれを
未予約のケースとして認識し、ケース C3 の場合とは異なり、患者 ID を以前に受け取った ADT
情報と対応させることはできない。

•

一時的な患者 ID とモダリティステーション名を含む MPPS トランザクションからの情報を使用して、DSS/OF は新しい要求済み処置を作成し、同じ内視鏡検査室のすべてのモダリティに対す
る SPS も作成して、現在のアクティブなケースを反映する。

__________________________________________________________________________
40
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________•

患者情報は、ADT からの患者登録を使用して、DSS/OF によって内部的に整合される。

•

DSS/OF は、患者更新/マージトランザクション[Rad-12]をイメージマネージャに送信する。

•

DSS/OF は、フィーラオーダー管理(新規オーダー)トランザクション[Rad-3]を OP に送信する。

•

処置ステップ完了トランザクションおよび出されたオーダーの情報を使用して、DSS/OF は、(古い)処置予約済みトランザクション[Rad-4]を、新しい正式なオーダープレーサ番号オーダーを含
むイメージマネージャに送信する。

3.4.6 ケース C6: 処置中に更新された患者
臨床的背景: 身元不明の患者は、ADT システムにおいて登録され、患者の一時的な患者基本情報と共に内視鏡検査室に送られる場合がある。検査手技の処理中に、ADT システムは患者の正しい患者基本情報を取得し、更新メッセージを送信できる。このような状況では、情報の一部を元の(一時的な)患者基
本情報から取得し、一部を変更された基本情報から取得することができる。このケースでは整合を行う
方法を示す。
IHE 背景: 最初の患者登録とオーダー発行が発生した後で、更新が必要になる場合がある。更新を行い、続けて元の患者登録およびオーダー発行の情報と共に画像を送信する前に、モダリティは、部門システ
ム予約に情報を要求する場合がある。イメージマネージャは、イメージアーカイブシステムに格納されている項目、およびモダリティから続けて受け取る可能性のある項目の、患者情報を更新する必要がある。

__________________________________________________________________________
41
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order
Filler

Order
PlacerADTPPSManager

Acquisition
Modality

ReportManager

IM/IA

Order
Manager

Report Creater/ImageDisplay

SpecimenManager

ReportRepository

Enter J.Doe
Temp Patient ID

Modality Procedure Step In Progres [RAD]Perform
Acquisition
Auto create
Procedure
画像受信の準備
Modality Procedure Step
In Progres [RAD-6]

検査開始(study in progress)を以てレポート作成をEnableとする

Modality Procedure Step In Progres [RAD-6]
レポート作成指示
Report Status Ready [ENDO-

Study In Progressが出ていることが必須条件

Modality Procedure Step In Progres [RAD-6]
Modality Procedure Step In Progres [RAD-6]

ModifyPatient
Patient Update/Merge [RAD-12]
Patient Update/Merge [RAD-12][RAD-12]Update Patientin stored objects
Patient Update/Merge [RAD-12]

Update Patientin stored objects

Patient Update/Merge [RAD-12]

Update Patientin stored objects

Patient Update/Merge [RAD-12]

Update Patientin stored objects

Update Patientin stored objects

Patient Update/Merge [RAD-12]

Update Patientin Procedure and Steps

リカバリ開始（手動）

リカバリ情報？？

リカバリ開始[RAD-6][RAD-3]

リカバリ情報？？
[RAD-3]

リカバリ完了（手動）リカバリ完了[RAD-7]

図 3.4-6. 処置中に更新された患者−ケース C6

重要なトランザクション:•

モダリティは、患者情報の更新が発生した後でも、元の患者情報を使用して引き続き情報を送
信できる。

•

イメージマネージャは、患者更新トランザクションが完了した後でも、引き続き患者情報を整合する必要がある。

__________________________________________________________________________
42
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
一部のトランザクションのみが示されている。他のトランザクションは、他のプロファイルユースケー
ス要件に従って実行される。

3.4.7 ケース C7: 検体採取無しによる病理オーダー無し
臨床的シナリオ:内視鏡検査において検体採取が無い場合はめずらしくない。検査前に採取を確定することは出来ず、検査によって検査中に採取の判断と実施が行われる。このため、内視鏡検査で検体採取が実施されることを想定した準備を整えて検査を行う必要があり、検査終了時に検体採取の有無が結果として判明することになる。
IHE 背景: このケースでは、内視鏡検査において検体採取を行わなかったことによる病理オーダーが無い場合の処理手順について説明する。
検体取得は検査によって決まるため、検査開始時には病理オーダーがなされても問題がないように、病理オーダーに向けた準備段階まで進めておく。
検体取得が行われなかった場合には、Specimen Manager によって生検発生の入力が行われず、病理オー
ダーの手続きが発生しないまま、検査終了手続きが行われることになる。
また、内視鏡オーダー終了手続き中のレポート作成直後における正式な病理オーダー依頼の手続きも発生しない。
つまり、この 2 箇所の病理オーダーに関する手続きが発生しないだけであり、それ以外の手続きは病理
オーダーが発生した場合と同じとなる。
放射線部門のテクニカルフレームワークには対応するケースがないことに注意すること。
一部のトランザクションのみが示されている。他のトランザクションは、他のプロファイルのケース要件に従って実行される。

__________________________________________________________________________
43
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order
PlacerPPSManager

Order
FillerAcquisition
Modality

ReportManager

IM/IA

Order
Manager

Report Creater/ImageDisplay

SpecimenManager

ReportRepository

Perform
Acquisition

Modality Worklist [RAD-5]

Modality Procedure Step In Progres[RAD-6]
画像受信の準備[RAD-6]
Modality Procedure Step
In Progres [RAD-6]

検査開始(study in progress)を以てレポート作成をEnableとする

Modality Procedure Step In Progres [RAD-6]
レポート作成指Report Status Ready
示 [ENDO-

Study In Progressが出ていることが必須条件

Modality Procedure Step In Progres [RAD-6]
Modality Procedure Step In Progres [RAD-6]

生検発生無し検査完了

Study Comleted[RAD-7]

Modality PPS Completed [RAD-7][RAD-7]
Modality PPS Completed [RAD-7]
Modality PPS Completed [RAD-7]
Study Comleted [RAD-7]
Modality PPS Completed [RAD-7][RAD-8]Modality Image Stored（画像保存）[RAD-9] Modality Presentation State Stored（画像取得情報保存）[RAD-10]Storage Commitment（保存委託）

画像完了 Image Availability Query [RAD-11]
画像完了[RAD-3]

レポートマネージャへ画像参照が出来るようになった事を通知Query Image [RAD-14]
Query Presentation State [RAD-15]
Retrieve Images [RAD-16]
Retrieve Presentation State [RAD-17][Rad-14]Query Images, [Rad-16]RetroeveI
レポート作成完

オーダ完了（内視鏡下生検、後処置薬剤の集計が出来ていれ

オーダ完了
オーダ完了
[RAD-3]

画像取得
レポート作成Report Submission [RAD-24]
レポート登録Query Report [RAD-26]
Retrieve Report [RAD-27]

Report Status Completed [ENDO6][RAD-7]
レポート作成完了フラグ

リカバリ開始（手動）

リカバリ情報？？

リカバリ開始[RAD-6][RAD-3]

リカバリ情報？？
[RAD-3]

Report Status Completed [ENDO6]

リカバリ完了（手動）リカバリ完了[RAD-7]

図 3.4-7. 処置中の部屋の変更−ケース C7__________________________________________________________________________
44
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

3.4.8 ケース C8: 処置の中断・中止
臨床的シナリオ:内視鏡検査が中止された場合、情報システムは中止の状況を把握して、内視鏡検査室
スタッフが患者に関する問い合わせに対して対応できるようにしておくことが重要である。
IHE 背景: このケースでは、内視鏡検査が開始される前に中止になった場合の処理手順について説明する。処理は図 3.4-8 にあるように OP システムか DSS/OF からオーダーされる。DSS/OF は処理要求 ID
や Study Instance UID の発行、処置のスケジュール、IM への通知を実施する。
もし処置が部門で中止された場合は DSS/OF が OP と IM に通知する。
３つのシステム全ては、DSS/OF、OP、IM で、中止になったオーダー情報と処置要求情報等を設定されている時間ないし、施設で規定されている時間保持してもよい。
処理が中断・停止となるタイミングでは前処置が完了している場合もあり、内視鏡検査前の処置フローの進捗がシステムで管理される場合もあることに注意が必要である。

__________________________________________________________________________
45
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
Order
PlacerADTPPSManager

Order
FillerAcquisition
Modality

IM/IA

ReportManager

Order
Manager

Report Creater/ImageDisplay

SpecimenManager

RegisterJ.Doe
Patient Registration [RAD-1][RAD-1]CreatePlacer OrderManagement
New [RAD-2]

Trace
Study
[ORU^R01]

Schedule
Procedur
患者受付

Start
Procedure
Pt.Status[ENDO-1]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]

Schedule
Procedur
Trace
Study
[ORU^R01]

患者受付

Start
Procedure
Pt.Status[ENDO-1]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]
Procedure
Scheduled[RAD-4]

図 3.4-8. 処置の中止−ケース C8__________________________________________________________________________
46
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix A: 内視鏡検査処置の概要
内視鏡と名の付く医療機器の範囲は広く、腹腔鏡やカプセル内視鏡（2005 年 8 月現在国内で未承認）もこのジャンルに含まれる。そして、それらのワークフローはとてもひとまとまりに括れるものではな
く、予約なしに聴診器感覚で使用されるものから、手術に準ずる（時に手術そのもの）処置として運用され得るものまで多種多様である。IHE-J の活動として内視鏡ワークフローの検討に入ったとき、当面のスコープ（対象範囲）を消化器内視鏡に絞ることとした。いわゆる予約有りのルーチン検査として行われ、かつ部門として独立した運用形態が整っていることが多い検査種として消化器内視鏡を最初のターゲットにしたことは決して的外れではなかったと考えている。この文中では、「内視鏡」という用語
は特別なことわりをしない限り、「消化器内視鏡」を指していると考えて頂きたい。
IHE において、内視鏡という検査種・モダリティについての検討は国際的には行われていない。現時点では IHE-J 独自の活動である。2004 年末に RSNA に合わせて行われた IHE の国際会議で日本独自の活動として紹介したところ、欧州のメンバーが興味を示したが、まだ、臨床検査のように共同作業が行われているわけではない。

ここでは、既に実用化されていた放射線の Scheduled WorkFlow(SWF)を対象に、IHE が提唱する基本的な概念が内視鏡で利用できるかを検討した。その概念はオーダーリングシステムとの連携に HL7 を
画像系システム間の連携に DICOM を利用するものである。
予約（オーダー）・受付・検査（画像生成）・レポート作成といった部分的なワークフローでは放射線と大きな違いはないが、内視鏡のモデルシナリオのワークフローとしては、異なる。このため、対象を外来上部消化管内視鏡検査のシナリオとした。

A.1 内視鏡ワークフローの特徴

A.1.1 内視鏡画像の相違点

内視鏡画像と放射線画像との大きな違いがその位置づけである。放射線画像は一般的に技師により撮影・撮像され、読影医の診断に供せられる。つまり診断の対象である。しかし、内視鏡画像は医師により撮影され、保存されるが、診断の対象になるとは限らない。撮影されたときには既に診断が完了していることが多いからである。内視鏡に於いて医師が診断の対象としているものは内視鏡観察中の動画像である。その意味では、現在、主に静止画として残されている内視鏡画像は診断に関連した画像の提示という意味では、むしろ放射線のキー画像に近い。
最近でこそ内視鏡には何らかの画像保存手段が備わっていることが多いが、旧来の機械では必ずしもそうでなかったことから、デジタル画像保存について十分な環境があったとはいいにくい。放射線におけるデジタル保存加算のようなインセンティブがないことも関連していると思われる。そもそも内視鏡
画像に関しては明確な保存義務がないと考えられている向きもある。もっとも、画像を含め可能な限りの医療情報を保存することが目標になり始めている現在、保存義務の有無についてはあまり議論する必要はないであろう。
内視鏡画像の多くは VGA 程度の解像度のセカンダリーキャプチャーであり、撮影された画像を見て診断するという位置付けでないことから、保存形式が Lossy(非可逆圧縮)画像であることにさほど抵抗__________________________________________________________________________
47
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________はない。このような条件は、現在の PACS の記憶容量から見れば静止画での保存は大きな負担となるものではない。また、記憶容量の増大は、現在多くの施設でローカルに保存している内視鏡の動画像を、将来的にはネットワーク上で保存する方向に向けることになるであろう。

A.1.2 内視鏡業務の位置づけ

前項で述べたように、内視鏡は医師により施行され、その観察結果等は概ね検査直後にその場で記録される。これは検査というよりも診察行為に近い。いや診察業務そのものと言える。医師の責任の元に種々の処置が行われることは、オーダーを受けてそれにそって検査等を実施する、というこれまでのオーダーリングと部門システムの考え方は、この業務に於いてかなりの違和感がある。そのことは内視鏡のワークフローの検討作業の中で行った、千葉大学病院のオーダーリングシステムにおけるオーダー内容と実施結果の違いの集計で、より明確となった。2004 年 6 月１ヶ月間の放射線及び内視鏡検査に於いて、オーダーと実施結果に相違つまり変更があった割合は、放射線が 1.2%であったのに対し、内視鏡は 48.2%であった。内視鏡のルーチン検査が占める割合が一般の診療施設に比べると低いことが予想される大学病院のデータであるので、多少過大評価の可能性もあるが、それでも内視鏡に於いては頻繁に処置内容が変えられていることが分かる。放射線に於いて内視鏡のように変更の多い検査種は血管造影(26.8%)であった。血管造影は往々にして治療手技として行われ、患者の状態に応じた処置内容の変
更は臨機応変に行われる。
内視鏡検査で変更が多い原因として、検査の前に麻酔や消化管運動抑制を初めとした種々の処置があり、終了後にも関連した後処置がある他、検査中に生検と呼ばれる組織採取が行われ、病理検査依頼が発生することが多いことなどが挙げられる。
これらを鑑み、ここでは内視鏡 SWF で前・後処置を含んだきめ細かい進捗管理を提案している。それ
ぞれのフェーズで薬品や医療器具など様々な物品を使用するが、その調達方法（院内物流）は施設毎にバラエティが多く、標準的なワークフローのアイデアを準備できなかったので、これらについてのオーダーとの関連や実施記録は今回の内視鏡 SWF 検討では対象外とした。

A.1.3 内視鏡レポートの位置づけ

内視鏡画像の位置付けとの関連もあり、レポートの位置付けも放射線とは大きく違う。放射線は原則として、画像が発生して初めてレポート作成の必要性が生じるが、内視鏡は検査をした時点でレポート作成が必要となる。仮に画像があろうがなかろうが、検査が成功しようが失敗しようが、レポートは必要になる。この点は業務の位置付けとして内視鏡検査が診療業務と考えると診療録の記録義務といった観点からの必要性もあるのであろう。いずれにせよ、放射線のように画像が厳然と存在し、それに対しての所見を記録するためにレポートを作成するという意味合いではなく、診察行為の一つとして行った検査が画像を伴った検査であったという意味合いであると考えて頂きたい。そこで、我々WG では、レポーティングのワークフローを内視鏡 SWF の中に含めた形で表現した。このことは他の IHE との関連に於いて意見が分かれるところかも知れないが、レポート作成までが検査のワークフローであるという概念を明確にする意味も含めて SWF に記述してある。
消化器内視鏡のレポートに関しては、MST（Minimal Standard Terminology)という用語集が世界内視鏡学会で提案されている。これは消化器内視鏡手技に関する多くの範囲の情報を構造化された形で記録できるように作られたもので、これまで日本を含め 10 カ国ほどの国で翻訳されており、日本消化器内視鏡学会でも内視鏡レポートでの利用を推奨している。このような用語集について言及するこ__________________________________________________________________________
48
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________とは本来 IHE のスコープ外であるかも知れないが、業務フローの標準化のみでなく、医療情報記述方法についても標準化できれば、その効果は絶大である。MST には検査理由などオーダーリングでも役立つ用語のテーブルがあるので、オーダーリングシステムの構築時にも有用である。標準用語集を用いたレポーティングシステムは、医学概念・入力ポリシーの統一、検査方針による最適化などを行わないとユーザにとって利用しにくいものになるので構築には細心の注意が必要である。医師・ベンダ
ー双方が MST の利用を前向きになって検討して頂きたい。

A.1.4 病理部門への検体検査オーダー

生検で採取された組織の処理は病理による検査依頼として出されるため、それにあわせて内視鏡室から病理部門へ検査依頼がオーダーとして出される必要がある。また、依頼を出すに当たり、上記のレポート情報を元にして依頼書を作成することとなる。内視鏡にワークフローがよく似ていると考えられる
心臓カテーテルに於いても、病理検査との関連づけは議論されていない。したがって、この部分は内視鏡の運用に於いて非常に重要な部分であると同時に、これまでの IHE のワークフローになかった運用概念である。
病理との連携を行うための作業として・生検で採取した検体に対して検体番号を振る。
・レポート作成時、どこから検体を採取したのか記録する。
・OrderPlacer(いわゆるオーダーリングシステムにおけるオーダーを出す部分)に病理オーダー発行を依頼する。このとき検査依頼情報の中に検体採取に関する情報を含めておく。
・病理部門システムはどの内視鏡検査から発生した病理検査であるかを記録しておき、検体番号に対応
して病理レポートを作成する。
これにより、内視鏡レポートから関連する病理レポートにリンクすることと、内視鏡の所見と検体の病理所見を関連づけながら参照するためのリンク情報が記録される。この試みによりこれまで縦割り的に機能していた部門システムやそこから発生したレポートが互いに連携して機能することが出来るようになる。ただし、これまで、他の部門に対してのオーダーを発行するという機能を持った部門システ
ムは一般的ではなく、この部分の実装に際してはオーダーリングシステム・部門システムともかなり大きな改造作業が必要になると考えられる。しかし、各システムがそれぞれ単体としては相当の機能を持ち合わせるようになったことから、このような情報連携は今後求められる重要な機能の一つとなるだろう。

__________________________________________________________________________
49
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix B: 内視鏡検査におけるワークフロー管理の課題
B.1 臨床的背景：診断とインターベンション処置
放射線科では臨床医は患者ヒストリ、身体所見、他の検査結果等を評価してから具体的に検査をオーダーする。内視鏡検査要求は臨床的に非常に違う慣習で扱われる。紹介医は通常内視鏡医に診断を求める（さらに特化してインターベンション医に診断を求めるかもしれない）。具体的な処置は内視鏡検査室
で、初期情報（診断画像結果）を入手時に、あるいは入手後に選択される事が一般的である。臨床活動
は、担当医が適切であると判断され選択される。更に、放射線科のモダリティ的に選択されるのと違い、選択される活動（“プロトコル”）はより臨床的に選択される。
ロジスティックと管理上の都合で、処置は恣意的に“診断”と“インターベンション”とに分けられている。実際双方のカテゴリの境界は不明瞭である。しかし、診断造影後のインターベンションのケースを除き（例えば、何かの限定的な理由で、同時にインターベンションがおこなえなかった場合）、オー
ダーする医師が事前にどちらかを限定して指定する事はまれである。

B.2 ワークフローの確立：要求処置と処理ステップ
過去においては（IHE 以前）、循環器領域ではカテーテル検査室で診断からインターベンションに移行する
場合、一般的に（しかし普遍的にではなく）、新しい DICOM の XA のスタディを作成していた。これは管理的にカテーテル検査室におけるこの二つのフェーズの区切りを付けておきたいからである。これは、理想的な方法ではないが、使用できる手段が DICOM XA スタディしか無い環境では仕方が無い事である。
一方、内視鏡検査でも、カテーテル検査と同様に診断からインターベンションに移行する場合がある。しかし、この二つのフェーズの区切りを付けることに問題は無いものの、必要性も無い。
しかし、IHE はワークフローの管理と、データの系統的管理のために幾つかのツールを提供している。主として、要求処置、予約済み処理ステップ（SPS）、実施済み処理ステップ（PPS）である。更に、IHE は XA
モダリティのみではなく、フルマルチモダリティ対応を内視鏡検査室内で対処している。この章ではこれら必須の IHE の構成に関して記述する。
SPS と PPS は予約されたものや、実施されたものでそのステータスが追跡されているもので、プロトコールに関連されているワークフローの中の一番小さなユニットである。上で述べられている通り、プロトコール
は内視鏡検査の臨床活動を表すものでありえる。

予約済みと実施済み処理ステップは、臨床手技に特定されているのではなく、モダリティに特定されている、関連するプロトコールも同様にモダリティに特定されている。
それにもかかわらず、適切なモダリティが PPSのプロトコールで、診断とインターベンションの処置フェーズを、識別してレポートする事は可能である。
IHE テクニカルフレームワークはユーザの施設の望むワークステップステータストラッキングを実現するた
めに、モダリティプロトコールの構成に柔軟性を提供している。

B.3 マルチモダリティと Ad Hoc（予定外）スケジュール
内視鏡検査室は本来はシングルモダリティでありマルチモダリティは稀である（透視、超音波等）。従って、本 TF のスコープ外とする。
マルチモダリティの場合では、データ入力エラーや患者の安全性の問題等が起きやすいのである。完全に同じ患者が全ての装置で選択される事が非常に重要なのである。IHE のゴールは単一の装置での一度の選択で、内視鏡検査室内の他のすべての装置に間違いなく正しい患者情報が提供され、結果として、
データ入力エラーの排除を実現することである。このゴールは頻繁に起きる緊急患者対応のための部屋__________________________________________________________________________
50
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________の割り当て等で、複雑になっていく。特定の検査室が使用されることが判るのは、実際に患者が搬入されてから決定される事もしばしば起きるからである。
DSS/OF は処置のスケジュール（予約）に責任がある。マルチモダリティの内視鏡検査室では使用されるかもしれない装置全てに対して SPS を作成する必要がある。特定の検査室と時間が前もって処置のために割り当てられる場合には、シンプルなモダリティワークリスト情報モデルで定義される特定されたリソースを割り当てる SPS で問題はない。しかし、現実世界ではこのような事は可能ではない。たとえ、そのような予約が可能であったとしても、緊急ケースで無効にされてしまうかもしれない。
Ad Hoc の予約に対応するために DSS/OF は通常どの検査室でも使用可能な“汎用的なリソース”で SPSを作成する。
“汎用的リソース”環境下で患者の単一選択を容易にするために、テクニカルフレームワークはマルチ
モダリティ処理更新機能を DSS/OF に指定して いる。DSS/OF は１つ以上のモダリティ（通 常Hemodynamics system）を“セレクタ”として指定しなくてはならない。そのモダリティはモダリティ
ワークリスト SPS により患者を選択し PPS を開始する。そのモダリティが最初の要求処置に対してモ
ダリティ処理ステップ処理中を送信した時、DDS/OF は全ての検査室内のモダリティに対して要求処置（と患者）の SPS をスケジュール（予約）する。検査室内の他のモダリティはその後で調整された患者と要求処置識別子をモダリティワークリストクエリトランザクションを使用して取得する。
注：最初のモダリティのモダリティ処理ステップ処理中と他のモダリティへの SPS がモダリティワー
クリストから入手可能になるまでに時差が生じる可能性がある。この時差は数秒から数分になる事が、しかし数時間ではない、予想される。内視鏡検査室では通常最初のモダリティの MPPS と他のモダリティのそれとに遅れが生じる、この遅れが通常は DSS/OF の遅れに適応するのに十分である。
しかし、他のモダリティは臨床的な理由からデータの取得をモダリティワークリストからの Study
Instance UID の提供を待たずに開始する必要が生ずるかもしれない。したがって、そのモダリティ
は別の Study Instance UID を使用することになる。ひとつの処置の中で別の Study Instance UID の拡散をできる限り避けることが非常に望ましい。このバージョンの IHE 内視鏡テクニカルフレーム
ワークでは複数の Study Instance UID の整合については扱わない。

B.3.1 未予約のケース一貫した患者、要求処置識別子の必要性は未予約のケースで、複数のモダリティで共有できる要求処置が入手不可能な場合、同様に、もしそれ以上でなければ、重要である（内視鏡検査ユースケース C3 とC5 を参照）。
テクニカルフレームワークは DSS/OF のマルチモダリティ処理更新機能にセレクタからの MPPS が未予約の場合自動的に要求処置の作成を義務付けている。この要求処置の自動作成が検査室内の全てのモダ
リティへの SPS の作成に必要な前提条件となっている。
上に述べている通り、要求処置は通常分化されていない“内視鏡診断”であることを表す。したがって、要求処理自動作成のためのディフォルトの処置タイプ（コードと、あるいは種類）を持つことは可能である。DSS/OF は適切な処置タイプを、MPPS で受け取ったプロトコールの属性をもとに、セットの中から選択する事も可能である。
このアプローチは放射線部門テクニカルフレームワークでのアプローチと多少違っている。RAD-TF
2:4.6.4.1.3 は以下のように述べている：
もし要求処置 ID が空のまま送信された場合（未予約要求処理ステップのケース）、DSS/OF と IMは例外を作成し適切な処置済みステップとのリンクをマニュアルで解決しなければならない。
放射線部門テクニカルワークフレームの意図は適切な要求処置と関連した PPS の最終的な整合を強制する事にある。

__________________________________________________________________________
51
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
実際内視鏡部門テクニカルフレームワークはこのコンディションを DSS/OF が要求処置（とマルチモダ
リティ SPS）を自動作成するトリガーに使用していることは放射線科のフレームワークの文面（マニュアル整合）と反対ではあるが、意図とはそうではない（未予約の PPS と要求処置の整合）。
内視鏡部門技術委員会の考えは放射線部門と内視鏡部門のテクニカルワークフレームにおけるアプローチの違いは MPPS 処理中のトランザクションの必要な使用法や使用目的に重要な違いはないという事である。また、マルチモダリティ処置更新オプションが必要な機能の特徴づけをしている。

B.4 モダリティ処置ステップ完了／中断
このテクニカルフレームワークはマルチモダリティ内視鏡検査室内の個々のモダリティが PPS/（データ）取得開始のためにモダリティワークリストから個別に SPS を選択する事を義務付けている。同様に、個々のモダリティは開始したどの PPS も完了または中断しなくてはならない。
全てのモダリティへの単一患者選択機能を助長するのと同様に、間違った患者選択も助長される。最初の装置での患者選択が誤っていた場合、最初の装置で作成された SPS を使用した検査室内の全ての装置で誤った患者が選択される。したがって、全てのモダリティで、誤った患者が“中断”される事が重要で、患者の誤認識問題が軽減される。

B.5 処置の開始と終了
内視鏡検査ワークフローは内視鏡検査室内のワークフローに焦点を合わせている。しかし、内視鏡イン
ターベンションの性質上、このプロファイルは内視鏡検査直前直後の検査室内で起きうる活動を無視できない。内視鏡検査のマルチモダリティ環境が引き起こす問題に関しては前述の通りであるが、マルチ
ロケーションでもあるため問題が起きる。１つの内視鏡検査は最大３箇所にわたりおこなわれる事もあり、それぞれの場所に個々の装置がある場合もある（処置準備室、診断検査室、リカバリー室）。
内視鏡検査前活動は重要な検査情報の収集、存在する全ての血液検査の確認、その他内視鏡検査を開始するのに必要な検査結果、検査室の準備、患者の到着の通知、患者との話し合いとサインの取得等がある。内視鏡検査後の活動は不測の事態に対しての患者のモニタ、全ての装置の検査の終了（完了）、検査室の清掃、完了（未使用）しなかった検査の中止等がある。内視鏡検査ワークフローはこれらの活動について記述する事はできないが、それらの存在については認識している。
そのような理由で、内視鏡検査において DSS/OF に“処置開始”オプション機能が付け加えられる。特に、処置開始オプションは以下のような利点がある：z

関連する SPS でステータス(0040,0020)で患者到着を登録できるz

患者到着ステータスを使用して検査室に提供されている幅広いクエリワークリストを減らす事ができる（個別の検査室が割り当てられていない場合）

z

収集された処置前情報を正確に検査室からの処置情報とまとめることが可能になる

z

処置がおこなわれる検査室を特定でき、同検査室内の全ての装置への患者の選択が単純化される（患者の安全性の向上）対応する DSS/OF の“処置終了”オプション機能は以下のような利点を提供する：z

個々の装置の検査終了を手動で確認する

z

完了しなかった検査の SPS を中止することで、検査が終了したことを示す事になり、部屋が占有されていない事を示す（部屋の清掃やその他の術後活動の開始を指示できる）

z

オーダーステータス更新をトリガして OP に送信する__________________________________________________________________________
52
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
このような理由で DSS/OF の内部機能として“処置開始”、“処置終了”機能が内視鏡検査ワークフロ
ーユースケースに含まれている。DSS/OF のインプリメンテーションにサポートされる事を強く推奨する。

B.6 グループ処置
B.6.1 グループ化処置とは内視鏡においての必要性について積極的に指示するものではないが、グループ化処置については、IHE
放射線テクニカルフレームワーク(RAD-TF-1:4.6)で記述されている。グループ化処置のケースは、多くは収集の効率と患者の快適さのために、2 つ以上の独立した依頼済処置の収集ステップをオペレータが組み合わせる際の、ワークフローを容易にするためのメカニズムを提供する。ただし、画像とレポートの表示は、やはり、個別の依頼済手処置において行う必要がある。グループ化処置を使用すると、単一の収集済画像セット(検査)が生成されるが、ワークフローのトランザクションでは、各依頼済処置に関係する画像サブセットの表示と解釈を個別に行うことができる。
IHE 放射線部門におけるグループ化処置は、CT 頭部や脊椎などの単一のモダリティに限定される。各
Modality Performed Procedure Step (MPPS)は、複数の Scheduled Procedure Step (SPS)および依頼済処置に関係する。
グループ化処置に関する問題の 1 つは、"実施済検査"に関連する依頼済処置の識別である。DICOM では依頼済処置は検査インスタンス UID によって識別され、通常、生成される画像は同じ検査 UID で格納される。グループ化されたケースでは、複数の依頼済処置が存在するので、これは不可能である。
従来の単一モダリティによるグループ化されたケースでは、検査 UID は比較的単純である。各依頼済
処置(RP)は、それぞれのオーダーフィラー指定検査インスタンスを識別する。モダリティは、さまざまな RP に関連する複数の Scheduled Procedure Step (SPS)を選択する。複数の RP 検査 UID が参照されるので、モダリティは、独自の“I-Study”検査インスタンス UID を作成し、グループ化処置収集(MPPS)に関連する画像/エビデンスを格納する。これにより、収集に関連するすべての画像/エビデンスが単一の“I-Study” UID に含まれるが、これには複数の RP 検査 UID に対する参照が含まれる。(グループ化されたケースで使用されるデータモデルの詳細については、RAD-TF-2、付録 A を参照)。

B.6.2 マルチモダリティ検査でグループ化されたケースが問題になる理由
内視鏡検査は、グループ化処置には最適である。通常は、個別に請求および報告する複数の処置が存在するが(内視鏡検査の診断フェーズと治療フェーズ)、装置を共用し、患者の安全と効率のために処置はまとめて実施される。
マルチモダリティのプロセスの場合は、先に概要を説明した従来のグループ化処置のアプローチでは問題が発生する。
従来のケースでは、各モダリティが独自の I-Study UID を作成して、グループ化されたケースにおいて作成される画像/エビデンスを保管する。ただし、I-Study UID は(定義上)モダリティごとに一意なので、マルチモダリティの処置では、処置に関係する画像/エビデンスが、モダリティごとに 1 つずつ、複数の I-Study UID に分散する。これにより、すべてのデータが共通の I-Study UID を共有する処置に関連付けられることによるワークフローの利点が失われる。

B.7 IHE 内視鏡で採用されている方法
内視鏡については原則、一検査一レポートである。
病理が別レポートであるのは病理自体が全く違う部門における検査であるという位置づけと考える。

__________________________________________________________________________
53
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
ただし、一つの内視鏡検査において一般診療としてのレポートと、臨床試験など特殊なプロトコルによるレポートとが発生することを否定しないものとした。
IHE 内視鏡では、処置から 2 つのレポート(診断と治療)と個別の請求が発生する場合でも、内視鏡検査に対しては単一の依頼済処置を使用することが強く推奨される。これにより、処置に対するすべてのデータを、依頼済処置の単一の検査インスタンス UID で収集できる。
この選択を支持する主張がいくつかある。
まず、IHE 放射線部門であっても(最新のバージョン)、依頼済処置とレポート/請求の間には厳密な 1:1の対応はない。1:1 ではない例として従来からあるのは乳房撮影法である。この場合、検査は 2 人の放射線医によって個別に読み取られ、2 つの個別のレポートが作成されるが、それでも単一の依頼済処置である。複数のレポートの作成は、Reporting Workflow の内部プロセスである。内視鏡検査のケースも同じように扱うことができる。つまり、単一の依頼済処置ではあるが、レポートプロセスでは 2 つの文書が生成される(IHE 内視鏡では、レポートと請求については今後の年度で扱う)。
第 2 に、内視鏡検査は、臨床的には単一の処置であり、患者は診察台に 1 回だけ乗る。処置のログには、内視鏡検査室に入る前から出た後までの、患者の連続した記録が収められる。また、治療データは、診断データなしでは解釈できない。処置後の内視鏡検査データの臨床的使用でも、同様に、データの単一項目に対する背景を提供するために、全体として見る必要がある。結果として、検査を 2 つの依頼済処置に分けても、効率のよい診療のためにはグループ化する必要があるので、あまり意味がない。
第 3 に、単一の依頼済処置は、部屋の変更の有無にかかわらず、診断内視鏡検査が治療に変化する処置を簡単にする。治療フェーズにおいてのみ処置に加わるモダリティ(IVUS など)が、診断フェーズの開始時に加わっていたモダリティとは異なる検査情報を持っていてもかまわない。
単一の依頼済処置であっても、診断フェーズと治療フェーズにおいてモダリティが収集したデータに対して個別の MPPS を作成できる(ただしオプション)。これらの MPPS は、モダリティに対する単一の診断/治療予約済処置ステップから、または独立した診断 SPS と治療 SPS から派生される。反対に、単一の依頼済処置では、オーダー受注側が個別の診断 SPS と治療 SPS を予約した場合、モダリティは単一の MPPS で両方を満たすことができる(SPS が同じ依頼済処置からのものなので、これはグループ化処
置のケースではない)。
ただし、一つの施設で２つの依頼済処置を実装してもかまわないが、その場合は、すべてのモダリティが診断フェーズに対するデータ収集を閉じて、新しい治療検査を開始する必要がある。したがって、マ
ルチモダリティ内視鏡検査室のユースケースに対しては、グループ化処置を禁止する必要がある。

__________________________________________________________________________
54
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix C: IHE 統合ステートメント
IHE 統合ステートメント(IHE Integration Statement)は、製品において意図されている IHE テクニカルフ
レームワークに対する準拠について記述するためにベンダが準備および公開する文書である。IHE 統合
ステートメントでは、IHE の重要な概念つまりアクタと統合プロファイル(テクニカルフレームワークのボリューム I、第 2 節で説明)に関して、対象製品がサポートするように設計されている特定の IHE 機
能を明らかにする。
これらの概念を理解しているユーザであれば、統合ステートメントを参考にして、相補システムで製品がサポートするとベンダが主張している統合のレベル、およびそのような統合が提供する臨床および運営の面での利点を、判別することができる。統合ステートメントは、特定の規格(HL7、DICOM、W3Cなど)に対する準拠のステートメントと併せて使用するように意図されている。
IHE は、IHE のアクタと統合プロファイルの実装をテストするためのプロセスを、ベンダに提供している。IHE テストプロセスは、コネクタソンという名前のマルチパーティ対話式テストイベントであり、ベンダに対して、有用なフィードバックと、実装の準拠状況の判断基準となる指示を提供する。ただし、このプロセスは、製品の準拠をそれだけで評価または保証することは意図されていない。コネクタソンの結果を公開し、ベンダの IHE 統合ステートメントへのアクセスを容易にすることで、IHE およびその後援組織は、ベンダの IHE 統合ステートメントの正確性や妥当性、または製品に関するベンダのその他の主張を、いかなる形でも立証するものではない。
重要 -- 注意: IHE 統合ステートメントの正確さおよび有効性に関しては、ベンダのみが責任を負う。ベ
ンダの統合ステートメントが IHE を通して入手できるようになっているのは、単に、特定の製品の統合機能に関する情報を探すためだけである。IHE およびそのスポンサー組織は、いかなる IHE 統合ステートメントまたは関連製品の評価または承認も行っていず、IHE 統合ステートメントの使用またはそれに対する信頼から発生する、ビジネスの妨害や収益の損失を含む直接的、間接的、偶発的、必然的ない
かなる主張または鈍害に対しても、責任を負わないものとする。

C.1 IHE 統合ステートメントの構造と内容製品に対する IHE 統合ステートメントには、以下の情報が含まれる。
1.

ベンダ名

2.

IHE 統合ステートメントが適用される製品名(販売において使用されるもの)

3.

IHE 統合ステートメントが適用される製品のバージョン

4.

発行日

5.

以下のステートメント:“This product is intended to implement all transactions required in the IHE Technical Framework to
support the IHE Integration Profiles, Actors and Options listed below:”(「この製品は、以下で示されている IHE 統合プロファイル、アクタ、オプションをサポートするために IHE テクニカルフレームワークにおいて必要なすべてのトランザクションを実装
することを意図している。」)

6.

製品がサポートする IHE 統合プロファイルのリスト、および各統合プロファイルについてサポートされている IHE アクタのリスト。各統合プロファイル/アクタの組み合わせに対し、IHE
テクニカルフレームワークで定義されている 1 つ以上のオプションについて記述してもかまわない。プロファイル、アクタ、およびオプションでは、IHE テクニカルフレームワークボ__________________________________________________________________________
55
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
リューム I で定義されている名前を使用する必要がある。(注: ベンダは、各統合プロファイ
ルに対して参照されているテクニカルフレームワークのバージョン番号を示すこともできる)
統合プロファイルの実装では、アクタに対するすべての必須トランザクションが実装されるものと想定される。オプションには、オプションのトランザクションまたは必須トランザクションに対するオプシ
ョンの機能が含まれる。
また、ステートメントは、次の情報に対する参照および/またはインターネットリンクを含まなければ
ならない。
1.

ベンダの統合ステートメントが公開されている特定のインターネットアドレス(つまり URL)

2.

製品が実装している IHE トランザクションに関連するベンダの標準準拠ステートメント(HL7、DICOM など)が公開されている特定の URL

3.

IHE に関する一般情報のための、IHE イニシアチブの Web ページの URL (www.rsna.org/IHE)

IHE 統合ステートメントは、IHE 機能の実装に直接的な関係のない製品の側面をプロモーションまたは
宣伝する意図はない。

C.2 IHE 統合ステートメントのフォーマット
各統合ステートメントは、次に示すフォーマットに従わなければならない。ベンダは、それぞれの製品
資料の方針に従って、表紙および必要なページを追加してもかまわない。

__________________________________________________________________________
56
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________IHE Integration Statement
VendorDate

Product Name

Any Medical Systems Co.

12 Oct 2002

VersionIntegrateRAD

V2.5

This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles,
Actors and Options listed below:

Integration
ProfilesImplemented
Scheduled Workflow

Simple Image andNumeric Report

Actors Implemented

OptionsImplemented

Image Manager/Image Archive

none

Image Display
Image Creator

none

Order Filler

PPS Exception
Management

Report Creator

none

Performed Procedure Step

Internet address for vendor’s IHE information:www.anymedicalsystemsco.com/ihe

Links to Standards Conformance Statements for the Implementation
HL7

www.ihe-j.jp

DICOM

www.anymedicalsystemsco.com/dicom/integrateRAD.pdf

MFER

ecg.heart.or.jp

Links to general information on IHE
In North America: www.rsna.org/IHE

In Europe: www.ihe-europe.org

In Japan: www.jira-net.or.jp/ihe-j__________________________________________________________________________
57
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix D: 用語集
この文書に固有の用語（訳注：本用語集は内視鏡のためではなくテクニカルフレームワークから直接コピーされていて、本文書に特化したものではないと考えられる）
アクタ(Actor): ユースケース図の中のエンティティであり、ユースケース図内のアクションを実行できる。可能性のある振る舞いはメッセージの作成あるいは破棄である。
エビデンス文書(Evidence Documents): 解釈されていない情報を表し、主として画像部門の内部で管理および使用される。ただし、画像部門外への配布は除外されない。非画像情報であり、測定値、CAD 結果、処置ログなどの情報を含み、DICOM SR 文書としてエンコードされる。
エビデンスオブジェクト(Evidence Objects): 画像部門のシステムにおいてプロセジャー・ステップを実施した結果として生成されるすべてのオブジェクト。これらのオブジェクトは、診断レポート
作成の過程で読影する医師によって使用され、画像部門内で管理される。エビデンスオブジェ
クトの例としては、画像、プレゼンテーション状態、重要画像ノート、エビデンス文書などがある。
予想されるアクション(Expected Actions): トリガーイベントの結果として発生するアクション。
相互作用図(Interaction Diagram): データフローとイベントのシーケンスを示す図。
プロセスフロー図(Process Flow Diagram): 特定の例に含まれるアクタ間のプロセスのフローと相互作
用を示す図。
役割(Role): ユースケース内でのアクタのアクション。
スコープ(Scope): トランザクションの概要記述。
トリガーイベント(Trigger Event): メッセージの受信またはプロセスの完了などのイベント。別のアクションが発生する原因となる。
ユースケース(Use Case): システムのアクタと操作を示す図。

DICOM の用語
基本テキスト SR 保存 SOP クラス(Basic Text SR Storage SOP Class): DICOM 補足 23 を参照
現実世界の DICOM モデル(DICOM Model of the Real World): DICOM PS 3.3 を参照
拡張 SR 保存 SOP クラス(Enhanced SR Storage SOP Class): DICOM 補足 23 を参照
グレースケールソフトコピープレゼンテーション状態保存 SOP クラス(Grayscale Softcopy
Presentation State Storage SOP Class): DICOM PS 3.4 を参照
グレースケール標準標示機能(Grayscale Standard Display Function): DICOM PS 3.14 を参照
画像サービス依頼(Imaging Service Request): DICOM PS 3.3 を参照
モダリティ(Modality): DICOM PS 3.3 を参照
モダリティワークリスト SOP クラス(Modality Worklist SOP Class): DICOM PS 3.4 を参照
モダリティ実施済処置ステップ(Modality Performed Procedure Step): DICOM PS 3.3 を参照
モダリティ実施済処置ステップ情報モジュール(Modality Performed Procedure Step Information
Module): DICOM PS 3.3 を参照__________________________________________________________________________
58
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
モダリティ実施済処置ステップ関係モジュール(Modality Performed Procedure Step Relationship
Module): DICOM PS 3.3 を参照
モダリティ実施済処置ステップ SOP クラス(Modality Performed Procedure Step SOP Class):
DICOM PS 3.4 を参照
N イベントレポート(N-Event Report): DICOM PS 3.7 を参照
患者(Patient): DICOM PS 3.3 を参照
患者識別モジュール(Patient Identification Module): DICOM PS 3.3 を参照
印刷プレゼンテーション LUT SOP クラス(Print Presentation LUT SOP Class): DICOM PS 3.4 を参照処置計画(Procedure Plan): DICOM PS 3.3 を参照
処置タイプ(Procedure Type): DICOM PS 3.3 を参照
プロトコルコード(Protocol Code): DICOM PS 3.3 を参照
依頼済処置(Requested Procedure): DICOM PS 3.3 を参照
依頼済処置モジュール(Requested Procedure Module): DICOM PS 3.3 を参照
依頼済処置 ID (Requested Procedure ID): DICOM PS 3.3 を参照
結果情報オブジェクト定義(Results Information Object Definition): DICOM PS 3.3 を参照
予約済処置ステップ(Scheduled Procedure Step): DICOM PS 3.3 を参照
予約済処置ステップモジュール(Scheduled Procedure Step Module): DICOM PS 3.3 を参照
保存委託 SOP クラス(Storage Commitment SOP Class): DICOM PS 3.4 を参照
構造化レポート情報オブジェクト定義(Structured Reporting Information Object Definitions):
DICOM PS 3.3 を参照
構造化レポート SOP クラス(Structured Reporting SOP Classes): DICOM PS 3.4 を参照
構造化レポートテンプレート(Structured Reporting Templates): DICOM PS 3.16 を参照
固有識別子(Unique Identifier : UID): DICOM PS 3.5 を参照

HL7 の用語
ADT: HL7 バージョン 2.5 を参照
受注側(Filler): HL7 バージョン 2.5 を参照
観察(Observation): HL7 バージョン 2.5 を参照
発注側(Placer): HL7 バージョン 2.5 を参照
ユニバーサルサービス ID (Universal Service ID): HL7 バージョン 2.3.1 を参照

頭字語と略語HIMSS: Healthcare Information and Management Systems Society
HIS: Hospital Information System (病院情報システム)
IHE: Integrating the Healthcare Enterprise (医療施設の統合)
IOD: Information Object Definitions (情報オブジェクト定義)
IT: Information Technology (情報技術)
IVUS: Intravascular Ultrasound (血管内超音波法)__________________________________________________________________________
59
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
MWL: Modality Worklist (モダリティワークリスト)
MPPS: Modality Performed Procedure Step (モダリティ実施済処置ステップ)
NEMA: National Electrical Manufacturers Association
OID: Object Identifier (オブジェクト識別子)
PACS: Picture Archive and Communication System (画像保管通信システム)
PPS: Performed Procedure Step (実施済処置ステップ)
RID: Retrieve Information for Display (表示用情報取得)
RIS: Radiology Information System (放射線部門情報システム)
RSNA: Radiological Society of North America
SCU: Service Class User (サービスクラスユーザ)
SCP: Service Class Provider (サービスクラスプロバイダ)
SPS: Scheduled Procedure Step (予約済処置ステップ)
SR: Structured Report (構造化レポート)
UID: Unique Identifier (固有識別子)
UUID: Universally Unique Identifier (ユニバーサル固有識別子)__________________________________________________________________________
60
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________

Appendix E: セキュリティ環境に関する考慮
IHE 準拠システムは、通常、プライベートな医療情報を処理する。これは、国のプライバシー規制およびおそらくは他の地域的および契約的な要件の対象となる。IHE プロファイルでは、このような情報を保護するために必要なセキュリティメカニズムは完全には定義されていない。基本セキュリティプロフ
ァイルでは、このソリューションの 1 つのコンポーネントが提供される。
IHE では、次のような特徴を持つノードにアクタがインストールされるものと想定される。
•

各ノードには、操作に適用されるセキュリティポリシーと手順がある。これは、医療施設セキュリ
ティポリシーの一部と考えられる。

•

ノード境界の外部のユーザ(人またはアプリケーションプロセス)は、アクセス制御手順に渡されて、ユーザ/アプリケーションプロセスは認証を受ける。

•

すべての必要な監査用ログイベントが収集されて記録される。

このフレームワークのプロファイルでは、以下の環境が想定される。
•

物理的セキュリティ環境•

装置は、物理的に保護され、積極的にモニターされている場所にある。これは、他の患者の安全、プライバシー、および操作に関する考慮のため、通常はモダリティ装置のケースである。同様に、HIS システムおよびさまざまなアーカイブも通常は保護される。PACS ワーク
ステーションのような装置は、保護されない場所に置かれる場合があるが、通常は、病院ス
タッフがモニタし、アクセスを制限する場所に置かれる。装置変更の脅威からは、物理的セキュリティメカニズムにより保護されるものと考えられる。

•

コンピュータに接続するネットワーク装置も、許可されない接続および変更に対して物理的に保護されるものと想定される。大部分の病院の治療場所では、ネットワーク装置は、天井
裏、索道内、ロックされたキャビネット、およびその他の保護された場所に置かれる。通常は、許可されない活動が行われないことを監視するスタッフが存在する。

•

物理的セキュリティの考慮が、リスクがさらに大きい管理オフィスなどの病院内の他の場所に対して有効であるよう、ローカルな手順と運用が設けられている。

•

遠隔場所(特に自宅オフィス)は、物理的に保護されていない。他の手段を使用して環境を保護する。これには、VPN 接続や HTTPS 暗号化などのテクノロジが含まれる。暗号化や VPN
は物理的セキュリティに完全に代わるものではなく、全体的な保護システムの一部である。

•

個人用と業務用の両方に使用する自宅コンピュータは、保護するのが困難である。有害なソフトウェアによる不注意の変更から保護するか、またはそのようなコンピュータの使用を禁止する。

ネットワークセキュリティ環境•

ネットワークの物理的セキュリティに加えて、管理されないシステムによるネットワークア
クセスから保護する。このような保護は、通常、ファイヤウォールや VPN などのメカニズムによって提供する。

脅威プロファイルは次のように想定される。
• 偶然で不注意による誤使用•

個人的な利益、悪意、報復、好奇心などによる個別の悪用。悪用者は、基になっているシス
テムおよびソフトウェアに対するアクセスのみを制限されるものと想定される。システムの内部構造についての専門的知識はない。

•

インターネットハッカーなどによる、特定施設を対象としない無作為の悪用。

__________________________________________________________________________
61
For Public Comment

Copyright © 2005: JAHISIHE Endoscopy Technical Framework, vol. I: Integration Profiles______________________________________________________________________________
また、脅威プロファイルでは、以下の脅威は存在しないか、または保護されているものと想定される。
•

システム管理者、システム開発者、または他の専門家による個別の悪用。

•

軍または敵対政府によるアクション。

•

組織的犯罪者による攻撃。

IHE は、IHE 医療アプリケーションのスコープ内にある IT システムに関係するセキュリティ要件のみを扱う。ネットワーク攻撃やウイルス感染などに対する防御に関するセキュリティ要件は扱わない。
現在の暗号アルゴリズムではパフォーマンスに対する影響が大きいため、IHE は暗号化の使用を要求しない。ほとんどの病院ネットワークは、物理的および手順的なメカニズムを通して、適切なセキュリテ
ィを提供する。このようなネットワークでは、暗号を使用することでさらにパフォーマンスが悪化する
ことは正当化されない。プロファイルでは、全体的なセキュリティ計画の一部として使用できるよう、暗号化の使用を許可している。

__________________________________________________________________________
62
For Public Comment

Copyright © 2005: JAHIS