医療情報システムという言葉は、電子カルテ単体を指す場面と、オーダリング・レセコン・部門システムまで含めた院内全体を指す場面の両方で使われています。この二つを混ぜたまま見積もりを取ると、ベンダーごとに前提の範囲が食い違い、金額の比較が成立しません。本記事では、医療情報システムの種類と院内を流れる情報の経路を整理したうえで、2026年9月時点で厚生労働省が公開している安全管理ガイドライン第7.0版、および提供事業者向けの第2.0版が求める責任分界を確認します。続いて、電子カルテ情報共有サービスへの接続準備として、SS-MIX2の格納データを数えるスクリプトと、HL7 FHIRの検証用サーバーで患者情報を往復させる手順をコード付きで示しました。最後に、標準パッケージのままで足りる医療機関と、受託開発や連携開発に踏み込むべき医療機関を条件付きで切り分けます。個別製品の種類や選定基準そのものは電子カルテとは何かを整理した記事が扱う領分なので、ここでは院内システム全体の構成設計と発注スコープに絞ります。
まとめ：医療情報システムの構成整理と第7.0版対応で先に決める3点
- 医療情報システムは電子カルテ・オーダリング・レセコン・部門システムの総称で、病院情報システム（HIS）とほぼ同義に使われます。見積もり依頼の前に、自院がどの範囲を指しているかを文書で定義してください。
- 院内の情報は「受付→オーダー→実施→記録→会計→レセプト請求」の一本の線で流れます。この線のどこで職員が手入力や紙の転記をしているかを洗い出すと、連携開発の対象がそのまま特定できます。
- 厚生労働省の安全管理ガイドラインは、2026年9月時点の現行版が第7.0版です。概説編・経営管理編・企画管理編・システム運用編に保守委託機関編が加わり、保守や運用を委託する相手にも読ませる編が用意されました。令和8年9月にはQ&Aも出ています。
- 事業者側は経済産業省・総務省の「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」第2.0版（令和2年8月策定、令和7年3月改定）が受け持ちます。両者を合わせた通称が3省2ガイドラインです。
- 電子カルテ情報共有サービスは、令和8年度冬頃からの運用開始が目標とされています。接続準備の第一歩は、既存システムから標準形式で何件のデータを取り出せるかを実測することで、SS-MIX2の格納ファイルを数えれば半日で見当が付きます。
- 費用は初期・月額・更新の3層で見ます。見積もりから抜け落ちやすいのは、旧システムからのデータ移行の変換費と、既存の部門システム側に発生する改修費の2つでした。
- 標準パッケージのままで運用が回るのは、無床診療所で外部接続が検査会社1系統に収まる場合です。受託開発や連携開発が見合うのは、部門システムが複数系統あり、二重入力の実測時間から算出した回収年数が3年以内に収まる場合です。
医療情報システムの定義と病院情報システム（HIS）との呼び分け
同じ言葉が指す範囲が人によって違うと、要件定義は最初の打ち合わせで空転します。範囲の確定から始めます。
医療情報システムが指す範囲と電子カルテ単体との境界線の引き方
医療情報システムは、診療・看護・検査・投薬・会計といった医療機関の業務で発生する情報を電子的に記録し、部門をまたいで受け渡す仕組みの総称です。電子カルテはその中核を担う1コンポーネントにすぎません。厚生労働省の安全管理ガイドラインも、規制の対象を電子カルテ製品ではなく「医療情報システム」という括りで置いており、院内ネットワーク、端末、外部委託先までが射程に入ります。2026年度改定で新設された加算がこの準拠を施設基準に組み込んだ経緯は、診療報酬改定2026の加算再編とシステム要件で扱っています。
実務上の境界線は、患者情報を保持するか、他システムと患者IDで結びつくかの2点で引けます。この基準に照らすと、勤怠管理や会計ソフトは対象外、検体検査システムやPACSは対象内という切り分けになります。範囲を狭く定義しすぎると、監査で指摘を受けたときに管理台帳の作り直しが発生しました。台帳は最初から広めに作るほうが手戻りが少なく済みます。
病院・有床診療所・無床診療所で必要なシステム構成が変わる要因
構成を左右するのは病床の有無と外部接続の本数です。無床診療所であれば、電子カルテとレセコン、外部の検査会社との結果連携までで完結する例が大半を占めます。有床診療所や中小病院になると、入退院管理、給食、看護記録が加わり、部門システムの数が一段跳ね上がります。病棟のバイタル測定器やナースコール、医療機器の稼働監視といった院内IoTを電子カルテへつなぐ構成は医療IoTシステムの院内構成を扱った記事で詳しく整理しています。
規模の差は導入率にも表れています。厚生労働省が医療施設調査をもとにまとめた電子カルテの普及状況の推移（令和8年3月の検討会資料）では、令和5年の電子カルテ導入率が一般病院65.6%、一般診療所55.0%でした。病床規模別では400床以上が93.7%、200〜399床が79.2%に達する一方、200床未満は59.0%にとどまります。未導入が残っているのは小規模施設です。電子カルテとレセコンを1製品にまとめるか別製品で連動させるかという構成タイプの選択については、一体型と連動型の違いを比較した記事で判断軸を整理しています。
電子カルテ・オーダリング・レセコン・部門システムの役割分担と連携経路
構成要素は4つに分けて捉えると、責任の所在と連携箇所が同時に見えます。先に種類の全体像を一覧にしておきます。
| 種類 | 主な役割 | 主な規格・接続 |
|---|---|---|
| 電子カルテ | 診療経過・所見・処方の記録 | SS-MIX2出力、HL7 FHIR |
| オーダリング | 検査・投薬・処置の指示伝達 | HL7 v2.5メッセージ |
| レセコン | 点数算定・窓口負担・請求 | オンライン請求、点数マスタ |
| PACS・RIS | 医用画像の保存と撮影管理 | DICOM |
| 検体検査 | 採血・尿検査の結果取り込み | 外部検査会社との結果連携 |
| 薬剤・給食 | 処方監査、食事オーダー | 医薬品コード、病棟連携 |
診療記録を担う電子カルテと検査・処方指示を流すオーダリングの分業
電子カルテが受け持つのは、診療の経過・所見・処方内容といった記録の作成と保存です。オーダリングシステムは、医師が出した検査・投薬・処置の指示を、検査室や薬剤部といった実施部門へ電子的に伝える伝票の役割を担います。歴史的にはオーダリングが先に普及し、そこへ記録機能を載せる形で電子カルテが広がりました。オーダリング側の定義と、処方・検査・放射線でオーダが流れる経路はオーダリングシステムとは？処方・検査オーダの流れと電子カルテ連携・規模別の導入判断で整理しています。
現在の製品は両者を統合して提供するものがほとんどです。ただし内部では別モジュールとして分かれており、ライセンス体系や改修範囲もモジュール単位で切られます。見積書に「オーダリング」の行が独立していたら、それは統合製品でも別課金の対象という意味になります。
医事会計を担うレセコンから月次レセプト請求までのデータの流れ
レセプトコンピュータ、いわゆるレセコンは、診療行為を診療報酬点数に変換し、患者の窓口負担額を計算したうえで、月次のレセプト（診療報酬明細書）を作成します。審査支払機関へのオンライン請求まで担う位置づけです。点数マスタの更新が改定のたびに必要になるため、保守契約が事実上の必須要件になります。
電子カルテとレセコンの接続点は「実施情報」です。実施済みの処置・投薬が会計側へ落ちなければ、算定漏れがそのまま収入減として跳ね返ります。ここが手作業の転記になっている医療機関は珍しくありません。医事側の製品選定と系統の違いはレセコンの仕組みと電子カルテとの違いを解説した記事にまとめました。
PACS・検体検査・薬剤など部門システムとの接続点と連携方式
部門システムは、特定の診療科や部門の業務に特化して動く周辺システム群です。代表例を接続の重さ順に並べると次のようになります。
- PACS（医用画像管理システム）：CT・MRI・X線の画像を保存し参照させる。DICOM規格で装置と接続し、データ量が最大になる（PACSとは？仕組みと容量設計・導入判断）
- 検体検査システム：採血・尿検査の結果を取り込む。外部の検査会社との接続が発生し、外部通信の管理対象になる
- 放射線科情報システム（RIS）：撮影予約と実施記録を管理し、オーダリングとPACSの間をつなぐ
- 薬剤部門システム：処方監査、調剤支援、在庫管理を担う。医薬品コードの整合が課題になりやすい
- 給食・栄養管理システム：入院患者の食事オーダーを受け取る。有床施設でのみ必要になる
接続の重さは一律ではありません。まず押さえるべきは、患者IDの突合方式と、結果を返す経路が自動か手動かの2点です。この2点が決まれば、残りの詳細は要件定義の後半で埋められます。画像連携を実装する側でタグ構造や通信方式まで踏み込むなら、DICOMのタグ構造とDIMSE通信・DICOMwebを実装者目線で解説した記事が技術面を理解するための手引きです。画像部門の製品を実際に並べて選ぶ段階の判断軸は、医用画像システムの製品タイプ別比較と見積もりの前提にまとめています。
安全管理ガイドライン第7.0版と3省2ガイドラインで問われる責任分界
規制文書は医療機関向けと事業者向けの2系統に分かれています。どちらを誰が読むかを最初に決めます。
安全管理ガイドライン第7.0版の5編構成と保守委託機関編の新設
厚生労働省の「医療情報システムの安全管理に関するガイドライン」第7.0版の掲載ページには、2026年9月時点で概説編・経営管理編・システム運用編（令和8年6月）、企画管理編（令和8年5月）、保守委託機関編が並んでいます。同じページにはチェックリストとそのマニュアル（令和8年6月）、令和8年9月発出のQ&Aも置かれました。編ごとに読み手を分ける設計は第6.0版から引き継がれており、経営管理編は経営層、企画管理編はシステム担当、システム運用編は実務担当が読む建て付けになっています。各編の中身と、運用管理規程などの規程類をどの章に対応させて整えるかは安全管理ガイドライン第7.0版の読み方を解説した記事にまとめました。
第7.0版で目を引くのが保守委託機関編です。保守や運用を担う委託先が読む編が独立して置かれたことで、契約書に「ガイドライン遵守」とだけ書いて済ませる運用が通りにくくなりました。委託先の作業手順まで含めて確認する必要があります。委託先の選定時には、どの編を読み込んでいるかを提案書で示させると、力量の差がそのまま表面化しました。画像を院外の読影医へ渡す場面での委託先管理は、遠隔読影で院外へ画像を出すときの委託先管理にまとめています。
提供事業者向けガイドライン第2.0版が求める合意事項の書き方
ベンダーやクラウド事業者の側が従うのは、経済産業省と総務省が所管する「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」です。令和2年8月に策定され、令和7年3月28日に第2.0版が総務省の報道発表とあわせて公表されました。かつては経済産業省と総務省が別々のガイドラインを出していたため3省3ガイドラインと呼ばれていましたが、この統合以降は3省2ガイドラインという呼称に変わっています。呼称の変遷と第7.0版での改定点を細かく追う場合は、3省2ガイドラインの改定点と3省3ガイドラインとの違いを整理した記事が詳しく扱っています。
この文書が繰り返し求めるのは、医療機関と事業者の間で「何をどちらが実施するか」を合意し、文書化することです。第2.0版の改定では、対象事業者の明確化と、合意内容の明確化、リスクコミュニケーションの実効化が柱に据えられました。対象事業者の範囲や事業者が負う義務、第5章のリスクマネジメントは提供事業者向け安全管理ガイドライン第2.0版の解説記事で詳しく扱っています。抽象的な準拠表明ではなく、バックアップの取得頻度、障害時の復旧目標時間、ログの保存期間、監査への協力範囲といった単位まで落とし込んで初めて合意になります。
クラウド利用時に契約書へ落とし込む責任分界点の記述と粒度の目安
クラウド型の医療情報システムでは、物理的なサーバー管理を事業者が握るため、医療機関側で実施できない項目が生じます。ここを曖昧にしたまま契約すると、インシデント発生時に双方が相手の責任だと主張する状態に陥ります。契約書または覚書には、少なくとも次の粒度で書き分けてください。
- データの保存場所と国内保管の可否、再委託先の有無と所在地
- バックアップの取得間隔、世代数、復元試験の実施頻度と実施者
- 障害発生時の連絡経路、一次切り分けの担当、復旧目標時間
- アクセスログの取得項目、保存期間、医療機関からの開示請求への応じ方
- 契約終了時のデータ返還形式と、事業者側での消去証明の発行
5番目の契約終了時の扱いは、締結時に議論されないまま流されがちです。乗り換えを検討した段階で、標準形式での一括出力に別途費用が必要と判明する例が起きています。返還形式は締結前に決めておくほうが安全でした。後述のSS-MIX2やHL7 FHIRを返還形式として指定しておけば、次のベンダーへの引き継ぎで変換費を抑えられます。
HL7 FHIR・SS-MIX2・電子カルテ情報共有サービスへの接続準備
規格対応は将来の乗り換えコストを左右します。何を前提に発注するかを決めます。
HL7 FHIRとSS-MIX2の使い分けと院内に残る独自項目の扱い
SS-MIX2は、患者基本情報・処方・検査結果といったデータを決められたフォルダ構成のファイルで蓄積する国内の標準化ストレージ規格です。日本医療情報学会が構成の説明と構築ガイドライン Ver.1.2i（2024年5月16日版）を公開しており、中身はHL7 Ver.2.5形式のメッセージです。既存の電子カルテからデータを取り出す出口として広く実装されています。対してHL7 FHIRは、リソース単位でデータを定義しWeb APIでやり取りする国際規格で、施設間の情報共有や外部サービス連携を担います。
両者は競合ではなく、院内の蓄積がSS-MIX2、外部との交換がHL7 FHIRという役割分担で共存します。国内でFHIRを使うときの共通ルールは、日本医療情報学会のWGが作成するJP Core実装ガイドにまとまっており、2026年9月時点で公開ページに1.2.0（2025年7月30日、FHIR 4.0.1ベース）が正式版として掲載されています。どちらを使っても、院内で独自に運用してきた項目は標準の枠に収まりません。独自項目は無理に規格へ押し込まず、標準項目と拡張項目を分けて管理する方針を要件定義の段階で決めておくと、後続の改修が軽くなります。
電子カルテ情報共有サービスで医療機関間に共有される文書と情報の範囲
電子カルテ情報共有サービスは、医療機関の電子カルテに記録された情報の一部を、患者の同意のもとで全国の医療機関等が閲覧できるようにする仕組みです。厚生労働省の電子カルテ情報共有サービス概要案内 2.1.0版（令和8年7月）では、できることとして診療情報提供書・退院時サマリー・健康診断結果報告書と、傷病名・感染症・薬剤アレルギー等・その他アレルギー等・検査が並んでいます。退院時サマリーは診療情報提供書の添付として送受信する位置づけで、健診文書は別の登録・閲覧サービスとして整理されました。2文書5情報の最新の整理と送信データの組み方は電子カルテ情報共有サービスの2文書5情報のFHIR送信と接続方式の解説で扱っています。
開発側の仕様は、FHIR IGポータルに掲載された「2文書6情報電子カルテ情報共有サービス実装ガイド（CLINS-IG）」で追います。2026年9月時点の最新はVer.1.13（2026年8月31日公開）です。解説記事の多くは「3文書6情報」という初期の呼び方のままなので、要件定義書には実装ガイドの版番号と日付を書いておくと、ベンダー間で前提がずれません。スケジュールは、令和7年2月からモデル事業を順次開始し、令和8年度冬頃からの運用開始を目標とする段階です（同概要案内）。医療機関向けの最新資料は厚生労働省の医療機関等向けページに集約されています。制度と導入時期の関係については医療DXの3本柱を整理した記事を参照してください。
接続要件を要件定義書に書き込む際の記載単位と受け入れ試験の条件
要件定義書に書くときは、規格名だけを書いても検収できません。「HL7 FHIR対応」ではなく、対象とする文書・情報の種類、準拠する実装ガイドの版、送信の契機、失敗時の再送方式、標準コードへの変換責任者まで分解して記載します。受け入れ試験では、実データを模した検証用データで往復の送受信を通し、コード変換の欠落件数をゼロで確認する条件を入れてください。この条件を契約前に合意しておくと、稼働後の追加費用の交渉を避けられます。往復の確認は、次の章の手順で発注前に自院でも試せます。
SS-MIX2の格納データを数えてFHIR連携の対象範囲を実測する手順
連携開発の見積もりは、取り出すデータの件数と種類で大きく動きます。ベンダーに聞く前に、自院のSS-MIX2ストレージを数えておくと、提案の妥当性を自分で確かめられます。
標準化ストレージのフォルダー構成とファイル命名規則を確かめる
SS-MIX2の構築ガイドラインでは、ルートフォルダーの下に患者IDを3文字ずつ区切った3階層を置き、その下に患者IDフォルダー、診療日フォルダー（YYYYMMDD形式、患者基本情報は「-」）、データ種別フォルダーの順に並べます。ファイル名は「患者ID_診療日_データ種別_オーダNo_発生日時_診療科コード_コンディションフラグ」をアンダースコアで結んだ形で、拡張子は付けません。
数えるときに見落としやすいのが末尾のコンディションフラグです。1が有効、0が無効（削除）、2が過去履歴を表し、ファイルは物理削除せず履歴として残す方針なので、単純にファイル数を数えると修正前の版まで重複して拾います。データ種別はADT-00（患者基本情報）、OMP-01（処方オーダ）、OML-11（検体検査結果通知）、PPR-01（病名）といったコードで分かれています。
Pythonでデータ種別ごとの有効ファイル数を数えるスクリプト
次のスクリプトは標準ライブラリだけで動き、データ種別ごとに有効ファイルと履歴ファイルの件数を出します。本番ストレージへは読み取りだけを行い、実行は複製したボリュームか、院内の閲覧権限を持つ端末で行ってください。
# ssmix2_inventory.py
# 使い方: python ssmix2_inventory.py 標準化ストレージのルートフォルダー
import os
import sys
from collections import Counter
root = sys.argv[1]
valid = Counter() # コンディションフラグ1（有効）
history = Counter() # コンディションフラグ0（無効）と2（過去履歴）
patients = set()
for dirpath, dirnames, filenames in os.walk(root):
for name in filenames:
parts = name.split("_")
if len(parts) != 7:
continue # 命名規則に合わないファイルは数えない
pid, day, dtype, order_no, occurred, dept, flag = parts
patients.add(pid)
if flag == "1":
valid[dtype] += 1
elif flag in ("0", "2"):
history[dtype] += 1
print(f"患者数: {len(patients)}")
for dtype in sorted(set(valid) | set(history)):
print(f"{dtype}\t有効 {valid[dtype]}\t無効・過去履歴 {history[dtype]}")
出力のうち、共有対象に関わるのは病名（PPR-01）、アレルギー（ADT-61）、検体検査結果（OML-11）の行です。ここがゼロ件なら、電子カルテ側がSS-MIX2へ出力していない種別があるという意味で、連携方式の議論より先に出力設定の確認が要ります。件数が多いのに患者数が少ない場合は、同じオーダの修正が繰り返されている可能性があり、移行時の変換ルールに影響します。
検証用FHIRサーバーでJP Core準拠のPatientを登録して検索する
FHIR側の往復は、オープンソースのHAPI FHIR JPA Server StarterをDockerで起動すると手元で試せます。READMEの手順どおり、起動後は http://localhost:8080/fhir/ がベースURLになります。作成・更新・検索・$validateまでのcurlの手順はFHIRとは？JP Coreのリソース構造とHAPI FHIRで試すREST APIの実例にまとめています。
docker run -p 8080:8080 hapiproject/hapi:latest
登録する患者データは、HL7 FHIR R4のPatientリソースにJP Coreのプロファイルを指定して作ります。プロファイルのURLはJP Core Patientの定義ページに記載された値です。患者番号のsystemは、JP Coreの識別子一覧で urn:oid:1.2.392.100495.20.3.51. に枝番を付ける仕様とされているので、下の例の末尾は仮の値として自院の番号へ置き換えてください。
{
"resourceType": "Patient",
"meta": {
"profile": ["http://jpfhir.jp/fhir/core/StructureDefinition/JP_Patient"]
},
"identifier": [
{ "system": "urn:oid:1.2.392.100495.20.3.51.19999999999", "value": "00000123" }
],
"name": [ { "use": "official", "family": "山田", "given": ["太郎"] } ],
"gender": "male",
"birthDate": "1970-01-01"
}
上の内容を patient.json として保存し、登録と検索を続けて実行します。検索で登録した1件が返れば往復は成立しています。
curl -s -X POST -H "Content-Type: application/fhir+json" \
--data @patient.json http://localhost:8080/fhir/Patient
curl -s "http://localhost:8080/fhir/Patient?identifier=urn:oid:1.2.392.100495.20.3.51.19999999999|00000123"
この構成で確かめられるのは、リソースの形と検索の往復までです。JP Coreへの適合やCLINS-IGの制約を満たすかどうかは、実装ガイドのプロファイルを読み込んだバリデータで別に検証します。ベンダーの受け入れ試験でも、どの版のプロファイルで検証したかを試験記録に残させてください。
医療情報システム導入費用の内訳と見積もり比較で抜け落ちやすい項目
金額の妥当性は総額では判断できません。層に分けて並べ替えると、ベンダー間の差が見えます。
初期費用・月額費用・5年更新費用の3層に分けた費用構造の見方
医療情報システムの支出は、導入時に一度発生するもの、毎月継続するもの、数年ごとに再発生するものの3層で構成されます。オンプレミス型は初期に厚く、クラウド型は月額に寄る形になりますが、5年から7年の総額で並べると差が縮まる例が多く見られました。
| 費用の層 | 主な項目 | 見落としやすい点 |
|---|---|---|
| 初期費用 | ライセンス、サーバー、端末、設置作業 | 院内LANの敷設工事が別枠 |
| 初期費用 | データ移行、マスタ設定、操作研修 | 紙カルテのスキャン代行費 |
| 月額費用 | 保守、点数マスタ更新、回線、クラウド利用料 | 端末台数での従量課金 |
| 更新費用 | ハード更改、OS更新、バージョンアップ | 5年目に初期費の相当額が再発 |
| 連携費用 | 部門システムとの接続開発、規格対応 | 既存側の改修費は別ベンダー |
更新費用の層を初期の検討から外すと、5年目に想定外の支出が立ち上がります。提案を受け取った時点で、5年総額と7年総額の2本を出させてください。この形にそろえると、初期値引きの厚いオンプレミス提案とクラウド提案の優劣が逆転する場合があります。
複数ベンダーの見積もり比較で前提条件をそろえるための確認項目
比較が成立しない最大の原因は、各社が想定する範囲の違いです。依頼時に次の前提を明示して統一すると、金額が同じ土俵に乗ります。
- 接続する部門システムの名称・バージョン・ベンダー名を一覧で提示する
- 移行対象データの期間と件数、移行しない範囲を明記する（前章のスクリプトの出力をそのまま添付できる）
- 同時利用する端末台数と、外来・病棟の内訳を指定する
- 研修の実施回数と対象職種を指定し、追加分の単価も出させる
- 保守の対応時間帯と、時間外対応の可否・追加料金を書かせる
特に効くのが1番目です。既存の部門システム側にも改修が発生する場合、その費用は電子カルテのベンダーの見積書には載りません。既存ベンダーへ個別に確認しない限り総額は確定しないため、この確認は必ず並行して進めてください。
パッケージ導入と受託開発・連携開発を分ける判断基準と見送る場面
ここは条件で言い切れる領域です。規模と接続本数で線を引きます。パッケージ・クラウド型・受託開発の3方式を表で並べた比較と、開発会社に確認する項目は医療システム比較｜パッケージ・クラウド・受託開発の違いと開発会社の選び方にまとめています。
標準パッケージのままで運用が回る医療機関の条件と見極めの手順
標準パッケージで完結させるべき条件は明確です。無床の診療所であり、外部接続が検査会社1系統に収まり、レセコンが電子カルテと同一製品または同一ベンダーの連動製品であること。この3条件がそろうなら、開発には踏み込まない判断が正解になります。パッケージ側の運用手順に業務を合わせるほうが、総コストも障害時の復旧速度も有利でした。
厚生労働省は、この層に向けた製品の要件もそろえ始めています。令和8年3月31日に中小病院向け・医科診療所向けの電子カルテ及びレセプトコンピュータ標準仕様書（基本要件）第1.0版が公表され、電子カルテ情報共有サービスと電子処方箋への対応、クラウド型での提供、標準APIの搭載、データ引き継ぎの互換性確保といった要件が示されました。製品選定では、この標準仕様書への対応状況を提案書で確認すると比較が速くなります。開業初期でカスタマイズ要望が固まっていない段階なら、まず標準機能で運用し、不足が具体化してから改修を検討する順序を推奨します。
受託開発や連携開発に踏み切る条件と投資回収期間の見積もりの型
踏み込むべきなのは、部門システムが複数系統あり、そのうち1つ以上が電子カルテと自動連携していない医療機関です。判断材料には感覚ではなく実測値が必要です。まず、二重入力や紙からの転記に費やしている時間を職種別に1週間実測し、年間の人件費に換算します。次に、その作業を解消する連携開発の見積額を取り、回収年数を割り出します。3年以内に収まるなら投資判断は成立し、5年を超えるなら見送りが妥当です。
部門システム間をつなぐ接続開発は、既存の製品を入れ替えずに二重入力だけを解消できる点で、費用対効果が読みやすい領域です。当社では既存システムを残したまま、患者IDの突合と結果返却の経路を設計する連携開発を医療機関向けシステム開発として請け負っており、電子カルテ本体の更改を待たずに着手できます。既存ベンダーが仕様を開示しない場合でも、SS-MIX2などの出力ファイルを経由する方式で回避できる例が多くあります。
開発に踏み込むと失敗する条件と見送りを選ぶべき3つの具体的場面
開発を選ばないほうがよい場面を、条件付きで挙げます。第一に、既存の電子カルテが2年以内に更改を控えている場合です。連携先の仕様が変わるため、開発した接続部分がそのまま捨てられます。更改後に着手してください。
第二に、要望を出しているのが特定の1名だけで、部門としての合意が取れていない場合。この状態で作った機能は、担当者の異動とともに使われなくなります。第三に、業務手順の見直しで解消できる転記作業を、そのままシステム化しようとしている場合です。紙の運用を電子に置き換えるだけの開発は、投資に見合いません。運用側で消せる工程を先に消し、それでも残る接続だけを開発対象にする順序が結果的に安く付きました。
よくある質問
導入検討の初期に寄せられる質問を、判断に直結するものから順に整理しました。
医療情報システムと電子カルテは何が違いますか？
電子カルテは医療情報システムを構成する要素の1つです。医療情報システムは、電子カルテに加えてオーダリング、レセコン、PACS、検体検査システムなど、院内で患者情報を扱う仕組み全体を指します。病院情報システム（HIS）もほぼ同義で使われる呼称です。安全管理ガイドラインが規制の対象としているのも製品単体ではなくこの全体であり、ネットワークや端末、外部委託先までが管理の範囲に入ります。見積もりを依頼するときは、どちらの意味で言っているかを先に定義してください。
3省2ガイドラインとは何を指しますか？
医療機関向けの厚生労働省「医療情報システムの安全管理に関するガイドライン」と、事業者向けの経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」の2本を合わせた通称です。かつて経済産業省と総務省が別々に出していた時期は3省3ガイドラインと呼ばれていましたが、2020年に事業者向けが1本へ統合されました。2026年9月時点では前者が第7.0版、後者が第2.0版です。医療機関が読むべきは前者で、後者はベンダーの提案内容を評価する物差しとして使います。
医療情報システムの導入費用はどのくらいかかりますか？
金額は施設規模と部門システムの接続本数で大きく変わるため、相場を単一の数字で示すことはできません。判断に使えるのは費用の構造です。初期費用、月額費用、5年前後で再発する更新費用の3層に分け、さらに部門システムとの連携費用を別枠で見積もらせてください。オンプレミス型は初期が厚く、クラウド型は月額に寄りますが、5年総額と7年総額で並べると差が縮まります。提案を受け取ったら、この2本の総額を必ず出させて比較してください。
クラウド型の医療情報システムでもガイドラインに準拠できますか？
準拠できます。厚生労働省のガイドラインはクラウド利用を前提に整理されており、提供事業者向けの第2.0版もクラウドサービスの責任分界を扱っています。標準仕様書（基本要件）もクラウド型での提供を要件に含めました。条件は、医療機関と事業者の役割分担を文書で合意することです。データの保存場所と再委託先、バックアップの間隔と復元試験、障害時の連絡経路と復旧目標時間、ログの保存期間、契約終了時のデータ返還形式まで書き分けてください。事業者側が第2.0版に沿った説明資料を用意できるかどうかは、選定時の判断材料になります。
既存の部門システムを残したまま電子カルテだけ入れ替えられますか？
可能ですが、既存側の改修費が別途発生する点に注意が必要です。部門システムのベンダーが接続仕様の変更に対応する工数は、電子カルテのベンダーの見積書には含まれません。両社へ並行して確認しないと総額が固まらないため、入れ替えの検討段階で既存ベンダーにも接続要件を提示してください。仕様が開示されない場合は、SS-MIX2などの出力ファイルを経由する方式で連携を成立させる選択肢もあります。入れ替え前に格納データの件数を数えておくと、移行範囲の交渉で根拠として使えます。
関連記事
- 電子カルテとは？種類・メリットと失敗しない選び方：中核となる製品タイプと選定基準を整理しています。
- レセコンとは？仕組み・電子カルテとの違い・種類と選び方：医事会計側の仕組みと請求までの流れを扱っています。
- 電子カルテ義務化はいつから？2030年普及率100%目標と対応判断：制度の法的位置づけと導入時期の判断をまとめています。
- 電子カルテの補助金｜補助額と申請条件：国・自治体の補助経路と申請実務を解説しています。
- レセコンメーカーの選び方｜3系統の違いとシェアの読み方：医事系ベンダーの系統差と乗り換え判断を比較しています。
