循環器部門 Year 2
IHE-J ワークショップ 2006
循環器技術検討WG
大関 毅、 平井 正明、 清水 学
1

お題目
1. IHE CARDとIHE-J 循環器
2. IHE CARD Y1とY2
3. IHE-J 循環器 Y2
1. カテーテル検査ワークフロー （CATH）
2. エコー検査ワークフロー （ECHO）
3. 心電図表示ワークフロー （ECG）
4. 表示できるレポート （DRPT）
5. エビデンスドキュメント （ED）
6. 施設間ドキュメント参照 （IHE-ITI XDS）

2

IHE CARDとIHE-J 循環器
IHE CARDは米国主導でInternationalとして進行している
メインスポンサーはAmerican College of
Cardiology （ACC）である
その他のスポンサーとしてはAmerican
Society for Echocardiography （ASE）、American Society for Nuclear Cardiology(ASNC）、Heart Rhythm Society （HRS）等がある

3

IHE CARDとIHE-J 循環器
IHE-Euro CARDはEuropean Society ofCardiologyがスポンサーとなっている
Planning CommitteeとTechnicalCommitteeに分かれて活動している
両方のChairpersonsはACCのFacultiesから選出されている4

IHE CARDとIHE-J 循環器
IHE CARDはACCのスポンサーで２００３年１２月に発足
Year 1は２００５年３月に完了¾ コネクタソンは２００５年１月に実施¾ デモはACC 2005でオーランドで実施

Year 2は２００６年３月に完了
コネクタソンは２００６年１月に実施¾ デモはACC 2006でアトランタで実施

5

IHE CARDとIHE-J 循環器
現在はYear 3のコネクタソンの準備中¾ １回目のベンダーワークショップ（Educational

Workshop）は６月に実施されたYear 4も既にプランニング段階にある
この後のプレゼンで、Year 3以降の活動内容に関しては説明する

6

IHE CARDとIHE-J 循環器
IHE-Jでは循環器ワークグループは２００４年５月の発足
現在ではベンダ１１社、医事従業者数名が参加
して、約１月に１回のペースで、検討会を開催している

7

IHE CARDとIHE-J 循環器
主な活動内容はテクニカルフレームワーク（TF）の翻訳と、日本での適用の検討、パブリックコメ
ントの募集、試験的導入版（TI版）の作成等と、関連学会等での啓蒙活動等である
IHE-J 循環器ではYear 1ではオリジナルのTFに日本拡張（National Extension）としてECG
部門にMFERを追加した¾ 現在、National ExtensionとしてInternationalへ提出する文書の作成をおこなっている

8

IHE CARDとIHE-J 循環器
Year 1のTFは２００５年６月から７月にかけて２ヶ月間のパブリックコメント期間を経て、TIを発行した
２００６年２月におこなわれたIHE-Jコネクタソンで、接続試験を実施¾ 参加ベンダは全て合格した¾ 結果については、IHE-Jのホームページを参照の事

２００６年３月に名古屋で開催された日本循環器学会においてIHE-J 循環器部門のセッションを学会の協力を得て実施、同時に接続デモをおこなった

9

IHE CARDとIHE-J 循環器
Year 2のTFは現在パブリックコメント募集中で、８月中に寄せられたコメントを反映したTI版を発行する予定である¾ 本日の、プレゼンはパブリックコメント版の内容でおこなわれる事を了承してください¾ TI版で内容の若干の変更がある可能性のあることに留意願います

次回の、参加ベンダ向けのワークショップではTI版の内容を基に説明がおこなわれます
コネクタソンはIHE-Jの他部門と同時に２００７年２月に実
施されます

10

IHE CARD Y1とY2
Year 1は基本的に以下の４つのプロファイルを含む
1. CATH （カテーテル検査ワークフロー）
2. ECHO （心エコー検査ワークフロー）
3. ECG （心電図表示ワークフロー）
4. Consistent Time （時間の統一、IHE ITI）

11

Y1 CATHワークフロー
以下の８つのユースケースが必須とされた¾ Case C1: Patient Registered at ADT and Procedure Orderedat the Order Placer¾ Case C2: Patient Registered at ADT and Procedure Orderedat DSS/OF¾ Case C3: Patient Registered at ADT and Procedure Not
Ordered¾ Case C4: Patient Registered at DSS/OF and Procedure
Ordered¾ Case C5: Patient Not Registered¾ Case C6: Patient Updated During Procedure¾ Case C7: Change Rooms During Procedure¾ Case C8: Cancel Procedure

12

Y1 ECHO ワークフロー
以下の６ユースケースが必須とされた¾ Case E1: Patient Registered at ADT and Procedure Ordered¾ Case E2: Intermittently Connected Modality¾ Case E3: Intermittently Connected Modality with Ad Hoc

Procedure, Patient Registered, Scheduled Procedure¾ Case E4: Intermittently Connected Modality with Ad Hoc
Procedure, Patient Registered, Unscheduled Procedure¾ Case E5: Intermittently Connected Modality with Ad Hoc
Procedure, Patient Unregistered, Unscheduled Procedure¾ Case E6: Stress Echo Staged Protocol

13

Y1 ECG ワークフロー
以下の２つのユースケースが必須とされた¾ Use Case D1: Simple Display¾ Use Case D2: Advanced Display

サポートされた表示形式はPDFとSVG（Scalable Vector Graphic）の２形式のみ

14

IHE CARD Y1とY2
Year 2は基本的に以下の７つのプロファイルを含む
1. CATH （カテーテル検査ワークフロー）
2. ECHO （心エコー検査ワークフロー）
3. ECG （心電図表示ワークフロー）
4. DRPT （表示可能なレポートワークフロー）
5. ED （エビデンスドキュメントワークフロー）
6. XDS （施設間ドキュメントシェアリングワークフロー）
7. Consistent Time （時間の統一、IHE ITI）

15

Y2 CATH ワークフロー
以下の９つのユースケースが必須とされた¾ Case C1: Patient Registered at ADT and Procedure Ordered at theOrder Placer¾ Case C2: Patient Registered at ADT and Procedure Ordered at
DSS/OF¾ Case C3: Patient Registered at ADT and Procedure Not Ordered¾ Case C4: Patient Registered at DSS/OF and Procedure Ordered¾ Case C5: Patient Not Registered¾ Case C6: Patient Updated During Procedure¾ Case C7: Change Rooms During Procedure¾ Case C8: Cancel Procedure¾ Case C9: Post-procedure evidence creation

16

Y2 ECHO ユースケース
以下の７つのユースケースが必須とされた¾ Case E1: Patient Registered at ADT and Procedure Ordered¾ Case E2: Intermittently Connected Modality¾ Case E3: Intermittently Connected Modality with Ad Hoc

Procedure, Patient Registered, Scheduled Procedure¾ Case E4: Intermittently Connected Modality with Ad Hoc
Procedure, Patient Registered, Unscheduled Procedure¾ Case E5: Intermittently Connected Modality with Ad Hoc
Procedure, Patient Unregistered, Unscheduled Procedure¾ Case E6: Stress Echo Staged Protocol¾ Case E7: Echo measurement evidence creation

17

Y2 ECG ワークフロー
Year 1から変更は無いので、以下の２つのユー
スケースのみである¾ Use Case D1: Simple Display¾ Use Case D2: Advanced Display

サポートされた表示形式はPDFとSVG（Scalable Vector Graphic）の２形式のみ

18

Y2 DRPT ワークフロー
この新規のプロファイルには以下の４つのユー
スケースが必須とされている¾ Case R1: Report manager provides local storage

and distribution of reports¾ Case R2: Image manager/archive provides
storage and distribution of reports¾ Case R3: Multiple Reports on one Requested
Procedure¾ Case R4: Preliminary, Final and Corrected
Reports

19

Y2 ED プロファイル
Evidence DocumentプロファイルはRadiologyのTFドキュメントで仕様に関しては解説されているのでそちらを参照願います（RADTF 1:14）
CATHワークフローとECHOワークフローでそれ
ぞれ循環器オプションをユースケースとして記載されているので、そちらを参照の事

20

Y2 XDS ワークフロー
XDSやConsistent Timeのプロファイルに関して、IHE ITIのTFの中に記述されているので、そちらを参照願います
IHE CARDの中では上記のプロファイルに関してはそのまま使用するということで、解説はおこなわれないので、留意願います21

IHE-J 循環器 Y2 プロファイル
基本的には、IHE CARDのTFそのままが採用されている（注：現在パブリックコメント中のドキュメ
ント）
ECGワークフローには変更が無いが、日本拡張しようとして、Year 1からMFERでの表示オプ
ションがそのまま採用されていることに留意

22

Y2 CATH ユースケース
９つのプロファイルが記載されている¾ ケースC1: ADTで患者登録が行われOrder Placerで処置オーダが出される¾ ケースC2: ADTで患者登録されてDSS/OFで処置オーダされる¾ ケースC3: ADTで登録され処置がオーダされていない患者¾ ケースC4: DSS/OFで登録されて処置がオーダされた患者¾ ケースC5: 未登録の患者¾ ケースC6: 処置中に更新された患者¾ ケースC7: 処置中の部屋の変更¾ ケースC8: 処置の中止¾ ケースC9: 処置後のエビデンスの作成

23

Y2 ECHO ワークフロー
以下の７つのユースケースが採用されている¾ ケースE1: ADTと検査オーダで登録された患者¾ ケースE2: 断続的に接続されるモダリティ¾ ケースE3: 臨時処置、登録済患者、予約済処置に関する断続的に接続されるモダリティ¾ ケースE4: 臨時処置、登録済患者、未予約処置に関する断続的に接続されるモダリティ¾ ケースE5: 臨時処置、未登録患者、未予約処置に関する断続的に接続されるモダリティ¾ ケースE6: ストレスエコーステージプロトコル¾ ケース E7: 心エコーの計測エビデンスの作成

24

Y2 ECG ワークフロー
Year 1のTF変わりが無いので、Year 1とまった
く同じである¾ ケース D1:単純な表示¾ ケース D2:高度な表示

表示フォーマットはIHE CARD Internationalと同様に、PDFとSVGであるが、日本拡張として
MFERでの表示も記載されているので、留意

25

Y2 DRPT ワークフロー
Year 2で新規に追加されたプロファイルで、以下の4つのユースケースが記載されている¾ ケース R1: レポートマネジャが、ローカル・ストレージとレポートの配信を提供する¾ ケース R2: イメージマネジャ/アーカイブは、レポートの配信・保存を提供する¾ ケース R3: 一つのRequested Procedureに対する複数のレポート¾ ケース R4: 仮、最終、修正されたレポート

26

Y2 ED プロファイル
エビデンスドキュメントのプロファイルもYear 2で新規に追加になったプロファイル
エビデンスドキュメントのプロファイルに関しては、
放射線部門のTFに詳細が記載されているので、そちらを参照の事
ここでは、循環器オプションのみの解説となる
CATHワークフローとECHOワークフローのそれぞれにユースケースとして追加になっている

27

カテーテル検査ワークフロー
心カテは複雑な処置でワークフローも複雑で問題が多い¾ 処置は予定（予約）されていない事が多い¾ 患者情報が知られていない事もある（海外では急患はほぼ未確認情報である事が多い）¾ エビデンスの収集はオーダが出される前に開始される¾ 複数の機器が処置中のデータを収集する¾ 診断カテーテル検査で始まった処置が途中からPCI等の治療に移行する事が珍しくない

28

問題はご覧の通りです・・・
これはカテ検査のワークフローのほんの１
例です。詳細を読む必要はありませんが、全体をみていただければ複雑さを理解していただけるかと思います。

29

CATHワークフロー概要
ワークフローを管理することによって、循環器部
門では基本的な患者データの連続性と完全性を設立する。特に：¾ 検査の管理（特にカテーテル検査）•

Multi-modality, multiple procedure steps¾ 患者情報の整合性の確保•

未予定（未予約）や緊急検査¾ 時間の同期•

X-ray、 hemo、 IVUS、 ECG、 心エコー検査等

30

CATHワークフロー ： 価値提案
このprofileはカテ室内に存在する異なるモダリティ間の根本的なデータの整合性のベースとなります
どのシステムの時間が正しいのか？
この患者の名前のスペルは・・・？
31

CATHワークフロー：トランザクション図
ADT

Pt. Registration [RAD-1] ↓Patient Update [RAD-12] ↓DSS/ Order Filler↓ Pt. Registration [RAD-1]↓ Patient Update [RAD-12]← Placer Order Management [RAD-2]→ Filler Order Management [RAD-3]↑ Modality PS in Progress [CARD-1]↑ Modality PS Completed [RAD-7]

Year 2の新規部分
エビデンスドキュメント&表示できるレポート

Order Placer↓ Procedure Scheduled [RAD-4]↓ Patient Update [RAD-12]↓ Procedure Updated [RAD-13]↑ Instance Availability Notification [RAD-49]
Evidence
Creator← Modality PS in Progress [CARD-1]← Modality PS Completed [RAD-7]

Performed
Procedure
Step Manager

Storage ↓Commitment[CARD-3]

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

Image
Manager↓ Query Images [RAD-14]↓ Retrieve Images/Evidence [CARD-4]

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

Acquisition
Modality

32

CATHワークフロー ： アクタ群
Acquisition Modality – X線血管造影システムや血行動態測定システムなど、患者がいる間に医学的な画像または波形を収集および作成するシステム。モダリティは、測定値を含むSR（Structured Report）文書などの他のエビデンスオブジェクトを作成する場合もある。

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

Department System Scheduler/Order Filler (DSS/OF) – 外部システムや部
門システムから受け取ったオーダの管理に関する機能を提供する、部門ベース(循環器分野や放射線分野など)の情報システム。

Evidence Creator – 構築された画像（３D等）、計測結果等の追加エビデンスオブジェク
ト（モダリティで作成されるエビデンスオブジェクト以外）作成システム。

Image Archive – 画像、表示状態、キー画像ノート、エビデンス文書などのエビデンスオブジェクトの長期間保存を提供するシステム。

33

CATH ワークフロー ： アクタ群
Image Display – 患者の検査を表示するためのシステム。さらに、画像セット、提示状態、
キー画像ノート、エビデンス文書などを含む、選択したエビデンスオブジェクトの検索と表示をサポートする場合もある。

Image Manager – エビデンスオブジェクトの安全な保管と管理に関する機能を提供するシステム。これらのオブジェクトに関する利用可能性情報をDSSに提供する。

Order Placer – さまざまな部門に対するオーダを生成し、それを正しい部門に配布する、病院または施設の全体に関わるシステム。

Performed Procedure Step Manager (PPSM) – アクイジションモダリ
ティからのモダリティ実施済み処理ステップ情報をDSS/OF（部門システムスケジューラ/オーダフィラー）およびイメージマネージャに再配布するシステム。

Time Client – 自身の日時をタイムサーバによって提供される正確な時刻に同期させるユ
ニット。

34

CATH ワークフロー ： トランザクション
Patient Registration （患者登録） – ADTシステムは、患者の登録および/または受け入れを行い、他の情報システムに情報を転送する。[RAD-1]

Placer Order Management （オーダ送信管理） –オーダ発行側は、オーダ
受注側に対し、オーダの開始または取り消しを通知する。Placer/Filler Order Managementトラ
ンザクションは、新規オーダの開始時には“-New”と示され、既存オーダの取り消し時には“Cancel”と示される場合がある。[RAD-2]

Filler Order Management （オーダ受信管理） –オーダ受注側は、オーダ発
行側に対し、開始、取り消し、またはオーダの状態の変化を通知する。Placer/Filler OrderManagementトランザクションは、新規オーダの開始時には“-New”と示され、既存オーダの取り消し時には“-Cancel”と示されることがある。[RAD-3]

Procedure Scheduled （予約済処置） –スケジュール情報が、DSS/OFからイ
メージマネージャに送信される。[RAD-4]

Query Modality Worklist （モダリティワークリストクエリ） – データ取込
みモダリティで入力されたクエリーに基づき、クエリーを満たすすべての項目を一覧したモダリティ
ワークリストが生成される。選択された患者基本情報のSPS(Scheduled Procedure Steps)のこのリストは、アクイジションモダリティに返される。[RAD-5]

35

CATH ワークフロー ： トランザクション
Modality Procedure Step In Progress –アクイジションモダリティ
は、新しいPS（Procedure Step）の開始を実施処理ステップ管理(PPSM)に通知し、
PPSMはDSS/OFとイメージマネージャに通知する。[CARD-1、RAD-6より派生]

Modality Procedure Step Completed –アクイジションモダリティ
は、PSの完了をPPSMに通知し、PPSMはDSS/OFとイメージマネージャに通知する。
[RAD-7]

Modality Images/Evidence Stored –アクイジションモダリティは、収集または生成された画像、波形、または他のエビデンス文書をイメージアーカイブ送信する。[CARD-2、RAD-8およびRAD-43から派生]

Storage Commitment –要求元(アクイジションモダリティ)はエビデンス文
書、要求元がイメージアーカイブシステムに格納した指定のDICOMオブジェクト(画像、波形、エビデンス文書、またはこれらの組み合わせ)に対する所有権をイメージマネー
ジャが確認することで、イメージマネージャが所有するようになったこれらのオブジェクト
を送信側が削除できるようにすることを要求する。[CARD-3、RAD-10から派生]

36

CATH ワークフロー ： トランザクション
Patient Update – ADT 患者登録システムは、OPおよびDSS/OFに対し、特定の患者に対する新しい情報を通知する。DSS(部門スケジュール管理システム)
は、さらにそれをイメージマネージャに通知する場合がある。[RAD-12]

Procedure Update – DSS/OFは、イメージマネージャに対し、オーダまた
は処理の更新された情報を送信する。[RAD-13]

Query Images –画像表示装置は、イメージアーカイブシステムに対し、患者、検査、シリーズ、またはインスタンスを指定して、画像を表すエントリーのリストを問合わせする。[RAD-14]

Retrieve Images –画像表示装置は、イメージアーカイブシステムに特定の画像または画像の組合わせを要求して取得する。[CARD-4、RAD-16から派生]

Maintain Time –ローカルタイムをタイムサーバの時刻と同期させる。[ITI-1]

37

CATH ワークフロー ： オプション
Instance Availability Notification – IM/IA

は問い合わせのあったアクタ（DSS/OFやレポートマネジャ等）に対して、その時点での指定のあった保存場所での入手可能性に関してのステータスの通知をする。 [RAD-49]

PPS Exception Management – アクイジション
モダリティアクタはMPPSメッセージの中止ステータスをDICOM
2003 PS 3.16 Annex B Context ID 9300で定義されているもののひとつを使用し適切なコードを提供する。

Availability of PPS-Referenced
Instances – その通知を受けた結果、DSS/OF（その他のアクタ）は指定されたインスタンスがワークフロー内での追加利用可能であることをふまえた上で適切なアクションを取らなくてはならない。

38

CATH ワークフロー・ユースケース
全てのユースケースをサポートする事が基本的に必須（現時点で）¾ ケースC1: ADTで患者登録が行われOrder Placerで処置オーダが出される¾ ケースC2: ADTで患者登録されてDSS/OFで処置オーダされる¾ ケースC3: ADTで登録され処置がオーダされていない患者¾ ケースC4: DSS/OFで登録されて処置がオーダされた患者¾ ケースC5: 未登録の患者¾ ケースC6: 処置中に更新された患者¾ ケースC7: 処置中の部屋の変更¾ ケースC8: 処置の中止¾ ケースC9: 処置後のエビデンスの作成

39

ケース C1: ADTで患者登録が行われOrder
Placerで処置オーダが出される
Clinical Context¾ トラディショナルな放射線部門のワークフローに相当します¾ オーダはセントラルシステムで発行される¾ 緊急識別子の生成がおこなわれるケースにも対応する¾ 共通識別子が事前に既知である

IHE Context¾ 最初のモダリティのMMPS in Progressを使用して他のワークリスス

トの更新を行う40

ケース C2: ADTで患者登録されてDSS/OFで処置オーダされるClinical Context¾ ケースC1とはわずかに違う¾ オーダはセントラルシステムで発行されるのではなく部門で発行される¾ 部門システムがセントラルオーダリングシステムに情報を提供する¾ 多数の施設での典型である、検査室でのHIS端末の必要性を軽減する

IHE Context¾ Filler Order Management (New Order) トランザクション [RAD-3] はDepartment System Scheduler/Order FillerからOrder Placerへ送信される

41

ケース C3: ADTで登録され処置がオーダされていない患者
Clinical Context¾ ケース 2とはわずかに違う¾ 処置情報は部門システムに入力されていない¾ 最初に立ち上げるモダリティ（Hemoシステムか）が共通な処置識別子を作成するプロセスを開始しなくてはならない¾ 共通な処置識別子は最初に立ち上がったモダリティからの情報を基に部門システムで作成される¾ もし分類された処置タイプが提供されない場合は『一般カテーテル処置』を生成する

IHE Context¾ 最初の MPPS の受信を受け DSS/OF は自動的に Requested

Procedure を作成し、それと関連した Scheduled Procedure Stepsは最初の MPPS で提供された Study UID を利用する。他のすべてのモダリティは Query Modality Worklist トランザクションを使用する。
42

ケース C4: DSS/OFで登録されて処置がオーダされた患者
Clinical Context¾ このケースは緊急ケースで、ADTシステムで患者登録する時間がな

い場合に適応している¾ 部門レベルで、一時的な患者識別子が生成される¾ OP は患者が登録されてから通知され、マニュアルで部門システムと整合をおこなうIHE Context¾ DSS/OF が一時的な Patient ID と一時的な患者名を割り当て、必要な処置を予約する¾ DSS/OF は Filler Order Management (New Order) トランザクショ
ンを Order Placer には患者が ADT システムで登録されるまで送らず、PIR が DSS/OF おこる
43

ケース C5:未登録の患者
Clinical Context¾ このケースは緊急のケースで患者情報が不明であるか、入力する時間が無い場合のケースである¾ 一時的な患者IDと患者名が部門で割り当てられ、最初のモダリティで入力され、部門システムに情報が転送され他のモダリティと共有される¾ ケース C4 と同様に Order Placer には患者登録後に情報が転送され、部門システムで、 PIR がおこなわれる

IHE Context¾ 患者IDと患者名は（通常部門の）ローカルルールにより決定される¾ 最初のモダリティは MPPS を適切な情報と共に DSS/OF に送り、その後 DSS/OF は適切な Requested Procedure(s) を最初のモダリティで割り当てられた Study UID を使用して生成する

44

ケース C6:処置中に更新された患者
Clinical Context¾ 未確認の患者はADTで登録されているにもかかわらず、カテーテル検査室に一時的な患者IDと患者名を割り当てられて搬送されてくる可能性がある¾ 処置中に患者情報が ADT で更新され、患者の更新情報が送られてくる¾ これにより、一時的な患者IDと関連した一部の情報が残りの恒久的な患者IDと関連した情報と関連する¾ このケースではどのように整合を図るかを定義する

IHE Context¾ モダリティは患者上の更新前に DSS/OF に対し情報を求めるかもしれない¾ Image Manager は Image Archive に保存された項目や続けて受け取る項目に関して情報の更新をする必要がある
45

ケース C7:処置中の部屋の変更
Clinical Context¾ このケースは以下のいずれかの理由で患者が別の部屋に移動された場合のケースである：•••

診断処置からインターベンションへ変更になった
他の患者が部屋を使用する必要が出た
機材の故障等¾ 注意：このケースでは患者カテーテル検査室から患者準備室へ移動されるシナリオには対応していない

46

ケース C7:処置中の部屋の変更
IHE Context¾ それぞれのモダリティは MPS （Completed あるいはDiscontinued）を発行する¾ DSS/OF は新しい部屋で Requested Procedure を再割り当てする¾ DSS/OF が再割り当てをおこなわなかったような場合は、新しい部屋の各モダリティは広範の Modality Worklist Queryをおこなう必要がある¾ これにより Study UID の整合性が保証される

47

ケース C8:処置の中止
Clinical Context¾ このケースにより情報システムは中止された処置を把握できるようになり、カテーテル検査室スタッフが患者に対する問い合わせに適切に対応できるようになる

IHE Context¾ 処置が部門で中止された場合、 DSS/OF は OP と Image Managerに通知する¾ この処置情報が保持される時間の長さはローカルポリシーにより決
定される

48

ケースC9: 処置後のエビデンスの作成
Clinical Context¾ このケースにより画像やその他の処置データを処置後に解析専用ソフトウエア等を使用して解析できるようになる（例：QCA、QLV、派生画像（３D等）等）¾ このケースはコアラボでの解析や術後結果解析等は適用外である

IHE Context¾ この解析等はIDやエビデンスクリエータなどのアクタが存在する

ワークステーション（や同等な機器）で実施されなくてはならない¾ エビデンスクリエータはMPPS In Progress and Completeトラン
ザクションを使用して、IM/IAやDSS/OFに活動を通知する¾ エビデンスクリエータはStorage CommitmentトランザクションでIM/IAにエビデンスを保存する
49

心エコーのワークフロー
類似の IHE - 放射線科部門プロフィールの利用¾ Scheduled Workflow (IHE-R SWF)
¾ Patient Information Reconciliation (IHE-R PIR)

随時ネットワークに接続するモバイル装置¾ Workflow¾ モバイル装置によるデータの収集と保存

ストレスエコー¾ Workflow¾ Staged Protocol• データ収集モダリティ (オプション)• 画像表示機能 (必須)

デジタル画像 vs ビデオテープ

50

心エコーワークフローＹｅａｒ１に含まれる項目

心エコー検査の種類¾ 経胸壁心エコー（TTE)、経食道心エコー（TEE)、ストレスエコー

心エコー検査の管理 （画像モダリティーに限定）¾ IHE-RadiologyのSWFに近似¾ 患者ID/オーダ/予約ステータス報告/ストレスエコーなどの複数ステージ検査、データ保存¾ 一時的にネットワーク接続するモバイル装置も含む

患者情報の整合（PIR）¾ IHE-RadiologyのPIRに近似¾ 予約外の心エコー検査も例外ではない
51

心エコーワークフローＹｅａｒ１に含まれない項目
看護ノートや薬剤投与文書
計測/測定結果 →Year ２ で含む
４次元超音波 (リアルタイム３D超音波)
その他：心カテワークフローの方で対応するもの¾ 血管内超音波（IVUS)¾ 心臓内心エコー（ICE)52

心エコーワークフローYear 2での追加項目
計測値/測定結果のデータ
エビデンス ドキュメント53

アクタとトランザクション
循環器として新しいアクタは無い¾ 放射線部門のスケジュールワークフローと同じアクタ群

４つの”モディファイド”トランザクション¾ 存在する放射線部門のトランザクションをモディファイして循環器部門に特化したトランザクションとする

54

心エコー検査のアクタとトランザクション
ADT

Pt. Registration [RAD-1] ↓Patient Update [RAD-12] ↓DSS/ Order Filler↓ Pt. Registration [RAD-1]↓ Patient Update [RAD-12]← Placer Order Management [RAD-2]→ Filler Order Management [RAD-3]↑ Modality PS in Progress [CARD-1]↑ Modality PS Completed [RAD-7]

Year 2の新規部分
エビデンスドキュメント&表示できるレポート

Order Placer↓ Procedure Scheduled [RAD-4]↓ Patient Update [RAD-12]↓ Procedure Updated [RAD-13]↑ Instance Availability Notification [RAD-49]
Evidence
Creator← Modality PS in Progress [CARD-1]← Modality PS Completed [RAD-7]

Performed
Procedure
Step Manager

Storage ↓Commitment[CARD-3]

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

Image
Manager↓ Query Images [RAD-14]↓ Retrieve Images/Evidence [CARD-4]

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

Acquisition
Modality55

心エコー検査のアクタ群
Acquisition Modality – アクイジションモダリティ
ADT – 患者登録システム
DSS/OF （Department System Scheduler/Order Filler）¾ 部門システムスケジューラ･オーダ受注側
Image Archive – イメージアーカイブ
Image Display – 画像表示装置
Image Manager – イメージマネージャ
Order Placer – オーダ発注
PPSM （Performed Procedure Step Manager）¾ 実施済み処置ステップマネージャ

56

心エコー検査各アクタ群のトランザクション (ADT,OP)

ADT Patient Registration – 患者登録システム¾ Patient Registration – 患者登録 [RAD-1]¾ Patient Update – 患者更新 [RAD-12]

OP – オーダ発注¾ Patient Registration – 患者登録 [RAD-1]¾ Patient Update – 患者更新 [RAD-12]¾ Placer Order Management – オーダ発行管理 [RAD-2]¾ Filler Order Management – オーダ受信管理 [RAD-3]

57

心エコー検査各アクタ群のトランザクション (DFF/OF)
DSS/OF （Department System Scheduler/Order Filler）¾ 部門システムスケジューラ･オーダ Patient Registration¾ 患者登録 [RAD-1]• Patient Update – 患者更新
[RAD-12][RAD-2]• Placer Order Management – オーダ発行管理[RAD-3]• Filler Order Management – オーダ受信管理[RAD-4]• Procedure Scheduled – 予約済み処置• Query Modality Worklist – モダリティワークリストクエリ [RAD-5]• Modality Procedure Step In Progress – モダリティ検査 検査進行中[CARD-1, derived from RAD-6]• Modality Procedure Step Completed – モダリティ検査 完了 [RAD-7][RAD-13]• Procedure Update – 処置更新

58

心エコー検査各アクタ群のトランザクション (AM)

Acquisition Modality¾ Query Modality Worklist – モダリティワークリストクエリ[RAD-5]¾ Modality Procedure Step In Progress – モダリティ検査 検査進行中[CARD-1, derived from RAD-6]¾ Modality Procedure Step Completed – モダリティ検査 完了[RAD7]¾ Modality Images/Evidence Stored [CARD2]¾ Storage Commitment [CARD-3]

59

心エコー検査各アクタ群のトランザクション (IM／IA)

Image Manager / Image Archive¾ Procedure Scheduled – スケジュール検査[RAD-４]¾ Modality Procedure Step In Progress – モダリティ検査 検査

進行中[CARD-1, derived from RAD-6]¾ Modality Procedure Step Completed – モダリティ検査 完了[RAD-7]¾ Modality Images/Evidence Stored [CARD2]¾ Storage Commitment [CARD-3]¾ Procedure Update – 処置更新[RAD-13]¾ Query Images – 画像クエリ[RAD-14]¾ Retrieve Images –画像参照 [CARD-4, derived from RAD-16]

60

心エコー検査各アクタ群のトランザクション (PPSM/ID)

Preformed Procedure Steｐ Manager¾ Modality Procedure Step In Progress – モダリティ検査 検査進行中[CARD-1, derived from RAD-6]¾ Modality Procedure Step Completed – モダリティ検査 完了[RAD-7]¾ Patient Registration – 患者登録[RAD-1]

Image Display¾ Query Images – 画像クエリ[RAD-14]¾ Retrieve Images –画像参照 [CARD-4, derived from RAD-16]

61

心エコー検査 ６ユースケース
Case E1: 患者はADTで登録され、手技はOPでオーダされていて、検査室内の装置でワークリストトランザクションが利用できる場合

Case E2:患者はADTで登録され、手技はOPでオーダされていて、モバイル装置でワークリストトランザクションが利用できる場合

Case E3: 患者はADTで登録され、手技はOPでオーダされているが、モバイル装置でワークリストトランザクションが利用できない場合

Case E4:患者はADTで登録済みだが、手技はOPでオーダされていない緊急で、
モバイル装置でワークリストトランザクションが利用できない場合

Case E5: 患者はADT未登録で、手技もOPでオーダされていない緊急例で、モバイル装置でワークリストトランザクションが利用できない場合

Case E6: ストレスエコーのステージプロトコルの場合

62

Case E1の例:
患者はADTで登録され、手技はOPでオーダされていて、検査室内の装置でワークリストトランザクションが利用できる場合

臨床的シナリオ¾ 従来の放射線科部門の予約済検査ワークフローに対応¾ オーダは特定のエコー処置に対するオーダプレーサシステムまたは部門システムから発行¾ 緊急患者IDが作成される特殊ケースも考慮

IHE的シナリオ¾ IHEデータモデルの３レベル(オーダ、要求済処置、予約済/実行

済処置ステップ)を利用して検査を依頼¾ 完全な予約済処置を含む

63

Case E2の例:
患者はADTで登録され、手技はOPでオーダされていて、モバイル装置でワーク
リストトランザクションが利用できる場合

臨床的シナリオ¾ ネットワークに断続的にのみ接続されるモバイル超音波診断装置を使用した検査¾ 接続は“シフト”の開始時と終了時に確立される¾ “断続的な接続”はモダリティの電源OFFの場合も含む

IHE的シナリオ¾ シフト開始時のモダリティ問い合わせワークフロートランザクションでそのシフトに対して¾¾¾¾

予約されている検査ステップの一覧を取得
超音波検査技師はワークリストにリストされている検査を実施
ネットワーク接続を切った際にはMPPS処理中または終了トランザクションは送信不可
シフト終了時のネットワーク再接続の際にシフトのアクティビティに対するMPPSメッセージを送信
続けて画像保存トランザクションを送信、これらの収集に対するStorage Commitmentを送
信¾ トランザクション送信の遅延はIHEの予約済ワークフロープロファイルに於ける

DSS/Order Filler及びイメージマネージャ/イメージアーカイブシステムの通常操
作と一致
64

Case E3の例:
患者はADTで登録され、手技はOPでオーダされているが、モバイル装置でワークリストトランザクションが利用できない場合
臨床的シナリオ¾ モバイル超音波診断装置が移動中（ネットワークに接続されていない状態）に超音波検査技師がワークリスト問い合わせトランザクションに於いて予約されていなかった検査の実施通知を受け取った場合

IHE的シナリオ¾ オーダはOPシステムまたはDSS/OFに於いて作成でき予約済、処置はDSS/OFで予約済だが、モバイル超音波診断装置が移動中のためMWMトランザクションが実行できない¾ モバイル超音波診断装置がネットワーク再接続時に依頼済処置または予約済処置の情報を含まないMPPS処理中メッセージを送信¾ DSS/OFで整合を実施するための例外処理を生成する•••

MPPS処理中メッセージで指定の患者IDに対する患者基本情報の修正実施済処理とDSS/OFが認識しているオーダ及び依頼処理とのマッチング
DSS/OFはステータスの処理更新/キャンセルをイメージマネージャに送信し、MPPS処理中メッセージからの検査インスタンスUIDを含む新予約済処置を生成¾ 画像マネジャは患者更新トランザクションを使って超音波装置からのオブジェクトの患者基本情

報を更新

65

Case E４の例:
患者はADTで登録済みだが、手技はOPでオーダされていない緊急で、モバイル装置でワークリストトランザクションが利用できない場合

臨床的シナリオ¾ モバイル超音波診断装置が移動中（ネットワークに接続されていない状態）に超音波検査技師が登録済の患者の緊急エコー検査の実施通知を受け取った場合

IHE的シナリオ¾ 放射線科部門の患者情報の整合性確保のプロファイルにある未予約処理の場合と同様¾ 患者IDを含む患者基本情報は超音波診断装置側で手入力、検査インスタンスUIDも超音波診断装置側で作成¾ モバイル超音波診断装置がネットワーク再接続時に依頼済処置または予約済処置の情報を含まないMPPS処理中メッセージを送信¾ DSS/OFで整合を実施するための例外処理の生成 （ケース３と同じ）• MPPS処理中メッセージで指定の患者IDに対する患者基本情報の修正• DSS/OFは実施済み処理に対する新しいオーダを作成し、処理中ステータスと伴にOPへ送信し、MPPS処理中メッセージからの検査インスタンスUIDを含む新予約済
処置を生成¾ 画像マネジャは患者更新トランザクションを使って超音波装置からのオブジェクトの患者
基本情報を更新
66

Case E5の例:
患者はADT未登録で、手技もOPでオーダされていない緊急例で、モバイル装置でワークリストトランザクションが利用できない場合

臨床的シナリオ¾ モバイル超音波診断装置を移動中（ネットワークに接続されていない状態）に超音波検査技師

が識別不可な患者の緊急エコー検査の実施通知を受け取った場合

IHE的シナリオ¾ 放射線科部門の患者情報の整合性確保のプロファイルにある未予約処理の場合と同様¾ 一時的な患者IDと名前を超音波診断装置側で手入力、検査インスタンスUIDも超音波診断装置側で作成¾ モバイル超音波診断装置がネットワーク再接続時に依頼済処置または予約済処置の情報を含まないMPPS処理中メッセージを送信¾ DSS/OFで整合を実施するための例外処理の生成 MPPS処理中メッセージで指定の患者IDに対する患者基本情報の修正•患者が登録されると、DSS/OFは患者登録とローカルな一時的IDを整合し、患者更新をイメージマネージャに送信•
イメージマネジャは患者更新トランザクションを使って超音波装置からのオブジェクトの患者基本情報を更新•
実施済み処理に対する新しいオーダを作成しOPへ送信し、MPPS処理中メッセージからの検査インスタンスUIDを含む予約済処置を生成
イメージマネージャはオブジェクト内のオーダと検査情報を予約済処理に基づいて更新•

67

Case E6の例:
ストレスエコーのステージプロトコルの場合
臨床的シナリオ¾ “ステージ”と呼ぶ2つ以上の時間間隔で“ビュー”と呼ぶ一貫した画像セットが、各ステージの検査中に収集される¾ ビューは超音波素子の特定の位置と向きに於いて収集された組織の断面図¾ 異なる時間間隔の異なる負荷(運動または投薬による)レベルで、2チェンバー、4チェンバー、長軸、短軸などのビュー断面像を得るし心臓ストレスエコー検査

IHE的シナリオ¾ E1のネットワークに接続されたモダリティまたはE2の断続的にネットワークに接続されたモダリティの場合と同様¾ ストレス・プロトコルのタイプは、予約済プロトコル・コード・シーケンスあるいは予約済モダリティワークリストステップの記述によって画像収集モダリティに指定¾ “データ収集の実施”には複数のステージがあるが、一般的に、これらは同じ処置
ステップの一部¾ 最後のMPPS は、臨床的終了ポイントに達したすべてのケースについて、完了のステータスを示す¾ 中止ステータスは、臨床的終了ポイントへの到達を妨げる技術的障害に対して使用可能
68

Case E７の例:
心エコーの計測エビデンス作成の場合

臨床的シナリオ¾ 通常、計測(例えば拡張期・収縮期における左心室の径など)は心エコー検査中に行われる．
¾ この場合、クリニカルワークステーション上で検査の後処理として追加計測などを行い検査データを更新することができる．

IHE的シナリオ¾ この場合カテのケースＣ９に類似している¾ アクタはＥＣＨＯとＥＤのプロファイルに属している¾ DICOM SRの作成はオリジナルを参照
69

心電図参照: Retrieve ECG for Display
Ｗｅｂ技術を使っていつでもどこでも必要な心電図を参照
診断レベルの高品質の心電図の表示
必要に応じて過去の心電図を比較表示（標準１２誘導心電図以外の波形の表示）※IHEIHE-Jのみオプション（2次利用のための波形の提供） ※IHEIHE-Jのみオプション

70

Retrieve ECG for Display Actor Diagram
Retrieve Specific Info for Display [ITI-11]
Retrieve ECG List [Card-5]
Information
SourceDisplay

Retrieve ECG Document for Display [Card-6]
Actors

Optional
ity
O

ITI-TF 2 3.11

Retrieve ECG List [CARD-5]

O

CARD-TF 2:4.5

Retrieve ECG Document for Display[CARD-6]Specific Info for Display [ITI-11]
RetrieveR

CARD-TF 2:4.5

R

ITI-TF 2 4.11

Retrieve ECG List [CARD-5]

R

CARD-TF 2:4.5

Retrieve ECG Document for Display[CARD-6]

R/O

CARD-TF 2:4.5

Transactions
Retrieve Specific Info for Display [ITI-11]

Display

Information
SourceSection V2

71

Retrieve ECG List Process Flow
Information
SourceRetrieve Specific Info [ITI-11]
or Retrieve ECG List [CARD-5]
Prepare ECG
Information for
Display

Request for
Information ona patient
Display
Information

Retrieve Specific Info [ITI-11]
or Retrieve ECG List [CARD-5]
Information notfound orinformation typenot supported

Display

Request for
Information ona patient
Display Error

72

Retrieve ECG Document Process Flow
Information
SourceRetrieve ECG Document for
Display [CARD-6]
Prepare Selected
ECG Document
for Display

Request for
ECG Document
Display ECG
Document
Content

Retrieve ECG Document for
Display [CARD-6]
Requested
Document does
not exist or client
proposed formats
not supported

Display

Request for
ECG Document
Display Error

73

Web service request types
Request Type Value
SUMMARY
SUMMAYCARDIOLOGY

Description
Summary of all reports known to the
Information Source
Summary of Cardiology reports

http://<location>/IHERetrieveSummaryInfo?requestType=SUMMARY&patientID=99
998410^^^%26www.mlhlife.com%26DNS &lowerDateTime=2003-0101T00:00:00&upperDateTime=2003-01-01T23:59:59&mostRecentResults=1

Request Type Value
SUMMAY-CARDIOLOGYECG

Description
List of ECG documents

http://<location>/<IHERetrieveDocument>?requestType=”DOCUMENT”&documentUID=”
1.2.3”&preferredContentType=”application/pdf”
1.2.3^4.5.6で2つの波形を同時表示
application/mwf
74

SVGによる表示75

MFERビューアによる波形比較表示

76

77

心電図一覧の表示 (HL7 V3)

RIDによるHTMLのサービスでもＯＫ
78

IHE V3(XML+XSL)による心電図一覧表示

79IHE-J用(HTML)日本語表示による心電図一覧80

MFERビューアによる標準１２誘導心電図表示81

MFERビューアによる波形計測表示

82

波形比較表示83

心カテ波形の表示

84

CDA R2とMFERビューアによる心電図結果表示85

DRPT ワークフロー ： 問題点
存在するほとんどのレポートアプリケーションは紙ベースのパラダイムを使用¾ プリント¾ 手書き（署名等）¾ FAX“進化”しているアプリでは電子化機能があるが・・・¾ 保存／データベース¾ 電子サイン¾ システムから直接FAX（あるいはe-Mail）

増加する電子化されたレポートの中心的なレポジトリの要望¾ 統一されていない実現に向けての要求仕様

86

DRPT ： 概要とスコープ
PDFでフォーマットされた臨床レポートの管理¾ PDFは数多くの紙ベースのレポートで有効な特徴を保持できる作成、サイン／リリース、配布
レポートレポジトリ／アーカイブ¾ １レベルでの保存は必須である（通常当該部門）¾ ２次レベルでの追加保存もサポートされている（施設全体での）標準的フォーマットでの施設内集中レポジトリ／レジスト
リへの電子的提出¾ PDFドキュメント、またはドキュメント保存場所のリファレンス

（URL）

87

DRTP ： 価値提案
既に存在する数多くの臨床レポートアプリケーションはPDFを使用している
グラフィックコンテンツをサポートしている（循環器レポートでは重要）¾ ECG用のベクトルグラフィックを含む

ソースシステムがレポートの”見え方”をコントロールする¾ 臨床的にもビジネス的にも重要¾ 司法的にも法的に同一のレポートの提示が必要になる場合がある

88

DRTP ： 価値提案
一定したアクタとトランザクションがレポーティングプロセスを表現
する
IM/IAが部門レポートレポジトリとして影響力を発揮できる可能性がある
分散されている施設内のレポート保存アーキテクチャをサポートしている

89

DRPT ： レポート例90

DRPT : トランザクション図
ReportCreatorEncapsulated Report Submission [CARD-7] ↓ReportManager
Encapsulated Report Storage [CARD-9] ↓Storage Commitment [RAD-10] ↓ReportRepository
Encapsulated Report Query [CARD-10] ↑Encapsulated Report Retrieve [CARD-11] ↑ReportReaderEncapsulated Report Submission [CARD-7] →→Report Reference Submission [CARD-8]

Enterprise
ReportRepository

Retrieve Information for Display (RID) Profile
Information
Source↑ Retrieve Specific Info for Display [ITI-11]↑ Retrieve Document for Display [ITI-12]

Display91

DRPT : アクタ群
Report Creator – 臨床レポートを作成し、発行（転送）するシ
ステム
Report Manager – レポート作成のステータスやレポートレポ
ジトリへ配信（複数対象も可）を管理するシステム
Report Reader – レポートをQ/Rでき、DICOMオブジェクトとしてエンコードされているレポートを観る事ができるシステム
Report Repository – レポート受信し、長期にわたってアクセスできるよう保存する部門システム¾ Information Sourceアクタとグループ化されなくてはならない – 特定の情報やドキュメントの要求に対して対応するシステムで要求しているアクタで表示されるようにready-for-presentationな情報を返すシステム

Enterprise Report Repository – レポートかレポートの保存場所のリファレンス（ポインタ） （あるいは両方）を受け取り、医療機関内全体からのアクセスの為に保存するシステム

92

DRPT : 使用される標準
PDF – レポートコンテントフォーマット
HL7 v2 – カプセル化されたレポートの提出とレポートのリファレンスの提出¾ ORU

DICOM – カプセル化されたレポートの保存、クエリ、読み出し¾ カプセル化されたPDFの保存¾ Storage Commitment¾ Query¾ Retrieve

93

DRPT – 使用される標準
HL7

MSH|^~¥$|…
PID|1|0123456-1||R…
OBR|1|X89-1501^…
OBX|1|ED|11528-7^LN…

HL7

MSH|^~¥$|…
MSH|^~¥$|…
PID|1|0123456-1||R…
PID|1|0123456-1||R…
OBR|1|X89-1501^…
OBR|1|X89-1501^…
OBX|1|RP|11528-7^LN…
OBX|1|ED|11528-7^LN…
http://serv.hosp.org/app?req
uestType=DOCUMENT&documentUID=”1.2.3”&pref
erredContentType=”applicat
ion/pdf”

HL7

MSH|^~¥$|…
PID|1|0123456-1||R…
OBR|1|X89-1501^…
OBX|1|ED|11528-7^LN…

ReportCreatorEncapsulated Report Submission [CARD-7] ↓DICOM

ReportManager(0008,0005) IR_100(0008,0012) 20061113(0008,0013) 1109
(0008,0016) 1.2.8401008.…

Encapsulated Report Submission [CARD-7]→
Report Reference Submission [CARD-8] →Enterprise
ReportRepository

Encapsulated Report Storage [CARD-9] ↓Storage Commitment [RAD-10] ↓ReportRepository
Encapsulated Report Query [CARD-10] ↑Encapsulated Report Retrieve [CARD-11] ↑DICOM(0008,0005) IR_100(0008,0012) 20061113(0008,0013) 1109
(0008,0016) 1.2.8401008.…

ReportReaderInformation
Source↑ Retrieve Specific Info for Display [ITI-11]↑ Retrieve Document for Display [ITI-12]
HTTP
Display

どのように非DICOMレポートマネージャが係われるか？
94

DRPT : オプションとアクタのグループ化
レポートマネージャはDICOM Storageオプションをサポートしても可¾ IM/IAをレポートレポジトリとして使用する場合はDICOMカプセル化されたPDFを使用するもしDICOMオプションが実装されていない場合は、レポートマ
ネージャはレポートレポジトリとグループ化されなくてはいけない¾ これにより独自の内部通信の実装を許可できる

DICOMカプセル化されたPDFのQ/Rはレポートレポジトリのオプションである¾ もしこれが実装されない場合は、ワークステーションがRIDを使用して、レポートにアクセスしなくてはならない

Enterprise Report Repositoryはカプセル化されたドキュメン
トまたはドキュメントリファレンスを受信してもよい¾ レポートマネージャは両方のフォーマットをサポートしなければいけない（設定できるように）¾ ドキュメントリファレンスはRID Retrieve Document for Display URL
95

DRPT：グループ化されたレポートマネージャとレポジトリ
HL7

MSH|^~¥$|…
PID|1|0123456-1||R…
OBR|1|X89-1501^…
OBX|1|ED|11528-7^LN…

HL7

MSH|^~¥$|…
MSH|^~¥$|…
PID|1|0123456-1||R…
PID|1|0123456-1||R…
OBR|1|X89-1501^…
OBR|1|X89-1501^…
OBX|1|RP|11528-7^LN…
OBX|1|ED|11528-7^LN…
http://serv.hosp.org/app?req
uestType=DOCUMENT&documentUID=”1.2.3”&pref
erredContentType=”applicat
ion/pdf”

HL7

MSH|^~¥$|…
PID|1|0123456-1||R…
OBR|1|X89-1501^…
OBX|1|ED|11528-7^LN…

ReportCreatorEncapsulated Report Submission [CARD-7] ↓ReportManager
ReportRepository
Encapsulated Report Query [CARD-10] ↑Encapsulated Report Retrieve [CARD-11] ↑DICOMオプション

未実装

ReportReaderEncapsulated Report Submission [CARD-7]→
Report Reference Submission [CARD-8] →Information
SourceEnterprise
ReportRepository↑ Retrieve Specific Info for Display [ITI-11]↑ Retrieve Document for Display [ITI-12]
HTTP
Display96

Report Creator ： 要求事項のまとめ
PDFレポートの作成
HL7 v2 ORUメッセージの作成¾ DICOM Procedureに関連している場合はOBXセグメントにDICOM

Study UIDを含む¾ OBXセグメントにカプセル化されたPDF¾ ORCとOBXセグメントにステータスをセット¾ レポートマネージャに送信

持続的（長期的）にレポートを保存してはいけない¾ レポートマネージャがリリースされたレポートの内容に責任がある。レポートクリエータローカルに保存されたレポートの内容は公式レポート内
容と不一致になる可能性がある（例えば患者情報のアップデートがあっ
た場合等）

97

レポートマネージャ ： 要求事項のまとめ
HL7 v2 ORUメッセージにカプセル化されたPDFを受信する
レポートのリリースの管理¾ 未確定または確定済みのレポートをリリースしてもよい（製品の機能または運用ルールによる設定）¾ オプションで電子サインを管理してもよい¾ 正しい患者情報やサイン、レポートのステータスを含んだカバーページ
をPDFに追加する

レポートの保存
¾ DICOMカプセル化されたPDFをグループ化されていないレポートレポ

ジトリへ¾ 特に定義されていない方法でグループ化されているレポートレポジトリ
へ

レポートをEnterprise Report Repositoryへ転送¾ 設定された通りカプセル化されたPDFと（あるいは）RID URL
98

レポートマネージャの問題
レポートクリエータとレポートマネージャがグループ化された製品であっても、外部のレポートクリエータをサポートしなくてはならないレポートマネージャはレポートの種類（レポートのタイトル）でサポートするレポートに制限をかけてはならない¾ 画像の種類でサポートの制限をかけてもよいDICOM IMとは違う¾ 全ての表示可能なレポートは基本的には同じである － カプセル化されたPDFであるので、レポートの内容ではプロセスされない

レポートマネージャアクタはPIRプロファイルにも含まれる¾ Patient UpdateとProcedure Updateトランザクションでレポートマネージャはenterprise-levelアクタである可能性もある99

レポートレポジトリ ： 要求事項のまとめ（非グループ化）

カプセル化されたPDFをDICOMメッセージで受信する
HTTP Getを使用してRID Information Source経由でレポートを提供¾ レポートのサマリリスト¾ PDFレポートドキュメント単体

DICOM経由でレポートを提供¾ カプセル化されたPDFのDICOM Q/R

IM/IA （PACS）に追加されるべき妥当な機能である

100

レポートリーダ ： 要求事項のまとめ
カプセル化されたPDFのDICOM Q/R¾ スタディ画像とエビデンス内容に基づいたアクセスを許可 – DICOM

スタディの完全な検索においてレポートの検索も可能にする

PDFコンテンツの提出
ID（ワークステーション）に追加されるべき妥当な機能

101

Enterprise Report Repository ：要求事項のまとめHL7 v2 ORUメッセージにカプセル化されたPDFを受信
またはReceive PDF reference in HL7 v2 ORUメッセージにリファレンスされているPDFを受信
レポートを施設全体に不特定の機能で施設内に提供¾ レポートレポジトリアクタからのRIDサービスに追加¾ Enterprise Report Repositoryはリファレンスのみ実装しても可（完全分散型アーキテクチャ）

102

DRPTとXDS
DRPTプロファイルは組織内でのレポートの作成を特定している
施設間ドキュメント共有（XDS）プロファイルは１組織（施設）の外部へのレポートの配信を定義している
通常、組織内で作成されたレポートの一部分のみ外部と共有される
外部で共有されるレポートはXDSの”Affinity Domain”
で使用される患者IDで識別されなくてはならない
XDSドキュメントエクスポートは Enterprise Report
Repositoryにグループ化されるべき妥当な機能である

103

エビデンスドキュメント？
アクイジションと臨床的リポートの中間的な生成物¾ 最初のエビデンス（画像や、波形）から派生したデータ（計測値等）¾ 手動または自動的に派生

アクイジションステップのパフォーマンスに関連したデー
タ¾ プロシージャログ

アクイジションモダリティまたはエビデンスクリエータで生成される （ワークステーションや自動プロセス）¾ アクイジション中かポストプロセスワークフローで作成される画像や他の取得されたデータと共に臨床レポート作成において、判断される

104

現実は・・・
計測はモダリティやワークステーションでおこなわれ、紙のワークシートに書き写され、最終的にレポートに書き込まれる
解析結果はプリントアウトや他の形でアウトプットされる。その途中で、アプリケーションでデータを抽出される
スクリーンキャプチャをレポートシステムに送り、OCRを使ってもとの計測名やデータ数値を再現して入力する• 間違えやすく、非効率、設定が難しく、管理も難しい

105

EDプロファイル ： 概要とスコープ
DICOM SRでフォーマットされた計測値、ログ、
CAD結果の管理
作成、保存、参照
計測結果のレポートへの追加

106

DICOM SR例 ： 計測
Echocardiography Measurement
Patient: Doe, John Technologist: der Payd, N
Measurements:
Mitral valve diameter 3.1cm- shown in image at [ ]Ventricular length, diastolic 5.97 cm- shown in image at [ ]Ventricular volume, diastolic 14.1 ml- inferred from [ ]- inferred from VLZ algorithm

107

DICOM SR例 : プロシージャログ
Catheterization Procedure Log
Patient: Doe, John Technologist: Logger, H. Moe
11:15:37 Patient admitted
11:18:39 Physician arrived- ver Payd, O
11:20:46 Patient prepped and draped
11:22:07 Drug administered- Agent: D51/2NS- Volume: 400 ml- Rate: 30 ml/hr- Route: IV
11:22:13 Vital signs- NIBP Systolic: 105 mm(Hg)- NIBP Diastolic: 59 mm(Hg)- HR: 101 /min
- Resp: 21 /min
11:23:16 Consumable: 7Fr sheath
11:24:11 Sheath inserted- Right Femoral Artery...

11:41:08 Catheter placed- Left Ventricle
11:41:21 Waveform acquired [ ]- Modality: HD- Technique: Aortic valve pullback
11:43:11 Drug administered- Agent: Omnipaque- Volume: 30 ml- Rate: 20 ml/s
- Route: power injection
11:43:29 Image acquired [ ]- Modality: XA- Number of frames: 77- Positioner primary angle: 30 deg- Positioner secondary angle: 60 deg
...

108

DICOM SR例 : CAD

Mammography CAD Results
Patient: Doe, Jane
Overall Findings: Successful analysis- Suspicious abnormality, biopsy should be considered- Follow-up immediately
Feature: Mass
Scope: Detected on multiple images
Algorithm: Lesion Analyzer V.1.3
Pathology: Lobular carcinoma in situ
Image: [ ]Feature: Calcification
...

109

DICOM SR 特徴
構造化されたコンテンツ¾ リスト、階層的、関係

数的計測、コード化された値¾ データベースやデータ間イニングの為の自動抽出が可能

画像や、波形、その他オブジェクトにリファレンス
明確なコンテキスト情報¾ ドキュメントに明白な意味を持たせる

110

SRコンテンツツリーとSRテンプレート
データは階層的コンテンツアイテムツリーで構成されているツリー構造、アイテム間関係、コンセプトとコード化された値はテンプ
レートにより規定されている
Root Content Item
Document Title

Content Item

Content Item

Content Item

Content Item

Rel with
ParentContent Item

VT

Concept NameCONTAINER

DT (DCM, D-640-017),“Thermal Cardiac Output
Technique Properties”
DT (DCM, D-640-018),“Thermal Cardiac Output
Method”
DT (DCM, D-640-019,“Catheter Size”)
DT (DCM, D-640-020,“Injectate Temperature”
DT (DCM, D-640-021,“Injectate Volume”
DT (DCM, D-640-022,“Calibration Factor”

CONTAINSCODE

CONTAINSNUM

CONTAINSNUM

CONTAINSNUM

CONTAINSNUM

VM ReqType

Condition

Value Set Constraint

1

M

DCID (CID 618) “Thermal
Cardiac Output Methods”

1

M

1

M

1

M

1

M

UNITS = DT (UCUM, [Ch],“French”
UNITS = DT (UCUM, Cel,“°C”)
UNITS = DT (UCUM, ml,“milliliter”)
UNITS = DT (UCUM, 1,“unary, no units”)

Content Item

Content Item111

EDプロファイル ：価値提案
DICOM SRは計測、プロシージャログ、CAD結果との標準的なインターフェースを提供する¾ マニュアル記録、書き写すステップを取り除ける¾ ベンダ特定の設定を最小限に出来る

DICOMテンプレートは意味的に相互利用可能な計測名や一貫した階層構造を定義¾ クリエータとレシーバに自動プロセスを可能にさせる

EDプロファイルは画像交換データフローに匹敵する計測
値を交換する為のアクタやトランザクションを明記する¾ SWF、CATH、ECHOプロファイルと一貫している

112

EDプロファイル ： トランザクション図

Evidence Creator

RAD-10: Storage ↓Commitment

Image
ManagerRAD-10: Storage
Commitment ↑Image Display↓ RAD-43: Evidence
Documents Stored

ReportCreator↓ RAD-44: Query Evidence Documents↓ RAD-45: Retrieve Evidence Documents

Image
Archive

RAD-43: Evidence↑ Documents Stored

Acquisition Modality113

EDプロファイル ： アクタ
Acquisition Modality – 医用画像や波形データを患者が居る間に取得、作成するシステムで、その他のエビデンスオブジェクト（計測値等）も作成するEvidence Creator – 追加されるエビデンスオブジェクト（派生画像や計測値）を作成するシステム
Image Manager / Image Archive – 画像や他のエビデンスオブ
ジェクトを長期保存や管理するシステム
Image Display – 患者に対するスタディのブラウジング、選択された画像や他のエビデンスオブジェクトを読み出して表示する機能を提供するシステム
Report Creator – 臨床レポートを作成して発信するシステム。この
プロファイルではIDとグループ化されなくてはならない

114

EDプロファイル ： 使用される標準
DICOMサービス¾ SR保存• Enhanced• Comprehensive• Procedure Log• CAD¾ Storage Commitment¾ Query¾ Retrieve

DICOM SRテンプレート

115

EDプロファイル ： オプション
CATHエビデンスオプション – モダリティ／エビデンスクリエータは最低下記のうちの１つのCATHテンプレートをサポートする必要がある¾ 3001 Procedure Log¾ 3202 Ventricular Analysis¾ 3213 Quantitative Arterial Analysis¾ 3250 Intravascular Ultrasound¾ 3500 Hemodynamics

ECHOエビデンスオプション –モダリティ／エビデンスクリエータは最低
下記のうちの１つのECHOテンプレートをサポートする必要がある¾ 5100 Vascular Ultrasound¾ 5200 Echocardiography

116

Image Displayの問題
IDアクタはDICOM SRのディプレイルールに従わなくてはならない¾ テンプレート如何によらずSRオブジェクトの完全なコンテンツツリーを表現しなくてはならない

EDレポートクリエータアクタは臨床レポートにEDからのデータを利用可能である製品である事を強調される¾ レポートクリエータはIDとグループされなくてはならなく、IM/IAからドキュメントを検索、読み出しする必要がある¾ レポートクリエータは臨床レポートを作成する為に、他にSimple Image
and Numeric Reportプロファイル（SINR）やDRPTにも含まれる

EDを修正するワークステーションはIDとエビデンスクリエータアクタであることを要求すべきである¾ 例えば、初期の計測を修正（アップデート）したものを、IM/IAに送信して

保存する

117

ワークフロープロファイルとの関係
エビデンスクリエータアクタはSWF、CATHワークフロー、
ECHOワークフロープロファイルにも含まれる¾ これらのプロファイルでエビデンス作成の実施はMPPSで通知される¾ 解析された画像で認識されるSPSは作成されたエビデンスドキュ
メントのリファレンスSPSとして使用できるエビデンスクリエータアクタはポストプロセシングワークフ
ロープロファイルにも登場する¾ そのプロファイルの中ではエビデンス作成実施の管理は一般的なワークリスト（GPW）と一般的なPPS（GPPPS）でおこなわれる

118

CATHテンプレートスコープ
3001 Procedure Log¾ Time stamped event log, with codes defined for common events,and free text entries allowed

3202 Ventricular Analysis¾ Quantitative measurements of heart chambers, including wallmotion by any of three types of analysis

3213 Quantitative Arterial Analysis¾ Angiographic arterial measurements and findings organized byvessel3250 Intravascular Ultrasound¾ IVUS arterial measurements and findings organized by vessel

3500 Hemodynamics¾ Pressure and flow measurements organized by procedure phaseand measurement location

119

XDS :Cross-Enterprise Document Sharing
利用されるスタンダード
Healthcare
Content Standards
HL7 CDA, CEN EHRcom
HL7, ASTM CCR
DICOM …

Electronic BusinessStandards
ebXML Registry, SOAP …

Internet Standards
HTML, HTTP,
ISO, PDF, JPEG …

Implemented world-wide by more than 30 vendors/open source. Final
text published August 2005.

Adopted in several national & regional projects (Italy, France, Canada,
Austria, US-NHIN Contractors, RHIOs, etc.). Leverage by US EHR Vendor
Association Interoperability Roadmap.

IHE XDS : 40,000 “Google” references (June’ 06)120

XDS: Cross-Enterprise Document Sharing
ドキュメント記述内容レベルで使用されるスタンダード
データの再利用が容易 (会計、 臨床、 民生分野)• Medical Summaries

XDS Doc Content(HL7 CDA/CRS+V3)• Imaging (DICOM)• ECG Reports, PDFs
• Lab, PHR Extract (CDA)

XDS Infrastructure(Document sources, consumers,
registries, repostories)

121柔軟なインフラストラクチャ: 共有、送信、相互交換
Health Information Exchange or RHIO

XDS
PublishStructured
objects

Pull

Pull

Send to

XDP

SwitchSend toCrossCross-Enterprise Document PointPoint-toto-Point Interchange

Write

Workflow
MgrInterchange
Media

Read

Workflow
MgrTransactions122循環器のXDS/XDP
施設内の循環器に関する情報交換¾ PIR （患者IDの整合処理）¾ セキュアなシステム識別¾ 循環器情報交換の統合プロファイル

RHIOネットワークに参加方法の規定
ACCリージェンシィデータの取得と配布のためのフレー
ムワーク¾ Retrieve Form for Data Entry (RFD)¾ Medical Summaries and Other Content Profiles for Clinical Research, Public Health

Data, etc

123

循環器のXDS/XDP（PCC分野と共同して）循環器サービスのためのコンテンツ統合プロファイル作成のためのユースケースを規定
循環器での要求に対するPCC分野とITIのテクニカルフ
レームワークのレビューとフィードバック
独自の製品の提供するXDSアクターの機能とビジネスパートナーIHE循環器の結合(ACC、ASE等)の循環器現場での相互運用性のショー
ケースの統合部分としてXDS/XDPを含む
PCC: Patient care coordination
ASE: The American Society of Echocardiography124その他の情報は….
IHE 関連 Web サイト：
¾ www.jira-net.or.jp/ihe-j¾ www.ihe.net

Technical Frameworks, Supplements••••

Radiology Technical Framework
Cardiology Technical Framework
Cath and Echo Options for Evidence Documents Supplement
IT Infrastructure Technical Framework and Supplements

Non-Technical Brochures :
•
•
•
•
•

Calls for Participation
IHE Fact Sheet and FAQ
IHE Integration Profiles: Guidelines for Buyers
IHE Connect-a-thon Results
Vendor Products Integration Statements
125

WWW.IHE-J.ORG
126