コネクタソン2023
IHE-ITI ドメイン
日本IHE協会
接続検証委員会
ITI技術委員会
関 昌佳
1

ITIドメイン• ITI: IT-Infrastructureのこと• インフラに相当する部分の情報連携• 業務シナリオ（統合プロファイル）は、全部で26種類• 技術文書（ITI-Technical Framework）が公開されている• 最新版: 2022年7月発行のRev,19.0• Download URL:
• http://ihe.net/Technical_Frameworks/#IT
2

ITI Technical Framework• 4部構成になっている• Rev18よりPDF版からHTML版に変更– Volume 1:– Volume 2:– Volume 3:– Volume 4:

各統合プロファイルの概要
各トランザクションの説明
コンテンツ等の規定
国別拡張3

ITI Technical Frameworkの読み方• 「1. Introduction」に文書の概要説明や読む上で必要な事項等の説明がある– 最初は読み飛ばしても問題ない、わからないところがあったらこちらを参照• 「2. IT Infrastructure Integration Profiles」に業務シナリオ（統合プロファイル）の概要説明がある– 対応したい（できそうな）シナリオがあるか探す•

3章以降に業務シナリオ（統合プロファイル）の説明がある– 対応したい（できそうな）シナリオの内容を確認し、自社システムに対応する
通信（トランザクション）を把握する• 通信（トランザクション）の内容については、Volume 2に詳細が説明されている– 対応すべき通信（トランザクション）について把握する– 必要に応じて、Volume 3も参照する

4統合プロファイル （１）
•
•
•
•
•
•
•
•
•
•
•
•
•

Sharing Value Set Integration Profile (SVS)
Retrieve Information for Display (RID)Enterprise User Authentication (EUA)
Patient Identifier Cross-referencing (PIX)
Patient Synchronized Applications (PSA)
Consistent Time (CT)Patient Demographics Query (PDQ)
Audit Trail and Node Authentication (ATNA)
Cross-Enterprise Document Sharing (XDS.b)
Personnel White Pages (PWP)
Cross Enterprise User Assertion (XUA)
Patient Administration Management (PAM)
Cross-Enterprise Document Reliable Interchange (XDR)
5

統合プロファイル （２）
•
•
•
•
•
•
•
•
•
•
•
•
•

Cross-Enterprise Document Media Interchange (XDM)
Retrieve Form for Data Capture (RFD)
Cross-Community Access (XCA)
Basic Patient Privacy Consents (BPPC)
Scanned Documents Integration Profile (XDS-SD)
Patient Identifier Cross-referencing HL7 V3 (PIXV3)
Patient Demographics Query HL7 V3 (PDQV3)
Multi-Patient Queries (MPQ)
Document Metadata Subscription (DSUB)
Cross-Community Patient Discovery (XCPD)
Cross-Enterprise Document Workflow Content Profile (XDW)
Document Digital Signature (DSG)
XAD-PID Change Management (XPID)6日本のコネクタソン2023で実施を予定している統合プロファイル
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

Consistent Time (CT)
Audit Trail and Node Authentication (ATNA)
Patient Administration Management (PAM)
Patient Demographics Query (PDQ)
Patient Identifier Cross-referencing HL7 V3（PIXV3)
Patient Demographics Query HL7 V3 (PDQV3)
Cross-Enterprise Document Sharing (XDS.b)
Cross-Enterprise Document Sharing for Imaging (XDS-I.b)
Cross-Community Access (XCA)
Cross-Community Access for Imaging (XCA-I)
Cross-Enterprise Document Reliable Interchange (XDR)
Cross-Community Patient Discovery (XCPD)
Cross Enterprise User Assertion (XUA)
Retrieve Form for Data Capture (RFD)
New
Sharing Value Set Integration Profile (SVS)
Patient Demographics Query for Mobile (PDQm)
その他– Patient Location Tracking (PLT)【 Trial Test 】

7

Consistent Time (CT)• システム間で標準時刻を同期させるための仕組みを定義している• 登場する機能（アクタ）– Time Server– Time Client• 通信（トランザクション）– Maintain Time [ITI-1]• 他の業務シナリオ（統合プロファイル）で、このプロファイルの適用を必須としている場合がある• 通信プロトコルはRFC 1305に定義されたNetwork
Time Protocol (NTP)を使用している。
8

Consistent Time (CT)Time Server

Maintain Time [ITI-1]↑

Time Client

9Audit Trail and Node
Authentication (ATNA)•

ATNAはRev13で定義が更新されたので、注意が必要•

ATNAでは、次の２つの仕組みについて定義している––•登場する機能（アクタ）
–
–
–
–

•

•
•

Audit Record Repository
Audit Record Forwarder
Secure Node
Secure Application

通信（トランザクション）––•

ノード認証とノード間におけるセキュアな通信の実現（ATNAのNA部分）
各ノード間通信における監査証跡の収集のための監査メッセージ（ATNAのAT部分）

Authenticate Node [ITI-19]
Record Audit Event [ITI-20]

監査証跡を収集するログサーバー
監査証跡を転送する機能
ATNAに対応したシステム
ATNAに対応したアプリケーション

ノード認証
監査証跡の収集

このプロファイルでは対応しているネットワーク環境をセキュアドメイン（Secure Domain）と呼んでいる。部門、施設の規模から地域連携の規模まで適応可能
監査証跡は、だれがどの端末から何の情報にアクセスしたかを収集するもの
施設のセキュリティ担当者が、システムの動作を監査し、不適切な情報の生成・利用・変更や削除がなかったかの検出を容易にする

10

Audit Trail and Node
Authentication (ATNA)
SecureApplication

Node Authentication [ITI-19]↕

セキュア通信Audit Record
Repository
Audit Record
Forwarder

Secure Node

監査証跡

Record Audit Event [ITI-20]→↓ Record Audit Event [ITI-20]

Audit Record
Repository

監査証跡

11

Audit Trail and Node
Authentication (ATNA)• 監査証跡の記録時刻を統一するため、CTの対応が必須• ATNAは単独での参加が可能なのは、Audit Record
Repositoryだけ• ATNAにおける他のアクタは、別のプロファイルのアクタを実装した上でATNAに対応する必要がある– 例えば・・・• 地域連携（XDS）の機能を実装済みで、更にATNAに対応する• 放射線ドメインのDICOM通信の監査証跡を収集するためにATNAに対応する。
• などなど・・・
12

Audit Trail and Node
Authentication (ATNA)• ATNAのアクタ申し込みの注意事項– 監査証跡とノード認証の両方を実装している場合:• Secure Node
– 監査証跡とノード認証のどちらかを実装している場合:• Secure Application• Audit Record Repositoryについて– 監査証跡メッセージを受け取るだけではNG– 監査証跡メッセージを受け取って管理・閲覧ができることが必要• ATNAに参加する場合は、CTの参加も必須とします（ATNAとCTは依存関係があるため）。
13

Audit Trail and Node
Authentication (ATNA)• Rev13での主な変更点（2016年）– 監査証跡の書式• RFC 3881の使用はIHEとIETF(The Internet Engineering Task
Force)によって廃止された• 今後はDICOMで規定された書式およびコードを使用する必要がある– DICOMスキーマでは、すべてのコード化された型に対してcodeSystemNameおよびoriginalTextが必要です。
– 標準コードが利用可能でなく、監査イベントレポートが依然としてRFC 3881で規定された整数値を使用している場合、IHEアクターはRFC 3881の値をcodeValueに、RFC 3881の説明文をoriginalText属性に、”RFC-3881“をcodeSystemName属性に記載しなければならない。
– 他のコーディングシステムのコードが利用可能な場合は、RFC
3881が推奨されていないため、これらのコードを使用するべきである。

• 詳しくは、ITI-TF Vol2 3.20を参照のこと

14

Patient Administration
Management (PAM)• 患者基本情報等の通知を行うための仕組み• ２つのシナリオ（ユースケース）がある– 患者識別情報の管理– 管理する情報: 患者ID、氏名、生年月日、性別、住所など• 患者移動情報の管理– 管理する情報: 患者の入院・外来区分、診療科、入院の場合は病棟の情報• 上記、２つのシナリオでそれぞれ別の機能（アクタ）が定義されている
15

PAM -患者識別情報の管理
Patient Demographics
Supplier

Patient Identity Management [ITI-30] →Patient Demographics
Consumer• 登場する機能（アクタ）– Patient Demographics Supplier• 患者基本情報の登録を行い、別システムに通知を行う– Patient Demographics Consumer• 患者基本情報の通知を受け取り、自システムで利用する※患者基本情報とは:

患者ID、氏名、生年月日、性別、住所など• 通信（トランザクション）– Patient Identity Management [ITI-30]
16

PAM -患者移動情報の管理
Patient Encounter Management [ITI-31] →Patient Encounter
Supplier

Patient Encounter
Consumer• 登場する機能（アクタ）– Patient Encounter Supplier• 患者の入院・外来情報等の登録を行い、別システムに通知を行う– Patient Encounter Consumer• 患者の入院・外来情報等の通知を受け取り、自システムで利用する※患者の入院・外来情報とは：患者の入院・外来区分、診療科、入院の場合は病棟の情報• 通信（トランザクション）– Patient Encounter Management [ITI-31]
17

Patient Administration
Management (PAM)•

Patient Identity Management [ITI-30]– PDS→PDC• メッセージタイプとしては、A28・A31・A40・A47・A24・A37があるが、今年度のコネクタソンでは、A28・A31・A47のテストを行う予定•– A28 新規患者登録– A31 患者情報更新– A47 患者ID変更（オプション）

Patient Encounter Management [ITI-31]– PES→PEC• 以下のサブセット（オプションセット）がある– Basic Subset（A01・A04・A03・ A11・ A13）
– Inpatient/Outpatient Encounter Management（A05・A06・A07・A02・A38・A12）– Advanced Encounter Management（A54・A21・A22・A55・A52・A53）• 「Basic Subset」は必須• 「 Inpatient/Outpatient Encounter Management 」と「 Advanced Encounter
Management 」はどちらかを選択してください（もちろん両方実施することを歓迎致します）。申し込み時に対応オプションを必ず選択してください。
• 基本的にキャンセル系のトランザクションはオプションとしています。
• 詳しくはGazelleのテストシナリオを参照してください。

18

Patient Identity Management [ITI-30]の注意事項•

PV1セグメントについて– ITI-30トランザクションの全てのメッセージでこのセグメント（PV1セグメント）は使用されるが、実際には仮のPV1として使用され、（内容は）空となる。（使用される）唯一のフィー
ルドPV1-2 Patient Classには、「N (Not Applicable)」の値がセットされる。
「ITI-TF 2b 3.30.5.4 PV1 - Patient Visit segment Page 26, Line 695」より– ITI30トランザクションでは、PV1セグメントが含まれる全てのメッセージで（PV1-2の）値は「N (Not Applicable)」だけが使用される。
「ITI-TF 2b 3.30.5.4 PV1 - Patient Visit segment Page 27, Line 711」より↓

ITI-30トランザクションでは、PV1-2のみ「N」をセット、それ以外のPV1セグメントのフィールドは空とする。
19

Patient Administration
Management (PAM)• 注意事項– 移動情報の管理を行わないシステムで、PESやPECに参加されている場合が見受けられます。移動情報の管理が行えない場合は、不合格となりますので、注意してください。
– 詳細はVWS2で説明致します。
– 順次変更しています・・・• TFでは多数のトリガーイベントが定義されています。
原則として全てのトリガーイベントに対応している必
要があります。テストシナリオを段階的に増やしている最中です。今年度のテストに含まれていないメッ
セージタイプについても対応準備をお願い致します。

20

Patient Identifier Crossreferencing HL7 V3（PIXV3）• 登場する機能（アクタ）– Patient Identity Source• 患者基本情報の登録を行う– Patient Identity Consumer• 患者基本情報の相互参照を行うシステム– Patient Identifier Cross-reference Manager• 患者基本情報を保持するシステム※患者基本情報とは: 患者ID、氏名、生年月日、性別、住所など• 通信（トランザクション）– Patient Identity Feed HL7 V3 [ITI-44]– PIXV3 Query [ITI-45]– PIXV3 Update Notification [ITI-46]（オプション）

21

Patient Identifier Crossreferencing HL7V3（PIXV3）
Patient Identifier
Cross-reference
Consumer

Patient Identity Source

Patient Identity Feed
HL7 V3[ITI-44]↓
PIXV3 Query [ITI-45]↓

Patient Identifier
Cross-reference Manager
PIXV3 Update Notification [ITI-46]↑

22

PIXV3のテスト範囲• 次のトランザクションは必須– Patient Identity Feed

HL7 V3[ITI-44]– PIXV3 Query[ITI-45]• 次のトランザクションはオプション– PIXV3 Update Notification[ITI-46]

23

Patient Demographics Query（PDQ）• ユーザ定義の検索条件に基づき、患者基本情報を保持したサーバに患者のリストの問い合わせを行い、患者基本情報を取得するための方法を提供する• 登場する機能（アクタ）– Patient Demographics Supplier• 患者基本情報を保持したサーバー– Patient Demographics Consumer• 患者基本情報の検索を行うシステム（利用者）※患者基本情報とは: 患者ID、氏名、生年月日、性別、住所など• 通信（トランザクション）– Patient Demographic Query [ITI-21]– Patient Demographics and Visit Query [ITI-22]• 施設内での患者基本情報の問い合わせに限定します。
• 施設間連携での患者基本情報の問い合わせはPDQV3で!
24

Patient Demographics Query（PDQ）
Patient
Demographics
Supplier

Patient Demographic Query[ITI-21]↑↑

Patient Demographic
and Visit Query[ITI-22]

Patient
Demographics
Consumer25

PDQのテスト範囲• PDQ[ITI-21]は必須です• PDVQ[ITI-22]はオプションです• 注意事項• 以下の検索パラメータでのテストを必須とします– PID.3.1（患者ID）– PID.5.1（患者カナ姓）~PID.5.2（患者カナ名）• 以下の検索パラメータでの検索はオプションです。
– PID.7 （患者生年月日）（複数レコードの応答を許可）– PID.8 （患者性別）（複数レコードの応答を許可）

26

Patient Demographics Query
HL7V3（PDQV3）••

HL7のバージョン３である以外はPDQのシナリオとアクタは同じである
検索条件に基づき、患者基本情報を保持したサーバに患者のリストの問い合わせを行い、患者基本情報を取得するための方法を提供する•

登場する機能（アクタ）– Patient Demographics Supplier• 患者基本情報を保持したサーバー– Patient Demographics Consumer• 患者基本情報の検索を行うシステム（利用者）※患者基本情報とは:•通信（トランザクション）

患者ID、氏名、生年月日、性別、住所など– Patient Demographic Query V3•[ITI-47]

施設間連携での患者基本情報の問い合わせに限定します!

27

PDQV3のテスト範囲• PDQV3[ITI-47]は必須です• 検索パラメータは、以下のもの単独および複合での検索が行える必要があります– 患者ID
– 患者姓
– 患者名
– 性別
– 生年月日– 住所28

Cross-Enterprise Document
Sharing (XDS.b)• 地域連携のコミュニティ（ XDSアフィニティドメイン）に属する多数の医療機関等が、文書形式の臨床記録を共有することによって、協力して患者の診療等にあたることを可能にする方法を提供する• 医療施設はひとつ以上のコミュニティ（ XDSアフィニティドメイン）に属することを前提にしている• XDSアフィニティドメインとは、共通の基本方針（ポリシー）と共通の基盤上で、協働することを合意した医療機関の集まりである• XDSで言うドキュメントとは、文字情報に限定されない• XDSは情報の内容や表示に関わりなく、いかなる種類の臨床情報も使用可能とする。これにより、単純テキスト、書式化
テキスト（例:HL7 CDA R1）、画像（例:DICOM）、構造
化され語彙がコード化された臨床情報（例:CDA R2、
DICOM SRなど）を等しく扱うことができる。
29

Cross-Enterprise Document
Sharing (XDS.b)
Patient ID Source

Patient Identity
Feed [ITI-8]

Patient Identity Feed
HL7 v3 [ITI-44]
Document
Registry

RegistryStored Query[ITI-18]

Document
Consumer

Register Document Set-b[ITI-42]

Document
SourceProvide &Register Document
Set-b[ITI-41]

Document
Repository

Retrieve Document Set [ITI-43]

30

Cross-Enterprise Document
Sharing (XDS.b)• テストについて–

テスト項目、テストシナリオの詳細は２回目のVWSで説明– 基本は「登録」「検索」「取得」を行う

文書の登録

ドキュメントソース

ドキュメント
リポジトリ

メタデータ検索ドキュメントコンシューマドキュメント
レジストリ

文書の取得

ドキュメントコンシューマドキュメントリポジトリ

ドキュメント
レジストリ

トランザクション単位のテストではないことに注意
31

Cross-Enterprise Document
Sharing for Imaging (XDS-I.b)• 医療施設間で患者の画像情報のドキュメント（XDS画像文書）を共有する仕組みを提供する。
• IHE Radiology Technical Framework（IHE
Rad TF）で定義。
– XDS.bはIHE ITI TFで定義– XDS-I.bは現在IHE Rad TFで定義• 日本では、XDS.bとXDS-I.bはITIドメインで行います。
32

Cross-Enterprise Document
Sharing for Imaging (XDS-I.b)
Registry Stored
Query [ITI-18]

Document
Registry
Register Document
Set – b [ITI-42]
Provide & Register
Imaging Document Set– MTOM/XOP[RAD-68]

Image
Document
Source色のアクタはXDS.bで定義

Document
Repository

Document
Consumer
Image
Document
Consumer

Retrieve Document
Set [ITI-43]

WADO Retrieve [RAD-55]
Retrieve Imaging Document Set [RAD-69]
Retrieve Images [RAD-16]
Retrieve Presentation States [RAD-17]
Retrieve Reports [RAD-27]
Retrieve Key Image Note [RAD-31]
Retrieve Evidence Documents [RAD-45]

33

Cross-Community
Access(XCA）• コミュニティ間での情報連携を行う仕組
みを提供する。
• 対象文書はXDS.bと同様。
• コミュニティ内の仕組みはこのプロファ
イルでは関知しない– XDS.bを実装したシステムが動作（XDSアフィニティドメインオプション）– 独自に実装したシステムが動作
34

Cross-Community
Access(XCA）
Initiating Community

Responding Community

Registry Stored Query [ITI-18] ↓Document
Consumer
Retrieve Document Set [ITI-43] ↓Cross Gateway Query [ITI-38]→

Initiating
Gateway

Responding
Gateway
Cross Gateway Retrieve [ITI-39] →35

XCAのテスト範囲• Initiating GWとResponding GWのトランザク
ションの確認を行います。

• XCAでは、ベンダ＝Communityとしてテストを行います。

• XCAとXDS.bの両方に参加を予定されている
場合は、以下の準備をお願いします。

– XDS.bテスト用システムとXCAテスト用システムは違うホストで動作させてください（任意）• 理由:これらのプロファイルのテストはかなり複雑です。システム設定の切り替え等を行っていると、期間内にテストが完了しない恐れがあります。

36

Cross-Community Access for
Imaging (XCA-I)• コミュニティ間での画像情報連携を行う
仕組みを提供する。
• 連携対象はXDS-I.bと同様。
• コミュニティ内の仕組みはXDS-I.bに対応
してある前提（XCAと違う）

37

Cross-Community Access for
Imaging (XCA-I)
Initiating Community
Document
Repository

Responding Community←Registry Stored Query [ITI-18]

Document
Registry

Retrieve Document Set [ITI-43] ↑Document
Consumer[ITI-18] →[ITI-43] →ImagingDocument
Consumer
Retrieve Imaging
Document Set [RAD-69] →Document
Repository

Cross Gateway Query [ITI-38]→

Initiating
Gateway

Document
Registry

Retrieve Document Set [ITI-43] ↑Responding
Gateway→Registry Stored Query [ITI-18]

Cross Gateway Retrieve [ITI-39] →Imaging
Initiating
Gateway

ImaingResponding
Gateway
Cross Gateway Retrieve →Imaging Document Set [RAD-75]

Retrieve Imaging
Document Set [RAD-69] →ImagingDocument
Source38

XCA-Iのテスト範囲• 画像を取得する部分のみがテスト範囲• 検索・マニフェストの取得については
XCA（XDSアフィニティドメインオプション）で合格しておく必要がある• コミュニティ内でのイメージ取得トラン
ザクションは、Retrieve Imaging
Document Set [RAD-69]のみ対象なので注意が必要。WADOは使用できない
39

Cross-Enterprise Document
Reliable Interchange (XDR)• 地域連携の仕組み• XDS.bが共有なのに対して、XDRは1対1の通信• トランザクション自体はXDS.bで定義されているものを使用している
Document Source

Provide and Register Document Set-b [ITI-41]→

Document
Recipient40

Cross-Community Patient
Discovery (XCPD)• 患者属性情報等を使用して当該患者の診療情報を保持しているコミュニティの探索を行い、探索先のコミュニティの患者
識別情報の取得を行う機能と仕組みを提供する。
• XCAでコミュニティ間のデータ連携をおこなっている場合、XCAと組み合わせて実施することを想定している。
41

Cross-Community Patient
Discovery (XCPD)
Initiating Community

Responding Community

Other Actor

Other Actor

Initiating
Gateway

Cross Gateway Patient
Discovery [ITI-55]→

Responding
Gateway42

XCPDのテスト範囲• 患者の情報を保持するコミュニティを探索して患者識別情報を取得する部分がテスト範囲– 患者の診療情報の検索・取得はXCPDの範囲外•

XCPDには以下の３つのモードがある– Demographic Query only mode
– Demographic Query and Feed
– Shared/national Patient Identifier Query and Feed•

Init. GWは、自コミュニティ内の他アクタからの要求を受け取り他
コミュニティへ要求メッセージが転送できること• Resp.GWは、他コミュニティからの要求を受け取り自コミュニティの患者情報を保持しているアクタに要求を転送できること• 対応している各モードで適切な処理・データの保持等が行えること

43

Cross Enterprise User Assertion(XUA)• 施設間でのユーザー、アプリケーションおよびシステムなどに関する認証要求を伝達する手段を提供する。
• Webサービスセキュリティ、SAML 2.0トー
クンプロファイル、W3CおよびOASISのさ
まざまなプロファイルを利用してIDの統合をサポートしている。
• 大半のユースケースでは、SAML 2.0 IDア
サーションで提供できる認証済みID（SAML2.0）要求が活用される。
44

Cross Enterprise User Assertion
(XUA)
User
Authentication
ProviderX-Assertion
ProviderAuthenticate User↑ Get X-User Assertion↑

X-Service User
Other Actor↑Other Assertion Transactions

Provide X-User
Assertion [ITI-40]→

Web-Service based Transactions →X-Service
ProviderOther Actor

45

Retrieve Form for Data Capture(RFD)• 外部システムからの要求のために、自施設内にあるシステム内で収集したデータの提出方法を提供する。
• 書式提供元からのフォームの取得、フォームの表示と入力、およびインスタ
ンスデータの返却をサポートしている。
さらに、RFDは以前に入力したデータを修正するためのメカニズムも提供する。
46

Retrieve Form for Data Capture(RFD)
Form Manager

Form ReceiverForm Processor↑Retrieve Form
↑Retrieve[ITI-34]
Clarifications[ITI-37]

Form Filler↑Submit Form
[ITI-35]→Archive Form [ITI-36]

Form Archiver47

Sharing Value Set (SVS)• 画像診断機器、レポートシステム、電子カルテシステムなどの臨床または管理データを生成または利用するヘルスケアシ
ステムが、中央で管理された共通の統一コードマスタを受け取る手段を提供する 。 ある特定の用途のために派生された
コードセットを統一して管理し各システムで共有することは、相互運用性を実現するために不可欠である。
• このプロファイルでは、Value Set ConsumerがValue Set
Repositoryからバリューセットを取得するためのトランザク
ションについて定義している。 単一のValue Set Repository
は、複数のValue Set Consumerからアクセスされ、一貫して統一されたコードマスタドメインを確立する。 Value Set
Consumerを実装するシステムによるコードマスタの自動更新をサポートし、手動設定の負担を軽減することができる。

48

Sharing Value Set (SVS)
SVSの範囲検索

バリューセット
レジストリ

バリューセット
バリューセット
バリューセット
利用システム利用システム利用システム登録取得

バリューセット
リポジトリ

登録
ターミノロジー
レジストリ

検索

検索

バリューセット
生成システム登録
ターミノロジー
リポジトリ
登録
ターミノロジー
生成者
例：SNOMED, LOINC,
HL7, etc.

ターミノロジー
発行システムターミノロジー
レジストリ
登録

取得

取得

ターミノロジー
リポジトリ
登録
ターミノロジー
発行システムターミノロジー
生成者
例：SNOMED, LOINC,
HL7, etc.

49

Sharing Value Set (SVS)
Value Set
Repository

アクタ
Value Set Repository
Value Set Consumer←Retrieve Value Set [ITI-48]←Retrieve Multiple Value Set [ITI-60]

トランザクション

Value Set
Concumer

オプション

Retrieve Value Set [ITI-48]

R

Retrieve Multiple Value Sets [ITI-60]

R

Retrieve Value Set [ITI-48]

R

Retrieve Multiple Value Sets [ITI-60]

O50

Sharing Value Set (SVS)• 日本IHE協会でValue Set Repositoryを配備します– Concumerの参加を募集します– もちろんRepositoryでの参加も募集します• 今年はSOAP通信はテスト対象外とし、HTTP＋XMLでの通信でのテストとします51

Patient Demographics Query for
Mobile (PDQm)• PDQのFHIR版• 規約としては、Trial Implementation版ですが、今年から募集する予定です• 日本IHE協会でサーバー（Supplier）を用意する予定– クライアント（Consumer）の応募があれば実施します– もちろんサーバー（Supplier）の応募も期待
しています

52

Patient Demographics Query for
Mobile (PDQm)
Patient
Demographics
Supplier

Mobile Patient
Demographic Query[ITI-78]↑

Patient
Demographics
Consumer

53

Patient Demographics Query for
Mobile (PDQm)• 今年のコネクタソンでは、HTTP＋JSON
でのテストを実施予定です– HTTP＋XMLはテストを行いません• 詳細については、「PDQｍ Rev2.2 Trial
Implementation」を参照してください
https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PDQm.pdf• テスト内容についてはVWS2で詳しく説明
いたします
54

Patient Location Tracking (PLT)• 患者の現在の位置を管理し、検索を行う機能を提供します。
• このプロファイルは日本から提案を行ったもの– 現在のステータスはTrial Implementation– 今年度も、トライアルテストを実施します。
• プロファイルに記載されている内容が実装する上で問題ないかを確認するためのテスト• ベンダーの皆様のご協力をお願いします55

Patient Location Tracking (PLT)
Patient Demographics
Supplier

Patient Identity
Management[ITI-30]
Patient Demographics

Patient Location Tracking Feed [ITI-76]

Patient Location
Tracking Supplier

Consumer

Patient Location
Tracking Manager

Patient Location Tracking Query [ITI-77]

Patient Location
Tracking Consumer

56

最後に
• 今回説明したプロファイル以外のものも希望があれば実施を検討しますので、応募時に希望をお寄せください• 審査基準の詳細については、VWS２で解説を行います• 日本IHE協会のホームページに技術文書の和訳資料が公開されています––

原典はあくまでも、英文の文書です
和訳版は参照資料として活用してください57

ご清聴ありがとうございました。
ご質問があれば承ります。

58