再胡言乱语几句

ermulong · 发表于 2006-6-26 10:12:01

我很理解楼主的想法。我也认为目前的HIS系统不够细致，还有很多问题需要去讨论去解决，信息科科长每天都要去面对这些问题。而且有些看起来小的问题，却会影响某个子系统、某个系统，以至于整个HIS的实施效果。系统不够细致，归根结底还是公司对需求分析得不够细致，没有正确地反映某个事物、某个过程、某个流程的真实情况，或者说根本就没有去理会应该如何去将流程体现出来。系统的不够细致，同样地体现在数据结构对信息表示的不充足。其实楼主提到的几个问题都不错，楼上的一些贴子也提供的一些解决方法，有时我们提供一些配置给医院或科室，由科室去选择方案，但是不是真正解决了问题呢，我看不见得，有时只是将皮球又踢给了医院或科室而已。有人会说，这是管理的问题，不关技术或公司的事。如果真是这样，这也就是HIS不成功的原因了，因为我们提供了一个产品给医院，同时也提供了很多难题给医院，我们并没有给医院一个解决难题的方法。现在的状况，即没有好的产品，也没有好的服务，更没有好的咨询。至于标准，我只是总有些说不清楚，专家们在谈，厂商也在谈，却总是见不到效果。有两点疑问：1、不知道ERP的标准有没有，各大厂商有没有按标准在办事2、银业系统有没有标准，银联做的挺好的，是不是在按什么标准做的。如果，假设，有可能，现在国内的情况是三四家公司占着国内大部分市场，是不是可以理解他们的产品就是标准呢

老贼 · 发表于 2006-6-26 10:25:10

我也胡说几句。<div class='quotetop'>引用:</div><div class='quotemain'>挂号时分诊好，还是挂完号，再分诊？是医生端收费好，还是收费员收费好？医生端是即时刷新的病人列表好，还是刷卡出病人好？分诊是根据挂号顺序，还是根据到分诊台的顺序？如何实现分诊时能“方便熟人”，又能不让病人发火？发生会诊的时候，涉及多个医生，如何计算医生的工作量？转诊呢？病房护士医嘱确认应该定期，还是即时进行？如果即时，药房发药如何跟上？出院时，病人如果欠费，应该堵在病房，还是堵在住院收费处？</div>楼主提出的上述几个问题，我认为这属于医院管理问题，应该由医院的相关部门决定如何处理，然后由HIS实现。

ironstone · 发表于 2006-6-26 14:23:40

<div class='quotetop'>引用

老贼 @ 2006-06-26 10:25)</div><div class='quotemain'>楼主提出的上述几个问题，我认为这属于医院管理问题，应该由医院的相关部门决定如何处理，然后由HIS实现。</div> 从医院的角度我是反对这种观点的哦。对于公司来说理是不错，这些问题也的确是管理问题？关键在于，医院请一个供应商仅仅是请一堆来进行编码实现的人，还是一个具有实践经验和丰富行业经验的专业供应商？如果是前者，那么任何公司在医院面前的选择都是一样的，选择也简单，只选择价钱最便宜的，因为需求我自己都搞定了，只是要你去实现而已啊。问题恰恰不是这么简单。很多问题医院的相关部门也是一头雾水，即便是简单的手工过程电子化也涉及很多具体问题是医院难以考虑到的，毕竟做任何事情都有其前提条件和相关影响，作为一个合格的供应商就应当在这个时候提供参考意见。此外对于论坛来说，也应该鼓励这种讨论，论坛不是只是面对公司的论坛，也还有很多医院的人员存在，如果简单说一句医院去决定就好了，那么医院如何去决定，每种方式的前提是什么，困难是什么，可能出问题的地方在哪里？会有什么直接影响，会有什么间接影响，是否会对未来的系统构建和医院管理有重大影响？我想这些都是可以讨论的。

老贼 · 发表于 2006-6-26 14:41:44

继续胡说<div class='quotetop'>引用:</div><div class='quotemain'>HL7真的没用上。我们医院也连接银行（刷卡消费）和社会保险局，可人家不用那个。也没有区域会诊中心或者检查中心要和我连，那是国外的模式，</div>HL7这个标准似乎有些水土不服.

老贼 · 发表于 2006-6-26 15:06:04

与18楼商榷，大家讨论。我认为是医院管理问题的理由：上HIS的过程同时是医院优化管理的过程，在很多医院上HIS都遇到这些问题。在上HIS的同时要把这些问题解决，否则HIS很难用好，我估计这也是楼主提出这些问题的原因，他希望了解其他医院对这些问题是如何处理的。另外，一个公司的产品要在多家医院使用，而各医院的管理又不大一样，公司不可能提出一个令大医院满意的产品。一般对于大医院，搂主体出的问题是需要由医院提出规则，经过与公司的协商（公司要有这方面的经验），最后由医院拍板确定，由公司实施。

老贼 · 发表于 2006-6-26 15:22:04

继续胡说2：<div class='quotetop'>引用:</div><div class='quotemain'>不支持DIcom的设备</div>设备都是旧的？新设备应该符合DICOM标准。另外，多说一句，符合DICOM标准的设备未必能够实现互联。因为<span style="FONT-SIZE: 9pt; FONT-FAMILY: 宋体; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; mso-bidi-font-size: 18.0pt; mso-bidi-font-family: "Times New Roman"; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">该标准促进了影像设备制造商环境中系统的互操作性，但它本身并不能保证互操作性。 <div class="O" style="mso-margin-left-alt: 216" v:shape="_x0000_s3074"></div>。

Bland · 发表于 2006-6-26 15:22:52

细节决定成败，想必大家都知道。有些公司就是在细节上不注意，造成用户怨声载道。作为软件公司，尤其是专业再做医疗行业的，以上的问题应该都考虑过，应该有应对的办法。作为细节问题，无论公司也好，医院也好可以各抒己见，一起讨论怎样处理比较好，能够满足不同医院的需求。具体实现不仅仅是公司的问题，医院一定要有一个说法，不然公司无法做。挂号时分诊好，还是挂完号，再分诊？我就无法了解这个问题。我们医院挂号人员并不决定病人应该看哪个科室，那是预检人员的工作。挂号人员也不分诊，只是软件系统按照挂号的先后产生一个序号，表明病人所挂的号是某个科室的第几位。病人到诊室的候诊处才由分诊护士排队分诊。如果挂号病人比较多，排长队，那么收费人员也可以挂号，或者把挂号人群分散到各个楼层。我们曾经做过一个不用人工干预的分诊系统，自以为流程不错，在实际应用中根本无法运行。或许还会有人想做一个全自动的分诊系统，我们就可以交流流程的细节问题，避免我们所走的弯路，对大家都有好处。就像IHE一样定义各个软件系统的流程？包括每一个细节？

eyedoctor · 发表于 2006-6-26 15:29:12

<div class='quotetop'>引用

ironstone @ 2006-06-26 14:23)</div><div class='quotemain'>\从医院的角度我是反对这种观点的哦。对于公司来说理是不错，这些问题也的确是管理问题？关键在于，医院请一个供应商仅仅是请一堆来进行编码实现的人，还是一个具有实践经验和丰富行业经验的专业供应商？如果是前者，那么任何公司在医院面前的选择都是一样的，选择也简单，只选择价钱最便宜的，因为需求我自己都搞定了，只是要你去实现而已啊。问题恰恰不是这么简单。</div>楼上说的很正确，信息化和电子病历里面确实管理因素占了很大成分。许多时候，“需求为王” --------- 也就是说，把需求分析得明确、固定的情况下，同时许多技术都可以实现，“买”也很容易。现实情况恰恰是需求不容易把握。医院许多情况吃的最多的亏，也就是需求不清楚，结果没话说。医学信息学原理所说的意思，当计算机/网络被用于医学领域的时候，情况发生了深刻的改变，这种改变和其它领域的应用不一样（所以才有医学信息学，而不是仅仅是计算机在医学领域的应用）。我们需认识到计算机被用来处理生命相关问题时的优势和局限性，这就是分析需求时的法则，其实也就是所谓的“管理问题” --------- 确定哪些可行、哪些不行、确定在流程的什么环节用什么方式。记得软件工程中说，需求分析时，脑子里面没有具体的实现技术，但它确实是软件开发的一部分。可见，不能把“管理问题”独立开来，本身它和技术就是一回事。至于产商应该做到哪里为止，自然有市场的检验，有实力的，给出在丰富实施经验基础上的整体解决方案，包括流程的改造和建议；没实力的，给个软件，说明书还不全。但我们在和公司交互的时候，心里要明白，要清醒，核心矛盾是需求。这个问题上模糊，合同容易签下来，但以后麻烦；这个问题上清晰起来，头绪会很多，但值得，也要利用公司希望做成这笔单子的动力和经验。所以，无论做还是买，我还是建议关注细节，特别是在现实环境中具有可行性好的实现方式的细节，这实际上是在研究医学领域的信息管理问题，也就是分析计算机在某个领域/流程中应用的优势和局限性 --------- 医学信息学

ermulong · 发表于 2006-6-26 16:36:38

引用bland的“作为软件公司，尤其是专业再做医疗行业的，以上的问题应该都考虑过，应该有应对的办法。”引用eyedoctor的“现实情况恰恰是需求不容易把握。医院许多情况吃的最多的亏，也就是需求不清楚，结果没话说。”仔细想想这两种观点，也正是目前公司的想法与医院的困惑，往往公司都以为已经解决了的问题，在医院可能变成了更复杂的问题。

ermulong · 发表于 2006-6-26 16:45:51

挂号时分诊好，还是挂完号，再分诊？两种办法都有各自的理由，其实还有别的选择，关键是提供方法或选择方法的过程是否合理，公司有没有以下义务呢？针对该问题与医院一起探讨流程，提供方案供选择，将各种方案可能的优缺点拿出来讨论，甚至该问题提出也是由公司提出，而不是医院提出，等等

tyq · 发表于 2006-6-26 20:15:51

应该说医院要主动，不要在需求问题上太依赖公司。公司是可以提供一些其它医院的做法，也就是提供几个选项给你而已，选择还是需要医院来做。公司无法为医院做决定。像上面的挂号问题，有些固定的号别，可以用自动分诊，不能固定的号别，只能手式分诊，不管分诊地点在挂号处还是分诊台。有些问题不懂，可以和公司一起交流，从不明确到明确，医院是主，公司是客。如果医院的需求不明确，又怎么能对公司指手划脚呢？公司提供的方案医院能接受吗？符合医院的流程吗？工程验收又怎么进行呢？一句话，落后就要捱打，被动也要捱打。这是医院与公司的角力，相互较量、相互促进。一般来说，初次上系统的医院有点模糊，换系统的医院一定不会含糊的，要不然为什么要换呢？怎么换呢？如果说第一次上系统交了学费，换系统还是老样子，那学费就白交了。

小城医生 · 发表于 2006-6-26 23:15:15

需求永远是无穷尽的,事实上我从业以来几乎就没有哪个医院能把自己的需求能清晰地进行描述。在海外，很多情况下在签署合同前就已经做好的需求调研，将需求详细的体现在合同中，即不存在过度需求的情况（否则加钱），也不存在“镀金”现象。在我公司餐厅的玻璃墙上写着这样的一句话“客户的需求虽不如玻璃一样透明，但我们仍然可以一眼看穿。”，这无疑是对厂商的艰难挑战。我现在越来越感到，其实是医院应该更加反思自己。很多解决方案是不是应由咨询公司提出？此外，也许是受到流行书籍的影响，越来越多的人都把“细节决定成败”放在口头上，我却不以为然。我并不认为细节不重要，但更为关键的是整体和系统上的把控。在管理学上有一个经典的案例：日本研究人员偶然机会曾经得到前苏联的米格战斗机零部件进行分析，结果令他们大吃一惊，每个零部件竟然不是当时先进的设备，甚至比较落后，而且有些部件工艺上还是很粗糙。但是飞机的整体性能上与美国的F 系列战斗机不相上下，精细的日本人推断出，前苏联的米格飞机的整体框架结构上更有优势。回到我们当初讨论的话题，软件的细节问题各家都有自己的优势所在。此时，就主要看客户的感觉和偏好了。白菜永远是我的最爱，萝卜永远是兔子的最爱，你呢？也许和油盐酱醋炒出来的才是最好。 <div>此帖由小城医生在 2006-06-26 15:19 进行编辑...</div>

url · 发表于 2006-6-27 00:00:37

<div class='quotetop'>引用

tyq @ 2006-06-25 13:54)</div><div class='quotemain'>流程的制定：……医院的流程那么多，怎么定？这是CIO的职责，如果需要公司来负责，那就是管理咨询了，就不是单纯的买软件了。就像买一套OFFICE，微软不会教你标题用什么字体、字号的。</div> 做一个管理咨询公司有市场吗？或者像IBM那样的。

ermulong · 发表于 2006-6-27 08:55:13

一个医院上HIS是一个项目，需求是项目的一部分我想大家都没有异议。需求应该由谁来完成？以医院为主，医院有没有这个能力。以公司为主，公司有没有花这个精力。是开发一个HIS，还是实施一个HIS，需求与产品有没有关系？找咨询公司，有没有，咨询公司主要做什么工作，有没有能力参与实施或者负责实施。有没有成熟的产品可供咨询实施。

khan · 发表于 2006-6-27 16:26:39

电子病历要有进步关键是要看医疗体制，放不开手就永远不会走路。医院凭什么就是老大，凭什么就不能接受市场的竞争？

		自动登录	找回密码
密码			欢迎注册