2014 年 8 月,我 27 岁,住在安曼,我做了一件所有明智的人都告诉你不要做的事:我创办了一家软件公司。不是 SaaS 副业项目。是一家医疗软件咨询公司,最终会向沙特阿拉伯艾哈萨省的 Prince Sultan 心脏中心部署一套完整的电子健康记录系统。

我们叫它 AFAQ。十二名工程师。真实的医院。真实的患者。我同时担任创始人、CTO、首席工程师、产品经理、代理 CEO、IT 经理和研发经理——全都在同一张名片上,拿着同样的薪水(第一年实际上是零)。

没有人警告我”什么都管的首席”是个会以狗年速度让你变老的职位描述。

AFAQ 实际上构建了什么

我们构建了一个 EHR/EMR 平台——临床、行政和财务模块,外加完整的 ERP 能力。这个想法是医院不应该需要七家不同供应商的七套不同系统。我们会交付一个连贯的平台,约旦制造,部署给正处于从纸质和遗留系统升级到现代系统的中间阶段的海湾地区医疗机构。

技术栈不小。Java EE。Spring Boot、Spring Security、Spring WS。Hibernate 加 JPA。前端:重型临床界面用 GWT(Google Web Toolkit),行政界面用 AngularJS 和 Bootstrap。ETL 用 Talend。应用服务器用 Tomcat 和 WildFly。集成用 PHP 加 Symfony 和 Yii。主数据库用 MySQL 和 Oracle。互操作性用 HL7 和 FHIR。

太多了。对一个十二人团队来说太多了。我们还是发布了,因为当你是签合同的那个人,你就没资格抱怨范围。

那个没人在写的数据库 connector

这里有一部分我至今还为之自豪:我们为 fis GT.M 写了新的数据库 connector。

如果你没听说过 GT.M——你不孤单,而这正是重点。GT.M 是一个层次化 NoSQL 数据库,运行在 VA 开源 EHR 系统 VistA 内部,这个系统从 1990 年代起就被部署在美国退伍军人医院。它跑在一门叫 MUMPS(现在叫 M)的语言上。它的访问模式是古老的,工具链是稀疏的,文档假设你已经了解这个系统四十年的上下文。

2015 年没有人在为 GT.M 写现代数据库 connector。我们写了,因为 AFAQ 的平台需要和跑着 GT.M 基础设施的医院系统对接——而”我们绕过去”不是一个选项,当你客户的药房和计费数据都在里面的时候。所以我坐下来,读了 GT.M 程序员指南,读了 MUMPS 规范,写了让 GT.M 在现代 Java 服务面前表现得像一个可以被调用的东西的 connector。

在职业生涯中大多数工程师不会写数据库 connector。写过的那些人中,大多数会为 Postgres 或 MySQL 写,每个问题都有 Stack Overflow 答案的地方。2015 年为 GT.M 写 connector 意味着读在我出生之前就开始做这件事的人写的源代码和邮件列表。

十二名工程师,一张说不通的组织架构图

一边是产品首席工程师,一边还要管理十二名工程师,这是一个没有干净答案的协调问题。你应该委托技术决策。你也应该比团队里任何人都快地做出决策,因为你是对合同负责的那个人。这两件事不断互相打架。

我学到的:小型咨询公司里最重要的约束不是技术性的,而是每个人任务范围的明确性。每位工程师需要有一个他们拥有并对其负责的东西。一旦两名工程师都在”做临床模块”,你就有了一个合并问题和通信开销,它会吃掉你的 sprint。

我们在它成为博客概念之前就在跑精益领域所有权。计费工程师拥有计费。药房工程师拥有药房。我拥有跨越这些界限的架构决策,而我每个月最多做两个,因为每一个横切决策都是对所有人的上下文切换税。

心脏病医院 deploy 里的 KPI 分析是什么样子

在 Prince Sultan 心脏中心 go-live 之前,我们对他们的临床工作流进行了 KPI 分析和实施。这听起来很抽象。以下是具体意味着什么。

心脏中心关心的是:门到球囊时间(从胸痛到介入手术需要多长时间)、用药对账错误、重复检验医嘱、部门间患者 ID 不匹配。这些不是理论上的 KPI。它们是生死安全 KPI。把报告搞错不会产生糟糕的季度评审——它会产生一个你不想被点名的临床审计。

所以我们和他们的临床负责人坐在一起,把他们现有的基于纸质和遗留系统的工作流映射出来,然后在我们的 EHR 里构建在正确地方呈现正确数字的报告 pipeline。Talend ETL 承担他们遗留数据和我们模型之间转换的重活。HL7 消息携带互操作性层。

go-live 不是一个戏剧性的时刻。那是个周二。几个护士问按钮移到哪里去了。这就是你知道进展顺利的方式。

AFAQ 真正是为了什么

AFAQ 从 2014 年 8 月运营到 2017 年 1 月。两年半。我们交付了。我们有客户。我们在生产医院里有运行中的系统。

但 AFAQ 与其说是一家公司,不如说是一座熔炉。十二名工程师进来时知道 Java 或 PHP,离开时知道医疗数据模型是如何工作的、HL7 为什么存在、如何与一个有十二层审批流程的医院 IT 部门谈判合同,以及当你的生产数据库是 Oracle 而你的客户是沙特阿拉伯的一家心脏病医院时,在数据模型层做出错误假设会付出什么代价。

我从 AFAQ 出来,带着一套非常具体的观点。医疗软件在和代码无关的方面比企业软件更难。一个十二人团队足够大,能产出真实系统,也足够小,仍然以百人公司没有的方式脆弱。为一个 1980 年代层次化数据库写数据库 connector,是比你上的任何课程都更好的数据建模教育。

有六个职称的名片是混乱的。我们交付的系统不是。那就是全部意义所在。