医療費請求の再考:UI/UXケーススタディ

公開: 2022-07-22

医師から医療費請求情報を収集し、それを保険会社に送って支払いを行う会社であるAll Data Healthは、2020年後半に請求エクスペリエンスを再設計するために私を雇いました。当時、医師のクライアントは紙のスーパービルに記入することに慣れていました。診断、手順、および保険金請求コードが含まれます。

クレームプロセスの速度と精度を高めるために、会社のリーダーは、既存の医師ポータルを介してオンラインのスーパービル(e-superbillと呼ばれる)を提出するように医師を誘惑したかったのですが、医師は抵抗しました。 彼らは引き続きAllDataHealthに紙のフォームを郵送し、請求スペシャリストが保険会社に請求を提出する前にデータを手動で入力しました。

医師は新しいテクノロジーに警戒していることで有名です。 セキュリティ、生産性、および手頃な価格の懸念により、医師は使い慣れた方法やツールにしがみついています。 私の使命は、既存の医療費請求ソフトウェアを再考し、医師が紙のスーパービルを喜んで放棄できるようにユーザーフレンドリーにすることでした。

アプローチ:調査、ワイヤーフレーミング、プロトタイピング

多くの消費者向け製品に取り組んできたUI/UXデザイナーおよびアートディレクターとして、私はデジタル体験の人間化を専門としています。 3か月以上にわたって、All Data Healthと協力して課金システムを更新し、それに付随するコンポーネントライブラリとスタイルガイドを作成しました。

私はいつものように、調査とブレインストーミングから始めました。 次に、情報アーキテクチャを作成し、ワイヤーフレームを使用して忠実度の低いプロトタイプを設計してから、忠実度の高いプロトタイピングに移行しました。 私はクライアントの開発者チームと緊密に協力し、進捗状況を毎日更新しました。

スーパービルの紙版。フォームの上部には、名前、住所、生年月日、保険情報などの患者情報のフィールドが含まれています。その下には、オフィス訪問、予防訪問、日常的な手順、診断、カウンセリング、延長、往診、予防接種など、多くのカテゴリを含む4列の情報があります。各カテゴリの下にはアイテムのリストがあり、それぞれにコードがあり、その横にチェックボックスがあります。このページには約200のアイテムがあります。
AllDataHealthが使用した元のスーパービル。 医師は当初、オンラインバージョンへの移行に抵抗していました。

UXリサーチ:医師の働き方の特定

すべてのプロジェクトは、ユーザーを理解することから始まります。 まず、All Data HealthのCTO兼マネージングディレクターに会い、医師と会社のデータ入力スペシャリストのニーズを学びました。 私はマドリッドのカルロス3世大学でジャーナリズムの学位を取得し、ジャーナリストとして4年間働いていたので、この種の事実調査に長けています。

一緒に、3つの詳細なペルソナを作成しました。

  • ソロ博士:この医師は大きな組織で働いており、同じ一握りの診断と手順をフォームに記入することがよくあります。 e-superbillでは、彼は最も一般的に実行される手順に簡単にアクセスできる必要があります。 ソロ博士は病院のフロアと医療施設の間を移動するのに多くの時間を費やし、多くの場合コンピューターにアクセスできないため、フォームはモバイルフレンドリーである必要があります。
  • オフィス博士:この医師は小さなオフィスを運営しており、通常は看護師や助手と一緒に働いています。 彼のアナログワークフローでは、アシスタントは患者情報を使用してフォームを準備し、訪問中に実行された手順を入力するだけで済みます。
  • チームを持つ博士:この医師は中小企業の経営者に似ています。 彼女は診療所を運営し、追加の医師を雇用しています。 スタッフドクターが書類の一部に記入しますが、Dr。With a Teamは、最終的に保険会社からの支払いを回収する責任があります。

顧客のペルソナと、請求UIを操作する可能性が最も高い時期を詳しく説明したホワイトボードのスクリーンショット。ペルソナはテーブルのように配置され、一番上の行は1日のさまざまな部分に名前を付けています。最初の列には、Dr。Solo、Dr。Office、Dr。WithaTeamの3つのペルソナが表示されます。さまざまな列に付箋が表示されます。
Miroを使用して、すべてのDataHealthユーザーのペルソナを作成しました。 このホワイトボードは、スーパービルに記入するときに実行されるタスクを示しています。

機能分析:ベストプラクティスに注目する

All Data Healthの請求UXは、ユーザーが時間を節約できると見なすことができるほど直感的である必要があること、または少なくとも請求に時間がかからないことを認識している必要があることを知っていました。 大規模なプロジェクトを管理可能なタスクに分割し、TurboTaxのWebサイトのいくつかの側面に触発されたプログラムを調べました。

  • これにより、ユーザーは一度に1つのタスクに集中できます。 たとえば、通常、「株式、債券、投資信託の株式、またはその他の投資を売却しましたか?」など、ページごとに1つの質問のみを行います。 シンプルな「はい」、「いいえ」、「わからない」ボタンがあります。
  • TurboTaxのワークフローは、長いフォームでユーザーを圧倒するのではなく、賃金/収入や控除/クレジットなどのカテゴリに分けられます。 また、進捗状況を示し、次のことへの期待を設定します。たとえば、今後の質問が年間収益を扱うことをユーザーに知らせます。
  • 並べて表示します。 ユーザーは、画面の片側の作業領域に入力し、反対側の概要を確認します。 概要はメニューとしても機能するため、ユーザーはさまざまなセクションに移動できます。

情報アーキテクチャ:階層の設計

請求UIは、医師の紙のフォームのレイアウトをできるだけ忠実に模倣して、紙からデジタルへの移行を容易にし、慣れ親しんだものにしたかったのです。 私は、スーパービルに記入するユーザーのプロセスを小さなステップに分解することから始めました。

心理図

情報がどのように構造化されているかを視覚化するために、Miroを使用してAllDataHealthの医師ポータルのマインドマップを作成しました。 マインドマップを作成することで、ポータルの情報アーキテクチャの欠陥を見つけることができました。 たとえば、ポータルにはレポートオプションの単一のドロップダウンメニューがありましたが、リストが長く、意思決定が遅くなりました。 私は、いくつかの高レベルのトピックとサブトピックを作成することを提案しました。これは、よりクリーンで効果的なナビゲート方法です。 また、既存のe-superbillのマインドマップを作成し、簡素化する必要のある領域を特定しました。

マインドマップの画像。ページの上部中央には「e-superbill」という言葉があります。この単語から4行が派生し、e-superbillの4つのサブカテゴリ、「作成」、「保存」、「送信履歴」、「設定」につながります。 「作成」の下には「患者について」と「訪問について」のサブカテゴリがあり、これらのそれぞれの下には複数のサブサブカテゴリがあります。 「保存済み」サブカテゴリの下には「完了」と「未完了」を選択するオプションがあり、「設定」の下にはサブサブカテゴリ「手順」と「診断」があります。
このマインドマップは、既存のオンラインスーパービルのレイアウトに基づいています。 点線は提案された構造を表し、実線は既存の構造を表します。

ワイヤーフレーム

私はデジタル版を作成する前にワイヤーフレームを手でスケッチすることがよくあります。 でも今回は自分が作りたいものがはっきりとわかっていたので、ミロを使い続けました。 改訂されたデスクトップUIの最初の反復では、上部に4つのカテゴリ(e-superbillの作成、レポート、患者、およびプロファイル)のメニューがありました。 左側に動的なナビゲーションがあり、ユーザーが電子スーパービルのどこにいるかによって変化しました。

私の提案では、最初の記入フォームは単純でした。それは、施設、プロバイダー、日付、手順、診断、および手順に関する詳細情報を提供する修飾子を入力するようにユーザーに求めました。 また、ユーザーを以前の作業方法と比較して方向付けるために、紙幣の視覚化を実装しました。

モバイルアプリで、メニューを非表示にして2つの画面を作成しました。これにより、ユーザーは、プロセスのどこにいるかがわかるように、完全なフォームと紙幣の画像を切り替えることができます。

最初のワイヤーフレームを提示したとき、CTOは、追加の手順を追加できるようにする必要があり、すべてを保険会社が必要とする診断にリンクする必要があると述べたので、この機能を有効にするコンポーネントを作成します。

2つの画面の切り替えを示すGIF。最初の画面には「E-Superbillの作成」と表示され、その下に「患者について」と「訪問について」と表示され、その下に手順や診断コードなどの患者情報を入力する6つのフィールドがあります。 2番目の画面には、元の紙幣の画像が表示されます。その上には、「Feeling lost?あなたはスーパービルのこの部分に記入しています。
e-superbillを使用すると、医師は電子フォームと紙の画像を切り替えることができます。

モックアップ:ユーザーフローの定義

ソフトウェアの全体的なルックアンドフィールに満足したとき、ユーザーフローのモックアップを開始しました。 新しい患者用に1つ、既存の患者用に別の1つを作成しました。 モックアップでは、複数の診断を受けて複数の手順を実行する患者や、さまざまな施設で働く医師など、理想的な状態と基本的なシナリオについて説明しました。 プロジェクトのこの時点でクライアントからのフィードバックを得ることが重要だったので、私は毎日のスタンドアップでモックアップを提示しました。

最後の仕上げ:コンポーネントと美学の洗練

プロジェクトの目標は、紙幣に似た感じで、医師が電子的に提出しやすい製品を作成することでした。 たとえば、医師は紙の請求書の一部に記入し、後で記入することがよくあります。 再設計されたe-superbillについては、請求書が不完全な場合に保存して印刷し、[下書き]タブで未完成の請求書を取得する機能を組み込むことで、その利便性を維持しました。

さらに、複数の紙幣に記入する場合のように、医師が同じデータを繰り返し入力する必要性を減らしたいと思いました。 そこで、頻繁に実行される手順を自動入力する設定機能を作成しました。 予測テキストを使用するフィールドも含めました。 たとえば、医師が患者名「Mary」を入力すると、ソフトウェアはデータベースにMarysの最後の名前を表示します。

忠実度の高いプロトタイプ

プロトタイプについては、ミロからフィグマに移行しました。これは、デザインの改良に適しています。 クライアントは、使いやすさよりも美学にあまり興味がなく、ビジュアルデザインに多くの時間を費やすことを望んでいませんでした。 Figmaコミュニティを閲覧して、必要な基本コンポーネント(フォーム、ボタン、ページネーション、トグル、チェックボックス)を備えたデザインシステムを探しました。

当時、All Data Healthには社内のデザイナーや視覚的なガイドラインがありませんでしたが、更新された請求エクスペリエンスを会社の他のブランド資産と一致させたいと思ったので、会社のホームページからフォントと色を引き出しました。 できるだけ少ないテキストを含めて、視覚言語を軽くしました。

3列のページのスクリーンショット。左側には、「作成」、「ドラフト」、「履歴」、「設定」のオプションがあるメニューがあります。中央の列には、サービスの日付、診断コード、および手順コードに関する情報を入力するためのスペースがあります。右端の列は、この情報をグループ化して示しています。上部には「Provider&Patient」というヘッダーがあり、その下には「Dr. Hindy Spitzer、NYCommunityHospital-22」という名前が付いています。その下には患者の名前「MeryPoppins」があり、その下には自己負担、遭遇、および手続きのコードがあります。
最終的なUIは、医師が重要な請求タスクに集中できるように、審美的に最小限に抑えられています。

重要な学習

このプロジェクトでの私の作業は、エンドユーザーと製品を検証するために余分な時間とお金の価値があることを確認しました。 この場合、医師は新しいe-superbillが公開される前にテストする機会がなかったため、リリース後にいくつかの修正が行われました。 さらに、設計が完了するまで待って開発を開始することの価値を学びました。 迅速に開発することで製品のリリースを迅速化できますが、システムを再構築する必要があるため、長期的にはコストが高くなる可能性があります。

また、アジャイルについてAll Data Healthを教育することもできました。また、毎日のスタンドアップなど、いくつかのアジャイルルーチンをプロセスに組み込んでいました。 同社のリーダーは、将来的にアジャイル手法をさらに含める予定であると述べており、第2フェーズで起動する別の機能を設計するように依頼しました。

全体として、All Data Healthはプロジェクトが成功したと見なし、保険金請求の処理時間が半分に短縮され、エラーが事実上排除されたと報告しました。 All Data Healthは、面倒な紙幣から電子紙幣に医師を移行することで、クライアントのための効率的で効果的なシステムを確立しました。

実行中の最終的なe-superbillを見てください。