DICOM と WWW の融合は、今日では医療画像ネットワークシステムの根幹となるアイディアとして様々な形態で実現されている。筆者らも早くからこのアイディアの有効性に着目しその研究を続けてきた。加えて、研究の成果をより多くの施設で活用していただく方法についても検討を重ねてきた。その結果、DICOM/WWW サーバを低価格のパッケージ製品としてマーケットに供給する事がもっとも望ましいと結論付けた。DICOM/WWW サーバの製品としての発表は近日中を予定しているが、それに先立ちその概略について説明する。
当初、想定した利用形態は HIS クライアントや研究用の多数のパーソナルコンピュータ上での単純な DICOM 画像の参照であり、筆者らにとっての DICOM と WWW の融合の目的は、病院ワイドでの画像配信における DICOM のディメリットを WWW によって解消することであった。その後のプラットホーム技術の進歩により、単純な参照から高度な画像処理をも視野に入れる事が可能となった。
DICOM/WWW サーバの機能を一言で云うならば「DICOM in / WWW out」である。「DICOM in」とは「DICOM C-STORE により画像を受信し、画像データの属性情報により自動的にデータベースに登録する」である。「WWW out」とは「URL により画像を検索し、サーバ上でオンデマンドで DICOM→JPEG 変換を行い、HTTP により転送する」である。
これらの機能の中でとりわけ重要な点は「サーバ上でオンデマンドで DICOM→JPEG 変換を行う」事であり、その際には拡大縮小、ウィンドウレベルなどの画像処理も行われる。画像を表示する際に要求される画像サイズやウィンドウレベルは様々であり、予め表示用の画像ファイルを用意しておくことは、画像表示の自由度を低下させるだけでなく、画像の格納量の増加とそれに伴う画像ファイル管理の複雑化を招く。筆者はプロジェクトの当初から一貫してオンデマンドでの変換の有効性を主張しており、今日のパーソナルコンピュータの処理能力はそれに十分応えられるレベルに達している。
DICOM/WWW サーバを開発する上で、プラットホームの選択は重要な検討項目となった。基盤プラットホーム技術（ＣＰＵ、バスアーキテクチャ、オペレーティングシステム）やアプリケーションプラットホーム技術（言語、ライブラリ、フレームワーク）、ネットワークプラットホーム技術（媒体、転送プロトコル、アプリケーションプロトコル）の進歩は止まることを知らず、しかも、これらの技術革新への追従は必須である。この事は実装だけの問題に止まらずシステムのアーキテクチャや基本的な機能にまで影響を与えることになる。
当初、基盤プラットホームとして UNIX プラットホーム（Sun Workstation / Solaris 2.x）上で実装を行ってきた。しかし、このプラットホームは、ハードウェアが高価であること、エンドユーザによる運用管理が困難であること、など「低価格のパッケージ製品としてマーケットに供給する」という目的には合致しない為、プラットホームの変更を余儀なくされた。今日、この目的に最も適したプラットホームは、Intel x86 CPU ベースのパーソナルコンピュータ上で稼動する Microsoft Windows NT Server であると考えられる。
基盤プラットホームの変更はアプリケーションプラットホームにも大きな影響を与え、CGI / PIPE ベースのコマンド／スクリプトの実行形式から、ISAPI / OLE ベースの DLL 実行形式への移行を余儀なくされた。この変更は開発の困難さを増したが一方ではより高度なメカニズムの実現を可能とした。また Java の登場は、Web ブラウザー以外のクライアントアプリケーションの可能性を生み出した。
ネットワークプラットホームの進化は媒体の高速化大容量化に集中した一方、TCP/IP と HTTP はほとんど進化していない。言い換えれば、進化を必要としなかった。それは、これらの規格がインターネットの賢者達の洞察と議論の成果だからであろう。また、DICOM についても最もベーシックな画像転送サービス（C-STORE）関しては変更がなく、その実装の効率化に力を注ぐことが可能であった。これらの標準に対して、凡身たる我々が衆愚となりて不必要な変化を求めないよう自重が必要であろう。
サーバの外部へのインタフェイスは安定した標準規格を利用している。また、DICOM 画像ファイルも DICOM の媒体保存形式に準拠している。一方、それ以外の内部的の情報はシステムの性能を最優先するため、Windows NT に強く依存した構造になっている。
DICOM/WWW サーバのアーキテクチャの概略は次の図１のとおりである。
図１ DICOM/WWW サーバのアーキテクチャ
DICOM/WWW サーバ自身は非常に単純な機能、すなわち「DICOM in / WWW out」を提供する。システムとして DICOM/WWW サーバをネットワークの資源として活用する形態についていくつかの例を挙げる。
Java アプリケーションによる画像ワークステーション
Java はホームページに埋め込まれる小さなアップレットより、GUI アプリケーションの開発にその真価を発揮する。特に、HTTP による通信や JPEG 画像の表示などは組み込みの機能として簡単に利用することができ、しかも、DICOM/WWW サーバでは、すべての機能（画像検索、画像処理）を HTTP によってアクセスすることができるので開発者はユーザインタフェイスのデザインに専念することができる。Java の実行環境はネットワーク性能やJPEG画像表示について十分にチューニングされており、DICOM ワークステーションに匹敵するクライアントを開発することも考えられる。
Active Server Pages による Web サーバ
Web サーバに Windows NT Server に標準で添付される Internet Information Server (IIS) を採用しているため、ホームページの作成には、Active Server Pages (ASP)の協力なスクリプティング機能を利用することができる。ASP を利用すると、アクティブなホームページを通常の HTML 文書の中に短いスクリプト（VBScript か Java Script で記述）を埋め込むだけで作成することができる。Perl 言語で HTML 文書を生成するようプログラミングしなければならない CGI に比べてホームページの作成が大幅に容易になる。特に、内部の DICOM 画像データベースにアクセスする ActiveX コンポーネントを添付するため、スクリプトでダイレクトに画像データの検索ができる。
MERIT-9 による利用
MERIT-9 においては MML 文書からの画像参照は URL によって行う。DICOM ファイルのコピーや JPEG に変換したファイルを MML 文書に添付する代わりに DICOM/WWW サーバ上の URL を指定することでデータ交換の量やコピー／変換の手間を大幅に減らすことができる。