電子カルテの経験から、複雑なプロダクトデザインのアプローチを考える

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「CLINICS カルテ」のデザインを担当しているマエダです。

この電子カルテは、医療情報という複雑かつ独特なデータを扱うため、これまで自分自身が取り組んで来たような Web サービスとは違ったデザインのアプローチが必要でした。

今回は、そんなデザイナーの苦悩と葛藤についてお話します。医療に限らず、複雑な業務フローの業界でデザインに悩む人のお役に立てれば嬉しいです。

デザインに取り掛かる前の準備

CLINICS カルテは「日医標準レセプトソフト（ORCA）」を完全内包しているカルテなのですが、医療にかなり詳しい人でないと、「レセプトソフトって？」というところから疑問ですよね。

自分も同様で、レセプト？オーダー？DO 処方？...など医療の用語がわからない状態だったので、医療知識の理解や業務フローなどを知るところからプロジェクトに入り始めました。

デザイン業務を行う前に、医療事務の書籍を読んだり、医療事務がどのようにレセプト業務を行っているのかを学ぶことで、どのような UI が適しているかなど掴んでいきました。

ちなみに、皆さんが医療機関で受診した時に診療費の一部負担して支払われると思いますが（よく「3 割負担」など聞くこともあるかもしれません）残りの診療費については、 加入している医療保険の保険者（健康保険組合など）が支払います。

この診療費の請求のために発行する明細を診療報酬明細書（レセプト） といい、レセプトを作成し診療報酬を請求する業務のことをレセプト業務と言います。

そのレセプトを作成するための専用システムを「レセプトソフト」と言いますが、数あるレセプトソフトの中でも、日本医師会がオープンにして提供している「日医標準レセプトソフト（ORCA）」を、CLINICS カルテは内包しています。

実際に ORCA を使ってみると、レセプト業務を知らない初心者には難易度が高い操作性に戸惑い、ウェブデザイン歴 14 年のマエダも機能ひとつひとつ理解するのに苦しめられました。

Web サービスの管理ツールの利用に慣れていると、操作順序だったりボタンをクリックした後の挙動についてある程度予測できるのですが、ORCA はぜんぜん予測できない...。

そんなときに大活躍したのが、超大作 1400 ページ程もある ORCA の操作マニュアル。人生でこんなに読み込んだマニュアルはないと断言できるほど、カルテをデザインした際に大変重宝しました。

最初は操作に非常に大変でしたが、業務フローを理解したうえで、操作に慣れてくると ORCA の UI が請求業務をする上で理にかなっていることも理解できて、UI の奥深さにあらためて気付かされました。

ORCA は実際にダウンロードして試してみることができるので、興味のある方はぜひ触ってみてはいかがでしょうか。

• ORCA 日レセクライアント：https://www.orca.med.or.jp/receipt/download/java-client/
• ORCA 操作マニュアル：https://manual.orca.med.or.jp/5.0/html/

また、医療機関にカルテ入力〜会計処理までのフローのヒアリングなども行い、カルテのデザインをする上での前提知識を蓄えたり、既存カルテの課題なども整理することで、CLINICS カルテをどのようなデザインにしていくか、徐々に UI 方針を固めていきました。

ようやくデザインへのアプローチのお話

さて、ここまできてやっとデザインについての話です。

昨今の Web デザインはワイヤーを引いて、モックを Sketch 等のデザインツールで制作し、動作検証するためにプロトタイピングツールで触れるようにした後、システム実装に取り掛かるというのが一般的だと思います。しかし、カルテは画面ごとに細かい機能がたくさんあり、それぞれの機能についてデザインして、プロトタイピングして....という一連の作業を行うとデザイン業務だけで恐ろしいほどの工数がかかるのが目にみえてました。

そこで私は、デザインに取り掛かるアプローチを普段と変えてみることにしました。

デザインするけどデザインツールは使わない

カルテはほぼコーディングだけでデザインしました。俗にいうインブラウザコーディングというやつでしょうか。

これによりワイヤー → デザインツール → プロトタイピングという、一連の工程を大幅に短縮して開発することができました。

カルテが動作する開発環境のほかに UI デザイン用の環境があります。UI デザインの環境でコーディングした HTML/CSS ファイルを開発環境に移植することができるため、エンジニアは UI 実装する手間も大幅に削減でき、システム開発に専念することができたのもよかった点です。

またインタラクションも CSS で制御するようにしたため、動作の部分もデザイナー自身の思い描いたイメージに合うように調整できたので、制限もあるプロトタイピングツールを使うよりも実際の挙動に近いかたちで検証できたこともメリットでした。

ちなみに以前にマエダが書いた記事として CLINICS アプリでデザイン言語システムを導入した事をお伝えしましたが、CLINICS カルテの UI は絶賛改善中のため、まだ導入はしていません。ある程度 UI 設計の軸が固まった段階で改めて整理したいとおもっています。

UI の方針を定義することの重要性

私自身これまで Web サービスをいくつも手がけてきましたが、カルテのデザインほど UI に悩まされた経験はありませんでした。

これまで見てきた電子カルテは機能毎にいくつものポップアップが表示されたり、深い階層を辿ったりするため、かなり独自の UI になっているように思えました。さらに、医療機関によって個別にカスタマイズされていることが多く、裏をかえせば UI のあるべき姿の方針が開発側ではなく、ユーザである医療機関側に委ねられているように思えました。実際に医療機関にヒアリングをしても、UI へのこだわりを持っている方が多い印象を受けました。

こうなると、電子カルテを使っている医師は職場を変わる度に新しい電子カルテの使い方を学びなおすということになります。また、医療機関間で情報連携しようと思った時も、データの保管形式などにバラツキが出てしまいます。

そこで CLINICS カルテでは、開発者側が UI 方針をしっかり定義し一貫性をもった操作性を提供することが診療効率の改善にもつながると考え、UI 開発を重要視しています。 カスタマイズに慣れている医療機関からすると、こうしてプロダクト側から UI を提示されることは珍しいことだと思います。しかしカスタマイズをしない分、UI の良し悪しが導入の判断を左右するという自負を持ちながら、どのような UI が最適なのかを日々模索し続けています。

見た目的には問題なくても、触ってみるとクリック数が多くなってしまったり、適切な導線設計をしたつもりが逆にユーザーを迷わせる導線になってしまったりと、機能ひとつとっても「作る → 検証 → 改善」の工程を幾度となく繰り返しながら、使い勝手向上と機能の両立を目指しています。右脳と左脳が行き来するため脳内キャッチボールが発生し、疲弊することもしばしばありましたが、その分想いの強いプロダクトとしてリリースできたことはデザイナーをしていてもなかなか巡り合うことのできない貴重な経験を得られたと思っています。

上流工程としてだけでなく運用フェーズのデザインの重要性

プロダクトに携わるデザイナーの役割がどんどん幅広くなってきている昨今、広範囲でプロダクトに携わらないと、本質を捉えたデザインができず、プロダクトの方向に迷いが生じてしまうことになるので、全体像を理解したうえでデザインにどう落とし込んで行くかが重要になってきます。

デザイナーは上流工程だけでなく、システムがどういう設計で成り立っているのか踏まえ、実運用も理解することで、今後の改善やアイデアに活かせると思います。

どこが課題でどれを優先して開発するかなどもデザインする上で重要で、それも踏まえて企画検討することがプロダクトとして良いものにできるかどうかに影響します。

上流だけでは結局のところ表面的な部分だけの品質を重視してしまいがちですが、全体像を捉えることがプロダクト品質を底上げするようにしていくことの大切さを、このプロダクト開発に携わることで学ばせてもらっています。

まとめ

すでに実際にご利用いただいてる医療機関もあり、実運用からのフィードバックを経て日々進化している CLINICS カルテ。まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務の課題解決をしていきます。

実際に CLINICS カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。

次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！