副标题：全面分析国家疫情网络直报系统，设计与应用缺陷是其失灵根源！（下）
（下：系统如何优化改进）
人类的认知模式总是从既往已有的知识与经验去推及未来。过去若干年以来，无论是对于作为需求方的软件系统项目建设者来说，还是对于作为供应方的软件开发商来说，国内绝大多数管理软件的系统开发，其设计思想与产品路线实际上主要就是把“原先手工业务的作业过程与管理方式”（即所谓“用户需求”），照搬、模仿或整理、再现进软件系统里，成为一种系统可以流程化运作的工作方式。这在管理软件的发展史上有一个相应的特定称谓“电算化模式”（即手工作业的电子计算机化）。
而在管理软件设计与应用领域，与国内全行业普遍流行并采用的“电算化模式”不同的是，国际上代表行业最高先进水平的是所谓“软件包使能模式”。“软件包使能模式”实际上来源于年左右IBM公司所提出的“软件包驱动业务变革”（PEBT，PackageEnabledBusinessTransformation）这一概念。按IBM当年为华为提供管理咨询服务时所给出的定义，其中的所谓“软件包”，实际上是指一系列业务与管理逻辑基于计算机与软件特性的高效协同，西方公司在企业管理方面，已经有了上百年的经验积累，他们总结了非常多的业界最佳实践，通过软件包的形式把它展现出来。
“电算化模式”的管理软件听起来好像有点不够“高大上”，但今天实际上已广泛存在于社会经济生活中的各个方面，例如我们现在常说的“2C类消费互联网（个人应用）”就基本上主要是这种性质；而对于2B类产业互联网（企业应用）来说，除了少数的所谓“高端”应用软件（SAP/ORACLE）是例外，目前国内绝大多数“中低端”企业应用诸如你在网上看到的各种B2B平台，各种自称是企业ERP、HR、CRM以及OA办公软件等等，基本上也都是这种性质。
注意，这里所谓的“高端、低端”，并没有什么特定“褒贬”的涵义，它仅是行业内的一种分类习惯，即如同样是求解一道应用数学题，你可以是用大学的“微积分、复变函数”，也可以是用中学的“代数、几何”。实际工作中，“电算化模式”与“软件包使能模式”两者各有其应用优缺点，各有其适用的业务场景与管理目标诉求。详细研究探讨这两者的区别与不同，非是本文目的，以下仅重点讨论这两者在国家疫情网络直报系统中的相关应用问题，
一、国家网络直报系统基于“电算化模式”的现状及其问题。
对于“疫情网络直报”这一本来就不算复杂的“业务场景”来说，从“（手工作业）电算化模式”的业务流程设计角度来看，它其实相当简单，仅主要包含三方面内容：一是基层医疗单位的“网络直报员”将纸面的“传染病报告卡”的内容新增录入直报系统；二是（县市省）疾控中心审核员审核确认“传染病报告卡”；三是各级疾控中心分析监测传染病数据；
而从疫情网络直报系统最初的应用功能设计角度来看，它则主要包含了“报卡管理（新增、审核、查询）”与“统计报表/数据分析等”两大组成部分。其中，报卡管理中的所谓“新增报告卡片”功能就是基层单位（医院）的“网络直报员”所主要使用的菜单功能。如下图C所示：
图C报卡管理中的所谓“报卡浏览审核”功能就是各级疾控中心的“审核员”所主要使用的菜单功能，如下图D所示：
图D而所谓“统计报表、资料分析”等其余的菜单功能，医院已经填报并记录在系统数据库中的“传染病个案”数据信息，从地方到中央的各级疾控中心所进行分析、监测的各项日常工作。如图E所示：
图E此外，参照上述并不复杂的“传染病个案报告”系统设计与应用实现方式，基于实际管理工作的需要，这个直报系统后来又陆续补充增加了若干种类可能需要基层医疗单位填报的“表格（报告卡）”数据功能，例如，为满足本次新冠疫情数据的收集、分析、监控需要，国家疾控中心于年1月24日紧急开发、上线运行了“新型冠状病*感染的肺炎动态监测系统”等等。如下图F所示：
图F有细心的读者可能已发现，上述若干种类的“表格”直报系统相互之间，有些表格内容是有交叉重叠的，例如“疾病监测信息报告系统”与“甲型H1N1流感信息管理系统”等，这也是有媒体在武汉采访时，有医院方面抱怨说直报系统“有点多、有点乱”的来由。究其原因，和系统功能的设计与应用方式原本就是“把手工表格（EXCEL）内容照搬进系统，有一个表格就对应一个直报系统功能”的做法有关。
实际工作中，这种“手工作业电子计算机化模式（电算化）”的管理软件有着诸多明显的好处与优势。一方面从系统开发者角度来看，照猫画虎、照葫芦画瓢、简单省事，行业进入门槛低，所需要的系统管理知识、技能、经验比较少，对设计人员的业务、管理、技术的归纳、综合能力与水平要求不高等；另一方面从系统使用者角度来看，与原先的手工操作高度相似，简单易懂、好学易用，学习成本低、难度小，无需对原先已习惯熟悉的业务流程进行调整，系统应用推广容易、阻力小等。
但寸有所长、尺有所短。管理软件“电算化模式”在拥有种种好处的同时，也存在诸多自身难以克服的根本性缺陷，例如无法充分利用机器（计算机）的优势与特长；类手工作业环节只考虑当前与局部，数据信息收集不全面、不完整；类手工作业流程简单粗糙，继承保留了手工作业的缺陷与不足，总体应用水平不高；类手工方式严重束缚信息系统管理的内在价值与潜力的充分发挥等等。
疫情网络直报系统“电算化模式”照搬照抄原手工作业（EXCEL）方式的系统设计与应用缺陷，不仅导致了武汉疫情早期，尽管有不少一线医生对武汉卫健委下发的判定不明肺炎标准表示不同意，认为门槛太高、不合理，但也无可奈何、无法正常发声；也导致了武汉卫健委有关工作人员仅凭一句未必是深思熟虑的口头意见：“经区、市、省级逐级检测，仍为不明原因肺炎后，经省卫健委同意才能进行病例信息上报”，医院后续关键疫情信息的及时报告与披露；最终导致了国家网络直报系统在遇到COVID-19这种“首例正式报告到疫情爆发仅半个多月、发展迅速”的新发传染病时，立即变得不堪一击、形同虚设，给国家经济造成巨大损失，给人民生活带来沉重灾难。
二、国家网络直报系统基于“软件包使能模式”的设计优化与改进
全方位研究探讨“软件包使能模式”在管理软件中的具体应用非是本文所能胜任。以下仅参考其“不拘泥于手工作业现状、充分发挥机器特长与优势”的基本指导思想，就“疫情网络直报”这一原本并不复杂、比较简单的“业务场景”提出如下几点系统优化改进建议，以供有关方面参考：
（一）“传染病报告卡”的系统填报。在保留原“医院（院感办）直报用户”功能的基础之上，还必须增加“一线医生”直接填报的功能。基于传染病病例数据信息采集的三个“第一”原则，即“第一时间、第一现场、第一责任人”，对于有条件的基层医疗单位（医院等），必须坚持让一线医生在网络直报系统中直接填写有关传染病病例的采集信息。
（二）“传染病报告卡”的系统审核。原先的“审核”功能需要被分为“医院院内审核”与“法定报告审核”两部分。由一线医生在直报系统中直接填写的初始传染病病例信息单据，基于系统院内审核流程与规则设置，医院内的（至少）两级审核（科室主任、院感办），并拥有若干种相对应的单据状态；若“病例信息单据”是由院感办直接录入，则相关单据将有不同的初始状态。院感办已完成的“医院院内审核”的单据或由院感办直接录入的单据，最后均须由由院感办“直报用户”代表院方负责提交报告本地疾控中心，以便启动网络直报系统的疫情信息“法定报告审核”流程。
（三）医院内部HIS系统的对接。网络直报系统提供可以调用的API接口，同时对各家HIS供应商的软件产品中，关于“传染病病例数据信息”的填写与生成作出标准规范。医院内部HIS系统中创建“传染病病例数据”单据后，可通过点击“导入直报”功能立即调用API而将相关数据直接导入网络直报系统；导入的一线医生创建的初始状态的病例单据，后续单据提交、院内审核流程全部在国家网络直报系统中完成（医院HIS中的创建、审核流程完全同步到国家网络直报系统），与一线医生在国家网络直报系统中手工直接创建单据无异；
（四）智能数据分析、机器人报表与预警。目前网络直报系统中的所谓数据查询分析及报告功能，其应用设计仅从“把数据查询条件当作用户菜单功能项”这一点来看，就可以推断其似乎还停留在类似EXCEL的应用水准，完全不能体现过去若干年来计算机在线数据分析（OLAP）领域所取得的应用成就，例如BI商业智能分析、大数据分析等等。
另外，受传统手工（EXCEL使用）习惯的影响，目前国内几乎所有的管理软件都采取的是所谓“查询式前台报表”的设计方式，好处当然是简单易用，因为和一般的系统数据查询功能相比，差别不大。但缺点也是显然的，一是只能进行比较简单的数据处理，业务逻辑复杂、数据运算量大、机器耗时长的就处理不了，二是灵活性、可配置性、可管理性比较差，难以满足管理者（如领导者、专家组等）突发的、随机的、个性化的需求。例如专家组需要知道不明肺炎感染/易感性与患者职业（是否医生等）、年龄、家庭、地域等等各种关键考量因素的综合关系等等。
所谓“智能机器人报表与预警（并发管理器）”，若从纯粹的技术角度来看并无特别，因为一般的技术开发人员，都会写一段可以定时运行的后台服务程序，来执行某些特定的任务。但如何对数量上可能成百上千或更多的所谓“并发程序（智能机器人）”进行有效管理，达到所有人都可以基于管理授权、工作需要而随时随地灵活应用，就不是纯粹技术性问题了。但令人遗憾的是，这么多年以来，国内绝大多数管理软件系统的设计开发，囿于认知水平、经验见识，对于这种比较抽象、与手工习惯差异较大的东西，要么知之甚少，要么难以接受。
综上所述，上述网络直报系统改进建议的核心与关键，就是摒弃传统的手工做法与管理方式，系统传染病病例数据信息采集在保留原“院感办直报员录入”方式的同时，另外也给予一线医生最大的参与权、自主权、发声权（想一想武汉曾有多少“艾芬医生”在遭上级领导训斥之后的无奈与愤懑吧！），以便在系统层面尽可能做到相关数据信息的“应收尽收、应记尽记”，而这一点对于“不明原因肺炎”的尽早发现、尽早报告的系统保障作用尤其重要！
即使网络直报系统后续有关院内审核环节因种种原因审核不通过（院内会诊也可能犯错），也基本不影响所有各级疾控中心对于疫情数据尤其是“不明肺炎”的统计分析与监测；提交院内审核、提交上级疾控部门审核的目的不再仅仅只是为了“报告”，还包括为了保证最终数据质量，对数据进行分类分级、方便统计分析等作用。
“软件包使能模式”的特点就是不完全立足于直观的、可见的业务当前，更强调借助机器的工具手段实现对现有业务与流程的优化与提高，以便从总体上获得更好的管理效果。医院直报用户可以新增录入传染病报告卡数据的“电算化模式”的简单化做法，医院“一线医生”直接在直报系统中新增填写“传染病报告卡”之后，系统业务流程与管理功能的设计复杂性、实际应用推广的难度，以及进入网络直报系统的数据量等方面一定都会有比较大幅度的增加。
如果考虑到系统的使用范围是全国近10万家基层医疗单位，则由此改变所造成的系统应用难度与管理成本增加的幅度应当也不是一个小的数字，但这种“应用难度、管理成本”的增加绝对是必要的、不可或缺的，因为相对于“简单化”做法所造成的（新冠疫情）严重后果与巨量损失，多那么一点子管理成本与花费简直可以忽略不计！
三、“一线医生”直接使用网络直报系统的相关问题
有读者或许还是会担心，当前网络直报系统的直报用户（单位）数量就已达10万个，再增加一线医生以及相关科室主任等人员进入，是否会导致系统用户数量庞大，系统管理工作量与应用难度剧增等问题，导致系统在实际工作中难以被有效、合理地应用？
首先，从系统管理功能设计层面来看，医院“系统用户/权限”还需要通过提交纸面的“用户/权限申请表”给上级部门（疾控中心），由上级部门批准、设置的原始、笨拙的手工管理方式，需要从系统管理功能灵活性、完善性设计层面，更改并实现为“医院在直报系统中自主管理”，即医院自己在系统中负责管理设置本院的用户及其权限。
其次，从系统应用推广管理角度来看，实际工作中也没有必要将有关“不明肺炎填报”应用推广至包括数万乡镇卫生院在内的所有一线医生。因为基于实际生活常识与历史经验，通常一个较低等级的基层医疗单位（医院）在遇到自己无法确诊或难以治愈的病例时，大概率会选择让病人转院至更高等医院。
例如，年SARS的首例病人先是医院住院治疗，后病情危重了被医院（医院），其后才被正式报告给疾控卫生部门；而此次新冠肺炎的发生，离华南海鲜市场最近仅医院（医院）也很早就接诊了有关疑似不明肺炎病例，据有关医生事后回忆：一开始只是当普通感冒发烧治疗，发现不对劲之后有些病人是自己选择、也有些是在医生建议之下去医院。
医院约二千多家，医院约八千多家，若仅需这些三级、医院的相关一线医生承担起“不明肺炎”的网络直报系统的填报工作，则虽然可以参与网络直报的一线医生数量被大大减少，但也足以保证网络直报系统能够对新发传染病实现“早发现、早报告”的管理目标。
此次武汉疫情，有人推测（南华早报报道）更早可能是在去年11月中旬就已悄悄发生。设想一下，在11月中旬到12月中旬的那一段早期时间内，医院一周之内仅有一个医生在系统中记录并发出了仅1例“不明肺炎”的疑问或警示，即便其在网络直报系统中是“自问自答、自说自话”，只保存不提交，或者提交了但被科室主任、院内专家会诊所否决，因而如同仅是一小杯水，不会引起院内其他人更多的重视。
医院，医院就有三十多家，相关的一线医生数量十分可观，汇总起来就是一周之内有关不明肺炎的疑似病例突然从0或一个很小的数字猛增至30-例左右或更高（系统自动监测到相关数据的异常变化并拉响警报，易如反掌）。此时，就不再只是一小杯水的问题，而是一大盆水的问题。这一大盆水兜头浇下来，足以令武汉各级疾控中心/卫健委、武汉主*者、各路专家乃至远在北京的国家卫健委、疾控中心/高福院士全都猛然惊醒、高度紧张起来，尽早拉响警报、动手采取防控措施。
有读者或许还会有疑问，医院内审核不通过的所谓“无用数据、垃圾数据”引入国家疾控中心CDC数据库，是否可行？会否影响后续CDC的数据分析得出正确的结论？医院的张文宏主任就曾在媒体采访时谈到：“一个冬季，每个城市至少数万例吧。这个系统要一一鉴别，最后还要告诉你是流感、疱疹病*、呼吸道合胞病*、腺病*……这是不现实的。所以一个有效的申报系统首先要有有价值的信息。这说明，我们必须对当前不明原因肺炎申报体系进行改造”。
张文宏主任认为：目前的网络直报系统的一个问题是“经受不起大量垃圾信息的摧毁”。他说的这一点完全正确，但前提是仅针对目前“简单照搬手工作业方式”的网络直报系统而言。对于已按“软件包使能模式”优化改进过的网络直报系统来说，这根本就不是问题。
因为系统在做“不明原因肺炎”的数据统计分析与监测预警时，会首先从多个维度、不同层次对海量数据进行分类分级，例如：一线医生未确认、一线医生已确认、科室主任已确认、医院已确认、疾控中心已确认等等；医院数据、医院数据、乡镇卫生院数据等等；不同维度、不同层级的数据，系统会赋予不同的分析权重、风险系数，从多个角度去判定当前的风险程度以及基于时间轴的变化趋势。
武汉去年12医院的“疑似不明原因肺炎”数据，若能全部及时进入直报系统，基于系统事先设置的各种数据分析模型，即便不做人工干预，系统也会自动得出有价值的、正确的预测结果与判定结论并提供给各路专家、各级决策者。最近几年被市场炒得火热的所谓“大数据分析”，没能在这次新冠疫情的防控中起到关键性作用，委实令人遗憾！
人不可能去模仿机器/计算机的工作方式，反过来机器也不应该去简单模仿人的手工作业方式；人工可以实时处理几条、几十条数据，但不可能实时处理成千上万条数据，但计算机/机器在恰当的系统业务逻辑与应用设计功能之下，及时、高效地处理海量数据并得出正确的结论并不是什么困难的事，机器实时处理几条与几万条数据的速度区别可能仅仅只是几毫秒之差。信息化（机器）可以让可能变为不可能，也可以让不可能变为可能。
四、网络直报系统如何阻止本次不明肺炎疫情的爆发
回到我们前面所讨论的疫情网络直报系统，如果当初的系统规划设计者能够不拘泥于手工作业现状，能够站在更高的业务管理优化的角度去看待问题；又或者在随后十几年的该系统应用实践中，相关的业务管理者、系统维护人员在发现“系统对不明肺炎存在防控隐患”之后，能够及时意识到网络直报系统存在设计与应用缺陷，并尽早对该系统进行优化改进，则该网络直报系统对于本次新冠肺炎的早期预警防控就根本不可能会失灵，新冠疫情虽不能完全被阻止发生，但极大概率后来的发展也不会超过年SARS的为祸烈度与灾害程度。
设想在网络直报系统不存在设计与应用缺陷且运行正常的情况下，相对于年12月27医院的张继先主任口头报告首个不明肺炎病例，系统极大概率能够至少提前10天（至12月17号，医院已发现多个不明原因肺炎病例），或者提前15天（至12月12号，医院已发现多个不明肺炎病例），或者更早发出明确的“不明肺炎”预警（至12月8号，武汉官方后来承认的首例病人被发现的日子），并收集到足够多的、详细的相关病例数据信息，则后续新冠病*检出分型、基因测序、检测试剂盒的制备与量产等等一系列工作，也会至少整体提前10天、15天或更多时间，则1月16号武汉本地可进行核酸检测以方便确诊的实际日期就可以被提前到1月6号、1月1号或更早等。
那么以此类推，即便年元旦前后半个月时间的武汉防控措施不升级，直至年1月7医院急诊科陆俊医生双肺感染入院，1月10号医院李文亮医生感染入院等，武汉医护人员的感染病例数据也进入CDC不明肺炎病例数据库，则此时数据库中的不明肺炎或新冠肺炎确诊病例数按12月30号例的基数推算，基于钟南山院士团队的预测模型，每5天翻3倍，到1月10号的病例数量应该已经接近0例（而不是武汉卫健委实际通报的59或41例），这足以令所有的有关各方立即得出“新冠肺炎强烈人传人、疫情已经非常严重”的判定与结论。
此时“春运”才刚刚开始，如若断然采取相关“隔离与防控”措施，或即便不立即采取“武汉封城”这样最激烈的举措，仅采取外出强制戴口罩、取消聚集性人群活动、关闭公共场所、限制交通出行、春节假期禁足等等“中等强度”的防控措施，则大概率上武汉后来也不会出现医疗资源严重挤兑所出现的惨况，武汉及湖北的病例总数或可下降到1万以内，武汉及湖北输出到全国各地的病例总数或可从现在的左右下降到0左右，则新冠疫情对于中国经济的总体影响程度或许只有目前评估的五分之一到十分之一左右。
此外，如若网络直报系统不存在设计与应用缺陷且对不明肺炎的预警报告、监测防控正常有效，则在元旦之后的前半个月，大概率上李文亮等八个医生遭警察训诫、央视新闻辟谣、团拜会、万家宴等等一系列后来被舆论广为诟病的颟顸事件也就不可能会发生。推而广之，从武汉到全国、再到全世界，全球各地的疫情发展状况是否会有根本性改变或许无法预测，但国外认为中国*府故意隐瞒了疫情的各种“甩锅”言论则至少失去了发生、存在的基础，国际舆论场上如今的中国或许就不会在某些方面显得那么被动。
五、网络直报系统失灵的教训给我们的启示
根据有关媒体的调查了解，网络直报系统在过去若干年的使用过程中，早就曾经有人如张文宏医生那样对于“不明原因肺炎”的处理、对于系统的设计与应用问题产生过疑问，例如向妮娟、冯子健等人在年发表的《4-9年中国不明原因肺炎病例报告情况分析》论文中，就曾对不明原因肺炎病例的系统监测、报告等方面所存在的隐患问题做过相关分析，认为当前的不明原因肺炎处理流程，有形、无形地给卫生行*部门、疾控机构、医疗机构以及临床医务人员带来了很大压力，没人愿意通过直报系统申报。
千里之堤，毁于蚁穴！我们现在很难想象与理解，为什么网络直报系统所存在的这样一个似乎“人人皆知”的系统实际应用问题，且深入研究起来并不算困难与复杂的“设计与应用缺陷”，何以在过去十几年相安无事的太平日子里，一直就没有被及时纠正与有效解决？一直被有关方面所无视与忽略？
笔者认为，表象背后的根本原因可能还是和管理软件的设计与应用，长期以来国内无论是“需求方（用户）”还是“供应方（软件厂商）”，都一直存在的片面追求“简单易用”的（电算化）指导思想有关。是默认的“指导思想”禁锢了有关人员的思维与导向！
前两年国内有人提出所谓“2B应用的2C化”（越简单越好！），最近又看到有公司公开宣称要做一款“既适用于大型企业且无需学习培训就可以使用”的采购应用管理软件平台。问题是“大型企业的应用”要求一定是复杂的，而“无需学习培训就可以使用”的要求又一定是简单的！笔者非常怀疑这种“鱼与熊掌”兼得的想法是否真的能够实现！
过去一段时间以来，