医院食堂的信息化，一直有个被低估的技术难题：如何把医生开的"饮食医嘱"，结构化地流转到后厨，并最终精确送达患者餐盘。这篇文章聊聊治疗膳食的数据建模思路，以及医嘱闭环怎么设计。
先说一个核心矛盾。医嘱是自然语言，比如"低盐低脂糖尿病餐"；而配餐需要的是结构化参数，比如每日钠摄入上限、总热量、碳水化合物占比。中间缺的，是一个能把自然语言医嘱映射到营养参数的"方案库"。
设计上，通常把膳食抽象成三个层级。第一层是膳食类别（普通膳食、治疗膳食、疗程膳食），第二层是具体膳食类型（普食、软食、流食、糖尿病餐、低盐餐等），第三层是营养标签（热量、蛋白质、脂肪、钠等）。患者的一次配餐，本质上是这三个层级的一次具体实例化。
下面是医嘱流转的一个简化示意，用 Python 表达核心映射逻辑：
def match_diet(diet_order, patient): # 依据饮食医嘱 + 患者指标，匹配膳食方案 if "糖尿病" in diet_order: plan = build_plan("治疗膳食", "糖尿病餐", carb_ratio=0.5) elif "低盐" in diet_order: plan = build_plan("治疗膳食", "低盐餐", sodium_max=patient.na_limit) else: plan = build_plan("普通膳食", "普食") return plan
这个逻辑的关键，是把散落在医生、营养师、厨师脑中的经验，沉淀为系统里可复用的规则。医嘱通过 HIS 接口同步进来，经过映射，输出后厨能直接执行的配餐单。
好伙狮数字食堂这套系统的做法，本质上就是这个思路的工程化落地。营养师在后台维护方案库，医嘱自动流转，患者扫码自助预订或由医生开配餐医嘱，每一份餐都能追溯到医嘱来源。
从工程角度，这套闭环有三个要点值得注意。一是医嘱的结构化映射，把自然语言翻译成营养参数；二是方案库的标准化，让治疗膳食、疗程膳食可沉淀、可复用；三是全程可追溯，从下单到送达，数据链不断。
对医院信息科来说，营养膳食系统不是孤立的"点餐工具"，而是要能接入 HIS、支撑临床营养质控的一环。数据模型设计得是否合理，直接决定了它能不能真正跑通"医嘱到餐盘"这条链路。
技术落地的尽头，还是那句朴素的话：把医生开的医嘱，原原本本变成患者餐桌上的那顿饭。数据模型和闭环设计，都是为这件事服务的。