医療情報部門で大病院向け電子カルテを内製するには？範囲と手順

ITトレンドがおすすめする製品・サービス

■連携・拡張の方式別

• 部門・外部システムとの連携：HOPE LifeMark-HX、MALL、Wing
• データの抽出・二次利用：HOPE LifeMark-HX、MOMACE
• 帳票・一覧表を院内で作成：MOMACE

■カスタマイズ方針別

• 設定項目や画面を細かく調整：MALL、ドクターソフト
• 標準の運用フローをもとに運用：Wing

大病院の電子カルテ内製は連携とデータ活用が中心

大病院の電子カルテは、診療録の本体に加え、検査や放射線、薬剤、物流、医事など多数の部門システムで構成されます。内製の効果が出やすいのは、これらをつなぐ部分と、蓄積したデータを使う部分です。大病院ならではの3つの領域を紹介します。

本体開発より周辺領域に人材を充てる理由

オーダーや診療録、医事会計まで含む電子カルテ本体を院内で開発・保守し続けるには、大規模な体制が必要です。過去には大学病院などで独自開発のシステムを運用してきた例もありますが、担当者の交代や技術の古さで維持が難しくなる場合があります。

本体の法令対応や制度改定はパッケージのベンダーに任せ、医療情報部門の限られた人材を院内固有の領域に充てるほうが、投資に見合う効果を得やすいと考えられます。内製する範囲を周辺に絞れば、更新時の移行作業も限定でき、院内の負担を見通しやすくなります。

部門システムとのインターフェース開発

大病院では、電子カルテと部門システムの間でオーダーや結果を受け渡すインターフェースが多数存在します。ベンダー同士の調整だけでは対応しきれない細かなデータ変換や、院内独自のコード体系への対応を内製で担う方法があります。

ただし、インターフェースで不具合が起きると、検査結果が届かない、オーダーが重複するといった影響が診療に及ぶおそれがあります。エラーの検知と通知、再送の手順まで含めて設計することが前提です。どの連携でエラーが起きたかを画面やログで追える仕組みがあると、夜間や休日も対応を進めやすくなります。

DWHと臨床研究のデータ基盤

大病院では、経営分析や臨床研究、病院指標の作成に診療データを活用する場面があります。電子カルテから出力したデータをDWH（分析用にデータを蓄積する仕組み）に集め、院内で集計や分析の仕組みを作るのは、内製と相性のよい領域です。

研究目的で使う場合は、倫理審査や個人情報保護の手続きに沿って、仮名化などの処理を行う必要があります。SS-MIX2（診療データを標準的な形式で保存するための仕様）などの標準形式を活用すると、製品が替わってもデータを使い続けやすくなります。

医療情報部門が内製を担う体制づくり

大病院で内製を続けるには、医療情報部門だけに負担を集中させない体制が必要です。医療業務とシステムの両方を理解する人材は限られるため、院内外の役割分担と、変更を管理するルールを整えましょう。

医療情報部門と現場部門の役割分担

医療情報部門は、要件の整理や設計、ベンダーとの調整、セキュリティの管理を担います。一方、診療部門や看護部、事務部門からは、業務に詳しい担当者を窓口として選んでもらい、要望の優先順位づけや試用に参加してもらいます。

現場の要望をすべて開発対象にすると、保守対象が増え続けるおそれがあります。要望はまずパッケージの標準機能や設定で解決できないかを確認し、内製するものを絞り込む手順を決めておきましょう。

外部開発会社との協働

院内の技術者だけで開発と保守をまかなうのが難しい場合は、外部の開発会社と協働する方法があります。設計と仕様の決定は院内が担い、実装や保守の一部を委託すると、院内にノウハウを残しながら人手不足を補えます。

委託する場合は、ソースコードや設計書の権利と保管場所、障害時の対応時間を契約で定めておきましょう。特定の担当者や委託先しか内容を把握していない状態を避けるため、複数人でレビューする仕組みも必要です。

変更管理と安全管理のルール

内製した仕組みでも、厚生労働省の「医療情報システムの安全管理に関するガイドライン」（2026年6月公表の第7.0版が最新）に沿った管理が求められます。アクセス権限やログ、バックアップの管理に加え、電子保存の三原則である真正性・見読性・保存性を満たす設計が必要です。

大病院では、変更の申請から承認、検証、本番反映までの手順を委員会などで管理する方法があります。医療法施行規則の改正で医療機関にサイバーセキュリティ対策が求められている点も踏まえ、点検の担当を明確にしておきましょう。

電子カルテ更新時期にあわせた内製計画

大病院の電子カルテは、数年ごとに更新（リプレイス）を迎えます。内製した仕組みは更新のたびに影響を受けるため、更新サイクルを前提に計画を立てることが大切です。更新時期に向けて進めたい3つの準備を説明します。

1. 内製資産を棚卸しする

更新の検討を始める段階で、院内で開発したインターフェースやツール、帳票を一覧にします。それぞれの利用状況、担当者、連携しているシステムを記録すると、更新後も必要なものと廃止できるものを判断できます。

新しいパッケージの標準機能で代替できる内製資産は、更新にあわせて廃止を検討します。内製資産を減らせば、移行の作業量と更新後の保守負担をあわせて抑えられます。

棚卸しの結果は、更新後の保守計画や人員配置を考える資料としても活用できます。

2. 移行テストの範囲を決める

継続して使う内製資産は、新しい電子カルテと正しく連携するかを検証環境で確かめます。データの欠落や重複、文字化け、処理の遅れがないかを、実際の業務の流れに沿ってテストしましょう。

大病院では連携先が多く、テストの範囲が広がりやすいため、診療への影響が大きい連携から優先順位をつけます。稼働直後は不具合が起きる場合もあるため、問い合わせ窓口と復旧の手順も用意しておくと安心です。

3. ベンダーとの責任分界を契約に盛り込む

パッケージと内製部分が連携する構成では、障害が起きた際に原因の切り分けが難しくなる場合があります。どこまでをベンダーが保守し、どこからを院内が担うのかを契約書や運用文書に明記しておきましょう。

あわせて、APIの仕様変更が予定される場合の事前連絡や、制度改定への対応時期についても取り決めておくと、内製部分の改修計画を立てやすくなります。

障害の切り分けに備え、連携部分のログをどちらが取得・保管するかも決めておくと、原因調査を速やかに進められます。

大病院の内製と相性のよい電子カルテの条件

内製と組み合わせる前提で大病院向け電子カルテを選ぶなら、機能の多さより院内開発とのつなぎやすさを重視しましょう。医療情報部門の負担を左右する3つの条件を紹介します。

API・標準規格への対応状況

院内で開発した仕組みと電子カルテ本体をつなぐには、APIや標準規格への対応が欠かせません。国の電子カルテ情報共有サービスでも使われるHL7 FHIRや、SS-MIX2といった標準形式でデータを出し入れできるか、APIの仕様書が開示されるかを確認しましょう。

APIの利用に追加費用がかかるか、呼び出し回数に上限があるかも重要です。連携でエラーが起きた際に、通知やログで原因を追えるかもあわせて確認すると、院内の保守負担を見積もりやすくなります。

カスタマイズ方針と保守費の考え方

パッケージによって、個別カスタマイズにどこまで応じるかの方針は異なります。カスタマイズを多く入れると、バージョンアップ時の改修費や検証期間が増える場合があります。

選定時には、帳票やテンプレートを院内で作成・変更できる範囲と、ベンダーに依頼が必要な範囲を確認しましょう。院内で変更できる範囲が広いほど、内製で補う部分を減らせます。

大病院では診療科や部門ごとに要望が寄せられるため、院内でカスタマイズ要望を審査する場を設けておくと、保守費の増加を抑えられます。

データ出力と二次利用のしやすさ

DWHへの出力方法や出力できる項目の範囲、出力の頻度を確認します。リアルタイムに近い連携が必要か、日次の一括出力で足りるかによって、適した製品や構成が変わります。

あわせて、契約終了時にデータをどのような形式で受け取れるかも確認しておきましょう。将来、別の製品へ移行する場合にもデータを持ち出せることが、内製資産を生かし続ける条件です。

臨床研究で使う場合は、出力データを匿名化する作業をどの段階で誰が行うかも、医療情報部門と研究部門で取り決めておきましょう。

医療情報部門の内製と組み合わせやすい製品一覧

この記事で紹介する大病院向けの電子カルテと関連システムについて、データ活用や外部システムとの連携、主な特徴を一覧にまとめました。院内の情報共有や部門業務の効率化、既存システムとの連携を検討する際にお役立てください。

データ活用と連携の土台になる大病院向け製品

ここでは、診療情報の活用や施設間の情報共有、部門業務の管理などに対応する電子カルテと関連システムを紹介します。外部システムとの連携方法やデータ出力機能を確認し、自院の運用に適した製品を比較してください。

まとめ

大病院向け電子カルテの内製は、本体の開発ではなく、部門システムとのインターフェースやDWHなどのデータ基盤に絞ると効果を得やすくなります。医療情報部門と現場部門、外部開発会社の役割を分け、変更管理と安全管理のルールを整えましょう。更新時期には内製資産の棚卸しと移行テストを行い、APIや標準規格に対応した製品を選ぶことが大切です。資料請求で各製品の拡張性を比較してみてください。