偏执MRI处理管道：领域模型与临床医生闭环
MRI二诊工程循环摄入DICOM数据，以体素支持或元数据降级模式生成初稿分析，经过安全检查和强制临床医生审核后方可最终确定。TypeScript协调器管理病例状态，Python工作进程处理异步计算。将协调与计算分离，避免内存溢出和超时，通过事件溯源+出箱模式记录日志。
超越Jupyter脚本的基础设施
在实际诊所，DICOM档案常包含无扩展名文件、自定义私有标签，以及导致库段错误崩溃的JPEG 2000无损格式。摄入工作进程确定性解包数据，按PS3.5 §9.1验证DICOM UID，并创建ImagingStudyRef。对于不完整扫描，它切换到元数据降级模式：从元数据提取临床问题，或默认“常规二诊审核请求”。
摄入和交付工作进程在DI容器中注册，并通过标志激活。这是CDS（临床决策支持），而非SaMD：DomainInvariantViolationError在无临床医生审核时阻塞finalize()，符合FDA CDS指南第520(o)(1)(E)节。
关键管道阶段：
- Python摄入：从DICOM元数据创建病例。
- TypeScript协调器：初始化
MriSecondOpinionCase。 - Python处理器：两种模式生成初稿。
- 安全策略：切换到
AwaitingReview。 - 人工审核：医师最终确定。
- 交付：结构化报告。
TypeScript中的严格不变量
GenerateMriSecondOpinionUseCase应用IClinicalSafetyPolicy，针对低置信度、显著分歧或数据不足设置标志。参考ACR实践参数（Res. 11, 2020）。拥有Neuroradiologist或Attending Physician角色的医师更新初稿；聚合根单独跟踪humanReview.modifications，与AI初稿区分。
状态机：9种状态（INGESTING → QC_REJECTED, SUBMITTED → AWAITING_REVIEW → REVIEWED → FINALIZED → DELIVERY_PENDING → DELIVERED / DELIVERY_FAILED）。4种由领域聚合根管理，5种由摄入/交付循环管理。
协调与计算分离
TypeScript API立即返回HTTP 200，而异步Python处理器处理GPU任务。契约（端口、DI令牌、安全策略）允许无重建即换多模态引擎适配器。存储：本地SQLite，生产PostgreSQL。
报告通过ImagingStudyRef映射到HL7 FHIR R4 DiagnosticReport，支持导出DICOM SR（SOP Class 1.2.840.10008.5.1.4.1.1.88.33）。RadiologyReportSummary使用RadLex（RSNA）和SNOMED CT。捕获编辑应对数据集偏移/模型漂移，用于未来再训练。
指标与可观测性
Prometheus指标：摄入/处理/交付的计数器/直方图，仪表如mri_second_opinion_cases_awaiting_review（按紧急度）和mri_second_opinion_review_wait_started_at_unix。针对危重病例（如卒中）在AwaitingReview超时的警报。
开源仓库：测试与工作台
独立仓库含Dockerfile、docker-compose、SECURITY.md。176/177测试通过（状态机、PostgreSQL、认证）。定位为临床医生闭环工作流，仅限研究使用，无监管批准。
发布特性：
- 完整病例生命周期，支持重试和审计。
- 分离TypeScript（协调、验证、审核UI）和Python（分发、降级）。
- 无审核即阻塞交付。
- 指标与标准导出。
关键要点
- 管道在代码层面强制临床医生闭环，无审核即阻塞最终确定。
- 元数据降级避免损坏DICOM崩溃。
- 计算与协调分离简化AI适配器更换。
- FHIR/DICOM SR + RadLex/SNOMED确保互操作性。
- 指标针对审核时长，支持临床风险管理。
— Editorial Team
暂无评论。