JMDC TECH BLOG

JMDCのエンジニアブログです

DICOMデータを匿名化してみた

みなさん、こんにちは!株式会社JMDC 医療機関支援事業部 データ取得ツールグループの崔です。

今年、JMDCではアドベントカレンダーに参加しています。

qiita.com

本記事は、JMDC Advent Calendar 2024 18日目の記事です。 この後も記事をどんどん出す予定なので、チェックのほどよろしくお願いいたします!

はじめに

データ取得ツールグループでは電子カルテのデータの取得や、レセプト・DPCデータのチェックや提出前の匿名化・名寄せ・暗号化などの各種データ加工を行うツールの開発を行っております。

今回、匿名化行程の一部として、CTやMRIなどで撮影した画像に含まれる個人識別子(個人を識別するために使われる情報)の除去を行う事になりました。

医療機関にて利用される医用画像データには全世界で利用されているDICOMという標準規格があり、データ構造や通信のプロトコルなどが定義されています。 受領するデータもこのDICOM形式の画像になっており、個人識別子の除去についても標準的なプロファイルが定義されているのでそれに基づき各種個人識別子の処理を行いました。

DICOMの基本

上記の通り、主に以下の2点が定義されています

  • データ構造の定義:画像(やその周辺データ)データの格納方法
  • 通信仕様の定義:上記の画像(やその周辺データ)を各システム間で通信する際のプロトコル
    ※今回は既に撮影済みの画像をファイルとして受領し、それらについて処理を行うため通信仕様については触れません

画像データには「画像(つまりレントゲンの絵)」の部分と、「メタ情報(撮影日時、患者情報など)」の両方が含まれています。

メタ情報は「タグ」と呼ばれるデータの種類を識別する情報とそれに対応する「値」がそれぞれ格納されています。

「タグ」 にはさまざまな種類があり

  • 「患者名」「患者ID」などの「患者の属性を表すもの」
  • 「画像の幅」「画像の高さ」などの「画像データの属性を表すもの」
  • 「撮影日時」「撮影した機材情報」などの「撮影にまつわる属性情報」 などさまざまな情報が含まれています。

個人識別子の処理を行う必要があるのは主に「メタ情報」ですが「画像」にも個人識別子が含まれている可能性があり両者共に処理を行っています。

処理しなければならないタグはどれ?

上記のようにメタ情報にはさまざまな情報が含まれており、個人の識別に繋がるような情報については何かしらの形で処理しなければなりません。

ただし、DICOMにて定義されているタグは数千にのぼるため、どのタグを処理しなければならないかを特定するのは非常に困難です。

幸いNEMA(DICOMを策定している機関)が「Security and System Management Profiles」という物を公開しており、これの「6.9 Attribute Confidentiality Profiles」にて「匿名化するにあたって処理が必要なタグ」の基本的なProfileを公開してくれています。

もちろん、これだけでは不十分なのでJMDC独自の基準と照らし合わせて更に処理対象のタグを追加していますが、基本的にはこの「6.9 Attribute Confidentiality Profiles」をベースに各タグの処理を行いました。

細かい所はさておき、基本的な処理方針としては以下の通りとしています。

  • Basic Profileにてタグごと削除とされているもの:タグごと削除
  • Basic Profileにてタグを残し値を削除とされているもの:タグを残し値を削除
  • Basic Profileにて変換が必要とされているもの:タグを残し値は変換(主にUIDなど)
  • Basic ProfileにてKeep(残す)とされているもの:タグ毎に個別判断

上記基本方針にのっとって処理された画像ファイルですが、削除されていないタグ情報に個人識別子が残存している可能性があるためチェックを行い問題無ければ最終的な成果物としています。

画像に埋め込まれている個人識別子

メタ情報については文字列情報やバイナリデータなので比較的システムにて処理が容易なのですが「画像」情報にも以下のような個人の識別に繋がる情報が含まれている可能性があります。

  • 頭部のCT、MRIなどの場合はスライス画像を合成すると顔貌情報を再構成出来るため個人の識別に繋がる可能性がある
  • 画像情報として「患者名」「患者ID」「撮影日時」「医療機関名称」などの文字列が埋め込まれている可能性がある

他にもありますが主には上記の点にも気を付けなければなりません。 今回対象としている画像は幸い腹部だったので「顔貌」情報については気にする必要はありませんでしたが2番目についてはチェックが必要です。

「画像に文字列などが埋め込まれている」と言ってもあまりピンとこない方も多いかと思いますが例えば以下のような物があります

  • スカウト画像と呼ばれる「スライス位置」や「撮影情報」などが埋め込まれている物
  • 「スタンプ」などと呼ばれる画像に「患者名」「撮影日」「患者ID」などが埋め込まれている物 などがあります。

本当はサンプル画像をこちらに記載出来れば良いのですが、権利関係などで適切な画像が見当たらないので気になる方は検索などしてみてください。

こちらのチェックについてはメタ情報のようにシステム的な処理が難しいため、画像を目視で確認の上チェックを行いました。 (一般的なCT、MRI画像の場合、1検査につき数十~数百枚の画像が作成されるため、こちらのチェックは非常に大変でした・・・)

まとめ

今回DICOMデータの匿名化の一工程として、個人識別子の削除を行ってみました。

匿名化処理の基本的な要求性は抑えつつ、DICOMデータ特有の各種処理・チェックが必要となったため当初想定よりも大分大変な作業となりました。

今後の展望としては

  • タグのチェックのさらなる自動化
  • 画像に埋め込まれている文字列の自動検出

あたりが実現出来ればさらなる省力化が可能かなと思っています。機会があればチャレンジしてみようと思います。

明日19日目は、古橋さんによる「失敗から学んだAWS CloudFormationの仕様」です。お楽しみに!

JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です!フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。 hrmos.co まずはカジュアルにJMDCメンバーと話してみたい/経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。 hrmos.co ★最新記事のお知らせはぜひ X(Twitter)、またはBlueskyをご覧ください! twitter.com bsky.app