三甲医院传统院内信息化系统经历20多年的建设发展，目前正面临智慧医院建设转型中的诸多问题：例如在互联互通和电子病历评级过程中，原有单体应用、C/S架构应用的ESB性能、单点故障和服务治理问题；在基于消息驱动模型的医疗大数据分析中数据标准化、全面向性和及时性等问题；在后疫情时代，传统架构无法快速满足互联网医疗发展的问题；医院物联网应用的数据分析计算协同问题等等。
基于云原生架构的解决方案是医院迈向数字化时代的必由之路，包括面向医务人员的“智慧医疗”、面向患者的“智慧服务”以及面向管理者的“智慧管理”都可以利用云原生架构实现。
社区近日组织2021容器云职业技能大赛医疗行业应用创新解决方案成果发布及探讨活动，邀请到武汉市中心医院、深圳华侨医院、西宁市中医院、内蒙古医科大学附属医院、中山大学附属肿瘤医院、南京市第二医院、廊坊人民医院和浏阳市中医医院等8家医院的一线技术专家和东软集团、RedHat公司的技术顾问参与，针对如何基于云原生架构加速三甲医院实现互联互通、建设智慧医院，在热烈的氛围中对基于云原生架构的医院信息化解决方案进行了讨论和探索。
本文梳理了与会者的分享精华，重点从五个方面20个交流主题进行总结，包括：医院业务容器化转型的思考，智慧医院建设的思考，智慧医院解决方案的实施和部署，容器云平台的使用、安全和运维，交流共识，希望给致力于研究的医院容器云解决方案的同行们提供一定的参考和帮助。
一、医院业务容器化转型的思考
目前医院信息化发展以ESB和C/S架构私有云部署为主，基于容器化的云云原生架构尚未普及。特别是核心HIS/PACS/EMR等业务系统也没有进行微服务化改造。那么，考虑对医院业务系统进行微服务化改造并采用容器技术进行部署，哪些信息化系统会比较合适呢？如果将现有业务系统进行改造部署，困难和问题又有哪些？
1、三甲医院目前适合容器化的典型应用有哪些？
jakeyyu某三甲医院系统架构师：
首先明确的就是互联网业务，因为大部分互联网业务可以使用单体结构技术去实现，比如功能单一的业务或并不复杂的业务；第二就是在核心业务中可以拆分成为独立服务的业务，通过接口与核心相连。
刘东东软集团IT技术咨询顾问：
目前三甲医院最适合的容器化场景应该是智慧医院应用场景。
例如说患者中心：通过服务化、移动化的手段使医疗服务和医院流程向患者集中。医疗费用中心，通过微服务和容器化支持产品应用快速构建，灵活应对医院快速发展的信息化需求。
另外，在医院的云数据中心建设上，容器化部署也会带来很多好处。
基于容器化的云原生技术是大势所趋，容器云具备快速部署和便捷运维等特性，支持DevOps的开发运维一体化，可以让医院信息中心业务部署更灵活，更简单。
2、三甲医院业务的特殊性和复杂性导致单体应用转变为云原生架构具有一定的困难性，如何解决？
【问题描述】云原生架构中具有微服务、容器化、DevOps等特点，目前国内三甲医院的信息化建设相对较为完善，技术成熟，为了尽快全面实现互联互通，智慧化医院建设，也期待技术上的领先和突破。目前，国内大多数三甲医院的信息系统体量较大，绝大多数以单体应用为主。随着政策的指引，以及信息安全的要求，ESB总线技术业已全面应用在三甲医院的信息化平台架构中。作为云原生架构的优点，容器化和微服务应用优势明显。但是三甲医院业务的特殊性和复杂性导致单体应用转变为云原生架构具有一定的困难性，比如业务如何拆分并迁移至微服务，数据如何统一管理，业务流程的全面管控，在转变过程中这些困难如何克服？
Sam_Zhu RedHat（Beijing）解决方案架构师：
需要引入具有丰富经验的合作伙伴和领先解决方案的厂商。三甲医院的IT建设水平处在行业领先阶段，在智慧医院建设方向也有很强的意愿。红帽与近90%全球500强企业客户合作，帮助他们进行数字化转型，使用OpenShift业内领先技术，在应用微服务和容器化、业务流程自动化等方面积累了丰富经验。相信红帽的技术再配合东软在行业解决方案方面的能力，一定能为广大三甲医院客户IT建设带来全面提升。
医疗行业技术专家：
1、业务拆分尽量遵循DDD设计原则，由医院具体的使用者来驱动设计，而不是传统的设计方法！尽量在比较完备的模型基础上去做相应的架构。而不是在原有业务基础上由开发主导设计，这样的结果就是换汤不换药。
2、医疗业务确实很复杂，面对这样的业务，短时间内没办法拆分相对合理的领域模型，所以不要过分设计，把握核心业务就好。
3、还有您提到的ESB，相对于云原生，其本质就是上面的业务拆解
4、任何技术都不是银弹，鞋子合不合适只有脚知道。不要刻意模仿比如淘宝、京东等互联网大厂的架构方案，否则只会东施效颦。
以上是个人对云原生在医疗领域的浅见，欢迎讨论指正。
3、医院消息驱动的系统互通架构如何转型到云原生？
【问题描述】消息驱动的集成平台架构随着系统越来越多，依赖平台就越来越强，这种架构如何往云原生转换，微服务与这种集成平台是怎样关系，存在矛盾还是并不冲突？
Sam_Zhu RedHat（Beijing）解决方案架构师：
消息是异步通讯的基础，集成平台也是实现SOA的重要标志。这些架构处理的问题也都是云原生技术（微服务、容器化等）所需要面对的，它们不矛盾，反而会利用消息和原有的集成模式来以最低的代价解决问题。
因此我们看到大量基于消息中间件异步通讯的微服务方案，以及基于容器和微服务技术的分布式敏捷集成方案。集成平台由于服务设计和功能拆分不合理或管理因素等形成的依赖性导致平台形成了一个新的大单体业务系统，这和集成平台建设初衷也是背道而驰的，我们应该在云原生技术引入时避免这些问题的出现。存量和新建并行是可取的做法，开发和运维会积累实际经验，不断纠正和完善。
4、医院从基于ESB的平台迁移到云原生平台的难点在什么地方？
【问题描述】原有的服务要变成微服务，是否有工具自动转换，.NET封装的服务如何跑着DOCK上？客户端调用是否需要改变？
Sam_Zhu RedHat（Beijing）解决方案架构师：
云原生的目的不是重构和技术升级，是为了更灵活和高效的解决业务问题。ESB的大单体应用整体搬迁技术上问题不大，但是没有业务上的收益，甚至效果更差。实际遇到很多客户的经验是小步快跑，老ESB会和微服务应用共存很长一段时间，我们用运用一些微服务容器化的敏捷集成技术将无法改造的老系统和新系统打通。业务挑战严峻，对灵活性和开发迭代周期短的业务领域应用，可以优先考虑转到这个方向上来。
原有的服务变成微服务更多的是业务问题，业务领域拆分的合理性才是重点。技术上有很多工具实现，包括.net服务容器化，红帽就提供.netcore基础镜像和迁移支持。客户端一定是最大限度的保证稳定不变，这也是集成层解耦的主要目的。
jakeyyu某三甲医院系统架构师：
从这个问题来说，主要是esb的平台迁移到云原生平台，关注微服务架构如何实现的问题。我们知道对于单体架构业务转变为微服务的架构面临着一些固有的特点，如微服务之间如何通信，微服务之间数据如何共享，迁移过程如何不影响现有业务等。如果原来的基于esb平台上的业务是linux系统，客户端调用应该问题不大。
5、微服务化改造过程中，数据中台技术是如何对于医院信息化互联互通要求起到支撑作用的？
【问题描述】数据中台技术是如何对于医院信息化互联互通要求起到支撑作用的？（从数据中台技术的特点，发挥作用，结合医院信息化建设的特点，以及三甲医院业务的需求层面）
gulx东软集团股份有限公司软件架构师：
数据中台以数据湖为底座，打破数据壁垒，实现医疗信息数据的统一存储，解决医疗大数据存储难的问题。以大数据平台的分布式计算能力为支撑，结合数据治理，形成数据资产，解决医疗数据孤岛现象，实现数据连通。采用流批一体的OLAP技术解决方案，支撑大型三甲医院的离线与实时相结合的业务需求。
二、智慧医院建设的思考
医院进行互联网架构转型，建设容器化的云原生平台，建设数据中台、业务中台，进行微服务化改造，这一切都是为了智慧医院的建设，那么医院智慧医院究竟该如何进行建设？智慧医院和云原生平台的关系又是什么呢？
1、智慧医院平台建设一般需要分为几个阶段进行设计？
刘东东软集团IT技术咨询顾问：
1、智慧医院平台的建设按照2021年国家卫生健康委《关于印发医院智慧管理分级评估标准体系（试行）的通知》。智慧医院的建设主要分为三部分内容，包括智慧医疗、智慧服务、智慧管理三大评估标准。
2、智慧医疗面向医务人员，智慧服务主要面向患者，智慧管理主要指后勤物资和运营管理。
3、为了实现以上三部分智慧医院建设内容，首先需要有一定的基础建设和积累，主要包括以电子病历为核心的医院信息化和医院数据的统一安全管理。
4、在医院信息化建设和数据安全建设之前，又需要有一个具备安全、可靠和稳定的基础设施。
5、所以，实现智慧医院，以上任何一部都不可或缺，特别是在基础设施方面，首先需要查缺补漏。在医院内部利用物联网、云原生、云计算和大数据等新技术完成基础环境建设，统筹管理资源。
2、智慧医院建设中，后勤建设、管理的难点和对策有哪些？
【问题描述】医院后勤管理的智能化实际是上医院管理智慧化，它是“智慧医院”建设中的一个重要部分，但是，目前情况下，医院后勤建设和管理，其智能化水平还比较低，和智慧医院的中的智慧医疗、智慧服务的快速发展不相匹配。我的问题是医院后勤管理智能化有哪些痛点和难点，有什么对策？
刘东东软集团IT技术咨询顾问：
首先，后勤管理的建设难点主要如何建设一个数据平台，将智慧后期系统与其他系统连接获取数据，然后进行精细化运营。
其次，智慧化的医院后勤管理系统需要将被动服务转化为主动服务，提高后期服务效率，同时构建智慧化的统一后勤服务体系。
1、数据平台的建设需要利用IT技术和其他系统（例如如电梯、中央空调、医用气体和消防系统等）连接，开展数字化智慧后勤建设。
2、对数据进行精细化管理，提高设备运行效率，降低能源与资源消耗，促进医院的和谐、可持续性发展
3、数据平台的运营和承载同时需要一个云平台进行统一，同时也可以考虑云原生平台来实现。
jakeyyu某三甲医院系统架构师：
这个问题目前的解决办法还是比较成熟，是因为各大公司有很多具体的实施案例，一般依托于企业的智慧园区管理模式。对于医疗行业，特别是医院，包括两个方向，第一是建设数据中枢平台，将院区管理，人员、车辆、物业、楼宇等相关要素信息集中管理，通过一卡通的方式，进行人员身份认证，门禁识别，车辆进出院区等。第二是关于医疗，这部分通常与医院系统做集成，包括医用物资、设备采购管理，高值耗材等。我认为这两点不能进行混合管理，也就是通过一个平台来进行，主要原因是二者的业务流程区别很大，虽说涉及的多个管理部门都和后勤相关，但管理内容包括医疗部分，医疗业务必有专业的医疗部门去管理，因此在智慧医院的建设中应该区分开来建设。
3、在智慧医院建设，如何提高医疗设备的智能化水平？
【问题描述】随着“智慧医院”建设的不断推进，不少同行发现了在“智慧医院”建设中，有一个瓶颈，那就是医院整体缺少智能化的设备，无法满足集中管理和分散控制的需求，达不到自动化智能控制照明，锅炉，空调，除湿机等用电设备；无法分析环境、湿度等数据，造成设备过度运行能耗浪费情景，能耗巨大，延长寿命减短，环境不够舒适智慧化。那么我的问题是：在“智慧医院”建设，如何提高医疗设备的智能化水平？
刘东东软集团IT技术咨询顾问：
在智慧医院建设中，提高医疗设备的智能化水平，并不是简单的通过智能设备实现的，主要还得需要依靠智能化的管理系统。例如在问题中提到的自动化智能控制照明，锅炉，空调，除湿机等用电设备，除了智能化设备以外，还需要智慧后勤管理系统，可以将这些设备统一的联动起来，获取运行数据，然后进行统一数据分析和管控。利用获得的数据更好的利用这些智能设备，让医院更具智慧化。
spgoall和祐国际医院信息管理部部长：
对于旧设备，无法提供运行状态接口的，可以利用一些RFID等智能标签做到设备定位和开关机时间的收集，对于新的设备，特别是即将要采购的设备则需要在需求里明确要开放运行状态数据接口，或自带的运行监测系统开放接口给第三方平台调用。有了数据才能做分析、预警。
4、在智慧医院建设中如何提高智慧服务水平？
【问题描述】我院已经实施建设了智慧医院建设，应用一年多来，发现智慧服务水平有待提高，具体情况是，在智慧医院应用过程中，患者挂号就诊途径多元化，对于患者，存在这样的问题，初次就诊没有问题，我什么时候挂的号，什么时候去找相应医生看病，智慧挂号都已准确到分了。但是在整个就诊过程中存在患者重复等待情况，患者不满意。如患者就诊，要去检查，因为做不到就诊后，相应的检查等着你去做，要排队（患者不可能先回家等），做完检查后，找医生看，这时医生在跟别的患者看病，并且这时还有其他患者等着看病，不可能让你插队先看你的检查结果、诊断，因此这种情况下又要等待，多次重复等待，患者不满意。那么，我的问题是，在智慧医院建设中，如何解决这些问题？
刘东东软集团IT技术咨询顾问：
1、您提到的智慧服务水平提高主要是门诊服务流程问题。患者到医院就诊体验如果产生过多的排队情况，往往就诊体验就不高。如何进行门诊流程再造，优化就诊流程，构建科学、规范、合理的就医流程，改善患者就医体验，国内大量的医院也在进行积极的探索。
2、优化患者就诊流程和体验除了信息化技术手段，还需要一定的流程优化和管理制度的优化。例如允许在新挂号患者之间按一定比例安排检查后复查患者插队，可以起到一定的作用。之前我去过一个医院就默认2名新挂号患者+1复查患者+2+1这种自动的排队模式。大家也都可以理解和接受。
3、另外，针对目前医院存在患者排队、等待、辗转多次而造成的就医体验差，也可以应用技术手段设立统一的预约通道，设定患者冲突知识库等，避免多次预约等问题。解决患者预约、排队、等待、辗转等问题，有效降低冲突，降低就医成本，提升就医满意度。
5、智慧服务首先实现哪些项目效果更明显？
gulx东软集团股份有限公司软件架构师：
对目前排队比较明显的服务，比如：
患者建档，预问诊，方便医生提前前了解患者症状，缩短看诊时间；
预约挂号和预约检查检验，减少患者排队，注意事项重点通知；
患者费用管理，对接移动支付减少排队，欠费催缴信息及时发送；
诊疗过程查看，包括检查检验结果，病历等，方便患者及时了解看诊进度，以便安排复诊时间；
基于物联网的院内导航业务。
三、智慧医院解决方案的实施和部署
医院信息化系统的建设离不开云架构，为了让医院信息化系统更智慧，除了云架构更需要考虑容器云平台建设。在容器云平台建设、实施和部署之前，需要对现有医院业务系统进行梳理，哪些业务适合进行改造和适配，其次进行容器平台的技术选型和建设完成部署，最后是对容器云的维护和DevOps建设。在容器平台选型上可以考虑采用k8s开源架构，但是要求这类医院有较强的技术开发和自研能力，否则建议选用基于k8s的商用容器平台，可以加速应用容器化实施落地，稳定性和安全性也更高。
1、互联网医院的建设是智慧医院建设的重要一环，如何搭建适合互联网医院的云架构？
【问题描述】互联网医院的建设是智慧医院建设的重要一环，如何搭建适合互联网医院的云架构？是私有云还是混合云，如何划分安全边界，同时又能保证数据本地化存储？最重要的是满足互联网医院线上的应用扩展。
Sam_Zhu RedHat（Beijing）解决方案架构师：
从目前趋势看，传统医院云架构体系建设应该是私有云为基础，公有云为必要补充的混合云路线。核心业务系统和关键业务数据是在本地数据中心维护，同时充分利用共有云弹性计算资源搭建渠道应用和流程。数据下发和同步应通过标准的安全协议通道传递，启用公有云环境中的数据加密功能，保障落地数据的安全性。封装业务流程服务接口，调用通过统一的API网关把控安全和链路追踪。安全建设是系统工程，没有绝对的安全方案，私有云和公有云安全应该通盘规划和设计。
jakeyyu某三甲医院系统架构师：
云架构建设具有多种方式，私有云，公有云和混合云。针对该问题，一般情况下医疗机构会根据自身的投资情况，大多会采用混合云和小规模私有云，混合云负责同互联网互通，公共业务的服务都可以部署在上面，而核心业务数据库等在自身的私有云上，形成内部业务闭环。一般通过在边界上放置防火墙，网闸等安全设备，数据通过业务接口程序单向传递。这样对于互联网医院的应用扩展形成安全的架构，既保证了数据的本地化存储，也方便应用扩展，不足之处是对接口服务有一定的要求，此处处理不好，多数情况下会影响业务。
spgoall和祐国际医院信息管理部部长：
目前互联网医院有两种模式，一种是完全第三方平台，Saas模式，另一种是自建或合作共建，本地私有化部署，这个问题应该是适用于第二种情况，这种情况实际上是要实现线上线下联动的，最优的做法是医生端的电脑端是和业务HIS融合对接，这样必然涉及到内外网打通的问题，所以需要的是混合云架构，需要界定出口防火墙DMZ的前置服务器和内网HIS服务器的访问策略以及和桌面终端的访问策略，存储肯定是存在内网。
2、后疫情时代，互联网＋医疗医院数据中心与混合云如何建设？
【问题描述】后疫情时代，大型医院数据中心该如何建，私有云有必要与公有云形成严格物理边界吗，是建软件定义的数据中心还是传统的呢？网络安全如何同步考虑？
jakeyyu某三甲医院系统架构师：
就目前从安全角度出发，无论在什么应用环境下，目前的技术私有云和公有云的严格物理边界是无法去掉的；其次对于医疗系统的数据中心建设我认为更应该继续坚持以患者为中心的服务系统的建设，同时兼顾防疫的信息采集，数据中心的功能应该包括和政府防疫信息平台的对接，这种应用场景业务在公有云上能够更好的服务社会。根据实际的需要，基于软件定义的数据中心和传统数据中的建设都应考虑。
3、医院集成平台架构和业务连续性问题？
【问题描述】问题一：新一轮的医院互联互通评审开始后，医院信息科又遇到这样的场景问题，基于SOA的架构，由于历史的原因，遇到评审也过后，但是无法真正的运行起来，原因有以下几个方面的原因：
1.沟通与协作成本高：新系统迫于业务需求和市场压力，急需上线，对负责的团队而言，与周边系统的对接和调试属于外部不可控因素，团队总是倾向于在内部可控的范围内解决问题，因此会刻意避开对外部服务的依赖，选择自建相关功能，这样一来，系统间的交互会向着衰减的方向发展，重复建设也因此随之蔓延；
2.组织架构制约：团队往往缺乏为响应其他系统的诉求而改造和升级自身服务的意愿，因为新系统与他们没有直接的利益关系，医院也缺乏适当的奖惩机制促使各团队之间的积极协作，本质上，这是组织架构决定的；
3.缺乏长效机制：SOA改造常常是作为一个项目实施的，项目结束之后就不再有专门的组织和团队对SOA架构进行持续把控了，后续新的系统在融入SOA系统时受到的支持就减弱了，而新系统本身提供的服务也缺乏必要的梳理和管控，有的新系统甚至不对外提供服务。
我们在做五级互联互通后，发现产品的架构无法适应新的要求，希望专家给支支招。
问题二：有一次处理一个医院故障事件，发现集成平台存在着单点故障，虽然重启服务后，解决了问题，但是给我们带来了一个思考？
集成平台选型时须考虑，支持热备高可用性部署，主备机之间配置、消息库可实时同步，当主机发生故障时，备机可在不需人工干预的情况下秒级自动启动，消息在备机中继续运行，当主机修复后，消息会转回主机中继续处理。
请专家讲讲，在冗余和集群服务中，如何考虑产品？
刘东东软集团IT技术咨询顾问：
解答问题一：
1、SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。
2、SOA体系架构主要是业务驱动IT，SOA通过所谓粗粒度服务接口和分级，确实提高了效率。实现流程化以后，也确实简化了开发难度。但是同时也给服务划分带来难题，如果说这个架构不能符合医院用户的实际需求，也确实不合适。如果所有厂商都进行个性化开发，那么医院业务系统就更难集成。
3、所以服务松耦合设计其实是一把双刃剑，在带来应变敏捷性的同时，也应该考虑类似的问题。
4、为了避免类似的问题出现，其实现在许多行业已经从SOA架构转向了微服务架构。
5、微服务架构其实和SOA架构类似,微服务主要是在SOA上做优化，其特点是将业务系统进行组件化和服务化。原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。所以只要对这些组建进行维护就可以了，新的开发商需要什么组建、服务和能力，只要他提出了，再把服务给他就可以了。可以更快的实现系统开发、上线和部署。同时避免SOA的诸多问题。
6、最后需要说明的一点微服务架构在部署的同时还需要对现有基础设施进行优化，最好采用基于容器的云原生运行环境。
解答问题二：
集成平台选型时可以同时考虑冗余和集群服务。
冗余机制通常是对集成平台本身来说的，例如数据的冗余备份，集成平台承载设备的自身部件的冗余配置。
集群服务机制通常是指多个节点同时提供服务，即使有一个节点发生故障，也不会影响业务的连续性。
实现集群服务通常的做法分为三个层次选择产品。
1、数据库层，例如采用ORACLE数据库RAC群集，单个节点故障，并不会对其他节点产生影响。
2、虚拟化层，例如VMware虚拟机群集迁移，单个VM故障，业务也不会中断。
3、例如云平台或云原生平台实现群集化部署，通常部署在云平台或云原生平台上的业务，都可以利用云平台的相关群集策略和机制实现，可以避免单节点故障和停机。
Sam_Zhu RedHat（Beijing）解决方案架构师：
传统集成平台架构即便运用了主备高可用、多集群等技术手段，仍然是摆脱不了星型架构的单点结构。基于容器PaaS平台的分布式敏捷集成已经是此类总线系统的成熟替代方案，一来解决了大单体巨石应用的问题，二来解决了运维问题。
当然我们仍然可以将多中心、热备等手段用于PaaS平台节点和组件设施，但应用层面上的高可用和弹性伸缩已经被平台接管，我们充分利用基于KS8的容器编排技术，让微服务化的容器集成应用“自维护”。
jakeyyu某三甲医院系统架构师：
目前大多数集成平台都支持双机冗余，或者是多机集群服务。以我们医院为例，我们采取了双机冗余的机制。当然，我们也曾经遇到过上述的问题，也对平台故障转移的机制进行了思考。其实在医院这种生产业务特点下，最大的需求是面临快速的业务恢复，那么对于产品的选型，更应当倾向于备机的迅速接管业务的能力以及平台上消息队列的转移。
4、医院如果采用东软信息化软件产品，又采用红帽的容器化平台，相比其他医院厂商，有哪些优势特点？
刘东东软集团IT技术咨询顾问：
首先，东软医疗信息化软件产品同时支持K8S开源容器云平台和包括红帽在内的多种商业化容器云平台。
采用红帽容器化平台的主要优势包括：
1、红帽容器化平台构建于开源创新和行业标准的基础上，包括K8S和红帽企业Linux，是一个兼容开源标准的容器云平台，可以完全兼容基于开源K8S的医院容器化应用。
2、红帽的容器化平台对安全进行了增强，结合安全增强型Linux（SELinux）环境结合使用，更适合医院用户的多租户环境。
3、红帽的容器化平台还提供了很多实用的工具和组件，可以轻松部署Web应用。通过支持持久性卷等功能，容器云平台可以更好的支持医院大量的有状态应用。
4、红帽的容器化平台是一个完整的容器应用程序平台，在性能、安全和稳定性上可以更好的满足医院未来容器化的需求和应用。
jakeyyu某三甲医院系统架构师：
红帽的技术基于OpenShift容器化技术，因此，除了保持有OpenShift自身的特点和优势外，也会融入红帽和东软的一些成熟技术特点。红帽公司是全球知名的Linux平台的技术厂家，东软是国内著名的软件公司，二者结合应该在云原生系统的技术上具有一定的实力。
5、较高互联互通要求HIS与平台异构，是否必须上两个云？如果不必，怎样证明异构？
Sam_Zhu RedHat（Beijing）解决方案架构师：
HIS的平台无关性需要一个抽象层来保证，通过PaaS平台来支撑这部分能力是一个主流方向。即在平台选型中将对多云和混合云环境的支持作为重要的考核指标。这样就可以达成一套系统跨不同云厂商环境跨区域部署，来满足业务要求。
IT实践中，未必是上两个云，业务将来可能是要求上任意云，这一点对国际化的组织机构来说尤为重要。
jakeyyu某三甲医院系统架构师：
从我的经验角度来讲，HIS与平台异构要求HIS系统的架构与支撑平台架构异构，我们说在建设云平台的时候首先要根据HIS的选型，如果是从头开始建设，这样会容易一些，HIS的选型可以结合云原生架构来建设，这样也可以只建设一个平台，该平台仅仅是对系统的支撑。如果是对已有的HIS系统进行改造，可以考虑独立HIS建设新的平台，并把HIS的部分业务迁移至新的平台上。至于两个云的问题，是根据实际情况而定，可以考虑建如果资金充足的话。
刘东东软集团IT技术咨询顾问：
HIS与平台异构不需要通过上两个云来证明，也完全没有必要。多个云不但不方便管理，还会造成资源浪费。
HIS与平台指的是两套技术路线和保障机制，不一定需要2套云环境，在建设之初需要规划好。通常医院HIS系统是最先建设的，那么在平台建设时就需要考虑异构问题，建议有兴趣的话采用基于容器云技术的云原生架构进行新的云平台建设和支撑。因为新的云原生架构可以支持容器化、DevOps化和微服务化等多种先进技术，同时也可以更好支持医院未来的互联互通。
四、容器云平台的使用、安全和运维
容器云平台对于医疗行业还是一个新兴事物，还处于探索、研究和学习阶段，需要更深入的了解。而且容器云平台比以往任何的基础架构平台更加的接近业务，同时容器云也包含了更多的层级和组件，因此也带来了更多的风险。容器云平台的好用吗？安全和运维情况如何，这都是医院用户比较关注的问题。
1、OpenShift容器云平台使用对医院信息化人员的门槛如何？
Sam_Zhu RedHat（Beijing）解决方案架构师：
我们可以了解到k8s和容器技术对传统的信息从业者还是有比较高的学习门槛的。回答这个问题的前提是下没下决心上基于K8S的容器平台。如果答案是“是”，那么OpenShift就是一款企业级的K8S容器平台产品。它的产品定位就是让用户不用深入了解上述技术，就能快速和高效利用它带来的优势。
OpenShift PaaS平台面向两方面用户群体。一是开发人员，平台提供工具（IDE--eclips风格和命令行--git风格）让开发人员以自己熟悉的方式同OpenShift交互。二是运维人员，SRE工程师甚至不用登到操作系统后台，通过管理控制台就可扩展集群，升级和安装新环境。因此，OpenShift最大限度地帮助我们的用户降低了K8S和容器技术引入带来的技术门槛。
jakeyyu某三甲医院系统架构师：
OpenShift对于医院信息化人员具有一定的高要求，结合近些年三甲医院信息化人员的引进多为应届计算机相关专业硕士研究生，以及HIS厂家成熟的实施工程师和开发工程师，学历高，技术起点也高，同时这类人员对于新技术的学习能力也较强，完全可以胜任openshift的开发使用。
2、如何保证容器本身的安全？
【问题描述】微服务化后，多了一层容器，安全复杂度增加，有无特别针对容器安全的工具或手段？
Sam_Zhu RedHat（Beijing）解决方案架构师：
红帽在OpenShift基础组件之上，提供了高级集群安全管理模块（stackrox），可以帮助用户在镜像安全和容器运行安全，以及提供基于AI的使用安全方面主动的安全加固建议和手段，这和普通的容器静态安全检测手段相比处于领先地位。
gulx东软集团股份有限公司软件架构师：
1、从网络上需要做到网络划分，需要将不同租户之间的网络进行隔离或者使用SR-IOV之类的网络虚拟技术。
2、存储加密，使用K8S CSI管理存储卷的生命周期，将用户与存储架构隔离。同时加密保护各个存储卷，防止不安全访问。
3.对于镜像安全，可以所以用Aqua、Sysdig等工具对正在构建的容器镜像进行漏洞、程序包以及依赖包的扫描。
其次，应该有严格的准入控制策略，只允许通过组织签过名的镜像。
在运行中的容器可以使用AquaSysdig等工具进行事实监控预防威胁。
3、云原生架构的运维？
【问题描述】不是每个厂家系统都原生支持云原生的，当使用基于微服务、服务网格、无服务计算、物联网、Kubernetes等云原生技术统一技术架构，利用数据中台提供的数据服务等这一系列的技术后，整体的运维又有谁来统一管理负责，尤其大多数厂商仍旧使用传统操作系统加配置环境的情况下。
Sam_Zhu RedHat（Beijing）解决方案架构师：
随着DevOps理念和实践在国内的不断发展，有将运维工作下放到开发团队的趋势，因为运维将面对是密集的容器而不是数量有限的虚机，根本管不过来。同时运维也开始做开发，公有云大行其道就是将基础设施代码化的最好体现。趋势不可阻挡，所以运维需要逐步做好自动化体系建设，将运维能力开放给开发甚至业务部门，让他们“自助服务”。运维将有限的精力放在对这些基础设施的管控和环境治理方面，形成良性循环的局面。
gulx东软集团股份有限公司软件架构师：
基于原生的Kubernetes系统进行运维确实会比较麻烦，因为大多数API的使用都是基于命令行或yaml配置，需要运维人员具备很高的技术水平和知识储备。但如果使用云原生管理平台类产品可以在一定程度上减轻运维的负担，即由平台统一提供多租户、系统配置、管理、监控和运维等图形化界面，并且可以即时处理监控告警等重大事件。平台也能集成一定的优化、故障处理方面的经验和专家能力，对平台以及依托于平台运行的应用的健康状况提供合理化的处理建议等。
jakeyyu某三甲医院系统架构师：
我认为云原生架构运维的核心点在两点，一是运维人员的素质，需要同时精通技术和业务的优秀运维管理人员，第二是充分运用devops所需的技术和协作流程。既然企业要进行云原生的架构的建设，必然要在这两方面提前准备，同时在产品选型时要把握所选产品的技术特点，方便后期的运维，不能对市场的产品技术特点过于广泛的关注，这样会增加运维的难度。
4、如何让厂家配合使用容器云平台？
【问题描述】一个大型三甲医院往往使用多个厂家的多个系统，是不是每个厂家都愿意使用，或者说是不是每个厂家都愿意配合使用是个很大的问题。尤其大多数系统都有自己定制的内容，这些如何在容器化的时候实现，由谁来实现？
Sam_Zhu RedHat（Beijing）解决方案架构师：
推进医院IT标准体系建设，建立准入机制，通过构建统一的基础平台来倒逼厂家支持和兼容。医院的不应该也不会在开发方面投入很多资源，集成厂商和软件厂商应该满足微服务化和容器化方面的要求。
5、医院打造智慧医疗，那么云平台方案应该如何设计能更好的保证安全性？
刘东东软集团IT技术咨询顾问：
云平台的安全设计不仅注重技术安全，还应该更多的关注安全管理制度。严格遵循国家等级保护有关规定和标准规范要求，坚持管理和技术并重的原则，将技术措施和管理措施有机结合，建立信息系统综合防护体系，提高信息系统整体安全保护能力。
1、技术安全方面。根据国家等保护标准进行建设，建议至少按照3级及以上标准建设。同时需要确定安全策略，并实施强制性的安全保护，使数据信息免遭非授权的泄露和破坏，提供较高安全的系统服务。
2、安全管理方面，需要建立完整的信息系统安全管理体系，对安全管理过程进行规范化的定义，并对过程执行实施监督和检查。根据实际安全需求，建立安全管理机构，配备专职安全管理人员，落实各级领导及相关人员的责任。
五、交流达成的共识总结
通过本场医疗同行的交流活动达成了一些交流共识如下，仅供参考：
（1）在智慧医院的业务场景驱动下，医院正在逐渐转变现有的技术架构和业务架构以快速适应这种变化。医院的信息化架构也越来越互联网化。
（2）医院有意愿基于微服务架构对原有医院的应用系统进行业务拆分和改造，部署在以业务为中心、低耦合、高度自治、高弹性和自动化的容器云平台上，这将成为未来医院的主流技术架构。
（3）医院的传统核心应用系统、集成平台和智慧医院业务都依赖云平台的建设，而医院目前云平台的基础设施建设能力不足，难以适应新兴业务的灵活性和快速响应能力、部署能力和开发能力的要求。
（4）在容器云的技术选型方面，不同于其他行业，医院普遍自研能力不足，应该首选基于k8s的商用容器平台，可以加速应用容器化实施落地，稳定性和安全性也更高。
（5）容器云平台对于医疗行业还处于起步阶段，对于容器云平台的使用、安装、部署和运维管理还缺乏足够的认识和信心。
