短く言うと： ヘルスケアアプリにおけるセキュリティは、4つの質問に順番に答えることで実現されます。「誰か？」 識別情報：OpenID Connectを通じて検証されたユーザー（患者、医療従事者、システム）。医療従事者の場合は、国の専門職識別情報も使用されます。パスワードの強度よりも、検証レベルが重要です。「何ができるか？」 認可：SMART on FHIRの構文で定義されたスコープを持つOAuth 2.0（2.1へ移行中）トークン。これは、患者の同意に基づき、目的と期間が定められ、データレイヤーで強制されます。「何をしたか？」 説明責任：患者が閲覧できるアクセスログと、組織のためのFHIR AuditEvent（AuditEvent）の記録。「データは保存時、転送時、バックアップ時に安全か？」 保護：暗号化、鍵管理、分離、テスト済みの復元。これらを支える基盤として、ISO 27001および27799、NIS2、HIPAAのセキュリティ規則、そしてヘルスケアデータ特有の脅威（内部不正閲覧、誤ったファイリング、ランサムウェア）への対策があります。
マップ
ヘルスケアアプリにおけるセキュリティとアイデンティティは、7つのレイヤーで構成されます。OpenID Connectや国のID、専門職IDによるアイデンティティ、OAuth 2.0やSMART on FHIRのスコープによる認可、あらゆる許可の源泉としての同意、アクセスログやFHIR AuditEventによる説明責任、暗号化やバックアップによる保護、ISO 27001、ISO 27799、NIS2、HIPAAの基準、そして患者主導の共有です。
| レイヤー | 標準または慣行 | 提供されるもの | ページ |
|---|---|---|---|
| 識別情報 | OpenID Connect、国のID（eIDAS、NHS login、GesundheitsID）、専門職ID（eHBA、CPS、UZI） | 検証された主体と保証レベル | SMART App Launch の解説 |
| 認可 | OAuth 2.0および2.1（PKCE必須、暗黙的およびパスワードグラントはなし）、SMART on FHIR スコープ（patient/Observation.rs）、非対称クライアント認証を備えたバックエンドサービス | ユーザー、患者コンテキスト、スコープにバインドされたトークン | SMART App Launch の解説、SMART on FHIR バックエンド |
| 同意 | FHIR Consent、目的および期間に基づく許可、取り消し、正当な理由とアラートを伴うブレーク・ザ・グラス | すべての認可の源としての患者 | 患者同意プラットフォーム、クリニックのアクセスリクエスト |
| 説明責任 | 患者が閲覧可能なレコードごとのアクセスログ、FHIR AuditEvent、改ざん防止ストレージ、保持期間 | 誰が、いつ、何を、なぜ見たか | 私の医療記録を誰が見ましたか？ |
| 保護 | TLS 1.2+、管理された鍵による保存時の暗号化、識別子のフィールドレベル暗号化、分離された環境、テスト済みの復元を備えたバックアップ | 機密性と可用性 | ISO 27001 vs ISO 27799 |
| 基盤 | ISO 27001 ISMS、27799 ヘルスケア管理策、NIS2対策、HIPAA セキュリティ規則、国のスキーム（HDS、DSPT、C5） | 病院、監査人、規制当局が期待するもの | 病院およびベンダー向けのNIS2、HIPAA vs GDPR |
| 共有 | SMART Health Links および Cards、検証可能なクレデンシャル | 患者主導の共有（リンクまたはQRコード）、取り消し可能 | SMART Health Links の解説 |
識別情報：パスワードよりも保証レベル
ヘルスケアアプリにおけるアイデンティティは、パスワードの強度よりも保証レベルに依存します。NIST IAL、eIDASのsubstantialおよびhigh、NHS login P9のようなアイデンティティ保証レベルは、登録時に個人がどれだけ強く本人確認されたかを示し、多要素認証やパスキーは個々のログインを説明します。臨床医は、退職時に無効化される専門職IDによって識別されます。
完全な記録を表示する患者アプリは、それがその患者と通信していることを知る必要があります。識別情報保証レベル（NISTのIAL、eIDASのsubstantialおよびhigh、NHS loginのP9）は、登録時に識別情報がどれだけ強く検証されたかを示します。認証強度（多要素認証、パスキー）は、各ログインを示します。病院や国のシステムでは、自己申告型のサインアップよりも、認識されたスキームからの検証済み識別情報がますます求められており、EUデジタルアイデンティティウォレットが受け入れられる手段となるでしょう。医療従事者にとっては、専門職の識別情報（および退職時の取り消し）が、そもそも医療従事者として行動できる人物を決定する記録システムとなります。
認可：同意がスコープになる
患者が管理する記録における認可は、患者の同意（例えば、クリニックが90日間、検査結果や病状を閲覧することを許可するなど）を、OAuthスコープとトークン上の患者コンテキストに変換します。これは、SMART on FHIRの構文（例: patient/Observation.rs）で記述され、すべてのリクエストでデータレイヤーで強制され、患者が同意を取り消すと無効になります。「ブレイク・ザ・グラス」は、別途監査されるパスです。
患者が管理する記録では、患者の同意がポリシーとなります。「このクリニックは、私の検査結果と病状を90日間読み取ることができる」といった具合です。システムはこれをOAuthスコープとコンテキスト（どの患者、どのリソース、どの操作）に変換し、クリニックのシステムが受け取るトークンに含め、データレイヤーのすべてのリクエストで強制し、患者が取り消したときに失効させます。SMART on FHIRのスコープ構文（patient/Observation.rs、patient/Condition.rs）がこのための共通言語です。より細かい制御のために、SMART v2には（カテゴリまたはコードによる）詳細なスコープが存在します。ブレーク・ザ・グラス（同意なしの緊急アクセス）は、別途監査されるパスであり、必須の正当な理由と患者へのアラートを伴いますが、デフォルトではありません。患者同意プラットフォームを参照してください。
説明責任：患者が読むログ
ヘルスケアアプリにおける説明責任とは、記録へのすべてのアクセス（誰が、いつ、何を、どの同意に基づいてアクセスしたか）が、患者がアプリで閲覧できる追記専用ログと、FHIR AuditEventの組織監査証跡に記録されることを意味します。ISO 27799ではこれを必須としており、可視化されたログは内部関係者による不正閲覧に対する最も強力な抑止力となります。
記録へのすべてのアクセスについて、誰が、いつ、何を、どの同意に基づいてアクセスしたかを、患者がアプリで読める追記専用ログと、セキュリティチームのための組織的な監査証跡（FHIR AuditEvent）に記録します。ISO 27799ではこれを医療情報に必須としており、GDPRの透明性の原則とEHDSの患者の権利も同様の方向性を示しています。内部不正閲覧に対する最も強力な抑止力は、可視化されたログです。私の医療記録を誰が見ましたか？を参照してください。
保護：エンジニアリングの基盤
ヘルスケアデータを保護するためのエンジニアリングの基盤は、あらゆる場所でのTLS、管理・ローテーションされる鍵による保存時の暗号化、直接的な識別子のための個別の暗号化またはトークン化、本番環境外での合成データを用いた分離された環境、管理者に対する多要素認証を用いた最小権限アクセス、シークレットと脆弱性管理、ランサムウェアに対する復元テスト済みの暗号化バックアップ、そしてGDPRおよびNIS2の期限内でのインシデント対応です。
どこでもTLSを使用し、最新の暗号化方式と、適切な場合はアプリでの証明書ピンニングを使用します。管理された鍵サービスとローテーションによる鍵を用いた保存時の暗号化。直接的な識別子に対する個別の暗号化またはトークン化。本番環境と開発環境の分離、本番環境外での合成データの使用。スタッフに対する最小権限のアクセス、共有アカウントなし、すべての管理アクセスに対する多要素認証。シークレット管理。開示を伴う依存関係および脆弱性管理。バックアップは暗号化され、復元テストが行われ、病院や研究所で繰り返し発生しているランサムウェア（2017年のWannaCry、2020年のデュッセルドルフ病院、2024年のChange HealthcareおよびSynnovis）から保護されています。インシデント対応は、72時間のGDPRおよび24時間のNIS2の期限を一つのランブックで対応します。
ヘルスケアデータ特有の脅威
ヘルスケアデータ特有の脅威には、知人の記録の内部関係者による閲覧、患者間の誤った記録、長期間にわたる過度に広範な共有、ヘルスケアデータを扱うアプリ内の広告SDK、AI機能への文書経由の注入、そして鍵、フォーマット、アクセスルールがスタッフやベンダーよりも長く存続しなければならない数十年にもわたる長期保存があります。
- 内部不正閲覧（知人や著名人の記録）：関係性に基づくアクセスと可視化されたログ。
- 誤ったファイリング（患者間での混同）：アクセス制御だけでなく、識別情報の照合と来歴。
- 過度に広範な共有：1年間「すべて」の権限を付与されたクリニック。適切なデフォルト値を持つスコープと期間。
- 広告SDKを含むアプリ：ヘルスケアデータを扱うものには、第三者のトラッカーを一切含めない。
- AI機能への文書経由の注入：コンテンツはデータであり、命令ではない（医療記録に対するRAG）。
- 長期保存：記録は何十年も残ります。鍵、フォーマット、アクセスルールは、スタッフやベンダーの変更に耐える必要があります。
Anpheros における取り組み
Anpherosは、アプリ用のPKCE付きOAuth 2.0とバックエンド用の非対称クライアント認証、あらゆるクリニックのアクセス源泉としての目的別・期間別同意、個人のアプリでの記録ごとのアクセスログ、保存時および転送時の暗号化、EUでのホスティング、広告SDKの不使用、そしてISO 27001および27799に準拠したISMSを適用しています。
Anpheros はこのマップを自身に適用しています。アプリにはPKCEを備えたOAuth 2.0、バックエンドには非対称クライアント認証を使用。クリニックのすべてのアクセス源として、目的と期間ごとの同意を設定し、取り消し可能で、サイレントなブレーク・ザ・グラスは排除。個人のアプリにはレコードごとのアクセスログを実装。保存時および転送時の暗号化、EUホスティング、広告SDKは不使用。ISO 27001に準拠したISMSに27799のヘルスケア管理策を統合。開発者サイトでは、認証、同意、セキュリティについて説明しています。
関連ページ
- SMART App Launch の解説
- 患者同意プラットフォーム
- 私の医療記録を誰が見ましたか？
- SMART Health Links の解説
- ISO 27001 vs ISO 27799
- 病院およびヘルスケアテクノロジーベンダー向けのNIS2
- プラットフォームセキュリティ（開発者サイト）
- 認証（開発者サイト）
ソース
- HL7 SMART App Launch
- IETF: OAuth 2.1 (draft)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: Procurement guidelines for cybersecurity in healthcare services
よくある質問
OAuth 2.1 は 2.0 とどう違うのですか？
OAuth 2.1 は、2.0 にセキュリティのベストプラクティスを統合したものです。すべてのクライアントでPKCEが必須となり、暗黙的グラントとパスワードグラントは削除され、リダイレクトURIは完全に一致する必要があり、パブリッククライアントのリフレッシュトークンはバインドまたはローテーションされる必要があります。SMART on FHIR v2 は、これらのほとんどをすでに要求しています。
ブレーク・ザ・グラスとは何ですか？
患者の事前の同意なしに、正当な理由を主張する医療従事者による記録への緊急アクセスです。これは稀であるべきで、記録され、レビューされ、患者に報告される必要があります。決してデフォルトのアクセスパスではありません。
患者はなぜアクセスログを見るべきなのですか？
不適切なアクセスに対する最も強力な抑止力であり、管理の最も明確な表現だからです。患者はどのクリニックがいつ何を見たかを確認し、取り消すことができます。ISO 27799とEHDSも同様の方向性を示しています。
別途監査システムが必要ですか？
アプリケーションが変更できない追記専用の監査証跡（FHIR AuditEventまたは同等物）と、ポリシーに従って保持される記録、およびそこから派生した患者向けのビューが必要です。それがプラットフォーム内の別のシステムであるか、保護されたストアであるかは、実装上の選択です。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →