Epic Systems (MyChart)

Ben：答案大概在中间。

David：昨晚你发短信告诉我，你已经到新加坡了。

Ben：对，我到新加坡了。研究美国医疗保健行业时，一旦你查到了新加坡，就知道该结束研究，开始录节目了。

好，我们开始吧。

Ben：欢迎收听 Acquired 2025 年春季节目。这是一档讲述优秀公司及其背后故事与经营方法的播客。我是 Ben Gilbert。

David：我是 David Rosenthal。

Ben：我们是本节目的主持人。听众朋友，今天我们要聊的是一家位于威斯康星州乡村的低调公司，但它对我们的生活有着巨大的影响。这家公司就是 Epic Systems。

David：没错，不管你是否知道。

Ben：你可能是通过他们的医疗患者软件 MyChart 认识 Epic 的。如果你正在收听这期节目，你很可能用过 MyChart。

Epic 在很多方面都是一家非常不同寻常的公司。他们不做营销，基本也不做销售；经常会拒绝主动找上门的潜在客户。他们不谈判、不打折。在成立 47 年间，他们从未融资，也从未收购过其他公司。

他们不允许远程办公，员工始终都要到现场工作。公司以一座巨大的农场园区闻名，建筑被设计成绿野仙踪中的场景：有巫师学院、树屋、谷仓、纽约中央车站的复制品，还有一座位于地下、能容纳 11,000 人的礼堂。

美国大多数主要医院系统都在使用他们的软件。他们有 600 多家客户，却从未失去过任何一家。

David：这家公司最让我惊讶的一点是，成立 47 年来从未失去过客户。后来我们发现这并不完全准确：他们曾经有一家客户离开了六个月，六个月后又回来了。

Ben：公司的创始人 Judith Faulkner 无疑是我们这个时代最出色的创始人之一。你可能对她和公司了解不多，因为 Epic 仍是私营公司，而 Judy 和她的家族基金会拥有公司大约一半的股份。

尽管公司规模庞大，我想目前年收入接近 60 亿美元，员工超过 14,000 人，但他们明确表示永远不会上市，也不会被收购。81 岁的 Judith 已经制定了继任计划，并为她持有表决权的股份设立信托架构，确保公司永远保持这一方向。

David：我们听说很多公司多年来都试图收购 Epic。GE、Microsoft、Google，你能想到的公司都想买下它，但这永远不会发生。

Ben：节目最后我们会结合完整背景和数据继续讨论这个话题，不过我认为，Judith Faulkner 创办了医疗健康领域最有价值的公司之一，她可能是历史上最成功的女性企业家。

David：几乎可以肯定。

Ben：好吧，听众朋友，先剧透到这里。

David：我们会在最后再讨论。

Ben：美国医疗体系有很多问题，这是无法否认的事实。没人会告诉你：“其实还不错。”它并不好，而是一团糟：成本失控、行政负担沉重，存在大量冗余和浪费。我想现在医疗保健支出已经占到 GDP 的 18%。

今天我们不会试图解决整个医疗体系的大问题，而是聚焦 Epic 在其中扮演的角色，以及它如何取得主导地位。

David：想了解这个体系，就必须了解 Epic。

Ben：听众朋友，如果想知道每期节目什么时候上线，可以订阅我们的邮件列表。只有在那里我们会透露下一期节目的线索，也会分享往期节目的更正，以及一路上学到的小发现。网址是 acquired.fm/email。

听完节目后，欢迎加入 Slack，和我们以及整个 Acquired 社群一起讨论。我猜医疗行业里会有很多人活跃在 Acquired Slack 上。网址是 acquired.fm/slack。

如果想在每月一期的 Acquired 正片之间收听更多内容，可以搜索 ACQ2。这是我们的访谈节目，会与创始人和 CEO 讨论他们正在打造的企业，以及我们在正片中提过的相关领域。

上一期节目里我们宣布了一个好玩的活动预告。现在还不能多说，但回应听众多年来的热烈要求，我们终于要和 J.P. Morgan Payments 的朋友们一起去纽约市了。7 月 15 日，请在日历上记下日期。如果想第一时间了解活动详情，欢迎访问 acquired.fm/nyc。

David：那一定会……

Ben：非常疯狂的一晚。

David：一定会非常精彩。

Ben：最后，本节目不构成投资建议。David 和我可能持有节目中讨论公司的投资，不过 Epic 不在其中。本节目仅供信息和娱乐之用。

David，请带我们进入正题。

David：好。我们的故事从 1943 年 8 月讲起。Judy，也就是今天的 Judy Faulkner，当时叫 Judy Greenfield，出生于新泽西州 Erlton。Erlton 属于 Cherry Hill，是费城郊区，隔着特拉华河就在对岸，离你我长大的地方不远。

Ben：没错，Taylor Swift 也是那里的人。

David：对，还有 Taylor Swift。特拉华河沿岸真是孕育企业家的好地方。

Ben：还有 DuPont，那一带出了很多出色的美国企业家。

David：确实如此。当然，Judy 当时可能并不知道这些。不过她出生的时间和地点确实很特别：她出生大约四年后，在 Cherry Hill 往北不远的 Murray Hill，新泽西州，William Shockley 和同事在 Bell Labs 发明了晶体管。这项发明后来让 Microsoft、Epic、Intel 等公司成为可能。

Ben：而且很长一段时间里，电子病历的早期先驱都是硬件公司。

David：Lockheed、GE、Siemens。

Ben：Lockheed 还是医院的软件供应商。

David：真不可思议。不过当时 Judy 大概对此一无所知，因为她成长的家庭并不属于科技行业。她的父亲 Lou 是一位小镇创业者，在 Erlton 经营一家叫 Lou's Soda Fountain 的药店和汽水柜台。也许 Judy 后来的创业精神就来自他。

Ben：有可能。

David：Judy 的母亲 Del Greenfield 则是一位精力充沛、能力出众的女性。她 15 岁就高中毕业，先做过秘书，后来和 Lou 一起经营商店、药房和汽水柜台。之后她积极参与越战期间及战后的和平倡议。我想，对于经历过第二次世界大战的那一代人来说，这并不常见。她后来成为 South Jersey Peace Center 的主任。

孩子长大离家后，Del 和 Lou 搬到俄勒冈州 Portland。Del 成为 Oregon Physicians for Social Responsibility 的执行主任。听好了，1985 年，这个组织与一个名为 Physicians for the Prevention of Nuclear War 的国际团体合作，获得了诺贝尔和平奖。Judy Faulkner 的母亲所在的团体在 1985 年获得了诺贝尔和平奖。

Ben：你是怎么找到这段资料的？我和你几乎把网上能找到的 Epic 资料都读完了，但我看过的文章里从来没提到过。

David：没有人知道这件事。

Ben：这些信息完全没有被引用过，你是怎么发现的？

David：我当时很好奇，想多了解 Judy 成长的家庭背景，也想查她父亲经营的汽水柜台和药店，以及这对她日后创业有什么影响。我就开始搜索讣告，找到她母亲的讣告，才知道这件事；Epic 公司也向我们确认了。是的，Judy 的母亲在 1985 年获得了诺贝尔和平奖。真不可思议。

Ben：太酷了。好，所以她有创业基因，也有追求和平、思想开放的基因。

David：然后是 Judy。她小时候大部分时间只是对数学感兴趣。她很喜欢讲自己七年级时的一件事：老师给全班出了一道数论题。

当然，老师可能没有把它称作数论题，而是问大家：为什么一个能被 3 整除的数字，把各位数字相加后，得到的和也能被 3 整除？这是数论中的一条规律。Judy 听到这个问题就想：“我的未来就在数学里。”

1961 年，Judy 高中毕业，进入 Dickinson College 主修数学。大学期间，有一年夏天她在更北边一点的 University of Rochester 找到一份工作，在那里的粒子物理实验室做事。

为了完成暑期工作，她需要学习计算机编程。当时是 60 年代初中期，实验要用 Fortran，于是她得学会用 Fortran 运行这些实验。

他们给了她一本 Fortran 手册。Judy 一周内自学会了 Fortran，成为实验室里最优秀的程序员之一。如果你还没看出来，Judy 是个天才，是一位才华极高的人。

Ben：那时编程还不是一门常见职业，软件工程也还没有形成一个领域。数学专业的人开始学习编程语言并将其用于实际工作，但当时全世界掌握这些技能的人非常少。

David：当时大学甚至还没有计算机科学系。Judy 参与了计算机科学成为独立学科的早期阶段。

Ben：有道理。

David：那个夏天，Judy 在 Rochester 爱上了编程。她后来会说，自己像个玩黏土的小孩；编写计算机程序则像把数学、语言和艺术奇妙地结合在一起，当然她本来就喜欢数学。

Ben：她也有艺术气质。虽然她特别擅长数学，但创造力也格外旺盛。

David：她的故事和 Bill Gates 非常不同，她也是完全不同的人，但你应该已经看到一些相似之处：Judy 的成长经历、思维方式和创业做法，都会让人想到 Bill Gates。

Ben：我以为你会说 Steve Jobs，因为 Judy 成长环境里的和平运动色彩。她在那种氛围里长大，我不想说她是嬉皮士，但也有点类似嬉皮士运动。

David：你说得也有道理。我提 Gates，是因为后面会讲到一些 Microsoft 的基因和 Epic 之间的类比。

Ben：而且他们是同一时代的人。她创办公司的时期，几乎和 Apple、Microsoft 成立的时间完全重合。

David：完全正确。回到 Wisconsin 之后，Judy 决定申请数学博士项目。她申请了五个项目，当然全部都录取了。她在履历上写了自己在 Rochester 的经历和 Fortran 编程经验。

她申请的学校中有两所，Stanford 和 University of Wisconsin，当时刚开始筹建计算机科学系。她申请时，这两个学校还没有计算机科学系，但不久之后就成立了。学校看到 Judy 的申请，觉得：“这是一位优秀人才，我们必须招她。我们刚成立计算机科学系。”于是他们把她的申请直接转到了新成立的计算机科学项目。

Judy 想：“噢，我之前甚至不知道还能读计算机科学博士。太棒了，这就是我要做的。”

她最后选择了 University of Wisconsin，前往威斯康星州 Madison 攻读计算机科学博士。我们之后会看到，她最终没有完成博士学位，却也没有离开那里。真是命运的转折点。如果 Judy 当时去了 Stanford，我们大概还是会讲她的故事，但故事会完全不同。

Ben：当然。如果她当时去了硅谷，就会受到完全不同的文化影响，也会对计算机的用途，以及应该用计算机建立什么样的公司形成不同理解。

David：Judy 在 Wisconsin 时修了一门叫“医学中的计算机”的课程，由 Wisconsin 医学院的 Warner Slack 医生教授。这可能是全世界最早的一门同类课程。计算机科学系本身才刚出现，把计算机应用到医疗实践中也是新事物。

Ben：这肯定是最早的同类课程之一，因为大型机直到 60 年代才真正普及。当时距离 ENIAC 问世也只有 15 到 20 年。

David：说得好。这是计算机第一次可以被用于政府和国防行业之外的领域。

Judy 修完 Warner Slack 医生的课程后，果然成了全班最优秀的学生。之后 Slack 医生请她编写一个医院和医学院可以使用的程序，用来优化医生值班安排。医生必须轮流值班，所以这是一个非常适合用计算机应用程序解决的问题。

Judy 说：“好啊。”她开始编写程序。这是她读研究生期间的一份兼职工作，每小时挣 5 美元。那时她是用自己的时间换取报酬。

据说她编程能力很强，写应用程序效率也极高。她会跑遍医院各个科室，接下他们提出的各种应用开发需求。由于完成得很快，按小时收费反而赚不了太多。有一次医院给她加薪，把时薪从 5 美元提高到 10 美元，但她赚的仍不算多。

Judy 在 Wisconsin 医学院各个部门工作，接触精神科、妇产科、康复科、住院部和重症监护室。她开始收到不同医生和科室的各种需求。

一个大问题是，我们在看这些病人时，其他科室也可能同时在看同一位病人，但我们无法得知他们在医院其他部门接受了什么诊疗。我们很希望有一个统一数据库，能够记录病人在整个 Wisconsin 医疗中心接受治疗期间的全部信息，也就是一份电子健康档案。这就是 Epic 的起源。

在继续讲 Judy 接下来做了什么之前，我觉得有必要退一步，谈谈什么是健康记录和医疗记录，60 年代中期美国的医疗记录处于什么状态，以及为什么电子版本如此吸引人。

至少在美国医疗体系里，患者健康记录过去是一种零散、非正式的流程，而且当然都是纸质的。

Ben：我想，人们至少从 1912 年起就开始尝试统一记录或制定标准。

David：没错，最早是在麻省总医院。你可以想象，制定标准有很多重要原因。患者会去不同的医生和医院看病，也会搬家。即使在 Wisconsin 这样的单家医院里，心脏科医生也很想知道病人此前在其他科室接受过什么诊疗。

Ben：或者说，如果你因为同一个问题去看不同医生，他们能把同一种病称为同一个名称就好了。

David：正是如此。美国医疗记录标准化方面的努力，可以追溯到波士顿的 Massachusetts General Hospital，简称 Mass Gen 或 MGH。它是 Harvard Medical School 的主要教学医院，也是规模最大的教学医院。很多医学研究在这里开展，也就不难理解了。

正如你说的，1912 年，American Medical Association 和 American Hospital Association 的几位成员在波士顿的 Mass General 聚集，讨论能否制定一套统一的记录填写方法，推广到全国，让医生用来记录患者情况。当时人们称这些记录为“患者日记”。

1919 年，也就是花了七年之后，他们终于推出了一套标准化的“治疗日记”，向全国推广。但医生没有动力使用它。正如我们之后会看到的，医生这一群体和职业向来很有主见，不喜欢别人告诉他们该怎么做，也不喜欢别人规定他们该如何写病历。

Ben：这也说得通。医生一生都很聪明，做的是一份需要大量教育训练、地位很高、收入也很高的工作。

David：我觉得当时反对标准化也有合理的一面。医疗实践，无论当时还是现在，都同时是一门艺术和一门科学。医生可能觉得，别人告诉他们该如何标准化记录患者情况，根本无法接受。

Ben：医生会想：“我是医生，我最清楚。我会自己决定怎样提供最好的医疗服务。”

David：没错。后来，1928 年，北美健康记录图书管理员协会正式成立，负责推动患者数据收集、存储和检索的标准化。这里还有个有趣的呼应，我想当初这些努力由 Rockefeller Foundation 出资支持。你们还记得我们做 Standard Oil 那几期节目时讲过 Rockefeller Foundation 吧。

Ben：我记得我们对 Standard Oil 那期的结论是，Rockefeller Foundation 最初资助了美国的医学院，对吧？

David：对。

Ben：或者推动了建立真正的医学院这一运动。

David：Rockefeller Foundation 的主要目标之一，甚至可能是最主要的目标，就是改善美国的医疗状况。所以在 20 年代末、30 年代初，这些工作获得它资助也很合理。

这些努力听起来都不错。但事实上，在 60 年代电脑开始普及之前，即使医生真的很想遵循这些标准，只要还在使用纸质病历，它们能发挥的作用就有限。

记录格式再标准化也没用，你还是得把一大叠纸从医院里的一个地方搬到另一个地方。更别说要把它送到另一家医院、另一个医疗系统，甚至另一个州，简直一团乱。

Ben：而且纸张不适合用来结构化数据，因为最终你可以按照自己喜欢的方式在纸上写东西。

David：终于来到 60 年代中期这个时间点，两件非常重要的事发生了。你可以说两件事同等重要。

第一，计算机时代到来了，人们可以把这些资料数字化，于是信息能够跨地点流转，也能实现标准化，这个愿景终于有可能实现。第二，也许更重要的是，1965 年国会在美国建立了 Social Security、Medicare 和各州的 Medicaid 项目。

Ben：对，我们刚才讲的是医疗记录的技术史，现在该转向政策了。在医疗行业，你必须先理解政策，才能理解商业。这个行业的商业结构都是由美国的政策架构决定的。我们再把时间拨回 1942 年。

David：好，给我讲讲。

Ben：我们来讲 Medicare 是如何出现的。1942 年美国正在打仗，当时通过了一项叫《稳定法》的法案，规定工资和物价管制。值得注意的是，当时只有 10% 的美国人拥有任何形式的医疗保险。

David：当时医疗服务主要是按次付费。你去看医生，然后付医生诊金。

Ben：那时还没有成本失控的情况，也没有那种可能随机花掉 100 万美元的治疗手段。也还没有突破性疗法，它们一旦实现就会非常昂贵。因此，大多数医疗费用基本都是自费。

当时有工资管制，但雇主仍想吸引优秀人才，于是就用医疗保险作为福利，绕开工资管制。

David：市场总会找到出路。

Ben：这件事一发生，工会就说：“这太好了，我们的员工能拿到更多福利。”

David：现在我们可以让企业资本来为医疗保险计划买单了。

Ben：没错，这就等于提高了员工的薪酬。工会游说政府把这种做法明确合法化，因为工资管制下它原本处于灰色地带。于是 National War Labor Board 正式批准了这种做法。

第二，随后成立的雇主和医疗保险公司又游说政府：“这些医疗保险保费能不能在企业税前扣除？如果企业拿钱为员工购买医疗计划，就不该为这笔钱交税。”

此外，即使医疗保险是一种薪酬形式，能不能不把它算成员工的应税收入？这样就更好了。企业可以把保费从税前收入中扣除，个人也不用把它算进所得税，尽管这显然属于员工薪酬。

David：工资单上税前和税后金额的区别，就是从这里来的。

Ben：没错，这一切由此启动。有了这样的激励，谁还会想要其他医疗保险制度？这太合算了，可以用税前收入支付保费。对雇主来说也很划算，因为他们提供的福利还能抵税。

1946 年战争结束时，拥有医疗保险的美国人比例已经从六年前的 10% 上升到 30%。快进到几十年后，1964 年这个比例已经达到 80%。

这套监管框架一建立，雇主提供医疗保险就注定会成为主流。美国没有机会采用其他制度。最终会形成这样一套体系：主要由雇主负责医疗保险，并由大型保险公司提供服务。

David：这就把我们带到了 1965 年和 Medicare、Medicaid。因为关键政策问题是：那些没有工作的人该怎么办？

Ben：没工作的人其实不算很多，但那些老人或贫困人群怎么办？美国需要社会保障网，这是我们的基本理念。

David：顺便说一句，他们也是医疗服务使用量最高的人群。

Ben：所以现在来到 1965 年。David，你说得完全正确。Medicare 和 Medicaid 作为《社会保障法》的一部分出台。要理解这是怎么发生的，很有意思。

FDR、Truman 和 Kennedy 都曾试图通过单一支付方医疗体系，效仿英国在二战后采用的制度。英国当时正处于强烈的民族自豪感中，大家觉得应该团结起来、彼此照顾，于是他们建立了 National Health Service。

美国没有足够的政治意愿，所以没有这样做。于是就出现了覆盖缺口：不在劳动力市场的人得不到保障。最后的妥协是，为 65 岁以上的人设立 Medicare；低收入人群和其他特定情况的人则可以使用 Medicaid。但两项计划的资金都没有完全安排好，于是决定由联邦政府为 Medicare 筹资，而 Medicaid 由各州负责。联邦政府会提供帮助，但由各州分别管理。

这就是我们今天的医疗体系：私人保险公司；如果你有工作，就可以直接通过私人保险公司购买保险。如果不符合这个情况，也仍然可以通过私人保险公司获得保险；若符合条件，则使用 Medicare 或 Medicaid。

这一切最重要的影响是，在美国，绝大多数患者不会直接感受到医疗服务的全部成本。成本经由私人保险公司、Medicare 和 Medicaid 层层转移。大多数人面对一次医疗服务时，会觉得是其他人或某个系统在付钱。

如果你想弄清楚，为什么美国医疗支出占 GDP 的 18%，英国是 11%，新加坡只有 6%（虽然整体规模小得多），为什么美国会达到 18%，有个重要因素是：每一次医疗服务在心理上都像是由某个系统付费。我向系统缴费，系统再付钱，但一次服务究竟要花多少钱、我实际付了多少？这变成了一个很抽象的问题。

David：显然，这对医疗记录和早期电子病历行业非常重要。因为现在建立了第二方和第三方支付方，医疗服务要想获得付款，就必须提供记录证明发生了什么。

在这套制度之前，医院、医生或诊所只要给患者看病，患者就会直接付钱。现在则变成先给患者看病，然后还要和付款方协商，比如保险公司或政府，才能收到费用。保险公司和政府会说：“你得拿出证据，证明你做了什么。不能光口头告诉我你做了这些事，我就给你付款。”

Ben：而且这些记录必须采用非常标准化的格式。

David：必须要有正式、标准化的医疗记录。医疗行业因此陷入一种类似浮士德交易的局面，或者说走上了一条难以回头的路：为了获得报销，并且随着治疗变得越来越复杂而拿到更多费用，医生必须严格编码、规范并标准化记录。我们需要完善的工作流程和数据流，将病房中发生的诊疗与最终提交给付款方的账单准确关联起来。

这就产生了电子病历系统的根本需求。但也许更重要的是，它同时产生了电子医疗账单系统的需求。

Ben：我认为行业很早就意识到，保险公司希望把所有人纳入一个大型风险池，这样付款方就能对个人医生、小型医院系统，甚至大型医院系统拥有很强的议价能力。因此医疗机构必须做到极其规范、极其标准化、极易审计，因为它们要和大型交易对手谈判，无论付款方是政府还是大型保险公司，对方都可能掌握议价优势。

David：对医院来说，那些被称为“客户”的其实是付款方，不是真正接受医疗服务的人，所以才叫付款方。Medicare 和 Medicaid 是最重要的付款方，因为他们覆盖了老人，而老人是医疗服务使用量最高的人群，其中包括绝大多数复杂且昂贵的治疗。

Ben：说得通。

David：现在是 1966 年，政府在前一年刚刚设立 Medicare 和 Medicaid。医疗行业有了一个迫切需求：必须采用系统化的记录。

波士顿的 Massachusetts General Hospital 又有一群人开始开发第一个真正的计算机化医疗记录系统，名叫 COSTAR，也就是“计算机存储的门诊记录”。它用于患者排期、登记、临床数据管理，以及电子健康档案所需的其他功能；更重要的是，它还能处理账单，并与付款方对接。这个项目由 National Institutes of Health 资助。

但当时可用的 Fortran 等编程语言，让系统的技术实现相当困难。这是一个高度并发的事务处理系统，整个医疗系统里的很多用户都需要同时使用。

Ben：即使在当时也是这样。

David：是的，整个医疗系统里有很多用户同时使用，而且系统需要连接许多不同终端。当时大型机的存储和处理能力又十分有限。负责开发的程序员发现，现有编程语言不太适合构建他们需要的系统，于是自己开发了一种新语言，叫 Massachusetts General Hospital Utility Multi Programming System，简称 MUMPS。

Ben：居然有一种专门面向医疗领域、名字叫 MUMPS 的编程语言，真不可思议。

David：Epic 直到今天还在用 MUMPS，准确地说，是它的现代后代 Caché。这是整个行业的标准编程语言和数据库系统。

Ben：我不确定是不是整个行业都这样，不过 Epic 肯定是这样，我想现在也影响了整个行业。

David：这正是我要说的。Epic 的很多竞争者并没有使用 MUMPS，但 Epic 一直在用，所以它现在事实上成了行业标准。

MUMPS 有两个关键特点，也正是为什么开发者必须自己创造一种新语言。第一，编程语言和数据库整合在一起，语言内部就包含数据库结构，因此处理大量高速、高数据密集型事务时，计算效率很高。

Ben：至少对程序员来说很高效，因为你不用在程序中不断切换去写 SQL 查询。所有东西都用同一种语言。如果你做的主要是给数据库构建一个封装层，用今天的话说，就是一个会被不断读写的“高级数据库”，那让所有东西都用同一套标准语言会方便得多。

David：他们还把第二个目标设为支持多个用户同时使用。想象一下，医院不同部门同时更新同一位患者的病历；医院的行政人员也在更新同一份记录，标注哪些费用已向付款方开账单、哪些还没有、哪些遭到质疑，等等。

Ben：你可不希望数据冲突导致信息丢失之类的问题。毕竟这关系到人的生命。

David：完全正确。当时，Mass General 这个项目的首席程序员是 Neil Pappalardo，他刚从 MIT 毕业。作为年轻、有创业精神的 MIT 毕业生，几年后的 1968 年，Neil 便带着这个项目出来创业，成立了一家公司，最初叫 Medical Information Technology，简称 MIT。

Ben：这个名字已经被占用了。

David：对。不过后来，在真正的 MIT 可能提出要求后，他们很快把名字改成了 Meditech。医疗行业的人听到这个名字会很熟悉，因为 Meditech 至今仍在运营，是电子病历市场的第三大厂商，仅次于 Epic 和 Cerner。

Ben：真了不起。

David：现在回到 Wisconsin 的 Judy。她在大学期间和 Slack 医生及医学院合作，开发了各种应用项目。后来 Slack 医生去了 Harvard，在那里认识了 Neil，并开始与 Meditech 合作，但他和 Judy 仍保持联系。

Judy 属于一个为医疗系统开发应用程序的程序员和计算机科学家群体。正如我们之前所说，Wisconsin 的人真正想要的，和 Harvard、Mass General 的人想要的完全相同：一套集成系统，能跟踪患者在整个医疗过程中的长期记录，并且可以用来向付款方结算费用。

Ben：这就是他们梦寐以求的圣杯。

David：没错。这段关系让 Judy 了解到 MUMPS。她去学习了这种编程语言，开始着手解决这个问题。坊间传说，到了 70 年代中期的一天，她坐在客厅里，突然想到该怎样打造一套出色的系统：一个能完成所有这些工作的统一数据库。

她曾回忆说：“那天阳光明媚，我心不在焉，只是坐在那里，突然一切都想通了。我知道该怎样构建它，那就是集成系统。我记得自己跑到厨房，拿起一叠便笺纸，就开始写代码、写代码、写代码。”那些代码后来成为 Chronicles，也就是患者治疗历程的编年记录。直到今天，那套代码和数据库依然是 Epic 的核心。

Ben：它真的是同一套代码吗？

David：不是。她会说自己当年写的代码没有一行还在生产系统中使用，这大概是真的。但 Epic 的核心数据库确实是统一的。这是 Epic 最大的差异化优势：所有应用都从同一个数据库读取数据。

Ben：所有应用都直接连接它。

David：没错。不管是电子病历临床端、名为 Resolute 的账单模块、Cosmos，还是面向妇产科的 Stork、面向肾脏科的 Beans，Epic 几百种应用中的每一种都读取同一个 Chronicles 数据库。Judy 在 70 年代写下的就是这个系统。

Ben：好，所以它其实只是一个数据库？她领悟到应该以患者数据模型为核心来建立数据库，然后写了一堆代码，接下来它是怎么发展的？

David：这是个好问题，因为它当时确实只是一个数据库。我们还处在大型机时代，数据库之上并没有所谓的应用程序，更不用说图形界面了。产品就是这个数据库。Wisconsin 医疗中心的不同部门可以自行编写屏幕界面和查询程序，连接到数据库，让各部门在终端上直接调取患者信息。

Ben：所以那时候用的是终端，屏幕只有 80 个字符宽，而且只有文本。

David：对，就是绿色屏幕，Unix 终端。

Ben：也就是说，医院大楼里的某台大型机运行 Judy 的数据库 Chronicles，其他部门通过这些纯文本终端查询数据库。

David：这就是当时的产品。

Ben：真要走的路还很长。

David：和波士顿 Mass General 的项目一样，最初的目的都是为医院本身开发系统。Judy 起初只是在为 Wisconsin 医疗系统构建 Chronicles，她只是医疗中心的程序员员工。

但 Wisconsin 大学的医生会参加全国各地的学术会议，他们开始向其他学术机构的医生介绍这套名叫 Chronicles 的优秀系统，说这是他们聘用的程序员 Judy Faulkner 写的。口碑很快传开。Wisconsin 陆续接到电话，Judy 也接到全国各地医疗系统的电话，对方会问：“你能不能也为我们做一套？”

Ben：她是不是被问了很多次要不要创业？她总是说：“不用，我只为这里做了一个实例，不需要围绕它成立整家公司。”

David：没错，这样的情况一次又一次发生。坊间传说，最后她终于受不了了，说：“好吧，我成立一家公司，但我只兼职做这件事。我们再找几位和我一起工作的同事，也兼职参与。规模就控制得很小。”于是，1979 年，公司终于诞生，名字叫 Human Services Computing。

Ben：这个名字也太普通了。

David：这就是后来 Epic Systems 的前身。不过在讲 Human Services Computing 如何变成 Epic 之前……

Ben：好，David，Judy 离职创业了。她成立的公司叫什么来着？Human Computer……

David：Human Services Computing。

Ben：Human Services Computing。

David：读起来确实挺拗口。

Ben：她到那时为止并没打算成为公司创始人，但接下来的 47 年人生都在经营这家公司。事情是怎么发展的？

David：但在开始做任何事之前，她得先筹钱，至少要买一台电脑来开展工作。

Ben：买一台电脑不是要花 7 万美元吗？

David：对。那是一台 Data General Eclipse 16 位小型机，大概有洗衣机和烘干机那么大，放在地下室里。

Ben：是的，因为我们处在大型机和微型计算机之间的尴尬时代。微处理器还没发明。那时的“小型机”仍然和洗衣机差不多大。

David：我们当时正处于 PC 时代来临之前。

Ben：很有意思。有时新技术浪潮会完全取代之前的一切，但有时中间也会出现一些过渡阶段，最后并没有彻底取代所有东西。

David：小型机就像当年的上网本。我们在 Microsoft 系列节目里聊过这一点。小型机的关键在于，消费者不会买，但小企业可以买，大公司的小型部门也买得起。

一套 IBM 大型主机系统会花掉很多钱，一台 Data General 或 DEC 小型机则要大约 7 万美元。Judy 需要买一台，于是她去银行贷款 7 万美元，买下 Data General Eclipse 小型机。

她还邀请朋友、家人以及其他人投资新公司，包括医生和 Wisconsin 大学系统里曾与她合作项目的程序员。他们一共投入了约 7 万美元。公司估值也是 7 万美元，也就是投前估值 7 万美元。

Ben：然后又追加了 7 万美元的新资金。

David：投后估值就是 14 万美元。

Ben：这轮 7 万美元融资让创始人的股份被稀释了 50%，此外她还有 7 万美元银行贷款。

David：那些人就是 Epic Systems 唯一的早期股权投资者。关于原始投资者后来持有的股份，有一些很有意思的故事。公司回购了其中很多股份，但并不是全部。

Ben：现在还剩一些股份在外流通。

David：确实还剩一些。研究时我们听到不少故事，但不能全部公开。其中一个有意思的事情是，我想大概在 2000 年代，有相当一部分股份转到了 Sequoia Capital 手里。Sequoia 没有把这笔投资写在自己的网站上。

Ben：Epic 的历史几乎是它和硅谷唯一的一次交集。不过这点很惊人：如今他们年收入达到 57 亿美元，主导着一个行业，至少在美国是这样；而他们总共只融资了 7 万美元股权，另外借了 7 万美元银行贷款。

David：就这些。

Ben：这又像 IKEA 的故事。

David：完全如此。我觉得，做软件不一定需要大量资本。尤其是在当年，打造优秀软件确实很难。我认为 Epic 没怎么融过资，很大原因是 Judy 具有顶尖程序员的能力。

Ben：我之前没想到这两件事之间的联系，有意思。

David：作为初创公司，Epic 拥有稀缺的人才。Microsoft 当年也有 Bill Gates 和 Paul Allen 这样的核心人物，Epic 也有 Judy。她能写出非常优秀的软件。

Ben：所以他们不需要雇佣一大群程序员。

David：而且公司很长一段时间里一直规模很小。

Ben：坊间传说，公司创办时只有三个兼职员工，在一栋楼的地下室里办公。我想他们靠这几个人就走得很远。

David：我想是的。很多年里，他们都没有招很多人。当然后来公司规模逐渐扩大。

我再讲一件事，90% 的把握能难住你。你刚才提到地下室办公。Judy 给公司找到的第一间办公室，是 Wisconsin 州 Madison 的 University Avenue 2020 号的一栋公寓楼地下室。你知道还有哪家伟大的美国公司也从同一间办公室起步，而且我相信还和 Epic 有一段时间同时在这间共享办公室办公？

Ben：David，关于这家公司能找到的资料就那么多，我们俩都查过了。听众朋友，这是 American Girl 娃娃公司。

David：我真的以为这次能难倒你。Ben 和我通常不会一起做研究电话访谈，但有一次我们一起参加。我正想问对方这件事时，对方快要说出来了，我赶紧打断：“别说，我想留到节目里考考他。”

Ben：不过我确实在别处看到过。更不可思议的是，我觉得 American Girl 搬走时，Epic 还买下了他们的一些家具。

David：我想确实如此。听众朋友，我们说的是 Pleasant Rowland 在 Wisconsin 州 Madison 创办的 American Girl 娃娃公司。

Ben：我姐姐小时候好像有好几个这种娃娃。

David：天哪，Jenny 有很多这种娃娃。现在不少已经搬到我们家了，女儿们也会玩。我三岁的女儿已经会拿着 American Girl 的娃娃杂志在家里跑，每周都指着一个 250 美元的娃娃对我说：“这个是我生日想要的。”真是一家了不起的公司。它后来在 90 年代末被 Mattel 收购，很长时间都是 Mattel 业务的重要组成部分。

唉，没能难住你我真遗憾。好，回到 Epic 的故事。Judy 有了资金，也买了电脑，但她还不知道怎么创办和经营公司。她是一名软件开发者。Warner Slack 对她说：“来波士顿吧，我安排你花几天时间和 Neil 以及 Meditech 的团队相处。我会请他帮你一起创业。”

Ben：我得说这是个关键时刻。不只是因为她从 Meditech 学到了很多，接下来我们会讲她借鉴了哪些做法。关键在于，Slack 没有说“我给你介绍一位商界人士”，而是说“我会教你作为程序员怎样经营企业”。

Epic 基本上从未聘用过商科人士。这种说法不完全准确，但大致成立。Epic 本质上是一家由程序员、逻辑思维者和实施人员组成的大型公司，即使实施人员不是程序员，也会像程序员那样思考。这种基因一直延续至今。公司本来也可能走向完全不同的道路，比如去制定销售和营销战略、写商业计划，但这些事情并没有发生。

David：这对 Epic 和 Judy 来说是一个关键转折点，因为她能遇到一位商业导师，而对方是一名软件开发者，不是商学院毕业的商界人士。我们说的是 70 年代，当时的商业套路是把成年人请进来，让穿西装的管理人士接管，把创始人赶走。

Ben：但只有在你融资以后才会发生这种事。

David：完全正确。难怪 Judy 那么抗拒风险投资。当时她认识的其他创业者只要接受风投，最后就会被解雇。

Ben：然后公司换上一个商业人士来经营。

David：没错。Neil 毕业于 MIT，是一名程序员，也是最早参与 MUMPS 开发的人之一。Judy 去波士顿跟 Neil 一起待了三天，接受了一场关于如何创办和经营公司的速成培训。

Ben，正如你说的，Neil 以软件开发者的方式经营 Meditech，所以所有流程都高度标准化。他为公司运营建立了成熟的应用程序接口，为所有事情都编写了手册和文档，并把这些材料交给 Judy。比如如何建立人力资源系统、如何办理福利和薪资发放……

Ben：如何从大学招聘、如何在内部晋升。

David：Meditech 会在波士顿的大学招人，不聘用有经验的程序员，而是招刚毕业的大学生。Judy 自然也会在 Epic 采用同样的方式，先从 University of Wisconsin 开始，后来再从其他学校招聘。这就是她得到的经营方法，这种基因直到今天仍贯穿 Epic。

Ben：他们招的大多数人都没有医学专业背景。他们从中西部大学招聘技术专业的学生，相信这些人可以在工作中学会医疗保健。

David：这和 Microsoft、Google、Meta 等公司的做法一样：去大学各个院系招聘，在校园里招应届毕业生。

Ben：而她在当时就这么做了，这并不常见。得不断强调那个时代和今天有多么不同。当时还没有大学招聘会，也没人能理所当然地认为大学毕业后就能找到一份自主性很强的好工作。Microsoft 是最早大规模招聘聪明的大学毕业生、授权他们自由发挥的公司之一。Epic 也这样做，但这不是行业标准。

David：而且当时 Microsoft 甚至还没开始这么做。他们才刚搬到华盛顿州，刚离开 Albuquerque。我们说的就是那个时期。

Ben：那是几年？

David：1979 年。

Ben：Microsoft 那时候还没真正开始大规模招聘。

David：没错，那时还没有 DOS，也没有真正的 PC 产业。Microsoft 的主要产品是 BASIC 解释器。Judy 和刚起步的 Human Services Computing 虽然已经有其他大型学术医院和医疗系统的需求，但这些机构都有大型主机和大学计算基础设施可供使用。美国普通医院、医疗诊所和门诊机构都还没有小型机，更不用说大型主机。除了大学医疗系统，这类产品的大众市场还没有真正出现。

Ben：她做的事情也和 Meditech 服务的市场不同，这多少是出于对 Neil 及其公司的尊重。Meditech 面向小型医院，而 Judy 要采取更高端、更偏企业级的路线，服务最复杂的机构：大学教学医院，后来还有大型综合医疗网络和儿童医院。也就是说，她选择了需求最复杂、最有能力购买复杂软件的高端客户群。

David：而她开发的是基于 Unix 的产品，这么做也有必要，因为只有这些机构有 Unix 基础设施。

Ben：他们也负担得起这些大型计算机。

David：1979 年，他们从四家早期客户起步。四年后，也就是 1983 年，公司更名为 Epic Systems。Ben，你知道他们为什么改名吗？

Ben：除了原来的名字实在太糟糕以外，你也能看到 Judy 的古怪风格。最早是 Chronicles 这个名字，能看出她抽象而富有创意的思维。“史诗”在希腊文学里是一个宏大的故事，是一段漫长的历史事件。我觉得她把患者病历看作一部史诗，记录患者一生的历程。你觉得这个理解对吗？

David：对。这不是一家公司宏大抱负的宣言，因为当时它仍然非常非常小。1983 年更名时，它有四家客户；之后客户数量才达到九家。到公司成立后的第一个十年末，也就是 1988 年底，他们只有 24 家客户，收入仅 150 万美元，员工也只有几个人。这正是关键：和 Microsoft 不同，Epic 从一开始就是一家小企业。

Ben：花了十年，收入才达到 150 万美元。这是一家缓慢起步、扎实经营的初创公司。

David：我觉得可以把它描述成一家在 Madison, Wisconsin 服务本地客户、经营得很好的软件公司。成立后的前十年，公司确实在增长，但并没有引起轰动。部分原因是客户的计算基础设施还不成熟，正如我们刚才所说。

另一个导致客户增长不快的重要原因是，他们当时只做临床病历记录，直到 1987 年才开发出非常重要的账单系统。在公司成立后的前八年左右，他们没有解决医院最关键的问题，也就是如何帮助医院为医疗服务收费。

Ben：如果你能帮医院赚更多钱，他们就会更愿意购买你的软件，也愿意付更高的价格。

David：完全正确。1987 年，他们推出了名为 Resolute 的账单模块，它同样搭建在 Chronicles 单一核心数据库之上。直到今天，Resolute 仍是 Epic 为所有医院提供的收入周期应用程序。我知道我们已经强调过几次，但我真的想再说明一下：它本质上仍然只是一个搭建在 Chronicles 数据库之上的应用。快进到今天，我觉得这正是 Epic 能胜过竞争者的最大原因。

Ben：我认为 Epic 今天能胜出的原因有两个。第一是可靠性，而可靠性也来自所有系统都建立在同一个数据库上，不需要把多个系统拼接在一起。其他竞争者几乎都通过并购，把三十家公司拼在一起，经历上市、私有化等各种复杂交易。除了 Meditech 之外，Epic 从始至终就是 Epic。

当你买下系统时，他们估计需要多少费用、花多长时间实施，结果基本就是如此。上线以后，系统也确实能正常工作。听起来好像理所当然，但它真的会按承诺的时间和预算完成工作，至少达到了这个行业里最好的水平。

除了可靠性，David，你刚才暗示的第二个原因是临床端和账单端完全整合在同一套代码里，共用一个数据库，协调得天衣无缝。系统之间传递信息时不会丢失数据。如果医院想采用一套记录院内所有工作、并确保能从这些工作中获得收入的系统，这就是理想架构。

David：你刚才说“系统会按预期工作”时我笑了。我猜你说的是临床医生实际使用的电子病历系统。如果医院想让医疗服务和账单、收入相互关联，那就不能出现任何差错。

Ben：医院想要的就是这个。

David：这就是医院需要的产品。正如 Ben 所说，其他竞争者除了 Meditech 可能部分例外，账单系统通常与医疗记录系统分开，而且常常是另外收购来的产品。

问题不只是信息不能快速、高效、准确地在两个系统之间传递，这种情况会造成非常严重的后果：医院可能无法收到应得的医疗费用。更糟的是，你可能提交错误的记录，那就可能构成联邦犯罪。

Ben：反过来也一样糟糕。如果账单系统的信息没有同步到临床系统，就可能伤害患者，甚至危及生命。在这种用途中，任何方向的数据错误都非常严重。

还有一个很棒的 Substack，叫 Health API Guy。我会在节目里多次引用，因为其中有些关于 Epic 的文章写得特别好。他说得很到位：

“对企业决策者来说，Epic 自然会成为首选，正是因为它采用了集成式系统架构。买家不用管理多个供应商和系统，而是能得到一个综合平台，其中有单一数据库、统一工作流程，以及通过 Care Everywhere 内置的互操作能力。”我们稍后会讲 Care Everywhere。它是一个神奇的按钮，可以让一家 Epic 客户医院的病历轻松整合，并在其他 Epic 客户医院查看。

David：Resolute 上线后，也就是进入 80 年代末和 90 年代初，我们终于进入 PC 时代。医院和医疗机构只需花几千美元就能买到电脑，不再需要花几万美元。Epic 的市场开始真正发展。1992 年，他们基于这个趋势推出 EpicCare。我想这是整个行业第一个基于 Windows 的图形界面电子病历应用。

Ben：肯定是。Epic 自己确实这样说。

David：这意味着什么？回到 Chronicles 最初的样子，它只是通过终端直接访问 Unix 数据库，数据库运行在大型机或小型机上。普通医生、护士或医疗助理不可能轻松使用这样的系统。

到了 90 年代，EpicCare 成为一款 Windows 应用程序。任何 PC 用户都能在 Windows 电脑上启动它，通过图形界面处理患者的电子病历。顺便说一句，这套系统还直接连接医院或诊所的账单系统。突然之间，产品变得非常有吸引力。

Ben：对于医院管理者来说，这就接近圣杯了。除了账单，还有一个叫 Cadence 的排期系统。只要把账单、排期和负责临床记录的 EpicCare 整合起来，就非常完整了。不过这里说的还是门诊业务，对吧？还没讲到住院业务。

David：对。最初推出的 EpicCare 图形界面电子病历，只适用于门诊场景，也就是患者不住院的情况。

Ben：不包括住院病人。是的。

David：对，不包括需要住院的患者。

Ben：作为一个不了解医疗行业的人，我一直用“是否过夜”来区分住院和门诊。

David：听到“门诊”，你就想到不需要过夜的治疗。否则这些术语实在太让人困惑了。

Ben：但对医院来说，排期、账单和门诊临床记录都整合在一起，这已经是一个非常出色的产品了，也彻底改变了公司的发展轨迹。功能足够丰富，公司很快就不会再是小企业。

David：到 1995 年，他们的收入达到 1,800 万美元，高于 1988 年的 150 万美元。

Ben：所以七年时间增长了十多倍。从大多数指标来看，这门生意都发展得很好。

David：没错，已经不再是一家位于 Madison, Wisconsin 的小企业了。

Ben：不过，之前我们把 Epic 和 Microsoft 作比较。你提到了 Bill Gates。这家公司成立于哪一年？1970……？

David：1979 年，比 Microsoft 晚几年。

Ben：比 Microsoft 晚四年。1995 年 Epic 的收入是 1,800 万美元，而同年 Microsoft 已经上市，推出了 Windows 95，收入达到 60 亿美元。

David：两家公司的发展轨迹完全不同。

Ben：主要原因是，一家是专注于垂直行业的小型医疗软件公司，另一家则在打造面向未来的横向平台。不过，为了客观看待 Epic 的发展，我们应该停止再拿 Microsoft 作比较。

David：我想稍后在节目和分析里再回到这个话题。Epic 的确一直受限于它是垂直软件供应商，而不是像 Microsoft、Google 或 Oracle 那样提供横向软件。

Ben：垂直行业就是某一个行业。

David：对，垂直行业就是一个行业。但 Epic 服务的医疗行业占美国 GDP 的 18%，所以它到底能发展到多大，我们稍后会再讨论。

2001 年，他们终于推出 EpicCare 的住院版本，适用于在医院过夜的患者。这时他们终于有了完整的理想方案：Chronicles 是单一数据库，EpicCare Ambulatory 服务所有门诊，EpicCare Inpatient 服务所有住院业务。

顺便说一句，住院服务大概是收入的主要来源，因为最昂贵、最复杂的治疗都发生在那里。这和 Medicare 是最重要的付款方差不多，因为老年人使用的医疗服务最复杂、费用也最高。现在 Epic 有了这一整套系统：住院和门诊服务都连接到 Resolute 账单系统，全部基于同一个数据库，并整合在一起。对医院管理者来说，这简直是最理想的方案。

Ben：Epic 也开始真正认识到，未来的关键是业务范围。医院客户不想买零散的解决方案。他们想从一家供应商那里买齐所有产品，而且希望这家供应商提供尽可能优秀、整合程度尽可能高的体验。所以公司必须继续围绕这个理念发展。

David：差不多在同一时期，实际上比 EpicCare Inpatient 更早，Epic 推出了 MyChart。这很惊人。如果你在研究这期节目之前问我 MyChart 是什么时候推出的，这是一种基于互联网、面向消费者的医疗记录访问平台，所在行业还受 HIPAA 严格监管。我可能会猜是 2010 年，或者最早 2000 年代中期。结果不是，Epic 在 2000 年就推出了 MyChart，真不可思议。

Ben：正好是在互联网泡沫破裂前后。

David：对，真是不可思议。他们推出了这个产品，而且客户医院也真的上线了。

Ben：这非常创新，确实走在时代前沿。虽然节目里也会合理地讨论一些对 Epic 的批评，比如技术陈旧、界面笨拙之类，但 1999 年的 MyChart 真的是尖端产品。大家马上就理解了它的价值。一旦患者可以在家里用自己的电脑直接查阅医疗记录，而不用联系任何人，就再也回不去了。世界一夜之间变了。

David：这有点像房地产领域的 Zillow。一旦你能查到自己社区和朋友邻居房屋的成交价，就再也不想回到查不到这些信息的时代。

Ben：之后我们会认真讨论电子病历的优缺点，以及今天的医疗服务是否比过去更好。但我实在无法想象，如果没有 MyChart，我只能亲自去医院找他们索取记录，或者打电话请他们回电。

David：以前换医院或更换医疗服务提供方时，记录必须通过传真来回传递，过程非常糟糕。MyChart 另一个很有吸引力的用途，尤其是刚推出时、甚至直到今天仍然重要，就是帮助家人管理彼此的医疗照护。

比如年迈的父母开始经常使用医疗系统，你也需要帮忙照料他们，但你们不住在同一座城市。即使住在一起，能够访问家人的 MyChart 也非常有用。这让 Epic 在患者端形成了口碑传播。

对医院客户来说，最初推出 MyChart 可能令人很不安。但当它加入自助预约功能后，就成了医院的利器。原本电话预约需要投入大量工作，现在都可以由系统处理。

另一个很大的好处是减少患者爽约。MyChart、自助预约和候补名单功能推出之前，患者爽约就意味着医院损失收入，也会在每天的营收运营中留下一个缺口。现在医院可以自动用候补名单里的其他患者填补空出来的时段。

Ben：我们先给后面的话题打个预告。如今 MyChart 已有 1.91 亿活跃用户，而且这个数字经过了去重，指的是独立用户。

David：MyChart 在 2000 年推出，EpicCare Inpatient 在 2001 年推出。随后公司收入突破 5,000 万美元，他们开始觉得自己终于可以进入大联盟了。

Ben：再给 5,000 万美元的收入一个背景：他们当时已有 88 家医疗系统客户，通过逐个医院系统销售软件，开始真正打入市场。

David：他们准备好进入大联盟后，2003 年接到一个电话，来电者不是一般的大客户，而是加州最大的医疗机构之一 Kaiser Permanente。

Ben：David，这相当于最大联盟里的最大客户主动找上门。

David：Kaiser Permanente 是一家很特别的医疗机构，总部位于加州。它是一家完全整合式的“管理医疗联盟”。

意思是，它既是你的医疗保险计划，也拥有医院系统。就像保险公司和医院系统合并，然后说：“这些医院由我们运营，会员只能来这里接受医疗服务。”它控制着整个系统，是美国最接近单一付款方模式的机构。

不过，Kaiser 也必须和 Medicare 对接，因为它还提供 Medicare Advantage 计划。患者年纪变大后，可以转入 Kaiser 的 Medicare Advantage 计划。

Ben：明白了。

David：当时是 2003 年，Kaiser 是全美最大的单一医院系统，拥有 30 家医院、400 多家诊所、11,000 名医生和 850 万名患者。他们决定为整个 Kaiser 系统采购一套全新、完整、集成化的电子病历系统，并发布了一份招标书。

Ben：这时你就该意识到，电子病历不只是医疗记录，也不只是与账单和预约相连的记录系统。

David：这是整个行业的操作系统。

Ben：有人把它形容成医疗系统的神经系统。我觉得这很贴切。你有 20 家医院、大量医生和行政人员，所有人都靠这套无比复杂、包含数千个不同界面、权限级别、认证、角色和许可的软件相互连接。系统极其复杂，却是整个组织赖以运行的核心神经系统。

David：叫它操作系统还不够。这就像操作系统加 ERP 系统，再加上运行在操作系统之上的应用程序。它就是一切。

Ben：这么说很合理。虽然我们把这些产品叫作电子病历，但应该把它看成整个医疗系统中所有部门都依赖的一项基础功能。

David：2003 年，Kaiser 为整个系统的新产品发布了招标书。名义上是“电子健康记录”，但实际上是要更换整个 Kaiser 的神经系统，而 Epic 赢得了这笔交易。

Ben：Epic 当时还是一家小公司。就在几年前，他们的收入还只有 5,000 万美元。

David：签下 Kaiser 合同后，他们的年收入升至 1.62 亿美元，影响巨大，收入可能一夜之间翻了一倍还多。

Ben：我们来谈谈合同金额，这很有意思。新闻里经常出现的数字是 40 亿美元。媒体会把它称为一项价值 40 亿美元的三年项目，而 Epic 能拿到的部分大约是 4 亿美元。当然，这笔钱不是一年内全部到账。项目一开始要花大量资金实施，之后才有持续的软件许可收入。我想这些许可最后会转为订阅模式，但当时还是购买软件使用权。

但看这些新闻标题很有意思。40 亿美元不仅包括合同多年期的价值和系统实施成本，也把医院员工需要投入的工作时间算进去了，还把整个医疗系统里的医生转用新软件时可能损失的生产力也算进去。

David：顺便说一句，这确实会产生实际的经济影响。

Ben：当然。

David：但这并不意味着 Epic 从中赚了 40 亿美元。

Ben：没错，我总觉得这些数字听起来特别夸张。动辄几十亿美元。即使是小型医疗系统，也会说这是一个 3 亿美元的项目。最后 Epic 真正拿到的钱远没有这么多，但行业就是用这种方式描述交易规模。

David：对，这很有意思。我们也应该开始说 Acquired 的规模，然后……

Ben：再把第四层、第五层的间接影响也算进去。

David：这样我们就成了一家十亿美元级企业。

Ben：想想我们的客户和 Acquired 听众做了多少生意……不过你说得对。如果 Kaiser 用好几年时间更换整个核心神经系统，对它来说，累计 40 亿美元的影响确实合理。

David：这件事的经过很离奇。当时 Kaiser 的两个主要中心分别在北加州和南加州。虽然都隶属于 Kaiser，但它们几乎像两家公司，使用不同系统，有各自的电子病历和管理团队。当然它们会彼此沟通，也属于同一个母公司。

Ben：不是还有个类似远亲的 Northwest 区域吗？有点像继子女？

David：对。我不确定当时只有 Northwest，还是还有其他较小的地区业务，但他们在俄勒冈州 Portland 有一个规模不大的太平洋西北区域。如今 Kaiser 已经在美国大部分地区建立了大型区域业务，从那时起发展了很多。

但在这个小小的 Portland 区域，他们已经开始在门诊使用 Epic。也就是说，当时还没有医院住院系统，只在门诊使用。与此同时，北加州和南加州两大阵营正在争斗，各自与软件顾问合作，试图开发自己的专有电子病历系统，其中包括 Accenture 等公司。

Ben：那时有一段时期，医院认为电子病历应该属于自己的知识产权，可以靠自己开发的系统比其他医院更有竞争优势。我不知道这种想法从何而来，但大家都想拥有自己的电子病历系统。

David：我觉得他们可能还幻想过把系统商业化、卖给其他医院。这似乎并不是医院应该具备的核心能力。

David：对，这很有意思。我们也应该开始说说 Acquired 的规模，然后……

Ben：再把第四层、第五层的间接影响也算进去。

David：我们就能成为一家十亿美元级企业。

Ben：想想我们的客户以及 Acquired 听众所做的所有生意……不过你说得对。如果 Kaiser 用几年时间更换整个核心神经系统，对它而言总影响达到 40 亿美元确实合理。

David：整个过程很离奇。当时 Kaiser 的两个主要中心分别在北加州和南加州，几乎就像 Kaiser 旗下的两家公司。它们有不同的系统和管理团队，当然会彼此沟通，也同属一个母公司。

Ben：是不是还有一个类似远房亲戚的 Northwest 区域？有点像继子女？

David：对。我不确定当时是否只有 Northwest，还是还有其他较小的区域业务，但他们在俄勒冈州 Portland 有一个很小的太平洋西北地区。如今 Kaiser 已经在美国大片区域都设立了业务，从那时起它的规模增长了很多。

但在这个小小的 Portland 区域，他们已经开始在门诊诊所使用 Epic，也就是还没有用在医院住院业务上。与此同时，北加州和南加州的两个大阵营正互相竞争，分别与 Accenture 等软件顾问合作，开发自己的专有电子病历系统。

Ben：当时有一种想法，认为医院应该拥有自己开发的电子病历，把它作为知识产权，以为自己的电子病历比其他医院更好就能获得竞争优势。我不知道这种想法从何而来，但人们确实想拥有自己的电子病历。

David：我觉得他们甚至幻想过把系统商业化，再卖给其他医院。但这似乎不是医院应该具备的核心能力。

不过，Kaiser 系统内部医生的调动相对灵活。如果你在 Portland 的 Kaiser Pacific Northwest 工作，后来想搬家，或者因为家庭原因必须搬到加州，就可以比较容易地调到北加州或南加州的 Kaiser。

事情就这样发展着，西北地区的医生开始调到加州。他们会说：“你们怎么回事？花这么多钱请 Accenture 和其他顾问，试着自己开发系统。我们 Portland 那边有一套叫 Epic 的系统，医院还没用上，但比你们正在开发的东西好得多。”

北加州和南加州争了大约一两年后，终于决定停火、达成和解。他们放弃彼此竞争的项目，改为向第三方供应商公开招标。于是，他们为整个 Kaiser 系统采购一套集成的电子病历，最后选了 IBM。IBM 准备为 Kaiser 开展一个价值 40 亿美元的大项目。

Ben：没人会因为买 IBM 而被解雇。那是这个时代的尾声，但当时还留有一些这样的想法。

David：那时才 2003 年，采购决定也可能更早。IBM 进场后，项目失败了，没有成功。

Ben：这种事并不少见。尤其是 ERP 系统，很多公司都经历过失败的实施项目，CEO 还会在电话会议上解释：“我们损失了几亿甚至几十亿美元，最后却连系统都没切换成功。”医院里也会出现这种情况。Epic 把整个公司都押在“项目实施不能失败”的声誉上，而这帮助它赢得了交易。

David：没错。我觉得这是客户喜欢 Epic 的最重要原因之一。

Ben：这期节目里我们会反复提到这一点。他们的客户很喜欢 Epic。我们说“客户”时，指的是医院 CEO、CIO（首席信息官）和 CFO。

当然，首席医疗官、医生、护士和护理人员也都和系统有关。不过我的研究让我发现，真正的采购客户是医院管理层。

David：我怀疑这在 Epic 内部都不算有争议。他们自己大概也认为，客户就是那些医院的 CEO、CIO 和 CFO。

所以 IBM 项目失败了。值得再说一点：这不只影响医院本身的运营表现，也伤害了医生和员工。IBM 实施失败对医生来说肯定非常糟糕，他们也需要稳定的工作系统。

Ben：医生为医院创造价值。因此，要让管理层保住工作，就必须让医生满意。医生在组织里有议价能力，因为他们提供了核心专业服务。但你去争取医院客户时，并不是直接向医生推销。

David：你可以把医院想成一家媒体公司。医生、护士和临床人员就像出镜的人才；而作出商业决策的并不是这些人才，而是 Disney、Universal 这类公司里的管理人员。

Ben：所以医疗人员会参与采购，但他们不是决策者。

David：Kaiser 现在必须重新招标。此时已经有足够多的 Portland 医生调到加州，开始称赞 Epic。他们说：“好吧，我们应该认真考虑这家小公司。”重新招标后，最终进入竞争的是 Epic 和主要对手 Cerner。

Cerner 是做什么的，我们之前还没怎么讲。它现在属于 Oracle，之后会再谈。Cerner 当时的规模大得多。

Ben：有意思的是，它们成立的时间差不多，对吧？

David：对，哇，我想 Cerner 也是 1979 年成立的，和 Epic 同一年。

Ben：没错，是 Neal Patterson 创办的。

David：Neal Patterson 在密苏里州 Kansas City 创办了 Cerner。它走的路线和 Epic 不同：Epic 选择不融资、不收购、坚持单一平台、永不上市；Cerner 则选择大量并购、融资、上市和扩大规模。

Ben：另一条路线也可能行得通。

David：确实行得通。

Ben：而且很长时间都发展得不错。

David：当时 Cerner 年收入接近 10 亿美元，是一家规模大得多的上市公司，也已走向国际市场。最后进入招标竞争的就是这两家公司。

Ben：值得一提的是，在被 Oracle 收购前，Cerner 是由 24 家公司合并起来的。看起来像一家完整公司，里面其实有很多并购整合的痕迹。

David：这和 Judy 选择的路线不同，但不是说 Cerner 的做法不好。当时 Cerner 确实是一款很有竞争力的产品。2003 年，Kaiser 显然更应该选择 Cerner。

他们实际上也试着选择 Cerner。Kaiser 找到 Cerner 和 Epic，说：“Cerner，你们最擅长医院住院业务，这是你们的核心，也最重要、规模最大。我们信任你们，也知道你们经验丰富。”

他们又对 Epic 说：“你们也有住院产品，但 2001 年才刚推出，经验还不够。你们在门诊方面很强，也为我们 Portland 的业务做得很好。我们想把工作拆开：门诊由 Epic 负责，住院由 Cerner 负责。”

Ben：对啊，这样做肯定没问题。

David：Judy 说：“不，这是个错误的决定。你们可以选我们，也可以选他们，但要为了患者、整个系统和账单正常运作着想，还要确保门诊诊所和医院之间能传递患者记录，这非常重要。你们应该只选一家。”

不过 Judy 这么说也有私心，因为 Cerner 的门诊产品并不出色。

Ben：这是一次经过计算的高风险决策。

David：但她敢这样说，确实非常大胆。她知道 Epic 两方面都有不错的产品，只是住院产品比较新，市场还不信任它。不过 Epic 仍是一家小公司：Cerner 的年收入已接近 10 亿美元，而 Epic 略高于 5,000 万美元。

之后招标继续推进。Kaiser 安排了一场技术尽职调查会议，要求两家公司解释系统如何处理 Kaiser 的并发数据交易量。别忘了，Kaiser 当时有 850 万患者和 11,000 名医生，系统负载非常大。

Ben：听众朋友，这是个很精彩的故事。已经到了交易的最后阶段，双方很接近作出决定，但还没有最终拍板。Kaiser 让两家公司在同一栋楼的不同会议室里分别陈述，整天在两边来回切换，每次和一家聊一小时，再根据另一家的陈述提出新问题。

如果你代表其中一家公司，就能从问题中猜出另一边在讲什么，也能知道为什么突然有人开始追问一个新话题。

David：Epic 团队原本准备从理论上讲解系统架构，也就是单一系统理论上能同时处理多少负载。

据说，Epic 总裁 Carl Dvorak 在汇报前一晚飞到加州，和团队见面后看了他们的计划，说：“不行，大家必须用 Excel 建模，准确算出 Kaiser 一整天的交易流程，以及我们的系统如何处理。要证明系统的处理能力远超需求，不会宕机。”

Ben：我想他们原本只做了理论公式。Carl 知道 Epic 在这方面有优势；如果把流程完整建模、把电子表格做好，就能证明系统的实际性能会更好。

David：于是他和团队在汇报前熬了一整夜做建模。我不知道 Judy 是否也在那里，我猜她也在。第二天，他们向 Kaiser 展示模型，Kaiser 则在两家公司的会议之间来回切换。

随着会议推进，Cerner 明显没有做同样深入的建模，也无法证明自己的系统能处理这些交易量。我觉得这就是局势开始转向的时刻，Epic 开始觉得：“我们可能要赢了。”

Ben：不过，结果没有立刻明朗。我想 Epic 在这件事上得了很多分，但据我了解，Kaiser 之后还找 Cerner 谈过股权交易：能否给 Cerner 一部分持股，换取这份大合同？我想 Cerner 答应了。

David：据我们听到的说法，最后关头，Kaiser 找两家公司说：“我们想在你们公司持有一部分股权。我们是美国最大的医疗系统，这将是你们能拿到的最大合同。我们希望你们给我们一些股权。”显然 Cerner 为这份交易提出了 10% 的股份。这说明合同对它有多重要。

Ben：于是他们又去找 Epic，说……

David：他们问 Epic：“你们怎么看？”Judy 说：“不，我们不会这么做。不只是不为你们这么做，我们不会为任何客户这么做。这样做不对。如果给你们股权，就得给所有大客户股权，最后对你们也不好。所以绝对不行。”但最终 Kaiser 仍然选择了 Epic。

Ben：Epic 凭借架构评估和坚持“你们只能选我们或他们”的立场赢得了合同，在整个谈判过程中都坚持原则。

David：这应该能说明，住院、门诊和账单系统之间的稳定性与连续性有多重要，因为只有 Epic 能提供这样的整合方案。

Ben：顺便说一下，我刚才说 Cerner 是由 24 家公司合并而成的。后来我看到的图表其实还没算上 Cerner 收购 Siemens。Siemens 本身又是由另外 12 家公司合并起来的。

David：我们稍后会聊 Siemens 的收购，我想那是 2014 年。但没错，这就是关键，也是 Epic 能胜出的原因。

Epic 赢得了合同，收入几乎一夜之间翻倍或翻三倍。合同公布时，《洛杉矶时报》写道：“Kaiser 的 Epic 系统可能成为这个行业的 T 型车：它不是第一款同类产品，却是第一款能服务大众的产品。”

从那一刻起，Epic 成为了新的行业黄金标准。如果你是一家医院系统，CIO 或 CEO 正在考虑重新招标电子病历系统，你会想：“最大的医疗系统刚刚选了 Epic，而且排除了所有这些不利理由后，还是选了它，说明它肯定有出色之处。”当然，之后你也会把 Epic 纳入考虑，而且它在评估中自然更有竞争力。

Ben：一开始这确实带来了一点帮助，但等系统正式上线、实施完成后过了几年，大家发现系统没有崩溃，运行也很顺利，真正的客户浪潮才在 2006、2007、2008 年前后涌来。

David：到 2007 年，Epic 的收入达到 5 亿美元。签下 Kaiser 后，他们的收入又增长了三倍，是之前的八倍，接近十倍。公司开始真正转变成一家大型企业。

Ben：我和一位前员工聊过公司的发展拐点。我问他什么时候发生的，他说：“赢下 Kaiser 合同前，我们每个月大概从大学招聘 10 个人；签约后，感觉每个月都有几百名毕业生涌进公司，我们终于能扩张了。”

David：这也会引出我们稍后要聊的话题：Epic 在威斯康星州 Verona 的大型园区。

Ben：对。按我们的叙事顺序，有件 2000 年代初发生的事刚才略过去了。它有点像 Epic 本可能走上的另一条历史路线。

想象一下，你是一家小公司，一家大公司找上门说：“我们能不能共同开发一款新产品？你可以卖给自己的客户，我们也会用自己的品牌卖给我们的客户，你还能分到部分收入。我们一起开发，这会推动你的业务。”

如果你没有经验，这听起来很诱人，也许会想：“我们应该这么做。”这样的合作确实有很多成功案例，所以更容易让人心动。我最喜欢的一个奇特失败案例，是 HP iPod。你们还记得吗？

David：当然记得。我想我可能有一台。不，我有一台 U2 版 iPod，就是红黑配色的那款。

Ben：听众朋友，自己去 Google 搜一下。那真是个奇怪的安排：iPod 背面印着 HP 的品牌。这足以说明当时 Apple 的处境有多弱，竟然愿意让 HP 把自己的品牌印在完全由 Apple 打造的产品上，以换取 HP 的分销渠道和部分收入。当然，这也能帮助 Apple 扩大生态，因为这款产品仍然使用 iTunes 等服务。

David：Epic 当时基本上也遇到了类似情况。荷兰公司 Philips 找上 Epic，希望共同开发一款专注放射科的产品。Epic 负责大部分开发工作，Philips 则拥有客户关系和分销渠道。

David：因为 Philips 可能在销售医疗设备。

Ben：没错。Philips 会获得 Epic 整套 IT 系统的许可，也会销售 Epic 已经提供的所有产品，并以 Philips Externity Enterprise 的品牌推向客户。客户买到的实际上是贴着 Philips 品牌的 Epic 系统。

David：有意思。我猜 Philips 在美国以外，可能也有很多客户，比如欧洲客户。这样就能帮助 Epic 进入国际市场。

Ben：所以 Epic 开始在荷兰招人，组建团队，花了一年甚至更久来开发产品。我想他们甚至正式推出了产品，但整个项目最后还是失败了。产品推出后一两年内就结束了，这是一次非常昂贵的弯路，公司因此对合作关系产生了强烈戒心。

Epic 团队从这次合作中得出的教训是：（a）组织外部的事情无法由我控制；（b）风险很大；（c）公司历史上从来没有成功的合作案例。这种依赖不可控。于是，他们形成了一种戒心：只专注于自己能控制的事情，直接面向客户，不要和其他公司搞复杂的合作整合。

这可能说得过于简单，但我觉得 Epic 后来形成的封闭、互操作性不足等 DNA，确实有一部分源自这次失败的合作。

David：完全没错，他们和 Philips 的合作关系后来才重新恢复，已经是 15 到 20 年之后了。

Ben：感谢 Health API Guy 提供这个线索。

到 2000 年代后期，Epic 的目标非常明确：所有东西都自己开发，自己争取大客户；坚持不谈判、不让出公司股份，价格就是价格，并确信自己能够兑现承诺。接下来该投资未来了，他们怎么做？

David：Verona 园区。可能只有少数听众了解 Epic，或者曾经和他们合作过，但如果你了解这家公司，肯定听说过他们的企业园区。

关于园区有两个故事。第一个是 Judy 的儿子当时在 Redmond 的 Microsoft 工作，做开发者。Judy 和 Carl 一直很欣赏 Microsoft 的做法。

有一次 Judy 去看儿子，就问他：“能不能带我参观一下 Redmond 园区？我们准备扩张，办公空间快不够了，我想看看那里的环境。”她非常喜欢 Redmond，我想任何去过那里的人都会喜欢。

Ben：尤其是当时，那还在 Googleplex 出现之前。Redmond 是童话般的科技园区。

David：那时它就像 Google 出现以前的 Google。Judy 会说：“这里就像大学校园，氛围真好。”

Ben：有运动场，有很多建筑，楼都不高，只有两三层或四层，户外空间和步行区域很多，每个人都有办公室，简直完美。

David：Judy 回去后，几乎照搬了 Microsoft 的园区策略。

Ben：他们之前一直在改造过的老校舍里办公。想想他们一路走来，再看看后来有机会建造的园区。那栋校舍翻修得很漂亮，不过……

David：那是在公司年收入达到 5 亿美元之前很久的事。

Ben：没错。

David：后来 Judy 在威斯康星州 Verona 买了 1,000 英亩农田。Verona 和 Redmond 一样，是位于 Madison 市郊、风景如画的地方，开车大约半小时。Redmond 在 Microsoft 扩建前也许同样很田园。虽然 Microsoft 几乎让 Redmond 因公司而发展起来，但在精神层面上，Epic 才是 Verona 的代表。他们在那里建起了令人惊叹的园区。

Ben：和 Microsoft 不同的是，Epic 园区没有那么实用主义。Epic 早就有童话般、异想天开的特点，从产品名称就能看出来。但 David，老校舍壁炉的故事是怎样的？

David：好，这就是 Epic 园区的第二个故事。正如你所说，Verona 园区建成前，Epic 总部位于 Madison 一栋买下并翻修的旧校舍里。设计师翻修时，想在一个主要会议室里加个壁炉，让它更有家的感觉。

Ben：就像 Wisconsin 湖边的小屋。

David：我甚至不确定是不是设计师先提出的。但我想 Judy 和公司当时觉得：“这里有点像 Wisconsin 湖畔的小屋，那就把这种风格发挥出来。”他们按小屋风格装饰，挂上雪鞋、毛皮和斧头之类的东西。最后它成了整栋楼里最受欢迎的房间。客户来 Madison 时总想在那间小屋风格的会议室里见面。后来他们要建新园区，心想：“把小屋的想法搬过来，再……”

Ben：大幅升级。

David：把它做到极致。

Ben：所以他们把童话般的元素放大了十倍来建设新园区。他们聘请了 2008 年翻修 Disneyland California Adventure 的那家设计公司。

David：我觉得实际情况更具体。他们聘请了两家建筑事务所，一家就是你说的那家，另一家则参与了 Microsoft Redmond 园区很多建筑的设计。

Ben：真的吗？哇。整个园区简直像《爱丽丝梦游仙境》，还有《哈利·波特》和《绿野仙踪》的风格。听众朋友，可以 Google 搜 Epic 的 Verona 园区，图片真的很夸张。它对刚毕业的大学生很有吸引力：他们想继续体验大学生活，也想在一家好玩、有趣的公司工作。

Epic 的文化似乎是两面并存，而且配合得很好：一面是滑稽、童话般的氛围，另一面是全力取胜、以绩效为导向的激烈竞争。理解这家公司时，必须同时看到这两种 DNA。我觉得这两方面都来自 Judy 本人。

David：完全正确，我百分之百同意。你刚才说“为什么要建这个园区”，我脚本里也写了这个问题，答案正是如此。我们招聘的是非常聪明、年轻、积极进取的大学毕业生，怎么让他们愿意来威斯康星州 Verona 工作？那就给他们打造一个理想乐园。

Ben：再说几个有意思的数据。园区占地 1,700 英亩，其中 410 英亩是校园，其余是农场。现在有 89 栋建筑、4 座室内礼堂，合计可容纳 18,000 人。最大的礼堂 Deep Space 是世界上最大的地下礼堂。

它有 11,400 个座位，是一座礼堂。想象一下，两座 Radio City Music Hall 的人数挤在一座地下礼堂里。座位数更接近 Chase Center 或篮球馆，而不是我能想到的其他礼堂。它向地下延伸 74 英尺。

他们建造时的想法是：“我们永远不会有 11,400 人。用它办全员大会就行了，没问题。也可以让所有客户和整个生态系统都来这里聚会。”当然，现在公司已经发展得太大了，不是所有员工都能一起坐进礼堂，甚至不是所有员工都能参加那里举办的全员大会。

建这个礼堂的想法来自每月全员大会。以前他们在电影院里开会，新园区也想有这样的场地。这很夸张。亲眼看到这栋建筑时，你根本无法相信它这么大。

David：好，我觉得现在正适合聊聊园区和 Epic 的企业文化。

Ben：对。首先必须理解，Judy 把 Epic 称为一家软件工厂。你会想：“这家公司怎么这么特别？”最重要的一点是，在 Judy 看来，他们既不收购其他公司，也没有软件开发之外的核心能力，本质上就是一家生产软件的工厂。他们招来开发者，生产供医疗行业使用的软件。

David：真有意思。她可能比时代早了一步……

Ben：现在大家说的 AI 工厂？

David：对，NVIDIA 和 Dell 现在都在说 AI 工厂。

Ben：完全正确。一旦你把 Epic 想成一家把开发者转化为医疗代码和医疗应用的工厂，很多事情就说得通了。这样的工厂，就该建在威斯康星州 Verona。

David：说到企业文化，园区最令人惊讶的事情之一是 Epic 有一份“十诫”。它就像 Moses 颁布的圣经十诫。他们把 Epic 十诫张贴在整个园区的每间洗手间和休息室里，而且向公众开放，除了洗手间，你可以直接进去看。

十诫的第一条是不上市，第二条是不收购其他公司，也不被收购。

Ben：顺便说一下，前两条其实不需要告诉普通员工，因为只有 CEO 才能决定这些事。把它们写成“十诫”挺有意思，说明 Judy 多希望这些理念深入每一位员工。

David：我觉得把它们张贴在洗手间里的另一个重要原因，是每位来访客户都能看到。它也在告诉客户：“我们永远不会上市，不会被收购，也不会收购其他公司。你们可以相信，这会是一个长期统一的系统。”

第三条：软件必须正常工作。第四条：现实要符合预期。第五条：即使是没有明说的承诺，也要兑现。第六条：专注于能力，不容忍平庸。第七条：有标准，而且公平待人。第八条：要有勇气，你所容忍的，就是你所认同的。第九条：教导公司的理念和文化。第十条：保持节俭，不要为了日常运营而负债。

Ben：这十条里没有一条提到医疗保健。我读的时候一直想：“我会不会看到‘每条生命都很重要’，或者‘患者是一切工作的中心’？”没有。这就是经营一家公司的方法，是我认为经营任何公司都应该遵循的原则。

David：而且具体来说，这确实是经营一家软件工厂的好方法。

Ben：他们还会在园区里敲婚礼钟，庆祝签下新客户。这说明他们怎么看待这种合作：客户和公司仿佛结了婚，要共度一生。

David：就像婚礼进行曲。这是他们版本的敲锣庆祝。

Ben：我们还没怎么讲员工在 Epic 的工作体验，现在正好谈谈。如果你是聪明、有抱负的大学毕业生，这会是一所特别棒的训练营。

有人指责 Epic 像邪教。不过它也有好的一面。公司会招刚毕业的新人，然后教会他们所有事情。我说“所有事情”不是夸张，包括怎样做笔记。

Epic 有一套用黄色法律便笺纸做笔记的方法，也有一套写电子邮件的方法。这些都是多年不断迭代、测试和分析后形成的成熟实践。

David：这很可能可以追溯到 Neil、Meditech，以及他们在波士顿共度的那三天。

Ben：他们的想法就是：“这绝对是最好的方法。”我们要教每个人怎样把所有事情做到最好，让大家在一定程度上像机器人一样一致。我们相信，只要你经过 Epic 体系的培训，出来后就能按照一套运作良好的方式工作，让同事之间能够真正彼此信任。

正因为信任度很高，公司里的中层管理者很少。每个人都理解同事工作的体系，因此不必有人时时管理混乱。大多数员工都是刚毕业就加入公司，在这里待了很久。

公司没有预算制度；只有在这种高度信任的环境里才能这么做。当然还是有财务控制，但 Judy 讲过一个故事：她去见客户，客户说：“这是正确的事，但今年没预算，只能推迟到明年。”她会说：“这太愚蠢了。”

或者客户会问：“今年能不能把这笔支出塞进去？如果今年不把预算花掉，我的预算就会被削减。”她会说：“这也很愚蠢。所以在我的公司里，我们不会设那种预算。”

公司对头衔也很不讲究。你可能有一张名片，上面只印着“实施”，无论你在公司工作了 20 年还是 6 个月，去客户那里开展项目时都用同一个头衔。所有员工都要参加沉浸式体验，开发者和其他员工必须到临床场景中，比如手术室，直接观察工作流程。

David：我觉得，一开始你得做五家客户，之后每年再增加一些。

Ben：哇。Y Combinator 经常说要和客户交流、花时间陪客户。Epic 一直这么做。其他公司后来才意识到，并把这套“Epic 做法”当成了准则。但 Epic 的每个人都会花时间去医疗机构工作、和客户交流，这确实非常有价值。

在开发者这边，他们有一套非常严格的软件开发方法，用来尽量减少错误。新员工加入后要接受六个月的强化培训。开始编程后，整个系统的设计目标是尽量缩短代码写好到接受测试之间的时间。一旦发现 bug，原开发者就会放下手头所有工作去修复它，因为他们脑子里还保留着刚写完代码时的完整上下文。不会等几个月后才进行系统测试，避免错误层层累积成更大的问题。bug 会尽早被发现。

David：我相信他们有条规定，每位开发者都必须修复自己写出的 bug。

Ben：我听说也是这样。这种软件工程方法比其他行业更重视零缺陷，因为出错可能会危及生命。它未必能让你以最快速度发布软件，也未必能做出最有创意、最前沿的产品，但会尽量确保发布的软件没有 bug。

David：我觉得有两个原因。第一，确实有人命攸关。如果处方剂量的医嘱因为 bug 出错，很多人可能会因此死亡。

第二，客户的收入周期和账单系统也极其重要，这些地方绝不能出错。否则最好的情况是医院损失大量收入，最坏的情况是因为医疗欺诈而面临联邦刑事指控。

Ben：说得好，所以我们需要……

David：极其可靠的系统。

Ben：没错。在 Epic 做实施项目的工作非常惊人，像军队级别的后勤管理。你得同时处理多个客户，而每个客户都是地球上最复杂的组织之一。

Peter Drucker 曾经说，医院是人类尝试管理过的最复杂组织。你每天都要了解客户的各种依赖关系，还要跟踪十几件彼此相关的事情。对一个非常年轻的人来说，这确实是一份高强度、高风险的领导工作。

你每天可能工作 10 到 12 小时，但很多人喜欢这份工作，因为他们不断获胜。刚毕业就能参与非常重要的项目，和其他聪明的人一起做事。因此公司会努力招聘高智商、高情商，通常性格温和的中西部年轻人，让他们承担面向客户的工作。

David：我觉得扁平组织也很重要。你能和资深员工一起工作，直接向他们学习。比如 Carl 和 Sumit 的故事：年轻程序员 Sumit 和身为程序员、同时领导团队的公司总裁 Carl 一起做项目。这种情况确实会发生。

Ben：如果你有抱负、重视职业发展，在高风险环境里和高绩效团队一起获胜，没有什么比这更有趣的了。再加上那些童话式的设计元素，大致就能概括 Epic 的文化。结果是，工作成了你生活中的头等大事。

和许多曾在那里工作、或仍在那里的员工聊过后，你会发现他们全身心投入其中，而且公司位于偏远地区。这也是园区的另一个作用：你不会经常接触到其他可以跳槽的机会，于是生活很容易完全围着 Epic 转。

David：你可以开车去附近的大城市 Madison。我知道我们一直拿园区作比较，这里确实和 Microsoft 很相似。它最让我想起的是早期的 Microsoft。我们采访过那些研究 80 年代和 90 年代 Microsoft 的人，他们描述的工作状态几乎一模一样。

Ben：我研究这期节目时也听到两三次有人拿 Palantir 作比较。聪明、积极的年轻人被派到非常艰难的环境中，但他们了解业务，接受过培训，也有很好的工具，能够把事情做成。

另一面是“不胜任就离开”。他们会积极淘汰表现最差的一部分员工，而且工作强度很大。每年有大量新员工加入，他们要尽快判断你是否适合这份工作。与其留下表现不佳、拖慢团队的人，重新招聘可能更划算。前几年人员流失很大，但如果有人留了一段时间，就说明他们表现不错，可以信赖。

他们的招聘方式很特别。现在编程测试越来越常见，但当年并不是这样。

David：这个故事太精彩了，我能讲吗？

Ben：请讲。

David：我们提过 Judy 的儿子在 Microsoft 做程序员，这也是她去参观园区的原因之一。他与公司的关系其实更早，在成为 Microsoft 程序员，甚至成年之前就开始了。

80 年代末，Judy 在招聘软件开发者时发现，面试并不能很好地预测谁会成为优秀程序员。与此同时，她的儿子大概上七年级，经常参加全州的编程比赛。她和儿子聊起这件事，他说：“我们参加编程比赛时会做测试，我有些测试还拿了奖。”这种测试或许能很好地判断一个人是不是优秀程序员。

Ben：这些测试确实有一定预测能力。

David：Judy 问他：“你能不能帮我设计一类这样的测试？我想用它来测试 Epic 的软件开发者候选人，看看他们水平如何。”

Ben：听众朋友，整整 18 年，这就是 Epic 用来判断是否录用员工的测试。他们很多时候，也许接近 100%，也可能是其中相当高的比例，根本不和候选人面试。他们相信测试足以预测表现。候选人考得好，就能收到录用通知，然后参观园区之类的。

而且不止这一种测试，还有 Rembrandt 测试等。所有测试都经过系统化整理和归档，每位新员工入职时都会参加。

David：对，公司里的每种职位都有对应测试。

Ben：我们听说连餐饮团队入职时都要做逻辑测试，虽然不是完整的软件开发者测试。

David：太不可思议了。对，Judy 的儿子十几岁时编写了第一套测试，现在已经不用了。我想答案后来被人发到了网上，但这套测试用了很长时间。故事很有趣，不过那是在 80 年代，远早于 Google 采用这些做法，那时这样的招聘方式非常超前。

Ben：我们聊了很多内部文化，但最重要、还没仔细讲的是 Epic 文化如何影响外部客户。Epic 非常以客户为中心，而我说的客户，就是前面定义的那些人。

University System for Health 的首席信息官 Jeff Gautney 有句很精彩的话：“即使 Epic 不便宜，付多少钱就能得到相应价值。”我们在客户访谈中一次又一次听到类似评价：系统可靠，能正常运行，不会过度承诺，而且如今已经充分整合。买 Epic 不会让你丢掉工作，就像过去大家说买 IBM 不会让你丢掉工作一样。

David：客户永远排第一，所有事情都围绕客户。

Ben：客户能够投票决定公司接下来开发什么。每年客户会来到园区参加大会，公司会征集功能建议，然后让客户投票，根据他们的意见决定下一步做什么。

David：公司基本只有三类岗位：软件开发者、负责新客户实施项目的项目经理，以及负责长期客户支持的技术专家。

公司没有销售或营销部门。大约只有八名“销售人员”，他们只负责回应主动找上门的客户，而且全都曾担任项目经理或技术专家。这就是销售团队的全部人员。

技术专家是公司最大的群体。Epic 有 600 多家医院系统客户，每家客户使用的每项产品都有自己的技术专家团队。医院可以为 EpicCare 电子病历、MyChart、Resolute、Cosmos 等所有使用中的产品配备专属团队。

此外，每家客户都有一位专属的 BFF，也就是“永远的好朋友”。这是 Epic 内部的一位员工，他唯一的工作就是确保客户能够成功使用 Epic 产品。

比如，公司每年会对客户进行评分，根据它们使用 Epic 工具的情况与其他客户比较。每年他们会分别给客户的 CEO、CIO 和 CFO 寄送报告卡，从多个方面按 1 到 5 分打分，再提供同类医院系统的基准数据进行比较。

Ben：哇，这真特别。

David：我从没听说过其他公司会做这种事。

Ben：Epic 在客户关系中拥有很强的影响力。以 2025 年为例，当客户想用某种方式做事、Epic 却认为应该采用另一种方式时，Epic 最终仍以客户为中心，会照客户的要求做；但它也会提出非常有说服力的理由，解释自己的方案为什么更好。这会让 Epic 更容易推行标准化方案。

许多医院使用 Cerner 时，每个实施项目都各不相同。Epic 则有明确的主张：请尽可能使用标准化配置，这样我们才能轻松推送更新、为你添加新模块，并确保互操作性按预期运行。

Epic 在谈判中拥有很强的议价能力，因为他们可以说：“我觉得你们还没准备好成为客户。今年我们会先把精力放在其他地方，只接 10 到 20 家，也许最多 30 家新客户。”

David：他们愿意等。

Ben：他们会说：“等你准备好和我们合作，我们再开始。”而现在，他们确实有底气这么做。

David：说到标准化实施，我相信客户想获得 Epic 折扣，唯一办法就是接受全部或大部分标准方案。可能会根据实施有多标准来划分不同级别。偏离标准越多，费用就越高。

Ben：我能理解这一点。我知道，如果客户及时进行数据库维护和版本升级之类的工作，Epic 会给折扣。

David：我们刚才说的似乎体现了 Epic 如何积累影响力，这确实如此。但公司和客户的关系中也有近乎利他主义的一面。我觉得这来自 Judy 的个人特质。

Ben：我会把这种企业描述为“利他型资本主义”：极具竞争力、努力实现价值最大化，同时也为客户着想。

David：我觉得这就是 Epic 的总结。尽管它价格不低，但几乎从不涨价。当然也涨过，但整体来看，平均每年只涨约 2%，低于通胀率。相比很多软件公司，这很不一样。他们还做过一些事，比如整个公司历史上从未涨过 MyChart 的价格。

Ben：我们多次听到这句话。我觉得这是个烟幕弹，因为我们不知道最终价格是多少。我们看到的只是零散信息，并没有拿到一份完整合同，能看清客户所有模块和子项目加起来究竟要付多少钱。

David：说得有道理。

Ben：有两点。没错，他们以客户为中心，也会听取客户意见。但他们做这些事当然也是为了 Epic 的长远利益。客户选择 Epic，核心原因是它能帮助医院把患者服务转化为尽可能多的收入，同时降低下行风险。

David：同时尽可能降低风险。

Ben：这就是客户选择 Epic 的原因。Epic 自己想做什么？它想赢得合同、长期留住客户，最终成为行业霸主。Epic 做的很多事情看起来非常以客户为中心，确实如此，但也能为 Epic 带来很大价值。

比如，市场上出现某种新软件时，Epic 会向客户推荐第三方产品。比如到了 2020 年，远程医疗突然变得非常重要，他们会说：“这里有一种符合 HIPAA 要求的 Zoom 使用方式。顺便说一下，我们也在开发自己的远程医疗产品，很快就会推出。现在你完全可以先用 Zoom。等我们的新模块推出后，它会免费提供给你，因为你已经是我们的客户。”

Ben：你肯定不会再去找其他产品，因为知道 Epic 最后会免费提供给你。你不会一推出就立刻采用，因为那时功能还很基础；但等它足够成熟，你就会想：“好，我现在直接用 Epic 的版本，反正它已经包含在企业协议里了。”这是一种非常聪明的捆绑策略，让我想起我们在 Microsoft 那期节目里聊过的内容。

David：你说得完全正确。

Ben：我觉得这是正确的理解方式。Epic 以客户为中心，是因为从长远看，这样做也对 Epic 有利。这并不是什么新发现。

我突然想起 Jeff Bezos 有一句话，我没写在笔记里，大意是从长远来看，客户的需求和 Amazon 的需求没有区别。我清楚记得他在 1999 年左右的某段很早期视频里说过这句话。

Epic 确实以客户为中心。再说一次，我们指的是医院系统的 CEO 和 CIO，因为只要服务好他们，长远来看 Epic 也会受益。

David：这就像……

Ben：这就是经营公司的目标。

David：这也是资本主义理论的基础，对吧？

Ben：没错。

David：总之，这是一种很有意思的企业文化和组织方式。

Ben：听众朋友，如果你了解这个行业，就知道我们还没讲到真正重要的部分。我们已经讲了 Kaiser 合同，也讲了 Epic 搬到 Verona。

理解这些文化很重要，不过很多记者只会抓住园区这种可爱有趣的元素，说：“这个园区很酷，我该去拍些照片写篇好玩的报道。”

但真正改变行业的大事发生在大衰退时期，以及一项法案通过之后。它彻底改变了行业，带来了很多好处，也造成了很多问题。

Ben：好，我们来到 2000 年代。刚讲完 Verona 园区，现在至少从外部观察，我们已经了解了 Epic 的文化。2006 年前后是个很有意思的时期。

那时美国正处于 Bush 政府时期。Bush 在国情咨文中说：“对所有美国人来说，我们必须应对不断上涨的医疗成本，加强医患关系，帮助人们负担所需的保险。我们会更广泛地使用电子记录和其他医疗信息技术，控制成本并减少危险的医疗错误。”这番话赢得了热烈掌声。

David：研究这个话题时，有一件事让我特别惊讶。外界常见的说法，包括我以前了解或注意到的情况，都是 Obama 政府和 Obamacare 推动了电子病历采用、meaningful use 等改革。事实上，这完全是两党共同推动的，而且最早始于 Bush 政府。

Ben：这也能让你看看，党派立场会如何随着时间而改变。Bush 的下一段讲话是：“我们要让保险覆盖更具可转移性，让员工换工作时不用担心医疗保险。”很有意思。如果四年后有共和党人在 Obama 时期谈论让保险在不同雇主之间转移，听起来可能会很令人担忧。

David：真有意思。

Ben：你开始看到一种政治共识：大家都希望医疗记录系统变好。我们笼统地认为，推广电子病历会带来很多好处。

David：我觉得背后还有更深层的动机。2006 年时，美国人普遍知道现行医疗体系很糟糕。它当然有好的方面，但总体而言，成本上涨失控，占 GDP 的比例很大，效率也极低。我们想办法解决这个问题。

Ben：但大家并不都同意该怎么解决。

David：我们不知道该怎么解决。不过，数字化医疗记录并通过激励机制推动电子病历采用，被视为可能帮助我们摆脱困境的承诺。对吧？

Ben：听起来像是朝正确方向迈出的一步。

David：当时美国只有 13% 的医疗机构使用电子健康记录系统。到了 2000 年代中期，整个行业还远未数字化。

Ben：有些人会质疑 13% 这个数字，说电子健康记录的定义刚刚改变，所以实际采用的机构比 13% 多。但我们能找到的最好数据就是这个。

David：有道理。

Ben：在介绍法案和后续情况之前，还得先了解另一个概念：互操作性。每次提到 Epic 或任何电子健康记录系统都会谈到它，有必要先区分几种情况。

第一种，也是最简单的，是 Epic 对 Epic，也就是两家医院都用 Epic。我想把自己的记录从一家医院转到另一家医院，它们使用相同技术，理论上应该很容易转移。

第二种是 Epic 和另一家医院使用的电子病历系统之间互通，比如 Epic 与 Cerner、Meditech、Allscripts 或某家医院自行开发的系统。你可以想象，技术上会难得多。

David：它们采用不同架构。除了 Meditech 之外，其他系统可能都不是单一数据库，等等。

Ben：而且这个行业的标准远不如 SaaS 软件行业那么标准化，也不像更简单的企业对企业软件领域。

在讲第三种情况前，先想想其中可能存在的激励。Epic 把数据转给另一家 Epic 医院，当然容易。如果两家医院是竞争对手，可能不太想支持数据转移，除非这明显符合患者利益，至少会对此比较敏感。Epic 把数据转给使用另一套电子病历的医院，医院可能不愿意，Epic 也可能不喜欢。

David：双方利益都不希望这件事发生。Epic 不想，医院也不想。

Ben：他们也会提出很多很好的理由，解释自己为什么支持数据共享。但我们也得直说：除了符合患者利益，大家都应该以患者利益为重之外，Epic 并没有商业理由特别希望数据转给竞争对手，而患者通常会在多个地方接受医疗服务。

第三种是 Epic 与想读取 Epic 数据、在 Epic 上运行或以某种方式与 Epic 互通的第三方应用之间的连接。Epic 多年来一直非常谨慎，原因很充分。

你不希望患者数据泄露。Epic 曾公开说，他们从来没有发生过 Cambridge Analytica 那样的事件，因为他们在向其他应用开发者分享数据时格外谨慎。但结果是，作为应用开发者，和 Epic 整合比在其他任何软件行业都困难得多。

David：再说一次，谨慎当然有充分理由，我们处理的是 HIPAA 保护的数据。但这种做法显然也很符合 Epic 自身利益。

Ben：作为一项策略，这确实很方便。至于第一种情况，也就是 Epic 对 Epic，实际上体验非常好。他们有一项叫 Care Everywhere 的服务。如今每天会交换 2,000 万份患者记录。我在准备这期节目时用它把自己在西雅图三个医疗系统里的 MyChart 账户连在一起，体验似乎很顺畅。

这项功能的诞生过程也很有意思。Judy 亲自决定，Care Everywhere 不能由客户自行选择是否启用。只要是 Epic 的客户，即使彼此是当地竞争对手，这项功能也应该覆盖他们。

故事是这样的：最早接受这款带有 Care Everywhere 功能的新软件的客户，当时并不知道其中包含这项互操作功能。后来那位客户承认，如果他当时知道合同里包含这项功能，自己可能会拒绝。

David：那是那家医疗系统的 CEO，他后来承认了这一点。

Ben：Judy 说，Epic 能够继续推进这项功能纯属运气。赢得第一个客户后，他们就规定所有客户都必须启用，并为旧版软件补上 Care Everywhere。这样，美国所有 Epic 客户都能互相分享记录。

这是 Epic 的宣传重点：“我们的互操作性很强，我们推出了 Care Everywhere，一直在交换数百万、数千万份记录。”

David：他们会说，自己分享的医疗记录比任何人都多。

Ben：所以到了 2008 年，你应该了解 Epic 在互操作性问题上的历史：他们认为自己已经通过偏好的方式做了很多互操作工作。几乎没有任何一家公司真正做好了互操作性。我看过一些医疗系统管理人员的访谈，他们认为这个行业的互操作性简直不可想象。除非被迫，没人有动力互相分享。技术很复杂，还伴随很多风险。

David：一位 CIO 和我聊这个话题时，用了一个有意思的比喻。因为这是患者和健康数据，我们会觉得互操作性应该存在，数据应该能到处共享。当然，我们当然希望如此，我完全不想贬低这一点。

不过他让我想象另一个行业，比如航空业。United 会把客户数据分享给 Delta 吗？

Ben：即使这样做对客户有好处？

David：即使数据属于客户，他们也不会分享，当然不会。我愿意把患者的数据分享给附近的竞争对手吗？当然不愿意。

Ben：这时候你就会感受到冲突。我想听众现在也会有情绪反应：你内心的资本家会想：“这是一家企业，它就应该做对自己有利的事。”

你内心作为社会成员和患者的那一面又会想：“也许吧，但这个行业不该受到资本主义负面影响。它应该有不同的运作方式。”你可能觉得商业利益影响医疗服务很不舒服。你应该感受到这种张力，因为这是一个两方面都成立的问题。

David：这概括了整个医疗行业。别搞错了，这是一个营利行业，同时受到严格监管，也有各种复杂问题。

Ben：好，接下来进入正题。2008 年，全球金融危机爆发。我们应该单独做一期节目，聊聊金融危机、经济崩溃、政府救助，以及我们如何避免国家和全球经济一起崩溃。我们最终挺了过来。花了一些时间，但确实恢复了。

David：而恢复经济的一部分做法，和新冠疫情期间类似，就是政府说：“好，我们需要……”

Ben：经济刺激，对吧。

David：……我们需要经济刺激，需要一些可以向经济注入资金的项目。

Ben：利率降到零，到处发钱，打开印钞机，想办法让人们开始做有生产力的事情，并给予相应奖励。

David：一方面是把利率降到零的货币政策，另一方面还有财政政策：我们要把资金直接撒进经济里。

Ben：问题是要把钱撒进经济时，可以直接给每个人寄支票，就像新冠期间做的那样。

David：但这不是最理想的做法。

Ben：更有生产力的做法，可以追溯到 FDR 新政时期的 Civilian Conservation Corps：寻找已经准备好、全社会都认同是好主意的项目。有哪些好主意值得国家去做？我们就通过法律拨款，奖励人们去做这些原本就值得做的事情。

这样希望能一举两得：一方面把钱发出去，创造就业和经济活动；另一方面完成大家都认为有价值的事情。电子病历显然是一个现成的好项目。那就立法吧，终于把它推广起来。

所以目标包括：（1）用财政刺激帮助大衰退后的经济复苏；（2）推动采用电子健康记录；（3）推动实际使用电子健康记录，这和采用本身不同……

David：也就是“有意义的使用”。

Ben：……电子健康记录。我们不只希望有人安装系统却从不登录，还希望他们经常登录、真正使用它。还要推动互操作标准，让全国各地的医疗服务提供者都能分享患者数据。这些就是 HITECH 法案的目标。

David：也就是 2009 年的《健康信息技术促进经济和临床健康法案》。

Ben：我喜欢他们给法案取名字的方式。

David：我知道。后来它被纳入近 1 万亿美元的《美国复苏与再投资法案》。

Ben：法案的具体安排是这样的：2009 年法案通过时，政府拨出 270 亿美元，直接奖励实施电子病历系统的医院。如果把其他更广泛的激励措施、其他医疗 IT 项目、数据交换和培训都算进去，总额实际上达到 360 亿美元。

这太惊人了。想象一下，你是一家软件初创公司，政府开始给你的客户寄支票。客户不仅因为注册成为客户、购买软件就能拿钱，实际使用软件还会拿到更多钱。这是软件供应商最希望发生的事。

David：政府就像对你的客户说：“我会给你钱，但这是一张专款专用卡。你只能、也必须用这笔钱购买这家初创公司的产品，而且之后还必须实际使用。如果你不购买、不使用，不但拿不到钱，我还会罚你，让你倒过来付钱给我。”

Ben：胡萝卜加大棒。具体来说，在几年时间里，每位医生采用系统可带来 44,000 至 64,000 美元的奖励。钱实际付给医院，但基本上会按照使用系统的医生人数计算。

David：想想 Kaiser 这样有 11,000 名医生的大型医疗系统，这可是一大笔钱。

Ben：HITECH 法案里有个短语叫“有意义的使用”。这是个很特别的词组，在医疗行业里，只要你说“有意义的使用”或简称 MU，大家马上就会有反应。

起初“有意义的使用”是胡萝卜，之后又变成大棒。正如你说的，大约五年后刺激资金用完，医疗系统如果没有有意义地使用电子健康记录等医疗 IT 软件，就会面临巨额罚款。

KFF 有一篇文章叫《千次点击致死》，引用了这个情况。时任 EHR 厂商 NextGen Healthcare CEO 的 Rusty Frantz 说：“当时 EHR 供应商还只是一个年收入 20 亿美元、处境艰难的行业。大家抱怨要求太多，但政府注入 360 亿美元，收益实在太大，所以整个行业都排队参与。”他还说：“当时整个行业的想法就是，政府把支票放在我面前，我只要勾选这些项目就能拿到钱，那我当然会去做。”NextGen 是 Epic 排名前十的竞争对手之一。

如果你想把这件事看作 Epic 的巨大胜利，确实如此，但也并非完全是好事。为了确保产品准确符合奖励要求，他们必须完成很多繁琐步骤。整个行业都不得不投入大量开发时间、重新安排公司优先事项，确保产品符合 HITECH 法案规定的要求。

David：情况比“这对 Epic 很有利”更复杂。它当然对 Epic 很有利，但这其实对整个电子病历行业都有利。行业内部的竞争格局是另一个问题。

Ben：好，那谁最受益？可能是最可靠的厂商。如果医院本来不打算采用电子健康记录，现在面前有一张政府支票，我肯定会选集成程度最高、100% 确定能够运行的系统，不愿承担任何风险。

而且我听说 Epic 的产品价格不便宜。不过现在既然几乎是免费的，那价格贵不贵也无所谓，我就买最好的。

David：实际上等于免费。

Ben：Epic 是高价、高价值、而且可以信赖的供应商，风险又最低，因此在这种环境下会胜出。

David：说得好。这就像政府刺激你去买手提包，你可以买 Target 的包，也可以买 Birkin 包，反正都免费。

Ben：虽然不完全是这样，但大致可以这么理解。还有意思的是，这套机制奖励的是最可靠的软件，不一定是最有创新性的。当奖励取决于系统是否真正上线、是否达到有意义的使用标准时，你就不敢冒风险，最终会选择那个肯定能运行的系统。

HITECH 实际上带来了什么？我们逐一来看它的目标。它有没有加快使用？绝对有。电子健康记录在医院中的普及率，从 2009 年的 9% 提高到 2014 年的 95%。太惊人了。David，你还听说过哪些市场在五年内从几乎无人使用变成几乎人人使用？

David：疫情期间的一些软件类别。

Ben：说得好。

David：也许疫情期间的 Zoom 是最接近的例子。

Ben：作为 Epic 员工，突然发现自己的产品类别对所有潜在客户都像是免费的一样，这太不可思议了。数字化对患者也很有帮助，尽管很多医生会抱怨。就像我们谈到 MyChart 时说的，能直接给医生发消息、查看自己的医疗记录，确实很好。

David：还可以自己预约、使用所有这些功能，也可以管理家人的医疗照护。

Ben：没错。接下来一个目标是降低成本。关于电子健康记录是否普遍降低成本，数据有正反两面。我们找到一个说法，声称引入电子健康记录后，医院成本下降了 10%。但也有人认为，采用电子病历可能使不必要的诊疗增加，也让医院为相同手术使用更多或金额更高的账单代码。

这就是“电子病历有没有降低系统成本”的另一种观点。批评者说，现在诊室里针对同样的医疗程序开出了更多医嘱。坦率地说，医院购买电子病历的部分目的正是如此。目标之一就是提高收入。

David：再说一次，这些机构都是商业组织。虽然很多可能是非营利机构，或属于大学系统，但归根结底，医院会产生收入，也有管理团队；主要员工是医生和护士，他们也希望赚钱。人们去医学院成为医生或护士，是为了找到好工作、过上不错的生活。

Ben：当然还有职业声望和帮助他人的愿望，但这也是一份高薪工作。有一篇很棒的文章叫《Epic 式反乌托邦》。我得说明，这篇文章的观点比较片面。

David：是 The American Prospect 的那篇文章吗？

Ben：对。里面引用了一位医生的话，她说主管经常联系她问：“那次预约你只记成了 2 级。你不觉得应该记成 3 级吗？”显然，记成 3 级可能会让保险公司支付更多费用。

另一个人这样说：“如果你做了 X，在那次就诊中几乎肯定也做了 Y。用了这些代码，你就能多收一些费用。如果你有一套计算机系统，而不是没有，更有可能把更多项目记到账单上。”这是反对大规模推广电子病历会降低系统成本的一种观点。

数据互操作性呢？基本没有。立法对“有意义的使用”有明确要求，却没有严格规定人们谈到的数据标准。互操作性虽是法案目标之一，但没有像有意义的使用那样提供专门奖励。于是大家自然会跟着激励机制走。

数据互操作性实际上并没有实现，这对 Epic 来说很方便。Epic 拥有一整套自己开发的系统，不需要与其他系统集成，也能让整套软件发挥作用。作为行业领先者，又能独立提供所有功能，他们不需要互操作性；而立法也没有明确奖励这一点，所以客户也没有优先考虑。

David：这里确实有一项事实可能让 Epic 受到批评：整个过程中，Judy 都是 Obama 政府医疗 IT 委员会的成员，该委员会为政府制定 HITECH 法案提供建议。

Ben：其他竞争者也有人参与其他委员会。并不是只有她一个人在政府里发声。

David：对。提出这种批评的人经常忽略了一个有利于 Epic 的事实：Cerner、Allscripts 等其他竞争者也都有人在这些委员会里。

Ben：不过看看互操作性这件事。它当时没有实现，但 15 年后的今天进展更多了。至少现在有了数字化记录的基础，随着后续推动，各系统可以逐渐提高互操作性。没有基本的系统可操作性，就无从谈互操作。

David：对我来说，这就是 HITECH 法案和“有意义的使用”给电子病历行业带来的启示。只要政府介入并扭曲市场，就会出现一些奇怪的结果。尤其是当政府规定市场中的产品应该如何开发和使用时，情况就会变得非常混乱。

Ben：这件事有两个非常糟糕的副作用。第一，国会明确规定什么叫“有意义的使用”，无意中设计了软件、指定了功能，还无意中告诉医生该怎么工作。

现在医生得在界面上点击九个以前不必点击的选项。有些是医院系统实施得不好，有些是软件太复杂，但很多都是为了确保……

David：这是法律要求的内容。

Ben：没错，必须符合“有意义的使用”要求，这样医院才不会受到经济处罚。

David：我觉得这是“有意义的使用”最令人遗憾的地方。

Ben：我觉得这是第二严重的问题。最大的问题是，它整体上提高了行医的监管负担。现在医院可能面临高额罚款，所以到处都是强制填写的字段和工作流程。即使刺激资金用完后，这些要求仍然存在。整个行业的运营开销普遍增加了。

现在大家优化的目标变成了依法满足 MU 的定义，而不是遵循它的初衷，也就是帮助医生和患者从系统中获得更多价值。结果之一是医疗系统不断与其他系统合并。合并本来就是既有趋势，但这项法案无疑加快了趋势。最终系统里有了更多管理成本、更繁重的监管、更多琐事和浪费。

David：这些后果显然很糟。但替代方案是什么？继续用纸质系统吗？那也不好。至少现在电子病历已经得到普及。

Ben：很多人最后只得出这个结论：至少实现了普及。数字化肯定更好，但这是最好的数字化方式吗？不是。数字化总体上是好事吗？是。

David：如果从非常宏观的角度看，我觉得最该肯定的是推动这一切的政府和立法者。他们的目标真的是创造就业、刺激经济吗？如果是，成绩可以打 A+。这项计划确实创造了很多工作。

Ben：医疗行业的就业岗位占 GDP 的 18%，因此它已经成为社会的重要组成部分，无论这是好是坏。

David：还有相关领域的岗位，比如医院 IT 管理员和 Epic 系统管理员。它们提供了大量不错的工作。这些都是美国本土的工作，不依赖进口，也不依赖制造业，为很多人创造了可行且很好的职业道路。从政策角度看，这或许不算坏事。

Ben：不行，我不喜欢这个结论，David。

David：我不是说我喜欢把创造就业当成政策目标。我只是说，如果从很宏观的角度看，政府这么做的目标是什么？它成功了吗？如果目标是这样，那它确实成功了。

Ben：在我们确实需要刺激经济的那个时期，这项财政刺激是有益的。但政府是否应该长期用纳税人的钱扶持某个行业，在行业里创造并维持大量岗位？绝对不应该。

这个标准太低了。给大家寄支票也能刺激经济。我认为这项计划确实刺激了经济，还附带了一张免费的“优惠券”：我们至少获得了一些电子医疗记录。它们虽然不能互操作，也不是国家最理想的系统，但比如果没有刺激计划会得到的系统更好，而且这份好处是随刺激资金一起送来的。

David：回到 Epic 的故事。

Ben：那么，“有意义的使用”对 Epic 有什么作用？如果退一步想，政府花钱让整个行业采用新技术，实际上就是把未来提前了。原本这些事情迟早都会发生，政府只是想让它们现在就发生。

David：说清楚一点，我觉得即使没有“有意义的使用”，特别是在赢下 Kaiser 之后，Epic 也会成为主导者。他们已经开始在竞争中脱颖而出。

Ben：这正是问题所在。他们当时确实开始这么做了。但政府要是拿出 360 亿美元来解决问题，必然会让其他可能成为主导者的新公司很难进入市场。现有竞争者就成了接下来要考虑的全部对象，政府认为这些公司已经足够可靠，项目也已经成熟到可以全面推广，应该让最好的几家广泛实施。这些系统一旦部署，可能就会用上几十年。

David：这里的转换成本非常高。

Ben：这是个合理的取舍。我甚至不觉得立法时的人有意做出这样的取舍，但结果确实如此。HITECH 通过之后，理论上更具创新性的电子病历系统很难再出现，至少很长一段时间内如此。

David：因为政府把原本会分散到多个年份的大量招标集中在同一时间点。多数机构选择了 Epic，尽管它们可能本来就会选 Epic；但很多招标本来会发生在以后，那时可能已有其他竞争者出现。

Ben：后来出现的那些理论上更创新的新竞争者，就没有机会参与竞争这些绿地项目，只能和客户现有系统竞争。

David：我同意。

Ben：不过这有点吹毛求疵。关键是我们到底在为谁敞开大门。如果要找监管俘获的直接证据，我觉得更准确的说法是，监管为 Epic 带来了顺风，而不是 Epic 俘获了监管。我不认为 Epic 的人也很喜欢这套过程。我的感觉是，他们本来就会拿下这个市场，却被迫以一种像弗兰肯斯坦怪物一样拼凑的方式做产品。

David：这确实让产品变得更差。

Ben：产品变差了，所有人的负担也加重了。但市场更可能由 Epic 主导，因为如果一件原本五年后才会发生的事现在就要发生，大家宁愿现在就做完，而且确保一定成功。

David：但他们肯定不喜欢医生每次看诊都要勾选 57 个框。

Ben：这一堆合规负担，加上软件本身确实很难用……

David：这是法律规定的？

Ben：对。

David：由立法来设计产品开发，而且这不只是 Epic 的问题，所有厂商都一样。

Ben：还有这么大型的软件本身就很复杂，涉及许多不同界面和参与者。一个常见批评是，电子病历占用了医生照顾患者的时间。

有一项 2016 年研究发现，医生每花一小时面对面照顾患者，就要花大约两小时在电子健康记录中输入数据。还有其他研究显示，医生现在每天工作 11 到 12 个小时，不停地回复消息。当然，这也与医院系统的配置有关，消息可以通过分诊等方式处理。

David：HITECH 法案和“有意义的使用”还有一个缺点：数字化之前，很多医院规定和指南不一定总被遵循，而在医院里，不遵守某些流程有时反而更好。

例如，按规定应该由医生亲自开药物、处方或影像检查的医嘱。但在所有工作迁入电子病历之前，医生理应亲自下医嘱，实际操作却常由医疗助理完成。如果你每天看 20 位患者，其中很多人需要影像检查、药物或其他治疗，你可以对医疗助理说：“把这些都处理一下。”他们可以在白天完成。

Ben：我晚点再全部签字。

David：没错。但当所有操作数字化并记录在电子病历里，规章就必须严格遵守，因为系统会追踪。这意味着医生不能再像以前那样借助其他工作人员来分担工作。

Ben：这很有意思。这也是医生倦怠的原因之一。不过也得和过去比较。1970 年有一项著名研究发现，管理纸质病历等沟通工作占医院总运营成本的 35% 到 39%。这不是医生个人的工作时间，但尤其在纸质病历时代，它一直给医院带来大量成本和耗时工作。

David：从某种角度看，你只是把负担从一处转移到另一处，同时又因“有意义的使用”规定增加了负担。但这不是新问题。

Ben：你知道谁也不喜欢这件事吗？2017 年，Obama 在接受 Vox 采访时说，他觉得 HITECH 法案没有达到预期。他说：“现在仍然有大量文书工作，医生还得输入信息，护士也把时间都花在行政工作上。我们投入了大笔资金，鼓励大家数字化、追赶世界其他地区，但这比我们预想的要难得多。”

不过这段话我不觉得主要是在说数字化进度落后于世界其他地区。我觉得美国在数字化方面是领先的。如果目标是降低成本，使美国医疗支出能与世界其他地方持平，那当然很好，但这并没有发生。

David：一位 CIO 说过一句很好的话：“HITECH 法案中的‘有意义的使用’极大推动了整个行业的数字化，但对行业的数字化转型几乎毫无作用。我们实现了数字化，却没有完成转型，而我觉得人们当初乐观地期待会发生后者。”

Ben：有意思。好消息是，现在所有记录都已数字化，未来仍有机会实现真正的转型。

David：对，数字化已经完成了。

Ben：现在可以用这些数据做以前做不到的有趣事情了。

David：过几分钟讲到故事结尾时我们还会聊这个。至少目前看来，人工智能，尤其是环境式 AI，有望让很多繁琐流程在人们不知不觉中消失。

在这一切发生的同时，Epic 继续一路获胜。2011 年，公司收入达到 10 亿美元。它不断赢得大型系统的招标，包括 Johns Hopkins、Cedars-Sinai、UCSF 等，名单还很长。

Epic 的竞争对手一直在合并和整合。HITECH 法案通过后，这种行业整合明显加快。整合的结果都会让 Epic 受益，因为系统越复杂，组合在一起越难稳定运行，Epic 的优势也就越明显。

2008 年，Allscripts 与 Misys 合并。2010 年，合并后的 Allscripts 又与 Eclipsys 合并。他们继续收购更小的厂商。如今这家公司叫 Veradigm。2011 年，Meditech 收购了 LSS Data Systems。随后在 2014 年 8 月，前面提到的大型并购之一发生了：Cerner 以 13 亿美元收购 Siemens Health。

Ben：我听到的说法是，这笔交易让 Cerner 开始走下坡路。

David：研究时我听说，即使到了 2025 年，客户还会自称是 Siemens 客户或 Cerner 客户，系统仍未完全整合。

Ben：而且 Oracle 收购之后，听说他们又想重写整个系统。

David：那件事进展也不顺利，我们之后会再聊。这就把故事带到了国防部合同。

Ben：这是电子病历行业最大的机会。

David：退伍军人事务部合同，也是最大的机会。如果你是美国纳税人，这又可能是美国政府浪费行为的最大体现。

Ben：好，David，接下来谈谈国防部项目的惨败。

David：2015 年，国防部决定为军方所有医院和医疗服务招标一套全球电子健康记录系统。最初的范围只包括现役军人，与后来会提到的退伍军人事务部（VA）系统不同，VA 服务的是所有美国退伍军人。

2015 年这个项目是当时有史以来最大的医疗 IT 合同，最终价值 43 亿美元，比 Kaiser 项目还大。两年后，VA 合同招标，金额达到 100 亿美元，超过了它。Epic 当然参与了这两个项目，结果也和 Kaiser 项目一样，最后由 Epic 和 Cerner 竞争。

Ben：但也不是两家公司直接竞标，因为这个体系本身非常荒唐。除非你经常承接政府合同，否则几乎不可能直接参加政府招标。你必须与大型承包商合作，由他们分包；这些公司的主要业务就是承接美国政府合同。

David：两家公司各自找合作伙伴，过程中争议不断。正如我们后面会看到的，各方都开始互相攻击。只要赢下其中一个或两个合同，公司未来好多年都能有业务。

尽管过程充满争议，Cerner 最终赢得了国防部和 VA 两个合同。和许多大型政府项目一样，它们都严重超时、超支。后果非常糟糕。现役军人使用的国防部系统直到 2024 年，也就是去年年底，才终于全面上线。从 2015 年招标到上线，实施花了九年。VA 系统更糟糕，至今远未全面上线。

Ben：两个合同都是 Cerner 赢的吗？

David：Cerner 是作为分包商赢得这两个项目的。VA 项目在 2017 年招标。VA 最近一次发布的项目进度公告说，所有 VA 站点“最早可能在 2031 年”上线。

Ben：什么？

David：就连他们所说、但看起来非常不可能实现的最乐观情况，也是一个长达 14 年的项目。

Ben：我最近看到的消息是系统仍未全面上线。他们居然说“最早可能在 2031 年”。

David：现在确实有几个站点上线了，不是说过去十年什么都没发生。但天哪，如果你是美国公民或观察者，对“有意义的使用”感到恶心，那作为纳税人看到这种情况更是让人无法接受。

Ben：为什么会这样？项目为什么花了这么久，或为什么这么贵？

David：我不完全清楚，可能有很多原因共同造成。

Ben：或者说，背后的激励是什么？

David：很遗憾，政府合同有句老话：“失败的政府合同比成功的合同更赚钱。”我想这里适用的激励大概就是这样。

Ben：因为只要合同还没结束、项目还在实施，就可以继续追加成本。

David：也就可以继续拿到款项。我认为把责任全推给 Cerner 不公平，也许他们有一部分责任，但他们只是大型政府总承包商的分包商。

我们在 Lockheed 那期节目里聊过类似情况。这就是如今军工复合体的运作方式。政府、军方和电子病历项目都有层层叠加的官僚体系，最后形成一团复杂混乱。这样的项目一做就是几十年，花掉几十亿美元的纳税人资金，却仍未全面上线，实在令人崩溃。

Ben：你觉得 Epic 会庆幸自己没有赢得合同吗？

David：Epic 确实参加了招标，也提交了方案，我相信他们肯定想赢。

Ben：光是最初的 100 亿美元合同金额、还没算超支，就相当于 Epic 今天收入的两倍，这本来可以成为改变公司命运的大项目。

David：是的，就像当年 Kaiser 合同改变了 Epic 一样。但和 Epic 的 CIO 客户及其他受访者聊过后，我听到他们都长舒一口气，庆幸 Epic 没有赢得这份合同。

Ben：因为 Cerner 深陷项目泥潭。

David：没错，他们被拖进了泥潭，而且还有很多其他问题叠加在一起。正如我们说过的，收购 Siemens 之后，Cerner 已经整合了大约 36 家公司。创始人、首席信息官、长期领导者 Neal Patterson 在这段时期患癌，并于 2017 年去世。也就是说，在这个极其复杂的项目过程中，公司的创始人和领导者离世了。

之后几年里，Cerner 换了好几任领导者。Epic 则没有陷入国防部和 VA 项目的烂摊子，继续一份接一份赢得大型医疗系统合同。

Ben：这也体现了 Judy 对公司经营的理念。我们要极度专注，按一套很明确的流程办事，倾听客户，并兑现承诺。

David：我们必须坚持高标准的软件工程和产品架构。

Ben：客户发现新的使用场景时，我们也会开发相应的软件。Judy 以一种不寻常的方式经营公司，但这种做法正好适合赢得这个市场。

David：国防部项目之后，Epic 赢得了波士顿的 Partners Healthcare，也就是 Harvard 和 Massachusetts General Hospital（MGH）合并后的新机构。它还是最早的大型研究机构之一。他们还赢得了 Mayo Clinic 的整个系统，也就是最大的合同之一。后来又赢得英国的 Cambridge、Intermountain Health 和近期的 CommonSpirit Health。这样的例子还很多。

2018 年，Epic 的收入达到 27 亿美元。他们宣布，美国新闻与世界报道排名前 20 的学术医院全都在使用 Epic。这对他们非常重要，因为赢得顶尖学术医院，就意味着那些在这里学习、受训的新医生和护士都会使用 Epic。

Ben：我想他们还会单独向学校出售教育许可。他们似乎把大学医院和学术课堂分开处理。我相信医院里使用这个系统很有帮助，不过学校可能也会单独购买。

David：我相信是这样。而且医学教育有很大一部分是在医院里进行的。

Ben：我想现在 90% 的医学院学生都在使用 Epic 培训。

David：这是目前公布的数据。2019 年 Epic 的收入达到 32 亿美元。然后在 2021 年 12 月，正如我们刚才提到的，Oracle 以 280 亿美元收购了 Cerner。

正如我们讨论过的，Cerner 当时以及现在都是一家大公司，多年来收购了很多公司，业务收入很可观，拥有庞大的国际业务，还在负责国防部和 VA 项目，这些项目带来很多收入。它的年收入大约是 55 亿美元，可能还多一点，但自 2018 年起一直持平或下降。

Oracle 在 2021 年收购了 Cerner。现在 Oracle 不再把 Cerner 的财务数据作为独立业务公布，只说 Cerner 和 Oracle Health 拖累了公司的整体增长和盈利。Oracle Health 还进行了很多裁员。

现在下结论可能还太早，但我觉得这可能是 Oracle 有史以来最糟糕的一笔收购之一。很难找到分析师会说这是一笔很成功的收购。

Ben：委婉地说，确实如此。

David：与此同时，这一切对 Epic 都非常有利，也进一步印证了 Judy 在这个行业建立公司的理念：为客户提供一体化平台，专注软件开发，完全以客户为中心，永不收购其他公司、永不上市，也永远不被收购。你能理解为什么这对客户来说像一个温暖的拥抱。

Ben：时间越久，他们就越和市场上的其他公司不同。这里很有意思的一点是，他们起步很慢，真的很慢。

他们的发展方式几乎是在为未来积蓄势头，等 20 到 30 年后再看到成果，而不是靠并购等捷径，把未来的事情提前到今天。

头 20 年里，Epic 看起来并不起眼，因为他们只是在积累实力、锻炼能力，按照今天这样的业务所需的方式慢慢成长。

David：说得太好了。我之前一直在想，怎么解释“有意义的使用”显然对 Epic 很有利，加速了他们的发展，并进一步巩固了原本正在形成的市场领先地位；但和 Epic 内部的人交流时，他们对“有意义的使用”却褒贬不一。

Ben：我一直不确定他们说这对自己帮助不大，是不是在客套。但看客户数量和收入曲线，他们的发展确实很好。

David：它确实提前了一部分增长，但趋势线显示他们本来就会走到这一步。

Ben：这并不是那种两年之内突然出现巨大跃升的情况，图表上看不到这种变化。

David：正如我们讲的，他们的产品更好，给客户的方案也更好，本来就在走向胜利。你刚才说得对，他们在理念上一直排斥人为加速增长。如果他们确实对“有意义的使用”感到矛盾，我想这可能就是原因。

Ben：他们想慢慢赢。

David：他们当然想赢。

Ben：他们一定会赢。但他们想慢慢赢，因为这样长期来看能赢得更稳、更彻底。

David：不过目前 Epic 的前景几乎从未这么好。当然也有风险，我们之后会讨论。现在他们开始拓展国际市场，并把它发展成一块真正的业务。目前规模不大，大概占总业务的 10% 到 15%。2023 年，他们在英国伦敦的 Guy's and St Thomas' NHS Trust 上线。这可能是他们有史以来最大的单个实施项目，地点就在英国。英国正逐渐成为他们的重要市场。

Ben：还有另一个顺风因素正在推动 Epic 的业务。我想这一整期节目里，你应该听出来了：有些顺风因素让人感觉不太好，但对 Epic 的业务仍然有利。医院系统不断合并，把规模更小的地方诊所纳入旗下，这种趋势正在加速。

David：对，这还给了医院重新招标的理由。

Ben：这件事有很多原因，其中之一是《平价医疗法案》。它也加重了行医的合规负担；多年来的各种监管本来已经很沉重，HITECH 还大幅提高了违反 HIPAA 的处罚。

我们刚才没提 HITECH 的另一项内容，它还加强了 HIPAA 的监督。现在，地方医疗机构要承担这么重的合规负担，必须有足够规模才能负担得起。

这继续发展下去意味着，大多数医疗服务会由大型医疗系统提供，而不是社区诊所。这对 Epic 很有利，因为他们 30 年前选择专攻最大、最复杂的医疗系统，如今看起来简直有远见，因为这些大型机构几乎是唯一能继续生存的客户。

我觉得这其实是美国医疗体系里最不合理的事之一。大型私人保险公司已经拥有很强的议价权，现在地方上又出现了规模很大的准垄断医院系统。这种集中化并不好，也不会让价格下降。

David：但你也能理解为什么会这样。我们做这期节目时，本来觉得：“医院才是坏人，他们收这么多钱。”

Ben：我觉得医院其实赚不了多少钱。

David：它们真的没赚多少钱，几乎快撑不下去了，所以才要合并。

Ben：即使最成功的医院赚到一些钱，也往往会把钱投回扩张。正如我们讨论过的，当今医院需要规模。它们要建新大楼，在当地收购其他医疗机构。大家都在追求规模，因为必须和其他大机构打交道，所以也需要扩大自己的规模。

David：这就带出了 Epic 未来另一个重要的增长方向，他们正在积极拓展。现在他们在医疗服务提供方一侧已具备足够规模，可以开始接触系统里的其他大型参与者，也就是付款方，还可以拓展生物技术和制药领域。Epic 现在可以告诉这些公司：“我们有办法和你们合作，也能提供有吸引力的产品。”

他们把这称为“互联体系”，有时也叫“医疗照护网络”。他们正在为付款方、保险公司、药企以及家庭护理、康复护理等其他机构开发产品并与其合作。不过，最大的机会还是付款方和制药企业。

一个例子是事前授权。这在美国医疗体系里是个大问题：医生觉得患者需要某种药物或治疗程序，但保险公司会说：“不能直接做。”

Ben：费用太高了，你得针对每个患者、每种情况先问我们是否愿意报销。

David：没错，这就叫事前授权。Epic 现在掌握了足够多的医院数据，也有足够大的规模，可以去找保险方说：“我们的客户不喜欢事前授权，你们也不喜欢。我们拥有全部数据，可以帮你们把流程自动化。”

Ben：我觉得这是 Epic 最喜欢的商业策略之一：先向医院系统销售核心产品，观察他们还用哪些供应商。如果我们具备某种竞争优势，就想办法让他们也从我们这里购买相同功能，而不只是因为“单一供应商”听起来方便。有时即使产品水平相当，只用一个供应商也足够有吸引力。然后 Epic 会想办法把这些功能放进企业协议里。

他们想把所有产品都卖给医院，成为医院唯一的 IT 供应商。医院仍会购买其他 IT 服务，所以 Epic 的策略是先从一款产品开始，再设法卖给医院所有产品。等这个市场饱和后，再想办法把产品卖给其他客户。这就是他们关注付款方和制药公司的原因：利用已有资产拓展其他客户群。

David：说得有道理。

Ben：好，这就把我们带到了今天。如果你身处这个生态系统，肯定会说：“Epic 还有 50 件事你们没讲。”没错，这期节目不可能把所有内容都讲完。

但他们现在做的一件很酷、很有意思的事值得我们在讲到今天时谈一谈。然后我们会介绍公司目前的数据，再聊聊未来，最后做分析。几年前他们推出了一个叫 Cosmos 的系统。

David：这很酷。

Ben：真的很棒。他们意识到，患者数据不属于 Epic，而属于患者和医院。这些数据分散在不同服务器上：有些在医院本地，有些在 Epic 的云上，有些在 AWS 或 Azure 上。但无论如何，各个 EpicCare 系统里都存着大量有意思的结构化患者数据。

他们想能不能把这些数据匿名化，集中到一个由 Epic 托管、方便查询、能支持许多应用场景的系统里？他们做到了，这个系统叫 Cosmos。Cosmos 收录了 2.95 亿名患者的匿名化数据。

David：我想这 2.95 亿名患者总共贡献了 150 亿条独立就诊记录，也就是说，患者与医生之间发生过 150 亿次有结构化数据的就诊。

Ben：太不可思议了。前面我们问过，电子病历是否真的让患者受益？除了在家查病历很方便，还有大量数据表明它确实对患者有帮助。

这包括患者安全和便利。有研究称，45% 的患者表示电子病历提高了医疗质量，只有 6% 的人觉得质量下降。Epic 自己的一项 2023 年统计显示，其系统预防了 6,600 万次可能有害的药物相互作用，以及 25 万起可能发生的手术错误。

这些听起来都很合理。如果把信息数字化，就可以利用数据做出更聪明的决策，改善医疗服务。更有意思的是，如果所有数据都在一个地方，人们可以用它做什么？和纸质记录相比，拥有数字数据有什么价值？

David：这就是人们一直以来的乌托邦式愿景，也是 Bush 和 Obama 政府曾经追求的。Epic 终于把它实现了。

Ben：一个很清楚的例子是，想象一下供水系统出了问题，但所有病历都是纸质的。除非你把每个档案都找出来，再比较很多人的某项特定检查结果；而这可能还需要研究经费，得花大量时间逐个翻阅，否则你根本发现不了问题。

但如果有一个包含大量信息的数据库，就能迅速横向比较许多人的病历。密歇根州 Flint 的水污染问题就是这样被发现的；如果还在纸质病历时代，就不会发现这个问题。Cosmos 就是把这种能力进一步放大。拥有 2.95 亿患者的匿名、可查询数据库后，你能对整个世界发现什么？只要医疗机构贡献数据，任何机构都可以免费使用。

所以，所有 Epic 客户只要选择加入，就能使用这个系统。例如研究人员可以查询；医生也可以问：“我有一位情况很罕见的患者，出现了我从没见过的病情。世界上其他地方有类似病例吗？他们的治疗结果怎样？”

David：这才是真正有意思的地方。他们把这项能力做成了产品并免费提供，所以任何客户都可以直接启用。Ben，正如你说的，如果我是医生，患者出了某些情况，Cosmos 就能找到相似案例，而且都是匿名数据。

Ben：我想他们把这些病例叫作“相似患者”？

David：对，就是 Epic 所有历史记录里相似的患者，以及治疗过这些患者的医生。我觉得这对罕见疾病和复杂病例已经很有用了。

Ben：我也这么觉得。它会对临床试验和研究有帮助。我认为现在仍然免费，这很有意思。之后他们会怎么定价和打包产品，我们还得继续观察。不过你说得对，这就像实现了那个乌托邦式愿景：如果所有数据都放在一个地方，会有多棒？

David：这也预示了我们稍后分析时会重点讨论的一件事：想象一下，有了这些数据，人工智能能做什么？不过我们过一会儿再谈。

Ben：好，我们先对齐一下 Epic 目前的情况。这家公司有 607 家客户，这些客户旗下合计有 3,200 家医院。正如你知道的，他们从未失去过任何一家客户，这非常惊人。每年他们会新增 10 到 25 家医疗系统客户。客户合计拥有 590,000 名医生和 495,000 张住院床位。

David：这些客户覆盖 3.25 亿名患者？

Ben：全球范围内是这样。其中 2.8 亿人在美国。

David：所以几乎每个美国人都在某个阶段通过 Epic 系统接受医疗服务。

Ben：没错。收入方面，2024 年他们的收入是 57 亿美元。过去五年年均增长 13%，去年收入从 49 亿美元增长到 57 亿美元，增幅是 16%。

David，我有件事想和你讨论。我原本以为他们的收入会更高。有些人会觉得：“57 亿美元已经很多了，你还想怎样？”但如果除以客户数量，每家客户平均每年大约贡献 1,000 万美元。

如果你熟悉企业软件，这个数字并不夸张。这是大型医疗系统的核心神经系统，其他所有工作都依赖它。他们整个业务都在这个系统上运行，因此成本很高，因为需要很多人来管理。

我和一个中型医疗系统的人聊过，她说自己的医院系统有 100 名全职员工负责管理 Epic。但 Epic 每年实际只获得约 1,000 万美元收入。所以这里有个有意思的区别：支出确实很大，但其中只有一小部分真正付给 Epic。

David：这就涉及我之前说 Epic 带有利他主义色彩。你说得对，他们并非纯粹出于利他。但这一点非常重要：他们的经营理念非常长期。他们完全可以向客户收更多钱，绝对可以。

Ben：他们过去可能无法这么做，因为客户的支付意愿已经到顶了。现在他们的市场地位已经如此强大，可能确实有提价空间。但医院还要承担顾问费用，比如 Accenture、Deloitte、IBM、Nordic 的费用，项目上线后的人员开销、系统优化费用，以及切换系统造成的收入损失和停机损失。这一切对医院系统来说成本很高，而 Epic 实际上只拿走了其中一小部分。

我不太确定他们还能涨多少价，但让我惊讶的是，作为医院系统的核心神经系统，他们实际获取的整体价值占比并不高。也许他们还有一些涨价空间；未来如果越来越占主导地位，定价权肯定会增强。

David：我觉得他们确实有涨价空间。毕竟这套软件对业务至关重要，平均每年花 1,000 万美元并不算高。我觉得他们不这样做，部分原因是他们不想给客户任何重新招标或考虑其他系统的动机。这有点像 Jeff Bezos 早年谈 AWS 时说的，希望客户觉得“不用 AWS”才是一个不理性、不负责任的决定。

Ben：对，选择其他供应商就是不理性。

David：我觉得 Epic 也希望医院觉得，不用 Epic 才是不理性、不负责任的决定。

Ben：我也这么认为。再给你一个从不同角度看问题的数据。医疗行业里，57 亿美元的收入其实不算很大。United Healthcare 同时拥有保险公司和医院系统，每年收入达到 4,000 亿美元。这当然是完全不同的业务模式，因为它还通过医院系统实际提供医疗服务。

不过这家公司一年创造 350 亿美元 EBITDA，是 Epic 全部收入的六倍。Epic 已经成了医疗体系中极其重要、极有影响力的关键环节，但它在这个行业里的利润池并不大。更准确地说，Epic 在行业收入池里占据的比例也没有那么大。

做这期节目之前，我以为这家公司会像印钞一样赚钱。大家总在谈它、它又是医疗体系的重要部分，所以我以为它手里流转的现金会更多。

再说几个简要数据。Epic 现在有 14,000 名员工。按医院数量计算，他们目前的市场份额只有 42%，但客户是规模最大、最成功的医院，因此他们覆盖的医疗服务比例实际上更高。现在 58% 的门诊医生使用 Epic，而美国有 79% 的人口以某种方式接触过 Epic。

盈利方面，我们听到了几种估算。EBITDA 利润率大约在 30% 到 35% 之间。为了保守起见，我们取低端估算，如果这些数据属实，EBITDA 大约为 17 亿美元。

接下来是 Epic 值多少钱的问题。这问题有点荒唐，因为如果你持有它的股份，除了公司本身，你几乎不可能把股份卖给别人。既然你不能持有它，估值又有什么意义？如果它永远不能带来财务回报，持有它又有什么意义？

David：你的股份永远不会出现流动性事件。

Ben：不过还是值得估算一下。节目开头我们说，Judy 可能是有史以来最成功的女性创始人。Forbes 有一份最富有白手起家的女性榜单，我觉得他们的估值低得离谱。

David：错得非常离谱。

Ben：2021 年，Forbes 估算她的净资产为 76 亿美元，也就是说他们认为公司价值 150 亿美元。Epic 的估值怎么可能这么低？如果保守地采用 Oracle 收购 Cerner 时 30 倍 EBITDA 的估值倍数，再保守地假设 Epic 的 EBITDA 利润率为 30%，公司估值就会达到 510 亿美元。

但说真的，Epic 的收入来源比 Cerner 持久得多，而且 Epic 还在增长，Cerner 当时却陷入困境。假设使用 9 倍收入的估值倍数，也能得到大约 500 亿美元。对上市软件公司来说，这是合理的可比倍数。不过，Epic 的业务极为持久。

David：我觉得这还没有抓住重点。Epic 可能是历史上最持久的软件公司。

Ben：我的猜测是，如果 Epic 上市，尽管它永远不会这么做，投资者可能会把它的估值定在 1,000 亿美元左右，让 Judy 的股份价值约 500 亿美元。她会成为世界上最富有的白手起家女性之一，也是最成功的企业家之一。这会让 Epic 跻身全球最有价值的 150 家左右公司，和 Shopify、Arm、Lockheed Martin、Starbucks 等公司并列。

David：还有一个思考方式：假设在某个平行宇宙里，Microsoft、Google、Amazon，或者也许 Berkshire Hathaway、Apple 能收购 Epic，他们愿意出多少钱？我觉得 1,000 亿美元绝对只是这个区间的下限。

Ben：这相当于 Apple 或 Microsoft 市值的 4%。他们当然愿意拿公司市值的 4% 来收购 Epic。

David：这既涉及市场价值，也涉及收入和利润的持久性。

Ben：我懂了。你是说，单从财务角度看，这家公司就很有价值。此外还有战略价值。

David：还有战略价值：你能成为这个庞大行业里最重要的合作伙伴之一，为行业最大的一批机构服务。也别忘了我们如今处于 AI 时代。天哪，Cosmos 有 150 亿次患者互动数据。你觉得 Google、Microsoft 或其他公司不愿意花大价钱拥有这些数据吗？他们肯定愿意。

Ben：我有时会想：“太好了，Judy 把公司放进了信托。”

David：总之，这种收购永远不会发生。故事最后要讲的是，Judy 现在 81 岁了。未来某个时候会发生什么？即使她能像 Warren Buffett 那样长寿，我们讨论的也只是未来几十年内要发生的交接。

正如 Ben 说的，她拥有公司大约一半的经济权益和 100% 的表决权。她一直把不带表决权的股份转入名为 Roots and Wings 的基金会。她签署了捐赠承诺，并把财富转入基金会。基金会再按照每年变化的价格把股份卖回给公司，为基金会提供资金。

Judy 已宣布，她去世后，自己持有的全部表决权股份，也就是对公司的 100% 表决控制权，将转入一个“目的信托”。信托由三个群体管理：（1）她的家人，如果丈夫 Godon 仍在世，就包括他和他们的三个孩子；（2）Epic 的五位长期资深管理人员；（3）我想还有三位大型客户的 CEO。

这群人将管理信托。信托章程有几项规定：（1）公司永远不能出售或上市，这是不可更改的；（2）Epic 的下一位 CEO 必须满足两个条件。

Ben：首先必须是软件开发者，对吧？

David：没错：（1）必须是在 Epic 工作多年的员工；（2）必须是一名软件开发者。

Ben：我很喜欢让来自公司核心技能领域的人担任 CEO。Costco 很有代表性，这些年他们的 CEO 都是熟悉公司核心运营、在公司工作了 30 多年的人。Nike 鼎盛时期的 CEO 是一位从鞋类设计起步的人，后来负责整个公司，就是 Mark Parker。这种安排很有价值。

David：这确实是一套成熟的方法。

Ben：最后再讲一件关于 Epic 现状的事。我们聊过互操作性，也聊过 Epic 过去以缺少合作、不便访问数据或集成为名。现在情况改变了很多。但如果要详细解释各种项目、不同的集成方法、名称和标准如何逐年变化，可能还得再录四小时。

现在有些项目会向 Epic 支付收入分成。真正的合作项目也可能会给 Epic 认股权证，让它获得对方公司的一部分股份。但总的来说，现在开发建立在 Epic 之上的应用、与 Epic 集成，比 10 或 20 年前容易多了。

David：好，这就是 Epic 的故事。我们开始分析吧？

Ben：开始吧。分析的第一部分叫“竞争优势”。这个概念来自我们借鉴的 Hamilton Helmer《Seven Powers》一书。我们要问的是：一家企业凭什么能持续获得差异化回报，长期比最接近的竞争者更赚钱？

一共有七种竞争优势：反向定位、规模经济、转换成本、网络效应、流程优势、品牌和稀缺资源。和往常一样，我们得把业务起步阶段和当前阶段分开分析。

David，我想听听你的看法。你觉得 Epic 在起步阶段有哪种优势吗？你能分析他们最初如何获得优势吗？

David：有意思的是，他们很长一段时间都没有起飞。

Ben：我甚至会说，在起步阶段他们可能根本没有竞争优势。

David：我也这么认为。最后，他们最大的差异化优势就是单一平台，但在起步阶段不太重要。那时其他公司也刚开始，尚未构建很多东西，电子病历在医院里的普及程度还很低，所以单一平台也谈不上优势。

Ben：我觉得当时发生的是，他们在一个刚起步的电子病历市场里找到了生存空间，产品规模不大，收入足以自给自足，让他们有时间等待和打造更完整的平台。

他们实际上把时间当作一种很少有人利用的资源。大多数创业者都想在短期内做出成绩，通常是因为资本结构要求如此。要么推出平台，让别人开发应用，因为市场变化非常快；要么在别人的平台上开发应用，因为市场变化非常快。

Epic 所处的市场发展得很慢，而且持续了很长时间。他们愿意长期维持一家小公司，然后逐渐开发所有功能，等最终有一个庞大的市场需要整套集成系统时再扩张。

那么，如今作为规模领先者的 Epic 具备什么竞争优势？

David：答案是很多。最明显的是转换成本。这可能是所有软件产品中转换成本最高的。

Ben：噢，有意思。真的是最高的吗？你觉得比企业资源规划系统的转换成本还高？

David：当然。这就像强化版 ERP，是整个企业最重要的神经系统。对了，如果系统出问题或停机，还有人会因此丧命。

Ben：说得对。算上机会成本，医院要花数亿美元甚至几十亿美元才能部署这套系统。有没有 ERP 或 CRM 系统的实施项目会花 10 亿、50 亿或 100 亿美元？

David：也许有，但我觉得没有哪个系统对客户整个业务如此核心。

Ben：你说得对。即使某个系统部署成本极高，医院仍然更可能替换它，而不是替换电子病历系统。

David：电子病历远不只是医疗记录，确实如此。

Ben：规模经济肯定存在，正如我们刚才说的。如果没有今天这样的规模，就无法投资打造如此广泛的产品。

同样，如果没有规模经济，也不可能像他们那样把许多未来可能用得上的软件免费打包，或者以后再提供给客户。他们开发了大量软件，要么免费附送，要么让客户以后使用。而要开发这么多软件，唯一办法就是拥有大量客户，把开发成本分摊到他们身上。

如果你今天想创办一家新的电子病历公司，为了具备竞争力，你必须开发大量软件。这就是规模经济。

David：网络效应也很明显。

Ben：毫无疑问。

David：确实如此。

Ben：Epic 达到了一个有意思的拐点。很长一段时间里，光凭“我们是最优秀、最可靠的平台”就能赢得客户。之后某个时候，又多了一种价值主张：大多数其他医院也在使用 Epic。如果你也采用 Epic，患者和医生就更容易与那些医院共享记录，互操作也更方便。这就像锦上添花。

David：你说的是互操作性。除了互操作之外，还有个问题：你觉得未来为了业务增长，或者替换退休的现有医生，医院会不会继续招聘医生？

Ben：选择行业标准。

David：他们知道怎么使用什么系统？他们受训使用的是什么系统？Epic。

Ben：没错。这是第二种网络效应，除此之外还有 Care Everywhere，能让我在不同机构之间共享自己的病历。

西雅图有一家医疗机构专门帮我儿子看食物过敏，我们去那里看病。他们使用 Cerner。我这些年去过的另外三家医疗机构都使用 Epic。我不知道为什么那家医院还在用 Cerner。

David：这让你觉得很烦，对吧？

Ben：我相信西雅图其他人也会想：“你们为什么不跟其他大医院一样，使用同一个平台呢？”这就是网络效应。

David：很难想象医疗软件还能建立起网络效应。

Ben：这个系统里的每个参与者都有价值，包括其他医院、我这样的患者和医生。如果那家还在使用 Cerner 的医院改用 Epic，那就是网络效应的典型案例。

我觉得他们也有品牌优势。他们是最值得信任、声誉最好的机构所选择的产品。因此现在就算 Epic 没有其他优势，只要它和其他供应商的报价完全相同，100% 的情况下客户都会选 Epic，因为大家知道它会正常运行，也熟悉这个品牌。

David：这就像“买 IBM 不会被解雇”，没错。我之前没想到这点，以为他们没有品牌优势，因为 MyChart 不是面向消费者的大品牌。但你说得完全对，他们确实有品牌优势。

Ben：他们建造那座巨型礼堂，邀请整个 Epic 生态圈每隔几个月聚到一起，部分原因也是为了打造品牌。

David：我觉得他们还具备流程优势，至少可以说软件开发流程以及他们使用的专属语言有流程优势。这更像一种防御性优势。

Ben：我觉得这也包括他们培训年轻员工、让员工按照 Epic 的方式工作的体系。

David：对 Epic 的流程优势我基本同意。不过我觉得更具体的例子是，他们从大学招聘软件开发者，主要使用 Caché 和 MUMPS 来开发，而他们并不……

Ben：这些技能不能轻易迁移到别处。

David：没错，你不能轻易转去 Cerner 做同样的工作。当然，如果你是优秀的软件开发者，也能学习其他语言和框架。但如果你整个职业生涯都在 Epic 的专有系统里开发，我得说明，“专有”这个说法并不准确，因为 MUMPS 或 Caché 不是 Epic 自己开发的，而是另一家公司 InterSystems 的产品，Epic 向他们购买许可。不过，行业里的大多数其他公司并不用这些技术。这确实带来了一些流程优势。

Ben：我觉得这说得通。好，竞争优势这一部分就到这里。

David：好。

Ben：你觉得有哪些经营方法值得借鉴？

David：有。

Ben：最先让我注意到的是，他们在研发上投入很大。这条观点来自节目好友、Worldly Partners 的 Arvin Navaratnam。他每次都会写一篇很棒的配套分析，我们会在节目说明里附上链接。

Epic 几乎完全从头开发整套系统，正如我们反复提过的。他们不收购其他公司，所有软件都在内部开发。因此，他们把 35% 的运营费用投入研发。相比之下，竞争者 Athenahealth 约为 10%，Oracle 整体约为 23%。如果看行业外，Apple 的研发支出占运营费用 36%，Amazon 则为 28%。所以 Epic 的 35% 确实很高。

David：确实很高。

Ben：只有 Google 更高，为 45%。想想 Google 投入那么多研发资金，做各种面向未来的项目；而 Google 本来就是一家核心技术公司。

另一方面，这也不难理解。Epic 基本不收购公司，也几乎没有销售和营销支出，还把一般管理费用控制得很低，那剩下的主要开支当然就是研发。

David：与大多数公司不同，他们在销售和营销上完全不花钱。如果把他们雇用的八位所谓“销售人员”也算进去，我不知道，可能也花不了多少钱。

Ben：确实很少。我觉得这又说明了我们刚才反复讲到的重点：如果早期不花钱做销售和营销也能赢下客户，你就能把几乎所有成本用于研发。随着时间推移，这些研发投入会不断累积，形成很大的竞争优势，而其他类型的投入没有这种效果。

David：尤其是在软件行业。

Ben：我接下来想讲增长。我读过一篇文章，说 Faulkner 曾把自己的做法比作爬山：她不试图一次看清整座山，而是专注于前面那座小山。这让我想起以前读到过的一个观点。你想到什么了吗？

David：我一时想不起来，你说吧。

Ben：Paul Graham 在 2012 年那篇著名文章《Startups = Growth》里说，初创公司要做的就是专注于下周的增长。

他接着说：“理论上，这种逐步爬坡的方式可能会让初创公司陷入局部最优。但实际上从来没有发生过。每周都必须达到增长指标，会迫使创始人采取行动；而采取行动而不是无所作为，是成功的关键。十次里有九次，坐在那里制定战略不过是在拖延。创始人对该爬哪座山的直觉，通常比自己以为的更好。而且初创点子所处的空间并不是一座座孤立陡峭的山，大多数还不错的点子都邻近更好的点子。”

我当时就想，Judy 几乎肯定没读过 Paul Graham 的文章，但她却有相同的领悟：“我不试图一次看清整座山。我只专注于眼前的小山，而这座小山旁边还有一座更大、更有意思的山。”

David：很高兴你提到这一点。我之前在想，Judy 是一位出色的软件开发者，后来成为公司的创始人和优秀的商业人士，却没有遵循 MBA 课程里的规则。

Ben：但她确实遵循了，只不过自己在 Wisconsin 把这些方法都总结出来了。

David：对。我在想她和公司的故事，觉得很像 Paul Graham 和 Y Combinator。这里有很多相似之处，但又属于完全不同的世界。

如果 Y Combinator 不给公司提供资金，也不做风险投资，而是劝创始人不融资、独立经营公司，我们今天可能会看到更多像 Epic 这样的公司。但 Judy 创业的时代不同，她可以在不融资的情况下做到这一点。

Ben：我觉得说得对。

David：但 Judy Faulkner 和 Paul Graham 的距离其实没有想象中那么远。

Ben：她把计算机科学原则和常识用于经营公司。这些做法对她来说显而易见，但和大多数公司的惯例相反。她把从程序员转型为商业人士这件事做到了极致。

接下来还有一件我们没谈到的事：他们的诉讼策略。值得提一下，让大家知道这方面的情况。Epic 会积极保护自己的知识产权，也会积极应对他们所谓的专利流氓；在雇佣相关法律事务上，他们也非常强硬。

他们会用竞业限制协议保护商业秘密，而且会积极执行。他们也是推动雇主强制员工接受仲裁的案例之一，并赢得了一起关于强制仲裁的里程碑式诉讼。

David：我想这案子到了最高法院。

Ben：他们还和其他医疗 IT 公司打过官司，指控对方以 Epic 认为违反服务条款的方式使用 Epic 软件。这种诉讼不止一件，有很多起。

David：还包括一场重大的反垄断诉讼，是和一家名叫 Particle Health 的初创公司之间的案件。

Ben：现在案件正处于非常关键的阶段。对，David，Epic 被指控违反《谢尔曼反垄断法》。

David：诉讼仍在进行中。

Ben：我们提这些，是想说明这家公司似乎不怕用法律保护自己认为属于自己的东西，并加深竞争壁垒。不过有意思的是，在公司历史上，他们从未和客户打过官司，甚至连调解都没有过。他们非常珍视客户关系。

David：这又回到了公司文化：Epic 所有事情都以客户为中心。

Ben：好，接下来我要讲一个经营主题，我称之为“强化版企业销售”。通常企业软件销售周期很长，而且买家不是实际用户，所以界面常常显得笨重。

这不只是因为厂商不在乎，企业软件覆盖的范围确实非常广，开发所有功能要花很长时间。新界面趋势出现时，你不可能立刻更新全部产品。

此外，不同用户和使用场景会有上百万种相似的界面，最后往往都变成下拉菜单和按钮。这也不能完全怪某一个人。

企业销售周期很长，定制内容很多，实施时间也很久。这是企业软件的一般情况，不只医疗行业如此。但医疗行业还要额外遵守 HIPAA 和其他医疗合规规定，处理敏感数据，而且人命攸关，所以问题更加复杂。

在大多数行业，初创公司看着企业销售这条路，会说：“我们不做自上而下的销售，我们要做产品驱动增长，争取自下而上的采用。”可以学 Slack、Figma 之类的公司。

但 HIPAA 让产品驱动增长难得多。根据优秀的 Substack 作者 Health API Guy 的说法，按照 HIPAA 规定，业务伙伴协议通常必须由有权代表组织签署法律文件的人签署，而不是由个别医务人员或普通员工签署。

David，我研究时一直在想，为什么不能让一位医生或一家诊所先采用产品，再自下而上推动整个行业的采用？未来的电子病历系统难道不能这样发展吗？不行，因为这些销售都得面对 CIO，也就是必须和医院管理层谈。

David：你不能指望一支大公司里的小团队刷信用卡买下系统。绝对行不通。

Ben：当然也有一些例外。我知道医疗行业里也会出现产品驱动增长，但比起普通的企业 SaaS，要想办法实现难得多。

最后一点，Judy 是一位非常特别的创始人，所有真正伟大的企业家都很特别。她确实独一无二。她曾说过，相比退休，她更可能先去世，就像 Warren Buffett 经常开玩笑说的那样。她一心只想让 Epic 做好，这让我想起 IKEA 的 Ingvar Kamprad。她非常专注于迅速吸收客户反馈，就像 Jeff Bezos 一样。她还相信“技术宅终将获胜”，至少在她的市场、她的理念和她所处的行业里是这样。她和我们研究过的所有伟大创始人一样独特。

David：你在开场时预告说，Judy 几乎可以肯定是历史上最成功的女性创始人。如果按任何标准衡量，我觉得这是真的。我查过还有谁可能接近她。

Estée Lauder 也许可以一比。不过，尽管它在疫情期间的市值一度达到约 1,000 亿美元，现在却只值约 200 亿美元。我不知道发生了什么。

还有 Taylor Swift 和 Oprah，我们聊过她们；去年 Chase Center 的节目里，我们还更新过 Taylor Swift 的情况。我们估计 Taylor Inc 企业价值“只有”约 110 亿美元。

Ben：我喜欢你和我一直在做 Taylor Inc 的估值表。

David：对。Oprah 的资产也低于这个数字。Forbes 目前认为 Diane Hendricks 是世界上最富有的女性创始人，或者至少是美国最富有的。她创办了 ABC Supply，这是美国最大的屋顶材料供应商之一。

Ben：你知道这有多疯狂吗？这意味着美国最成功的两位女性创始人都在 Wisconsin。

David：没错，真不可思议。我本来也想说这件事，很高兴你也找到了。ABC Supply 确实是一家规模很大、很优秀的公司，不过它年收入大约是 200 亿美元。我想它的利润率远低于 Epic，所以我不认为它值 Epic 的最低估值，也就是大约 1,000 亿美元。

Ben：哇，你现在认为它至少值 1,000 亿美元了。

David：对，我是按照“如果有人收购它，愿意出多少钱”的标准来估值的。

Ben：有意思。如果 Epic 现在的估值是 1,000 亿美元，你愿意买它的股票吗？

David：这问题问得好。如果我能从 Epic 获得利润分配，我愿意一辈子持有 Epic 的股份，我肯定会买。

Ben：我完全同意。

David：如果我押注的是未来会有流动性事件，那我就不会买。但如果是我自己持有，那我非常愿意。

Ben：有人猜测一项资产值多少钱时，最有意思的反问往往是：“如果它值这个价，你愿意买吗？那就打开钱包。”这样估值才显得真实。

David：如果现在有 Epic 的股票，我肯定会按 1,000 亿美元的估值买入。我永远不可能获准这样做，但我会非常愿意。

Ben：这听起来像是一份公开报价。不过，本节目不构成投资建议。在这一点上，创始人长期留在公司究竟有多大影响，确实令人惊叹。我在想，还有哪家公司由同一位创始人领导了 47 年？Jensen Huang 领导 Nvidia 已经 31 年，Zuckerberg 经营 Facebook 已经 21 年。当然还有很多人长期经营小公司。但像 Judy 这样，把创始人的个性注入公司，并一路建设到这么大的规模，真的罕见，也非常有力量。

David：还有 Berkshire Hathaway。

Ben：那确实是个例外。Buffett 经营 Berkshire 超过 50 年。不过 Judy 的情况是，她有 47 年时间把自己的个性融入公司。

David：正如你刚才说的，她和 Jensen 很像，仍然在经营公司，依然高度投入。

Ben：完全没错。好，我们来聊看跌和看涨的理由？

David：开始吧。

Ben：如果要提出看跌理由，有几件事需要考虑。美国客户能付的金额非常高。这个市场很大，一方面因为美国经济和人口规模大；另一方面，很不幸，医疗保健支出占经济的比例也很高。如果 Epic 未来要在国际市场增长，结果可能不那么好，因为大多数国家对医疗行政软件的支付意愿低得多。这是一个看跌因素。

另一个看跌因素是，如果 Particle 的诉讼继续推进，最终 Epic 真正受到反垄断事件影响，并被判违反《谢尔曼反垄断法》，那就是大问题。这会改变整个公司，所以我们得继续关注后续进展。

过去几年还有一项关于信息封锁的法律。通过的《Cures Act》大致规定，电子病历供应商和医疗系统不能阻止他人访问信息。Epic 提出的数据隐私、安全和患者长期安全理由都相当合理，但这项法律使得第三方可以通过屏幕抓取、Chrome 扩展或机器人流程自动化来提取 Epic 的数据。法律要求 Epic 允许这些做法，他们没有办法阻止。

David：有意思。

Ben：我不知道这会如何真正取代 Epic。

David：这也让人想问：你拿到 Epic 的数据后要做什么？你不会因此就能打造一个 Epic。

Ben：Epic 一直非常谨慎地控制这些数据，既是为了客户，也是为了保护自己。我的担心是，这可能会成为它防御体系上的一个小裂缝。

问题在于，假设有人把产品部署到 70% 的客户那里，大家都用某种 Chrome 扩展，把数据输进一个很不错的界面。结果这个界面变成了所有人都喜欢的产品。那家软件公司可能会说：“你也可以不用 Epic 作为后台系统，改用我自己开发的系统。”但这种情况发生的概率接近于零。

David：不可能发生。

Ben：我也没有太担心这一点。另一种可能是，互操作性进一步发展，最佳单点应用比整合式平台变得更加普遍。这仍然只是个很模糊的看跌情景。

David：但即使这样，Epic 仍然可以沿用 Microsoft 的做法，他们确实在这么做。好，就算外面有更好的单点应用，医院 CIO 也可以花钱购买，也可以继续购买 Epic 的企业许可，在一个价格里获得所需的所有应用。

Ben：最后一个看跌因素是范式转变，这是任何主导型公司的风险。AI 会不会带来极大的范式转变，彻底改变医疗系统的需求？或者价值医疗会不会改变医疗系统的组织方式？

也许多数时候患者都不需要去看医生。我很难想象，未来会有什么变化，让医疗系统不再需要 Epic 这样的系统。又或者新的医疗服务模式会让传统电子病历过时。这需要一些想象力，目前还很模糊。Epic 自己也在关注这些变化，所以很难想象其中任何一种情况会……

David：我正想问你，AI 该在这里讲多少？还是应该留到看涨理由里谈？

Ben：大概更适合放在看涨理由里。

David：好，那我们讲看涨理由。

Ben：好。看涨理由之一是，他们已经成功把业务从电子病历和账单扩展到其他专科和模块。服务的还是同一批客户，只是产品更多。

未来这些客户（a）会需要更多产品，（b）还会有更多医疗系统可供 Epic 销售，现在（c）他们也从医院系统扩展到制药公司、付款方和研究机构。Epic 已经占据主导地位，能以此进入一大批新的潜在客户市场。我觉得这非常可信，他们可以发展成一家更大的公司。

David：事前授权看起来是最直接、最明显的业务机会。

Ben：医院的利润很低，所以从某种角度说，它们是糟糕的客户。如果能为保险公司开发真正有吸引力的产品，它们可能会是好得多的客户。可惜我每次想到医疗行业里的利润池，都会想：“唉，我真希望这种利润不要存在。”我得想想自己为什么总这么觉得。但可以肯定的是，医疗系统里的利润太高时，我就会开始批评。

David：背后的原因是，消费者觉得有些医疗机构没有给我们提供相应价值。

Ben：我觉得自己被宰了。我看过一项研究，说医疗支出中有 30% 是浪费；医疗占 GDP 的 18%，其中确实有大量浪费。另一项研究估算医疗系统里有 8,000 亿美元的浪费，相当于整个瑞士的 GDP 都被浪费在美国医疗系统里。

David：听起来差不多。

Ben：还有人问我，一家人每年要交多少医疗保险保费。我说我不知道，大概是 25,000 到 30,000 美元吧。对方接着问：“你觉得自己什么时候会用到这么多医疗服务？”

别看账单上的金额，因为那些数字全是人为设定的。标价、协商后的价格、保险覆盖金额，全都是人为设定的。你就想想自己实际要从口袋里掏多少钱，不要只看一年，要看十年，因为某些事情可能会发生。

有些年份你会做手术，有些年份不会。未来十年里，你愿意为需要的医疗服务花多少钱、实际付给医生多少钱？再把这个数字和你一直交给医疗体系的钱相比。即使把雇主和员工交的保费，以及所有自付费用都算进去，我们也没有得到划算的服务。确实没有，大家都能感受到。

继续说看涨理由，有一类技术叫环境式聆听。人们对电子病历最大的抱怨之一，是医生花太多时间看电脑、输入病历，还要在九个不同的下拉菜单和提示框里反复点击。

有时医院会安排记录员在诊室里打字，医生则负责看诊。无论如何，医生还是要看电脑里的病历，所以最终还是会对着屏幕。他们要么浪费很多时间打字，要么雇人替自己打。

如果有环境式聆听 AI 记录员，能够记录、分类并整理医生和患者对话中的信息，那 AI 就能极大改善这个问题。好消息是，这件事已经开始发生了。

David：已经发生了，而且确实有效。

Ben：David，有几家公司是 Epic 的合作伙伴，对吧？

David：没错。其中一家是 Microsoft 和 Nuance。几年前 Microsoft 收购了 Nuance。

Ben：他们以前做 Dragon Dictation 吧？

David：对。他们长期从事医疗语音技术，现在也推出了环境式 AI 产品。

还有两家大型初创公司，一家是位于 Pittsburgh 的 Abridge，另一家是 Suki。它们都开发了优秀的环境式 AI 产品，可以接入 Epic。它们能当 AI 记录员，使用的医生很喜欢。医生只要专注照顾患者，系统就会自动记录全部信息。

Ben：这应该能有效缓解医生的职业倦怠、疲劳和长时间看屏幕的问题。

David：这就是看涨理由。这些产品都是 Epic 的合作伙伴，有些情况下 Epic 可能和其中一些公司有合作关系、认股权证或收入分成。也可以想象，未来 Epic 可能会自己开发类似产品。这是一个很大的机会。

Ben：Epic 现在是整个行业的关键枢纽，决定哪些软件创新能进入医院。我觉得这么说并不过分：如果你开发了一款要在医院里供医生使用的突破性软件，Epic 有权决定你能不能接触到这些客户。

David：对。我觉得环境语音和环境式 AI 的基本看涨理由，是这会成为新的产品收入机会。更乐观的理由是，借用我们在印度板球超级联赛那期节目里的说法：一位 CIO 对我说，虽然他不确定这种情况是否会发生，但随着环境式 AI 越来越好，电子病历本身会不会逐渐退到幕后，最后整个医疗系统都由 AI 操作系统来驱动？

电子病历主要在做什么？它记录发生过的事情，用于临床和账单处理。为了支付账单，这些数据要发送给政府或保险公司等付款方，再进行审核和处理，最后付款。

未来真的不能由 AI 完成所有这些工作吗？为什么还需要面向用户的软件？或者至少为什么要这么多这类软件？也许未来某天，环境式 AI 会自动处理大量繁琐流程，彻底减少系统里的行政负担和成本。这当然是一种乌托邦式设想。

Ben：等我亲眼看到再说吧，不过听起来确实很美好。

David：没错，但这是一个大型医院系统的真实 CIO 向我提出的看法。

Ben：我很难相信行政臃肿会消失。降低管理成本非常困难。该怎么办？难道要让医院里很多有稳定行政工作的员工失业吗？这对整个社会来说很难处理。

David：当然。这就是 AI 面临的问题，对吧？

Ben：但你说得对。如果你是 Epic 的股东，这肯定算看涨理由。

David：如果 Epic 成为那套系统的话。总之，和所有行业一样，AI 在这里有巨大潜力。

Ben：我觉得这说得通，而且这是在我们之前谈到的所有理由之外。没有人会从 Epic 换走，现有客户带来的收入会继续增长。它已经成为行业标准，一旦医院成为客户，就会一直用下去。

老实说，在公司成为行业老大之后，监管也可能成为看涨因素。这就是行业进入现有企业主导阶段后的情况：监管往往会排斥新进入者、巩固老牌企业的地位，因为老牌企业更有资源满足监管要求。

他们了解行业动态，资源也非常充足。新的数据互操作标准，例如正在推进的 TEFCA，Epic 可以率先做好实施。随着他们准确遵守新法规和合规要求，市场地位可能会进一步巩固。

正如我们讨论过的，他们现在可能有提价空间。对客户来说这未必是好事，但对 Epic 有利。他们也许可以提高价格，把一部分未来价值提前变现。

David：如果他们真的这么做，我会非常非常惊讶。

Ben：我也愿意买。我不觉得他们会那样做。最后一个因素是把公司变成平台。到目前为止，他们基本都是自己开发所有东西。但我很好奇，他们未来会不会更积极地把平台开放出来。

他们一直有一些零散尝试，比如 App Orchard。我很好奇，他们会不会有一天真正投入资源，打造一个强大的平台层，让其他应用在上面开发。正如你说的，这种做法是否适合垂直软件行业还不确定，但如果 Epic 认为这样比目前的模式更有价值，他们完全有机会尝试。

David：好，我们来做最后的总结吧？

Ben：我最想弄明白的问题是：为什么在这个行业，自己打造整个平台和所有应用的模式行得通？任何其他时候听到有人这样说，我都会回答：“算了吧，我不会投资，那是个愚蠢的策略。”但为什么在这个行业却能成功？

David：我问自己的问题说法不同，但我觉得是同一件事：Epic 为什么赢了？我认为答案突然就很清楚了。这是垂直市场软件，采用这种商业模式，才是赢得垂直软件市场的正确方法。它和打造横向软件完全不同。

Ben：有意思。

David：因为垂直软件只服务一类用户。你越深入他们的业务流程、越能解决他们的问题，产品就越好。相比之下，如果你要开发 Slack 或 Salesforce……

Ben：我们举一个复杂的横向软件例子，比如 Microsoft Office。

David：对，Microsoft Office 是最典型的例子。

Ben：或者 Windows。

David：没错。你必须非常谨慎，不能过度针对某个客户群体。这甚至会影响产品开发。你经常听到优秀的产品经理和工程师说，设计糟糕产品最可靠的方法就是听客户意见。

Ben：你会把反馈吸收进来，再根据自己的经验，或把不同客户的经验综合起来，决定什么功能最好。

David：我觉得这对打造横向软件和产品通常是对的。但打造垂直软件和产品时，你确实应该倾听客户。Epic 很擅长这一点。

Ben：有意思。

David：你需要打造客户真正想要的产品，并清楚了解客户是谁。Epic 的客户就是医院系统的 CIO、CIO 和 CFO。

Ben：我现在同意你的看法。我的答案可能是在此基础上，再加上医疗行业特有的因素，而不只是垂直行业的特点。刚才我们说过，这个行业有很多“胡萝卜和大棒”。如果软件出问题，患者可能会死亡。最合理的做法就是采用一个完整整合的系统，避免不同应用之间断开或中断，这是第一点。

第二点是各种合规要求。如果数据泄露，后果会极其严重，特别是违反 HIPAA。如果系统运行不正常，医院可能会因为违反“有意义的使用”等规定而失去 Medicare 和 Medicaid 补贴。错误会带来很多惩罚。在一个不允许犯错的环境中，即使要花 47 年才能建立一家主导市场的公司，单一供应商模式依然是正确选择。你必须写很多软件，而且这些软件必须能很好地协同工作。

David：我刚才想到，虽然我们很少在节目里讲其他垂直软件公司，但 Epic 确实是一家垂直市场软件公司。

Ben：对，我们好像确实没讲过。

David：其实也讲过一些。我之前想，为什么会这样？垂直软件公司通常不会做得这么大，因为它们受限于所在行业的规模。但 Epic 是个少见的案例，因为它进入的医疗行业规模巨大，美国医疗市场……

Ben：而且我们所有人都会用到。

David：没错，我们所有人都会用到，而且这个行业非常重要。所以，即使只服务一个行业，也能打造一家极有价值的公司。我接着想，Epic 大概是全世界最有价值的垂直软件公司。还有谁能排在它前面？

我想来想去，唯一可能接近它的是 Bloomberg。我们总有一天得做一期 Bloomberg，但那会是我们介绍的第二家垂直软件公司。后来我又查了查，发现还有人会提到 Veeva Systems。

Ben：对，Veeva，它也在医疗行业。

David：它可能是最大的上市垂直软件公司。但它的价值肯定不如 Epic，而且它同样服务医疗行业。

Ben：它的价值比 Epic 低？

David：对，市值大约 200 亿美元。

Ben：哇，那确实低不少。

David：另一家进入大型企业行列的垂直软件公司是 Constellation Software，也是我们的老朋友和节目常客。

Ben：不过他们是把不同垂直行业的公司组合到一起。

David：没错，他们是做收购整合的。我觉得 Constellation 旗下最大的一些公司，可能就是垂直医疗软件和医疗 IT 公司。Mark Leonard 肯定很欣赏 Epic，或者也可能不是，因为他旗下可能也有 Epic 的竞争者。但我相信他尊重 Judy。

Ben：我相信。她在资本主义奥运会上拿了金牌，值得尊敬。好，这期节目就到这里。我们来推荐点东西吧？

David：来推荐一些东西吧。

Ben：好，来点有趣的。

David：我今天准备了两项推荐，一项是常规推荐，另一项是提前推荐。

Ben：好啊。

David：今天我想推荐一段很有名的早期 YouTube 视频，但我以前从没看过。一位朋友推荐给我。2012 年，拉力赛车手 Ken Block 在旧金山拍了一段视频，封锁了市区道路，让他驾驶赛车在街道上飞驰。这是一段精彩的 10 分钟视频。

它就像 Steve McQueen 主演的老电影《Bullitt》里那段经典追车戏，只不过换成了一辆 600 马力的拉力赛车，由世界顶尖车手驾驶。我不敢相信以前从没看过。我看着视频想：“天哪，那些街区我都认识，我以前住在那里。”太酷了。Ken Block 最近在一次事故中去世，这也是这段视频最近又被媒体提起的原因。我后来又了解了他的经历，发现以前对他一无所知。

他是 DC Shoes，也就是滑板鞋品牌的两位联合创始人之一。公司卖给 Quiksilver 后，他开始参加职业拉力赛，成为顶尖车手之一，还在各个城市拍了许多精彩视频。真的很棒，我不敢相信以前从没看过。我们会把链接放在节目说明里。

Ben：你刚才说的东西我全都不了解，得去查查，因为刚才说的我一点都没听懂。

David：视频很短，但非常精彩，值得一看。

Ben：太好了。

David：这是我的主要推荐。提前推荐的话，我特别期待 Switch 2。

Ben：如果它真的能推出的话，或者 Nintendo 重新开放预购。

David：是啊。

Ben：也许等节目播出时就有消息了。

David：我不担心它不能按时发货。我想 Nintendo 还得解决美国售价之类的问题，但看起来太棒了。我们在 Nintendo 节目里希望 Switch 后继机能做到的事情，他们几乎全做到了：完全向下兼容、保留在线账号，而且主机设计也很出色。还会搭配一款新的 Mario Kart，光是主机本身就很棒。我迫不及待想买一台自己用。

另外，我的大女儿从出生那天起，我就一直等着什么时候能和她一起玩电子游戏。等 Switch 2 推出时，我觉得她可能终于可以玩 Mario Kart 了，我特别期待。

Ben：太好了，一定很好玩。好，现在轮到我推荐。

David：请说。

Ben：我刚重看了电影《利刃出鞘》。

David：噢，对，Daniel Craig 演的那部。

Ben：非常有趣，特别好看，就是纯粹的爆米花电影，画面也很漂亮。大家都喜欢推理片，Daniel Craig 很棒，整个演员阵容都很好。如果你还没看过，安排个电影之夜会很享受。

我的第二个推荐是 Charli XCX 的专辑《Brat》。我肯定是最后一个才发现它的人。最近我一直在听，真的太棒了。

David：你肯定不是最后一个，因为别担心 Ben，我在发现新音乐这件事上永远落后于你。

Ben：我得说，我肯定是年纪最大的男性听众。而且这张专辑 2024 年就发行了，所以这个推荐实在太迟了。我在 Grammys 上看到 Charli XCX 的表演，此后就一直循环听这张专辑，真的很棒。它能把你带到另一个世界，比你现在坐在电脑前的世界有趣多了。

David：我喜欢。

Ben：最后一个推荐是 Odesza 刚发行的《Music To Refine To》，里面是《人生切割术》的混音曲。很好听，工作时可以当 lo-fi 背景音乐。我喜欢 Odesza，也喜欢《人生切割术》，这就像我的两个世界撞到了一起。

David：很高兴我们有你给大家介绍音乐。我的音乐品味还停留在 2006 年。

Ben：如果你想感觉自己去参加了一个已经 20 年没收到邀请的酷炫派对，就去听《Brat》。

David：好极了。

Ben：听众朋友，最后再提醒一次：7 月 15 日纽约见。我们迫不及待想在那里见到大家。访问 acquired.fm/nyc 获取最新信息，也能第一时间知道活动详情。

感谢本季的合作伙伴：J.P. Morgan Payments、ServiceNow、Crusoe 和 Fundrise。

感谢所有为这期节目抽出时间的人。我们采访了几十位人士，节目里可能只能特别感谢其中四五位。

一如既往，感谢 Worldly Partners 的 Arvin Navaratnam 撰写精彩的配套文章，链接见节目说明。还要感谢撰写 Health API Guy Substack 的 Brendan Keeler，他非常出色。Oakcliff Capital 创始人、这期节目的重要思想伙伴 Bryan Lawrence，也在这里特别致谢。

Lekan Wang 是医疗科技投资人，也是 JSL Health Capital 的管理合伙人。Scott Gaines 是 Highland 和 CoverMyMeds 的资深 IT 高管。Patrick Wingo 是 Elion 的研究负责人，曾在 Palantir 系统研究医疗 IT 行业。

John Bertrand 是 Digital Diagnostics 的 CEO、8VC 顾问，也曾在 Epic 工作。他帮我了解了 Epic 的文化，以及那里是多么独特的成长环境。还要感谢斯坦福医生和投资人 Abed Meir，他曾亲自使用 Epic，后来成为投资人，并受到启发成为 Epic 股东。David，你还有几位要感谢。

David：我还采访了很多医疗系统的 CIO，非常感谢大家。我想特别提一下 Stanford Medicine 的 CIO Mike Pfeffer。

还有两位有趣的朋友是 Jenny 和我在 Princeton 本科时认识的，他们现在都在大型 Epic 客户机构当医生：旧金山 UCSF 的 Molly Kantor，以及波士顿 Harvard MGH 的 Carine Davila。我和她们聊过医生使用 Epic 的体验。

最后，我们还要感谢 Epic 的几位员工。因为网上没有关于这家公司的权威长篇资料，我们平时很少这么做，但这次就想直接发邮件问 Judy 能不能聊聊。她回复了，我们也真的和她聊了。

Ben：谢谢 Judy 抽时间和我们交流，帮我们补齐了 Epic 历史中缺失的信息。也感谢 Carl Dvorak、Sumit Rana 和 Epic 的 Lee Lavonne，他们和我们一起回顾公司的历史。

David：是的，我们真的非常感谢。

Ben：听众朋友，如果你喜欢这期节目，可以去听 Acquired 资料库里的其他节目。如果你关注医疗领域，我们特别推荐 Novo Nordisk。ACQ2 也有很多访谈，最近一期采访了 ServiceNow CEO Bill McDermot。

听完节目后，欢迎到 acquired.fm/slack 和 Acquired Slack 社群里的聪明听众讨论。听众朋友，我们下次再见。

David：下次再见。

‍