package com.ruoyi.common.core.service;
|
|
/**
|
* 出入院随访模块<b>下沉给宣教模块</b>的最小接口：生成一条"宣教类"随访子任务。
|
*
|
* <h3>为什么需要它（以及为什么放 ruoyi-common）</h3>
|
* 宣教（{@link PublicityApi}）与出入院随访是<b>互相调用</b>的：
|
* <ul>
|
* <li>{@code ruoyi-inhospvisit} 的 {@code dealOutHospInfo} 要调 {@link PublicityApi} 决定"要不要宣教"；</li>
|
* <li>{@code ruoyi-publicity} 判定"要发"之后，又要把建子任务交回 inhospvisit
|
* （这样 {@code boxedServiceSubtask} 的宣教分支 type=0/4/5 全仓只有一份实现）。</li>
|
* </ul>
|
* 若 publicity 直接依赖 inhospvisit，就形成 {@code inhospvisit <-> publicity} 双向依赖 → Maven 构建失败。
|
* 所以把"宣教模块唯一需要的那一个能力"下沉成本接口放在 ruoyi-common，
|
* 两边都只依赖 ruoyi-common，运行时按类型查找实现（取不到就降级）。
|
*
|
* <h3>和 ruoyi-inhospvisit 里那个同名能力的关系</h3>
|
* 本接口只有 1 个方法，是给宣教模块用的<b>最小面</b>；
|
* {@code com.ruoyi.inhospvisit.api.InhospVisitApi} 是完整契约（含出院随访主扫描、任务组轮次滚动等），
|
* 供直接依赖该模块的 smartor / ruoyi-quartz 使用。
|
* 两者由同一个常驻门面 {@code InhospVisitFacade} 一并实现，因此按任一种类型查找都能拿到同一个 Bean。
|
* <p>
|
* <b>刻意不做继承</b>：若让完整契约继承本接口，本接口就会"声称"自己也有那些方法，
|
* 而按本接口编译的代码运行期却拿到完整实现 —— 这正是满意度模块"门面把自己当实现"
|
* 那类假象的翻版，会掩盖配置错误。
|
*
|
* @see PublicityApi 调用方
|
*/
|
public interface PublicitySubtaskApi {
|
|
/**
|
* 为某个患者生成一条"宣教类"随访子任务（type=0 药品宣教 / type=4 入院科室 / type=5 入院病区）。
|
* <p>
|
* 这是给 {@code ruoyi-publicity} 用的：宣教模块判定"该发"之后，
|
* 把建子任务这件（含 {@code boxedServiceSubtask} 的宣教分支、回写 check_flag）交回 inhospvisit。
|
*
|
* @param taskid 命中的长期宣教任务ID
|
* @param patid 患者档案ID
|
* @param inhospid 出入院记录ID
|
* @param type 0=药品宣教（出院维度）/ 4=入院科室 / 5=入院病区
|
* @param config {@code sys_config: visit.early.day} 的值，可能为 null
|
* @return true = 已生成（或按原逻辑被标记为不执行）
|
*/
|
boolean generatePublicitySubtask(Long taskid, Long patid, Long inhospid, int type, String config);
|
}
|
