Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

FHIR対カスタム医療データベース

医療データのための独自テーブルかHL7 FHIR R4か：両方法で同じデータを読み取った場合の比較、トレードオフ、それぞれの適切な場面、そしてデータベースとFHIRレコードの一般的な分割について説明します。

ヘルスケア製品を開発するチームは、通常、早い段階で同じ選択に直面します。PostgreSQL やその他のデータベースで患者、測定値、診断のための独自のテーブルを設計するか、あるいは最初から HL7 FHIR R4 リソースとして医療データを保存するかです。カスタムスキーマは初日から迅速に実装でき、製品に正確に適合します。FHIR は初期段階でより多くの検討が必要ですが、データがシステム外に出る場合、監査される場合、同意を得て共有される場合、あるいは自分以外の誰かによって読み取られる場合に、その価値を発揮します。このページでは、同じデータを両方で保存した場合のトレードオフを正直に提示し、それぞれの選択が適切な場面について説明します。

これは、どの FHIR サーバーを使用するかという質問とは異なります。それについては、Anpheros と他の FHIR サーバーの比較を参照してください。

同じ測定値を、2つの方法で

カスタムスキーマにおける血圧測定値：

CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);

シンプルで、クエリが高速で、アプリケーションが必要とするものに正確に対応します。しかし、そのテーブルでは答えられない疑問が出てきます。

その値はどのデバイスまたは人物によって生成されたのか？患者が入力したのか、カフで測定されたのか、それとも看護師が入力したのか？
誰かが修正する前の値はいくらで、誰が修正したのか？
クリニックシステム、検査機関、または保険会社はそれをどのように読み取るのか？彼らのシステムでは、systolic は何を意味するのか？
患者はそれを医師のアプリケーションとどのように共有し、来月共有を停止するにはどうすればよいか？
心拍数、体重、HbA1c、その他の200の測定値を追加する場合、それは200のテーブルなのか、それとも自分で設計した1つの汎用テーブルなのか？

FHIR R4 における同じ測定値：

{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}

より冗長ですが、各部分にはどのFHIRシステムでも共有できる意味があります。LOINC は何を測定したかを示し、UCUM は単位を示し、meta.versionId は履歴を開始し、同じ Observation の形状が他の200の測定値を保持します。Anpheros では、Provenance リソースは誰がそれを書いたかも記録します。FHIR R4 を使用して医療記録を保存する方法で詳しく説明しています。

並列比較

	カスタムスキーマ	FHIR R4
最初の機能までの時間	数時間	リソースを学習するのに1日か2日
製品への適合性	完全一致	一般的。製品のビューはその上に配置されます。
新しい種類のデータの追加	種類ごとにマイグレーション	通常、既存のリソースに新しいコードを追加
システム外での意味	マッピングなしではなし	共有コード (LOINC, ICD-10, ATC, UCUM)
履歴と修正	設計が必要	バージョンと `_history` は設計による
誰が何を書いたか	設計が必要	`Provenance` (Anpheros では自動)
クリニック、ラボ、その他のアプリとの交換	その都度カスタム統合	FHIR R4 API, HL7 v2 インポート, International Patient Summary
アプリケーションごとの患者同意	設計が必要	SMART on FHIR スコープと OAuth
分析のためのクエリ	プレーン SQL	FHIR 検索、またはデータウェアハウスへのエクスポート
規制 (GDPR 第9条, EHDS)	全てのパートを文書化する必要がある	規制が参照する標準フォーマット

カスタムスキーマが適切な場合

データが医療データではなく、個人に関するものでもない場合。 トレーニングプラン、コンテンツ、製品カタログなど：独自のテーブルを使用してください。
短期間のプロトタイプで、製品を求める人がいるかどうかをテストする場合。合成データを使用し、移行計画を立てます。
標準モデルではうまく表現できないデータ、例えば新しい研究測定値など。FHIRでも（独自のコードシステムであるObservation、またはBasicで）格納できますが、カスタムテーブルの方が明確な場合があります。
ヘビーな分析。 FHIRをシステムオブレコードとして使用する場合でも、ほとんどのチームはレポート作成のためにデータを独自の形式でウェアハウスにコピーします。

FHIR が適切な場合

データが個人の健康記録である場合：測定値、診断、投薬、アレルギー、検査結果、文書など。
システム外にデータが移動する場合：患者、医師、クリニック、検査機関、保険会社、AI モデル、または患者の転居に伴う競合他社など。
誰が何を作成し、何が変更されたかを示す必要がある場合：監査、臨床安全性、紛争など。
患者がアプリケーションごとにアクセスを許可および取り消す場合。
欧州連合（EU）で販売する場合。EU では、European Health Data Space が標準フォーマットでの交換可能な記録を期待しています。

一般的な中間パス

ほとんどの製品は、データの種類によって両方を使い分けることになります。

your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks

データベースは小さく、製品の形状に合ったままになります。医療記録は標準化され、バージョン管理され、共有可能であり、自分で構築する必要はありません。Medical app backend and database でこの分割について詳しく説明しており、How to build a healthcare API with TypeScript でそれを構築します。

FHIRを自社で構築するために必要なこと

FHIRを選択することは、FHIRサーバーを自分で開発することを意味しません。選択肢としては、自身で運用するオープンソースサーバー、クラウドプロバイダーのFHIRストア、オープンソースのヘルスケアプラットフォーム、またはAnpherosのようなマネージドヘルスケアデータベースがあります。これらの選択肢は、同意管理、監査、来歴、居住性、および統合の処理者が異なります。Anpherosと他のFHIRサーバーとの比較で詳しく説明しています。

よくある質問

FHIRはデータベースですか？

いいえ。FHIRは、ヘルスデータの構造と交換のための標準です。リソース、コード、およびREST APIが含まれます。FHIRサーバーまたはマネージドFHIRデータベースは、リソースを格納し、実際のデータベースの上にAPIを実装します。

FHIRリソースを自分でPostgreSQLに保存できますか？

はい、JSONカラムとして独自のインデックスを使用すれば可能です。いくつかのオープンソースサーバーがまさにそれを行っています。作業は、ストレージに関するすべてのこと、つまり検索パラメータ、バージョン管理、参照、検証、患者ごとのアクセス制御、および来歴（provenance）です。

カスタムスキーマから始めて、後でFHIRに移行できますか？

はい、可能です。多くのチームがそうしていますが、移行はマッピングプロジェクトになります。すべてのテーブルは、これまで記録したことのないコード、単位、および作成者が必要になります。最初の機能から医療データをFHIRとして保存する方が、後で変換するよりもコストがかかりません。

GDPRに準拠するためにFHIRが必要ですか？

いいえ。GDPRは特定のフォーマットを要求していません。FHIRは、いくつかの義務をより簡単に満たすことができます。ポータビリティ（レコードが標準フォーマットでエクスポートされる）、目的ごとのアクセス制御、および誰がどのデータを処理したかを示すことです。