こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 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/receip t/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 カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp 次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 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/receip t/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 カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp 次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 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/receip t/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 カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp 次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 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/receip t/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 カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp 次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 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/receip t/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 カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp 次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 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/receip t/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 カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp 次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日 4/29 (日)に虎ノ門ヒルズフォーラムで開催された CLINICS SUMMIT 2018 と合わせて、3 本のニュースリリースをだしました。 これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 ニュースリリース www.medley.jp www.medley.jp www.medley.jp オンライン診療システムのいま まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。 オンライン診療システム CLINICS は、2015 年 8 月に厚生労働省から示された遠隔診療に関する通知をうけて、2016 年 2 月にプロダクトをローンチしたところからはじまりました。 ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすい MVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。 その結果として、現在では契約医療機関は 800 を超え、1 ヶ月に 100 回以上ものオンライン診療を実施するような医療機関もでてきました。また 平成 30 年度の診療報酬改定 では オンライン診療料が新設 され、オンライン診療というものが正式に医療の現場で認められるようになってきています。 しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは 電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携 です。  オンライン診療から電子カルテへ 医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。 オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。 このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て 現状の電子カルテをとりまく課題と将来の可能性 を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。 おりしも 2017 年は 3 省 4 ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第 5 版) や、日本医師会 ORCA 管理機構による 日レセクラウド や API 拡張 (HAORI) の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。  患者とつながる電子カルテ「CLINICS カルテ」 開発した電子カルテシステム「CLINICS カルテ」は、医事会計ソフトである ORCA を会計エンジンとして組み込んだ ORCA 内包型のクラウド電子カルテ となります。 医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります(もちろんオンライン診療を実施するための基準を満たしていることが前提です)。 まさに 患者とつながる電子カルテ ということを実現したプロダクトとなります。 もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3 省 4 ガイドラインへの準拠は当然のことながら、第 3 者認証機関による認証取得に向けても動いています ( TRUSTe 取得完了 、ISMS 取得作業中)。   医療 IT の課題とアプローチ しかし、CLINICS カルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。 クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に 医療情報システム関連技術の標準化が遅れている ことや、ローカルネットワークを前提とする 院内システムのエコシステムができあがっている ためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。 この現状をふまえ、我々は CLINICS カルテの公開とあわせて、医療 IT の世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いが**「ORCA API のオープンソース公開」 と 「ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」**という 2 つのニュースリリースにあらわれています。  ORCA API のオープンソース公開 ORCA API は ORCA((正確には ORCA プロジェクトが提供している日医標準レセプトソフト))が提供する API を Ruby から利用するためのライブラリです。ORCA API をオープンソースとして公開することで、ORCA と接続するウェブアプリケーションの開発が促進されることを期待するものです。 github.com ブロックチェーンを活用した電子処方せん管理方式に関する特許出願 電子処方せんに関してはすでに 実装ガイド が作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために 今後の方向性についての議論 も行われているようですが、なかなか前に進む気配が見られません。 それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。 col 1 col 2 名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム 内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム 概要 ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現するもの この 2 つは現状の医療 IT に存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化や HPKI のオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIX の促進など、標準化という観点で医療 IT の世界には取り組むべき課題が多くあります。 標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、 テクノロジーの進化の時間軸との間にギャップ が発生しがちです。我々は今回の ORCA API や電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用した ボトムアップの技術提案 も積極的に行っていきたいと考えています。 その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場の IT 化が進み、医療従事者が診療により専念できる環境がつくられる。 そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。 医療 IT の未来に向けて toppa.medley.jp 以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療 IT における課題であると私は思っています。 若く優秀なクリエイターたちが医療 IT の世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。  メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療 IT の世界における標準化の課題に対しても積極的にアプローチしていきます。 さいごに メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ https://www.medley.jp/recruit/creative.html

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。 先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design System について発表しました。医療介護の求人サイト「 ジョブメドレー 」において、Design System を「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。 Design System とは何か Design System とは、Salesforce の Lightning Design System や IBM の Carbon Design System などが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自の Bootstrap となるものです。 UI 開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトの UI の一貫性を保つように努めることが一般的かと思いますが、Design System ではスタイルガイドだけでなくデザインの原則や UI コンポーネントの CSS や JS なども含めてプロダクトのインターフェースに関わる全てを、1 つのプロダクトとする考え方です。 Design System はスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis 氏の 「A Design System isn’t a Project. It’s a Product, Serving Products.」 という言葉を引用して、その差異を示しています。 スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design System はプロダクトに対して UI のエコシステムを提供するプロダクトである、ということが Design System の基幹となる考え方だと思います。 ジョブメドレーにおける Design System TechLunch で発表したスライドはこちら。 今回 Design System を段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。 ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトの UI の一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなく Design System によってより包括的にプロダクトの UI 開発に対する取り組み方を変える必要があるのではと考えていました。 とはいえ最初からプロダクトの UI 全てを Design System に置き換えるというのは変化が大き過ぎるし、Design System がうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。 最初から一気に色々やらない まずは一部だけ導入してみる 上手くいく部分といかない部分を検証する Design System の改善と段階導入を繰り返す Design System はプロダクトに UI のエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。 実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーの Design System として npm 化したモジュールから提供するようにしています。 npm 化して Design System から提供するようにしたのは、以下の 3 つのみです。 jmds-tools sass mixin や function を提供するユーティリティモジュール jmds-tokens design tokens（デザイン上の値を信頼できる唯一の情報源として 1 つの場所で定義されるもの） jmds-flex flexbox ユーティリティ プロダクトの UI として見ると、flexbox のユーティリティクラスを Design system から提供するようになっただけです。 ただ、今は全体のごく一部が Design System から提供されていますが、Design System に移行できる UI コンポーネントを選定して段階的に npm 化をしていくことで、プロダクトの UI コンポーネントの多くが Design System から提供されている状態にすることが可能だと思います。 単純に npm 化することが目的ではなく、npm 化した Design System をプロダクトチームでメンテナンスしていくことで、より一貫性のある UI をジョブメドレーのプロダクトに提供していくことが目的です。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける Design System の取り組みについて紹介させていただきました。 今回紹介した Design System が今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトの UI を支える強固な土台へと成長させられるように取り組んでいこうと思います。 お知らせ メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 ちょっと興味があるという方も、ぜひお気軽にご連絡ください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp