「地域医療連携における情報連携基盤
Q1)

技術仕様」パブリックコメント

コメント対応9 章以降は章ごとに改ページされているが、8 章まではされていない。Appendix は、Appendix毎に改ページすべき。統一するべき。

A1)

ご意見ありがとうございます。
「全体的な見やすさ」と「ページ余白を多くしない」という 2 点を考慮し、現在のようなページ構成になっております。ご理解ください。

Q2)

6 章の最後のパラグラフは、2 章に入れた方が良い。

A2)

ご意見ありがとうございます。6 章は説明（解説）にあたる部分ですので、この内容を 2 章「範囲」に組み入れることは妥当ではないと考えます。しかしながら、記載に誤解がないよう以下の様に変更を行いました。
「ポリシーに関してはそれぞれのコミュニティで定めることとし、本仕様書の範囲外とする。」↓「 ポ リ シ ー に 関 し て は そ れ ぞ れ の コ ミ ュ ニ テ ィ で 定 め る こ と で あ り 、 IHE-ITI TechnicalFramework ではスコープ外となっている。」

Q3)

IHE の用語、統合プロファイル名、アクタ名、トランザクション名が説明されないまま使われている。

A3)

ご意見ありがとうございます。統合プロファイル名、アクタ名、トランザクション名の解説については、本文中にて説明を行っております。用語定義でプロファイル名・アクタ名等の解説を行うのは妥当ではないと考えております。ご理解ください。

Q4)

6. 地域医療連携の概要が、地域医療連携をこのパターンだけに限定しているように読める。

A4)

ご意見ありがとうございます。6 章は説明（解説）にあたる部分です。地域連携のパターンを限定しているわけではありません。しかしながら、記載に誤解がないよう以下の様に変更を行いました。
「地域医療連携における情報連携として、図 1 のようなシナリオを想定する。」↓「地域医療連携における情報連携として、図 1 のようなシナリオを例示する。」

Q5)

6 章の第 2 パラグラフは PIX/PDQ の、第 3 パラグラフは XCA の、IHE 用語を使った説明と思われるが、XDS.b、XDS-I.b、ATNA、CT については、同様の説明がない。

A5)

ご意見ありがとうございます。XDS.b の説明は第１パラグラフ内に記載がございます。6 章は説明（解説）にあたる部分であり、あくまでも例を挙げて説明しているにすぎません。ここで全ての機能（統合プロファイルなど）に関する例示を行う必要はないと考えています。ご理解ください。

Q6)

図と説明文が別ページになっていて見にくい。

A6)

ご意見ありがとうございます。ページ余白等を考慮した結果、現在のようなページ構成になっております。今回は、ページレイアウト上修正は行いませんが、今後の参考とさせていただきます。

Q7)

図のタイトルの付け方や、図の描き方がばらばら。

A7)

ご意見ありがとうございます。図に関しては全て同一作者によるものであり、タイトル・描き方についてはある程度統一されていると思っています。今回は修正を行いませんが、今後の参考とさせていただきます。

Q8)

図の実線、点線、鎖線の使い分け・意味が不明。

A8)

ご意見ありがとうございます。実線、点線、鎖線についての明確な区別は行っていません。また、線の近辺にその線の意味等の記載がされています。今回は修正を行いませんが、今後の参考とさせていただきます。

Q9)

統合プロファイル名のあとに括弧書きでいちいち略号をつけているのは鬱陶しい。

A9)

ご意見ありがとうございます。統合プロファイル名のあとに括弧書きで略称を付けるのは、IHE
Technical Framework の記載方法です。本規約では、IHE Technical Framework の記載方法を採用しております。ご理解ください。

Q10) 統合プロファイルの利用を「必須」と言うのはどのような意味なのか。PIX/PIXV3、PDQ/PDQV3、XDS.b、CT、ATNA は必ず実装しなくてはいけないという意味か？

PDQ を実装しない、ATNAを実装しないという地域連携はあり得ると思うが。
A10) ご意見ありがとうございます。各統合プロファイル間での依存関係があるため、必須とならざるを得ない統合プロファイルがございます。統合プロファイル間の依存関係については、「7.2. 地域医療連携における統合プロファイル間の依存関係」に記載してあります。ただ、PDQ については、実装しないユースケースに配慮いたしまして、「患者属性情報の検索が必要な場合は、PDQ もしくは PDQV3 のどちらかを利用する必要がある」と記載を改めました。
Q11) 8 章以降のプロファイルの説明は表形式の方が見やすいのでは。
A11) ご意見ありがとうございます。参照先の原典を記載している箇所と推察致しました。現在の表現方法と表形式での表現方法を見比べて検討いたしましたが、現在の表現方法の方が、見やすいとの結論に至りました。ご理解頂けると幸いです。
Q12) 17 章になぜこのような拡張をするのかの説明が必要。
A12) ご意見ありがとうございます。17.1 節

先頭箇所に国内拡張理由について記載致しました。

Q13) 日本国内拡張が、IHE 標準とどのように違うのか、同一頁内にて、上段/下段、左/右 で対比出来るような構成になることを希望します。
A13) ご意見ありがとうございます。日本国内拡張部分につきましては、拡張した部分を灰色で表記し、拡張内容を「○→△」のように記載するように致しました。また、拡張理由を注記として記載しております。

Q14) 「１．はじめに」に「診療に必要な情報を空間的制約を超えて迅速に取得し、診療の質の向上に役立てるには、本技術仕様に記載の基盤的な統合プロファイル以外にも、実際の診療に必要な統合プロファイルがある（第７章参照）」を追加する。
A14) ご意見ありがとうございます。本仕様の範囲として地域連携の基盤部分のみとしており、その他の統合プロファイルについては、記載しないことになっております。ご了承ください。今後の改訂時に改めて検討させて頂きます。
Q15) 本書では「ドキュメント共有(XDS を中心) ≒地域医療連携」という感じを受けますが、相互読影なども「地域医療連携」の一部と考えることもできます。読者それぞれの立場によって「地域医療連携」の定義が異なるので、本仕様書の位置づけを、「情報共有(相互参照)を目的とした地域医療連携を実現するための技術仕様」ということでとらえた方がよろしいかと思いました。
A15) ご意見ありがとうございます。
「２．範囲」に「（前略）参加施設の情報システム間で患者（個人）の識別情報および医療情報等を共有するのに必要な情報連携基盤の仕様を定めたものである。」と記載しております。よって、本仕様の位置付けとしては、情報共有を前提としたものであるとご理解頂きたいと思います。
Q16) XDS-I 関連の説明が少ない(ほとんどない)ので、本書で記載すべきかと思います。
A16) ご意見ありがとうございます。
「６．地域連携の概要」での記載と認識しております。ここは、理解を助けるために、情報共有型地域連携の概要について例を挙げて説明している箇所ですので、全ての統合プロファイルについて説明は行っておりません。ご了解ください。
Q17) CT や ATNA が P8 ではじめて登場していますが、「どの場面で、どういう目的で」これらの統合プロファイルが必要なのかが分かるように、XDS や PIX と絡めて、ドキュメントの登録や参照のユースケースの中で CT や ATNA の必要性に言及した方がよろしいかと思います。
A17) ご意見ありがとうございます。
「６．地域連携の概要」では、CT や ATNA については説明しておりません。
「７．地域医療連携における情報連携基盤の仕様」以降で、順次説明しております。ご了解ください。
Q18) 実際に運用するには、ドキュメントの削除や、登録時のメタ情報の変更も発生しうるので、それらに対応した統合プロファイルについても言及した方がよろしいかと思います。
A18) ご意見ありがとうございます。ご指摘の統合プロファイルは Document Metadata Subscription(DSUB) の こ と と 推 察 い た し ま す 。 し か し な が ら 、 DSUB の 現 在 の バ ー ジ ョ ン は TrialImplementation となっております。本仕様では、Supplement 並びに Trial Implementation のバージョンは、記載しない方針で編集をおこなっております。将来、DSUB が Technical
Framework 本編に編入された場合は、本仕様に含むべきか再度検討を行うつもりです。また、実際の運用に関する事柄やポリシーに関しては、本仕様の範囲外となっております。ご了解ください。
Q19) 17 章は、原文(英文)の Technical Framework の仕様も残しつつ、日本では「この仕様も使用可能」とする…という追加的な意味でしょうか？それとも、英文の仕様は使わず、日本では「この仕様のみが使用可能」という意味でしょうか？後者であれば、大本のテクニカルフレームワークに定義されているものは極力そのまま日本でも使用すべきだと考えます。合理的理由があれば、明確に示していただきたいです。
例：PIX Query の Consumer 側の AuditEvent・・・提案の仕様書 P35 では EV(110117, IHEJ,“PIXQuery”) ですが、原文のテクニカルフレームワークでは、EV(110112, DCM, “Query”) となっています。
→

日本では、EV(110112, DCM, “Query”)も、EV(110117, IHEJ, “PIX Query”)もどちらでも使用可なのか、EV(110117, IHEJ, “PIX Query”)のみに限定するのか･･･どちらでしょうか？
A19) ご意見ありがとうございます。ご質問の部分は、DICOM 規格の記載と Technical Framework の記載に整合性の点で問題が存在しております。この整合性を解決するため、日本国内拡張を行いました。拡張理由については、公開版文書の１７章に説明文を追加致しました。