mybook

ユースケース:医療 — 電子カルテ連携 AI 診断支援システム

「ソウタくん、次の案件なんだけど」

カイがSlackで送ってきた資料のタイトルを見て、ソウタの指が止まった。

「聖路加メディカルネットワーク — AI 画像診断支援システム導入検討」

フィンテック案件で自信をつけたばかりのソウタだったが、医療という二文字が持つ重みは桁違いだった。金融は間違えれば金を失う。医療は間違えれば命を失う。

「カイさん、僕に医療は……」

「不安か?」

「正直、はい。医療の知識がまったくないです」

カイの返信は意外なものだった。

「フィンテックの時も金融の知識はなかっただろう。FDE に必要なのは業界の専門知識じゃない。専門家から本質的な課題を引き出し、技術で解決する力だ。ただし——」

カイは一拍置いた。

「医療には、他の業界にない絶対的な制約がある。患者の命と個人情報だ。ここを軽視した瞬間、プロジェクトは終わる。技術的に正しいだけでは足りない。臨床的に正しいかどうかが問われる」

ソウタはモニターに映る資料を改めて見つめた。5つの病院、800名の医師、年間120万人の外来患者。一つのバグが、一人の患者の診断に影響しうるシステム。

「わかりました。やります」

「いい覚悟だ。まずは相手を知ろう」

顧客プロフィール — 聖路加メディカルネットワーク

聖路加メディカルネットワークは、大学病院を中核とした5施設のグループだ。ソウタはカイと一緒に、事前リサーチで以下を把握した。

項目詳細
施設数大学病院1 + 関連病院4(計5施設)
医師数約800名(常勤600 + 非常勤200)
年間外来患者数120万人
電子カルテ3ベンダー混在(施設ごとにバラバラ)
画像診断件数年間45万件(CT/MRI/X線)
読影レポート作成時間平均40分/件
画像診断の見落とし率約3%(業界平均2.5%)

「見落とし率3%。45万件の3%は13,500件だ」カイが静かに言った。「この数字の裏に、13,500人の患者がいる」

ステークホルダーマップ

医療機関のステークホルダーは、一般企業とは構造が異なる。意思決定が分散しており、各診療科が独立した王国のように機能する。

Loading diagram...

WARNING

医療機関では、IT部門に予算権限がないケースが多い。最終決裁者は病院長や理事会だが、現場のキーマンである診療科長が反対すれば導入は頓挫する。MEDDIC でいう Economic Buyer と Champion が分離しやすい業界だ。

ソウタは Chapter 8 で学んだ MEDDIC を頭の中で組み立てた。

  • M(Metrics): 見落とし率3%→1%以下、読影時間40分→15分
  • E(Economic Buyer): 病院長・理事会
  • D(Decision Criteria): 薬事法適合、既存カルテとの連携、医師の受容性
  • D(Decision Process): 倫理委員会→医療情報委員会→理事会の三段階承認
  • I(Identify Pain): 読影医の過重労働、見落としリスク、施設間の情報断絶
  • C(Champion): 医療情報部長の佐藤先生(AI推進派)

ディスカバリーフェーズ — 医師の言葉で聴く

医療特有のディスカバリー質問

ソウタは Chapter 5 の SPIN フレームワークを医療に適応させた質問リストを作った。しかし、カイのレビューは厳しかった。

「この質問、『現在のワークフローのペインポイントは何ですか?』って書いてあるけど、医師に『ペインポイント』なんて言うなよ」

「え、なんでですか?」

「医師にとってペインポイントは患者が訴えるものだ。彼らの言葉で聞け。『先生が日々の読影で、最も時間がかかる工程はどこですか?』——こう聞くんだ」

INFO

医療機関へのディスカバリーでは、ビジネス用語を避け、臨床の文脈に沿った質問をすること。「ROI」ではなく「患者アウトカムの改善」、「スケーラビリティ」ではなく「他の診療科への展開可能性」と言い換える。言葉の選び方一つで、医師の協力姿勢が変わる。

ソウタが練り直した質問リストの一部を示す。

SPIN カテゴリ一般的な聞き方医療向けに翻訳
Situationワークフローを教えてください先生の一日の読影の流れを教えていただけますか
Problemペインポイントは何ですか読影で最も負担を感じる場面はどこですか
Implicationビジネスインパクトは見落としが起きた場合、患者さんや病院にどんな影響がありますか
Need-payoffROI はどの程度見込めますかもし読影時間が半分になったら、先生の時間をどう使いたいですか

放射線科・田中教授とのセッション

最初のディスカバリーは、放射線科の田中教授との1時間だった。

田中教授は白衣のまま会議室に入ってきた。開口一番、こう言った。

「AI で読影が自動化できるとは思っていません。それを前提で話してくださいね」

ソウタの心臓が跳ねた。しかし、カイに言われた通り、反論せずに受け止めた。

「もちろんです。先生の読影を置き換えるつもりはありません。先生が見落としなく、より早く診断できるための『第二の目』として使えるかどうか、今日はお話を伺いたいんです」

田中教授の表情がわずかに和らいだ。

「『第二の目』か。それなら話を聞こう」

30分後、田中教授は自ら課題を語り始めた。

「正直なところ、当直明けの読影が怖いんです。CT を100件近く読むこともある。集中力が落ちた状態で、肺の小結節を見落とすリスクは自覚しています。見落としを防ぐダブルチェックの仕組みがあれば、それは患者のためになる」

ソウタはこの言葉をノートに書き留めた。「当直明けの読影が怖い」——これが本質的な痛みだった。

現行アーキテクチャの課題

ディスカバリーを通じて、聖路加メディカルネットワークの IT 基盤の実態が見えてきた。

Loading diagram...

3つの異なる電子カルテベンダーが混在し、施設間のデータ連携はほぼ手動だった。PACS(医用画像管理システム)だけが唯一の共通基盤だったが、カルテ情報との紐付けは施設ごとにバラバラだった。

「つまり、統一した患者データを取得する API すら存在しないということですね」ソウタが確認した。

医療情報部長の佐藤先生がうなずいた。「その通りです。HL7 FHIR を導入したいとずっと言ってきましたが、各施設の電子カルテベンダーが対応してくれない。予算もつかない」

ソウタは、このプロジェクトが単なる AI モデルの導入ではなく、データ基盤の整備から始まるプロジェクトだと理解した。

PoC フェーズ — 「臨床的に使えるか」を証明する

FHIR API 連携基盤

ソウタは PoC の技術スタックを設計した。カイのアドバイスは明確だった。

「医療データの標準規格は HL7 FHIR だ。各ベンダーの独自 API を直接叩くんじゃなく、FHIR ファサードを作って統一的にアクセスできるようにしろ。これが長期的なスケーラビリティの鍵になる」

# app/services/fhir_client.rb
class FhirClient
  BASE_HEADERS = {
    "Content-Type" => "application/fhir+json",
    "Accept" => "application/fhir+json"
  }.freeze
 
  def initialize(endpoint:, auth_token:)
    @endpoint = endpoint
    @auth_token = auth_token
    @conn = Faraday.new(url: endpoint) do |f|
      f.request :json
      f.response :json
      f.adapter Faraday.default_adapter
    end
  end
 
  # 患者リソースを FHIR R4 形式で取得
  def fetch_patient(patient_id)
    response = @conn.get("Patient/#{patient_id}") do |req|
      req.headers = authorized_headers
    end
 
    raise FhirError, response.body unless response.success?
 
    FhirPatientMapper.from_resource(response.body)
  end
 
  # 画像検査(ImagingStudy)を検索
  def search_imaging_studies(patient_id:, modality: nil)
    params = { patient: patient_id }
    params[:modality] = modality if modality # CT, MRI, CR など
 
    response = @conn.get("ImagingStudy", params) do |req|
      req.headers = authorized_headers
    end
 
    bundle = response.body
    bundle.dig("entry")&.map { |e| e["resource"] } || []
  end
 
  private
 
  def authorized_headers
    BASE_HEADERS.merge("Authorization" => "Bearer #{@auth_token}")
  end
end

患者データの匿名化パイプライン

医療データを AI モデルに渡す前に、個人を特定できる情報を除去する必要がある。個人情報保護法の「仮名加工情報」の要件を満たすパイプラインを構築した。

# app/services/anonymization_pipeline.rb
class AnonymizationPipeline
  # 仮名加工情報の基準に準拠した匿名化処理
  DIRECT_IDENTIFIERS = %i[
    name address phone_number email
    insurance_number my_number
  ].freeze
 
  QUASI_IDENTIFIERS = %i[
    birth_date zip_code occupation
  ].freeze
 
  def initialize(key_store:)
    @key_store = key_store # 仮名化キーの安全な保管
  end
 
  def anonymize(patient_record)
    anonymized = patient_record.deep_dup
 
    # 直接識別子を仮名化(不可逆ハッシュ + ソルト)
    DIRECT_IDENTIFIERS.each do |field|
      next unless anonymized.respond_to?(field)
 
      original = anonymized.public_send(field)
      next if original.blank?
 
      pseudonym = generate_pseudonym(patient_record.id, field)
      anonymized.public_send(:"#{field}=", pseudonym)
    end
 
    # 準識別子を一般化(k-匿名性の確保)
    generalize_quasi_identifiers!(anonymized)
 
    # 匿名化ログを監査証跡として記録
    AuditLog.create!(
      action: "anonymize",
      target_type: "PatientRecord",
      target_id: patient_record.id,
      performed_at: Time.current,
      details: { fields_processed: DIRECT_IDENTIFIERS + QUASI_IDENTIFIERS }
    )
 
    anonymized
  end
 
  private
 
  def generate_pseudonym(record_id, field)
    salt = @key_store.fetch_salt(record_id)
    Digest::SHA256.hexdigest("#{record_id}:#{field}:#{salt}")[0..15]
  end
 
  def generalize_quasi_identifiers!(record)
    # 生年月日 → 年齢帯に変換(例: 1985-03-15 → "35-39")
    if record.respond_to?(:birth_date) && record.birth_date.present?
      age = ((Time.current - record.birth_date.to_time) / 1.year).floor
      age_band = "#{(age / 5) * 5}-#{(age / 5) * 5 + 4}"
      record.birth_date = nil
      record.age_band = age_band
    end
 
    # 郵便番号 → 上3桁に丸める(例: 160-0023 → "160-XXXX")
    if record.respond_to?(:zip_code) && record.zip_code.present?
      record.zip_code = record.zip_code[0..2] + "-XXXX"
    end
  end
end

WARNING

匿名化は「名前を消せば終わり」ではない。準識別子(生年月日・郵便番号・性別)の組み合わせで個人を再特定できるケースがある。k-匿名性(同じ属性を持つレコードが k 件以上存在する状態)を確保するために、準識別子の一般化が必須だ。

AI 診断支援サービス

ソウタが最も神経を使ったのは、AI モデルの出力の扱い方だった。「AI が診断する」のではなく、「AI が医師の注意を促す」という設計思想が必要だった。

# app/services/diagnosis_assistant.rb
class DiagnosisAssistant
  CONFIDENCE_THRESHOLD = 0.85 # この閾値以上で医師に通知
  CRITICAL_FINDINGS = %w[
    nodule mass hemorrhage pneumothorax fracture
  ].freeze
 
  def initialize(ai_client:, fhir_client:)
    @ai_client = ai_client
    @fhir_client = fhir_client
  end
 
  # 画像を解析し、所見候補を返す(診断ではなく "注意喚起")
  def analyze_imaging_study(study_id:, physician_id:)
    study = @fhir_client.fetch_imaging_study(study_id)
    anonymized_images = prepare_images(study)
 
    # AI モデルによる解析
    ai_result = @ai_client.analyze(
      images: anonymized_images,
      modality: study[:modality],
      body_region: study[:body_site]
    )
 
    # 所見候補をフィルタリング
    findings = ai_result[:findings].select do |finding|
      finding[:confidence] >= CONFIDENCE_THRESHOLD
    end
 
    # 結果を「支援情報」として構造化
    AssistantReport.create!(
      imaging_study_id: study_id,
      physician_id: physician_id,
      findings: findings.map { |f| format_finding(f) },
      ai_model_version: ai_result[:model_version],
      processing_time_ms: ai_result[:elapsed_ms],
      status: :pending_review, # 医師の確認待ち
      disclaimer: build_disclaimer
    )
  end
 
  private
 
  def format_finding(finding)
    {
      region: finding[:location],
      description: finding[:description],
      confidence: finding[:confidence],
      severity: classify_severity(finding),
      suggested_action: suggest_action(finding),
      # 医師が必ず確認すべきことを明示
      review_note: "この所見は AI による候補です。臨床判断は担当医が行ってください。"
    }
  end
 
  def classify_severity(finding)
    if CRITICAL_FINDINGS.any? { |cf| finding[:description].downcase.include?(cf) }
      :critical
    elsif finding[:confidence] >= 0.95
      :high
    else
      :moderate
    end
  end
 
  def build_disclaimer
    "本レポートは AI による支援情報であり、医学的診断ではありません。" \
    "すべての臨床判断は担当医師の責任において行われます。"
  end
end

INFO

AI 診断支援システムの設計原則は「Human-in-the-Loop」だ。AI の出力には必ず status: :pending_review を設定し、医師が確認・承認するまで正式な所見とはしない。「AI が見つけました」ではなく「先生が見落とさないための第二の目です」という位置づけが、医師の受容性を高める。

AWS インフラ構成

医療データを扱うインフラには、3省2ガイドライン(厚生労働省・経済産業省・総務省)準拠の厳格なセキュリティが求められる。

# config/initializers/aws_healthcare.rb
Rails.application.config.aws_healthcare = {
  vpc: {
    cidr: "10.100.0.0/16",
    private_subnets: %w[10.100.1.0/24 10.100.2.0/24],
    no_internet_gateway: true        # インターネット直結禁止
  },
  rds: {
    engine: "aurora-postgresql",
    encryption_at_rest: true,        # AES-256 / KMS管理鍵
    backup_retention_days: 35,
    audit_logging: true              # 全クエリの監査ログ
  },
  s3: {
    bucket: "seiryoku-medical-images",
    encryption: "aws:kms",
    block_public_access: true,       # パブリックアクセス完全ブロック
    lifecycle: { transition_to_glacier: 365 }
  },
  cloudtrail: {
    include_data_events: true        # S3 オブジェクトレベルの操作も記録
  }
}

規制対応 — SaMD と3省2ガイドライン

医療機器ソフトウェア(SaMD)とは

PoC が順調に進んだ矢先、カイから思わぬ指摘が入った。

「ソウタ、この AI システム、薬事法上は医療機器に該当する可能性がある。知ってたか?」

「え、ソフトウェアなのに医療機器……?」

「SaMD — Software as a Medical Device。AI が画像診断の支援をする場合、その出力が医師の診断に影響を与えるなら、薬機法上の管理医療機器(クラス II)に分類される可能性が高い。つまり、PMDA(医薬品医療機器総合機構)の認可が必要だ」

ソウタの顔が青ざめた。認可取得には通常1〜2年かかる。

「PoC の段階では研究利用として進められる。だが、本番導入を見据えるなら、早い段階で薬事戦略を立てる必要がある。ここを後回しにすると、技術的に完成しても市場に出せないという地獄を見る」

Loading diagram...

3省2ガイドラインへの準拠

医療情報を扱うクラウドシステムには、3省2ガイドラインへの準拠が求められる。ソウタはチェックリストを作成した。

ガイドライン主要要件技術的対策
厚生労働省監査証跡の保管CloudTrail 7年保管、全操作ログ
厚生労働省アクセス制御多要素認証 + IP制限 + RBAC
経済産業省保存時暗号化AES-256(KMS管理鍵)
経済産業省通信暗号化TLS 1.2以上
総務省ネットワーク分離専用VPC + プライベートサブネット
総務省侵入検知AWS GuardDuty + WAF
共通最小権限の原則IAM ポリシー + セッション30分タイムアウト

WARNING

3省2ガイドラインは「準拠している」と宣言するだけでは不十分だ。具体的な技術的対策の証跡を文書化し、定期監査で更新し続ける必要がある。FDE は顧客に「準拠しています」と言うだけでなく、「どの要件を、どの技術で、どう担保しているか」を一覧表で示せなければならない。

仮名加工情報の実装

個人情報保護法の2022年改正で導入された「仮名加工情報」の概念を正確に実装することが求められた。AnonymizationPipeline で直接識別子を除去した上で、モデル層では利用目的の記録と検証を行う。

# app/models/concerns/pseudonymizable.rb
module Pseudonymizable
  extend ActiveSupport::Concern
 
  ALLOWED_PURPOSES = %w[ai_training quality_improvement clinical_research].freeze
 
  included do
    def to_pseudonymous(purpose:)
      raise ArgumentError, "不正な利用目的: #{purpose}" unless ALLOWED_PURPOSES.include?(purpose.to_s)
 
      pseudonymous_record = self.class.new(
        age_band: calculate_age_band,      # 医療上必要な属性は保持
        sex: sex,
        medical_history: medical_history,
        pseudonym_id: SecureRandom.uuid,    # 個人識別情報は仮名化
        original_id_hash: Digest::SHA256.hexdigest("#{id}:#{Rails.application.secret_key_base}")
      )
 
      # 利用目的の記録(法的要件)
      PseudonymizationLog.create!(
        original_record_type: self.class.name,
        pseudonym_id: pseudonymous_record.pseudonym_id,
        purpose:,
        processed_at: Time.current
      )
 
      pseudonymous_record
    end
  end
end

本番デプロイと医師トレーニング

変革管理 — 医師の抵抗を乗り越える

PoC の技術的な成功とは裏腹に、本番展開への道のりは険しかった。最大の障壁は技術ではなく、医師の心理的抵抗だった。

「田中教授は協力的ですが、他の医師からの反発がすごいです」ソウタがカイに相談した。

「どんな反発だ?」

「大きく三つです。『AI に仕事を奪われる』『AI の判断は信用できない』『使い方を覚える暇がない』」

カイはうなずいた。

「どれも正当な懸念だ。否定するな。一つずつ、事実で答えろ。仕事を奪われる? →AI は読影医の仕事を増やさない、ダブルチェックの自動化だ。信用できない? →信頼度スコアと根拠領域を表示して、医師が判断する仕組みだ。暇がない? →ここが一番重要だ」

カイは続けた。

「医師に30分のトレーニングを受けろと言っても来ない。だから、システムを『学習不要』に設計しろ。既存の読影ワークフローの中に自然に溶け込むUIを作るんだ。新しい画面を開かせるな。今使っている PACS ビューワの横に、さりげなく表示される——それが理想だ」

段階的ロールアウト戦略

カイの指導のもと、ソウタは段階的な展開計画を策定した。

Loading diagram...

Phase 1 では、Champion である田中教授の放射線科だけに導入する。ここで成功事例を作り、他の診療科に「うちも使いたい」と言わせるのが戦略だ。

# app/services/rollout_manager.rb
class RolloutManager
  PHASES = {
    phase_1: {
      departments: ["放射線科"],
      modalities: %w[CT MRI],
      duration_months: 3,
      success_criteria: {
        physician_adoption_rate: 0.80,   # 読影医の80%が利用
        false_positive_rate: 0.10,        # 偽陽性率10%以下
        physician_satisfaction: 3.5       # 5段階評価で3.5以上
      }
    },
    phase_2: {
      departments: ["放射線科", "呼吸器内科", "消化器外科", "整形外科"],
      modalities: %w[CT MRI CR],
      duration_months: 3,
      success_criteria: {
        physician_adoption_rate: 0.70,
        false_positive_rate: 0.10,
        physician_satisfaction: 3.5
      }
    },
    phase_3: {
      departments: :all,
      modalities: :all,
      duration_months: 6,
      success_criteria: {
        physician_adoption_rate: 0.60,
        false_positive_rate: 0.08,
        physician_satisfaction: 4.0
      }
    }
  }.freeze
 
  def evaluate_phase(phase_key)
    phase = PHASES[phase_key]
    metrics = collect_metrics(phase)
 
    phase[:success_criteria].all? do |criterion, threshold|
      metrics[criterion] >= threshold
    end
  end
end

医師向けトレーニング設計

ソウタは Chapter 6 のデモ技法を医療向けにアレンジした。医師は多忙だ。30分以上の研修には出ない。

「トレーニング」という言葉すら使わなかった。代わりに「5分間ハンズオン」と名付けた。

実際のトレーニング内容は3ステップだった。

  1. 見る(1分): 田中教授が実際の読影で AI 支援を使う様子を動画で見せる
  2. 触る(3分): ダミーデータで自分の PACS ビューワ上で AI 支援を体験する
  3. 聞く(1分): 疑問点を田中教授(医師の言葉で説明できる Champion)に質問する

INFO

医療機関での Change Management は、技術者ではなく臨床の Champion に語らせるのが鉄則だ。「エンジニアが便利ですよと言う」のと「同僚の教授が使ってみたら見落としが減ったと言う」のでは、医師の受容度がまるで違う。FDE の仕事は Champion を育て、Champion に語らせる舞台を用意することだ。

成果測定 — 数字と物語で語る

定量成果

Phase 1 の3ヶ月間で、以下の成果が確認された。

指標BeforeAfter改善率
画像診断の見落とし率3.0%0.8%73%改善
読影レポート作成時間40分/件15分/件62.5%短縮
当直明けの読影エラー率5.2%1.1%78.8%改善
読影医の NPS-12+4557pt改善
緊急所見の報告遅延平均4.2時間平均0.8時間81%短縮

Chapter 17 で学んだメトリクスフレームワークに沿って、ソウタはこれらの数字を三層で整理した。

  • 患者アウトカム: 見落とし率73%改善(臨床的価値)
  • 業務効率: 読影時間62.5%短縮(運用的価値)
  • 医師体験: NPS -12→+45(ユーザー満足度)

インパクトストーリー

数字だけでは理事会は動かない。ソウタは一つの事例を用意した。

ある金曜日の深夜、当直3日目の若手放射線科医が胸部CTを読影していた。120件目の画像。疲労がピークに達していた。

AI システムが右肺下葉に8mmの小結節を検出し、信頼度93%のアラートを出した。

若手医師はアラートに従って画像を再確認し、結節を発見。翌週の精密検査で早期肺がん(ステージ IA)と診断された。

田中教授はこう語った。

「あの結節は、疲れた目では見逃していたかもしれない。AI が指摘してくれたから、もう一度注意深く見直せた。患者さんは早期発見のおかげで手術だけで済んだ。これが『第二の目』の価値です」

この事例が理事会に報告されたとき、全施設展開の予算が即座に承認された。

INFO

成果報告では「数字」と「物語」の両方が必要だ。数字は論理的な意思決定者(Economic Buyer)を動かし、物語は感情的な共感を生む。特に医療では、一人の患者の具体的なストーリーが、何千という統計データより強い説得力を持つことがある。

振り返りと学び — 「技術的に正しい」と「臨床的に使える」の違い

プロジェクトの節目に、ソウタとカイは振り返りを行った。

「ソウタ、このプロジェクトで一番難しかったことは何だ?」

ソウタは少し考えてから答えた。

「コードを書くことじゃなかったです。一番難しかったのは、医師の世界の言葉を理解することでした。最初、僕は『ワークフロー最適化』とか『データパイプライン』とか言っていた。でも医師にとって大事なのは『患者さんのために見落としをなくす』ことで、技術用語は壁を作るだけでした」

カイがうなずいた。

「いい気づきだ。FDE の仕事は技術を売ることじゃない。顧客の課題を、技術を使って解決することだ。そして医療では、その課題は常に患者の安全に繋がっている」

医療 FDE 固有の教訓

ソウタがまとめた教訓を以下に示す。

1. 規制は敵ではなく、信頼の源泉

SaMD対応や3省2ガイドライン準拠は、一見するとスピードを殺す障壁に思える。しかし、これらをクリアしていることが、医師や病院経営者の信頼を勝ち取る最大の武器になる。

2. 「置き換え」ではなく「増強」を設計する

医師は自分の専門性に誇りを持っている。「AI が診断します」と言えば反発される。「先生の読影をサポートします」と言えば受け入れられる。技術的には同じことでも、フレーミングで結果が180度変わる。

3. Champion は同じ言語を話す人を選ぶ

田中教授が Champion として機能したのは、医師として他の医師に語れたからだ。IT部門の佐藤先生がいくら推進しても、臨床医は「現場を知らない人の意見」として受け流していた。

4. データの匿名化は技術と法律の両方を理解する

仮名加工情報の実装には、個人情報保護法の条文理解と、k-匿名性やハッシュ化の技術的知識の両方が必要だ。どちらかが欠けると、法的にも技術的にも穴のあるシステムになる。

カイは最後にこう締めくくった。

「医療の案件は時間がかかる。規制、倫理委員会、医師の合意形成——フィンテックの倍は見ておけ。でも、成功したときのインパクトは計り知れない。一人の患者の命を救えるシステムを作れる FDE は、そう多くない。ソウタ、いい仕事だった」

実践演習

演習1: 医療データの匿名化戦略を設計せよ

以下のシナリオで、匿名化戦略を設計してください。

シナリオ: 糖尿病患者の治療効果を AI で予測するモデルを構築したい。以下のデータを使う。

  • 患者基本情報(氏名、生年月日、性別、住所、保険証番号)
  • 検査データ(HbA1c、血糖値、BMI、血圧)
  • 処方履歴(薬剤名、用量、期間)
  • 合併症情報(網膜症、腎症、神経障害の有無)

問い:

  1. どの項目を削除し、どの項目を仮名化し、どの項目をそのまま残すか分類せよ
  2. 準識別子の一般化ルールを定義せよ
  3. k-匿名性の k をいくつに設定するか、根拠とともに述べよ

演習2: 医師向けデモのシナリオを作成せよ

Chapter 6 のデモ技法を医療に応用し、以下の条件でデモシナリオを作成してください。

条件:

  • 対象: 消化器外科の部長(AI に懐疑的、60代、紙カルテ時代を知る世代)
  • 時間: 15分(部長が取れる最大の時間)
  • 目的: Phase 2 への参加合意を得る

問い:

  1. 開始3分で何を見せるか(「つかみ」の設計)
  2. 消化器外科特有のユースケースをどう盛り込むか
  3. 懐疑的な医師からの想定質問3つと、その回答を用意せよ

演習3: SaMD 認可に必要なドキュメントリストを作成せよ

AI 画像診断支援システムをクラス II 管理医療機器として PMDA に申請する場合に必要なドキュメントを整理してください。

問い:

  1. 申請に必要な技術文書のリストを作成せよ(最低8項目)
  2. 臨床性能試験の計画書に含めるべき要素を5つ挙げよ
  3. FDE として、開発チームと薬事チームの橋渡しをするために、どんなドキュメントを自主的に作成すべきか提案せよ

INFO

医療 FDE の核心は、「技術的に正しいシステム」ではなく「臨床的に信頼されるシステム」を作ることにある。規制対応、データ匿名化、医師との協働——これらすべてが、患者の安全という一つのゴールに収束する。技術力だけでは足りない。医療の文脈を理解し、医師の言葉で語れる FDE だけが、この領域で成功できる。