如果是一个大医院，
如果放射医生包括CT、MR、B超、内窥镜，甚至心电图、病理，
如果病区、门诊、手术室，甚至管理部门同时有不少用户，
如果医生浏览不仅仅限于在医院内，
以上的规模和频率不是没有可能，应该有所准备。

这个是有多种解决方案的，不必担心

影响系统响应速度的原因很多，比如：服务器的配置，数据库软件的选择，应用程序是否优良，网络内是否有病毒等等。网络带宽是比较重要的，但是我认为相对于其他几方面的因素，网络带宽还是比较容易解决的。我就见过一个医院的系统被病毒影响的很慢

根据不同的配置情况会有不同的规划方案，基本上都可以或多或少的解决/缓解/平衡这一问题，当然，如果又想马儿跑又想马儿不吃草是基本上不可能的，除非你是很牛的医院大把厂商愿意倒贴，否则我们还是要遵循市场规律，一分钱一份货付出得多，才可能收获的多。
楼上说的很有道理，一看就是有过很多经验的人。呵呵，顶一下。

在100Mb带宽的网络中，理论传输速度应为100/8=12.5MByte，实际按5MB计算，如果10G流量，则传输时间为10*1024/5=2048秒，约35分钟。这些数据并不需要实时传输，所以这样的数据量在现行的院级局域网络中并没有大的影响。
在实际工作中，通过1个交换机，200米范围内，数据传输速度可以达到8-10MB的。我院通过4台交换机，约500米范围也在5MB左右。

病毒等属于异常情况。我在这里考虑的是常态－－
正常情况下，大量并发的PACS影像数据流会否延滞千兆骨干网络中HIS频发交易数据的响应！
这里的PACS影像数据流的大量并发在大型医院是常态，千兆骨干网的带宽限制也是常态，HIS交易的频发也是常态，如此产生了在带宽限制下的影像流与频发HIS数据的竞争，也是常态！
产生的问题就是：有没有技术方案能解决或缓解这种竞争？

医院信息主管，实际上是一个规则制定者－－如同政治家一样，如何在有限资源内寻求最佳平衡？

在带宽这个资源限制下，在建立各个信息系统时，需要建立许多有形和无形的规则，有些由自己实施，有些要灌输给院长和使用科室主任－－比如，如果确认带宽确实是信息化实施中的最紧缺资源，在大型医院，为了不造成影像流延滞HIS的频发交易，带有压缩影像流的PACS方案就是比没有压缩的方案，更有利于医院信息化的健康实施－－除非考虑万兆网！

20楼的有两点有差异
1：实际传输是要考虑每个socket加的校验，以及包失败重传等，所以流量要大上那么一些
2：你指的是单路传输，未考虑并发访问，假如20个终端同时调阅呢？应该计算明天的总调阅流量等

同意21楼的观点，厂商和医院信息科应从技术上为决策领导提供足够的依据，然后如何根据实际情况配置自己满意的性价比的东西，是决策者需要考虑决定的东西，这是个平衡问题。

如同MOUSE在“64排CT对PACS的影响”一贴中所谈，现在大型医院都在考虑上或已经上64排CT－－有已经上了64排的曾在一次扫描中产生600+幅影像；CT的下一步发展甚至会有平板CT－－每一圈扫描产生1024层影像。
以影像矩阵512x512计，像素深度12bit，则每幅影像0.5MB；若为1kx1k，则每幅影像为2MB。
对于上述用64排CT一次做了600+层影像的具体事件，相应地就产生了PACS终端会一次调用600x0.5=300MB=2400Mb、或600x2=1200MB=9600Mb的影像数据流。
这时候，网络主干的带宽限制，就必然是信息化实施中的最大瓶颈－－注意，我这里谈的是“实施”，就是让系统在医院的真实情景中真实使用时的状态。

哎，这个问题，迟早大家都会面临的，存储这块暂时还不担心，我最担心的是使用，即调图和看图

我认为，骨干网带宽的瓶颈问题，在那些年收入过4亿的大型医院，现在已经是问题了－－
－64排CT已经开始装备了许多了！
－DR/CR往往是多台！
－DSA也往往是多台！
－乳腺机也开始通过平板技术数字化了！

咱们再分别计算－－

普放(DR/CR/乳腺)：可以达到4kx4kx16bit/每幅，即32MB/每幅，如果一个病人一次拍了10幅，则放射医生调用一个病人时，网上会涌出320MB即2560Mb的影像流，会否延滞HIS的频发性调用呢？

导管室(DSA)：如果对一个介入手术采集了4个序列，每个序列30秒，影像矩阵为1kx1kx16bit/每幅，即2MB/幅，则放射医生调用一个病人时，网上会涌出“2MB/幅 x 25幅/秒 x 30秒/序列 x 4序列”＝6000MB＝48000Mb的影像流；即便这一个病人的各个序列单独存储和单独调用，也有12000Mb的影像流！会否延滞HIS的频发性调用呢？

所以，我是愈发地感到，医院信息化实施，其瓶颈就是骨干网络的带宽！

关于 PACS系统的带宽问题，需要分层考虑：

1）最大的爆发流量出现在设备和控制台，三维重建站之间， 建议把这样的流量封在放射科子网内在楼层交换机一级流动，

2）其次的流量出现在PACS 服务器， 工作站和设备之间，流量相对比较小 （影像已经有过初步筛选和处理），但是时间要求仍然比较高（急着写报告呢），可以考虑给ＰＡＣＳ设置一个单独的核心交换机。将这部分流量封在ＰＡＣＳ网里面。

　３）最后的流量出现在临床工作站和ＰＡＣＳ服务器之间，由于这部分影像受到进一步删减（除非放射科医生非常开放，或者ＰＡＣＳ没有这个功能），　而且临床医生对影像调用时间要求没有放射科高。所以可以在普通ＨＩＳ网络中跑。　当然，　优秀的ＰＡＣＳ应该有专用的临床看图客户端，充分考虑普通显示器，有限带宽情况下的图像质量和速度保证。

　　这样处理就没有问题了，坦率地说，还没有听说过哪家医院的网络曾经是瓶颈。

如果到临床，流量还是不可忽视的，至少对HIS主干网来说绝对是个不小的负担，即使选择了压缩。。。之所以“没有。。。”也许是因为应用还不够大吧，呵呵

我很同意“优秀的ＰＡＣＳ应该有专用的临床看图客户端，充分考虑普通显示器，有限带宽情况下的图像质量和速度保证。”的观点，没理由专门在医生工作站旁边还要配备专门的PACS工作站。

多谢QIUYE的细致考虑。但是我仍有疑虑：

1、设备/控制台/3D站之间，可做子交换机子段直联，倒可以不必过虑。

2、我上面计算的如此大影像流，主要指的是放射医生工作站对PACS服务器的存取，流量并不小。
即便单为PACS设核心交换机，从而不会影响HIS的频发交易，但千兆骨干网，对于上述2560Mb的数字乳腺片、或12000Mb的DSA图，会出现什么问题？须知在某台放射站调用这个病人的影像时，同时还会有几十台其它放射站在用，RIS数据也在这个子段内跑，会不会RIS登记台长时间登记不上？会不会某个医生写的报告长时间发不上去？

3、并入HIS主网的临床影像发布，除非支持了KI标志、病灶标注等，让临床医生调用某个病人时不是所有影像同时发送，否则，仍然会有上述的突发数据流！即便支持了KI标志和病灶标注，也许临床医生也偶尔会调览全套影像，这时不会影响HIS的频发性交易？

4、关于“专用的临床看图客户端”，我赞成MOUSE所说，“没理由专门在医生工作站旁边还要配备专门的PACS工作站”，即应该把PACS对临床浏览的支持，集成到HIS的医生工作站内。一般而言，我理解，这应该是以WEB方式来支持临床浏览，对吗？

5、这时，又出现我前面谈过的问题：有没有一种方法，能针对临床浏览医生站的显示分辨率来调整其发布影像的分辨率，同时又能在临床医生作ZOOM时将ROI内的部分影像以最大分辨率发布？

我回答4和5吧，

4：临床方式不一定非要web，当然面对数量庞大的临床医生终端，瘦客户端或者B/S结构在维护上来说方便得多，但是web的一个缺点是不能很好的与医生工作站集成，直观点说就是两个不同的界面，调用的时候可能操作步骤也多了好几步，要多点不少次鼠标。。。。。另一种思路是作为中间件嵌入到医生工作站，形成统一的界面和一体化的平台，感觉上都在同一个系统里运行，通过约定的衔接方式，努力达到所谓“无缝”的程度，这样对使用者来说就更方便和好了

5：针对临床医生站的显示分辨率来调整，技术上是完全可行的，理论上也很清晰，可以采用图象分层次、渐进式的传输和所谓On Demand的方法，这样传输的数据量也会少很多，DICOM标准里JPEG2000格式就可以支持这种实现。