ベンダー中立アーカイブ

ベンダーニュートラル アーカイブ( VNA ) は、画像や文書 (および臨床関連のある可能性のあるファイル) が標準インターフェイスを備えた標準形式で保存 (アーカイブ) され、他のシステムからベンダー ニュートラルな方法でアクセスできるようにする医療用画像技術です。

この用語は、従来の画像保管および通信システム(PACS) とは区別して使用されますが、共通機能の連続体上で VNA と PACS の境界がどこにあるかについては議論があります。

最も単純な定義は、「標準インターフェースを備えた標準形式で医療画像を保存し、ベンダーに依存しない方法で他のシステムからアクセスできる医療機器」です。

いわゆる「ベンダー中立性」は、標準フォーマットとインターフェースによって暗示されており、その中立性は、それらの画像を作成または使用するベンダー固有のデバイス（たとえば、表示、配布、分析用、特定のワークフローの有無にかかわらず、放射線レポート用、つまりPACS 用）に関するものです。

ただし、正確な定義と機能セットは議論の余地があり、さまざまな VNA ベンダーが競合他社との差別化を図り排除されないように努め、顧客が実用的なものから空想的なものまでさまざまな要望を表明するにつれて進化します。

以下の主要な特徴については、一般的に合意が得られています。

• DICOM画像および関連する複合オブジェクト (プレゼンテーション状態、キー オブジェクト、構造化レポート)の保存
• 保存、照会、検索のための DICOM ネットワーク標準インターフェース
• 管理上の更新と修正（患者IDの変更と研究の統合）
• スケーラビリティ

以下の各機能は、一部の顧客やベンダーが一部またはすべてがコンセプトの基本であると主張している一方で、他の顧客やベンダーがそれに反対しているという意味で、依然として議論の余地があります。

• 画像に直接関係のないオブジェクト（人間が作成したリクエストやレポートなど）の保存
• 非DICOMコンテンツ（ HL7 CDAドキュメントなど）の保存
• DICOM以外のアクセスプロトコル（IHE Cross-Enterprise Document Sharing（ XDSおよびXDS-I）など）
• クロスドメイン ID およびコード解決 (患者 ID、アクセス番号、手順コード)
• ダイナミック DICOM タグ モーフィング
• 情報ライフサイクル管理
• ワークフロー管理データベースコンテンツの除外
• データベースエンジンの選択に依存しない
• アクセスの監査証跡

従来、医療画像を保存する必要性は放射線科や核医学科で最も多く、画像管理と画像アーカイブの機能を 1 つのソリューションに統合したサブスペシャリティおよび部門別 (PACS) の形で実装されてきました。このようなシステムはすべて、ネットワーク経由および物理メディア (CD など) での画像の取り込みと配信のための標準インターフェイス ( DICOMおよびIHE ) を備えていますが、通常、ワークフローと表示の最適なパフォーマンスは、独自のソフトウェアとプロトコルを使用して実現されます。さらに、独自の PACS の「内部」にある永続的なストレージは標準形式ではない可能性があり、PACS はデータベースに保存されている最新の研究および人口統計の更新と注釈で保存ファイルを更新しない可能性があり、保存ファイル内の特定の標準および非標準 (プライベート) DICOM 属性を拡張、乱用、または依存する可能性があります。

時間の経過とともに、多くの実装において、基盤となるストレージ インフラストラクチャは、ハードウェアおよびファイル システム ( DAS、NAS、SAN ) レベルで従来の (PACS) から「分離」され、代わりにドメイン固有ではないコンピューター データ ストレージベンダーによって提供されるようになりました。

より多くの医療専門分野で画像が診療に取り入れられるようになると、企業全体で画像の保存と配信機能を他の部門に拡張する必要性が高まっています。画像とメタデータを認識する標準プロトコルを使用して、表示パフォーマンスを犠牲にすることなく、部門固有のワークフロー、表示、分析ソリューションを画像保存インフラストラクチャから分離し、より高いアプリケーション レベルで相互運用したいという要望が高まっています。

問題を複雑にしているのは、(PACS) 製品は機能とサービス品質に関して常に流動的であり、従来、ユーザーは 3 ～ 5 年ごとに 1 つのベンダーを放棄して別のベンダーの製品に置き換えることです。これにより、画像と関連情報をデータ損失なしで新しいアーキテクチャに「移行」する必要が生じます。これは、画像エンコードに標準形式を使用しているにもかかわらず、簡単な作業ではありません。VNA の概念は、より高いアプリケーション レベル (表示とワークフロー) での急速な進化と変化にもかかわらず、理論的にはアーカイブ レベルでの安定性 (再利用性と移行頻度の低減) を高めます。もちろん、あるベンダーの VNA から別のベンダーの VNA への移行も簡単ではありませんが、頻度が低くなればよいだけです。^[1]

VNA の別名は「PACS ニュートラル アーカイブ」です。おそらく、この用語の方が本来の意図をよりよく伝えているのでしょうが、この用語はほとんど使用されず、良くも悪くも、VNA は顧客やセールスマンの間で流行語になっています。^[2]

上で述べたように、画像のアーカイブは当然ほとんど静的です。つまり、アーカイブの内容のほとんどは変更されず、毎日（比較的）少数の研究が追加されるだけで、変更や修正はほとんど必要ありません。

PACS の初期の頃から、標準的な相互運用性の境界を定義する必要があると予想されていました。^[3] ACR-NEMA 標準、および後に DICOM 標準が生まれたのは、標準ファイル形式の必要性だけでなく、画像を取得装置からアーカイブに保存するためのプロトコル、およびアーカイブから画像を照会して取得するためのプロトコルにも対応するためです。1985 年の最初の ACR-NEMA 標準でも^[4]、 FIND および GET トランザクションが定義されていました。^[5]つまり、ワークステーションとワークフロー管理をアーカイブから分離することが最初から想定されていました。1992 年に始まった RSNA での最初の DICOM デモでは、いわゆる「中央テスト ノード」が使用されました。^[6]これは、おそらく最初の DICOM ベースのベンダー中立アーカイブの 1 つでしたが、当時はそのラベルは使用されていませんでした。自家製の PACS またはミニ PACS では、通常、アーカイブとワークステーションを別のエンティティとして記述していました。^[7]すべてではないものの、多くのモノリシックな商用PACSは、統合されたワークステーションとアーカイブ間で独自のプロトコルを使用し続けましたが、3D処理や放射線治療計画などの特殊な作業のために別のサードパーティワークステーションをサポートする必要性は常に認識されており、DICOMプロトコルを使用して実装されていました。

1998 年、Erickson と Hangiandreou ^{[8] は}、アーカイブ機能を従来のモノリシック PACS から再び分離し、プリフェッチを利用して「解釈ストレージ デバイス」にデータを入力することの利点について議論しました。また、複数のアーカイブからのクエリと取得 (現在ではフェデレーテッド クエリと呼ばれる方法) により、企業間で画像を共有する方法についても説明しています。この記事では、当時の実際的な課題として、複数のアーカイブに対して DICOM クエリを実行し、プリフェッチに関連する応答を分離することの相対的な非効率性や、患者 ID の課題などが指摘されています。それでも、ワークステーションとは別のシステムに画像を保存できることは重要な機能であると考えられていました。最終的に、Erickson と同僚はこれを 2000 年にスタートアップ企業 TeraMedica ^[9]に発展させ、2015 年に Fuji Medical Systems に買収されました。

^{このテーマに関する多くのブログ記事[10]}の1つで、マイケル・グレイは、フロスト＆サリバン社の医療画像市場アナリストであるナディム・ダハー氏の記事の中で、フロントエンドの臨床アプリケーションとバックエンドのストレージ機能を分離するという概念の初期の説明に言及しています。^[11]

長く続いていたアント・ミニーPACSフォーラムのスレッドは、マイケル・グレイからの返答を受けて、より幅広い聴衆の間で中立的なアーカイブの問題について議論するために脱線しました。^[12]

2009年にWayne DeJarnette氏によって発表されたホワイトペーパー^[13]は、必要な機能セットに基づいて定義を確立する初期の試みであり、彼の会社はより最近の解釈も提供しています。^[14]

マイケル・グレイは2009年のブログ記事でVNAの必須要素を紹介し、^[15]アクオの属性チェックリストを参照しています。その最新の形式は、シャノン・ワーブの「真の」VNAの属性に関するホワイトペーパーに記載されています。^[16]

1997 年、ラリー シトカは、アーカイブ マネージャーと、市場にはリリースされなかった IMAS と呼ばれる分散アーカイブの構築で Cemax/Icon を支援した後、3M/Imation を離れ、Acuo Technologies という会社を設立しました。資本金を調達して、他の 3 人の Acuo 創立エンジニアを雇うのに 2 年 3 か月かかりました。個人投資家のジム ジャントから資金提供を受けた Acuo は、2000 年 1 月 1 日に 4 人の従業員とともに正式にオフィスを開設しました。同社は、表示アプリケーション (PACS) をデータ管理およびストレージ デバイスから分離することに重点を置いていました。

Acuo は、すべての画像コンテンツに対して、単一の標準化された中央リポジトリを介してベンダーに依存しない表示を提供するサービスを提供しました。コンテンツは、DICOM メッセージングのルーティングとマッピングによって、メッセージングとプロトコルを使用して Acuo 内に保存/リンクされました。コンテンツがローカルに保存されている場所、またはプロトコルで接続された場所から取得された場合、PACS にとって Acuo ソリューションは単一のリポジトリのように見えました。2004 年に Michael Gray が「ベンダー ニュートラル アーカイブ」というフレーズを作り出し、Acuo プラットフォームの表示、コンテンツ管理、メッセージ オーケストレーション、およびストレージを分離する機能を直接的に示しました。Acuo の ROI は、アーカイブを PACS から取り出し、移行 (アプリケーションまたはストレージ) に再び費用をかけることなく、上位にある表示アプリケーションへの最善のアクセスを可能にすることを中心に構築されました。PACS 表示アプリケーションと下位にあるストレージ プロバイダーからのベンダー ニュートラル。

多くの医療提供組織は、23 年も前に導入されたシステムから、いまだにコスト削減を実現しています。  

Herman Oosterwijk 氏は、Teramedica を代表して、ホワイト ペーパー^[17]でより最近の説明を提供し、より詳細な定義を示しています。「ベンダー ニュートラル アーカイブ (VNA) は、スケーラブルな画像と情報、およびライフ サイクル管理を提供する医療機器です。これにより、患者のプライバシーとセキュリティを維持しながら、複数の部門、企業、および地域レベルでオープン スタンダードで定義された方法で画像と関連情報を照会、保存、および取得できます。VNA の特徴は、さまざまな表示、取得、およびワークフロー管理コンポーネントのアップグレードや変更を超越する患者中心のアプローチを提供することです。これは、VNA のデータ形式やインターフェイスを移行、変換、または変更することなく、コンポーネントが交換可能である必要があるためです。」

VNAとクラウドでの医療画像の保存との関係も曖昧ですが、流行語に準拠する可能性が高く、マイケル・グレイはEMCの委託を受けた論文である程度明確にしています。^[18]

コスト、価値、参入障壁の問題に対処する さまざまな代替展開モデル^[19]とフレームワーク^{[20]が説明されています。}

「VNA」という用語はマーケティング用語として乱用されてきたため、すでに神話的な地位を獲得しています。^[21]

パッシブ アーカイブは、受信したものを単に保存し、変更を加えた同じ (一意の) 識別子で再度受信した際に、同じものを上書きする可能性があります。これは、間違いが発生する生産操作では不十分であり、患者の人口統計を修正したり、間違い (検査中に間違った患者、リクエスト、または側が選択され、画像ヘッダーに間違った情報が存在する) を修正したりする必要があります。

IHE 患者情報調整 (PIR) やイメージング オブジェクト変更管理 (IOCM) など、いくつかのユース ケースをカバーする標準が存在します。

アーカイブを部門、機関、地域、さらには国境にまで広げるには、実体と概念の識別の問題に対処する必要があります。

一般的に、個々の機関などのドメイン内では、患者識別子とリクエスト、研究、レポートの識別子 (アクセス番号など) は、そのドメイン内では一意に割り当てられますが、外部では割り当てられません。ほとんどの内部システム (およびほとんどのPACS ) は、複数の ID ドメインの存在を管理しておらず、識別子がドメイン間で使用されると、衝突やあいまいさが発生します。したがって、各識別子は、使用時に「割り当て機関」によって修飾されるか（DICOMベースのIHE複数画像マネージャ アーカイブ (MIMA) プロファイルで採用されているアプローチ）、または統合された企業間システムすべてを含むより大規模なドメインの範囲にまたがる単一の「標準」識別子に強制変換される必要があります（IHE 企業間ドキュメント共有で採用されているアプローチ）。外部の画像をローカル アーカイブにインポートする場合も、この問題に対処する必要があります。通常は、外部の識別子を内部の識別子にマッピングし、DICOM「ヘッダー」またはその他のメタデータで情報を再エンコード（強制変換）します（インポート調整ワークフローで指定されている方法など）。

このサポートが VNA にとって必須の機能であるかどうかは、VNA がどのような環境に展開されるか (1 つの企業内か、複数の企業間か) によって異なりますが、堅牢なサポートにより、将来の展開構成の変更 (企業の合併など) に対する保証が提供されます。

同様に、手順コード (請求コードではなく「注文可能」) などに使用されるローカル コード セットは十分に標準化されておらず、これらがワークフローや表示 (ハンギング プロトコルなど) を駆動するために画像で役立つ場合、これらをマップする機能も便利な機能です。

VNA の目的の 1 つは、情報を保存し、その情報を、標準とプライベートの両方で保存されている DICOM 属性と値の非常に特殊な特性に対する使用要件と期待が異なる可能性がある複数のシステムに提供することです。

「動的タグ モーフィング」の概念は、2 つの異なるシステムが同じ属性に異なる値を期待するという問題の解決策として宣伝されています。「タグ モーフィング」とは、1 つ以上の属性 (このコンテキストでは通常 DICOM データ要素) の値を変更することを指します。これは「静的」に実行され、その場合は 1 つのマッピングのみが実行されます。また、「動的」に実行され、その場合は特定の受信者に固有の複数のマッピングが実行されます。

退化した形態では、任意のタグと値を他のタグと値にマッピングする機能は本質的に危険であり、そもそも属性を標準化しようとすることの価値、およびモダリティと PACS ベンダーによる属性を「適切に」使用するための努力の価値を損ないます。とはいえ、インストール ベースや新製品でも、特に非常に特殊で高度な形式のイメージングの場合、一部のフィールドの使用方法にはばらつきがあり、高度な表示および分析アプリケーションが入力に期待するものにもそれに応じたばらつきがあります。したがって、これは危険性にもかかわらず、人気のある機能です。VNA として分類されるには必須の機能であると強く主張する人もいます。

この機能は、 HL7バージョン 2 の世界で一般的な、いわゆるインターフェース エンジンを彷彿とさせます。インターフェース エンジンは、ソースとターゲットに応じて、ほぼあらゆるものを他のものにマッピングするように設計されています。

典型的な使用例は、取得モダリティによって提供されるシリーズ記述の値を変更して、同じデータを共有する 2 つの異なる PACS がシリーズ記述に基づいて異なるハンギング プロトコル ルールを使用できるようにすることです。モダリティが他の属性をより詳細に設定し、取得プロトコルとそのコードがより標準化され、ハンギング プロトコル エンジンがより柔軟であれば、これはより標準的な方法で実現できると言えますが、最先端の制限を考慮すると、この手法は依然として有用です。

動的タグ モーフィングは、クロスドメイン ID およびコード解決 (PS 3.4 の DICOM では「強制」と呼ばれているもの) に関連する特定の属性変更とは異なります。クロスドメイン ID およびコード解決には、何をいつどのように変更するかについての標準が定義されており、多くの場合、マスター 患者インデックスなどの追加のアクターが関係しますが、一部の支持者はこれらをまとめて扱い、一部の製品は同じメカニズムを使用してこれらを実装しています。

マイケル・グレイはタグモーフィングの初期の提唱者であり、それをVNAの重要な機能とみなしています。^[22]タグモーフィングの使用例の説明は、ウェイン・デジャネットの2010年のホワイトペーパーに記載されています。^[23]

ディスクは安価ですが、電力と空調はそうではありません。しかし、特にローカルでホストされている資本化されたインフラストラクチャを使用するのではなく、使用した分だけ支払う場合、ストレージには有限のコストがあります。

したがって、医療法上の保管期間が満了した場合、または臨床的有用性が失効した場合 (患者の死亡など)、多くのユーザーはストレージを消去できることを望みます。このためのルールは複雑で、管轄区域や地域のポリシーによって異なります。資金提供者、リスク管理者、訴訟担当者、研究者、教育者からの相反する要求を考えると、このようなポリシーについて合意に達することは難しいかもしれません。

いずれにしても、潜在的に有用な VNA 機能として、ルールを直接実装するか、別のルール エンジンからの IHE イメージング オブジェクト変更管理 (IOCM) 要求に応答するかに関係なく、ローカルでカスタマイズ可能なルール ベースの消去 (カリング) 基準のサポートが挙げられます。

VNA は、画像やプレゼンテーション状態などの関連情報、モダリティによって記録された測定値やCADなどの後処理結果などを含む DICOM 構造化レポートなどのいわゆる「証拠文書」などの DICOM コンテンツを問題なく保存できるはずです。

しかし、臨床現場では、保存することが望ましい他の種類の文書やバルク オブジェクトが利用できる場合があります。ほとんどの PACS では、これらを DICOM に変換するアプローチを採用しており、場合によっては別の種類のオブジェクトを「カプセル化」することを目的としたオブジェクトを使用します。典型的な例は、スキャンされた文書が PDF ファイルとして保存され、画像のように識別して管理するのに十分なメタデータとともに DICOM PDF オブジェクトにカプセル化されていることです。VNA は、このようなカプセル化された DICOM オブジェクトをサポートする必要があります。DICOM「ヘッダー」は、クエリと検索をサポートするインデックス用のメタデータを取得する手段を提供します。Michael Gray は、このトピックに関するホワイト ペーパーでこのトピックについて詳しく説明しています。^[24]

その他のオブジェクト タイプの場合、または DICOM カプセル化オブジェクトが利用できない場合、または DICOM システムとインターフェイスする必要がない場合は、HL7 バージョン 2 メッセージや XDS レジストリ サービスを使用するなど、インデックス作成に必要なメタデータを提供する標準的な手段がある限り、理論上は VNA は何でも保存できます。

特定の種類の非 DICOM コンテンツ (たとえば、放射線レポートを含む HL7 CDA ドキュメント インスタンス) は、XDS として保存するか、最初に DICOM カプセル化 CDA オブジェクトにカプセル化して DICOM サービスを使用して保存するか、そのコンテンツとヘッダーを DICOM 構造化レポート インスタンスにトランスコードすることができます。フル機能の VNA には、要求元のシステムで必要なものに応じて、任意の単一インスタンスを別の形式にトランスコードする機能 (いわゆる「オブジェクト モーフィング」) がある場合があります。

ウェイン・デジャネット氏の製品における非DICOMオブジェクトストレージへのアプローチについては、2009年のホワイトペーパーに記載されています。^[25]

画像には DICOM ファイル形式を使用する必要があること、また、アーカイブまたは転送用に画像を圧縮する場合は、独自の圧縮方式 (転送構文) ではなく標準の圧縮方式を使用する必要があることについては、一般的な合意があります。実際、多くの従来の PACS と比較すると、ほとんどの VNA の特徴は、インターフェイス全体で良好なパフォーマンスを実現しながら、過去に「パフォーマンス」上の理由で表面上使用されていた独自の内部形式を回避していることです。

実装によって、サポートされる圧縮方式の範囲が異なる場合があります。また、法医学的アーカイブの目的で可逆 (ロスレス) 圧縮が必須であるかどうかも異なります。実装によって、サポートされるモダリティ固有の画像の種類の範囲も異なります。多くのアーカイブは、原則としてすべての DICOM 画像情報オブジェクトをサポートしますが、スライド全体の病理画像や長いビデオなどの極端なケースはサポートされない場合があります。VNA の一般的な機能は、取得モダリティからの属性か、他の介在アプリケーション (QC ワークステーションや PACS など) によって追加されたプライベート (独自の) 属性を含む、すべての属性を最初に提供されたとおりに保持しようとすることです。

DICOM は、特定のモダリティやアプリケーションに関連する特定のメタデータを含む画像を保存するためのさまざまな「情報オブジェクト定義」と「SOP クラス」を記述しており、これらのリストはテクノロジの進化とともに増えています。DICOM 形式は本質的に拡張可能であり、すべての新しいオブジェクトは共通のエンコードとパターンに基づいて構築されるため、SOP クラスが認識されているか新しいかに関係なく、VNA は任意の DICOM 画像オブジェクトを保存できる必要があります。これは、フィールドで変更可能な構成を使用して新しい SOP クラスを追加するか、オブジェクトの「ヘッダー」の内容を分析するか、DICOM C-STORE 操作によって転送されたものをすべて受け入れ、保存し、再送するという単純なアプローチによって実現できます。

基本的な DICOM C-STORE、C-FIND、C-MOVE、および C-GET のサポートは基本的なものであり、議論の余地はありません。暗黙的および明示的な VR リトルエンディアンを含む基本的な非圧縮転送構文と、あまり一般的ではないビッグエンディアン転送構文が通常サポートされています。圧縮転送構文の範囲には、通常、ロスレス JPEG、可逆および非可逆JPEG 2000、場合によってはJPEG-LS、および通常はロスレス JPEG (そのように提供された画像の場合) が含まれます (特にトゥルーカラー写真)。モーション圧縮 (マルチフレーム JPEG 以外) のサポートはそれほど一般的ではありませんが、特に表示せずに保存および再送信する場合、VNA ではPACSよりも一般的である可能性があります。

重要な VNA インターフェイスは、Web Access to DICOM Persistent Objects (WADO) のオリジナル バージョンであることにほとんどの人が同意するでしょう。WADO を使用すると、単一の画像をHTTP URL を使用して DICOM ファイル形式で取得したり、 JPEGなどのコンシューマー形式に事前レンダリングしたりできます。

IHE イメージング向け企業間ドキュメント共有のSOAP Web サービスベースのトランザクションも、一般に、 クレームが VNA となるための前提条件と見なされます。

表示用画像に適用されるグレースケールまたはカラーレンダリング変換は、DICOM プレゼンテーション状態オブジェクトとして保存する必要があります。これらのオブジェクトは、グレースケールおよびトゥルーカラー画像、およびグレースケール画像への疑似カラールックアップテーブルの適用をサポートします。プレゼンテーション状態は、適用されたズームおよびパン（表示領域の選択）も記録できます。IHEは、これらを画像の一貫性のあるプレゼンテーション (CPI) プロファイルで使用します。

最近の多くのPACS はDICOM プレゼンテーション状態オブジェクトを使用して画像注釈を保存することもできるため、VNA はこれらをサポートする必要があります。これには、保存と再表示だけでなく、VNA コンポーネントとして提供される任意のビューアでの選択と表示も含まれます。

注釈、関心領域、および測定値の保存に推奨される形式は、DICOM 構造化レポート (SR) オブジェクトです。これにより、構造、コード化された意味情報を単なる表示ではなく永続化できます。IHE では、これらを証拠文書 (ED) と呼んでいます。DICOM SR オブジェクトは、IHE がシンプル画像および数値レポート (SINR) プロファイルで指定するコンテキストで生成される場合もあります。

多くの取得モダリティ、マンモグラフィー CAD システム、定量的画像分析ワークステーションは SR オブジェクトを生成するため、VNA はこれらを保存して再表示できる必要があります。理想的には、すべてのビューア コンポーネントは、参照画像上の座標の表示を含め、すべての SR のコンテンツの一般的な (理想的ではないにしても) レンダリングが可能である必要があります。

放射線治療などの特定のドメインでは、3D 患者相対座標等高線(のみ)をエンコードできる古い形式の DICOM RT 構造セットが使用され、一部の非 RT ワークステーションでは SR の代わりにこれらも生成されます。VNA はこれらもサポートする必要があります。

PACS の一般的な概念は、ユーザー (モダリティ オペレーターや読影放射線科医など) が一部の画像 (またはその他のオブジェクト) を「キー」、つまり何らかの理由で特に重要なものとしてフラグ付けすることです。旧式の PACS ではこれを内部データベースにフラグとして記録するだけですが、最新の PACS ではDICOMキー オブジェクト選択オブジェクト (SR の特殊な形式) を使用してこの情報をエクスポートします。この使用法は、IHE キー画像メモ (KIN) プロファイルで説明されています。VNA は、KOS オブジェクトの保存と再表示、および任意のビューアでのこれらの選択と表示をサポートする必要があります。

多くの医療用画像技術は、患者にかなりの量の電離放射線を照射するため、被曝量を追跡する必要があり、一部の地域では法律で記録する必要があります。DICOM は、これをエンコードするための構造化レポートの特殊な形式である放射線量構造化レポート (RDSR) を定義しています。IHE は、これを放射線被曝管理 (REM) プロファイルで使用します。VNA は、これらの保存と再送をサポートする必要があり、理想的には、重要な情報を抽出して任意のビューアで表示できる必要があります。

放射線科および核医学アプリケーションでは、口述および転写 (または音声認識の使用) の実践が定着しており、これらの出力は通常、非構造化または最小限の構造化された散文であり、プレーン テキストとしてエンコードされ、ファックスまたは HL7 バージョン 2 メッセージまたは同様に原始的なメカニズムによって配布されます。これらの「ドキュメント」の永続的な形式は十分に標準化されていませんが、多くの顧客は、VNA が、望ましいローカル形式でそれらを受け入れることができることを期待しています。DICOM 以外のコンテンツの保存にも同じ原則が適用されます。これには、DICOM または CDA オブジェクトにカプセル化されていない PDF としてレンダリングされたレポートの場合など、構造化された「ヘッダー」の代わりにメタデータを提供するための HL7 バージョン 2 メッセージまたは XDS の使用が含まれます。 HL7 は、CDA を無償で提供するなど、これまで閉鎖的だった IP ポリシーを緩和することを約束しているため、CDA がエンコードの推奨形式になる可能性はありますが、VNA はインストール ベースからさまざまな形式のレポートを受け入れる (場合によってはトランスコードする) 必要があります。DICOM は、人間が作成したレポートをエンコードするためのテンプレートを DICOM 構造化レポート (SR) オブジェクトとして定義し、IHE はこれをシンプル イメージおよび数値レポート (SINR) プロファイルで指定します。

DICOM RT 構造セットに加えて、放射線治療を実施する企業で VNA を使用できるようにするには、ビーム、イオン、および近接放射線治療用の DICOM RT オブジェクト ファミリ全体を保存して再出力する必要があります。

DICOM は、患者、検査、シリーズ、インスタンス情報を含む従来の DICOM 複合インスタンス ヘッダーである Raw Data オブジェクトを定義しますが、ペイロードはありません。これは、CT スキャナーの検出器から取得した Raw ビューや MRI スキャナーからのk 空間データなど、画像または画像のようなオブジェクトとして簡単に表現できないが、あらゆるもののエンコードに使用できる Raw データの保存を目的としています。VNA は、これらのデータを保存して出力できる必要がありますが、その内容を認識しておらず、元のデバイスのみが解釈できる可能性があります。

オーディオをエンコードするためのコンシューマー フォーマットは広く使用されていますが、これらには患者と診療を識別するために必要なヘッダーやメタデータがありません。これらをサポートしたい VNA には、XDS を使用した送信など、そのような情報を提供する手段が必要です。DICOMはBasic Audio オブジェクトを定義しており、コンシューマーの世界で利用可能な多数のオーディオ コーデックをサポートしていませんが、一部の PACS はこれらを生成しているため、VNA はこれらをサポートする必要があります。

時間ベースの波形 (ECG など) は、DICOM または他のさまざまな形式で保存できます。オーディオの場合と同じ原則が適用されます。つまり、形式が医療向けのものであれば、取り込み中にインデックス作成にヘッダー メタデータを使用し、そうでない場合は XDS を使用して登録します。

DICOM MR 分光法オブジェクトが定義されており、一部のモダリティがそれを生成するため、VNA はそのインスタンスを保存して再出力できる必要があります。

DICOM では、DICOM のエンコードと転送メカニズムを使用するものの、内容が不透明なプライベート SOP クラスの概念が認められています。ベンダーは、標準化されていない情報をエンコードする必要がある場合にこれを効果的に使用し、また、標準エンコードを使用する代わりに利便性のためにこれを悪用します。いずれにしても、その内容は臨床ワークフローにとって重要である可能性があるため、VNA はこれらを受け入れ、保存し、再送するように構成可能である必要があります。

• 複数のPACSに画像をオンサイトで提供
• 複数のPACSへの画像のオフサイト提供
• 画像の直接表示（ローカルまたは外部）
• 高可用性
• 事業継続と災害復旧

複雑な歴史を考えると、VNA を主張する 2 つの製品がまったく異なる機能セットとパフォーマンスを備えていることは驚くことではありません。ただし、基本的に製品には 4 つのカテゴリがあります。

• PACSとは独立して開発されたサードパーティシステム
• もともとBC/DRを目的としたオフサイトアーカイブシステム
• 企業間および外部アクセスをサポートする中央リポジトリ製品
• 社内アーカイブへの標準アクセスを改善した従来のPACS

クリエイティブ マーケティング部門によって再構想された機能セットにもかかわらず、個々の製品ラインの伝統は、当初意図されていたものとは異なるアプリケーションへの適合性を検討するときに重要な要素となる場合があります。

世界のVNA市場の規模はPACS市場に比べると小さいですが、成長していると言われています。^[26]

2012年末時点のVNA市場の状況の概要は、この概要に記載されています。^[27]