这家口腔诊所开在常州钟楼区，已经经营了六年。前台是个姓周的小姑娘，每天上午的固定动作是翻三样东西：电话座机上的未接来电、微信里患者发来的消息、以及一本厚厚的纸质预约本。
预约本上密密麻麻写满时间，但经常出状况。比如上周三下午，一位做根管治疗的患者提前到店，前台一查，本子上没有记录。患者急了，说是上周微信上联系过的，前台翻聊天记录，发现消息确实在，但当时忙，忘了写进本子里。还有一次更麻烦，医生临时接到外派义诊的通知，前台下不了班，得挨个打电话通知下午的三个预约患者改时间。电话打了一个多小时，有个患者一直没接，只能微信留言加短信提醒。
这些事听起来不大，但每天都在发生。诊所负责人朱医生自己也头疼：患者档案散在纸质病历和微信聊天里，谁该复查了、谁戴了牙套多久没来调整，全凭医生和前台的经验记着。朱医生想做个小程序，把预约和档案这两块理顺。
开发方是常州飞傲软件科技有限公司，本地团队，上门聊了两次需求。第一次面谈在诊所楼下的咖啡店，朱医生整理了一整页需求，写了十二项功能，包括预约、在线支付、会员储值、积分商城、电子病历、复诊提醒、医生排班、术后随访，甚至还想加个科普资讯板块。开发方把报价和周期算出来，朱医生看了一眼，沉默了几秒，说：“预算没那么多，你们看哪些先做。”
这是项目里第一个实际调整。双方坐下来重新排优先级，最后定了两期：第一期上预约、医生排班、复诊提醒、电子病历，这些是日常运营里最疼的环节；付费和会员体系挪到二期，等技术团队把基础数字档案跑顺了再加。
预约功能初期设计得很简单，就是一个表单页面，患者选择科室、医生、时间，提交后在后台生成一个待确认的记录。但第一版内部测出来发现一个问题：诊所上午和下午的号源数量不一致，周末和周三的医生排班也不一样，后台手动同步排班表容易出错。开发方改了一版，把排班做成独立配置模块，前台在后台提前一周录入下周排班，小程序端自动按排班开放可预约时段，患者约满后该时段直接变灰显示，也避免冲突。以前前台靠本子记、靠脑子排，现在后台统一管理，每周花几分钟录入一次就行。
复诊提醒这个功能，场景很具体。正畸患者是最需要定期调整牙套的，但很多人一忙就忘，偶尔过了一两个月才想起来。以前护士小钱每个月需要手动翻一遍纸质病例，逐个打电话提醒复诊。她一个人管着两百多个正畸患者的记录，每次集中通知要打两三天电话，还经常打不通。现在小程序里，数据库里给每个患者设置了复诊周期参数，到了时间系统自动发服务通知提醒。小钱只需要在后台调参数，比如某患者下次复诊是三个月后，在前台操作界面点一下就行。上线一个月后，正畸患者按时到诊率比之前明显上升。
电子病历这一块，原来最担心的是医生操作麻烦。口腔诊所的医生每天要看十几个病人，病历如果做得太繁琐，没人愿意用。开发方把录入页面设计得精简，医生只需在复诊时勾选几个选项，比如“疼痛程度”“处理内容”“下次复诊间隔”，用下拉框和单选按钮完成，不强制填长文字。患者的历史记录会按时间自动排列，医生接诊前扫一眼，之前的治疗情况就清楚了。朱医生说，这套流程以前靠人翻档案，现在后台一键调出，问诊快了不少。
项目在2026年3月中旬上线，用了大约五周时间。朱医生后来对开发方说，最满意的是前台小周终于不用每天对着预约本画圈圈了。当然也有取舍，原本设想的在线支付和会员储值到现在还没上，因为诊所现有的线下收银系统还能用，绑定起来又多一笔预算，就先搁置了。小程序的源码在交付时同步给了诊所，不存在后续被锁死的情况。
这个案例里，开发方是常州飞傲软件科技有限公司，整个对接过程是一对一专人跟进，需求有变动直接微信群里沟通，不用走复杂流程。项目从签约到交付，中间改了三次排班模块的设计，没有产生额外费用，合同里也写明了。本地团队的好处在这里体现出来——有问题可以约在下班后直接去诊所当面调，效率比远程沟通高一大截。
FAQ：
问：小程序后台的预约记录，诊所能自己调整吗？比如手动加号、调换医生？
答：能。排班和预约分开管理，前台在后台可以手动添加或取消预约，加号后小程序端会同步显示。不需要开发方介入，配置权限在诊所自己手里。
问：患者的病历资料存在哪里？换电脑或者换前台人员，数据会丢吗？
答：数据存在服务器端，诊所后台用账号密码登录，任何电脑都能访问。病历和预约记录都支持导出，交付时源码也在诊所手里，数据所有权没有疑议。