* 所以：接口放 ruoyi-common，实现（{@code PublicityDataPortBridge}）留在 smartor， * 宣教模块运行时按类型查找实现。这与 * {@link VisitTaskCreateApi} / {@link PublicitySubtaskApi} 是同一手法。 * *
* 迁移对应 {@code PatMedInhospServiceImpl#dealOutHospInfo}： *
* 迁移对应 L347-353（{@code deptType="1"}、{@code serviceType="17"}）与
* L390-396（{@code deptType="2"}、{@code serviceType="17"}）。
* SQL 条件：{@code del_flag = 0}、{@code longtask = 1}、{@code dept_code = ?}、
* {@code dept_type = ?}、{@code service_type = '17'}、{@code orgid = ?}。
*
* @param deptCode 科室编码（deptType=1）或病区编码（deptType=2）
* @param deptType "1" = 科室， "2" = 病区
* @param orgid 机构ID
* @param inhospid 该条记录对应的出入院记录ID（回填进返回值，方便调用方回调 inhospvisit）
* @return 命中的任务（可能多条）；无数据返回空列表
*/
List
* 迁移对应原代码 L424-434。原实现设了三个字段：
*
* ⚠️ 越界分支是个历史笔误，但会真实影响 SQL，因此必须原样保留：
* 越界时 {@code medical_name} 被置为空串（而非 null），
* 而 SQL 条件是 {@code
* 所以本方法必须把 {@code medicalName} 也传进来 —— 不能让 Bridge 自作主张把空串转成 null
* 或反过来（那会改变 SQL 条件是否生效）。
*
* @param medicalCode 药品编码
* @param medicalName 药品名称；越界分支传空串；正常分支传 null
* @param medicalCompany 药品公司；越界分支传 null；正常分支传数组里的值
* @param inhospid 该条记录对应的出入院记录ID
* @return 命中的任务（可能多条）；无数据返回空列表
*/
List
* 迁移对应 L338-344 / L382-388。原实现取的是完整 {@code PatArchive}，
* 但宣教这一层只用到"是不是 null"（真正的患者信息填充发生在 inhospvisit 组子任务时），
* 所以这里只返回存在性。
*
* @param patid 患者档案ID（即 {@code PatMedInhosp.patid} / {@code PatArchive.id}，都是 Long）
* @return true = 存在且未删除
*/
boolean existsPatArchive(Long patid);
/**
* 把入院宣教的标志位置为给定值，并可同时写 {@code long_task_reason}。
*
* 迁移对应 L340-342 / L357-359 / L367-370（科室维度）与 L384-386 / L400-402（病区维度）。
*
*
* 迁移对应 {@code PatMedInhospServiceImpl#addSubTaskByRule} L1704-1707：
*
* serviceTaskmedical.setMedicalCode(split[i]);
* if (i < medicalCompanyArray.length) {
* serviceTaskmedical.setMedicalCompany(medicalCompanyArray[i]);
* } else {
* log.warn("...下标越界...");
* serviceTaskmedical.setMedicalName(""); // ← 注意：越界时设的是 name，不是 company
* }
*
* ⚠️ 原实现有"覆盖"与"追加"两种写法，必须区分（所以这里给的是 {@code reasonMode}）
*
*
* 因为"覆盖 / 追加"是两种不同语义，本方法用一个布尔区分，而不是让调用方拼字符串
* —— 拼字符串会让 {@code null} 前缀这种原缺陷被"顺手修掉"，那就成了行为变更。
*
* @param inhospid 出入院记录ID
* @param flagColumn {@code "in_deptcheck_flag"} 或 {@code "in_wardcheck_flag"}（只允许这两个值）
* @param flagValue 要写入的标志位值（原实现写 "2"）
* @param reason 要写入 {@code long_task_reason} 的文案；为 null 表示不动该字段
* @param appendMode true = 追加（{@code 旧值 + reason}，旧值按 inhospid 重查，不判 null）；
* false = 覆盖（直接写 {@code reason}）
* @return true = 更新成功
*/
boolean updatePublicityFlag(Long inhospid, String flagColumn, String flagValue,
String reason, boolean appendMode);
/**
* 按字段更新出入院记录（可一次写多个 flag + {@code long_task_reason} + {@code remark}）。
*
* 场景 原代码 语义 患者基本信息为空（科室/病区共用）
* {@code setLongTaskReason("患者基本信息为空")}
* 覆盖（直接赋值，丢掉旧值） 科室未配宣教任务
* {@code setLongTaskReason(旧值 + "该患者所在科室未配置入院长期宣教任务;")}
*
* 其中"旧值"是按 inhospid 重查一次拿到的追加（且不判旧值是否为 null） 病区未配宣教任务
* {@code setLongTaskReason(旧值 + "该患者所在病区未配置入院长期宣教任务;")}
* 追加（同样不判 null；旧值为 null 时会拼出 {@code "null该患者所在病区..."}） 科室处理异常
* {@code setLongTaskReason("人员入院科室处理出异常了")}
* 覆盖；且原代码不设 longTaskReason 前缀、也不重查 为什么要有这个"宽"接口
* 出院随访编排层（{@code InhospTaskOrchestrator} 的 3 个 {@code *ForPatient}）在写失败标志位时，
* 原实现有三种不同写法，写进去的列集合也不同：
*
*
* 窄接口 {@link #updatePublicityFlag} 表达不了"一次写多个 flag"，
* 所以加这个通道。调用方按原逻辑决定给哪些字段赋值，null = 不改
* （对应原 XML 每个字段各自的 {@code 为什么放在这个端口上
* 该查询服务的是出院随访的规则编排（{@code addSubTaskByRule}），
* 语义上不属于"宣教"。但本端口已经是"随访侧访问 smartor 只读配置"的统一入口
* （它已经提供 {@code findInHospForPublicity} / {@code findDeptPublicityTaskIds} 等），
* 再为一张单表加第四个端口不划算。这里在注释里写明用途，避免后人误以为它只服务宣教。
*
* ServiceTaskRule ruleQuery = new ServiceTaskRule();
* ruleQuery.setDeptcode(patMedInhosp1.getLeaveldeptcode());
* ruleQuery.setWardcode(patMedInhosp1.getLeavehospitaldistrictcode());
* ServiceTaskRule rule = serviceTaskRuleMapper.selectServiceTaskRuleByDeptOrWard(ruleQuery);
*
* 注意：该查询最多返回一条（原实现直接取单个对象）。
*
* @param leaveldeptcode 离院科室编码
* @param leavehospitaldistrictcode 离院病区编码
* @return 规则；未配置返回 {@code null}
*/
com.ruoyi.common.core.service.dto.VisitTaskRuleDto findTaskRule(String leaveldeptcode,
String leavehospitaldistrictcode);
}