15

連携用医用情報（PDI）

連携用医用情報 （PDI）は、連携上で画像関連情報を交換するアクタ及びトランザクションを規定する。このプロファイルの意図は、連携データ及び診断報告書を確実に交換し、受信アクタが読込み、表示又は印刷できるようにすることである。
本規約で扱うのは、連携コンテンツの情報源及び患者（適切な場合）の識別、読込み中のデータの整合性確保及び連携用コンテンツの構造である。
プロファイルの主な要素は次のとおりである:• DICOM規格に基づいた画像関連情報の確実な交換• ウェブ可視コンテンツを連携データに含めるための指針を提供するウェブコンテン

ツ選択肢
ウェブコンテンツ選択肢が扱うのは、DICOMコード化オブジェクト、及びこれらのDICOMコード化オブジェクトに由来したXHTML又はJPEGのオブジェクトを含む連携データのケースである。

15.1

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

図15.1-1が示すのは、このプロファイルに直接関与するアクタ、及びアクタ間のトランザクションである。

→RAD-47、連携情報で画像情報を配布する→RAD-47、連携情報で画像情報を配布する→RAD-47、連携情報
で画像情報を配布する→RAD-47、連携情報で画像情報を配布する

連携情報
書き込み
→RAD-47、連携情報で画像情報を配布する

表示

画像表示

報告書
閲覧
プリント生成連携情報
読み込み

図15.1-1. 画像連携用接続図

表15.1-1に列記したのは、画像系プロファイルの連携用データに直接関与する各アクタのトラ1／9

ンザクションである。本規約をサポートしていると主張するためには、実装に必要なトランザクション（ラベル「R」の付いた）を行うものとする。ラベル「O」の付いたトランザクションは選択肢である。本規約によって定義された選択肢の完全なリストはRAD TF-1: 15.2に記載されている。注意が必要なのは、RAD TF-1: 2.5 に記述されるように、多数のアクタの一つは連携用データ読込みについてグループ化しなければならないことである。

表15.1-1.

画像統合プロファイル用の連携用データ - アクタ及びトランザクション
Vol. II/III
アクタ
トランザクション
選択性Section
R4.47
連携情報書込み
連携情報で画像情報を配布する[RAD-47]
R
4.47
連携情報読込み
連携情報で画像情報を配布する[RAD-47]
R
4.47
画像表示
連携情報で画像情報を配布する[RAD-47]
報告書閲覧

連携情報で画像情報を配布する[RAD-47]
連携情報で画像情報を配布する[RAD-47]
連携情報で画像情報を配布する[RAD-47]

プリント生成表示 (III TF)

15.2

R

4.47

R

4.47

R

4.47

画像統合プロファイル選択肢用の連携用データ

本規約に選ばれることがある選択肢を、それらが適用するアクタと共に、表 15.2-1 に列記する。選択肢間の依存性を、適用可能な場合、注記で指定する。

表 15.2-1: 画像用の可搬用データ - アクタ及び選択肢
アクタ

選択肢

Vol & Section

連携情報書込み

ウェブコンテンツ

連携情報読込み

選択肢は定義されていない
選択肢は定義されていない
選択肢は定義されていない
選択肢は定義されていない
選択肢は定義されていない

RAD TF-1: 15.4.2RAD TF-2: 4.47, 4.1.2
-

画像表示
報告書閲覧
プリント生成表示（III TF）

2／9-15.3

画像プロセスフロー用の連携データ

このセクションでは、交換する連携情報の使用と関係する典型的なプロセスフローについて記述する。扱うトランザクションは「47-連携情報で画像情報を配布する」である。
このプロセスフローで次のステップを識別できる:•

ソースアクタ（連携情報書込み）は、1グループの連携情報セット及び／又は関連する診断報告書を1個の交換する連携情報内に書く。連携情報書込みが、グループ化されたアクタからのデータ、又はIHE適用範囲外の別のソースへのアクセスを持つと考えられる。

•

連携情報に含まれる画像関連情報が使用される送付先へ、連携情報が送付される。

•

連携情報読込みは、連携情報内のDICOMオブジェクト（画像、表示状態、キー画像への注釈、エビデンス文書及び報告書）を読み、ローカル情報スペースへそれらを読み込む。連携情報読込みは、必要に応じてデータの整合性を確保する（例えば記録された患者IDを変更して、ローカルの患者IDにする）。DICOMオブジェクトのいくつかのクラスが連携情報内に存在し、それらを読み込めない場合、連携情報読込みは、影響を受けたスタディ及びシリーズをオペレータに通知し、それらが読込みアプリケーシ
ョンでサポートされないことを明確にする。
•

画像表示装置、報告書閲覧、表示又はプリント生成は、それがサポートするオブジェクトを読む。そしてレシーバのニーズによってそれらを表す。いくつかのオブジェクトが閲覧アプリケーションにサポートされない場合、それらのオブジェクトはサポートされないことをオペレータに通知する。

データの潜在的な使用法のシナリオをユースケースについて下に記述する。

15.3.1

ユースケース

本規約では、文書保管に関する問題を解決することを意図していない。
ユースケース1 - 患者／紹介医師ビューイング: 診断及び治療の画像データ、例えば画像及び報告書は、潜在的に多数のユースケースに役立つ連携情報で受け取られる。患者又は紹介
医師は、同じ連携情報内に存在するビューアアプリケーションを使用するか又はウェブブラウザーを使用してデータを見ることができる。このデータは必ずしも診断又は治療のプロセスの基礎として意図されておらず、単に参考データに過ぎない。セキュリティ及びプライバシーの理由から、患者に与えられる媒体は、他の患者のデータを含まない。追加のセキュリ
ティ考察に関してはセクション15.5を参照。
ユースケース2 - ヘルスケアエンタプライズ交換: 1人以上の患者のデータ、例えば画像、報告書又は完結したスタディは、連携情報上で受取られ、診断又は治療のケアプロセスを可能3／9

にする。連携情報は異なるサイトで読み込まれ、一般的には「２次的読込み」又は「参照読込み」用である。

•２次的読込み: 連携情報は画像管理／保管装置に読込まれ、リード／オーバーリードされる。データ矛盾を回避するために、重要な患者／スタディ属性は既存のローカルデータとの整合性を確保する必要がある。画像及び関連表示状態は、プリント生成のもとへ送られプリントされる。

•参照読込み: 連携情報は画像管理／保管装置及び／又は報告書保管に読み込まれ、患者履歴の一部になる。それは「適切な従来」データとして将来の読取りに使用できる。データ矛盾を回避するために、重要な患者／スタディ属性は既存のローカルデータとの整合性を確保する必要がある。
ユースケース3 - 手術室ビューイング: 確実なネットワーク接続のない環境でも診断又は治療プロセスを可能にするために、媒体を使用する。データ容量は非常に大きくなり、画像データ、後処理結果及び報告書を含むことがある。手術室で外科スタッフは、媒体を受取り高度なビュアーを使用してそのコンテンツを読む。ビュアーには画像の操作又は処理を含むことがある。

15.3.2

プロセスフロー記述

ユースケースは情報連携に関連する三つの活動の点から指定される:•連携情報書出し•

連携情報ビューイング

•連携情報読込みA) 連携情報書出し（すべてのユースケース）:
連携用情報書込みは、連携コンテンツ（DICOM及びウェブ可視コンテンツ）を組み立てて、連携情報にそれを書く。
次のシーケンスの活動が連携情報生成中に行われる:•DICOMデータの書出し（FSC活動）•

選択肢として、ウェブ可視データの書出し。それには容易にアクセスできる情報的データをDICOMデータから引き出すことが含まれる（ウェブコンテンツ選択肢）。

•

選択肢として、追加コンテンツの包含（例えば: DICOMビュアー又はビューイングソフトウェアコンポーネントであって媒体上でDICOMデータにアクセスするもの）
4／9

B) 連携情報ビューイング:
B 1) ウェブ（ユースケース1）（ケアプロバイダー、他の利用者、及び患者であってDICOMビューイング機器又はソフトウェアを持たない者）:
表示アクタは、ウェブ可視コンテンツすべてを受け取り表示する。そのアクタは一般に利用可能なリソース（つまりウェブブラウザー）として存在する。連携用情報書込み
は、ウェブ可視コンテンツの存在について連携情報すべてに頼ることができないことに注意する。なぜならそれが含まれるのは、ウェブコンテンツ選択肢を使用して作成した連携情報に限るからである。
B2) DICOM（ユースケース1及び3）（DICOMビューイング機器又はソフトウェアを持つ利用者）: 読取り環境の中に既に存在するか、又は連携情報自体に含まれている専門アプリケーションを使用して、連携コンテンツのDICOM部分を表示する。画像表
示及び／又は報告書閲覧アクタが処理できるDICOMオブジェクトの種類は、対応するコンテンツプロファイルのサポートによって示される。プリント生成アクタは画像を連携情報から印刷サーバへ送り印刷する。
C) 連携情報読込み（ユースケース2）:「連携情報読込み」活動は連携用情報読込みで行われ、連携コンテンツのDICOM部分を専ら扱う。連携用情報読込みアクタは、一つ以上のコンテンツアクタ（エビデンス生成、報告書作成など）でグループ化されるが、これは読み込まれる連携情報コンテンツのタイプに依存する。グループ化されたアクタは、連携用情報読込みによってアクセスされた連携情報を保存する。
連携用情報読込みは、DICOMDIRファイルで参照されたDICOMインスタンスすべてにアクセスし、利用者は連携情報患者データセットを選択し読み込むことができる。
連携用情報読込みは、ローカルデータを得る。そのローカルデータは読み込む機関／施設 内に正確であると知られており、患者及びスタディ情報（要求されたとき）の「主要属性」と整合性を確保する。これらのステップを行う方法は、「読込み整合性確保ワークフロー プロファイル」で文書化されている（セクション3.21を参照）。RAD TF-3: 4.47.4.1.3．に「主要属性」のリスト及び行うべき整合性確保の関連処置が記載されている。
注: 連携用情報の読込みは、色々な方法でクループ化できる。例えば「エビデンス生成」についてグループ化し診断・治療の画像コンテンツを画像管理／画像保管装置に保存する。
又は「報告書作成」についてグループ化し報告書を「報告書保管」に保存する。これによってコンテンツの使用が可能になり、以後「適切な従来」データとして将来の読取りに使用される。「撮影装置」アクタについてグループ化すれば、以後「リード／オーバーリード」
5／9にも使用できる。連携用情報読込みを「プリント生成」アクタについてグループ化すれば、読込まれたコンテンツ（画像及び表示状態）を印刷サーバへ送り印刷できる。
図 15.3.2-1 に例示したのは、前のセクションで述べたユースケースを扱うイベントのフローである。

6／9

連携情報
書込み

書出す

ウェブ
ビュー
イング

DICOM
ビュー
イング

表示

画像表示

エビデン 報告書 連携情報
ス生成 作成読込み

画像管理/ 報告書
保管装置 管理

連携コンテ
ンツを組立てる

画像情報を配布する

画像情報を配布する

DICOM
Directory
セスする

示
DICOM
画像情報を配布するにアクセスする

する

読込む

保存する

可搬用画像データ書込み 表示
可搬用画像データ読込み

報告書提出
エビデンス生成

画像表示装置
画像管理／保管装置

報告書作成
報告書管理

を保存する
を保存する
クリエータ画像保存

図15.3-2-1. 画像プロセスフロー用の連携用データ

15.4

連携情報コンテンツ

連携情報コンテンツに対する要求事項が意図することは、連携情報、例えば診断報告書などを確実に転送し、画像及び報告書を汎用コンピュータでも見えるようにすることである。
連携コンテンツには連携情報上の二つの「入口」からアクセスできる: 一つはDICOM画像情報用のDICOMDIRファイルであり、他の一つはオプションとしてのウェブ可視コンテンツ用のINDEX.HTMファイルである。DICOMデータを含むために作成する連携情報が必要であり、それに由来したウェブ可視データをオプションとして含むことがある。このウェブ可視データは、存在すれば、オリジナルのDICOM情報の臨床意図を忠実に保存するものとする。

7／9

15.4.1

DICOMコンテンツ

DICOMデータの作成は、「DICOM汎用媒体保存アプリケーションプロファイル」の使用によるものとする。DICOMDIRファイルは、連携情報に保存されたDICOMファイルすべてを参照するものとする。
DICOMファイルはルートディレクトリには置かないものとする。しかしそれらを含むディレクトリの名前に制約はない。

15.4.2

ウェブコンテンツ選択肢

ウェブコンテンツ選択肢を実装する連携用情報書込みは、連携情報にウェブ可視データも含むことがある。
ウェブ可視データは、XHTMLファイル及び参照JPEG画像としてDICOM情報に由来するものとする。XHTMLエントリページ（INDEX.HTM）によって、このデータすべてにアクセスできるものとする。これによって最終利用者は汎用ウェブブラウザーを使用して、関連情報コンテンツにアクセスできる。INDEX.HTMファイルはルートディレクトリに置くものとする。
注意すべきは、本規約で指定されたウェブ可視データが反映するものは、書き出されたDICOMデータのフルセットか、生成時に考慮されたサブセットであって、患者の臨床症状を忠実に表すことである。例えば、「DICOM構造化報告書がキー画像及び大きい方のDICOMデータセットだけを参照する場合、それに由来したウェブ可視データは、XHTMLフォーマットを選択的に含み、DICOMキー画像に由来したJPEG画像だけを含むことがある。

15.4.3

他のコンテンツビューイングアプリケーション（例えば、DICOMビュアー）は、オプションとして連携情報に含まれることがある。そのようなビュアーはHTMLに含まれるリンクにつながることがある。そのようなビュアーを連携情報に含むことは，次のセクションで述べるセキュリティ問
題及び潜在的な相互運用問題が生じるため望ましくない。
追加データ（例えば、非DICOMフォーマットでの診断報告書）も連携情報に含まれることがある。そのようなデータのフォーマットはこのプロファイルによって指定されないので、そのようなデータは連携情報上の別のディレクトリに置くものとする。そのようなデータがINDEX.HTMファイルで参照される場合、「このコンテンツはIHE放射線テクニカル・フレー
ムワークに適合して生成されたものではないので、確実に読込めるか否か保証できない」ことを明示するものとする。

8／9

セキュリティ及びプライバシー側面

15.5

連携用情報書込みアクタは、悪意のあるソフトウェア（ウイルスなど）が作成する連携情報内に存在しないことを保証するものとする。
連携情報からのアプリケーションの自動立上げは、悪意のあるソフトウェア開始のリスクがある。連携情報読取りアクタが自動立上げしないことが望ましい。したがって、連携用情報書込みも自動立上げの使用を避けることが望ましい。これは連携情報内にあるかもしれないDICOM ビュアーを自動立上げしないことを含む。
さらに、DICOMビュアーが存在する場合、次のことによってセキュリティ問題を最小限に抑止できる:•

通常の（制限された）利用者特権の下で操作し、管理者又はルート特権の下で操作することを利用者に要求しない、さらに•連携情報が使用されるコンピュータにソフトウェアをインストールする必要がな

い。書出し／読込み／ビューイング活動を追跡する監査証跡は、RAD TF-3: 4.34.1.1.1.15及び4.34.1.1.1.H．に記載してある。「連携用情報書込み」及び連携情報読取りアクタで「基礎的セキュリティ統合プロファイル」のサポートを主張するものは、そのような監査証跡エントリを生成するものとする。
データの暗号化及び連携コンテンツへの他のアクセス制限は、このプロファイルでは扱わない。このプロファイルを使用して作成された連携情報は、鍵のかからない情報（例えば紙の記録）であると考えることが望ましい。そのような連携情報は適切なサイト方針に従って扱うことが望ましい（例えば、他の患者のデータを含むディスクを患者に与えない。部外者などに持ち去られる場所に配置しない）。
ユースケースの多くの場合、多数の患者のデータを単一の連携情報内に入れることは、セキ
ュリティ及びプライバシーの理由から適切ではない。

9／9

Appendix A 地域連携基盤等でPDI形式のデータを利用する場合の留意事項
インターネットなどのネットワークを経由して連携情報を送受信する際、医療機関やサービス提供事業者は、いわゆる3省2ガイドライン等の指針に従い、通信経路の安全対策および利用者の管理などによりセキュリティの確保およびプライバシーの保護を実施する必要がある。セキュリティの確保については、IHE プロファイルであるATNAを利用してもよい。ATNAについては、「（HS031）地域医療連携における情報連携基盤技術仕様」（日本IHE協会発行）を参照のこと。
プライバシーの保護については、患者同意を得た上で情報連携を行うことが特に重要であり、同意を得ていない情報連携が行えない仕組みを確立するなどの対策も必要である。

10／9