# ヘルスケアアプリケーションアーキテクチャ

> 図とデータフロー：患者からアプリケーションへ、Anpheros APIへ、FHIRレコードおよび外部サービスへ、そしてAIエージェントからコンテキストAPIへ、認可されたデータへ。

Source: https://developers.anpheros.com/ja/guides/architecture

Anpherosは、アプリケーション（またはAIエージェント）と患者のレコード間のメディカルデータレイヤーです。アプリケーションは独自のユーザーインターフェースとビジネスロジックを保持します。メディカルレコード、同意、来歴、監査はAnpheros内に存在し、1つのAPIを通じてアクセスされます。

```
  Your application, backend or AI agent
  (mobile app, web app, clinic system, lab system, LLM-based assistant)
                        │  HTTPS · API key (sk_test_ / sk_live_) or OAuth token (at_…)
                        ▼
  Anpheros Platform API
  ├─ /v1        simplified REST: patients, observations, conditions, medications,
  │             documents, timeline, provenance, context, labs, webhooks
  ├─ /fhir/R4   strict FHIR R4: 26 resource types, search, history, transactions,
  │             $everything, $summary (IPS), $validate
  └─ /oauth     OAuth 2.1 + PKCE, SMART on FHIR, OpenID Connect
                        │  every request: project isolation · scopes · rate limits
                        ▼
  One FHIR R4 record per patient
  ├─ versions of every resource (history)   ├─ Provenance for every write
  ├─ Consent resources for every grant      └─ access log visible to the patient
                        │
                        ▼
  Events out: signed webhooks to your server (ids only, never clinical content)
```

## 患者の視点：個人から外部サービスへ

```
Patient
   ↓   uses an app, chooses what to share, sees every access
Healthcare application          Anpheros Daily, or your own app
   ↓   REST v1 / FHIR R4 over HTTPS, API key or OAuth token
Anpheros API
   ↓   isolation, scopes, idempotency, provenance
FHIR medical data               the patient's record: 26 resource types, every version kept
   ↓   only what the patient allowed, only for as long as allowed
External healthcare services    laboratories (lab import), clinics (directory, acting-as),
                                other apps (OAuth / SMART), your backend (webhooks)
```

## AIビュー：エージェントから認可済みデータへ

```
AI agent or LLM application     runs the model you choose — hosted or local
   ↓   POST /v1/context  {patient, task, question, budget_tokens}
Medical context API             plans which parts of the record matter, fits them into the budget,
   ↓                            labels every item with author type and source, records a manifest
Authorised medical data         only records the project created or the patient granted;
                                the read appears in the patient's access log
```

モデルは認証情報を受け取ることはなく、Anpheros を直接呼び出すこともありません。コンテキストの要求とモデルに送信する内容の決定は、アプリケーションが行います。API 呼び出しを含む完全な例を 2 つ示します。AI ヘルスケアアプリケーションは [AI healthcare applications](https://developers.anpheros.com/ja/guides/ai-healthcare) に、同意に基づくエージェントは [AI agents and medical data](https://developers.anpheros.com/ja/guides/ai-agents-medical-data) にあります。詳細については、[AI agents and medical data](https://developers.anpheros.com/ja/guides/ai-agents-medical-data)、[LLM applications and healthcare data](https://developers.anpheros.com/ja/guides/llm-healthcare-data) を参照してください。

## レコード

各患者は、FHIR R4 リソースで構成される1つのレコードを持ちます。バイタルサイン、検査結果、症状、日々の活動概要には`Observation`、その他に`Condition`、`EpisodeOfCare`、`MedicationStatement`、`MedicationAdministration`、`DocumentReference`、`Immunization`、`AllergyIntolerance`など、合計26種類のリソースがあり、これらはCapabilityStatement (`GET /fhir/R4/metadata`) でライブ表示されます。学習すべき独自のスキーマはありません。REST API は、同じリソースを同じ ID で、よりシンプルなビューで提供します。

何もサイレントに上書きされることはありません。各更新は新しいバージョン (`/fhir/R4/{type}/{id}/_history`) を作成し、各バージョンはそれを書き込んだプロジェクトと、そのプロジェクトが書き込んだ組織を記録します。

## 2つのアクセス方法

| | API キー | OAuth アクセストークン |
|---|---|---|
| 見た目 | `sk_test_…` / `sk_live_…` | `at_…` |
| 使用者 | あなたのサーバー | 患者の代理として動作するアプリケーション |
| 閲覧範囲 | あなたのプロジェクトが作成した患者 | 患者が付与したスコープ内で、厳密に1名の患者 |
| 一般的な用途 | あなた自身のアプリのバックエンド、検査システム、クリニック連携 | 患者が既に持つレコードにアクセスするサードパーティ製アプリまたはAIアシスタント |

患者が付与しない限り、あるプロジェクトが別のプロジェクトの患者を見ることはありません。各プロジェクトは、同じ人物に対して独自の識別子（ペアワイズID）を取得するため、アプリケーション間でIDを相関させることはできず、あなたのアクセス範囲外にあるレコードは `404` を返しますが、`403` を返すことはありません。

## 2つの環境

サンドボックスと本番環境は、それぞれ独立したデータベースです。サンドボックスキー（`sk_test_`）は、実際の患者データにアクセスすることは物理的にできません。各サンドボックスプロジェクトには、30人の合成患者のコピーが提供され、自由に編集およびリセットできます。本番環境キー（`sk_live_`）は、検証済みの組織に発行されます。

## データフロー

**あなたのアプリが書き込みます。** `POST /v1/patients/{id}/observations` を `Idempotency-Key` を使用して行います。プラットフォームは FHIR `Observation` を保存し、`Provenance`（作成者タイプ：patient, practitioner, device, import, または ai）を書き込み、アクセスをログに記録し、サブスクライブされたエンドポイントに `resource.created` webhook を送信します。

**別のアプリケーションが同意を得て読み取ります。** 患者はホストされた同意ページ（`/oauth/authorize`）で承認し、レコードと期間（30〜365日）を選択します。アプリケーションはコードをトークンと交換し、スコープで許可されたもののみを読み取ります。患者はアプリケーション、そのスコープ、およびすべての読み取りをアクセスログで確認でき、いつでも取り消すことができます。

**検査機関が結果を届けます。** `POST /v1/patients/{id}/labs/import` を CSV、HL7 v2 ORU^R01、または JSON レポートで送信します。各結果は、既知の場合は LOINC コードを持つ検査機関 `Observation` となり、同じレポートを再送信しても安全です。

**AI モデルがコンテキストを必要とします。** `POST /v1/context` は、トークン予算内で、タスクに関連するレコードの部分を、ソースがラベル付けされた状態で返します。呼び出しはマニフェスト ID で記録されます。モデル自体は、選択した場所で実行されます。

## Anpheros と自社開発の比較

| 懸念事項 | 自社開発 | Anpheros を使用する場合 |
|---|---|---|
| 医療データモデル | 各レコードの種類ごとにテーブルを設計 | FHIR R4 リソース、26 タイプ |
| 相互運用性 | カスタムエクスポート形式 | FHIR R4、International Patient Summary、SMART on FHIR |
| 同意 | 付与、スコープ、有効期限、取り消しロジックを構築 | OAuth 2.1 グラントは FHIR `Consent` としてミラーリング |
| 監査 | ログ記録を構築し、患者に表示する方法を実装 | すべての読み取りと書き込みがログに記録され、患者に表示可能 |
| 検査連携 | 各検査機関のフォーマットを解析 | CSV、HL7 v2 ORU、JSON インポート |
| AI コンテキスト | 取得および要約コードを記述 | トークン予算と来歴ラベルを備えたコンテキスト API |

## 関連情報

- [Anpheros とは？](https://developers.anpheros.com/ja/guides/what-is-anpheros)
- [ヘルスケアソフトウェア開発](https://developers.anpheros.com/ja/guides/healthcare-software)
- [医療アプリのバックエンドとデータベース](https://developers.anpheros.com/ja/guides/medical-app-backend)
- [ヘルスケアアプリの構築](https://developers.anpheros.com/ja/guides/build-a-healthcare-app)
- [同意とアクセスモデル](https://developers.anpheros.com/ja/guides/consent)
- [セキュリティ、プライバシー、データレジデンシー](https://developers.anpheros.com/ja/guides/security)