2026.08.05 DX

PACSとは？仕組み・電子カルテ連携・容量設計から導入判断まで解説【2026年版】

RPA開発

PACSの検討は「フィルムをやめたい」から始まることが多い一方で、見積もりを取ると金額の幅が数倍に開きます。差を生んでいるのは製品の優劣ではなく、保存する画像の量をどう見積もったか、電子カルテやRISとどこまでつなぐか、という前提の置き方です。この記事では、PACSが担う範囲を定義から切り分け、モダリティから画像サーバ、ビューアへ至る仕組みと周辺システムとの役割分担を整理します。そのうえで、1検査あたりの容量から年間増加量を積算する手順、医療法と療養担当規則で年数が異なる保存年限の置き方、オンプレミス型とクラウド型を分ける判断基準、そしてPACSを単独導入しない方が収まる場面までを扱います。

まとめ：PACSが担う範囲と、導入判断を分ける3つの数値

PACSは、CTやMRIなどの撮影装置が出力した医用画像を受け取り、保存し、診断用の端末へ配信する仕組みです。診療録そのものを管理する電子カルテとも、検査予約と実施を管理するRISとも役割が違います。ここを混ぜたまま要件を書くと、電子カルテ側で足りる機能をPACSに二重発注する事故が起きる。

判断を分ける数値は3つに絞れます。第一が年間の画像増加量で、モダリティ別の1検査あたり容量に年間検査件数を掛けて積算した値。第二が保存年限で、医療法施行規則の2年と療養担当規則の5年、そして診療上の過去画像比較に必要な年数のどれを採るかという設計判断です。第三が読影端末の同時利用数と、画像を開くまでに許容できる待ち時間。

結論を先に置きます。年間の撮影件数が少なく、モダリティが一般撮影1台に限られ、画像参照が院内の1、2台で足りる診療所では、PACSを単体で構えるより電子カルテ側の画像保存機能や装置付属のビューアで足ります。逆に、CTやMRIを備え複数の医師が並行して読影する、あるいは分院や連携先と画像を共有する構成に入ると、PACSを独立させた方が総保有コストは下がる。この境目を撮影件数と参照体制の2軸で確認してから、製品比較に進んでください。

PACSとは何かと、モダリティ・画像サーバ・ビューアの3要素構成

まず言葉の指す範囲をそろえます。同じ「画像システム」でも、部門の呼び方によって含む機能が変わるためです。

PACSが指す範囲と、医用画像管理システムという呼び方の対応関係

PACSはPicture Archiving and Communication Systemsの略で、日本語では医用画像管理システム、あるいは医用画像ファイリングシステムと呼ばれます。名前が示すとおり、担うのは「保存（Archiving）」と「通信（Communication）」の2つ。撮影そのものは装置側の仕事であり、診断内容の記録は電子カルテ側の仕事です。

この線引きを外すと要件が膨らみます。読影レポートの作成機能を指してPACSと呼ぶ製品もあれば、レポートを別システムとして切り出す製品もある。見積比較の前に、レポート作成・検査予約・所見の診療録への反映がどちら側の機能なのかを製品ごとに表へ落とすと差分が見えます。

モダリティから画像サーバ、ビューアへ流れる画像データの経路と滞留点

PACSの構成は3つの要素に分解できます。1つ目がモダリティで、CT、MRI、一般撮影装置（CR・DR）、超音波、内視鏡など、画像を生成して送出する装置群。2つ目が画像サーバで、受け取った画像を患者・検査・シリーズという階層で整理して保存するデータベース。3つ目がビューアで、医師が画像を呼び出して読影する端末側のソフトウェアです。

画像は撮影の完了後、装置から画像サーバへ送信され、サーバ側で受信が完了した時点で参照可能になります。ここで滞留が起きるのは、装置と回線の速度差、サーバ側の書き込み処理、参照時のキャッシュの3か所。特に1検査が数百MBに達するCTでは、この待ち時間が現場の体感を左右します。要件定義では「撮影終了から何秒で外来の端末に出るか」を数値で握っておくと、後の性能検証がぶれません。

フィルムレス運用に切り替えたときに変わる読影の手順と院内ルール

フィルムを前提にした運用では、撮影した技師がフィルムを出力し、物理的に診察室へ渡す手順が入っていました。PACSに移すと、この受け渡しが「サーバへの送信完了」に置き換わります。手順が短くなる一方で、渡し漏れが可視化されにくくなる点には注意が要る。

そこで運用ルールとして決めておくのが、撮影後に技師が画像の品質を確認して確定する手順です。フィルム時代は「渡されていない＝まだ完了していない」が自明でしたが、サーバ上では未確定の画像も見えてしまう。確定フラグをどの操作で立てるか、確定前の画像をビューアに出すかどうかを、導入前に部門間で合意しておきます。

DICOM規格が支える機器間の相互接続と、実務で詰まる連携の型

異なるメーカーの装置を1つのサーバに集約できるのは、DICOMという共通規格があるためです。ただし規格に対応していれば無条件でつながるわけではありません。

DICOMが定める画像形式と通信手順、患者情報タグの持ち方と注意

DICOMは医用画像の保存形式と通信手順を定めた国際標準規格で、画素データだけでなく、患者ID・氏名・検査日時・撮影条件といった付帯情報をタグとして同じファイルに持ちます。画像とメタ情報が一体である点が、一般的な画像形式との大きな違い。

この構造は便利な半面、運用上の落とし穴も生みます。患者IDの桁数や文字種が装置側で制限されている場合、電子カルテ側のIDをそのまま入れられず、変換規則を持たせる必要が出てくる。氏名の文字コードの扱いも装置によって差があり、外字や旧字体で文字化けが起きた事例は珍しくありません。自院の患者ID体系を実際のタグに通せるか確認してください。

モダリティ側の出力仕様の差で起きる取り込み失敗と切り分けの手順

取り込み失敗が起きたとき、原因はネットワーク・タグ内容・受信設定のいずれかに落ちます。切り分けは上流から順に進めるのが早い。まず装置からサーバへの通信が届いているかを接続確認の機能で見て、次にサーバ側のログで受信したタグの内容を確認し、最後にサーバ側の受け入れ条件と突き合わせます。

実務で多いのは3つ目のパターンです。サーバ側が特定のタグを必須項目として扱っている一方で、装置側がその項目を空で送ってくる。この不整合は装置の設定変更で解消できる場合もあれば、間にゲートウェイを置いてタグを補完する対応になる場合もある。古い世代の機器を残す構成では、この補完処理を最初から見込んでおきます。

DICOM対応をうたう機器同士でも接続検証が必要になる構造的な理由

DICOMは範囲の広い規格で、すべての機能を全機器が実装しているわけではありません。各機器は自分が対応する機能の範囲を適合性宣言書という文書で公開しており、接続可否はこの文書同士を突き合わせて判断します。「DICOM対応」という表記だけでは、必要な組み合わせが成立するかどうかは決まらない。

そのため導入プロジェクトには接続検証の工程を必ず組み込みます。既存装置を残す構成なら、装置1台ごとに検証の時間と立ち会いの人員が要る。ここを見積もりから落とすと、稼働直前に「この装置だけ画像が入らない」という事態になります。

電子カルテ・RIS・オーダリングとPACSの役割分担と連携設計

PACSは単体では完結しません。院内の他システムとどう分担するかで、必要な機能も費用も変わります。

電子カルテ・RIS・オーダリングが担う範囲とPACSとの境界

役割は次のように分かれます。オーダリングシステムが医師の検査依頼を発行し、RIS（放射線科情報システム）がその依頼を受けて検査の予約・実施・進捗を管理し、モダリティが撮影を行い、PACSが生成された画像を保存・配信する。そして電子カルテとは何かと種類・選び方の判断で扱っているとおり、診療の経過と所見を記録するのが電子カルテの役目です。

小規模な施設ではRISを独立させず、電子カルテやPACSの機能で代替する構成も取られます。判断の目安は、検査の予約枠管理と技師の作業指示をシステム上で回す必要があるかどうか。撮影件数が少なく予約枠の競合が起きない施設なら、RISを省いた構成でも運用は成立する。院内全体のシステム構成の考え方は医療情報システムの種類と構成の全体像で整理しています。

検査オーダーの発行から画像参照までの流れと、院内連携が生じる接点

一連の流れを追うと、システム間の接点は4か所に整理できます。1つ目が、オーダリングからRISへ渡る検査依頼。2つ目が、RISからモダリティへ渡る撮影対象の患者・検査情報（この受け渡しが自動化されていないと、技師が患者IDを手入力することになる）。3つ目が、モダリティからPACSへ送られる画像。4つ目が、電子カルテのビューアからPACSの画像を呼び出す参照要求です。

費用と難度が集中するのは2つ目と4つ目。2つ目は装置ごとに対応状況が異なるため、対象装置の台数がそのまま工数に効きます。4つ目は電子カルテ側のベンダーが提供する連携方式に合わせる形になる。既存の電子カルテを残す前提なら、この方式を最初に確認してください。

連携方式をHL7・DICOM・ファイル連携から選ぶときの判断材料

連携の実装方式は大きく3つあります。医療情報の交換規格であるHL7を用いる方式、DICOMの通信機能をそのまま使う方式、そしてCSVなどのファイルを介する方式です。画像そのものの受け渡しはDICOMが担い、患者・検査情報の受け渡しにHL7やファイル連携が使われるという分担が一般的。

選択の判断材料は、既存システム側が何に対応しているかと、リアルタイム性がどこまで要るかの2点。予約情報を日次で流せば足りる業務ならファイル連携で十分で、実装も検証も軽く済みます。当日受付の変更を即座に反映する必要があるならHL7側に寄せる。将来の拡張を理由に高機能な方式を先に選ぶと、初期の検証工数だけが増えて回収できません。

受託開発でPACS周辺を作るときに切り分ける内製範囲と製品の境目

PACS本体をゼロから開発する選択は、現実にはほぼ取られません。DICOMの適合性を担保し、装置ごとの検証を積み上げるコストが大きすぎるためです。開発の対象になるのは、既製のPACSでは埋まらない周辺の部分になります。

具体的には、複数拠点の画像を横断して検索する仕組み、健診や研究向けに画像と結果を匿名化して取り出す処理、既存の部門システムと画像を突き合わせる画面、あるいは装置とサーバの間でタグを補正するゲートウェイ。これらは施設ごとの業務に強く依存するため、製品の標準機能では届かない領域です。当社でも基幹システム開発として、既製パッケージを軸に据えたうえで、この差分の部分を設計・実装する形の支援を行っています。製品選定の前に「差分がどこに出るか」を洗い出しておくと、開発範囲が過大にならずに済む。

画像データの容量設計と保存年限：2年と5年の使い分けから積算する

見積もりの幅を生む最大の要因が容量設計です。ここは実データから積み上げるしかありません。

モダリティ別の1検査あたり容量から年間増加量を見積もる計算手順

積算の手順は単純で、モダリティごとに「1検査あたり容量 × 年間検査件数」を出し、合計します。目安として、2026年8月時点の一般的な装置構成では、CTは1スライスが512×512画素・16bit相当で1枚あたり約0.5MB、1検査300から1,000スライスの構成なら150から500MB程度。一般撮影は1枚8から30MB程度、マンモグラフィは高精細のため1枚40から50MB程度になります。MRIは撮像条件の幅が大きく、1検査で数十MBから200MB程度に収まる例が多い。

注意したいのが、装置の世代交代で1検査あたり容量が増える点です。CTの多列化や再構成条件の追加は、そのまま容量の増加に効く。過去3年の実績値が手元にあるなら、件数の伸びと1検査あたり容量の推移を出し、年率で何%増えているかを掴んでください。設計値は現状の実測にこの増加率を掛けて置きます。

医療法の2年と療担規則の5年から、実運用の保存年限をどう置くか

保存年限には複数の根拠が並びます。医療法施行規則第20条第10号では、エックス線写真を含む「診療に関する諸記録」を過去2年間備えておくことが定められている。一方、保険医療機関及び保険医療養担当規則第9条では、診療録は完結の日から5年間の保存が求められます。

実運用では、この法定年数をそのまま設計値にする施設は多くありません。経過観察で過去画像と比較する診療科では、5年より長い期間を参照する場面が生じる。訴訟リスクへの備えとして長期保存を選ぶ判断もあります。設計としては「法定の下限」と「診療上参照したい年数」を分けて書き、後者を容量設計の根拠に据えるのが実務的な形です。

一次保存と長期保存を分ける階層構成と、増え続ける容量への備え方

全期間を同じ性能の領域に置くと費用が跳ねます。そこで、直近の画像は高速な領域に、古い画像は安価な領域に置く階層構成を取る。参照頻度は撮影からの経過時間で大きく落ちるため、この分け方は費用と体感速度の両方に効きます。

区切りの目安は、直近1年から2年を一次領域、それ以前を長期領域とする構成。長期領域から呼び出す際に数十秒の待ちが出る設計なら、その待ち時間を診療科と合意しておきます。加えて、容量が設計値を超えたときの増設手順と、そのときに停止が必要かどうかを契約前に確認してください。

オンプレミス型とクラウド型PACSを分ける判断基準と回線の前提

設置形態の選択は、費用だけでなく回線と院外参照の要件で決まります。

オンプレミス型が向く条件と、画像表示の速度と初期費用の見え方

オンプレミス型は、院内にサーバを設置して画像を保持する形態です。画像の転送が院内ネットワークで完結するため、大容量のCT画像でも表示までの待ちが短く収まります。外部回線の障害に影響されない点も、救急対応のある施設では効いてくる。

負担は初期費用と運用側に出ます。サーバとストレージの購入費が最初にまとまって発生し、更新の周期も5年から7年で回ってくる。加えて、バックアップの取得と保管、機器故障時の対応、セキュリティ更新の適用を院内で回す体制が要ります。情報システム担当を置いていない施設では、この運用負担を保守契約でどこまで外に出せるかが判断材料になる。

クラウド型が向く条件と、回線品質と院外参照の運用で生じる制約事項

クラウド型は、事業者側のデータセンターに画像を保持し、回線経由で参照する形態です。初期費用を抑えやすく、容量の増加にも契約変更で追随できます。分院や在宅からの読影、連携先への画像共有を前提にする構成では、こちらが素直な選択になる。

制約は回線に集中します。表示速度が回線の実効帯域と遅延に依存するため、契約帯域だけでなく時間帯ごとの実測値を確認しておく必要がある。回線障害時に画像へ到達できなくなる点も設計に織り込み、装置側やローカルの一時保存で当日分を参照できる構成を併せて検討します。月額費用は容量の増加とともに上がるため、5年から7年の総額でオンプレミス型と比較してください。

安全管理ガイドライン第7.0版が両方式に共通で求める体制の備え

設置形態にかかわらず、医療情報を扱う以上は厚生労働省の「医療情報システムの安全管理に関するガイドライン」への対応が前提になります。2026年6月に策定された第7.0版では、保守を担う事業者向けの内容が保守委託機関編として独立した構成に整理されました。クライアント端末とサーバの二要素認証についても対応が明確化され、2027年4月1日までの緩和措置として次期システム改修時での対応が許容されています。

実務への影響は、選定と契約の両方に及びます。製品側の認証機能が要件を満たすかという確認に加えて、保守を委託する事業者との責任分界をどう書くかという論点が出てくる。ガイドライン対応の全体像と、医療機関側で整える体制については医療情報システムの安全管理ガイドライン対応の判断で詳しく扱っています。PACSの選定時は、そこで整理した体制要件を製品の機能要件へ落とし込む形で進めてください。

PACS導入を進める条件と、単独導入を見送るべき場面の切り分け

ここまでの内容を、採用と見送りの条件として言い切ります。

PACS単独で導入して効果が出る条件を、撮影件数と体制から判断する

PACSを独立したシステムとして構える判断が正しくなるのは、次の条件が重なったときです。第一に、CT・MRI・一般撮影のように複数種類のモダリティを持ち、装置ごとに画像の保存先が分かれている状態にある。第二に、読影や画像参照を行う端末が3台以上あり、複数の医師が並行して同じ画像へ到達する必要がある。第三に、過去画像との比較参照が診療の手順に組み込まれている。

この3つが揃うと、装置付属のビューアや電子カルテの画像機能では手が回らなくなります。画像の所在が装置ごとに分散し、探す時間が積み上がる。分院との画像共有や健診部門での大量保持といった要件が加わる場合は、条件が2つでもPACSを分けた方が収まります。

導入を見送る判断と、電子カルテ一体型へ寄せた方が収まる場面の条件

逆に、次の場面ではPACSの単独導入を見送る判断を推奨します。モダリティが一般撮影1台のみで、年間の撮影件数が数百件規模にとどまり、画像を参照する端末が診察室の1、2台に限られる診療所。この規模では、電子カルテ側の画像保存機能や装置付属のビューアで運用が回り、PACSを別建てにすると保守費と更新費だけが積み上がります。

もう1つが、電子カルテの更新時期が1年以内に迫っている場合。先にPACSを入れると、電子カルテの入れ替え時に連携部分を作り直すことになり、同じ工程の費用を2度払う形になります。この場合は電子カルテの選定と同時に画像の扱いを決め、一体型の構成か、連携込みの調達にまとめる方が総額は下がる。導入時期の判断材料としては、電子カルテ義務化の時期と対応判断で整理した普及目標の時間軸も併せて確認してください。

PACSの選定と要件整理を進める順序と、社内で先に決めておく項目

進め方は一本道です。最初に現状の実測値を集めます。モダリティの一覧と各装置の出力仕様、直近3年の検査件数と1検査あたり容量、参照端末の台数と設置場所、既存の電子カルテとRISの製品名と連携方式。この5点が揃わないまま製品比較に入ると、見積もりの前提が各社でばらつき、金額を並べても比較になりません。

次に、保存年限と表示待ち時間の目標値を院内で決めます。ここは技術ではなく診療側の合意事項なので、システム担当だけで決めると後戻りする。最後に、既存装置の接続検証にかかる工数と、フィルム運用との併走期間を計画に入れてください。

PACSの仕組みと費用や電子カルテ連携に関してよくある質問への回答

検討の場で繰り返し出る質問を、判断に直結する形で整理します。

PACSと電子カルテは何が違うのですか？

管理する対象が違います。PACSが管理するのは医用画像そのものと、その付帯情報。電子カルテが管理するのは診療の経過、処方、所見といった診療録の内容です。両者は連携して使われ、電子カルテの画面から患者を指定してPACSの画像を呼び出す構成が一般的になります。製品によっては電子カルテ側に簡易な画像保存機能が含まれており、小規模施設ではそれで足りる場合もある。

PACSとRIS、オーダリングシステムの関係はどうなりますか？

業務の流れに沿って役割が並びます。医師が検査を依頼するのがオーダリング、その依頼を受けて検査の予約と実施を管理するのがRIS、撮影された画像を保存・配信するのがPACSです。小規模な施設ではRISを独立させず、電子カルテやPACSの機能で代替する構成も取られる。

クラウド型PACSに切り替えれば費用は下がりますか？

初期費用は下がりますが、総額が下がるとは限りません。クラウド型は月額が容量に応じて増える構造のため、画像が毎年積み上がる施設では年を追うごとに費用が上がる。比較するときは、機器更新の周期に合わせて5年から7年の総額で並べてください。

画像の保存年限は何年に設定すればよいですか？

法定の下限と診療上の必要を分けて決めます。医療法施行規則ではエックス線写真を含む診療に関する諸記録を2年、保険医療機関及び保険医療養担当規則では診療録を5年としています。ただし経過観察で過去画像と比較する診療科では、これより長い期間の参照が生じる。実務では診療科ごとに必要年数を聞き取り、その最大値を容量設計の根拠に置く進め方が確実です。

古い撮影装置を残したままPACSを導入できますか？

可能な場合が多いものの、事前検証が前提になります。装置がDICOMのどの機能に対応しているかは適合性宣言書に記載されており、その内容とPACS側の受け入れ条件を突き合わせて判断する。患者IDの桁数制限や文字コードの差で不整合が出る場合は、間にゲートウェイを置いてタグを補正します。導入計画には装置1台ごとの検証工数を必ず含めてください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る