1

IHE-J 2013 コネクタソンITI(XDS関連)

テスト項目およびシナリオ

2013年7月24日

IHE-J 2013 コネクタソン参加ベンダ・ワークショップ

2013/7/26 2

現在の版：Revision 9

(2012年8月31日公開)

Volume1,2a,2b,2x,3

TFのほかにも

Supplements for Trial Implementation

User Handbook

White Paper

などがある。

ITインフラ （ITI-TF）テクニカルフレームワーク

Volume 1（ITI-TF-1）: 統合とコンテンツのプロファイル臨床ニーズとユースケースの記述の明確化：

アクターとトランザクション、あるいはコンテンツ・モジュール

Volume 2a, 2b, 2x（ITI-TF-2a,2b,2x）：トランザクションまたはコンテンツモジュールの実装仕様を提供

Volume 3（ITI-TF-3）：XDSメタデータ及びコンテンツに関する仕様

3

• 調査研究: テクニカルフレームワーク

– http://www.ihe.net/Technical_Framework/index.cfm

• ITIを含むすべての部門のテクニカルフレームワークが取得できる

– ePHDS委員会/日本PACS研究会、日本IHE協会編

「地域医療連携情報システム構築ハンドブック2011」

• 実践段階: コネクタソン接続テスト

– www.ihe.net and www.connectathon.net

• 流通段階:

– ヘルスケア IT ベンダのインフラストラクチャ専門家

– 他のITベンダとの協業

2013/7/26

IHE IT インフラストラクチャ情報の入手

IHE Web Site - http://www.ihe.netTechnical FrameworksTechnical Framework Supplements – Trial ImplementationCalls for ParticipationIHE Fact Sheet and FAQIHE Integration Profiles: Guidelines for BuyersIHE Connectathon ResultsVendors’ Product Integration Statements

IHEWiki.wustl.edu: Support of IHE Connectathons

http://ihewiki.wustl.edu/wiki/index.php/Main_Page

Sponsors’ IHE siteshttp://www.himss.org/IHE http://www.rsna.org/IHEhttp://www.acc.org/quality/ihe.htm

42013/7/26

IHE IT インフラストラクチャ(1)

Profiles –医療情報

Document Sharing（ドキュメント共有） XDS.b – Cross-Enterprise Document Sharing

XDS-I.b – Cross-Enterprise Document Sharing for Imaging

XDS-SD – XDS Scanned Documents

XDP – Cross-Enterprise Document Interchange

NAV – Notification of Document Availability

RID – Retrieve Information for Display

XDM－Cross-Enterprise Document Media Interchange

XDR－Cross-Enterprise Document Reliable Interchange

DRR－Document-based Refferal Request

XCA－Cross-Enterprise Community Access

XCA-I－Cross-Enterprise Community Access for Imaging

52013/7/26

IHE IT インフラストラクチャ(2)

Patient Management（患者情報管理） PAM – Patient Administration Management

PDQ – Patient Demographics Query

PIX – Patient Identifier Cross-referencing

PSA – Patient Synchronized Applications

XCPD－Cross-Community Patient Discovery

RFD – Retrieve Form for Data Capture

Profiles –セキュリティ ATNA – Audit Trial and Node Authentication

CT – Consistent Time

DSG – Document Digital Signature

EUA – Enterprise User Authentication

XUAーCross-Enterprise User Authentication

PWP – Personnel White Pages

BPPC－Basic Patient Privacy Consents

DSUBーDocument Metadata Subscription

62013/7/26

Document

Consumer

Retrieve

Document Set

Registry

Stored Query

Patient

Identity Source

Patient Identity

Feed

Document

Source

Document

Registry

Document

Repository

Provide&Register

Document Set - b

Register

Document Set - b

Patient Identity

Feed HL7v3

ドキュメントソース

文書（ファイル）ならびに文書のインデックス情報（メタデータ）を登録する

患者IDソース

(患者IDを提供する)

ドキュメントリポジトリ

(文書本体を保存する)

ドキュメントレジストリ

(メタデータを保存する)

ドキュメントコンシューマ

(文書を検索、参照する)

[ ITI-41 ]

[ ITI-42 ]

[ ITI-43 ]

[ ITI-18 ]

[ ITI-8 ][ ITI-44 ]

IHE : XDS.b(Cross-Enterprise Document Sharing-b )

①文書の登録

②メタデータの検索

③文書の取得

7

XDS.ｂの技術的な特徴

2013/7/26

XDS.bはいくつかの標準規格を参照している

• メタデータ： ebXML ver3.0 にもとづく

• トランザクション間のWebサービス： SOAP1.2

• 特に[ITI-41][ITI-43]ではMTOM/XOP を用いたSOAPバインディングを利用する。

• 「患者IDの供給」では HL7に基づくトランザクションを提供

• IHEはXDS.b用のWSDL定義を提供

SOAP：Simple Object Access Protocol

MTOM：Message Transmission Optimization Mechanism

XOP: XML-binary Optimized Packaging

WSDL: Web Services Description Language

82013/7/26

ドキュメントソース

ドキュメントリポジトリ

ドキュメントレジストリ

・登録文書選定

・文書のメタデータ作成

文書ファイル＋メタデータ

・文書の保存

・文書ファイルの情報（リポジトリのID、ハッシュ値、サイズ）をメタデータに付与

メタデータ

・メタデータのチェック・メタデータの登録

ITI-41 ITI-42

①文書の登録

9

XDS.ｂで扱うメタデータ（１）

2013/7/26

DocumentEntry

Folder

SubmissionSet

登録するドキュメントの特徴を説明する。１文書ファイルにつきDocumentEntry

１つ用意する。

複数のドキュメントを目的に応じてまとめる。

ドキュメントを登録する際の、ドキュメントエントリ、フォルダなどメタデータの集合を表す。1回の登録につき１つ必要。

各メタデータの項目は ITI-TF-3の 4章を参照のこと

10

XDS.ｂで扱うメタデータ（２）

2013/7/26

XDSはebXMLの技術をベースとする

メタデータはebXML RIM ver.3.0 の流儀で書く

DocumentEntry

Folder

SubmissionSet

ExtrinsicObject

RegistryPackage

RegistryPackage

Classification

“Folder”

Classification

“SubmissionSet”

XDSオブジェクト ebXMLオブジェクト

ebXML： Electronic Business using

eXtensible Markup Language

RIM： Registry Information Model

RS：Registry Service （and Protocols）

11

XDS.ｂで扱うメタデータ（３）

2013/7/26

各オブジェクト間の関係は「Association」オブジェクトを利用する。

（Association：ebXML RIMで定義）

SubmissionSet

（RegistryPackage）

Folder

（RegistryPackage）

DocumentEntry

（ExtrinsicObject）

Association

type=“HasMember”

Association

type=“HasMember”

Association

type=“HasMember”

【例】

2013/7/26 2011（C）管理工学研究所 12

フォルダ

- 利用可能状態（availability Status): code- フォルダ識別番号(uniqueId): OID- 地域患者ID(patientId): CX- 最終更新日時（lastUpdateTime): DTM- コードリスト（codeList): typeCode- タイトル(tilte): char- 備考（comment): char

サブミッションセット

- 利用可能状態(availabilitya Status): code- サブミッションセットID(uniqueId): OID- 地域患者ID(patientId): CX- 施設患者ID(sourceId): OID- 作成元施設名称(authorInstitution): char- 提出日時(submissionTime): DTM- 作成者（authorPerson): XCN- 作成者職種(atuhorRole): code- 作成者診療科（atuhorSpeciality): code- タイトル(title): char- 備考(comment): char- 含む文書タイプ（contentTypeCode): typeCode

ドキュメントエントリ

- 利用可能状態(availability Status): code- 文書ID(uniqueId): OID- 地域患者ID(patientId): CX- 文書クラス(classCode): code- イベントコード(eventCodeList): code- entryUUID(Id): UUID- 守秘レベル(confidentiality Code): code- 文書タイプ詳細（typeCode): code- 作成日時(creationTime): DTM- 診療開始日(serviceStartTime): DTM- 転帰日（serviceStopTime): DTM- バイト長(size): int- 施設患者ID(sourcePatientId): OID- 作成元施設名称(authorInstitution): char- 施設患者情報(sourcePatientInfo): PID- 作成者職種(authorole): code- 作成者診療科(authorSpeciality): code- 作成者(author): XCN- 施設タイプ(healthcareFacilityTYpeCode): code- 診療科(practiceSettingCode): code- 作成元責任者(legalAuthenticator): XCN- 言語コード(languageCode): code- ハッシュ値(hash): int- フォーマットコード(formatCode): code- 親文書ID(parentDocumentId): UUID- MIMEタイプ(mimeType): code- 親文書関係タイプ(parentDocumentRelationship): code- タイトル(title): char- URI: uri

XDS.bで扱うメタデータ（４）

注）XDS.bで、DocumentEntryのmetadataに「repositoryUniqueId」が追加された。

13

②メタデータの検索

2013/7/26

ドキュメントコンシューマ

ITI-18 ドキュメントレジストリ

文書のメタデータ検索要求

文書のメタデータ検索要求作成

検索要求に基づく検索処理実行

検索結果

検索結果の表示

14

メタデータの検索：StoredQuery

2013/7/26

SQL文は「型」としてレジストリ側で保持

例）SELECT fol.id FROM RegistryPackage fol

WHERE fol.id IN $XDSFolderEntryUUID

コンシューマ側はSQL文に埋め込むパラメータをレジストリへ送る

レジストリはコンシューマからのパラメータ値を「型」に入れてSQL文による検索を実行する。

コンシューマに余計な検索をさせないというのが狙い。

パラメータ

15

メタデータの検索：StoredQuery

2013/7/26

ITI TF-2aで定義されているStoredQueryの種類

・FindDocuments

・FindFolders

・FindSubmissionSets

・GetAll

・GetDocument

・GetSubmissionSetAndContents

・GetFolderAndContents

・GetFoldersForDocument

・GetRelatedDocuments

・GetFolders

・GetAssociations

・GetDocumentsAndAssociations

・GetSubmissionSets

16

③文書の取得

2013/7/26

ドキュメントコンシューマ

ITI-43 ドキュメントリポジトリ

・文書取得要求を作成

（文書所在情報はDocumentEntryに含まれる）

文書取得要求

コンシューマが所望した文書

・文書取得要求で、コンシューマが所望した文書を用意し、コンシューマへ送信

文書の表示

172013/7/26

IHE : XDS-I.b (Cross-Enterprise Document Sharing for Imaging )

Image

Document

Source

Image

Document

Consumer

Document

Registry

Document

Repository

Document

Consumer

Provide & Register

Imaging Document Set

– MTOM/XOP

[RAD-68]

Register Document

Set – b [ITI-42]

Retrieve Document

Set [ITI-43]

Registry Stored

Query [ITI-18]

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]

色のアクタはIHE ITI TFで定義

画像ドキュメントソース

画像ドキュメントコンシューマ

IHE Radiology Technical Framework （IHE Rad

TF）で定義

XDS-I.bは、現在Supplementで提供

XDS-I.bの登場で、旧バージョン（XDS-I）は廃止

医療施設間で患者の画像情報のドキュメント（XDS画像文書）を共有する仕組みを提供する。

XDS.bで、取り扱うコンテンツを画像としたもの

2013/7/26 2011（C）管理工学研究所18

出典http://www.myesr.org/html/img/pool/ECR_2010_ICT_Booth_A1Poster2_12.pdfXDS-I.bの利用ステップ

①

②KOS及びXDS

submission Set作成

③KOS及びReportのXDS submission登録

⑤

④

⑥KOS及びReportのXDS submission登録

⑦

⑧ XDS Query⑨ XDS Retrieve

KOS 及びReport

⑩⑩

⑪ WADO Retrieve⑪ WADO Retrieve

⑨ XDS Retrieve

KOS 及びReport

19

XDS関連のテスト項目

20

オプション 意味

R テスト対象とする。

O 相互にサポートされていれば実施する。

RO 相互にサポートされていれば実施する

XDS.b テスト項目及び実施必要性

テスト項目

テスト説明 XDS.bアクタ

技術文書（節番号）

資料 Doc.Src Doc. Rep Doc.Re

g

Doc.Con

XDS.b_Cons_homeCommunityID ー R

XDS.b_Registry_Folder_Handling ー R

XDS.b_Consumer_QR_Async 1.1 RO RO RO

XDS.b_Consumer_QR_with_Proxy 1.2 R R R

XDS.b_Consumer_Query_Retrieve 1.3 ○ R R R

XDS.b_Doc_Source_Stores_Async 1.5 RO RO RO

XDS.b_Doc_Source_Stores_Document 1.4 ○ R R R

XDS.b_Doc_Source_Stores_with_Proxy 1.6 R R R

XDS.b_Error_Reporting 1.7 ○ O R R

XDS.b_Folder_Management ー RO R

XDS.b_Repository_Registry_Lifecycle ー RO R

21

Integration Profile Actor Profile Option Option Meta Test

XDS.b DOC_CONSUMER NONE R

XDS.b DOC_REGISTRY NONE R

XDS.b DOC_REPOSITORY NONE R

Step Trans. Msg Type Return From Actor To Actor Step Description Opt.

10 NULL -- --1つ以上の患者を見つけるため、選択されたレジストリ及びリポジトリに登録されたドキュメントを持Connectathon -> Connectathon ObjectsのもとでGazelleを調べる。

R

20 ITI-19 -- -- 認証ノード：TLS通信の開始 R

30 ITI-18 DOC_CONSUMER DOC_REGISTRYドキュメントコンシューマは、一人の患者に対して、ドキュメントリストを得るために、ドキュメントレジストリに対してストアードクエリを送信する。

R

40 ITI-43 DOC_CONSUMER DOC_REPOSITORY ドキュメントコンシューマは、ドキュメントリポジトリからドキュメントを取り出す。 R

80 NULL -- --

自分のログファイルを開き、トランザクションがTLS通信を使って実施されたことのエビデンスを示すログ情報を検索する。XDS_Consumer_Query_Retrieve_NNNと呼ぶテキストファイル（又は他のドキュメント）を生成する、ここで、NNNは、Gazelleテスト番号である。このファイルをコネクタソン審査員に渡すまで保持する。

R

1.3 XDS.b Consumer Query Retrieve

指示このテストを行う前に、Doc Registryおよび Repositoryは、テストXDS.b_*_Do_This_Firstをパスしなければならない。TLS通信を利用してこのテストを実施すること。Doc Sourcesによって登録されたドキュメントを見つけるために、ドキュメントコンシューマ は、Connectathon Images/CDs/Objects pageを使うべきである。Objects Information.上のObjects to Render'タブを参照。このテストのATNA監査ログを受け取る監査レコードリポジトリ（ARR）の名前を記録すること。説明XDS_Consumer_Query_Retrieve テストは、XDS ドキュメントコンシューマの観点から、XDSプロファイルを試行する。ドキュメントリストを得るため、XDSレジストリに患者IDで特定のクエリを出す。XDS コンシューマは、ドキュメントを取り出し、コネクタソン審査員にそれらを表示する。

テストされるドキュメントコンシューマは、ドキュメントレジストリの少なくとも１つのクエリを発行することを要求する。そのクエリの形式は、規定されていない。テクニカルフレームワークは、多くのオプションを定義している。評価のためには、コネクタソンの審査員は、クエリ、およびドキュメントコンシューマアクタでの取り出しのプロセスを観察すべきである。評価ドキュメントコンシューマ上で、コネクタソンの審査員は、リアルタイムでクエリおよび取り出し、および。両方のトランザクションがTLS通信を用いて実施されたことのログやまたは他のエビデンスを観察することになる。このテストに関連する統合プロファイル／アクタ：

テストシナリオ:

22

1.4 XDS.b Document Source Stores Document

指示Doc Source, Registry, およびRepositoryは、このテストを行う前に、XDS.b_*_Do_This_Firstのテストをパスしていなければならい。注１：独自のドキュメントを生成しないドキュメントソースシステム（ミドルウェアとして動作する）は、すべてのXDSテストで定義された特定の患者に対するドキュメントを生成するように準備してコネクタソンに望まなければならない。ドキュメントソースシステムは、テスト指示によって定義された患者を利用して、オンデマンドで、ドキュメントを生成することが要求される。このテストのATNA監査ログを受け取る監査レコードリポジトリ（ARR）の名前を記録すること。これは、つぎの３つのシステムの手当てが必要であり、難しいテストである：Document Source ,Document Repository ,Document Registry ,Document Sourceから始めたリンク又はDocument Registryで終わるリンクをはじめに試すかの指針は与えない。結局は、エンドからエンドの操作を試さなければならない。このテストの終了時には、格納されたドキュメントについての情報を格納するためGazelleの共通の場所を更新してほしい。このテストは、Document Sourceが、審査員がレジストリおよびリポジトリの中のソースドキュメントをより容易に発見できるような患者名を使用することを要求する。説明XDS_Doc_Source_Stores_Documentのテストは、ITIトランザクション４１及び４２のテストである。Document Sourceは、少なくとも、１つのドキュメントを供給し、Document Repositoryへそのドキュメントを提出する。このテストは、1つのサブミッションセットおよび１つのドキュメントをカバーする。Document Sourceへのオプションは、異なるテストでカバーされる。ITI-41は、ITI-42:

Register Document Setに強く結びついている。Document Sourceが、オリジナルのドキュメントを提出したとき、Document Repositoryは、次に、Document Registryにそのドキュメントを登録する。このテストは、TLS通信を用いてテストを実施すべきである。このことは、コネクタソンの開始時に、TLSの作業を行っておく必要があることを意味する。このテストに対しては、ATNAのログをとることは要求されないが、TLS通信を使う必要がある。このテストを完了したとき、Doc Consumersが、Connectathon Images/CDs/Objectsの下のドキュメントを見つけられるようにGazelleツールの参照情報を記録しなければならない。このページへのリンクは、Objects Information.である。提出には、いくつかの値の入力を促される。コネクタソンの審査員は、Submission Set uniqueIDで参照されるドキュメントを見つけることができない場合には、テストは失敗とみなさる。コネクタソンの審査員は、このレジストリまたは他のレジストリの中にSubmission Set uniqueIDの複数インスタンスを発見した場合には、そのテストは、失敗とみなさる。このコネクタソンの間、すべてのサブミッションに対するユニークなSubmission Set uniqueIDを生成する必要がある。審査員は、このテストを走らせたエビデンス／ログを求める。または、立会いのもと再度テストを実行することを求めることができる。このテストを終了したとき、このテストのこのインスタンスのGazelleのチャットウインドウの中にログ情報／エビデンスを記録すべきである。これにより、審査員にあなたのログデータを素早く見せることができるようになる。評価評価は、2つのフェーズで行われる。最初のフェーズは、一人のコネクタソン審査員が、システムに訪れ、ログファイルを調べてトランザクションがTLSを用いて実行されていることのエビデンスをチエックする。コネクタソン審査員は、テストを再実行することを求めることができる。ログの要求内容は、以下のとおり(ITI TF-2:3.41.7 &

3.42.7)。ITI-42 (Provide & Register)に対しては、（他のフィールドの）ドキュメントメタデータから患者IDおよび submissionSet uniqueIDを含む"Export" eventのログを取。ITI-42 (Provide & Register)に対しては、（他のフィールドの）ドキュメントメタデータから患者IDおよび submissionSet uniqueIDを含む"Import" eventのログを取る。ITI-41 (Register Doc)に対しては、（他のフィールドの）ドキュメントメタデータから患者IDおよび submissionSet uniqueIDを含む"Export" eventのログを取る。ITI-41 (Register Doc)に対しては、（他のフィールドの）ドキュメントメタデータから患者IDを含む"Import" eventのログを取る。セキュリティ要件が確認された後は、審査員は、状態を部分的に確認済みに設定する。評価の2つ目のパートは、Submission Set IDが見つかるかどうか、その値が複数の値であるかどうかを決定するためにRegistryに対して再びクエリ実行することである。これは、登録されたドキュメントの検索によって確かめられる。URIは、TLS (https://)を示していなければならない。最後に、Document Sourceシステムで生成されたドキュメントは、がIHEコンテンツプロファイルの一つに準拠していないならば、コネクタソン審査員は、このシステムで生成されたドキュメン

トは、そのような一般的な電子フォーマットのラッピングサポートを含む公開されたヘルスケア標準に準拠することを確認する。非構造データ、テキストファイル、固有のドキュメントフォーマット（例えば、RTF）、または、イメージ、は、標準的なドキュメント形式内にカプセル化されるべきである(Ref ITI TF-1: 10.4.2)。

Integration Profile Actor Profile Option Option Meta Test

XDS.b DOC_REGISTRY NONE R

XDS.b DOC_REPOSITORY NONE R

XDS.b DOC_SOURCE NONE R

このテストに関連する統合プロファイル／アクタ：

23

Step Trans.Msg

Type

Ret

urn From Actor To Actor Step Description Opt.

10 NULL -- --

ドキュメントレジストリ、PIXマネジャおよびPDQサプライヤは、コネクタソンの基本情報スプレードシートから患者IDで事前登録される。それらの基本情報は、姓としてXDSのDoc Sourceのシステム名を含む。例えば、Ehrabc^Mary。

R

20 NULL DOC_SOURCE --

Document Sourceは、コネクタソンでの基本情報および作られた患者名から、患者IDを利用する新しいドキュメントを生成する。ドキュメントのそれらの値を使用して、最低限、患者名を提出する。1つのドキュメントを生成し、異なるリポジトリにまき散らしてはならない。

R

30 ITI-19 DOC_SOURCE DOC_REPOSITORY 認証ノード：TLS通信を開始。 R

40 ITI-41 DOC_SOURCE DOC_REPOSITORYDocument Sourceは、あなたのDocument Source'sの後ろにベンダ名が付けられた患者に対するDocument Repositoryに一つのドキュメントを送信する。

R

42 ITI-20 -- --Doc Sourceは、"Export" event、 Doc Repositoryは、"Import" eventのログを取る。

R

45 ITI-19 DOC_REGISTRY DOC_REPOSITORY 認証ノード：TLS通信を開始。 R

50 ITI-42 DOC_REPOSITORY DOC_REGISTRY Document Repositoryは、Document Registryにドキュメントを登録する。 R

52 ITI-20 -- --Doc Repositoryは、"Export" event、 Doc Registryは、"Import" event.のログを取る。

R

55 NULL -- --

チャットウインドウにSubmissionSet.unique IDの値を貼りつける。それをラベル付けする。例えば、SSID: 1.2.3.4.5.

審査員は、このテストを検証するためにその値が必要である。R

60 ITI-41 DOC_SOURCE DOC_REPOSITORY

（オプション）Document Sourceは、１つのサブミッションで複数のドキュメントを送付することが可能である。・今、それを実施する。（Document Sourcesは、この機能をもつことを要求はされない。しかし、Document Registries およびRepositoriesは、これをサポートしなければならない）。

O

70 ITI-42 DOC_REPOSITORY DOC_REGISTRY（オプション）Document Repositoryは、Document Registryにドキュメントを登録する。

O

80 NULL -- --あなたのログファイルを開いて、TLS通信を用いてトランザクションが実施されたことのエビデンスを示すログ情報を取り出しなさい。

R

90 NULL -- --

このステップは、Document Consumersにあなたのドキュメントのテストの支援を得る。Webブラウザを用いてGazelleにアクセスする。Connectathon ->

Connectathon. Objects。あなたが格納したドキュメント上の情報を追加する。それには、Patient Name, Patient ID, Document Source, Document Repository,

Document Registry, Document Type & Submission Set IDを含むことになる。

R

100 NULL -- --

NISTツールキットを利用して、あなた自身のテストを検証しなさい。ツール上では、Connectathon Tools.の下で、このテストへのリンクを見つけなさい。このテストのチャットウインドウで、ログの印"Pass"をつけて、コピー／ペーストしなさい。このテストを、あなたが成功を得るまで"ready to be verified"にしないこと。

R

130 NULL -- -- XDS_Error_Reporting.を終了するために、直ちに、実行することが許される。 O

テストシナリオ:

24

1.7 XDS.b Error Reporting

指示Document Registry およびDocument Repositoryシステムは、このテストを行う前に、XDS_Doc_Source_Stores_Documentのテストをかんりょうしておくべきである。Document Registry およびDocument Repositoryシステムは、このテストの１つのインスタンスを実行すべきである。Document Sourceは、このテストで補助の役割を果たすので、オプショナルなアクタとして認識されている。記述これは、ITI-42 Register Document Set-bに対して報告されたエラーをテストする。Registry actor およびRepository アクタは、ITI TF-2: 4.1.13の中で定義されたコードセットを使用してエラーを報告する必要がある。これは、エラー条件の小さなサブセットをテストする、しかし、コネクタソン審査員は、コネクタソンのテスト期間中に発生した他のエラー条件も監視し、それらの場合も同様にエラーコードをチックすることがある。それらの条件で、適切にエラーを報告することが成功したか、失敗したかが、このテストの一部である。審査員は、それらのテストを実行した際のエビデンス／ログを要求するか、立会いの下、再実行を求める。テストを終了したとき、このテストのこのインスタンスに対するGazelleチャットウインドウにログ情報／エビデンスを記録すべきである。これで、審査員にあなたのログデータを素早く見せることができる。評価コネクタソン審査員は、２つのエラー条件を評価する。１．ドキュメントソースが、Registry.で知られていない患者に対するドキュメントを提出した。Registryにより報告されたエラーは、このようなものであるべきである（errorCodeの値は、マッチしなければならない、しかし、codeContextのコンテンツは、テクニカルフレームワークでは必須ではない、そして、実装依存であってもよい；これは、可能な値のサンプルを含む）errorCode="XdsUnknownPatientId"

codeContext="Patient ID is not known to the registry"

location=""

severity="Error"/>

２．（オプショナルなステップ）Document Repositoryは、Document Registryに接続するのに失敗した。Repositoryにより報告されたエラーは、このようなものであるべきである（errorCodeの値は、マッチしなければならない、しかし、codeContextのコンテンツは、テクニカルフレームワークでは必須ではない、そして、実装依存であってもよい；これは、可能な値のサンプルを含む）<>

xmlns="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1" status="Failure">

<>

errorCode="XdsRegistryNotAvailable"

codeContext="Unable to connect to the Registry to register document"

location="" severity="Error"/>

このテストに関連する統合プロファイル／アクタ：テストシナリオ：

25

Stepb Trans.Msg

TypeReturn From Actor To Actor Step Description Opt.

10 NULL -- --

Document Registryは、次のような患者に対するPatient Identity

Feedを受け付けないことに注意。これは、ここでテストするエラー条件である。

R

20 NULL -- --

Document Sourceは、新しい Patient IDおよび名前としてError^Reportingをもつ新しいドキュメントを生成する。ドキュメント中のそれらの値を使用する（最低、患者名およびID）。

R

30 ITI-19 -- --Authenticate Node: Begin TLS communication.

認証ノード：TLS通信を開始。R

40 ITI-41 DOC_SOURCEDOC_REPOSITORY Document Sourceは、患者Error^Reportingに対して、Document

Repositoryに１つの単体のドキュメントを送信する。R

50 ITI-42DOC_REPOSITORY

DOC_REGISTRY

Document Repositoryは、Document Registryにドキュメントを登録する。このRegistryは、これは、知らない患者であるので、エラー

を報告すべきである。エラー返答のコピーを後の評価のため取っておくこと。

R

55 NULL -- --

Document Sourceは、Repositoryから返されたエラーの受け取り

を適切に扱うべきである。このステップは、評価の間に行なわれた判断を適切に導く認識として“オプショナル”と明記されている。

O

60 NULL -- --Document Registryは、このテストで終了し、他のテストに移ることができる。

R

70 NULL -- --つぎのステップは、Registryに接続できないRepositoryのエラー条件をテストする。

O

80 NULL -- --Document Repositoryは、このエラー条件を引き起こす存在しないRegistryを設けるべきである。

O

90 ITI-41 DOC_SOURCEDOC_REPOSITORY Document Sourceは 、患者 Error^Reporting と し て Document

Repositoryに他の単体のドキュメントを送る。O

100 ITI-42 -- --

Document Repositoryは、Document Registry.にドキュメントを登録することを試みる。Repositoryは、Registryに接続できなかった

場合は、エラーを報告すべきである。後の評価のため、チャットウインドウでエラー応答のコピーを保存しておくこと。

O

26

参照ドキュメントIT Infrastructure Technical Framework

Comments and implementer feedback on all documents can be submitted to the online discussion forums at http://forums.rsna.org.

Current Technical Framework - Revision 7.0

August 10, 2010

Copyright © 2010: IHE International, Inc.

Final Text Version

Vol. 1 (ITI TF-1): Integration Profiles

Vol. 2: Transactions - Volume 2 is divided into three separate sub-volumes:

Vol. 2a (ITI TF-2a): Transactions ITI-I through ITI-28. These transactions are used in the following profiles CT, PSA, EUA, PIX, RID,

XDS, ATNA, PDQ, PWP, NAV

Vol. 2b: (ITI TF-2b): Transactions (cont'd) ITI-29 through ITI-50. These transactions are used in the following profiles PAM, XDM,

XUA, XDS

Vol. 2x (ITI TF-2x): Appendices A through W and Glossary

Vol. 3 (ITI TF-3): Contains Section 4 Cross-Transaction Specifications and Section 5 IHE Content Specifications

27

参照ドキュメントSupplements for Trial Implementation

The IHE IT Infrastructure Technical Committee invites organizations to begin development work based on the following supplements to the IT

Infrastructure Technical Framework for Trial Implementation. These trial implementation profiles will be tested at the IHE Connectathons in January

2012. Supplements extend the IHE ITI Technical Framework 7.0 for Trial Implementation.

Asynchronous Web Services Exchange - Revised 2010-08-10

Cross-Community Access (XCA) - Revised 2010-08-10

Cross-Community Patient Discovery (XCPD) - Revised 2011-03-04

Cross-Enterprise User Assertion - Attribute Extension (XUA++) - Published 2010-08-10

Delayed Document Assembly - Published 2010-08-20

Document-based Referral Request (DRR) - Revised 2009-08-10

Document Digital Signature (DSG) - Revised 2009-08-10

Document Metadata Subscription (DSUB) - Revised 2010-08-10

Healthcare Provider Directory (HPD) - Published 2010-08-10

Multi-Patient Queries - Revised 2010-08-10

Notification of Document Availability (NAV) - Revised 2010-08-10

On-Demand Documents - Published 2010-08-10

Patient Identifier Cross-Reference (PIX) and Patient Demographic Query (PDQ) HL7 v3 - Revised 2010-08-10

Pediatric Demographics Option for PIX and PDQ - Revised 2010-08-11

Retrieve Form for Data Capture (RFD) - Revised 2010-08-10

Sharing Value Sets (SVS) - Revised 2010-08-10

XDS Metadata Update - Published 2010-08-10

IT Infrastructure User Handbooks

User handbooks provide advice, examples and considerations for the use of IHE ITI profiles.

Cookbook: Preparing the IHE Profile Security Section - Revised 2008-11-10

HIE Security and Privacy through IHE - Revised 2008-08-22

Template for XDS Affinity Domain Deployment Planning - Revised 2008-12-02

IT Infrastructure White Papers

The IHE IT Infrastructure Technical Committee has published the following white papers. These white papers facilitate the use of existing IHE ITI

profiles or scope the need for future profiles. White papers scope the need for future profiles.

Access Control - Published 2009-09-28

Cross-Community Information Exchange including Federation of XDS Affinity Domains - Revised 2008-10-10

A Service-Oriented Architecture (SOA) View of IHE Profiles - Published 2009-09-28

Emergency Contact Information (ECON) - Published 2008-08-22

XDS Patient Identity Management - Published 2011-03-04

28

参考サイト

１）XDS Main Page---XDS/XDR/XCAの各種情報が載っているWikiサイトhttp://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page

テストについては、XDSの他、XDR、XCAの各アクタも含まれる

29

参考サイト

２）XDSのテストについての説明Requirement

http://ihewiki.wustl.edu/wiki/index.php/XDS_Test_Kit_Test_Requirements

30

参考サイト

２）XDSのテストについての説明Descriptions http://ihewiki.wustl.edu/wiki/index.php/XDS_Test_Kit_Test_Descriptions

31

参考サイト

３）テストの実施方法

ただいま作成中