1
2
3

Integrating the Healthcare Enterprise

4

5
6

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

7

解説文集

8

IHE-J Year 3: 2007-2008 用

910
11
本書は、IHE-J Cardiology Technical Framework 等の Year 3 に必要なオリジナル文書をパブリ
ックコメントの為 IHE-J 循環器技術検討委員会メンバー有志により作成されたものである。
作成に際しては、出来るだけ原文の読破の助けとなるよう心がけたが、オリジナル文書の翻訳でないことに留意願いたい。去年までの翻訳文、ITI の翻訳文もあるので、参考にされたい。疑問点については、英語版による十分な確認をお願いしたい。
12
13
14
15
16
17

Year 3 解説文集
第１．０版
公開日: 2007 年 7 月 31 日

18
19
20

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2

目次
まえがき ................................................................................................................................... 3

3

1

解説文の概要..................................................................................................................... 4

4

1.1

IHE-J 循環器の Year 3 対象ドキュメント ................................................................. 45

1.2

解説文のフォーマット ............................................................................................... 4

6

1.3

対象読者 ...................................................................................................................... 4

7

1.4

著作権 .......................................................................................................................... 482

IHE CARD Technical Framework version 2.1 Final Text .................................................... 5
統合プロファイル .................................................................................... 5

9

2.1

Volume I10

2.1.1 第１章

11

2.1.1.1

12

2.1.2 第２章

13

2.1.2.1

解説文.................................................................................................................... 6

14

2.1.2.2

変更点.................................................................................................................... 815

2.1.3 第３章

16

2.1.3.1

解説文.................................................................................................................... 8

17

2.1.3.2

心臓カテーテル検査ワークフローのユースケースの説明 ............................. 1018

2.1.4 第４章

19

2.1.4.1

20

2.1.5 第５章

21

2.1.5.1

22

2.1.6 第６章

23

2.1.6.1

24

2.1.7 Appendix .................................................................................................................... 16

25

2.2

26

2.2.1 解説文 ........................................................................................................................ 16

27

2.2.2 HL7 v.2.5 の扱いに関して ........................................................................................ 1828

2.2.2.1

序章 .............................................................................................................. 5

変更点.................................................................................................................... 5
統合プロファイル ....................................................................................... 6

心臓カテーテル検査ワークフロー（CATH） .......................................... 8

心エコーワークフロー（ECHO）............................................................ 12

解説文.................................................................................................................. 12
表示の為の心電図の呼び出し（ECG）................................................... 15

解説文.................................................................................................................. 15
エビデンスドキュメント（ED） ............................................................. 15

解説文.................................................................................................................. 15

Volume II

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

HL7 プロファイルに関する合意事項................................................................ 18__________________________________________________________________________
1（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1

2.2.2.2

HL7 実装注釈 ...................................................................................................... 192

2.2.2.2.1

ネットワークガイドライン ........................................................................... 193

2.2.2.2.2

メッセージコントロール ............................................................................... 194

2.2.2.2.3

アクノレッジモード....................................................................................... 21

52.2.2.3

HL7 と DICOM のマッピングする際の考慮 ..................................................... 24

6

2.2.2.4

コード化されたエンティティとコーディングの使用法 ................................. 24

7

3

IHE CARD Technical Framework Supplement Stress ....................................................... 25
3.1.1 解説文 ........................................................................................................................ 25

894

IHE CARD Technical Framework Supplement IDCO ....................................................... 32

105

IHE ITI Technical Framework version 2.0 Final Text........................................................ 33
解説文 ........................................................................................................................ 33

11

5.1

12

5.1.1 Patient Identifier Cross-referencing (PIX) ................................................................... 33

13

5.1.2 Consistent Time (CT).................................................................................................. 36

14

5.1.3 Patient Demographics Query (PDQ)............................................................................ 37

15

5.1.4 Audit Trail and Node Authentication (ATNA)............................................................. 3816__________________________________________________________________________
2（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________

1

まえがき

2
3
4
5
6
7
8
9

IHE (Integrating the Healthcare Enterprise : 医療施設の統合)は、現在の医療施設で使用されている情報シ
ステムの統合を促進するために企画された構想である。その基本的な目的は、患者を治療するために医療従事者が治療方針を決定するための必要なすべての情報を正しく利用できるようにすることである。IHE イニシアチブは統合作業を促進するための手段であり討議の場である。IHE では特定の臨床的目標をするメッセージ交換規約を実装するためのテクニカルフレームワークを定義している。また、IHE には、このフレームワークを実装した上での厳密なテストプロセスも含まれている。さらに、IHE
では、このフレームワークの利点を立証し、業界やユーザが、IHE を採用しやすくするために、医療関係者の会議で教育セッション、展示会を開催している。

10
11
12
13

IHE では、新しい標準を開発することではなく、HL7、DICOM、IETF、およびその他の既存の標準を、それぞれが適切な分野にで統合して使用し、必要に応じて構成の選択肢を定義することである。IHE
では、既存の標準で明確化しなければならないときや拡張が必要な場合には、該当する標準化団体に推奨事項を提示することにしている。

14
15
16
17
18
19
20
21
22
23
24
25

この構想のために、多くの医療分野や地域、スポンサーやサポート組織がある。北米での主なスポンサーは、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 Cardiology (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-J は、2007 年３月に設立された日本ＩＨＥ協会の活動として、経済産業省(METI)、厚生労働省、MEDIS-DC、および日本画像医療システム工業会(JIRA)、保健医療福祉情報システム工業会(JAHIS)、日本医学放射線学会(JRS)、日本放射線技術学会(JSRT)、日本医療情報学会(JAMI)などが協力し後援している。また、
IHE プロセスの学問分野および地理的な拡大に伴って他の医療専門家の参加が要請されている。

26
27
28
29
30
31

さまざなま分野(IT インフラストラクチャ、循環器科、検査室、放射線科など)における、IHE テクニ
カルフレームワークは、その統合目標を実現するために、既に確立されている標準を利用して定義する。このような統合により、患者の最前の治療を支援するために、適切な医療情報を共有できるようになる。これらは、公開レビューの期間の後、毎年拡張され、誤りを訂正し定期的に保守される。これらのテクニカルフレームワークの最新バージョンは、www.ihe.net、www.acc.org、www.rsna.org/IHE、または http://www.himss.org/IHE から入手できる。

32
33
34
35
36
37

IHE テクニカルフレームワークでは、IHE アクタと呼ばれる医療機関の機能コンポーネントのサブセ
ットを規定し、組み合わされた標準に沿ったトランザクションのセットに関する相互作用が規定されている。テクニカルフレームワークでは、このトランザクション本体を段階的に詳細化されて記述されている。このボリューム I では、IHE 機能の概要レベルのビューが提供され、特定の臨床ニーズの対応能力に焦点を当てた統合プロファイルと呼ばれる機能単位として編成されたトランザクションが示されている。以降のボリュームでは、各 IHE トランザクションの詳細な技術的説明が提供されている。

38
39
40
41

Year 3 のドキュメントは基本的に北米、欧州で 2006-2007 用として採用された文書を基に日本で、パブリックコメントを実施するものであり、本解説書はオリジナル文書（英語）を読破するのに少しでも助けになればと云う意図で作成されたもので、本文書はパブリックコメントの対象ではない事に留意されたい。

42__________________________________________________________________________
3（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________

1 1

解説文の概要

2 1.1 IHE-J 循環器の Year 3 対象ドキュメント
3
4
5
6
7
8

2007-2008 の IHE-J の循環器の Year 3 は以下のドキュメントを基に実施される。したがって、本解説書
は完全ではないが、以下のドキュメントの読解の助けになるように用意されている。

9
10
11
12
13
14

上記のドキュメントの中には同バージョンではないが、以前のバージョンのドキュメントに対しての日本語翻訳版が存在するものがある。同じドキュメントではないが、大部分で同等である場合が多い
ので、参考文献として活用してもらいたい。また、本解説書は日本語翻訳版がある場合はそこからの変更点等を記載してあるので参考にされたい。また、IHE-J では去年より、コネクタソン、実装は基本
的に HL7 v.2.5 でおこなう事になっているが、HL7 に関しては放射線部門のドキュメントを参考にされたい。循環器ではどの部分がそれに対応しているのか指摘している。

•

IHE CARD Technical Framework version 2.1 Final Text Volume I & II•

IHE CARD Technical Framework Supplement Stress Trial Implement version•

IHE CARD Technical Framework Supplement IDCO Trial Implement version•

IHE ITI Technical Framework version 2.0 Final Text Volume I & II

15 1.2 解説文のフォーマット
16
17
18
19
20

本解説文は、基本的に改編された物に関しては変更点と、初めて Techinical Framework に接する読者の為の簡単な解説とが併記されている。ただし、リソースと時間の制約の為に、文書のフォーマットや内容に関しては出来る限り、統一させたが完全ではなく、読者に混乱をもたらす事になる場合も想定される。実際の内容は必ずオリジナルの対象文書を読んで、理解、疑問、問題点に関してはパブリッ
クコメントとして提出願いたい。

21 1.3 対象読者
22
23
24
25
26

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

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

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

医療機関の IT 部門•

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

27 1.4 著作権28
29

本文書の著作権は中間責任法人日本ＩＨＥ協会に帰属する。また、それ以外のドキュメントに関してはそれぞれに記載されている組織、団体、個人に帰属する。

30__________________________________________________________________________
4（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________

1 2
2
3

IHE CARD Technical Framework version 2.1 Final Text

本ドキュメントは 2006 年 6 月 9 日に IHE CARD TC により発行された。解説文はこの文書に基づいて書かれている。

4
5
6 2.1 Volume I

統合プロファイル

7
8

この章ではVolume Iの解説文を掲載する。

92.1.1 第１章

序章

10 2.1.1.1 変更点
11

1.1 テクニカルフレームワークの概要

12
13
14
15
16
17
18

CARD-TFは、関連するIHEテクニカルフレームワークのセットの一部であり、次のような分野固有の文書で構成されている。
• IHE循環器テクニカルフレームワーク• IHE IT基盤テクニカルフレームワーク• IHE放射線テクニカルフレームワーク• IHE検査室テクニカルフレームワーク• IHE患者ケアテクニカルフレームワーク 追加

19
20
21
22

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

23
24

1.8 コメント

25
26
27

ACC は、この文書およびIHE イニシアチブに関するコメントを歓迎する。コメントは、
http://forums.rsna.org/のディスカッションサーバまたは次の住所までお送りいただきたい。

28

Rishi Adhikari （Katherine Doermann 変更になっているが更に変更）

29

American College of Cardiology

30

9111 Old Georgetown Rd

31

Bethesda, Md 20814-1699

32

Email: IHE@acc.org__________________________________________________________________________
5（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1

（変更前）

2

Jayne Jordan

3

Specialist, Division Information

4

Strategic & External Relations Division

5

American College of Cardiology

69111 Old Georgetown Rd

7

Bethesda, Md 20814-1699

8

Email: jjordan@acc.org

9
10
11

2.1.2 第２章

統合プロファイル

12 2.1.2.1 解説文
13

２

統合プロファイル

14
15
16
17

IHE 循環器統合プロファイルは、医療従事者とベンダが製品の開発において使用できる共通の言語を提供している。現場でのシナリオを用いて、システムの具体的な機能：アクタを抽出している。各
アクタに対し、これらの機能をサポートするために必要な通信方法：トランザクションを指定してい
る。

18
19

一般に、IHE 統合プロファイルは単独では機能せず、他分野などのあるプロファイルを実装した結果として生成される場合がある。

20
21
22

例えば、さまざまな循環器プロファイルのアクタは、ユーザ認証、監査のためのログ、患者ID相互参照、時間整合などのために、ITインフラストラクチャ分野のプロファイルを実装する場合などであ
る。

23
24
25

また1つの製品が、複数のアクタおよび複数の統合プロファイルを実装できる。さらにアクタは、目的のプロファイルのトランザクションに加えて、前提条件のプロファイルにおいて必要なすべてのト
ランザクションを実装する必要がある。

26
27
28
29

IHE 統合プロファイルは標準規格に対する準拠の表明ではなく、またIHE が認定団体ではないことに留意しなければならない。ユーザは、ベンダにDICOM やHL7 などの関連規約に対する準拠の表明をするように要求し続ける必要がある。各規約に準拠することは、IHE 統合プロファイルを採用する
ベンダの前提条件である。

30
31
32

また、IHE では扱えないが、うまく運用されているいかなる統合プロジェクトにも重要なニーズがあることにも留意すべきである。さらに、システムの統合を成功させるには、明確に識別されたシス
テムの境界、詳細化されたコスト目標、保守とサポートの計画などが必要である。

33
34

2.2.1 心臓カテーテル検査ワークフロー統合プロファイル(CATH)__________________________________________________________________________
6（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
12
3
4

心臓カテーテル検査は、ワークフローの観点から特に複雑である。実際に急患では心臓カテーテル検査処置のオーダが出される前に検査が始まることが多い。さらには関連する全ての処置や画像、検査、レポートに同一患者ＩＤで確実に行われなければな
らない。

5
6
7

心臓カテーテル検査ワークフロー統合プロファイルでは、心臓カテーテル検査処置の前後関係の基本的な患者データの継続性と完全性が確立される。このプロファイルでは、特に、患者ID と患者基本データの一貫した処理を取り扱っている。

8
92.2.2 超音波心臓検査ワークフロー統合プロファイル(ECHO)

10
11
12
13
14
15

超音波心臓検査ワークフロー統合プロファイルでは、デジタル超音波心臓検査、特に、経胸壁心エコー(TTE)、経食道心エコー(TEE)、ストレスエコーに関するワークフローが記述されている。心臓カテーテル検査ワークフロー統合プロファイルと同じように、このプロファイルでは、患者ID、オーダ、
予約、ステータス報告、複数ステージ検査(特にストレスエコー)、およびデータ保管が扱われている。
特に、携帯式超音波検査装置のように一時的にのみネットワークに接続される取り込み用モダリティ
装置の問題、およびエコー固有のデータ要件も扱われている。

16
17

しかしながら血管内超音波法(IVUS)および心臓内心エコー検査(ICE)は心臓カテーテル検査ワークフ
ロー統合プロファイルのモダリティとしてサポートされている。

18
19

2.2.3 表示用心電図参照統合プロファイル (ECG)

20
21
22
23
24

表示用心電図参照 (Retrieve ECG for Display)統合プロファイルでは、施設全体から参照するために心電図(ECG)データにアクセスする方法を規定している。心電図データには、"診断品質"の波形、計測値、および解析結果が含まれている。この統合プロファイルを使用すると、循環器分野専用のソフトウェ
アやワークステーションではなく、Web ブラウザのような汎用コンピュータアプリケーションを使用して、この種の情報を表示できる。

25
26
27
28

この統合プロファイルは、主に、安静時の１２誘導心電図を参照でき、ストレス、ホルター、および他の検査で収集された心電図波形も参照することができる。この統合プロファイルでは、情報シス
テムに既に保存されている心電図のみを取り扱うこととし、心電図検査のオーダ、収集、保存や診断のプロセスは扱わない。

29
30
31

2.2.5 エビデンスドキュメント統合プロファイル (ED)32
33

エビデンスドキュメントプロファイル(Evidence Documents Profile)は、検査・治療を行う過程で記録された観察、計測および結果などのデータの利用方法を定義する。

3435

このようなデータは収集システムや他のワークステーションのような装置から出力され、保存シス
テムに保存・管理される。

3637

そして、表示やレポートシステムによって検索され、臨床報告書を作成する途中で使用されたり、判読医のための付加的な情報で使用されたりする。

38__________________________________________________________________________
7（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1 2.1.2.2
2

変更点

Displayable Reports (DRPT)に関する部分が削除された

3
4

2.2.4 Displayable Reports (DRPT)：レポート表示統合プロファイル

5

全文削除

6
7
8
9
10
11
12

2.3 Actor Descriptions：アクタ説明• Report Manager• Report Reader• Report Repository• Enterprise Report Repository
上記削除

13
14
15
16
17
18
19
20

2.4 Transaction Descriptions：トランザクション説明• Encapsulated Report Submission• Encapsulated Report Storage• Encapsulated Report Query• Encapsulated Report Retrieve• Report Reference Submission
上記削除

21
22
23
24
25
26
27
28
29
30

2.5 Product Implementations：製品の実装について• The Report Repository Actor participating in Displayable Reports Integration Profile shall begrouped with the Information Source Actor of the Retrieve Information for Display Profile.
• The Report Manager Actor participating in Displayable Reports Integration Profile shall begrouped with the Report Repository Actor of that Profile, unless it supports the DICOM
Storage Option.
•
The Report Repository Actor participating in Displayable Reports Integration Profile shall begrouped with the Report Manager Actor of that Profile, unless it supports the DICOM Storage
Option.

31
32

上記削除

33

2.1.3 第３章

心臓カテーテル検査ワークフロー（CATH）

34 2.1.3.1 解説文
35

3 心臓カテーテル検査ワークフロー (CATH)__________________________________________________________________________
8（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2
3
4
5
6
7
8

心臓カテーテル検査ワークフロー統合プロファイルでは、心臓カテーテル検査手技での患者データの連続性と整合性が確立する。このプロファイルは、患者 ID と患者基本データの一貫した処理を取り扱う。長い時間が検査開始から経過しても、整合性が確立されないものも含まれる。また、さまざまな
画像、測定、解析システム間における検査手技データのスケジューリングと調整、および以降のワー
クフローをサポートするためのデータのアーカイブへの確実な保管も指定されている。

9

3.1

10
11

本文中の図には、このプロファイルに関係するアクタと、アクタ間のトランザクションが示されているので参照されたい。

1213

表 3.1-1 は、心カテワークフロー統合プロファイルに直接含まれる各アクタに対するトランザクションのリストである。完全なリストについては、本文の 3.2 節を参照すること。

1415

表 3.1-1. 心カテワークフロー - アクタとトランザクション•

このプロファイルは、IHE 放射線予約済ワークフロー、患者情報の整合性確保、およびエ
ビデンス文書の各統合プロファイルとよく似ているが、複数モダリティの調整および循環器分野に固有のデータ要件が扱われている。

アクタ/トランザクション

ActorsTransactions

Optionality

Section

ADT Patient
Registration

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Order Placer

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Placer Order Management [RAD-2]

R

RAD-TF 2: 4.2

Filler Order Management [RAD-3]

R

RAD-TF 2: 4.3

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

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 [CARD1]
Modality Procedure Step Completed [RAD-7]

R

CARD-TF 2: 4.1

R

RAD-TF 2: 4.7

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Query Modality Worklist [RAD-5]

R

RAD-TF 2: 4.5

Modality Procedure Step In Progress [CARD1]
Modality Procedure Step Completed [RAD-7]

R

CARD-TF 2: 4.1

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Procedure Scheduled [RAD-4]

R

RAD-TF 2: 4.4

Modality Procedure Step In Progress [CARD1]
Modality Procedure Step Completed [RAD-7]

R

CARD-TF 2: 4.1

R

RAD-TF 2: 4.7

Department System
Scheduler/
Order Filler

Acquisition
Modality
Acquisition
Modality

Image Manager/
Image Archive
Image Manager/
Image Archive__________________________________________________________________________
9（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________

Performed
Procedure Step
Manager
Image Display
Performed
Procedure Step
Manager

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Modality Procedure Step In Progress [CARD1]R

CARD-TF 2: 4.1

1

心臓カテーテル検査ワークフロー統合プロファイルのオプション

2

3.2

3
4
5

多くのアクタは幅広い実装のバリエーションに適応する為、オプションが定義されている。本文中の表３．２－１に、この統合プロファイルに対して選択できるオプションを、それを適用できるアクタ
毎に示しているので参照されたい。

6

予約済プロセスフロー

7

3.3

8
9

各プロセスフローはエンドユーザの問題（”臨床的背景”）と本テクニカルフレームワークで採られているアプローチ（”IHE 背景”）とともに紹介されている。

10
11
12
13
14
15
16
17

臨床的背景: このプロセスフローは、放射線部門の検査と同様に、患者が施設に受付され、カテーテル検査処置がオーダおよび予約されている状況を反映している。主な相違点は、カテーテル検査はその性質上マルチモダリティであり、関係するすべてのモダリティが連携して患者、手技情報等を共有するための手段が必要である。放射線部門ではスケジュールド（予約済み）ワークフローは正常な、または予想される状況であるが、現状では心臓カテーテル検査においては例外的であることに注意すること。この処置は、通常は先行する Cardiology Consultation (循環器医によるコンサルテーション)が処置を実行するように調整するだけなので、従来はあまりオーダされていない。カテーテル検査処置および全体的な治療状況に対するその関係については、本文付録 A も参照すること。

18
19
20
21
22
23

IHE 背 景 : こ の 節 で は 、 IHE デ ー タ モ デ ル の 3 レ ベ ル の 制 御 (order, requested procedure, andscheduled/performed procedure steps)をすべて完全に利用して既知の患者に対する処置を要求する場合の、"通常の"予約済ワークフローについて説明する。実際には、急患が多いという性質のため、心臓カテーテル検査処置に対してはオーダが作成されないことが多いが、このプロセスフローは、本文中 3.4
節で説明されている特定のユースケースを理解するための基本を示している。実際、このワークローと患者情報修正（PIR）ステップが本文 3.4 節のケース C1 となっている。

24
25 2.1.3.2 心臓カテーテル検査ワークフローのユースケースの説明
2627

ここでは、心臓カテーテル検査ワークフロープロファイルに対して定義されている具体的なユースケースとプロセスフローについて説明する。

28
29
30

心臓カテーテル検査ワークフローに対しては、C1 から C10 の具体的なユースケースが定義されている。患者が登録されているかどうか、またその場所、およびオーダが出され__________________________________________________________________________
10（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2
3ているかどうか、またその場所に基づいて、バリエーションが発生する。C10 は今回新しく追加された電気生理学による心臓アブレーション術や埋め込み型装置のユースケース
である．

4
5

ケース C1: ADT で患者登録が行われ Order Placer で処置オーダが出される

6
7

心臓カテーテル検査のオーダが病院のオーダリングシステムにおいて出される。また、患者に対して急患 ID が作成される特殊な状況も考慮されている。

8
9

ケース C2: ADT で患者登録されて DSS/OF で処置オーダされる

10
11

ケース C1 と似ているが、オーダは部門システムが処置情報の入力後、情報を病院オーダシステムに送信する。通常、このワークフローは多数の施設で典型的なものである。

12
13

ケース C3: ADT で登録され処置がオーダされていない患者

14
15
16

ケース C2 と似ているが、時間的な制約などにより部門システムでは入力されない。したがって、関係するモダリティの 1 つが、共通の処置 ID を作成するプロセスを開始する必
要がある。

17
18

ケース C4: DSS/OF で登録されて処置がオーダされた患者

19
20
21

部門でオーダが出されるケース C2 のバリエーションである。これには、病院システムに患者を登録するのに十分な時間がない場合、または ADT システムが利用できない場合(時間外など)の緊急ケースが含まれる。

22
23

ケース C5: 未登録の患者

24
25
26
27

ケース C3 と C4 (前記)を組み合わせたものである。このケースでは、患者は ADT システ
ムにおいて登録されておらず、かつそれより前にオーダエントリーまたは部門システム
においてオーダは出されていない。このようなケースは、救急状況において発生する場
合がある。

28
29

ケース C6: 処置中に更新された患者

30
31
32
33

身元不明の患者は、患者の一時的な患者基本情報と共にカテーテル検査室に送られる場合がある。検査手技の処理中に、患者の正しい患者基本情報に更新できる。この時、情報の一部を元の患者基本情報から取得し、一部を変更された基本情報から取得することができる。このケースでは整合を行う方法を示す。

34
35

ケース C7: 処置中の部屋の変更__________________________________________________________________________
11（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2
3

検査手技が行われている間に部屋の変更が必要になることは、カテーテル検査環境においてはめずらしくない。これは、診断ケースが治療ケースになり、治療の実行にさらに適した部屋に患者が移動する場合に、発生する可能性がある。

4
5

ケース C8: 処置の中止

6
7
8

心臓カテーテル検査が中止された場合、情報システムは中止の状況を把握して、カテーテル検査室スタッフが患者に関する問い合わせに対応できるようにしておくことが重要
である。

9
10

ケース C9: 処置後のエビデンスの作成

11
12
13
14

心臓カテーテル検査処置後に画像やその他の検査処置データは専門的なソフトウエアを使用して解析される事が多い。この解析は冠動脈や左心室の定量的な計測値、冠動脈ツ
リー図とインターベンション記録文章、再構築された画像のような派生データ等を提供
する。

15
16

ケース C10: 電気生理学による心臓アブレーション術や埋め込み型装置

17
18
19
20

電気生理学検査室では，埋め込み型装置を始め，ペースメーカ，除細動器，心臓再同期
治療器が使われ，マルチモダリティ環境で運用されているが，個々のベンダ装置が単独に動作している．これらを統合することにより、効率アップと医療エラーの低減が見込
める．

21
22

2.1.4 第４章

心エコーワークフロー（ECHO）

23 2.1.4.1 解説文
24
25
26
27
28
29
30
31

超音波心臓検査ワークフロー統合プロファイルでは、デジタル超音波心臓検査、特に、
経胸壁心エコー(TTE)、経食道心エコー(TEE)、ストレスエコーに関するワークフローが記述されている。心カテワークフロー 統合プロファイルと同じように、このプロファイ
ルでは、患者ID、オーダー、予約、ステータス報告、複数ステージ検査(特にストレスエコー)、およびデータ保管が扱われている．特に、携帯式超音波検査装置のように一時的にのみネットワークに接続される取り込み用モダリティ装置の問題、およびエコー固有のデータ要件も扱われている。また、超音波心臓検査で行われる計測値情報等を構造化
レポートとしてシステムに取込み表示するエビデンス文書のワークフローも含まれる。

32
33
34

血管内超音波法(IVUS)および心臓内心エコー検査(ICE)は心臓カテーテル検査処置で使用され、エコー検査ワークフローではなくカテーテル検査ワークフローのモダリティとしてサポートされている。

35__________________________________________________________________________
12（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1

Table 4.1-1. Echocardiography Workflow - Actors and Transactions
ActorsTransactions

Optionality

Section

ADT Patient
Registration

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Order Placer

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Placer Order Management [RAD-2]

R

RAD-TF 2: 4.2

Filler Order Management [RAD-3]

R

RAD-TF 2: 4.3

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

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 [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Query Modality Worklist [RAD-5]

R

RAD-TF 2: 4.5

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Department System
Scheduler/
Order Filler

Acquisition
Modality

Image Manager/
Image Archive

Performed
Procedure Step
Manager
Image Display
Evidence Creator

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Procedure Scheduled [RAD-4]

R

RAD-TF 2: 4.4

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

2
3

Case E1 から E7 まであるが、誤字の訂正以外の変更点は無い。
__________________________________________________________________________
13（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1【CaseE1：患者登録済みでオーダーが発行されている予約済み検査】234

この検査は最も標準的な検査のワークフローであり、モダリティもネットワークに接続された検査室の装置で行われる場合ある。なお、ここでは救急の場合の特殊な急患 ID を発行して検査を行う場合も考慮している。

5【CaseE2：断続的に接続されるモダリティ】

6
7
8
9

このケースは、移動式の検査装置等でよく使用される。検査のワークリスト等を最初にモダリティに取り込んでおき、一旦、ネットワークから切り離されて（例えば病棟等へ移動し）検査を実施する。その後、ネットワークに再接続され検査結果を取り込む状況が想定される。この場合、移動中は電源断ということも想定する。

10
11【CaseE3：臨時処理、登録済患者、予約済処理に関する断続的に接続されるモダリテ
ィ】

12
13
14

このケースは、病棟等の移動検査を想定する。検査オーダーはあらかじめ発行されているが、検査開始時にはネットワークに接続できないためそのワークリストを取得できな
い。検査終了後に依頼済み処理とのマッチングを取る状況を想定する。

15
16【CaseE4：臨時処理、登録済患者、未予約処理に関する断続的に接続されるモダリテ
ィ】

17
18
19
20

このケースは、緊急に検査を実施しなければいけないような状況が想定される。入院患者等で状況が急変し緊急に検査を実施しなければいけない状況になった場合、検査オーダーが発行されていない状況で検査が実施され、あとで実施済み検査に関するオーダー
を発行して結果を登録するような状況を想定する。

21
22【CaseE5：臨時処理、未登録患者、未予約処理に関する断続的に接続されるモダリテ
ィ】

23
24
25

このケースはケース E4 に似ているが、救急外来等で患者情報等が登録されていない状況を想定する。オーダーが発行されていない状況で未登録患者への緊急検査を実施し、後から患者登録と検査の結果を登録することになる。

26【CaseE6：ストレスエコーステージプロトコル】

27
28
29
30
31
32
33

このユースケースは、一般的な超音波ステージプロトコル検査である心臓ストレス検査を行う場合を想定している。ワークフローはケース E1 又はケース E2 と同じである。データ収集の実施には複数のステージ（ベースライン、中間負荷、ピーク負荷、及び回復）があるが、一般的にこれらは同じ処理ステップの一部として考えることができる。
段階的なステージを経て、臨床的な終了ポイントに達すると終了する。終了ポイントとして、予め定義した心拍数に達した場合や患者が検査を続けられないような症状（不整脈、血圧降下、狭心症、疲労など）が現れた場合がある。

34【CaseE7：心エコーの計測エビデンスの作成】

35
36
37

このユースケースは、超音波心エコー計測のプロセス・フローについて説明している。
このプロセス・フローは、CATH プロファイル・ケース C9 と同様である。検査中において超音波検査診断装置上で画像収集及び予備計測から始まり、収集した画像と計測結果__________________________________________________________________________
14（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2
3

を保存する。計測結果は DICOM の構造化レポート(SR)オブジェクトとして保存される。
検査終了後に検査報告書作成ワークステーション上で画像及び計測結果を検索して参照することが可能になる。

45

2.1.5 第５章

表示の為の心電図の呼び出し（ECG）

6 2.1.5.1 解説文
7
8
9

Retrieve ECG for display統合プロファイルは心電図データマネージメントシステム上で保存、管理されている心電図波形、計測値、解析結果などの心電図記録を、循環器専用のソフトウェアあるいはワークステーションを使用しないで、一般的なコンピュータのアプリケーションソフトにより表示するためのプロファイルである。

10
11

アクタ・トランザクション

12

図5.1-1は心電図統合プロファイルに直接関連するアクタと、アクタ間で関連するトランザクションを示している。

13
Retrieve Specific Info for Display [ITI-11]
Retrieve ECG List [Card-5]

Information
SourceDisplay
Retrieve ECG Document for Display [Card-6]

1415
図 5.1-1: Retrieve ECG for display プロファイルアクタ図表

16
17
18

2.1.6 第６章

エビデンスドキュメント（ED）

19 2.1.6.1 解説文
20

7． エビデンスドキュメント （ＥＤ）

21
22
23
24
25
26
27

エビデンスドキュメントプロファイル(Evidence Documents Profile)は、観察、計測および結果のような、処理を行う過程で記録されたデータの利用方法を定義する。それらのデータは、モダリティや他のワークステーション等の装置から出力され、保存システムに保存・管理される。レポートを作成する途中で利用されたり、読影医のための付加的な情報であったりする。エビデンスドキュメントプロファイルの完全な仕様は放射線プロ
ファイルにある。このセクションではそれらの定義において循環器特有のオプションを
説明する。

28

__________________________________________________________________________
15（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1

2.1.7 Appendix

2

解説文はありません。

3
4 2.2 Volume II

トランザクション

5

2.2.1 解説文

6

４．

7

本章では IHE-J card で使用するトランザクションについて説明したものである。

IHE Transactions

8
9
10
11
12

４．１

IHE 循環器で使用しているトランザクション

IHE 循環器で使用されるトランザクションは、IHE 放射線トランザクションと、それを循環器用に修正されたもの、IHE インフラストラクチュア トランザクションが使用される。

13
Integration Profile

CATH ECHO ECG

DRPT

ED

X

X
X

Transaction
Patient Registration
Placer Order Management
Filler Order Management
Procedure Scheduled
Query Modality Worklist
Modality Procedure Step In Progress
Modality Procedure Step Completed
Modality Images/Evidence Stored
Storage Commitment
Patient Update
Procedure Update
Query Images
Query Evidence Documents
Retrieve Images/Evidence
Instance Availability Notification
Maintain Time
Retrieve Specific Info for Display
Retrieve ECG List
Retrieve ECG Document for Display
Encapsulated Report Submission
Report Reference Submission
Encapsulated Report Storage
Encapsulated Report Query
Encapsulated Report Retrieve
Retrieve Document for Display[RAD-1][RAD-2][RAD-3][RAD-4][RAD-5][CARD-1][RAD-7][CARD-2][CARD-3][RAD-12][RAD-13][RAD-14][RAD-44][CARD-4][RAD-49][ITI-1][ITI-11][CARD-5][CARD-6][CARD-7][CARD-8][CARD-9][CARD-10][CARD-11][ITI-12]

X
X
X
X
X
X
X
X
X
X
X
X

X
X
X
X
X
X
X
X
X
X
X
X

X
X
(X)

X
X

X

X
X
X

(X)

X
X
X
X
X
(X)

14
15

以下のトランザクションは HL7 V2.5 メッセージにより処理される__________________________________________________________________________
16（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2

RAD-1：患者登録(Patient Registration) 注：IHE-J では本メッセージは ADT_A08 が使用され RAD-12 と同じ A08 イベントが使用される

3

RAD-2：オーダ発行管理(Placer Order Management)

4RAD-3：オーダ実施管理(Filer order Management)

5RAD-4：予定検査(Procedure Scheduled)

6

RAD-12：患者情報更新(Patient Update)

7RAD-13：施行情報更新(Procedure Update)89

以下のトランザクションは HTTP プロトコルにより処理される

10

CARD-5：心電図リスト参照(Retrieve ECG List)

11

CARD-6：心電図表示(Retrieve ECG Document for Display)12

ITI-11：表示用特殊情報参照(Retrieve Specific Info for Display)

13

ITI-12：表示文書参照(Retrieve Document for Display)14
15

以下のトランザクションは DICOM により処理される

16

RAD-5：モダリティワークリスト問い合わせ(Query Modality Worklist)

17RAD-7：検査完了(Modality Procedure Step Completed)18RAD-10：保存指示(Storage Commitment)

19RAD-14：画像問い合わせ(Query Image)20

RAD-43：エビデンスドキュメント保存済み(Evidence Documents Stored)

21

RAD-45：エビデンスドキュメント参照(Retrieve Evidence Documents)

22

RAD-49：インスタンス有効性通知(Instance Availability Notification)

23
24
25

４．２

IHE 循環器用トランザクション

26
27
28

放射線トランザクション Modality Procedure Step In Progress ［RAD-6］にマルチモダリ
ティに対するオーダのために追加したものである。
（２）CARD-2：Modality Image/Evidence Stored

29
30
31
32

放射線トランザクション Modality Images Stored［RAD-８］および Evidence Documents
Stored［RAD-43］にカテーテル、心臓超音波、ストレスエコー、カテ・エビデンスおよびエコー・エビデンスに関する SOP に対応したものである。
（３）CARD-3：Storage Commitment（１）CARD-1：Modality Procedure Step In Progress__________________________________________________________________________
17（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2
3

放射線トランザクション Storage Commitment［RAD-10］にポータブル機器特有のネットワークの接続が断続的であるオプションに対応したものである（４）CARD-4：Retrieve Images/Evidence

4
5
6
7

放射線トランザクション Retrieve Images［RAD-16］および Retrieve Evidence
Documents［RAD-45］にストレスエコー、カテ・エビデンス、エコー・エビデンスのためのトランザクションを追加したものである（５）CARD-5：Retrieve ECG List

8
9
10

Retrieve Specific Information for Display［ITI-11］を心電図に関する一覧表を表示するよう修正したものである（６）CARD-6：Retrieve ECG Document for Display

11

Retrieve Document for Display［ITI-12］を心電図表示のために修正したものである

12
13

その他、今後の循環器 IHE 用に予約されたトランザクションがある

14
15

2.2.2 HL7 v.2.5 の扱いに関して

16 2.2.2.1 HL7 プロファイルに関する合意事項
17
18
19

本書で使用している HL7 テーブルは HL7 バージョン 2.5 から引用されたものである。このような変更はプロファイルといわれる。テーブルの各行の意味については HL7 V2.5 を参照すること。

20
21
22

本書のプロファイルテーブルは常にバージョンアップされる HL7 プロファイルの定義をささえるものである。汎用的な基準で本規定を保守するために次のような差異を紹介し
ている

23

•

メッセージ仕様ではメッセージ内のセグメントの多重度は規定していない

24
25

•

多重のコンポーネントで構成されるフィールドについて、それぞれのコンポーネ
ントのサイズの指定はしていない

26
27

•

列挙値を含んでいるテーブルをセグメントプロファイルテーブルから参照する場
合、列挙値テーブルは常には表してはいない

28
29

•

繰り返しフィールドで繰り返すことができる“時間”の繰り返しの数は示してい
ない

30
31
32

•

条件フィールドに必要な包含するだろう条件は、そのトランザクションを実装しているシステムの機能的な特性に依存しデータの統一性に影響しないときには定義されていない3334

次の記号はプロファイルとして示している OPT（オプション）行を参照しているR

必須__________________________________________________________________________
18（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2
3

R2

IHE の拡張。もし送信アプリケーションがそのフィールドのデータを使用しているときは、そのフィールドは必須である。もしその値が不明な場合は、そのフィールドは送信されない

4

O

オプション

5

C

条件による

6
7

IHE は Z セグメントに関して該当する IHE テクニカルフレームワークによって定義されているときのみ HL7 トランザクションで表されることが必要である。

8
9
10
11

HL7 規約では、もしフィールドの値が記述されていないときは受信側ではそのデータベースの値を変更してはならない。しかし、もし送信側が明確に NULL データ（２つの連続した“”）で記述している場合は受信側のデータベースのフィールドに相当する値を消さなければならない。

12
13
14
15

[注：以下の原文はあまり意味がないので取り去っている。Table 2.3-1 provides a sample
profile for an imaginary HL7 segment. Tables for real segments are copied from the HL7 2.3.1
standard with modifications made only to the OPT column.]

16 2.2.2.2 HL7 実装注釈
17 2.2.2.2.1 ネットワークガイドライン
18
19[IHE NA では HL7 V2.3.1 を使用しているが IHE-J では V2.5 を使用することにしているために本章を含め V2.5 に基づいて説明するように変更している]

20
21
22
23
24

HL7 V2.5 規約ではネットワーク通信のプロトコールは規定していない。V2.1 規約および
V3 を含めたガイドでは下位層プロトコールを定義しているが、これらは実装ガイドに示されるようになっている。IHE-J では、通信手順に関して TCP/IP などの技術に依存することにし、不要にアプリケーションや通信の混乱させることを避けるために、下位層のプロトコール（MLLP：Minimum Low Layer Protocol）の使用を禁止している。

25 2.2.2.2.2 メッセージコントロール
26
27
28

HL7 規約では、全てのメッセージは MSH(メッセージヘッダ)ではじめなければならないと規定している。Table 2.4-1 はメッセージヘッダのフィールドを規定している。本テーブ
ルは V2.5 規約書 第 3.15 章等に示されている。

29
30

Table 2.4-1. IHE Profile - MSH segment
SEQ

LEN

DT

OPT

ITEM #ELEMENT NAME

1

1

ST

R

RP/#

TBL#

00001

フィールド分離子 IHE-J では”|”としている

2

4

ST

R

00002

エンコード IHE-J ^&~\とする

3

227

HD

O

0361

00003

送信アプリケーションコード IHE-J では HL7 に準拠してオプションとする ＊IHE では R

4

227

HD

O

0362

00004

送信部門・機関 IHE-J では HL7 に準拠してオプションとする ＊IHE では R__________________________________________________________________________
19（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
SEQ

LEN

DT

OPT

TBL#

ITEM #ELEMENT NAME

5

227

HD

O

RP/#

0361

00005

受信アプリケーション IHE-J では HL7 に準拠してオプ

6

227

HD

O

0362

00006

受信部門・機関 IHE-J では HL7 に準拠してオプション

7

26

TS

R

00007

メッセージ発生時刻

8

40

ST

O

00008

セキュリティ IHE-J では使用しない

9

15

MSG

R

00009

メッセージタイプ V2.5 から CM から変更されているた

10

20

ST

R

00010

メッセージコントロール ID

ションとする ＊IHE では Rとする ＊IHE では R

め注意すること Message Type 参照
11

3

PT

R

00011

プロセス ID

12

60

VID

R

00012

バージョン ID IHE-J では 2.5 を使用する

13

15

NM

O

00013

シーケンス版合意

14

180

ST

O

00014

連続ポインタ

15

2

ID

O

0155

00015

受信アクノレッジタイプ

16

2

ID

O

0155

00016

アプリケーションアクノレッジタイプ

17

3

ID

O

0399

00017

国コード ”JPN”を使用する

18

16

ID

O

0211

00692

文字コードセット ＊IHE では C

19

250

CE

O

00693

メッセージの主言語

20

20

ID

O

01317

代替文字コードセット処理方法

21

427

EI

O

01598

メッセージプロファイル識別

Y

0356
Y

1
2

1) メッセージタイプ(MSG)は旧 CM から変更され Message Structure が必須となっている

3

HL7 Component Table - MSG – Message Type
SEQ

LEN

DT

OPT

TBL#

COMPONENT NAME

1
2
3

3
3
7

ID
ID
ID

R
R
R

0076
0003
0354

Message Code
Trigger Event
Message Structure

COMMENTS

SEC.REF.
2.A.352.A.352.A.35452) IHE-J ではバージョン ID は 2.5 を使用する

6

HL7 Table 0104 - Version ID
Value
2.5

Description
Release 2.5

Comment (Date)
May 2003

783) 受信アクノレッジテーブル

9

HL7 Table 0155 - Accept/application acknowledgment conditions
Value
AL
NE
ER
SU

Description
AlwaysNever
Error/reject conditions only
Successful completion only

Comment

10114) 文字コード__________________________________________________________________________
20（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________1

HL7 Table 0211 - Alternate character sets
Value
ASCII

Description
印刷可能な 7 ビットの文字セット

ISO IR87

UNICODE UTF-8

日本のグラフィック文字集合用の情報交換コード(JIS X 0208-1990)

UCS 変換フォーマット,8-bit 形式

Comment（このフィールドを省略する場合、これがデフォルトである）
コードはスペースを含んでいることに注意。すなわち"ISO IR87"
日本では JIS X 0208 はエスケープシークエンスを必要としており、エスケープ技術は ISO2022 である。標準
ASCII では、エスケープシークエンス”escape”$B(16 進数、1B 24 42)は以下のバイトは 2 バイトの幅であることを自身に知らせる。ASCII へのもどるには 1B 28 42 である。
UTF-8 は可変長符号であり、それぞれのコードは 1,2 もしくは 3 バイトで表され、コード値に依存する。7 ビット
ASCII は UTF-8 の下位集合である。このコードは UTFの前にスペースを含んでも良いが、ハイフンの前後にスペースを含んではならないことに注意

235) 文字コード変換法

4

HL7 Table 0356 - Alternate character set handling schemeValue
ISO 20221994

Description
この規格は、"情報技術 – 文字コード構造と拡張技術"と名付けられている。

Comment
この規格は、基本的な 1 バイト文字セットから指定された異なる文字セットとの間の、遷移する手順を指定する。その遷移手順
は、明示的に起動される交代文字セットを指定する。このモードでは、実際の ASCII エスケープ文字が、参照される ISO 文書中で定義され使用される。1.7.1 節で注意したように、代替文字セットへ（から）の遷移手順は、HL7 区切り文字間内で起きるべきである。
言い換えれば、HL7 区切り文字は基本の 1 バイト文字だけであり、区切り文字の直前と直後の文字は、状態を符号化している基本的な 1 バイトセットであるべきである。

56
7IHE テクニカルフレームワークでは MSH-1 Field Separator と MSH-2 Encoding Characters
フィールドについては HL7 推奨値(“|”および“^&~\”)を使用する。

89

日本語環境を使用する場合、IHE-J では MSH-18 Character Set フィールドは“~IR87”を使用
する。

10
11

[Field MSH-18 Character Set shall only be valued if the message utilizes character sets other thanISO IR-6, also known as ASCII.]

12
13
14

シーケンス番号プロトコール（および MSH-13 Sequence Number フィールド）を使用する
場合は、シーケンス番号を使用していないトランザクションのために設定可能にしなければならない。

15 2.2.2.2.3 アクノレッジモード
16
ACK^varies^ACKGeneral Acknowledgment

MSH

Message Header

Status

Chapter2[{ SFT }]Software segment

2

MSA

Message Acknowledgment2__________________________________________________________________________
21（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________

1
2

ACK^varies^ACKGeneral Acknowledgment[{ ERR }]Error

Status

Chapter2

IHE-J ではソフトウェアセグメント(SFT)は使用しない
Table 2.4-2. IHE Profile - MSA segment
SEQ

LEN

DT

OPT

1

2

ID

R

2

20

ST

3

80

4

15

TBL#

ITEM #ELEMENT NAME

0008

00018

アクノレッジコード

R

00010

メッセージ制御 ID

ST

B

00020

テキストメッセージ

NM

O

00021

期待されるシーケンス番号

W

00022

遅延アクノレッジタイプ

00023

エラー状態

5
6

250

CE

RP/#

B

0357

3
4
5

HL7 メッセージを受信したアプリケーションは HL7 オリジナルモードによるアクノレッジ(別に拡張アクノレッジモードがある)を送信しなければならない。

6
7
8
9
10
11

IHE テクニカルフレームワークではそれぞれの HL7 メッセージに対してそのメッセージを受信したことを送信者に HL7 ACK メッセージにより知らせることを規定している。下
記一覧に示した ACK メッセージセグメントは必須であり、その詳細はテーブル 2.4-1、
2.4-2 およびそれらの注釈に規定している。ERR セグメントはオプションで MSA-1
Acknowledgement Code フィールドエラーの状態を示しているかどうかを含まれているかも
しれない。

12

HL7 Table 0008 - Acknowledgment code
Value
AA
AE
AR
CA
CE
CR

Description
基本モード:アプリケーション受諾 - 拡張モード:アプリケーション肯定応答:受諾
基本モード:アプリケーションエラー - 拡張モード:アプリケーション肯定応答:エラー
基本モード:アプリケーション拒否 - 拡張モード:アプリケーション肯定応答:拒否
拡張モード:受諾肯定応答:コミット受諾
拡張モード:受諾肯定応答:コミットエラー
拡張モード:受諾肯定応答:コミット拒否

Comment

13
14

HL7 Table 0357 - Message error condition codes
Value
0

Description
メッセージ受諾

100

セグメントシーケンスエラー

101
102

要求されたフィールドの消失
データ型エラー103

表の値が見つからない

200
201

提供されていないメッセージ型
提供されていないイベントコー
ド提供されていない処理 ID
提供されていないバージョン
ID
不明なキー識別子

202
203
204

Comment
成功。オプションでは、AA が成功を伝えるだけ。常時状態コードを返す必要があるシステムのために利用される
エラー:メッセージセグメントが適当な順番でないか、要求されたセグメントが失われている
エラー:要求されたセグメントが消失している
エラー:フィールドが不正なエラーを含んでいる。例えば NM フィールドが”FOO”を含んでいる
エラー: データ型 ID か IS のフィールドが対応する表と比較され、合致するものが無い
却下:そのメッセージ型は提供されていない
却下:そのイベントコードは提供されていない
却下:その処理 ID は提供されていない
却下:そのヴァージョン ID は提供されていない
却下: 患者、オーダ等の ID が見つからない。付加以外ではトランザクションに用いられる。例えば存在しない患者の転送__________________________________________________________________________
22（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
Value
205

Description
キー識別子の重複

206

アプリケーションレコードがロッ
クされている
アプリケーション内部エラー

207

Comment
却下:患者やオーダ等の ID が既に存在している。付加トランザクションの応答で用いられる（許可、新オーダ等）
トランザクションが、アプリケーション格納レベルで実行することができなかった（例えばデータベースのロック）
却下: 他のコードで明示的に対象としていない、包括的な内部エラー用

1
2
3
4
5

MSA-2 Message Control ID フィールドに、このアクノレッジが送信されたものであることを知らせるため、送られてきた MSH-10 Message Control ID メッセージ ID が含まれていな
ければならない。
Table 2.4-3. IHE Profile - ERR segment
SEQ

LEN

DT

OPT

RP/#

1

493

ELD

B

Y
Y

TBL#

要素名

ITEM #
00024

エラーコードと位置

2

18

ERL

O

01812

エラー位置

3

705

CWE

R

0357

01813

HL７ エラーコード

4

2

ID

R

0516

01814

影響度

5

705

CWE

O

0533

01815

アプリケーションエラーコード

6

80

ST

O

01816

アプリケーションエラーパラメータ

7

2048

TX

O

01817

診断情報

8

250

TX

O

01818

ユーザメッセージ

9

20

IS

O

0517

01819

人への通知指標

10

705

CWE

O

0518

01820

オーバライドタイプ

11

705

CWE

O

Y

0519

01821

オーバライド理由コード

12

652

XTN

O

Y

01822

ヘルプデスクコンタクトポイント

Y/10

Y

6
7

HL7 Table 0516 – Error severity
Value
W

Description
警告

I

情報通知

E

エラー

Comment
トランザクションは成功したが、何か問題がある
トランザクションは成功したが、何か情報を含む，例）患者へ伝えるべき情報
トランザクションが失敗した

8
9

User-defined Table 0517 – Inform person code
Value
PAT
NPAT
USR
HD

Description
患者に知らせる
患者に知らせてはいけない
ユーザに知らせる
ヘルプデスクに知らせる

Comment

1011

User-defined Table 0518 – Override type
Value
EXTN

Description
拡張オーバライド

INLV

間隔オーバライド

EQV

等価オーバライド

Comment
ある処理が指示された期間より長い間に実行されている場合のオーバラ
イドを示す
処理の繰り返しが指示された回数よ
り早く行われている場合のオーバラ
イドを示す
ある処理がそのシステムが指示され__________________________________________________________________________
23（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
Value

Description

Comment
た処理と同等であるとわからないオーダに対して行った場合のオーバラ
イドを示す

12 2.2.2.3 HL7 と DICOM のマッピングする際の考慮
3
4
5
6
7
8
9
10
11
12

フィールド長は DICOM では明確に規定されているが HL7 エレメントでは定義された最大長でない複数のコンポーネントで構成される可能性がある。DICOM 属性長より長い
HL7 コンポーネントがある場合がある。マッピングされたフィールドは決められた HL7と DICOM のフィールド長の短いほうを超えない必要がある。また代替文字コードセットを使用しているシステムでは、制御文字等を含めて超えないこと。全てのシステムは
DICOM のデフォルト文字コードセット(ISO-IR 6 or ASCII)をサポートしなければならない。
さらに IHE-J では日本語文字コードをサポートしなければならない（IHE では othercharacter sets may be supported となっている）代替文字コードセットを使用してエンコー
ドされているデータの一貫性を維持することは IHE テクニカルフレームワークの範囲外
でとなっている。

13
14

値表記については明確に述べていない。注意すべきことは HL7 表記と DICOM 表記のマッピングで決められるべきである。これらの例としては、患者名、日時などがある。

15 2.2.2.4 コード化されたエンティティとコーディングの使用法
16
17
18
19
20

IHE は管理された用語（コード化されるもの）に対するコーディング法あるいはリソースについてを規定、管理、特定することはない。利用可能な場合は HL7 と DICOM で必要なコーディング法は前もって示すこと。そのようなリソースが HL7 および DICOM によって明確に示されないときには、実装においてライセンス・版権が必要なリソース（所有物あるいはローカルも含めて）を使うことになるかもしれない。

21__________________________________________________________________________
24（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________1 3

IHE CARD Technical Framework Supplement Stress2

3.1.1 解説文

3

1. Stress Testing Workflow

4
5
6

この統合プロファイルは、患者の識別、オーダー、検査のスケジューリング、状態の報告、多段階試験の実施、
およびデータの保存について規定している。

7
8

ワークフロー図ADT

Pt. Registration [RAD-1] ↓Patient Update [RAD-12] ↓DSS/ Order Filler↓ Pt. Registration [RAD-1]↓ Patient Update [RAD-12]← Placer Order Management [RAD-2]→ Filler Order Management [RAD-3]

Order Placer↓ Procedure Scheduled [RAD-4]↓ Patient Update [RAD-12]↓ Procedure Updated [RAD-13]

Time Client↑ Modality PS in Progress [CARD-1]↑ Modality PS Completed [RAD-7]↑ Instance Availability Notification [RAD-49]
Evidence
Creator← Modality PS in Progress [CARD-1]← Modality PS Completed [RAD-7]
Storage ↓Commitment[CARD-3]

Performed
Procedure
Step Manager

Image Display↓ Modality Image/EvidenceStored [CARD-2]

Image
Manager

Report Creator↓ Query Images [RAD-14]↓ Retrieve Images/Evidence [CARD-4]

Image
Archive→ Modality PS in Progress [CARD-1]→ Modality PS Completed [RAD-7]
StorageCommitment ↑[CARD-3]↑Modality Image/EvidenceStored [CARD-2]← Modality PS in Progress [CARD-1]← Modality PS Completed [RAD-7]
Acquisition
Modality← Query Modality Worklist [RAD-5]

Report Creator

Time Client

9
10

Figure 8.1-1. Stress Testing Workflow Diagram

11
12

アクタとトランザクション

13
14
15

使用しているアクタとトランザクションは Table 8.1-1 のとおりである。詳細は各テクニカルフレーム
ワークを参照すること。

Table 8.1-1. Stress Workflow - Actors and Transactions
ActorsADT Patient
Registration

Transactions

Optionality

SectionPatient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12__________________________________________________________________________
25（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
Actors

Optionality

SectionPatient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Placer Order Management [RAD-2]

R

RAD-TF 2: 4.2

Filler Order Management [RAD-3]

R

RAD-TF 2: 4.3

Patient Registration [RAD-1]

R

RAD-TF 2: 4.1

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

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 [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Query Modality Worklist [RAD-5]

R

RAD-TF 2: 4.5

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Procedure Scheduled [RAD-4]

R

RAD-TF 2: 4.4

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Patient Update [RAD-12]

R

RAD-TF 2: 4.12

Procedure Updated [RAD-13]

R

RAD-TF 2: 4.13

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Instance Availability Notification [RAD-49]

O

RAD-TF 3: 4.49

Performed
Procedure Step
Manager

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Image Display

Query Images [RAD-14]

R

RAD-TF 2: 4.14

Retrieve Images/Evidence [CARD-4]

R

CARD-TF 2: 4.4

Modality Procedure Step In Progress [CARD-1]

R

CARD-TF 2: 4.1

Modality Procedure Step Completed [RAD-7]

R

RAD-TF 2: 4.7

Modality Images/Evidence Stored [CARD-2]

R

CARD-TF 2: 4.2

Storage Commitment [CARD-3]

R

CARD-TF 2: 4.3

Order Placer

Department System
Scheduler/
Order Filler

Acquisition
Modality

Image Manager/
Image Archive

Evidence Creator

Report Creator

Transactions(See Text)__________________________________________________________________________
26（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1

Use Case S1: Cardiac Stress Test （ECG Only）

2
3

Table 8.4-1: ECG Only Stress Use Case
Clinical Context

IHE Context

ストレステストオーダーを発行する。

Placer Order Management [RAD-2]トランザクションの Order Placer か、Filler Order Management [RAD-3]トランザクションの DSS/OF

ストレスモニタ装置が準備され負荷プロトコルを選択する。

DSS/OF患者がテストのために到着する。
患者の情報やオーダー情報がストレ
スモニタ装置にロードされる。

Modality Worklist [RAD-5]ｸｴﾘを使用する。

テスト実施者によって、負荷プロト
コルが確認されるか変更される。

選択されたプロトコルには、関連プ
ロトコル Code があり、テスト開始
は Modality Procedure Step In Progress[CARD-1]トランザクションで
DSS/OF と Image Manager/Image
Archive へ送られる。

患者の準備ができている。
心電図電極が付けられ、血圧をモニターするならばカフが巻かれる。
安静時心電図が記録される。

プロトコルが選択され心電図の記録
が、Modality Images/ Evidence Stored[CARD-2] トランザクションを使って、Image Manager/Image Archive に送られる。

運動負荷プロトコルを使用するな
ら、患者は負荷装置に乗り基準心電図波形が収録される。

プロトコルステージが選択され心電図の記録が、Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。

負荷プロトコルを開始する。ステー
ジにしたがって負荷が増え、心電図波形が収集される。

プロトコルステージが選択され心電図の記録が、Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。

運動負荷ではトレッドミルの速度/勾配やエルゴメータの抵抗を増やし、薬物負荷では周期的な投薬で負荷をあげる。

__________________________________________________________________________
27（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
最大負荷に達するか、他の停止要因があった時にテストは終了する。
リカバリ時の心電図波形が収集される。

プロトコルステージが選択され心電図の記録が、Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。

試験が終了し、患者は解放される。

追加負荷試験データ（測定値、手順
ログなど）が Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。
テストの終了は、Modality Procedure
Step Completed [RAD-7] トランザク
ションで伝えられ、Storage
Commitment [CARD-3] トランザクシ
ョンで Image Manager/Image Archive
で結果が保存される。

ストレステストは、ストレスモニタ
装置または判読ワークステーション
で医師によってレビューされる。

The Image Display actor uses Query
Images [RAD-14] と Retrieve
Images/Evidence [CARD-4] で心電図が呼び出される。

医師は結果を判定しレポートを作成する。

The Report Creator アクタが他のプロファイルを使ってレポートを送る。

__________________________________________________________________________
28（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1

Use Case S1: Cardiac Stress Test with Imaging

2
3

Table 8.4-1: ECG with Imaging Stress Use Case
Clinical Context

IHE Context

ストレステストオーダーを発行する。

Placer Order Management [RAD-2]トランザクションの Order Placer か、Filler Order Management [RAD-3]トランザクションの DSS/OF

ストレスモニタ装置が準備され負荷プロトコルを選択する。

DSS/OF患者がテストのために到着する。
患者の情報やオーダー情報がストレ
スモニタ装置にロードされる。

Modality Worklist [RAD-5]クエリを使用する。

テスト実施者によって、負荷プロト
コルが確認されるか変更される。

選択されたプロトコルには、関連プ
ロトコル Code があり、テスト開始
は Modality Procedure Step In Progress[CARD-1]トランザクションで
DSS/OF と Image Manager/Image
Archive へ送られる。

ストレスモニタ装置から心電図波形のアナログ出力が画像装置に接続され、心臓のイメージ収集のためのゲーティング信号として使われる。
患者の準備ができている。
心電図電極が付けられ、血圧をモニターするならばカフが巻かれる。
安静時心電図が記録される。

プロトコルが選択され心電図の記録
が、Modality Images/ Evidence Stored[CARD-2] トランザクションを使って、Image Manager/Image Archive に送られる。

安静時の、負荷前画像が収集される。

プロトコルが選択され心電図の記録
が、Modality Images/ Evidence Stored[CARD-2] トランザクションを使って、Image Manager/Image Archive に送られる。

__________________________________________________________________________
29（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
運動負荷プロトコルを使用するな
ら、患者は負荷装置に乗り基準心電図波形が収録される。

プロトコルステージが選択され心電図の記録が、Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。

負荷プロトコルを開始する。ステー
ジにしたがって負荷が増え、心電図波形が収集される。

プロトコルステージが選択され心電図の記録が、Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。

運動負荷ではトレッドミルの速度/勾配やエルゴメータの抵抗を増やし、薬物負荷では周期的な投薬で負荷をあげる。
ストレス中の画像が必要に応じて収集される。運動負荷では、患者は画像収集のためトレッドミルかエルゴ
メータを降りる。

プロトコルステージが選択され心電図の記録が、Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。

最大負荷に達するか、他の停止要因があった時にテストは終了する。
最大負荷の画像が収集される。

プロトコルステージが選択され心電図の記録が、Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。

リカバリ時の心電図波形が収集される。

プロトコルステージが選択され心電図の記録が、Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。

試験が終了し、患者は解放される。

追加負荷試験データ（測定値、手順
ログなど）が Modality Images/
Evidence Stored [CARD-2] トランザク
ションを使って、ImageManager/Image Archive に送られる。
テストの終了は、Modality Procedure
Step Completed [RAD-7] トランザク
ションで伝えられ、Storage
Commitment [CARD-3] トランザクシ
ョンで Image Manager/Image Archive
で結果が保存される。

__________________________________________________________________________
30（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
ストレステストは、ストレスモニタ
装置または判読ワークステーション
で医師によってレビューされる。

The Image Display actor uses Query
Images [RAD-14] と Retrieve
Images/Evidence [CARD-4] で心電図が呼び出される。

医師は結果を判定しレポートを作成する。

The Report Creator アクタが他のプロファイルを使ってレポートを送る。

__________________________________________________________________________
31（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________

1

4 IHE CARD Technical Framework Supplement IDCO

2

本ドキュメントは IHE-J では対象外（コネクタソン、実装）なので、解説文はない。

3__________________________________________________________________________
32（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________

1 5

IHE ITI Technical Framework version 2.0 Final Text

2
3
4
5
6

本解説文の対象範囲は、以下の統合プロファイルのみを対象としている。
a) Patient Identifier Cross-referencing 統合プロファイル (PIX)b) Consistent Time 統合プロファイル(CT)c) Patient Demographics Query 統合プロファイル(PDQ)d) Audit Trail and Node Authentication 統合プロファイル(ATNA)

7
8

これは、Year 3 の循環器部門では上記の IHE ITI の TF を必要としているからであり、残りの部分は対象外あるが、必要に応じて参照することを推奨する。

9 5.1 解説文
10

5.1.1 Patient Identifier Cross-referencing (PIX)

11
12
13
14

Patient Identifier Cross-referencing Integration Profile (PIX)は複数のドメイン間で、患者ID相互参照を可能にする。特定の患者について、異なるIDを利用しているソースからの患者情報を関連付けさせることができる。これにより、医師は患者情報をより完全な形で閲覧することができる。

15
16
17
18

PIXは、様々な規模の医療機関（病院、クリニックや開業医など）をターゲットにしいる。以下の相互関係で、複数の患者IDドメインからの患者IDの相互参照をサポートする。
• IDソースから「Patient Identifier Cross-reference Manager」への患者ID情報の送信。
• クエリ・リスポンスまたはアップデート通知による相互参照された患者IDリストへのアクセス

19
20
21

この統合プロファイルは、特定のエンタープライズポリシーや相互参照アルゴリズムを定義しない。単一アクタに、これらのふるまいを包括させることで、そのエンタープライズで適切と考えられた相互参照ポリシー、アル
ゴリズムを使用して、柔軟な互換性を提供する。

22

下図に、患者IDドメイン、患者ID相互参照ドメイン、2つのタイプのIDドメインを示す。

__________________________________________________________________________
33（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________

Patient Identifier
Cross-reference Domain

患者IDフィード、患者 ID
レファレンス

患者IDドメインC
Patient Identifier
Cross-referenceManager

患者IDフィード

Patient Identity
Source内部ドメイント
ランザクション

患者IDフィード
患者ID相互参照

Patient Identifier
Cross-reference
Consumer

他のIHEアクタ

Patient Identity
Source内部ドメイント
ランザクション

Patient Identifier
Cross-reference
Consumer

他のIHEアクタ

患者IDドメインA

1
2

患者ID相互参照

患者IDドメインB

図 5-1 患者ID相互参照プロセスフロー__________________________________________________________________________
34（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2

アクタ・トランザクション

34

図5.1-1はPIXに直接関連するアクタ、そしてアクタ間のトランザクションを示している。他の関連するプロファイ
ルに参加しているため、間接的に関連している他のアクタはここでは示されていない。

5

Patient Identity Source

患者IDフィード[ITI-8]↓

Patient Identifier
Cross-reference
Consumer↓PIXクエリ[ITI-9]↑PIXアップデート通知[ITI-10]

Patient Identifier
Cross-referenceManager67

図 5.1-1 「Patient Identifier Cross-referencing」アクタ図表

8910__________________________________________________________________________
35（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
12

5.1.2 Consistent Time (CT)

3
4
5
6
7
8
9

Consistent Time 統合プロファイル(CT)は複数のアクタとコンピューター間のタイムベースを同期化するメカ
ニズムを定義する。複数のインフラ、セキュリティ、情報収集プロファイルが、複数のコンピューターにおける一貫したタイムベースを必要とする。CTはRFC 1305で定義されたNetwork Time Protocol (NPT)の利用を求めている。タイムサーバがより上層のタイムサーバから時間を入手することを目的に、タイムクライアントとグルー
プ化されている場合、タイムクライアントはNTPを利用する。タイムサーバとグループ化されていないタイムクライアントでは、SNTPが利用可能な場合もある。

10
11

アクタ・トランザクション

12
13
14

図7.1-1は直接CTに関連するアクタと、アクタ間で関連するトランザクションを示している。一貫した時間情報を必要とする他のプロファイルに参加しているために、間接的に関連している他のアクタはここでは示されていな
い。

15
16
17
18

Time Server

19
20
21

時間維持[ITI-1] ↑

22
23
24

Time Client

25
26
27
28
29
30
図 7.1-1: Consistent Time プロファイルアクタ図表

31
32
33
34

__________________________________________________________________________
36（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
12

5.1.3 Patient Demographics Query (PDQ)

3
4
5
6

Patient Demographics Query 統合プロファイル(PDQ)は複数の分散されたアプリケーションから集中管理された患者情報サーバに、ユーザが定義した検索基準でクエリを行い、患者の基本情報（名前、生年月日、住所、電話番号、オプションとして来院または来院関連の情報）を直接取り込むことができる方法を提供する。

7
8

アクタ・トランザクション

910

図8.1-1は直接PDQに関連するアクタと、アクタ間で関連するトランザクションを示している。Patient ID Crossreferencingなどに参加しているために、間接的に関連している他のアクタはここでは示されていない。

11
12
13
14
15
16
17
18
19

Patient Demographics
Supplier

患者基本情報クエリ[ITI-21]↑

20
21
22

↑患者基本情報と来院
情報クエリ[ITI-22]

Patient Demographics
Consumer

23
24
25
26
27
28
29

図 8.1-1. Patient Demographics Query プロファイルアクタ図表

30__________________________________________________________________________
37（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
12

5.1.4 Audit Trail and Node Authentication (ATNA)

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Audit Trail and Node Authentication 統合プロファイル(ATNA)はエンタープライズが持つセキュリティポ
リシーや手順とあわせ、患者情報の機密性、データの完全性とユーザのアカウンタビリティを提供するセキュリ
ティ対策を確立する。この環境は、部門から、エンタープライズまたは関連ドメインにかけられ、セキュリティドメ
インとして考慮される。ATNAモデル以下の項目を考慮する。
1) 全ての機器はホストで承認される。（これを達成する様々な方法がある。）この認証は、医療機関のセ
キュリティシステムのセキュリティ特性で認識された機器を識別する。未認証の機器は、未認証の機器または、公共に公開された情報のみへのアクセスが認証される。
2) ホスト認証は、（もしあれば）ホストで自動化されたプロセスでのアクセス許可、および（/または）ホストのアクセスコントロールの指示で人によるアクセス許可を使用する。
3) セキュアノードは適度なアクセスコントロール機能を提供する責任がある。これは一般的なユーザ認
証と権限を含んでいる。ユーザ認証の重要性は、実行できる安全性と、認証手順の追加で、医療の提供が遅れる患者の健康への影響とのバランスを考慮する必要がある。
4) セキュアノードはさらに、セキリティイベントの追跡のために、セキュリティ監視ログ記録を提供する責務がある。この監視ログはヘルスケアにおいて厳しいアクセスコントロールより、常に有用であり、緊急事に信頼すべきである。

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

ATNAによるセキュリティに関する前提条件は以下の通りである。
• セキュアドメインのメンバーである全てのシステムは、ATNAプロファイルの「Secure Node」アクタを導入している。ATNAプロファイルはドメインセキュリティ担当者が管理するセキュアドメイン作成のため、セキュアノード間のトランザクションを定義する。
• セキュアノード上の全てのアプリケーションは、IHEアクタかどうかにかかわらず、ATNAリクワイヤメン
トを遵守する。これはIHEで指定され、IHEアクタに実施されるものだけでなく、直接PHIを作成、アクセス、アップデート、削除するなど、ITに支援された全てのアクティビティに適用される。
•
IHEはIHEヘルスケアアプリケーション関連のシステムにおけるセキュリティ要件のみに言及する。ネットワーク攻撃やウィルス感染対策などの他のセキュリティリ要件に関しては対象外である。監査証跡
メカニズムの主要な目的は、IHEトランザクションではなく、PHIへのデータアクセスを追跡することである。

••

モバイル機器もAudit Trail and Node Authentication統合プロファイルに参加することができるが、このプロファイルにおいては、モバイル機器に特有の問題については、明確に言及しない。
ATNAは物理的なアクセス制御、職員へのポリシーや他の組織におけるセキュリティの問題など、エンタープライズセキュリティやプライバシー規制に遵守に必要な事柄については、すでに対応が行われていることを前提としている。

38
39

認証

40
41
42
43

ATNAは、ノード間のネットワーク・アクセスの制限と、個々のノードのアクセスを許可されたユーザに制限する
ことで、アクセスコントロールに貢献する。セキュアドメイン内のセキュアノード間のネットワーク通信は、そのドメイン内の他のセキュアノードに制限される。セキュアノードは、ローカル認証とアクセスコントロールの方針で指定されたように、許可されたユーザへアクセスを制限する。

__________________________________________________________________________
38（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1
2

ユーザ制限

3
4

ATNAはローカルユーザ認証のみが要求される。このプロファイルは、各々のセキュアノードが選択したユー
ザ認証のアクセス制御技術を使用することを許可する。

5
6

接続認証

7
8
9
10

ATNAは、それぞれのノード間の接続において、双方向の証明書ベースのノード認証を要件としている。
DICOM、 HL7、そしてHTMLプロトコルにおいては、証明書ベースの認証メカニズムの定義が行われている。
これらはユーザではなく、ノードを認証する。双方向のノード認証が行われていないマシンへの接続は禁止されるか、PHIへのアクセスを阻止するようなデザインや確認が行われる。

11
12
13
14
15
16

IHEは伝送中の暗号化の使用を要求しない。ほとんど病院のネットワークは物理的および手続的メカニズムを通して十分なセキュリティを提供している。このプロファイルは、セキュアノード間の全ての通信で、他の認証されたセキュリティノードの通信のみを保証する方法として、TLSセキュリティネゴシエーションメカニズムの使用を要求している。これは、両ノードで暗号のサポート要求が設定されている場合、暗号化のネゴシエーションを許可する。これは、ネットワークが他の方法でセキリティされていない環境に、IHEセキュアノードの設置を可能
にする。

17
18

監査証跡

19
20
21
22
23
24

ユーザの説明義務は監視証跡を通して提供される。監査証跡は施設のセキュリティ担当者の監査活動の許可、セキュアドメインポリシーの遵守を査定、不適合な行動の検出、と保護された健康情報(PHI)の不適当な作成、アクセス、修正および削除の検出の促進の必要がある。PHIは、患者確認可能な情報記録として考慮される（例えば、登録、オーダ、検査／手順、レポート、イメージ、および提示状態）。PHIはユーザによりアクセス
されるか、システム間で交換されるであろう。これは、セキュアドメイン内の全てのセキュアノードへエクスポー
トされる情報と、セキュアドメイン内の全てのセキュアノードからインポートされる情報を含んでいる。

25
26
27
28
29
30

ユーザの説明責任は、中央監視記録所（Centralized Audit Record Repository)の設置基準を通じてさらに高められる、それはセキュリティ要件を実行する最も簡単な方法として中央監視記録所（Centralized Audit
Record Repository)を提供する。全てのIHEアクタからAudit Record Repositoryへ監視記録を可能な限り即時に転送することが要求される、これは、不正変更の機会をへらして、部門を監視することを容易にする、しかし、セキュリティドメインのネットワークに接続されていないノードでは、再接続直後にAudit Repositoryに転送するために、監視データ貯められる。

31
32
33
34
35

監査証跡は以下のような質問に答えることが出来る情報を含んでいる。
• ユーザのため：どの患者のPHIがアクセスされましたか？
• 患者PHIのために：どのユーザがそれをアクセスしたか？
• どのようなユーザ認証の失敗が報告されたか？
• どのようなノード認証の失敗が報告されたか？

36
37

アクタ・トランザクション

38
39
40
41

表9.4-1はATNAに直接関連するそれぞれのアクタのトランザクションをまとめたものである。この統合プロファ
イルをサポートしていると申告するためには、「R」で示される、必要条件とされるトランザクションが実行されなければならない。「O」で示されるトランザクションはオプションである。この統合プロファイルで定義されているオプションの全リストはITI TF-1: 9.4に示されている。

__________________________________________________________________________
39（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
1

これらの関連は図9.4-1に示されている。

2
o ITI-1: Maintain TimeTime Server

Secure Nodegrouped with
Any IHE Actor

ITI-20: Record Audit Event↓o ITI-1:
Maintain Time

Secure Nodegrouped with
PHI Application

Audit Repository↔ ITI-20: Record
Audit Event

ITI-19: Node
Authentication o
ITI-20: Record Audit Event↑
Secure Nodegrouped with
Any IHE Actor34

図9.4-1. Audit Trail and Node Authentication5
表 9.4-1. Audit Trail and Node Authentication

6

統合プロファイルーアクタとトランザクション

7
Actor

Transactions

Optionality

Vol II / III Section<any PHI application grouped with a Secure Node Actor>

Record Audit EventR

IHE ITI-2: 3.20

<any IHE actor grouped with a Secure Node actor>

Record Audit EventR

IHE ITI-2: 3.20

Audit Record Repository

Record Audit EventR

IHE ITI-2: 3.20

Secure Node

Authenticate NodeR

IHE ITI-2: 3.19

Maintain TimeR

IHE ITI-2: 3.7

Authenticate NodeO

IHE ITI-2: 3.19

Maintain TimeOIHE ITI-2: 3.7

Secure Application

8
9
10
11
12

セキュアノードアクタには以下が含まれる。
1. プライベート情報を公開する可能性のある全てのネットワーク接続におけるノード認証トランザクション。
これらのトランザクションは以下を使って定義される。

13a) DICOM、TLSを利用

14b) HL7、 TLSを利用

15
16
17
18

c) HTTP、TLSを利用
2. 許可されたユーザのみの利用を保証するため、全てのローカルユーザアクティビティ（ログイン、ログアウトなど）の保護
3. 以下のいずれかを利用した監査トランスポートメカニズム__________________________________________________________________________
40（中）日本ＩＨＥ協会

Copyright © 2007: IHE-JIHE Cardiology Year 3 パブリックコメント用解説文集______________________________________________________________________________
12
34a) Reliable Syslog Cooked Profileフォーマット (RFC-3195、Section 4)b) BSD Syslog (RFC-3164)、baseline syslog mechanism
4. 監査メッセージフォーマットの代替としての定義を活用し、推奨されるイベントの監査メッセージを作成。
監査メッセージフォーマットは以下のとおり。

5a) DICOMとIHEボキャブラリを利用したIETF common audit message format

6b) Provisional IHE Audit Message フォーマット

7__________________________________________________________________________
41（中）日本ＩＨＥ協会

Copyright © 2007: IHE-J