4. 主数据模型设计方法与实战

主数据模型是医疗主数据平台的“骨架”。它决定了患者、医师、科室、药品、诊疗项目等核心对象如何被唯一识别、如何相互关联、以及在各业务系统之间如何保持一致。模型设计一旦出现偏差，后续的数据集成、共享交换和指标统计都会持续付出代价。本节围绕实体关系建模、属性定义、编码规则设计三个核心环节展开，并通过一个可落地的案例演练，把方法转化为可执行的建模动作。

一、实体关系建模：先确定“谁”和“谁与谁有关”

实体关系建模的第一步不是画图，而是从业务域中识别出真正需要作为主数据管理的实体。判断标准通常有三条：该对象是否被多个业务系统引用；是否需要在全院范围内保持唯一标识；是否具有相对稳定的生命周期。以患者主数据为例，患者实体需要被 HIS、EMR、LIS、PACS 等系统共同引用，且必须全院唯一，因此是典型主数据实体。而一次门诊挂号记录虽然也涉及患者，但它属于业务流水，不应作为主数据实体。

识别出实体后，需要明确实体之间的关系类型与基数。医疗场景中常见的关系包括：患者与就诊记录之间是一对多；医师与科室之间是多对多（一名医师可属于多个科室，一个科室有多名医师）；药品与药品分类之间是多对一。关系基数直接决定后续数据模型中的外键设计和唯一性约束。例如，若把医师与科室错误地建模为一对一，就会导致多科室执业医师无法正确表达。

在建模表达上，推荐使用实体关系图（ER 图）作为主要沟通工具。ER 图不需要一开始就追求完整，而应聚焦于核心实体及其关键关系，再逐步扩展。下图展示了一个简化的医疗主数据实体关系模型，包含患者、医师、科室、药品四个核心实体及其关系。

二、属性定义：从“有字段”到“字段可用”

属性定义是主数据模型中最容易被低估的环节。很多项目在实体关系确定后，直接按源系统字段照搬，结果导致同一属性在不同系统中含义不一致、格式不统一、无法用于匹配和合并。属性定义的核心任务是：为每个属性明确业务含义、数据类型、是否必填、是否唯一、取值范围以及来源系统。

以患者主数据为例，姓名属性需要明确：是中文姓名还是包含英文；是否允许空格和特殊字符；长度上限是多少。身份证号属性需要明确：18 位还是 15 位；是否校验校验位；是否允许为空。出生日期属性需要明确：格式是 YYYY-MM-DD 还是 YYYYMMDD；是否允许只精确到月份。这些看似琐碎的约定，恰恰是后续数据清洗和匹配算法能否有效运行的前提。

属性定义还应区分“标识属性”和“描述属性”。标识属性用于唯一识别实体，如患者 ID、身份证号、医保卡号；描述属性用于补充说明，如姓名、性别、联系方式。标识属性必须满足唯一性和稳定性要求，描述属性则允许在一定范围内变化。在模型设计中，建议为每个实体至少定义一个主标识属性和一个备用标识属性，以应对主标识缺失或变更的情况。

三、编码规则设计：让每个对象都有“身份证”

编码规则是主数据平台实现唯一标识和跨系统映射的关键。好的编码规则应满足：唯一性、稳定性、可扩展性、可读性和无歧义性。医疗主数据中常见的编码对象包括患者编码、医师编码、科室编码、药品编码、诊疗项目编码等。

编码规则的设计通常包含三个要素：码段结构、码值来源和校验机制。码段结构决定编码由哪些部分组成，例如“机构代码 + 业务类型 + 流水号”；码值来源决定每段取值来自哪里，例如机构代码取自卫健委统一编码，业务类型取自平台字典；校验机制决定如何防止编码重复或错误，例如使用校验位或数据库唯一约束。

以科室编码为例，一种可行的规则是：前 4 位为医院机构代码，中间 2 位为科室类别（01 临床、02 医技、03 行政），后 4 位为顺序号。例如“H001-01-0001”表示某医院第一个临床科室。这种规则既保证了唯一性，又便于人工识别科室类别。需要注意的是，编码规则一旦确定并投入使用，就不应轻易变更，否则会导致历史数据无法关联。

四、案例演练：从需求到可执行模型

假设某三甲医院要建设主数据平台，首批纳入患者、医师、科室三个主数据实体。以下是建模过程的关键动作。

第一步：识别实体与关系。患者与就诊记录是一对多；医师与科室是多对多；患者与医师通过就诊记录关联。确定核心实体为患者、医师、科室，就诊记录作为业务实体暂不纳入主数据。

第二步：定义属性。患者实体定义患者 ID（主键，平台生成）、姓名（必填，长度 50）、性别（必填，字典值：男/女/未知）、出生日期（必填，格式 YYYY-MM-DD）、身份证号（唯一，18 位校验）、医保卡号（唯一，可空）。医师实体定义医师 ID（主键）、姓名（必填）、执业证号（唯一）、职称（字典值）、所属科室 ID（外键）。科室实体定义科室 ID（主键）、科室名称（必填）、科室编码（唯一）、上级科室 ID（外键，可空）。

第三步：设计编码规则。患者编码采用“P + 8 位流水号”，如 P00000001；医师编码采用“D + 6 位流水号”，如 D000001；科室编码采用“机构代码 4 位 + 类别 2 位 + 顺序 4 位”，如 H001010001。所有编码由平台统一生成，源系统编码通过映射表关联。

第四步：验证模型。用三条测试数据验证：新增一名患者，身份证号重复时应被拒绝；新增一名医师，所属科室不存在时应被拒绝；新增一个科室，上级科室 ID 为空时应允许。通过验证后，模型即可进入物理表设计和接口开发阶段。

通过以上四个步骤，一个可执行的主数据模型就基本成型。需要强调的是，模型设计不是一次性工作，而是一个持续迭代的过程。随着业务变化和系统接入，实体、属性和编码规则都可能需要调整。因此，建议在平台中建立模型版本管理机制，记录每次变更的内容、原因和影响范围，确保模型演进有据可查。