B2B: ICUモニターへの新しい臨床パラメータの設計：RFPのUI、安全シナリオ、リスク対応ドキュメント
プロジェクトについて
プロジェクト概要
役割: Philipsにおけるシニアプロダクトデザイナー／ユーザビリティエンジニア（UX経験10年以上）
臨床／エンジニアリングの要件を、リスク＋臨床＋エンジニアリングがレビューできるエンドツーエンドのユーザーワークフローに翻訳しました。
RFP固有のシナリオの差分（SpO₂から受け継がれるものに対して、本当に新しいものは何か）を定義しました。
プロダクト: Philipsのベッドサイド患者モニタリング（IntelliVue/Deltaプラットフォームの機能）
注力領域：
SpO₂モニタリングのワークフロー（センサーの装着、ソース／ラベルの選択、アラーム設定）
連続体温（ContTemp）のワークフロー（スマートケーブル＋プローブ、2点間の温度差）
SpO₂のプレスモグラフ信号から導かれるパラメータとしてのRFP（Respiration From Pleth）（成人／小児のみ）
Deltaプラットフォーム全体の一機能としての患者モニタリング
目的：明確なユーザーワークフロー（使用シナリオ）を設計し、リスク評価（uFMEA）とスタディ計画のために安全に関わるユーザータスクを特定することで、新規／更新された機能が安全で、理解可能で、テスト可能であることを保証すること。
私は、事実と仮定を切り分けるために、構造化されたステークホルダー・ディスカバリーを実施しました：
臨床、リスク、エンジニアリング、機能オーナーと連携して、エイジド値の概念、アラームのアプローチ（標準のDelta上限を継承する ）、そしてRFPは有効／無効を切り替えられる が、アラーム上限はRRのソースごとに分けられない（上限はRRパラメータ全体に適用される）ことを確認・検証しました。また、他のRRソースのより高い上限に対して、RFPの70 rpmの上限（現実の安全／ロジック上のエッジケース）にも注意を促しました。
ユーザーリサーチとインサイト
私はまず仮定を事実から切り分けることから始めました。ステークホルダーからの初期メモは方向性としては正しかったものの、言い回しが一貫していませんでした（例：「エラー%」対「rpm精度」、「age値」対「H値」）。私は言葉を、正式なレビューに耐えるものに収束させました：エイジド値 、rpmで表される精度 、そして標準のDeltaの振る舞いに沿ったプラットフォームアラームの継承。
次に、重複させてはならないものをマッピングしました 。SpO₂はすでに物理的なワークフロー（センサー選択、センサー装着、ケーブル接続、数値確認）をカバーしているため、RFP用に完全な2つ目のセットを作ることはノイズであり、安全レビューを希薄化させます。代わりに、私はRFPをすでにカバーされていない、明確で安全に関わるUIの振る舞いの最小セットにスコープしました。
これらのシナリオを起草しながら、シナリオの妥当性と後のUFMEAの質を損なうであろう、まさにそのUIの不確実性にフラグを立てました：
Neonate（新生児）を選択したとき、正確に何が起こるのか（ダイアログ、無効状態、自動オフ、フィードバック）？
RFPは正確にどこでオン／オフされるのか（パラメータメニュー、サイドバーのトグル、コンテキストメニュー）、そして成人／小児向けのデフォルトオンはどのように表現されるのか？
特に両方が利用可能なとき、どの呼吸ソース（ECG対プレス由来）が現在アクティブなのかを、UIはどうやって間違えようもなく示すのか？
設計上の依存関係を解消するために、私は観察可能な振る舞い にのみ焦点を当て、実装の詳細には踏み込まない、的を絞ったステークホルダーへの質問（UIアーキテクト／SME向け）を用意し、シナリオがレビューで擁護できるものであり続けるようにしました。
コンセプト化
ユーザーリサーチをもとに、私たちはICU Angelを次のような統合インターフェースとして構想しました：
アルゴリズムによるグラフを用いてARDSの進行を追跡する。
あらゆる重大な変化について、医療従事者にリアルタイムでアラートを出す。
既存の病院システムとシームレスに統合し、患者データを自動で取り込む。
ワイヤーフレーミング
私たちは、次のことを示すローファイのスケッチを作成しました：
ステージベースのビジュアライゼーション：各ARDSステージ（リスクあり、重度など）を色分けし、素早く認識できるように。
アラート管理：緊急アラートを最前面に表示する階層的なシステムで、アラーム疲労を最小化。
服薬追跡：投薬の時刻と用量を確認するための専用セクション。
プロトタイピングとユーザーフィードバックループ
次に、私は入院や服薬スケジューリングからリアルタイムのバイタルモニタリングまで、中核となるワークフローをシミュレートするインタラクティブなプロトタイプを開発しました。
実地テスト：ICUスタッフと研究責任者が、構造化されたセッションでこれらのプロトタイプをテストしました。
主なフィードバック：医師はカスタマイズ可能なアラートしきい値を望み、看護師はよりシンプルなデータ入力フォームを求め、ITスタッフは堅牢なデータセキュリティの枠組みを主張しました。
背景と課題の提示
Philipsは、臨床的に意味があるが、ICUの状況下では誤用しやすい機能を導入または改良しようとしていました：
ユーザーは、中断、アラーム疲労、認知負荷、時間的プレッシャーのもとで操作します。
新しいパラメータ（RFPなど）は技術的には「SpO₂の一部」かもしれませんが、それでも新しいUIの振る舞いと新しい故障モード（例：初回値までの遅延、新生児の制限、共有アラーム上限の振る舞い）をもたらします。
ContTempのスマートケーブルのワークフローでは、リスクには誤ったアクセサリー選択、不適切なセットアップ、切断／廃棄時の感染管理の失敗が含まれます。
ギャップは「画面の欠如」ではありませんでした。ギャップは運用上の明快さの欠如でした：
ユーザーは何をし 、何を見て 、何を判断し 、何を確認するのか、そしてそれはどこで間違いうるのか？
私が徹底させた設計上の決定
継承の境界：物理的なセットアップはSpO₂のシナリオの下に留まり、RFPのシナリオはセンサーチェーンがすでに接続された後にのみ始まる。
期待値の管理：RFPは後から表示されることが許容される。シナリオは、遅延した利用可能性を明示的にエラーではなく正常として扱う。
エイジド値の言葉遣い：「エイジド値」という用語を正式に使用した（既知の経過時間を持ちながらも表示される値）。
アラームの整合：デフォルトのアラーム動作は、上限を含めて標準のDeltaアラームから継承される。RFPは別個の「アラームシステム」を導入しない。
新生児の制限は安全の境界である：ロックアウトは隠れたルールではなく、UI上で明示的でなければならない。
成果
この仕事は「アルゴリズムのアドオン」を、定義された安全の境界を持つレビュー可能なインタラクションデザインへと変えました。RFPやDeltaデバイスのアドオンを抽象的に議論する代わりに、ステークホルダーは今や次のことを検証できるようになりました：
臨床医が何を見て、いつ見て、システムが彼らに何をすることを期待しているか
新生児の制限が、テスト可能な形でどのように実施されているか
矛盾するUI状態を生むことなく、RFPが既存のアラームおよび呼吸ソースの振る舞いにどう収まるか
ベッドサイドモニターにアドオンデバイスを行き来させる場面のために設計された14以上のシナリオが、データ損失、患者リスク、管理上の問題のリスクを排除しました。
