Medley Developer Blog

株式会社メドレーのエンジニア・デザイナーによるブログです

電子カルテシステム開発の難しさを解決するためのフルマネージドサービスの活用

4月末に新たにリリースしたクラウド型電子カルテ「CLINICSカルテ」の開発を担当している田中です。

電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回はCLINICSカルテのデザインについてマエダが紹介しましたが、今回はエンジニアから見た苦悩と葛藤についてお話します。

苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト（医療会計専用のシステム）のシステム管理など、多岐にわたり対応が必要なことが挙げられます。

ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携しているORCAのシステム管理方法についてお伝えさせていただければと思います（ORCAに関する説明は後述します）。

ガイドラインへの対応

電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして3省4ガイドライン（厚生労働省、経済産業省、総務省の3省が出している4つのガイドライン）があります。

CLINICSカルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。

システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の2点となります。

  • サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること
  • クライアント証明書を利用した TLS クライアント認証を実施すること

CLINICSカルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まずCLINICSのシステムをHerokuからAWSに移行することから始まりました。

また、クライアント認証を行うためにAWSの構成を色々と検討し、Nginxとも日々格闘したりしました。。。

これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。

developer.medley.jp developer.medley.jp developer.medley.jp

ORCAサーバの管理方法

CLINICSカルテは、日本医師会ORCA管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA内包型」のクラウド型電子カルテです。

参考: ORCAとは

医療現場IT化を推進する日本医師会が会員等のために提供しているレセプトソフト（診療報酬の請求業務を行うための医療会計ソフト）。2002 年にオープンソースとして公開され、現在、診療所を中心に17,000 を超える全国の医療機関に導入されています。

医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」（1997年 情報化検討委員会）を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCAプロジェクト」が開発、提供を開始したものです。

www.orca.med.or.jp

CLINICSカルテはおおまかに以下のような構成となっており、Ruby on Railsで稼働しているカルテアプリケーションと医療機関ごとのORCAサーバがあり、その間をORCAが提供しているAPIで接続しています。

（下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります） f:id:medley_inc:20180521152610p:plain

このORCAサーバですが、医療機関ごとに1つのEC2インスタンス構成となっており、利用する医療機関が増える度にEC2インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。

（これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果EC2インスタンス単位で管理する構成になっています）

ORCAサーバー関連で主に使用したAWSサービス

f:id:medley_inc:20180521152646p:plain AMI作成やインスタンス作成などのビルド系はCodeBuild、パッチ適用やコマンド実行などのインスタンス管理はSystems Manager、脆弱性チェックなどのセキュリティ関連にはGuard Dutyといったサービスを主に利用しています。

次に、インスタンス構築に関してもう少し具体的に説明します。

ORCAサーバのインスタンス構築

ORCAサーバ用AMI（ゴールデンイメージ）作成

ビルドの実行はCodeBuildで行っています。AMIのビルドにはPackerを使用しており、ビルド完了時に作成されたAMIのIDをパラメータストアに登録しています。このAMI IDをインスタンス作成時に参照します。

f:id:medley_inc:20180521152801p:plain

参考までに、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 http://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） f:id:medley_inc:20180521152838p:plain

なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。

  • 該当インスタンスの内部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カルテが目指す医療のプラットフォームとは？という話は、こちらで詳しく書かれています）

www.wantedly.com

CLINICSカルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp