# FHIR とカスタム医療データベースの比較

> 独自のテーブルか、医療データのための HL7 FHIR R4 か：同じデータを両方で保存した場合のトレードオフ、それぞれの適切な場面、そして通常、独自のデータベースと FHIR レコードの間の分割について。

Source: https://developers.anpheros.com/ja/guides/fhir-vs-custom-database

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

これは、*どの* FHIR サーバーを使用するかという質問とは異なります。それについては、[Anpheros と他の FHIR サーバーの比較](https://developers.anpheros.com/ja/guides/fhir-server-comparison) を参照してください。

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

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

```sql
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 における同じ測定値：

```json
{"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 を使用して医療記録を保存する方法](https://developers.anpheros.com/ja/guides/store-medical-records-fhir) で詳しく説明しています。

## 並列比較

| | カスタムスキーマ | 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](https://developers.anpheros.com/ja/guides/medical-app-backend) でこの分割について詳しく説明しており、[How to build a healthcare API with TypeScript](https://developers.anpheros.com/ja/guides/healthcare-api-typescript) でそれを構築します。

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

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

## よくある質問

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

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

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

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

## 関連情報

- [FHIR データベーススキーマ](https://developers.anpheros.com/ja/guides/fhir-database-schema): FHIR リソースの保存とインデックス作成方法
- [FHIR R4 を使用した医療記録の保存方法](https://developers.anpheros.com/ja/guides/store-medical-records-fhir)
- [FHIR プラットフォーム](https://developers.anpheros.com/ja/guides/fhir)
- [Anpheros と他の FHIR サーバーとの比較](https://developers.anpheros.com/ja/guides/fhir-server-comparison)
- [医療アプリのバックエンドとデータベース](https://developers.anpheros.com/ja/guides/medical-app-backend)
- [ヘルスケア API](https://developers.anpheros.com/ja/guides/healthcare-api)