MongoDB电子病历建模核心是合理运用嵌套、数组与动态字段，按临床实体拆分集合，对敏感字段启用CSFLE加密，生命体征用time-series集合优化，避免滥用$lookup。
MongoDB 建模电子病历，核心不是“怎么塞进文档”，而是用好嵌套、数组和动态字段的组合逻辑，同时守住临床语义边界。硬套 JSON 自由度反而导致后期查询崩、权限失控、审计失效。
嵌套结构要分层，别一股脑全塞进 report_data
常见错误是把整份病历当一个大 JSON 字段存，比如：{"patient":{...},"visits":[{...}], "labs":[{...}]}。表面省事，实际埋雷：
- 无法对
visits.date或labs.result_value建高效索引 - 更新某次就诊记录时，得读-改-写整个文档，放大写放大锁
- 审计日志只能记“
emr_records表更新”，看不到具体改了哪条血压值
推荐做法是按临床实体拆表（collection），但保留嵌套合理性：
// 患者主表（稳定字段强约束）
{
"_id": ObjectId("..."),
"patient_id": "P2024001",
"name": "张三",
"id_card": "11010119900307211X", // 加密存储
"gender": "M",
"birth_date": ISODate("1990-03-07")
}
<p>// 就诊记录表（每次门诊/住院一条，含嵌套 vitals、diagnosis）
{
"_id": ObjectId("..."),
"visit_id": "V20240601-001",
"patient_id": "P2024001",
"date": ISODate("2024-06-01T09:15:00Z"),
"vitals": {
"blood_pressure": "138/86",
"heart_rate": 78,
"temperature": 36.5
},
"diagnosis": ["高血压2级", "2型糖尿病"],
"notes": [
{ "role": "doctor", "content": "建议加用ARB类降压药" },
{ "role": "nurse", "content": "已测血糖，空腹6.2mmol/L" }
]
}这样既能对 date、vitals.blood_pressure 单独建索引，又避免跨文档关联——visits 和 labs 用 visit_id 关联即可。
$lookup 联合查询前先确认是否真需要实时 JOIN
电子病历里“患者全病程视图”常被当作刚需，但 $lookup 在高并发下极易拖慢响应。某三甲医院实测：单次 $lookup 关联 3 张表（patients + visits + labs）平均耗时 2.4 秒，超临床容忍阈值。
更务实的策略是：
- 医生端高频操作（如调阅本次就诊）直接查
visits，vitals和diagnosis已内嵌，毫秒级返回 - 质控/科研等低频场景才走
$lookup，且限定时间范围（如最近 30 天）+ 加allowDiskUse: true - 对真正需要宽表的报表，用 Change Stream + Kafka 同步到 OLAP 库（如 Doris），不压 MongoDB
敏感字段不能靠应用层“自觉加密”，必须用 client-side field level encryption
病历里的 id_card、family_history、genetic_info 等字段，仅靠 C# 或 Java 层加密远远不够——DBA 可直连数据库导出裸数据，备份文件也明文可读。
MongoDB 4.2+ 支持客户端字段级加密（CSFLE），密钥由 KMS（如 HashiCorp Vault）托管，数据库全程只存密文：
const autoEncryptionOpts = {
keyVaultNamespace: "encryption.__keyVault",
kmsProviders: { "local": { "key": new Buffer.from(key, "base64") } },
schemaMap: {
"emr.visits": {
"properties": {
"id_card": { "encrypt": { "keyId": [keyId], "algorithm": "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic" } },
"family_history": { "encrypt": { "keyId": [keyId], "algorithm": "AEAD_AES_256_CBC_HMAC_SHA_512-Random" } }
}
}
}
};注意两个坑：
- 确定性加密（
Deterministic）支持等值查询，但会泄露重复值分布；随机加密（Random）更安全，但只能查不能WHERE - 启用 CSFLE 后，
mongodump默认不导出密钥，需显式加--master-key-file，否则恢复失败
别忽略 time-series 集合对生命体征类数据的优化价值
监护仪、可穿戴设备产生的连续血压、心率、血氧数据，每秒多条，若全塞进普通 collection，索引膨胀快、TTL 删除不准、聚合慢。
MongoDB 5.0+ 的 time-series 集合专治这类场景：
db.createCollection("vitals_timeseries", {
"timeseries": {
"timeField": "timestamp",
"metaField": "patient_id",
"granularity": "minutes"
}
});
<p>// 写入自动按时间窗口压缩，查询天然支持 window、$dateTrunc
db.vitals_timeseries.aggregate([
{ $match: { patient_id: "P2024001", timestamp: { $gt: ISODate("2024-06-01") } } },
{ $group: { _id: { $dateTrunc: { date: "$timestamp", unit: "hour" } }, avg_bp: { $avg: "$systolic" } } }
]);实测同样 1000 万条心率数据，time-series 集合体积比普通集合小 62%，$avg 聚合提速 3.8 倍——但注意它不支持二级索引、事务、变更流，纯做时序分析用。
真正难的不是建模本身，是临床逻辑和数据库能力的咬合点：什么时候该拆 collection，什么时候该留嵌套，哪些字段必须加密，哪些聚合可以离线。这些判断没法靠文档自由度自动解决，得拿真实业务流去试错。
