主题 4.6 — 电子病历与临床系统

电子病历是一家现代医院的运营支柱,因此你如何选择、配置、部署并持续优化它,是一项将塑造未来十年照护的临床安全、劳动力生产力与公共资金决策——而不是一次性的 IT 采购。

为什么这在医疗与照护领域很重要#

电子病历(EPR)是如今大多数临床工作流经的单一系统。医生与护士阅读它来了解一位患者出了什么问题,下达会改变患者病程的检验与用药医嘱,并记录他人在数小时或数年后将依赖的决策。当电子病历良好时,它让安全的事情变成容易的事情:正确的剂量、正确的过敏警告、结果摆在需要它的人面前。当它糟糕时,它会把临床医生埋没在点击之中,把信号隐藏在噪音里,并以没有人预期的方式悄悄地重塑临床行为。

这就是为什么一个电子病历项目与你将运行的几乎任何其他技术项目都不同。它触及每一位临床医生、每一个班次、每一位患者,而且正是在照护交付的那一刻。一套配置糟糕的医嘱集,可能在整个医院传播一个剂量错误;一次搞砸的上线,可能让每一次问诊延长数月;一次丢失了过敏史或复苏抢救状态的数据迁移,可能致人死命。这份记录也是一份法律与监管成果文件——关于做了什么、为什么做的医疗法律说明——因此它的完整性、可用性与可审计性承载着法定分量(见主题 1.6——临床安全与风险管理,以及主题 1.7——信息治理、数据保护与网络安全)。

利害关系也是财务性与战略性的。一个电子病历是一家信托机构一生中所做的最大单笔投资之一,常常在其生命周期内耗资数千万英镑,并把机构锁定在一个供应商与一种工作方式上长达许多年。在国家层面,NHS England 的一线数字化项目已经让核心电子病历成为每一个急症、社区、精神健康与救护车提供者的基线期望,把资本资金与数字成熟度挂钩。把电子病历做对,如今与把运营模式做对密不可分(见主题 1.1——运营模式)。把它做错,会浪费公共资金,耗尽临床医生的精力,并可能让一个机构倒退数年。

核心概念#

一份电子健康记录(EHR)是一位患者健康信息的系统化数字集合。在英国的实践中,近义词电子病历(EPR)通常指的是一个提供者机构的核心临床系统——临床医生在照护现场使用的记录与工具。围绕着它的是一系列临床系统,历史上被称为医院信息系统(HIS):追踪入院、出院、转科与门诊预约的患者管理系统(PAS);临床文档;结果报告;以及手术室、产科、急诊与重症监护的专科系统。

计算机化医嘱录入(CPOE,也称为医嘱通信或"order comms")是由下医嘱的临床医生直接以电子方式录入临床医嘱——检验、用药、转诊——取代纸质与电话。一个电子病历大部分的安全价值都是在这里实现的,因为医嘱可以被检查、标准化为医嘱集,并自动路由。CPOE 与电子处方及临床决策支持紧密耦合,后者在工作流程中呈现警报与指导(见主题 4.7——临床决策支持与临床信息学,以及主题 4.8——电子处方与药品管理)。

两个设计选择定义了一个电子病历项目。第一个是配置 vs 定制:配置使用供应商所支持的杠杆(构建屏幕、医嘱集、角色、规则)来调整产品,并保持在受支持的升级路径之内,而定制则编写定制代码或构造供应商未曾设想的结构,这很强大,但在每一次升级时都会变成一项维护与安全负债。第二个是部署形态:大爆炸式采用(直接换装,整个机构在一个日期切换)与按顺序让场所或功能上线的分阶段或模块化推广。每一种形态都在风险集中度与集成复杂性及"大爆炸疲劳"之间做出取舍。

这个项目既由临床医生、也由技术人员领导。首席医疗信息官(CMIO,在英国通常是首席临床信息官,CCIO)与首席护理信息官(CNIO)是拥有系统临床设计、安全性与采纳权的高级临床医生——是一线与构建之间的桥梁。他们的学科是健康信息学:应用信息与计算机科学来改善临床信息的管理与使用。

有几个系统层面的概念反复出现。数据迁移是把历史记录从遗留系统一次性转移到新电子病历中——技术上是常规操作,临床上却充满风险。一个集成引擎(接口引擎)使用诸如 Health Level Seven(HL7)与 FHIR 这样的标准在系统之间路由消息(见主题 4.3——互操作性与数据标准)。一个健康信息交换或共享照护记录,让一个地区的各机构能够读取彼此的记录。而由于这份记录是安全攸关的,宕机流程——电子病历不可用时的业务连续性计划——是系统的核心部分,而不是事后补充(见主题 3.9——业务连续性与灾难恢复)。数字成熟度通常用来自医疗信息与管理系统学会(HIMSS)的电子病历采纳模型(EMRAM)来基准化,这是一个 0 到 7 的临床系统能力量表。

最佳实践#

1. 让临床领导力成为项目的支柱,而不是被咨询者。 一个电子病历的成败,取决于临床医生是否拥有它。任命并恰当配置资源给一位拥有真正权力与被保护时间的 CCIO 与 CNIO,在每个专科与病房建立一个"数字化倡导者"网络,并给予临床设计领导对构建与配置的真正决策权。失败的模式,是一个技术主导、通过偶尔的工作坊"接触"临床医生的项目;成功的模式,是把执业临床医生当作他们每个班次都要使用的系统的共同作者来对待。

2. 配置到受支持的产品;定制时要睁大眼睛。 每一次定制的改动都是你在每次升级时要偿还的债务,也是一个没有人重新测试的隐藏临床安全面。默认在供应商支持的模型内进行配置,在安全的地方采用产品经过测试的内容与医嘱集,把真正的定制保留给少数几个真实临床或法定需求无法以其他方式满足的地方——每一处都要有文档记录、经过风险评估,并有负责人。要抵制在新系统内重建你旧系统的冲动;"让它像纸质表格一样运作"正是机构花钱买了一个现代电子病历、却继承了自己遗留问题的方式。

3. 刻意地选择部署形态,并为你所选择的那种降低风险。 大爆炸式把风险集中在一个日期上,但避免了并行运行两个系统、并对它们进行集成的痛苦与成本;分阶段或模块化推广分散了风险,让你能够学习,但会倍增接口、双重运行与变革疲劳。依据你的风险偏好、集成复杂性,以及机构能一次吸收多少临床中断来决定(见主题 8.0——分阶段引入创新)。无论你选择哪一种,都要不成比例地投资于切换过程:经过演练的实战演习、一个指挥中心、前几周大规模的现场巡回支持,以及一个清晰的、经过演练的回滚方案。

4. 把数据迁移当作一项临床安全练习,而不是一项数据管道任务来对待。 决定哪些历史数据迁移进新记录——并核验它是否正确抵达——正是迁移通过遗漏的过敏史、不匹配的标识符,或被截断的用药史来伤害患者的地方。明确商定什么自动迁移、什么被总结、什么被留在遗留系统的只读档案中,以及临床医生将如何触及它;然后在上线之前核对并验证迁移数据,并获得临床签核。绝不要因为加载运行时没有报错就假设一个字段被干净地映射了——一次技术上成功的迁移依然可能在临床上是错误的(见主题 4.9——数据质量与主数据管理)。

5. 为生产力低谷做好规划,并为随之而来的优化提供资金。 几乎每一次电子病历上线之后都会有一段吞吐量下降的时期,员工要学习这个系统,假装并非如此的机构既会损害安全,也会损害士气。在上线前后刻意地减少择期活动,保护培训时间,并与董事会一起设定现实的恢复轨迹,这样这个低谷就是一个有计划的事件,而不是一场危机(见主题 8.1——变革管理)。至关重要的是,要为之后的持续优化提供预算与人员:一个电子病历的价值是在上线之后的数年里,通过对工作流程、医嘱集与警报的迭代调优实现的——这是一门产品学科,而不是一个在切换那一刻就结束的项目(见主题 5.0——以产品为主导的工作)。

6. 设计能减轻负担、而不是增加负担的医嘱集、警报与工作流程,并持续治理它们。 临床构建正是电子病历要么节省认知负荷、要么增加认知负荷的地方。围绕良好证据标准化医嘱集,调优决策支持警报,让临床医生只看到少数重要的、而不是被淹没在低价值弹窗中的警报,并把文档记录负担当作一项头等成果来衡量。建立一个常设的临床信息学治理小组,长期拥有这个构建,审查警报触发与覆盖率,并退役不再值得占据位置的内容(见主题 4.7——临床决策支持与临床信息学)。

7. 从一开始就把宕机与业务连续性构建进记录之中。 电子病历终有一天会不可用——通过一次失败的升级、一次网络中断,或一次勒索软件攻击——而一家在那几个小时内无法靠纸质运作的医院,是一起即将发生的患者安全事故。在中断期间提供对一份近期记录副本的只读访问,维护经过演练的、基于纸质的临床工作流程,并演练有计划与无计划的宕机,这样员工才不会在压力下即兴发挥。明确商定临床记录的恢复时间与恢复点目标,并测试恢复后把纸质记录核对回系统的过程(见主题 3.9——业务连续性与灾难恢复)。

8. 刻意地实现效益,并衡量你所承诺的结果。 一份电子病历的商业论证依赖于不会自动出现的安全、质量与效率效益;它们必须被设计、拥有并追踪。在上线之前建立指标基线,把每一项效益与一位具名负责人及一次工作流程变更挂钩,并按定义的时间间隔对照商业论证审查其实现情况,而不是在切换那一刻就宣告胜利(见主题 6.2——效益实现与价值管理)。使用一个公认的成熟度基准,如 HIMSS EMRAM,给董事会一个外部的、可比较的进展衡量标准,而不仅仅是内部的轶事。

9. 把趋同与互操作性当作一个系统、而不仅仅是一个信托机构项目来管理。 在一个整合照护系统(ICS)范围内,战略拉力是走向更少的电子病历实例与一份共享照护记录,这样一位患者的信息就能跟随他们在各机构之间流动。趋同到一个共同的电子病历可以削减成本、顺畅患者流动,但它集中了风险,稀释了地方控制,因此要把它与不同系统之间强大的互操作性相权衡(见主题 4.3——互操作性与数据标准)。无论形态如何,都要坚持要求开放标准与一个现实的退出策略,以限制供应商锁定,因为一个你无法从中提取数据的电子病历,是一个拥有你的电子病历(见主题 6.3——采购与商务)。

与团队讨论的问题#

1. 我们电子病历的临床设计真正由谁拥有?他们是否有权力、时间与信誉去做出一线会接受的艰难决定? 这一点之所以重要,是因为电子病历成功的单一最强预测因子是真正的临床所有权,而单一最常见的失败,是一个技术上能干、临床上却空洞的项目。讨论你的 CCIO 与 CNIO 是否拥有受保护的时段、真实的预算与决策权,还是他们只是被交付时间表与供应商默认设置所否决的受尊敬的摆设。揭示临床差异与标准化之间的张力:每个专科都想要自己的构建,但一千个本地变体会变得无法维护、不安全。考虑今天的争议实际上是如何解决的——通过临床共识、通过最大声的声音,还是通过谁掌控着日程。审视一线倡导者是否存在于每个领域,还是仅仅存在于纸面上。一个好的、诚实的答案会说出负责任的临床负责人,承认权力目前在哪些地方过于薄弱,并描述一条临床设计决策由临床医生做出并得到坚持的治理路径。

2. 生产力低谷实际上会让我们付出什么代价?董事会是否睁大眼睛地接受了它? 几乎每一次上线都会先拖慢机构、然后再加速它,然而商业论证与董事会常规地假设一条平滑的曲线,恰恰在项目表现正常时就把它判定为失败。讨论你将在上线前后刻意减少多少择期活动,对你的专科组合而言恢复现实需要多久,以及在那个窗口期你将对监管机构与患者关于等候时间说什么。权衡一个更短更陡峭、配有大量前期支持的低谷,与一个更温和更长的低谷之间的取舍——以及谁承担每一种的运营与财务风险。探究培训时数是否真正受到保护,还是在排班紧张时第一个被牺牲。考虑什么样的领先指标会告诉你这个低谷比计划更深或更长,以及你的应对方案是什么。一个好的答案会陈述一个有计划的、有资金支持的、董事会认可的低谷,配有恢复轨迹,而不是寄希望于临床医生会自行消化它。

3. 当电子病历宕机时,我们依然能够运行一家安全的医院吗?我们上一次证明这一点是什么时候? 这份记录如今是如此核心,以至于它的不可用就是一起临床紧急情况,然而宕机流程常常是整个项目中演练最少的部分。讨论哪些临床功能一旦丢失最危险,员工在中断期间是否真的能够触及一份近期的只读记录副本,以及纸质后备工作流程是否存在并被实践,还是一堆没有人打开过的落满灰尘的活页夹。揭示最困难的场景——一次持续数天的、无计划的中断,比如一次网络攻击,而不是一个整洁的计划内升级窗口——以及你为临床记录设定的恢复时间与恢复点目标是否已商定并经过测试。考虑核对问题:宕机期间创建的纸质记录之后如何在不丢失或重复信息的情况下安全地回到系统中。一个好的答案会指出近期的、现实的宕机演练,为记录设定的具名目标,以及知道该做什么的员工,而不是一份只存在于纸面上的计划。

4. 我们在配置受支持的产品与自建之间的界线划在哪里?谁对每一个例外负责? 每一次定制的改动在当下都感觉是合理的——一位临床医生的强烈偏好、一个旧系统支持的工作流程、有人坚持要求的一份报告——但每一个都是在每次升级时偿还的债务,也是一个没有人重新测试的临床安全面。讨论你是否有一条明确表述的"配置到受支持"的原则,还是定制决策是在交付压力下逐模块临时做出的。揭示真正的张力:采纳供应商经过测试的内容更安全、维护成本更低,但它迫使临床医生改变他们的工作方式,而"产品不按我们的方式做"是一股强大的游说力量。审视谁签核一项例外,每一项是否有文档记录并经过风险评估,以及是否有人曾经重新审视并退役你已经背负的定制内容。考虑这在十年间会如何复合,以及它如何塑造你干净利落地采纳未来升级的能力。一个好的、诚实的答案会描述一个明确的标准、一条批准与拥有例外的具名路径,以及一份关于你已经承诺要维护多少定制构建的现实说明。

5. 上线之后,谁在持续改进电子病历——这是作为一项永久职能获得资助,还是被当作一种恩惠来寄望? 一个电子病历所承诺的大部分价值,是在切换之后的数年里,通过对工作流程、医嘱集与警报的迭代调优来实现的,然而机构常规地在上线时解散项目团队,期望优化能免费发生。讨论你是否有一支常设的、配有受保护员工与预算的临床信息学与优化团队,还是一旦项目资金用完,改进就依赖于善意。权衡维持这种能力的支出与在商业论证中立即计入节省的压力之间的取舍。探究效益实际上是如何被追踪的:它们是否在上线前就建立了基线,与具名负责人及具体的工作流程变更挂钩,并按既定时间间隔对照商业论证进行审查,还是被悄悄假设已经实现?考虑你如何决定退役哪些警报、修订哪些医嘱集,以及一线如何请求并看到变化。一个好的答案会说出一个永久的、获得资源的职能,配有一个清晰的效益实现节奏,而不是一个在切换时就结束的项目。

6. 我们是在为自己的信托机构优化,还是在为患者实际穿越的更广泛系统优化? 在一个整合照护系统范围内,战略拉力是走向更少的电子病历实例与一份共享照护记录,这样信息就能跟随患者在医院、社区、精神健康与初级照护之间流动,而不是在每一道前门止步。讨论你的电子病历选择是在加强还是在削弱这一点:你是坚持要求开放标准与干净的互操作性,还是在构建一座运行良好的孤岛?揭示趋同——它可以削减成本、顺畅流动,但集中了风险,推翻了地方的临床偏好——与保留自主权、代价是更多接口的强互操作性之间真正的张力。审视你在多大程度上暴露于供应商锁定,以及你是否有一份现实的退出策略与提取自己数据的能力。考虑在 ICS 层面谁在做这些决定,以及你的本地决策是否与它们一致。一个好的答案会展示一个关于趋同与互操作性的明确立场、对开放标准与安全退出的承诺,以及一个关于本地与系统利益目前在哪里分道扬镳的诚实看法。

实践中:一个医疗与照护案例#

Brackenmoor NHS 基金会信托机构,一家中等规模的急症与社区提供者,正在用一个单一供应商的电子病历取代三个老化的系统——一个患者管理系统、一个独立的医嘱通信系统,以及一片七拼八凑的部门数据库——部分资金来自国家一线数字化项目。它目前的 HIMSS EMRAM 阶段很低,它的商业论证承诺了董事会所指望的安全与效率效益。早期出现的诱惑,是把旧的工作方式"原封不动地搬迁"到新系统中以最小化中断。

这个项目抵制了它。一位 CCIO(一位执业顾问医生)与一位 CNIO(一位高级护士)被任命,拥有受保护的时间,并被赋予对临床构建的联合签核权,由一个覆盖每个病房与诊所的数字化倡导者网络支撑。他们设定了一条坚定的原则:配置到供应商支持的模型,在临床安全的地方采纳其经过测试的医嘱集,只有在真实需求无法以其他方式满足时才进行定制,每一项例外都通过 DCB0160 下的临床安全流程被记录并进行风险评估。医嘱集与决策支持警报是与将使用它们的专科一起设计的,刻意偏向数量更少、价值更高的警报,以避免把员工埋没在弹窗中。

数据迁移被当作一项临床练习来运行,而不仅仅是技术练习。临床团队决定,活跃的问题、过敏史、当前用药与关键结果迁移进结构化记录;更早的历史被总结,或留在一份一键可触及的遗留系统只读档案中。临床医生在上线之前核对并签核了迁移数据的样本,团队捕获到一个悄悄截断了一些过敏条目的映射错误——一个在它能伤害任何人之前、而不是之后做出的修复。董事会同意了一个有计划的生产力低谷:择期活动在上线前后六周内按商定的幅度减少,培训时间被专门保留,恢复轨迹被设定,这样这个低谷就是一个受管理的事件,而不是一个意外。

Brackenmoor 选择了按场所分阶段推广、而不是全信托机构单次大爆炸,接受额外的集成与双重运行,以换取阶段之间学习的机会。每一次切换都通过一个经过演练的指挥中心运行,前两周有大量的现场巡回支持。在第一次上线之前,该信托机构运行了一次完整的宕机演练——只读记录访问、纸质工作流程,以及核对回系统——因为一家邻近信托机构的网络事件让这个风险变得生动起来。上线之后,这个项目没有解散:它变成了一个常设的优化与临床信息学职能,调优工作流程与警报,对照商业论证追踪承诺的效益,并在接下来的两年里刻意地推动该信托机构在 EMRAM 量表上向上移动。

行业视角#

初创企业#

一家数字医疗初创企业很少销售一个完整的电子病历,但它的生死取决于它与一个电子病历的对接程度。要为这个现实而设计:医院运行在一个你无法掌控的核心临床系统之上——支持诸如 HL7 与 FHIR 这样的开放标准,通过信托机构的集成引擎进行集成,而不是要求一条定制链接,并干净、安全地写回记录。你最快的采纳路径,是减少、而不是增加临床医生在他们已经使用的电子病历内的点击负担。把电子病历供应商的生态系统与信托机构的信息治理当作需要围绕它设计的约束条件,而不是要抱怨的障碍。

小型企业#

一家成熟的小型提供者——一家全科诊所、一家社区药房、一家养老院,或一家单一场所的诊所——通常购买一个临床系统,而不是自己构建一个,承担着与大型信托机构同样的记录保存、安全性与信息治理职责,却没有它的 IT 资源。选择一个受支持的、集成良好的产品,并抵制你无法维护的本地定制,因为没有内部团队能在每次升级时偿还那笔债务。即使在小规模下,也要把从旧系统迁移数据当作一项临床安全任务来对待:过敏史、当前用药与活跃问题必须完整抵达,并由一位临床医生检查,而不是因为加载运行了就被假设是正确的。也要为生产力低谷做好规划——寥寥几位临床医生学习一个新系统就可能让一家小诊所停摆,因此要保护培训时间,分阶段推进变革,而不是冷不丁地全部启用。最重要的是,要坚持要求互操作性与一份共享照护记录,让你的患者信息能够跟随他们进入更广泛的系统,并要求一份现实的退出方案,这样单一供应商就不会拥有你的数据。

大型企业#

一家大型 NHS 信托机构或一个运行电子病历项目的 ICS,正在做出一项长达十年、耗资数百万英镑的承诺,重塑每一个临床工作流程。它的核心挑战是规模化的临床所有权、对繁杂定制的有纪律配置、一种可交付的部署形态,以及在上线很久之后依然为优化与效益实现提供资金的耐力。在 ICS 范围内趋同到更少的电子病历实例提供了真实的回报——共享记录、更顺畅的患者流动、更低的单位成本——但它集中了风险,可能推翻地方的临床偏好,因此必须以真正的参与和对供应商锁定的清醒认识来引领。在这个规模上,最大的回报来自少数几门被一致坚持的学科——临床领导力、受支持的配置、经过演练的切换、持续的优化——而不是任何单一模块上的英雄主义。

政府机构#

国家机构塑造着每一个电子病历项目所处的环境。通过 NHS England 的一线数字化项目,政府设定了每一个提供者都应拥有核心电子病历的期望,把资本资金与数字成熟度挂钩,并通过趋同与采购框架引导市场。它的杠杆,是让开放标准、互操作性与安全退出成为市场的默认条款,这样单个信托机构就不必各自在弱势地位下与少数几家大型供应商谈判(见主题 9.1——与地方及中央政府合作)。政府还承担着系统范围的学习职责:在各信托机构之间传播有效的做法,在全国范围内对成熟度进行基准化,并确保一份共享照护记录能够改善跨机构边界的照护,而不是在每家信托机构的前门止步。

常见失败模式#

• 临床上空洞的项目。 一个技术上运行良好、却把临床医生当作被咨询者的项目,产出一个没有人想使用的系统。给予 CCIO 与 CNIO 对构建的真正权力、受保护的时间与决策权。
• 铺设牛径。 在一个现代电子病历内重建旧的纸质表格与遗留工作流程,花钱买了新软件,却继承了旧问题。采纳受支持产品经过测试的内容,重新设计工作流程,而不是复制它们。
• 定制蔓延。 每一次定制变更都会在每次升级时被重新偿还,并重新打开一个没有人重新测试的安全面。配置到受支持的模型;记录、评估风险,并拥有每一个真正的例外。
• "运行干净"的迁移。 一次没有技术错误的加载依然可能遗漏过敏史或错配患者。在上线之前核对迁移数据并获得临床签核,保留一份可触及的遗留档案。
• 假装没有低谷。 假设一条平滑的生产力曲线,把一次正常的上线后放缓变成了一场被感知到的灾难。规划、资助并让董事会认可一个减少活动量的窗口,配有现实的恢复方案。
• 止步于上线。 把电子病历当作一个在切换时结束的项目,导致它的效益未被实现。建立一个永久的优化与效益实现职能。
• 警报过载。 触发过多低价值的决策支持警报,训练临床医生对所有警报都点击跳过,包括重要的那些。调优、衡量覆盖率,并退役噪音。
• 未经测试的宕机计划。 一本没有人打开过的宕机活页夹不是一份计划。演练有计划与无计划的中断,包括核对回记录之中。

成熟度模型#

检查清单#

• 一位 CCIO 与一位 CNIO 被任命,拥有受保护的时间、预算,以及对临床构建的真正决策权,由一个数字化倡导者网络支撑。
• 该项目默认配置到供应商支持的模型;每一次定制都有文档记录、经过风险评估,并有负责人。
• 部署形态(大爆炸式 vs 分阶段/模块化)依据风险偏好与集成复杂性被刻意选择,配有经过演练的切换与回滚计划。
• 数据迁移被当作一项临床练习来运行:迁移范围已商定,数据经过核对并获得临床签核,并提供一份可触及的遗留档案。
• 一个生产力低谷被规划、资助,并获得董事会认可,配有减少的活动量、受保护的培训,以及现实的恢复轨迹。
• 医嘱集与决策支持警报与临床医生共同设计,并被持续治理,警报触发与覆盖率受到监测。
• 宕机与业务连续性流程——只读访问、纸质工作流程、商定的 RTO/RPO、核对——存在,并为有计划与无计划的中断而演练。
• 效益在上线前建立基线,与具名负责人及工作流程变更挂钩,并在上线后对照商业论证进行审查。
• 数字成熟度被基准化(例如 HIMSS EMRAM),并用于与董事会一起追踪进展。
• 一个永久的优化与临床信息学职能在切换之后继续存在。
• 开放标准、互操作性与一份现实的退出策略被确保,以限制供应商锁定,并与 ICS 趋同计划保持一致。

关键来源#

• NHS England ——一线数字化项目与面向提供者临床系统的What Good Looks Like / Who Pays for What 数字成熟度框架。
• HIMSS ——电子病历采纳模型(EMRAM),一个 0 到 7 的临床系统数字成熟度国际基准。
• NHS England / NHS Digital ——治理健康 IT 系统(包括电子病历)的临床安全标准 DCB0129(制造)与 DCB0160(部署)。
• 临床信息学学院与 CCIO/CNIO 网络 ——针对临床信息领导角色的专业指导。
• HL7 International ——用于临床系统之间消息传递与集成的 HL7 v2 与 FHIR 标准。
• 英国财政部 ——用于电子病历商业论证与效益实现的《绿皮书》与《五案例模型》。
• Wachter 评审(《让 IT 发挥作用》,2016)与 Topol 评审 ——关于 NHS 提供者数字化与临床劳动力的国家级评审。

参考文献#

1. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
2. Hospital information system — Wikipedia — https://en.wikipedia.org/wiki/Hospital_information_system
3. Computerized physician order entry — Wikipedia — https://en.wikipedia.org/wiki/Computerized_physician_order_entry
4. Clinical decision support system — Wikipedia — https://en.wikipedia.org/wiki/Clinical_decision_support_system
5. Big bang adoption — Wikipedia — https://en.wikipedia.org/wiki/Big_bang_adoption
6. Chief medical informatics officer — Wikipedia — https://en.wikipedia.org/wiki/Chief_medical_informatics_officer
7. Health informatics — Wikipedia — https://en.wikipedia.org/wiki/Health_informatics
8. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
9. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
10. Health information exchange — Wikipedia — https://en.wikipedia.org/wiki/Health_information_exchange
11. Healthcare Information and Management Systems Society — Wikipedia — https://en.wikipedia.org/wiki/Healthcare_Information_and_Management_Systems_Society
12. NHS England — Frontline Digitisation — NHS England — https://www.england.nhs.uk/digitalhealth/connecting-frontline-digitisation/
13. NHS England — What Good Looks Like framework — NHS England — https://www.england.nhs.uk/digitalhealth/what-good-looks-like/
14. HIMSS — Electronic Medical Record Adoption Model (EMRAM) — HIMSS — https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models/electronic-medical-record-adoption-model-emram
15. NHS Digital — Clinical Safety standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
16. Robert Wachter — Making IT Work: Harnessing the Power of Health Information Technology to Improve Care in England — GOV.UK — https://www.gov.uk/government/publications/using-information-technology-to-improve-the-nhs
17. Faculty of Clinical Informatics — professional body for clinical informaticians — FCI — https://facultyofclinicalinformatics.org.uk/