4 月末に新たにリリースしたクラウド型電子カルテ「 CLINICS カルテ 」の開発を担当している田中です。 電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回は CLINICS カルテのデザインについてマエダが紹介しました が、今回はエンジニアから見た苦悩と葛藤についてお話します。 苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、 電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト（医療会計専用のシステム）のシステム管理など、多岐にわたり対応が必要なこと が挙げられます。 ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携している ORCA のシステム管理方法についてお伝えさせていただければと思います（ORCA に関する説明は後述します）。 ガイドラインへの対応 電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして 3 省 4 ガイドライン（厚生労働省、経済産業省、総務省の 3 省が出している 4 つのガイドライン）があります。 CLINICS カルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。 システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の 2 点となります。 サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること クライアント証明書を利用した TLS クライアント認証を実施すること CLINICS カルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まず CLINICS のシステムを Heroku から AWS に移行することから始まりました。 また、クライアント認証を行うために AWS の構成を色々と検討し、Nginx とも日々格闘したりしました。。。 これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サーバの管理方法 CLINICS カルテは、日本医師会 ORCA 管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA 内包型」のクラウド型電子カルテです。 参考: ORCA とは 医療現場 IT 化を推進する日本医師会が会員等のために提供しているレセプトソフト（診療報酬の請求業務を行うための医療会計ソフト）。2002 年にオープンソースとして公開され、現在、診療所を中心に 17,000 を超える全国の医療機関に導入されています。 医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCA プロジェクト」が開発、提供を開始したものです。 https://www.orca.med.or.jp/orca/summary/outline.html CLINICS カルテはおおまかに以下のような構成となっており、Ruby on Rails で稼働しているカルテアプリケーションと医療機関ごとの ORCA サーバがあり、その間を ORCA が提供している API で接続しています。 （下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります） この ORCA サーバですが、医療機関ごとに 1 つの EC2 インスタンス構成となっており、利用する医療機関が増える度に EC2 インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。 （これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果 EC2 インスタンス単位で管理する構成になっています） ORCA サーバー関連で主に使用した AWS サービス AMI 作成やインスタンス作成などのビルド系は CodeBuild 、パッチ適用やコマンド実行などのインスタンス管理は Systems Manager 、脆弱性チェックなどのセキュリティ関連には Guard Duty といったサービスを主に利用しています。 次に、インスタンス構築に関してもう少し具体的に説明します。 ORCA サーバのインスタンス構築 ORCA サーバ用 AMI（ゴールデンイメージ）作成 ビルドの実行は CodeBuild で行っています。AMI のビルドには Packer を使用しており、ビルド完了時に作成された AMI の ID をパラメータストアに登録しています。この AMI ID をインスタンス作成時に参照します。 参考までに、CodeBuild で使用している buildspec.yaml は以下のようになります（説明箇所など、一部実際とは異なります）。 phases : pre_build : ## 説明 * packer と jq をビルド用コンテナにインストール commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 処理に必要な AWS credential 情報を取得＆設定（後の aws cli 使う用） * packer ビルド実行、AMI 作成 * packer ビルド結果から作成された AMI ID を取得 * AMI ID をパラメータストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サーバ用 EC2 インスタンス作成 医療機関用のアカウントを新規追加する場合、社内用の管理ツールでまず医療機関の基本情報を登録します。その後、ORCA インスタンス設定に必要なパラメータ（医療機関を識別する ID など）を設定し、インスタンス作成のビルド処理を実行します。 CodeBuild がゴールデンイメージ用の AMI をベースに ORCA インスタンスを構築します。ORCA インスタンスは起動時に各種設定処理を行います（cloud-init） なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。 該当インスタンスの内部 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ更新 Postgres のバックアップ設定 Mackerel や Systems Manager 等の各種 Agent インストール、設定 ORCA サーバ運用 構築が完了し稼働した後も、ORCA 自体のアップデートやパッチの適用など様々な運用が発生します。それらをどのように行っているか、まだ改善中ではありますが一部ご紹介します。 インスタンスに対する各種操作の実行 ORCA のアップデートなど、定期的に行う操作に必要なコマンドを document として登録し、RunCommand で特定インスタンスまたは複数インスタンスに一括実行できるようにしています。 ORCA アプリケーションの死活監視 ORCA アプリケーション自体構成が複雑で、いくつものミドルウェアと連携して動いています。これらの各種プロセス/ログ監視は行った上で、API として正しく稼働しているかを確認するための死活監視を Mackerel のカスタムメトリクスとして登録し、一定数以上失敗した場合は各種プロセスを再起動し、それでも正常に動かない場合は Mackerel から Slack に通知させています。 セキュリティチェック CloudTrail や VPC フローログなどをもとに、GuardDuty で定期的にチェックし脆弱性が見つかった場合は Slack に通知させるようにしています。その他、セキュリティパッチ適用などもパッチマネージャーを利用し自動化させています。 まとめ 電子カルテのシステムは検査や画像データなどを取り扱う外部システムと連携したいという需要もあります。そのような連携も視野に入れるとデータ標準化の問題などもあり難しい分野ではありますが、CLINICS カルテとして日々進化していくためにも、フルマネージドサービスなど活用できるところは積極的に活用し、集中すべき問題を解決していきたいと思います。 また、電子カルテのシステムとしての性質上、絶対に落とさないシステム運用が必要です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機能面の強化や日々のモニタリングなど地道なことも含め、もっともっと取り組んでいく必要があります。 まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォームとなるべく進化していきたいという構想を持っています。（CLINICS カルテが目指す医療のプラットフォームとは？という話は、こちらで詳しく書かれています） https://www.wantedly.com/companies/medley/post_articles/118281 CLINICS カルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 https://www.medley.jp/recruit/creative.html

4 月末に新たにリリースしたクラウド型電子カルテ「 CLINICS カルテ 」の開発を担当している田中です。 電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回は CLINICS カルテのデザインについてマエダが紹介しました が、今回はエンジニアから見た苦悩と葛藤についてお話します。 苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、 電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト（医療会計専用のシステム）のシステム管理など、多岐にわたり対応が必要なこと が挙げられます。 ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携している ORCA のシステム管理方法についてお伝えさせていただければと思います（ORCA に関する説明は後述します）。 ガイドラインへの対応 電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして 3 省 4 ガイドライン（厚生労働省、経済産業省、総務省の 3 省が出している 4 つのガイドライン）があります。 CLINICS カルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。 システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の 2 点となります。 サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること クライアント証明書を利用した TLS クライアント認証を実施すること CLINICS カルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まず CLINICS のシステムを Heroku から AWS に移行することから始まりました。 また、クライアント認証を行うために AWS の構成を色々と検討し、Nginx とも日々格闘したりしました。。。 これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サーバの管理方法 CLINICS カルテは、日本医師会 ORCA 管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA 内包型」のクラウド型電子カルテです。 参考: ORCA とは 医療現場 IT 化を推進する日本医師会が会員等のために提供しているレセプトソフト（診療報酬の請求業務を行うための医療会計ソフト）。2002 年にオープンソースとして公開され、現在、診療所を中心に 17,000 を超える全国の医療機関に導入されています。 医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCA プロジェクト」が開発、提供を開始したものです。 ORCA Project： ORCAプロジェクトの概要 日本医師会開発・日医標準レセプトソフトウェアのサイトです www.orca.med.or.jp CLINICS カルテはおおまかに以下のような構成となっており、Ruby on Rails で稼働しているカルテアプリケーションと医療機関ごとの ORCA サーバがあり、その間を ORCA が提供している API で接続しています。 （下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります） この ORCA サーバですが、医療機関ごとに 1 つの EC2 インスタンス構成となっており、利用する医療機関が増える度に EC2 インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。 （これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果 EC2 インスタンス単位で管理する構成になっています） ORCA サーバー関連で主に使用した AWS サービス AMI 作成やインスタンス作成などのビルド系は CodeBuild 、パッチ適用やコマンド実行などのインスタンス管理は Systems Manager 、脆弱性チェックなどのセキュリティ関連には Guard Duty といったサービスを主に利用しています。 次に、インスタンス構築に関してもう少し具体的に説明します。 ORCA サーバのインスタンス構築 ORCA サーバ用 AMI（ゴールデンイメージ）作成 ビルドの実行は CodeBuild で行っています。AMI のビルドには Packer を使用しており、ビルド完了時に作成された AMI の ID をパラメータストアに登録しています。この AMI ID をインスタンス作成時に参照します。 参考までに、CodeBuild で使用している buildspec.yaml は以下のようになります（説明箇所など、一部実際とは異なります）。 phases : pre_build : ## 説明 * packer と jq をビルド用コンテナにインストール commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 処理に必要な AWS credential 情報を取得＆設定（後の aws cli 使う用） * packer ビルド実行、AMI 作成 * packer ビルド結果から作成された AMI ID を取得 * AMI ID をパラメータストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サーバ用 EC2 インスタンス作成 医療機関用のアカウントを新規追加する場合、社内用の管理ツールでまず医療機関の基本情報を登録します。その後、ORCA インスタンス設定に必要なパラメータ（医療機関を識別する ID など）を設定し、インスタンス作成のビルド処理を実行します。 CodeBuild がゴールデンイメージ用の AMI をベースに ORCA インスタンスを構築します。ORCA インスタンスは起動時に各種設定処理を行います（cloud-init） なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。 該当インスタンスの内部 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ更新 Postgres のバックアップ設定 Mackerel や Systems Manager 等の各種 Agent インストール、設定 ORCA サーバ運用 構築が完了し稼働した後も、ORCA 自体のアップデートやパッチの適用など様々な運用が発生します。それらをどのように行っているか、まだ改善中ではありますが一部ご紹介します。 インスタンスに対する各種操作の実行 ORCA のアップデートなど、定期的に行う操作に必要なコマンドを document として登録し、RunCommand で特定インスタンスまたは複数インスタンスに一括実行できるようにしています。 ORCA アプリケーションの死活監視 ORCA アプリケーション自体構成が複雑で、いくつものミドルウェアと連携して動いています。これらの各種プロセス/ログ監視は行った上で、API として正しく稼働しているかを確認するための死活監視を Mackerel のカスタムメトリクスとして登録し、一定数以上失敗した場合は各種プロセスを再起動し、それでも正常に動かない場合は Mackerel から Slack に通知させています。 セキュリティチェック CloudTrail や VPC フローログなどをもとに、GuardDuty で定期的にチェックし脆弱性が見つかった場合は Slack に通知させるようにしています。その他、セキュリティパッチ適用などもパッチマネージャーを利用し自動化させています。 まとめ 電子カルテのシステムは検査や画像データなどを取り扱う外部システムと連携したいという需要もあります。そのような連携も視野に入れるとデータ標準化の問題などもあり難しい分野ではありますが、CLINICS カルテとして日々進化していくためにも、フルマネージドサービスなど活用できるところは積極的に活用し、集中すべき問題を解決していきたいと思います。 また、電子カルテのシステムとしての性質上、絶対に落とさないシステム運用が必要です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機能面の強化や日々のモニタリングなど地道なことも含め、もっともっと取り組んでいく必要があります。 まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォームとなるべく進化していきたいという構想を持っています。（CLINICS カルテが目指す医療のプラットフォームとは？という話は、こちらで詳しく書かれています） 「CLINICSカルテ」が目指す ”医療のプラットフォーム” とは？ | 株式会社メドレー お久しぶりです。メドレーで採用と広報を担当している加藤です。昨年よりはじめた「そのテーマ、役員みんなで話しました。」のコーナーですが、昨年と状況も変わりいろいろなメンバーにJOINしてもらえるよ... www.wantedly.com CLINICS カルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

4 月末に新たにリリースしたクラウド型電子カルテ「 CLINICS カルテ 」の開発を担当している田中です。 電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回は CLINICS カルテのデザインについてマエダが紹介しました が、今回はエンジニアから見た苦悩と葛藤についてお話します。 苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、 電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト（医療会計専用のシステム）のシステム管理など、多岐にわたり対応が必要なこと が挙げられます。 ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携している ORCA のシステム管理方法についてお伝えさせていただければと思います（ORCA に関する説明は後述します）。 ガイドラインへの対応 電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして 3 省 4 ガイドライン（厚生労働省、経済産業省、総務省の 3 省が出している 4 つのガイドライン）があります。 CLINICS カルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。 システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の 2 点となります。 サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること クライアント証明書を利用した TLS クライアント認証を実施すること CLINICS カルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まず CLINICS のシステムを Heroku から AWS に移行することから始まりました。 また、クライアント認証を行うために AWS の構成を色々と検討し、Nginx とも日々格闘したりしました。。。 これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サーバの管理方法 CLINICS カルテは、日本医師会 ORCA 管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA 内包型」のクラウド型電子カルテです。 参考: ORCA とは 医療現場 IT 化を推進する日本医師会が会員等のために提供しているレセプトソフト（診療報酬の請求業務を行うための医療会計ソフト）。2002 年にオープンソースとして公開され、現在、診療所を中心に 17,000 を超える全国の医療機関に導入されています。 医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCA プロジェクト」が開発、提供を開始したものです。 ORCA Project： ORCAプロジェクトの概要 日本医師会開発・日医標準レセプトソフトウェアのサイトです www.orca.med.or.jp CLINICS カルテはおおまかに以下のような構成となっており、Ruby on Rails で稼働しているカルテアプリケーションと医療機関ごとの ORCA サーバがあり、その間を ORCA が提供している API で接続しています。 （下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります） この ORCA サーバですが、医療機関ごとに 1 つの EC2 インスタンス構成となっており、利用する医療機関が増える度に EC2 インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。 （これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果 EC2 インスタンス単位で管理する構成になっています） ORCA サーバー関連で主に使用した AWS サービス AMI 作成やインスタンス作成などのビルド系は CodeBuild 、パッチ適用やコマンド実行などのインスタンス管理は Systems Manager 、脆弱性チェックなどのセキュリティ関連には Guard Duty といったサービスを主に利用しています。 次に、インスタンス構築に関してもう少し具体的に説明します。 ORCA サーバのインスタンス構築 ORCA サーバ用 AMI（ゴールデンイメージ）作成 ビルドの実行は CodeBuild で行っています。AMI のビルドには Packer を使用しており、ビルド完了時に作成された AMI の ID をパラメータストアに登録しています。この AMI ID をインスタンス作成時に参照します。 参考までに、CodeBuild で使用している buildspec.yaml は以下のようになります（説明箇所など、一部実際とは異なります）。 phases : pre_build : ## 説明 * packer と jq をビルド用コンテナにインストール commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 処理に必要な AWS credential 情報を取得＆設定（後の aws cli 使う用） * packer ビルド実行、AMI 作成 * packer ビルド結果から作成された AMI ID を取得 * AMI ID をパラメータストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サーバ用 EC2 インスタンス作成 医療機関用のアカウントを新規追加する場合、社内用の管理ツールでまず医療機関の基本情報を登録します。その後、ORCA インスタンス設定に必要なパラメータ（医療機関を識別する ID など）を設定し、インスタンス作成のビルド処理を実行します。 CodeBuild がゴールデンイメージ用の AMI をベースに ORCA インスタンスを構築します。ORCA インスタンスは起動時に各種設定処理を行います（cloud-init） なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。 該当インスタンスの内部 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ更新 Postgres のバックアップ設定 Mackerel や Systems Manager 等の各種 Agent インストール、設定 ORCA サーバ運用 構築が完了し稼働した後も、ORCA 自体のアップデートやパッチの適用など様々な運用が発生します。それらをどのように行っているか、まだ改善中ではありますが一部ご紹介します。 インスタンスに対する各種操作の実行 ORCA のアップデートなど、定期的に行う操作に必要なコマンドを document として登録し、RunCommand で特定インスタンスまたは複数インスタンスに一括実行できるようにしています。 ORCA アプリケーションの死活監視 ORCA アプリケーション自体構成が複雑で、いくつものミドルウェアと連携して動いています。これらの各種プロセス/ログ監視は行った上で、API として正しく稼働しているかを確認するための死活監視を Mackerel のカスタムメトリクスとして登録し、一定数以上失敗した場合は各種プロセスを再起動し、それでも正常に動かない場合は Mackerel から Slack に通知させています。 セキュリティチェック CloudTrail や VPC フローログなどをもとに、GuardDuty で定期的にチェックし脆弱性が見つかった場合は Slack に通知させるようにしています。その他、セキュリティパッチ適用などもパッチマネージャーを利用し自動化させています。 まとめ 電子カルテのシステムは検査や画像データなどを取り扱う外部システムと連携したいという需要もあります。そのような連携も視野に入れるとデータ標準化の問題などもあり難しい分野ではありますが、CLINICS カルテとして日々進化していくためにも、フルマネージドサービスなど活用できるところは積極的に活用し、集中すべき問題を解決していきたいと思います。 また、電子カルテのシステムとしての性質上、絶対に落とさないシステム運用が必要です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機能面の強化や日々のモニタリングなど地道なことも含め、もっともっと取り組んでいく必要があります。 まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォームとなるべく進化していきたいという構想を持っています。（CLINICS カルテが目指す医療のプラットフォームとは？という話は、こちらで詳しく書かれています） 「CLINICSカルテ」が目指す ”医療のプラットフォーム” とは？ | 株式会社メドレー お久しぶりです。メドレーで採用と広報を担当している加藤です。昨年よりはじめた「そのテーマ、役員みんなで話しました。」のコーナーですが、昨年と状況も変わりいろいろなメンバーにJOINしてもらえるよ... www.wantedly.com CLINICS カルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

4 月末に新たにリリースしたクラウド型電子カルテ「 CLINICS カルテ 」の開発を担当している田中です。 電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回は CLINICS カルテのデザインについてマエダが紹介しました が、今回はエンジニアから見た苦悩と葛藤についてお話します。 苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、 電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト（医療会計専用のシステム）のシステム管理など、多岐にわたり対応が必要なこと が挙げられます。 ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携している ORCA のシステム管理方法についてお伝えさせていただければと思います（ORCA に関する説明は後述します）。 ガイドラインへの対応 電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして 3 省 4 ガイドライン（厚生労働省、経済産業省、総務省の 3 省が出している 4 つのガイドライン）があります。 CLINICS カルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。 システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の 2 点となります。 サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること クライアント証明書を利用した TLS クライアント認証を実施すること CLINICS カルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まず CLINICS のシステムを Heroku から AWS に移行することから始まりました。 また、クライアント認証を行うために AWS の構成を色々と検討し、Nginx とも日々格闘したりしました。。。 これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サーバの管理方法 CLINICS カルテは、日本医師会 ORCA 管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA 内包型」のクラウド型電子カルテです。 参考: ORCA とは 医療現場 IT 化を推進する日本医師会が会員等のために提供しているレセプトソフト（診療報酬の請求業務を行うための医療会計ソフト）。2002 年にオープンソースとして公開され、現在、診療所を中心に 17,000 を超える全国の医療機関に導入されています。 医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCA プロジェクト」が開発、提供を開始したものです。 ORCA Project： ORCAプロジェクトの概要 日本医師会開発・日医標準レセプトソフトウェアのサイトです www.orca.med.or.jp CLINICS カルテはおおまかに以下のような構成となっており、Ruby on Rails で稼働しているカルテアプリケーションと医療機関ごとの ORCA サーバがあり、その間を ORCA が提供している API で接続しています。 （下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります） この ORCA サーバですが、医療機関ごとに 1 つの EC2 インスタンス構成となっており、利用する医療機関が増える度に EC2 インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。 （これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果 EC2 インスタンス単位で管理する構成になっています） ORCA サーバー関連で主に使用した AWS サービス AMI 作成やインスタンス作成などのビルド系は CodeBuild 、パッチ適用やコマンド実行などのインスタンス管理は Systems Manager 、脆弱性チェックなどのセキュリティ関連には Guard Duty といったサービスを主に利用しています。 次に、インスタンス構築に関してもう少し具体的に説明します。 ORCA サーバのインスタンス構築 ORCA サーバ用 AMI（ゴールデンイメージ）作成 ビルドの実行は CodeBuild で行っています。AMI のビルドには Packer を使用しており、ビルド完了時に作成された AMI の ID をパラメータストアに登録しています。この AMI ID をインスタンス作成時に参照します。 参考までに、CodeBuild で使用している buildspec.yaml は以下のようになります（説明箇所など、一部実際とは異なります）。 phases : pre_build : ## 説明 * packer と jq をビルド用コンテナにインストール commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 処理に必要な AWS credential 情報を取得＆設定（後の aws cli 使う用） * packer ビルド実行、AMI 作成 * packer ビルド結果から作成された AMI ID を取得 * AMI ID をパラメータストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サーバ用 EC2 インスタンス作成 医療機関用のアカウントを新規追加する場合、社内用の管理ツールでまず医療機関の基本情報を登録します。その後、ORCA インスタンス設定に必要なパラメータ（医療機関を識別する ID など）を設定し、インスタンス作成のビルド処理を実行します。 CodeBuild がゴールデンイメージ用の AMI をベースに ORCA インスタンスを構築します。ORCA インスタンスは起動時に各種設定処理を行います（cloud-init） なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。 該当インスタンスの内部 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ更新 Postgres のバックアップ設定 Mackerel や Systems Manager 等の各種 Agent インストール、設定 ORCA サーバ運用 構築が完了し稼働した後も、ORCA 自体のアップデートやパッチの適用など様々な運用が発生します。それらをどのように行っているか、まだ改善中ではありますが一部ご紹介します。 インスタンスに対する各種操作の実行 ORCA のアップデートなど、定期的に行う操作に必要なコマンドを document として登録し、RunCommand で特定インスタンスまたは複数インスタンスに一括実行できるようにしています。 ORCA アプリケーションの死活監視 ORCA アプリケーション自体構成が複雑で、いくつものミドルウェアと連携して動いています。これらの各種プロセス/ログ監視は行った上で、API として正しく稼働しているかを確認するための死活監視を Mackerel のカスタムメトリクスとして登録し、一定数以上失敗した場合は各種プロセスを再起動し、それでも正常に動かない場合は Mackerel から Slack に通知させています。 セキュリティチェック CloudTrail や VPC フローログなどをもとに、GuardDuty で定期的にチェックし脆弱性が見つかった場合は Slack に通知させるようにしています。その他、セキュリティパッチ適用などもパッチマネージャーを利用し自動化させています。 まとめ 電子カルテのシステムは検査や画像データなどを取り扱う外部システムと連携したいという需要もあります。そのような連携も視野に入れるとデータ標準化の問題などもあり難しい分野ではありますが、CLINICS カルテとして日々進化していくためにも、フルマネージドサービスなど活用できるところは積極的に活用し、集中すべき問題を解決していきたいと思います。 また、電子カルテのシステムとしての性質上、絶対に落とさないシステム運用が必要です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機能面の強化や日々のモニタリングなど地道なことも含め、もっともっと取り組んでいく必要があります。 まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォームとなるべく進化していきたいという構想を持っています。（CLINICS カルテが目指す医療のプラットフォームとは？という話は、こちらで詳しく書かれています） 「CLINICSカルテ」が目指す ”医療のプラットフォーム” とは？ | 株式会社メドレー お久しぶりです。メドレーで採用と広報を担当している加藤です。昨年よりはじめた「そのテーマ、役員みんなで話しました。」のコーナーですが、昨年と状況も変わりいろいろなメンバーにJOINしてもらえるよ... www.wantedly.com CLINICS カルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

4 月末に新たにリリースしたクラウド型電子カルテ「 CLINICS カルテ 」の開発を担当している田中です。 電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回は CLINICS カルテのデザインについてマエダが紹介しました が、今回はエンジニアから見た苦悩と葛藤についてお話します。 苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、 電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト（医療会計専用のシステム）のシステム管理など、多岐にわたり対応が必要なこと が挙げられます。 ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携している ORCA のシステム管理方法についてお伝えさせていただければと思います（ORCA に関する説明は後述します）。 ガイドラインへの対応 電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして 3 省 4 ガイドライン（厚生労働省、経済産業省、総務省の 3 省が出している 4 つのガイドライン）があります。 CLINICS カルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。 システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の 2 点となります。 サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること クライアント証明書を利用した TLS クライアント認証を実施すること CLINICS カルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まず CLINICS のシステムを Heroku から AWS に移行することから始まりました。 また、クライアント認証を行うために AWS の構成を色々と検討し、Nginx とも日々格闘したりしました。。。 これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サーバの管理方法 CLINICS カルテは、日本医師会 ORCA 管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA 内包型」のクラウド型電子カルテです。 参考: ORCA とは 医療現場 IT 化を推進する日本医師会が会員等のために提供しているレセプトソフト（診療報酬の請求業務を行うための医療会計ソフト）。2002 年にオープンソースとして公開され、現在、診療所を中心に 17,000 を超える全国の医療機関に導入されています。 医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCA プロジェクト」が開発、提供を開始したものです。 ORCA Project： ORCAプロジェクトの概要 日本医師会開発・日医標準レセプトソフトウェアのサイトです www.orca.med.or.jp CLINICS カルテはおおまかに以下のような構成となっており、Ruby on Rails で稼働しているカルテアプリケーションと医療機関ごとの ORCA サーバがあり、その間を ORCA が提供している API で接続しています。 （下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります） この ORCA サーバですが、医療機関ごとに 1 つの EC2 インスタンス構成となっており、利用する医療機関が増える度に EC2 インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。 （これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果 EC2 インスタンス単位で管理する構成になっています） ORCA サーバー関連で主に使用した AWS サービス AMI 作成やインスタンス作成などのビルド系は CodeBuild 、パッチ適用やコマンド実行などのインスタンス管理は Systems Manager 、脆弱性チェックなどのセキュリティ関連には Guard Duty といったサービスを主に利用しています。 次に、インスタンス構築に関してもう少し具体的に説明します。 ORCA サーバのインスタンス構築 ORCA サーバ用 AMI（ゴールデンイメージ）作成 ビルドの実行は CodeBuild で行っています。AMI のビルドには Packer を使用しており、ビルド完了時に作成された AMI の ID をパラメータストアに登録しています。この AMI ID をインスタンス作成時に参照します。 参考までに、CodeBuild で使用している buildspec.yaml は以下のようになります（説明箇所など、一部実際とは異なります）。 phases : pre_build : ## 説明 * packer と jq をビルド用コンテナにインストール commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 処理に必要な AWS credential 情報を取得＆設定（後の aws cli 使う用） * packer ビルド実行、AMI 作成 * packer ビルド結果から作成された AMI ID を取得 * AMI ID をパラメータストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サーバ用 EC2 インスタンス作成 医療機関用のアカウントを新規追加する場合、社内用の管理ツールでまず医療機関の基本情報を登録します。その後、ORCA インスタンス設定に必要なパラメータ（医療機関を識別する ID など）を設定し、インスタンス作成のビルド処理を実行します。 CodeBuild がゴールデンイメージ用の AMI をベースに ORCA インスタンスを構築します。ORCA インスタンスは起動時に各種設定処理を行います（cloud-init） なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。 該当インスタンスの内部 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ更新 Postgres のバックアップ設定 Mackerel や Systems Manager 等の各種 Agent インストール、設定 ORCA サーバ運用 構築が完了し稼働した後も、ORCA 自体のアップデートやパッチの適用など様々な運用が発生します。それらをどのように行っているか、まだ改善中ではありますが一部ご紹介します。 インスタンスに対する各種操作の実行 ORCA のアップデートなど、定期的に行う操作に必要なコマンドを document として登録し、RunCommand で特定インスタンスまたは複数インスタンスに一括実行できるようにしています。 ORCA アプリケーションの死活監視 ORCA アプリケーション自体構成が複雑で、いくつものミドルウェアと連携して動いています。これらの各種プロセス/ログ監視は行った上で、API として正しく稼働しているかを確認するための死活監視を Mackerel のカスタムメトリクスとして登録し、一定数以上失敗した場合は各種プロセスを再起動し、それでも正常に動かない場合は Mackerel から Slack に通知させています。 セキュリティチェック CloudTrail や VPC フローログなどをもとに、GuardDuty で定期的にチェックし脆弱性が見つかった場合は Slack に通知させるようにしています。その他、セキュリティパッチ適用などもパッチマネージャーを利用し自動化させています。 まとめ 電子カルテのシステムは検査や画像データなどを取り扱う外部システムと連携したいという需要もあります。そのような連携も視野に入れるとデータ標準化の問題などもあり難しい分野ではありますが、CLINICS カルテとして日々進化していくためにも、フルマネージドサービスなど活用できるところは積極的に活用し、集中すべき問題を解決していきたいと思います。 また、電子カルテのシステムとしての性質上、絶対に落とさないシステム運用が必要です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機能面の強化や日々のモニタリングなど地道なことも含め、もっともっと取り組んでいく必要があります。 まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォームとなるべく進化していきたいという構想を持っています。（CLINICS カルテが目指す医療のプラットフォームとは？という話は、こちらで詳しく書かれています） 「CLINICSカルテ」が目指す ”医療のプラットフォーム” とは？ | 株式会社メドレー お久しぶりです。メドレーで採用と広報を担当している加藤です。昨年よりはじめた「そのテーマ、役員みんなで話しました。」のコーナーですが、昨年と状況も変わりいろいろなメンバーにJOINしてもらえるよ... www.wantedly.com CLINICS カルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

4 月末に新たにリリースしたクラウド型電子カルテ「 CLINICS カルテ 」の開発を担当している田中です。 電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回は CLINICS カルテのデザインについてマエダが紹介しました が、今回はエンジニアから見た苦悩と葛藤についてお話します。 苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、 電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト（医療会計専用のシステム）のシステム管理など、多岐にわたり対応が必要なこと が挙げられます。 ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携している ORCA のシステム管理方法についてお伝えさせていただければと思います（ORCA に関する説明は後述します）。 ガイドラインへの対応 電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして 3 省 4 ガイドライン（厚生労働省、経済産業省、総務省の 3 省が出している 4 つのガイドライン）があります。 CLINICS カルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。 システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の 2 点となります。 サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること クライアント証明書を利用した TLS クライアント認証を実施すること CLINICS カルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まず CLINICS のシステムを Heroku から AWS に移行することから始まりました。 また、クライアント認証を行うために AWS の構成を色々と検討し、Nginx とも日々格闘したりしました。。。 これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サーバの管理方法 CLINICS カルテは、日本医師会 ORCA 管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA 内包型」のクラウド型電子カルテです。 参考: ORCA とは 医療現場 IT 化を推進する日本医師会が会員等のために提供しているレセプトソフト（診療報酬の請求業務を行うための医療会計ソフト）。2002 年にオープンソースとして公開され、現在、診療所を中心に 17,000 を超える全国の医療機関に導入されています。 医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCA プロジェクト」が開発、提供を開始したものです。 ORCA Project： ORCAプロジェクトの概要 日本医師会開発・日医標準レセプトソフトウェアのサイトです www.orca.med.or.jp CLINICS カルテはおおまかに以下のような構成となっており、Ruby on Rails で稼働しているカルテアプリケーションと医療機関ごとの ORCA サーバがあり、その間を ORCA が提供している API で接続しています。 （下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります） この ORCA サーバですが、医療機関ごとに 1 つの EC2 インスタンス構成となっており、利用する医療機関が増える度に EC2 インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。 （これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果 EC2 インスタンス単位で管理する構成になっています） ORCA サーバー関連で主に使用した AWS サービス AMI 作成やインスタンス作成などのビルド系は CodeBuild 、パッチ適用やコマンド実行などのインスタンス管理は Systems Manager 、脆弱性チェックなどのセキュリティ関連には Guard Duty といったサービスを主に利用しています。 次に、インスタンス構築に関してもう少し具体的に説明します。 ORCA サーバのインスタンス構築 ORCA サーバ用 AMI（ゴールデンイメージ）作成 ビルドの実行は CodeBuild で行っています。AMI のビルドには Packer を使用しており、ビルド完了時に作成された AMI の ID をパラメータストアに登録しています。この AMI ID をインスタンス作成時に参照します。 参考までに、CodeBuild で使用している buildspec.yaml は以下のようになります（説明箇所など、一部実際とは異なります）。 phases : pre_build : ## 説明 * packer と jq をビルド用コンテナにインストール commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 処理に必要な AWS credential 情報を取得＆設定（後の aws cli 使う用） * packer ビルド実行、AMI 作成 * packer ビルド結果から作成された AMI ID を取得 * AMI ID をパラメータストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サーバ用 EC2 インスタンス作成 医療機関用のアカウントを新規追加する場合、社内用の管理ツールでまず医療機関の基本情報を登録します。その後、ORCA インスタンス設定に必要なパラメータ（医療機関を識別する ID など）を設定し、インスタンス作成のビルド処理を実行します。 CodeBuild がゴールデンイメージ用の AMI をベースに ORCA インスタンスを構築します。ORCA インスタンスは起動時に各種設定処理を行います（cloud-init） なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。 該当インスタンスの内部 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ更新 Postgres のバックアップ設定 Mackerel や Systems Manager 等の各種 Agent インストール、設定 ORCA サーバ運用 構築が完了し稼働した後も、ORCA 自体のアップデートやパッチの適用など様々な運用が発生します。それらをどのように行っているか、まだ改善中ではありますが一部ご紹介します。 インスタンスに対する各種操作の実行 ORCA のアップデートなど、定期的に行う操作に必要なコマンドを document として登録し、RunCommand で特定インスタンスまたは複数インスタンスに一括実行できるようにしています。 ORCA アプリケーションの死活監視 ORCA アプリケーション自体構成が複雑で、いくつものミドルウェアと連携して動いています。これらの各種プロセス/ログ監視は行った上で、API として正しく稼働しているかを確認するための死活監視を Mackerel のカスタムメトリクスとして登録し、一定数以上失敗した場合は各種プロセスを再起動し、それでも正常に動かない場合は Mackerel から Slack に通知させています。 セキュリティチェック CloudTrail や VPC フローログなどをもとに、GuardDuty で定期的にチェックし脆弱性が見つかった場合は Slack に通知させるようにしています。その他、セキュリティパッチ適用などもパッチマネージャーを利用し自動化させています。 まとめ 電子カルテのシステムは検査や画像データなどを取り扱う外部システムと連携したいという需要もあります。そのような連携も視野に入れるとデータ標準化の問題などもあり難しい分野ではありますが、CLINICS カルテとして日々進化していくためにも、フルマネージドサービスなど活用できるところは積極的に活用し、集中すべき問題を解決していきたいと思います。 また、電子カルテのシステムとしての性質上、絶対に落とさないシステム運用が必要です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機能面の強化や日々のモニタリングなど地道なことも含め、もっともっと取り組んでいく必要があります。 まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォームとなるべく進化していきたいという構想を持っています。（CLINICS カルテが目指す医療のプラットフォームとは？という話は、こちらで詳しく書かれています） 「CLINICSカルテ」が目指す ”医療のプラットフォーム” とは？ | 株式会社メドレー お久しぶりです。メドレーで採用と広報を担当している加藤です。昨年よりはじめた「そのテーマ、役員みんなで話しました。」のコーナーですが、昨年と状況も変わりいろいろなメンバーにJOINしてもらえるよ... www.wantedly.com CLINICS カルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

4 月末に新たにリリースしたクラウド型電子カルテ「 CLINICS カルテ 」の開発を担当している田中です。 電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回は CLINICS カルテのデザインについてマエダが紹介しました が、今回はエンジニアから見た苦悩と葛藤についてお話します。 苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、 電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト（医療会計専用のシステム）のシステム管理など、多岐にわたり対応が必要なこと が挙げられます。 ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携している ORCA のシステム管理方法についてお伝えさせていただければと思います（ORCA に関する説明は後述します）。 ガイドラインへの対応 電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして 3 省 4 ガイドライン（厚生労働省、経済産業省、総務省の 3 省が出している 4 つのガイドライン）があります。 CLINICS カルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。 システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の 2 点となります。 サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること クライアント証明書を利用した TLS クライアント認証を実施すること CLINICS カルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まず CLINICS のシステムを Heroku から AWS に移行することから始まりました。 また、クライアント認証を行うために AWS の構成を色々と検討し、Nginx とも日々格闘したりしました。。。 これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サーバの管理方法 CLINICS カルテは、日本医師会 ORCA 管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA 内包型」のクラウド型電子カルテです。 参考: ORCA とは 医療現場 IT 化を推進する日本医師会が会員等のために提供しているレセプトソフト（診療報酬の請求業務を行うための医療会計ソフト）。2002 年にオープンソースとして公開され、現在、診療所を中心に 17,000 を超える全国の医療機関に導入されています。 医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997 年 情報化検討委員会）を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCA プロジェクト」が開発、提供を開始したものです。 ORCA Project： ORCAプロジェクトの概要 日本医師会開発・日医標準レセプトソフトウェアのサイトです www.orca.med.or.jp CLINICS カルテはおおまかに以下のような構成となっており、Ruby on Rails で稼働しているカルテアプリケーションと医療機関ごとの ORCA サーバがあり、その間を ORCA が提供している API で接続しています。 （下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります） この ORCA サーバですが、医療機関ごとに 1 つの EC2 インスタンス構成となっており、利用する医療機関が増える度に EC2 インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。 （これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果 EC2 インスタンス単位で管理する構成になっています） ORCA サーバー関連で主に使用した AWS サービス AMI 作成やインスタンス作成などのビルド系は CodeBuild 、パッチ適用やコマンド実行などのインスタンス管理は Systems Manager 、脆弱性チェックなどのセキュリティ関連には Guard Duty といったサービスを主に利用しています。 次に、インスタンス構築に関してもう少し具体的に説明します。 ORCA サーバのインスタンス構築 ORCA サーバ用 AMI（ゴールデンイメージ）作成 ビルドの実行は CodeBuild で行っています。AMI のビルドには Packer を使用しており、ビルド完了時に作成された AMI の ID をパラメータストアに登録しています。この AMI ID をインスタンス作成時に参照します。 参考までに、CodeBuild で使用している buildspec.yaml は以下のようになります（説明箇所など、一部実際とは異なります）。 phases : pre_build : ## 説明 * packer と jq をビルド用コンテナにインストール commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 処理に必要な AWS credential 情報を取得＆設定（後の aws cli 使う用） * packer ビルド実行、AMI 作成 * packer ビルド結果から作成された AMI ID を取得 * AMI ID をパラメータストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サーバ用 EC2 インスタンス作成 医療機関用のアカウントを新規追加する場合、社内用の管理ツールでまず医療機関の基本情報を登録します。その後、ORCA インスタンス設定に必要なパラメータ（医療機関を識別する ID など）を設定し、インスタンス作成のビルド処理を実行します。 CodeBuild がゴールデンイメージ用の AMI をベースに ORCA インスタンスを構築します。ORCA インスタンスは起動時に各種設定処理を行います（cloud-init） なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。 該当インスタンスの内部 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ更新 Postgres のバックアップ設定 Mackerel や Systems Manager 等の各種 Agent インストール、設定 ORCA サーバ運用 構築が完了し稼働した後も、ORCA 自体のアップデートやパッチの適用など様々な運用が発生します。それらをどのように行っているか、まだ改善中ではありますが一部ご紹介します。 インスタンスに対する各種操作の実行 ORCA のアップデートなど、定期的に行う操作に必要なコマンドを document として登録し、RunCommand で特定インスタンスまたは複数インスタンスに一括実行できるようにしています。 ORCA アプリケーションの死活監視 ORCA アプリケーション自体構成が複雑で、いくつものミドルウェアと連携して動いています。これらの各種プロセス/ログ監視は行った上で、API として正しく稼働しているかを確認するための死活監視を Mackerel のカスタムメトリクスとして登録し、一定数以上失敗した場合は各種プロセスを再起動し、それでも正常に動かない場合は Mackerel から Slack に通知させています。 セキュリティチェック CloudTrail や VPC フローログなどをもとに、GuardDuty で定期的にチェックし脆弱性が見つかった場合は Slack に通知させるようにしています。その他、セキュリティパッチ適用などもパッチマネージャーを利用し自動化させています。 まとめ 電子カルテのシステムは検査や画像データなどを取り扱う外部システムと連携したいという需要もあります。そのような連携も視野に入れるとデータ標準化の問題などもあり難しい分野ではありますが、CLINICS カルテとして日々進化していくためにも、フルマネージドサービスなど活用できるところは積極的に活用し、集中すべき問題を解決していきたいと思います。 また、電子カルテのシステムとしての性質上、絶対に落とさないシステム運用が必要です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機能面の強化や日々のモニタリングなど地道なことも含め、もっともっと取り組んでいく必要があります。 まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォームとなるべく進化していきたいという構想を持っています。（CLINICS カルテが目指す医療のプラットフォームとは？という話は、こちらで詳しく書かれています） 「CLINICSカルテ」が目指す ”医療のプラットフォーム” とは？ | 株式会社メドレー お久しぶりです。メドレーで採用と広報を担当している加藤です。昨年よりはじめた「そのテーマ、役員みんなで話しました。」のコーナーですが、昨年と状況も変わりいろいろなメンバーにJOINしてもらえるよ... www.wantedly.com CLINICS カルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 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 カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 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