「PACS」の版間の差分
(→セキュリティ) |
|||
(6人の利用者による、間の10版が非表示) | |||
1行目: | 1行目: | ||
[[ファイル:Inside a Microsoft data center.jpg|270px|right|thumb|PACSサーバー室(イメージ図)]] | [[ファイル:Inside a Microsoft data center.jpg|270px|right|thumb|PACSサーバー室(イメージ図)]] | ||
'''PACS''' | '''PACS''' ('''P'''icture '''A'''rchiving and '''C'''ommunication '''S'''ystem、読み:ぱっくす)とは、[[医療]]の場で使われる、[[CR]]や[[CT]]、[[MRI]]などから発生するデジタルな[[医用画像]]データを保管、管理し、オンライン・ネットワーク上でやりとりする医用画像システム一式のことである。 | ||
一般的にPACSという場合には、医用画像サーバーおよびビューアだけではなく、[[レポーティング・システム]]や[[放射線科情報システム]]([[RIS]])などを含むシステム一式を指すのが一般的であるが、狭義には[[DICOMサーバー]]と[[DICOMビューアー]]のセットを指すこともある。 | 一般的にPACSという場合には、医用画像サーバーおよびビューアだけではなく、[[レポーティング・システム]]や[[放射線科情報システム]]([[RIS]])などを含むシステム一式を指すのが一般的であるが、狭義には[[DICOMサーバー]]と[[DICOMビューアー]]のセットを指すこともある。 | ||
9行目: | 9行目: | ||
近年は利便性と通信効率を優先し[[DICOM]]規格に準拠しないPACS製品も増えてきている。たとえば[[モダリティ機器]]からの画像データ受信などの他社製品との通信にはDICOM通信を用いるが、自社[[DICOMビューア]]への配信には独自通信規格・独自画像フォーマットを用いるというPACS製品も少なくない。この傾向は特にシビアな応答性能が要求される大規模なPACSほど強い。 | 近年は利便性と通信効率を優先し[[DICOM]]規格に準拠しないPACS製品も増えてきている。たとえば[[モダリティ機器]]からの画像データ受信などの他社製品との通信にはDICOM通信を用いるが、自社[[DICOMビューア]]への配信には独自通信規格・独自画像フォーマットを用いるというPACS製品も少なくない。この傾向は特にシビアな応答性能が要求される大規模なPACSほど強い。 | ||
なお、稀に「うちのPACSも独自規格使っており高性能です。なお付属の[[DICOMサーバー]]はDICOM通信の受信しかできません(C-STORE SCPしかサポートしません)」というような酷いシステムもあるが、これは前述の性能云々ではなく単純に技術力がないだけなので華麗に避けるのが賢明である。このようなシステムを導入すると将来的にベンダーロックイン<ref>http://monobook.org/wiki/%E3%83%99%E3%83%B3%E3%83%80%E3%83%BC%E3%83%AD%E3%83%83%E3%82%AF%E3%82%A4%E3%83%B3</ref>とばれるデータ移行が不可能な最悪の状態となる。 | |||
つまり独自規格が許されるのは、[[DICOM規格]]を一通りサポートしている前提のPACS製品のみである。 | |||
== PACSの利点と欠点 == | == PACSの利点と欠点 == | ||
本格的に[[読影]] | 本格的に[[読影]]を行うという意味では、PACSの[[読影端末]](≒[[DICOMビューア]])で用いる[[高精細モニター]]が[[写真フィルム]]に比べ画質が大幅に劣ることから敬遠される傾向があった。たとえば[[レントゲン写真]]をみるための[[シャウカステン]]は輝度3000~15000カンデラ、写真フィルム自体のコントラストは20000諧調くらいあり、2013年時点での最高スペックの高精細モニターをもってしてもフルレンジでの比較では一桁以上性能が違うという状況である。 | ||
一方で、デジタル医用画像(≒[[DICOM画像]])は、[[ウィンドウレベル変換]]などの写真フィルムとは異なる見方ができ、解析や[[再構成]]も容易であり、かつ可搬性や保管性なども圧倒的に優れているなどの写真フィルムにはない利点も多々ある。 | |||
=== 新しい視点 === | |||
また、医用画像がデジタル化したことで、複数の断層画像を繋げあわせたり、重ね合わせたりすることで新たなる画像を作り出す[[再構成]]や画像解析なども飛躍的に簡単に出来るようになった。再構成手法は色々あるが[[MPR]]法([[Multi Planer Reconstruction]]、[[他断面再構成法]])や[[MIP]]法([[Maximum Intensity Projection]]、[[最大値投影法]])、[[ボリュームレンダリング]]などが有名である。 | |||
=== 並列化 === | |||
加えてPACSの最大の特徴であるネットワーク化により、ネットワーク越しに画像データを即座に送受信でき、また1つの画像を異なる場所から同時に参照することも可能であるため、医療業務のパイプライン化(並列化)が進み、より早く、より的確な[[診療]]が可能となった。 | |||
また、PACSによるネットワーク化は[[読影医]]の居ない施設と、[[研修医]]も含め多数の[[読影医]]を常時抱える[[大学病院]]などを繋ぐことを可能とし、[[遠隔読影]]という新たな読影形態も生み出した。近年ではPACSおよび[[遠隔読影]]の普及により、従来は他の診療科と併設されているのが一般的であった[[放射線科]]が単独で独立開業し、[[読影センター]]や[[撮影センター]]を名乗る[[診療所]]なども増えてきている。 | |||
また、PACSは[[電子カルテ]]や[[オーダリングシステム]] | ちなみに並列化の影響として、直列的な[[医療]]を行う場合に比べ、診療状況や検査状況の同期([[医療従事者]]間の意思疎通)の重要性が増大する。よってPACS導入にあわせ人間的なコミュニケーションやチームワークといったものをより強化することが求められる。この点を蔑ろにすると[[医療事故]]の発生確率が飛躍的に増大してしまう。また極端に並列度を上げすぎることで同期に大量の時間を消費してしまい結果として効率が落ちるという事例もあるので注意する必要がある。 | ||
=== その他 === | |||
最近のPACSでは[[読影端末]](≒パソコン、稀に専用機もある)のみならず、iPhoneやiPadをはじめ、Android、Windows Phoneなどのスマートフォンやタブレット端末などのモバイル機器でも画像参照([[参照端末]])できるシステムなども登場してきている。これらの携帯端末は、その特性上、本格的な[[読影]]向けではないが、緊急時の応急的な対応には欠かせないツールとなりつつある。ただし、携帯端末による補助は、まだ歴史も浅く、発展途上であり、幾多の試行錯誤が繰り返されいる分野であるため、完全な実用には「作っては壊す」を繰り返す勇気と忍耐、そしてお金が必要となる。 | |||
また、PACSは[[電子カルテ]]や[[オーダリングシステム]]などとのシステム間での連携連動により、検査時の[[患者]]情報の入力ミスによる[[ヒューマンエラー]]、[[患者取違え]]などの[[医療ミス]]を抑える効果があるといわれている。ただし、システム統合・システム間連携をおこなうアプリケーションなどは一品物の特注開発となるため、導入コストや運用コストは爆発的に増大する傾向がある。この点に関しては[[DICOM]]規格団体などが[[電子カルテ]]業界などに標準化を呼び掛けて会合などを開いているが一向に進んでいない模様。なお[[放射線科]]が主体の[[レポーティング・システム]]などはDICOM範囲外でもフォーマットの統一構想などが着実に進められている。 | |||
== 導入状況 == | == 導入状況 == | ||
31行目: | 40行目: | ||
短期的な出費は増えるが長期的には儲かるということで、多くの大学・医大、[[病院]]が導入し、大規模施設ではほぼ100%近い[[フィルムレス]]化を実現している。 | 短期的な出費は増えるが長期的には儲かるということで、多くの大学・医大、[[病院]]が導入し、大規模施設ではほぼ100%近い[[フィルムレス]]化を実現している。 | ||
一方で[[診療所]] | 一方で[[診療所]]などの小規模な施設では未だに写真フィルムが全盛である。そもそも[[診療所]]にはPACSメーカーの営業すら来ないという。これは小規模PACSの利益率の問題で、5年間保守するという前提では、消耗品である写真フィルムに比べ、PACSは導入コスト(初期費用)が高いため売りにくく、しかも長期運用を想定した場合に消耗品が発生しないため全体の売上は少ない(利益率が悪い)。これらの理由により売る側は[[診療所]]向けの小規模PACSでは長期的なメンテナンスを含めた場合にハードウェア保険料や人件費、地域によっては交通費すら捻出できない、買う側も一括払いでは大金を用意できない、というジレンマが原因だと言われている。 | ||
== 相互接続 == | == 相互接続 == | ||
39行目: | 48行目: | ||
日本における[[モダリティ機器]]やPACS、[[DICOM]]関連製品の保証期間([[薬事法]]では[[耐用期間]]という)は一般的に5年となっていることが多い。これは税法上の[[耐用年数]]が5年であるためだと思われる。 | 日本における[[モダリティ機器]]やPACS、[[DICOM]]関連製品の保証期間([[薬事法]]では[[耐用期間]]という)は一般的に5年となっていることが多い。これは税法上の[[耐用年数]]が5年であるためだと思われる。 | ||
一方で市販のパソコンの保証期間はせいぜい1~2年なので、とくにソフトウェアのみの製品を導入する際にはトラブルを避けるためにも5年以内に3回程度壊れる前提で見積もりを出させることが重要となる。無謀な赤字経営で保証しきれなくなって倒産されるほど困ることはない。高すぎず、安すぎず、という製品を選ぼう。 | |||
=== 保守・保障の必要性 === | |||
一定以上の大きな[[病院]]の場合、これらの機材において重大なトラブルが発生すると、主に導入担当者(決裁者)の責任(進退に関わる)になるので、その責任を擦り付ける業者が必要となる。業者もトラブル時に擦り付けられ謝罪(賠償)する前提の価格を提示するのが普通である。この世界では価格が安ければ良いというものでもなく、むしろ価格が高い方が喜ばれるような構造になっている。これは医療業界に限った話ではなく一般的な法人でも似たようなものである。 | |||
小さい[[診療所]] | 小さい[[診療所]]の場合は運用保守を自分でやるのもいい。それらを扱う中小企業が近所にある場合には利用するのも良い。それしか選択肢はないともいう。[[医薬品]]などとは異なり[[医療機器]]や[[医療用ソフトウェア]]大して儲かる業界ではないので、都市部はともなく[[僻地]]では交通費の方が高いので大手メーカーの営業も来ないのが実情である。ただし自分で保守する場合には責任のなすりつけはできない。いわゆる自己責任となる。 | ||
[[医者]]がパソコンいじりに係きりになり、本業である[[医業]]・[[診療]]が疎かになっては本末転倒である。また、そんな時間があるのなら[[患者]]の話を聞いたり、[[医学書]]の1冊でも読んだ方がマシである。 | |||
== セキュリティ == | == セキュリティ == | ||
PACSは基本的にサーバー・クライアント型のシステムなので、必ずオンライン・ネットワークを用いるが、[[病院]]の場合は[[患者]]の[[病歴]]などの非常に重い個人情報を取り扱う関係上、セキュリティや個人情報保護の兼ね合いでインターネットではなくイントラネット(LAN)に限定したものが一般的である。 | PACSは基本的にサーバー・クライアント型のシステムなので、必ずオンライン・ネットワークを用いるが、[[病院]]の場合は[[患者]]の[[病歴]]などの非常に重い個人情報を取り扱う関係上、セキュリティや個人情報保護の兼ね合いでインターネットではなくイントラネット(LAN)に限定したものが一般的である。 | ||
ただPACSに限らず[[電子カルテ]] | ただPACSに限らず[[電子カルテ]]などもそうだが、「イントラネットであれば安全」という過信からLANに対して[[IEEE802.1X]](通称:[[認証VLAN]])や[[MACアドレス認証]]などによるアクセス制御がかけられておらず、[[病室]]の壁についているLAN端子に私物パソコンを繋げると院内ネットワークに入れてしまい、さらにはそのLAN上を暗号化されていない平文データが平然と流れているなど、セキュリティに対する意識の低いがゆえに下手な無線LANアクセスポイントよりも危険な状況に陥っていることも多い。 | ||
[[遠隔読影]]においては主に専用線やインターネットが使われるが、インターネットを使う場合は半ば専用線に近い通信キャリアが提供する回線レベルで拠点認証が付いたルータの設置場所の変更すら難しいガチガチなVPNを利用するのが一般的である。 | |||
== その他 == | == その他 == | ||
67行目: | 78行目: | ||
* [[VOX-BASE]] - [[J-MAC SYSTEMS]] | * [[VOX-BASE]] - [[J-MAC SYSTEMS]] | ||
* [[FAINWORKS]] - [[J-MAC SYSTEMS]] | * [[FAINWORKS]] - [[J-MAC SYSTEMS]] | ||
* [[FORZ]] - [[Excel Creates]] | |||
* [[K-PACS]] | * [[K-PACS]] | ||
* [[Conquest]] | * [[Conquest]] | ||
* [[OsiriX]] | * [[OsiriX]] | ||
* [[DICOM mini PACSシステム]] - [[日本バイナリー]] - [http://www.nihonbinary.co.jp/Products/Medical/MedicalImaging/PACS/index.html] | |||
* [[AZE VirtualPlace]] - [[AZE]] | |||
{{stub}} | {{stub}} | ||
== 関連項目 == | == 関連項目 == | ||
84行目: | 97行目: | ||
== 参考文献 == | == 参考文献 == | ||
{{reflist}} | |||
{{medical-stub}} | {{medical-stub}} |
2014年5月30日 (金) 16:20時点における最新版
PACS (Picture Archiving and Communication System、読み:ぱっくす)とは、医療の場で使われる、CRやCT、MRIなどから発生するデジタルな医用画像データを保管、管理し、オンライン・ネットワーク上でやりとりする医用画像システム一式のことである。
一般的にPACSという場合には、医用画像サーバーおよびビューアだけではなく、レポーティング・システムや放射線科情報システム(RIS)などを含むシステム一式を指すのが一般的であるが、狭義にはDICOMサーバーとDICOMビューアーのセットを指すこともある。
概要[編集 | ソースを編集]
医用画像システム一式というと、DICOMサーバーとDICOMビューアーのセットを想像されるかもしれないが、「PACS」という定義においては必ずしもDICOM準拠製品である必要ななく、独自規格の医用画像システムも含まれる。
近年は利便性と通信効率を優先しDICOM規格に準拠しないPACS製品も増えてきている。たとえばモダリティ機器からの画像データ受信などの他社製品との通信にはDICOM通信を用いるが、自社DICOMビューアへの配信には独自通信規格・独自画像フォーマットを用いるというPACS製品も少なくない。この傾向は特にシビアな応答性能が要求される大規模なPACSほど強い。
なお、稀に「うちのPACSも独自規格使っており高性能です。なお付属のDICOMサーバーはDICOM通信の受信しかできません(C-STORE SCPしかサポートしません)」というような酷いシステムもあるが、これは前述の性能云々ではなく単純に技術力がないだけなので華麗に避けるのが賢明である。このようなシステムを導入すると将来的にベンダーロックイン[1]とばれるデータ移行が不可能な最悪の状態となる。
つまり独自規格が許されるのは、DICOM規格を一通りサポートしている前提のPACS製品のみである。
PACSの利点と欠点[編集 | ソースを編集]
本格的に読影を行うという意味では、PACSの読影端末(≒DICOMビューア)で用いる高精細モニターが写真フィルムに比べ画質が大幅に劣ることから敬遠される傾向があった。たとえばレントゲン写真をみるためのシャウカステンは輝度3000~15000カンデラ、写真フィルム自体のコントラストは20000諧調くらいあり、2013年時点での最高スペックの高精細モニターをもってしてもフルレンジでの比較では一桁以上性能が違うという状況である。
一方で、デジタル医用画像(≒DICOM画像)は、ウィンドウレベル変換などの写真フィルムとは異なる見方ができ、解析や再構成も容易であり、かつ可搬性や保管性なども圧倒的に優れているなどの写真フィルムにはない利点も多々ある。
新しい視点[編集 | ソースを編集]
また、医用画像がデジタル化したことで、複数の断層画像を繋げあわせたり、重ね合わせたりすることで新たなる画像を作り出す再構成や画像解析なども飛躍的に簡単に出来るようになった。再構成手法は色々あるがMPR法(Multi Planer Reconstruction、他断面再構成法)やMIP法(Maximum Intensity Projection、最大値投影法)、ボリュームレンダリングなどが有名である。
並列化[編集 | ソースを編集]
加えてPACSの最大の特徴であるネットワーク化により、ネットワーク越しに画像データを即座に送受信でき、また1つの画像を異なる場所から同時に参照することも可能であるため、医療業務のパイプライン化(並列化)が進み、より早く、より的確な診療が可能となった。
また、PACSによるネットワーク化は読影医の居ない施設と、研修医も含め多数の読影医を常時抱える大学病院などを繋ぐことを可能とし、遠隔読影という新たな読影形態も生み出した。近年ではPACSおよび遠隔読影の普及により、従来は他の診療科と併設されているのが一般的であった放射線科が単独で独立開業し、読影センターや撮影センターを名乗る診療所なども増えてきている。
ちなみに並列化の影響として、直列的な医療を行う場合に比べ、診療状況や検査状況の同期(医療従事者間の意思疎通)の重要性が増大する。よってPACS導入にあわせ人間的なコミュニケーションやチームワークといったものをより強化することが求められる。この点を蔑ろにすると医療事故の発生確率が飛躍的に増大してしまう。また極端に並列度を上げすぎることで同期に大量の時間を消費してしまい結果として効率が落ちるという事例もあるので注意する必要がある。
その他[編集 | ソースを編集]
最近のPACSでは読影端末(≒パソコン、稀に専用機もある)のみならず、iPhoneやiPadをはじめ、Android、Windows Phoneなどのスマートフォンやタブレット端末などのモバイル機器でも画像参照(参照端末)できるシステムなども登場してきている。これらの携帯端末は、その特性上、本格的な読影向けではないが、緊急時の応急的な対応には欠かせないツールとなりつつある。ただし、携帯端末による補助は、まだ歴史も浅く、発展途上であり、幾多の試行錯誤が繰り返されいる分野であるため、完全な実用には「作っては壊す」を繰り返す勇気と忍耐、そしてお金が必要となる。
また、PACSは電子カルテやオーダリングシステムなどとのシステム間での連携連動により、検査時の患者情報の入力ミスによるヒューマンエラー、患者取違えなどの医療ミスを抑える効果があるといわれている。ただし、システム統合・システム間連携をおこなうアプリケーションなどは一品物の特注開発となるため、導入コストや運用コストは爆発的に増大する傾向がある。この点に関してはDICOM規格団体などが電子カルテ業界などに標準化を呼び掛けて会合などを開いているが一向に進んでいない模様。なお放射線科が主体のレポーティング・システムなどはDICOM範囲外でもフォーマットの統一構想などが着実に進められている。
導入状況[編集 | ソースを編集]
PACSは、厚生労働省によるPACS導入補助(画像診断管理加算などの保険点数)が実施されたことで爆発的に普及した。
PACS導入によるフィルムレス化を実現することで、一時的に莫大な導入コストが掛るものの、保険点数は一気に増え(収入が増え)、写真フィルムのときに問題となっていた薬事法の規定でフィルム捨てられないことによる保管費用(倉庫費用)や現像液の廃棄料(産業廃棄物指定されているので高い)などが掛らなくなる(支出が減る)。
短期的な出費は増えるが長期的には儲かるということで、多くの大学・医大、病院が導入し、大規模施設ではほぼ100%近いフィルムレス化を実現している。
一方で診療所などの小規模な施設では未だに写真フィルムが全盛である。そもそも診療所にはPACSメーカーの営業すら来ないという。これは小規模PACSの利益率の問題で、5年間保守するという前提では、消耗品である写真フィルムに比べ、PACSは導入コスト(初期費用)が高いため売りにくく、しかも長期運用を想定した場合に消耗品が発生しないため全体の売上は少ない(利益率が悪い)。これらの理由により売る側は診療所向けの小規模PACSでは長期的なメンテナンスを含めた場合にハードウェア保険料や人件費、地域によっては交通費すら捻出できない、買う側も一括払いでは大金を用意できない、というジレンマが原因だと言われている。
相互接続[編集 | ソースを編集]
電子カルテやレセコンなどとの相互接続方法の標準化も検討されているが、DICOM関連団体が必死に活動しても、電子カルテ業界は腰が重いらしく、とくに動きはない。
保障期間[編集 | ソースを編集]
日本におけるモダリティ機器やPACS、DICOM関連製品の保証期間(薬事法では耐用期間という)は一般的に5年となっていることが多い。これは税法上の耐用年数が5年であるためだと思われる。
一方で市販のパソコンの保証期間はせいぜい1~2年なので、とくにソフトウェアのみの製品を導入する際にはトラブルを避けるためにも5年以内に3回程度壊れる前提で見積もりを出させることが重要となる。無謀な赤字経営で保証しきれなくなって倒産されるほど困ることはない。高すぎず、安すぎず、という製品を選ぼう。
保守・保障の必要性[編集 | ソースを編集]
一定以上の大きな病院の場合、これらの機材において重大なトラブルが発生すると、主に導入担当者(決裁者)の責任(進退に関わる)になるので、その責任を擦り付ける業者が必要となる。業者もトラブル時に擦り付けられ謝罪(賠償)する前提の価格を提示するのが普通である。この世界では価格が安ければ良いというものでもなく、むしろ価格が高い方が喜ばれるような構造になっている。これは医療業界に限った話ではなく一般的な法人でも似たようなものである。
小さい診療所の場合は運用保守を自分でやるのもいい。それらを扱う中小企業が近所にある場合には利用するのも良い。それしか選択肢はないともいう。医薬品などとは異なり医療機器や医療用ソフトウェア大して儲かる業界ではないので、都市部はともなく僻地では交通費の方が高いので大手メーカーの営業も来ないのが実情である。ただし自分で保守する場合には責任のなすりつけはできない。いわゆる自己責任となる。
医者がパソコンいじりに係きりになり、本業である医業・診療が疎かになっては本末転倒である。また、そんな時間があるのなら患者の話を聞いたり、医学書の1冊でも読んだ方がマシである。
セキュリティ[編集 | ソースを編集]
PACSは基本的にサーバー・クライアント型のシステムなので、必ずオンライン・ネットワークを用いるが、病院の場合は患者の病歴などの非常に重い個人情報を取り扱う関係上、セキュリティや個人情報保護の兼ね合いでインターネットではなくイントラネット(LAN)に限定したものが一般的である。
ただPACSに限らず電子カルテなどもそうだが、「イントラネットであれば安全」という過信からLANに対してIEEE802.1X(通称:認証VLAN)やMACアドレス認証などによるアクセス制御がかけられておらず、病室の壁についているLAN端子に私物パソコンを繋げると院内ネットワークに入れてしまい、さらにはそのLAN上を暗号化されていない平文データが平然と流れているなど、セキュリティに対する意識の低いがゆえに下手な無線LANアクセスポイントよりも危険な状況に陥っていることも多い。
遠隔読影においては主に専用線やインターネットが使われるが、インターネットを使う場合は半ば専用線に近い通信キャリアが提供する回線レベルで拠点認証が付いたルータの設置場所の変更すら難しいガチガチなVPNを利用するのが一般的である。
その他[編集 | ソースを編集]
PACSを導入する際の注意事項として、
主なPACS製品[編集 | ソースを編集]
- Centricity - GE
- TFS - 東芝
- IDS (旧EasyAccess) - PHILIPS (スウェーデンSectra社のOEM品)
- iSite - PHILIPS (米国Stentor社を買収)
- EV Insite - PSP
- SYNAPSE - 富士フィルム
- DxServer - MEDASYS (フランス、近所にはシンクロトロン実験施設ソレイユがある)
- XTREK - J-MAC SYSTEMS
- VOX-BASE - J-MAC SYSTEMS
- FAINWORKS - J-MAC SYSTEMS
- FORZ - Excel Creates
- K-PACS
- Conquest
- OsiriX
- DICOM mini PACSシステム - 日本バイナリー - [1]
- AZE VirtualPlace - AZE