简介这份《省级医学重点专科评估评分标准》doc文档面向医院专科管理者、医务科与质控人员以及参与等级评审、重点专科申报的科室负责人用于对照自查专科建设中的各项指标。评分体系覆盖基础条件、支撑条件、科室管理、医疗技术队伍、医疗服务能力及水平四大板块细化到专科规模床位数、每床净使用面积、近五年经费投入、学科带头人与专科骨干的学术地位、医师年龄学历职称结构3∶4∶3、护理队伍与人才培养、亚专科设置、技术特色先进性、独立诊治主要病种等条目并逐项标注标准分、检查方法与扣分规则如30张床得5分、每增10张加1分投入每少20万元扣1分。资源包共1个doc文件约337KB为纯文档表格型资料可直接打印作为迎评台账与模拟打分表使用帮助读者把抽象评审要求拆解为可量化、可追溯的准备清单。目前已有120人学习下载。1. 为什么「省级医学重点专科评估评分标准.doc」需要一个可执行的评分引擎每到评审周期医务处共享盘里那份「省级医学重点专科评估评分标准.doc」就会被反复下载。它是老的 Word 二进制格式里面通常是一张上百行的表格一级指标若干条二级指标几十条每条后面跟着分值、评分要点、扣分说明和佐证材料要求。真正消耗人力的不是读它而是几十个科室要把自己的台账一条条对上去——人工找佐证、人工算分、人工复核最后汇总出来的分数谁都说不清口径是否一致。这个标题要解决的正是这件事把评分标准从人看的文档变成机器能跑的规则。做法不复杂拆成两步——先把 .doc 里的评分表解析成结构化的指标树再为每类指标写一个确定的计分函数让同一份材料无论谁跑都得到同一个分数。适合医务管理、质控和医院信息科的工程师也适合那些每到评审就被材料压住的科室秘书。2. 把 .doc 评分标准拆成可计算的指标树2.1 .doc 与 .docx 的解析差异与工具选型省级主管部门下发的评分标准多数还是.doc后缀。这是个 OLE 复合文档不是 zip 包Python 生态里主流的python-docx直接打开会抛PackageNotFoundError。常见的处理路线有三条一是用 LibreOffice 无头模式转成.docx再解析二是用antiword/catdoc这类命令行工具抽纯文本三是用olefile手工读 Word 流——第三条基本是自找麻烦。我一般选第一条。原因是评分标准的价值几乎全在表格结构和单元格边界上纯文本抽取会把行列关系压平后面再想还原这一行的分值属于哪条指标就得靠猜。转成.docx之后表格是w:tbl结构行、列、合并关系都能拿到。提示转换前先确认文档没有密码保护也不要直接覆盖原件转换产物放到独立的build/目录原始.doc保留只读副本作为审计依据。2.2 三级指标结构从「一级指标」到「评分要点」的字段映射翻过几份不同省份的评分标准会发现表格列名五花八门但语义高度一致稳定落在这么几个字段上文档里的列名常见变体字段名类型说明一级指标 / 指标类别 / 项目level1文本如专科基础条件二级指标 / 指标名称 / 考核内容level2文本如人才梯队结构分值 / 标准分 / 满分max_score数值该条满分多为整数或 0.5 步进评分标准 / 评分要点 / 评分细则rule_text文本决定怎么打分含每降低 1%扣 0.2 分这类描述佐证材料 / 检查方法 / 资料要求evidence文本科室要准备什么备注 / 说明remark文本否决项、加分项常藏在这里映射的关键判断是rule_text决定计分函数max_score决定分数的天花板两者必须拆开存。很多团队图省事把满分 5 分每缺 1 项扣 1 分整句话丢进一个字段后面写评分逻辑时就只能对字符串做匹配脆弱得不堪一击。2.3 指标字典表的 SQL 建模结构化之后落到关系库里用一张自引用的指标表就够了CREATE TABLE indicator ( code VARCHAR(32) PRIMARY KEY, -- 指标编码如 3.2.1直接沿用文档编号 parent_code VARCHAR(32), -- 父级编码一级指标为 NULL name VARCHAR(200) NOT NULL, -- 指标名称 level TINYINT NOT NULL, -- 1 / 2 / 3 级 max_score DECIMAL(6,2) NOT NULL, -- 满分 score_type VARCHAR(16) NOT NULL, -- quant 定量 / qual 定性 / veto 否决 rule_json JSON, -- 计分规则参数见第 4 章 evidence VARCHAR(500), -- 佐证材料要求 version_id VARCHAR(32) NOT NULL -- 所属标准版本 );code直接沿用文档里的编号好处是科室填材料时可以照着纸质版对号入座出了争议能立刻定位到原文哪一行。rule_json用 JSON 存参数而不是存自然语言是为了让评分引擎只面对数字{kind:linear,points:[[60,0],[90,6],[100,10]]}比达到 90% 得 6 分好处理太多。version_id现在看着多余等第二年评分标准修订时就明白它的分量了。3. 从 Word 表格到结构化 JSON 的解析与清洗3.1 用 LibreOffice 把 .doc 批量转成 .docx转换命令不需要图形界面服务器上跑得通# 单文件转换输出到 build 目录保留原文件名 soffice --headless --convert-to docx \ --outdir ./build \ ./原始标准/省级医学重点专科评估评分标准.doc # 目录里有多份历史版本时批量转换注意加防重入锁避免多个实例抢 profile find ./原始标准 -name *.doc -print0 | \ xargs -0 -n1 -P1 soffice --headless \ -env:UserInstallationfile:///tmp/lo_profile \ --convert-to docx --outdir ./build第一条命令的三个参数里--headless表示无界面、--outdir指定输出目录、最后一个位置参数是源文件。批量那条多了一个-env:UserInstallation这是关键LibreOffice 默认用同一个用户配置目录并发启动会互相锁死、进程卡住不返回指定独立 profile 后-P1串行执行才稳定。转换完记得校验一次文件大小0 字节的输出说明源文件损坏或本身是老式 Word 6.0 格式需要另找工具。3.2 python-docx 抽取评分表的最小脚本拿到.docx后先把所有表格行拉成二维数组from docx import Document import re DOCX ./build/省级医学重点专科评估评分标准.docx def cell_text(cell): 单元格内可能有多个段落用换行拼回再去掉首尾空白 parts [p.text.strip() for p in cell.paragraphs if p.text.strip()] return \n.join(parts) def load_rows(path): doc Document(path) rows [] for table in doc.tables: for row in table.rows: cells [cell_text(c) for c in row.cells] # 合并单元格会让同一段文字在相邻列重复出现做一次相邻去重 dedup [c for i, c in enumerate(cells) if i 0 or c ! cells[i - 1]] if len(dedup) 4: # 少于 4 列基本是表头或说明行 continue rows.append(dedup) return rowscell.paragraphs而不是cell.text是因为评分细则里经常用软回车分行列举扣分情形cell.text会把这些分行拍平成一句话。相邻去重这一步不能省python-docx对横向合并的单元格会重复返回同一段文本不去重的话分值列会被复制成好几份后面按列取数就全错位了。len(dedup) 4是个经验阈值用来滤掉跨页重复的表头行和纯说明行实际文档里如果列数不同改成len(dedup) 3再试。3.3 合并单元格、换行符与全角数字的清洗规则解析出来的字符串不能直接入库得先过一遍清洗。常见的噪声有四类处理方式各不相同纵向合并导致的空值一级指标只在第一条二级指标那行出现后续行是空的。处理办法是维护一个当前层级变量遇到非空就更新遇到空就继承。全角数字与中文括号一、.、分这类字符会让正则匹配失败。统一做str.maketrans转换。不可见字符从 PDF 转 Word 再转发的文档里常混入\u200b、\xa0用正则[\u200b\u3000\xa0]一次性清掉。分值列混入单位5 分、5分含加分2分要在抽取数字时只取第一个数值同时把括号内容单独存进remark。清洗这一步别想着一次写完正确姿势是先跑一遍全量统计哪些行的分值字段抽不出数字把这些行打出来人工看二十条规律自然就出来了。指标总数通常不过一两百条人工确认的成本完全可控。4. 评分引擎定量、定性与否决项怎么算4.1 三类指标的判定与分值函数把score_type分三类是保证评分可复现的前提定量项quant科室能填出一个数字如高级职称占比 32%年出院人次 8000。计分函数拿到数字直接算。定性项qual只能由专家按档次判定如专科发展规划的科学性。引擎不自动给分改为输出打分区间和佐证材料清单由专家在界面上选档。否决项veto触发即整体不合格或该项归零常见于发生重大医疗事故数据造假。这类必须在规则里显式标出不能靠人记。区分的价值在于责任边界定量项由系统算专家只负责复核定性项系统只做归集。评审现场最容易吵起来的就是这条到底该算 4 分还是 5 分而绝大多数争议其实发生在定性项上把定量项先自动化掉争议面积能缩小一大半。4.2 连续型指标的线性插值与分段计分rule_json里最常见的一类是分段线性用折线点集表达import bisect def score_linear(value, points): points 形如 [(60, 0), (90, 6), (100, 10)]按 x 升序 在折线上做线性插值超出两端按端点截断 xs [p[0] for p in points] ys [p[1] for p in points] if value xs[0]: return float(ys[0]) if value xs[-1]: return float(ys[-1]) i bisect.bisect_right(xs, value) - 1 x0, x1 xs[i], xs[i 1] y0, y1 ys[i], ys[i 1] return round(y0 (y1 - y0) * (value - x0) / (x1 - x0), 2) # 高级职称占比 65% 对应多少分 print(score_linear(65, [(60, 0), (90, 6), (100, 10)])) # 1.0用折线点集而不是给每类指标写一个if/elif分支好处是评分标准修订时只改 JSON 不动代码。bisect_right找的是不大于value的最大断点下标-1之后得到的[x0, x1]一定把value夹在中间插值结果是确定的。两端的截断规则要注意下限截断到最低分而不是负分上限截断到该项满分否则会出现某科室分数被算成负数的荒唐结果。还有两类规则需要单独处理阶梯型每降低 1 个百分点扣 0.2 分扣完为止用min(max_score, base - step * n)表达扣完为止的关键是那个max下限保护计数型每缺 1 项扣 1 分本质是阶梯型的特例把系数改成 1 即可复用。4.3 跑一遍完整评分并输出明细单个科室的评分主循环长这样def score_department(dept_code, values, indicators): values: {indicator_code: 实测值} indicators: 指标字典列表 detail, total, veto_hit [], 0.0, [] for ind in indicators: if ind[score_type] veto: if values.get(ind[code]) Y: veto_hit.append(ind[code]) continue if ind[score_type] qual: # 定性项不自动给分留空由专家填写但仍计入满分基线 detail.append((ind[code], None, ind[max_score])) continue rule ind[rule_json] raw score_linear(values.get(ind[code], 0), rule[points]) # 双重保护既不能超过该项满分也不能为负 s max(0.0, min(raw, float(ind[max_score]))) detail.append((ind[code], s, ind[max_score])) total s return { dept: dept_code, auto_total: round(total, 2), veto: veto_hit, detail: detail, }这段代码有三个刻意的设计。veto项不进总分累加只记录命中情况因为否决的后果通常是不予认定而不是扣几分两套语义混在一起会让汇总逻辑变得不可读。qual项写入明细时分数为None报表里能一眼看出哪些分是系统给的、哪些是专家给的。max(0.0, min(...))的双重保护看着啰嗦但真跑生产数据时输入值出现空值、负数或者超出预期的极大值时这行是最后一道防线——宁可分数被截断也不能让一条脏数据污染整个汇总。5. 评分结果对不上时的排查路径5.1 解析错位合并单元格与跨页表格最常见的故障是某条指标的分值莫名其妙变成了 0.5而原文写的是 5。八成是纵向合并单元格把上下两行的列错开了一位分值列读到了备注列第一个字符。排查方法是把解析结果和原文并排打印# 抽出解析后前 30 行的编码、名称、满分人工对照原文档 python -c import json rows json.load(open(build/indicators.json, encodingutf-8)) for r in rows[:30]: print(f\{r[code]:8} {r[name][:20]:22} {r[max_score]}\) 判断依据很直接一级指标的满分应当等于其下所有二级指标满分之和。如果某一级指标下出现了 0.5、0.25 这类零碎值而原文全是整数基本可以锁定错位。修复手段是在清洗阶段引入level状态机而不是单纯依赖列下标取数。5.2 权重归一化与四舍五入误差第二个高频问题是总分对不上 100。原因有两层一是原文档本身存在 0.5 分的舍入所有二级指标加起来是 99.5 或 100.5这不是 bug 而是文档事实处理方式是允许 ±0.5 的容差并记录在案二是保留两位小数时分步累加与最后统一舍入的结果不同。# 分步累加每条四舍五入后再相加 total_step sum(round(x, 2) for x in scores) # 统一舍入全部加完再四舍五入 total_final round(sum(scores), 2) print(total_step, total_final) # 可能差 0.01两种口径没有绝对对错但必须全系统统一。我一般选统一舍入因为报表需要可复算任何人拿原始分数重算一遍都能得到同样结果。分步累加会让误差随指标数量放大指标上百条时差出零点几分很常见评审现场解释起来很被动。5.3 用差异比对表定位异常科室自动分和历史人工分放在两张表里一条 SQL 就能把差异大的科室捞出来SELECT a.dept_code, a.indicator_code, a.auto_score, m.manual_score, a.auto_score - m.manual_score AS diff FROM score_auto a JOIN score_manual m ON a.dept_code m.dept_code AND a.indicator_code m.indicator_code WHERE ABS(a.auto_score - m.manual_score) 0.01 ORDER BY ABS(a.auto_score - m.manual_score) DESC;ABS(...) 0.01这个阈值是为了滤掉浮点尾差。按差异绝对值降序排头几条基本能直接定位问题类型如果集中在同一个indicator_code上是这条指标的解析或规则写错了如果集中在同一个dept_code上多半是该科室填报数据的口径和标准不一致比如把占比填成了人数。后一种情况要把差异表直接发给科室确认而不是改规则迁就数据——规则一旦为某个科室松动整套评分就失去公信力。6. 把评分标准做成可版本化、可追溯的评估台账评分标准不是一次性的。省级主管部门通常两三年修订一次修订后分值、指标口径都会变。如果系统里只有一张indicator表新旧标准会互相污染去年的分数用今年的规则重算一遍就完全对不上。解决办法是给每次解析出来的指标结构算一个指纹作为版本号。import hashlib, json def structure_fingerprint(indicators): 只把影响分数的字段纳入指纹编码、满分、计分规则 payload [ {code: i[code], max_score: str(i[max_score]), rule: i[rule_json]} for i in sorted(indicators, keylambda x: x[code]) ] raw json.dumps(payload, ensure_asciiFalse, sort_keysTrue) return hashlib.sha256(raw.encode(utf-8)).hexdigest()[:16]指纹只覆盖code、max_score、rule_json三个字段是刻意的选择。指标名称改个措辞、佐证材料描述调整一句不影响任何一条分数不该触发版本变更而分值变了一分、扣分系数从 0.2 改成 0.3就必须生成新版本。sort_keysTrue保证字典序稳定否则同一份数据两次序列化结果不同指纹就失去意义。取前 16 位十六进制足够避免碰撞也让版本号在界面上显示得下。有了指纹之后每年的评估结果记录里带上version_id就能回答这个科室 2023 年的 87.5 分是按哪版标准算的这类追问。再进一步把两次解析结果的编码集合做差集就能自动生成一份修订说明def diff_versions(old, new): o {i[code]: i for i in old} n {i[code]: i for i in new} added [c for c in n if c not in o] removed [c for c in o if c not in n] changed [c for c in n if c in o and (str(n[c][max_score]) ! str(o[c][max_score]) or n[c][rule_json] ! o[c][rule_json])] return {新增: added, 删除: removed, 分值或规则变化: changed}这份差集会直接变成给科室的培训材料——哪些条目删了、哪些分值调了逐条列清楚比让人自己拿新旧两份 Word 对着翻高效得多。指标编码在这个场景下的价值也体现出来了只要编码规则稳定跨版本比对才有意义所以解析时不要自作主张重排编号文档里怎么写就怎么存。最后一个实操技巧把每年解析出来的indicators.json连同源.doc、LibreOffice 转换出的.docx、结构指纹一起归档文件名带上年份和指纹前 8 位例如2024_省级重点专科_3f9a2c71.json。评审出现争议时从争议指标编码一路倒查到当年原始文档的具体单元格链路是完整闭合的这比任何口头解释都管用。本文还有配套的精品资源点击获取 省级医学重点专科评估评分标准.doc解析与自动化评分引擎
简介这份《省级医学重点专科评估评分标准》doc文档面向医院专科管理者、医务科与质控人员以及参与等级评审、重点专科申报的科室负责人用于对照自查专科建设中的各项指标。评分体系覆盖基础条件、支撑条件、科室管理、医疗技术队伍、医疗服务能力及水平四大板块细化到专科规模床位数、每床净使用面积、近五年经费投入、学科带头人与专科骨干的学术地位、医师年龄学历职称结构3∶4∶3、护理队伍与人才培养、亚专科设置、技术特色先进性、独立诊治主要病种等条目并逐项标注标准分、检查方法与扣分规则如30张床得5分、每增10张加1分投入每少20万元扣1分。资源包共1个doc文件约337KB为纯文档表格型资料可直接打印作为迎评台账与模拟打分表使用帮助读者把抽象评审要求拆解为可量化、可追溯的准备清单。目前已有120人学习下载。1. 为什么「省级医学重点专科评估评分标准.doc」需要一个可执行的评分引擎每到评审周期医务处共享盘里那份「省级医学重点专科评估评分标准.doc」就会被反复下载。它是老的 Word 二进制格式里面通常是一张上百行的表格一级指标若干条二级指标几十条每条后面跟着分值、评分要点、扣分说明和佐证材料要求。真正消耗人力的不是读它而是几十个科室要把自己的台账一条条对上去——人工找佐证、人工算分、人工复核最后汇总出来的分数谁都说不清口径是否一致。这个标题要解决的正是这件事把评分标准从人看的文档变成机器能跑的规则。做法不复杂拆成两步——先把 .doc 里的评分表解析成结构化的指标树再为每类指标写一个确定的计分函数让同一份材料无论谁跑都得到同一个分数。适合医务管理、质控和医院信息科的工程师也适合那些每到评审就被材料压住的科室秘书。2. 把 .doc 评分标准拆成可计算的指标树2.1 .doc 与 .docx 的解析差异与工具选型省级主管部门下发的评分标准多数还是.doc后缀。这是个 OLE 复合文档不是 zip 包Python 生态里主流的python-docx直接打开会抛PackageNotFoundError。常见的处理路线有三条一是用 LibreOffice 无头模式转成.docx再解析二是用antiword/catdoc这类命令行工具抽纯文本三是用olefile手工读 Word 流——第三条基本是自找麻烦。我一般选第一条。原因是评分标准的价值几乎全在表格结构和单元格边界上纯文本抽取会把行列关系压平后面再想还原这一行的分值属于哪条指标就得靠猜。转成.docx之后表格是w:tbl结构行、列、合并关系都能拿到。提示转换前先确认文档没有密码保护也不要直接覆盖原件转换产物放到独立的build/目录原始.doc保留只读副本作为审计依据。2.2 三级指标结构从「一级指标」到「评分要点」的字段映射翻过几份不同省份的评分标准会发现表格列名五花八门但语义高度一致稳定落在这么几个字段上文档里的列名常见变体字段名类型说明一级指标 / 指标类别 / 项目level1文本如专科基础条件二级指标 / 指标名称 / 考核内容level2文本如人才梯队结构分值 / 标准分 / 满分max_score数值该条满分多为整数或 0.5 步进评分标准 / 评分要点 / 评分细则rule_text文本决定怎么打分含每降低 1%扣 0.2 分这类描述佐证材料 / 检查方法 / 资料要求evidence文本科室要准备什么备注 / 说明remark文本否决项、加分项常藏在这里映射的关键判断是rule_text决定计分函数max_score决定分数的天花板两者必须拆开存。很多团队图省事把满分 5 分每缺 1 项扣 1 分整句话丢进一个字段后面写评分逻辑时就只能对字符串做匹配脆弱得不堪一击。2.3 指标字典表的 SQL 建模结构化之后落到关系库里用一张自引用的指标表就够了CREATE TABLE indicator ( code VARCHAR(32) PRIMARY KEY, -- 指标编码如 3.2.1直接沿用文档编号 parent_code VARCHAR(32), -- 父级编码一级指标为 NULL name VARCHAR(200) NOT NULL, -- 指标名称 level TINYINT NOT NULL, -- 1 / 2 / 3 级 max_score DECIMAL(6,2) NOT NULL, -- 满分 score_type VARCHAR(16) NOT NULL, -- quant 定量 / qual 定性 / veto 否决 rule_json JSON, -- 计分规则参数见第 4 章 evidence VARCHAR(500), -- 佐证材料要求 version_id VARCHAR(32) NOT NULL -- 所属标准版本 );code直接沿用文档里的编号好处是科室填材料时可以照着纸质版对号入座出了争议能立刻定位到原文哪一行。rule_json用 JSON 存参数而不是存自然语言是为了让评分引擎只面对数字{kind:linear,points:[[60,0],[90,6],[100,10]]}比达到 90% 得 6 分好处理太多。version_id现在看着多余等第二年评分标准修订时就明白它的分量了。3. 从 Word 表格到结构化 JSON 的解析与清洗3.1 用 LibreOffice 把 .doc 批量转成 .docx转换命令不需要图形界面服务器上跑得通# 单文件转换输出到 build 目录保留原文件名 soffice --headless --convert-to docx \ --outdir ./build \ ./原始标准/省级医学重点专科评估评分标准.doc # 目录里有多份历史版本时批量转换注意加防重入锁避免多个实例抢 profile find ./原始标准 -name *.doc -print0 | \ xargs -0 -n1 -P1 soffice --headless \ -env:UserInstallationfile:///tmp/lo_profile \ --convert-to docx --outdir ./build第一条命令的三个参数里--headless表示无界面、--outdir指定输出目录、最后一个位置参数是源文件。批量那条多了一个-env:UserInstallation这是关键LibreOffice 默认用同一个用户配置目录并发启动会互相锁死、进程卡住不返回指定独立 profile 后-P1串行执行才稳定。转换完记得校验一次文件大小0 字节的输出说明源文件损坏或本身是老式 Word 6.0 格式需要另找工具。3.2 python-docx 抽取评分表的最小脚本拿到.docx后先把所有表格行拉成二维数组from docx import Document import re DOCX ./build/省级医学重点专科评估评分标准.docx def cell_text(cell): 单元格内可能有多个段落用换行拼回再去掉首尾空白 parts [p.text.strip() for p in cell.paragraphs if p.text.strip()] return \n.join(parts) def load_rows(path): doc Document(path) rows [] for table in doc.tables: for row in table.rows: cells [cell_text(c) for c in row.cells] # 合并单元格会让同一段文字在相邻列重复出现做一次相邻去重 dedup [c for i, c in enumerate(cells) if i 0 or c ! cells[i - 1]] if len(dedup) 4: # 少于 4 列基本是表头或说明行 continue rows.append(dedup) return rowscell.paragraphs而不是cell.text是因为评分细则里经常用软回车分行列举扣分情形cell.text会把这些分行拍平成一句话。相邻去重这一步不能省python-docx对横向合并的单元格会重复返回同一段文本不去重的话分值列会被复制成好几份后面按列取数就全错位了。len(dedup) 4是个经验阈值用来滤掉跨页重复的表头行和纯说明行实际文档里如果列数不同改成len(dedup) 3再试。3.3 合并单元格、换行符与全角数字的清洗规则解析出来的字符串不能直接入库得先过一遍清洗。常见的噪声有四类处理方式各不相同纵向合并导致的空值一级指标只在第一条二级指标那行出现后续行是空的。处理办法是维护一个当前层级变量遇到非空就更新遇到空就继承。全角数字与中文括号一、.、分这类字符会让正则匹配失败。统一做str.maketrans转换。不可见字符从 PDF 转 Word 再转发的文档里常混入\u200b、\xa0用正则[\u200b\u3000\xa0]一次性清掉。分值列混入单位5 分、5分含加分2分要在抽取数字时只取第一个数值同时把括号内容单独存进remark。清洗这一步别想着一次写完正确姿势是先跑一遍全量统计哪些行的分值字段抽不出数字把这些行打出来人工看二十条规律自然就出来了。指标总数通常不过一两百条人工确认的成本完全可控。4. 评分引擎定量、定性与否决项怎么算4.1 三类指标的判定与分值函数把score_type分三类是保证评分可复现的前提定量项quant科室能填出一个数字如高级职称占比 32%年出院人次 8000。计分函数拿到数字直接算。定性项qual只能由专家按档次判定如专科发展规划的科学性。引擎不自动给分改为输出打分区间和佐证材料清单由专家在界面上选档。否决项veto触发即整体不合格或该项归零常见于发生重大医疗事故数据造假。这类必须在规则里显式标出不能靠人记。区分的价值在于责任边界定量项由系统算专家只负责复核定性项系统只做归集。评审现场最容易吵起来的就是这条到底该算 4 分还是 5 分而绝大多数争议其实发生在定性项上把定量项先自动化掉争议面积能缩小一大半。4.2 连续型指标的线性插值与分段计分rule_json里最常见的一类是分段线性用折线点集表达import bisect def score_linear(value, points): points 形如 [(60, 0), (90, 6), (100, 10)]按 x 升序 在折线上做线性插值超出两端按端点截断 xs [p[0] for p in points] ys [p[1] for p in points] if value xs[0]: return float(ys[0]) if value xs[-1]: return float(ys[-1]) i bisect.bisect_right(xs, value) - 1 x0, x1 xs[i], xs[i 1] y0, y1 ys[i], ys[i 1] return round(y0 (y1 - y0) * (value - x0) / (x1 - x0), 2) # 高级职称占比 65% 对应多少分 print(score_linear(65, [(60, 0), (90, 6), (100, 10)])) # 1.0用折线点集而不是给每类指标写一个if/elif分支好处是评分标准修订时只改 JSON 不动代码。bisect_right找的是不大于value的最大断点下标-1之后得到的[x0, x1]一定把value夹在中间插值结果是确定的。两端的截断规则要注意下限截断到最低分而不是负分上限截断到该项满分否则会出现某科室分数被算成负数的荒唐结果。还有两类规则需要单独处理阶梯型每降低 1 个百分点扣 0.2 分扣完为止用min(max_score, base - step * n)表达扣完为止的关键是那个max下限保护计数型每缺 1 项扣 1 分本质是阶梯型的特例把系数改成 1 即可复用。4.3 跑一遍完整评分并输出明细单个科室的评分主循环长这样def score_department(dept_code, values, indicators): values: {indicator_code: 实测值} indicators: 指标字典列表 detail, total, veto_hit [], 0.0, [] for ind in indicators: if ind[score_type] veto: if values.get(ind[code]) Y: veto_hit.append(ind[code]) continue if ind[score_type] qual: # 定性项不自动给分留空由专家填写但仍计入满分基线 detail.append((ind[code], None, ind[max_score])) continue rule ind[rule_json] raw score_linear(values.get(ind[code], 0), rule[points]) # 双重保护既不能超过该项满分也不能为负 s max(0.0, min(raw, float(ind[max_score]))) detail.append((ind[code], s, ind[max_score])) total s return { dept: dept_code, auto_total: round(total, 2), veto: veto_hit, detail: detail, }这段代码有三个刻意的设计。veto项不进总分累加只记录命中情况因为否决的后果通常是不予认定而不是扣几分两套语义混在一起会让汇总逻辑变得不可读。qual项写入明细时分数为None报表里能一眼看出哪些分是系统给的、哪些是专家给的。max(0.0, min(...))的双重保护看着啰嗦但真跑生产数据时输入值出现空值、负数或者超出预期的极大值时这行是最后一道防线——宁可分数被截断也不能让一条脏数据污染整个汇总。5. 评分结果对不上时的排查路径5.1 解析错位合并单元格与跨页表格最常见的故障是某条指标的分值莫名其妙变成了 0.5而原文写的是 5。八成是纵向合并单元格把上下两行的列错开了一位分值列读到了备注列第一个字符。排查方法是把解析结果和原文并排打印# 抽出解析后前 30 行的编码、名称、满分人工对照原文档 python -c import json rows json.load(open(build/indicators.json, encodingutf-8)) for r in rows[:30]: print(f\{r[code]:8} {r[name][:20]:22} {r[max_score]}\) 判断依据很直接一级指标的满分应当等于其下所有二级指标满分之和。如果某一级指标下出现了 0.5、0.25 这类零碎值而原文全是整数基本可以锁定错位。修复手段是在清洗阶段引入level状态机而不是单纯依赖列下标取数。5.2 权重归一化与四舍五入误差第二个高频问题是总分对不上 100。原因有两层一是原文档本身存在 0.5 分的舍入所有二级指标加起来是 99.5 或 100.5这不是 bug 而是文档事实处理方式是允许 ±0.5 的容差并记录在案二是保留两位小数时分步累加与最后统一舍入的结果不同。# 分步累加每条四舍五入后再相加 total_step sum(round(x, 2) for x in scores) # 统一舍入全部加完再四舍五入 total_final round(sum(scores), 2) print(total_step, total_final) # 可能差 0.01两种口径没有绝对对错但必须全系统统一。我一般选统一舍入因为报表需要可复算任何人拿原始分数重算一遍都能得到同样结果。分步累加会让误差随指标数量放大指标上百条时差出零点几分很常见评审现场解释起来很被动。5.3 用差异比对表定位异常科室自动分和历史人工分放在两张表里一条 SQL 就能把差异大的科室捞出来SELECT a.dept_code, a.indicator_code, a.auto_score, m.manual_score, a.auto_score - m.manual_score AS diff FROM score_auto a JOIN score_manual m ON a.dept_code m.dept_code AND a.indicator_code m.indicator_code WHERE ABS(a.auto_score - m.manual_score) 0.01 ORDER BY ABS(a.auto_score - m.manual_score) DESC;ABS(...) 0.01这个阈值是为了滤掉浮点尾差。按差异绝对值降序排头几条基本能直接定位问题类型如果集中在同一个indicator_code上是这条指标的解析或规则写错了如果集中在同一个dept_code上多半是该科室填报数据的口径和标准不一致比如把占比填成了人数。后一种情况要把差异表直接发给科室确认而不是改规则迁就数据——规则一旦为某个科室松动整套评分就失去公信力。6. 把评分标准做成可版本化、可追溯的评估台账评分标准不是一次性的。省级主管部门通常两三年修订一次修订后分值、指标口径都会变。如果系统里只有一张indicator表新旧标准会互相污染去年的分数用今年的规则重算一遍就完全对不上。解决办法是给每次解析出来的指标结构算一个指纹作为版本号。import hashlib, json def structure_fingerprint(indicators): 只把影响分数的字段纳入指纹编码、满分、计分规则 payload [ {code: i[code], max_score: str(i[max_score]), rule: i[rule_json]} for i in sorted(indicators, keylambda x: x[code]) ] raw json.dumps(payload, ensure_asciiFalse, sort_keysTrue) return hashlib.sha256(raw.encode(utf-8)).hexdigest()[:16]指纹只覆盖code、max_score、rule_json三个字段是刻意的选择。指标名称改个措辞、佐证材料描述调整一句不影响任何一条分数不该触发版本变更而分值变了一分、扣分系数从 0.2 改成 0.3就必须生成新版本。sort_keysTrue保证字典序稳定否则同一份数据两次序列化结果不同指纹就失去意义。取前 16 位十六进制足够避免碰撞也让版本号在界面上显示得下。有了指纹之后每年的评估结果记录里带上version_id就能回答这个科室 2023 年的 87.5 分是按哪版标准算的这类追问。再进一步把两次解析结果的编码集合做差集就能自动生成一份修订说明def diff_versions(old, new): o {i[code]: i for i in old} n {i[code]: i for i in new} added [c for c in n if c not in o] removed [c for c in o if c not in n] changed [c for c in n if c in o and (str(n[c][max_score]) ! str(o[c][max_score]) or n[c][rule_json] ! o[c][rule_json])] return {新增: added, 删除: removed, 分值或规则变化: changed}这份差集会直接变成给科室的培训材料——哪些条目删了、哪些分值调了逐条列清楚比让人自己拿新旧两份 Word 对着翻高效得多。指标编码在这个场景下的价值也体现出来了只要编码规则稳定跨版本比对才有意义所以解析时不要自作主张重排编号文档里怎么写就怎么存。最后一个实操技巧把每年解析出来的indicators.json连同源.doc、LibreOffice 转换出的.docx、结构指纹一起归档文件名带上年份和指纹前 8 位例如2024_省级重点专科_3f9a2c71.json。评审出现争议时从争议指标编码一路倒查到当年原始文档的具体单元格链路是完整闭合的这比任何口头解释都管用。本文还有配套的精品资源点击获取