企业官网建设流程全解析

简介：这份PPT资料聚焦深圳医诺在放射治疗信息化与远程医疗领域的实践，面向放疗科管理者、信息化建设人员及医疗IT从业者，帮助理解RTIS（放疗网络信息管理系统）如何统一管理文本、影像、计划与治疗数据。资源包内含1个PPT文件，约5.06MB，以幻灯片形式系统梳理科室概况、治疗机与QC设备、放疗网络与流程、信息化实施方案及网络架构设计。内容涵盖一体化需求、国产化趋势、基于SQL Server与DICOM协议的三层架构，以及数据流拓扑与技术实现，并对比使用前后在信息录入、资料完整性、流程记录与随访等环节的改进效果。已有83人学习，适合需要了解放疗信息化落地路径、质控流程优化与远程医疗管理思路的读者参考借鉴。

1. 深圳医诺放射治疗信息化应用和远程医疗：从一份 PPT 标题拆出的落地路线

放疗科的信息化改造，最怕的不是没预算，而是钱花完了、系统上线了，物理师和医生还是靠 U 盘拷计划、靠微信传定位 CT。深圳医诺这套放射治疗信息化应用和远程医疗方案，本质上要解决的就是这条链路上的数据孤岛问题：把 TPS、OIS、加速器、CT 模拟定位机、剂量验证设备串成一条可追溯的数据流，再通过远程医疗把总院和分院、上级医院和基层医院之间的会诊与计划审核打通。它适合三类人看：正在做放疗科信息系统选型的医院信息科工程师、需要对接多院区放疗数据的物理师、以及想搞清楚远程放疗会诊到底怎么落地的集成商。这份 PPT 标题背后，其实是一套从设备接入、数据建模到远程协同的完整工程问题，不是买套软件就能收工的。

2. 放疗信息化到底要接哪些设备：DICOM 是绕不开的第一道坎

2.1 放疗科的数据源比影像科复杂在哪

普通影像科的信息化，核心就是 PACS 加 DICOM 标准，CT、MR、DR 出来的都是标准 DICOM 图像，归档、调阅、后处理相对统一。放疗科不一样，它的数据源至少分四层：第一层是影像设备，CT 模拟定位机、MR 模拟定位机，输出的是带定位信息的 DICOM CT/MR；第二层是 TPS 治疗计划系统，输出的是 RT Plan、RT Dose、RT Structure Set 这类放疗专用 DICOM 对象；第三层是 OIS 肿瘤信息系统，管患者流程、预约、疗程记录；第四层是加速器和剂量验证设备，输出的是 RT Record、机器参数、验证结果。这四层里，只有第一层是标准影像 DICOM，后面三层全是放疗扩展对象，很多老设备的 DICOM 实现还带私有 tag。

我见过最典型的翻车场景：医院上了新的 OIS，结果发现 TPS 导出的 RT Plan 里患者 ID 和 HIS 里的住院号对不上，物理师只能手工在 OIS 里再录一遍，录错一个数字，计划就绑到别人身上了。这不是软件 bug，是数据模型没对齐。深圳医诺这类方案要做的第一件事，就是建一个统一的患者主索引，把 HIS 的住院号、OIS 的患者 ID、TPS 的 PatientID 做映射，映射表要落库、要可审计。

2.2 用 DCMTK 验证设备 DICOM 连通性的最小命令

在正式对接前，我一般会先用 DCMTK 的echoscu和findscu把每台设备的 DICOM 服务摸一遍。下面这几条命令是现场必跑的：

# 1. 验证 DICOM 连通性，确认 AE Title 和端口对得上 echoscu -v -aet RADIOMICS_SCU -aec TPS_AE 192.168.10.21 104 # 2. 查询 TPS 上某患者的 RT Plan，确认能返回结果 findscu -v -aet RADIOMICS_SCU -aec TPS_AE 192.168.10.21 104 \ -P -k "PatientID=202405001" \ -k "Modality=RTPLAN" \ -k "QueryRetrieveLevel=STUDY" # 3. 把 RT Plan 拉到本地做解析验证 movescu -v -aet RADIOMICS_SCU -aec TPS_AE 192.168.10.21 104 \ -P -k "PatientID=202405001" \ -k "Modality=RTPLAN" \ -k "QueryRetrieveLevel=STUDY" \ -od /tmp/rtplan_dump

echoscu的-aet是本端 AE Title，-aec是对端 AE Title，这两个写反了是最常见的连不上原因。findscu的-P表示用患者根查询，-k是查询键，QueryRetrieveLevel设成 STUDY 表示按检查级别查。movescu的-od指定输出目录，拉下来的 RT Plan 可以用dcmdump看 tag 结构。如果echoscu通了但findscu返回空，大概率是对方 DICOM 服务只开了验证没开查询，或者查询键的 VR 类型不对。

2.3 设备接入的三种模式与选型建议

现场设备接入无非三种模式：主动拉取、被动接收、代理转发。主动拉取适合 TPS 和 OIS 这类有标准 DICOM Query/Retrieve 服务的系统，定时或按需去拉；被动接收适合 CT 模拟定位机，它做完扫描主动把图像推过来；代理转发适合那些既不能拉也不能推的老加速器，只能在网络层做镜像或者让工程师在设备端配一个转发规则。

选型上我的建议是：能拉就不要推，能推就不要代理。代理转发看着省事，实际上丢包、时序错乱、日志缺失的问题最多，出了问题连是哪台设备发的都查不到。深圳医诺方案里如果涉及远程医疗，分院设备的数据往总院传，优先走 DICOM 主动上报加断点续传，而不是在分院本地存一份再人工同步。

3. 远程放疗会诊怎么落地：从网络层到业务层的四步走

3.1 远程会诊不是开个视频会议就完了

很多人一听远程医疗，第一反应是视频会议系统。放疗远程会诊跟普通远程会诊最大的区别是：它要传的不只是视频和语音，还有 RT Structure Set、RT Dose、RT Plan 这些带空间坐标和剂量分布的数据。总院专家在视频里说“这个靶区再往外扩 3 毫米”，分院物理师得能在自己的 TPS 里看到总院专家标注的靶区轮廓，而不是靠截图比划。

所以远程放疗会诊的落地，网络层只是基础，业务层才是核心。业务层要解决三件事：数据同步、权限控制、操作留痕。数据同步保证分院和总院看到的是同一份计划数据；权限控制保证分院医生不能改总院专家审核过的计划；操作留痕保证每一次远程修改都有记录，出了医疗纠纷能回溯。

3.2 用 Orthanc 搭一个放疗 DICOM 中转节点的最小配置

Orthanc 是一个轻量级 DICOM 服务器，适合做远程会诊的数据中转。下面是一个最小配置，把分院数据同步到总院 Orthanc，并限制只允许特定 AE Title 写入：

{ "Name": "RadiotherapyRelay", "StorageDirectory": "/var/orthanc/rt_data", "IndexDirectory": "/var/orthanc/rt_index", "DicomAet": "RT_RELAY", "DicomPort": 4242, "DicomCheckCalledAet": true, "DicomModalities": { "BRANCH_TPS": ["BRANCH_TPS", "192.168.20.31", 104], "MAIN_OIS": ["MAIN_OIS", "192.168.10.11", 104] }, "RemoteAccessAllowed": true, "AuthenticationEnabled": true, "RegisteredUsers": { "rt_admin": "change_this_password" }, "OrthancPeers": { "MAIN_RELAY": ["http://10.0.0.5:8042", "peer_password"] } }

DicomAet是本节点 AE Title，DicomPort是监听端口，DicomCheckCalledAet设为 true 表示只接受配置里登记过的 AE Title 连接，这是防止未授权设备写入的第一道门。DicomModalities里登记分院 TPS 和总院 OIS 的 AE Title、IP、端口。OrthancPeers用于节点间同步，总院和分院各跑一个 Orthanc，通过 peer 机制做数据推送。

配置好之后，用 Orthanc 的 REST API 做一次手动同步测试：

# 查询分院 Orthanc 上某患者的检查 curl -u rt_admin:change_this_password \ "http://192.168.20.41:8042/patients?filter=PatientID=202405001" # 把指定检查推送到总院 peer curl -u rt_admin:change_this_password \ -X POST "http://192.168.20.41:8042/peers/MAIN_RELAY/store" \ -d '{"Resources": ["study_id_here"], "Synchronous": true}'

filter参数按 PatientID 过滤，Resources填要推送的 study ID，Synchronous设为 true 表示同步等待结果，方便排查。如果推送失败，先看总院 Orthanc 的日志，再看网络层 4242 端口是否放通，最后确认两边 AE Title 是否在各自DicomModalities里登记。

3.3 远程会诊的业务流程与权限设计

数据通了之后，业务流程要设计清楚。我一般建议按这个顺序走：分院物理师提交会诊申请，附上 RT Structure Set 和 RT Plan；总院专家在总院 TPS 里打开同步过来的数据，做靶区勾画或计划审核；审核意见以 RT Structure Set 的 ROI 注释形式回传，或者以结构化报告形式落库；分院物理师根据意见修改计划，修改后的计划再走一次同步，总院确认后锁定。

权限设计上，总院专家对分院数据只有读和注释权限，没有直接修改分院 TPS 计划的权限。分院物理师对总院回传的审核意见只有读权限，不能改。所有跨院操作都要记操作日志，日志字段至少包括：操作时间、操作人、操作类型、涉及患者 ID、涉及 DICOM SOP Instance UID、源 IP。这套日志在医疗纠纷场景下就是后悔药。

4. 放疗信息化避坑：五条血泪经验

4.1 患者 ID 映射错位导致计划绑错人

现象：OIS 里显示患者 A 的计划，打开一看是患者 B 的靶区。原因：HIS 住院号、OIS 患者 ID、TPS PatientID 三者没有做唯一映射，或者映射表在数据迁移时被覆盖。解决：建独立的主索引表，三个 ID 字段加唯一约束，每次数据写入前先查映射，查不到就拒绝写入并告警。迁移时先做全量比对，比对不通过不切换。

4.2 DICOM 传输中断后文件不完整

现象：分院传过来的 RT Dose 文件在总院 TPS 里打不开，提示文件损坏。原因：网络抖动导致 DICOM 传输中断，Orthanc 或接收端只写了部分文件，没有做完整性校验。解决：接收端开启 DICOM 传输校验，Orthanc 可以配StorageCompression和CheckReception，接收完成后用dcmdump或gdcmconv做一次解析验证，解析失败的文件移到隔离目录并触发重传。

4.3 远程会诊延迟高导致操作超时

现象：总院专家在 TPS 里加载分院数据，转圈几分钟后超时。原因：分院上传的 CT 序列太大，或者总院 Orthanc 的存储目录在慢速磁盘上，查询索引没建好。解决：分院上传前做一次压缩，CT 序列用 JPEG Lossless 压缩；总院 Orthanc 的IndexDirectory放 SSD，StorageDirectory可以放机械盘；查询时用filter缩小范围，不要一次拉整个 study。

4.4 AE Title 冲突导致数据串台

现象：两台设备配了同一个 AE Title，数据推到了错误的节点。原因：现场工程师图省事，把新设备 AE Title 直接抄了旧设备的。解决：AE Title 命名规范强制要求带院区缩写和设备类型，比如SZ_CT01、GZ_TPS01，上线前用echoscu全网扫一遍，发现重复立即改。

4.5 日志缺失导致问题无法回溯

现象：远程会诊出了纠纷，查不到谁在什么时候改了哪个计划。原因：系统只记了业务日志，没记 DICOM 层操作日志，或者日志只存本地没集中收集。解决：Orthanc 开启Verbose日志，业务系统记录操作审计表，两边日志通过患者 ID 和 SOP Instance UID 关联，集中存到 ELK 或类似平台，保留至少三年。

5. 把远程会诊从能用做到好用：一个验证清单和我的习惯

远程放疗会诊系统上线后，怎么判断它是真能用还是只是演示能跑？我一般会跑一个验证清单，分四组：连通性、数据完整性、业务闭环、异常恢复。连通性组测每台设备的echoscu和findscu；数据完整性组随机抽 10 个患者，比对分院和总院的 RT Structure Set、RT Dose、RT Plan 的 SOP Instance UID 是否一致；业务闭环组模拟一次完整会诊流程，从申请到审核到回传，记录每一步耗时；异常恢复组人为断网、断电、杀进程，看系统能不能自动重传和恢复。

下面这个表格是我常用的验证项和通过标准：

还有一个我自己的习惯：每次远程会诊前，先让分院物理师把当天要会诊的患者数据做一次预同步，不要等到会诊开始了才传。预同步的时间窗口放在会诊前两小时，传完后跑一次完整性校验，校验不通过的有时间重传。这个习惯帮我挡过好几次会诊中途卡住的事故。

另外，远程会诊的音频视频通道和 DICOM 数据通道建议分开走，视频用独立的 WebRTC 或专线，DICOM 走 Orthanc 的 HTTP 或 DICOM 端口。混在一起的话，视频一卡，数据同步也跟着断，排查起来就是黑匣子。分开之后，视频卡了不影响数据，数据断了也不影响沟通，各自有各自的日志，定位问题快很多。

最后说一个我踩过的坑：早期做远程会诊，总想着把所有数据都同步到总院，结果总院存储爆了，查询也慢。后来改成按需同步，分院只同步会诊申请里指定的患者数据，会诊结束后数据保留 30 天自动清理，总院存储压力降了七成。放疗信息化和远程医疗这件事，数据不是越多越好，该传的传，该留的留，该删的删，边界清楚比功能多更重要。希望帮到你。

本文还有配套的精品资源，点击获取