关于医院的收费系统报价？

老包

最初由 tyq 发表
[B]有很多人开始都是这么想的，但做下去的时候，发现并不像当初想像的那样简单。医院的需求是一步一步提出来的，等你做好了这一步，下一个需求又提出来了，你会发现医院的系统原来是那么复杂。很多公司都是交过这样的学... [/B]

[B]认识到这一点确实很不错。[/B]医院复杂性取决于医学的复杂性，医学的复杂性取决于人体的复杂性。在某种程度上可以说医学是“个性的天下”。你只要看世上有没有“江湖物理学家”，但世上有多少“江湖郎中”？很多人比我们活得潇洒！大医院、大医生对他们也只能干瞪眼。(“江湖郎中”大概很清楚医学的复杂性，浑水摸鱼起来游刃有余)公司、院长、医生、护士下意识也许对复杂性知道一些，但到决策时往往又认识不清。有一个院长在一次医学信息学大会上大声责问道“HIS为什么不能像彩电一样拿来就用？！”你想这先生脑子浆糊到什么程度！特别是在一个不崇尚规范的文化和社会环境中搞信息化。

对医院复杂性估计不足，对公司来说就生死攸关，因此必须在对医院业务复杂性充分估计的基础做出方案。

水晶苍蝇拍

从目前楼主反映出的情况来看，我个人到是建议楼主坚持比较低起点的开始建设，而非高投入、大规模的搞。

个人认为楼主医院的具体情况确实还达不到高水平信息化建设的要求，这在国内也很普遍，是一种客观存在。

首先目前经济条件不充分是客观事实，再加上以前信息化没有积累，无论是领导还是科室员工的思维改变也绝非一朝一夕；此外，医院目前也缺乏迫切实施高层次信息系统的内外部驱动因素；再次，依目前楼主医院再信息化水平方面的经验积累和专业能力，即使钱到位了，领导头脑发热同意了，我个人评估此项目建设的风险依然偏大，信息科本身的风险也会非常大，这点无庸讳言。

因此，以较低的代价（资金成本，时间成本，使用成本，机会成本）和较清晰有限的目标（一日清单，初步的财务报表、基本的药品库存管理等）为定位，先立足用起来，并在使用中逐渐体现信息系统的重要性（一旦用起来，你必定会有很多机会向领导作这类报告的，呵呵），为今后的更高层次的应用奠定专业能力、应用习惯和建设经验上的积累，不失是一个可行的方法。

比较需要注意的是，这种基础建设一定要将目标的有限性突出出来，避免“花小钱办大事”的不正确思维。

同时我个人认为，其实作信息化建设咨询和医生看病有一个地方很像，就是要注意个体差异，要根据具体情况开不同的处方，而非简单的对谁都是一个十全大补（当然咨询与看病有本质的不同）。引导客户注重长远发展是必要的，但也不能不顾对方的具体情况而盲目拉高其需求。

tyq

比如药品库存管理，很多人认为和工厂的仓库管理差不多，确实药库和仓库管理是差不多，但按仓库管理做好了，医院提出了一个调价的需求，做好了，医院又提出了货到发票没到如何入库的需求，一般按上一批的价格入库，入库了，票到一看，价格和上一批不一样，如何处理？1.全部退货，重新入库，药品已经售出，何来退货？如果允许退货说明管理不严谨。2.修改入库单，违反财务制度，并且重打报表数据会不一致；3.修改差价，医院核算的实质是想核算药品的进出差价（利润），通过修改差价就可以了，但数据库中又必须保存差价这个数据。做好了，医院又提出来药品是有效期的，过期不能用，差不多到期要提醒。做好了，药房提出库存管理有问题，如药房库存10支，第一个病人交钱，如果减库存，但病人不拿药，第二天才拿，每天的发药与收费就不一致，需要对帐，麻烦，不减库存，第二个病人收费后就没有药了，要退费，又是麻烦，于是引入双库存，即可用库存与实际库存。做好了，医院又提出数量准了，金额不准，为什么？昨天卖出的药品是2元，后来调价了，调为2.5元，今天病人来退药，按2元退了，入库金额也是2元，所以金额不对，原来退药还要考虑调价。做好了，医院提出医嘱发药有问题，药品包装是100ml，医嘱是30ml，tid，由于不能拆开发药，结果发了3瓶，本来1瓶就可以的了，于是做一个合并发药的功能。做好了，医院提出药品移库的功能，门诊药房按盒发，住院药房按粒发，一盒有12粒，一移库数量就不准，于是在库存量加减时，要先做换算。做好了，医院说周末住院药房不上班，星期五科室要把星期六、日的药领回去，领回去后，病人星期六要出院了，退药又怎么办？继续做下去吧！工作是做不完的。

tyq

商品化软件的思想就是把客户的需求收集后，经过归纳、抽象为处理逻辑，再去实现，在实现时综合考虑，并进行优化，推出新的版本。在初期，客户会反馈大量的问题，以来问题会越来越少，最后稳定在一定水平，商品化软件经过不断的升级，把个别客户的管理方法带给所有客户，实现资源共享，并且经过严格的测试，软件运行比较稳定。如果做不到知识积累，就要做大量的重复劳动，成本相对较高，质量也难以保证。软件开发如果不能待续升级，就会落后，就不能满足客户的需求。所以医院买软件，更是买服务。就像上面的例子那样，医院的需求是不断提出来的，如果不能待续升级实现，医院就会不满意，后果应该能想像得到。

Bland

按水晶苍蝇拍说的做吧，想不到还有医院什么都没有做，差异真大。看样子医院的规模也不小啊

dongxi

真精彩

Bland

“HIS为什么不能像彩电一样拿来就用？！”作为现今的院长，基本上是从业务层走上来的，他们最关心的是医院的主业，现在后勤也逐步社会化了，想当然，HIS为什么不可以？其实HIS不但与管理密切相关，今后将与医疗业务也密切相关。从这一个角度看，这位院长的知识结构老化了。

lyq81404

最初由 水晶苍蝇拍 发表
[B]从目前楼主反映出的情况来看，我个人到是建议楼主坚持比较低起点的开始建设，而非高投入、大规模的搞。

个人认为楼主医院的具体情况确实还达不到高水平信息化建设的要求，这在国内也很普遍，是一种客观存在。

... [/B]

感谢水晶苍蝇拍！你说的问题很中肯！我们医院只是一个县级人民医院，也确实存在如你所诉的问题，医院现在也还未设置信息科！就我个人而言目前也还在临床科室轮科（我的专业是医学），并没有信息化水平方面的经验积累！医院也还有两个也是当计算机方面的人才招进来的，不过知识能力方面可能还存在一些问题，包括我自己在内，院领导现在打算让我们几个自己写个系统出来！他们的要求很简单，只要能打出一日清单，财务帐目等没有要求，估计还是手工方式操作。就目前这种情况如果自行编写可能出现哪些问题呢？

lyq81404

多谢水晶苍蝇拍！

lyq81404

最初由 tyq 发表
[B]比如药品库存管理，很多人认为和工厂的仓库管理差不多，确实药库和仓库管理是差不多，但按仓库管理做好了，医院提出了一个调价的需求，做好了，医院又提出了货到发票没到如何入库的需求，一般按上一批的价格入库，入... [/B]

感谢tyq摆出这些问题！由于院领导有意让我们自己编写这套一日清单的系统，我这段时间也在进行一些筹备工作，数据库参考了前段时间论坛上的网友提供的军惠系统数据库，因为暂时还不准备做中心药库的管理，只打算做住院部药房的管理，所以应该不会出现货到发票没到的情况；有效期，这是做药品管理必做的，已有所考虑；你所诉的发药与收费不一致的问题需要实际与药房联系看是否也存在这个问题；退药时价格为调价前价格的问题，我原来的打算是使用负数冲帐，然后将药品入库，不知道行不行得通；因为不涉及医嘱处理，拆药的问题不存在；因为我们医院六、日照常上班，这个问题也不存在，感谢你提出这些问题

水晶苍蝇拍

最初由 lyq81404 发表
[B][QUOTE]最初由 水晶苍蝇拍 发表
[B]院领导对这方面的认识也很粗浅，现在打算让我们几个自己写个系统出来！他们的要求很简单，只要能打出一日清单，财务帐目等没有要求，估计还是手工方式操作。就目前这种情况如果自行编写可能出现哪些问题呢？[/B]

我个人建议，千万不要自己写！后面的麻烦事情远远超出你的想象，找一切可能的理由建议医院找公司作，否则你别看现在领导的要求简单，过一阵子可就慢慢变的不简单了，那时候你可就算是陷入漩涡了，呵呵。而且这样一来你们医院各科室的心态也会发生变化，变得整个过程反而不利于信息化经验的积累。。。

你们配合公司作一些工作是可以的（而且是必须的，小公司的经营风险比较大，为防万一你们要事先掌握维护能力），但就是不要定位于自己作！不是说自己作就不好，坦率讲，国内最成功和最失败的案例都是自己作出来得，但最成功的案例的背后是比找公司作更多的资金和人才保障，失败的案例背后则都是像目前你们医院领导一样的把其想的太简单。。。

因此直说吧，我的建议：
第一，立即建议成立专门信息中心，否则职责不清，名不正言不顺，没法搞
第二，找公司合作，信息中心定位于协调项目进展和配合研发
第三，整个实施不能完全放由公司作，一定要盯紧，特别注意对原代码和相关技术文档的备份学习，做好有朝一日自己承担全部维护的准备

lyq81404

我有这样的想法是因为现在的要求只是要打出一日清单，财务方面还是准备手工进行！医院一直都有建信息系统的计划，但就近几个医院的系统建立起来后，反应并不太好！院领导又希望能有统一的标准，还下不了决心！

Bland

对水晶苍蝇拍的说法非常赞同。就以下几点谈谈个人的看法：
1.我个人建议，千万不要自己写！
原则上应该这么做，如果医院的应用没有什么特别需求，找个公司合作是非常理想的方案。既不用花很长时间的准备，又不用承担太大的责任。如果你认为自己有能力实现，并能够死心塌地为医院服务，争得医院同意后，可以尝试一下。不用理会他人说“低水平重复”等等套话，路是一步一步走出来的。但是要注意规范和各方面的标准，尽可能地做好自己能够做的事情。尤其是文档的建立。还有一点需要提醒，你的责任非常大，上马之后来不得半点后悔撤退，不然医院的麻烦可就大了。

2.坦率讲，国内最成功和最失败的案例都是自己作出来得，但最成功的案例的背后是比找公司作更多的资金和人才保障，失败的案例背后则都是像目前你们医院领导一样的把其想的太简单。。。
对于这一点，我们要分开看。小医院不尽然，有二、三位软件开发人员就可以支撑常用软件系统的开发和维护。不必面面俱到，部分系统可以集成其他公司的，譬如LIS等。大医院就不行了，成本必然比应用公司的软件大，而且不是一点点。但是现在有这样的趋势，很多大医院不得不走到自行开发和维护的这条路上去。大医院有大医院的特点和需求，一般的软件公司难以满足，如果软件公司真的满足了各家大医院的方方面面，他的版本就难以控制了，同理他也维持不下去。

第三，整个实施不能完全放由公司作，一定要盯紧，特别注意对原代码和相关技术文档的备份学习，做好有朝一日自己承担全部维护的准备
哈哈就这一点说，不是与第一点互相矛盾吗？医院非常难，即想少花钱多办事，又担心万一公司有了点问题怎么办？如果要自己承担全部维护，为什么不从头就开始呢？

tyq

先做吧!做到做不下出的时候就买公司的商品化软件。

水晶苍蝇拍

[哈哈就这一点说，不是与第一点互相矛盾吗？医院非常难，即想少花钱多办事，又担心万一公司有了点问题怎么办？如果要自己承担全部维护，为什么不从头就开始呢？]

呵呵,我个人的实际体会是,自己负责开发与全面维护是截然不同的两个概念,没觉得存在什么矛盾啊

[但是现在有这样的趋势，很多大医院不得不走到自行开发和维护的这条路上去。大医院有大医院的特点和需求，一般的软件公司难以满足，如果软件公司真的满足了各家大医院的方方面面，他的版本就难以控制了，同理他也维持不下去。]

其实有条件完全自己开发的医院很少,而且拘我所知,以前自己开发的医院目前的趋势是找公司合作,包括曾经以自主开发闻名全国的几个大医院.至于公司而言,考虑的会更复杂,也不可能满足医院的方方面面----不是不能,而是医院付不起这个代价,其实也没必要.