--- title: "医療のデータ連携｜院内4方式と地域連携の構成・電子カルテ更新時の移行判断【2026年版】" url: "https://www.issoh.co.jp/column/details/16926/" published: 2026-08-25 updated: 2026-09-25 categories: ["Webシステム"] publisher: "株式会社一創" --- # 医療のデータ連携｜院内4方式と地域連携の構成・電子カルテ更新時の移行判断【2026年版】 医療のデータ連携という言葉には、院内で電子カルテと部門システムをつなぐ話、地域の医療機関どうしで診療情報を見せ合う話、国の仕組みに情報を載せる話が同居しています。この3つは、仕様を決める主体も費用の出どころも別物です。本記事では、院内で使われるHL7 v2.5・SS-MIX2・HL7 FHIR・DICOMの4方式を用途で切り分け、地域医療連携ネットワークに参加する価値が出る条件、電子カルテを入れ替えるときに連携が壊れる箇所までを扱います。API連携の仕組みとデータ連携との言葉の違いは[API連携の仕組みとデータ連携との違いを整理した解説](https://www.issoh.co.jp/column/details/15354/)に譲り、ここでは医療機関の判断だけに集中します。 ## まとめ：医療のデータ連携で先に決める4項目と着手の順序 最初に決めるのは、つなぐ相手が院内なのか、地域の他施設なのか、国の仕組みなのかという層の切り分けです。層が変われば仕様を決める主体が変わり、自院で動かせる範囲も変わります。 院内は自院が仕様を決められる領域で、患者IDの一意性とデータの粒度をそろえれば大半が片づきます。地域連携は相手先の協議会や幹事施設のベンダーが仕様を握るため、譲れない項目を先に固めてから交渉に入る順序です。全国の電子カルテ情報共有サービスは仕様の見直しが続き、2026年8月時点の公表情報では本格運用の目標が2027年1・2月頃に置かれています。 着手の順序は、患者IDとマスタの整備、院内の接続方式の選定、地域連携への参加可否の判断、全国の仕組みへの対応という4段です。この順を飛ばして地域連携から入ると、院内で名寄せできないデータを外へ出すことになり、運用が止まります。見積もりを取る前に決めるのは方式ではなく、4段のどこまでを今回の予算で買うかという範囲でした。 ## 院内・地域・全国の3層で変わる医療データ連携の相手と決定権の所在 同じ「連携」でも、誰が仕様を決めるかで難易度がまるで違います。層ごとに、自院に残る裁量を確認します。 ### 院内連携で先に決める2点：接続の粒度と患者IDの一意性を担保する範囲 院内連携でつまずく原因の多くは、規格の選定ではなく患者IDの扱いにあります。電子カルテの患者ID、検査部門の受付番号、医事会計の請求番号が別体系で振られていると、同じ患者のデータが突き合わせられません。 先に決めるのは2点です。ひとつは接続の粒度で、オーダ単位で流すのか、日次でまとめて渡すのかを区間ごとに確定させます。もうひとつは患者IDの一意性を誰が担保するかという役割で、電子カルテを親IDの発番元に固定し、部門側は自分の番号と親IDの対応表を持つ形が扱いやすい構成。医療情報システム全体の構成と部門システムの役割分担は[医療情報システムの種類と構成を整理した解説](https://www.issoh.co.jp/column/details/16039/)に譲ります。 ### 地域連携で相手先が仕様を決める範囲と自院が譲れない項目の線引き 地域医療連携ネットワークでは、接続仕様を参加施設が個別に決められません。幹事となる基幹病院とその電子カルテベンダーが決めた仕様に、参加側が合わせにいく構図です。自院が交渉できるのは、出す情報の範囲、更新の頻度、接続機器の保守を誰が負担するかの3点に限られます。ここを合意文書へ書かないまま参加を決めると、負担者が曖昧なゲートウェイ機器だけが院内に残ります。 ### 全国レベルの共有は制度側が仕様を決める前提と院内側の待ち方の基準 電子カルテ情報共有サービスや標準型電子カルテは、厚生労働省側の仕様確定が先行します。標準型電子カルテは標準仕様ver.1の公表が2026年9月、提供開始は2027年4月を目指すと報じられており、医療機関の側から仕様交渉に入る余地はありません。待ち方の基準はひとつだけで、仕様の確定に依存しない準備を先に済ませておくことです。院内のマスタ整備や患者IDの統一は、どの仕様へ落ち着いても捨てずに済みます。 ## 電子カルテと部門システムをつなぐ4方式の違いと使い分けの判断基準 院内接続で使われる方式は大きく4つです。設計された目的が違うため、どれが優れているかではなく、どの区間に何を流すかで選びます。 ### HL7 v2.5のメッセージ連携：オーダと実績をリアルタイムで流す 電子カルテから検査部門や薬剤部門へ指示を流し、結果を返す区間で長く使われてきたのが、HL7のバージョン2系のメッセージです。日本ではJAHIS標準として項目の解釈がそろえられ、v2.5が事実上の基準になっています。 この方式の性格は、発生した事象をその都度送る点にあります。オーダが出た瞬間に部門側へ届くため、検査の受付や実施の状況を院内で追えます。反面、項目をひとつ増やすたびに送信側と受信側の双方で改修と接続試験が発生し、部門システムの数だけ費用が積み上がる構造。オーダの業務フローそのものは[処方・検査オーダの流れと電子カルテ連携を扱った解説](https://www.issoh.co.jp/column/details/16873/)で整理しています。 ### SS-MIX2の標準化ストレージ：1ファイル1メッセージの蓄積型 SS-MIX2は、診療データを決められたフォルダ構成のファイルとして貯めておく仕組みです。日本医療情報学会が公開する標準化ストレージ仕様書は2024年5月16日版のVer.1.2iが最新で、格納する形式にHL7 Ver2.5、HL7 CDA R2、DICOMを定めています。 仕様上は1ファイルが1メッセージ、すなわち1オーダに対応し、複数のオーダを1つのファイルへまとめません。この作りのおかげで、電子カルテを入れ替えても過去データがベンダー非依存の形で残ります。一方、ファイルを読みに行く方式のため、外部システムへ即時に反映させる用途には向きません。二次利用のデータ基盤や施設間の受け渡しを想定した置き場です。 ### HL7 FHIRのAPI連携：JP Core実装ガイド1.2.0系を前提にする条件 HL7 FHIRは、JSONとRESTful APIという一般的なWeb技術で医療情報を交換する規格です。日本向けのHL7 FHIR JP Core 実装ガイドは、jpfhir.jpの公開バージョン履歴で正式公開版がv1.2.0（2025年7月30日公開）、その先は開発版のv1.3.0-devという状態にあります。 採用を判断する条件は2つです。外部のサービスやアプリから患者単位でデータを引きたい要件があること、そして接続先が実装ガイドの版に追随できること。版が動く規格なので、契約時に「どの版を前提にした実装か」を明記しないと、数年後の改修範囲が読めなくなります。院内の部門接続を全面的にFHIRへ置き換える必要は、2026年8月時点ではほとんどの医療機関にありません。 ### 画像系はDICOM通信：PACSと部門システムの接続で費用が動く箇所 CTやMRIなどの医用画像は、DICOMという専用の規格でモダリティとPACSの間をやり取りします。ここは他の3方式と別系統で、画像の容量がそのまま保管費用と回線設計に跳ね返る領域です。 費用が動くのは、モダリティ1台ごとの接続作業と、電子カルテからPACSの画像を参照するビューアの連携部分です。装置を更新するたびに接続確認の工数が発生する点を、更新計画の見積もりへ最初から入れておきます。容量設計の詳細は[PACSの仕組みと容量設計を扱った解説](https://www.issoh.co.jp/column/details/16201/)を参照してください。 ### 4方式の比較：改修範囲・即時性・保守負担で決める使い分けの基準 4つの方式を、実務で効いてくる観点だけで並べます。同じ院内でも区間ごとに答えが変わるため、全体で1方式に統一しないほうが費用は収まります。 | 方式 | 主な用途 | 即時性 | 改修範囲 | 保守負担 | | -------- | ------------- | --- | ---------- | ---- | | HL7 v2.5 | 院内のオーダと実績 | 即時 | 送信側と受信側の双方 | 中 | | SS-MIX2 | 二次利用と施設間の受け渡し | 蓄積後 | 出力側に集約 | 小 | | HL7 FHIR | 外部サービスとのAPI連携 | 即時 | API公開側に集中 | 中 | | DICOM | 医用画像の送受信 | 即時 | 装置とPACSの間 | 小 | 読み方はこうです。院内の指示と結果はHL7 v2.5、分析や引き継ぎのための蓄積はSS-MIX2、外部連携の入口はFHIR、画像はDICOM。業種をまたいだ連携の型そのものは[データ連携の事例を6つの型に整理した解説](https://www.issoh.co.jp/column/details/16920/)で扱っています。 ## 地域医療連携ネットワークの構成と参加コストが割に合う条件の見極め 地域医療連携ネットワークは、参加すれば紹介患者が増えるという性質の仕組みではありません。構成の違いが費用に直結するため、参加の可否は数字で判断します。 ### 集中型と分散型のサーバ構成：初期費用と5年更新費用が変わる理由 構成は大きく2種類あります。地域のセンターにサーバを置いて各施設がそこへデータを送る集中型と、各施設にゲートウェイを置いて必要なときだけ相手先へ取りに行く分散型です。 集中型は参加施設の初期費用が抑えられる代わりに、センター側の更新時期に地域全体で費用負担の議論が起きます。分散型は施設ごとに機器を持つため初期費用が乗り、5年程度の更新周期でその費用が繰り返し発生する構造。参加の可否を検討する段階で、この更新分まで含めた総額を運営主体へ確認しておきます。 ### 一方向の閲覧公開と双方向の情報共有：運用負担が分かれる3つの条件 データを出すだけの一方向であれば、院内の運用はほぼ変わりません。双方向にすると、閲覧の同意取得、閲覧履歴の管理、相手先データを診療フローのどこで参照するかという3つが、新たな運用として発生します。この3つを引き受ける体制がないまま双方向で参加すると、機能はあるのに誰も見ないという状態に落ち着きます。まず一方向で始め、閲覧の実績が出てから広げる順序が現実的です。 ### 参加を見送ってよい医療機関の条件：紹介件数と診療圏で引く線引き ここは言い切ります。他施設との紹介・逆紹介が月に数件しかなく、患者の受療行動が自院の診療圏で完結している医療機関は、地域医療連携ネットワークへの参加を見送って問題ありません。年間の保守費用に対して、閲覧される回数が見合わないためです。 参加を検討すべきなのは、救急の受け入れがあり他施設からの紹介が日常的に発生する施設、在宅や介護の事業所と情報をやり取りする施設、そして地域の基幹病院から接続を要請されている施設に絞られます。判断材料は紹介件数の実数であり、周囲の医療機関が参加しているという事実ではありません。 ## 電子カルテ情報共有サービスへの対応時期と院内改修の先行範囲の決め方 全国で診療情報を共有する仕組みは、仕様の見直しが続いています。対応そのものは避けられませんが、着手の時期は選べます。 ### 3文書6情報の中身と、院内にデータが揃っていない項目の洗い出し 共有の対象は3文書6情報です。3文書は診療情報提供書、退院時サマリ、健康診断結果報告書。6情報は傷病名、アレルギー情報、感染症情報、薬剤禁忌情報、検査情報（救急および生活習慣病）、処方情報を指します。 先にやるべきは、この9項目のうち院内で構造化して持てていないものの洗い出しです。モデル事業では感染症情報の約9割が共有されていない状態が判明し、アレルギー情報はアナフィラキシー情報から段階的に始める整理になりました。自院でも自由記載のテキストに埋もれていれば、それは制度の話ではなく入力運用の問題。 ### 本格運用が2027年1・2月頃へずれた経緯と改修計画の置き直し 本格運用の目標は、当初より後ろの時期へ動いています。2026年8月時点で公表されている流れは、見直しを踏まえた技術解説書の改版を2026年6月頃に公開し、ベンダーの改修を経て2026年10〜12月頃に再度のモデル事業で検証、2027年1・2月頃に全国展開という順序です。現行のモデル事業は全国9地域・22医療機関という規模でした。 この経緯から読み取れるのは、ベンダーの改修版が出そろう時期が後ろへ動いたという事実です。自院の電子カルテ更新をこの対応と同時に計画していた場合、更新時期そのものを見直すか、対応を後追いの改修として切り出すかの判断が要ります。 ### 待ってよい改修と先に着手すべき改修を分ける2つの判断材料の使い方 判断材料は2つです。第一に、その改修がベンダー側の対応版に依存するかどうか。第二に、仕様が変わっても価値が残るかどうか。 ベンダーの対応版に依存する改修、たとえば送信インタフェースの実装や項目のマッピングは待つ側に入れます。逆に、傷病名マスタの整理、アレルギーと感染症の入力を構造化された項目へ移す運用変更、患者IDの統一は、仕様がどう転んでも残る資産なので先に着手します。医療DX推進体制整備加算のように制度側の要件と連動する対応は、要件が確定してから動いても間に合う設計にしておくのが安全でした。 ## システム更新時に連携が壊れる箇所と移行方式を分ける判断の順序と範囲 連携が最も壊れるのは、平常運用ではなくシステムの入れ替え時です。電子カルテの普及は令和5年の医療施設調査で一般病院65.6%、400床以上で93.7%、200床未満で59.0%、一般診療所で55.0%まで進んでおり、いま起きている案件の多くは新規導入ではなく更新になっています。 ### 電子カルテ更新で真っ先に切れる接続：部門システムと外部の接続点 電子カルテを入れ替えると、ぶら下がっていた接続はすべて作り直しの対象です。検査、放射線、薬剤、栄養、リハビリといった部門システム、医事会計、地域連携ゲートウェイ、外部の検査委託先。数えると20を超える施設は珍しくありません。 見落とされやすいのは、外部の検査委託会社との接続と、院内で個別に作られた小さな連携です。手作りのファイル受け渡しやマクロは資産台帳に載っておらず、見積もりから漏れます。企画段階で接続点の一覧を作り、1本ずつ「残す・やめる・作り直す」を決める作業を先に置いてください。電子カルテ製品の選び方は[電子カルテの種類と選び方を扱った解説](https://www.issoh.co.jp/column/details/15243/)で整理しています。 ### 過去データの移行範囲：全件移行と参照専用の並行運用で分かれる条件 過去の診療データをどこまで移すかは、費用が大きく振れる論点です。全件移行は新システムだけで過去を追える代わりに、データ変換の検証工数が膨らみます。もうひとつの選択肢が、旧システムを参照専用で残す並行運用。直近数年分だけを移行し、それ以前は旧システムかSS-MIX2のストレージで参照する形にすれば、変換の対象が絞れます。分岐の条件は診療科の性質で、長期の経過を追う診療科が主体なら全件移行、外来中心で参照頻度が落ちるなら並行運用が費用に見合います。 ### 契約書に書いておく連携の責任分界：接続試験の合格条件を決める粒度 更新のトラブルは、技術ではなく責任範囲の曖昧さから起きます。電子カルテと部門システムのベンダーが別会社である以上、不具合はどちらの領分かという議論から始まってしまうためです。 契約書に落としておく項目は3つあります。接続する区間ごとの担当会社、テストデータの提供者、そして合格と判定する条件。合格条件は「疎通できること」では足りず、「オーダ送信から部門側の受信までを何件流し、差異ゼロで一致すること」といった件数と判定基準まで書きます。この粒度で書いてあるかどうかが、稼働直前の追加費用の有無を分けました。 ### ベンダーロックインが起きる箇所と、標準へ寄せて外せる範囲の限界 ロックインが起きるのは、製品そのものではなく接続の作り込みと過去データの形式です。独自形式でしか出せない状態が続くと、次の更新でも同じベンダーを選ぶしかなくなります。 外せる範囲には限界があります。SS-MIX2で標準化ストレージを持てば過去データの可搬性は確保できますが、院内の運用に密着した画面やテンプレートは標準規格の範囲外で、移行時に作り直しが発生する部分。ここを「標準に寄せれば全部持ち出せる」と考えないほうが、更新の見積もりは現実に近づきます。業種は違いますが、階層ごとにインタフェースを切り分ける考え方は[製造業のデータ連携で設備・MES・基幹を階層別に設計した解説](https://www.issoh.co.jp/column/details/16922/)と同じ構造です。 ## 医療のデータ連携を見送ってよい規模の線引きと先に直すべき業務の順番 連携の投資が回収できる規模には下限があります。つなぐ前に直したほうが効果の大きい業務があるなら、そちらが先です。 ### 見送ってよい条件：紙の運用量と接続本数、更新時期で引く3つの線 次の3つがそろう医療機関は、いま連携へ投資しなくて構いません。部門システムの接続本数が3本以下であること。転記の作業が1日あたり合計1時間に届かないこと。電子カルテの更新時期が2年以内に来ていること。 とくに3つ目が効きます。更新の直前に個別の連携を作り込むと、その投資は更新でほぼ失われるためです。更新が近いなら、連携要件は次期システムの調達仕様書へ書き込む形に切り替えたほうが、同じ金額で残るものが増えます。 ### 連携より先に直すもの：マスタ整備と入力運用をそろえる範囲と順番 連携の前に手を付けるのは、傷病名マスタと患者IDと入力運用の3点です。標準病名マスターに寄せていない傷病名が残ったまま外へ出すと、受け取る側で読み替えが必要になり、その読み替え表を誰が保守するかという問題が新たに生まれます。 入力運用も同じです。アレルギーや感染症が自由記載欄に書かれている限り、どんな規格でつないでもデータとしては出ていきません。順番としては、マスタの整理、入力項目の構造化、患者IDの統一、そこまで済ませてから接続方式の選定に入ります。医事会計側との突き合わせで詰まる場合は、[レセコンの仕組みと電子カルテとの違いを整理した解説](https://www.issoh.co.jp/column/details/15328/)で役割の境界を確認しておくと話が早く進みます。 ### 外注に出す範囲の切り分け：ベンダー間の調整と受託開発で引く責任線 連携の案件で外へ出す範囲は、大きく2つに分かれます。ひとつは電子カルテベンダーと部門ベンダーの間の調整で、これは自院か支援に入るコンサルティング側が担う領域。もうひとつが、標準規格の外側に残る変換処理や、外部システムとつなぐAPIの実装です。 後者は既製品では埋まりにくく、[医療機関向けシステム開発](https://www.issoh.co.jp/service/business%5Fsystem/medical/)のように接続部分を作る形で外注する判断になります。切り分けの目安は、電子カルテ本体に手を入れる必要があるかどうか。本体の改修が要るならベンダーの領分、本体の外側で受けて変換するなら外注で対応できます。この線を最初に引いたかどうかで、見積もりの比較が同じ土俵に乗るかが決まりました。物流で企業間の接続を扱った[物流のデータ連携で二層設計を整理した解説](https://www.issoh.co.jp/column/details/16924/)も、責任分界の引き方として参考になります。監査ログと権限の要件が連携方式を先に絞り込む業種の切り分けは[金融のデータ連携で行内と対外を切り分けた解説](https://www.issoh.co.jp/column/details/16928/)にまとめています。 ## よくある質問 医療機関のデータ連携について、検討の初期に寄せられることの多い質問をまとめました。 ### 医療機関のデータ連携にかかる費用はどのくらいですか？ 金額は接続本数と方式で決まるため一律の相場は示せませんが、費用の構造は共通しています。初回の接続作業費、毎年の保守費、更新時の再接続費という3層です。部門システム1本ごとに接続と試験が発生し、項目を追加するたびに送信側と受信側の双方で工数がかかります。見積もりを比較するときは、接続する区間の数と、試験の実施範囲がどちらのベンダーに含まれているかをそろえて確認してください。 ### SS-MIX2とHL7 FHIRはどちらを選べばよいですか？ どちらか一方を選ぶ関係ではありません。SS-MIX2は診療データを標準的な形式で貯めておく置き場で、標準化ストレージ仕様書は2024年5月16日版のVer.1.2iが公開されています。HL7 FHIRは外部とデータをやり取りするAPIの規格で、日本向けのJP Core実装ガイドは2025年7月30日公開のv1.2.0が正式版という状態。過去データの可搬性ならSS-MIX2、外部サービスと患者単位でつなぐ要件があるならFHIRという整理です。 ### 電子カルテを入れ替えると地域医療連携ネットワークとの接続はどうなりますか？ 接続は原則として作り直しになります。地域連携用のゲートウェイが院内にある場合、新しい電子カルテからそのゲートウェイへデータを渡す部分を再実装し、接続試験をやり直す流れです。ネットワークの運営主体との調整にも期間が要るため、更新の企画段階で運営側へ連絡し、作業範囲と費用負担の所在を確認しておいてください。 ### 電子カルテ情報共有サービスに対応すれば院内の連携も不要になりますか？ 不要にはなりません。電子カルテ情報共有サービスが扱うのは3文書6情報という限られた範囲で、施設をまたいだ共有を目的とした仕組みだからです。院内で電子カルテと検査・放射線・医事会計をつなぐ連携は、その外側に残り続けます。院内の連携を整えておくことが、全国の仕組みへ出すデータの品質を支える関係にあります。 ### 部門システムのデータを分析用に取り出すことはできますか？ 取り出せますが、経路の選び方で難易度が変わります。部門システムのデータベースへ直接つなぐ方法は、製品の更新でテーブル構造が変わると壊れるため保守が続きません。SS-MIX2の標準化ストレージや、部門システムが持つ標準的な出力機能を経由する経路のほうが、更新の影響を受けにくい構成です。取り出しは日次など決まった間隔にまとめると、本番系の負荷も抑えられます。 ## 関連記事 - [医療情報システムとは？種類・構成と安全管理ガイドライン第7.0版対応の判断【2026年版】](https://www.issoh.co.jp/column/details/16039/)：システム全体の構成と費用の内訳、ガイドライン対応を扱っています。 - [電子カルテとは？種類・メリットと失敗しない選び方・開発判断を解説【2026年】](https://www.issoh.co.jp/column/details/15243/)：連携の起点になる電子カルテ本体の選定基準です。 - [データ連携の事例：6つの型と業種別の制約・効果指標の置き方](https://www.issoh.co.jp/column/details/16920/)：業種をまたいだ連携の型と効果の測り方を整理しています。 - [製造業のデータ連携｜設備・MES・基幹の階層別インタフェース設計と段階導入](https://www.issoh.co.jp/column/details/16922/)：階層ごとにインタフェースを切り分ける設計の考え方です。 - [物流のデータ連携｜社内WMS・TMSと企業間EDIの二層設計と標準への寄せ方](https://www.issoh.co.jp/column/details/16924/)：社内と企業間を二層に分ける責任分界の引き方を扱っています。 --- 出典: [医療のデータ連携｜院内4方式と地域連携の構成・電子カルテ更新時の移行判断【2026年版】]()（株式会社一創）