📚 標準化シリーズ 第4回（全4回＋実例編）
📄 参照: HL7 FHIR JP Core 実装ガイド（jpfhir.jp）、版の履歴、JP-CLINS 実装ガイド、日本医療情報学会 FHIR IGポータル（std.jpfhir.jp）、日本HL7協会。JP Core・JP-CLINSは日本医療情報学会（JAMI）のFHIR日本実装検討ワーキンググループが策定しています。
はじめに ― 「日本版FHIR」の正体
前回のHL7 FHIR 入門で、FHIR R4 と JP Core をひととおり見ました。今回は、その JP Core だけを取り出して深掘りします。日本で FHIR を語るとき、必ず出てくる言葉。ここを押さえると、電子カルテ情報共有サービスの設計図がすっきり見えてきます。
結論を先に言うと、JP Core は 「日本でFHIRを使うときの共通ルールブック」。国際標準のFHIRと、日本の現場のあいだをつなぐ土台です。
なぜ JP Core が要るのか
FHIR R4 は国際標準で、あえて自由度を高く作られています。世界中のどんな医療制度にも対応できるよう、緩やかに決めてあるのです。ところが自由度が高いままだと、同じ患者情報でも実装者によって書き方がバラバラになり、結局つながりません。
そこで登場するのが 実装ガイド（Implementation Guide, IG） です。IGは「この国・この用途では、こう書く」と制約を足すもの。JP Core は、その日本向けの共通版です。
キーワードは「プロファイル」
JP Core の中身は、プロファイルの集まりです。プロファイルとは、FHIRのリソース（前回の Patient や Observation など）に「日本ではこの項目は必須」「このコードはこのマスタを使う」といった制約をかけた型のこと。
たとえば JP_Patient（患者のプロファイル）では、患者の 識別子（identifier）を必ず持つことが求められます。被保険者番号などで患者を確実に識別できるようにするためです。ほかにも JP_Observation（検査・観察）、JP_Condition（病名）、JP_MedicationRequest（処方）、JP_AllergyIntolerance（アレルギー）などが定義されています。
JP Core は FHIR R4（4.0.1）をベースに、日本医療情報学会（JAMI）のワーキンググループが策定・改訂を続けています（2025年に v1.2.0 が公開され、後継版の開発も進行中）。
JP Core は FHIR R4 の「どこまで」をカバーするか
よく聞かれるのが「FHIR R4 のうち、JP Core はどこまで対応しているのか」です。
FHIR R4 には、患者や検査から予約・請求まで 約145種類 のリソース型があります。JP Core は、そのすべてではなく、日常診療でまず必要になる中核的なリソースにプロファイルを定義しています。JP Core v1.2.0 時点では、約25種類 のFHIR R4リソース型に対応しています。
つまり JP Core は「FHIR R4 の全部」ではなく、現場で必要な範囲から。足りない部分は、版が上がるにつれて、また用途別IG（JP-CLINS など）で補われていきます。
JP Core v1.2.0 が対応するFHIR R4リソース（約25種）
| 分類 | 対応する FHIR R4 リソース |
|---|---|
| 人・組織・受診（管理系） | Patient（患者）／ Practitioner（医療者）／ PractitionerRole（医療者の役割）／ Organization（組織）／ Location（場所）／ Coverage（保険）／ Encounter（受診・入院） |
| 傷病・アレルギー・所見 | Condition（傷病名）／ AllergyIntolerance（アレルギー）／ Observation（検査値・バイタル・身体所見 ほか、用途別に複数）／ DiagnosticReport（検査・画像レポート、用途別に複数）／ Procedure（処置・手術）／ FamilyMemberHistory（家族歴） |
| 医薬品（処方〜調剤〜実施） | Medication（医薬品）／ MedicationRequest（処方）／ MedicationDispense（調剤）／ MedicationAdministration（投与実施）／ MedicationStatement（服薬状況） |
| 検査・画像・検体・予防接種 | ServiceRequest（オーダ）／ Specimen（検体）／ ImagingStudy（画像検査）／ Media（内視鏡画像 等）／ Immunization（予防接種） |
| デバイス・データ | Device（医療機器）／ Binary（バイナリデータ） |
Observation や DiagnosticReport などは、用途ごとに複数のプロファイルへ枝分かれします（例：Observation はバイタル・検査結果・身体所見 …）。最新かつ正確な一覧・対応版は、公式の JP Core Artifacts でご確認ください（版が上がると対応リソースも増えます）。
標準マスタと、ここで合流する
思い出してください。第2回の標準マスタで見た ICD-10対応標準病名・JLAC・HOT などのコード群。JP Core のプロファイルは、「このコード欄には、この標準マスタを使う」という結びつき（用語のバインディング）を定めています。
つまり——
器（FHIR / JP Coreのプロファイル）× 語彙（標準マスタ）= 実際に交換できるデータ
この連載でずっと分けて説明してきた「器」と「語彙」が、JP Core で具体的に合流します。ここが、標準化シリーズの一つの到達点です。
階層構造 ― JP Core の上に「用途別IG」が立つ
JP Core の最大のポイントは、それ自体が最終ゴールではなく、共通の土台だということです。実際のサービスは、JP Core の上に用途ごとの実装ガイドを重ねて作られます。
代表が JP-CLINS（CLinical Information Sharing IG）です。これは電子カルテ情報共有サービス向けの実装ガイドで、正式には 「2文書5情報＋患者サマリー」 を扱う仕様として整備されています。
📝 補足：電子カルテ情報共有サービスは全体として「3文書6情報」と呼ばれますが、そのうち診療情報提供書・退院時サマリーなどを扱う JP-CLINS は「2文書5情報＋患者サマリー」という単位で仕様化されています（健診結果報告書などは別の記述仕様）。
同じように、電子処方箋の処方情報や健診結果報告書にも、それぞれ JP Core の上に立つ FHIR 記述仕様があります。共通の土台（JP Core）を一度作れば、用途別IGはそれを再利用できる——これが、開発の効率と、サービス間の一貫性を生みます。
クリニック・ベンダーにとっての意味
- 電子カルテやシステムが 「JP Core 対応」 であることは、これからの連携のベースラインになります
- ただし、実際に電子カルテ情報共有サービスへ接続する際は、JP-CLINS など用途別IGの仕様に従う必要があります（JP Core だけでは足りない）
- 仕様は版が上がっていくもの。対応バージョン（JP Core / JP-CLINS の版）が合っているかは、導入時の確認ポイントです
- 前回同様、普及はこれから。だからこそ、選定時に「どのIG・どの版に対応しているか」を確認する意味があります
まとめ
- JP Core は、国際標準 FHIR R4 を日本向けに具体化した 共通基盤の実装ガイド（JAMI が策定、FHIR R4 4.0.1 ベース）
- 中身は プロファイル（
JP_Patientなど、制約をかけたリソースの型）。標準マスタと結びつき、「器 × 語彙」がここで合流 - 構造は FHIR R4 → JP Core → 用途別IG。電子カルテ情報共有サービスの JP-CLINS（2文書5情報＋患者サマリー）などがその上に立つ
- 「JP Core 対応」は今後のベースライン。実接続は用途別IG（版に注意）に従う
「標準化 → マスタ → FHIR → JP Core」。この4回で、日本の医療データがつながる仕組みを、土台から屋根まで通して見てきました。
📎 標準化シリーズ（全4回＋実例編）
- （第1回）医療等情報の『標準化』とは ― グランドデザインと将来像
- （第2回）標準マスタ入門 ― 病名・医薬品・検査コードの世界
- （第3回）今更聞けない HL7 FHIR ― FHIR R4・JP Core
- （第4回・本記事）JP Core とは何か ― 日本版FHIRの共通基盤
- （実例編）FHIRに対応する主なサービス・製品カタログ
あわせて読みたい
- 電子カルテの更改・データ移行で失敗しないために
- 言葉の確認は 医療DX 用語集
本記事は、HL7 FHIR JP Core／JP-CLINS 実装ガイド（jpfhir.jp）・日本医療情報学会 FHIR IGポータル・日本HL7協会 の公開情報に基づき整理したものです。プロファイル・版の最新情報は各公式情報をご確認ください。