DICOM ファイル共有 in Healthcare: ベストプラクティス

現代のDICOMファイル共有はCDベースの物理的な転送やレガシーのDIMSEではなく、HTTPS上のDICOMウェブ標準（WADO-RS、STOW-RS、QIDO-RS）を使う。標準的な胸部CTは300〜800MBを生成し、複数シーケンスの心臓MRIは2GBに達する。個人情報保護法（APPI）と個人情報保護委員会（PPC）のガイドラインは患者画像データにも適用され、日本の医療機関も適切な暗号化と転送ログの維持が必要だ。

CDベースの画像転送が衰退している理由

20年間、病院はDICOM検査をビューア内蔵のCDに書き込んで送付してきた。ワークフローは馴染み深いが問題が多かった：

書き込み速度：イメージングセンターでCD1枚に3〜5分
読み取り失敗：受領施設でCDの10〜20%が読み取り不能
ビューア互換性：内蔵ビューアが最新のmacOSやLinuxで動作しないことが多い
物理的な輸送：緊急転送でもFedEx翌日配送で18〜24時間
CD紛失：一定の割合が意図した目的地に届かない

ACRと放射線科学会は長年にわたり電子的な交換を推進してきた。Ambra、LifeImage、PocketHealthなどのクラウドプラットフォームが、主要な学術医療センターでは患者主導の画像共有を標準にしている。

DICOMウェブ：モダンな標準規格

DICOMウェブはDICOMネットワークプロトコルのHTTPベース版だ。3つの主要サービス：

STOW-RS（Store over Web）：HTTP POSTでDICOMオブジェクトをサーバーへ送信
WADO-RS（Web Access to DICOM Objects）：HTTP GETでDICOMを取得
QIDO-RS（Query based on ID）：HTTP経由でStudy/Series/Instanceを照会

3つすべてがHTTPS上でTLS 1.2またはTLS 1.3で動作し、レガシーDICOM DIMSE（ポート104または11112）では実現できなかったファイアウォール対応が可能になる。認証にはOAuth 2.0またはクライアント証明書を使用する。

ほとんどのモダンなPACSベンダーがDICOMウェブエンドポイントを提供している。クラウドネイティブプラットフォーム（Google Cloud Healthcare API、AWS HealthImaging、Azure DICOM Service）はDICOMウェブファーストの設計だ。

モダリティ別のピクセルデータサイズと帯域計画

検査サイズはモダリティによって大きく異なる：

胸部X線（CRまたはDX）：5〜15MB（非圧縮）、JPEG 2000で1〜3MB
頭部CT：100〜300MB
胸部CT：300〜800MB
腹部/骨盤CTコントラスト：500MB〜1.5GB
脳MRI（複数シーケンス）：150〜400MB
心臓MRI：500MB〜2GB
マンモグラフィ（デジタルブレストトモシンセシス）：試験あたり500MB〜1.5GB
病理ホールスライドイメージング（WSI）：スライドあたり1〜10GB
3D心エコー：200〜500MB

1日500件の検査を行う放射線科は毎日150GB〜1TBの新しい画像データを生成する。主要な紹介先との間には専用1Gbpsリンクがますます一般化している。

圧縮：非可逆、可逆、診断上の問題

DICOMはいくつかの転送構文に対応している：

非圧縮（Explicit VR Little Endian）：ベースライン、最大サイズ
JPEG Lossless：2〜3倍圧縮、完全可逆
JPEG 2000 Lossless：3〜4倍圧縮、現在の可逆推奨
JPEG 2000 Lossy：10〜20倍圧縮、情報を破棄
HTJ2K（High-Throughput JPEG 2000）：新しい、同様の圧縮率、高速デコード

一次診断用途にはACRガイドラインが可逆圧縮を推奨している。二次レビュー、遠隔診断、患者向け閲覧には非可逆圧縮が明示的な文書化を伴えば許容される。

米国のスクリーニングマンモグラフィに非可逆圧縮を適用することは絶対に禁止。FDA MQSAは一次診断マンモグラムの可逆表示を要求している。

患者主導の画像共有

Cures Actの情報ブロッキングルールは画像にも及ぶ。患者は自分の画像に電子的にアクセスする権利を持つ。対応プラットフォーム：

PocketHealth：患者向け画像アクセス、700以上のイメージングセンターと統合
LifeImage（現Mach7の一部）：プロバイダー間および患者間
Ambra Health（Intelerad）：クラウド画像交換、患者ポータル
Apple Health：FHIRのImagingStudyリソース経由でますます画像を取得

放射線科にとって、これらのサービスのいずれかを提供することは事実上必須になっている。患者アクセスを提供しないことは、OCRにより情報ブロッキングと解釈され、CMP（民事制裁金）の対象となりうる。

研究・教育のための匿名化

研究、学会発表、教育ファイルにはPHIのないDICOMデータが必要だ。DICOMはDICOM PS 3.15 Annex EのBasic Application Confidentiality Profileで削除または置換が必要なタグを規定している。

対処すべき主要タグ：

PatientName (0010,0010)
PatientID (0010,0020)
PatientBirthDate (0010,0030)
StudyDate (0008,0020)：患者内でランダムオフセットでシフト可能
ReferringPhysicianName (0008,0090)
InstitutionName (0008,0080)
UID：研究用UIDに置換、参照整合性を維持

対応する適切なツール：Posda（CTPベース）、RSNA MIRC CTP、pydicomカスタムスクリプト、dcm4che。ピクセルに焼き込まれたPHIは別途削除が必要であることを常に確認。DICOMタグをクリアするだけでは画像ピクセルに埋め込まれたテキストは除去されない。

監査ログとアクセス制御

HIPAAとIHEの監査証跡・ノード認証（ATNA）プロファイルはすべてのDICOMイベントのログを規定している：

誰がアクセスしたか（認証済みユーザー）
何にアクセスしたか（Study/Series/Instance UID）
いつ（タイムスタンプ）
どこから（送信元IP）
どんなアクション（表示、ダウンロード、変更、削除）

ほとんどのモダンなPACSとVNAベンダーがこれらのログをネイティブに生成する。SIEM（Splunk、Sentinel、QRadar、Datadog）にシップし、少なくとも6年間保存する。これがHIPAAの記録の最低保存期間だ。

クラウド画像：Google、AWS、Azure

クラウドプロバイダーは自社のDICOMサービスを提供している：

Google Cloud Healthcare API：DICOMウェブエンドポイント付きのDICOMストア、BAA対象
AWS HealthImaging：フレームごとの遅延ロード最適化DICOMストレージ
Azure DICOM Service：マネージドDICOMウェブエンドポイント、Azure FHIRと統合

価格はストレージあたり月0.02〜0.05ドル、プラスデータ転送とAPIコスト。年間10TBの中規模放射線実践では月200〜500ドル程度。

これらのサービスはBAAに署名しコンプライアンスエンジニアリングの多くを処理してくれる。トレードオフはベンダーロックインとオンプレミス資本支出に対する継続的なコストだ。

HexaTransferを使ったアドホックDICOM転送

PACSやクラウドプラットフォームの外でDICOMアーカイブを送付する必要がある場合（例：患者が自分のCDを持参し、別施設のPACSに取り込む前に放射線科医に確認を求めるケース）、BAA対象のHexaTransferエンタープライズサービスが機能する。AES-256-GCMで暗号化し、TLS 1.3で転送、有効期限を設定し、転送ログを保持する。

放射線科実践のための実践的なDICOM交換設定：

PACS：既存のエンタープライズベンダーまたはクラウドDICOM
VNA：Hyland、IBM Merge、VisageまたはクラウドネイティブVNA
画像交換：Ambra、LifeImage、またはPocketHealth
匿名化：研究用のRSNA MIRC CTPまたはMIM
アドホック暗号化転送：BAA署名E2EEサービス
監査ログ保存：SIEMで6年以上

詳細は https://hexatransfer.com で確認できる。