ある 2024年の調査によると、主要なアプリストアには35万件以上のヘルスケア関連モバイルアプリが存在し、毎日約250件の新しいアプリがリリースされています。この飽和した市場は、 ヘルスケア向けモバイルアプリ開発に 求められるものを変えます。アプリの構築は始まりに過ぎません。チームには、機能を分類し、患者データを保護し、情報が同期されたかどうかを表示し、リリースが失敗したときに安全に復旧するための制御された方法も必要です。 2024年のヘルスケアアプリ調査 が明らかにしているとおりです。
コンプライアンスは、最後にチェックリストで確認するものではなく、リリースシステムとして扱うのが有効です。患者データがビルドに入る前に、各機能には規制ラベル、各データフローには患者が確認できる状態、各リリースにはテスト済みのロールバックパスが必要です。
目次
- ヘルスケアアプリが真の意味でリリースできない理由
- あなたのアプリに適用されるヘルスケア規制
- スマホ上で患者データをどう動かすべきか
- 患者が実際に確認できる臨床連携
- 安全でないヘルスケアビルドを防ぐリリースゲート
- ストア掲載情報とヘルスケアデータの宣言
- アドバイスが危害につながる場合のインシデント対応
- ストアの審査を待たずにWeb修正を配信する
- ビルド前にリリースパスを選ぶ
ヘルスケアアプリが真の意味でリリースできない理由
ヘルスケアアプリは、すでに飽和状態にある市場でユーザーの関心を引くために競い合っています。服薬リマインダー、症状日記、予約ツールなどを選ぶ患者は、数ある選択肢の中からどれを信頼すべきかを判断しています。その信頼は、単なる機能のリストだけで決まるものではありません。
ヘルスケアアプリは、初回のリリース後も毎日稼働し続けます。ストアの掲載情報は期待値を設定し、オンボーディングは使い道を説明し、アクセシブルな画面は多様なユーザーに対応し、プライバシーに関する記述は明確でなければなりません。プロダクト分析によってユーザーがどこで躓いているかを特定できますが、OSや臨床ワークフローの変化、バグへの対応など、継続的なメンテナンスは不可欠です。
リリース計画では、患者が目にする失敗（エラー）を考慮すべきです。サインインに失敗して復旧できなかったり、アンケートが保存されたかどうかが分からなかったりする場合、新機能を追加しても問題は解決しません。広く配布されたビルドに含まれる欠陥は、患者に直接的な影響を及ぼす可能性があります。 リリースの制御は、最初の設計会議において、ワークフローや機能のスコープと並んで検討されるべきです。
コンプライアンスをリリースシステムの一部として扱いましょう。すべての機能に規制ラベルを割り当て、データの同期状態を患者に示し、患者データがアプリに入る前にロールバックをテストします。これらの制御が、初期段階からのアーキテクチャやリリースに関する意思決定を形作ります。
歩数計と臨床アクションを推奨するツールは、バックログ上では隣り合っていても、求められる安全性は全く異なります。アーキテクチャを選定する前に、各機能を以下のいずれかに分類してください。 ウェルネス, ケアコーディネーション、または 医療機器ソフトウェアの可能性あり この分類を行うことで、リリース前に何をレビューし、何をテストすべきかをチーム内で明確に定義できます。
あなたのアプリに適用されるヘルスケア規制
実装前に、各機能に規制上のラベルを割り当ててください。ラベルには、その機能の役割、扱うデータの種類、および動作環境を含める必要があります。この決定をリリースプロセスの一部として扱い、適用されるルールを記録し、患者に機能の同期状態を表示し、患者データが関わる前にロールバック経路をテストしてください。なお、この表は計画を支援するためのものであり、法的または規制上の助言ではありません。
| ルール | 対象範囲 | トリガー | アプリに必要な計画 |
|---|---|---|---|
| HIPAA | 米国の対象機関およびビジネスアソシエイト | 作成、受信、保持、または送信されるPHI（保護対象保健情報） | アクセス制御、監査ログ、ビジネスアソシエイト契約、最小限の表示制限 |
| GDPR | EUまたはEEAの個人データを処理する組織 | 特別なカテゴリとして処理されるヘルスケアデータ | 法的根拠、必要に応じたDPIA、アクセス・訂正・消去への対応 |
| FDAのデバイスソフトウェアに関するポリシー | 米国のモバイル医療アプリ開発者 | ウェルネス機能ではなく、デバイスとみなされる可能性のあるソフトウェア機能 | ウェルネスとデバイスソフトウェアを分離し、デバイスに該当する場合は設計管理を適用する |
| 欧州ヘルスデータスペース 2025 | EUヘルスデータスペースにおけるウェルネスアプリ | EHRまたは国家システムとの連携に関する主張 | 連携の可否、相互運用可能なエクスポートのサポート、および自動共有の禁止を明示すること |
| グローバルな接続性 | 帯域幅の広い地域以外で使用されるアプリ | ネットワークアクセスとモバイルインフラの違い | オフライン耐性、低帯域幅での動作、ローカライズ、SMSまたはプッシュ通知へのフォールバック |
HIPAAへの対応では、まずアプリが対象団体（covered entity）またはビジネスアソシエイトに代わって保護対象保健情報（PHI）を扱うかどうかを判断します。扱う場合は、制御されたアクセス、適切な監査ログ、必要に応じたビジネスアソシエイト契約（BAA）、および業務に必要な情報のみを表示する画面設計を計画してください。重要なのは、アプリが健康に関するものかどうかではなく、データフローとアプリプロバイダーと組織との関係性です。開発チームは、 自閉症向けアプリをHIPAA準拠の観点で比較し、 プライバシーへの配慮がアプリの機能やデータ処理とどのように関連するかを示す具体的な例として活用できます。
GDPRにおいて、健康データは個人データの特別なカテゴリに分類されます。処理の法的根拠を特定し、データ保護影響評価（DPIA）が必要かどうかを判断した上で、ユーザーが自身のデータ権利を行使できる使いやすい方法を設計してください。これらの決定は、同意文言、アカウント設定、エクスポート、および削除の挙動を左右します。実装前にこれらをバックログに入れ、 規制コンプライアンスを理解するためのガイドを活用し、 管轄区域ごとの意思決定の構造化を支援します。
ソフトウェア機能に独自のデバイス・ソフトウェア・ラベルを付与してください。FDAの Device Software Functions and Mobile Medical Applicationsに関する ガイダンスは、開発者がその機能がウェルネス・ソフトウェアではなく、医療機器機能に該当するかを判断するのに役立ちます。ソフトウェアが診断、治療、またはケアの指示を行うといった主張を含め、意図された機能を検討してください。マーケティング上の修正だけで、機能の実態と製品説明の不一致を解消することはできません。
接続性も機能の範囲やリリース判断に影響します。グローバル展開するアプリでは、低速ネットワークへの対応、ローカライズ、オフライン動作、およびSMSや通知などのフォールバック方法を定義すべきです。保存や同期の保留中、失敗時、または完了時に患者に何が表示されるかを明確にしてください。同期ステータスが不明確だと、患者が「情報が医療チームに届いたかどうか」を不安に感じる可能性があるため、これらの状態を機能要件に含めてください。
症状アンケートのアップロードなど、特定の機能に対してこの表を適用します。データをラベル付けし、関与する地域や組織を特定した上で、その機能が医療上の主張（medical claim）に該当するかを判断します。該当しない行は削除しますが、決定内容は機能のレコードとして保持してください。機能、対象者、またはデータフローが変更された場合は、アップデートをリリースする前に再度ラベルを確認します。テスト済みのロールバックパスを用意しておくことで、変更が安全でない動作をした際にチームが明確な対応を取れるようになります。また、患者向けの同期状態を表示することで、機能の現在のステータスを明確にできます。
スマホ上で患者データをどう動かすべきか
患者データのフローは、デバイスに到達する前にレビュー可能であるべきです。各機能に対して規制ラベルを割り当て、データの流出先をすべて特定し、患者に対してデータがローカルにあるのか同期中なのかを表示します。そして、実際の患者データを使用する前に、ロールバック方法をテストしてください。
-
各フィールドにラベルを付ける。 ウェルネス設定、識別子、臨床値、または資格情報として分類します。症状の入力と通知設定では、情報漏洩のリスクが異なります。そのため、すべてのアプリデータを一括りにせず、各フィールドに対して個別に保存およびアクセスルールを割り当ててください。
-
すべての保存先をマッピングする。 メモリ、ローカルデータベース、iOS KeychainやAndroid Keystore、ログ、スクリーンショット、バックアップ、およびプッシュ通知のペイロードを含めます。アプリのデータベースが保護されていても、通知バナーに薬の名前が表示されてしまう可能性があるためです。
-
ローカルに保持するものを決定する。 デバイス内に留めるべきデータと、どのような条件や同意のもとで同期を許可するかを明確に定義してください。データ型や目的ごとに選択を行います。患者向けUIでは、単に「ヘルスケアデータの同期」というトグルで隠すのではなく、情報がローカルにあるのか、キュー待ちなのか、送信済みなのかといった同期状態を表示すべきです。
-
レコードをコピーすることなく、アクセス履歴を記録します。 誰がいつレコードを閲覧またはエクスポートしたかをログに記録しますが、ログ自体に臨床内容は含めないようにします。これにより、患者情報の制御不能なコピーを増やすことなく、監査用のアクセスログを提供できます。
-
エクスポートと削除のテストを実施します。 ログインと同様に、これらも慎重に検証してください。アカウント削除後に電話のバックアップから情報を復元できないことや、クリニックで共有するタブレットにおいて、前の患者のセッションが次の利用者に残っていないことを確認します。
機密情報には、通信時および保存時の暗号化を適用してください。 アプリ暗号化の実践ガイド データの保護場所に関する意思決定をサポートします。セッション時間を短く設定することで、放置されたデバイスへの露出を抑えられます。生体認証は再アクセスを簡略化できますが、アカウント認証の代わりではなく、その上に構築されるべきものです。
Capacitor チームは、クローズドなエンタープライズ向けプラグインに頼らずにネイティブ機能を利用できます。Capgo は、ストレージ、認証、生体認証などをカバーする Ionic enterprise プラグインのオープンソース代替手段を提供しており、以下が含まれます。 native-biometric, data-storage-sqliteや social-login. 各プラグインが機密値をどのように扱うか、機能のデータラベルおよび脅威モデルに照らしてレビューしてください。
最終承認の前に、フロー全体を1つのページにまとめます： ソースフィールド、保存先、受信者、保持期間、および削除パス. 臨床値を含むクラッシュログや、削除後にデータを復元してしまうバックアップなど、失敗するケースも含めてください。リリース前にロールバックパスを定義し、患者データを使用せずにテストを行います。フローの中で「誰がデータを受け取るのか」「患者がどのようにデータを削除できるのか」を特定できない場合、その設計は不十分です。
患者が実際に確認できる臨床連携
FHIRクライアントであることは、患者が「何がデバイスから送信されたか」を理解していることと同じではありません。製品がヘルスケアシステムに接続できていても、共有が承認されたのか、レコードが届いたのか、あるいは情報がローカルに残っているのか、ユーザーが確信を持てない場合があります。
この WHO SMART Guidelinesのアプローチは、 標準に基づいた基盤を提供します： HL7 FHIR 患者中心のデータ交換をサポートし、 ICD-11 一貫した臨床用語をサポートし、 Clinical Quality Language (CQL) 計算可能な意思決定支援をサポートします。これらの標準規格を活用することで、個別の統合ごとに独自のデータモデルに依存することを避けられます。
Capacitor や Ionic アプリでは、ドメインモデルをトランスポートロジックから分離してください。臨床リソースを FHIR プロファイルにマッピングし、OAuth 2.0 や OpenID Connect でアクセスを認可します。また、断続的な接続環境に備え、明示的な競合解決ルールを定義しましょう。WHO が提唱する Android 向けの SDK パターンには、ローカルストレージ、データアクセス、検索、同期 API に加え、FHIR Structured Data Capture の質問票への部分的なサポートが含まれています。これは、オフラインで質問票を収集し、後で同期させるための有用なモデルです。
インターフェースでは、それらを一つの緑色のチェックマークにまとめず、以下の3つの状態を区別すべきです：
| ステータス | 意味 | 画面の表示内容 |
|---|---|---|
| 互換性 | このレコード形式のエクスポート形式が存在する | 名前とバージョンの形式 |
| 接続済み | EHRが患者の認証情報を承認しました | アカウント、付与されたスコープ、最終確認時刻 |
| 転送済み | この特定のペイロードはEHRに受理されました | タイムスタンプと受領証。サイレントリトライではなく、失敗を表示すること |
これらのステータスは互換性がありません。「Compatible（互換あり）」はフォーマットが存在することを意味し、アカウントが接続されたことを意味しません。「Connected（接続済み）」は認証が成功したことを意味し、特定のレコードが転送されたことを意味しません。「Transferred（転送済み）」は、受信システムがペイロードの受理を確認した場合にのみ表示すべきです。
オフライン動作は単なるキャッシュ機能ではなく、臨床的な整合性の問題です。タイムスタンプ、ソースデバイス、同期状態、バリデーションエラー、および値がローカルで入力されたのかサーバーによって確認されたのかを保存してください。EHRがレコードを拒否した場合は、何が失敗したのか、患者が次に何をすべきかを表示します。サイレントリトライは情報の最新性を隠してしまい、臨床医が「実際には届いていないデータ」を見ていると誤認させる原因になります。
EUの2025年欧州ヘルスデータスペース（EHDS）規制により、実用的な製品要件が追加されました。ウェルネスアプリは、EHRや国のヘルスシステムに接続できるかどうかを説明し、必要に応じて相互運用可能なエクスポートをサポートする必要があります。相互運用性は自動送信を許可するものではありません。データの共有には同意が必要であり、以下の規制に従って明示された目的に限定されなければなりません。 欧州ヘルスデータスペース規制. 同意の受領証、項目レベルの共有コントロール、エクスポートのプレビュー、およびエラー状態の可視化を提供してください。複数の個人健康機能を組み合わせた製品を評価するチームは、以下のようなものを含みます。 症状と周期のトラッキングを組み合わせたアプリ。互換性、接続性、および確認済みの転送という区別を同様に適用できます。
臨床医は、画面または監査トレイルから次の3つの質問に答えられる必要があります： 何が共有されたか、いつ共有されたか、そしてこの端末にのみ残っているデータは何か？
安全でないヘルスケアビルドを防ぐリリースゲート
リリースゲートでは、各機能の規制ラベルをテスト、担当者、およびロールバックの判断に紐付けるべきです。機能テストだけでは、ヘルスケアアプリの安全性や使いやすさを証明できません。211のヘルスケアアプリを評価した調査では、平均総合スコアは 5点満点中 3.02点、プライバシーとセキュリティの平均は 2.21、相互運用性の平均は 1.75 (ヘルスケアアプリの評価調査）でした。これらの調査結果をコンテキストとして活用し、アプリがサポートするワークフローの合格基準を設定してください。
| ゲート | しきい値 | 根拠 | リリースがブロックされる理由 |
|---|---|---|---|
| システムユーザビリティスケール | 最低でも68以上 | 実際のタスクを行う患者と臨床医 | 一般的なベンチマークを下回る |
| プライバシーとセキュリティの基準 | 調査平均の2.21/5を上回る | セキュリティテストとログレビュー | 脆弱な保護と処理を特定 |
| 相互運用性の動作 | 調査平均の1.75/5を上回る結果 | エクスポート、同意、同期失敗のシナリオ | 接続要求が実際の転送を上回る可能性 |
| 患者の識別情報 | 未解決の欠陥ゼロ | 誤ったチャートのテストケース | レコードの不一致は安全上の問題 |
| 投薬、同意、または送信に関する事項 | 未解決の欠陥ゼロ | シナリオベースのテスト | 誤った指示や共有は危害を及ぼす可能性がある |
| 同期とクラッシュ | 前回の安定版との比較 | OSバージョン別の失敗率 | リグレッション発生時は一時停止またはロールバックが必要 |
以下を設定: System Usability Scale (SUS) の下限を68に設定. テストを開始する前に、ケアに最も影響を与える可能性が高い2〜3つのワークフローを選択し、タスク完了の閾値を定義します。アクセシビリティ、低速ネットワーク、オフライン、およびセキュリティテストも含めてください。デバイスおよびOSバージョンごとに、離脱率、バリデーションエラー、レイテンシ、クラッシュフリーセッション、同期失敗、およびタスク完了率を追跡します。
すべての機能において、患者データを扱う前に、患者から見える同期状態とテスト済みのロールバックパスが必要です。「待機中」「送信済み」「拒否」「確定」といったステータスにより、レコードが目的地に届いたかどうかが明確になります。ロールバックの基準はリリースごとに具体的に定め、どの失敗でロールアウトを停止するか、誰が前回の安定版への復元を承認できるかを明確にします。実用的な アプリ品質保証プロセスにおいては、各テスト結果をリリースゲートおよび責任者に関連付けてください。
承認内容は平易な言葉で記録します: SUS責任者、ゼロハーム欠陥責任者、タスク完了責任者、および同期失敗責任者. ゲートにオーナーがいない場合や、パスした結果がない場合は、機能をリリースしないでください。臨床的なアドバイスのリスクを評価するチームは、以下を確認できます： AI利用時における臨床責任.
ストア掲載情報とヘルスケアデータの宣言
ストアの宣言内容はリリース記録の一部として扱い、各機能に割り当てられた規制ラベルと一致させてください。アプリの挙動とストア掲載情報が一致しないと、ユーザーと審査員の双方に混乱を招きます。
-
App Store Connectのプライバシー詳細を完了させてください。 ヘルスケアやフィットネスデータを含む、アプリが収集するすべてのデータ型について、プライバシー・ニュートリション・ラベルの質問に回答してください。それらのデータを受け取るサードパーティSDKも考慮に入れる必要があります。
-
Google Playのデータセーフティフォームを完了させてください。 データ型、利用目的、共有の挙動を一致させ、アプリのヘルスケアに関する宣言が実際の機能と整合しているか確認してください。
-
アプリ内でアカウント削除機能を提供してください。 アプリでアカウント作成が可能な場合は、削除機能を容易にアクセスできるようにし、ローカルデータ、バックアップ、および連携サービスへの影響をテストしてください。
-
医学的な主張と機能ラベルを一致させてください。 ウェルネス機能は、疾患の診断や治療を行うものとして記述すべきではありません。画面上のコピーだけでなく、意図した機能に照らしてストア掲載情報を確認してください。
-
レビュアーにアプリ内での安全なルートを提供しましょう。 実際の患者データを使用せずに、同意画面、エクスポートフロー、およびエスカレーションパスへ到達する方法を説明してください。レビュー用の認証情報や指示は、本番用アカウントとは別に管理してください。
各宣言のコピーに日付を付与し、リリース記録と共に保管してください。機能が変更された際は、開示事項とレビュー用メモを同じ変更セット内で更新してください。そうしないと、ストア上の説明とアプリの実装でデータフローに乖離が生じる可能性があります。
アドバイスが危害につながる場合のインシデント対応
コンプライアンスをリリースシステムの一部として扱ってください。患者データを取り扱う前に、各機能に規制ラベルを割り当て、データ同期の状態を患者に表示し、以前のアドバイスを復元する方法をテストしてください。インシデント計画には、誰がロールアウトを停止できるか、患者に何が表示されるか、そしてチームが正常なバージョンをどのように復旧させるかを明記しておく必要があります。
患者が不確実性を認識できるか、推奨理由を理解できるか、臨床ガイダンスを見つけられるかを確認するために、現実的な訓練を実施してください。アドバイスの責任の所在が明確であること、および機能が臨床医のワークフローに適合していることを確認してください。エスカレーションパスがないまま確信的な回答を出す症状チェッカーは、緊急診療の受診判断に影響を与える可能性があります。
リリース前に、アプリが不確実性をどう伝えるか、緊急時にどうエスカレーションするか、そしてどのように有人レビューへ回すかを定義してください。アクセシビリティと多言語対応を考慮したフローのテストも不可欠です。また、監査ログを保持し、各回答を生成したモデルや臨床ルールのバージョンを記録してください。この記録により、チームは患者がどの助言を受け、どのリリースによってそれが生成されたかを特定できるようになります。
テスト環境での正確性は、安全性の一部に過ぎません。リリース後は患者の行動をモニタリングしてください。助言によってエスカレーションが遅れていないか、フローを中断していないか、ルールの変更が推奨事項に影響を与えていないかを確認します。助言の変更はリリースイベントとして扱い、規制ラベルの割り当て、同期状態の可視化、および以前のバージョンへ戻すためのテスト済みパスを用意してください。
運用ルール: 永続的なフォールバックを用意し、新しいバージョンが患者に届く前に、以前の助言を復元できることをテストしてください。
Webベースの臨床ルール、プロンプト、またはヘルプ画面の場合、チームがインシデントを調査している間、段階的なデリバリー（progressive delivery）によって影響範囲を限定できます。ただし、Native Buildの変更や規制対象となる挙動の変更には、引き続き適切なストアと規制プロセスが必要です。以下の4つのフィールドを持つインシデントカードを作成してください： トリガー、通知先担当者、患者向けメッセージ、および以前の助言を復元するための手順。これを使用して モバイルアプリ・インシデント対応ガイド を、訓練を実効可能な手順へと昇華させます。
ストアの審査を待たずにWeb修正を配信する
変更内容に基づいてリリースレーンを選択します。同意文、アンケートのレイアウト、またはエスカレーション画面のコピー修正などは、 JavaScript、HTML、CSS、静的アセット. Native code、新しいデバイス権限、規制対象のデバイス動作の変更には、引き続きアプリストア経由の適切な手続きが必要です。トレードオフはスピードとスコープです。対象となる Web の変更は迅速に配信できますが、ネイティブおよび規制対象の変更には、それぞれ該当する審査が必要です。
Capacitor と Ionic のチーム向けに、Capgo は、ストア審査を待たずに、対象となる JavaScript、CSS、アセットの変更を数分で本番アプリに配信します。ネイティブの変更は引き続きストアを経由します。また、Capgo はクラウド上で署名済みの iOS および Android ビルドを作成し、ローカルで運用する Mac を必要とせずストアへの提出もサポートします。
各アップデートを管理されたリリースとして扱ってください。動作確認済みの bundle を常に利用可能にし、新しい bundle を一部のデバイスに割り当て、採用状況と失敗シグナルを短い間隔で確認します。ロールアウトを一時停止する失敗しきい値を設定し、本番、臨床医のベータテスト、プルリクエストのプレビューには別々の channel を使用してください。 OTAアップデートのガイド 対象となる Web アセットをネイティブリリースとは別に配信する方法を説明します。迅速な配信が変えるのはリリースのタイミングであり、各機能へのラベル付け、患者への同期状態の表示、患者データを扱う前のロールバックテストの必要性がなくなるわけではありません。
Live UpdateプラットフォームはHIPAA認証ではありません。アップデートのペイロードに健康データが含まれる可能性がある場合は、データフローや契約要件、および事業提携契約（BAA）が必要かどうかを確認してください。どの変更カテゴリが迅速な配信の対象となるかを定義し、規制対象となる医療機能については適切なレビュープロセスを維持してください。
実用的なルール： 修正内容がネイティブ機能や規制対象の動作に影響を与えず、Webの code のみを変更する場合は、数日間のレビュー待ちで患者に不具合のあるbundleを使い続けさせるのではなく、Web-code レーンを使用してください。。必要な変更にはStoreレーンを使用し、両方のレーンに対してテスト済みのロールバックパスを用意してください。
ビルド前にリリースパスを選ぶ
各機能をラベル付けし、リリースレーンを選択し、ゲートの責任者を明確にできれば、チームはビルドの準備ができています。洗練された最初の画面では、これらの決定の代わりにはなりません。これらは、患者のデータがシステムに入る前に、適切なレビュアー、テスト、およびロールバック制御が整っているかを判断するためのものです。
まずは3つのラベルから始めましょう：
- 機能ラベル： ウェルネス、ケアワークフロー、またはデバイスソフトウェアの可能性。
- アップデートレーン： 同意テキストやレイアウト修正などの対象となるWebアセット用チャンネル、またはネイティブおよび規制対象の変更用のStore申請。
- リリース責任者： 各ゲートには責任者を指名し、SUS 68以上、かつ患者の身元、投薬指示、同意、またはデータ転送に関する未解決の欠陥がゼロであることを条件とします。
Capacitor または Ionic アプリの場合、患者データを扱う前に、非臨床画面をステージング用の live-update チャネルにデプロイし、ロールバックの練習を行ってください。その後、小規模な本番チャネルから開始して同期状況やクラッシュ率を監視し、インシデント発生時に即座に対応できる責任者が明確な場合にのみ、配布範囲を拡大します。
この規律を守ることは、膨大な機能リストから始めるよりも有用です。これにより、臨床ワークフローがリリースシステムに依存する前に、リスクの低いコンテンツでリリース体制のテストが可能になります。
Capgo は、対象となる JavaScript、CSS、およびアセットの修正に対する Live Update を提供するほか、iOS および Android 用のクラウドベースの Native Build も提供します。これにより、チームは Web の修正とストアへのリリースを別々のパスで管理できます。患者データがアプリに入力される前に、段階的なロールアウトとロールバックの練習を試してみてください。その後、 Capgo を訪問して Capacitor の Live Update および Ionic リリースツールがワークフローに適合するか確認してください。
