恩尔普分诊叫号系统

1.1 编写目的

本说明书用于完整描述「恩尔普分诊叫号系统」（以下简称"本系统"）的产品定位、系统组成、功能范围、技术架构、数据模型、部署方案与运维要点，作为产品交付、实施部署、验收培训与后续运维的技术依据。

1.2 读者对象

1.3 术语与缩略语

2.1 产品定位

本系统是一套面向医院门诊与体检中心的分诊排队叫号软件，用于解决候诊人员无序聚集、诊室叫号靠人工喊、就诊进度不可见、多科室排队难以协同等问题。

系统以"一个服务端 + 多种显示终端"的形态交付：院内只需部署一套服务端，即可同时支撑医护工作站、大厅信息屏、诊室门口屏、欢迎屏以及自助一体机等多类终端，各终端通过网络实时获取队列状态。

2.2 应用场景

2.3 设计理念

2.4 产品形态一览

3.1 服务端

服务端是本系统的核心，提供统一的数据存储、业务规则计算、语音合成与对外接口服务。主要包含：

• 业务服务层：排队分配、叫号、过号、状态流转、队列调整、诊室迁移、队列清理。
• 数据访问层：负责与关系数据库交互，持久化排队、科室、播报、人员等数据。
• 对外开放接口：向各类终端提供任务接口，同时向医院信息系统（HIS）获取人员与科室数据。
• 语音合成服务：将叫号文本合成为语音文件，供终端播报。
• 后台定时任务：周期性清理超时队列与历史播报记录，保持数据精简。
• AI 问答代理：为可选的本地 AI 知识库提供统一入口，负责请求鉴权、输入脱敏、超时熔断、并发控制与出处透传。
• 授权校验：对核心业务接口进行授权有效期校验。

3.2 医护工作站

Windows 桌面客户端，是分诊护士与诊室医护的日常操作界面。主要包含：

• 排队列表与候诊区 / 就诊区 / 已完结列表分页展示；
• 一键排队、选号（呼叫指定人员）、下一个（顺序叫号）、过号；
• 状态调整（恢复至等待 / 恢复至过号 / 转入就诊）；
• 调整诊室（将队列整体或指定人员在诊室间迁移）；
• 科室与诊室维护（新增、修改、删除、启用停用）；
• 语音播报与本地音量、播报频率设置；
• 快速打印（号票打印）。

3.3 大屏信息发布终端

同一份队列数据可投放到不同形态的屏幕上，按用途分为：

大屏终端存在三种实现形态，实施时按现场条件择一：

3.4 授权与运维工具

一个轻量的 Windows 桌面工具，用于在实施现场写入软件授权有效期。工具与授权校验使用配套的加密参数，避免授权信息被简单篡改。

3.5 智能问答（可选模块）

在服务端与联网终端之外，系统可选配一套本地 AI 知识库问答能力，由两部分组成：

• 内网 AI 服务：提供院内资料的知识库检索与本地大模型推理，模型文件与向量数据均落在本院内网服务器，不依赖互联网；
• 问答入口：网页端「智能问答」独立页、公共首页入口卡片，以及医护工作站的 AI 助手抽屉（见 11.2）。

该模块由服务端配置开关控制启用，未启用时前端自动隐藏入口，对取号、叫号等主业务无任何影响。详细说明见第 11 章。

4.1 功能总览

4.2 服务端功能

排队分配

接收人员编号与排队模式参数，自动完成信息获取、可用诊室筛选、序号分配与入库，并返回该人员的排队结果（含前面还有几人）。

叫号与状态流转

支持"下一个"顺序叫号与"选号"指定叫号；同一诊室同时只允许一名就诊人员，若诊室已有就诊者，重复叫号会被拒绝并给出明确提示；若被叫人员已在其他诊室就诊，同样会给出提示，避免一人同时占用两个诊室。

过号处理

过号后序号保持不变，仅将状态置为过号，可在后续任意时刻重新呼叫，不打断其余人员的排队秩序。

队列调整

支持将某个诊室的全部未完结队列整体迁移到另一个已激活诊室；也支持按人员编号列表批量迁移到指定诊室，适用于诊室临时停诊、设备故障或人员分流。

播报队列

叫号类操作会将待播报信息写入播报队列，终端轮询取出后即刻翻转状态，保证同一条叫号不会被重复播报；同时提供历史播报记录的清理能力。

后台定时清理

按可配置周期（默认 300 秒）执行两类清理：清理已完成且超出保留时长的排队记录（默认 6 小时）、清理历史播报记录。

语音合成

接收文本、诊室、发音人等参数，调用云端语音合成能力生成音频文件，并返回文件名供终端播放；合成失败时终端可降级使用本机语音引擎播报，保证叫号不中断。

授权校验

核心业务接口在执行前校验授权有效期，过期时返回明确的业务状态码与提示，便于实施人员快速定位。

4.3 医护工作站功能

4.4 大屏与终端功能

4.5 管理配置功能

4.6 对外接口（HIS 对接）

系统对外提供三类集成接口，均以统一 JSON 结构返回，字段约定为"状态码 + 消息体"：

对接要点：

1. 多条数据以英文逗号分隔，姓名与性别以"姓名,性别"形式返回；
2. 实际对接时由医院侧按其 HIS 能力实现上述三个地址，并将地址配置到本系统，本系统在排队过程中实时调用；
3. 系统内置一套可直接运行的示例接口实现，便于在未接通 HIS 时完成功能验证与培训。

4.7 智能问答功能

为可选模块，提供两类场景能力：院内资料速查（就诊须知、科室位置、检查注意事项、医保报销等）与文书整理（把口述或草稿整理为规范文本格式）。所有回答均只依据院内知识库并强制附带出处，不产出诊断、用药与治疗建议。入口形态、技术实现与合规要求详见第 11 章。

5.1 架构总览

系统采用典型的三层架构并按"服务端集中、终端轻量"的原则组织：

• 表现层：桌面客户端、网页大屏、移动一体机，统一通过 HTTP 接口与服务端交互；
• 服务层：业务应用服务（排队、叫号、科室、呼叫站等）、后台定时任务、对外接口控制器、授权切面、语音合成服务、AI 问答代理（可选模块）；
• 数据层：关系数据库，承载排队、科室、播报、人员等数据；启用 AI 知识库时，另由内网 AI 服务维护院内资料的向量数据。

5.2 分层设计

5.3 技术栈

5.4 数据存储

系统支持两类关系数据库，同一时间使用其中一种，通过配置项切换：

切换方式：修改配置项 Database:Provider 为 SqlServer 或 PostgreSql，并配置对应连接串；也可通过环境变量覆盖，便于同一套程序在多环境间迁移。

5.5 关键技术机制

叫号状态机

排队记录的状态取值与含义如下：

播报去重机制

叫号产生的播报任务写入播报队列并标记为"未播报"；终端取走即翻转为"已播报"。由于翻转发生在服务端且为单次操作，多个大屏同时轮询时同一条叫号只会被取走一次，从机制上避免重复播报。

定时清理机制

后台服务以固定周期运行，清理已完成超过保留时长的排队记录与历史播报记录，保证数据量长期稳定，避免历史数据影响查询性能。

授权校验机制

核心业务接口带授权校验，读取本机保存的加密有效期，解密后与当前时间比对，过期即返回未授权状态。授权有效期由配套运维工具写入。

多终端并发访问

大屏采用短周期轮询、客户端采用带取消机制的异步拉取，服务端接口为无状态查询，天然支持多终端并行访问；叫号类操作在服务端做唯一性校验（同诊室仅一名就诊者），从规则层面防止并发重复叫号。

6.1 排队主流程

6.2 叫号流程

6.3 三种排队算法

系统提供三种排队模式，由调用方通过参数选择，适配不同科室的组织方式：

公共规则

• 只能存在一个未完结队列——人员若已有未完结队列，重复排队时直接返回原队列，避免重复占号；
• 诊室必须处于"已激活"状态方可排队；
• 性别受限诊室自动排除不符合条件的人员；
• 序号在同一诊室内体现先后顺序，大屏按序号与排队时间展示。

6.4 状态流转

7.1 数据表清单

7.2 关键字段说明

排队表（核心字段）

科室 / 诊室表（核心字段）

7.3 数据生命周期

8.1 功能层面

8.2 技术层面

8.3 部署与运维层面

8.4 交付与适配层面

8.5 与典型自建方案的对比

9.1 部署形态与拓扑

推荐采用院内单服务器集中部署：

9.2 服务器环境要求

9.3 终端环境要求

9.4 网络与端口

9.5 数据库准备

方式一：使用 SQL Server

1. 在数据库实例上创建业务库（例如 MedQueueDb）；
2. 创建专用登录账号并授予该库的读写与建表权限（建议不使用超级管理员账号）；
3. 记录连接串，格式：Data Source=<主机>,<端口>; Database=<库名>; uid=<账号>; pwd=<密码>;

方式二：使用 PostgreSQL

1. 创建业务库（例如 medqueuedb），字符集建议 UTF-8；
2. 创建专用账号并授予该库权限；
3. 记录连接串，格式：Host=<主机>;Port=5432;Database=<库名>;Username=<账号>;Password=<密码>

9.6 服务端部署步骤

9.7 数据库初始化与升级

系统提供独立的数据初始化与迁移工具，负责建表、写入基础数据以及版本升级：

# 使用 SQL Server
迁移工具 --provider SqlServer

# 使用 PostgreSQL
迁移工具 --provider PostgreSql

# 静默模式（适合脚本化执行）
迁移工具 --provider PostgreSql -q

执行要点：

1. 运行位置：需在程序输出目录（即日志配置所在目录）下执行，否则日志组件会因找不到配置而报错；
2. 首次部署：执行一次即可完成全部建表与基础数据写入；
3. 版本升级：替换程序文件后再次执行，工具会按差量应用新增结构变更；
4. 数据库切换：更换数据库类型时，须以新类型对应的参数重新执行，且两套结构脚本不可混用；
5. 执行前备份：生产环境升级前务必先备份数据库。

9.8 终端部署与配置

医护工作站

1. 安装 .NET Framework 4.8 运行时；
2. 拷贝客户端程序目录到工作站；
3. 编辑客户端配置文件，将服务地址指向应用服务器，并按科室设置默认科室 / 诊室、是否启用语音、音量、播报频率、打印机等参数；
4. 启动后逐项验证：排队、选号、下一个、过号、状态回退、调整诊室、科室维护、语音播报、打印。

桌面大屏

1. 安装 .NET Framework 4.8 运行时；
2. 拷贝大屏程序目录；
3. 配置服务地址、机构名称、默认科室 / 诊室、语音开关与音量；
4. 设置开机自动启动并全屏显示；
5. 验证：总览刷新、叫号弹窗、语音播报。

网页大屏

1. 将网页构建产物部署到任意静态站点（可与应用服务器同机，也可独立部署）；
2. 配置后端服务地址与页面标题；
3. 在大屏设备上用浏览器打开并以全屏方式运行；
4. 若网页与后端不同源，需确认服务端已允许对应的跨域来源。

移动一体机

1. 将移动应用安装到横屏一体机；
2. 配置后端服务地址；
3. 验证自助排队流程与叫号展示。

9.9 授权注册

1. 在应用服务器上，以运行应用服务的同一 Windows 账号执行授权运维工具；
2. 选择授权到期日期并写入；
3. 工具会将加密后的有效期与配套密钥写入当前账号的配置区；
4. 重新启动应用服务使授权生效；
5. 到期前重复上述步骤即可续期，无需升级程序版本。

9.10 上线验证清单

9.11 备份与容灾

9.12 日常运维

9.13 常见故障排查

10.1 已具备的安全能力

10.2 部署与使用建议（重要）

为满足医院信息安全管理要求，投产前建议落实以下加固措施：

1. 配置项加密与最小暴露：数据库账号、云端语音服务密钥、令牌签名密钥等敏感配置，建议改由环境变量、密钥管理服务或加密配置提供，避免以明文形式留在配置文件中；数据库账号应使用最小权限的专用账号，不使用超级管理员账号。
2. 账号与口令策略：修改系统内置账号的默认口令，启用强口令与定期更换策略，按岗位最小授权。
3. 网络访问控制：服务端口仅在院内网开放，禁止映射到公网；终端与服务器之间建议划分独立 VLAN 或做访问控制。
4. 数据脱敏：大屏展示姓名时可按院内要求做部分脱敏（如"张*三"）；人员编号不在大屏展示。
5. 日志与审计：保留服务端与终端的操作日志，定期归档；对叫号、状态回退等敏感操作可启用审计追踪。
6. 传输安全：如需跨网段或跨院区访问，建议在服务端启用 HTTPS 或通过安全网关转发。
7. 授权方案跨平台化（如需）：若后续需要部署到非 Windows 环境或容器平台，建议将授权校验改造为基于签名授权文件的跨平台方案，使应用与操作系统解耦。
8. 个人信息保护：系统处理的姓名、性别、出生日期、就诊信息属于个人信息，应按《个人信息保护法》与医院信息安全管理规定，明确采集范围、使用目的与留存期限，并做好访问控制与销毁记录。
9. AI 知识库内容治理：入库资料须经院内审核并明确可对外范围，涉及诊疗规范、医保政策的内容应由对应管理部门把关；建议定期复核知识库版本与失效文档，并在界面上持续保留"AI 输出仅供参考、不作为诊疗依据"的提示。

11.1 能力定位

智能问答是一个可选增值模块，为导诊与护士站提供两类辅助能力：

11.2 使用入口

入口是否显示由服务端配置与 AI 服务可用性共同决定：模块未启用或服务不可用时，前端自动隐藏入口或提示"暂不可用"，不影响取号、叫号等其他功能。

11.3 交互与输出

11.4 技术实现

系统不采用「终端直连大模型」的做法，而是由服务端做一层薄代理，所有问答统一经此转发，终端与 AI 服务之间不直接通信：

服务端薄代理

对外只暴露两个接口——查询可用性与提交问题。由它统一完成：

• 密钥保护：AI 服务的地址与应用密钥只存在于服务端，不下发到浏览器；
• 输入预处理：去除首尾空白、按配置截断超长问题，并把手机号、证件号替换为占位符；
• 并发闸门：限制同时打到本地推理服务的请求数（默认 4），避免公共终端连续提交把显卡压垮；
• 超时与熔断：单次问答超时（默认 60 秒）；一旦失败则在设定时长内（默认 30 秒）快速失败，保证 AI 抖动不拖累取号叫号主链路；
• 输出清洗：剥离推理模型的思考内容，避免屏幕上出现大段"自我独白"；
• 出处透传与日志：原样返回知识库出处，并记录问题与耗时（不记录患者身份）。

内网 AI 服务

由知识库检索与本地大模型推理两部分组成，可基于开源组件自建，或采用自研检索增强方案，前端完全无感：

• 知识库：院内资料（就诊须知、科室指引、医保政策、制度文件等）经审核后切分、向量化入库；
• 本地大模型：模型文件部署在本院内网服务器，推理过程不访问互联网；
• 检索增强：先从知识库检索相关片段，再交由模型组织答案，使回答有据可依并可直接给出出处。

11.5 部署与配置

启用该模块需完成三步：

AI 服务与应用服务器之间只需内网互通，无需互联网。

11.6 合规与安全