Open Health Sync

docker pull ghcr.io/soma-intelligence/open-health-sync:0.2.0

_{合成データを使った v0.1.0 のクイックスタートの記録です。スタックを起動し、6 台のデバイスから 90 日分のデータを読み込み、統合ビューの 1 日分のデータと、1 件の心拍数測定値を REST、FHIR R4、Open mHealth 形式で読み取り、MCP ツールを確認します。モックは一切ありません。録画は再度レンダリングできます。}

Open Health Sync（ohs）は、ヘルスデータを取り込み、正規化するセルフホスト可能なレイヤーです。プロバイダーからデータを取得し、スマートフォンからのアップロードを受け付け、各ペイロードをそのまま保存して、1 つの標準モデルと単位にマッピングし、REST API と読み取り専用 MCP サーバーで提供します。ダッシュボードでもコーチングアプリでもなく、医療機器や臨床ソフトウェアでもありません。ご自身で運用するか、ホステッドベータでこちらに運用をお任せください。

同じサーバーを、あなたに代わって運用します。ホステッドベータでは、Postgres、raw store、ワーカーの運用が不要な Open Health Sync を利用できます。サインインしてキーを作成すれば、最初の呼び出しからデータを読み取れます。

_{テストデータを使った75秒のツアーです。アカウントとプロジェクトを作成し、MCP 経由でコーディングエージェントを接続して、サンプルデータを読み込み、グラフを確認し、エクスプローラーから API を呼び出して、最後に Ctrl K を押します。動画を再生（MP4、9 MB）。}

• 1分でキーを取得。 プロジェクトを作成して、API キーを取得できます。ベータ期間中は、1アカウントにつき3つのプロジェクト、1プロジェクトにつき5つのキーを作成できます。
• 最初の呼び出しからデータを取得。 クリック1つで、6つのソースから30日分の合成ユーザーデータを追加できます。そのため、最初のリクエストから睡眠、心拍数、歩数が返されます。
• あらゆる出力形式。 REST（OpenAPI ファイル付き）、FHIR R4、Open mHealth、CSV と Parquet、署名付き Webhook、読み取り専用の MCP サーバーを利用できます。詳しくはここに記載しています。
• あなたの値が入力されたクイックスタート。 curl、TypeScript、Python にはインスタンスのアドレスが入力されています。さらに、サンプルアプリと MCP 経由の AI エージェントも利用できます。
• 移行は不要。 このオープンソースサーバーを実行します。このサーバー向けに書いたコードは、ベース URL とキーを変更するだけで自分のインスタンスに移行でき、また戻すこともできます。

_{ウェブサンプルがプロジェクトキーを使ってユーザーのデータを読み戻します。1日あたりの歩数、安静時心拍数、睡眠ステージは、すべて合成データです。}

オープンサインアップの無料ベータで、共有容量で運用されています。現在はテストデータのみ利用できます。デモユーザーと合成ユーザーが対象で、実在する人の健康データは利用できません。セルフホストは引き続き第一級の選択肢であり、サーバーは AGPL のもとで無料のままです。

無料で始める →  メールアドレスで登録して、確認してください。すでにアカウントをお持ちですか？ 開発者ポータルにサインイン。

ロードマップの概要

✅ v0.2.0 に含まれる機能  ·  🛠 予定

構築できるもの

• ヘルスアプリのバックエンド。 iOS アプリから HealthKit データをアップロードし、ユーザーは Oura、WHOOP、Withings のアカウントを接続します（ロゴを入れたホスト型の接続ページを経由）。アプリは 18 種類の API ではなく、1 つの API を読み取ります。
• 独自データを扱う AI エージェント。 自宅で実行し、デバイスを接続して、MCP を通じて睡眠、ワークアウト、心拍数の読み取り専用ビューをデスクトップエージェントに提供します。
• 参加者のウェアラブルデータを収集する研究。 監査用に生のペイロードを保持し、研究参加を取りやめた場合は完全に削除でき、分析側には FHIR R4 を出力します。
• 個人データのアーカイブ。 ヘルスケアアプリのエクスポートから、何年分もの履歴を 1 つのコマンドで読み込み、自分が所有するマシンに保管できます。
• 自分のデータを使う小さなツール。 ohs admin personal setup を実行すると、自分専用のインスタンスを用意できます。レシピを使えば、睡眠レポート、心拍数の推移、週間ダイジェスト、ダッシュボードなどを追加できます。それぞれ依存関係のない単一の Go ファイルで構成されています。

理由

ヘルスデータのソースは、それぞれ独自の形式を使っています。Apple Health は HealthKit サンプルごとに 1 行の JSON を送信し、心拍数は count/min、酸素飽和度は小数で表されます。Withings は日付をキーとする日ごとのアクティビティオブジェクトと、Unix エポックをキーとする日中の時系列データを送信します。日、デバイス、重複データの扱いもソースごとに異なります。

そのため、チームはプロバイダーごとにスクリプトを作成します。パーサー、テーブル、cron ジョブです。2 つ目のプロバイダー、最初の再送アップロード、バックフィルが必要な最初のマッパーバグ、あるいは保有するすべてのデータを削除してほしいという最初の依頼が来るまでは、それでうまくいきます。

Open Health Sync は、こうした層を一度実装し、面倒な部分まで適切に処理します。

機能

• 正規モデルは一つです。 量のサンプル、カテゴリのサンプル、睡眠セッションとフェーズ、ワークアウトとルート、栄養、日次サマリーを扱います。各レコードには出所を示す provider、source、device、ingested_at が含まれます。
• 量ごとに単位は一つです。 量の名称には UCUM 単位と LOINC コードが付与されます（データモデル）。心拍数は、ソース側の名称にかかわらず bpm です。
• 生のペイロードは保持されます。 すべてのアップロードと取得データは、ほかの処理より先に生データストア（ローカルフォルダーまたは S3 互換バケット）に保存され、書き換えられることはありません。マッパーを修正した後は、どのユーザーのデータでも生ファイルから再処理できます（方法）。
• UTC 日ではなく、現地の日付を使います。 日次サマリーは、レコードのタイムゾーンに基づく現地の暦日ごとに作成されます。プロバイダーが日次サマリーを送信しない場合は、サンプルから歩数、エネルギー、距離の合計を算出します。
• アップロードは常に冪等です。 Apple Health の各パートは、日付、バッチ、パート番号ごとに保存されます。同じバイト列を再送すると "duplicate": true とともに 200 が返されます。使用済みのキーに異なるバイト列が指定された場合は拒否され、上書きされることはありません。レコードはコンテンツハッシュで重複排除されます。
• 同期ボタンなしで常に最新の状態を保ちます。 プロバイダーの Webhook を受け取ると、定期処理より先に変更分だけを取得します。さらに、6 時間ごと（Webhook が届かない場合は1時間ごと）にバックアップ取得を行い、取りこぼしを検出します。GET /v1/users/{id}/freshness で、各ソースの最新状態を確認できます（バックグラウンド同期）。
• 処理状況を把握できます。 カバレッジレポートには、プロバイダー別、現地日付別のレコード数に加え、処理待ちのジョブ、リトライ後に保留されたジョブ、保存されなかった行が表示されます。
• 確実に消去します。 DELETE /v1/users/{id} は、ユーザーの生ファイルとすべての行を削除してからユーザーを削除します。ソフトフラグではありません。プロバイダーからレコード削除の通知（Oura、WHOOP、Strava）があった場合は、こちらでも削除します。?delete_data=true を指定してソースの接続を解除すると、そのソースがユーザーについて送信したすべてのデータ（レコード、生ファイル、同期履歴）が消去されます。また、DELETE /v1/users/{id}/data/{provider} でも Apple Health または Health Connect のデータを同様に消去できます。OHS_RETENTION_DAYS を設定すると、指定日数を超えた生ファイルと正規化データが削除されます。
• カテゴリごとに同意を管理します。 各ユーザーは、データカテゴリ（睡眠、心拍、位置情報、血糖値など）ごとに各ソースへの同意または拒否を設定します。同意されていないデータは保存前に破棄され、カテゴリへの同意を取り消すと保存済みのデータが削除されます。また、consent.granted と consent.revoked の Webhook でサーバーに通知します（ガイド）。
• 1回の呼び出しでユーザーアーカイブを取得できます。 GET /v1/users/{id}/archive は、アクセス要求やデータポータビリティ要求に応じて、1人のユーザーについて保持しているすべてのデータを1つの zip ファイルで返します（ドキュメント）。
• マルチテナント対応です。 サーバー用のテナント API キー（ohs_sk_）と、1人のユーザーのアプリまたはエージェント用の有効期間が短いスコープ付きユーザートークン（ohs_ut_、スコープは upload と read）を使用します。キーとトークンは SHA-256 ハッシュとして保存されます。
• 送信 Webhook に対応しています。 同期によるデータの書き込みや削除、ユーザーの消去、ユーザーに再接続を求める必要がある場合に、サーバーへ通知します。Standard Webhooks に準拠した署名が付与され、約28時間にわたって再試行されます。また、ヘルスデータの値がペイロードに含まれることはありません（ガイド）。
• AI エージェント向けの読み取り専用 MCP です。 ユーザーは、自分のデータに自分のエージェントを接続できます。使用するトークンで可能なのは読み取りだけです。
• バイナリと Postgres だけで動作します。 キューは Postgres（FOR UPDATE SKIP LOCKED）に格納されます。メッセージブローカー、キャッシュ、ワーカーフリートは不要です。api、collect、etl の各ロールは、1つのプロセス内でも個別でも実行できます。
• 小規模な環境で動作します。 4 GB の Raspberry Pi 5 で、専用に調整された compose オーバーレイを使ってスタック全体を実行できます。30日より古いサンプルは圧縮され、ディスク上のサイズが約7分の1になります。また、圧縮されたデータへの履歴の再インポートも高速です。
• オープンスタンダードを採用しています。 OpenAPI 3.1 ファイルで API を記述し、FHIR R4 Observations は公式 HL7 バリデーター（scripts/fhir-validate.sh）で検証されます。MCP はオープンプロトコルであり、信頼して使用する前に ohs doctor で設定を確認できます。
• スコアも、内部の AI もありません。 清潔で追跡可能なデータを提供するところまでです。その上にインサイトを構築してください。

データソースと出力

v0.2.0 では18のデータソースに対応しており、そのうち5つが新たに追加されました。Garmin、Eight Sleep、Xiaomi、アクティビティファイル、Bluetooth デバイスです。Amazfit と RingConn は Health Connect 経由で利用できます。 それ以外はすべて今後の予定です。ロードマップに掲載されていますが、まだ実装されていません。 各データソースの連携方法、ベンダープログラム、追跡課題については、こちらをご覧ください。 docs/connectors。

クイックスタート

Docker Compose v2.24以降に加えて、curl、jq、opensslが必要です。Composeは公開イメージghcr.io/soma-intelligence/open-health-sync（amd64およびarm64）を取得します。

git clone https://github.com/soma-intelligence/open-health-sync.git && cd open-health-sync
cp .env.example .env
sed -i.bak "s|^OHS_ENCRYPTION_KEY=.*|OHS_ENCRYPTION_KEY=$(openssl rand -base64 32)|" .env
docker compose --env-file .env -f deploy/docker-compose.yml up -d --wait
docker compose --env-file .env -f deploy/docker-compose.yml run --rm ohs doctor
docker compose --env-file .env -f deploy/docker-compose.yml exec ohs /ohs admin tenant create --name dev

ohs doctorは各チェック（設定、データベース、rawストア、公開URL、コネクター）についてokまたはfailの行を1行ずつ出力します。.envを変更したときは、再度実行してください。最後のコマンドはテナントAPIキーを一度だけ出力します。大切に保管してください。

export OHS=http://localhost:8080
export KEY=ohs_sk_...    # the key printed above

APIは127.0.0.1のみで待ち受けるため、以下の手順は同じマシン上で実行します。スマートフォンアプリ、プロバイダーのWebhook、または別のコンピューターから利用するには、外部からアクセスできるようにする必要があります。TLS対応のリバースプロキシを前段に配置するか、.envでOHS_HTTP_BIND=0.0.0.0を設定し、ネットワーク上でプレーンHTTPを使ってください。

デバイスやプロバイダーのキーがまだありませんか？ohs seed --demoを実行すると、6つの重複するソースからの合成データ90日分がインスタンスに追加され、試用できるデモAPIキーとリクエストが出力されます （docs/demo.md）。

docker compose --env-file .env -f deploy/docker-compose.yml exec ohs /ohs seed --demo

ポート8080が使用中ですか？.envでOHS_HTTP_PORTと、それに対応するOHS_PUBLIC_URLを設定してください（セルフホスティングを参照）。

エンドユーザーと、そのユーザーのアプリが保持するトークンを作成します。

USER_ID=$(curl -s -X POST $OHS/v1/users -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' -d '{"external_ref":"demo"}' | jq -r .id)
TOKEN=$(curl -s -X POST $OHS/v1/users/$USER_ID/tokens -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' -d '{"scopes":["upload"]}' | jq -r .token)

Apple Healthのパートを1つ（心拍数の測定値1件、gzip圧縮）アップロードします。

DAY=$(date -u +%Y-%m-%d); NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
printf '{"quantityType":"HKQuantityTypeIdentifierHeartRate","startDate":"%s","endDate":"%s","value":72,"unit":"count/min","sourceName":"Demo Watch","metadata":{"HKTimeZone":"UTC"}}\n' "$NOW" "$NOW" \
  | gzip | curl -s -X POST $OHS/v1/ingest/apple-health \
    -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/gzip" \
    -H "X-OHS-Type: HKQuantityTypeIdentifierHeartRate" -H "X-OHS-Day: $DAY" \
    -H "X-OHS-Batch: demo1" -H "X-OHS-Part: 0" --data-binary @-

処理が完了するまで待ち（pending_jobsが0になるまで）、正規化されたサンプルを読み戻します。

curl -s "$OHS/v1/users/$USER_ID/coverage" -H "Authorization: Bearer $KEY"
curl -s "$OHS/v1/users/$USER_ID/samples?type=heart_rate" -H "Authorization: Bearer $KEY"

マシンにohsバイナリをインストールします。 以下のインポートとMCPの設定では、コンテナーの外部でohsを実行します。お使いのシステムに合ったアーカイブを リリースページ から取得します（ohs_<version>_<os>_<arch>.tar.gz。osはlinuxまたはdarwin、archはamd64またはarm64です）。同じ名前のフォルダーに展開されます。

tar xzf ohs_*_linux_amd64.tar.gz
sudo install ohs_*_linux_amd64/ohs /usr/local/bin/ohs
ohs version

macOSでは、まず隔離フラグを解除してください：xattr -d com.apple.quarantine ohs_*_darwin_*/ohs。

既存の履歴を読み込みます。 iPhoneでヘルスケアアプリを開き、自分の写真をタップして、すべてのヘルスケアデータを書き出すを選ぶと、export.zipが作成されます。ユーザーのトークンを使って読み込みます（--dry-runを先に実行すると、送信されるデータの件数を確認できます）。

OHS_TOKEN=$TOKEN ohs import apple-health export.zip --url $OHS

記録、ルート情報付きのワークアウト、心電図は、一定のメモリ使用量で同じアップロードAPIを通じて処理されます。再実行しても、同じデータが二重にアップロードされることはありません。詳細はエクスポートのインポートを参照してください。

データはpgdataボリュームとrawボリュームに保存されます。docker compose ... downを実行しても保持されます。

仕組み

flowchart LR
  AH["Apple Health, Health Connect<br/>app upload, export import"] --> C
  CL["Withings, Oura, WHOOP, Fitbit,<br/>Polar, Strava, Suunto, Ultrahuman,<br/>intervals.icu, Dexcom, OMRON<br/>OAuth pull + webhooks"] --> C
  C["collect / ingest"] --> R[("raw store<br/>disk or S3")]
  R --> E["ETL<br/>normalize, dedup,<br/>units, local-day summaries"]
  E --> P[("Postgres<br/>+ TimescaleDB")]
  P --> API["REST API<br/>(OpenAPI)"]
  P --> MCP["MCP server<br/>(read only)"]
  P --> FHIR["FHIR R4<br/>Observations"]

1. 収集。 iOSアプリは、uploadスコープを持つユーザートークンと、ヘッダーX-OHS-Type、X-OHS-Day、X-OHS-Batch、X-OHS-Partを使って、HealthKitデータをgzip圧縮されたNDJSONパートとしてPOST /v1/ingest/apple-healthに送信します。クラウドプロバイダー（Withings、Oura、WHOOP、Fitbitなど）のデータは、Webhookが送信されたときに（変更分のみ）取得され、スケジュールに従って定期的にも取得されます。
2. rawペイロードの保存。 パートはまずrawストアに書き込まれ、その後、ジョブがPostgresにキューイングされます。応答にはrawキーと、パートが重複していたかどうかが含まれます。
3. 正規化。 etlロールが各行を標準モデルにマッピングし、単位を変換して重複を削除し、ソースとデバイスを関連付け、現地時間の日ごとのサマリーを集計します。
4. 提供。 読み取りにはテナントキーを使ったGET /v1/users/{id}/...を使用し、カーソルでページ分割します。MCP サーバーは同じデータを読み取り専用で参照します。

詳細：アーキテクチャ、APIガイド。

プロバイダーを有効にして、ユーザーが接続する

管理コンソールでOuraアプリのキーを貼り付けると、再起動なしでOuraが有効になります。その後、アプリが接続リンクを作成し、ユーザーに送信します。ユーザーはOuraを選び、次にWithingsを選んで、それぞれでアクセスを許可します。ohsがコードを交換し、許可情報を暗号化して保存し、バックグラウンドで履歴を取得して正規化します。コンソールに戻ると、パイプラインにデータの処理状況が表示され、ユーザーのページには各ソースが有効で最新であることが示されます。

_{このリポジトリで合成データを使って記録しました。コンソール、接続ページ、コード交換、暗号化された許可情報、バックグラウンドでの取得、正規化は実際のものです。プロバイダー側（同意画面とAPI）は、コネクターテスト用のテストサーバーが担っています。作成方法については、docs/demoをご覧ください。}

実際の動作を見る

これらはモックアップではなく、実際のキャプチャです。このリポジトリからビルドしたohs 0.0.1をTimescaleDBに対してネイティブに実行し（そのマシンでは8080が使用中だったため、ポート8088を使用）、connectors/applehealth/testdata/e2eにあるApple Healthのエンドツーエンド用フィクスチャを6つのパートに分けてアップロードしました。フィクスチャの値は合成データです。

サンプルは正規単位で返され、プロバイダーから送信された値はmetadataに保持されます（count/minはbpmになりました）。

日次サマリーはローカル日付ごとに導出され、カバレッジレポートで処理の完了状況を確認できます。

read スコープのみを持つユーザートークンを発行します（最長 30 日間有効です）。

curl -s -X POST $OHS/v1/users/$USER_ID/tokens -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' -d '{"scopes":["read"],"ttl_seconds":2592000}'

次に、デスクトップエージェントの mcpServers に ohs mcp（stdio）を追加します （インストール手順で入手したバイナリを使用します）。

{
  "mcpServers": {
    "open-health-sync": {
      "command": "/usr/local/bin/ohs",
      "args": ["mcp"],
      "env": { "OHS_MCP_URL": "http://localhost:8080", "OHS_MCP_KEY": "ohs_ut_..." }
    }
  }
}

ohs mcp はデータを保持せず、データベースも必要ありません。各メッセージをインスタンスの /mcp エンドポイントに転送します。ホストがループバックでない限り、OHS_MCP_URL には https を指定する必要があります。Streamable HTTP に対応するエージェントは、ベアラートークンを使って /mcp を直接呼び出せます。

0.2.0 以降、サーバーは 12 個のプロンプト（prompts/list）も一覧表示します。トレーニング、睡眠、回復について、先にデータを読み取って数値を示す質問が用意されています （プロンプト、プロンプトライブラリ）。同じガイダンスは、skills/open-health-sync にエージェントスキルとしても同梱されています。

ツール、引数、ページングについては、docs/mcp.md を参照してください。

データモデル

すべてのデータソースは、以下のレコードに対応付けられます（フィールドと単位についてはdocs/data-model.mdを参照してください）。

• QuantitySample：心拍数、歩数、SpO2 などの単一の数値測定値です。
• CategorySample：立位時間や月経量の記録など、カテゴリ別のイベントです。 月経周期は、読み取り時に /menstrual-cycles が月経量の記録から導出します （docs/menstrual-cycles.md）。
• SleepSession と SleepPhase：各夜の睡眠時間の内訳と、個々の睡眠段階です。
• Workout と RoutePoint：各ワークアウトの指標と、その GPS トラックです。
• NutritionLog：栄養素を含む食べ物または飲み物の記録です。
• ECGRecording と ECGVoltageSample：記録のメタデータと、その電圧トレースです。 データは保存されますが、まだ提供されていません。読み取りルートは今後実装予定です。
• HeartbeatSample：拍動ごとの（RR）間隔です。/rr-intervals と /hrv が、系列ごとに導出した HRV とともに提供します （docs/hrv.md）。
• DailySummary：プロバイダーから取得する、またはサンプルから集計するローカル日ごとの合計値です。
• Observation：多様なデータを扱うための汎用的なコード付き事実です。現時点では、これを書き込むコネクターはありません。

デプロイ

• 公開イメージで Compose を実行します。 クイックスタートと同様に、deploy/docker-compose.yml を使用します。OHS_VERSION でタグを固定してください（0.x の間は latest はありません）。セルフホストをご覧ください。
• Raspberry Pi 5。 オーバーレイ deploy/docker-compose.pi.yml を追加します（Postgres のバッファーを縮小し、メモリー制限を設定します）。Raspberry Pi 5をご覧ください。
• S3 の生データストア。 deploy/docker-compose.s3.yml を追加するか、OHS_RAW_STORE を任意の S3 互換バケットに設定します。S3をご覧ください。
• バックアップと復元。 scripts/backup.sh はデータベース、生データストア、スキーマバージョンを含む単一のアーカイブを書き出し、scripts/restore.sh はそれを復元します。CI では、すべてのプルリクエストでスタックを破棄して復元します。バックアップと復元をご覧ください。
• リリースバイナリ。 Linux と macOS 向けの amd64 および arm64 バイナリを、checksums.txt とともにリリースページで公開しています。Postgres と TimescaleDB はご自身で用意し、ohs doctor を実行してから ohs up を実行します（マイグレーション後にサーバーを起動します）。各アーカイブを展開すると ohs_<version>_<os>_<arch>/ohs が含まれます（インストール）。macOS バイナリはまだ署名されていません。xattr -d com.apple.quarantine で検疫フラグを解除してください。0.2.0 以降、イメージと checksums.txt は cosign で署名されています（リリースの検証）。
• ソースからビルドします。 Go 1.26 の場合、make build を実行すると bin/ohs が生成されます。Compose を使用するには、docker buildx が必要な deploy/docker-compose.build.yml を追加します。これを使用できない場合は、ソースからのビルドをご覧ください。

Open Health Sync と Terra、その他のヘルスデータ API の比較

Terra API の代替や、オープンソースのヘルスデータアグリゲーターをお探しですか？Open Health Sync とホスト型ウェアラブル API の比較を以下に示します。他社製品に関する情報は、各社のウェブサイトと料金ページから確認したもので、確認日は 2026-10-17 です。各行のリンク先には、移行方法を含む詳細な比較があります。

現在 Garmin や多数のデバイスに対応する必要がある場合、サーバーの運用を望まない場合、またはベンダーの SOC 2 および HIPAA に関する保証が必要な場合は、ホスト型 API を選んでください。データを自社のインフラストラクチャ内に保持する必要がある場合、ユーザーごとの料金体系が合わない場合、標準形式（FHIR R4、Open mHealth）での出力と、すべての生ペイロードの保持が必要な場合は、Open Health Sync を選んでください。各選択肢の比較については、ヘルスデータアグリゲーターの比較をご覧ください。

よくある質問

ステータスとロードマップ

最新リリースは v0.2.0 です。パイプラインを実行する管理コンソール、テナントとそのキーを管理する管理 API、テナントごとに保存するプロバイダーキー、Garmin、Eight Sleep、Xiaomi のコネクター、アクティビティファイルのインポート、ohs-bridge 経由の Bluetooth ヘルスデバイス、心電図の読み取り、自己申告、共有リンク、時間単位と日単位のサンプル統計、暗号化キーのオンラインローテーション、署名付きリリースが追加されました。変更内容：CHANGELOG.md。インストールとアップグレードに関する注意事項、および制限事項の全一覧：リリースノート。

既知の制限事項：

• 強制終了後、処理中だったジョブが再び処理されるのは、可視性タイムアウトの 10 分後です。
• インスタンスごとにデータベースは 1 つ、raw ストアは 1 つです。マルチリージョンレプリケーションには対応していません。
• FHIR R4 の一括エクスポート（$export）には、まだ対応していません。
• クライアント SDK は 0.1.0 で、まだパッケージレジストリには公開されていません。このリポジトリからインストールしてください。Kotlin SDK で Health Connect を読み取る機能は、今後対応予定です。

ホスト型ベータ版は、誰でも登録できる無料ベータ版です（容量は共有で、テストデータとデモデータのみ利用できます）：無料で登録。

今後の予定：コネクターの追加、標準出力（FHIR R4 リソースの追加）、Kotlin SDK での Health Connect の読み取り、続いて SMART on FHIR 経由での医療記録（EHR）の連携です。コネクターのリクエストフォームを含め、GitHub の Issue でのリクエストを歓迎します。

ドキュメント

• セルフホスティング：設定、イメージ、Raspberry Pi、S3、運用上の注意事項。
• セキュリティモデルとセキュリティ強化チェックリスト：保護対象と保護方法、実際のユーザーデータを扱う前にインスタンスで設定する内容。
• API ガイドと、信頼できる情報源であるOpenAPI ファイル。
• MCP サーバー：ツール、プロンプト、認証情報、デスクトップエージェントとリモートエージェント。
• FHIR R4 出力：ユーザーの記録を Observations として扱う方法、そのマッピングと制限事項。
• 送信 Webhook：イベント、署名、再試行、エンドポイントのルート。
• データモデル：単位を含む、すべての標準的な型と量の名称。
• クライアント SDK：Kotlin、Swift、 React Native、Flutter。
• サーバー SDK：バックエンド向けの TypeScript および Python クライアントと、 Postman コレクション。
• サンプルアプリ：SDK を使用して構築された iOS（HealthKit）、Android、React Native のアプリと、最初のユーザー登録から Webhook までをサーバー SDK で実現する Next.js ウェブアプリ。
• デスクトップブリッジ：ohs-bridge を使うと、コンピューターまたは Raspberry Pi から、Bluetooth 対応の健康管理デバイスや USB 接続の時計が記録したデータを送信できます。
• アーキテクチャ：役割、パイプライン、ストレージ、信頼性。
• コネクター：サポート対象および開発予定のソース、 Apple Health、 Withings、Oura、 WHOOP、Strava、 Polar、独自コネクターの作成。
• バックグラウンド同期：Webhook、バックストップ用の取得処理、データの鮮度。
• バックアップと復元：データベースと生データストアをまとめた 1 つのアーカイブと、その復元方法。
• 接続ページ：ユーザーがソースを接続してからアプリに戻るためのホスト型ページ。
• 管理コンソール：ブラウザーからパイプラインを実行できます。プロバイダーとそのキー、ユーザーと接続、同期および処理ジョブ、Webhook、API キー、監査ログを管理します。
• 管理 API：1 つのインスタンスを複数のチームで運用できます。HTTP 経由でテナントを作成し、キーを管理して、デモユーザーにデータを入力します。
• レシピ：個人用のセットアップと、自分のデータを使った小さなツール。
• RR 間隔と HRV：拍動間隔と、そこから算出される HRV。
• 月経周期：記録された経血量から算出される周期。予測は行いません。
• 時間タグ：病気や旅行など、データにコンテキストを与える期間。
• 自己報告：同期されたデータと並べて保存される、本人による評価。
• 共有リンク：ビューアーを内蔵した SMART Health Links。

貢献

Issue やプルリクエストを歓迎します。5 分から週末まで、3 つの方法で参加できます。

• ウェアラブルをお持ちですか？ make record PROVIDER=oura（またはその他のソース）を実行して、約 5 分でご自身のアカウントを記録できます。レコーダーはお使いのマシン上で匿名化し、CI では変更のたびにファイルを再生します。#60 でソースを選び、コネクターの記録をご覧ください。
• 初めての貢献に適した Issueを選ぶ：ドキュメント、レシピ、CLI コマンド、デプロイ用テンプレートなど、いずれも 1 つの PR で完了する範囲です。
• プロバイダーを追加する。 コネクターは自己完結型です。コネクターの作成から始めてください。

まず CONTRIBUTING.md と行動規範をお読みください。初めて貢献する方には、48 時間以内にレビューを行います。

make setup        # git hooks
make build        # bin/ohs
make test         # unit tests
make integration  # needs Docker (testcontainers)

貢献者

セキュリティ

脆弱性は、SECURITY.mdに記載の方法で非公開で報告してください。公開 Issue に健康データ、キー、トークンを絶対に貼り付けないでください。

ライセンス

サーバーは AGPL-3.0-only です。詳しくはLICENSEをご覧ください。Open Health Sync を変更してサービスとして実行する場合は、変更内容を公開する必要があります。sdks/ のクライアント SDK も同じライセンスの下で提供されています。