ACC, HIMSS and RSNA
Integrating the Healthcare Enterprise

IT インフラストラクチャ
テクニカルフレームワーク
Volume 1(ITI TF-1)
統合プロファイル

Revision 2.0 – Final Text
August 15, 2005
Copyright © 2005: ACC/HIMSS/RSNA

翻訳 平成18年3月 JAHISIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

目次
1 はじめに ..........................................................................................................3
1.1
テクニカルフレームワーク概要................................................................4
1.2
IT インフラ・ボリューム 1 の概要 .............................................................4
1.3
対象読者 .................................................................................................5
1.4
標準との関係...........................................................................................5
1.5
実際のアーキテクチャとの関係...............................................................6
1.6
記載方法 .................................................................................................6
1.7
今年度導入された変更の焦点................................................................8
1.8
セキュリティ上の影響 ........................................................................... 10
1.9
コメント .................................................................................................. 10
1.10
著作権許可....................................................................................... 11
1.11 IHE テクニカルフレームワーク開発と保守プロセス ............................. 11
2 IT インフラ統合プロファイル......................................................................... 12
2.1
統合プロファイル間の依存関係 ........................................................... 12
2.2
統合プロファイル概要........................................................................... 13
2.3
製品への実装....................................................................................... 16
3 Retrieve Information for Display (RID) ..................................................... 18
3.1
アクタ・トランザクション ......................................................................... 18
3.2
Retrieve Information for Display 統合プロファイルのオプション........ 20
3.3
Retrieve Information for Display プロセスフロー ............................... 21
4 Enterprise User Authentication (EUA)...................................................... 24
4.1
アクタ・トランザクション ......................................................................... 24
4.2
Enterprise User Authentication 統合プロファイルオプション ............. 26
4.3
Enterprise User Authentication プロファイルプロセスフロー............. 27
5 Patient Identifier Cross-referencing (PIX) ................................................ 33
5.1
アクタ・トランザクション ......................................................................... 35
5.2
Patient Identifier Cross-referencing 統合プロファイルのオプション.. 36
5.3
Patient Identifier Cross-referencing プロセスフロー ......................... 36
5.4
PIX 統合プロファイルと eMPI との関係............................................... 39
6 Patient Synchronized Applications (PSA) ................................................ 42
6.1
アクタ・トランザクション ......................................................................... 42
6.2
Patient Synchronized Applications 統合プロファイルオプション....... 43
6.3
Patient Synchronized Applications 統合プロファイル プロセスフロー44
7 Consistent Time (CT)................................................................................. 46
7.1
アクタ・トランザクション ......................................................................... 46
7.2
Consistent Time 統合オプション ......................................................... 47
7.3
Consistent Time プロセスフロー ......................................................... 47
8 Patient Demographics Query (PDQ) ........................................................ 49
8.1
アクタ・トランザクション ......................................................................... 49
8.2
Patient Demographics Query 統合プロファイルオプション................ 49
8.3
Patient Demographics Query プロセスフロー ................................... 50
9 Audit Trail and Node Authentication (ATNA) ........................................... 53
9.1
接続認証 .............................................................................................. 55-1Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

9.2
監査証跡 .............................................................................................. 56
9.3
監査証跡転送....................................................................................... 58
9.4
アクタ・トランザクション ......................................................................... 59
9.5
暗号化オプション .................................................................................. 61
9.6
Audit Trail and Node Authentication プロセスフロー......................... 61
10
Cross-Enterprise Document Sharing (XDS) ........................................ 66
10.1
アクタ・トランザクション ..................................................................... 68
10.2
統合プロファイルオプション .............................................................. 72
10.3
統合プロファイルプロセスフロー....................................................... 73
10.4
一般的な法則 ................................................................................... 78
10.5
実装戦略 .......................................................................................... 90
11
Personnel White Pages (PWP) ............................................................. 94
11.1
アクタ・トランザクション ..................................................................... 94
11.2 PWP 統合プロファイルオプション ........................................................ 95
11.3 PWP 統合プロファイルプロセスフロー................................................. 96
付録 A: アクタについて........................................................................................ 97
付録 B: トランザクションについての記述........................................................... 100
付録 C: IHE 統合説明書................................................................................... 103
付録 D: ユーザ認証テクニックーパスワード、バイオメトリクス、トークン .......... 106
付録 E: プロファイルの組み合わせ利用 ........................................................... 107
付録 F: 標準団体に対する要請 ........................................................................ 111
付録 G: セキュリティへの考慮........................................................................... 112
付録 H: 意図的に空白....................................................................................... 115
付録 I: 意図的に空白 ........................................................................................ 115
付録 J: XDS ドキュメントのコンテンツとフォーマット ......................................... 116
付録 K: XDS 概念の詳細 ................................................................................. 118
付録 L: XDS 連合ドメイン定義のチェックリスト................................................. 124
付録 M: エンタープライズ間の文書共有と IHE ロードマップ............................. 126
用語集................................................................................................................ 128-2Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1 はじめにIntegrating the Healthcare Enterprise (IHE) は、現代のヘルスケア機関の情報シス
テム統合を推進する目的で始められたイニシアチブである。その主な目的は、患者のケアにあたり、医療従事者が治療方針決定の際に必要とされる全ての情報を、正確に入手することを確実にする、というものである。IHEイニシアチブは、このような目的達成に必要となる情報統合を目指す「プロセス」そのものであり、また「フォーラムの場」でもある。
IHEイニシアチブでは、特定の臨床治療実施に必要とされるメッセージング（情報交換）に必要な、テクニカルフレームワークの定義づけを行っている。またフレームワー
クの統合に向け、厳密なテストプロセスも実施している。IHEイニシアチブではまた、
医療プロフェッショナル向けに開催されている主要な会議などにおいて、教育セッショ
ンや展示などを行い、このようなフレームワークの利点についてのデモンストレーションを行い、産業やユーザに対し、フレームワークの適用を促進する活動も行っている。
IHEイニシアチブでは、新しい標準を確立するのではなく、HL7、ASTM、DICOM、ISO、IETF、OASISをはじめとする既存の標準を適宜サポートするというアプローチを取っている。IHEでは、それぞれのドメインにおいて、異なるアクタ間でも一貫した形で利用することができるよう、必要に応じてこれらの標準の設定をさらに指定している。
またこれら既存の標準において、さらに明確化や拡張が必要な場合、IHEは関連する標準団体に対して提言を行う。
このイニシアチブは、さまざまな専門医療分野や地域にまたがる、数多くのスポンサ
ーや支援団体によって成り立っている。北米における主要スポンサーとしては、米国
心臓病学会（American College of Cardiology：ACC), 医療情報管理システム学会（Healthcare Information and Management Systems Society：HIMSS) 、そして北米放射線医学学会（Radiological Society of North America：RSNA)が挙げられる。
またカナダにおいては、IHE Canadaも新しく結成された。一方IHE Europe (IHEEUR)は、欧州放射線学協会（European Association of Radiology：EAR)、 欧州放射線学会議（European Congress of Radiologists：ECR)、 欧州放射線・電子医療
産業調整委員会（Coordination Committee of the Radiological andElectromedical Industries：COCIR)、Deutsche Röntgengesellschaft (DRG)、
EuroPACS協会（EuroPACS Association）、 病院情報システム近代化グループ（Groupement pour la Modernisation du Système d'Information Hospitalier：
GMSIH)、フランス放射線学協会（Société Francaise de Radiologie：SFR)、イタリア
医療放射線協会（Società Italiana di Radiologia Medica：SIRM)そして欧州医療記録協会（European Institute for health Records：EuroRec)といった、多数の組織によって支援されている。日本のIHE-J は、経済産業省（METI）、厚生労働省、MEDISDCのほか、日本画像医療システム工業会（JIRA）、保健医療福祉情報システム工業会（JAHIS）、日本医学放射線学会（JRS）、日本放射線技術学会（JSRT）、日本医療情報学会（JAMI）により支援されている。この他にもIHEでは、専門分野や地域の枠-3Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNA

コメント [MS1]: 訳者注：正確にはEuropean Congress of Radiology

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

を超えたIHEプロセスの拡大に向け、さまざまな医療専門家を代表する団体の参加を歓迎している。
1.1 テクニカルフレームワーク概要
本ドキュメント（IHE IT インフラテクニカルフレームワーク：ITI IF）は、医療情報共有を促進するため、情報統合実現を目的に設置された標準の実装方法について定義を行う。これはレビュー期間を経て毎年拡大されるもので、正誤表の作成、訂正などを通じて定期的な保守が行われている。現在のバージョンである最終テキスト改定 2 版
は、2005 年 8 月の時点において定義、導入されている IHE トランザクションを示したものである。本ドキュメントの最新版は、常時インターネット上で入手可能である（http://www.ihe.net/Technical_Framework）。
IHE IT インフラテクニカルフレームワークは、IHE アクタと呼ばれる医療機関の機能
コンポネントのサブセットを特定、調整された、標準ベースのトランザクションという点で、どのようなインタラクションが行われるのかを提示する。このトランザクション本体
については、段階を追って詳細に記述されている。現在のボリューム（ITI TF-1）では「統合プロファイル（Integration Profile）」と呼ばれる機能単位にまとめられたトランザ
クションを提示することで、IHE の機能について概観を提供している。ここでは、統合
プロファイルが、特定の IT インフラの必要条件にいかに対応できるかに焦点を置いている。
ITI TF-2 においては、IT インフラ統合プロファイルに利用される IHE トランザクション
について、より詳細な技術的記載に焦点が置かれている。これら 2 種類のドキュメン
トは一貫したものとなっており、他の IHE 分野の統合プロファイルとあわせて利用することが可能である。
IHE イニシアチブでは、この IHE テクニカルフレームワークと同じような形で、それぞれの分野におけるテクニカルフレームワークが作成されている。現在、以下の IHE テ
クニカルフレームワークが入手可能となっている。
•
•
•
•
•

IHE IT インフラテクニカルフレームワーク
IHE 心臓病学テクニカルフレームワーク
IHE 検査室（ラボ）テクニカルフレームワーク
IHE 患者ケア調整のためのテクニカルフレームワーク
IHE 放射線学テクニカルフレームワーク

本ドキュメントにおいては、必要に応じて他のテクニカルフレームワークに言及するが、他のフレームワーク引用方法については、本ドキュメントのセクション 1.6.3 を参照のこと。
1.2 IT インフラ・ボリューム 1 の概要-4Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

セクション 1 ではこの後、テクニカルフレームワークの一般的な性質、目的と機能について説明する。セクション 2 においては、テクニカルフレームワークを構成する IHE
統合プロファイルの概念を紹介する。
またセクション 3 以降においては、それぞれの統合プロファイルを詳細に記述する。
ここでは、統合プロファイルが取り組もうとしている IT インフラの問題や、そこに含まれる IHE アクタやトランザクションなどについても述べられる。
本文に続く付録は、アクタやトランザクションのサマリー・リスト、統合プロファイルに関連する特定の問題についての詳細な考察、用語集となっている。
1.3 対象読者
本文書の対象読者は以下のとおりである。
••••

ヘルスケア機関の IT 部門
IHE イニシアチブに参加するベンダの技術スタッフ
標準開発に関係する専門家
医療情報システムとワークフローの統合に興味を持つ者

1.4 標準との関係
IHE テクニカルフレームワークは、分散型医療業務環境における機能コンポネント（ここでは IHE アクタと呼ばれる）について、医療機関内でのインタラクションという点のみに注目している。現時点では、ASTM、DICOM、HL7、IETF、ISO、OASIS、W3C
標準に基づき調整されたトランザクションのセットが定義されている。IHE イニシアチ
ブの焦点が今後さらに拡大することにより、将来、必要に応じてこの他の標準に基づ
くトランザクションも含まれる可能性がある。
場合によっては、IHE はこれらの標準に基づくオプションの利用を推薦するが、標準遵守に矛盾するような技術的選択を紹介することはない。もし既存の標準やその拡張にエラーが見つかった場合、IHE は適切な標準団体にその旨報告を行い、標準団
体がそれを将来の遵守・標準開発戦略に反映させることで、問題解決にあたってもらうという方針をとっている。
つまり IHE はあくまで導入フレームワークであり、標準そのものではない。製品が何を遵守しているかを明記するにあたっては、直接これらの標準に言及しなくてはならない。さらに、自社製品に IHE 統合機能を実装したベンダは、その製品機能を伝える
ため、IHE 統合説明書（IHE Integration Statement）を発行しても良い。IHE 統合説
明書を発行するベンダが、その内容について全面的な責任を持つ。異なる製品の
IHE 統合説明書を比較することで、IHE のコンセプトやアクタについての知識を持つユーザは、これらの製品間の統合レベルを見極めることができる。IHE 統合説明書のフォーマットについては、付録 C を参照。

-5Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1.5 実際のアーキテクチャとの関係
IHEテクニカルフレームワークに記載されているIHEアクタとトランザクションは、現実のヘルスケア情報システム環境を抽象化したものである。従来、トランザクションの一部は、特定の製品カテゴリの中で実施されるが（病院情報システム、医療データレポ
ジトリ、放射線情報システム、医療情報システムや心臓病情報システムなど)、IHEテ
クニカルフレームワークでは意図的に機能やアクタを、これらの製品カテゴリと関連付けることを避けている。IHEテクニカルフレームワークは、それぞれのアクタにおいて、
情報システムの統合に関連する機能部分の定義のみを行っている。このため、IHEにおけるアクタの定義は、アクタを実装する製品の完全な定義にはなりえない。また、フレームワークそのものについても、ヘルスケア情報システムのアーキテクチャを包括的に記述するものと見なすべきではない。
アクタやトランザクションの定義は、医療情報システム環境における機能コンポネントのインタラクションを定義するための基盤提供を目的に行われる。例えばある製品が複数の機能を提供するような場合、その製品と、医療情報システム環境内部の他機
能とのインターフェイスのみが、IHEイニシアチブにとって重要な部分と見なされる。このため、IHEイニシアチブは、ある目的を達成する上で、全てを包括的に統合したひと
つの情報システムあるいは複数のシステムどちらの利用が有利であるかといった点について、特別な見解を表すことはない。IHEデモンストレーションは、IHEテクニカル
フレームワークに基づき、複数のベンダシステムの統合を強調するものである。
1.6 記載方法
本ドキュメントは、フレームワークのコンセプトを表現するため、また標準に基づくIHE
テクニカルフレームワークがいかに適用されるべきかを記載するため、以下のような記載方法を採用している。
1.6.1 IHE アクタ、トランザクション図表と一覧表
それぞれの統合プロファイルは、「トランザクション」を通じてやり取りする「アクタ」のセットによってサポートされている、現実世界の機能を表現したものである。「アクタ」は情報システムまたは情報システムのコンポネントを指し、エンタープライズ内の運用活動で必要とされるカテゴリーの情報の作成、管理、またはこれらの情報に基づき機能する。「トランザクション」はアクタ間のインタラクションを指す。ここでは、必要な情報が、標準ベースのメッセージを通じてやり取りされる。
以降のセクションで提示されるアクタとトランザクションの図表と一覧表は、それぞれのプロファイルにおけるアクタが、どのトランザクションをサポートしなければならない
かを示すものである。
図表に示されるトランザクションは、ITI TF-2で定義された名称と、トランザクション番号を利用して明示される。図表に示されたトランザクション番号は、かぎ括弧内に示され、特定のテクニカルフレームワークドメインの識別番号となっている。
-6Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

的確な機能、また有用性を維持するため、プロファイルは、前提条件となる他のプロファイルと従属関係を持つ場合がある。例えば「Enterprise User Authentication（EUA）」は、「Consistent Time（CT）」と従属関係にある。これらの関連性については、
表2-1において、前提条件となっているプロファイルがあるかを確認することができる。
アクタは、それぞれのプロファイルで求められているトランザクションに加え、前提条件となっているプロファイルに必要なトランザクションについても実行しなければならない。
1.6.2 プロセスフロー表
統合プロファイルには、プロセスフローに関する図表も含まれている。これはプロファ
イルが関連するアクター間で、いかにトランザクションの連続として機能するかを示したものである。
これらの図表は外観を示す目的で提示され、これによりトランザクションを、医療機関のワークフローの文脈の中で見ることができる。特定のトランザクションとアクティビテ
ィのうち、IHEにより詳細な定義が行われていないものについては、イタリック体で示されている。これは関連するIHEトランザクションが、幅広いヘルスケア情報システムのスキームのどの部分に合致するかについての追加情報として提供されている。
これらの図表は、唯一可能なシナリオを提示するものではない。これ以外のアクターのグループ化も可能な場合も多く、他のプロフィールからのトランザクションがそれぞれ組み込まれることもありうる。
場合によっては、トランザクションの順番もフレキシブルである。そのような場合、他のバリエーションが存在することを指摘する注記が記載されている。トランザクションの流れは矢印で示されている。この矢印はトランザクションによって処理される主要情報のフローを示すものであり、必ずしもトランザクションの開始を示すものではない。
1.6.3 テクニカルフレームワーク相互参照
本分文書内の他のセクションを参照を促す記載があった場合、セクション番号がそのまま利用される。参照が他のボリュームや、他のドメインの技術フレームワークに言及された場合、以下のフォーマットが利用される。
<ドメイン名> TF-<ボリューム番号>: <セクション><ドメイン名> の部分には、IHEドメインを示す記号が含まれる（ITI=ITインフラ、RAD=
放射線）<ボリューム番号> はテクニカルフレームワークのボリューム番号（1、2、3など）を含む。
<セクション番号> は適切なセクション番号が含まれる。
-7Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

例えば、ITI TF-1: 3.1 はIHE ITインフラテクニカルフレームワーク、ボリューム1におけるセクション3.1を参照している。RAD TF-3: 4.33はIHE 放射線テクニカルフレーム
ワーク、ボリューム3におけるセクション4.33を参照している。またITI TF-2: 付録 BはIHE ITインフラテクニカルフレームワーク、ボリューム2の付録Bを参照している。
テクニカルフレームワークのトランザクション番号に関する参照は以下のようになる。
[<ドメイン名>-<トランザクション番号>]<トランザクション番号> は指定されたドメイン内のドメイン番号を指す。例えば、 [ITI1] はIHE ITインフラテクニカルフレームワークにおけるトランザクション1を指す。
1.7 今年度導入された変更の焦点
IHEテクニカルフレームワークは、新たなプロファイルや修正、そしてこれらのプロファ
イルに利用される新たなトランザクション（ITI TF-2参照）を反映するため、毎年アップ
デートされる。
この文書は、ITインフラテクニカルフレームワークボリューム1を拡大するもので、また2003年から2004年の間に作成された統合プロファイルのほか、IHE ITインフライニ
シアチブが4-200-2005サイクルの間に最終決定した新規プロファイルなどが含まれている。これは2006年のConnect-A-thonテスト、そして特にHIMSSの2006年度会議における展示プロセスの基本となる。
ボリューム1には、5つの統合プロファイルが含まれていたが、ボリューム2では、利用者からのフィードバックを元に、これらのプロファイルのさらなる明確化や修正のため、小規模なセットの変更提案（Change Proposals：CP）が適用されている。
Retrieve Information for Display (RID) – より良いケア提供に必要な患者情報を、簡便で迅速なリード・オンリーの形で提供する。既存の保存文書は、CDA、PDF、JPEGなど一般に利用されているフォーマットで提供される。また医師に対し、アレルギーや現在の服薬情報、レポートのサマリーなど、個別患者に関する情報提示もサポートする。
Enterprise User Authentication (EUA) –統合プロファイルに参加する全ての機器やソフトウェアに利用できるよう、ユーザごとに単一のユーザ名を確立する方法を指す。これにより、ユーザ認証の集中管理、またユーザにシングルサインオンの迅速さと便宜性を提供することが可能となる。このプロファイルはKerberos(RFC1510)とHL7 CCOW標準（User Subject）を利用する。
Patient Identifier Cross-referencing (PIX) – 複数の患者IDドメイン間において、患者ID相互参照を可能にする。これらの患者IDは、ID利用システムで活用され、これ-8Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

により、特定の患者について、異なるIDを利用しているソースからの患者情報を関連付けさせることができる。
Patient Synchronized Applications (PSA) –ユーザのワークステーション上にある、独立した、リンクされていないアプリケーションを利用し、特定の患者のデータを閲覧する方法。複数のアプリケーションにおいて患者の情報を引き出す際に、何度も患者を特定する必要性をなくす。同じ患者に複数のIDが割り当てられる問題を解決する
PIX統合プロファイルとあわせて利用することで、異なるIDドメインからのデータを閲覧することが可能となる。このプロファイルは、HL7 COOW Patient Subject Context
Managementを活用する。
Consistent Time (CT) – 複数のアクタとコンピューターの時間基準を同期化させるメカニズム。インフラ、セキュリティ、情報取得に関するプロファイルにおいては、複数のコンピュータにおいて一貫した時間基準を利用することを求めている。CTプロファイ
ルは、同期化エラーを1秒以下に抑える中央値を提供する。
ITインフラテクニカルフレームワークバージョン2においては、2004年から2005年のサイクルの間に開発、テストが行われた4つの新しい統合プロファイルの最終化も行っている。
Patient Demographics Query (PDQ) –複数の分散されたアプリケーションが、集中管理された患者情報サーバに対し、ユーザが指定する検索基準に基づくクエリを実施、患者の基本情報（オプションとして来院または来院関連の情報）を直接取り込
むことができる方法を提供。
Audit Trail and Node Authentication (ATNA) – 基本的なセキュア・ノードの特徴を確立する。
1. ノードに必要とされるセキュリティ環境（ユーザ識別、認証、許可、アクセス制
御など）について記載、セキュリティ検討者はこれが自らの環境に合致するかどうかを決定することができる。
2. ノードにおける基本的な監査要件を定義する。
3. TLSや同等の機能を利用したノードの通信における、基本的なセキュリティ要件を定義する。
4. 基本的なセキュア・ノード、監査情報を収集する監査レポジトリ（Audit
Repository）ノード間における、監査メッセージのやり取りの特徴を定義する。
このプロファイルは、特定のドメインフレームワークが、それぞれのドメインテクニカル
フレームワークで定義されているオプションを通じ、プロファイルを拡張することができるようにデザインされている。プロファイルの拡張は、特にアクタ特有の要件など、さら-9Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

なる監査イベント報告要件を定義するために利用される。IHE放射線テクニカルフレームワークにおける、放射線監査証跡オプションが、このような拡張の事例である。
Personnel White Pages (PWP) – 基本的な職員・ユーザディレクトリ情報へのアクセスを提供する。この情報は、ヘルスケアエンタープライズ全体を通じ、医療、非医療関係のアプリケーションに幅広く活用される。
Cross-Enterprise Document Sharing (XDS) – ケアコミュニティなど、医療連合ドメイン（Clinical Affinity Domain）に属するヘルスケア提供機関が診療記録を文書の形で共有し、患者ケアにおいて協力することを可能にする。このプロファイルは
ebXML Registory標準、SOAP、HTTP、SMTPなどに基づく。またXDSをサポートするためのebXML Registoryの設定について、詳細に記述する。
1.8 セキュリティ上の影響
IHE トランザクションには、HIPPA（Health Insurance Portability And Accountability
Act）やそれに類似するプライバシー法や規制を通じて保護が求められている情報が含まれる場合が多い。IHE には以下に提示される、セキュリティやプライバシーに焦点を置いたプロファイルも少数含まれている。他のIHEプロファイルには特定のプライ
バシー保護対策などは含まれていないが、適宜セキュリティプロファイルとのグループ化が求められている。
•

Audit Trail and Node Authentication (ATNA) プロファイルは、ネットワーク上のノードが認証されることを保証する方法を特定している。

•

ATNA プロファイルは、セキュリティやプライバシーに関連するイベントを報告する
監査メッセージを明記している。

•

Enterprise User Authentication (EUA) プロファイルは、システムユーザの認証方法、アプリケーション間で認証されたユーザ情報を共有する方法について指定
している。

•

Personnel White Pages (PWP) プロファイルは、システムユーザのIDデータ保持に利用されるレポジトリを提供する。

実装者はこれらのIHEプロファイルに沿って、セキュリティニーズの一部を達成することができる。医療機関は、エンタープライズのニーズや規制に対応するため、ポリシー
やワークフローステップを導入しなければならないことは周知の事実である。
1.9 コメント
HIMSSとRSNAは、本ドキュメントやIHEイニシアチブに関するコメントを歓迎している。
コメントはhttp://ihe.rsna.org/ihetf/ 内のディスカッションサーバか、以下のアドレスに送付することができる。
- 10 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Chris Carr
Joyce Sensmeier
Director of Informatics
Director of Professional Services 820
Jorie Boulevard
230 East Ohio St., Suite 500
Oak Brook, IL 60523
Chicago, IL 60611
Email: ihe@rsna.org
Email: ihe@himss.org
1.10 著作権許可
Health Level Seven社はIHEに対してHL7標準からの表を利用することを許可している。本文書内のHL7関連の表はHealth Level Seven社が著作権を所有している。
この文書から資料を引用した場合はその旨記載すること。
1.11 IHE テクニカルフレームワーク開発と保守プロセス
IHE ITインフラテクニカルフレームワークは毎年IHE ITインフラ技術委員会により、継続的に維持・拡張が行われている。フレームワークの開発と保守プロセスは、スペックの安定性を確実にするため、いくつかの原則に沿って行われる。これはベンダ、ユーザ双方がIHE統合能力を持つシステムの指定、開発、調達を行う際、確実にフレームワークを利用することができるようにするためである。
第一の原則として、テクニカルフレームワークにおいて拡張、さらなる明確化や修正が行われた場合、旧バージョンにも遡って互換性が維持される。これは旧バージョンで定義されたIHEアクタや統合プロファイルを導入したシステムとの互換性を維持するためである。
IHE ITインフラテクニカルフレームワークは、以下の3段階のプロセスを経て、毎年開発、再発行される。
1. ITインフラテクニカル委員会は、IHE戦略・計画委員会により特定された新機
能サポートのため、現在のバージョンのテクニカルフレームワークの補足分を作成、一般からのコメントを募集する。
2. 委員会はコメント募集期間に寄せられた全てのコメントを検討し、「トライアル
導入」用に、アップデート版のテクニカルフレームワークを発行する。これは以前のサイクルで作成されたバージョンと、新たに作成された補足部分から成る。
このバージョンに基づき、ベンダは毎年実施される「IT Infrastructure
Connect-A-Thon」トライアル導入用ソフトウェア開発を行う。
3. 委員会は「Connect-A-Thon」参加者などから寄せられた変更提案を定期的に検討。「Connect-A-Thon」の60日以内に寄せられた変更提案検討の後、テクニカルフレームワークバージョン「最終版テキスト」が発行される。

- 11 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

2 IT インフラ統合プロファイル
IHE ITインフラ統合プロファイル（図2-1）は医療従事者とベンダが、医療機関における統合ニーズや情報システムの統合能力について、正確に話し合うことができる共通言語を提供する。統合プロファイルは特定の医療ニーズに見合うようデザインされた標準を導入するよう指定している。ユーザとベンダは、IHE ITインフラテクニカルフレームワークの詳細なスペックを参照することにより、どのIHE機能を求めているか、または提供しているかを明らかにすることができる。
統合プロファイルはIHEアクタとトランザクションという形で定義されている。アクタは医療機関における医療行為や運用活動に関連する情報を作成、管理、実行する情報システムまたは情報システムのコンポネントを指す（ITI TF-1 付録A参照）。トラン
ザクションは、標準に基づくメッセージを通じ、必要とされる情報のやり取りを行うイン
タラクションを指す（ITI TF-1 付録B参照）。
ベンダは製品に適切なアクタやトランザクションを実装することで統合プロファイルをサポートする。製品においては、1種類以上のアクタや統合プロファイルを実装している場合もある。

Retrieve Information
For Display (RID)

Cross-Enterprise
Document Sharing(XDS)
医療情報を医療機関の間で登録、配布、またアクセスを提供

患者の医療情報や文書をユーザに提示できるフォーマットで提供

Audit Trail & Node
Authentication (ATNA)
セキュアなドメインを作成するための集中型のプライバシー監査証跡、
ノード・ツー・ノードの認証

Patient Identifier
Cross-Referencing
For MPI (MPX)
IDドメイン間で患者IDをマッピング

Personal White Page
職員情報へのアクセス

Patient Demographics
Query
Patient Synchronized
Applications
デスクトップ上の複数のアプリケーションを同じ患者に同期化

Enterprise User
Authentication

Consistent Time
ネットワーク化されたシステム間での時間調整ユーザに対し、全てのシステムにおいて画一された名前、集中型の認証プロセスを提供

図 2-1 IHE IT インフラ統合プロファイル

2.1 統合プロファイル間の依存関係
ある統合プロファイルの導入が、他の統合プロファイルで定義されている機能実現の前提条件となっている場合、IHE統合プロファイル間に依存関係が発生する。図2-1- 12 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

はIHEインフラ統合プロファイル間の依存関係を図として示したものである。ここではプロファイル間の関連性が矢印で示されている。表2-1は、この依存関係を表の形で表している。
相互関係の中には、あるプロファイルをサポートするアクタが、他の統合プロファイルをサポートするアクタとグループ化されていることを求めているものもある。例えば、
Enterprise User Authentication (EUA) は、関連する別のアクタがConsistent Time(CT)統合プロファイルの中の「Time Client」アクタとグループ化されることを求めている。この相互関連性は、EUAアクタが正しく機能するために、一貫して正確な時間をを参照する必要があるために存在する。
表 2-1 統合プロファイルの依存関係
統合プロファイル
Retrieve Information
for Display Integration（RID）
Enterprise User
Authentication （EUA）

依存するプロファイル
無し

タイプ
無し

目的
－

Consistent Time (CT)

認証チケットの有効期限
管理実施が求められるPatient Identifier
Cross-referencing（PIX）

Consistent Time (CT)Patient Synchronized
Applications (PSA)
Consistent Time (CT)Patient Demographics
Query (PDQ)
Audit trail and Node
Authentication（ATNA）

無し

EUAを実装するアクタはTime Client アクタとグ
ループ化される
PIXを実装するアクタはTime Client アクタとグ
ループ化される
無し

無し
無し

無し
無し

―
―

Consistent Time (CT)

ATNAを実装するアクタはTime Client アクタとグループ化される
XDSアクタはSecure
Node アクタとグループ化されなければならない

監査ログのために一貫したタイムが必要となるCross-Enterprise
Document Sharing（XDS）

Audit trail and Node
Authentication（ATNA）

複数のアップデートにおける情報不一致の管理・解決が求められる―

エクスポートされるPHIの監査証跡、ノード認証と暗号転送の管理が求められる依存するプロファイルをサポートするため、アクタは依存プロファイルのほか、前提条件となっているプロファイルで要求されているトランザクションについても全て実装しなければならない。前提条件として、アクタが提供されているプロファイルのうちいずれかを選択するという場合もある。
2.2 統合プロファイル概要
本文書において、IHE統合プロファイルは以下により定義される。
••

関連するIHEアクタ
それぞれのIHEアクタにより交換されるIHEトランザクションセット

これらの要件は、統合プロファイルをサポートするそれぞれのアクタが必要とするトラ
ンザクション一覧として提示される。複数の統合プロファイルをサポートしているアクタ- 13 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

は、それぞれの統合プロファイルがサポートする全てのトランザクションをサポートする必要がある。統合プロファイルが、他の統合プロファイルに依存するものであった場合、依存する統合プロファイルが要求するトランザクションは、表に含まれない。
IHE統合プロファイルは標準遵守に関する説明ではなく、またIHEは認証団体ではない点に留意されたい。ユーザはベンダに対し、ベンダがHL7やDICOMといった標準を遵守しているかの記述を引き続き要求していく必要がある。標準を遵守していること
は、IHE統合プロファイルを利用するベンダの必要前提条件である。
また、統合プロジェクトを成功裏に進める際に重要な要件について、IHEでは言及できないものもある点に留意する。システム統合を成功裏に進めるには、混乱を最小限に抑えるためのプロジェクト計画、失敗しないための戦略、明確で、関係者の合意を得たパフォーマンス指標、明確に定義されたユーザインタフェイス要件、システム機能の制限、詳細なコスト目標、保守サポートのための計画などが必要となる。
2.2.1 Retrieve Information for Display (RID)
Retrieve Information for Display は、より良いケア提供に必要となる患者情報への、簡便で迅速なアクセスを提供する。既存の保存文書は、CDA、PDF、JPEGなど
一般に利用されているフォーマットで提供される。また医師に対し、アレルギーや現在の服薬情報、レポートのサマリーなど、個別患者に関する情報提示もサポートする。
またワークフローをユーザのスクリーン上またはアプリケーションからも補足する。他の2種類のIHEプロファイル（Enterprise User AuthenticationとPatient Identifier
Cross-referencing）とリンク付けることで、このプロファイルがカバーする範囲は医療機関における組織の枠を超えて拡大することができる。このIHE統合プロファイルにおいては、HTTP、WebServices、ITプレゼンテーションフォーマット、そしてHL7 CDA
Level1などが活用される。
2.2.2 Enterprise User Authentication (EUA)
Enterprise User Authentication (EUA) –統合プロファイルに参加する全ての機器やソフトウェアに利用できるよう、ユーザごとに単一のユーザ名を確立する方法を指す。これにより、ユーザ認証の集中管理、またユーザにシングルサインオンの迅速さと便宜性を提供することが可能となる。このプロファイルはKerberos(RFC1510)とHL7 CCOW標準（User Subject）を利用する。ユーザ認証はほとんどのアプリケーシ
ョンやデータアクセスオペレーションで必要なもので、ユーザのワークフローを一貫させる。認証管理など他のセキュリティ関連の問題については、将来別のプロファイル
を通じて対処されることになる。
2.2.3 Patient Identifier Cross-referencing (PIX)
複数の患者IDドメイン間において、患者ID相互参照を可能にする。これらの患者IDは、
ID利用システムで活用され、特定の患者について、異なるIDを利用しているソースか- 14 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

らの患者情報を関連付けさせることができる。これにより、医師は患者情報をより完全な形で閲覧することができる。
2.2.4 Patient Synchronized Applications (PSA)
Patient Synchronized Applicationsはユーザのワークステーション上の、独立した、リンクされていないアプリケーションを利用し、特定の患者のデータ閲覧をサポートする。また間違った患者データを閲覧することで起こる医療ミスの可能性を削減し、患者の安全を改善する。複数のアプリケーションにおいて患者の情報を引き出す際に、何度も患者を特定する必要性を削減する。Patient Identifier Cross-referencingプロフ
ァイルとあわせて利用することが可能であり、医師やITスタッフに均一な環境を提供する。このプロファイルは、HL7 COOW Patient Subject Context Managementを活用する。
2.2.5 Consistent Time (CT)Consistent Time プロファイルは、複数のアクタ、コンピューター間のタイムベース同期化のためのメカニズムを定義する。さまざまなインフラ、セキュリティ、情報取得関連のプロファイルは、一貫したタイムベースを複数のコンピュータ上で利用することが必要になる。Consistent Time プロファイルは、シンクロエラーを1秒以下に抑える中央値を提供する。設定オプションはより良い同期化を提供することを可能にする。
Consistent Timeプロファイルは、RFC 1305で定義されたNetwork Time Protocol(NTP)の利用を指定している。
2.2.6 Patient Demographics Query (PDQ)
複数の分散されたアプリケーションが、集中管理された患者情報サーバに対し、ユー
ザが特定する検索基準に基づくクエリを実施、患者の基本情報（オプションとして来院
または来院関連の情報）を直接取り込むことができる方法を提供。
2.2.7 Audit Trail and Node Authentication (ATNA)
基本的なセキュア・ノードの特徴を確立する。
1. ノードに必要とされるセキュリティ環境（ユーザ識別、認証、許可、アクセス制
御など）について記載、セキュリティ検討者はこれが自らの環境に合致するかどうかを決定することができる。
2. ノードにおける基本的な監査要件を定義する。
3. TLSや同等の機能を利用したノードの通信における基本的なセキュリティ要件を定義する。
4. 基本的なセキュア・ノード、監査情報を収集する監査レポジトリ（Audit
Repository）ノード間における、監査メッセージのやり取りの特徴を定義する。
- 15 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

このプロファイルは、特定のドメインフレームワークが、それぞれのドメインテクニカル
フレームワークで定義されているオプションを通じ、プロファイルを拡張することができるようにデザインされている。プロファイルの拡張は、特にアクタ特有の要件など、さらなう監査イベント報告要件を定義するために利用される。IHE放射線テクニカルフレー
ムワークにおける、放射線監査証跡オプションが、このような拡張の事例である。
2.2.8 Personnel White Pages (PWP)
Personnel White Pages Profile (PWP)は基本的な職員・ユーザディレクトリ情報へのアクセスを提供する。この情報は、ヘルスケアエンタープライズ全体を通じ、医療、
非医療関係のアプリケーションに幅広く活用されるほか、医療ワークフロー（コンタクト
情報）の強化、ユーザインターフェイスの強化（ユーザフレンドリーな名前やタイトル）、保証（デジタル証明書）などに利用することができる。PWPディレクトリーは、事前にIHEで定義されたEUA統合プロファイルで提供されるユーザIDに関連付けられる。
2.2.9 Cross-Enterprise Document Sharing (XDS)
ケアコミュニティなど、医療連合ドメイン（Clinical Affinity Domain）に属するヘルスケ
ア提供機関が診療記録を文書の形で共有し、患者ケアにおいて協力することを可能にする。このプロファイルはebXML Registory標準、SOAP、HTTP、SMTPなどに基づく。またXDSをサポートするためのebXML Registoryの設定について、詳細に記述する。
2.3 製品への実装
開発者がIHEアクタとトランザクションを実装するには複数のオプションがある。以下の3階層のオプションについて決定する。
•

システムにどのアクタを組み込むか（システムに複数のアクタを組み込むことも可能）を選択• それぞれのアクタにおいて、参加する統合プロファイルを選択• それぞれのアクタとプロファイルにおいて、どのオプションを実装するかを選択
プロファイルをサポートするには、必要とされる全てのトランザクションが実装されていなければならない（ITI TF-2のトランザクションに関する記述を参照）。
実装者は製品にどのIHEアクタ、IHE統合プロファイルとオプション含まれているかを記載する。記載に際して推奨されているフォームはITI TF-1 付録Cに示されている。
一般的に製品実装においては、ひとつかそれ以上のアクタが組み込まれることがある。2種類以上のアクタがグループ化された場合、アクタ間でそれぞれの機能をサポートするために必要な情報フローが可能となっているなど、十分な内部コミュニケーシ
ョンが行われていることが前提となっている。例えば、「Context Manager」は「Patient Identifier Cross-reference Consumer」アクタ を利用し、「Patient Identifier
Cross-reference Manager」から必要な患者IDマッピング情報を入手する。このよう- 16 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

な内部コミュニケーションのためのメカニズムそのものについては、IHEテクニカルフ
レームワークの範囲外となっている。
複数のアクタがひとつの製品実装でグループ化される場合、それぞれのアクタが開始・終了する全てのトランザクションがサポートされる（例：IHEトランザクションが、外部製品インターフェイスを通じて提供される）。
以下の例は、一般的なシステムがどのアクタをサポートするかを示したものである。
以下は必要条件ではなく、ある実例として紹介するものである。
検査室（ラボ）情報システムやレントゲン写真アーカイブ・コミュニケーションシステムといった部門別のシステムは、「Kerberized Server」アクタのほか、「Inormation
Source」アクタを含むことが考えられる。
医療レポジトリは、「Kerberized Server」アクタや「Patient Identifier Crossreference Consumer」アクタのほか、「Information Source」アクタを含むことが考えられる。
コンテクスト管理サーバは、「Patient Identifier Cross-reference Consumer」アクタのほか、「Context Management」アクタを含むことが考えられる。

- 17 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

3 Retrieve Information for Display (RID)
Retrieve Information for Display Integration Profile (RID) は、ユーザの現在のアプリケーション外に存在するが、より良いケアのために必要となる患者の治療情報（放射線部門によるラボレポートへのアクセスなど）へ、簡便で迅速なリード・オンリ
ーの形で提供する。既存の保存文書は、CDA、PDF、JPEGなど一般に利用されているフォーマットで提供される。また医師に対し、アレルギーや現在の服薬情報、レポー
トのサマリーなど、個別患者に関する情報提示もサポートする。ユーザのスクリーン
上やアプリケーション内部から、幅広い情報へのアクセスを提供することで、ワークフ
ローを補充する。
このプロファイルにおいては、「Information Source」がヘルスケア特有のセマンティッ
クスを、IHE統合プロファイルが「プレゼンテーション」フォーマットと呼ぶフォーマットに変換する役割を果たす。この結果、「Display」アクタはこの「プレゼンテーション」フォーマットを、一般的なヘルスケアセマンティックスの知識のみに基づき処理、表示することが考えられる。それぞれのフォーマットは、 (1) サーバが設けている制限、（2）クライアントが持つ表示機能制限内でのディスプレイの柔軟性（例：Generic CDA Level1
スタイルシート）の2点において異なる特徴を持つ。
「Information Source」は表示される情報とその正確さに関する全ての責任を持つ。
このプロファイルは、情報ソースに返信される文書の構造や、コンテンツに関する標
準を活用する機能を提供する。このプロファイルでHL7 Clinical Documentation
Architecture (CDA)について言及された場合、ここでは承認されているCDA Level 1のみを対象としている。さらに、情報を表示のために入手可能とするCDA Level 1のサブセットのみが利用される。
将来IHE ITインフラ・テクニカルフレームワークが拡張されることにより、さらにCDA
Release 2や他の産業標準が活用されるようになり、医療テンプレートのほか
SNOMEDやClinical LOINCなどのボキャブラリーも含まれることが期待される。
このプロファイルは、アクセス制御や情報送信におけるセキュリティを保証するための必要条件を特定するものではない。そのような方法は、Enterprise User
Authentication（セクション4参照）など、適切なセキュリティ関連の統合プロファイルを通じて実装されるべきである。付録Eは、RID統合プロファイルをEAやPIC統合プロフ
ァイルと組み合わせて利用する際のプロセスフローを示している。

3.1 アクタ・トランザクション
図 3.1-1 はRID統合プロファイルに直接関連するアクタと、アクタ間の関連するトランザクションを示している。User AuthenticationとPatient Identifier Cross-referencing- 18 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profilesに関連するために、RIDにも間接的に関連する可能性があるアクタについては、ここに示されていない。

表示のための特定情報の取り出し[ITI-11]

Display

表示のための文書の取り出し[ITI-12]

Information
Source

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

Display

Information
Source

トランザクション表示のための特定情報の取り出し[ITI-11]
表示のための文書の取り出
し[ITI-12]
表示のための特定情報の取り出し[ITI-11]
表示のための文書の取り出
し[ITI-12]オプション

Vol.2におけるセクションR

ITI TF-2:3.11

R

ITI TF-2: 3.12

R（下記参照）
R（下記参照）

ITI TF-2:3.11

ITI TF-2: 3.12

もし「Information Source」アクタが以下のオプションのうちひとつを選択している場合、トランザクション[ITI-11]が要求される(セクション3.2参照)。

- 19 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

全てのレポートのサマリー
ラボレポートのサマリー
放射線レポートのサマリー
心臓病レポートのサマリー
外科手術レポートのサマリー
集中治療レポートのサマリー
緊急レポートのサマリー
退院レポートのサマリー
処方箋リストのサマリー
アレルギーと拒否反応リストのサマリー
服薬リスト「Information Source」アクタが「Persistent Document」オプションを選択している場
合、トランザクション[ITI-12] が要求される（セクション3.2参照）。
「Display」アクタがトランザクション [ITI-11]を通じて文書を取り出すため、文書のユニ
ークIDを取得する方法として、トランザクション [ITI-12]を通じた方法、またはRID統合
プロファイル対象外の他の方法が考えられる。
3.2 Retrieve Information for Display 統合プロファイルのオプション
この統合プロファイルのために選択可能なオプションは、対応するIHEアクタとあわせ、
表3.2-1に示されている。
表 3.2-1 Retrieve Information for Display – アクタとトランザクション
アクタ
Display
Information
Source

オプションなし
Persistent Document

Vol＆セクション-ITI TF-2: 3.12

全てのレポートのサマリー（注2）
ラボレポートのサマリー（注2）
放射線レポートのサマリー（注2）
心臓病レポートのサマリー（注2）
外科手術レポートのサマリー（注2）
集中治療レポートのサマリー（注2）
緊急レポートのサマリー（注2）
退院レポートのサマリー（注2）
処方箋リストのサマリー（注2）
服薬リスト（注2）

ITI TF-2: 3.11
ITI TF-2: 3.11
ITI TF-2: 3.11
ITI TF-2: 3.11
ITI TF-2: 3.11
ITI TF-2: 3.11
ITI TF-2: 3.11
ITI TF-2: 3.11
ITI TF-2: 3.11
ITI TF-2: 3.11

注1: 服薬リストは患者に対して現在投薬されている薬品のリストも含む。これは処方箋のサマリーとは異なる。処方箋サマリーには、患者に処方されたが、現在は必ずしも投薬されているわけではない薬品情報も含まれる。
注2: 上記全てのオプションにおいて、「レポートのサマリー」は、一般的な患者情報（患者の名前など）が、日時、専門分野をはじめ、閲覧者がエントリーを選択するのに必要な情報とともに提供されているものを指す。エントリー
はRIDのためにPersistenet DocumentやRIDサマリーで定義された他のアプリケーションを参照する場合もある。
この一般的なガイドライン以外にも、特定のコンテンツは利用状況や、利用者の要望などに影響されることが考えられる。このようなサマリーは患者ケアを通じてアップデートされるため、非持続的なものとなっている。

- 20 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

3.3 Retrieve Information for Display プロセスフロー
本セクションでは、ディスプレイ可能な患者情報が、情報ソースから抽出される際のプ
ロセスと情報フローについて記述する。
以下の3つのケースに区別されている。
•

ケース1－表示のため特定の情報の取り出し：最初のケースは、ディスプレイ
アクタと、関連する人物が、患者に関連する情報をリクエストする際の事例である。「Information Source」アクタに特有の患者IDに関連した、なんらかの特定情報が発行される（ラボレポートのサマリー取り出しなど）。患者IDは、ID指定機関に確認され、一義的なものであることが前提となっている。リクエストのタイプにより、他にもフィルタリングキー（Last N Reports、日付の幅など）が利用される。「Information Source」アクタはリクエストに関連すると考えられる情報を、表示対応可能な形で提示する。この統合プロファイルでは、「Information Source」アクタが、返信する情報のコンテンツや表示を自由に編成する柔軟性を持つ。「Display」アクタはリクエストを行った人物に情報を表示するのみである。「Information Source」アクタは特定のタイプのリクエストをサポートしない時や、リクエストされた患者IDに関する記録が存在しない際、
エラーメッセージを返す。

Information
SourceDisplay

表示のための特定情報の取り出し[ITI-11]
特定情報の表示準備

患者に関する情報のリ
クエスト
情報表示

情報が見つからない場
合、または情報タイプがサポートされていない場
合表示のための特定情報の取り出し[ITI-11]

患者に関する情報のリ
クエスト
エラー表示

図 3.3-1 ケース 1: 表示のための特定情報の取り出し プロセスフロー•

ケース2－文書取り出し：ケース2は、「Display」アクタと、関連する人物が、レポートや画像、ECGストリップなど、ユニークに特定される文書をリクエストした場合である。「Information Source」アクタは、管理するオブジェクトのうち、
プレゼンテーション可能なコンテンツを提供するため、提案されたフォーマット
のひとつを利用してリクエストに返答する。詳細なプレゼンテーションと、文書- 21 -

Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

における医療データの完全性は、「Information Control Source」アクタによりコントロールされている。「Display」アクタはリクエストを行った人物に情報を表示するのみである。「Information Source」アクタはリクエストされたドキュメン
トが不明な場合、また「Display」アクタが対応するフォーマットが、リクエストされた文書を提示するのに適切でない場合、エラーメッセージを返す。

特定の情報の取り出し、文書の取り出しの2つのトランザクションの主な違いは、後者がユニークで特定が可能な永続オブジェクト（異なる時点で同じ文書インスタンスの取り出しを行うと、提示されるコンテンツに対し、同じセマンティクスが提供される）に適用される点である。特定の情報を取り出すトランザクションにおいては、この情報は常に患者IDに関連付けられているが、そのコンテンツが特定のタイプであっても（ラボのサマリー、放射線サマリー、アレルギーリストなど）、その表示は動的なものとなる（同じタイプの特定情報を異なる時点で取り出した際、異なるコンテンツが表示されることがある。例えば、アレルギーリストはリクエストが行われた間にアップデートされている可能性がある）。
注: この統合プロファイルは、患者モニタリング情報など、非常に動的である情報については対象としていない。

Information
SourceDisplay

表示のための文書取り出し [ITI-12]

文書リクエスト

特定文書の表示準備

文書コンテ
ンツ表示

文書が見つからない場合、またはフォーマットがサポートされていない場
合表示のための文書取り出し [ITI-12]

文書リクエスト
エラー表示

図 3.3-2 ケース 2: 文書取り出し プロセスフロー•

ケース3－表示のための特定情報の取り出し そして複数の文書取り出しのためのプロセスフロー：3つ目のケースは、上記の2つのケースを組み合わせ、
特定情報の取り出し、表示のための文書取り出しのトランザクションを連続したものとして関連付けるものである。これは、取り出された特定の情報に含まれる永続文書へのリンク付けや、永続文書が他の永続文書を参照することを可能にする。例えば、ユーザが最近の退院レポートをリクエストし、そのサマリーリストで参照されている特定の文書を選択する。提示されている退院レポー
トの中から、ユーザは特定の外科手術レポートを選択、外科手術レポートが取り出され、表示される。
- 22 -

Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Information
SourceDisplay

表示のための特定情報の取り出し[ITI-11]
特定情報の表示準備

ユーザが患者に関する情報をリクエスト
情報表示

選択された文書の表示準備

表示のための文書取り出し [ITI-12]

ユーザが返された情報で参照されている文書
をリクエスト
文書コンテンツ表示選択された文書の表示準備

表示のための文書取り出し [ITI-12]

ユーザが返された情報で参照されている文書
をリクエスト
文書コンテンツ表示

図 3.3-3 ケース3: 表示のための特定情報の取り出しそして複数の文書取り出しのためのプ
ロセスフロー「Display」アクタは、連続して異なるトランザクションを行うことで、複数の「Information Source」アクタと関連することもある。この統合プロファイルは、「Display」アクタが、表示のための情報取り出しリクエストを発行するアプリケーションの内容に適したトランザクション取り出しのタイプ、リクエストのタイプ、特定のキーと共に、複数のリモート「Information Source」アクタとアプリオリに設定されていることを前提としている。将来新たな統合プロファイルが、このようなサイトに特有な設定タスクに対応することが考えられる。

- 23 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

4 Enterprise User Authentication (EUA)
Enterprise User Authentication Profile (EUA) –統合プロファイルに参加する全ての機器やソフトウェアに利用できるよう、ユーザごとに単一のユーザ名を確立する
方法を定義する。これにより、ユーザ認証の集中管理、またユーザにシングルサイン
オンの迅速さと便宜性を提供することが可能となる。このプロファイルはKerberos(RFC1510)とHL7 CCOW標準（User Subject）を利用する。ユーザ認証はほとんどのアプリケーションやデータアクセスオペレーションで必要なもので、ユーザのワークフローを一貫させる。IHE EUAプロファイルは、ユーザサブジェクトやCCOW
User Subjectサフィックスを指定することで、ユーザサブジェクトのためのCCOW規格に付加価値を与えている。このプロファイルは監査証跡、アクセス制御、許可管理やPKIなどのセキュリティ機能については言及しない。将来、このEUAプロファイルを補完する形で、これらのセキュリティに関連するプロファイルが開発される。
ここでは、ひとつのセキュリティポリシーと、共通のネットワークドメインを持つ、シング
ルエンタープライズ環境であるという前提がとられている。セキュアでないドメイン、つまりインターネットへのアクセスについては興味の対象ではあるものの、このプロファ
イルでは取り扱わない。このため、遠隔治療や患者によるヘルスケアデータへの遠隔アクセスに関するアプリケーションについてもここでは取り扱わない。詳しくは付録Gを参照のこと。
ノードやマシン認証については、IHE放射線テクニカルフレームワークで示されたように、IHE基本セキュリティプロファイルで特定されており、このプロファイルには含まれない。
4.1 アクタ・トランザクション
このプロファイルに利用されるトランザクションのいくつかは、RFC 1510で定義されているKerberos v5標準を遵守している。この標準は1993年から安定して利用されているものであり、OSプラットフォームに幅広く利用されており、過去10年間の様々な攻撃にも耐え、プラットフォーム間での互換性もある。例えばSun Solaris、 Linux、 AIX、
HPUX、IBM-z/OS、 IBM-OS400、 Novell、MAC OS X、そして Microsoft
Windows 2000/XPは全て互換性を持つ形でKerberosを導入している。これ以外にも多くのベンダがKerberosをサポートしている。
このプロファイルで明記されている以上のKerberosの詳細な情報は、以下を参照の
こと。
•
•
•

RFC 1510 - http://www.ietf.org/rfc/rfc1510.txt
MITによる Kerberosホームページ http://web.mit.edu/kerberos/www/
The Moron's Guide to Kerberos
http://www.isi.edu/~brian/security/kerberos.html- 24 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles•

Microsoftによる Kerberos情報
http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/deploy/kerberos.asp

Kerberos導入は世界中で実施されている。Kerberosは、国によっては米国の法律で利用を規制している暗号を含んでいる。米国の輸出規制に関する情報はhttp://www.bxa.doc.gov/Encryptionで入手することができる。
図4.1-1はEUAプロファイルに直接関連するアクタ、そしてアクタ間のトランザクションを示している。「その他のIHEアクタ」は、このプロファイル内の、隣接するアクタとグループ化される、他の統合プロファイルのアクタを示している。認証を利用するため、間接的に関連しているアクタについては、ここには示されていない。

Kerberos
Authentication Server
ユーザ認証取得[ITI-2] ↑Kerberized Server

他の IHEアクタ↑サービスチケット取得[ITI-3]↑Kerberos化されたコミュニケーション[ITI-4]
ClientAuthentication
Agent

コンテクスト参加[ITI-5]↓
コンテクスト変更[ITI-6]↓
コンテクスト終了[ITI-7]↓

他のIHEトランザクション

他の IHEアクタ
コンテクスト参加[ITI-5]←
コンテクストフォロー[ITI-13]→
コンテクスト終了[ITI-7]←
User Context
ParticipantContext Manager

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

- 25 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

表 4.1-1 Enterprise User Authenticationプロファイル- アクタとトランザクション
アクタ

トランザクションオプション

Kerberos Authentication Server

ユーザ認証取得[ITI-2]
サービスチケット取得[ITI-3]
ユーザ認証取得[ITI-2]
サービスチケット取得[ITI-3]
コンテクスト参加[ITI-5]
コンテクスト変更[ITI-6]
コンテクスト終了[ITI-7]
Kerberos化されたコミュニ
ケーション[ITI-4]
コンテクスト参加[ITI-5]
コンテクストフォロー[ITI-13]
コンテクスト終了[ITI-7]
コンテクスト参加[ITI-5]
コンテクストフォロー[ITI-13]
コンテクスト終了[ITI-7]
コンテクスト変更[ITI-6]

R
R
R
R
O [注記 1]
O [注記 1]
O [注記 1]R

ITI TF-2: 3.2
ITI TF-2: 3.3
ITI TF-2: 3.2
ITI TF-2: 3.3
ITI TF-2: 3.5
ITI TF-2: 3.6
ITI TF-2: 3.7
ITI TF-2: 3.4

R
R
R
R
R
R
R

ITI TF-2: 3.5
ITI TF-2: 3.13
ITI TF-2: 3.7
ITI TF-2: 3.5
ITI TF-2: 3.13
ITI TF-2: 3.7
ITI TF-2: 3.6

Client Authentication Agent

Kerberized Server
User Context ParticipantContext Manager

Vol2 におけるセクション

注記 1: 「Authentication for User Context」オプションがサポートされている場合、トランザクションが必要となる。

CCOWは、EUA認証ユーザとのID共有を促進するが、ユーザの認証そのものは提供しない。「Context Manager」 と「User Context Participant」がEUAプロファイルに参加するためには、「Client Authentication Agent」が、「Authentication for User」オ
プションをサポートしている必要がある。このデザインは「User Context Participant」
に対して一貫した、エンタープライズ全体で認識されるユーザIDを提供するものであるが、Kerberosの証明書へのアクセスを定義するものではない。将来新たなIHEプロ
ファイルがこの制限について言及する可能性がある。PSAとEUAが組み合わされた
場合、「Client Authentication Agent」がキーアクターとなることに留意する。セクショ
ン4.3.2の利用事例を参照。「Client Authentication Agent」アクタと「User Context
Participant」アクタ両方を実装するアプリケーションは、いずれかのアクタが無効となっている設定についてもサポートする。
シングルユーザ環境においては、必ず一人のユーザに対し、一つの「Client
Authentication Agent」のみが存在する。マルチユーザ環境においては、ユーザごとに一つ以上の「Client Authentication Agent」があってはならない。
4.2 Enterprise User Authentication 統合プロファイルオプション
この統合プロファイルのために選択可能なオプションは、対応するアクタとあわせ、表
4.2-1に示されている。必要に応じ、オプション間の依存関係が注記に示されている。

- 26 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

表 4.2-1 Enterprise User Authentication – アクタとオプション
アクタ
Kerberos Authetication
ServerClient Authentication
Agent
Kerberized ServerContext Manager
User Context Participant

オプション
オプションは定義されていない--

Authentication for User Context

ITI TF-2: 3.6

オプションは定義されていない
オプションは定義されていない
オプションは定義されていない----

Vol＆セクション

4.3 Enterprise User Authentication プロファイルプロセスフロー
4.3.1 基本的なUser Authenticationプロセスフロー
以下の図表はEUAを利用する際の一連のイベントを表したものである。
Client Authentication
Agent

ログインまたはセッション開始

他のIHEアクタ（RID)

Kerberos
Authentication Server

他のIHEアクタ（RID)

Kerberized
Server

ユーザ認証取得[ITI-2]

内部ユーザ
認証

内部TGT管理

サービスチケット取得[ITI-3]

内部TGT確認

内部チケット管理

Kerberos化されたコミュニケーション[ITI-4]

他の IHEトランザクション

表4.3.1-1. Enterprise User Authenticationプロファイルの基本的なプロセスフロー

EUA利用時のイベントの流れは以下のとおりである。
•

ユーザがセッションを開始する。ローカルでのユーザ名／パスワード認証が行われる。これはパスワードのネットワーク上への送信を避けるため、Kerberos
によって利用されるChallenge/responseシステムに転換される。この情報は、「Ticket Granting Ticket (TGT)」入手のために利用されるユーザ認証取得ト
ランザクションの一部として利用される。

- 27 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles•

TGTは保存され、「Client Authentication Agent」アクタにより内部管理される。
TGTはユーザが認証されたことの確認の役割を果たす。

•

Kerberos化が行われたそれぞれのサービスにおいて、「Client
Authentication Agent」アクタはサービスチケット取得トランザクションを利用しサービスチケットを入手する。サービスチケットはKerberos化されたコミュニケーショントランザクションの一部として利用される。

Kerberos化されたコミュニケーションとは、他のIHEトランザクションに利用されている
HL7やDICOMなどの他のプロトコルに統合されている、Kerberosデータエクスチェン
ジを指す。Kerberos化の詳細は様々であり、Kerberos化されるプロトコルによって別々に記述される。Kerberos化は他のトランザクションに関連しているIHEアクタが、ユーザの許可やメッセージの監査の際、認証されたユーザのIDを利用することを可能にする。
「Client Authentication Agent」アクタはまたTGTやサービスチケットといった証明書の内部キャッシュの保守を行う。チケットの有効期限切れにあわせ、必要に応じてチケットの更新、有効期間中のチケットの再利用、ユーザセッション終了を受けた証明
書のキャッシュからの削除などが行われる。「Client Authentication Agent」はローカ
ル運用システムメカニズムを利用し、Kerberosの証明書を入手可能にする。
Kerberosの証明書を必要とする他のIHEアクタは、ローカル運用システムメカニズムを利用してこれらを入手することが強く奨励されている。チケット管理をサポートする
運用システムが今までに導入され、様々な運用システムのための定義づけが行われてきている。
4.3.2 ユーザが同期化されたアプリケーションにおけるユーザ認証プロセスフ
ロー
この利用例ではユーザ認証をサポートしているアプリケーションと、同じデスクトップ
上にある他のアプリケーションは、同じユーザIDと同期化され、ユーザにシングルサ
インオンを提供している。
以下の図はユーザが同期化されたアプリケーションにおけるユーザ認証におけるイベントの流れを示している。

- 28 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Client Authentication
Agent

ログインまたはセッション開始

内部TGT管理

Kerberos
Authentication Server

User Context
ParticipantContext Manager

コンテクスト参加

ユーザ認証
取得[ITI-2]

内部ユーザ
認証

コンテクスト参加[ITI-5]

コンテクスト変更[ITI-6]

ログアウトまたはセッション終了

内部TGT破棄

ユーザID
切り替え

コンテクスト変更[ITI-6]（NULL)ユーザID
をNULLに切り替え

コンテクストフォロー[ITI-13]

コンテクストフォロー[ITI-13]

図4.3.2-1 ユーザが同期化されたアプリケーションにおけるプロセスフロー

ユーザが同期化されたアプリケーションにおけるユーザ認証のイベントの流れは以下のとおりである。
•

ユーザは「Client Authenticacion Agent」を開始することでログインを開始する。

•「Client Authenticacion Agent」は、コンテクスト参加トランザクションを「Context Manager」アクタに送信することで、CCOWユーザコンテクストに参加する。この時点ではコンテクストにユーザIDは存在しない。

•

ユーザはユーザ名とパスワードを「Client Authenticacion Agent」に提供する。
これはパスワードのネットワーク上への送信を避けるため、Kerberosによって利用されるChallenge/responseシステムに転換される。この情報は、「Ticket
Granting Ticket (TGT)」入手のために利用されるユーザ認証取得トランザクションの一部として利用される。

•

TGTは保存され、「Client Authentication Agent」アクタにより内部管理される。
TGTはユーザが認証されたことの確認の役割を果たす。

•

認証されたユーザ名とともに、コンテクスト変更トランザクションが「Context
Manager」アクタに送信される。

- 29 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles•

これでユーザは「User Context Participant」にログインしたことになる。ユーザ
がセッションを終了すると、コンテクスト変更トランザクションが、NULLユーザ
名とともに「Context Manager」アクタに送信される。

•

ユーザは「User Context Participant」からログアウトする。
4.3.3 複数のアプリケーションにおける迅速なユーザの切り替え プロセスフ
ロー

医療環境における利用モデルの特徴として、複数の医師が一日に何度も、間を置かずに同じワークステーションを利用する点が挙げられる。このように、ワークステーシ
ョンが共有される環境においては、ユーザはアプリケーション内にある患者データに迅速にアクセスする必要がある。従来、ワークステーションやネットワークレベルの運用システムからのログイン、ログアウトの方法は、時間がかかりすぎ、アプリケーショ
ンが強制的に終了されることがあった。これではアプリケーションクライアントが新しい
ネットワーク接続を確立しなおさなければならないため、医師による患者データへのアクセスに時間がかかってしまう。CCOW標準、特にユーザサブジェクトは、「Enterprise Authenticator」と組み合わせることで、ユーザをアプリケーションレベル
で認証、また全てのアプリケーションをこの新しいユーザに合わせて変更する方法を提供する。
以下の図は複数のアプリケーションにおける迅速なユーザの切り替えにおけるイベン
トの一連の流れを示している。

- 30 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Client Authentication
Agent

ユーザ認証取得[ITI-2]（Kerbos認証サーバより）、
ユーザA

User Context
Participant 1

Context
Manager

User Context
Participant 2

コンテクスト参加[ITI-5]
コンテクスト変更[ITI-6]

コンテクスト参加[ITI-5]
コンテクストフォロー[ITI-13]
コンテクスト参加[ITI-5]
コンテクストフォロー[ITI-13]

ユーザAにスイッチ
ユーザ Aがエリアを離れる
ユーザ認証取得[ITI-2]（Kerbos認証サーバより）、
ユーザB

ユーザBがログアウト

コンテクスト変更[ITI-6]

コンテクストフォロー[ITI-13]

ユーザ Bにスイッチ
ユーザ Bがアプリケー
ションを終了

コンテクストフォロー[ITI-13]

ユーザBにスイッチ

コンテクスト終了[ITI-7]

コンテクスト変更[ITI-6]

コンテクストフォロー[ITI-13]

ユーザBがログオフ

図 4.3.3-1. 複数のアプリケーションにおける迅速なユーザの切り替え

プロセスフローは以下のようなものになる。
医師Aが「Client Authentication Agent」（詳細は図4.3.3-1 を参照）を含むアプリケー
ションを通じ、認証を開始する。このアクタはコンテクストセッションに参加し、医師Aがユーザとなるよう、コンテクストの変更を行う。
医師Aはここでは「User Context Participant1」と示されている「User Context
Participant」アクタを含む、医療データレポジトリアプリケーションを立ち上げる。アクタはコンテクストセッションに参加し、現在のユーザ情報を「Context Manager」から入手、医師Aをアプリケーションにログインする。
医師Aは「User Context Participant2」と示される「User Context Participant」アクタを含む心臓病アプリケーションを立ち上げる。アクタはコンテクストセッションに参加し、現在のユーザ情報を「Context Manager」から入手、医師Aをアプリケーションにログインする。
医師Aは必要な業務を行い、ワークステーションを離れる。
医師Bがワークステーションに行き、「Client Authenticaion Agent」を利用し自らを認証する。これにより、運用システムレベルにおけるログアウト、ログインにかかる時間
による遅延なしに、医師Aから医師Bへの内容の変更が行われる。医師Aが両方のア- 31 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

プリケーションからログアウトし、医師Bが続いて双方のアプリケーションにログインしたことにより、医療データレポジトリと心臓病アプリケーションはコンテクストの変更を「Context Manager」によって通知される。
医師Bは必要な業務を行い、続いて医療データレポジトリアプリケーションを閉じる。これにより、アプリケーションを終了する以前のコンテキストが残される。
医師Bは心臓病アプリケーションでの患者情報の閲覧を終え、「Client Authetication
Agent」を利用してログアウトを行う。これにより、現在のコンテクストからユーザを削除するようコンテクストの変更が行われ、ユーザは心臓病アプリケーションからログア
ウトされる。

- 32 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

5 Patient Identifier Cross-referencing (PIX)
Patient Identifier Cross-referencing Integration Profile (PIX)は様々な規模の医療機関（病院、クリニックや開業医など）をターゲットにしている。以下のインタラクシ
ョンを通じ、複数の患者IDドメインからの患者IDの相互参照をサポートする。
••

IDソースから「Patient Identifier Cross-reference Manager」への患者ID情報の送信。
クエリ・リスポンスまたはアップデート通知を通じて相互参照された患者IDリス
トへのアクセス

特定のアクタ間で上記のトランザクションを指定することで、この統合プロファイルが特定のエンタープライズポリシーや相互参照アルゴリズムを定義することはない。ひ
とつのアクタにこれらの動作を組み込むことで、この統合プロファイルは相互参照ポリシーや、エンタープライズごとに適切と見なされたアルゴリズムに対する柔軟性を保ちながら、必要な互換性を提供する。

Patient Identifier
Cross-reference Domain

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

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

患者IDフィード

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

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

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

Patient Identifier
Cross-reference
Consumer

他のIHEアクタ

患者ID相互参照

Patient Identifier
Cross-reference
Consumer

他のIHEアクタ

患者IDドメインA

患者IDドメインB

図 5-1 患者ID相互参照プロセスフロー

上記の図は、患者IDドメイン、患者ID相互参照ドメインの、2つのタイプのIDドメインを示している。

- 33 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

患者IDドメインは、シングルシステム、または共通のIDスキーム（IDと、患者へのアサイメントプロセス）と、患者IDを発行する機関を共通とする、相互接続されたシステムのセットである。さらに、患者IDドメインは以下のプロパティを持つ。
•

ドメイン特有のリクワイヤメントに沿って、どのようにIDが定義され、管理されるかを記載したポリシーのセット。

•

ドメイン内でID管理のポリシー管理を行う管理機関。

•

患者関連オブジェクトのそれぞれのインスタンスにユニークIDを割り振ったり、ID特性情報を維持する、患者IDソースシステムとして知られるシングルシステ
ム。

•「Patient Identity Source」アクタが同じ患者に複数のIDを与え、この事実を「Patient Identifier Cross-reference Manager」に通知する場合もあるが、理想的には、患者IDドメインの中において、ひとつのIDのみが患者とユニークに関連付けられているべきである。「Patient Identifier Cross-referenceManager」アクタがこれらの「重複」を含む相互参照IDリストへのリクエストにどのように返答するかについては、ITI TF-2: 3.9.4.2.2.6を参照。

•

患者ID相互参照ドメイン内でユニークな、割当権限者として知られる「IDドメイ
ン識別子（Identifier Domain Identifier）」•

患者IDドメイン内の他のシステムは、自らが属するドメインの患者IDソースシ
ステムに割当てられた患者IDソースシステムに依存する。

患者ID相互参照ドメインは、「Patient Identifier Cross-reference Manager」アクタにより認識、管理されている患者IDドメインのセットから成り立っている。「Patient
Identifier Cross-reference Manager」アクタは、異なる患者IDドメインにおいて、別名が利用されているIDリストの作成、保守、提供を行う。
患者ID相互参照ドメインは、個別のIDドメイングループ間の合意について、以下の前提を具体化する。
•

参加するドメインにおいて、いかに患者のID参照が行われるかについて記述
したポリシーについて合意済み。

•

これらのポリシーを管理するためのプロセスについて合意済み。

•

これらのプロセスとポリシーを管理する管理機関について合意済み。

これら全ての前提は、このプロファイルを成功裏に導入するにあたって重要である。この統合プロファイルは、参加する患者IDドメインにおける制約を最小限にし、また「Patient Identifier Cross-reference Manager」アクタ 内における患者ID相互参照ドメイン全体の運用制約のほとんどを集中させる。もし個別のIDドメインが上記に示さ- 34 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

れた点に合意できなければ、このプロファイルの導入は期待していた結果をもたらさない可能性もある。
「Patient Cross-reference Manager」アクタは、「Identity Source」アクタからそこに提供されるID情報の質改善に対する責任は無い。「Identity Source」アクタは「Patient Identifier Cross-reference Manager」 に高品質のデータを提供する義務があることが前提となっている。例えば、「Patient Identifier Cross-referenceManager」アクタは、患者の基本情報を提供する、唯一の情報ソースであるべき責任は持たない。ここでは、患者の個人情報の質と管理、IDの完全性についての責任はそれぞれの患者IDドメイン（「Source」アクタ）に残すことを意図している。レポートを受信し、複数のPIXドメインに表示する際、これらのレポートやディスプレイに一貫しない
名前が含まれることは避けることができない。
「Patient Identifier Cross-reference Consumer」は、相互参照患者IDのためのクエリを利用するか、相互参照の変更通知とクエリトランザクションの両方を利用する可能性がある。通知を利用するにあたり、「Patient Identifier Cross-reference
Consumer」はまた、「Patient Identifier Cross-reference Consumer」が「Patient
Identifier Cross-reference Manager」と同期化していないという状況を言及するため、
PIXクエリトランザクションを利用することもある。この統合プロファイルはPIXクエリト
ランザクション(ITI TF-2: 3.9)を利用する際のポリシーを特定するものではない。
この統合プロファイルと「enterprise master patient index (eMPI)」 との関連についての議論は、セクション5.4を参照のこと。
5.1 アクタ・トランザクション
図5.1-1はPatient Identifier Cross-referencingプロファイルに直接関連するアクタ、そしてアクタ間のトランザクションを示している。他の関連するプロファイルに参加しているため、間接的に関連している他のアクタはここでは示されていない。

Patient Identifier
Cross-reference
Consumer

Patient Identity Source↓PIXクエリ[ITI-9]↑PIXアップデート通知[ITI-10]

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

Patient Identifier
Cross-referenceManager

図 5.1-1 「Patient Identifier Cross-referencing」アクタ図表- 35 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

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

トランザクション

オプション

Patient Identity
Source

患者 ID フィード[ITI8]

R

Vol2におけるセクション
ITI TF-2:3.8

Patient Identifier
Cross-reference
Consumer

PIX クエリ[ITI-9]
PIX アップデート通知[ITI-10]

RO

ITI TF-2:3.9
ITI TF-2:3.10

Patient Identifier
Cross-referenceManager

患者IDフィード[ITI-8]
PIXクエリ[ITI-9]

R
R

ITI TF-2:3.8
ITI TF-2:3.9

PIXアップデート通知[ITI-10]R

ITI TF-2:3.10

5.2 Patient Identifier Cross-referencing 統合プロファイルのオプション
この統合プロファイルのために選択可能なオプションは、対応するアクタとあわせ、表5.2-1に示されている。必要に応じ、オプション間の依存関係が注記に示されている。
表5.2-1 Patient Identifier Cross-referencing – アクタとオプション
アクタ
Patient Identity Source
Patient Identifier Crossreference Manager
Patient Identifier Crossreference Consumer

オプション
オプションは定義されていない
オプションは定義されていない---

PIXアップデート通知

ITI TF-2: 3.10

Vol＆セクション

5.3 Patient Identifier Cross-referencing プロセスフロー
以下のセクションはこのプロファイルが取り組む利用事例について述べる。
5.3.1 利用例: 単独の施設・エンタープライズ内の複数IDドメイン
総合病院のICUに勤務する医師は、集中治療システムの患者チャートを閲覧、また病院のメインラボシステムに保存されているラボレポートに含まれている、患者のグ
ルコースレベルを閲覧またはモニターしたいと考えている。集中治療システムは内部で作成される独自の患者IDを、病院のメインADTシステムで作成され、ラボシステム
で患者IDとして利用されている、患者の医療記録番号（MRN）にマップする必要があ- 36 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

る。この場合、集中治療システムは、独自の患者ID識別を行っているため、基本的に他の病院システムとは異なるIDドメイン内にある。
このシナリオでは、病院のメインADTシステム（患者IDソースの役割を果たしている）
は患者IDフィード（患者のMRNをIDとして利用）を「Patient Identifier Crossreference Manager」に提供している。同様に、集中治療システムもまた、患者識別
子として内部で作成された患者IDを患者IDフィードとして「Patient Identifier Crossreference Manager」に提供、独自の「IDドメイン識別子」を提供している。
「Patient Identifier Cross-reference Manager」が患者識IDフィードトランザクションを受信すると、内部ロジックを利用し、受信したフィードトランザクションに含まれている補完的情報に基づき、同一人物としてリンク付けられる患者IDが無いかを見極める。
相互参照プロセス（アルゴリズム、人的決定など）は「Patient Identifier Crossreference Manager」内部で実施され、IHEの対象外となっている（相互参照ロジックの境界についての詳細な記述は、ITI TF-2: 3.9.4.2.2.6を参照）。
集中治療システムは、同システムが患者ID「MC-123」として認識している患者に関連するラボ情報をリクエストする。ドメイン識別子と割当権限者を含む独自の患者ID（MC-123）を利用し、ラボシステムからラボレポートをリクエストする。リクエストを受信すると、ラボシステムはこのリクエストが独自のIDドメイン外（ADTドメイン）の患者のためのものかどうかを特定する。ラボシステムは、（集中治療ドメイン内における）患者IDが「MC-125」に対応している患者IDエイリアスのリストを、「Patient Identifier
Cross-reference Manager」からリクエストする。この結果、この患者はADTドメイン
内の医療記録番号「007」とリンクされ、「Patient Identifier Cross-reference
Manger」は、ラボシステムが患者のラボレポートを取り出し、集中治療システムに転送できるようにするため、このリストをラボシステムに返送する。図5.3-1 はこのプロセ
スフローを示したものである。

- 37 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Patient Identity
Display
Source（集中治療ドメイン） （集中治療ドメイン）

Patient Identifier
Cross-referenceManager

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

集中治療
ID ドメイン
内のADT
フィード

Patient Identifier Crossreference
Patient Identity Consumer/Information
Source（ADTドメ Source（ラボシステム－
イン）
ADTドメイン）

相互参照ロ
ジック適用
患者IDフィード[ITI-8]

相互参照ロ
ジック適用

ADT ID ドメ
イン内のADTフィード表示のための文書取り出し[ITI-12] –リクエスト
PIXクエリ[ITI-9]

表示のための文書取り出し[ITI-12] –リスポンス

ラボレポート
選択にローカルで知られる
ID 利用

図 5.3-1. PIXプロファイルにおける施設内プロセスの複数IDドメイン
注記: 表示のための文書取り出しトランザクションにおけるリクエストとリスポンスの部分は、このプロファイルの一部ではないが、ここでは図解のために含まれている。

5.3.2 利用例: 連携するエンタープライズ間の複数のIDドメイン
ヘルスケアエンタプライズは、それぞれ異なる病院情報システムを利用した、独自の患者登録プロセスを持つ、2つの病院の統合により設立される。患者が一方の病院で治療を受けた際、他の病院で管理されている電子記録へのアクセスが必要となる。
以下のケースはこのようなシナリオを示している。
病院AとBは統合（Consolidate）され、2つの病院のIDリンクを維持する、ひとつの「Patient Identifier Cross-reference Manager」が存在する。それぞれの病院は患者登録を行うための異なるHISを持っているが、心臓病情報システムについては統合されている。心臓病システムは、相互参照が行われると、患者ID通知を受信するよう、「Patient Identifier Cross-reference Consumer」に設定されている。
患者は登録され、病院Aでなんらかのストレステストが実施される。心臓病情報システ
ムは、もし過去にその患者の心臓病関連のレポートがあったかどうかを確認するため、「Patient Identifier Cross-reference Manager」にクエリ送信を行い、患者のIDエイリ
アス候補のリストを受信する。患者IDエイリアスは見つからなかった。しばらく後、同じ患者は病院Bに行き、第二のストレステストを実施。患者は病院BのHISを通じて登録され、HISはそのID情報を「Patient Identifier Cross-reference Manager」に送信する。「Patient Identifier Cross-reference Manager」は、この患者が以前に病院Aで登録した同一の患者であるということを特定する。心臓病情報システムが通知を受信で- 38 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

きるよう、事前に「Patient Identifier Cross-reference Manager」を通じて設定が行われており、このため心臓病システムに患者IDエイリアスが存在するという通知が送信される。この通知は、複数のIDドメインを認識するシステムが、IDドメインで起こる患者ID変更に対する同期化を維持するために行われる。
図5.3-2 はこの事例のプロセスフローを示している。
Patient Identity
Source（ドメインA）

Patient Identifier Crossreference Consumer（ドメインAの心臓病情報シ
ステム）

Patient Identifier
Cross-referenceManager

Patient Identity
Source（ドメインB）

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

ID ドメイン
内のADT
フィード

PIXクエリ[ITI-9]

相互参照ロ
ジック適用

患者IDフィード
[ITI-8]PIXアップデート
通知[ITI-10]

リンクされ
た患者の内
部データ統
合のための
ロジック

相互参照ロ
ジックを適
用、通知に
興味を持つ
消費者の
特定

図 5.3-2 PIXプロファイルにおける連携するエンタープライズ間の複数のIDドメイン プロセスフロー
注記: 最初の患者IDフィードトランザクションの後には相互参照活動は行われないため、PIX アップデート通知は最初の患者IDフィードには送信されない。

5.4 PIX 統合プロファイルと eMPI との関係
PIX統合プロファイルは、同じ患者に関連付けられた患者IDの相互参照アプローチを利用することで、分散する患者IDドメインの統合を可能にする。このセクションでは、
このアプローチがいかに、マスター患者ID（MPI）やエンタープライズMPI（eMPI)シス
テムを確立したいという環境に適合するかについて述べる。eMPIはPIX統合プロファ
イル実装のバリエーションと捉えられる場合もある。
- 39 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

MPIのコンセプトは幅広いものであるが、多くの場合マスター患者IDドメインの作成と関連付けられる。このようなマスタードメインはより幅広く適用が可能、あるいはマスタ
ードメインに含まれている他の患者IDドメインと比べ、より「エンタープライズレベル」であると捉えられている。このように、患者IDドメインを「マスター患者IDドメイン」に階層的に含むことは、様々なドメイン内の患者IDが、マスタードメイン内の患者IDに相互参照される形となり、患者相互参照の一つの事例と考えることができる。想定される2種類の設定について、以下の図5.4-1に示されている。
マスター患者インデックス

Patient Identity
Cross-referenceManager

Master （C) Patient
Identity Source
マスター患者
インデックス

患者IDドメインC（マスタードメイン）

患者IDドメインA

Master （C) Patient
Identity Source

Patient Identity
Cross-referenceManager

患者IDドメインC（マスタードメイン）

患者IDドメインB

患者IDドメインA

患者IDドメインB

3相互参照ドメインとして示される同様の設定

マスター患者インデックスには2件のドメインが含まれる

図5.4-1 PIX プロファイルとeMPI との関係

上記の図5.4-1は、典型的なMPIアプローチにおけるマスター患者IDドメイン（ドメインC）が、相互参照アプローチで考えた場合、患者IDドメインのひとつに過ぎないということを示している。マスタードメインにクリニカルデータレポジトリなどのエンタープライ
ズワイドのシステムを設置するという決定は、単に設定に関する選択であるといえる。
さらに、このような設定においては、患者ドメインAはドメインAの患者IDの管理を行うだけでなく、ドメインCのIDも認識していることを前提としている場合がある。Patient
Identifier Cross-reference統合プロファイルにおいては、特定のシステムが複数のドメイン間で運営されるようなデザイン、設定が行われることは、設定における選択である。このため、MPI（楕円で示されている）と呼ばれるエンティティは、実際は「Patient
Identity Source」アクタ（ADT）とPatient Identifier Cross-reference Managerの組み合わせである場合が多い。
PIX統合プロファイルは明確なMPIを設置するような環境とも共存することができ、よりスケーラブルなアプローチを提供する。特に、他のドメインを含むようなマスタードメ
インの作成が必要ではないところ（例：ドメインのシンプルな連合であり、どのドメインも実際のマスターではない）において、他にも様々な設定を設置することができる。
- 40 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles- 41 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

6 Patient Synchronized Applications (PSA)
Patient Synchronized Applications プロファイル (PSA)は、ワークステーションデ
スクトップ上で複数のアプリケーションを利用しているユーザが、単一の患者を選択することを可能にする。この統合プロファイルにおいては、アプリケーションのいずれかが患者を選択すると、他の全てのアプリケーションが同じ患者にチューン・インするようになる。医師は、患者を選択するのに一番使い慣れているアプリケーションを利用することができ、またその選択を、続いて利用するアプリケーションにも反映させることができる。
このプロファイルは、特にHL7 CCOW patient subject context managementを活用する。このプロファイルの焦点はCCOW Patient subjectの共有のみである。IHE
PSAプロファイルは、PSAをサポートするアプリケーション間における一貫性を保証するため、さらに患者IDに制限を与え、またPSAをサポートするアプリケーション間における一貫した動作のためのガイダンスを与え、さらにエンタープライズにおいて「Patient Identifier Cross-reference Consumer」アクタとの一貫したインタラクションを保証することで、CCOW patient subjectの仕様に付加価値を与える。
ユーザ認証を必要とするアプリケーションに関しては、IHEはCCOW Authentication
Repositoryなどの他の方法とは反対に、Enterprise User Authenticationプロファイ
ルの実装を推奨する。ITI -1: 4において、Enterprise User Authenticationプロファイ
ルとCCOW user subjectの利用が記載されている。
6.1 アクタ・トランザクション

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

コンテクスト参加[ITI-5] →Patient Context
ParticipantActor

コンテクスト変更[ITI-6] →←コンテクストフォロー[ITI-13]

Context Manager Actor

コンテクスト終了[ITI-7] →図 6.1-1 Patient Synchronized Applications プロファイルアクタ図表- 42 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

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

「Patient Context Participant」アクタははITI TF-2で定義されたように、表6.1-1で特定された4つ全てのトランザクションをサポートする。「Patient Context Participant」ア
クタは全ての患者コンテクストの変更に対応する。このアクタは、アプリケーションに
患者選択機能がある場合、患者コンテクストを設定する。
「IHE Context Manager」アクタはコンテクスト管理レジストリや患者マッピングエージ
ェントなどの他のコンポネントを含むこともあるなど、CCOW context manager以上に様々な機能を包括する。
「Context Manager」アクタはPatient Identity Cross-Referencingプロファイルの「Patient Identifier Cross-Referencing (PIX) Consumer」アクタとグループ化されることもある。このケースの場合、「Context Manager」アクタの追加機能については、
ITI TF-2：付録Dを参照のこと。
表 6.1-1 Patient Synchronized Applications 統合プロファイル- アクタとトランザクション
アクタ

トランザクション

オプション

Patient Context
Participant

コンテクスト参加[ITI-5]
コンテクスト変更[ITI6]
コンテクスト終了[ITI7]
コンテクストフォロー[ITI-13]
コンテクスト参加[ITI-5]
コンテクスト変更[ITI6]
コンテクスト終了[ITI7]
コンテクストフォロー[ITI-13]R

Vol2におけるセクション
ITI TF-2:3.5

R

ITI TF-2:3.6

R

ITI TF-2:3.7

R

ITI TF-2:3.13

R

ITI TF-2:3.5

R

ITI TF-2:3.6

R

ITI TF-2:3.7

R

ITI TF-2:3.13

Context Manager

6.2 Patient Synchronized Applications 統合プロファイルオプション
この統合プロファイルのために選択可能なオプションは、対応するアクタとあわせ、表
6.2-1に示されている。必要に応じ、オプション間の依存関係が注記に示されている。
表 6.2-1 Patient Synchronized Applications – アクタとオプション
アクタ
Patient Context
Participant

オプション
オプションは定義されていない

Vol＆セクション--- 43 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Context Manager

オプションは定義されていない--

6.3 Patient Synchronized Applications 統合プロファイル プロセスフロー
Patient Synchronized Applications統合プロファイルはユーザが同時複数のアプリ
ケーションを利用する必要がある際に、最大限の価値を提供する。 セクション6.3.1で示されたプロセスフローでは、アプリケーションがPSAプロファイルのみに参加しているケースを示している。ITI TF-1:付録EはPSAと、Enterprise User Authentication（EUA）プロファイル両方が設置された場合を示している。
6.3.1 利用例: 簡単な患者切り替え
PSAプロファイルがEUAプロファイルとグループ化されていない場合、患者IDのみがコンテクストに伝えられる。この利用例は、アプリケーションに必要とされていなかった
り、他の方法で行われる可能性などを考え、ユーザ認証方法を明確には特定していない。この利用例では、両方のアプリケーションが同じ患者IDドメインを共有している。
この利用例のプロセスフローは以下のとおりである。
医師が、アクタ「Patient Context Participant 1」と示される医療データレポジトリアプ
リケーションを立ち上げる。医療データレポジトリアプリケーションは、医師のデスクトップにおけるコンテクストセッションに参加する。
医師は医療データレポジトリアプリケーションで患者Aを選択する。医療データレポジ
トリアプリケーションは、コンテクストに患者AのためのIDをセットする。
医師はアクタ「Patient Context Participant 2」と示されている、心臓病アプリケーショ
ンを立ち上げる。心臓病アプリケーションはコンテクストセッションに参加し、コンテク
ストから患者AのIDを取得、表示を患者Aに調整する。
医師は心臓病アプリケーションで患者Bを選択する。このアクションは心臓病アプリケーション（Patient Context Participant 2）によるコンテクスト変更トランザクションを開始することになる。他のアプリケーションはコンテクストフォロートランザクションを通じて参加、これにより医療データレポジトリアプリケーション（Patient Context
Participant 1）に選択された患者が表示される。
医師は医療データレポジトリアプリケーションを閉じる。医療データレポジトリアプリケーションはアプリケーションを終了する前に、コンテクストを終了する。
医師は心臓病アプリケーションを閉じる。心臓病アプリケーションはアプリケーションが終了する前に、コンテクストを終了する。
図6.3-1はこの利用例のプロセスフローを示したものである。

- 44 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Patient Context
Participant 1 （医療データレポジトリ）

Context Manager

Patient Context
Participant 2 （心臓科）

コンテクスト参加[ITI-5]

ユーザは患者 A
選択

コンテクスト変更[ITI-6]

コンテクスト参加[ITI-5]
コンテクストフォロー[ITI-13]

コンテクストフォロー[ITI13]

ユーザがアプリケーションを終了

アプリケーションが患者Aに合わせる

コンテクスト変更[ITI-6]

ユーザが患者 B を選択

コンテクスト終了[ITI-7]

ユーザがアプリケーショ
ンを終了

コンテクスト終了[ITI-7]

図 6.3-1. シンプルな患者切り替えプロセスフロー- 45 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

7 Consistent Time (CT)Consistent Time 統合プロファイル(CT) はネットワーク上の多くのコンピューターのシステムクロックとタイムスタンプの正しい同期化を保証する方法を提供する。このプ
ロファイルは、誤差中央値が1秒以下の同期化を指定している。これはほとんどの利
用目的において十分な数値である。
Consistent Time統合プロファイルは複数のアクタとコンピューター間のタイムベースを同期化するメカニズムを定義する。複数のインフラ、セキュリティ、情報収集プロファ
イルが、複数のコンピューターにおける一貫したタイムベースを必要とする。
Consistent TimeプロファイルはRFC 1305で定義されたNetwork Time Protocol(NPT)の利用を求めている。タイムサーバがより上層のタイムサーバーから時間を入手することを目的に、タイムクライアントとグループ化されている場合、タイムクライア
ントはNTPを利用する。タイムサーバとグループ化されていないタイムクライアントでは、SNTPが利用可能な場合もある。
このプロファイルは以前はRadiology Basic Securityプロファイルの一部であったが、他のインフラが利用する様々なバラエティがある。
注記：このプロファイルは、IHE 放射線テクニカルフレームワークのBasic Securityフレームワークに該当するものである。これは複数の放射線システムに必要とされている。これはまた、IHE ITインフラの複数のプロファイルや、
また心臓病テクニカルフレームワークでも必要とされるものであることから、IHE 放射線からIHE ITインフラに移動されている。リクワイヤメントに関する変更は無いため、Radiology Basic Secure NodeやTime Serverでサポートされていたアクタへの変更も必要無い。放射線テクニカルフレームワークにおけるITインフラのためのMaintain
Time [RAD TF-3: 4.33] トランザクションも同様である。

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

Time Server

時間維持[ITI-1] ↑Time Client

図 7.1-1: Consistent Time プロファイルアクタ図表- 46 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

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

トランザクション

オプション

Time Server

時間維持[ITI-1]

R

Vol2におけるセクション
ITI TF-2:7.1

Time Client

時間維持[ITI-1]

R

ITI TF-2:7.1

7.2 Consistent Time 統合オプション
この統合プロファイルのために選択可能なオプションは、対応するアクタとあわせ、表7.2-1に示されている。
表 7.2-1: Consistent Time – アクタとオプション
アクタ
Time Server
Time Client

オプション
セキュアNTP
SNTP，セキュアNTP

Vol＆セクション
ITI TF-2: 3.1.4-1
ITI TF-2: 3.1.4-1

7.3 Consistent Time プロセスフロー
このセクションは、Consistent Timeプロファイルに関する典型的なフローについて述べる。図7.3-1においては、タイムクライアントBとタイムサーバBがグループ化されている。クライアントとサーバがグループ化されている場合、内部のコミュニケーションメ
カニズムを活用して時間の同期化を行う。

- 47 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Time Client B
Time Server A
Time Server B

Time Client C

時間維持[ITI-1]

時間維持[ITI-1]
時間維持[ITI-1]

図 7.3-1 Consistent Time プロファイルにおける基本的なプロセスフロー

タイムクライアントBはタイムサーバAとの時間同期化を維持する。タイムサーバBはタイムクライアントBと内部で同期化されている。タイムクライアントCはタイムサーバBとの間での同期化を維持する。
NTPプロトコルはこのような形の縦続型同期化と共に、同期化のためのネットワーク
タイムサービスを提供するようデザインされている。どれだけの正確さを達成できるか
は、ネットワークハードウェアとトポロジーの詳細と、コンピュータハードウェアとソフト
ウェア実装の詳細による。タイムサーバとタイムクライアントは同期化の縦続とネット
ワークトラフィック削減のためにグループ化される。

- 48 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

8

Patient Demographics Query (PDQ)
8.1 アクタ・トランザクション

図8.1-1は直接Patient Demographics Query統合プロファイルに関連するアクタと、アクタ間で関連するトランザクションを示している。Patient ID Cross-refencingなどに参加しているために、間接的に関連している他のアクタはここでは示されていない。

Patient Demographics
Supplier

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

Patient Demographics
Consumer

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

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

トランザクション

オプション

Patient
Demographics
Consumer

患者基本情報クエリ

R

Vol2におけるセクション
ITI TF-2:3.21

患者基本情報と来院
情報クエリ
患者基本情報クエリ

O

ITI TF-2:3.22

R

ITI TF-2:3.21

患者基本情報と来院
情報クエリ

O

ITI TF-2:3.22

Patient
Demographics
Supplier

8.2 Patient Demographics Query 統合プロファイルオプション
この統合プロファイルのために選択可能なオプションは、対応するアクタとあわせ、表8.2-1に示されている。必要に応じ、オプション間の依存関係が注記に示されている。
- 49 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

表 8.2-1 Patient Demographics Query - アクタとオプション
アクタ
Patient Demographics
Consumer
Patient Demographics
Supplierオプション
患者基本情報と来院情報クエリ

Vol＆セクション
ITI TF-2: 3.22

患者基本情報と来院情報クエリ

ITI TF-2: 3.22

8.3 Patient Demographics Query プロセスフロー「Patient Demographics Supplier」は以下の機能を実行する。
•

患者登録情報を受信、エンタープライズ内の他のシステム（ADT患者登録シ
ステムなど）からのメッセージをアップデートする。これは異なる患者IDドメインを表す場合、表さない場合がある。「Patient Demographics Supplier」がアップデートされた患者の基本情報を受信する方法は、このプロファイルでは扱われない。

•

情報を問い合わせるクエリに返答を行う。

患者の基本情報を入手するための特定の方法はこのプロファイルの範疇を超えるものである。「Patient Demographics Supplier」が最新の基本情報を所有していることは前提条件となっている。最新の基本情報を入手する方法のひとつとしては、「Patient Demographic Supplier」を最新の基本情報の保守または受信している「Order Filler」などの他のIHEアクタとグループ化することが挙げられる。
全てのケースにおいて、「Patient Demographics Supplier」は「Patient
Demographics Consumer」から「Patient Demographics Query」または「Patient
Demographics and Visit Query」リクエストを受信し、クエリメッセージが送信された
アプリケーションに関連付けられている単一のドメインから、基本情報（必要に応じて、来院情報）を返信する。ID情報は複数または単一のドメインから返信されることもある。
アーキテクチャ関連の問題については、「マルチドメイン環境におけるPatient Data
Query (PDQ) の利用」セクション (ITI TF-2: 付録 M) を参照。
事例1: ベッドサイドにおける患者情報入力
入院患者にベッドが割り当てられる。患者が正しいID情報を提供できる場合と出来ない場合がある。看護師は、割り当てられたベッドと患者情報を関連付けるために、ベッドサイドに設置された機器を利用し、患者のID情報を入力する必要がある。機器は患者選択リストのためのデータを提供する「Patient
Demographics Supplier」に対しクエリを発行する。看護師によって入力される検索基準は、以下のものが挙げられる。
•

患者のフルネームまたは一部（患者記録に印刷してあるか、患者により申告される）- 50 -

Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles•

患者ID（印刷されたバーコード、ベッドサイドの表、カルテなどから入手されることが考えられる）•IDの一部入力スキャン•

誕生日/ 年齢層•

ベッドID

システムはMRN、フルネーム、年齢、性別、部屋・ベッド、入院日などが示されたリストを返信、看護師に提示する。看護師はそこからベッドサイド機器アプリ
ケーションに入力する的確な情報を選択する。
利用例2: 開業医オフィスでの患者ID情報入力
患者は開業医のオフィスに初めて訪れる。看護師は患者の情報を登録する必要があり、その際経営管理情報システム（PMIS）に患者の基本情報を入力する。開業医のオフィスは病院エンタープライズの中央患者レジストリに接続されている。看護師は、検索基準として患者の基本情報を指定し、患者クエリリ
クエストを中央患者レジストリに送信する。返信された患者リストから、看護師
は、PMISに入力するため、病院における患者IDを含む、患者の適切な情報を選択する（PMISは中央患者レジストリとは異なる患者IDドメインを利用していることに注意する）。
PMISは独自の患者IDを利用しているが、病院の医療レポジトリから情報を取り出すため、このIDと、患者選択リスト（患者IDドメインを共有）に含まれる患者IDを調整する。
利用例3: 複数の患者IDドメインを持つエンタープライズにおける患者基本情報クエリ
ラボにおける検査の際に患者を特定するため、ラボのテクニシャンは基本的なデータ（患者名など）をラボアプリケーションに入力し、「Patient
Demographics Supplier」にクエリを行う。またアプリケーションは結果送信のため、エンタープライズ内の別の患者IDドメインからの患者IDも必要とすることから、アプリケーションはクエリの応答において、他のドメインから患者IDを受信するよう設定される。

- 51 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Patient
Demographics
Consumer

Patient
Demographics
Supplier

患者基本情報クエリ[ITI-21]
患者基本情報リスポンス[ITI-21]

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

患者基本情報と来院情報リスポンス[ITI-22]

図 8.2-1. Patient Demographics Query プロファイルの基本的なプロセスフロー

8.3.1 他のIHEワークフロープロファイルとPDQの利用「Patient Demographics Supplier」アクタが、患者情報の調整を行う他のIHEプロフ
ァイル内のアクタ（Radiology PIRなど）とグループ化されている場合、「PDQ
Supplier」アクタはPDQクエリに返答するため、最新の情報を利用する。さらに、Patient Demographics Queryプロファイルは、他のIHEプロファイルと組み合わせ、総体的なワークフローの役割を果たすこともある。
8.3.2 Supplierにおけるデータ設定
単一の患者IDドメインの患者基本情報を持つ「Patient Demographics Supplier」アクタはドメイン内に調和をもたらす。
「Patient Demographics Supplier」アクタが複数の患者IDドメインの基本情報を持つ
場合、「Patient Demographics Supplier」アクタはMSH-5-Receiving Application、
MSH-6-Receiving Facilityに関連するドメインに対して情報を返信する。このケースの更なる考察とサポートするアーキテクチャの提示については、「マルチドメイン環境
におけるPatient Data Query (PDQ) の利用」セクション(ITI TF-2: 付録 M) を参照。

- 52 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

9 Audit Trail and Node Authentication (ATNA)
Audit Trail and Node Authentication (ATNA) 統合プロファイルはエンタープライズ
が持つセキュリティポリシーや手順とあわせ、患者情報の機密性、データの完全性とユーザのアカウンタビリティを提供するセキュリティ対策を確立する。Audit Trail andNode Authentication統合プロファイルの目標は以下のとおりである。
•

ユーザアカウンタビリティ（監査証跡）
医療機関のセキュリティ担当者が監査を実施、セキュアドメインのポリシー遵守状況の見極め、遵守が行われていない動作に関するインスタンスの探知、保護された医療情報（PHI）に対する不適切な作成、アクセス、変更、削除の探知を可能にする。PHIは患者特定を可能にする記録（例：登録、オーダー、
検査や処置、レポート、画像、表示状況)と見なされている。これらの情報はユーザがアクセスしたり、システム間で交換されることが考えられる。これはセキュアドメインの中の全てのセキュアなノードからエクスポート、インポートされた情報も含む。
監査証跡は、以下のような質問に答えられるような情報を含む。
•
•
•
•

•

ユーザの一部に対して：どの患者のPHIにアクセスされたか？
患者PHIの一部に対して：どのユーザがアクセスしたか？
どのようなユーザ認証失敗がレポートされたか？
どのノード認証失敗がレポートされたか？

アクセス制御ATNAは、ノード間のネットワークアクセスの制限、許可されたユーザのみにそれぞれのノードアクセスを制限することで、アクセス制御に貢献する。セキュアドメインにおけるセキュアノード間のネットワークコミュニケーションは、そのドメ
インの他のセキュアノードのみに制限されている。セキュアノードは、ローカル
認証とアクセス制御ポリシーに指定されたとおり、許可されたユーザのみにア
クセスを制限する。

•

中央監査記録レポジトリ
セキュリティ要件を満たすための最もシンプルな方法として、中央監査記録レ
ポジトリを提供する。改ざんを防ぎ、各部門の監査を行いやすいよう、可能であれば、全てのIHEアクタから、監査記録が監査記録レポジトリに即時転送されることが求められているが、接続されていないノードは、セキュアドメインネットワークに再接続する際に転送できるよう、監査データを保存しておくこともできる。

•

PHIデータの完全性- 53 -

Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

作成、変更、削除やロケーションといったPHI情報のライフサイクルをトラッキ
ングし、プロセス実施中のデータ完全性を可能にする。
ATNAの特徴
Audit Trail and Node Authentication統合プロファイルの主要な特徴は以下のとおりである。
•

ユーザの認証。このプロファイルにおいて、ユーザ認証にはいかなる技術が利用されても良い。IHEはATNAプロファイルに利用されるユーザ認証技術について特に制限していない。

•

監査記録作成。このプロファイルは不適切なアクティビティ探知をモニターする
ため、PHIの利用に関連するイベントが記録され、レポジトリに転送されることを求めている。

•

コミュニケーション時のノード認証。このプロファイルでは、PHIを転送する全てのデータコミュニケーションにおいて、ノードが許可・認証されたものであることを求めている。ユーザIDは送信されない。ユーザ情報はそれぞれのノードにおいて、ユーザ認証と、それぞれのノードで選択されたアクセス制御を実施することで、ユーザのアカウンタビリティが保証される。

ATNAによるセキュリティに関する前提条件
前提とされている条件は以下のとおりである。
•

セキュアドメインのメンバーである全てのシステムは、ATNAプロファイルの「Secure Node」アクタを導入している。ATNAプロファイルはドメインセ
キュリティ担当者が管理するセキュアドメイン作成のため、セキュアノード
間のトランザクションを定義する。

•

セキュアノード上の全てのアプリケーションは、IHEアクタかどうかにかかわらず、ATNAリクワイヤメントを遵守する。これはIHEで指定され、IHEアクタに実施されるものだけでなく、直接PHIを作成、アクセス、アップデート、
削除するなど、ITに支援された全てのアクティビティに適用される。

•

IHEはIHEヘルスケアアプリケーション関連のシステムにおけるセキュリテ
ィ要件のみに言及する。ネットワーク攻撃やウィルス感染対策などの他のセキュリティリ要件に関しては対象外である。監査証跡メカニズムの主要な目的は、IHEトランザクションではなく、PHIへのデータアクセスを追跡することである。

•

IHEはデータ転送中に暗号化を指定しない。ほとんどの病院のネットワー
クは物理的、プロセス的メカニズムを通じて、適切なセキュリティを提供し- 54 -

Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profilesている。暗号化することでさらにパフォーマンスに負担を与えることは、これらのネットワークにおいて理にかなったものとはいえない。 このプロファ
イルでは、許可されたセキュリティノード間のみでコミュニケーションが行われることを保証するため、セキュアノード間の全てのコミュニケーションに
TLSセキュリティ交渉メカニズムの利用を指定している。これは、両方のノードが暗号化のリクエスト、サポートを行うように設定されていれば、暗号の交渉を許可する。これにより、従来セキュアではないネットワーク環境においても、IHEセキュアノードのインストールが可能となる。
•

Audit Trail and Node Authentication統合プロファイルは、ローカルユー
ザ認証のみを必要としている。プロファイルはそれぞれのセキュアノードがユーザを認証するにあたり、独自に選択したアクセス制御技術を利用することを許可する。エンタープライズユーザ認証はそのような選択の一つであるが、このプロファイルを必ず利用する必要はない。

•

モバイル機器もAudit Trail and Node Authentication統合プロファイルに参加することができるが、このプロファイルにおいては、モバイル機器に特有の問題については、明確に言及しない。

•

Audit Trail and Node Authenticationプロファイルは、プライバシーやセキ
ュリティに関する規制（HIPPAや欧州、日本における規制など）を遵守しようとしているエンタープライズに対し、有用なツールを提供するが、プロファ
イルそのものが、これらの規制遵守を実現するというわけではない。

•

ATNAは物理的なアクセス制御、職員へのポリシーや他の組織におけるセキュリティの問題など、エンタープライズセキュリティやプライバシー規制に遵守に必要な事柄については、すでに対応が行われていることを前提としている。

9.1 接続認証
Audit Trail and Node Authentication統合プロファイルは、それぞれのノード間の接続において、双方向の証明書ベースのノード認証を要件としている。DICOM、 HL7、そしてHTMLプロトコルにおいては、証明書ベースの認証メカニズムの定義が行われている。これらはユーザではなく、ノードを認証する。双方向のノード認証が行われていないマシンへの接続は禁止されるか、PHIへのアクセスを阻止するようなデザイン
や確認が行われる。
注記：SQLサーバなど、IHEプロファイルで特定されていないコミュニケーションは、PHIに利用される場合双方向で認証されなければならない。このプロファイルでは、この認証がどのように実施されるかについては指定しない。

厳しい設定管理を行い、完全な物理的ネットワークセキュリティを保証することでも、
このリクワイヤメントを遵守することが可能となる。これは、信頼されていないマシンは、
ネットワークのどの部分にも物理的にアクセスすることが不可能になるということであ- 55 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

る。接続認証を設定可能にすることは、物理的にセキュアなネットワークのパフォーマンスを強化することになる。セキュアノードアクタは、接続認証と物理的にセキュアなネットワークの双方をサポートするため、設定可能であるべきである。
9.2 監査証跡
9.2.1 監査メッセージ
セキュリティ、プライバシープロセスの一部としての監査の実施は、プロセス参加者が信頼できる場合適切であり、また変化する状況に迅速に対応する幅広い柔軟性が必要となる。これは典型的なヘルスケアプロバイダの環境であるといえる。監査は何が起こったかをトラッキングし、関係者は、自らの行動が監査されているということを認識している。これは監査記録が、個別のIHEアクタに対応するコンポネントだけでなく、
プロセス全体のイベントの記述を取り込む必要があることを意味する。
IHE監査証跡は異なる形のアクセス制御や認証に対応する、複数のプロファイルのう
ち最初のものである。監査は常に、選択されたアクセス制御や認証方法とは無関係である必要がある。
IHEが特定する監査フローは図 9.2-1.1に提示されている。
1. 実際のアクティビティが行われる。これらのアクティビティのいくつかは、複数のIHEプロファイルのサポートを含む、機器におけるアプリケーションプロセスと関わっている。この製品は、特定のIHEアクタに対応するコンポネントを持つ
場合がある。製品はまた、IHEのレコメンデーションとは無関係の機能を持っていることもある。
2. プロセスの間、様々なイベントが起こる。これらのイベントのうちのいくつかは、
IHEアクタアクティビティと直接関連している。その他のイベントは間接的に関連しているか、またはIHEスペックとは全く関連していないものもある。イベント
はキーの入力といった非常に細かいものから、診断研究の分析といったハイレベルなものまである。これらのイベントのごく一部のみが、セキュリティやプ
ライバシー監査と関係のあるものである。多くのイベントが、活用するにはあまりにレベルが低いか、あまり関係のないものである場合が多い。
3. “Security Audit and Access Accountability Message XML Data Definitionsfor Healthcare Applications(RFC-3381)” は、セキュリティとプライバシー監
査に関連するイベントをレポートするXMLスキーマを定義する。これはASTM、
HL7、DICOM標準、そしてNEMA/COCIR/JIRA セキュリティ・プライバシー委
員会との協力を通じて定義されたものである。IHEはRFC-3381フォーマットの利用を奨励、またこのフォーマットで記載が可能なイベントのレポーティングのみを奨励している。

- 56 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

a. DICOMは監査メッセージのボキャブラリーのうちいくつかについて、標準化を行っている。DICOM Audit Message VocabularyはRFC-3381
が提供している基本的なボキャブラリーを拡張、またRFC-3381のオプ
ションエレメントをさらに特定する役割を果たしている。フィールドに
DICOM Study Instance UIDが含まれていることを明示するコード値の追加が、ボキャブラリー拡張の事例として挙げられる。また、RFC3381メッセージのUserIDフィールドは、ローカル機器オペレーティング
システムに利用されているユーザIDであり、AlternateIDはエンタープラ
イズ認証システムに利用されているユーザID（もし異なる場合）である、というリクワイヤメントが、オプションエレメント特定の例として挙げられる。
b. このプロファイルは、DICOMボキャブラリで定義されているイベントに対応しない、他のイベントについての定義を行う。これらのイベントは
RFC-3381を利用して記述することが可能であり、このプロファイルは
そのような記述に関するリクワイヤメントを含んでいる。
IHE監査では、RFC-3381を利用する際、機器がDICOM遵守機器でない場合でも、DICOMボキャブラリを利用して記述できるイベントであった場合、
DICOMボキャブラリを利用することを指定している。DICOMボキャブラリにマッチしないイベントは、RFC-3381ボキャブラリかその他の拡張を利用
してレポートされる。RFC-3381を利用してレポートできないイベントは、レポート対象にならない。
4. ローカルサイトはその後、独自のレポートポリシーを適用する。IHEプロファイ
ルは監査レポーティングにあるべき機能を特定、またローカルサイトのセキュ
リティ管理者が、レポーティングの詳細を制御できるべきだとしている。IHEプ
ロファイルは監査レポーティングの機能やフォーマットについては特定しない。
5. IHEは監査証跡でレポートされるべきイベントを特定する。この他にも、監査証跡またはその他の方法でレポートされる可能性のある、セキュリティ関連のイベントが存在する。このプロファイルはこれらについてはカバーせず、またこの
レポーティングフォーマットやメカニズムを利用することも要求しない。このようなイベントの例として、ルーティングやファイヤーウォールログなどが挙げられる。

- 57 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

図 9.2-1 監査メッセージ内のイベントフロー
基本的な監査ボ
キャブラリー（例：DICOM）

製品機能

製品監査機能レポートされたイベント

IETF CAM

アプリ
ケーショ
ン

アプリケー
ションアク
ティビティ

監査レポジトリシステム
レポート可能なイベント

全てのイベント

太線で囲まれたアイテムは
ATNAプロファイルで定義されている

IHE監査ボキャブラ
リー拡張

サイトポリシー

記述可能なアイテム

9.2.2 後方互換性
このプロファイルはまた、IHE Radiology TF6.0において今後廃止予定であるBasic
Securityプロファイルにおける、IHE Provisional Audit Messageフォーマットに基づき
フォーマット化されているメッセージについても、引き続き利用できるよう定義している。
この旧式のフォーマットは、放射線関連業務や、他の診断、治療活動のレポーティン
グに適したイベントの記述を行うものである。これらのイベントは、RFC-3381やDICOMボキャブラリを利用して記述することのできるイベントのサブセットである。
IHE ATNAプロファイルはまた、IHEで特定されたトランスポートメカニズムのいずれにおいても、Provisionalフォーマットを利用してこれらのイベントのレポーティングを行うことを可能としている。これは、製品が今後Provisionalメッセージフォーマットから
RFC-3381フォーマットに移行することが予測されているものの、古いフォーマットの導入が幅広く行われていることから、このような移行には時間がかかることが認識されているためである。
RFC-3381とDICOMボキャブラリを適切に利用することが求められている他のヘルス
ケアアプリケーションにおいては、Provisionalフォーマットが利用対象となることは考えられない。
9.3 監査証跡転送
Audit Trail and Node Authentication統合プロファイルは、Reliable Syslog Cooked
Profile （RFC-3195、Section 4）を、中央監査記録レポジトリにおける監査記録メッセ- 58 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

ージログ用のメカニズムとして利用することを特定している。またBSD Syslog（RFC3164）の利用も許可している。しかし、BSD Syslogには限界があることも知られている。
•

送信者に対して、送信先において監査記録が受信されたということを確認することができない。

•

監査記録メッセージを暗号化するオプションがない。

•

送信を行うノードと中央監査レポジトリの証明書を利用した認証を行うことができない。

•

メッセージが切断されたり紛失する可能性がある。

Reliable Syslog Cooked Profileメッセージのスペックは、これらの欠点を修正する。
9.4 アクタ・トランザクション
表9.4-1はAudit Trail and Node Authentication統合ファイルに直接関連するそれぞれのアクタのトランザクションをまとめたものである。この統合プロファイルをサポートしていると申告するためには、「R」で示される、必要条件とされるトランザクションが実
行されなければならない。「O」で示されるトランザクションはオプションである。この統合プロファイルで定義されているオプションの全リストはITI TF-1: 9.4に示されている。
これらの関連は図9.4-1に示されている。

ITI-1:時間維持
Time Server

他のIHEアクタとグループ化されているセキュアノード

ITI-20:監査イベント記
録↓

ITI-1:時間維持
PHIアプリケーションとグループ化されている
セキュアノード

Audit Repository

ITI-19: ノード認証
ITI-20:監査イベント記録

ITI-20:監査イベント記録↑
他のIHEアクタとグループ化されているセキュアノード

- 59 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

図9.4-1. Audit Trail and Node Authentication 図表
実装にあたり、アクタのためにこの統合プロファイルのサポートを選択した場合、そのアクタは「Secure Node」アクタとグループ化される。この実装における全てのIHEアクタとその他のアクティビティが、Audit Trail and Node Authentication統合プロファイ
ルをサポートすることが求められる。
フロッピーディスクや、ネットワークを通じたファイル転送など、実装に必要な証明書をアップロードする方法が提供されなければならない。
PHIを処理する非IHEアプリケーションは、監査可能なイベントを探知、レポートし、またアクセス保護を行う。
表 9.4-1. Audit Trail and Node Authentication 統合プロファイルーアクタとトランザクショ
ンアクタ

トランザクション

オプション<「Secure Node」アクタとグループ化されたPHIアプリケー
ション><「Secure Node」アクタとグループ化されたIHEアクタ>
監査記録レポジトリ

監査イベント記録

R

Vol2におけるセクション
ITI TF-2:3.20

監査イベント記録R

ITI TF-2:3.20

監査イベント記録R

ITI TF-2:3.20

セキュアノード

ノード認証

R

ITI TF-2:3.19

時間維持

R

ITI TF-2:3.7

表 9.4-2 他のドメインにおけるテクニカル・フレームワークでのATNA拡張
プロファイルオプション
Radiology Audit Trail Option

Vol＆セクション
ITI TF-2: 3.22

セキュアノードアクタには以下が含まれる。
1. プライベート情報を公開する可能性のある全てのネットワーク接続におけるノード認証トランザクション。これらのトランザクションは以下を使って定義される。
a) DICOM、TLSを利用
b) HL7、 TLSを利用
c) HTTP、TLSを利用
2. 許可されたユーザのみの利用を保証するため、全てのローカルユーザアクティビティ（ログイン、ログアウトなど）の保護
3. 以下のいずれかを利用した監査トランスポートメカニズム- 60 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profilesa) Reliable Syslog Cooked Profileフォーマット (RFC-3195、Section 4)b) BSD Syslog (RFC-3164)、baseline syslog mechanism
4. 監査メッセージフォーマットの代替としての定義を活用し、推奨されるイベントの監査メッセージを作成。監査メッセージフォーマットは以下のとおり。
a) DICOMとIHEボキャブラリを利用したIETF common audit message
formatb) Provisional IHE Audit Message フォーマット
監査レポジトリは以下をサポートする。
1. 両方の監査トランスポートメカニズム。
2. これらのトランスポートメカニズムのひとつを利用して送信された場合、IHEが特定した監査メッセージフォーマットのいずれか。新たなアプリケーションドメイ
ンはDICOM、IHEボキャブラリのほかに、独自に拡張ボキャブラリを持っている可能性がある。これはまた、IHE Provisional Messageフォーマットと、
BSDsyslogプロトコルをサポートしなければならないため、ATNA監査レポジト
リは自動的にRadiology Basic Securityプロファイルの監査レポジトリとなることを意味する。
3. 自己防衛とユーザアクセス制御。
このプロファイルは監査レポジトリの他の機能については特定しないが、多くのレポジトリがスクリーニングやレポーティング、アーカイブ化を行うことが前提となっている。
9.5 暗号化オプション
セキュアノードはATNA暗号オプションを導入することがある。このオプションは機密性を保護するための暗号化サポートを指定する。
9.6 Audit Trail and Node Authentication プロセスフロー
Audit Trail and Node Authentication統合プロファイルでは、セキュリティ対策としてユーザ認証、ノード認証と監査記録の作成が行われる。ノード認証とユーザ認証は、
セキュアノードのコンセプトや、セキュアドメインにおける接続されたセキュアノードの集合体を確立するトランザクションの定義を行う（Volume ITI-III: 付録 Aを参照)。
監査記録の作成は、監査を開始させるイベントのセット、そして監査記録の内容の定義などを必要とする。このプロファイルでは、2種類の受け入れ可能なメッセージフォ
ーマットを特定している。

- 61 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1. IHE Audit Messageフォーマットに沿ってフォーマット化されたメッセージ。これはDICOM Audit Messagesフォーマットと、IHEエクステンションの組み合わせである。RFC-3381へのIHEエクステンションは、イベントコード、そしてDICOM
標準のドメイン内以外で利用する際に必要な情報が追加されている。
2. 以前の IHE Provisional Audit Messageフォーマット。このフォーマットは、標準団体が、Common Audit Messageフォーマットとボキャブラリーを定義するための標準を検討している間の、暫定的なフォーマットとして定義されている。
ASTM (E2147-01 Standard Specification for Audit and Disclosure Logs for Use in Health
Information Systems) やHL7 (Framework for Audit Messages)の取り組みに基づき、IHEは監査をトリガーするイベントのセット、監査記録のためのコンテンツと一般的な監査メッセージのセット、そしてそれぞれのイベントと一般的な監査メッセージとのマッピングを詳細に定義している。監査記録のコンテンツは、XMLスキーマによって特定されている（ITI-II:付録Fを参照）。

以下のパラグラフは、認証されたユーザ、認証されていないユーザ、認証されていないノードが、保護された医療情報（PHI）にアクセスしようとした場合の3つの典型的なプロセスフローを示している。
9.6.1 通常ノードプロセスフロー
以下のシナリオは、IHEセキュリティ対策が、ネットワーク上の認証されたノードから、PHIへ認証されたアクセスを行う際、いかに運用されるかを示したものである。
1. 時間の同期化が独自に行われる。これらのトランザクションは、いつ行われても良い。正しいタイムスタンプを利用した監査記録を作成するため、正確な時間情報が必要となる。
2. ユーザは「Image Display/Secure Node」アクタにログインする。
ユーザは正しい証明書を入力、ノードにアクセスする許可を得る。
3. ノードが監査記録を作成する。
4. ユーザは画像のクエリ、取り出し、閲覧を行う。
画像のトランザクションが実施される前に、「Image Display/Secure Node」ア
クタと「Image Manager/Image Archive/Secure Node」アクタ間での認証プロ
セスが実行される。
5. ノード認証に続き、ノードはクエリ・情報取り出しのためのトランザクションを開始する。
6. ノードは監査記録を作成する。

- 62 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Image Display/ Secure
Node

Image Manager/
Image Archive/ Secure
Node

Audit Record
Repository/Secure NodeTime Server

時間維持[ITI-1]
時間維持[ITI-1]

時間維持[ITI-1]

監査イベント記録[ITI-20]（ユーザ認証済み）
ノード認証[ITI-19]
監査イベント記録[ITI20] （画像クエリ）

画像クエリ
画像取り出し画像閲覧

監査イベント記録[ITI20] （画像取り出し）監査イベント記録[ITI20] （画像取り出し）監査イベント記録[ITI20] （インスタンス利用）

図 9.6-1. 認証ノードプロセスフロー

9.6.2 不正ノード プロセスフロー
以下のシナリオは、IHEセキュリティ対策が、ネットワーク上の認証されていないノード
から、認証されていないユーザがPHIにアクセスすることを、いかに防止するかを述べたものである。
1. 不正なノードが「Lab Automation Manager/Secure Node」アクタに情報入手のためのクエリを行おうとする。ここでは認証が行われないため、クエリは失敗し、監査記録が作成される。
2. 不正なノードが「Image Manager/Image Archive/Secure Node」との間で認証プロセスを実行しようとする。ここでは、「Automation Manager/Secure
Node」が悪質なノードによって提示された証明書を信頼しないため、プロセスは失敗し、監査記録が作成される。
ここで記載されているトランザクションの順序は、ひとつの事例に過ぎない点に注意する。不正なノードからのトランザクションは予期不可能であり、この他の順序でも起こる可能性がある。

- 63 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Lab Automation
Manager/Secure Node

Unauthorized Node

Audit Record
Repository/Secure Node

画像クエリ

認証失敗
監査イベント記録[ITI20]（ノード認証失敗）

ノード認証｛ITI-19]

監査イベント記録[ITI20]（ノード認証失敗）

認証失敗

図 9.6-2. 不正ノードプロセスフロー

9.6.3 不正ユーザプロセスフロー
以下のシナリオは、IHEセキュリティ対策がヘルスケアエンタープライズ内の不正ユーザにより、PHIに不正アクセスされることをいかに防止するかを示したものである。
1. 不正ユーザが「ECG Display/Secure Node」アクタとの間で認証プロセスを実行しようとする。「ECG Display/Secure Node」アクタはユーザ名と提示された証明書がこのセキュアノードでは有効でないことを探知、このプロセスは失敗
し、監査記録が作成される。

- 64 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Audit Record
Repository/Secure NodeECG Display/Secure
NodeTime Server

時間維持[ITI-1]
時間維持[ITI-1]

ローカルユーザ認証（不正ユーザ）監査イベント記録[ITI20]（ユーザ認証済み）

図 9.6-3. 不正ユーザプロセスフロー- 65 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

10 Cross-Enterprise Document Sharing (XDS)
Cross-Enterprise Document Sharing IHE統合プロファイルは、ヘルスエンタープ
ライズにおける患者の電子記録の登録、分配、アクセスを可能にする。CrossEnterprise Document Sharing (XDS)は、個人開業医、クリニックから、救急治療施設に至るまで、いかなるヘルスケアエンタープライズ間ににおいても、文書共有管理を行うための標準ベースのスペックを提供することを目的としている。
XDS IHE統合プロファイルはこれらのエンタープライズが、一件かそれ以上の医療連合ドメインに属していることを前提としている。医療連合ドメイン（Clinical Affinity
Domain）は、共通のポリシーやインフラを利用し、協働することを合意したヘルスケア
エンタープライズのグループを指す。これらの「医療連合ドメイン」の例としては以下が挙げられる。
•
•
•

•
•
•

特定の地域の全ての患者に対応するための、地域医療情報団体に支援されたケアコミュニティ
全国レベルのEHR専門、または特定の疾病に関するケア団体
o 心臓専門医と緊急心臓センターo 癌専門ネットワーク
o 糖尿病ネットワーク
エンタープライズの連合
o 複数の地域の病院やヘルスケアプロバイダによる地域連合
政府による施設（退役軍人省や軍による施設）
保険プロバイダにより支援されるコミュニティ

医療関連ドメイン内では、共通のポリシーやビジネスルールが定義されていなければならない。これは医療情報のフォーマット、コンテンツ、構造、組織や医療情報の表示のほか、どのように患者が特定されるか、合意を得るか、アクセスの制御を行うかというものが含まれる。この統合プロファイルは、特定のポリシーやビジネスルールについては定義しないが、患者の医療ドキュメント共有のために、標準ベースのインフラ導入を可能にするため、このような幅広いポリシーに対応するようデザインされている。
これは医療関連ドメインにおいて、長期的に変化していく患者情報記録を作成するための、連合ドキュメントレポジトリとドキュメントレジストリを通じて管理される。これらは、異なる責任を持つ個別のエンティティとなっている。
•

ドキュメントレポジトリは透明、セキュアで信頼でき、一貫した方法で文書を保管、文書の取り出しリクエストに返答する。

•

ドキュメントレジストリは患者ケアに必要とされる文書が、実際どのレポジトリに保管されているかにかかわらず、簡単に特定、選択、取り出すことを可能にするため、これらの文書に関する情報を保管する。

- 66 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

XDSにおける「文書」の概念は、テキスト情報のみに限られたものではない。XDSは文書のコンテンツには中立であるため、内容や表示方法にかかわらず、いかなるタイ
プの医療情報もここではサポートされる。これにより、XDS IHE 統合プロファイルは、
シンプルテキスト、フォーマット化されたテキスト（HL7 CDA Release1など）、画像（DICOMなど）、または構造化、ボキャブラリのコード化が行われた医療情報（CDA
Release 2、CCR、CEN ENV 13606、DICOM SRなど）などを平等に扱うことができる。ドキュメントソースとドキュメント利用者に対して必要な互換性を保証するため、医療連合ドメインはドキュメントフォーマット、構造やコンテンツに関するポリシーを取り入れる必要がある。
XDS統合プロファイルはエンタープライズ間のEHRコミュニケーションのニーズ全てをカバーするものではない。シナリオの中には、Patient Identifier Cross-Referencing、
Audit Trail and Node Authentication、 Cross-Enterprise User Authentication、Retrieve Information for Displayなど、他のIHE統合プロファイルの利用を必要とす
るものも考えられる。また部分的にしかサポートされていないシナリオもあれば、将来ベースとなる標準が確立されて初めて、IHEが新たに作成することになる統合プロフ
ァイルが必要となるシナリオもあると考えられる。特に、以下のようなものが挙げられる。
1. アレルギーリスト、服用している医薬品リスト、問題リストなどのダイナミックな情報の管理はXDSでは対応していない。しかし、Retrieve Information for
Display Integrationプロファイルは、このような機能における初歩的なサポートに利用可能なトランザクションを提供している（LIST-ALLERGIES、 LISTMEDSなど) 。このようなダイナミックな医療情報のアップデート管理や、構造化されたアプリケーションアクセスは、将来別の統合プロファイルによってサポートされることが期待される。
2. オーダーの発注とトラッキング（処方箋やレントゲン撮影の依頼など）はXDSではサポートされていないが、これは、オーダの保管や登録、また結果が患者の医療記録に記載される必要がある場合、XDSの利用を除外するものではない。しかし、XDSはワークフローを通じてこのようなオーダーの進捗状況をトラッキングする便宜は提供しないため、オーダー管理には向いていない。エンタープライズ間のオーダーワークフロー(ePrescription、 eReferralなど) に対する補完的なアプローチについては、将来別の統合プロファイルを通じてサポートされることが期待される。
3. いかなるXDS連合ドメインのオペレーションにおいても、的確なセキュリティモ
デルが導入されている必要がある。ここでは幅広いセキュリティモデルの利用が考えられる。XDS統合プロファイルは、特定のセキュリティモデルの利用は求めないが、XDS実装者が、XDSアクタをIHE Audit Trail and Node
Authenticationのアクタとグループ化すること、またこのようなエンタープライズを超えた環境でも機能するアクセス制御機能が導入されていることを期待している。XDSを補完する、特定のIHE統合プロファイルも提供されている（Cross-Enterprise User Authentication、Document Digital Signatureなど）。
- 67 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

4. 独立した、しかし一貫してXDSベースである医療連合ドメインの確立は、患者が地域や国を移動した場合でも、患者の情報がどこからでも取り出すことができるよう、ドメイン間の連携を必要とする。IHEは医療連合ドメイン間での情報転送や、あるドメインから、文書が管理されている他のドメインへのアクセスの許可などが必要になってくることを予測している。XDSはこのような可能性を考慮してデザインされている。XDSを補完する、XDS Domains Federation統合プロファイルが将来考えられる。
5. XDSは医療連合ドメインの管理や設定のためのトランザクションなどには対応していない。例えば、ネットワークアドレスの設定や、どのタイプの医療情報が共有されるかについては、医療連合ドメインが確立したポリシーに基づくようになる。
10.1 アクタ・トランザクション

Patient Identity Source

患者IDフィード[ITI-8]↓
レジストリクエリ[ITI-16]←Document Registry

文書セット提供・
登録[ITI-15]→
Document Source

Document Consumer

ITI-20:監査イベント記録↑文書セット登録[ITI-14]
文書取り出し[ITI-17]←
Document Repository

図10.1-1 エンタープライズ間文書共有図表- 68 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

表 10.1-1 XDS - アクタとトランザクション
アクタ

トランザクション

オプション

Document
Consumer

クエリレジストリR

Vol2におけるセクション
ITI TF-2:3.16

文書取り出しR

ITI TF-2:3.17

文書セット提供と登録
オフライントランザク
ションモードR（注記 1）ITI TF-2:3.15

O

ITI TF1:10.4.7.1

複数文書提出O

ITI TF-2:3.15.5

文書ライフサイクル
管理
フォルダ管理OITI TF-2:3.15.5

O

ITI TF-2:3.15.5

文書セット提供と登録
文書セット登録R（注記1）ITI TF-2:3.15

R（注記2）R

ITI TF-2:3.17

Document Source

Document
Repository

文書取り出しDocument Registry

Patient Identity
SourceITI TF-2:3.14

オフライントランザク
ションモードO

ITI TF1:10.4.7.1

文書セット登録R（注記2）ITI TF-2:3.14

クエリレジストリR

ITI TF-2:3.16

患者IDフィードR

ITI TF-2:3.8

患者IDフィード

R（注記3）ITI TF-2:3.8

注記1： Provide and Register Document Setは、Document SourceがDocument Repositoryアクタとグループ化されている実装では必要とされない。
注記2： ドキュメント登録セットトランザクションは、Document RegistryアクタがDocument Repositoryアクタとグ
ループ化されている実装においては必要とされない。しかし、複数のレポジトリと将来設定が可能になるよう、このようなトランザクションをサポートすることが強く推奨されている。
注記3：患者ID指定機関が患者IDフィードトランザクションに存在する場合、患者IDソースは指定機関を特定する
ため、OIDの利用を求められる。指定機関情報に関する技術的な詳細は、TF-2におけるTransaction 8を参照。

10.1.1アクタ

10.1.1.1 Document Source「Document Source」アクタは文書を作成、発行し、文書を「Document Repository」
アクタに送信、また引き続き行われる「Document Registry」アクタへの登録のために、「Document Repository」アクタにメタデータを提供する。
10.1.1.2 Document Consumer- 69 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles「Document Consumer」アクタは「Document Registry」アクタに対し、特定の基準に合致した文書に関するクエリを送信、一件または複数の「Document Repository」アクタから、選択された文書を取得する。
10.1.1.3 Document Registry「Document Registry」アクタは文書エントリーにおいて、それぞれ登録された文書のメタデータを維持する。これは、レポジトリに保存されている文書へのリンクも含む。ドキュメントレジストリは「Document Consumer」アクタによる、特定の基準に合致する
文書クエリに返答する。また文書登録時、ヘルスケア機関に特有のテクニカルポリシーを実施する。
10.1.1.4 Document Repository
ドキュメントレポジトリはこれら文書の一貫した保管のほか、適切なドキュメントレジス
トリへの登録や、「Document Consumer」によって後に行われる文書取り出しのため、文書にURIを割り当てる。
10.1.1.5 Patient Identity Source「Patient Identity Source」アクタは、それぞれの患者へユニークIDを提供、IDの特徴についての情報維持を行う。「Patient Identify Source」は、他のアクタとのインタラク
ションにより、「Document Registry」アクタによる患者IDの確認を促進する。
10.1.2

トランザクション

10.1.2.1 文書セット提供と登録「Document Source」アクタは、文書セット提供と登録トランザクションを開始する。提出されたセット内のそれぞれの文書において、「Document Source」アクタはドキュメ
ントレポジトリに対し、文書を不透明なオクテット・ストリームとして、そして対応するメ
タデータもあわせて提供する。「Document Repository」は一貫してこのドキュメントを保管、「Document Source」アクタから受信した文書メタデータを転送することで、文書登録トランザクションを利用し、「Document Registry」に文書の登録を行う。
10.1.2.2 文書セット登録「Document Repository」アクタは文書セット登録トランザクションを開始する。このトランザクションは、登録される文書のメタデータを提供することで、「Document
Repository」アクタが、複数の文書を「Document Registry」に登録することを可能にする。この文書メタデータはレジストリにXDS Document Entryを作成するのに利用される。「Document Registry」アクタは、ドキュメントが登録される前に、メタデータが有効なものであることを確認する。複数の文書がメタデータの確認に失敗した場合、文書セット登録トランザクション全体が失敗となる。

- 70 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

文書の組み合わせをサポートするため、XDSドキュメントはマルチーパートな文書である場合もある。「Document Repository」はマルチパートデータセットを、「Opaqueentity」として処理できなければならない。「Document Repository」は、XDS統合プロ
ファイルに関連し、マルチパート構造やコンテンツのいかなる部分の分析、処理を行う必要はない。
10.1.2.3 登録クエリ「Document Consumer」アクタはケアプロバイダ（EHR-CR）に代わり、「Document
Registry」に対して登録クエリトランザクションを実施する。「Document Registry」アクタはレジストリを検索し、プロバイダが指定したクエリ基準に合致する文書を特定する。
一件または複数の「Document Repository」から、合致する文書のロケーションとID
を含メタデータを含むドキュメントエントリーリストを返信する。
10.1.2.4 文書取り出し「Document Consumer」アクタは文書取り出しトランザクションを開始する。
「Document Repository」は「Document Consumer」で指定された文書を返信する。
文書の組み合わせをサポートするため、XDSドキュメントはマルチパートドキュメントである場合もある。この場合、「Document Consumer」はユーザがマルチパートコン
テンツにアクセス可能であるよう、適切なアクションをとる必要がある。
10.1.2.5 患者IDフィード
患者IDフィードトランザクションは、患者IDを伝える役割を果たす。患者IDが作成、変更または統合された際に患者の基本データが取り込まれたり、患者に関連する基本
データが変更された場合、患者IDとその基本データを伝達する。XDS統合プロファイ
ルは、医療連合ドメインで登録された患者IDを、レジストリに投入することを目的としている。
10.1.3

XDS 文書コンテンツのサポート

以下の表は、他のIHE統合プロファイルでサポートされている文書コンテンツを示したもので、様々なドメインにおいて医療文書を共有するための確たるコンテンツタイプを特定している。これらのプロファイルはXDSプロファイルを元に構築されており、特定の利用例において、エンタープライズ間の文書共有時の制限やセマンティックスを追加提供する。

- 71 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

表 10.1-1: IHE統合プロファイルとサポートするドキュメントタイプ一覧
IHEテクニカルフレームワ
ークドメイン
Patient Care
Coordination
Radiology

統合プロファイル名

サポートされる文書コンテンツ

Cross-Enterprise
Sharing of Medical
Summaries
Cross-Enterprise
Document Sharing for
Imaging (XDS-I)

HL7 CDAフォーマットの医療サマリー
テキストフォーマットまたは PDF フォーマットの放射線診断レポート
DICOM Key Object Selectionフォー
マット内のマニフェスト文書内のDICOM SOPインスタンスの参照

10.2 統合プロファイルオプション
この統合プロファイルのために選択可能なオプションは、対応するアクタとあわせ、表10.2-1に示されている。必要に応じ、オプション間の依存関係が注記に示されている。

表 10.2-1 XDS - アクタとオプション
アクタ
Document Source

オプション
オフライントランザクションモード

Vol＆セクション
ITI TF-1:10.4.7.1

Document Repository
Document Registry
Document Consumer

複数文書提出文書ライフサイクル管理
フォルダ管理
オフライントランザクションモード
オプションは定義されていない
クエリ登録トランザクション（注記 1）

ITI TF-1:10.2.1
ITI TF-1:10.2.2
ITI TF-1:10.2.3
ITI TF-1:10.4.7.1-ITI TF-2:3.16

文書取り出しトランザクション（注記1）

ITI TF-2:3.17-Patient Identity Source
オプションは定義されていない
注記1: 「XDS Document Consumer」アクタには、オプションのいずれか、または双方を選択する。

10.2.1

複数文書提出オプション

このオプションでは、「Document Source」は提出リクエストに対して複数の文書を含む機能が提供する。
10.2.2

文書ライフサイクル管理オプション

このオプションでは、「Document Source」は以下のオペレーション実施機能を提供する。
••

文書を、すでにレジストリ・レポジトリに含まれている文書の添付として提出する。
文書を、すでにレジストリ・レポジトリに含まれている文書の変更として提出する。
- 72 -

Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

注記：文書差し替え・添付・変換においては、レジストリ（既存文書エントリーのUUIDなど）へクエリを行う
ため、「Document Consumer」とのグループ化が必要な場合もある。

フォルダ管理オプション

10.2.3

このオプションにおいて、「Document Source」は以下のオペレーション実施機能を提
供する。
•
•

フォルダを作成
フォルダに複数のドキュメントを追加
注記：既存フォルダへの文書追加をサポートするため、レジストリへのクエリ（既存フォルダのUUIDなど）が行えるよう、「Document Consumer」とのグループ化が必要な場合もある。

10.3 統合プロファイルプロセスフロー
患者は、異なる医療環境で、一連の診療を受けることになるのが一般的である。診察の結果作成される患者情報は、複数のケア提供情報システム（EHR-CR）によって作成、管理される。また一連の医療活動を通じ、複数の医療文書が作成される。これらの文書は、同じ医療連合ドメインの一部である、複数のEHR-CRから提供されたものであり、 EHR-LRはこれらの文書に関連するサブセットを共有する方法を提供する。
例 : 心臓病患者管理のシナリオ

10.3.1

地元病院

緊急室

PCP
5

病棟

１
7
リハビリ
セラピスト

カテーテルラボ10
6&8

心臓病アセスメント

心臓内科医

ラボ

8

心臓病治療

3&9
フォルダ

4
ラボ

2

提出セット

放射線科

XDSドキュメ
ント

図10.3-1 心臓病患者管理シナリオトランザクションプロセスフロー- 73 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

このシナリオは患者の心臓病に関する約3週間のエピソードである。患者は主治医（PCP）に息切れ、吐き気、疲労と胸の痛みを訴える。この医師はPCP、心臓内科医、ラボ、地元病院２軒との間で、患者ケアを改善を目指し、医療文書共有ネットワークを最近確立した、地元の病院と緊密に連携している。この心臓病ネットワークは、この地域に設置された地元ケアデータエクスチェンジコミュニティの一部であり、この患者が利用している保険プランも参加している。保険プランは利用者に対しこのネットワー
クへの参加を奨励しており、この患者にも、医療記録アカウント番号がすでに提供されていた。
1. 診察の際、主治医は患者が訴える症状を記録し、ECGを行うべきだと判断。ECGレポートのため、心臓病ケアネットワークが設置した、コード化されたドキュメントクラス「レポート」とコード化された診療セッティング「心臓病」を利用し、心臓病ケアネットワークにクエリを送信し、以前のECGレポ
ートがないか確認する（図10．3-2のステップ1）。合致する文書の中から、医師は以前のECGレポートを特定、取り出しを行う（図10．3-2におけるス
テップ2）。医師は二つのレポート結果を比較し、患者が心臓内科医に紹介されるべきだとの判断を下す。心臓病ケアネットワークの中からこの患者に関するレポートが他にないかを検索したが（図10．3-2におけるステップ3）、特に何も見つからなかった。外来EHRシステムを利用し、主治医は患者の医療記録アカウント番号に、「主治医オフィス来院」に関する提出リク
エストを作成する。ここでは、3つの新しい文書セット（訪問ノート、紹介書、新しいECGレポート）と、以前のECGレポートの参照情報（図10．3-2におけるステップ4）が含まれている。心臓病ネットワーク連合ドメインのポリシーに沿って、心臓内科医とコラボレーションが行えるよう、医師はこの4つの文書が含まれる「心臓病アセスメント」フォルダを作成する。外来EHRシ
ステムに利用されたレポジトリは、この提出リクエストの一部となっているこ
れらの文書を登録する（図10.3-2におけるステップ5）。

- 74 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Document Consumer:(PCP EHR-CR)

Document Source(PCP EHR-CR)

Document Registry (心臓病ネットワーク）

Document Registry (心臓病ネットワーク）

1．文書クエリ

2．文書取り出し

3．文書クエリ

4．文書提供と登録
5．文書登録図 10.3-2 PCP クエリトランザクションプロセスフロー

PCP EHRシステムはクエリ、取り出し・提供、そして登録トランザクションを図10.3-2で示されたとおり実施するため、「Document Consumer」アクタと 「Document
Source」アクタを導入する。トランザクションは、心臓病ケアネットワークが提供する「Document Repository」と「Document Registry」によって処理される。
2. 患者は心臓内科医にアポイントメントをとる。患者はアポイントの前に必要となるテストを受けにラボを訪れる。ラボは「ラボテスト」の医療コードがつけられた、ラボの結果を含む提出セットを作成する。ラボは「心臓病アセスメント」フォル
ダの存在には気づいていない。
3. 心臓内科医は患者を診る。医師は「心臓病アセスメント」フォルダの中の患者の記録について、レポジトリにクエリを送信する（図10.3-3におけるステップ1)。
ここでは主治医への来院記録、ECG、過去のECG、紹介書が入手可能となっており、医師はこれらを取り出し閲覧する（図10.3-3におけるステップ2-5）。医師はまた最近のラボレポートに関してクエリを送信、ラボの結果を見つける（図10.3-3におけるステップ6）。これもまた取り出され、閲覧される（図10.3-3のステップ7）。
心臓内科医は超音波検査を行い、来院ノートを作成し、核検査の実施をオーダーする。来院ノートと超音波画像、レポートは「心臓内科来院」提出セットとして登録され、「心臓病アセスメント」フォルダに保存される。さらに、ラボレポート
も「心臓病アセスメント」フォルダに追加される（図10.3-3におけるステップ8）。

- 75 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Document Consumer:(PCP EHR-CR)

Document Source(PCP EHR-CR)

Document Registry (心臓病ネットワーク）

Document Registry (心臓病ネットワーク）

1．文書クエリ
2．文書取り出し
3．文書取り出し
4．文書取り出し
5．文書取り出し

6．文書クエリ

7．文書取り出し

8．文書提供と登録
9．文書登録図 10.3-3 PCP クエリトランザクションプロセスフロー

4. 患者は核検査のために放射線施設を訪れる。テストが実施され、放射線担当
医がレポートを作成する。各検査レポートは「放射線テスト」提出セットに登録され、「心臓病アセスメント」フォルダと関連付けられる。
5. 心臓内科医とのアポイントメントにはあと2日あるが、患者は胸の痛みで目を覚まし、出勤途中に地元病院の緊急医療室（ER）に行くことにした。ERの医師
は病院のEHRシステムを利用し、心臓病ケアネットワークレジストリにクエリ送信を行い、時系列とは逆の順で関連する文書の呼び出しを行う（図10.3-4のステップ1）。最新の心臓病関連フォルダから入手可能な文書は、主治医と心臓内科医による来院ノート、最近行われたECGと過去のECG、ラボの結果、
超音波画像とレポート、核検査とレポート、となっている。
ERの医師は最も関連性の高い2つのレポートを取り出し閲覧を行う（図10.3-4のステップ２と3）。
ERの医師はラボテストとECGをオーダーし、患者をモニタリング下に置く。ラ
ボテストとECGが、心臓病ネットワークの「Document Repository」アクタの役
割を果たす病院のEHR内に置かれる。さらに心臓に異常が起きた場合、カテーテル化やさらなる診断、治療が必要となる。ERの医師は患者を心臓内科に入院させ、心臓内科医にコンタクトをとる。

- 76 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Document Consumer:(PCP EHR-CR)

Document Source(PCP EHR-CR)

Document Registry ( 心臓病ネットワーク）

Document Registry (心臓病ネットワーク）

1．文書クエリ2. 文書取り出し

2. 文書取り出し

図 10.3-4 ER クエリトランザクションプロセスフロー

6. ERの医師と協議中、心臓内科医はホームオフィスから心臓病ケアネットワー
クにアクセスする。心臓内科医は患者が最後に来院して以降の、関連する全ての文書のクエリを行う。ここでは、医師が以前閲覧できなかった核検査レポートが、ラボの結果とERからのECG結果とあわせ、入手可能となっている。二人の医師はケアの計画を決定し、心臓内科医は病院で患者に会うためのアレンジメントを行う。
7. 患者がERから移動されるにあたり、ER来院ノートが「緊急部門来院」提出セッションとして提出され、新たに設置された「心臓病治療」フォルダーに、ラボやECGの結果とともに置かれる。
8. 患者は以下の順番に沿って、入院患者用のベッドに移される。
•
•
•
•
•
•
•
•
•

患者に対するカテーテルラボにおけるカテーテル化の予定が立てられる
追加のラボテストのオーダー、実施
カテーテルラボにおける診断手続きの実施
ステント留置を行う診療が実施されるカテーテル診療レポートの記述
患者は回復のためモニターを続けながらも退院
患者、家族に対する教育が行われる
心臓内科医により退院サマリーが記述される
予定されているフォローアップのための来院の前に、心臓内科医はラボテスト
をオーダー- 77 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

入院アセスメント、ラボの結果、カテーテル診療レポートと主要な画像、そして退院サマリーが「心臓病診断」提出セットを形作っている。これは心臓病ケア
ネットワークレジストリ上の、ERから開始された「心臓病治療」フォルダに登録される。
9. 患者は、退院前のフォローアップのため心臓内科医を訪れる。結果、来院ノー
ト、心臓病リハビリテーションとサマリーレターが「心臓内科医来院」提出セットと「心臓病治療」フォルダに置かれる。
10. 患者は心臓内科医が予定したリハビリセッションに訪れる。患者は回復し、主治医と心臓内科医に、定期健診のために訪れるようになる。
10.4 一般的な法則
10.4.1

EDR-CR の概念「EHR-CR」または「ケア提供記録（Care-delivery Record）」は情報システムまたは
開業医、養護施設、外来クリニック、緊急ケア施設などが持つシステムの要約を行う。
一般的に、患者は以下の図の流れのように、複数の医療機関を訪れる。

長期ケア

緊急ケア(入院治療）
他の専門的なケア(診断サービスを含む）

PCPとクリニック（外来）
診断・治療ポイント

図 10.4.1-1 ケア提供組織にまたがる診断・治療ポイントの変遷

提供されるケアのタイプや、ケア提供組織における内部ワークフローの定義や制限を行うことは、IHE統合プロファイルの対象外である。EHR-CRシステムはエンタープラ
イズ間での医療文書共有においては、以下の原則に基づき、「Document Source」アクタまたは「Document Consumer」アクタとしてのみ参加する。
- 78 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

1. EHR-CRはドキュメントソースとして、XDS 医療連合ドメインにサポートされている文書フォーマットを利用し、文書を提供する（例： CDA Release 1、特定のテンプレートを含むCDA Release 2、DICOM Composite SOP Classes、
ASTM-CCR、CEN ENV 13606など）。
2. このプロファイルはEHR-CRを「Document Source」や「Document
Consumer」の保管場所として必要とせず、XDS 医療連合ドメイン内で共有するため、内部情報を文書の形で管理する。
3. ドキュメントソースとドキュメントレポジトリをグループ化することで、EHR-CRは統一されたアクセスメカニズムを提供するため、重複するストレージを必要とせず、既存のストレージを活用することもできる。
4. EHR-CRはDocument Source、Document Consumerとして、必要に応じローカルコードを医療連合ドメインのコードとマッピングする。
EHR-CRにより共有され、XDSレジストリによりトラッキングされるXDSドキュメントは、
XDS 医療連合ドメインのHER-CRの間でケアを受ける患者に対して、長期的な記録を形作ることになる。
EHR-LR：治療ポイントを超えて利用される長期的記録

EHR-CR
長期ケア

EHR-CR
緊急ケア（入院治療）

EHR - LR
EHR-CR
他の専門的ケアや診断サービス

EHR-CR
PCP 、クリニック( 外来）

EHR-CR：ケア提供をサポートするケア記録
システム

図 10.4.1-2 患者の長期的医療記録への貢献と共有
この統合プロファイルにおいては、共有される医療記録はEHR-LR と呼ばれる。
10.4.2

XDS ドキュメントの概念

XDS ドキュメントは「Document Repository」アクタに提供される最小ユニットの情報であり、「Document Registry」アクタにおいてエントリとして登録される。
XDSドキュメントは、交換を目的に、観察とサービスを含む医療情報の組み合わせであり、保存性（Persistence）、管理責任（Stewardship）、真正性（Potential for
Authentication）、完全性（Wholeness）という特徴を持つ。これらの特徴はHL7
Clinical Document Architecture Release 1 specificationにおいて定義されている。
- 79 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

XDSドキュメントは適切なアプリケーションを用いて、ユーザが閲覧可能なものとなっており、いかなる場合においても、その構造、コンテンツとエンコーディングを定義した
標準を遵守しているべきである。IHE はこのような標準に基づくコンテンツ主体の統
合プロファイルが、XDSとあわせて利用されるよう定義することを目的としている。
XDS統合プロファイルはXDSドキュメントをシングルユニットの情報として管理、XDS
ドキュメントの一部にアクセスするためのメカニズムは提供しない。「Document
Sources」または「Document Consumers」のみがXDSドキュメントの内部情報にアクセスできる。共有を目的に提出された際、XDSドキュメントはオクテット・ストリームとして、「Document Repository」アクタに提供される。文書取り出しトランザクションを通じて取り出された場合、提出されたオクテット・ストリームから変更されてはならない。
「Document Source」アクタは、「XDS Consumer」アクタがクエリのためにXDSドキュ
メントエントリを作成する際、「Document Registry」アクタに提出される必要のあるメ
タデータを作成する。「Document Source」は登録したXDSドキュメントに関する責任を維持する。誤って提出されたXDSドキュメントを差し替えても良い。XDSドキュメントのさらなる概念については、ITI TF-1: 付録Kを参照。
XDS ドキュメントは、GUID（Globally Unique Identifier）を利用して特定される必要がある。GUID（Globally Unique Identifier）については、ITI TF-2:付録B を参照。
10.4.3

提出リクエストXDS Submission RequestはXDSドキュメントを共有する方法である。これは以下によって伝えることができる。
•

文書セット提供・登録トランザクション内の「Document Source」アクタにより、「Document Repository」アクタへ。

または•

文書セット登録トランザクション内の「Document Repository」アクタにより、「Document Registry」アクタへ。

XDS 提出リクエストはXDSドキュメントが正しく登録されたことを確認するため、以下の情報を含んでいる。
1. 新たに提出されるXDSドキュメントのために、ドキュメントエントリに置かれるメ
タデータ
2. 新たに提出されるXDSドキュメントとフォルダのリスト、そしてオプションで以前に提出されたXDSドキュメントのリストを含む提出セット
3. 必要であれば、フォルダは含まれているXDSドキュメントのリストと共に作成される（以前提出されたドキュメントと、新たに提出されるドキュメント）- 80 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

4. 必要であれば、以前作成されたXDSドキュメントリストを含むフォルダの追加（以前提出されたドキュメントと、新たに提出されるドキュメント）5. 新たに提出されたXDSドキュメントのためのゼロまたはそれ以上のXDSドキュ
メントオクテット・ストリーム
提出リクエストに続き、新たなXDSドキュメント、提出セット、提出リクエストに含まれるフォルダがXDS連合ドメインで共有可能となる。提出リクエストの処理が失敗した場
合、提出セットやXDSドキュメント、フォルダとも登録されない。
10.4.4

提出セットの概念

XDS提出セットは、提出リクエストを行う医療機関のEHR-CRが提供する、患者に対するケアイベントに関連している。ここでは、同じケアイベントに関連する既存のXDS
ドキュメント（例：すでに登録されているなど）のほか、新たなXDSドキュメントの永久的な記録を作成する。また新たなXDSフォルダ作成の記録も含む。
XDS提出セットはそれぞれの提出リクエストにあわせて作成される。１件の「Document Source」アクタと関連し、１件のドキュメント提出・登録トランザクションまたはドキュメントセット登録トランザクションによって伝えられる。
「Document Registry」は同じXDS提出セットに登録された全ての文書を検索するためのクエリを受けることもある。
当初提出セットの一部として登録された同じXDSドキュメントは、後にXDS提出セットに参照されることもある。これにより、患者の現在のケアに関連する古い文書が、より最近の提出セットに関連付けられる。
XDSはEHR-CRに対し、ドキュメントセット、提出セットを治療、来院、ケアのエピソー
ドなど、HER-CR内の様々なワークフロープロセスと関連付ける柔軟性を提供する。
10.4.5

フォルダの概念

XDSフォルダは、複数のXDSドキュメントソースがXDSドキュメントを様々な理由に基づき（ケアの期間、問題、予防接種など）グループ化するため、コラボレーティブなメカ
ニズムを提供、「Document Consumer」に対し、同じフォルダに含まれる全てのドキュメントエントリを見つける方法を提供することを目的としている。以下の原則がXDS
フォルダに適用される。
1. フォルダは同一の患者のケアに関するXDSドキュメントをグループ化する。
2. フォルダに対し、一件またはそれ以上の「Document Source」アクタが文書を提出できる。
3. フォルダは「Document Source」により作成されるか、または医療連合ドメイン
により事前に定義される。
- 81 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

4. フォルダのコンテンツはコードや意味のリストにより条件付けられる。
5. 「Document Source」アクタは「Document Registry」にクエリを行うことで、またはXDSの範囲外での方法（ePrescriptionやeReferralなどのクロス・エンタ
ープライズワークフローなど）を用いて既存のフォルダを探す。
6. 一度作成されると、フォルダは「Document Registry」に永久に認識される。
7. 既存の文書をフォルダに置くことは提出セットの一部として記録されない。
8. XDS内のフォルダはネスト化されない。
9. 同じドキュメントが複数のフォルダに存在していても良い。
10. フォルダはGUIを持つ
提出リクエスト、提出セットとフォルダの事例

10.4.6

以下の一連の図は、2件の新規文書を含む提出リクエスト、既存文書の参照と2つのフォルダの利用例を示したものである。最初の図は、2件の文書が提出された際の「Document Registry」の最初の状態を示したものである。文書のうち１件はフォルダ
Aと関連付けられている。次の図は、2件の新規文書を追加する提出リクエストを示したものである。ここでは１件の文書は既存のフォルダに、もう１件は新たなフォルダBに置かれる。
ドキュメントレポジトリとレジストリ―当初の状態
ドキュメントレジストリ

フォルダA

提出セット1

文書エントリ
以前の提出文書エントリ以前の提出

ドキュメントレポジトリ

ドキュメントレポジ トリ- 82 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

ドキュメントレジストリとレポジトリ–提出リクエスト
ドキュメントレジストリ
提出リクエスト

フォルダA

フォルダB

提出セット1

文書エントリ
以前の提出

提出セット2

文書エントリ

文書エントリ

文書エントリ

以前の
提出

新規提出

新規提出

ドキュメントレポジトリ

図 10.4.6-1 XDSレジストリへの提出フロー例

以上の例における提出セットのコンテンツが以下の図に示されている。提出セットに関連付けられているドキュメントエントリは、提出セットのロジカルな部分となっている。

提出セット2
フォルダB

文書エントリ

文書エントリ

新規提出

以前の提出

文書エントリ

新規提出

図 10.4.6-2 提出セットのロジカルコンテンツ

10.4.7

XDS 登録データモデルと属性

XDS統合プロファイルはドキュメントソースが選択したレポジトリに文書を設置、また医療連合ドメインを管理する「Document Registry」へのエントリにおいても、この文書（またはメタデータ）の情報を設置する方法を提供する。
メタデータという用語は、この情報が文書に「ついて」の情報であることを反映している。
明確に定義されたドキュメントメタデータは、例えば図書館において、カードカタログを利用して読みたい本を簡単に見つけることができるように、「Document Consumer」
が、必要としている医療文書を簡単に見つけることができる、統一されたメカニズムの提供を可能にする。
- 83 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

このセクションは、メタデータが登録され、XDSレジストリにおいてそれに基づくクエリが行われるといった、ハイレベルなデータモデルについて述べる。また登録され、レジストリにおけるドキュメントエントリをフィルタリングするような特定の属性についても述べる。
10.4.7.1 XDS ドキュメントレジストリデータモデル
以下のエンティティはXDSドキュメントレジストリデータモデルに利用されている。
XDS Document Entry: 「Document Registry」アクタにより管理される情報エンティ
ティ。実際のXDSドキュメントを取り出すことのできる「Document Repository」アクタへのリンクと共に、XDSドキュメントの主要な特徴を述べたメタデータのセットを含む。
XDS Document: 「Document Repository」アクタに保存されているバイトのストリームであり、XDSドキュメントエントリにより指し示されている。
XDS Folder: いかなる方法であっても、１件かそれ以上のXDSドキュメントをグルー
プ化するロジカルコンテナが必要とされる（例：ソースケア提供アクティビティ、エピソード、ケアチーム、専門分野または病態など）。このような組織構造は多様な形で利用されている。センターやシステムによっては、フォルダは医療記録全体のインフォー
マルな情報細分化方法と見られている。一方で、フォルダが情報を作成したエンター
プライズやチームに関する正式なEHRの大部分を占めている場合もある。フォルダ
はXDSドキュメント（またはEHRCOMにおけるComposition）の組織化を提供する方法である。同一のXDSドキュメントエントリは、0件または複数のフォルダに属している
場合がある。
XDS Submission Set: XDSドキュメントが「Document Source」アクタによって登録されると、必ず厳密に１件の提出セットに含まれるようになる。XDS提出セットは0件ま
たは複数の新しいXDSドキュメントをグループ化し、すでに登録されているXDSドキュ
メントを参照、提出に関する一貫した記録を保証する。
XDS Submission Request: 提出リクエストには必ず1件のみの提出セット、0件または複数の新しいXDSフォルダと、XDSドキュメントの新規または既存のフォルダへの割り当てが含まれる。提出リクエストは「Document Repository」と「Document
Registry」において、原子的方法（Atomic Manner）で処理される（例：提出セットに含
まれる、または参照される全てのXDSドキュメントとフォルダ、そしてフォルダの包含に関する参照情報は、全てが登録されるか、全く登録されないかのどちらかとなる）。
これは全てが同時に「Document Consumer」アクタに提供されることを確実にするためである。

- 84 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

XDSフォルダ
10-n

当初の提出先医療連合ドメイン[EHR LR] 患者

関連

1

1

1

XDS提出セット所属

1

1

当初の提出先提出時
ローカル[EHR-CR]患者

参照

1

1-n

1

1
提出

XDSドキュメントエントリ

1

1
1

参照

レポジトリ内のXDSドキュメント

図 10.4.7-1 XDS ドキュメントレジストリデータモデル

10.4.7.2 XDSドキュメントエントリの属性
上記のレジストリデータモデルにおけるそれぞれのエンティティの属性は、複数の標
準のドキュメントヘッダ属性の中から選択されている（ITI TF-2：付録L)。ここでは以下のものが含まれる。
•••

ANSI/HL7 CDA R1-2000
HL7 CDA Release 2 (draft) Document header definition (Dec 2003
Committee Ballot)
EHR ENV 13606 (draft)におけるComposition Attributes

XDSは、最も関連性の高い文書を検索するため、最も一般的な利用例をサポートする、明確な焦点を持つ主要な属性のセットを定義している。これは以下を含む。

Patient Id
Service Start and Stop Time
Document Creation Time
Document Class Code and Display Name
Practice Setting Code and Display Name
Healthcare Facility Type Code and Display Name
Availability Status (Available, Deprecated)
Document Unique Id- 85 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

3つのコード (Document Class、Practice Setting、Healthcare facility Type) は特定の値（10から100）が入力されるコードセットであり、このため比較的容易な検索が保証されている。
この統合プロファイルでは、特定の文書を取り出すため、二次選択に利用される属性
や、追加のクエリ属性があわせて定義されている。ドキュメントレベルにおいては、これらはFine Grainedドキュメントタイプ（例：LOINC Classification）、キーワードとして利用できるイベントコードのリスト、文書の作成者と所属する機関、管理・差し替え・添付様々な変換と文書の関係、機密コード、言語コードなどが含まれている。
属性とその定義に関する総合的なリストは、IHE ITI登録トランザクション（Volume II
セクション3.12を参照）に記載されている。
10.4.8

XDS連合ドメインの概念

XDS連合ドメインは、医療文書共有に合意した、1件の「Document Registry」アクタの周囲に、明確に定義された「Document Source」アクタのセット、ドキュメントレポジ
トリのセット、「Document Consumers」のセットが組織化された管理構造である。
注記：「Document Source」「Document Repository」「Document Consumer」は複数の連合ドメインに属し、同一の、または異なる文書を共有している可能性がある。これは実装戦略であるため、ここでは詳
細には触れられない。
注記： XDS統合プロファイルは複数の連合ドメインの連携はサポートしていない。異なる連合ドメインにおける複数の「Document Registry」アクタの連携については、将来のIHE統合プロファイルにより言及されることが期待されている。

「Document Source」と「Document Consumer」の間で効果的な互換性を確実にす
るには、連合ドメインにおいて複数のポリシーが確立される必要がある。主要なテクニカルポリシーには以下が含まれる（連合ドメインが作成する必要のあるポリシー合
意のより詳細なリストは、ITI TF-1：付録Lを参照）。
1. 登録時に受け入れられるドキュメントフォーマット
2. ドキュメントのメタデータ、提出セットとフォルダ登録に利用される様々なボキャ
ブラリのバリューセットとコード化スキーム
3. ドキュメントレジストリに利用される患者IDドメイン（割当担当機関）
XDS連合ドメインの概念に関するより詳細な情報は、ITI TF-1: 付録 Kを参照。
10.4.9

患者ID管理XDS統合プロファイルの主要な焦点は「文書の共有」であり、それぞれの文書が関連する患者（患者ID）に正しく関連付けられていることが重要である。
「XDS Document Registry」は患者IDと患者の基本情報の典拠とはならない。 この
統合プロファイルでは、「Patient Identity Source」アクタを連合ドメインにおける患者
ID（マスター患者ID）のソースとして利用する。
- 86 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

注記：この統合プロファイルは、マスター患者IDが定義されていないようなシナリオにも簡単に拡張することができる（例：連合ドメインに患者IDソースが存在しない、など）。XDSドキュメントレジストリへのクエ
リの際、連合型患者IDの利用を必要とするといったオプションが、将来統合プロファイルに追加されることが期待される。

以下の原則が定義されている。
1. 連合ドメインにおいて、「Patient Identity Source」アクタに管理されている患者IDドメインが、特定の患者と文書をリンク付けるために、XDSドキュメントレ
ジストリによって利用される患者ID（と統合オペレーション）のソースとなる。この患者IDドメインはXDS Affinity Domain Patient Identification
Domain(XAD-Pid Domain)と呼ばれる。
2. XDS Affinity Domain Patient Identifier Domainに登録されていないIDと関連する患者に関連する文書の提出リクエストは、XDSドキュメントレジストリによって却下される。
3. 「XDS Document Registry」は、特定の患者情報（ソース患者ID、苗字、名前、
性別、誕生日）などを、監査や「Document Consumer」による確認のために保持する。この統合プロファイルは、参照が行われた際の情報の正確性や、情報が正しくアップデートされているかについては何も考慮していないため、これらのフィールド1をクエリマッチングキーとして利用してはならない。
4. 「XDS Document Source」と「Document Consumer」は異なる患者IDドメインに属している可能性もあるため、これらのシステムはレジストリのXAD-Pid
Domainにおける患者IDと、自らが利用するローカル患者IDとの間の相互参照を行う必要がある。このため、これらのシステムがIHE Patient Identifier
Cross-referencing統合プロファイル（付録E.3を参照）を利用することが望ましい。
5. 「XDS Document Registry」はXDS連合ドメインのポリシーにあわせ、文書のメタデータを確認する。「Document Registry」はこれらのポリシーに合致しない提出リクエストは却下しなければならない。
以下の図は、XADと呼ばれる患者IDドメインと、内部で「Document Source」と「Document Consumer」（順にドメインCとドメインD2）の間で相互参照が行われる2
つのEHR-CRを持つ、連合ドメインの例を示したものである。

1

当初の提出リクエストに含まれる文書のエラーを修正するため、レジストリに作成された新規ドキュメントエントリ
ーとともにさらに新規文書を提出、差し替えを行うことは可能である。しかし差し替えられた文書は利用が停止されただけで、オリジナルのメタデータはこの差し替えられた文書をポイントしたままとなるため、メタデータのみをアッ
プデートするメカニズムとはなっていない。
- 87 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

患者IDソース

患者IDフィード
Dm=XAD, Pid=Px

XDS Document
Registry
Dm=XAD
Pid=PxXDS Document Source

クエリ

XDS Document
Consumer

XDS Doc Entry

Dm=XAD
Pid=PxXDS Doc Entry

Dm=XAD
Pid=Px

提供＆
登録

XDS
Doc

Dm=XAD
Pid=Px
Dm=D2
Pid=PdXDS Document
Repository

Dm=C
Pid=Pc
XDS
Doc

患者ID
ドメインC

患者ID
ドメインD2

患者ID
ドメインXAD図 10.4.9-1 EHR-CR内部で患者ID相互参照を利用する連合ドメイン

10.4.10文書のライフサイクル

10.4.10.1

文書可用性ステータス「XDS Document Registry」に含まれるそれぞれのXDSドキュメントは、以下の可用性ステータスコードのいずれかに割当てられる。
Approved:

患者ケア用に入手可能（該当する場合、認証されていることが前提となる）

Deprecated: 古い情報であるが、クエリ、取り出しがまだ可能
XDSドキュメントの可用性ステータスは、「XDS Document Repository」と「XDS
Document Registry」が成功裏に提出リクエストを処理すると「Approved」にセットされる。

- 88 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

注記：ebXML Registry Servicesは原子的な提出を行うため過渡的に利用される「Status ofSubmitted」を定義している。この特定のステータスを外部からも確認できるようにすることは特に重要ではない。

「Approved」となっているXDSドキュメントは、オリジナルドキュメントソースが主な責任を持って「deprecated」に変更されることもある。これは患者の監督のもと行われる可能性もある。これはセキュリティポリシーの一環でもあり、XDSレポジトリ・レジストリに、所有権の実行を強制させることは、XDS統合プロファイルの焦点外である。文書のステータスを「deprecated」に設定した理由や、設定した関係者については、「XDS
Document Registry」監査証跡の一部としてトラッキングされる。これは要求されている機能の一部となっている。「deprecated」に設定された文書は、「Document
Consumer」クエリを通じて入手可能なままとなる。ステータスの変更以外は、「deprecated」ドキュメントエントリメタデータは「approved」ステータスの際と同じままとなっている。
「approved」または「deprecated」と設定されたXDSドキュメントエントリは削除されることもある。このような変更は、文書を「XDS Document Repository」と、「XDS
Document Registry」から関連するドキュメントエントリフォームを完全に削除するという決定に関連して行われる。XDS連合ドメインは文書削除に関連するセキュリティポ
リシーを確立する。このようなオペレーションをサポートするためのトランザクションについては、この統合プロファイルでは定義されていない。XDSドキュメントライフサイクルの概念に関する詳細な情報は、ITI TF-1: 付録Kを参照。
10.4.10.2

文書の関連性XDSドキュメントは以下の3つの方法のうちひとつで、先行する文書と関連付けられる。
••••

差し替え（Replacement）
添付（Addendum）
変換（Transformation）
変換‐差し替え（Transformation-Replacement）

これらのXDSドキュメントとの関係は「XDS Document Registry」においてトラッキン
グされる。文書内のメタデータに含まれる「Parent Relationship」属性が、このような関係タイプを記述するコード値となっている。オリジナルドキュメントは、Parentを持たないため、その結果「Parent ID」と「Parent Relationship」の部分は空白となる。
「XDS Document Registry」は、文書の関係が登録されていない、または「Deprecated」となっている提出を却下する。認知されているが、登録されていない文書との有効な関係を可能とするため、XDSはドキュメントスタブをサポートしている。
差し替え文書は既存文書の新しいバージョンである。差し替え文書は新たなドキュメ
ントIDを持つ。「ParentID」属性には、XDSドキュメントの前のバージョンと関連付けられているドキュメントエントリーのドキュメントIDが含まれている。また「Parent
Relationship」にはコード「RPLC」が含まれている。前バージョンのドキュメントエント
リーは、ステータスを「Deprecated」に変更する。
- 89 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

添付は以前の文書を参照する異なるXDSドキュメントであり、以前の文書の結果や所見を拡張したり変更したりすることができる。親文書を変更するが、親文書は患者記録の有効なコンポネントとして残り、そのステータスは「Approved」またはケアのために入手可能なままになる。添付XDSドキュメントメタデータは「ParentID」に以前の
XDSドキュメントバージョンのIDを含み、「Parent Relationship」にはコード「APND」を含む。
変換文書は他のフォーマットを機械翻訳して提供されるものである。変換文書の例として、DICOM Structured Reporting（SR）レポートから転換されたCDAドキュメントや、レポートをPDFなどのプレゼンテーションフォーマットに変更することなどが考えられる。
変換XDSドキュメントは「ParentId」に以前のバージョンのドキュメントIDを含んでいる
ほか、「Parent relationship」にはコード「XFRM」を含む。連合ドメインは変換XDSドキュメントがソースを置き換えるかどうかを見極めるためのルールを定義するが、一般的にこれは当てはまらない。もし当てはまる場合、追加Parent relationshipタイプ「RPLC」が利用される。
10.4.11

文書クエリ

クエリで返信される情報は以下のいずれかとなる。
••

Registry Objects Valuesのリスト（例：XDSドキュメントエントリ）
Registry Objects UUIDのリスト。これは「XDS Document Consumer」がクエリにマッチするエントリーの長いリストを受け取ったり、これらをサブセットごとに受け取ったりすることを可能にする。
10.4.12

転送モード

XDS統合プロファイルは、オフラインモードオプションがサポートされている提供・登録
トランザクションを除き、「Document Source」と「Document Registry」の双方において、全てのトランザクションのオンライン転送を定義する。オンラインモードにおいて、2つのアクタ（コンピューターアプリケーション）間のトランザクションは、アクタの同時のプレゼンスを必要とする（例：HTTP GET）。オフラインモードにおいては、2つのアクタ（コンピューターアプリケーション）間のトランザクションは、アクタの同時のプレゼンスは必要としない（例：電子メールエクスチェンジの保管・転送）。
1. HTTPベースのプロトコル（添付付きのSOAP）がオンラインオペレーションに利用される。
2. SMTPプロトコルがオフラインオペレーションに利用される。
10.5 実装戦略
XDS統合プロファイルは、3つの主要な実装戦略について言及している。これは、EHR-CRにおけるアクタの異なるグルーピング、そしてEHR-LRにおける異なる設定- 90 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profilesを反映したものとなっている。様々なワークフローや設定に対応する必要性を反映し、実装戦略は幅広いものとなっている。これらの実装戦略は、環境によっては共存することもある。またこの他の実装戦略も可能である。
Ø 戦略1: ソースでのレポジトリの設置。ひとつの情報システムが、システムが作成する文書の「Document Source」と「Document Repository」の役割を果た
し、「Document Registry」に登録を行う。
ケアが終了すると、EHR-CRはグループ化された「Document Repository」アクタ（同じシステム）に、文書の提出セットを登録する。そしてこの文書セット（新しく作成された文書、また以前に作成された関連文書）を「Document
Registry」アクタに登録する[2]。
連合ドメイン内の、それ以外の「Document Consumer」アクタは、「Document
Registry」アクタをクエリし、患者の全てのケアのフェーズに関連する文書を検索することができる[3]。ここではいずれの「Document Repository」アクタからも、これらの文書のいくつかを取り出すことができる[4]。

EHR-CR

2 登録

EHR-CR
Document
Registry

3 クエリ

Document Source
Document Consumer

Document
Repository

4 取り出し図 10.5-1 ソースにレポジトリを設置する実装戦略

Ø 戦略2：第三者によるレポジトリ。EHR-CRは「Document Repository」アクタとならず、第三者による「Document Repository」アクタのサービスを利用し、自らが作成する文書管理を委託する。最初にメタデータと文書トのセットを、この「Document Repository」アクタに提供 [1]、それにより「Document Registry」
アクタに、文書のセット（新たに作成された文書と、関連する過去の文書）の登録リクエストを転送する[2]。
全ての「Document Consumer」アクタが、患者ケアの全てのフェーズに関連する文書を検索するため、「Document Registry」アクタにクエリを行うことができる [3]。ここではいずれの「Document Repository」アクタからも、これらの文書のいくつかを取り出すことができる[4].

- 91 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

EHR-CR

EHR-CR
Document
Registry

3 クエリ

2 登録

Document Source

Document Consumer

4 取り出し1 提供＆登録

Document
Repository

図 10.5-2 第三者によるレポジトリを利用した実装戦略

EHR-CR

EHR-CR
3 クエリ
Document
Registry
Document Consumer

Document Source

1 提供＆登録

Document
Repository

4 取り出し図10.5-3 第三者による中央レポジトリ、レジストリを利用した実装戦略

Ø 戦略 3: 患者の直接の転送・紹介。「Document Source」アクタは患者に対するケアのフェーズを終了する。文書のセット（新たに作成された文書と、関連する過去の文書）を、「EHR-CR Document Consumer」（グループ化されたアクタ）とそして「Document Registry」にあわせてグループ化された「Document
Repository」[2]に、直接提供、登録[1]を行うことを決定する。
この場合、2つのEHR-CRのみをカバーするように定義されることもできるため、医療連合ドメインの範囲は非常に限られたものであることが考えられる。しかしここでは同じトランザクション[1]が適用される。この実装戦略では、アクタによってサポートされていても、他のトランザクションは「Document Consumer」には利用されない点に注意する。これは「Document Registry」と「Document
Repository」が、「Document Consumer」の内部に存在するからである。

- 92 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

EHR-CR

EHR-CR

Document Source

Document Consumer

Document
Registry

1 提供＆登録

Document
Repository

図10.5-4 「Document Consumer」に設置されているレジストリ、レポジトリを利用した患者の直接の紹介患者によるEHR-LRへのアクセスは、「Document Source」アクタ、「Document
Consumer」アクタを導入する特別なEHR-CR (例：ポータル)などを通じて可能となる。

- 93 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

11 Personnel White Pages (PWP)
Personnel White Pages（PWP）プロファイルは、エンタープライズ内の職員に対し、基本的な職員情報ディレクトリへのアクセスを提供する。この情報は、エンタープライズにおける多くの医療、非医療アプリケーションで幅広く利用される。情報は以下のように利用される。
1. 医療ワークフローの強化
i. コンタクト情報
ii. 電話番号
iii. 電子メールアドレス
2. ユーザインターフェイスの強化
i. ディスプレイ可能な名前
ii. タイトル
このPWPプロファイルはEnterprise User Authentication(EUA)統合プロファイルが提供するユーザID（ユーザ@部門）のディレクトリ情報を見つける方法を特定する。このプロファイルはアクセス制御と監査証跡については、その存在を前提とはしているが、定義づけは行わない。PWPプロファイルは、ヘルスケアエンタープライズ内での利用を目的としている。異なるヘルスケアエンタープライズ間でのPWPの共有をサポートするような拡張は可能であるが、このプロファイルではそれについて十分な言及は行われていない。PWPプロファイルはデジタル認証、暗号、デジタル署名、資格、役割などを含んだ、IHEロードマップにおける最初のステップである。
ディレクトリはヘルスケアオペレーションを越える利用例（HRオペレーションなど）をサポートする必要は無いが、適切にデザインされていれば重複利用について禁止しない。このプロファイルは、ヘルスケアに従事しない患者や他の個人などは対象としていない。
11.1 アクタ・トランザクション
図11.1-1は直接PWP統合プロファイルに関連するアクタと、アクタ間で関連するトランザクションを示している。EUAプロファイルに参加しているために、間接的に関連している他のアクタはここでは示されていない。

- 94 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Personnel White Pages
Consumer
Personnel White Pages 探知[ITI-23]

Personnel White Pagesクエリ [ITI-24]

DNS Server

Personnel White Pages Directory

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

トランザクション

オプション

Personnel White
Pages Consumer

ホワイトページ探知O

Vol2におけるセクション
ITI TF-2:3.23

ホワイトページクエリ

R

ITI TF-2:3.24

DNS Server

ホワイトページ探知R

ITI TF-2:3.23

Personnel White
Pages Directory

ホワイトページクエリ

R

ITI TF-2:3.24

11.2 PWP 統合プロファイルオプション
この統合プロファイルのために選択可能なオプションは、対応するアクタとあわせ、表11.2-1に示されている。必要に応じ、オプション間の依存関係が注記に示されている。
表 11.2-1 PWP Integration Profile - アクタとオプション
アクタ

オプション

Personnel White Pages
Consumer

オプション無しDNS Server

オプション無し

Personnel White Pages
Directory

オプション無し

Vol &セクション- 95 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

11.3 PWP 統合プロファイルプロセスフロー
PWPプロファイルは以下の利用例に対応する。
•

医療ユーザは「PWP Consumer」の役割を果たしている情報収集機器にログインする。医療アプリケーションは[ITI-23]を利用し、「DNS Server」アクタにクエリを行い、PWPディレクトリを発見する。医療アプリケーションは[ITI-24]ユー
ザ名を利用し、PWPディレクトリにクエリを行い、ユーザのファーストネーム、ミドルネーム、ラストネームを表示する。西洋系、アジア系双方の名前表記をサポートするような情報フィールドが提供される。

•

医療ユーザは医療データを取得する。アプリケーションは、データ記録にユー
ザの組織IDを組み込むため[ITI-24] PWPディレクトリにクエリを行い、ユーザの基本情報を取り出す。

•

ユーザは同僚に対し、電子メールでこのレポートを送信する必要がある。アプ
リケーションは送信先のユーザーを特定するため、ユーザが [ITI-24] PWPディレクトリを検索することを許可する。

•

ユーザは既存の医療レポートを閲覧し、記録にイニシャルが登録されていることを確認する。ユーザシステムはレポートのイニシャル確認のために、PWPディレクトリにクエリを行い、システムは表示可能な名前を表示する。
Personnel White
Pages Consumer

DNS Server

Personnel White
Pages Directory

Personnel White Pages
探知[ITI-23]

Personnel White Pagesクエリ[ITI-24]

図 11.2-1: PWPプロファイルの基本的なプロセスフロー- 96 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 A: アクタについて
アクタはエンタープライズ内のオペレーショナル活動に関する情報の作成、管理また
は実行を行う情報システムまたは情報システムのコンポネントである。以下は、IHE
ITインフラ統合プロファイルに利用されるアクタの定義である。
Audit Repository – このアクタは監査イベントに対するレポジトリを提供する。IHE
では、監査レポジトリにどのような分析やレポーティング機能が導入されるべきかについては、特定しない。
Client Authentication Agent – ユーザ認証のローカル管理を提供する。
Context Manager – このアクタは2つ以上のContext participantアクタ（Patient
Context ParticipantまたはUser Context Participant）間のコミュニケーションのブローカーの役割を果たす。ユーザや患者サブジェクトの通過をサポートする。
Display – 情報ソースから特定の情報やドキュメントをリクエストし、表示することのできるシステム。
Document Source – 「Document Source」アクタは文書の作成、発行者であり、また文書を「Document Repository」アクタに送信する役割を果たす。続いて「Document Registry」アクタに文書を登録するため、「Document Repository」アクタにメタデータを提供する。
Document Consumer - 「Document Consumer」アクタは特定の基準に合致する文書を特定するためのクエリを「Document Registry」アクタに行い、1件または複数の「Document Repository」アクタから、選択された文書を取り出す。
Document Registry – 「Document Registry」アクタは、ドキュメントエントリにおいてそれぞれ登録された文書のメタデータを維持する。これは、保存されているレポジト
リ内の文書へのリンクも含まれている。ドキュメントレジストリは「Document
Consumer」アクタからの、特定の基準に合致する文書に関するクエリへ返信を行う。
またドキュメントの登録の際、ヘルスケア特有のテクニカルポリシーの一部強化を行う。
Document Repository – 「Document Repositry」はこれら文書の一貫したストレー
ジ、そして適切な「Document Registry」への登録を行う。続いて「Document
Consumer」によって行われる文書取り出しのため、URIをドキュメントに割り当てる。
DNS Server – このアクタは信頼されるロケーション情報を持つ。
Information Source – 特定の情報またはドキュメントに関するリクエストに返答し、リクエストを行ったアクタに提示可能な情報を返信するシステム。

- 97 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Kerberos Authentication Server – エンタープライズユーザに対する集中した認証を提供する。
Kerberized Server – このアクタを含むサービスがさらに利用するためのユーザ認
証情報を受信する。
Patient Context Participant – このアクタは、「Context Manager」アクタからの通信を受け、患者コンテクストの設置、コンテクストの変更に対応することで、コンテクス
ト共有環境に参加する。このアクタは全ての患者コンテクストの変更に対応する。このアクタを含むアプリケーションが患者選択機能を持つ場合、このアクタは患者コンテク
ストを設定する。
Patient Demographics Consumer –ユーザが、ポイント・オブ・ケア（POC）において情報と患者を関連付けることを可能にする。
Patient Demographics Supplier – 基本情報または来院関連情報フィールドを通じて検索することのできる患者情報のレポジトリ。
Patient Identifier Cross-reference Consumer – このアクタは患者IDドメイン内のシステムが、「Patient Identifier Cross-Reference Manager」アクタのサービスを利用し、異なる患者IDドメインにおける患者のIDを特定することを可能にする。
Patient Identifier Cross-reference Manager – 明確に定義された患者IDドメインに対応する。「Patient Identity Source」アクタからそれぞれの患者IDドメインに提供された情報に基づき、患者IDドメイン間における患者IDの相互参照を管理する。
Patient Identity Source –「Patient Identity Source」アクタはそれぞれの患者のユニークIDを提供、IDの特徴情報を維持する。それぞれの患者IDドメインは患者のIDを指定、他のアクタ（「Patient Identifier Cross-reference Manager」アクタまたは「Document Registry」アクタなど）に、患者のIDに関する全てのイベント（作成、アッ
プデート、統合）を通知するため、このアクタを必要とする。
Personnel White Pages Consumer – このアクタは、PWPディレクトリ内で見つけることができる情報を利用する。
Personnel White Pages Directory – このアクタはエンタープライズにおける職員に関し、信頼のおけるPWP情報を含む。
Secure Node – システムにこのアクタが存在しているということは、この他全てのア
クタと、IHEに関連しないソフトウェアが、ユーザー認証、コミュニケーション認証とセキュリティポリシーに関して、IHEルールを遵守していることを意味する。

- 98 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Time Client – NTPプロトコル、そしてNTPまたはSNTPアルゴリズムを利用し、１件または複数のタイムサーバの同期化を行う。タイムサーバとのシンクロに基づき、UTCとローカルコンピューターシステムクロックの同期化も維持する。
Time Server – NTPタイムサーバをタイムクライアントに提供する。UTCマスタークロック（例：サテライトタイムシグナル）と直接同期化されているか、タイムクライアントが他のタイムサーバーとグループ化されていることで同期化が行われる。
User Context Participant – ユーザコンテクストの変更に関する通知を受け取り、それを含むアプリケーションのためにフォローを行う。

- 99 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 B: トランザクションについての記述
トランザクションとは、標準ベースのメッセージを通じて必要な情報をやりとりする、ア
クタ間のインタラクションである。以下はIHEにより定義されているトランザクションの簡単な記述である。
1. Maintain Time: 時間同期化を維持するために利用されるNTPトランザクショ
ン
2. Get User Authentication: クライアント認証エージェントはKerberos認証サーバからユーザ認証をリクエストする。ユーザが認証されると、Kerberos認証
サーバはTicket Granting Ticket (TGT)を返信し、将来のアクティビティを最適化する。
3. Get Service Ticket: サービスに利用するためのチケットを、Kerberosプロト
コルを利用して入手する。
4. Kerberized Communication: Kerberized Communicationトランザクション
は、ローカルクライアントとリモートサーバとの間の接続の一側面である。
5. Join Context: 「Context Participant」アクタが「Context Manager」アクタの位置を特定、コミュニケーションを確立することを可能とする。
6. Change Context: コンテクスト変更に関するトランザクションの開始・終了に必要な全てのメッセージを含む。
•••

リクエストを引き起こす、参加アクタによるコンテクスト変更リクエストの開始リクエストを引き起こしたアクタへの調査結果のデリバリーと、関連する返信の表示「Context Manager」アクタに対するコンテクスト変更決定の伝達

7. Leave Context: 「Context Participant」アクタが、「Context manager」アクタに、通信を切断することを通知。
8. Patient Identity Feed: 「Patient Identity Source」アクタが「Patient
Identifier Cross-Reference Manager」アクタに対し、患者IDに関連する全てのイベント（作成、アップデート、統合など）に関する通知を可能にする。
9. PIX Query: このトランザクションは「Patient Identifier Cross-reference
Consumer」が、「Patient Identifier Cross-reference Manager」アクタのサービスを利用し、異なる患者ID内の患者IDを発見することを可能にする。
10. PIX Update Notification: 「Patient Identifier Cross-reference Consumer」
が「Patient Identifier Cross-reference Manager」アクタにより、「Consumer」- 100 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

が興味を持つ患者IDドメインの全ての患者のIDの変更の通知を受けることを可能とする。
11. Retrieve Specific Information for Display: ディスプレイシステムにより患者に関する特定の情報へのリクエストが行われると、表示可能なフォーマット
で情報が返送される。
12. Retrieve Document for Display: ディスプレイシステムは、情報ソースの所
有下にあるユニークIDを持つ持続文書のインスタンスをリクエストし、表示可
能なコンテンツを受信する。
13. Follow Context: コンテクストの変更を、対応するアクタに伝播する必要のあ
るメッセージを構成する。
••「Context Manager」アクタによる全ての「Context Participant」アクタの調
査、また全ての関連する返信に関する「InstigatingParticipant」アクタによる表示「Context Participant」アクタによるコンテクストデータの取り出し

14. Provide and Register Document Set：「Document Source」アクタは、文書セットの提供・登録トランザクションを開始する。提出されたセットの中のそれぞれの文書について、「Document Source」アクタは、「Document
Repository」に対し、文書を不透明なオクテット・ストリームとして、そして対応するメタデータという形で提供する。「Document Repository」は、一貫してこ
れらのドキュメントを保管し、また「Document Source」アクタから受信したドキュメントメタデータを転送することで、文書登録トランザクションを利用し、「Document Registry」に文書を登録する役割を果たす。
15. Register Document Set：「Document Repository」アクタは文書セット登録
トランザクションを開始する。このトランザクションは、登録される文書に関するメタデータを提供することで、「Document Repository」アクタが「Document
Registry」に１件または複数の文書を登録することを可能とする。このドキュメ
ントメタデータは、「Document Registry」においてXDSドキュメントエントリ作成に利用される。「Document Registry」アクタは、文書の登録が許可される
前に、ドキュメントメタデータが有効であることを確認する。もし１件または複数の文書のメタデータの確認に失敗した場合、文書セット登録トランザクションの全体が失敗する。
16. Query Registry：レジストリへのクエリトランザクションはケアプロバイダ（EHR-CR）に代わり、「Document Consumer」アクタが、「Document
Registry」に対して実行する。「Document Registry」アクタはレジストリを検索し、プロバイダが指定したクエリ基準に合致する文書を特定する。「Document
Registry」アクタは合致したメタデータを含む文書に関するロケーション、ドキュ
メントID情報を含むドキュメントエントリーリストを返信する。
- 101 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

17. Retrieve Document：「Document Consumer」アクタは文書取り出しトランザ
クションを開始する。「Document Repository」は「Document Consumer」に指定された文書を返送する。
18. 意図的に空白
19. Node Authentication: このトランザクションは全てのネットワークコミュニケーションに含まれている。DICOM、HL7、そしてHTML コネクションは全て、Protected Healthcare Information (PHI)における双方向認証、そしてコミュニ
ケーション認証に関し、IHEのスペックを遵守する必要がある。IHEはPHIを転送する他のプロトコルがどのように双方向認証と許可を実行するの特定は行
わないが、他のプロトコルがこのような認証・認可を行うことを要求している。
20. Record Audit Event:監査レポジトリに対し、セキュアノードからの監査イベン
ト記述のデリバリー
21. Patient Demographics Query:ユーザが入力した基本情報の一部、または全体との合致に基づき、１件の患者基本情報ソースの情報を検索し、患者の基本情報を返送する。
22. Patient Demographics and Visit Query: ユーザが入力した基本情報・来院情報の一部、または全体の合致に基づき、１件の患者基本情報ソースから情報を検索し、患者の基本情報を返送する。
23. Find Personnel White Pages: このトランザクションはDNSにクエリを行い、LDAPディレクトリを検出する。
24. Query Personnel White Pages: このトランザクションは、PWPディレクトリ
へのリードオンリーアクセスを提供する。

- 102 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 C: IHE 統合説明書
IHE統合説明書は、ベンダにより作成、発行されるドキュメントで、ベンダの製品がIHEテクニカルフレームワークを遵守していることを記載するものである。説明書は製品がIHEアクタと統合プロファイル（ITI TF-1:2に記載されている）の中でどのIHE機能をサポートしているかを特定する。
これらのコンセプトの知識を持つユーザは統合説明書を利用し、製品が補完システム
と共にどのレベルの統合をサポートするのか、そしてこのような統合が、どのような医療・オペレーションへの利益をもたらすかについて見極めることができる。統合説明書
は特定の標準(例：HL7、IETF、DICOM、W3Cなど)遵守を示す説明書と共に利用されることを意図している。
IHEはベンダに対し、IHEアクタと統合プロファイルの実装をテストするプロセスを提供する。「Connect-a-Thon」と呼ばれる、複数の参加者によるインタラクティブなテストイ
ベントであるIHEテストプロセスは、ベンダに対して有効なフィードバックや、ベンダの実装の適合性に関するベースラインを提示する。プロセスは個別の製品の遵守の評
価や保証を行うものではない。「Connect-a-Thon」の結果発表や、ベンダのIHE統合
説明書へのアクセスを提供するにあたり、IHEとそのスポンサー組織は、ベンダのIHE統合説明書や製品に関するベンダの主張に関して、正確性や確認を証明する必要はない。
重要：IHE統合説明書に関する正確性やその確認はベンダが唯一責任を負う。IHE
は、製品の統合機能情報を求める関係者を考慮し、IHEを通じてベンダの統合説明書が入手できるよう便宜を図っているだけである。IHEとそのスポンサー組織は、IHE
統合説明書や製品に関する評価や承認は行っておらず、IHEやスポンサー組織は誰に対しても、IHE統合説明書の利用や説明書を信頼したことによる、ビジネスの中断や収益の損失をはじめとする、直接的、間接的、偶発的、結果的な苦情や損失に関して責任を持たない。

- 103 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

C.1 IHE統合説明書の構造とコンテンツ
製品に関するIHE統合説明書には以下が含まれる。
1. ベンダ名
2. IHE統合説明書が適用されている製品名（販売されている商品名）
3. IHE統合説明書が適用されている製品バージョン
4. 発行日、オプションでIHE統合説明書の改定日
5. 「この製品は、以下に示されるIHE統合プロファイル、アクタ、オプシ
ョンをサポートするために、IHEテクニカルフレームワークで求められている全てのトランザクションを実装している」という記述
6. 製品によってサポートされているIHE統合プロファイルと、それぞれの統合プロファイルにおいて、サポートされているIHEアクタのリス
ト。それぞれの統合プロファイル・アクタの組み合わせにおいては、
IHEテクニカルフレームワークで定義されている１件または複数のオプションも記載される。プロファイル、アクタとオプションはIHEテク
ニカルフレームワーク Volume Iで定義されている名称を使う（注記：ベンダはそれぞれの統合プロファイルで参照されているテクニ
カルフレームワークのバージョン番号を提示してもよい）。
統合プロファイルの実装は、選択されたオプションとアクタで必要とされている全てのトランザクションの実装が行われていることを指す。
説明書はまた以下の情報に関する参照情報やインターネットリンクを含む。
7. ベンダの統合説明書が掲示されている特定のインターネットアドレ
スまたは
8. 製品に実装されているIHEトランザクションに関連して、ベンダによる標準遵守説明書（例：HL7、DICOMなど）が掲示されているURL
9. 一般的なIHE情報を含むIHEイニシアチブのウェブサイト
（www.himss.org/ihe）。
IHE統合説明書はIHE機能に直接関連していない製品の側面について、プロモーショ
ンや広告の実施は意図していない。

- 104 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

C.2 IHE統合説明書のフォーマット
それぞれの統合説明書は以下に示されるフォーマットに沿ったものとなる。ベンダはカバーページや、自らの製品ドキュメンテーションポリシーに沿い、必要な情報を追加しても良い。
日付

IT統合説明書2003年10月12日

ベンダ名

製品名

バージョン

Any Medical Systems社

IntegrateRecord

バージョン 2.3

この製品は、以下に示されるIHE統合プロファイル、アクタ、オプションをサポートするために、IHEテク
ニカルフレームワークで求められている全てのトランザクションを実装している

実装されている統合プロファ
イル

実装されているアクタ

実装されているオプション

Retrieve Information for
Display

Information Source

無し

Enterprise User Authentication

Kerberized Server無し

Patient Identity Crossreferencing

Patient Identifier Crossreference Consumer

PIX Update Notification

ベンダのIHE情報に関するインターネットアドレス： www.anymedicalsystemsco.com/hl7

IHE情報へのリンク
北米：www.himss.org/ihe

欧州：www.ihe-europe.org

日本：www.jira-net.or.jp/ihe-j- 105 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 D: ユーザ認証テクニックーパスワード、バイオメトリクス、トークン
認証テクニックは、「ユーザの知識」「ユーザ自身」「ユーザが持っているもの」のいず
れかを活用して行われる。今日、様々な認証テクニックが利用されているが、これらのテクニックをサポートする技術は、十分に標準化されてはいない。また認証に利用される技術セットを特定することを避ける、セキュリティ上の理由もある。
Kerberosプロトコルはもともと、いかなる認証テクニックにも利用できるよう定義されている。Kerberosは様々なトークンやバイオメトリクスを含む、幅広い認証技術をサポートすることが明らかにされている。これらの技術の導入には、プロプラエタリーのコンポネントが含まれることが多い。ここではユーザワークステーション、そして照合するコンポネントが認証サーバにおいて、対のプロプラエタリコンポネントが追加される場合が多い。ユーザ認証が終了すると、続くKerberosトランザクションは同じである。
これらの拡張はまだ標準化されていない。Kerberosの利用に関するIHEスペックは、
特定のサイトにおけるこれらの拡張を阻止するものではなく、またこの拡張が機能することを保証するものでもない。
エンタープライズユーザ認証のために特定されたKerberosシステムは、ユーザを認証するため、ユーザ名・パスワードシステムと共に、チャレンジ・レスポンスシステムを活用する。パスワードの最小限のサポートは、IHE「Enterprise User
Authentication」の標準化されたベースラインを提供する。Kerberosは、強度の高い
パスワードを促進する、一極集中型のパスワードポリシーの実施を可能にするが、このようなパスワードポリシーはIHEの焦点外である。またKerberosは強度の低いパス
ワードの利用を阻止するものではない。パスワード強度ポリシーはサイトセキュリティ
管理者によって選択・実施される必要がある。

- 106 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 E: プロファイルの組み合わせ利用
E.1 RID、EUAとPIX統合プロファイルの組み合わせ利用
Retrieve Information for Display統合プロファイルは、個別に利用された場合、「Display」アクタ、「Information Source」アクタにおいて、同一の患者IDドメインが利用されることが前提となる。さらに、「Information Source」アクタにおけるユーザ認証についても明確には言及されていない。この付録においては、これら2点に対応する
ため、他のIHE統合プロファイルと、Display統合プロファイルにおける情報取り出しト
ランザクションの組み合わせについて議論する。
Patient Identifier Cross-referencing統合プロファイルと組み合わせて利用されると、Retrieve Information for Display統合プロファイルは、Information Sourceアクタが、自らのドメインで利用されているものとは異なるIDドメインの患者IDとマッピングを行う
必要の可能性について考慮するようになる。これらの統合プロファイルを組み合わせ
た利用は、「Information Source」アクタと、「Patient Identifier Cross-reference
Consumer」アクタをグループ化することで実現する。これは図E-1で示されている。
同様に、「Information Source」アクタは、Enterprise User Authentication統合プロフ
ァイルを実装するアクタによるユーザ認証リクエストに基づき、特定のアクセス制御を行うこともある。このような統合プロファイルを組み合わせた利用は、「Display」アクタ
を「Client Authentication Agent」アクタ、そして「Information Source」アクタと「Kerberized Server」アクタを組み合わせることで実現する。これもまた図E-1で示されている。

Patient Identifier
Cross-ReferenceManager

Patient Identifier
Cross-Reference
Consumer

表示のために特定の情報取り出し

Display

表示のために文書取り出し

ClientAuthentication
Agent

Information
SourceKerberized
ServerKerberized
Authentication
Server

図 E-1. 複数の統合プロファイルを実装するアクタを組み合わせた利用- 107 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

E.2 RIDとXDSの統合
RID 表示のための文書取り出しトランザクション [ITI-12]は、XDS 文書取り出しトラン
ザクション[ITI-17]と互換性を持つ。このため、表示のための文書取り出しトランザクシ
ョンを実装するRID情報ソースは、XDS 文書取り出しトランザクション実装のために利用することができる。このインスタンスにおいては、RID情報ソースはセキュアノードでなければならない[ATNA参照]。

E.3 PIXとXDSの統合（XAD-PidドメインまたはEHR-CRドメインのいずれかにおける）XDSトランザクション
で管理されている患者IDは、患者IDに関連する患者ドメイン（指定機関のOID）を含む。この一義的な患者IDは文書内の患者IDと合わせて利用することも推奨されている。XDSは、ドキュメントコンテンツに中立であるため、XDSレポジトリは、文書内に含まれている患者IDが、文書に関連するドキュメントエントリ内のレジストリに管理されている患者IDと一貫しているかについての確認は行わない。

PIX Patient
Identity Source

患者IDフィード
Dm=XAD, Pid=Px

PIX Manager

PIX Manager

XDS Document
Registry

Dm=C
Pid=Pc
Dm=XAD, Pid=Px

Dm=D2
Pid=PdDm=XAD, Pid=Px
Dm=XAD
Pid=PxXDS Document Source

クエリ

XDS Document
Consumer

XDS Doc Entry

Dm=XAD
Pid=PxXDS Doc Entry

Dm=XAD
Pid=Px

PIX
Id
Con
sum
er

XDS
Doc

提供＆
登録

Dm=XAD
Pid=PxXDS Document
Repository

PIX
Id
Con
sum
er
Dm=D2
Pid=Pd

Dm=C
Pid=Pc

患者ID
ドメインC

XDS
Doc

患者ID
ドメインD2

患者ID
ドメインXAD- 108 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

図 E.3-1連合ドメインにおけるPIXマネジャーを持つ患者ID相互参照
図E.3-1 は（XADと呼ばれる）患者IDドメインを持つ連合ドメイン、そしてDocument

Sourceドメイン、Document Consumerドメイン（それぞれC、D2）双方にある「Patient
Identifier Cross Reference Manager」により、相互参照が行われる2つのEHR-CRの事例である。
「Document Source」は、IHE PIX統合プロファイルを活用し、XAD-Pidドメインにある独自の患者IDの相互参照を実施することを選択してもよい（図参照）。「XAD Patient
ID Source」からの患者IDフィードトランザクションが、「Document Source」に利用されている「Patient Identifier Cross-Referencing Manager」にインプットを提供しても良い。「PIX Manager」はEHR-CRの内部で利用されるか、XDS連合ドメイン内で共有されても良い。

E.4 PWPとXDSとの統合
XDS統合プロファイルにおける「XDS Document Source」アクタは、XDS 文書セット
登録[ITI-14]トランザクション、 文書セット提供・登録[ITI-15] トランザクションにおいて、「autherPerson」「legalAuthenticatorName」フィールドに必要な情報を得るため、
PWP Personnel White Pagesへのクエリ [ITI-24] トランザクションの活用を選択しても良い。
PWPトランザクションはITI-TF 2:3.24.4.1.2.3.1において、HL7 XCNフォーマット（拡張された複合ID番号と、人材名）に情報を含む「lang-x-ihe」の属性を持つ「cn」を人材情報として定義している。これらのフィールドはPWP統合プロファイルではオプションとなっている。ケア提供組織はこれらの情報フィールドを自らのPWPディレクトリ内に作成、XDS活動をサポートするためにITI-24トランザクションを活用することができる。これは必要とされる依存関係ではないが、「Document Source」アクタを「PWP
Consumer」アクタとグループ化する理由となりうる。
PWP統合プロファイルは人材情報のみを提供する。組織情報は、組織オブジェクトと共にLDAPディレクトリを拡張するなど、別の手段を通じて入手される必要がある。

E.5 PDQ とXDSの統合
Patient Demographics Query(PDQ)統合プロファイルは、「XDS Document
Consumer」アクタや「Document Source」アクタに対し、XDS連合ドメインの患者IDドメインを調べるために、XDS統合プロファイルと組み合わせて利用される。この場合、「Patient Demographics Supplier」アクタは、一方で「XDS Patient Identifier
Source」アクタとグループ化され、またもう一方で「Patient Demographics
Consumer」アクタは、患者の特徴に基づきクエリを行うことで、XAD患者IDドメインから患者ID候補リストを入手したいと考える、「Document Source」や「Consumer」とグ
ループ化される必要がある。これはPIX統合プロファイルを利用した、よりシンプルな
ソリューションを提供するものである。
- 109 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles- 110 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 F: 標準団体に対する要請
以下の要請が標準団体に対して行われており、現在検討中となっている。これらの標準拡張は新たな統合プロファイルの追加や、統合プロファイルの組み合わせを可能
にする。
HL7
•
•

HL7 version 2 messagingのKerberos化
Kerberized CCOW Context Participantsのサポート

DICOM• DICOMメッセージのKerberos化におけるSOPクラスの追加- 111 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 G: セキュリティへの考慮
G.1 プロファイル間の考慮
IHEに遵守するシステムは、プライベートなヘルスケア情報を処理することになる。これは国家が制定するプライバシー規制、また州や契約に基づくリクワイヤメントの対象となる。IHEインフラプロファイルは、これらの情報を保護するために必要なセキュリ
ティメカニズムについて、総合的に定義を行うものではない。Enterprise User
Authenticationプロファイルはこの問題を解決するソリューションの一部を提供する。
IHEは、ノードにおいて以下の特徴をもつアクタが導入されることを前提としている。
•••

それぞれのノードは、そのオペレーションに適用されるセキュリティポリシーや手続きを持つ。これはヘルスケアエンタープライズセキュリティポリシーの一部であることが前提となっている。
ノードの境界の外側にいる全てのユーザ（人やアプリケーションプロセス）は、
ユーザやアプリケーションを認証するためのアクセス制御手続きに従う。
必要とされる全ての監査証跡イベントが取り込まれ、記録される。

このフレームワークのプロファイルは以下の環境を前提としている。
• 物理的なセキュリティ環境• 機器は物理的に保護され、アクティブにモニターされているエリアに設置されていることを前提としている。これは特に、他の患者の安全やプライバシ
ー、オペレーションに関する問題から、超音波・放射線機器において考えられる。同様に、HISシステムと様々なアーカイブも保護されていることが普通である。PACSワークステーションなどの機器は保護されていないエリアに置かれていることがあるが、病院のスタッフがモニタリングしており、アクセスが制限されている場所に設置されている。ここでは物理的なセキュリ
ティメカニズムにより、機器への変更の恐れが防止されていることが前提となっている。
• コンピューターを接続するネットワーク機器もまた、不正な接続や変更を防ぐため、物理的に保護されていることが前提となっている。病院の治療を行うエリアにおいては、ネットワーク機器は天井やケーブルウェイ、鍵がかけられたキャビネットや他の保護されたエリアに置かれている。不正が行われないよう、スタッフがモニタリングを行っている場合が多い。
• 事務室などリスクの高い病院の他のエリアにおける物理的なセキュリティを保証するための、手続きやオペレーションが存在している。
• ホームオフィスなどのリモートロケーションは物理的に保護されていないた
め、機器を保護するため他の手段が利用される。これはVPN接続や
HTTPS暗号化などの技術の利用が含まれる。暗号化やVPNの利用は、
物理的セキュリティの完全な代替にはならないが、包括的な保護システムの一部となりうる。

- 112 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles••

パーソナル、プロフェッショナル双方の目的で利用されているホームコンピ
ューターの保護は難しい。悪意のあるソフトウェアによる不用意な変更や、そのようなソフトウェアの利用が禁止される。

ネットワークセキュリティ環境• ネットワークの物理的なセキュリティに加え、監視されていないシステムによるネットワークアクセスからの保護が行われる。これは従来ファイやウォ
ールやVPNなどのメカニズムを通じて提供される。

脅威となるプロファイルとしては、以下のものが考えられる。
• 故意の、または不用意な悪用• 個人の利益のため、または悪意のある、または復讐のため、または興味から来る悪用。悪用する人物は、システムやソフトウェアに限られたアクセスしか持たず、システムの内部構造を熟知していないことが前提となっている。
• インターネットハッカーからによる攻撃など、特定のターゲットがないランダ
ムな悪用。
脅威プロファイルはまた、以下の脅威は存在しないか、または保護対策が採られていることを前提としている。
• システムアドミニストレーター、システム開発者や他の専門家による悪用• 軍や、敵意を持つ政府による行為• 組織化された犯罪攻撃
IHEはIHEヘルスケアアプリケーションの範囲内にあるITシステムに関連するセキュリ
ティ要件のみに言及する。ネットワーク攻撃やウィルス保護などに対するセキュリティ要件に関しては言及しない。
現在の暗号アルゴリズムは、パフォーマンスへのインパクトが大きいため、IHEでは暗号化の利用を義務付けない。ほとんどの病院ネットワークは、物理的、手続きを通じたメカニズムにより、適切なセキュリティを提供している。暗号化によるパフォーマン
スへのさらなる負担は、これらのネットワークに必要とはいえない。このプロファイル
は暗号化を全体のセキュリティの一部として利用することは許可している。

G.2 XDSセキュリティの考慮
セキュリティとプライバシー
連合ドメインに参加する、全てのケア提供組織のセキュリティやプライバシーポリシーの調整を行うことは、大きな挑戦である。ここではセキュリティ手続きやその目的、監査、記録保守などに関する合意を取り付ける必要がある。このような合意は、人事手続きなど、他のエンタープライズポリシーに変更が生じることもある。連合ドメインメン
バーは、ドメインの他のメンバーに対し、自らが発行したデータへの全面的なアクセス提供を行う。このような関係においては、ポリシー、手続き、アクティビティの維持が継- 113 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

続的に実施されることを保証するため、緊密なパートナーシップが必要となる。もし法律に変更が生じた場合、関連するポリシーについて、グループ全体で調整が行われる必要がある。グループメンバーに対する変更が企業で行われた場合、それはポリシーにも影響する。セキュリティに関する事件が起きた場合も、グループ全体で問題が管理されなければならない。これはまた一時的な事件としてではなく、長期的な活動として管理される必要がある。
特定の問題分野としては、以下が考えられる。
•

認証されたアクセスと変更に関するポリシー。アクセスポリシーの詳細はエンタープライズによって異なるため、一致しない部分の見直しが必要となる。連合ドメインにおいては、さらに新たなポリシー要件が必要になる。例えば、雇用に関する変更（雇用や解雇）が起きた場合、その情報は他のメンバーに迅速に通知される必要がある。プライバシー情報の変更（離婚など）も、特定の医療機関のみならず、連合ドメイン全体に通知される必要がある。

•

監査証跡とアクセス記録の維持は、従来それぞれの医療機関内部で行われる、非常にデリケートな活動であるが、これについても、連合ドメイン全体で適切に調整される必要がある。

•

法律や規制の変更は個別医療機関のポリシーに影響を与えるだけでなく、連合ドメインの関係契約、ポリシー、手続きに反映される必要がある。

•

患者による情報アクセス、ID管理。患者は従来セキュアではないコンピューターを所有している。また患者はセキュリティのための手続きに従わないことも多い。

•

境界を越えたPHIコミュニケーションは、法的な問題がかかわってくることが多い。

Volume IIのITI TF-2付録Jは、連合ドメインメンバー間で調整されるべきである脅威、目的、ポリシーや緩和対策などに関する詳細を述べている。
XDS統合プロファイルは以下の2点の理由から、このようなセキュリティやプライバシ
ーポリシーに関して規定を行っていない。まず第一に、法的枠組みやヘルスケアシス
テムのタイプによりソリューションは幅広いものとなり、このためXDSにも柔軟性が求められることは明白である。このドメインにおける決定は、XDSアクタの実装に一定のインパクトを与えるが、これらは最小限であることが予期される。

- 114 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNA

コメント [MS2]: 明確ではないが、おそらく離婚などにより元配偶者の医療情報へのアクセスが制限されることを指していると思われる

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 H: 意図的に空白
付録 I: 意図的に空白- 115 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 J: XDS ドキュメントのコンテンツとフォーマット
XDS統合プロファイルは、共有されるXDSドキュメントのコンテンツ構造やフォーマット、「XDS Document Registry」へのメタデータのマッピング、XDSドキュメントメタデータのコーディング、XDS提出リクエストを開始するイベント、共有のためのXDSフォルダの利用に関するポリシーなど、複数のポリシーについて、意図的にXDS連合ドメインに決定させるようにしている。
エンタープライズを超えたドキュメント共有に関して十分な経験が得られるまで、XDS
統合プロファイルの利用に関して、共通のプラクティスやベストプラクティスを確立することは不可能という点を認識しておくことは重要である。このためIHEは今回このトピックに関して特定の提案をすることは控えている。
IHEはまた、この統合プロファイルにあわせ、コンテンツ主体の統合プロファイルが必要である点について認識している。将来様々なIHEドメイン(Patient Care
Coordination, Cardiology, Laboratory, Radiology, IT Infrastructureなど)において、ドメイン内でのXDS利用をより洗練したものにするためのIHE統合プロファイルが作成されることが期待される。これらのコンテンツ主体の統合プロファイルはXDSに依存することになると考えられるが、共有される文書の形式、またはフォルダと提出セッ
トといったXDS機能の利用をさらに強制するものになるだろう。
コンテンツの中立性
XDSはコンテンツに中立なものである。これは「XDS Document Repository」から取り出すことのできるフォーマット、コンテンツ、ドキュメントの構造や表示を指定したり規制したりするものではない。XDS統合プロファイルの利用が、連合ドメインにImmediate valueをもたらすため、これらのプロファイルはメンバーが提供する文書に適用可能でなければならない。このため、コンテンツに禁止事項を与えることは、
XDS統合プロファイルの実用性と適用を制限するだけになってしまう。同様に、医療連合ドメインは、指示されたコンテンツフォーマットリストに示されていない、新たな標準にも対応可能でなければならない。
IHEはXDS連合ドメインに対し、可能な限り、文書が幅広く適用されている標準（HL7
CDA, CEN ENV 13606, ASTM CCR, DICOM Composite Objectなど)に遵守する
ようなルールを導入することを、強力に推奨している。
ドキュメントヘッダとメタデータ
XDSはコンテンツに中立であるため、XDSは「XDS Document Repository」に提供されたメタデータと、XDSドキュメントの本文に含まれるメタデータを照合確認することはできない。XDS連合ドメインはこのため、IHEが統合プロファイル既に定義を行っているコンテンツを選択するか、それまでは、「XDS Document Registry」の属性をどのように記入するかについて、十分に注意して定義する必要がある。
メタデータと患者記録- 116 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

ドキュメントヘッダのメタデータは「XDS Document Registry」で複製されるが、「XDS
Document Registry」メタデータは、保存される合法な医療記録の一部として、一定の役割を果たす。これは、実際の文書が保管されている、「XDS Document
Repository」に管理される医療記録の一部では決してない。さらに、XDSは、もし連合ドメインが希望すれば、文書作成者をトラッキングする機能を提供するが、XDS提出
セットのコンテンツに署名を行ったり、トランザクションに対して合法的な認証を提供するものではない（IHE Document Digital Signature Content－DSGを参照）。XDSフ
ォルダのコンテンツは、フォルダ内にドキュメントレファレンスを設置する提出セットを通じて追跡される。しかしレジストリ内のドキュメントメタデータの存在と、XDS提出セ
ットまたはXDSフォルダの作成に関連する医療行為などを通じて、「XDS Document
Registry」のコンテンツが、患者の正式な医療記録の一部となる可能性もある。これらの医療行為に関わる課題についてどのように取り組むか、また常識や一般的な医療
プラクティス、ローカル規制に基づきいかに解決していくかについては、個別のXDS
連合ドメインの判断にゆだねられている。

- 117 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 K: XDS 概念の詳細
K.1 XDS ドキュメントの概念
XDSドキュメントは「Document Repository」アクタに提供される最小ユニットの情報
で、「Document Registry」アクタにエントリとして登録される。
XDSドキュメントは、交換を目的に、観察とサービスを含む医療情報の組み合わせであり、保存性（Persistence）、管理責任（Stewardship）、真正性（Potential for
Authentication）、完全性（Wholeness）という特徴を持つ。これらの特徴はHL7
Clinical Document Architecture Release 1 specificationにおいて定義されている。
XDSドキュメントは適切なアプリケーションや人によって閲覧可能なものとなっており、
いずれの場合も、その構造、コンテンツとエンコーディングを定義した標準を遵守しているべきである。IHE はこのような標準に基づくコンテンツ主体の統合プロファイルが、
XDSとあわせて利用されるよう定義することを意図している。
さらに、
1. 共有のために提出が行われると、XDSドキュメントは、関連するMIMEタイプとともに、オクテット・ストリームとして、「Document Repository」アクタに提供される。
2. 文書取り出しトランザクションを通じて取り出される場合、XDSドキュメントは提出されたオクテット・ストリームからは変更されない(フル・フィディリテ
ィ・レポジトリ)。
注記：XDSドキュメントはMIMEマルチパートドキュメントであってもよい（例：HL7 CDAが最初の部分であり、添付がファイルとして続く）。マル
チパートの最初の部分が文書の主要部分であり、他の部分は主要部分への添付となる。「Document Repository」はこのマルチパートデー
タセットを曖昧なエントリとして処理する。「Document Repository」はマルチパート構造の分析を行ったり、XDS統合プロファイルに照らし合わせて処理を行ったりする必要はない。
注記：XDSドキュメントは文書に特有の方法を利用して取り出すこともできる。このようなオプション機能は現在のXDSスペックでは提供されていないが、この統合プロファイルにおいて将来オプションとなることが考えられる。
3. XDSドキュメントは「Document Source」に定義されたメタデータと関連付けられる。 このメタデータ情報は「XDS Registry」アクタにより、XDSドキュ
メントエントリに設置され、「XDS Consumer」アクタによるクエリに利用される。

- 118 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNA

コメント [MS3]: Opaque Entry

IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

4. XDS統合プロファイルはXDSドキュメントをひとつの情報ユニットとして管理しており、XDSドキュメントの一部にアクセスするメカニズムは提供しない。「Document Source」または「Document Consumer」がXDSドキュメ
ントの内部情報にアクセスすることができる。
5. XDSドキュメントにはGUID(Globally Unique ID)が利用されるので、異なるコンテンツを持つ2つのXDSドキュメントが同じユニークIDを持つことはない。このIDは全ての医療連合ドメインにおいてユニークであり、必要に応じ、異なるドメインからの「XDS Document Repository」の統合や医療連合ドメイン間のXDSドキュメントの交換を可能にする。
6. 「XDS Document Registry」アクタは、「Document Repository」アクタに保管されているXDSドキュメントへの単一のドキュメントエントリを維持する。
同じXDSドキュメントの重複するコピー （同一のユニークIDを持つ）が保存、登録されることもある。同じユニークIDを持つがコンテンツが異なるXDSドキュメントの登録は却下される。
7. この統合プロファイルは「Document Registry」に登録されるXDSドキュメ
ントに必要なメタデータの特定を行う。XDSドキュメントメタデータが関連す
るXDSドキュメントの実際のコンテンツを反映したものであることを保証するのは「Document Source」の責任である。「Document Repository」または「Document Registry」はこのような一貫性のチェックは行わない。
8. 「Document Source」は登録を行ったXDSドキュメントに関して以下の責任を持つ。
a. これらの文書のステータスを、「Approved」から「Deprecated」に変更するか、完全に削除する権利を持つ。
b. XDSドキュメントを、以前提出された文書の「Parent relationship」の代替（RPLC）として提出する権利を持つ2。

医療連合ドメインは必要に応じ、このようなオペレーションに患者がアクセスできるようなポリシーや手続きを持つべきである。例えば、特定の地域においては、患者がEHR-LRからドキュメントの削除を依頼できる場合がある。今のところ、このために定義されたIHEトランザクションは存在しないが、レジストリとレ
ポジトリでの実装において、このようなローカルオペレーションをサポートできるようでなければならない。

K.2 XDS連合ドメインの概念
2

例えば DICOM においては、内部の患者メタデータがアップデートされても文書 ID は変更されないが、「Socument Source」は既存文書の代替として、アップデートされた DICOM ドキュメントを提出する。
- 119 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

XDS連合ドメインは、明確に定義された「Document Repository」のセット、そして医療文書共有に合意した「Document Consumer」から構成されている。連合ドメインにおいては、複数のプロパティに関する定義が行われている。
1. 連合ドメインはケアを提供しない。XDS連合ドメインにおいて、「Document
Source」、「Document Consumer」として参加しているEHR-CRのみがケア提供を行う。
2. 連合ドメインは1件の「Document Registry」アクタにより管理されている。
注記：将来別の統合プロファイルとして、分散型レジストリアプローチが考慮される。「Document
Source」と「Document Consumer」アクタにおいては、1件の「Document Registry」アクタを認識するということは、分散型レジストリの複雑さを隠したものとなっている。

3. 「Document Registry」アクタを何件でも含むことができる（分散型の設定がデフォルトであるが、グループ化されたレジストリ・レポジトリによる一極集中型の設定もサポートされている）。
4. 文書共有に参加する「Document Consumer」と「Document Repository」アクタの明確なリストを含む。「Document Repository」または「Document
Consumer」アクタを追加することは、「Document Registry」、「Document
Repository」の保守を行う機関を巻き込んで実施する必要のある、事務的なタスクである。
5. それぞれのEHR-CR と連合ドメインにおいては、ユーザ間（ヘルスケアスタッフ）間の信頼の連鎖（Chain of trust）が構築されている。
6. 「Document Repository」と「Document Consumer」は、複数の連合ドメインに所属、同一または異なる文書を共有してもよい。これは実装戦略であり、ここではこれ以上の詳細は記載されない。
7. 連合ドメインは、「Document Registry」と通信するため、「Document
Source」、「Document Consumer」が利用する主要な患者IDドメインをサポートする。連合ドメインの「Document Source」と「Document Consumer」が異なる患者ID登録ドメインに属する場合、「Document Source」と「Document
Consumer」は、そのレジストリに対し、自らの患者ID登録ドメインとの間で相互参照を行わなければならない。ここでは IHE Patient Identifier Crossreferencing統合プロファイル、 IHE Patient Demographics Query統合プロフ
ァイル、またはその他連合ドメインに特有のメカニズムが相互参照に利用される (ITI TF-2 付録 E、 E.3とE.5を参照)。
8. 「Document Source」は、連合ドメインが承認した用語値セットを持つ文書コード、医療施設コードが含まれた文書のみを提供する。

K.3 XDSにおけるその他の原則- 120 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

XDS統合プロファイルは、以下の制約と原則に沿ってデザインされている。
1. 文書はコンテンツ内に、他の文書への参照情報を含むことがある。これらは「XDS Document Registry」に管理されていない。これらの参照情報は、これらの情報を含む文書を登録したEHR-CRによって入手することができる。
2. 「XDS Repository」は、コンテンツの処理や翻訳などは行わない。処理と翻訳
はSource EHR-CR またはConsumer EHR-CRの役割である。分析、文書間の組み合わせやコンテンツの表示は、XDS統合プロファイルとそのアクタの焦点外である。
3. 登録された文書に含まれる医療情報の管理は、EHR-CRのソースアクタの責任となる。EHR-LRは、文書を提供するEHR-CRの責任のもと、「共有スペース」のみを提供する。XDSにおいて、EHR-LR内の文書の差し替えや削除は、対応するEHR-CRソースによってのみ開始される。
4. 医療連合ドメインの「XDS Registry」XDSにすでに登録されたXDSドキュメント
が、同じ文書ユニークIDを利用し、あたかも新しいXDSドキュメントのように提出された場合、この「重複した提出」は、XDSドキュメントユニークIDがドキュメ
ントエントリにすでに存在する、という事実に基づき、レポジトリと、またはレジ
ストリに探知される。再提出したドキュメントが属する提出リクエストは、IDはマッチするが実際のコンテンツが異なる場合却下される（提出の際、ドキュメント
レポジトリにより作成されたハッシュキーの利用により探知される）

K.4 文書特定
XDSドキュメントに関連するユニークIDの数を削減するため、「Document Source」に割り当てられる全体にユニークな文書IDと、レポジトリに利用されるユニークなXDSドキュメントIDは同じである。IHEトランザクションオペレーションを内部で参照する際、ドキュメントエントリー言及のためにebRSごとに作成されるDocument Entry UUIDの利用を制限すること、そして全ての外部オペレーションにおいて全体にユニークな文書IDを利用することが強く奨励されている（例：「Document Source」アクタ内部のデータベースで維持されているリンクや、文書内のリンクなど）。
XDSドキュメントエントリはXDSDocument.uniqueId と XDSDocument.URI（Universal Resource Identifier）の異なる2つの属性を含む。URIはいかなるDocument Consumerでも、文書取り出しトランザクションの実施を可能とする自己完結型のウェブ方法である（ITI TF-2: セクション 3.17参照)。文書のユニークIDは、文書のロケーションからは独立したIDとなっている。XDSドキュメントが「XDS
Document Repository」から連合ドメイン内の別のレポジトリに移行することで、URIは変更されるが、文書のユニークIDは変更されない。

K.5 文書の関連性の事例- 121 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

追加

差し替え

差し替え
差し替え

追加

HL7 CDA Release2から引用

図10.4.10-5 文書の関係事例

これらの関係は上記の図に示されている。一般的なシナリオとして、シンプルな差し
替え (例：XDSDocument.id "1.2.345.678910.266"がXDSDocument.id"1.2.345.678910.123"を入れ替える) とシンプルな追加 (例：XDSDocument.id"1.2.345.678910.456" がXDSDocument.id "1.2.345.678910.123"に追加される)が考えられる。さらに複雑なシナリオとして考えられるのは以下のとおりである。
1. 追加の差し替え (例： XDSDocument.id "1.2.345.678910.224" がXDSDocument.id "1.2.345.678910.456"を差し替える。これはそれ自体がXDSDocument.id "1.2.345.678910.123"の追加である) – 予期される動作として、差し替えられた文書を、追加として表示する(例： XDSDocument.id"1.2.345.678910.224" をXDSDocument.id "1.2.345.678910.123"の追加として表示);
2. 差し替えられた文書に対する追加 (例：XDSDocument.id"1.2.345.678910.456" はXDSDocument.id "1.2.345.678910.123"に追加を行う。これ自体は、XDSDocument.id "1.2.345.678910.266"によって差し替えられたものである) - 予期される動作として、差し替えられた文書と共に、追加文書を表示する(例：XDSDocument.id "1.2.345.678910.456" を
XDSDocument.id "1.2.345.678910.266"の追加として表示)。

K.6 オフライン・トランザクションモード
「Document Source」アクタは、特に接続にダイヤルアップが利用されている医師のオフィスシステムが「Document Source」の役割を果たす際は、オフラインであっても良い。

- 122 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles「Document Registry」と「Document Repository」は、いかなるときでもオンラインであるようにデザインされている（例外については注記を参照）。
注記：「Document Repository」はポイントツーポイント電子メール送信などの縮小されたケースにおいては、オフラインであっても良い。ここでは連合ドメインは、「Document Source」、そして「Document
Registry」と「Document Consumer」とグループ化されている「Document Repository」の2つのシステム
のみから成り立っている （ITI TF-1: 10;5 戦略3参照）。

オフラインシステムに送信された情報は、インターネット電子メールプロトコルを通じてサポートされる。電子メールプロトコルは通知を送信する以下のメカニズムを提供する。
(1) エンドユーザーからの配信レシート(2) 中間にある保存・転送を行うSMTPサーバからの配信失敗通知。
電子メールプロトコルを利用においては、電子メールメッセージとして送信される通知の非同期性という特徴により、トランザクション送信と通知コンポネントが、はっきりと異なるメッセージに分かれていることが必要となる。
電子メールメッセージの本文にシンプルな通知（英語・ASCII）、固定されたサブジェク
トラインが含まれ、アドレスが自動処理に利用される。ローカル言語にフォーマット化
された添付にインストラクションが含まれる。トランザクションは異なる添付に含まれているべきである。

- 123 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 L: XDS 連合ドメイン定義のチェックリスト
XDS 連合ドメインのコンセプトはITI TF-1:10 と付録Kに定義されている。この付録は、
EHR-LRドキュメント共有環境を設置するにあたり合意されるべき主要なポリシーをまとめている。

L.1 XDS連合ドメインの設定
XDS統合プロファイルで定義されているIHEアクタを導入する複数のシステムは、通信を行うために特定、設定される必要がある。これは、アドレス情報の定義とATNA
Secured Node証明書を含む。
1. 「Document Registry」アクタをサポートするシステムの特定
2. 「Document Repository」アクタをサポートするシステムの特定
3. 「Document Source」、「Document Consumer」アクタをサポートするシステ
ムの特定

L.2 患者の特定
XDSドキュメントレジストリ（ITI TF-2:付録H参照）を適切な患者ID情報を利用し開始
する：
1. XDS連合ドメイン患者IDドメインの割り当て機関(OID)を指定
2. EHR-CR 「Document Source」、「Document Consumer」が運用するローカ
ル患者IDドメインのOIDを指定
3. 患者IDソースをサポートするシステムを指定、もし「Document
Source/Document Consumer」アクタをサポートするシステムのいくつかがPatient Identity Cross-reference Managerをサポートする場合、それをサポートするシステムを指定 (患者IDフィードトランザクションを受信する必要がある)。

L.3 XDSレジストリ関連のボキャブラリ
適切なボキャブラリ情報を利用してXDSドキュメントレジストリを開始する（ITI TF-2:付録 H参照)
1. コーディングスキームまたはコーディングスキーム・コード値が実行される「Registry Enforcement」において指定されているボキャブラリ定義を持つ- 124 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles「Document Souce」、「Document Consumer」の両方またはいずれか一方と「XDS Document Registry」を選択、開始する。

L.4 文書共有ポリシー
1. ケアイベントとEHR-LR内で共有が期待されている情報のレベルを定義。
2. ケアパスウェイでサポートされているXDSフォルダの利用ポリシー（作成とアッ
プデート）を定義

L.5 XDS ドキュメントのコンテンツ
1. それぞれの文書フォーマットコード値については、必要となる互換性に関する合意を確立し（例：IHEドキュメントコンテンツプロファイルを選択するなど）、「Document Consumer」が、XDS連合ドメインの「XDS Repository」から取り出したXDSドキュメントコンテンツ(例：MIMEタイプ、テンプレートの定義、アーキタイプ)を検出し（例：ドキュメントユニークID構造）、処理することを保証する。

L.6 文書アップデートと保守ポリシー「Document Source」は、連合ドメインにサポートされたEHR-LRで共有される、
XDSドキュメントの正確性（保守管理）を持続して行う責任を持つ。これは以下を含む。
1. EHR-LRの文書差し替え
2. EHR-LRの文書を削除する可能性のあるケースと方法

L.7 セキュリティとプライバシーポリシー
1. 連合ドメインに参加するケア提供組織間でポリシーと手順に関する合意を構築。特にITI TF-2:付録Kにおけるセキュリティへの考慮に取り組む。
2. 認証エクスチェンジを含むオペレーショナルセキュリティインフラの構築
3. オペレーショナルセキュリティインフラ、設定管理、監査管理、定期的な検査な
どの保守- 125 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

付録 M: エンタープライズ間の文書共有と IHE ロードマップ
IHE Cross-Enterprise Document Sharing統合プロファイルは、複数のドメインに特有のテクニカルフレームワーク（Patient Care Coordination, Cardiology, Laboratory,
Radiology, IT Infrastructureなど）とグループ化された、IHE統合プロファイルの一部である。XDSはエンタープライズを超えた互換性構築のための重要な基礎であり、既存のIHE統合プロファイル（ITI TF-1:付録E）と組み合わせることが可能である。しかし、今後複数の新たなIHE統合プロファイルが開発される必要があり、関連するベース標
準の実現はまだ保留されている。

M.1 XDSのためのDocument Content統合プロファイル
様々なIHEドメイン(Cardiology, Laboratory, Radiology, IT Infrastructureなど) において、共有される必要がある文書のコンテンツについて言及する、新しいIHE統合プ
ロファイルが作成されることが期待されている。これらの様々な「コンテンツ指向型の」
統合プロファイルは、共通の方法での登録、発見とアクセスプロセスを管理するためのXDS統合プロファイルに依存する。
このような取り組みは、紹介や退院サマリーに利用される医療サマリーのIHE
Patient Care Coordinationドメインにおいて行われているところである。www.ihe.net
を参照。

M.2 エンタープライズ間のダイナミックな情報共有
アレルギーリスト、医薬品リスト、問題リストなどのダイナミックな情報（非ドキュメント指向型）についてはXDSでは言及されない。しかし構造化されたフォームにアクセスする方法と、このようなダイナミックな医療情報をアップデートする方法は、新たな統合プロファイルの候補となっている。

M.3 コラボレーティブなワークフロープロセス管理
オーダーの発行やトラッキング（医薬品処方箋、放射線のオーダーなど）など、ケア提
供コラボレーティブプロセスは幅広く、XDSはこれに対して部分的なソリューションのみを提供している（結果情報と患者記録の作成など）。XDSは、複数のプロバイダがオーダー、処方箋、医薬品の提供と結果へのアクセスを共有することを保証するなど、
電子処方箋や電子紹介に主要なインフラを提供する。これらのコラボレーティブワー
クフロープロセスのコマンド・コントロール部分に互換性を持たせる方法については、
将来特定の統合プロファイルの候補となっている。

M.4 セキュリティとプライバシー管理
XDS連合ドメインにおけるいかなるオペレーションにおいても、適切なセキュリティモ
デルが設置されていることを要求している。ここでは様々なセキュリティモデルの利用- 126 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profilesが考えられる。XDS統合プロファイルは特定のセキュリティモデルの利用を含んだり要求するものではないが、XDS実装者はXDSアクタをIHE監査証跡、ノード認証からのアクタとグループ化し、このようなエンタープライズを超えた環境でオペレーションを実施する上で必要なアクセス制御機能を必要とする。XDSを補完する特定のIHE統
合プロファイルが現在入手可能である（Cross-Enterprise User Authentication,
Document Digital Signature）。

M.5 連合ドメインの連合化
XDSは、ローカル、地域、全国など様々なレベルにおけるケア提供組織を含む連合ドメイン確立に効果的な方法である。しかし患者は患者が地域や国を移動する際、自らの記録も共に移動することを期待しているため、独立した、XDSベースの連合ドメイン間の連合が求められる。IHEはひとつの医療連合ドメインから別の連合ドメインへの情報の移動の必要性に備えたり、またはある連合ドメインから、他の連合ドメインで管理されている文書へのアクセスを可能とする。XDSは、このような拡張を念頭においてデザインされている。XDSを補完するXDS Domains Federation統合プロファイルの作成が将来予期される。

- 127 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

用語集
アクタ: 利用例の図表内において、アクションを実行することができるエンティティとして示される。メッセージの作成と消費などがアクションの一例である。
ADT: Admit, Discharge & Transfer（患者受け入れ、退院、転送）
CCOW: Health Level Seven Context Management Architecture (CMA)のためにANSI認証された技術に中立なスペック。このアーキテクチャは、複数のアプ
リケーションが、利用するポイントにおいて、医療的に意味のある方法で自動的に調整、同期化されることを可能にする。この文書で特定されているアーキ
テクチャは、医療デスクトップとしての役割を果たすPCなどの機器に利用されているアプリケーション間に、互換性を持たせる基本となる。
Context Management Registry: 特定のデスクトップに利用されるコンテクスト
マネジャのインスタンスを位置づけるため、HL7 Context Management“CCOW” Standard に定義されたHTTP技術に特有のサービス。
Context Session: 1件かそれ以上のサブジェクトにおいてコンテクストを共有している、参加アプリケーションの集合体
CDA: Clinical Document Architecture (HL7により特定されている)
CT: Consistent Time統合プロファイル
Clinical Affinity Domain: 共通のポリシーセットを利用して協働することに合意し、共通のレポジトリのインフラとレジストリを共有するヘルスケアエンタープラ
イズのグループ
Directory:居住者の名前と居住場所を含む本、アドレス帳、ビジネスディレクトリ
EHR-CR: EHR-CR またはCare-delivery RecordはITシステムまたはケア提供
組織のシステムのセットにより管理されている患者情報を要約する。開業医、養護施設、外来クリニック、入院施設を持つ緊急ケア施設など、幅広いヘルス
ケア施設をサポートする役割を果たすことが考えられる。
EHR-LR: EHR-CRにより共有され、レジストリによりトラッキングされる文書は、医療連合ドメイン内の複数のEHR-CRの間でケアを受ける患者に対してLR(Longitudinal Record：長期的な診療記録)を形作る。これはEHR-LRとして知られている。
eMPI: Enterprise Master Patient Index
EUA: Enterprise User Authentication Integration Profile- 128 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

Expected Actions: トリガーイベントの結果起こるべきアクション
Globally Unique Identifier (GUID): 全体におけるユニークさを保証するアルゴ
リズムによって作成される、持続した（PERSISTENT）文書などのエンティティの識別子
HIMSS: Healthcare Information and Management Systems Society
HIS: Hospital Information System
IETF: Internet Engineering Task Force
IHE: Integrating the Healthcare Enterprise
inetOrgPerson: inetOrgPerson [RFC 2798] オブジェクトクラスは、人に関する属性を持つ多目的なオブジェクトクラスである。ここで含まれている属性は、典型的なインターネットとイントラネットディレクトリサービス展開で見られる情報
リクワイヤメントに対応するために選択されている。inetOrgPersonオブジェク
トクラスはLDAP v3 [RFC 2251] とX.500 ファミリーのプロトコルに基づくディレクトリーサービス内で利用されるようにデザインされており、他のコンテクスト
でも有用であるべきである。
Interaction Diagram: データフローとイベントの連続を示す図表
JPEG: – Joint Photographic Experts Group
KDC: Key Distribution Center (TGTとサービスチケットを発行するKerberosサーバ。RFC1510参照)
LDAP: X.500 Directory Access Protocol (DAP)のリソースリクワイヤメントを負うことなく、Lightweight Directory Access Protocolは、X.500モデルをサポートするディレクトリへのアクセスを提供するようデザインされている。このプロト
コルは、特にRead/Writeインタラクティブアクセスをディレクトリーに提供している、管理アプリケーションとブラウザアプリケーションをターゲットとしている。
X.500プロトコルをサポートするディレクトリと共に利用されると、X.500 DAPを補完することを意図している。
Local Authentication: ATNAプロファイルでは、「ローカル認証」はユーザID、認証、許可の方法がローカルシステムアドミニストレーションによって選ばれ、必ずしもいかなるIHEプロファイルに遵守するものではない。ローカルユーザ
名とパスワードシステム、セキュアトークンシステムまたはローカルセキュリティアドミニストレーションが受け入れ可能だと考えるいかなるシステムであることが考えられる。
MPI: Master Patient Index- 129 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

MRN: Medicare Record Number
NEMA: National Electrical Manufacturers Association
NTP: Network Time Protocol。これはコンピューター時計を同期化させる標準プ
ロトコルである。ウェブサイトhttp://www.ntp.orgでは、いかにコンピューターを同期化させるかの情報を、入門レベル、専門レベルで提供している。
OID: Object Identifier (Globally Unique Identifierも参照)
PACS: Picture Archive and Communication System
Patient: (ATNAのコンテクストで利用された場合) RFC 3381は患者である人物の特定方法を定義する。監査記録内の患者情報は、監査情報が作成された時点で、患者を特定するために入手可能であった情報と合致するものであるが、後のアップデートは反映しない（例：患者の調整など）。
PatientID: (ATNAのコンテクストで利用された場合) そのシステムドメイン内でユニークである、システム内部の患者IDを含むフリーテキスト。患者IDドメインは
監査イベント記録を作成するシステムに割り当てられる。監査イベント記録の患者情報は、患者記録が作成された際に患者を特定するために入手可能だ
った情報と合致するものであるが、後のアップデートを反映しない（例：患者の調整など）。
Patient Identifier Cross-reference Domain: 認識されている患者IDドメインセットから成り、「Patient Identifier Cross-reference Manager」アクタにより管理されている。「Patient Identifier Cross-reference Manager」アクタは異なる
患者IDドメインから、エイリアスIDのリストを提供する役割を果たす。
Patient Identifier Domain: 患者の共通するIDスキームを共有するひとつのシステムまたは相互接続されたシステムのセット。このようなスキームには以下が含まれる。 (1) ひとつのID発行機関 (2) 患者に対するID割り当てプロセス(3) 発行された患者IDと関連する特徴の永久的な記録 (4) 長期的なメンテナ
ンスプロセス。患者特定の目的はエラーを削減することである。
Patient Mapping Agent: 分散する患者IDドメインにまたがり、患者IDのマッピン
グを提供するCCOWに定義されたコンポネント
Patient Subject:デスクトップ上の異なるアプリケーションの間で現在選択されている患者IDの共有をサポートする、PSAによって定義されるサブジェクト。
Personnel White Pages: PWPディレクトリ内の人員情報。この情報はヘルスケ- 130 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

アエンタープライズ内の医療、非医療関係アプリケーションに幅広く利用される。情報は医療ワークフローの強化（コンタクト情報）、ユーザインターフェイスの強化（ユーザフレンドリーな名前やタイトル）、IDの確認などに利用される。
PIX: Patient Identifier Cross-referencing Integration Profile
PMA: CCOWに定義されるPatient Mapping Agentコンポネント
Process Flow Diagram: フロープロセスと特定の事例に関連するアクタのインタラ
クションを図表に示したもの。
PSA: Patient-Synchronized Applications統合プロファイル
RID: Retrieve Information for Display統合プロファイル
RIS: Radiology Information System
Role: 利用例におけるアクタのアクション。
RSNA: Radiological Society of North America
Scope: トランザクションに関する短い記述。
Secure Domain: アドレス可能なオブジェクトへのアクセスのために、1セットのセ
キュリティポリシーが定義、実施されているネットワーク、ハードウェアシステム、
セキュアノードと物理的環境。
Secure Node: セキュアドメインのアクセスポリシーと管理に沿った、ネットワーク
がアドレス可能なシステム。多くの場合セキュアノードはIHEアクタをサポートする。
SNTP: Simple Network Time Protocol。これは正確さを抑えたバージョンのNTPである。プロトコルフィールドは同じであるが、利用されるデータ値とアルゴリズ
ムは、機能が制限されたシステムでも導入できるよう、正確さを大幅に削減してある。
Submission Set： EHRシステムによって提供される、患者とケアイベントに関連する情報について、ドキュメントレポジトリに共に登録されるXDSドキュメントのセット。
SUID: DICOM SOPインスタンスからのStudy Instance UIDまたはSOPインスタ
ンスの集合。
TGT: Ticket Granting Ticket ユーザを確認する最初の証明書は認証されて- 131 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNAIHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles

いる。ユーザ認証イベントの繰り返しを防ぐために利用され、サービスにアクセ
スをリクエストする際のトークンとして利用される。
Trigger Event: メッセージの受信やプロセスの終了など、他のアクションのきっかけになるイベント。
UID: Unique Identifier (Globally Unique Identifierも参照)。
Universal ID: UIDタイプ内の長期的なユニークID。それぞれのUIDは特に列挙
された種類のひとつに属していなければならない。Universal IDはそのスキー
ムの統語ルールに沿わなければならない。
Use Case: アクタとシステムのオペレーションに関する図。
Username: パスワードとは異なる文字の連続で、ユーザ特定に利用され、マルチユーザーコンピューターシステム、LAN、掲示板システムまたはオンラインサービスにログインする際に利用される。ユーザーIDまたはuidとも呼ばれる。
User Subject: 現在ログインされたユーザIDをデスクトップ上のアプリケーション
での共有をサポートする、PSAにより定義されたサブジェクト。
UTC: Universal Coordinated Time これはGMTの代替である。国際的に認識、サポートされている参照タイムベースの定義を行う。
XDS Document: XDSドキュメントは「Document Repository」に提供され、Document Registryに登録される最小ユニットの情報である。XDSドキュメン
トはシンプルテキスト、フォーマット化されたテキスト（例：HL7 CDA リリース 1)、
画像（例：DICOM）または構造化、ボキャブラリーコード化された医療情報（例：CDAリリース2、CCR）または上記のコンテンツタイプの混合であることが考えられる。
XDS Folder: XDSフォルダは「Document Source」が、他の関連するドキュメント
とともに提出したドキュメントとグループ化することを可能にする。何がフォルダに含まれるか、そしてEHR-CRに利用される特定のフォルダに関連するボキャ
ブラリについては、医療連合ドメインのメンバーであるケア提供組織の合意を通じて決定される。

- 132 Rev. 2.0 Final Text 2005-08-15

Copyright © 2005: ACC/HIMSS/RSNA