Facility Report — 名古屋大学 / 2026-03-31 統合版

名古屋大学 CS 4D Flow active 訪問報告 2026-03-31

2026年3月31日の名古屋大学病院訪問を、単発の出張メモではなく、施設単位の運用レイヤーへ統合した explainer。CS 4D Flow 正式ライセンス、マグフィ安全運用、ESGAR/ISMRM 発表フォロー、加藤さん新体制を一枚で追跡できるように整理する。

TL;DR

  1. CS 4D Flow は Trial 運用から正式ライセンス運用へ切り替わる節目であり、2027年2月24日の期限を前倒し管理する必要がある。
  2. マグフィは研究技術ではなくMR安全運用の入口であり、検出性能だけでなく導線、停止判断、MR管理者負荷を確認する。
  3. ESGAR ePoster と ISMRM disclosure は研究発信のボトルネックであり、登録完了、症例数、解析済みデータを分けて確認する。
  4. Project Dossier はまだ stub なので、今回の判断根拠は元報告と過去訪問報告を主軸にし、要確認事項は可視化して残す。

01訪問の全体像 — facility report layer に置く理由

同じ日に複数のProjectと運用テーマを扱ったため、Project成果物ではなく施設横断の訪問報告として整理する。

Nagoya University facility visit four lanes
3/31訪問は、正式ライセンス、MR安全、学会発表、技師長期連携の4レーンを同時に扱った。

この訪問は、CS 4D Flow 正式ライセンス導入、マグフィデモ機動作確認、ESGAR/ISMRMフォロー、加藤さん新体制への配慮が同日に重なった。単一Projectの成果物ではなく、施設横断の運用記録として読むのが正しい。

レーン訪問時の事実施設統合で見る理由
CS 4D Flow正式ライセンスが発行済みで、Prisma fit XA60 への導入確認を実施研究継続性、契約、装置更新、HQ連携が同時に関係する
マグフィ3/30設置、3/31動作確認研究ではなくMR安全導線とMR管理者負荷のテーマ
ESGAR/ISMRMePosterとdisclosureの登録進捗を確認研究成果発信の期限管理と共同著者手続きに関係する
連絡体制加藤さんが4月から副主任技師兼MR管理者今後の訪問調整と依頼粒度を変える必要がある

📚 用語解説 — Facility Report Layer: `0000_報告書/` に置く、施設単位の訪問記録。Projectごとの `5_Deliverable/` は成果物やマイルストーン用であり、同日に複数Projectを扱う訪問報告とは役割が違う。
📚 用語解説 — source of truth: 本件では `260406_名古屋0331_報告書_v1.md` が元報告であり、explainerは閲覧用の再構成レイヤー。
📚 用語解説 — local_only: 契約番号、ライセンスファイル名、関係者名を含むため、外部公開やCloudflare deployを前提にしない内部資料。

🛠️ 運用方法: (1) 元報告を事実根拠として読む。 (2) Project Bridge の名古屋 active projects を確認する。 (3) Facility Report Layer に最終報告を置き、Project Dossierには関連報告としてリンクする。 (4) 未確認事項は消さず、次アクション表に残す。

⚠️ アンチパターン: CS 4D Flow の話だけに圧縮すると、マグフィ安全運用と加藤さん新体制の負荷が消える。逆にマグフィを一般安全メモだけで扱うと、同日のライセンス導入と学会発信フォローから切り離され、訪問後の優先順位が崩れる。

02CS 4D Flow — Trial から正式ライセンスへ

3/28署名完了と正式ライセンス発行を受け、Prisma fit XA60 上で研究継続性を確保する段階。

CS 4D Flow license transition
3/31訪問は、Trial bridgeを閉じて正式ライセンス運用へ移すための現地確認だった。

契約書の兵藤先生・長縄先生署名は3月28日に大草さん経由で完了し、Daniel Giese より正式ライセンスが発行済みだった。3月31日は Prisma fit XA60 にライセンスファイルをインストールし、従来のTrial Licenseブリッジ運用から正式ライセンス運用へ切り替える現地確認だった。

項目BeforeAfter / 次状態
契約Compliance Approval 完了後、wet signature 回収待ち3/28に兵藤先生・長縄先生署名完了、PDF本社提出済み
ライセンスTrial License によるブリッジ運用正式ライセンス発行済み、有効期限 2027-02-24
対象装置研究継続に必要なXA60環境を確保する必要ありMAGNETOM Prisma fit 3T XA60 にインストール確認
未確定点起動確認の最終結果が元報告で要確認WIP起動、プロトコル表示、Daniel報告の完了確認が必要

📚 用語解説 — WIP_039 AdvFlow: Advanced 4D Flow with Multi VENC mode として扱われる研究用WIP。元報告では `wip/039_AdvFlow` として記載されている。
📚 用語解説 — Trial bridge: 正式ライセンス発行まで研究継続を止めないための暫定運用。期限切れやurgent依頼が起きやすく、恒久運用にしてはいけない。
📚 用語解説 — Version + Option + WIP build: 装置名だけで互換性を判断せず、ソフトウェアVersion、必要Option、WIP buildの組合せで判断する考え方。

🛠️ 運用方法: (1) Prisma fit XA60 でライセンス認識とWIP起動結果を確認する。 (2) Danielへインストール完了通知を送る。 (3) 2027-02-24期限に対し、遅くとも2026-12から更新準備を始める。 (4) Cima.X XA61 と Vida Fit XB10 については、開示範囲を加藤さんと合意してから説明する。

⚠️ アンチパターン: 正式ライセンス発行をもって完了扱いにすると、対象装置でのWIP起動確認、試用時プロトコルとの整合、Danielへの完了報告が抜ける。さらに、次回更新を2027年2月直前まで放置すると、HQへurgent requestを再発させる。

03マグフィ — 安全運用を現場導線で評価する

デモ機の動作確認は機器性能だけでなく、誰が止めるか、どこで検出するか、負荷が誰に寄るかを確認する。

MRI ferromagnetic detector workflow
マグフィは検出性能だけでなく、検出後に現場が止まれるかまで評価する。

マグフィデモ機は3月30日に加藤さん手配で設置され、3月31日に動作確認した。元報告では結果と今後の運用方針が要確認として残っているため、検出できたかだけでなく、現場導線と停止判断の設計まで確認する必要がある。

評価軸Before / 未整理After / 確認したい状態
検出性能デモ機設置済み、動作確認結果は要確認想定持込物、誤検知、アラートの見え方を記録
導線どこで誰を止めるか未整理患者、スタッフ、業者の入口と確認ポイントを決める
判断責任MR管理者へ負荷が集中する可能性検出時の一次対応者、再確認者、記録者を分ける
デモ後返却予定と導入検討方針が要確認期間、評価基準、導入判断者を明確化

📚 用語解説 — 磁性体検知器: MRI室に持ち込むと危険な強磁性体を、入室前に検出するための安全機器。
📚 用語解説 — MR管理者: 装置運用、安全ルール、検査室導線、スタッフ教育の実務を担う現場キーパーソン。
📚 用語解説 — デモ評価: カタログ性能ではなく、現場の実導線でアラートが意味を持つかを確認する期間。

🛠️ 運用方法: (1) 加藤さんへ動作確認結果を確認する。 (2) 検出時の患者・スタッフ導線を図にする。 (3) 検出後の停止判断者と記録方法を決める。 (4) デモ期間、返却予定、導入検討の判断軸をメールまたは次回訪問で確定する。

⚠️ アンチパターン: デモ機が反応したかだけで評価を終えると、実際の検査導線で誰も止められない運用になる。加藤さんの新体制で依頼事項を増やしすぎると、安全機器の評価がMR管理者の追加負荷として受け止められる。

04研究発信フォロー — ESGAR / ISMRM / 症例数

発表期限、disclosure、症例収集、解析済みデータを混ぜずに別タスクとして追跡する。

Conference follow-up three checkpoints
ESGAR、ISMRM、Dual-VENC症例進捗は、別々の完了条件を持つタスクとして扱う。

3月31日時点では、ESGAR ePoster SE-002 のオンライン登録見込み、ISMRM 2026 Cape Town #00459 の disclosure 登録進捗、Dual-VENC症例収集の最新値が確認対象だった。元報告ではいずれも最終状態が要確認として残っている。

タスク訪問時点の状態完了条件
ESGAR ePoster SE-0024/3期限、兵藤先生へ登録見込みを確認オンライン登録完了、提出物不足なしを確認
ISMRM #00459 disclosureDaniel / Michaela Schmidt / 真鍋分の進捗確認共同著者全員のdisclosure登録完了
Dual-VENC症例数3/28時点21例、3/31時点は要確認最新症例数、解析済み数、発表使用可否を分離して記録
論文化ストーリー2月訪問でDual-VENC単体の論文化可能性を議論発表用図表とJMRI等への論文化素材を別管理

📚 用語解説 — ePoster: 学会への電子ポスター登録。期限内に本文、図表、著者情報、COI等が揃って初めて完了。
📚 用語解説 — disclosure: 共同著者や関係者が利益相反等を登録する手続き。研究内容が完成していても、手続き未完了なら発表準備が止まる。
📚 用語解説 — Dual-VENC症例数: 収集済み、解析済み、発表使用可能は別指標であり、症例数だけでは発表可能性を判断できない。

🛠️ 運用方法: (1) ESGARは登録完了メールまたは画面情報で確認する。 (2) ISMRM disclosureは対象者別にチェックする。 (3) Dual-VENCは症例数、解析済み、図表化済み、使用許可を4列で管理する。 (4) 次回訪問前に未完了タスクを1枚のチェックリストへ圧縮する。

⚠️ アンチパターン: ESGAR登録、ISMRM disclosure、症例収集を「学会対応」と一括りにすると、完了条件が曖昧になる。特にdisclosureは医師側・HQ側・社内側で担当が分かれるため、誰の分が未完了かを明示しないと滞留する。

05次アクション — 更新期限と確認責任を前倒し管理する

最重要は正式ライセンス導入完了確認、学会登録確認、マグフィ運用方針、加藤さん新体制への配慮。

Nagoya University next actions kanban
訪問後アクションは、担当者、期限、完了条件を分けて管理する。

次アクションは、元報告の今後予定を起点に、正式ライセンス導入完了確認、学会登録、マグフィ運用方針、加藤さん新体制への連絡配慮へ再整理する。特に2027年2月24日のライセンス期限は、2026年12月から準備を始める前倒し管理対象にする。

優先度Action担当 / 相手完了条件
P0Prisma fit XA60 の正式ライセンス起動確認結果を確定Manabe / 加藤さん / 現地担当WIP起動、対象プロトコル表示、試用時条件との整合を記録
P0Danielへインストール完了を報告Manabe / Daniel Giese導入完了メールまたはTeams記録が残る
P1ESGAR ePoster SE-002 登録完了確認Manabe / 兵藤先生4/3期限のオンライン登録完了を確認
P1ISMRM #00459 disclosure 登録状況確認Manabe / Daniel / Michaela Schmidt対象者別に登録済みか確認
P1マグフィデモ評価の結果と方針確認Manabe / 加藤さん動作結果、返却予定、導入検討軸を記録
P22027年2月ライセンス期限の前倒し管理Manabe2026年12月準備開始としてタスク化

📚 用語解説 — 完了条件: 『確認する』ではなく、何が残れば完了と言えるかを示す基準。メール、画面、登録番号、起動ログ、訪問メモなどの証跡が該当する。
📚 用語解説 — 前倒し管理: WIPライセンス期限の3から4か月前に更新準備を始め、HQへのurgent requestを避ける運用。
📚 用語解説 — Dossier更新: Project Dossierは現在stubなので、最終確認後に関連報告リンクと現在状態だけを軽く追記する候補にする。

🛠️ 運用方法: (1) この表を訪問後チェックリストとして使う。 (2) P0はメールまたはTeamsで証跡を残す。 (3) P1は次回訪問前に状況更新する。 (4) P2はカレンダーまたはTaskへ登録し、2026年12月にライセンス更新準備を開始する。 (5) 完了後にFacility Report Layerの本MDへ追記する。

⚠️ アンチパターン: 報告書を作った時点でタスク完了にすると、最も重要な起動確認結果とDaniel報告が抜ける。Concur精算や学会登録など期限が異なるものを一つのメモに埋めると、誰がいつ何を完了したか追跡できなくなる。

結論

  1. 名古屋大学の3/31訪問は、CS 4D Flow 正式ライセンス化を中心に、MR安全運用、学会発信、連絡体制を同時に扱った facility-integrated visit である。
  2. 最重要の残タスクは、Prisma fit XA60 上でのWIP起動確認結果、Danielへの導入完了報告、ESGAR/ISMRM手続き完了、マグフィ運用方針の確認である。
  3. Project Dossier はまだ stub のため、本ページと最終報告MDを根拠に、確認済み事項だけを後で軽量に反映するのが安全である。
  4. 2027-02-24のライセンス期限に対し、2026-12から更新準備を始めることで、urgent requestを繰り返さない運用へ移す。