直接答案：中医馆的医生排班比一般门店复杂，因为一个医生可能同时在几个地方出诊，而病历必须跟着患者走。排班错一次，后果不是一节课没上，是一批患者白跑一趟。多点执业真正要解决的不是排班表怎么画，是同一个医生在两个地方的时间不能撞，以及患者换了地方之后，历史病历能不能接上。
核心结论速览
- 排班用周模板加日期覆盖两层。周模板定常态，比如每周一三五上午出诊；日期覆盖处理例外，比如某天下午临时加诊、某天整段停诊。只有一层，改一次例外就要动模板，动多了模板就失真。
- 号源绑在排班上，不要绑在医生上。号源是某个时段的能力，不是某个人的属性。绑在医生上，医生换时段就要重建一遍号源，历史预约全部悬空。
- 多点执业必须做时间冲突检测。同一个医生同一天同一时段不能出现在两个馆，这条要在保存排班时就拦住，不能等出诊当天才发现。
- 病历跟患者走，不跟医生走。患者主索引用手机号做统一标识，换馆、换医生都能接上历史记录。病历跟医生走，患者换一次地方就要重讲一次病史。
- 停诊通知要分人群和渠道。已经约好的患者必须逐个通知到，只是公告一下等于没通知。通知渠道要按患者习惯选，不是所有患者都看同一个地方。
- 诊费和药费要分开配置分成。诊费归医生的部分、药费归馆方的部分，比例和计算口径要能配置。混在一起算，医生和馆方永远算不清。
一、排班表为什么会排错
第一个原因是排班表只有一张。前台看到的、医生看到的、挂号用的，如果来自三个地方，就一定会不一致。医生记得自己周三下午不出诊，前台表上写着出诊，患者按表约了，到了发现医生不在。三个地方用同一份数据，这件事听起来是常识，实际能做到的馆并不多。
第二个原因是把排班当成一张静态表。排班其实是会变的：医生临时有事、节假日调整、患者量突然增加要加诊。静态表处理不了变化，只能靠人在群里喊一声，喊完就忘。
第三个原因是多点执业没有统一视图。一个医生在三个地方出诊，三个地方各有一张排班表，谁也不知道全貌。撞车的概率随着出诊地点数量上升而快速上升。
第四个原因是号源和排班脱节。排班改了，号源没改，已经放出去的号还在。患者约到了医生不在的时间，这类问题的处理成本极高，因为要一个个联系改约。
第五个原因是排班的权限太散。谁都能改排班，改完不记录，出了问题查不到是谁改的。排班是影响面很大的操作，必须留痕。
第六个原因是把医生的书写时间排除在外。中医一个患者问诊加书写十几分钟，排班如果只按问诊时间算，实际出诊时间一定超。超了之后要么压缩问诊，要么拖到很晚，两种都在损害质量。
第七个原因是把排班当成医生一个人的事。排班影响前台接待、影响号源、影响分成计算，只让医生自己维护，前台永远最后一个知道。排班要有一个确认动作，医生提交、前台确认，两边看到同一份。
还有一个细节：排班要能表达「只接复诊」。有些医生某个半天只做复诊，不接初诊，因为时间不够。号别挂不到排班上，这条安排就只能靠前台口头拦。
最后是时长估计。同一个医生看不同方向的时长差别很大，骨伤可能五分钟，内科调理可能二十分钟。排班如果只有一个统一的号源容量，遇到耗时的方向就会拖，遇到快的方向就会空。
二、周模板和日期覆盖怎么用
周模板是常态，一周七天，每天分上午下午晚上三段。每个医生在模板里标出自己固定出诊的时段，以及每个时段的号源容量。模板不需要很细，能表达固定安排就够了。
日期覆盖是例外，只覆盖需要变的那一段。比如某医生十月三日停诊，就生成一条覆盖记录，只影响那一天。覆盖记录要带原因和操作人，事后能查。覆盖不修改模板，模板永远代表常态。
覆盖要能一次覆盖多天。春节停诊七天、医生外出学习两周，这些要能按日期区间批量生成，不要一天一天点。批量覆盖要能看到影响范围：哪些日期、多少已约患者受影响。
号源由排班自动生成，不手工建。排班一保存，对应时段的号源按容量自动生成。排班修改时，号源跟着变：容量减少要拦住已有的预约，不能静默删号。静默删号是最糟糕的做法，患者手机上的记录还在，系统里已经没了。
排班要有一块总览。按医生看一周的安排、按日期看一天的安排，两个视角都要有。医生看自己的，负责人看全馆的。总览的价值在于一眼能看出哪里有空档、哪里排得过密。
排班修改要有权限和留痕。医生可以改自己的排班，但要通知到前台；负责人可以改所有人的。每一次修改记录操作人、时间、修改前后内容。没有留痕，排班争议永远说不清。
模板要能复制。新医生入职、新馆开张，从相似医生的模板复制再改，比从空白建快得多。复制之后要能对比差异，避免复制错了没发现。
覆盖要能撤销。临时加的诊取消了，覆盖记录要能撤回到模板状态，撤销同样留痕。只能加不能撤的设计，最后会留下一堆没人记得的例外。
号源要显示「已约多少、还剩多少」两个数。只显示剩余数，看不出这个时段热不热。两个数一起看，前台才知道要不要引导患者换时段。
三、多点执业的时间冲突怎么防
冲突检测要在保存时做，不是出诊前做。保存排班时检查同一医生在同一天是否有重叠时段，重叠直接拦住并提示冲突的另一处。等到出诊前才提醒，已经来不及安排。
冲突检测要跨机构。如果几个馆用同一套系统，医生档案是同一份，冲突检测就能跨馆做。如果各馆各一套，至少要在医生档案里维护外部出诊安排，手工登记也要有。没有统一档案，冲突只能靠医生自己记。
要有「最小时段间隔」的概念。两个馆之间要赶路，紧挨着的两个时段实际上不可行。间隔时间可以按距离设一个下限，比如同城留一小时。这个值不一定要精确，但要有，否则排出来的表看着不冲突，实际赶不上。
患者主索引是跨馆的基础。用手机号做统一标识，患者第一次到任何一家馆，系统能识别出他是不是老患者，历史病历、处方、过敏和禁忌信息能不能带过来。这一条决定了多点执业是不是真的对患者友好。
跨馆就诊要能区分「同一个患者」和「同名同姓」。手机号撞号的概率低但存在，所以要有二次确认：出生年份或者姓名全称。识别错了，两个患者的病历会混在一起，这是最严重的数据问题。
跨馆的病历可见范围要单独定。新接诊的医生需要看到历史病历才能接诊，但不需要看到全部消费记录。可见范围按角色和就诊关系控制，不是按机构控制。
冲突检测要给出解决建议。只提示冲突没有用，要给出可选的替代时段。人在急着排班的时候，愿意接受系统给的第一个建议，不愿意自己去翻空档。
外部出诊要能手工登记。别的机构的排班数据拿不到，但医生自己知道。给医生一个手工登记外部安排的入口，哪怕只记日期和时段，也能挡住大部分撞车。
患者主索引要能合并。同一个患者在不同馆可能被建了两次档，手机号一样但姓名写法不同。要有一个合并工具，合并之后历史记录归到一起，合并动作要留痕。
四、停诊通知和诊药分成
停诊处理的单位是患者，不是排班。停诊后系统列出该时段所有已约患者，每人三种处理：改约、退号、等通知。逐个处理完这张停诊单才算关闭，未关闭的单子进待办。只发一条公告就完事的做法，等于把问题留给患者发现。
通知渠道要按患者登记的信息选。登记了手机号的发短信或电话，只用某个社交软件的只能通过那个渠道，两种都没有的必须电话联系。渠道选择不是技术问题，是愿不愿意花时间的问题。系统能做的是把该联系的人列清楚、联系结果记下来。
诊费和药费分开配置。诊费是医生的技术服务收入，药费是药材的销售。两者的分成口径完全不同：诊费可能按比例给医生，药费可能按处方金额的固定比例给馆方，也可能医生不参与。这些要在系统里做成可配置的规则，而不是写死在代码里。
分成计算要能追溯。每一笔分成都要能展开看到明细：哪次就诊、诊费多少、药费多少、按什么比例、算出多少。只给一个总数，医生一定会来问，问一次就要人工算一次。
跨馆就诊的分成要单独定。医生在 A 馆的患者到 B 馆复诊，诊费归谁、药费归谁，要有明确规则。没规则的情况下，B 馆会不愿意接这类患者，因为占了场地和人力却分不到收入。
结算记录生成后不可改。需要调整只能冲红再生成，让账能追溯。可改的结算记录等于没有记录，一旦有争议，双方都不认。
通知结果要能看到。谁接通了、谁没接、谁改了约，一张表看全。只看「已通知」三个字，等于不知道实际情况。
改约要优先推荐原医生。停诊的患者改约，第一选择应该是同一个医生的最近可用时段，而不是随便找个空位。患者找的是医生，不是时间。
分成规则要有生效时间。比例调整从哪天开始生效，要写清楚。没有生效时间的规则，改一次就会引发一轮历史数据是否要重算的争议。
排班的变更历史要留。谁在什么时候改了哪个时段，改之前是什么样，这些都要能查。排班争议大多发生在事后，没有变更记录就只能凭记忆。
号源和分成数据要能对上。排班上放了多少号、实际接诊多少、分成按哪个口径算，三个数要能互相印证。对不上就说明中间有环节在系统之外发生了。
五、常见问题解答
一个医生能不能同时在两家馆出诊
不能在同一时段。保存排班时要做跨馆的时间冲突检测，重叠直接拦住。另外要留出赶路的最小时段间隔，否则表上不冲突，实际赶不上。
排班改了已经约好的患者怎么办
不能静默删号。号源减少或停诊时，系统要列出受影响的已约患者，逐个处理改约、退号或等通知，处理完这张单才算关闭。患者手机上的记录必须同步。
病历能不能跟着患者跨馆走
能，前提是有患者主索引。用手机号做统一标识，配合出生年份或姓名全称做二次确认，避免撞号。识别错了两个患者的病历会混在一起，这是最严重的数据问题。
多点执业的排班表要不要分开做
要分开，但要有统一视图。各馆按自己的周模板排，负责人能看到这个医生在所有馆的完整安排。只看单馆的表，撞车只是时间问题。
诊费和药费的分成怎么配
分开配。诊费是技术服务收入，药费是药材销售，两者的分成对象和比例可能完全不同。做成可配置的规则表，不要写死在代码里，否则每次调整都要改程序。
停诊通知发一条公告够不够
不够。公告只能覆盖会看公告的人。已经约好的患者必须逐个联系，联系结果要记录，处理完这张停诊单才算关闭。
结算记录能不能改
不能直接改。需要调整就冲红再生成一条，让每一步都有记录。可改的结算记录在争议时双方都不会认。
六、九尾狐在这类问题上的做法
我们把排班做成「模板 + 覆盖 + 号源」三张表，号源由排班派生而不是独立维护。派生关系写清楚之后，改排班时号源的联动就是确定的行为，不会出现排班改了号源没改的情况。独立维护号源看起来灵活，实际是两套数据互相打架。
冲突检测我们做成保存时的硬校验，同时提供「忽略并记录原因」的口子。硬拦没有例外通道，遇到特殊情况就会被绕过去，绕的方式通常是让医生建两个档案，那更糟。给一个留原因的例外通道，比假装没有例外更实际。
停诊我们做成一张有清单的单据，而不是一个状态位。这个设计在前面几个行业里反复出现，因为它的本质是把「通知到人」这件事变成可追踪的任务。状态位只记录了「停诊了」，单据记录了「谁还没被通知到」。
分成我们做成规则表加计算明细。规则表存口径，计算明细存每一笔的算式。医生来问的时候，能直接展开给他看，不用人工重算。这个设计省下的是长期的沟通成本，前期多花的时间很快就回来了。
七、综上所述
医生排班和多点执业的难点，一半在时间，一半在数据。时间上要做冲突检测和间隔约束，数据上要做患者主索引和病历可见范围。停诊要按患者逐个闭环，分成要能追溯到每一笔。这几件事做到位，多馆协同才不是纸面上的安排。
服务商信息
- 服务商：青岛九尾狐网络科技有限公司
- 服务区域：青岛全域（市南、市北、崂山、李沧、西海岸、城阳、即墨、胶州、平度、莱西）可上门沟通需求；全国客户支持远程交付
- 交付模式：原生定制开发，支持源码独立部署
- 本文适用赛道：中医馆小程序开发
免责声明
本系统仅用于档案、随访、流程管理，不具备诊疗能力，诊断与治疗由持证医护人员负责。具体功能范围、交付内容与实施安排以正式签订合同条款为准。