FHIR / JLAC11 実装ガイド — 検査データを標準で繋ぐ

医療DX シリーズ： 目次 ① 工程表全体像 ② 法規制対応と技術要件 ③ 受注資格 ④ セキュア実装データインテグリティ AI 活用移行 ★ FHIR/JLAC11（本編） FAQ・用語集

「FHIR 対応は要件」の、その先の How

シリーズ②は「標準規格対応は要件」「相互運用は主導権の分水嶺」と書いた。だがどう実装するかは全編で空白だった。本編がその実装版。検査データを国際標準 HL7 FHIR と国内コード JLAC で他システムが解釈できる形にし、電子カルテ情報共有サービスに繋ぐところまでを扱う。

相互運用の核心は「データの意味を、相手のシステムにも分かる形で持つ」こと。自院ローカルの検査コードや独自フォーマットのままでは、繋いでも意味が伝わらない。FHIR が構造（どう運ぶか）、JLAC が意味（何の検査か）を担う——この2つを揃えて初めて相互運用になる。

本編は「深掘り編」。②が「標準対応は要件」（Why）、本編が「どう実装するか」（How）、移行プレイブックが「いつ変換を仕込むか」（When）、データインテグリティ編が「変換しても真正性を保つ」（Integrity）に接続する。

このガイドのスコープと網羅性の根拠

スコープ宣言（対象と対象外）

区分	内容
対象	臨床検査データの相互運用実装：HL7 FHIR R4（JP Core / JP-CLINS）のリソース設計、JLAC10→JLAC11 とローカルコードの名寄せ、HL7 v2 からの変換、電子カルテ情報共有サービスへの接続の考え方。
対象外	① 標準対応がなぜ要件か（法規制・調達）→ シリーズ②。② 変換をいつ仕込むか（移行の段取り）→ 移行プレイブック。③ 変換後も真正性を保つ方法 → データインテグリティ編。④ API 基盤のセキュア実装（OAuth/認可の作り込み）→ ④。⑤ 製品個別のマッピング表（ベンダー依存）。

区分

内容

対象

臨床検査データの相互運用実装：HL7 FHIR R4（JP Core / JP-CLINS）のリソース設計、JLAC10→JLAC11 とローカルコードの名寄せ、HL7 v2 からの変換、電子カルテ情報共有サービスへの接続の考え方。

対象外

① 標準対応がなぜ要件か（法規制・調達）→ シリーズ②。② 変換をいつ仕込むか（移行の段取り）→ 移行プレイブック。③ 変換後も真正性を保つ方法 → データインテグリティ編。④ API 基盤のセキュア実装（OAuth/認可の作り込み）→ ④。⑤ 製品個別のマッピング表（ベンダー依存）。

網羅性の根拠 — なぜ「これで足りる」と言えるか

相互運用は「構造」と「意味」の両輪。どちらが欠けても繋がらない。本編は2軸で押さえる。

軸1：構造（FHIR）＝検査を表す3リソース（DiagnosticReport / Observation / Specimen）を JP Core プロファイルに沿って設計（§3）。検査データの構造を漏れなくカバー。
軸2：意味（コード体系）＝検査項目 JLAC、単位 UCUM、その他必要なコードを正しく載せる（§4）。「何の検査か」を相手が一意に解釈できるようにする。

この2軸で「運ぶ器（FHIR）」と「中身の意味（コード）」を揃える。実装の残リスクは「①追加技術／②運用／③契約・SLA／④受容」の4分類で引き取る。

1標準の地図 — どれが何を担うか

標準	版・主体	役割
HL7 FHIR	R4（4.0.1）／HL7 International	データ交換の国際標準。REST API + JSON。日本の医療DXはこの R4 を採用
JP Core 実装ガイド	v1.2.0-a（2025-01、FHIR R4 ベース）／JAMI	FHIR を日本の臨床に合わせたプロファイル集。検査では Observation/DiagnosticReport/Specimen 等を規定
JP-CLINS 実装ガイド	v1.11.0／jpfhir.jp	電子カルテ情報共有サービス向け FHIR 実装ガイド（2文書5情報＋患者サマリー）。共有のための具体仕様
JLAC11（臨床検査項目分類コード）	日本臨床検査医学会／厚労省推奨	「何の検査か」を一意に表す国内コード。データ統合・2次利用向け。JLAC10（HS014 臨床検査マスターで定着）と併行運用中
UCUM	国際	検査値の単位を機械可読に（mg/dL 等）。FHIR の Quantity で使用
（参考）HL7 v2.5 / ASTM	従来規格	装置 IF・既存連携で広く使用。FHIR への変換元になる

役割分担の核心

FHIR が「構造」、JLAC が「意味」。 FHIR は「これは検査報告で、中にこういう結果項目がある」という器を標準化する。JLAC は「その項目が血清クレアチニンだ」という意味を一意に与える。両方揃えて初めて、受け取った別システムが「これは Cr の値だ」と機械的に理解できる。FHIR だけ対応してもローカルコードのままなら、繋がっても意味は伝わらない。

2検査を表す 3 つの FHIR リソース

臨床検査は主に次の3リソースで表現する（JP Core プロファイルに準拠）。

リソース	表すもの	検査での要点
DiagnosticReport	検査報告全体（オーダ単位の報告）	報告のまとまり。結果（Observation）への参照、検体（Specimen）への参照、報告日時、ステータス（final/preliminary 等）を持つ
Observation	個々の検査結果項目	1項目1リソース。code に JLAC（何の検査か）、value に結果（数値＋UCUM 単位、または定性値）、基準範囲、判定（H/L 等）
Specimen	検体	検体種別（血清・尿・組織等）、採取日時、検体 ID。DiagnosticReport/Observation から参照

「Observation の code に何を入れるか」が実装の分かれ目。 ここに自院ローカルコードを入れると相互運用にならない。JLAC（できれば JLAC11）を載せるのが標準。必要に応じてローカルコードを併記（CodeableConcept は複数 coding を持てる）するが、標準コードが主、ローカルが従。

3コード変換 — ローカル → JLAC11、v2 → FHIR

装置 / 既存IF

HL7 v2.5・ASTM・ファイル、ローカルコード

→

マッピング

ローカル→JLAC、単位→UCUM、v2セグメント→FHIR要素

→

FHIR リソース

DiagnosticReport / Observation / Specimen（JP Core）

→

共有 / 連携

JP-CLINS で電子カルテ情報共有サービスへ

JLAC10 → JLAC11 と名寄せの勘どころ

ローカルコード → JLAC のマッピング表を作るのが最初の山。自院の検査項目を JLAC（JLAC11 推奨、当面 JLAC10 併行）に対応づける。HS014 臨床検査マスターを参照基盤に
未マッピング項目の扱いを決める：標準コードが無い独自項目は、暫定の扱い（ローカルのみ＋将来対応フラグ）を明文化。「とりあえず空」は禁物
1依頼・複数報告等の構造差に注意（JLAC11 は 2025-02 改訂で識別コードの規定が見直された）。版とコード表の更新を追う
変換は一方向で終わらせない：マッピングの正しさを検証データで突合（移行プレイブックのリハーサルと同じ規律）

HL7 v2 → FHIR 変換

装置 IF や既存連携の多くは HL7 v2.5（OBR/OBX セグメント等）。これを FHIR の DiagnosticReport/Observation に対応づける
v2 の OBX-3（検査項目コード）→ Observation.code（JLAC）、OBX-5（値）→ Observation.value、単位 → UCUM
変換ロジックはアプリ層で実装し、テストで網羅検証（②④のセキュア実装・DI と接続）

4電子カルテ情報共有サービスへの接続

国の電子カルテ情報共有サービス（2025年度稼働）は、医療機関間で診療情報を HL7 FHIR で共有する仕組み。検査情報もここに乗る。

論点	内容
共有の単位	厚労省は「3文書6情報」として打ち出し。FHIR 実装ガイド JP-CLINS は「2文書5情報＋患者サマリー」として整備（健診結果報告書は健診 FHIR で別建て）。6情報に検査情報が含まれる
方式	HL7 FHIR（REST API・JSON）。自院システムの診療情報を FHIR に変換して連携
検査の載せ方	検査情報を JP-CLINS / JP Core のプロファイルに沿って Observation 等で表現。コードは JLAC、単位は UCUM
認可・セキュリティ	API 接続は OAuth 2.0 等の認可、通信暗号化。具体実装は④セキュア実装へ

用語の整理（混乱しやすい）

「3文書6情報」は政策の打ち出し、JP-CLINS の「2文書5情報＋患者サマリー」はFHIR 実装の packaging。健診結果報告書は健診 FHIR、患者サマリーが別途加わる、という整理。提案書では「電子カルテ情報共有サービス（FHIR 実装は JP-CLINS）」と書けば取り違えない。

5バリデーションとよくある落とし穴

バリデーション

生成した FHIR リソースをJP Core / JP-CLINS プロファイルで検証（必須要素・カーディナリティ・コード体系）。FHIR Validator を CI に組み込む
コード変換の全件突合：ローカル→JLAC、v2→FHIR の結果をサンプリングでなく機械照合
版の追従：FHIR R4・JP Core・JP-CLINS・JLAC11 は更新される。版を固定しつつ更新を追うプロセスを持つ（保守の仕組みはシリーズ目次のリンクチェック等と同様）

Observation.code にローカルコードだけ → 相互運用にならない。JLAC を主に。
単位を文字列で持つ → 機械処理不能。UCUM で。
未マッピング項目を空で流す → 受け側で欠落。暫定扱いを明文化。
「FHIR 出力できた」で検証を省く → プロファイル不適合のまま連携。Validator 必須。
「3文書6情報」と「2文書5情報＋患者サマリー」を混同 → 提案の正確性を損なう。JP-CLINS の packaging を正確に。
版を固定せず追従もしない → ある日連携が壊れる。版管理＋更新追跡を。
変換で真正性が落ちる → 誰が・いつ・どう変換したかを残す（データインテグリティ編）。