Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
FHIRデータベーススキーマ
FHIRリソースの保存方法：正規化テーブル対JSON（検索インデックス付き）対グラフ。Anpherosが実行するPostgreSQLスキーマ（リソース、履歴、型付きインデックス、プロジェクション）と重要なルールについて説明します。
FHIR データベースは、HL7 FHIR リソースを保存し、FHIR API を介して読み取り、検索、バージョン管理できるようにします。最も一般的なスキーマでは、各リソースを JSON として保存し、検索パラメータ用の個別のインデックステーブルを埋めます。これは、すべての要素を正規化されたリレーショナルテーブル全体に分散させるのではなく行われます。 このページでは、3 つの一般的な設計、Anpheros が PostgreSQL で実行するスキーマ、および自分で構築すべきでない場合について説明します。
FHIRの3つの保存方法
| Normalised tables | JSON + search indexes | Graph database | |
|---|---|---|---|
| Stores any valid resource unchanged | — | ✓ | ✓ |
| Standard FHIR search on any parameter | ◐ | ✓ | ◐ |
| New fields need a schema migration | ✓ | — | — |
| Easy SQL reporting | ✓ | ◐ | — |
| Used by mainstream FHIR servers | ◐ | ✓ | — |
◐ = possible with extra work. HAPI FHIR and Anpheros both keep the resource as JSON and index search parameters separately.
FHIRリソースは、深く、オプションであり、拡張可能です。例えば、Observationリソースだけでも数十個の要素、選択型（value[x]）、繰り返し可能なコーディング、拡張機能があります。これをリレーショナルカラムに正規化すると、プロファイルがフィールドを追加するたびにマイグレーションが必要になります。リソースをJSONとして保存すると、有効なものはすべて変更されずに保存され、インデックステーブルによって検索可能になります。
Anpheros スキーマ
- APIFHIR R4 REST and the simpler /v1 REST API
- Current resourcesOne row per resource: type, id, patient, version, the full FHIR JSON (JSONB)
- Search indexesTyped tables filled on every write: token, string, date, reference, quantity
- HistoryEvery version of every resource, never overwritten
- ProjectionsFlat tables for the common REST views: observations, conditions, medications
- PostgreSQLOne database per environment; sandbox and production are separate
| テーブル | 1行あたり | キー列 |
|---|---|---|
fhir_resources |
リソースの現在のバージョン | resource_type, id, patient_id, version, json (フルリソース), last_updated, deleted、およびプロベナンス列 |
fhir_history |
過去に書き込まれたすべてのバージョン | resource_type, id, version, json, last_updated |
idx_token |
コード化されたまたは識別子の検索値 | system, code — code, category, identifier, status 用 |
idx_string |
テキスト検索値 | 正規化されたテキスト — 名前およびフリーテキスト用 |
idx_date |
日付検索値 | 範囲の開始と終了 — date, onset-date, birthdate 用 |
idx_reference |
参照検索値 | ターゲットタイプとID — patient, subject, encounter 用 |
idx_quantity |
量検索値 | value, system, unit — value-quantity 用 |
proj_observations, proj_conditions, proj_medications |
リソース、フラット化 | シンプルなREST APIがフィルタリングする列 |
書き込みごとに、プラットフォームはリソースを検証し、新しいバージョンをfhir_resourcesおよびfhir_historyに書き込み、インデックス行とプロジェクションを置き換え、Provenanceを記録します。Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01のような検索は、idx_reference、idx_token、およびidx_dateに対するJOINになります。結果は、書き込まれたとおりの保存されたJSONを返します。
重要となる設計ルール
- 宣言された検索パラメータのみをインデックス化し、未知のものは無視せずに
400で拒否します。 - 履歴なしでのインプレース更新は絶対に避ける: 修正は、以前に知られていた情報を保持する必要があります。
- ソフトデリート: 削除されたリソースは読み取りおよび検索から消えますが、監査のためにそのバージョンは保持されます。
- 患者コンパートメント列: すべてのリソースに
patient_idを格納することで、$everything、同意フィルター、および患者ごとの分離が容易になります。 - 保存前に検証する: ストア内の無効な JSON は、後続のすべてのリーダーで問題を引き起こします。
よくある質問
FHIR に最適なデータベースは何ですか？
ほとんどのプロダクション FHIR サーバーでは、PostgreSQL のようなリレーショナルデータベースを使用し、リソースは JSON (JSONB) として格納し、検索パラメータは別のテーブルにインデックス化しています。これにより、柔軟なストレージと高速で標準的な検索を組み合わせることができます。
FHIR リソースをリレーショナルテーブルに正規化する必要がありますか？
通常、プライマリ ストアとしては必要ありません。正規化されたテーブルはレポートに適しています。それらは、格納されたリソースから構築されたプロジェクションとして保持してください。Anpheros がそのシンプルな REST API で行っているように。
HAPI FHIR はリソースをどのように格納しますか？
HAPI FHIR の JPA サーバーも、各リソースバージョンをシリアライズされた JSON として格納し、検索パラメータを別のインデックステーブルに保持します。Anpheros の設計も同じ原則に従っています。
FHIR データベースを自分で構築する必要がありますか？
プロファイルとリソースタイプを完全に制御する必要がある場合にのみです。それ以外の場合は、マネージド FHIR プラットフォームが、スキーマを実行せずにストレージ、検索、履歴、同意、監査を提供します。
関連情報
- FHIR とカスタム医療データベースの比較
- FHIR R4 を使用した医療記録の保存方法
- 無料の FHIR データベースとサンドボックス
- Anpheros と他の FHIR サーバーの比較
- FHIR プラットフォーム
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card