4. 协同治理总体架构
多标准医疗术语协同治理不是把几套术语表合并成一张大表，而是要在多个标准体系、多个业务系统和多个组织角色之间建立一套可持续运转的治理结构。总体架构要回答五个问题：谁来做决策、治理什么内容、按什么流程推进、靠什么技术承载、用什么组织机制保障长期运行。这五个维度相互约束，缺一不可。
治理主体：从单一维护者到分层责任网络
治理主体是架构的起点。医疗术语治理涉及的主体通常包括：标准归口部门（如信息科或病案统计室，负责标准选型与版本策略）、临床业务代表（各专科医生、护士、药师，负责语义确认与临床合理性判断）、数据治理专员（负责映射维护、质量核查、变更执行）、信息化团队（负责术语服务接口、发布与回滚）、外部标准组织或区域平台（如卫健委标准库、省级健康信息平台）。
关键设计原则是决策权与执行权分离：临床代表拥有语义终审权，数据治理专员拥有映射执行权，信息团队拥有发布操作权。任何术语变更都必须经过“提出—评审—批准—发布—回溯”的闭环，而不是由单一岗位直接修改生产库。建议设立三层责任结构：术语治理委员会（跨部门，季度例会，审批重大变更）、术语工作组（日常评审，双周例会）、系统运维岗（执行发布与监控）。
治理对象：术语资产的分层管理
治理对象不只是“术语”本身，而是一组有层次关系的资产。可以按四层划分：
- 标准层：ICD-10、ICD-9-CM-3、SNOMED CT、LOINC、RxNorm、ICD-11 等外部标准及其版本。
- 映射层：本地术语与标准术语之间的映射关系，包括一对一、一对多、多对一、无匹配等类型，以及映射置信度与审核状态。
- 本地层：医院或区域自有的诊断名称、手术名称、检验项目、药品名称、科室字典等。
- 实例层：实际病历、医嘱、检验报告中的术语使用记录，用于反向发现映射缺口和歧义。
每一层都需要独立的版本标识、生效时间、责任人和变更记录。治理对象的核心不是“有多少条术语”，而是映射关系的质量与可追溯性。例如，一条本地诊断“2型糖尿病伴肾病”可能同时映射到 ICD-10 的 E11.2 和 N08.3，需要明确主映射与附加映射，并记录临床语义依据。
治理流程：从需求触发到版本发布
治理流程应覆盖术语生命周期的完整链路。一个可落地的流程包含六个环节：需求触发（临床新业务、标准升级、数据质量告警）、影响分析（评估受影响系统、报表、接口和已归档数据）、映射设计与评审（由数据治理专员提出方案，临床代表确认语义）、测试验证（在测试环境验证编码、检索、统计和接口返回）、发布与通知（版本号、生效日期、变更说明、回滚方案）、运行监控与回溯（监控映射命中率、未匹配率、异常编码）。
流程设计中最容易被忽视的是影响分析和回滚方案。术语变更往往影响历史数据统计口径，因此必须明确：本次变更是否追溯历史数据、是否影响已上报的医保或绩效数据、回滚时如何恢复到上一版本。建议每次发布都附带一份变更影响清单，至少包含变更条目、影响系统、影响报表、生效时间、回滚步骤。
技术栈：术语服务的承载方式
技术栈的核心是术语服务，它把标准库、映射表和本地字典封装成可调用的接口，供 HIS、EMR、LIS、医保结算等系统使用。典型技术栈包括：术语存储（关系库或图数据库）、映射管理平台（支持批量导入、冲突检测、审核工作流）、版本与发布仓库（每次发布生成不可变版本号）、质量监控看板（未匹配率、映射命中率、异常编码趋势）、审计日志（记录谁在何时修改了哪条映射）。
接口设计上，建议提供三类能力：编码查询（根据本地名称返回标准编码及置信度）、反向查询（根据标准编码返回本地可用名称）、批量校验（对一批编码进行有效性检查）。例如，调用 GET /terminology/map?local=2型糖尿病伴肾病&standard=ICD-10，返回主映射 E11.2、附加映射 N08.3、置信度 0.92、审核状态“已确认”。这类接口让业务系统在录入时即可获得标准化建议，而不是事后清洗。
组织保障：让架构持续运转
组织保障决定架构能否长期运行。至少需要四项机制：制度规范（术语管理办法、变更审批流程、版本发布规范）、岗位职责（明确各角色的输入输出与时限）、培训考核（临床人员理解术语标准化的意义与操作方式）、绩效挂钩（将映射质量、未匹配率纳入数据治理考核）。
一个常见的失败模式是：技术平台建好了，但临床代表不参与评审，导致映射结果不符合临床语义；或者发布流程没有回滚方案，一次错误变更影响全院统计。因此，组织保障不是附属项，而是与治理主体、对象、流程、技术栈并列的第五根支柱。
总体来看，协同治理总体架构的本质是：用分层责任网络管理术语资产，用闭环流程控制变更风险，用术语服务承载标准化能力，用组织机制保障长期运行。五个维度中任何一层缺失，都会导致治理退化为一次性数据清洗，无法支撑多标准医疗术语的持续协同。