Bladder Diaries 将患者日记导出为两种标准文件:供现代 EMR 摄取的 FHIR R4 Bundle (.fhir.json),以及供遗留系统与 Direct Secure Messaging 使用的 HL7 C-CDA R2.1 CCD (.ccd.xml)。 两种文件均在浏览器内构建、在本地下载,再通过接收方 EMR 的标准入口附加到病历。任何患者数据均不经由 bladderdiaries.com 服务器中转;合成 Patient 占位符在录入时由接收方的 chart-matching 工具替换为真实信息。
您刚刚完成与一位患者的 3 天日记。计算器返回 MVV(最大排尿量)320 mL、AVV(平均排尿量)145 mL、NPi(夜间多尿指数)32%、24hVV(24 小时排尿量)2.1 L、FVC(排尿频次-量图)频次 每 24 小时 9 次。剩下的问题是机械的:这些数字如何以您的编码员、护士和下次就诊都能读懂的形式落入病历?本指南覆盖两种文件格式、各自在 Epic、Cerner / Oracle Health、Athena Health、经由 Kno2 的 Prompt Health 以及遗留 EMR 中的落点,以及接收方 chart-matching 的契约。
两种文件格式:FHIR R4 Bundle 与 HL7 C-CDA R2.1 CCD
病历导入目录中的两个标准是 FHIR(Fast Healthcare Interoperability Resources)与 C-CDA(Consolidated Clinical Document Architecture)。两者皆为 HL7 标准;两者以不同的传输形态承载相同的日记数据。Bladder Diaries 同时输出两种格式,因为 EMR 生态本身是"双语"的:现代部署原生摄取 FHIR,遗留的门诊部署摄取 C-CDA,而美国联邦法规(21st Century Cures Act、ONC Cures Act Final Rule)自 2023 年起要求获证 EHR 技术支持 FHIR R4,同时保留 C-CDA R2.1 作为遗留系统的接入坡道。
FHIR R4 Bundle:现代路径
FHIR R4 于 2019 年 10 月发布,是面向资源的 JSON 标准,被现代 EMR 群体所摄取。导出以 type: "collection" 的 Bundle 形式提供,内含:
- 1 个占位符
Patient资源,在Patient.identifier上携带哨兵值REPLACE_WITH_MRN。接收方在录入时填入真实 MRN。 - N 个事件级
Observation资源:每次排尿一个、每次饮水一个、每次尿急评分一个(如有记录)、每次漏尿事件一个。接收方可见原始时间线。 - 5 个用于 MVV、AVV、NPi、24hVV、FVC 的计算指标级
Observation资源,各自携带 LOINC 加 Bladder Diaries 自定义 CodeSystem 的混合编码(依据 Phase 8 D-12)。接收方既获得一个标准编码,也获得一个精确编码。 - 1 个汇总指标的
DiagnosticReport资源,PDF 以 base64 编入presentedForm[0].data。可供人工阅读的工件始终与结构化数据并行存在。
该 Bundle 通过 HL7 R4 schema 及 US Core 6.1.0 Implementation Guide 配置文件验证。针对 US Core 进行 profile 的接收方(Epic、Cerner / Oracle Health、Athena、Allscripts / Veradigm)可看到期望字段:Patient.identifier、Observation.code、Observation.value[x]、Observation.effectiveDateTime、DiagnosticReport。未针对 US Core 进行 profile 的接收方仍可获得基础 R4 形态,足以完成录入。
HL7 C-CDA R2.1 CCD:遗留系统的接入坡道
C-CDA R2.1 于 2015 年 7 月发布,是面向遗留门诊 EMR 群体与 Direct Secure Messaging 传输所摄取的基于 XML 的文档标准。导出以 ClinicalDocument 形式提供,内含:
- US Realm Header(CONF:1198-*),涵盖 Patient 占位符、custodian 组织、文档作者及标准 CDA 框架。
- 一个
body,包含 CCD 所要求的六个章节(过敏、药物、问题、操作、结果、社会史),日记未填充的章节标注nullFlavor="NI"。 - 一个
Resultsorganizer,承载相同的五项计算指标,每个<observation>双重声明 Result Observation V3 templateId(2.16.840.1.113883.10.20.22.4.2,extension2015-08-01)。 - 一个
observationMedia元素,内联 base64 编码 PDF 报告,无需单独附件。
该 CDA 通过 HL7 SDWG C-CDA R2.1 schematron 验证(在 Phase 11 Plan 11-01 中收尾)。在接收方 EMR 早于 21st Century Cures Act 合规周期、工作流由 Direct Secure Messaging 中转,或接收方 IT 团队已停用 FHIR 入口的情况下,C-CDA 路径是正确的选择。
该选哪一种?
| 接收方 EMR | 格式 | 入口面 | | ------------------------ | ---------- | --------------------------------------------------------------------------- | | Epic | FHIR R4 | SMART on FHIR app、FHIR Inbox、常规就诊的病历附件 | | Cerner / Oracle Health | FHIR R4 | FHIR R4 入口、Bridges、Code App Gallery | | Athena Health | FHIR R4 | More Disruption Please (MDP) 入口;MDP 停用时回退到 CCD | | Prompt Health | 两者皆可 | Kno2 合作:接收方侧的归一化器同时接受两种 | | Allscripts / Veradigm | FHIR R4 | dbMotion / TouchWorks 录入 | | NextGen | C-CDA | CCD 入口;并非所有版本均已交付 FHIR 路线图 | | eClinicalWorks | C-CDA | CCD 入口 | | Greenway / Intergy | C-CDA | CCD 入口 | | 长尾遗留系统 | C-CDA | Direct Secure Messaging (DSM)、HIE 投递至收件箱 |
决策规则:若已确认接收方支持 FHIR,则发送 FHIR R4;若不确定,或接收方明确处于遗留接入坡道,则发送 C-CDA。Bladder Diaries 从相同的计算器输出同时生成两种文件,因此您可以保留两份在手,使用接收方实际接受的那一份。
一步一步:从 /entry 到病历
端到端工作流分四步。前三步在 bladderdiaries.com 的浏览器中完成;第四步在接收方 EMR 中完成。
第 1 步:在 /entry 录入日记
打开 bladderdiaries.com 上的计算器。将患者日记录入为:排尿、饮水、就寝标记,以及(若有记录)漏尿事件与尿急评分。单屏录入表对一份典型的 3 天日记约需 90 秒。患者年龄与遗尿标志用于驱动 NPi 的年龄段阈值与连续性分类。
第 2 步:在 /results 阅读指标
提交后,计算器路由至 /results。该页面渲染 MVV、AVV、NPi、24hVV、FVC,以及 IPC(Integrated Pelvic Care)4Is 分类(Fluid Imbalance、Storage Impairment、Voiding Impairment、Incontinence)。这一四象限框架回流到就诊记录的病历语言;有关将数据与鉴别诊断配对的临床纪律,请参阅膀胱日记解读支柱文章。
第 3 步:点击导出按钮
/results 顶部的导出工具条提供三个按钮:PDF、FHIR Bundle、C-CDA CCD。点击接收方 EMR 所接受的格式。文件在浏览器内构建(FHIR Bundle 为 JSON,CCD 为 XML),并以确定性文件名落入本地下载文件夹:bladder-diary-YYYY-MM-DD.fhir.json 或 bladder-diary-YYYY-MM-DD.ccd.xml。其间没有任何 HTTPS 上传至 bladderdiaries.com;提示信息显示"已下载。注:文件存储于您的本机设备,处于本计算器之外"。
第 4 步:在接收方 EMR 中附加到病历
Epic 经由 SMART on FHIR: 若贵机构已搭建面向患者的 SMART on FHIR 应用,患者可通过 MyChart 上传 FHIR Bundle。若 IT 团队已启用 FHIR Inbox,可将文件投递至此。若上述两条路径都不可用,则在常规就诊中将 FHIR Bundle 作为病历附件附加;文件以二进制形式落入病历,结构化数据可在日后重新解析。
Cerner / Oracle Health: 当 IT 启用 R4/$import 操作时,FHIR R4 入口可经此接受文件。许多机构通过 Bridges(Oracle Health 互操作层)进行路由。Code App Gallery 是第三种路径:一个 SMART on FHIR 面,文件以患者关联资源的形式上传。
Athena Health: More Disruption Please (MDP) 入口是 FHIR R4 路径,可经由 MDP 端点投递 FHIR Bundle。若您所在的 Athena 实例仅启用了遗留 CCD 入口,则改为发送 C-CDA CCD。
Prompt Health: Kno2 合作支持两种文件格式。Kno2 作为接收方侧归一化器,将 FHIR 或 CCD 转换为下游 EMR 所期望的格式。Kno2 网络中的任何 EMR 都适用同一路径。
遗留 EMR 经由 Direct Secure Messaging (DSM): C-CDA CCD 以 XML 附件形式经 DSM 传送。接收方的 Health Information Service Provider (HISP) 将其投递至接收方收件箱。对于尚未采用 FHIR 的门诊机构,DSM 路径是正确选择。
不推荐普通电子邮件作为回退方案。请优先选择接收方 EMR 的标准入口;邮件路径属于最后手段的手工流程。
隐私契约:纯客户端,无 PHI 传输
导出管线最重要的属性是:它从不传输患者数据。两种文件均在您的浏览器内,以临床医生在 /entry 录入的日记数据为输入完整构建。日记仅存于浏览器的 localStorage:无服务器端数据库,无对 bladderdiaries.com 的 HTTPS 上传,亦无对日记载荷的第三方分析。
接收方 EMR 是 chart-matching 的权威方。Patient 占位符在 Patient.identifier 上携带 REPLACE_WITH_MRN,正是为了让接收方能针对本地 MRN 命名空间运行自有匹配。接收方的 IT 策略决定匹配是自动化(系统侧的 R4/$import 配合病历挂接规则)还是人工(前台工作人员将入站文件与病历配对)。Bladder Diaries 既不查看、也不存储、亦不传输任何匹配信息。
HIPAA / GDPR 合规姿态由此设计延伸而来。Bladder Diaries 始终位于 HIPAA Covered Entity 周界之外,亦位于 GDPR 数据控制者周界之外,因为它从未在其服务器上保有患者数据。日记由临床医生的本地浏览器持有;导出文件由临床医生的本机文件系统持有;病历由接收方 EMR 持有。每一环都是本地 IT 团队及本地 Business Associate Agreement(如适用)熟知的合规面;bladderdiaries.com 这一环按设计是空的。
隐私政策对此有详细说明。纯客户端不变量是将 Bladder Diaries 隔离于监管周界之外的架构锁;文件格式目录则是仍能将结构化数据交付病历的运营坡道。
我的审计日志中出现的 2.25.* CodeSystem OID 是什么?
按 CodeSystem 审计入站文档的接收方将在审计日志中看到一个 Bladder Diaries 特有的 Object Identifier (OID),形式为 2.25.<uuid-decimal>。这是有意为之,值得简要解释,因为临床 IT 团队有时会将未知 OID 标记为安全问题。
OID 是一个相对于全局 OID 树(ISO/IEC 9834 OID 弧)注册的分层标识符。HL7 标准用 OID 明确标识编码系统:LOINC 为 2.16.840.1.113883.6.1,SNOMED CT 为 2.16.840.1.113883.6.96。每个 OID 对应一个维护代码的注册机构。
Bladder Diaries 的五项计算指标(MVV、AVV、NPi、24hVV、FVC)目前尚未被规范 LOINC 完全覆盖。LOINC 为底层容量提供了编码(例如 28604-5 Voided volume、28649-0 Urine output 24 hour),但尚未为 IPC 框架所需精确形态下的膀胱日记专属计算指标提供编码。混合编码同时输出 LOINC 编码(在存在时)与 Bladder Diaries 自定义编码(始终输出),从而让接收方既得到用于检索锚定的标准编码,也得到用于计算锚定的精确编码。
自定义 CodeSystem 需要一个 OID。与其通过 HL7 申请一个注册弧(数月起步的流程),Bladder Diaries 选择按 RFC 4122 §4.5 使用 2.25.* 弧,该规范允许任何一方将 UUID 视为十进制整数,从而派生出全球唯一的 OID。所得 OID 无需注册即唯一,可追溯,并符合 HL7 对 CodeSystem 标识符的标准。临床 IT 团队可将该 OID 记录为 Bladder Diaries 自行发行(在 OID 白名单中一次性审批),审计日志便能继续正常流转。
首次导出前请向 IT 部门询问的问题
五个问题可在首次患者导出前对齐预期。答案决定使用哪种文件格式与哪个入口面:
- 我们是否支持 FHIR R4 摄取? 截至 2026 年,大多数 EMR 部署都在某种程度上支持 FHIR R4;差异在于入口面(SMART on FHIR app、FHIR Inbox、R4/$import、厂商特定路径)。
- 我们是否支持 C-CDA R2.1 摄取? C-CDA R2.0 接收方通常可解析 R2.1 文档(模式向后兼容),但 schematron 警告可能不同。
- 我们的 SMART on FHIR 应用面是什么? 对于 Epic 与 Cerner / Oracle Health:此问题决定 FHIR Bundle 是经由面向患者的应用(MyChart)上传,还是仅经由后台 FHIR Inbox。
- 我们的 Direct Secure Messaging 地址是否可被发现? 对于遗留门诊 EMR:DSM 地址是 C-CDA CCD 的目的地。您的 HISP 可确认该地址是否已在 DirectTrust 注册表中公布。
- 我们是否与 Kno2 有合作? 对于 Prompt Health 等接入 Kno2 的 EMR:Kno2 入口是一个统一端点,可路由至多个下游 EMR。
附加项:带占位符 MRN 的入站文件采用何种 chart-matching 规则? 部分接收方按人口学信息(姓名加出生日期加性别加地址)自动匹配;其他接收方要求 Patient.identifier 完整填充。了解接收方策略可让您判断文件是自动路由,还是由接收方人员手工配对。
常见问题
给 Epic 应当发送哪种文件格式?
FHIR R4 Bundle (.fhir.json)。Epic 经由其 SMART on FHIR 应用面、IT 启用时的 FHIR Inbox,或常规就诊的病历附件摄取 FHIR R4。可通过 US Core 6.1.0 验证。
给 Cerner 或 Oracle Health 应当发送哪种文件格式?
FHIR R4 Bundle (.fhir.json)。Cerner / Oracle Health 按同一标准摄取 FHIR R4。部分机构经由 Bridges 或 Code App Gallery 路由;后台 FHIR 入口是标准路径。
给 Athena Health 应当发送哪种文件格式?
经 More Disruption Please (MDP) 入口发送 FHIR R4 Bundle (.fhir.json)。若您的 Athena 实例仅启用了遗留 CCD 入口,则改为发送 C-CDA CCD (.ccd.xml)。
给 Prompt Health 应当发送哪种文件格式? 两者皆可。Prompt Health 经由 Kno2 合作接受两种格式;Kno2 的接收方侧归一化器会转换为下游 EMR 所期望的格式。
Bladder Diaries 会将我的患者数据上传到任何地方吗? 不会。两种文件格式均完全在您的浏览器内生成。文件落入您的本地下载文件夹;不向 bladderdiaries.com 或任何第三方发起 HTTPS 上传。隐私政策对此有完整描述。
REPLACE_WITH_MRN 占位符是什么? 合成 Patient 资源上有意为之的哨兵值。您的 EMR chart-matching 工具在录入时将其替换为真实病历号。该模式既使文件得以在无任何患者身份数据的情况下发出,也让接收方按自身的 chart-matching 策略行事。
为什么我的 EMR 审计日志显示一个我不认识的 2.25. CodeSystem OID?* 那是 Bladder Diaries 的自定义 CodeSystem,按 RFC 4122 §4.5 的 OID 弧自行分配。用于规范 LOINC 尚未覆盖的五项计算指标(MVV、AVV、NPi、24hVV、FVC)。当 LOINC 存在对应编码时,每项指标也会同时携带一个混合 LOINC 编码。
我可以将同一文件发送给多个 EMR 吗? 可以。两种文件格式都与接收方无关。同一份 FHIR Bundle 或 C-CDA CCD 可并行路由至多个 EMR(例如初级保健与专科转诊)。各目的地的 chart-matching 互相独立。
结语:在下一次日记中试用
您与患者完成的下一份 3 天日记即是测试用例。打开计算器,录入日记,在 /results 阅读指标,然后点击与接收方 EMR 相对应的导出按钮。文件落入下载文件夹;通过接收方 EMR 的标准入口附加即可。临床医生此时便在病历中拥有与计算器屏幕返回相同的结构化数据,bladderdiaries.com 服务器保持为空,而符合标准的文件落到了它本应所在的位置:在病历中,与患者档案的其余部分并列。
作者:Dr. Di Wu, MD, PT(IPC 创始成员)。Bladder Diaries v5.0 里程碑交付基于标准的 EMR 互操作能力。引用标准:HL7 FHIR R4、HL7 C-CDA R2.1、US Core 6.1.0 Implementation Guide、LOINC 与 RFC 4122 §4.5(基于 UUID 派生的 OID 弧)。 图片:Vitaly Gariev 摄于 Unsplash。
