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

Anpherosと他のFHIRサーバーの比較

セルフホスト型FHIRサーバー、クラウドFHIRストア、オープンソースヘルスケアプラットフォームとAnpherosを比較：アクセス認可、同意、来歴、データ所在地、価格設定、そしてそれぞれの適切な利用シーンについて解説します。

FHIR バックエンドを選択するチームは、通常 4 種類の選択肢を比較検討します。自分でホストするオープンソースサーバー、クラウドプロバイダーによるマネージド FHIR ストア、ホスト版を備えたオープンソースのヘルスケアプラットフォーム、または Anpheros のようなマネージドヘルスケアデータベースです。このガイドでは、それぞれの種類が得意なことと、2026 年 10 月時点の公開ドキュメントに基づいた Anpheros の位置づけについて説明します。ここに記載されている製品については、それぞれのドキュメントを確認してください。機能は変更される可能性があります。

4つの種類

	セルフホスト型 FHIRサーバー (例: HAPI FHIR)	クラウド FHIRストア (例: Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake)	ヘルスケアプラットフォーム (例: Medplum)	Anpheros
何か	あなたが実行するFHIRサーバー	クラウドアカウント内のFHIRデータストア	認証、ワークフロー、ホスト版を備えたFHIRネイティブアプリケーションプラットフォーム	管理されたヘルスケアデータベース: 患者ごとのFHIR R4レコード、同意、API、監査
アクセスを誰が承認するか	それを囲んで構築するものすべて	クラウドのIAM、プロジェクトまたはデータセットごと	プラットフォームのアクセスポリシー、あなたが設定したもの	患者 (OAuth 2.1同意) または組織 (APIキー)
患者向けの同意と監査	いいえ	いいえ	ポリシーモデルで構築可能	内蔵、患者に表示される
すべての書き込みにおけるプロベナンス	追加した場合	追加した場合	FHIRでサポートされています。あなたがそれを強制します	要求され、自動化されています
アプリケーション間の識別子の分離	いいえ	いいえ	いいえ	アプリケーションごとのペアワイズID
ラボインポート (HL7 v2)	別途ツール	部分的 (一部のストアでのv2からFHIRへのマッピング)	あなたが書いたインテグレーション	内蔵、1リクエスト
データレジデンシー	ホストする場所	プロバイダーが提供するリージョン	ホスティングによる	欧州連合のみ
価格	あなたのインフラストラクチャと時間	使用量ベース (リクエスト、ストレージ)	プランごとまたはセルフホスト	組織ごと、保存された患者数による
最適な用途	学習、完全な制御、特殊なデータモデル	そのクラウドにすでにいるチームで、ヘルスケアレイヤーを自分で構築する場合	オープンなコードベースで構築し、フルスタックを所有したいチーム	ヘルスケアレイヤーが完了し、製品を仕事として利用したいチーム

Google Cloud Healthcare API かマネージドプラットフォームか？

Googleの製品は文字通りCloud Healthcare APIと呼ばれており、「ヘルスケアAPI」の検索では最初に表示されることが多いです。これは、Google Cloudプロジェクト内のクラウドFHIRストア（HL7 v2およびDICOMストアも含む）であり、ストレージ、FHIR検索、IAMベースのアクセスを提供し、使用量に応じて課金されます。残りの部分（患者向け同意および監査、アプリケーション分離、ラボインポート、SDK、テストデータを含むサンドボックス）は、お客様が構築する必要があります。Anpherosはこれらの部分を提供し、EUにデータを保存します。お客様自身のクラウドアカウント内にFHIRストアを提供するものではありません。ヘルスケアレイヤーを誰に所有させるかによって選択してください。お客様のチーム（Cloud Healthcare API）か、プラットフォーム（Anpheros）かです。

オープンソース FHIRサーバーかマネージドか？

HAPI FHIRのようなオープンソースサーバーは、どこでも実行可能（Dockerイメージが利用可能）であり、独自のプロファイルと拡張機能を使用して、完全なFHIR仕様をサポートします。本番環境で実行する場合、データベース、アップグレード、セキュリティ、バックアップ、およびアクセスレイヤーを自身で運用する必要があります。マネージドプラットフォームは、その自由度の一部（Anpherosは26のリソースタイプを保存します）を、運用しないことと引き換えに提供します。このようなサーバーが内部で何を保存しているかについては、FHIRデータベーススキーマを参照してください。

Anpheros が適切な選択肢となる場合

患者、クリニック、研究所、または AI 向けの製品を構築しており、レコードではなく製品を記述したい場合。
患者の同意と、患者が閲覧できる監査ログが要件であり、あったら嬉しい機能ではない場合 (GDPR 第 9 条、EHDS)。
データは欧州連合内に留める必要がある場合。
FHIR R4 に加えて、シンプルな REST ビュー、SDK、および Webhook を 1 つのベンダーから利用したい場合。
無料のサンドボックスで現実的な合成患者データから開始し、書き直しなしで本番環境に移行したい場合。

他の選択肢が適している場合

Anpheros がサポートする 26 種類以外の FHIR リソースタイプ、プロファイル、または拡張機能が必要な場合、あるいは完全にカスタムのデータモデルが必要な場合：セルフホスト型サーバーがその自由度を提供します。
コンプライアンス上の理由から、すべてのものを 1 つのクラウドアカウント内に配置する必要がある場合：クラウド FHIR ストアがそのポリシーに適合します。
認証サーバーや UI コンポーネントを含むスタック全体を所有および変更したい場合：オープンソースプラットフォームがそのために設計されています。
EHR 起動、バルクデータエクスポート、または system/ スコープを今日必要としている場合：Anpheros はまだそれらを提供していません（SMART on FHIR による患者同意の実装方法を参照してください）。

公平な意思決定の方法

製品が必要とするヘルスケアレイヤーの各部分（同意、来歴、監査、識別子、ラボインポート、ドキュメントストレージ、居住性）を数え、選択したオプションごとに構築および保守にかかる月数を推定します。次に、その推定値を、それらの月数で取り組むことができた製品作業と比較します。後者の数値が大きい場合、Anpheros が適切な回答となります。