临床床旁计算工具 元医生 简介
元医生（Yuan Doctor）是面向执业医师与临床研究者的床旁临床计算与指南决策工具：把 NIHSS、HEART、Wells PE、CHA₂DS₂-VASc、HAS-BLED、GCS、qSOFA、SOFA、MELD、APACHE-II、CURB-65、GRACE、eGFR、NEWS2、中国 PAR 等常用评分集中到一个入口。所有计算在浏览器本地完成，不上传数据，网站明确写明结果不替代临床判断。产品由三甲医院临床医生团队合作开发，数据集最近一次审阅标注为 2026 年 10 月 29 日。
- 覆盖场景：脓毒症、卒中绿色通道、肺栓塞、房颤、胸痛等高频急症路径
- 评分工具：十六项以上床旁评分与计算器，按临床场景归类
- 隐私设计：浏览器本地计算，不在服务端留存患者数据
- 维护透明：公开更新日志与数据集审阅日期
为什么床旁工具最该做在浏览器里
临床计算的共同特征是「急、短、容错低」：值班时在床边要算清楚 NIHSS 分级或 qSOFA 评分，掏出手机打开一个需要登录、需要联网、还得填一堆信息的应用，实际体验往往不如直接心算——而心算恰恰是出错率最高的环节。
元医生的做法是把整个计算过程留在浏览器本地完成。这个设计带来的不只是速度：患者数据不出设备，意味着工具本身不构成一个新的数据合规风险点。对医院信息科来说，这一点往往比功能多少更关键——一个会在服务端留痕的评分工具，走内部审批的难度远高于纯前端计算器。
另一处细节是场景短链。网站为脓毒症、卒中、肺栓塞、房颤、胸痛这几条高频路径做了独立入口（例如 /r/sepsis、/r/stroke_code），把该场景需要的评分串在一起。急症场景里最忌讳「找不到」，短链的价值就在于把三次点击压缩成一次。
面向 AI 的机器可读入口
元医生比较少见的一点，是它专门做了一个「For AI」栏目——面向大模型、Custom GPT、Claude Project、Cursor Skill 与媒体提供机器可读入口。站内提供 llms.txt 系列索引（中、英、西、法、日、韩多语版本）、tools.json 工具清单、cite-map.json 引用映射、openapi.json 接口描述、ai-plugin.json 插件声明，以及 /api/v1/cite、/api/v1/tools 两个接口。
这意味着它不只服务人，也服务调用它的 Agent：在 Cursor 或 Claude 里装一个 Skill，或在 Custom GPT 里贴一段指令，模型就能按标准化描述去检索评分口径、引用计算依据。对做医学问答、临床辅助类应用的人来说，这种「可被正确引用」的设计比开放一个通用聊天接口更有价值——医疗场景最怕的就是模型凭印象编评分标准。
- 机器可读：llms.txt / tools.json / cite-map.json / openapi.json 齐备
- 一键安装：提供 Cursor、Claude 的 SKILL.md 与 Custom GPT 指令模板
- 可核查：公开 changelog 与数据集审阅日期，评分口径变更可追溯
- 研究辅助：另有 ROC、Meta 分析、t 检验、Table 1 等统计实验室工具
适合谁用、怎么上手
主要用户是临床一线的执业医师——尤其是急诊、重症、神经内科、心内科这些需要频繁做床旁评分的科室；其次是做临床研究与医学 AI 应用的开发者。上手方式很直接：按场景进短链，或者在评分列表里找到目标量表，填入参数即出结果，无需注册。
如果目的是把评分能力接进自己的 AI 应用，建议从 tools.json 和 openapi.json 看起，先确认接口能返回什么、引用字段怎么用，再用 /api/v1/cite 验证一次引用口径是否与你的知识库一致。
上手提醒
这类工具的正确姿势是「辅助计算，不替代判断」。评分只是把散落的指标换算成一个可讨论的数字，最终诊断与处置仍要结合病史、体征与本院流程。另外，评分量表本身存在版本差异，跨院使用时建议先核对一次口径。
写在最后
元医生把床旁评分做成了轻、快、本地化的工具集，又额外补上了一层面向 AI 的机器可读接口。对医生来说它省下的是掏计算器的时间，对做医疗 AI 的团队来说它提供的是一份可引用、可追溯的口径来源——在医疗这个最不容忍「大概差不多」的领域，后者可能更有长期价值。
类似元医生的软件
