電子カルテ情報共有サービスFHIR実装ガイド JP-CLINS(CLinical Information Sharing ImplementationGuide) ドラフト版
0.9.13 - draft
Japan
電子カルテ情報共有サービスFHIR実装ガイド JP-CLINS(CLinical Information Sharing ImplementationGuide) ドラフト版 - Local Development build (v0.9.13) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
項目 | 内容 |
定義URL | http://jpfhir.jp/fhir/clins/ImplementationGuide/clinical-information-sharing |
Version | 0.9.13 |
Name | FHIR |
Title | 電子カルテ情報共有サービスFHIR実装ガイド JP-CLINS(CLinical Information Sharing ImplementationGuide) ドラフト版 |
Status | Draft ( 2024-02-14 ) |
Copyright | (一社)日本医療情報学会. CC(Creative Commons license) BY-ND CC表示・改変禁止 |
パッケージ(tgzファイル)のダウンロードは上部メニューから可能です。
本実装ガイドに関する質問やコメント(要望等を含む)は、以下のGoogleフォームから投稿してください。投稿にあたっては、Googleフォーム冒頭の説明をお読みいただき、了解された場合のみ投稿くださるようお願いします。
質問・コメント投稿フォームへ
«注意:このIGは協議中の暫定的な内容が含まれます。リソースのProfileも暫定版です。内容は間違いや暫定情報を含むことがあります。お気づきの点は上部に記載のGoogleフォームからお知らせをお願いします。»
«本実装ガイドは、令和2年度厚⽣労働科学特別研究事業「診療情報提供書、電⼦処⽅箋等の電⼦化医療⽂書の相互運⽤性確保のための標準規格の開発研究」、令和3−4年度同「次世代の医療情報の標準規格への改定等に関する研究」、令和4年度〜ムーンショット型研究開発事業「病院を家庭に、家庭で炎症コントロール」分担課題7、令和5年度〜戦略的イノベーション創造プログラム「統合型ヘルスケアシステムの構築」サブテーマD1、のそれぞれ一部の支援を受けて実施されているとともに、日本医療情報学会NeXERS課題研究会「FHIR日本実装検討WG」活動の協力により策定されています。»
厚生労働省が定めるいわゆる「3文書6情報」で使用されるFHIRリソースについてのプロファイルを定義する実装ガイドである。また、6情報を「電子カルテ情報共有サービス」に送信する際のBundle仕様や、送信した情報を同定するための識別子に関する仕様もここで定めている。 ただし、3文書(健診結果報告書、診療情報提供書、退院時サマリー)の文書ごとのFHIR実装ガイドは、以下で記載されている。
本実装ガイドは、FHIR R4.0.1に従い、JP-Core V1.1.xからの派生プロファイルの実装ガイドとして作成されている。従って、本IGに記述されていないことについては、JP-Core V1.1.xを参照していただきたい。
Push形態:
臨床情報を格納しているサーバが、あらかじめ決められた期間や条件を満たす臨床情報について、あらかじめ決められたタイミンで、定められたデータ種別のデータを、別のシステムに送信する(Push方式)形態。
3文書6情報を医療機関から「電子カルテ情報共有サービス」に送信するのはこの形態である。
この形態において、サーバが送信時に作成するリソース・インスタンスが従うべきプロファイルが本IGで説明される。
この形態では、複数のリソース・インスタンスのセットを一括して送信するときには、複数のリソースインスタンスを格納したひとつのBundleリソースタイプのデータとして送信する仕様を本実装ガイドで定める。
Pull形態:
FHIRに準拠した臨床情報を必要とするクライアントシステムが、FHIR REST APIに従って、あるFHIRリソースタイプのデータ(リソース・インスタンス)を臨床データを保有するサーバに要求し、サーバからのレスポンスとしてFHIR規格に従ったデータを受け取る形態。
この形態において、クライアントが受け取るリソースが従うべきプロファイルが本IGで説明される。
この形態では、複数のリソース・インスタンスのセットを受け取るときには、FHIR REST APIでの仕様にもとづき、複数のリソース・インスタンスを格納したひとつのBundleリソースタイプのデータとして返される。
[用語説明] FHIRリソース: FHIRでは医療情報は、リソースというひとまとまりのデータ項目を集めた構造的なデータとして記述される。
プログラミング言語でいう構造体のようなもので、メソッドのないClassのような概念に相当するともいえる。患者基本情報のPatientリソース、
検査結果のObservationリソースなど、100種類以上のリソースが定義されている。それぞれのリソースの構造(どういうデータタイプのどんな
要素から構成されているか)を定義しているのがProfile(プロファイル)である。
Profile自体もひとつのリソースである(StructureDefinitionリソース)。リソースの種類のことをリソースタイプと呼ぶ。
[用語説明] リソース・インスタンス: リソース(のProfile)に従って記述されたひとつひとつの実際のデータ(実体)のこと。
例:患者、田中太郎さんの患者基本情報をPatientリソースに従って記述したデータは、田中太郎さんのPatientリソース・インスタンスである。
なお、処方依頼情報は、6情報のひとつとして単独で(2文書に含まれない形で)電子カルテ情報共有サービスに送信されることはない。しかし、診療情報提供書、退院時サマリーの2文書に処方の内容を記述するために使用され、2文書の情報に埋め込まれて電子カルテ情報共有サービスに送信されるため、その場合には本仕様(電子カルテ情報共有サービスに送信する場合の仕様)にもとづいて記述される必要がある。
上記のリソースから参照される関連情報
上記6情報から、その要素情報として参照されるリソースタイプを以下に示す。 ここに記載されないリソースタイプの情報も2文書ではそれぞれの仕様に従い使用可能である。
上記のうち、患者情報以外のリソースは、6情報では、埋め込みリソース(containedリソース)の形で記述される。患者情報のリソースはBundleリソースのひとつのentryとして記述され、6情報からは参照の形をとる。
3文書(診療情報提供書、退院時サマリー、健診結果報告書)に含まれる6情報に該当する情報の記述方法
3文書の仕様書に記載されている6情報に該当する情報は、本実装ガイドに従い記述するものとする。
「電子カルテ情報共有サービス」では、3文書データは文書として取り扱われるとともに、これらの文書中に記述されている6情報に該当する情報は取り出され、6情報として送信されたのと同様に管理される。したがって、6情報を電子カルテ情報共有サービスに送信するのと同じ仕様で記述しなければならない。
★注意:3文書の仕様書に記載されている6情報に該当する情報の仕様が、本実装ガイドと異なっているのは、本実装ガイドのほうがあとで策定されたためである。今後、3文書の仕様書は本実装ガイドに合わせて修正される予定である。したがって、現時点で両者に相違がある場合には、本実装ガイドの仕様を優先するものとする。
FHIRでは、リソースの要素(例えば患者情報を記述するsubject要素)から参照されるリソースをcontained要素に格納することで、すべての参照される情報も包含する(埋め込む)ことができる。これを「contain する」といい、この方法でリソースの用途に埋め込み記述されるリソースをContainedリソース(正確にはContainされたリソース)と呼ぶ。Containedリソースは、そのリソースタイプを通常のリソースとして記述する場合に比べて、いくつかの制限があり、例えばContainedリソースをさらに埋め込むことはできない。 https://www.hl7.org/fhir/references.html (2.1.3.0.10 節参照)