医嘱录入表单设计器方案：FcDesigner 如何承接医嘱类型、字典带出与剂量校验
病历系统里，医嘱录入是医生每天做得最多的动作。但「开医嘱」这件事，字段不是固定的：开一个药品，要选药品、剂量、单位、频次、给药途径，还要看要不要皮试；开一个检查，变成检查项目和部位；开一条护理医嘱，又变成护理级别和措施。类型一换，后面的字段和校验全变。
剂量还不能错。剂量超了要拦，该皮试的没标记要提醒，儿童剂量要按体重算。这些写死在页面里，每加一种医嘱类型、每调一条校验规则，都要改前端、重新发版。把医嘱单交给 FcDesigner 做可视化配置、交给 FormCreate 做动态渲染，医嘱类型和校验规则就从代码里抽出来，变成配置。
FcDesigner 和 FormCreate 在病历系统里分别干什么
FcDesigner 是基于 Vue 的低代码可视化表单设计器。实施在画布上拖组件、配校验、配联动，输出 JSON。开源即可搭出医嘱单结构，公式、角色权限、生成 SQL 等见 FcDesigner Pro 文档。
FormCreate 是动态表单渲染器。医生开嘱、护士校对、药师审核各端加载同一份 JSON。诊断、处方、收费继续由 EMR 承担，表单只管医嘱单长什么样、谁能填哪一项、剂量怎么校验。
对医嘱录入来说，这个拆分很关键：医嘱类型、字典、校验规则属于业务配置，诊疗和处方流转属于 EMR。医嘱单 JSON 存起来，各角色只决定「此刻谁来打开、以编辑还是阅读打开」。
医嘱录入真正难的不是字段多，是类型会分叉、剂量不能错
典型医嘱录入第一版通常长这样：患者信息、医嘱类型、医嘱内容。上线之后，几乎一定会出现这些变化：
- 医嘱类型从「药品」扩成检查、检验、护理、治疗、手术，每种要补不同字段。
- 药品要字典带出，不手输；输入名称带出规格、剂量单位，避免拼写和规格对不上。
- 剂量要校验：超量拦截、儿童按体重算、频次和给药途径要匹配。
- 有些药品要做皮试，漏标要提醒，否则执行端会拦。
- 医生开、护士校对执行、药师审核，能看能改的不一样。
如果这些都写死在页面里，药事部门每加一种医嘱类型、每调一条剂量规则，都要提需求找开发排期。
一张医嘱录入单怎么配
1. 先定结构：患者信息 + 医嘱类型
主表放患者信息和医嘱元信息：姓名、住院号、床号、科室、医嘱类型、开嘱时间、开嘱医生。患者信息从 EMR 带出，不重复采集。医嘱内容按类型展开，一条医嘱一个分组。
FcDesigner 支持栅格、表格布局，也支持子表单和分组。医嘱单适合「上患者信息、下医嘱内容」，医生按类型填，护士和药师阅读更清楚。开源设计器即可搭出这一层结构，后面的字典带出和剂量校验是 Pro 更合适的位置。
2. 医嘱类型一变，字段跟着变
这是医嘱录入里最不该写死在页面里的部分。
| 医嘱类型 | 需要出现的字段 | 校验要点 |
|---|---|---|
| 药品医嘱 | 药品名称、剂量、单位、频次、途径、皮试 | 剂量范围、皮试标记 |
| 检查医嘱 | 检查项目、部位、紧急程度 | 项目必选、部位必填 |
| 检验医嘱 | 检验项目、标本、采样时间 | 标本必选 |
| 护理医嘱 | 护理级别、措施、频次 | 级别必选 |
在 FcDesigner 里用条件显示和数据联动配：选「药品医嘱」才出现药品名称、剂量、频次、途径；选「检查医嘱」才出现检查项目和部位。不必为每种医嘱做一张独立页面，也不必在流程里拆分支只为了多几个字段。
3. 药品字典带出，不手输
药品名称靠手输，拼写、规格、剂量单位都会错。更稳的做法是字典带出：输入药品名首字母或编码，从药品字典里选出，自动带出规格、剂量单位、默认频次。
这用远程数据或自定义组件接到字段上：药品字典仍归药事主数据，表单只负责「检索、选中、带出」。FcDesigner 支持远程数据和自定义组件，不需要把整本药品字典复制进表单。
4. 剂量、频次、皮试的校验
医嘱的错误，大多出在剂量和频次。这些可以做成字段校验，开嘱当时就拦，而不是等护士执行或药师审核才发现。
- 剂量范围：单次剂量、日剂量与字典里的范围比较，超限提示或阻断。
- 儿童剂量：按体重或体表面积算，超出提示。
- 频次与途径：给药频次和途径要和药品属性匹配，不匹配提醒。
- 皮试标记：字典里标了「需皮试」的药品，皮试结果未填就不能提交。
FcDesigner Pro 的公式按字段引用，条件必填也能挂：选了需皮试的药品，皮试结果字段必须出现且必填。分寸要守：公式负责填报当时的可见校验和提示，最终用药安全仍归医生和药师。表单设计器不是合理用药系统，但能把「剂量超限」「皮试漏标」这类可标准化的环节挡在提交之前。
5. 同一张单，医生、护士、药师三种样子
医嘱单最容易被做成「所有人都能改」，然后靠口头约定。更稳的做法是同一份 JSON，按角色控制显隐、禁用、必填。FcDesigner Pro 支持预置权限树和角色树，运行时注入 $roles、$permissions。
| 角色 | 能看见 | 能编辑 | 打开方式 |
|---|---|---|---|
| 开嘱医生 | 患者信息、医嘱内容、校验提示 | 提交前可改；停止后按节点开放 | 编辑 |
| 执行护士 | 医嘱内容、频次、执行状态 | 只开校对和执行标记 | 阅读模式 + 执行区 |
| 药师 | 药品医嘱、剂量、皮试、审核结论 | 只开审核相关字段 | 阅读模式 + 审核区 |
阅读模式是这一步的配套：护士和药师不复制详情页，同一套规则切换查看态。设计器里的「组件操作权限」和运行态的「角色权限」要分开配，别把「只有管理员能设计医嘱单」当成「护士不能改剂量」。
6. 医嘱状态流转，落到库表
医嘱有生命周期：新开、校对、执行、停止。状态流转是 EMR 的事，但表单要能按状态决定哪些字段可编辑——停止的医嘱全只读，执行中的医嘱只开放执行标记。
设计稿要落到库表，FcDesigner Pro 可按字段生成建表 SQL，医嘱主表一张、按类型展开的内容各一张，生成结果人工确认后再执行。JSON 按版本存：哪条医嘱用的是哪一版规则，要能回放。
这条链路怎么接到现有 EMR 里
不改 EMR，先把医嘱单从代码里拆出来。
药事和临床先出规则，再进设计器。 医嘱类型枚举、药品字典、剂量范围、皮试标记、谁能改哪项，写成一页规则。规则不定，拖组件只会把混乱可视化。
用 AI 表单助理出第一版，人再改。 把「医嘱录入：患者信息 + 按医嘱类型联动 + 药品字典带出 + 剂量校验」描述给 AI 表单助理，生成初始结构，实施再补校验、角色、公式。
JSON 入库，各角色只决定打开方式。 医生节点编辑态，护士节点执行区，药师节点审核区。患者信息通过远程数据从 EMR 带出，医嘱结果也可以回写 EMR。
标准组件先用满，个性字段再扩展。 下拉、数字、日期、单选、子表覆盖医嘱主体；药品字典带出、皮试标记、医嘱编号用自定义组件或远程数据接入。「药品医嘱」可以沉淀成模板，避免每次从零搭。
先验证开源，再决定 Pro。 开源 FcDesigner 已能拖拽、校验、布局、输出 JSON；剂量公式、角色权限、生成 SQL、AI 助理，是把医嘱闭环收干净时更常落到 Pro 的能力。
这样做之后，临床侧真正少掉的工作
开发不再为「加一种医嘱类型」或「调一条剂量规则」开迭代。类型、字典带出、校验、提示在设计器改，JSON 发布后下一次打开即生效。
药事部门可以自己定字典和校验规则，画布上当场能试：选需皮试的药品，皮试结果出不出来；剂量超限，提示拦不拦。
开嘱、校对、审核不再分叉成三套页面。阅读模式让各角色共用规则，减少「医生开的是这一版、护士看到的是另一版」的事故。
医嘱录入不再靠手输药品名。字典带出减少拼写和规格错误，剂量校验把明显错误挡在开嘱当时。
以上是典型场景里可预期的分工变化，不是某家客户的实施报告。具体能少几人天，取决于你们现在有多少医嘱类型写在代码里。
常见问题
FcDesigner 能替代 EMR 或医嘱系统吗？
不能。FcDesigner 管医嘱单长什么样、谁能填哪一项、剂量怎么校验。诊断、处方流转、医嘱状态、收费仍是 EMR 的能力。两者通过「节点打开哪一版 JSON、用编辑还是阅读」衔接。
医嘱录入为什么不适合写死在页面里？
医嘱类型、药品字典、剂量规则会随药事规范持续调整。写死在页面里，每次变化都要改前端、发版。用表单设计器后，变化落在 JSON 配置上。
药品字典带出怎么做？
药品字典归药事主数据，用远程数据或自定义组件接到字段上：输入编码或首字母检索、选中带出规格和剂量单位。设计器管字段和校验，字典数据仍归药事系统。
剂量校验和合理用药系统有什么区别？
剂量校验是标准化的规则：范围和体重算法，可以配置化。合理用药涉及相互作用、配伍禁忌等复杂判断，仍归专业系统。表单设计器做前者，不碰后者。
只用开源版能不能做医嘱录入？
能做出可填、可校验、可提交的医嘱单，接入现有 EMR。剂量公式、按角色藏字段、生成库表这些一次配齐，需要看 FcDesigner Pro 的对应能力。
如果你正在给病历系统换医嘱录入，不必先上全量低代码。拿药品和检查两类高频医嘱，在 FcDesigner 里搭出患者信息加医嘱分组，把类型联动和剂量校验配通，用 FormCreate 接到开嘱节点上。跑通这两类，再决定哪些医嘱收进同一份 JSON，哪些必须分版本。