こんにちは。GMOリザーブプラスの馬場です。
本シリーズでは、医療系エンジニアを目指す方向けに、複数回にわたって院内IT 環境について技術面から分かりやすくお伝えします。本シリーズを通して読むことで、エンジニアをはじめとした読者の皆様が、少しでも楽しみながらかかりつけ医に通っていただけると嬉しいです。
なお、本シリーズでは、基本的には大規模な病院ではなく、病床数の少ない、いわゆる小規模な診療所(クリニック)を対象とします。
メタ的な話ではありますが、これまで私は「サカモトに聞く!」シリーズを連載してきたものの、恥ずかしながら実際にはクリニックの中に入ってエンジニア的な作業をしたことがありませんでした。電子カルテ連携など、クリニックの現地作業は基本的には弊社ではサポート側の業務となりますが、私の主な業務としては製品開発であり、キャリアとしても医療業界の経験はないので、実は本当に弊社のサカモトさん(仮称)に聞きながらブログを書いていました。ブログをライトな感じにするために、仮想的な登場人物を作り、会話形式で進めるタイプの手法はあるあるだと思いますが、本シリーズでは本当にサカモトさんとの会話がブログの元ネタになっています。
とはいえ、製品開発側としても、よりクリニックのインフラ構成に適したアプリケーション実装を考える必要がありますし、私自身のキャッチアップのためにも、今回はサポートチームに無理を言って実際の現地作業に同行させてもらったので、そのレポート的な感じで今回はまとめようと思います。
クリニックで行う作業によっては、1つのクリニックの中でも実はいろいろな登場人物が出てきます。特に新規開業の場合は、開院のためのプロジェクト全体を支援するクリニック向け開業コンサルタント、全体的なネットワーク設計を支援するネットワーク業者、電子カルテと電子カルテのネットワーク要件を定義する電子カルテメーカー、医療機器や業務に使う精算機などの機器メーカー、弊社のような予約システムをはじめとした様々なオンラインサービスのベンダー、そしてネットワークの物理配線業者など、色々なステークホルダーと連携しながらプロジェクトを進めます。
今回はすでに開院済みであり、電子カルテ(オンプレ版)も導入済みでしたが、予約システムとメディカル革命コネクタの導入する作業を進めるために、電子カルテのメーカーさんと連携しながら、実際の現地での作業もメーカーさんと一緒に進めました。弊社単体で進めることもありますが、今回実は電子カルテ側のネットワーク構成を一部変更する要件が出てきていて、その対応のために両者が連携した形になります。
今回は新規開院ではなく、すでに開院済のクリニックさんで、ありがたいことに弊社のオンライン予約システムの採用が決定し、そのための現地導入作業になります。予約システムはSaaS なのになぜ現地作業が必要かというと、1つは予約システムのレクチャー、つまりスタッフや医師へ、予約システムの使い方をハンズオンセミナー的な形で教えるためで、もう1つはシリーズ2回目で登場してきた、電子カルテなどのオンプレ側リソースとの連携のために使われるメディカル革命コネクタの導入作業になります。そのため、今回は現地でのレクチャー作業と並行しながら、裏側で電子カルテとの連携作業を進めます。
他にも、再来機や呼び出しディスプレイなどの設定にも現地作業は伴いますが、今回の作業としては、電子カルテ連携のためのメディカル革命コネクタの導入が主なミッションとなりました。
今回の特別な要件として、クリニックの電子カルテ閲覧用PC から予約システムを見たい、という要望がありました。ここで、前回のサカモトに聞くシリーズでお伝えした、クリニックの典型的なネットワークについておさらいしましょう。
電子カルテのある電カルLAN からは、基本的にインターネットにつなげないか、繋げたとしてもアクセスリスト等で厳密に外部接続を制御します。つまり、電カルLAN からは通常ではSaaS で提供されるメディカル革命を見ることはできませんが、信頼済みのサイトとしてアクセスコントロールリストなどを調整することで、「他のインターネットサイトは接続させないが、メディカル革命のみは信頼して接続させる」という設定をする必要があります。今回の場合その設定をするための電カルLAN 側のルーターへのアクセス権限は電カル業者のみがコントロールしていたため、そこで実際に両者での現地作業が必要となりました。
しかしながら、電カルLAN 側から予約システムを使うことは、必ずしもよい判断とは限りません。例えば今のWeb サービスのコンテンツは、クライアントサイドから見ると必ずしも単一エンドポイントとやり取りされるわけではなく、例えばアクセス高速化のためにAWS やCloudflare などのCDN サービスを経由したり、フォントを外部からダウンロードしたり、Googleアナリティクスに情報を送信したりと、実は色々なエンドポイントとの通信が必要になる場合があります。また、昨今はIP アドレスやFQDN が変わることも多いため、アクセスコントロールが複雑になり、Microsoft 365 などのプロキシやFW 設定などで悩まされる方もいらっしゃいます。つまり、Web で提供され、簡単にサービスを使えることがメリットのSaaS と、厳密なセキュリティ定義が必要となる電カルLAN は相性が良いとは言えません。
ただし、利便性の面で見てみると、電カルLAN 側から予約システムなどの便利なSaaS にアクセスしたいという要望が出てくるのも分かります。実際に現地作業に行って強く感じましたが、1人の人間が電子カルテと予約サービスを別々の端末で見る必要がある、というのは単純に面倒です。また、忘れがちですが、そもそもの物理的なスペースの制約があります。かつ電源なども限られており、スペースの関係上PC の台数をなるべく少なくしたい、という要望が出てくるのも理解できます。
つまり、一長一短ではあるものの、セキュリティと利便性のバランスを取りながら、クリニックさんでの最適な予約システムの利用を考えていく必要があります。今回は利便性を優先しつつ、なるべく問題が発生するリスクを最小限にとどめるために電子カルテメーカーさんと連携しながら作業を進めていくことになりました。
2024年10月のとある日の午後に作業があったのですが、2024年は秋の肩身がやたらと狭くなっており、案の定暑すぎたのでジャケット着用は諦めました。
今回の連携作業時間は目安として3時間を目標としていました。作業によりますが、トラブルによる延長も考慮すると2-4時間は確保することが多いです。そのため、開院後のクリニックさんで作業する場合は、基本的には休診日を作業日に選定しますので、今回も休診日にクリニックに行ったわけですが、こういったことは普段経験しないため、なかなか新鮮です。
待ち合わせ場所で当日一緒に作業してくださる電子カルテ業者さんと合流し、クリニックさんの人たちにご挨拶を済ませた後、作業開始となりました。事前にメディカル革命コネクタがインストールがしてあるPC などは配送手配済みだったので、今回の作業範囲としては、電子カルテ業者にルーターの設定を変更してもらいつつ、我々としてはメディカル革命コネクタの設置と接続、予約システムの動作確認、そして電子カルテの患者情報の予約システムへの同期をします。
さて、さっそく1つ問題が発生しました。物理的なスペースの確保です。現地に行ってみて初めて分かりましたが、PC を置くスペースの確保ができません。今回はスタッフさんの受付スペースにスタッフさん用のPC や電子カルテにアクセスする端末があり、必然的に設置スペースが限られます。残念ながらそのままだとメディカル革命コネクタ用PC と作業用PC の両方を置く場所が確保できなかったので、許可を取りながらスタッフ用PC の配置を変えつつ、奥まったスペースの配線周りを注意深く確認しながら、電源を確保し、メディカル革命コネクタPC を接続しました。
次に、事前に問題になりそうと考えていた電カルLAN からのメディカル革命閲覧ですが、案の定トラブルが発生しました。電子カルテ業者さんからルーターの設定が終わったという報告があったので、電子カルテ閲覧用PC からメディカル革命にアクセスしようとしたところ、アクセスができませんでした。楽しい(?)トラブルシューティングの始まりです。
まずは、ネットワーク構成の把握です。ここで、本クリニックさんの全体のネットワーク構成も先述したものとおおむね同じで、電カルLAN と院内LAN に分けられていることが分かりました。それに加えて、オンライン資格確認用(いわゆるマイナ保険証対応)でネットワークセグメントをもう1つ用意していました。
ただ、このようにクリニックのネットワーク構成を適切に把握するためには、電カル業者さんとの協力が不可欠です。作業前に構成図を手に入れることができればいいのですが、作業時での対応となると完璧なものが手に入るとは限りません。今回は物理構成や配線、電子カルテ業者さんからのヒアリングをしながら、現場で大体の構成を図に起こしつつ構成の整理をしました。
構成を明らかにした後で、まずは困ったときのPING です。メディカル革命へのPING をしようとしたところ、当然タイムアウトかな、と思ったらそもそも名前解決ができませんでした。そこで電子カルテ閲覧用PC のDNS サーバーの設定を見直したところ、名前解決はできるようになりました。最初の問題は解決です。
しかしながらまだPING は通っていませんし、ブラウザでもメディカル革命にアクセスできません。tracert (traceroute) でも確認しましたが、ONU 手前のルーターまでは届くのですが、そこから先が返ってきません。
ここで気を付けるのは、我々の問題なのか、電カルLAN 側の問題なのかの切り分けが難しく、さらに当然ながら機械だけではなく人が絡むので、自身の担当外の領域を疑う場合でも、丁寧なコミュニケーションが必要不可欠ということです。例えばネットワークが繋がらないからすぐに電子カルテ業者さんの設定が悪い、逆に電カルLAN 側は問題ないから予約システム側の問題でしょ、といったように勝手に決めつけてはプロジェクトはうまくいきません。ネットワーク構成図を描き、切り分けの結果を集め、それゆえにここの経路が怪しいからもう一度設定を見直してくれないですか?といったように、相手が納得して動いてくれるためのロジックと、相手にお願いをする場合でも自社側でできる作業については積極的に拾うといった前向き姿勢を相手に見せるといったある種の感情的な部分、両方がプロジェクトを前に進めるために必要となります。
ということで、今回はまずは電子カルテ業者さんからルーターのアクセス権を一時的にもらい、弊社側でもルーターの中の設定を見直しつつ、電子カルテ業者さんにはもう一度経路上のアクセスコントロールリストの設定を見直してもらいました。最終的には、アクセスコントロールリスト側の設定に誤りがあることが分かり、電子カルテ業者さんに設定を変更してもらうと、無事に接続ができるようになりました。繰り返しにはなりますが、どちらかが悪いといったことではなく(実際に弊社側の設定ミスも過去何度もありますし)、両者が協力して問題を前向きに進めていくことが重要となります。
これで万事解決、と思ったら、今度はメディカル革命の管理画面の一部コンテンツが正常に読み込まれないことが分かりました。機能自体は問題がないのですが、一部のアイコンが正しく読み込まれていません。
アイコンだけ読み込まれないということは、アイコンはCDN など別のアクセス先から取得してきている実装になっていて、そこが今回接続できていないのでは?と疑います。そこで、次のトラブルシューティングの方法として、フロントエンド開発者が愛してやまない Chrome DevTools (通称「魔法のF12」「神」など) を使います。
DevTools のNetwork タブで3rd-party requests に絞ると、クライアントがアクセスする、メディカル革命以外のアクセス先を表示できます。つまり、電カルLAN から追加でホワイトリストに含めないといけないURL が出てきます。
今回は、この中でGoogle のMaterial Symbols を使っているコンポーネントがあり、外部Material Symbols からデータの取得ができなかったことが原因でした。アクセスコントロールを見直すという手段もありますが、メディカル革命の管理画面でMaterial Symbols を使わないものに変更することができるので、それで対応しました。
これでネットワーク的な問題はすべて解決となり、最後に問題なく電子カルテの患者情報の予約システムへの同期を完了し、無事作業は終了しました(実はこの患者情報の同期でもトラブっていたことが分かったのはまた後日のこと……)。
今回の記事はいかがだったでしょうか。電子カルテ連携という1つの作業を通して、実際の医療エンジニアの業務がリアルに感じられれば嬉しい限りです。また、今回の記事を作成するにあたって協力いただいた弊社のメンバーや、作業中のいろいろな質問に快く答えてくださった某電子カルテ業者の方、また連携作業をご調整いただいたクリニックの方々に、この場を借りてお礼申し上げます。