本文由Markdown语法编辑器编辑完成。
1. 《一个都不能少》
《一个都不能少》是1999年上映的一部剧情片，由张艺谋导演拍摄。该片使用一班非专业演员制作一出像纪录片的电影，故事主题是关于农村、贫穷及文盲的问题。本片获得十项国际电影奖项，包括金鸡奖、圣保罗国际电影节和威尼斯电影节的金狮奖。
（图片摘自豆瓣：https://movie.douban.com/subject/1294963/）
水泉小学原先有三四十个学生，每个新学期开学都有学生流失，直到只剩二十八个人。高老师临走时再三叮嘱魏敏芝，一定要把学生看住，一个都不能少。魏敏芝整天让学生抄课文，每天清点人数，谁要把学生弄走，就跟谁急，连村长的话也不听。学生见她人小，又不会上课，不听她的，有的故意跟她捣乱，弄得教室里乱哄哄的。她不顾不问，只是守在教室门口不到时间不让走。
十岁的张慧科因家里欠债无力偿还，不得不失学到城里打工。魏敏芝记住高老师临行前的叮嘱，决心把张慧科找回来，她打听到张慧科城里的住处，单身一人踏上了进城之路，十三岁的魏敏芝开始茫茫人海里的寻找，终于在电视台台长的帮助下，找回了张慧科并得到了好心人的帮助，得到了大量的粉笔和文具。
——摘自百度百科。
我记得当时在央视电影频道看到了这部电影，虽然没有完整地把这部电影看完，但是电影的题目《一个都不能少》却深深地印在了我的脑海中。不经意间，这个词语就会冒出我的心头。
2. HIS系统的一个都不能少
近一年多在一家三级医院做医院信息化系统（Hospital Information System, HIS），亲身感觉到了在做医院这种，每天都有很多医生，护士在使用的，关系到入院的每个病人就医的每一个环节的系统时，对于数据的安全性和完整性，是多么多么的重要，容不得有半点的疏漏。套用这个“一个都不能少”的6字标题时，我大概可以概括为以下几点：
2.1 系统收费退费一分钱都不能少
费用计算准确是衡量一个系统是否可信，安全和精准的标准。如果一个系统自己内部的账都算不准确，那谁还敢用这样的系统来工作。到时候假如系统算出的账，和收费处的老师实际拿到的现金不相符，难道还让收费处的老师自己贴钱来补齐这个差额吗？
特别是对于HIS系统，由于有很大一部分费用是跟药品有关的。药品又分为：西药，中成药，草药；药房药库又分为了：中心药房（负责住院部），门诊药房（负责普通门诊），急诊药房（负责急诊），草药房（负责草药），药库等。
中心药房由于是负责给住院部的患者发放药品的，因此在发药时，不是按照整包装来发药的，而是会按药的最小单位来发药，因此每片药的价格就需要用整包装的钱去除以数量，这样计算出来的药片单价有可能会是一个无限循环小数。HIS在计算时，为了能够尽可能地接近真实价格，就保留了4位小数。这样，最后在月底药房药库进行盘点的时候，就会出现金额的差价。
此外，对于医院，存在患者退费的情况，而且退费时还不是全部退费，而是部分退费。比如一个病人刚开始开了10盒药, 结果他服用了3盒药后就康复了. 那么他可能之后就会把剩下的7盒药退掉. 诸如此类的部分退费情况， 数不胜数。 如果只是HIS自身来完成部分退费的逻辑，还好处理。但是，由于大部分病人都是医保病人，当初在缴费的时候，有一部分费用是由医保给垫付的。因此，在办理退费时，也需要涉及到医保的部分退费。但是，医保本身又不支持部分退费，因此需要HIS将部分退费拆分为两个过程来完成：先将原来的所有费用都退掉，然后再收取用户真正消费的那部分费用。在系统中，这里有一个专门的名词与之对应——红冲。
2.2 医保一笔交易都不能拒付
2.3 患者基本信息一个都不能少
2.4 患者挂号信息一个都不能少
2.5 检查/检验申请单一个都不能少
2.6 业务流程环节一个都不能少
这个业务流程环节一个都不能少，让我感受最深的就是：在HIS上线的那天，由于是先切急诊科室的。因为急诊科是24小时都开放的，而门诊是上午8点到下午5点。因此，从凌晨0点到上午8点，这段时间内是只有急诊科在使用我们的HIS系统。
急诊科除了普通的诊室，还有一个类似于住院的地方，叫“急诊留观”。那里住着的病人一般是急诊科的大夫在给挂急诊科的病人初步问诊后，感觉病人还需要再在医院再观察一段时间，但又不需要办理住院，通常就会叫这部分病人申请“急诊留观”， 然后在急诊留观间给其分配一个暂时的床位，留院观察一段时间，待到病情稳定后，再做下一步的安排。
在张嘉译和王珞丹主演的电视剧《急诊科医生》中，有很多病人都是在那个叫做“急诊留观”的病房里住着呢。
HIS系统需要与急诊留观间的“移动护理系统”进行系统集成。集成的主要流程是：HIS需要将急诊留观的患者的“基本信息”和“挂号信息”通过指定的接口，通过医院的集成平台，再发送给移动护理系统。发送成功后，移动护理系统的患者列表中便能看到这个急诊留观的患者基本信息，然后急诊留观的护士，便会在移动护理系统中对这个病人进行分床，并且执行之前大夫给这个病人开的医嘱。
当时在上线前，我们一直以为住在急诊留观病人的病人，都是经过留观申请，并且通过后才会进入留观病房的。因此，我们之前在进行系统集成联调测试时，也只是当病人在申请急诊留观通过后，才把病人的基本信息和挂号信息发送。但是，上线的当天凌晨，有一个急诊病人，没有办理留观申请，但是已经直接被推进了急诊留观的病房。当留观的护士还按照原来的工作流程，准备从移动护理的患者列表中给这个病人分床时，发现在患者列表中找不到这个患者了。这下可把护士给急坏了，正当我们在休息准备迎接第二天早上的门诊上线时，急诊科电话已经打过来说怎么分床时找不到刚才的病人了。
我们几个相关的技术人员，赶紧去了急诊留观病房，询问护士她们是如何操作的。后来经过她们的描述，我们才知道：原来移动护理系统中的患者列表，除了办理了留观申请的患者，还有所有挂了急诊科号的患者。也就是说，我们压根就没有把这部分未办理留观手续的急诊病人信息发给移动护理系统，她们当然就没办法在患者列表中看到这个病人和对这个病人进行分床了。
这还不算是致命的失误。因为虽然系统里无法对这个急诊病人进行分床，但是护士还可以先在线下进行操作和记录，不会耽误患者的治疗。但是，这个小小的需求变更，对于我们来说，却是一个非常大的失误。因为这涉及到代码的很大改动，以及联系与移动护理系统的重新联调测试，这无形中又增加了工作量和成本。
通过这件事，我也明白了，对于这种业务上的需求，必须要理解准确和清楚。当初仅仅是由于对推患者的类型与实际的业务有出入，就导致了后续额外的工作量，也给医生，护士和患者带来不便。因此，以后在调查需求时，必须要对业务非常熟悉，才可以进行编码和测试。
未完待续……
