Med-Well
2026/04/24 01:00
電子カルテ情報共有サービスには、どうやって繋ぐ？ — 3つの接続方式を調べてみた【電子カルテ情報共有サービスとMed-Well 第2回目】
はじめに
こんにちは！総合病院向けのLINE窓口システム「Med-Well（メドウェル）」を提供するコモン・クリエーションです。
本記事は「電子カルテ情報共有サービスとMed-Well」シリーズの第2回目です。
シリーズ「電子カルテ情報共有サービスとMed-Well」
「電子カルテ情報共有サービス」って何だろう？
電子カルテ情報共有サービスには、どうやって繋ぐ？ ◀ 今見ている記事
電子カルテ情報共有サービスのIF定義書を読んでみる — 診療情報提供書はどんな形？
FHIRで紹介状を書くと、こうなる — 診療情報提供書を分解してみた
電子カルテ情報共有サービスに繋ぐまでの道のり — ベンダー登録と接続テストの話
前提：オンライン資格確認ネットワークを介する
電子カルテ情報共有サービスは、一般的なインターネットから直接アクセスできるサービスではありません。通信は「オンライン資格確認ネットワーク（以下、オン資ネットワーク）」を経由します。
医療機関 ←→ オン資ネットワーク ←→ 支払基金（電子カルテ情報共有サービス）オン資ネットワークは、マイナンバーカードによる保険資格確認などで既に多くの医療機関に導入されている既存のネットワーク基盤です。電子カルテ情報共有サービスは、このネットワークの上に相乗りする形で構成されています。
つまり、インターネット上のクラウドサービスから直接繋ぎに行くことはできず、必ず医療機関の施設内にある端末やサーバーを経由する必要がある、ということです。これはこの後の接続方式を理解するうえで重要なポイントになります。
2つの接続方式
では、具体的にどうやってデータをやりとりするのでしょうか。
システムベンダ向け技術解説書によると、電子カルテシステム等から電子カルテ情報共有サービスに接続するための方式は、大きく分けて2つあります。
① ファイル連携方式
支払基金が提供する「オンライン資格確認等連携ソフト」を使った方式です。
仕組みはシンプルで、資格確認端末や電子カルテサーバー上の所定のフォルダにXML形式の要求ファイルを配置すると、連携ソフトが自動的にそのファイルを検知して電子カルテ情報共有サービスのAPIを呼び出し、結果ファイルを同じフォルダに返してくれる、というものです。
この方式には、さらに2つのパターンがあります。
クライアントOS対応連携ソフト構成
既に設置されているオンライン資格確認用のWindows端末（資格確認端末）に連携ソフトを載せて、そこ経由でファイル連携する方法です。既存のインフラをそのまま活用できるのがメリットです。ただし、資格確認端末に接続できるセッション数にはWindowsの制約上、最大20セッションという上限があるため、端末台数が多い大規模病院では注意が必要です。サーバーOS対応連携ソフト構成
連携ソフトをサーバーOS（Windows Server）にインストールして、電子カルテサーバー側でファイル連携を行う方法です。資格確認端末を経由しないため、大規模病院向きの構成です。なお、サーバーにも資格確認端末とは別に電子証明書（機関認証用）を発行・インストールする必要があります。
② Web API通信方式
電子カルテシステム等の端末またはサーバーから、電子カルテ情報共有サービスが提供するAPIを直接呼び出す方式です。
ファイル連携方式では連携ソフトがAPIコールを仲介してくれますが、Web API通信方式ではシステム側で直接APIを叩きにいくことになります。その分、実装の自由度は高くなりますが、ネットワーク機器（ルータなど）の追加設定やIPアドレスの追加対応が必要になります。
また、電子署名をカードレス方式で行う場合には、オン資ネットワーク経由でMEDIS（医療情報システム開発センター）が提供する鍵管理サービスにWeb APIで接続する必要もあります。
※ ただし、現時点（2026年4月時点）ではクライアント認証のAPI化は検討中段階で未実装であり、事実上、クラウドサーバーが直接オン資ネットワークに接続することはできず、オン資ネットワークへ接続可能なオンプレミスサーバーからAPIを呼び出す必要があります。
処理の流れ（ファイル連携方式の場合）
ファイル連携方式の基本的な処理の流れを整理すると、次のようになります。
電子カルテシステム等が、所定のフォーマットに沿った要求ファイル（XML）を作成する
資格確認端末または電子カルテサーバーの共有フォルダに要求ファイルを配置する
連携ソフトがファイルを検知し、電子カルテ情報共有サービスのAPIを自動的に呼び出す
処理結果が結果ファイルとして同じフォルダに返される
電子カルテシステム等が結果ファイルを読み込む
文書情報（診療情報提供書など）はFHIR形式のJSON、臨床情報や健診文書は従来と同じXMLまたはPDFで取得できます。なお、診療情報提供書は紹介元が添付したPDF形式のファイルも確認可能です。
クラウドSaaSベンダーにとっての課題
ここからがMed-Wellのような予約SaaSにとって特に重要なポイントです。
先ほど述べたとおり、電子カルテ情報共有サービスはオン資ネットワーク経由でしかアクセスできません。どの接続方式を選んでも、施設内に電子証明書（機関認証用）が入った端末またはサーバーが必要です。
技術解説書にも、SaaS型の電子カルテシステム等については「施設内の電子証明書（機関認証用）の入った端末もしくはサーバーを経由した接続が現状では必要」と明記されています。施設内の端末やサーバーを経由しないクラウド直接接続の仕組みは「今後検討予定」とされているものの、現時点では利用できません。
つまり、クラウドから直接電子カルテ情報共有サービスに繋げる構成は、今のところ想定されていないということです。
ではクラウドSaaSが接続するにはどうすればいいか。現時点で考えられるのは、院内にローカルブリッジとなるツールやエージェントを配置して、クラウドと資格確認端末（または連携サーバー）の橋渡しをする構成です。たとえば、クラウド側で生成したデータを院内のブリッジツールが受け取り、連携ソフトが参照するフォルダに配置する、といった流れです。
クラウドSaaSベンダーにとっては、クラウド側の開発だけでは完結せず、施設側にも何らかのコンポーネントを導入する必要がある。この点は導入計画や運用設計において、あらかじめ意識しておく必要があります。
Med-Wellとしての関わり
Med-Wellは診療予約や患者コミュニケーション、地域医療連携の入り口を担うクラウドサービスです。
電子カルテ情報共有サービスへの接続は、従来の予約業務の延長線上にある取り組みです。たとえばクリニックから中核病院への紹介予約と一緒に、診療情報提供書を電子的にやりとりできるようになれば、紹介・逆紹介の業務がよりスムーズになります。
現時点では、施設側にローカルブリッジを配置するアプローチで接続方式を検討しています。まだ道のりの途中ではありますが、この流れに対応していくことは重要なテーマだと考えています。
結び
今回は、電子カルテ情報共有サービスに「どうやって繋ぐか」のシステム構成を整理しました。
ファイル連携方式とWeb API通信方式という2つの方式があり、いずれもオン資ネットワーク経由の接続が前提になっていること。そして、クラウドSaaSにとっては施設側のローカルブリッジが現時点で必要になること。このあたりが、今回の主なポイントです。
次回は、実際にやりとりされるデータの中身に踏み込みます。外部インターフェイス定義書を参照しながら、診療情報提供書がどんな構造になっているのかを見ていきます。
Med-Wellは、LINEを活用した予約や呼び出し、患者コミュニケーションの仕組みを提供しています。電子カルテに依存しない形で現場の課題を解決しつつ、今後の情報連携にも対応していきます。
ご興味のある方は、お気軽にお問い合わせください。