项目设计概览
面向门诊运营的预约与号源自动化系统。系统负责资源容量校验、预约、候补排序、取消爽约空档恢复、补位通知与确认；特殊号源、资源冲突和规则外人工加号由运营人员接管。
公开说明匿名公开。页面中的患者、手机号、医生、科室、诊室、预约号、候补顺序和运营数据均为 GEXYRAL DEMO 或脱敏结构展示。
CASE-47
华东地区某综合医疗机构
华东地区 定制Web应用 医药制造 定制Web应用开发
从桌面到移动端，查看实际交付界面
桌面、平板和手机分别展示对应的项目界面，方便从不同终端查看信息层级、操作路径与实际交付范围。
多终端体验
项目功能与后台
改造前后，工作方式发生了什么变化
直接看原来的工作方式、系统接手的部分、仍然需要人工确认的环节，以及最后得到的结果。
改造前01
改造前
门诊运营中，预约号源会因为医生排班、诊室维护、患者取消、改期和爽约持续变化。前台或客服若依赖人工电话协调，很难及时把释放的号源重新利用。
系统处理02
系统接手了什么
资源矩阵｜统一查看医生、科室、诊室和时间段容量，自动识别冲突与不可用资源。
患者自助预约｜患者按科室、医生和时间段完成预约，系统实时校验剩余号源。
候补登记｜号源已满时进入候补队列，保留登记时间、优先级和就诊紧急程度等规则字段。
候补排序｜按既定规则自动排序候补患者，不依赖人工维护名单。
取消与改期｜患者取消或改期后立即释放原号源并进入空档恢复流程。
爽约识别｜超过到诊或确认规则后识别爽约并释放可恢复资源。
自动补位｜发现空档后自动查询符合条件的候补患者并依次发送补位通知。
确认时限｜候补患者需在设定时限内确认，超时自动释放并通知下一位。
就诊提醒｜预约确认后按设定时间发送就诊提醒，降低遗忘与爽约。
容量管理｜医生排班、诊室维护和临时停诊同步改变可预约容量。
冲突检测｜阻止重复预约、诊室冲突、医生冲突和超容量预约。
人工接管｜特殊号源、人工加号、资源异常和无法自动补位的事件进入运营队列。
审计日志｜记录预约、候补排序、通知、确认、取消爽约、补位和人工操作。
人工确认03
哪些仍需人工确认
本案例采用资源预约矩阵、患者移动端、流程编排引擎、医生诊室容量时间轴和取消爽约恢复中心五种不同的信息架构，避免使用同一套 Dashboard 模板。
最终结果04
最后得到什么
系统上线后，门诊前台和客服不再依赖人工维护候补名单、逐个电话通知和反复确认号源。正常预约、取消、空档释放与候补补位由系统持续执行，人工聚焦于特殊号源、临时停诊和无法自动解决的资源冲突。
这个项目具体做了什么
按实际业务问题、需要处理的流程、开发内容和交付结果展开，便于判断是否与你的情况相近。
现状01
改造前怎么工作
门诊运营中，预约号源会因为医生排班、诊室维护、患者取消、改期和爽约持续变化。前台或客服若依赖人工电话协调，很难及时把释放的号源重新利用。
主要问题02
重复人工与业务断点
传统流程通常需要人工登记预约、逐个核对医生时段、维护候补名单、电话通知候补患者并等待确认。患者临时取消或爽约后，空档可能无法及时补上，既影响患者体验，也浪费诊疗资源。
项目目标03
这次真正要改变什么
统一医生、科室、诊室和时间段容量；患者自助预约与候补；取消或爽约后自动释放号源；系统按规则排序候补并通知补位；超时未确认自动转下一位；就诊前自动提醒，最终回写预约和就诊状态。
人工确认04
哪些判断继续由人负责
本案例采用资源预约矩阵、患者移动端、流程编排引擎、医生诊室容量时间轴和取消爽约恢复中心五种不同的信息架构，避免使用同一套 Dashboard 模板。
流程设计05
流程怎样进入系统
预约调度平台负责医生诊室矩阵与资源冲突；患者移动端负责预约、候补、改期与提醒；补位引擎负责候补排序与自动通知；容量管理负责医生诊室周排班；恢复中心负责取消、爽约、空档和人工异常。
开发内容06
杰泽尔实际开发了什么
建设院区、科室、医生、诊室、排班、号源容量、预约、候补、改期取消、爽约检测、空档池、候补排序、自动通知、确认超时、补位结果、到诊提醒、人工加号、权限和审计日志。
系统处理07
系统现在承担什么
资源矩阵｜统一查看医生、科室、诊室和时间段容量，自动识别冲突与不可用资源。
患者自助预约｜患者按科室、医生和时间段完成预约，系统实时校验剩余号源。
候补登记｜号源已满时进入候补队列，保留登记时间、优先级和就诊紧急程度等规则字段。
候补排序｜按既定规则自动排序候补患者，不依赖人工维护名单。
取消与改期｜患者取消或改期后立即释放原号源并进入空档恢复流程。
爽约识别｜超过到诊或确认规则后识别爽约并释放可恢复资源。
自动补位｜发现空档后自动查询符合条件的候补患者并依次发送补位通知。
确认时限｜候补患者需在设定时限内确认，超时自动释放并通知下一位。
就诊提醒｜预约确认后按设定时间发送就诊提醒，降低遗忘与爽约。
容量管理｜医生排班、诊室维护和临时停诊同步改变可预约容量。
冲突检测｜阻止重复预约、诊室冲突、医生冲突和超容量预约。
人工接管｜特殊号源、人工加号、资源异常和无法自动补位的事件进入运营队列。
审计日志｜记录预约、候补排序、通知、确认、取消爽约、补位和人工操作。
交付结果08
最终形成什么业务能力
系统上线后，门诊前台和客服不再依赖人工维护候补名单、逐个电话通知和反复确认号源。正常预约、取消、空档释放与候补补位由系统持续执行，人工聚焦于特殊号源、临时停诊和无法自动解决的资源冲突。
完成这个项目实际用了哪些服务
这里列出项目实际使用的主要服务和相关服务，方便继续查看对应的服务内容。
主要服务定制Web应用开发
构建门诊预约、候补补位与诊疗资源自动调度系统。
- 门诊预约与候补自动化系统
相关服务需求梳理
梳理院区、科室、医生、诊室、门诊时段、预约容量、候补患者、取消爽约和通知之间的业务关系。
- 医生排班
- 诊室资源
- 预约号源
- 候补队列
相关服务产品规划
定义预约容量、资源冲突、候补排序、补位确认、超时释放、改期取消和人工接管规则。
- 容量规则
- 候补排序
- 超时释放
- 人工接管
相关服务信息架构设计
建立患者、医生、科室、诊室、排班、号源、预约、候补、通知、就诊状态和异常记录的统一数据结构。
- 预约模型
- 候补模型
- 资源模型
相关服务用户路径设计
设计从预约、候补登记、取消爽约、空档释放、自动补位、二次确认到就诊状态回写的连续闭环。
- 预约
- 取消
- 补位
- 确认
- 就诊闭环
相关服务UI界面设计
设计资源调度矩阵、患者移动端、候补补位流程、医生诊室容量时间轴和取消爽约恢复中心五类页面。
- 资源矩阵
- 患者移动端
- 补位引擎
- 容量时间轴
- 恢复中心
相关服务交互体验设计
让预约依据、候补顺序、资源占用、补位通知、确认结果和人工处理都有可核对证据。
- 资源依据
- 候补顺序
- 通知证据
- 确认结果
相关服务响应式设计
院内管理端以桌面 Web 为主，患者预约、候补、改期与提醒使用移动端。
- Desktop Web
- Mobile
相关服务移动端适配
对资源冲突、特殊号源、重复预约、无法补位和规则外人工加号提供接管入口。
- 资源冲突
- 人工加号
- 异常接管
相关服务前端开发
实现门诊预约、资源调度、候补队列、空档恢复和运营异常工作台。
- 预约工作台
- 候补工作台
- 恢复工作台
相关服务后端开发
实现号源、预约、候补、通知、确认、取消、爽约和就诊状态流转。
- 号源状态
- 预约状态
- 候补状态
- 通知状态
相关服务API接口集成
连接 HIS、医生排班、诊室资源、短信或消息服务和患者移动端数据。
- HIS
- Doctor Schedule
- Room Capacity
- Messaging API
相关服务权限控制
区分患者、门诊运营、医生、科室管理员和系统管理员权限。
- 患者权限
- 运营权限
- 医生权限
相关服务数据可视化
展示预约量、候补人数、资源利用率、空档数量、自动补位率、爽约和冲突情况。
- 预约量
- 候补量
- 利用率
- 空档恢复率
相关服务操作日志
保留预约、候补排序、空档释放、通知、确认、取消爽约、补位和人工接管审计记录。
- 预约日志
- 补位日志
- 通知日志
相关服务表单与消息通知
对重复预约、诊室维护、候补拥堵、确认超时、爽约和空档未恢复发送通知。
- 冲突提醒
- 候补提醒
- 爽约提醒
相关服务数据导入导出
支持排班、预约、候补、取消爽约、空档恢复与运营统计记录导出。
- 预约导出
- 候补导出
- 运营统计导出
相关服务HTTPS与安全配置
保护患者身份、联系方式、预约、就诊状态和院内资源数据。
- HTTPS
- 患者数据保护
相关服务性能优化
优化多科室、多医生、多诊室和高峰时段下的可用号源查询与候补补位性能。
- 高峰查询
- 资源调度
相关服务日志与异常排查
记录号源生成、预约、候补排序、补位通知、确认、取消爽约和异常处理日志。
- 应用日志
- 通知日志
- 异常排查
相关服务发布与验收
上线前核对资源冲突、候补排序、补位超时、号源恢复、通知与回滚链路。
- 发布检查
- 闭环验收
项目实际使用了哪些技术
技术信息用于说明项目是怎样实现的；真正需要判断的仍然是它是否解决了业务问题。
技术栈
HTML5
组织门诊资源矩阵、候补流程、医生诊室时间轴、取消爽约恢复和患者预约页面。
CSS3
分别支持高密度排班矩阵、流程编排画布、移动端和异常运营中心等不同界面。
JavaScript
实现号源筛选、时段选择、候补排序、自动补位流程、容量热力和异常处理交互。
响应式布局
院内运营端适配桌面浏览器，患者预约与候补适配手机。
PHP
承载号源、预约、候补、通知、取消爽约、补位和状态回写业务逻辑。
RESTful API
连接 HIS、医生排班、诊室资源、短信或消息服务与患者端。
认证与权限
区分患者、运营、医生、科室管理员和系统管理员权限。
队列与异步任务
承载候补通知、确认超时、空档恢复、爽约检测和提醒任务。
MySQL
保存患者、医生、科室、诊室、号源、预约、候补、通知和异常记录。
审计日志
保留预约、取消、候补排序、补位、确认、爽约和人工接管轨迹。
HTTPS与TLS
保护患者、预约和院内资源数据传输。
日志与监控
记录预约、候补、通知、确认、补位和异常。
输入校验
校验患者、号源、时间段、医生、诊室、候补资格和冲突条件。
技术SEO基础
维护公开案例详情的基础索引输出。
结构化数据
为公开案例提供结构化信息表达。
开发内容
需求梳理
梳理门诊前台、客服和运营每天登记预约、电话确认、改期取消、候补补位和处理爽约的重复事务。
产品与项目规划
把号源、预约、候补、取消爽约、空档恢复、通知与人工边界拆成清晰自动化流程。
信息架构
建立院区、科室、医生、诊室、排班、号源、预约、候补、通知和就诊状态层级。
UI视觉设计
针对资源矩阵、移动预约、候补流程、容量时间轴和异常恢复采用不同页面布局。
交互设计
处理预约、候补、改期、取消、空档释放、补位通知、确认超时和人工接管。
响应式设计
院内桌面管理端与患者移动端分别按真实场景适配。
前端开发
实现预约矩阵、患者移动端、候补引擎、容量管理和异常恢复页面。
后端开发
实现号源容量、资源冲突、候补排序、补位通知、超时释放和状态回写逻辑。
权限与角色
区分患者、门诊运营、医生、科室管理员和系统管理员权限。
数据看板
展示 DEMO 预约量、候补人数、资源利用率、空档、爽约和自动补位结果。
接口与第三方接入
接入 HIS、医生排班、诊室资源和短信或消息平台。
移动端适配
患者端支持预约、候补、改期、取消、提醒和确认。
HTTPS与安全配置
保护患者身份、联系方式、预约和就诊状态数据。
性能优化
优化高峰时段可用号源查询、多资源冲突检测和候补补位。
监控与日志
记录预约、取消爽约、候补排序、通知、确认和补位。
匿名与隐私保护
公开案例不展示真实患者身份、手机号、病历、真实医生排班或医疗机构运营数据。
表单与输入校验
校验患者、科室、医生、诊室、时间段、候补资格和预约冲突。
角色权限控制
限制人工加号、容量修改、特殊号源释放和异常处理权限。
操作日志与审计
记录系统自动补位与运营人员的人工接管操作。
质量验收
检查预约、候补、取消爽约、空档恢复、通知、确认、资源冲突和日志链路。
案例素材与隐私说明
客户名称、联系方式、敏感业务数据和不适合公开的界面会做匿名或脱敏处理。
匿名公开
匿名公开。页面中的患者、手机号、医生、科室、诊室、预约号、候补顺序和运营数据均为 GEXYRAL DEMO 或脱敏结构展示。
展示范围
页面只展示已经确认的项目范围、技术关系与脱敏素材，不公开客户联系方式和外部官网入口。
结果口径
案例以已完成的页面、功能、内容与交付范围为准，不使用无法独立核对的经营数字。
阅读这个案例时常见的问题
案例用于帮助判断问题和做法是否相近，具体项目仍需结合实际业务和现有系统确认。
面向门诊运营的预约与号源自动化系统。系统负责资源容量校验、预约、候补排序、取消爽约空档恢复、补位通知与确认；特殊号源、资源冲突和规则外人工加号由运营人员接管。
定制Web应用，案例展示以实际开发范围和交付界面为准。
匿名公开。页面中的患者、手机号、医生、科室、诊室、预约号、候补顺序和运营数据均为 GEXYRAL DEMO 或脱敏结构展示。
不建议直接复制。实际项目需要根据企业业务、产品结构、内容资料和转化目标重新规划。