2026年3月31日の名古屋大学病院訪問を、単発の出張メモではなく、施設単位の運用レイヤーへ統合した explainer。CS 4D Flow 正式ライセンス、マグフィ安全運用、ESGAR/ISMRM 発表フォロー、加藤さん新体制を一枚で追跡できるように整理する。
同じ日に複数のProjectと運用テーマを扱ったため、Project成果物ではなく施設横断の訪問報告として整理する。
この訪問は、CS 4D Flow 正式ライセンス導入、マグフィデモ機動作確認、ESGAR/ISMRMフォロー、加藤さん新体制への配慮が同日に重なった。単一Projectの成果物ではなく、施設横断の運用記録として読むのが正しい。
| レーン | 訪問時の事実 | 施設統合で見る理由 |
|---|---|---|
| CS 4D Flow | 正式ライセンスが発行済みで、Prisma fit XA60 への導入確認を実施 | 研究継続性、契約、装置更新、HQ連携が同時に関係する |
| マグフィ | 3/30設置、3/31動作確認 | 研究ではなくMR安全導線とMR管理者負荷のテーマ |
| ESGAR/ISMRM | ePosterとdisclosureの登録進捗を確認 | 研究成果発信の期限管理と共同著者手続きに関係する |
| 連絡体制 | 加藤さんが4月から副主任技師兼MR管理者 | 今後の訪問調整と依頼粒度を変える必要がある |
📚 用語解説 — Facility Report Layer: `0000_報告書/` に置く、施設単位の訪問記録。Projectごとの `5_Deliverable/` は成果物やマイルストーン用であり、同日に複数Projectを扱う訪問報告とは役割が違う。
📚 用語解説 — source of truth: 本件では `260511_名古屋大学_訪問報告書_2026-03-31.md` が正式報告であり、explainerは閲覧用の再構成レイヤー。
📚 用語解説 — local_only: 契約番号、ライセンスファイル名、関係者名を含むため、外部公開やCloudflare deployを前提にしない内部資料。
🛠️ 運用方法: (1) 元報告を事実根拠として読む。 (2) Project Bridge の名古屋 active projects を確認する。 (3) Facility Report Layer に最終報告を置き、Project Dossierには関連報告としてリンクする。 (4) 未確認事項は消さず、次アクション表に残す。
🔗 関連: 訪問単発 explainer: https://explainer-visit-nagoya-university-2026-03-31.pages.dev/ 。正式報告: `01_Projects/7_名古屋大学/0000_報告書/260511_名古屋大学_訪問報告書_2026-03-31.md` 。過去報告: `01_Projects/7_名古屋大学/0000_報告書/260225_訪問報告書.md` 。関連Dossier候補: `01_Projects/7_名古屋大学/2603_CS4Dflow_Project/`。
⚠️ アンチパターン: CS 4D Flow の話だけに圧縮すると、マグフィ安全運用と加藤さん新体制の負荷が消える。逆にマグフィを一般安全メモだけで扱うと、同日のライセンス導入と学会発信フォローから切り離され、訪問後の優先順位が崩れる。
3/28署名完了と正式ライセンス発行を受け、Prisma fit XA60 上で研究継続性を確保する段階。
契約書の兵藤先生・長縄先生署名は3月28日に大草さん経由で完了し、Daniel Giese より正式ライセンスが発行済みだった。3月31日は Prisma fit XA60 にライセンスファイルをインストールし、従来のTrial Licenseブリッジ運用から正式ライセンス運用へ切り替える現地確認だった。
| 項目 | Before | After / 次状態 |
|---|---|---|
| 契約 | 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 については、開示範囲を加藤さんと合意してから説明する。
🔗 関連: 訪問単発 explainer: https://explainer-visit-nagoya-university-2026-03-31.pages.dev/ 。正式報告 §3: `01_Projects/7_名古屋大学/0000_報告書/260511_名古屋大学_訪問報告書_2026-03-31.md` 。前段報告: `01_Projects/7_名古屋大学/0000_報告書/260225_訪問報告書.md` 。Dossier候補: `01_Projects/7_名古屋大学/2501_CS4Dflow_Project/` と `01_Projects/7_名古屋大学/2603_CS4Dflow_Project/`。
⚠️ アンチパターン: CS 4D Flow Trial と正式ライセンスを同列契約管理にすると、Trial bridge の暫定性と2027-02-24までの正式期限管理を見誤る。正式ライセンス発行をもって完了扱いにすると、対象装置でのWIP起動確認、試用時プロトコルとの整合、Danielへの完了報告も抜ける。
デモ機の動作確認は機器性能だけでなく、誰が止めるか、どこで検出するか、負荷が誰に寄るかを確認する。
マグフィデモ機は3月30日に加藤さん手配で設置され、3月31日に動作確認した。元報告では結果と今後の運用方針が要確認として残っているため、検出できたかだけでなく、現場導線と停止判断の設計まで確認する必要がある。
| 評価軸 | Before / 未整理 | After / 確認したい状態 |
|---|---|---|
| 検出性能 | デモ機設置済み、動作確認結果は要確認 | 想定持込物、誤検知、アラートの見え方を記録 |
| 導線 | どこで誰を止めるか未整理 | 患者、スタッフ、業者の入口と確認ポイントを決める |
| 判断責任 | MR管理者へ負荷が集中する可能性 | 検出時の一次対応者、再確認者、記録者を分ける |
| デモ後 | 返却予定と導入検討方針が要確認 | 期間、評価基準、導入判断者を明確化 |
📚 用語解説 — 磁性体検知器: MRI室に持ち込むと危険な強磁性体を、入室前に検出するための安全機器。
📚 用語解説 — MR管理者: 装置運用、安全ルール、検査室導線、スタッフ教育の実務を担う現場キーパーソン。
📚 用語解説 — デモ評価: カタログ性能ではなく、現場の実導線でアラートが意味を持つかを確認する期間。
🛠️ 運用方法: (1) 加藤さんへ動作確認結果を確認する。 (2) 検出時の患者・スタッフ導線を図にする。 (3) 検出後の停止判断者と記録方法を決める。 (4) デモ期間、返却予定、導入検討の判断軸をメールまたは次回訪問で確定する。
🔗 関連: 訪問単発 explainer: https://explainer-visit-nagoya-university-2026-03-31.pages.dev/ 。正式報告 §4: `01_Projects/7_名古屋大学/0000_報告書/260511_名古屋大学_訪問報告書_2026-03-31.md` 。2025活動報告: `01_Projects/7_名古屋大学/0000_報告書/(RC)活動報告書 名古屋大学病院(2025611).txt` 。施設KB: `01_Projects/7_名古屋大学/名古屋大学_ナレッジベース_完全版.md`。
⚠️ アンチパターン: マグフィを一般安全メモだけで扱うと、検出性能の話に圧縮され、導線、停止判断、記録、MR管理者負荷が消える。デモ機が反応したかだけで評価を終えると、実際の検査導線で誰も止められない運用になる。
発表期限、disclosure、症例収集、解析済みデータを混ぜずに別タスクとして追跡する。
3月31日時点では、ESGAR ePoster SE-002 のオンライン登録見込み、ISMRM 2026 Cape Town #00459 の disclosure 登録進捗、Dual-VENC症例収集の最新値が確認対象だった。元報告ではいずれも最終状態が要確認として残っている。
| タスク | 訪問時点の状態 | 完了条件 |
|---|---|---|
| ESGAR ePoster SE-002 | 4/3期限、兵藤先生へ登録見込みを確認 | オンライン登録完了、提出物不足なしを確認 |
| ISMRM #00459 disclosure | Daniel / 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枚のチェックリストへ圧縮する。
🔗 関連: 訪問単発 explainer: https://explainer-visit-nagoya-university-2026-03-31.pages.dev/ 。正式報告 §5: `01_Projects/7_名古屋大学/0000_報告書/260511_名古屋大学_訪問報告書_2026-03-31.md` 。前段報告: `01_Projects/7_名古屋大学/0000_報告書/260225_訪問報告書.md` 。関連Dossier候補: `01_Projects/7_名古屋大学/2502_Other_Research/`。
⚠️ アンチパターン: ESGAR登録、ISMRM disclosure、症例収集を「学会対応」と一括りにすると、完了条件と期限が曖昧になる。特にdisclosureは医師側・HQ側・社内側で担当が分かれるため、Daniel / Michaela Schmidt / 真鍋の誰の分が未完了かを明示しないと滞留する。
最重要は正式ライセンス導入完了確認、学会登録確認、マグフィ運用方針、加藤さん新体制への配慮。
次アクションは、元報告の今後予定を起点に、正式ライセンス導入完了確認、学会登録、マグフィ運用方針、加藤さん新体制への連絡配慮へ再整理する。特に2027年2月24日のライセンス期限は、2026年12月から準備を始める前倒し管理対象にする。
| 優先度 | Action | 担当 / 相手 | 完了条件 |
|---|---|---|---|
| P0 | Prisma fit XA60 の正式ライセンス起動確認結果を確定 | Manabe / 加藤さん / 現地担当 | WIP起動、対象プロトコル表示、試用時条件との整合を記録 |
| P0 | Danielへインストール完了を報告 | Manabe / Daniel Giese | 導入完了メールまたはTeams記録が残る |
| P1 | ESGAR ePoster SE-002 登録完了確認 | Manabe / 兵藤先生 | 4/3期限のオンライン登録完了を確認 |
| P1 | ISMRM #00459 disclosure 登録状況確認 | Manabe / Daniel / Michaela Schmidt | 対象者別に登録済みか確認 |
| P1 | マグフィデモ評価の結果と方針確認 | Manabe / 加藤さん | 動作結果、返却予定、導入検討軸を記録 |
| P2 | 2027年2月ライセンス期限の前倒し管理 | Manabe | 2026年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へ追記する。
🔗 関連: 訪問単発 explainer: https://explainer-visit-nagoya-university-2026-03-31.pages.dev/ 。正式報告 §8/§11/§12: `01_Projects/7_名古屋大学/0000_報告書/260511_名古屋大学_訪問報告書_2026-03-31.md` 。過去報告: `01_Projects/7_名古屋大学/0000_報告書/260225_訪問報告書.md` 。Project Dossier候補: `01_Projects/7_名古屋大学/2501_CS4Dflow_Project/`, `2502_Other_Research/`, `2603_CS4Dflow_Project/`。
⚠️ アンチパターン: 報告書を作った時点でタスク完了にすると、最も重要な起動確認結果、Daniel報告、2027-02-24ライセンス更新トリガーが抜ける。期限の違うマグフィ、ESGAR、ISMRM、契約原本返送を一つのメモに埋めると、誰がいつ何を完了したか追跡できなくなる。