Shdc Appointment

medical-triage-followup 是一个面向中文纯聊天窗口的医疗分诊、病例整理、随访跟踪和挂号辅助 Skill。它的定位不是替代医生做诊断，而是帮助 LLM 在对话中把用户的模糊健康问题逐步澄清为可执行的就医诉求，并在需要时编排 SHDC 预约 MCP 查询医院、科室、专家、专病门诊和可预约时间。

Skill 路径：

medical-triage-followup/

适用场景

• 用户描述身体不适，但诉求模糊，例如“腿疼”“最近不舒服”“想看看该挂什么科”。
• 用户希望根据症状选择医院、科室、专家或专病门诊。
• 用户提供一个时间范围，希望汇总该时间段内可预约的专家、专病门诊、余号和费用。
• 用户上传门诊病历、检查报告、检验报告、出院小结、病案首页、报告图片、PDF、DOCX 或复制的病例文本。
• 用户需要把病例整理成病情时间线、随访提醒、复查计划、就诊前准备清单和医生问题清单。
• 用户没有完成线下初诊或建档，需要先查看医院自助挂号入口，而不是直接进入正式预约。

核心原则

1. 只做分诊和就医辅助，不做确定诊断。
2. 症状问诊阶段每轮只问一个最关键问题。
3. 中间不展示“当前理解”，只在最终分诊时总结。
4. 出现急诊红旗时立即中止普通分诊，建议急诊或 120。
5. 预约前必须确认用户是否已经完成线下初诊/建档。
6. 不绕过验证码、短信码、实名校验、就诊人校验或最终确认。
7. 不在聊天中暴露完整身份证号、手机号、住址、医疗卡号、token 或密码。
8. 病例处理保留临床含义，但输出时默认脱敏。

工作流概览

1. 症状澄清

当用户只给出模糊症状时，Skill 会引导 LLM 连续追问，例如：

• 最困扰你的症状是什么？
• 具体部位在哪里？
• 持续多久了？
• 是否有外伤、发热、胸闷、呼吸困难、麻木无力等伴随表现？
• 目前严重程度如何，是否影响行走、进食、睡眠或日常活动？

基础澄清最多 5 轮。如果用户引入新的关键线索，可以开启新的 5 轮澄清。每轮只问一个问题，避免一次性把用户压住。

2. 红旗判断

在普通分诊前，Skill 会先检查危险信号。典型红旗包括：

• 压榨性胸痛、胸痛伴大汗/呼吸困难/晕厥。
• 单侧肢体无力、口角歪斜、言语不清、突发剧烈头痛。
• 严重呼吸困难、喉头水肿、过敏伴喘憋或头晕。
• 严重外伤、畸形、不能负重、活动性出血。
• 呕血、黑便伴乏力、持续剧烈腹痛、疑似宫外孕。
• 高热伴意识改变、颈强直、紫癜、严重感染进展。
• 自伤或伤人风险。

如果红旗存在，Skill 应优先建议急诊或 120，而不是继续推荐普通门诊预约。

3. 分诊与挂号类型判断

当信息足够后，Skill 会输出：

• 症状总结
• 紧急程度
• 建议科室
• 推荐挂号类型：专家或专病
• MCP 查询关键词
• 不能确定的部分
• 是否可以继续帮用户查询预约

目前普通门诊访问不稳定，因此默认不推荐普通门诊。只有用户明确要求普通门诊时，才提示其可能不可靠，并优先提供专家或专病替代方案。

挂号类型映射：

registerType=1 专家门诊
registerType=2 专病/专科专病门诊
registerType=3 普通门诊，默认不使用

4. MCP 预约查询

Skill 本身不直接访问医院网页，而是指导 LLM 使用 SHDC 预约 MCP。推荐调用顺序是：

1. search_hospitals
2. search_departments
3. list_available_experts
4. list_expert_slots
5. 如用户确认继续预约，再进入登录、就诊人、验证码、短信码、确认和提交流程。

如果用户给出时间范围，例如“本周末”“下周一上午”“6 月 28 日到 7 月 3 日”，Skill 要求 LLM 将其规范化为具体日期和上午/下午等时间段，并汇总范围内所有匹配专家或专病门诊的可用号源，而不是只返回一个医生。

5. 初诊/建档限制

如果用户是第一次使用，或没有完成目标医院的线下初诊/建档，Skill 要求停止正式注册和预约流程，只返回：

• 医院/院区
• 科室
• 门诊类型
• 专家或专病门诊项
• 可预约时间
• 剩余号数或状态
• 费用
• 对应医院的微信服务/自助挂号链接

在医院信息查询完成、正式帮用户挂号前，Skill 会提示：

你是否还没有完成线下初诊/建档，或者希望自己通过医院微信服务挂号？

如果用户回答是，则优先附上 hospital-wechat-links.md 中记录的医院挂号入口。

病例处理能力

用户上传病例、报告或复制病例文本后，Skill 会按以下顺序处理：

1. 文本提取或 OCR 清洗。
2. 识别文书类型和来源。
3. 抽取主诉、现病史、既往史、诊断/印象、检查检验、影像结论、用药、手术/操作、医嘱和复诊计划。
4. 评估资料可信度。
5. 检查缺失信息。
6. 建立病情时间线。
7. 追踪异常检查值。
8. 从病例中触发红旗结果。
9. 生成就诊前准备清单。
10. 生成建议问医生的问题。
11. 输出 Markdown + JSON 随访卡。

资料可信度与缺失信息

可信度分为：

• high：官方报告清晰、文书结构完整、关键日期/结果/来源可见。
• medium：大部分内容可读，但部分日期、单位、页码、来源或 OCR 内容不完整。
• low：图片或文本质量差、核心诊断/结果缺失、只来自用户转述。

缺失信息只列影响下一步决策的问题，例如：

• 报告日期或检查日期缺失。
• 检验值没有单位或参考范围。
• 当前症状是否仍在持续不明确。
• 用药剂量、频次、开始/停止时间不明确。
• 医生复查建议或目标科室不明确。

病情时间线

时间线用于把多份病例合并为一个清楚的过程。事件类型包括：

• 症状出现
• 门诊/急诊/住院
• 检查或检验
• 影像报告
• 诊断或印象
• 治疗计划
• 手术或操作
• 用药变化
• 出院和复诊建议

如果日期被脱敏或缺失，使用“最早记录”“随后”“住院期间”“术后”“当前”等顺序标签，不编造具体日期。

异常检查值追踪

异常值判断优先依据报告本身：

• 异常报告
• 危急报告
• 异常提示
• H / L / A
• ↑ / ↓
• 可见参考范围
• 医生文字说明，如“明显升高”“降低”“需复查”

如果没有参考范围或异常标记，只记录数值，不自行判断异常。

病例触发红旗

病例中出现以下线索时，应优先提醒用户尽快就医或急诊：

• 检验系统显示危急报告或危急值。
• 影像提示急性出血、急性梗死、严重感染、明显进展。
• 癌栓、门静脉主干栓子、梗阻性黄疸、腹水合并发热等严重并发症线索。
• 医嘱写明“立即就医”“急诊”“尽快住院”“需紧急处理”。
• 病例记录中有胸闷加重、呼吸困难、意识改变、呕血黑便等危险症状。

注意：既往病史中的红旗不应自动等同于当前急诊。例如“脑出血恢复期”应标为重要既往风险，而不是直接判断为正在急性脑出血。

输出格式

分诊建议

分诊建议
- 症状总结：
- 紧急程度：
- 建议科室：
- 推荐挂号类型：专家 / 专病
- 查询关键词：
- 理由：
- 不能确定：
- 预约协助：我可以继续帮你查询并预约，请告诉我你想预约的医院。

可预约信息

可预约信息
- 医院/院区：
- 科室：
- 门诊类型：专家 / 专病
- 专家/门诊项：
- 可用时间：
- 剩余号数/状态：
- 费用：
- 自助挂号链接：

病例整理

病例整理
- 资料可信度：
- 主要问题：
- 关键诊断/印象：
- 重要检查结果：
- 当前治疗/用药：
- 医嘱与复诊：

缺失信息
-

病情时间线
| 时间/顺序 | 事件 | 来源 | 可信度 |
|---|---|---|---|

异常检查值追踪
| 项目 | 结果 | 参考范围/标记 | 日期 | 建议追踪 |
|---|---|---|---|---|

病例触发红旗
-

就诊前准备
-

建议问医生的问题
1.

随访提醒卡

Skill 要求输出可见 Markdown 卡片和 JSON 卡片，便于后续聊天或其他应用继续接管。

JSON 卡片包含：

• record_quality
• conditions
• timeline_events
• symptoms_to_track
• medications
• tests_to_follow
• record_red_flags
• next_visit
• pre_visit_checklist
• doctor_questions
• reminders
• open_questions

文件结构

medical-triage-followup/
├── SKILL.md
└── references/
    ├── abnormal-and-red-flag-tracking.md
    ├── appointment-availability-summary.md
    ├── case-extraction-template.md
    ├── diagnostic-cases.md
    ├── followup-card-template.md
    ├── hospital-wechat-links.md
    ├── medical-entity-types.md
    ├── medical-timeline-template.md
    ├── ocr-guidelines.md
    ├── pre-visit-and-doctor-questions.md
    ├── record-quality-and-gaps.md
    ├── triage-clarification.md
    └── triage-rules.md

关键 Reference 说明

• triage-clarification.md：定义症状多轮追问状态机。
• triage-rules.md：定义症状到科室、挂号类型和危险信号的规则。
• diagnostic-cases.md：可扩展案例库，用于辅助分诊，不作为确诊依据。
• appointment-availability-summary.md：定义时间范围内号源汇总方式。
• hospital-wechat-links.md：保存部分医院微信服务或自助挂号入口。
• case-extraction-template.md：病例抽取主模板。
• record-quality-and-gaps.md：资料可信度和缺失信息检查。
• medical-timeline-template.md：病情时间线模板。
• abnormal-and-red-flag-tracking.md：异常值追踪和病例红旗触发规则。
• pre-visit-and-doctor-questions.md：就诊前准备和医生问题清单。
• followup-card-template.md：Markdown + JSON 随访卡模板。

与 SHDC MCP 的关系

Skill 负责“理解用户、澄清症状、整理病例、判断科室、组织对话流程”；MCP 负责“实时查询医院、科室、专家、号源，以及完成登录、验证码、就诊人和预约提交等官方流程”。

二者的边界是：

• Skill 不直接提交挂号。
• Skill 不绕过官方验证码或短信码。
• Skill 不保存或展示完整隐私字段。
• MCP 不负责诊断症状；症状应先由 Skill 转成科室和查询关键词。

测试建议

症状澄清测试：

• 输入“我身体不舒服”，应先问最困扰的症状。
• 输入“腿疼”，应逐步询问部位、持续时间、外伤、严重程度和伴随症状。
• 输入胸痛伴大汗、偏瘫、呼吸困难等，应立即触发急诊建议。

预约查询测试：

• 用户给出医院和科室后，应能引导 MCP 查询专家和专病门诊。
• 用户给出“下周上午”之类时间范围，应汇总该范围内所有匹配号源。
• 未确认线下初诊/建档时，只返回可预约信息和自助挂号入口，不进入正式预约。

病例测试：

• 门诊病历应抽取主诉、现病史、诊断、计划和随访医嘱。
• MRI/CT 报告应抽取检查项目、所见、印象和需要复查的问题。
• 检验报告应保留数值、单位、参考范围和异常标记。
• 出院小结或病案首页应生成诊断、治疗、住院过程和复诊计划。
• 多份病例应合并成时间线，而不是互相覆盖。

本项目本地曾使用 病例/ 目录下 4 个脱敏 DOCX 做验收，但该目录已被 .gitignore 排除，不上传 GitHub。

安全与合规边界

• 该 Skill 不能替代医生诊断、处方或急救判断。
• 对药物剂量、停药、换药，只能引用官方病历中的医嘱；如果病历没有写，应建议咨询医生。
• 对正常报告不能说“排除疾病”。
• 对恶性肿瘤、危急值、急性出血/梗死等结果，应保持谨慎，提示尽快专科或急诊评估。
• 对用户隐私字段默认脱敏，不在聊天中重复完整证件号、手机号、住址、病案号、条形码、二维码等。

维护方式

新增症状案例：

编辑 medical-triage-followup/references/diagnostic-cases.md

新增医院自助挂号入口：

编辑 medical-triage-followup/references/hospital-wechat-links.md

调整病例抽取字段：

编辑 medical-triage-followup/references/case-extraction-template.md
同步检查 medical-triage-followup/references/followup-card-template.md

调整红旗或异常值规则：

编辑 medical-triage-followup/references/abnormal-and-red-flag-tracking.md

更新后建议运行：

python C:\Users\RIRKO\.codex\skills\.system\skill-creator\scripts\quick_validate.py .\medical-triage-followup

在 Windows PowerShell 中如遇中文路径或输出乱码，建议设置：

$env:PYTHONUTF8='1'

远程 MCP Handoff（2026-07-04）

本节记录最近一次远程 MCP 部署、验证和 xskills 网页客户端排查情况，供后续接手继续定位。

工作区边界

• 本地工作区：D:\项目\shdc-appointment-mcp，默认用于开发 skill 和 MCP 源码。
• 远程服务器：SSH 别名 aliyun-mcp，部署路径 /opt/mcp。
• 远程数据目录：/opt/mcp/data。
• 远程命令格式：ssh aliyun-mcp "命令"。
• 上传文件格式：scp 本地文件 aliyun-mcp:/opt/mcp/目标路径。
• 不要删除远程系统目录，不要执行 git reset --hard、rm -rf / 等破坏性命令。

当前远程服务

• 公网域名：https://rirko.icu
• 健康检查：https://rirko.icu/healthz
• MCP Endpoint：https://rirko.icu/mcp
• 协议：Streamable HTTP
• systemd 服务：shdc-remote-mcp.service
• 启动命令：/opt/mcp/node/bin/node /opt/mcp/dist/httpIndex.js
• Nginx 反代：/mcp 和 /healthz 代理到 http://127.0.0.1:3000
• 证书：certbot 已签发 HTTPS 证书，域名解析到 47.239.148.19

远程环境文件：

/opt/mcp/remote-mcp.env

当前关键环境变量：

HOST=127.0.0.1
PORT=3000
SHDC_MCP_DATA_DIR=/opt/mcp/data
HTTPS_PROXY=http://127.0.0.1:18080
HTTP_PROXY=http://127.0.0.1:18080
NO_PROXY=127.0.0.1,localhost
MCP_AUTH_TOKEN=<见 /opt/mcp/remote-mcp.env>
MCP_JSON_RESPONSE=true

获取当前 MCP token：

ssh aliyun-mcp "grep '^MCP_AUTH_TOKEN=' /opt/mcp/remote-mcp.env"

客户端请求头模板：

Authorization=Bearer <MCP_AUTH_TOKEN>
Content-Type=application/json
Accept=application/json, text/event-stream
MCP-Protocol-Version=2025-06-18

部分客户端只需要：

Authorization=Bearer <MCP_AUTH_TOKEN>

最近代码和部署状态

• 已新建 remote-mcp/，从原 MCP 复制并改成远程 Streamable HTTP 形式。
• 已部署到远程 /opt/mcp，远程服务通过 systemd 管理。
• 已加入健康档案、病历/报告解析保存、用药、过敏、药物冲突、忌口提醒、时间轴、治疗记录等 MCP tools。
• 已接入 DDInter 实验性网页适配器，用于药物-药物、药物-食物、药物-疾病、复方/重复用药相关提醒。
• 已修复远程 MCP 浏览器兼容性：GET /mcp 无 session 时返回 200 探针，CORS 放行 MCP 相关头。
• 已修复 /opt/mcp/remote-mcp.env 中错误写成 nMCP_JSON_RESPONSE=truen 的问题，当前为 MCP_JSON_RESPONSE=true。
• 本地有一个未成功 push 的提交：0956e3f Improve browser MCP compatibility。GitHub push 之前多次因网络 reset/empty reply 失败，后续需要重试。

检查本地状态：

git status --short --branch

已验证结果

浏览器直连：

• https://rirko.icu/healthz 正常。
• https://rirko.icu/mcp 返回 200 JSON 探针。
• 从 xskills 页面浏览器直接 GET https://rirko.icu/mcp 也返回 200，Nginx 日志记录到 referer 为 https://xskills.acits.com.cn/。

MCP 协议探针：

• initialize 返回 200。
• notifications/initialized 返回 202。
• tools/list 返回 200。
• MCP_JSON_RESPONSE=true 生效后，POST initialize 和 tools/list 返回 application/json，不再是 SSE 包装。

远程服务状态检查：

ssh aliyun-mcp "systemctl is-active nginx; systemctl is-active shdc-remote-mcp.service"

日志检查：

ssh aliyun-mcp "tail -300 /var/log/nginx/access.log | grep ' /mcp' | tail -50"
ssh aliyun-mcp "tail -80 /opt/mcp/remote-mcp.log"

SHDC 访问与代理

远程服务器直接访问 SHDC 会遇到 WAF/403，因此当前方案是用本机作为代理出口。

本地代理脚本：

remote-mcp/scripts/local-http-proxy.mjs

本地代理监听：

127.0.0.1:18080

反向 SSH 隧道：

ssh -N -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=2 -R 127.0.0.1:18080:127.0.0.1:18080 aliyun-mcp

远程环境已配置：

HTTPS_PROXY=http://127.0.0.1:18080
HTTP_PROXY=http://127.0.0.1:18080
NO_PROXY=127.0.0.1,localhost

验证代理链：

ssh aliyun-mcp "curl -x http://127.0.0.1:18080 -I https://yuyue.shdc.org.cn/"

健康的代理链应返回 200。若 SHDC 查询超时，通常需要重启本地代理和反向 SSH 隧道。

xskills 网页客户端当前结论

xskills 页面新增/编辑 MCP 服务器时的配置：

连接地址：https://rirko.icu/mcp
协议类型：streamableHTTP
请求头：Authorization=Bearer <MCP_AUTH_TOKEN>
标签：shdc,mcp,remote
描述：上海医联预约远程 MCP，支持健康档案和 SHDC 查询

如果需要完整请求头：

Authorization=Bearer <MCP_AUTH_TOKEN>
Content-Type=application/json
Accept=application/json, text/event-stream
MCP-Protocol-Version=2025-06-18

当前 xskills 测试接口返回：

{
  "code": 200,
  "message": "操作成功",
  "data": {
    "serverName": "aliyun-mcp",
    "success": false,
    "toolCount": 0,
    "error": "服务连接失败，请检查服务是否正常运行"
  },
  "success": true
}

排查结论：

• xskills 前端测试请求是 POST https://xskills.acits.com.cn/api/v1/mcp-market/user/servers/62/test。
• 该请求 content-length: 0，说明它测试的是后端已保存的 server 配置，不是页面当前输入框实时内容。
• xskills 测试失败时，rirko.icu 服务器日志没有看到 xskills 后端访问 /mcp。
• 浏览器从 xskills 页面直接访问 https://rirko.icu/mcp 成功，Nginx 记录 GET /mcp 200。
• 因此当前失败更像是 xskills 后端未真正连到 https://rirko.icu/mcp、后端 DNS/网络不可达、保存配置未生效，或平台测试逻辑不兼容，而不是远程 MCP 服务本身不可用。

后续建议：

1. 在 xskills 页面先保存修改，再测试连接。
2. 测试时先只保留一行请求头：Authorization=Bearer <MCP_AUTH_TOKEN>。
3. 若仍失败，继续检查 xskills 的 test 接口响应，并同时观察远程 Nginx 日志是否出现来自 xskills 后端 IP 的 /mcp 请求。
4. 若服务器仍无请求，需让 xskills 平台侧确认后端是否能解析并访问 rirko.icu:443。

已知问题

• /opt/mcp/remote-mcp.log 里有一次 shutdown 期间的 RangeError: Maximum call stack size exceeded，出现在 SDK transport close 链路递归关闭时；服务已由 systemd 自动拉起且当前 active。后续可以单独修复关闭流程，避免 server.close() 和 transport.close() 互相触发。
• GitHub push 最近失败，当前本地可能领先远程 1 个提交。需要网络稳定后重试 push。
• xskills 平台账号的登录 Bearer/Cookie 曾在排查截图中暴露，后续 handoff 不应继续传播该平台登录 token。