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

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

袁永福 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之类的条条框框。怎么适合需求就怎么作，灵活变幻开发策略，以最优的路径作出符合客户需求的软件。