一种电子病历系统软件框架思想

一种电子病历系统软件框架思想

袁永福 2016-5-9

 

电子病历系统到底采用B/S还是C/S架构是一个长期争论的话题。而在业界两种架构的应用范围谁也不占有显著优势。

在此笔者提出一种BS和CS混合的架构，以下是其原理图：

 

在该结构中主要部分有

WEB服务器

这是系统的核心。大多数的业务流程运行在WEB服务器中。采用ASP.NET开发，直连数据库。

 

WEB服务器包含系统功能 API集合，以远程调用的方式向PC客户端软件提供功能支持。

还包含ASPX页面，向移动设备提供功能支持。

 

PC机客户端

PC机客户端为一个轻量级的客户端软件，为一个.NET开发的WinForm软件。该软件提供良好的互换性操作体验，提供各种病历数据的查看、录入和打印功能。大多数情况下本软件只进行简单的数据转发功能，基本上不执行具体的业务流程操作。

 

移动设备

移动设备采用浏览器形式访问WEB服务器。

 

数据库服务器

为一个专门的数据库服务器，只向WEB服务器开放连接。

 

 

以下是B/S,C/S以及这种混合模式的对比评分表：

 

 

编号	对比项目	满分	BS	BS 得分	CS	CS 得分	BS和CS混合模式	混合模式 得分	说明
1	离线运行能力	3	无，若系统突然断网、服务器崩溃，数据全部丢失。	0	有，若系统突然断网，数据可以缓存到本地，联网后再保存。	3	有	2	用户辛苦敲入大段文本，突然断网了，心情不会好的。
2	页面状态数据	1	全靠ASP.NET SESSION，编程比较复杂。	0.5	控制简单，几个全局变量即可完成。	1	控制简单	1
3	页面间数据传输	1	全靠ASP.NET SESSION，编程复杂而且效率低。	0.5	简单，全局变量，公开的属性或字段就能实现该功能。	1	简单	1
4	浏览器兼容性问题	3	有，增加开发和维护难度和工作量。	0	无	3	无	3	严格限制客户端浏览器版本是一种不友好的行为，有时候会和其他软件发生冲突。应当尽量避免。
5	本地数据缓存	1.5	无，如果系统配置了知识库列表，药品信息列表，ICD数据列表，则需要频繁的重复下载。	0	有。无需频繁的重复下载。减少网络IO负荷和对服务器的依赖。	1.5	有	1.5
6	软件升级	5	简单，只要更新服务器软件即可。	5	必须要更新客户端软件，次数多，成本高，影响系统运行。	2	大部分情况下更新服务器即可。少数情况下才需要更新客户端软件。	3	目前的各种自动更新技术应该是够用的，而且电子病历是院内系统，有一定的控制力度。另外应该是以用户使用方便为第一，开发和维护人员自己方便为第二。
7	系统配置更改	2	简单	2	复杂	0	简单	1.5	比如数据库服务器换IP了。防火墙修改了。
8	运行速度	4	慢。网络传输速度和客户端浏览器呈现速度比较慢，一般操作都需要几秒钟的时间。	2	快，主要受限于网络传输速度。	4	快，主要受限于网络传输速度。	4	对于BS软件，可能服务器端运行耗时只有几百毫秒，但在网络传输和浏览器展现页面需要耗掉几千毫秒。
9	网络带宽利用效率	1	低，一般为明文原始格式传输	0	高，可以加密压缩传输。	1	高。	1
10	用户互操作体验	6	一般。	2	良好	6	良好	6	用户年复一年的操作这些界面，稍微减少些鼠标键盘操作就能产生显著的效益。另外一些病历模板工具等软件模块基本上只能用CS模式。
11	安全性	1	高。服务器软件控制好就行了。	1	低。	0.5	高。基本上等于服务器的安全性。	0.5	由于是院内系统，行政管理能帮助进行安全管理。
12	部署	5	简单。但是如果不得不出现IE嵌控件的形式，则很复杂。	4	复杂，需要配置客户端运行环境，配置数据库连接信息。	0	比较复杂。但无需配置数据库连接信息。	3	可能要用上医保接口，容易出现IE嵌控件的情况。
13	U盘,K宝等外接设备	2	复杂，需要仔细配置客户端运行环境，容易出错。	0	简单	2	简单	2	比如用上电子签章功能，医生人手一个K宝。
14	打印	2	难于做到精细打印。比如不弹出对话框的打印，指定打印机、纸盒，续打，双面打印等。	0.5	简单强大	2	简单强大	2
15	开发技术	4	复杂。需要C#/HTML/JS的混合编程。对开发人员要求高。调试操作复杂。	1	简单，统一的WinForm编程模式。	4	较为简单，ASP.NET和WinForm编程，编程语言统一。	2	开发人才难找，需要降低对开发人员的要求。
16	产品化	1	复杂。	0.5	简单，可以方便的制作安装文件和各种配置工具。	1	比较复杂。	0.5	既然以后要向其他医院推广，需要考虑到软件的产品化。
17	数据库负载	4	良好	4	差，需要创建大量数据库连接。	0	良好，不直连数据库。	4
18	灾难恢复	5	差，服务器宕机，所有客户端都不能用。	0	有一定的应付能力。	3	有比较弱的应付能力。	1	电子病历应该是7X24小时运行的系统。
19	对移动设备的支持	4	良好	4	无	0	良好，仍然提供WEB页面功能。	3
20	并发控制	1	好	1	一般	0.5	好	1
21	系统伸缩性	1	好	1	差	0	好	1	医院职工数比较稳定。
22	系统可扩展性	5	好	5	差	1	较好	3.5	医疗需求变更比较大，会比较频繁的调整的系统功能，对系统可扩展性要求比较高。
23	客户端硬件要求	4	要求低	4	有一定的要求	1	要求比较低	2
24	服务器端硬件要求	1	要求高	0	要求低	1	要求比较高	0.5
25	操作系统底层功能调用	2	无，HTML/JS权限很低。	0	有	2	有	2	某些情况下需要调用操作系统底层功能。比如不同病人的病历文本不能相互复制就需要直接访问系统剪切板。
26	国际化（多语言版本）	0.5	复杂	0	简单	0.5	简单	0.5	比如开发繁体中文版，英文版等等。
	满分	70	BS得分	38	CS得分	41	混合模式得分	52.5

 

 

 

关于这种架构思想的来源，笔者长期做UI层开发，那么就从UI层开始说起。

现在所有的医疗软件都是图形化用户界面，对于C/S程序，写C#代码调用DrawString(),DrawLine(),DrawImage()之类的GUI API来绘制用户界面；而对于B/S程序是服务器端写代码输出HTML代码，然后发给浏览器让其解释这个HTML代码来“绘制”用户界面。

因此可以抽象出来看，程序猿都是花大量的代码来绘制图形化用户界面，只不过一部分代码输出图形绘制指令，一部分代码输出HTML代码。但最终目的都是一样的。

另外程序猿还需要写大量的代码来让图形化用户界面和用户互动，都需要响应KeyDown/MouseClick等事件，这点大家的写的代码都很类似。最终目标也一样。

按照这种思想，B/S和C/S的理解可以如下：

C/S程序	数据库服务器→应用软件→界面呈现信息（DrawString等指令）→GUI For Windows
B/S程序	数据库服务器→应用软件→界面呈现信息（HTML代码）→GUI For Browser

两者逻辑上的高度相似性可以很容易联想到物理学中引力和电磁力逻辑上的高度相似性。物理学中正在谋求统一场理论，那么我们也可以谋求B/S和C/S的统一。

虽然B/S和C/S呈现用户界面的代码虽然语言不同、代码执行的地方不同，但逻辑是相同的，因此逻辑上完全可以统一起来。以此类推，对于业务逻辑执行也是这样的，这就是B/S和C/S统一的理论基础，具体表现形式可以是OOP、AOP之类的。

按照B/S,C/S的统一设想，电子病历系统软件可以划分为以下几个部分：

1. 数据库服务器。SQL SERVER/ORACLE/NOSQL之类的。
2. 业务逻辑执行层。执行医疗业务逻辑的代码，这个层面纯粹执行业务功能，没有用户界面。而且考虑到B/S应用应该是多线程安全的。
3. B/S服务器应用层。运行在WEB服务器上的，直接调用业务逻辑执行层来实现业务功能。
4. 远程调用包装层。对业务逻辑层执行层的功能进行包装，能方便的进行远程调用，这个远程调用就是基于XML的WebService或者基于二进制的JAVA/.NET Remoting。
5. C/S客户端软件。客户端软件通过网络调用远程调用包装层来执行业务逻辑。

对于这种架构模型，如果业务逻辑执行层和B/S服务器应用层编译在一起就是传统的B/S系统；业务逻辑执行层和C/S客户端软件编译在一起就是传统的C/S系统。如果5个部分都分开，那么就是同时支持B/S和C/S的，这样软件具有强大的扩展性和生命力。

回归到笔者的老本行，电子病历编辑器。编辑器控件提供WinForm版本和ASP.NET版本的。WinForm版本支持所有的功能；不过受限于当前技术水平，ASP.NET版本只能只读的阅读病历文档内容，而无法编辑修改。因此建议在开发常规电子病历系统时采用C/S模式，对于互联网应用，比如公卫平台之类的，也是建议新的B/S和C/S统一模式。对于移动应用可以采用传统B/S模式。

最后想总结一下，孙子兵法又说了：兵势如水。小平同志的白猫黑猫也是这个理。笔者觉得开发软件也应该“兵势如水”，不必拘泥于B/S,C/S之类的条条框框。怎么适合需求就怎么做，灵活变幻开发策略，以最优的路径做出符合客户需求的软件。