尧图网站建设 
简介这份文档面向医院信息科、医务管理者及互联网医院建设相关人员系统整理了互联网医院从组织架构到岗位职责的一整套管理制度可用于制度建设、合规自查与日常管理参考。资源为单个 doc 文件压缩包约 176KB内容以条款式制度文本为主便于按目录检索与二次编辑。目录涵盖互联网医院管理体系、工作小组与运维管理科设置、诊疗管理办法、患者知情同意与登记制度、医务人员培训与考核、在线复诊风险评估与突发状况处置、在线医疗文书管理、处方审核规范、合理用药管理、医疗安全不良事件报告、信息系统使用管理、CA 签名管理以及医师、护理、药师、质控员、医务管理员、系统管理员、信息安全管理员等岗位职责和突发事件应急预案。已有 52 人学习适合需要快速搭建互联网医院制度框架、补齐条款细节的机构参考借鉴。1. 把二十多份子制度翻译成系统规则线上问诊跑通了患者也付了钱可质控科要一份上月处方点评合格率数据在问诊、处方、点评三个系统里对不上——这类问题很少出在接口上多半是制度没被翻译成系统规则。这份《医院互联网医院管理制度》正是干这个的它把领导小组、运维管理科、医务科、药剂科、信息科各管什么线上医师什么条件能上、什么情况必须下线每次诊疗前签什么处方怎么审、指标怎么算全部写成可执行条款。整份文档由二十多个子制度拼成从《互联网医院诊疗管理办法》到《CA 签名管理制度》覆盖组织架构、人员准入退出、知情同意、在线处方、信息安全六条主线。它适合三类人做互联网医院系统建设的研发与产品、负责线上质控的医务管理者、要把纸面制度搬进审批流的实施顾问。下面按条款到表结构、到校验逻辑、到指标对账的顺序走一遍。2. 组织架构与职责矩阵的数据建模2.1 为什么职责不能只躺在 Word 里制度里领导小组掌握政策方向工作小组制定管理制度运维管理科负责出诊医生培训这类表述如果只停在文档上落地时会出现三种典型扯皮一是权限不知道该给谁开二是审批流走到某个节点没人接三是出了问题回溯不到责任部门。常见做法是把组织节点、职责条目、岗位人员拆成三层用编码而不是中文名做主键这样后续换科室名称、调整分管副院长都不用改代码。需要特别提醒的是制度里明确写了其它支持部门包含医务科、质量管理科、护理部、药剂科、信息科、临床科室、宣传科与门诊部七类。这七类的职责颗粒度差别极大药剂科能直接对应处方审核表宣传科只能对应帮助文档硬塞进同一张权限表只会越做越乱。2.2 组织节点与职责条目的建表脚本CREATE TABLE ih_org_node ( node_code VARCHAR(32) PRIMARY KEY COMMENT 组织编码如 LEAD_GROUP/WORK_GROUP/OPS_DEPT, node_name VARCHAR(64) NOT NULL COMMENT 组织名称, parent_code VARCHAR(32) DEFAULT NULL COMMENT 上级组织编码顶层为 NULL, node_type TINYINT NOT NULL COMMENT 1决策层 2管理层 3执行层 4支持部门, is_active TINYINT NOT NULL DEFAULT 1 ); CREATE TABLE ih_duty ( duty_id BIGINT PRIMARY KEY AUTO_INCREMENT, node_code VARCHAR(32) NOT NULL COMMENT 所属组织, duty_seq SMALLINT NOT NULL COMMENT 职责序号与制度原文条目顺序一一对应, duty_text VARCHAR(500) NOT NULL COMMENT 职责原文摘要, sys_module VARCHAR(64) DEFAULT NULL COMMENT 落地模块NULL 表示纯人工流程, UNIQUE KEY uk_node_seq (node_code, duty_seq) );node_type是权限上卷的依据给运维管理科开的问诊数据权限决策层天然应该能看汇总但不该看到患者明细。duty_seq保留原文序号是关键设计质控或内审拿着制度对照系统时能一条一条点对而不是靠关键词搜。初始化之后先跑一次哪些职责还没落到模块上的盘点SELECT n.node_name, COUNT(*) AS total_duty, SUM(CASE WHEN d.sys_module IS NULL THEN 1 ELSE 0 END) AS manual_duty FROM ih_org_node n JOIN ih_duty d ON d.node_code n.node_code GROUP BY n.node_name ORDER BY manual_duty DESC;manual_duty数量高的部门往往是上线排期里最容易被漏掉的一环先把它拉出来开会定人比先写代码更省事。2.3 支持部门职责到系统模块的映射支持部门制度中的关键职责落地模块数据落点医务科准入审核、退出执行、线上服务质量抽查资质管理、抽查任务资质表、抽查记录表质量管理科制定质控指标体系、定期检查并记录指标定义、质控任务指标定义表、任务表护理部互联网护理风险评估、质量追踪护理风险评估风险评估单药剂科处方审核、药品目录、禁药管控处方审核、药品目录处方审核表、目录表信息科系统运行、全流程留痕、信息安全审计日志操作日志表临床科室图文/电话/视频复诊、科普更新问诊、内容管理问诊单、科普文章表宣传科与门诊部品牌推广、患者操作指导帮助中心帮助文档表提示药剂科职责里严格禁止麻醉药品、精神药品、医疗毒性药品在线上使用这条必须落成药品目录上的布尔字段加开方前置校验不能只靠药师事后审核兜底。2.4 权限初始化的执行顺序先把组织节点插进去再插职责条目最后按岗位把node_code挂到具体人员账号上。顺序颠倒会导致外键校验失败。跑完后用一条自检语句确认没有孤儿职责SELECT d.duty_id, d.node_code FROM ih_duty d LEFT JOIN ih_org_node n ON n.node_code d.node_code WHERE n.node_code IS NULL;结果非空说明职责挂到了不存在的组织上通常是编码大小写或空格问题修正后再放开权限初始化脚本。3. 医师准入退出与培训考核的自动判定3.1 准入四条件的校验顺序制度第 7 条给了四个条件依法取得执业资质并在实体机构注册且中级以上职称、执业证书注册在本院、取得门诊出诊资质、经互联网诊疗培训并考核合格。这四个条件的校验成本完全不同——前两个可以对接医师执业注册信息第三个查院内出诊排班表第四个依赖培训系统。按先查本地、后查外部的顺序排能在绝大多数场景下避免无谓的外部调用。我一般的做法是把四个条件做成独立的策略函数返回(passed, reason)由编排层决定是否短路。这样某个外部接口临时不可用时可以只把对应条件标记为待人工复核而不是整个准入流程卡死。3.2 退出机制的计数规则与时间窗口退出条款是这份制度里最容易写错代码的地方因为它同时涉及阈值、时间窗口和事件状态三个维度。from dataclasses import dataclass from datetime import date, timedelta dataclass class AccessPolicy: bad_review_limit: int 3 # 年度差评次数上限对应制度第8条 valid_complaint_limit: int 3 # 年度经核实的有效投诉上限 rule_violation_limit: int 2 # 年度违反制度或卫生法规次数上限 suspend_days: int 365 # 暂停线上诊疗资质的天数 def evaluate_access(doctor_id: str, year: int, stats: dict, policy: AccessPolicy AccessPolicy()) - dict: reasons [] if stats[bad_review] policy.bad_review_limit: reasons.append(f年度差评{stats[bad_review]}次) if stats[valid_complaint] policy.valid_complaint_limit: reasons.append(f有效投诉{stats[valid_complaint]}次) if stats[rule_violation] policy.rule_violation_limit: reasons.append(f违反制度{stats[rule_violation]}次) if stats[major_dispute] 0: reasons.append(线上不当诊疗导致重大医疗纠纷) if not reasons: return {doctor_id: doctor_id, suspend: False, resume_at: None} return { doctor_id: doctor_id, suspend: True, resume_at: date(year, 12, 31) timedelta(dayspolicy.suspend_days), reasons: reasons, }这里的判定用而不是因为制度写的是三次及以上。第四类情形重大医疗纠纷没有次数门槛一次即触发所以单独用 0判断。取数 SQL 要格外小心 join 膨胀SELECT d.doctor_id, COUNT(DISTINCT CASE WHEN e.event_type BAD_REVIEW THEN e.event_id END) AS bad_review, COUNT(DISTINCT CASE WHEN e.event_type COMPLAINT AND e.status CONFIRMED THEN e.event_id END) AS valid_complaint, COUNT(DISTINCT CASE WHEN e.event_type RULE_VIOLATION THEN e.event_id END) AS rule_violation FROM ih_doctor d LEFT JOIN ih_doctor_event e ON e.doctor_id d.doctor_id AND e.event_time :year_start AND e.event_time :year_end GROUP BY d.doctor_id;status CONFIRMED对应制度里经核实的有效投诉这个限定词未核实的投诉不能计入。COUNT(DISTINCT event_id)是为了防止同一条投诉因为多环节流转产生多条记录被重复计数。3.3 培训考核指标的参数化配置考核条款里塞了十一个维度硬编码进代码基本等于给自己挖坑建议全部配置化。指标制度阈值统计周期常见取数陷阱在线问诊人次每月不低于 20自然月撤单与测试单需排除在线诊疗人次每月不低于 10自然月以复诊完结算未结束不计数科普开展每季度不低于 1 次自然季度草稿状态不算在线活跃时长每月不少于 5 小时自然月需心跳去噪防后台挂机预约时间偏差小于 8 小时单次预约用预约时间对比首次有效回复时间咨询回复准确性不低于 90%月抽样口径必须固定复诊诊断准确率不低于 90%月依赖质控抽样结果初诊诊断准确率不低于 70%月与复诊分开统计规范治疗率不低于 90%月判定规则需先达成一致随访好转率不低于 80%月失访是否计入分母要先定死处方点评合格率不低于 90%点评周期与药师退回修改要区分开注意预约时间偏差 8 小时这一条用医生首次回复时间和实际视频接通时间算出来的结果可能差出一整天。先在需求评审上把口径定死并写进指标定义表再动手写 SQL。3.4 定时任务与暂停执行考核按年度跑但资质暂停不能等到年底才生效。可行方案是双轨年内每次差评或投诉核实后触发一次增量判定命中阈值立即写入资质暂停表年度考核只负责评分和绩效挂钩。暂停表落库后要同步刷新医生端的接诊开关缓存否则前端可能还在放号。4. 知情同意留痕、CA 签名与在线处方审核4.1 知情同意签署痕迹的表结构制度第 2 条写得很硬每一次的线上诊疗活动前都须签署知情同意书。注意主语是每一次不是每个患者一次所以唯一键必须建在诊疗单上。CREATE TABLE ih_consent_record ( consent_id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, visit_id BIGINT NOT NULL COMMENT 一次线上诊疗单, tpl_version VARCHAR(16) NOT NULL COMMENT 知情同意书模板版本号, signed_at DATETIME(3) NOT NULL, client_ip VARCHAR(45), device_id VARCHAR(64), signature_algo VARCHAR(16) COMMENT 如 SM2withSM3、SHA256withRSA, signature_val TEXT, UNIQUE KEY uk_visit (visit_id), KEY idx_patient_signed (patient_id, signed_at) );tpl_version不能省。制度第 4 条要求信息科负责模板线上维护和签署痕迹后台登记模板一旦改版旧记录的签署内容必须能按当时版本还原否则纠纷时说不清患者到底同意了哪一版。4.2 CA 签名的验签与存证要点from cryptography import x509 from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding def verify_signature(cert_pem: bytes, message: bytes, signature: bytes) - bool: cert x509.load_pem_x509_certificate(cert_pem) # 有效期与吊销状态应在验签前单独校验这里只做签名本身 pub cert.public_key() try: pub.verify(signature, message, padding.PKCS1v15(), hashes.SHA256()) return True except Exception: return False验签失败的绝大多数原因不在算法而在待签原文被重新序列化了。JSON 字段顺序、时间格式、空格任一变化都会导致验签不通过。稳妥做法是签署前把业务对象规范化字段排序、时间统一到毫秒、去掉不可见字符把规范化后的字节流单独存一份验签时直接取这份原文不要再去拼。4.3 在线处方状态机与药师审核队列制度明确处方经药师审核合格后方可生效所以状态机必须区分医师已签和处方已生效。状态含义可流转到触发方DRAFT医师编辑中SIGNED医师SIGNED已加签待药师审核REVIEWING、VOIDED药师REVIEWING药师审核中APPROVED、REJECTED药师APPROVED审核通过处方生效VOIDED药师REJECTED退回修改DRAFT、VOIDED医师或超时VOIDED作废终态药师-- 药师待审队列先进先出等待超时的排前面 SELECT r.rx_id, r.visit_id, r.doctor_id, r.signed_at, TIMESTAMPDIFF(MINUTE, r.signed_at, NOW()) AS waiting_minutes FROM ih_prescription r WHERE r.status SIGNED AND r.created_at DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY r.signed_at ASC LIMIT 50;waiting_minutes除了排序还能直接接告警超过 30 分钟未审就推送给药剂科值班药师。created_at的范围限制是为了避免历史积压单一直霸占队首。4.4 禁开药品与特殊人群的拦截规则SELECT 1 FROM ih_drug_catalog WHERE drug_code :drug_code AND online_forbidden 1 LIMIT 1;命中即拒绝开方返回给医师的提示要写清具体类别。低龄儿童这一条对应制度里为 6 岁以下儿童开具互联网儿童用药处方时应当确定患儿有监护人和相关专业医师陪伴落地时在校验器里加两个必填位guardian_present与second_doctor_id任一为空则不允许提交。5. 质控指标对账与考核评分的排错技巧指标算出来对不上先别怀疑数据库八成是口径问题。第一种表现是同名指标两个数预约偏差这一条A 版本用医生首次回复时间B 版本用视频接通时间两者能差出一整天。第二种是边界问题服务器跑 UTC自然月按东八区切月初月末各丢几个小时的量。第三种最隐蔽join 问诊表和投诉表统计投诉数一条投诉挂多条问诊记录时指标被放大数倍这时改用EXISTS或先在子查询里做COUNT(DISTINCT)预聚合再关联。制度第 21 条要求病历、医师意见等数据能实现全程全天候调阅、回溯这意味着历史考核结果不能因为上游数据更新而漂移。所以考核口径的数据要落快照表实时明细只用来对账。-- 快照与实时明细对账偏差超过 1% 就排查 SELECT s.doctor_id, s.month_key, s.visit_cnt AS snapshot_cnt, COALESCE(r.visit_cnt, 0) AS realtime_cnt, ROUND(ABS(s.visit_cnt - COALESCE(r.visit_cnt, 0)) / NULLIF(s.visit_cnt, 0) * 100, 2) AS diff_pct FROM ih_doctor_month_snapshot s LEFT JOIN ( SELECT doctor_id, DATE_FORMAT(completed_at, %Y-%m) AS month_key, COUNT(DISTINCT visit_id) AS visit_cnt FROM ih_consult WHERE status FINISHED AND deleted 0 GROUP BY doctor_id, DATE_FORMAT(completed_at, %Y-%m) ) r ON r.doctor_id s.doctor_id AND r.month_key s.month_key WHERE s.month_key :month_key HAVING diff_pct 1;COUNT(DISTINCT visit_id)防的是 join 膨胀status FINISHED必须与指标定义表里的口径逐字一致deleted 0排除作废单。经验上对账 SQL 只要留一列diff_pct并按它倒序看前十条绝大多数口径问题十分钟内就能定位到具体医生和具体单据。本文还有配套的精品资源点击获取 互联网医院管理制度落地：组织建模、医师准入与在线处方审核
简介这份文档面向医院信息科、医务管理者及互联网医院建设相关人员系统整理了互联网医院从组织架构到岗位职责的一整套管理制度可用于制度建设、合规自查与日常管理参考。资源为单个 doc 文件压缩包约 176KB内容以条款式制度文本为主便于按目录检索与二次编辑。目录涵盖互联网医院管理体系、工作小组与运维管理科设置、诊疗管理办法、患者知情同意与登记制度、医务人员培训与考核、在线复诊风险评估与突发状况处置、在线医疗文书管理、处方审核规范、合理用药管理、医疗安全不良事件报告、信息系统使用管理、CA 签名管理以及医师、护理、药师、质控员、医务管理员、系统管理员、信息安全管理员等岗位职责和突发事件应急预案。已有 52 人学习适合需要快速搭建互联网医院制度框架、补齐条款细节的机构参考借鉴。1. 把二十多份子制度翻译成系统规则线上问诊跑通了患者也付了钱可质控科要一份上月处方点评合格率数据在问诊、处方、点评三个系统里对不上——这类问题很少出在接口上多半是制度没被翻译成系统规则。这份《医院互联网医院管理制度》正是干这个的它把领导小组、运维管理科、医务科、药剂科、信息科各管什么线上医师什么条件能上、什么情况必须下线每次诊疗前签什么处方怎么审、指标怎么算全部写成可执行条款。整份文档由二十多个子制度拼成从《互联网医院诊疗管理办法》到《CA 签名管理制度》覆盖组织架构、人员准入退出、知情同意、在线处方、信息安全六条主线。它适合三类人做互联网医院系统建设的研发与产品、负责线上质控的医务管理者、要把纸面制度搬进审批流的实施顾问。下面按条款到表结构、到校验逻辑、到指标对账的顺序走一遍。2. 组织架构与职责矩阵的数据建模2.1 为什么职责不能只躺在 Word 里制度里领导小组掌握政策方向工作小组制定管理制度运维管理科负责出诊医生培训这类表述如果只停在文档上落地时会出现三种典型扯皮一是权限不知道该给谁开二是审批流走到某个节点没人接三是出了问题回溯不到责任部门。常见做法是把组织节点、职责条目、岗位人员拆成三层用编码而不是中文名做主键这样后续换科室名称、调整分管副院长都不用改代码。需要特别提醒的是制度里明确写了其它支持部门包含医务科、质量管理科、护理部、药剂科、信息科、临床科室、宣传科与门诊部七类。这七类的职责颗粒度差别极大药剂科能直接对应处方审核表宣传科只能对应帮助文档硬塞进同一张权限表只会越做越乱。2.2 组织节点与职责条目的建表脚本CREATE TABLE ih_org_node ( node_code VARCHAR(32) PRIMARY KEY COMMENT 组织编码如 LEAD_GROUP/WORK_GROUP/OPS_DEPT, node_name VARCHAR(64) NOT NULL COMMENT 组织名称, parent_code VARCHAR(32) DEFAULT NULL COMMENT 上级组织编码顶层为 NULL, node_type TINYINT NOT NULL COMMENT 1决策层 2管理层 3执行层 4支持部门, is_active TINYINT NOT NULL DEFAULT 1 ); CREATE TABLE ih_duty ( duty_id BIGINT PRIMARY KEY AUTO_INCREMENT, node_code VARCHAR(32) NOT NULL COMMENT 所属组织, duty_seq SMALLINT NOT NULL COMMENT 职责序号与制度原文条目顺序一一对应, duty_text VARCHAR(500) NOT NULL COMMENT 职责原文摘要, sys_module VARCHAR(64) DEFAULT NULL COMMENT 落地模块NULL 表示纯人工流程, UNIQUE KEY uk_node_seq (node_code, duty_seq) );node_type是权限上卷的依据给运维管理科开的问诊数据权限决策层天然应该能看汇总但不该看到患者明细。duty_seq保留原文序号是关键设计质控或内审拿着制度对照系统时能一条一条点对而不是靠关键词搜。初始化之后先跑一次哪些职责还没落到模块上的盘点SELECT n.node_name, COUNT(*) AS total_duty, SUM(CASE WHEN d.sys_module IS NULL THEN 1 ELSE 0 END) AS manual_duty FROM ih_org_node n JOIN ih_duty d ON d.node_code n.node_code GROUP BY n.node_name ORDER BY manual_duty DESC;manual_duty数量高的部门往往是上线排期里最容易被漏掉的一环先把它拉出来开会定人比先写代码更省事。2.3 支持部门职责到系统模块的映射支持部门制度中的关键职责落地模块数据落点医务科准入审核、退出执行、线上服务质量抽查资质管理、抽查任务资质表、抽查记录表质量管理科制定质控指标体系、定期检查并记录指标定义、质控任务指标定义表、任务表护理部互联网护理风险评估、质量追踪护理风险评估风险评估单药剂科处方审核、药品目录、禁药管控处方审核、药品目录处方审核表、目录表信息科系统运行、全流程留痕、信息安全审计日志操作日志表临床科室图文/电话/视频复诊、科普更新问诊、内容管理问诊单、科普文章表宣传科与门诊部品牌推广、患者操作指导帮助中心帮助文档表提示药剂科职责里严格禁止麻醉药品、精神药品、医疗毒性药品在线上使用这条必须落成药品目录上的布尔字段加开方前置校验不能只靠药师事后审核兜底。2.4 权限初始化的执行顺序先把组织节点插进去再插职责条目最后按岗位把node_code挂到具体人员账号上。顺序颠倒会导致外键校验失败。跑完后用一条自检语句确认没有孤儿职责SELECT d.duty_id, d.node_code FROM ih_duty d LEFT JOIN ih_org_node n ON n.node_code d.node_code WHERE n.node_code IS NULL;结果非空说明职责挂到了不存在的组织上通常是编码大小写或空格问题修正后再放开权限初始化脚本。3. 医师准入退出与培训考核的自动判定3.1 准入四条件的校验顺序制度第 7 条给了四个条件依法取得执业资质并在实体机构注册且中级以上职称、执业证书注册在本院、取得门诊出诊资质、经互联网诊疗培训并考核合格。这四个条件的校验成本完全不同——前两个可以对接医师执业注册信息第三个查院内出诊排班表第四个依赖培训系统。按先查本地、后查外部的顺序排能在绝大多数场景下避免无谓的外部调用。我一般的做法是把四个条件做成独立的策略函数返回(passed, reason)由编排层决定是否短路。这样某个外部接口临时不可用时可以只把对应条件标记为待人工复核而不是整个准入流程卡死。3.2 退出机制的计数规则与时间窗口退出条款是这份制度里最容易写错代码的地方因为它同时涉及阈值、时间窗口和事件状态三个维度。from dataclasses import dataclass from datetime import date, timedelta dataclass class AccessPolicy: bad_review_limit: int 3 # 年度差评次数上限对应制度第8条 valid_complaint_limit: int 3 # 年度经核实的有效投诉上限 rule_violation_limit: int 2 # 年度违反制度或卫生法规次数上限 suspend_days: int 365 # 暂停线上诊疗资质的天数 def evaluate_access(doctor_id: str, year: int, stats: dict, policy: AccessPolicy AccessPolicy()) - dict: reasons [] if stats[bad_review] policy.bad_review_limit: reasons.append(f年度差评{stats[bad_review]}次) if stats[valid_complaint] policy.valid_complaint_limit: reasons.append(f有效投诉{stats[valid_complaint]}次) if stats[rule_violation] policy.rule_violation_limit: reasons.append(f违反制度{stats[rule_violation]}次) if stats[major_dispute] 0: reasons.append(线上不当诊疗导致重大医疗纠纷) if not reasons: return {doctor_id: doctor_id, suspend: False, resume_at: None} return { doctor_id: doctor_id, suspend: True, resume_at: date(year, 12, 31) timedelta(dayspolicy.suspend_days), reasons: reasons, }这里的判定用而不是因为制度写的是三次及以上。第四类情形重大医疗纠纷没有次数门槛一次即触发所以单独用 0判断。取数 SQL 要格外小心 join 膨胀SELECT d.doctor_id, COUNT(DISTINCT CASE WHEN e.event_type BAD_REVIEW THEN e.event_id END) AS bad_review, COUNT(DISTINCT CASE WHEN e.event_type COMPLAINT AND e.status CONFIRMED THEN e.event_id END) AS valid_complaint, COUNT(DISTINCT CASE WHEN e.event_type RULE_VIOLATION THEN e.event_id END) AS rule_violation FROM ih_doctor d LEFT JOIN ih_doctor_event e ON e.doctor_id d.doctor_id AND e.event_time :year_start AND e.event_time :year_end GROUP BY d.doctor_id;status CONFIRMED对应制度里经核实的有效投诉这个限定词未核实的投诉不能计入。COUNT(DISTINCT event_id)是为了防止同一条投诉因为多环节流转产生多条记录被重复计数。3.3 培训考核指标的参数化配置考核条款里塞了十一个维度硬编码进代码基本等于给自己挖坑建议全部配置化。指标制度阈值统计周期常见取数陷阱在线问诊人次每月不低于 20自然月撤单与测试单需排除在线诊疗人次每月不低于 10自然月以复诊完结算未结束不计数科普开展每季度不低于 1 次自然季度草稿状态不算在线活跃时长每月不少于 5 小时自然月需心跳去噪防后台挂机预约时间偏差小于 8 小时单次预约用预约时间对比首次有效回复时间咨询回复准确性不低于 90%月抽样口径必须固定复诊诊断准确率不低于 90%月依赖质控抽样结果初诊诊断准确率不低于 70%月与复诊分开统计规范治疗率不低于 90%月判定规则需先达成一致随访好转率不低于 80%月失访是否计入分母要先定死处方点评合格率不低于 90%点评周期与药师退回修改要区分开注意预约时间偏差 8 小时这一条用医生首次回复时间和实际视频接通时间算出来的结果可能差出一整天。先在需求评审上把口径定死并写进指标定义表再动手写 SQL。3.4 定时任务与暂停执行考核按年度跑但资质暂停不能等到年底才生效。可行方案是双轨年内每次差评或投诉核实后触发一次增量判定命中阈值立即写入资质暂停表年度考核只负责评分和绩效挂钩。暂停表落库后要同步刷新医生端的接诊开关缓存否则前端可能还在放号。4. 知情同意留痕、CA 签名与在线处方审核4.1 知情同意签署痕迹的表结构制度第 2 条写得很硬每一次的线上诊疗活动前都须签署知情同意书。注意主语是每一次不是每个患者一次所以唯一键必须建在诊疗单上。CREATE TABLE ih_consent_record ( consent_id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, visit_id BIGINT NOT NULL COMMENT 一次线上诊疗单, tpl_version VARCHAR(16) NOT NULL COMMENT 知情同意书模板版本号, signed_at DATETIME(3) NOT NULL, client_ip VARCHAR(45), device_id VARCHAR(64), signature_algo VARCHAR(16) COMMENT 如 SM2withSM3、SHA256withRSA, signature_val TEXT, UNIQUE KEY uk_visit (visit_id), KEY idx_patient_signed (patient_id, signed_at) );tpl_version不能省。制度第 4 条要求信息科负责模板线上维护和签署痕迹后台登记模板一旦改版旧记录的签署内容必须能按当时版本还原否则纠纷时说不清患者到底同意了哪一版。4.2 CA 签名的验签与存证要点from cryptography import x509 from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding def verify_signature(cert_pem: bytes, message: bytes, signature: bytes) - bool: cert x509.load_pem_x509_certificate(cert_pem) # 有效期与吊销状态应在验签前单独校验这里只做签名本身 pub cert.public_key() try: pub.verify(signature, message, padding.PKCS1v15(), hashes.SHA256()) return True except Exception: return False验签失败的绝大多数原因不在算法而在待签原文被重新序列化了。JSON 字段顺序、时间格式、空格任一变化都会导致验签不通过。稳妥做法是签署前把业务对象规范化字段排序、时间统一到毫秒、去掉不可见字符把规范化后的字节流单独存一份验签时直接取这份原文不要再去拼。4.3 在线处方状态机与药师审核队列制度明确处方经药师审核合格后方可生效所以状态机必须区分医师已签和处方已生效。状态含义可流转到触发方DRAFT医师编辑中SIGNED医师SIGNED已加签待药师审核REVIEWING、VOIDED药师REVIEWING药师审核中APPROVED、REJECTED药师APPROVED审核通过处方生效VOIDED药师REJECTED退回修改DRAFT、VOIDED医师或超时VOIDED作废终态药师-- 药师待审队列先进先出等待超时的排前面 SELECT r.rx_id, r.visit_id, r.doctor_id, r.signed_at, TIMESTAMPDIFF(MINUTE, r.signed_at, NOW()) AS waiting_minutes FROM ih_prescription r WHERE r.status SIGNED AND r.created_at DATE_SUB(NOW(), INTERVAL 30 DAY) ORDER BY r.signed_at ASC LIMIT 50;waiting_minutes除了排序还能直接接告警超过 30 分钟未审就推送给药剂科值班药师。created_at的范围限制是为了避免历史积压单一直霸占队首。4.4 禁开药品与特殊人群的拦截规则SELECT 1 FROM ih_drug_catalog WHERE drug_code :drug_code AND online_forbidden 1 LIMIT 1;命中即拒绝开方返回给医师的提示要写清具体类别。低龄儿童这一条对应制度里为 6 岁以下儿童开具互联网儿童用药处方时应当确定患儿有监护人和相关专业医师陪伴落地时在校验器里加两个必填位guardian_present与second_doctor_id任一为空则不允许提交。5. 质控指标对账与考核评分的排错技巧指标算出来对不上先别怀疑数据库八成是口径问题。第一种表现是同名指标两个数预约偏差这一条A 版本用医生首次回复时间B 版本用视频接通时间两者能差出一整天。第二种是边界问题服务器跑 UTC自然月按东八区切月初月末各丢几个小时的量。第三种最隐蔽join 问诊表和投诉表统计投诉数一条投诉挂多条问诊记录时指标被放大数倍这时改用EXISTS或先在子查询里做COUNT(DISTINCT)预聚合再关联。制度第 21 条要求病历、医师意见等数据能实现全程全天候调阅、回溯这意味着历史考核结果不能因为上游数据更新而漂移。所以考核口径的数据要落快照表实时明细只用来对账。-- 快照与实时明细对账偏差超过 1% 就排查 SELECT s.doctor_id, s.month_key, s.visit_cnt AS snapshot_cnt, COALESCE(r.visit_cnt, 0) AS realtime_cnt, ROUND(ABS(s.visit_cnt - COALESCE(r.visit_cnt, 0)) / NULLIF(s.visit_cnt, 0) * 100, 2) AS diff_pct FROM ih_doctor_month_snapshot s LEFT JOIN ( SELECT doctor_id, DATE_FORMAT(completed_at, %Y-%m) AS month_key, COUNT(DISTINCT visit_id) AS visit_cnt FROM ih_consult WHERE status FINISHED AND deleted 0 GROUP BY doctor_id, DATE_FORMAT(completed_at, %Y-%m) ) r ON r.doctor_id s.doctor_id AND r.month_key s.month_key WHERE s.month_key :month_key HAVING diff_pct 1;COUNT(DISTINCT visit_id)防的是 join 膨胀status FINISHED必须与指标定义表里的口径逐字一致deleted 0排除作废单。经验上对账 SQL 只要留一列diff_pct并按它倒序看前十条绝大多数口径问题十分钟内就能定位到具体医生和具体单据。本文还有配套的精品资源点击获取