军字一号要升级，有什么需求没有？

tanyiqiang

1.现在还是在模型设计阶段,作为长远打算是很好的,但是离最终产品全面投入使用估计还有比较长一段时间.看来上层专家还比较务实,不做那些虚的东西,很不错.
2.大规模部署和升级确实是一个问题,1000台工作站如果不是自动化的,那部署将是一个问题.
3.二层架构只能用ORACLE RAC这类的数据库群集技术,数据库服务器与存储的性能和可靠性将会是一个突出问题,三层架构的应用服务器集群是一个难点,自己开发难度很大,采用其它大公司的中间件将会带来安全和依赖的风险,三层架构如果技术不过关,性能\可靠性\稳定性是一个很大的问题.
4.版本管理将是一个大问题,以前医院都或多或少做了修改,如果版本管理不善,将来又会出现版本混乱不能统一升级的问题.
5.军民结合问题,地方病人到部队医院就医,病历健康档案的共享问题,战争时期军人到地方医院就医的病历健康档案共享问题.
6.对于实现的问题,原先用ORACLE,建议一条路走到底,不考虑数据库的通用性,通用必定影响性能,也加大实现的难度,开发周期也会延长.存储过程是效率最高的方式,由于不考虑通用性,该用就用,不滥用就行了.数据库提供的功能就尽量使用,比自己开发节省时间,运行效率也比自己开发要高.
7.窗口服务建议用C/S或C/S/S架构,其它尽量用B/S架构.

lfree

>2.大规模部署和升级确实是一个问题,1000台工作站如果不是自动化的,那部署将是一个问题.
确实是这样,我们现在升级一个应用,要下去N多人.
我知道天健的体检好象有这个功能,以前我们这里医保程序升级也是一样,要下去一台一台升级,经常漏,好在升级不是很频繁.
现在医保已经改进了,升级文件放在数据库里面,不用技术人员去升级.

>4.版本管理将是一个大问题,以前医院都或多或少做了修改,如果版本管理不善,将来又会出现版本混乱不能统一升级的问题.
版本管理,我不知道以前的PB如果做,版本管理是一个复杂的问题,至少我缺乏这方面的经验,许多开发公司都没有版本管理系统.

>6.对于实现的问题,原先用ORACLE,建议一条路走到底,不考虑数据库的通用性,通用必定影响性能,也加大实现的难度,开发周期也会延长.存储过程是效率最高的方式,由于不考虑通用性,该用就用,不滥用就行了.数据库提供的功能就尽量使用,比自己开发节省时间,运行效率也比自己开发要高.

我觉得数据库选择oracle是必然的,要考虑通用性,成本太高了.

>7.窗口服务建议用C/S或C/S/S架构,其它尽量用B/S架构.
这个我不熟悉.我仅仅直觉认为3层架构是大势所趋,如果还是2层,用户数一多服务器压力太大.

我的感觉这个事情至少是2-3年以后的事情,不会太快.
而且军惠的一些开发商都有旧的源代码,他们是否愿意跟进还是问题.

tanyiqiang

说实在的,如果不是采取连续升级的策略,任何一个版本都不可能满足医院的需求,想一劳永逸估计是不可行的,10年前总后想到有今天这种需求?军队系统是相对封闭的,和地方系统差别比较大,开发商总想通吃,根据以往的情况,这条路不好走,资源是有限的,以部队为主,地方医院的服务就不会做得好,为地方医院投入过大,又影响部队医院的发展,建议不要太贪心,要做部队医院就专心做部队医院,总后也不要走市场化的道路,软件不像硬件,售后服务会把开发商拖死的.
如果是全新开发,估计没三五年不会面世,这么多医院,众口难调啊.各家医院都已经修改过很多,个性化多了,如何集中到一个版本,我想这是一个不是问题的问题.

fals

原帖由 tanyiqiang 于 2010-2-6 22:43 发表
1.现在还是在模型设计阶段,作为长远打算是很好的,但是离最终产品全面投入使用估计还有比较长一段时间.看来上层专家还比较务实,不做那些虚的东西,很不错.
2.大规模部署和升级确实是一个问题,1000台工作站如果不是自动化的,那部署将是一个问题.
3.二层架构只能用ORACLE RAC这类的数据库群集技术,数据库服务器与存储的性能和可靠性将会是一个突出问题,三层架构的应用服务器集群是一个难点,自己开发难度很大,采用其它大公司的中间件将会带来安全和依赖的风险,三层架构如果技术不过关,性能\可靠性\稳定性是一个很大的问题.
4.版本管理将是一个大问题,以前医院都或多或少做了修改,如果版本管理不善,将来又会出现版本混乱不能统一升级的问题.
5.军民结合问题,地方病人到部队医院就医,病历健康档案的共享问题,战争时期军人到地方医院就医的病历健康档案共享问题.
6.对于实现的问题,原先用ORACLE,建议一条路走到底,不考虑数据库的通用性,通用必定影响性能,也加大实现的难度,开发周期也会延长.存储过程是效率最高的方式,由于不考虑通用性,该用就用,不滥用就行了.数据库提供的功能就尽量使用,比自己开发节省时间,运行效率也比自己开发要高.
7.窗口服务建议用C/S或C/S/S架构,其它尽量用B/S架构.

太有道理了，谢谢！

fals

数据库没听说要变，应该还是选Oracle吧，总后不会考虑数据库通用性之类的问题的，这类问题，我感觉好象商业意义更大一些，对于统一应用来讲，反而不是什么有利的因素吧？

版本管理确实是个大问题，听说这次大规模升级以后，先找几家医院试点新版本，都稳定下来之后，以后会维持一个较小规模的团队，也可能分散到全军几个大点的医院，做持续的版本升级，总后将进行统筹和大的技术架构管理。

另外，听他们的意思，估计2010年底要拿出来一个能够验证新的技术框架、功能模型、数据标准之类的可试用程序来，全面稳定新版本程序的话，我估计至少要到2011年的年中去了。

这次没听到他们说新程序军地通用的问题，估计他们组织开发也只管军队的需求，地方医院的需求可能还是会交给公司去做。

军人和地方人员的健康档案相互交互的问题，这次也提出来了，也会是重点考虑的内容。听专家讲的意见，电子病历是个框，什么医疗业务信息都要往里面装，通过标准接口，使用统一界面访问电子病历信息，实际上就是健康档案的内容了，只不过这次内容方面可能集中在医院的内部业务，还没考虑如何包含健康体检等信息吧，所以提法上没讲军人电子健康档案，还是讲电子病历。


B/S 还是C/S或C/S/S的问题，确实是个问题，总有利弊，估计还要讨论好几次才能最终定得下来。我倒是觉得，查询类的业务都可以做成B/S的，最终弄成个B/S和C/S混合架构倒是能比较好的满足医院的业务。


哦，对了，P盘取消之后，每次程序启动时从数据库取字典数据放到本地程序的内存里调用，从天健最近的几个版本来看，性能问题并不是很突出，应该是可行的。

ocp_oracle

不管如何更新换代，总后应该考虑目前的这些用户（部队医院）的历史数据和系统平稳过渡的问题吧！不可能完全脱离原有系统而另起炉灶，应该在原有系统的基础上来优化系统。重新打造全新系统的可能性不太大吧！

dzwtdyy

1、三层架构是以后发展的趋势，这次升级最好也有这一方面的考虑
2、P盘最好不用
3、现用系统的变量绑定是一个问题，需要解决
4、数据库应该还是Oracle，变数据库的成本太大
5、程序自动升级的功能应该有

lfree

原帖由 dzwtdyy 于 2010-2-24 09:50 发表
5、程序自动升级的功能应该有

确实应该，程序自动升级应该支持。

ocp_oracle

原帖由 lfree 于 2010-2-25 08:51 发表


确实应该，程序自动升级应该支持。

这些功能已经早就解决了！

fals

好长一段时间没有上来，先多谢各位积极讨论啦。

就目前存在的各种问题，这次升级要下大力气来解决，我倒是感觉相对好办一些，毕竟积累了这么多年的使用经验了。

但还需要扩展的大块内容，比如急诊管理和院前急救管理的问题，门诊持续治疗业务的处理，临床路径等专家系统接入军字一号系统的问题，预约管理等，也应该有很大的需求吧？

前面多次讨论到的军队和地方病人信息交互的问题，特别是健康档案，这一块也应该有所考虑，这次的升级论证会，徐勇勇教授也参加了，所以估计数据标准化问题，军人和地方医院健康档案信息交接等问题也会一并提出来研究。

春节过了之后，估计还会有后续的动作。