ユースケース:医療 — 電子カルテ連携 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人の患者がいる」
ステークホルダーマップ
医療機関のステークホルダーは、一般企業とは構造が異なる。意思決定が分散しており、各診療科が独立した王国のように機能する。
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-payoff | ROI はどの程度見込めますか | もし読影時間が半分になったら、先生の時間をどう使いたいですか |
放射線科・田中教授とのセッション
最初のディスカバリーは、放射線科の田中教授との1時間だった。
田中教授は白衣のまま会議室に入ってきた。開口一番、こう言った。
「AI で読影が自動化できるとは思っていません。それを前提で話してくださいね」
ソウタの心臓が跳ねた。しかし、カイに言われた通り、反論せずに受け止めた。
「もちろんです。先生の読影を置き換えるつもりはありません。先生が見落としなく、より早く診断できるための『第二の目』として使えるかどうか、今日はお話を伺いたいんです」
田中教授の表情がわずかに和らいだ。
「『第二の目』か。それなら話を聞こう」
30分後、田中教授は自ら課題を語り始めた。
「正直なところ、当直明けの読影が怖いんです。CT を100件近く読むこともある。集中力が落ちた状態で、肺の小結節を見落とすリスクは自覚しています。見落としを防ぐダブルチェックの仕組みがあれば、それは患者のためになる」
ソウタはこの言葉をノートに書き留めた。「当直明けの読影が怖い」——これが本質的な痛みだった。
現行アーキテクチャの課題
ディスカバリーを通じて、聖路加メディカルネットワークの IT 基盤の実態が見えてきた。
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
endWARNING
匿名化は「名前を消せば終わり」ではない。準識別子(生年月日・郵便番号・性別)の組み合わせで個人を再特定できるケースがある。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
endINFO
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 の段階では研究利用として進められる。だが、本番導入を見据えるなら、早い段階で薬事戦略を立てる必要がある。ここを後回しにすると、技術的に完成しても市場に出せないという地獄を見る」
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 ビューワの横に、さりげなく表示される——それが理想だ」
段階的ロールアウト戦略
カイの指導のもと、ソウタは段階的な展開計画を策定した。
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分): 田中教授が実際の読影で AI 支援を使う様子を動画で見せる
- 触る(3分): ダミーデータで自分の PACS ビューワ上で AI 支援を体験する
- 聞く(1分): 疑問点を田中教授(医師の言葉で説明できる Champion)に質問する
INFO
医療機関での Change Management は、技術者ではなく臨床の Champion に語らせるのが鉄則だ。「エンジニアが便利ですよと言う」のと「同僚の教授が使ってみたら見落としが減ったと言う」のでは、医師の受容度がまるで違う。FDE の仕事は Champion を育て、Champion に語らせる舞台を用意することだ。
成果測定 — 数字と物語で語る
定量成果
Phase 1 の3ヶ月間で、以下の成果が確認された。
| 指標 | Before | After | 改善率 |
|---|---|---|---|
| 画像診断の見落とし率 | 3.0% | 0.8% | 73%改善 |
| 読影レポート作成時間 | 40分/件 | 15分/件 | 62.5%短縮 |
| 当直明けの読影エラー率 | 5.2% | 1.1% | 78.8%改善 |
| 読影医の NPS | -12 | +45 | 57pt改善 |
| 緊急所見の報告遅延 | 平均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、血圧)
- 処方履歴(薬剤名、用量、期間)
- 合併症情報(網膜症、腎症、神経障害の有無)
問い:
- どの項目を削除し、どの項目を仮名化し、どの項目をそのまま残すか分類せよ
- 準識別子の一般化ルールを定義せよ
- k-匿名性の k をいくつに設定するか、根拠とともに述べよ
演習2: 医師向けデモのシナリオを作成せよ
Chapter 6 のデモ技法を医療に応用し、以下の条件でデモシナリオを作成してください。
条件:
- 対象: 消化器外科の部長(AI に懐疑的、60代、紙カルテ時代を知る世代)
- 時間: 15分(部長が取れる最大の時間)
- 目的: Phase 2 への参加合意を得る
問い:
- 開始3分で何を見せるか(「つかみ」の設計)
- 消化器外科特有のユースケースをどう盛り込むか
- 懐疑的な医師からの想定質問3つと、その回答を用意せよ
演習3: SaMD 認可に必要なドキュメントリストを作成せよ
AI 画像診断支援システムをクラス II 管理医療機器として PMDA に申請する場合に必要なドキュメントを整理してください。
問い:
- 申請に必要な技術文書のリストを作成せよ(最低8項目)
- 臨床性能試験の計画書に含めるべき要素を5つ挙げよ
- FDE として、開発チームと薬事チームの橋渡しをするために、どんなドキュメントを自主的に作成すべきか提案せよ
INFO
医療 FDE の核心は、「技術的に正しいシステム」ではなく「臨床的に信頼されるシステム」を作ることにある。規制対応、データ匿名化、医師との協働——これらすべてが、患者の安全という一つのゴールに収束する。技術力だけでは足りない。医療の文脈を理解し、医師の言葉で語れる FDE だけが、この領域で成功できる。