最近，医疗信息化圈子里发生了两件事，引发了我的共鸣。一件是，华南某医院因信息系统故障导致业务中断了一段时间；另一件是，东北一家民营医院信息科主任发表了一篇总结该院信息化建设经验教训的文章。

结合笔者20多年从事医院信息化建设管理的实践经历，谨在此分享在医院信息化建设工作中，关于选择技术方案应该坚持的“三原则”。

原则一：保持简单。也可以叫做“KISS”原则（Keep It Stupid Simple）。一般而言，越复杂的技术解决方案，涉及的产品和技术越多，经历的环节也越多，自然引入的影响因素也越多，相对而言出问题的概率也越大。

例如仅有一个环节的技术方案，如果该环节的故障概率为20%，则整个解决方案稳定性为80%；而两个环节的解决方案，每个环节的故障概率为10%，则整个解决方案稳定性为81%，虽然单个环节的稳定性更好，但整个解决方案的稳定性却和单环节的几乎一样。

而在实际工作环境中，对技术方案的影响因素，更多、更隐蔽也更不可控。我们来看看前述华南那家医院对信息系统故障处置过程的描述：“故障发生后，组织了IBM、Oracle、CommVault、中国电信、赛姆、北明、云和恩墨、金蝶等公司的专家,对我院数据库及硬件进行联合排查……故障原因是由于存储设备和数据库主机硬件故障，导致数据库崩溃……通过数据库双机热备份数据文件异常无法恢复……”从这个过程描述看，系统发生故障时，很可能不能确定大致的问题排查方向，因此需要协调这么多的厂商技术力量。在短时间内，光是协调这么多厂商就是很大的工作量，是一个非常艰巨的沟通过程,也充分体现了医院的影响力和厂商的职业素养，要为他们点赞。最后对故障的原因描述得有点模糊，究竟是存储设备故障、数据库主机故障，抑或是存储设备和数据库主机都有故障，还是那个双机热备系统故障？类似这样找不到明确故障原因的现象，在实际工作中很常见。由此可见，在医院现今眼花缭乱的产品集成环境下，要快速定位并解决医院信息系统故障会有多么的困难，技术方案保持足够简单又有多么的重要。

需要明确的是，所谓“简单”，是相对于自身的技术能力而言的。同样的一套大数据平台架构，也许对于BAT的技术团队来说就很简单，而对于国内医院信息科的技术实力来说，可能就很不简单了。在保持简单的原则下，个人认为还有几个基本的规律需要遵循：技术方案的复杂度要和项目的重要程度成反比；技术方案的复杂度要和项目涉及的人数成反比；技术方案的复杂度要和项目的性能要求成反比。

原则二：追求细节。细节之所以重要，是因为信息化技术方案最终都要在真正的工作环境里解决实际问题，来不得半点疏忽。个人认为：99%的人都能把技术方案做到基本符合要求，只有1%的人会把技术方案做到优秀。而体现优秀的所在，正是在大家都采用的技术方案基础上，将相关的方方面面细节都考虑周全了。

吉林国文医院信息科主任在信息化建设的总结中，多次就提到关注细节的极端重要性：“我总结了三大点：一是合同签订时比较粗放，没有考虑细节……二是合同中未明确接口费用及接口数量……切换系统的三点经验：首先，由于有了前车之鉴，这次合同由我主抓，尽可能详细……项目实施的7点细节……要更多注意实施中的细节……”

回过头看看自己在实际工作中，对于每一个技术解决方案的确定，工作量最大部分、也是最难的部分，就是对细节的梳理。比如2017年北京市实现药品零差价政策时涉及信息系统切换，为了节省切换过程的每一分钟，我们把每条语句需要处理的数据库条目精简到最小，每条语句开始执行时间也都明确到几点几分、在多长时间内执行完毕，细致到每条数据改什么、什么时候改，以及相应的备份、回退措施等。

原则三：坚持常识。生活中有太多的常识，因此往往容易被忽视，而常识的重要性怎么强调都不过分。

有三个基本常识在我们选择技术方案的时候经常会用到。第一个是要研究人的动机。克拉克经济学奖获得者史蒂文.列维特说：“动机是现代生活的基石。理解动机或者找出人们真正的动机，几乎是解决所有社会问题的关键”。

比如，我们经常谈到医院实施检查科室的“集中预约”系统，如果在检查科室没有实现统一管理的情况下，几乎不可能成功，根本原因就是用户没有要实施集中预约的动机。

第二个是考虑机会成本。简单说，机会成本就是你选择了做A事就失去了做B事的机会，而这个B事所带来的收益就是你的机会成本。面对机会成本，我们在选择技术方案的时候一定要问问自己：“我们选择这样做而不那样做，损失了什么？”

比如，在我们选择“诊间缴费”方案的时候，就需要考虑哪种情况是合适的。假设一位主任一上午看60名患者，平均每人大约3分钟，而缴费过程每个患者需花10秒的话，就是600秒，这10分钟又可以看3名患者。所以，针对稀缺的优质专家资源，这种机会成本是很高的；尤其，缴费这种政策性非常强的业务，并不是每个医生都可以应付自如，遇到患者对费用发生质疑的时候，更可能会让医生非常被动。

第三个经常用到的常识是使用“80/20法则”。在一个技术方案中，我们要用80%的资源来实现20%的功能，剩下20%的资源来实现80%的功能。十多年前，在编制门诊收费程序的时候，发现在该程序的20多个功能中，“收费处理”功能是使用最频繁的，收款员绝大部分时间在使用这个功能。因此，该功能的交互界面和内部处理流程是很重要的。在具体程序编码过程中，也确实是这个功能花费的精力最多，界面中的每一个细节都需要仔细斟酌、反复修改，小到每一个字显示的字体、大小、颜色、摆放位置，用户视觉的焦点，鼠标常常停留的位置，按键光标移动的规律等，并且要让用户实际使用，在用户反馈过程中再反复修改。

以上是笔者在实际工作过程中的点滴体会，不同的技术方案会有不同侧重。而实际上，一个技术方案还会受到其他方方面面因素的影响，比如问题的定义、边界、有限资源等，此文就不一一列举了。