背景

医院信息系统不是一个独立运行的系统，而是由很多子系统(归属不同开发商)集成协同工作的大系统。子系统之间的数据交互，不管是通过集成平台总线还是点对点对接，都存在大量接口集成开发工作量，甚至有的子系统全部的字典接口与业务接口的总数量超过100个。由于各子系统开发商的技术水平不平衡，有的子系统开发商经验不足、项目交付进度紧迫、对业务流程的理解不够深入、开发技术路线不能适应项目建设等原因，造成接口开发周期长、文档不完整、运行稳定性欠缺、故障排查时间长，是影响医院信息子系统交付与运维的重要原因之一，笔者经历过多家开发商的多个子系统及集成平台交付的实践，在接口开发过程管理方面积累了一定的经验，现总结分享如下。

接口开发过程管理

（一）业务流程梳理

首先要根据合同的内容，确定项目交付的范围，根据项目范围确定项目需要上线哪些业务模块，与客户沟通这些业务模块的业务流程、规则，整理成需求调研文档，然后针对客户的需求，给出相应的解决方案，与客户沟通确认，形成最终的项目需求文档。在这个环节，最重要的是要给出解决方案并由客户确认，让各方对需求实现的方式达成一致意见。少了这部分的内容，项目很难落地交付。

（二）接口交互时序图编写

1.概要时序图

概要时序图是定义接口调用触发的时机(如建档时、修改档案时、分诊时、接诊时、定时调用等)及调用的接口名称和返回的结果，概要时序图是项目接口全集的总览，一看就明白项目有哪些接口及各个接口的作用，概要时序图是接口清单内容的组成部分，编写完成后，插入到接口清单文档。

2.详细时序图

详细时序图是每个接口调用的详细交互过程，比如：某子系统产品埋点->中间工程接口->院方接口->医保接口-->院方接口-->中间工程接口-->某子系统产品埋点(->是调用，-->是返回结果)，详细时序图是接口明细内容的组成部分，编写完成后，插入到接口明细文档。

（三）接口清单与接口明细编写

1.接口清单

接口清单是以表格的形式提供，内容包括接口编号、接口英文名称、接口中文名称、接口简要内容描述、埋点名称、调用时机、院方接口英文名称、院方接口中文名称、接口的提供方和调用方等，是概要交互时序图的补充说明。

2.接口明细

接口明细定义了接口调用的协议、URL、入参和返参的数据结构，入参和返参通常是XML或JSON格式，是树型结构，有些结点会有多个，可用子结点列表来定义，接口明细是详细时序图的补充说明，两者相互相承。接口明细的字段定义包括了英文名称、中文名称、内容描述、字段对照、转换规则等内容，在很多项目中，字段对照和转换规则是不太重视编写的，这部分内容的缺失，对后续接口开发与维护、故障排查带来困难。

（四）接口代码开发

1.理解业务流程与数据转换规则

接口开发工程师必须理解业务流程与数据转换规则才能编写出符合业务的接口，比如：处方分方，某子系统是按住院医嘱的方式下达的，没有门诊处方的概念，不需要考虑处方的分方规则，分方是由中间工程(接口)根据HIS的分方规则自动做分方处理的；另一种情况是字典双向影射，比如：医嘱频率字典，有专业子系统的频率字典和HIS的频率字典，专业子系统频率字典是稳定的，HIS频率字典是跟项目走的，拉取药品字典时，频率的默认值要转换成专业子系统的频率，医嘱提交时，要将频率转换成HIS的频率。

2.日志记录

每一次接口调用，都必须记录4个日志：

1）产品埋点调用中间工程入参

2）中间工程调用院方接口入参

3）院方接口给中间工程返参

4）中间工程给产品埋点返参

日志的结构要格式化、标准化，内容包括日志时间、日志级别、记录时机、日志详细内容，日志详细内容可用XML或JSON，格式化与标准化方便日志的查找，加快故障的排查。

日志也是出现故障时，界定责任的重要依据，由于接口是双方或多方交互调用，很多情况下，各方的日志记录有的完整有的不完整，由于日志记录的不完整，造成两个或多个子系统交付实施人员之间相互推诿扯皮、故障排查时间长，甚至造成系统带病运行，长期运行不稳定，最终影响项目交付与运维，给系统建设方(医院)带来损失，开发商的声誉也受到影响。

由于日志内容比较庞大，一般分为四个级别：调试、信息、警告、错误，根据系统配置参数，控制每个接口的日志输出级别，以免输出的日志信息过多或过少，影响问题的排查。对于日志保留的时间，应根据日志的输出量、存储空间大小、日志的重要程度等方面的要求，综合考虑日志的保留时间。过期的日志要自动清除，以免日志信息占用空间过大，造成系统崩溃或影响系统的性能。

（五）接口测试

接口测试，最重要的是测试环境的建立及测试用例的编写，有的开发商内部缺乏测试环境，接口难以测试，而以现场测试为主，造成测试效率不高、开发周期长、运行不稳定等问题。通过在开发商内部建立院方接口仿真环境，在开发商内部即可进行接口的正常流程测试和模拟故障的测试，接口开发效率、交付质量也大大提升。测试用例编写与接口开发同样需要理解业务流程和数据转换规则，才能编写出高质量的测试用例。笔者在这方面的经验，是由需求调研人员、接口开发人员、测试人员组成接口开发小组，充分分析讨论业务流程、业务规则及解决方案。

（六）接口故障监控与排查

接口涉及承建方(开发商)和建设方(院方)，完整的日志记录是故障监控与排查关键，日志记录不完整、格式不标准，将无法做到接口自动监控和快速故障排查，有的子系统日志记录是文件方式，不方便自动化监控与查找定位，迁移到数据库，可以利用数据库强大的查找和统计功能，做到自动化监控、预警、统计分析等。

（七）接口运维闭环管理

在产品的生命周期内，接口会有需求调整、BUG修复等，需要有一套完整的管理工具来管理。以往交付人员直接与接口开发人员沟通，文档及过程记录不完整，造成接口开发质量不保证、交付时间不保证等问题，通过建立完善过程管理制度，交付人员提交完整的需求文档或bug登记文档到需求管理系统，需求管理系统指派给相应的开发人员及测试人员，每个环节均有相应的文档及时间记录，这样形成了接口开发维护过程的闭环管理，提高了接口开发的效率和交付的质量，也为开发商积累接口开发的经验。

总结

综上所述，通过上述各个方面的过程管理，规范接口开发过程，健全接口开发文档，能够极大的减少接口开发过程的返工，真正缩短开发周期，对开发人员的技术水平要求也有所降低，综合开发成本也节省了不少，医院信息系统交互的整体效果得到保证，并且也符合CMMI认证的宗旨。