package com.ruoyi.common.core.service;
/**
* 宣教能力的对外接口（实现由 {@code ruoyi-publicity} 的常驻门面 {@code PublicityFacade} 提供）。
*
* 为什么要单独拆出来
* 宣教原本混在 {@code PatMedInhospServiceImpl#dealOutHospInfo} 里（迁移前 L331-444）：
*
* - 入院宣教（{@code in.helibrary.switch == "2"} 才执行）：科室维度 type=4、病区维度 type=5；
* - 药品宣教（仅 {@code active == "sltd"}）：按 {@code medicalCode} 拆串查
* {@code service_taskmedical}，命中则 type=0。
*
* 这两块不是"随访"而是"宣教"，所以按你的决定单独拉成 {@code ruoyi-publicity} 模块。
*
* 边界：宣教模块不建子任务
* 宣教模块只负责"决定要不要发、发什么"（读配置、判站点、拼说明），
* 真正的子任务落库与派发回调 {@code ruoyi-inhospvisit}
* （走 {@link PublicitySubtaskApi}）。这样 {@code boxedServiceSubtask}
* 的宣教分支（type=0/4/5）以及"回写 check_flag"的语义全仓只有一份实现，不会出现两份逻辑漂移。
*
* 调用方务必降级
* 取不到实现时按"没有宣教要做"处理并打 WARN，绝不能让出入院随访主流程抛异常。
*/
public interface PublicityApi {
/**
* 入院宣教：按患者所在科室（type=4）与病区（type=5）分别匹配长期宣教任务。
*
* 迁移对应：{@code PatMedInhospServiceImpl#dealOutHospInfo} L331-409。
*
* 内部行为要点（迁移时必须保留）：
*
* - 受 {@code sys_config: in.helibrary.switch == "2"} 控制，不是 "2" 时整块不执行；
* - 科室维度与病区维度是两段独立的扫描（各自查 {@code deptcheck_flag='0'} /
* {@code in_wardcheck_flag='0'}），不是一次查询分两组；
* - 患者档案为空时把标志位置 "2" 并写 {@code longTaskReason="患者基本信息为空"}；
* - 科室/病区没配长期宣教任务时置 "2" + 文案「该患者所在科室未配置入院长期宣教任务;」/
* 「该患者所在病区未配置入院长期宣教任务;」；
* - 病区分支在取已有 {@code longTaskReason} 时没有做 null 判断（迁移前 L401 直接拼接）
* —— 这是原缺陷，原样保留。
*
*
* @param config {@code sys_config: visit.early.day} 的值，可能为 null
* @return 提交处理的记录数（仅用于日志/返回，迁移前 {@code dealOutHospInfo} 固定返回 1）
*/
int dealInHospPublicity(String config);
/**
* 药品宣教（省立同德专属）：按患者的 {@code medicalCode} 逐个药品编码匹配长期宣教任务。
*
* 迁移对应：{@code PatMedInhospServiceImpl#dealOutHospInfo} L411-444。
*
* 内部行为要点（迁移时必须保留）：
*
* - 仅 {@code active == "sltd"} 时执行，其它站点直接返回 0；
* - {@code medicalCode} 为空则跳过该患者；查不到的药品直接忽略（不需要宣教）；
* - 三个数组长度不一致时取最小长度，越界时把 medicalName 置空串并打 WARN
* （迁移前 L428-433 的防御性编程，原样保留）。
*
*
* @param config {@code sys_config: visit.early.day} 的值，可能为 null
* @return 命中并处理的药品数
*/
int dealMedicalPublicity(String config);
}