远程医疗信息系统技术规范

Struggle

远程医疗信息系统技术规范 

前  言 
本标准按照GB/T1.1-2009给出的规则起草。 本标准主要起草单位：中日友好医院、郑州大学第一附属医院、国家卫生计生委统计信息中心、贵 州省卫生信息中心、浙江数字医疗卫生技术研究院。 本标准主要起草人:许树强、张铁山、杨崑、赵杰、翟运开、汤学军、张黎黎、严刚、兰文跃、陈 茂华、盛慧萍。 
 
远程医疗信息系统技术规范 
1 范围 
本标准规定了远程医疗信息系统总体技术要求、系统功能、信息资源规范、基础设施规范、安全规 范和性能要求等。 本标准适用于一方医疗机构（以下简称邀请方）邀请其他医疗机构（以下简称受邀方），运用网络 通信和计算机技术，为本医疗机构的患者及医务人员提供技术支持的医疗活动。 
2 规范性引用文件 
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 WS 363 卫生信息数据元目录（所有部分） WS 364 卫生信息数据元值域代码（所有部分） WS 365 城乡居民健康档案基本数据集 WS 445 电子病历基本数据集（所有部分） WS/T 447—2014 基于电子病历的医院信息平台技术规范 WS/T500（所有部分） 电子病历共享文档规范 WS/T 529 远程医疗信息系统基本功能规范 电子病历基本架构与数据标准（试行） 原卫生部 2009年 
3 术语和定义 
WS/T 529界定的术语和定义适用于本文件。 
4 缩略语 
下列缩略语适用于本文件。 B/S：浏览器/服务器模式（Browser/Server） DICOM：医学数字成像和通讯（Digital Imaging and Communications in Medicine） DNS: 域名服务器(Domain Name Server) ESB：企业服务总线（Enterprise Service Bus） ETL：数据集成（ExtractTransformLoad） GK: 网守(Gatekeeper) GW: 网关(GateWay) GTP：通用文件传输（General Transfer Platform） H.264：视讯通信协议 H.323：音视频协议 
HDMI: 高清晰多媒体接口(High Definition Multimedia Interface) HL7：卫生信息交换标准（Health Level 7） HTTPS: 超文本传输安全协议(Hypertext Transfer Protocol Secure) IHE：Integrating the Healthcare Enterprise IP: 互联网协议(Internet Protocol) IPSec: IP安全协议（Internet Protocol Security） LDAP: 轻型目录访问协议(Lightweight Directory Access Protocol) MAC: 消息鉴别码(Message Authentication Code) MCU: 多点控制单元(Multipoint Control Unit) QoS: 服务质量(Quality Of Service) SIP：会话初始协议（Session Initiation Protocol） SMP：标准管理规程（Standard management procedure） SOA：面向服务架构（Service Oriented Architecture） SRTP：安全实时传输协议(Secure Real-time TransportProtocol) TLS: 传输层安全(Transport Layer Security) VGA：视频图形阵列（Video Graphics Array） VPN: 虚拟专用网(Virtual Private Network) XML：可扩展标记语言（Extensible Markup Language） 
5 总体技术要求 
5.1 总体框架 
远程医疗信息系统总体框架主要包括远程医疗信息系统的应用、远程医疗信息系统的服务、信息资 源中心、信息交换层、基础措施、标准规范、安全保障，见图。

 
5.2 技术架构 
远程医疗信息系统技术架构如图所示。 

5.2.1 应用层 
远程医疗信息系统应用层由远程医疗服务应用和远程医疗监管组成。通过统一的远程医疗服务门户 访问，可实现远程会诊、远程影像诊断、远程病理诊断、远程心电诊断、远程监护、远程手术示教、远 程医学教育等远程医疗服务，各应用可实现“即插即用”；通过远程医疗监管模块提供的功能，可实现 各级远程医疗系统运营情况的分析、统计、决策等多种监管功能。 
5.2.2 服务层 
远程医疗信息系统服务层所提供的服务包括注册服务、远程服务、存储服务和电子病历档案服务， 用于通过远程医疗数据传输对象与远程医疗业务逻辑层直接进行交互，集中了系统的业务逻辑的处理。 服务间的消息交换和消息传输贯穿各个服务层，服务间的消息交换需要基于通用的交换标准和行业的交 换标准。 
5.2.3 资源层 
远程医疗信息系统资源层所提供资源包括结构化数据、非结构化（文档、音视频资料）数据、结构 化文档数据、应用服务资源等。主要用于支撑跨区域远程医疗工作开展的管理协调；支撑跨区域远程医 疗工作开展的效能建设；辅助决策开展数据统计分析服务；为国家远程医疗监管与资源服务中心与各区 域远程医疗监管与资源服务中心，以及各区域远程医疗监管与资源服务中心之间的互联互通提供信息服 务。 
5.2.4 交换与接入层 

5.2.4.1 远程医疗信息资源交换层 
包括：企业服务总线 ESB、服务集成 SMP、通用文件传输 GTP、数据集成 ETL、统一媒体控制单元 MCU。信息交换层根据业务流程，通过数据接口或消息传递与其他信息系统进行数据交换，实现信息共 享、数据上报等功能。主要用于满足临床信息跨医院、跨区域的信息交换和协同应用；用于医疗服务资 源的注册、申请、授权、管理、监控，实现基于服务的信息资源共享交换；用于满足基于卫生医疗行业 数据规范的业务信息采集，并对外部系统提供基于文件的数据交换服务；用于满足远程医疗数据仓库建 设过程中的数据采集、加工、转换处理的数据集成要求；用于满足音视频信息的跨医院、跨区域交互， 并按照平战结合要求，集成突发公共卫生事件应急指挥视频会议系统。解决医院依靠区域远程医疗监管 与资源服务中心开展远程医疗业务过程中的信息互联互通问题。 
5.2.4.2 远程医疗信息资源接入层 
5.2.4.2.1 应急指挥系统 
远程医疗信息系统与应急指挥系统对接，利用视频站点连接医院网络，提供现场和救治过程音视频 动态信息，实现突发事件应对中的信息共享与处置联动，既可使患者通过远程视频获得诊治，也可助医 护人员随时向指挥中心汇报患者的最新情况，分析任何潜在的新疾病。 
5.2.4.2.2 医疗卫生信息系统 
主要包括电子病历系统、医院信息系统、检验信息系统、临床信息系统、心电诊断系统、影像诊断 系统、病理诊断系统和其他医疗信息系统。通过远程医疗信息系统与医疗信息系统的对接，实现跨医院 之间的信息共享、业务协同。 远程医疗信息系统与区域卫生信息平台对接，提供远程医疗监管与业务服务实时信息，共享原有健 康档案和电子病历信息，使区域卫生信息平台具有对远程医疗业务的综合管理功能。 如医疗机构已经建立了数据共享的医院信息集成平台，将通过平台机制，实现与远程医疗信息系统 的对接，减少数据接口数量，实现跨医院之间的信息共享、业务协同。 
5.2.4.2.3 医疗信息采集设备 
医疗信息采集设备主要包括多参数生命体征监护仪、数字化影像设备、数字心电图机、呼吸机和其 他医疗信息采集设备，主要用于采集患者的生命体征、血糖、血压等数据。 
5.3 软件架构要求 
基本要求包括： ——远程医疗信息系统软件架构应该基于面向服务架构的思想来构建；系统采用 B/S 模式结构，根 据应用环境的不同，以网络最优化方案进行系统部署； ——符合已有的标准框架协议，采用业界协议；采用开放式标准设计，能够兼容其他医疗系统和设 备；满足今后的发展，为未来业务扩展留有充分的扩充余地； ——凡与 SOA 重用性密切相关的组件，如服务接口，必须采用成熟的技术标准规范；对还没有最后 定案的事实标准或规范，作为可选技术参考使用； ——远程医疗信息系统要求具有消息路由功能，可以具有业务流程管理、可以支持远程医疗业务流 程编排和人工参与的工作流。 
5.4 软件技术要求 
5.4.1 基本要求 
基本要求包括： ——系统应支持远程医疗服务相关的业务操作，可具有支持业务流程编排的功能； ——系统应支持与各医院信息系统的信息共享和交互，具有医疗信息和资料调阅功能； ——系统应提供管理工具，能够管理所有业务系统集成节点，监控整个远程医疗业务开展情况； ——系统应支持用户授权及认证，支持数据防篡改及隐私数据保密，支持业务流程的追踪与审计， 系统日志的记录与查看，支持消息可靠性传递及消息追踪等；系统具有很好的备份功能，满足 高可靠性需求； ——单点登录：提供对各种应用系统和数据的安全集成，用户只需登录一次就可以访问其它相关应 用系统和数据库； ——远程医疗信息系统，应提供二次开发环境，提供基础公共业务组件的封装。 
5.4.2 交互信息要求 
交互信息应支持WS 363、WS 364等国家颁布的相关卫生数据标准。 
5.5 集成能力要求 
具体要求包括： ——以 Web Service 技术作为 SOA 服务开发技术的首选技术，并要求遵循 WS-I Basic Profile 1.0 的有关指引； ——系统应支持主流的卫生信息交换国际和国内标准和规范； ——基于 Web Service 的服务的安全管理应遵循 Web Service 服务规范中 WS-Security 规范，其他 形式的服务也必须提供安全保障。 
6 系统功能 
6.1 基础功能 
6.1.1 基本要求 
基础功能应包括对患者、医疗服务人员、医疗卫生机构（科室）、医疗卫生术语的注册管理服务。 系统应对这些实体提供唯一的标识。针对各类实体形成各类注册库（如患者注册库、医疗服务人员注册 库、机构注册库、术语和字典注册库），各注册库具有管理和解决单个实体具有多个标识符问题的能力。 
6.1.2 患者注册服务 
基本功能包括： ——具备新增患者注册功能； ——具备患者信息更新功能； ——具备患者身份失效功能； ——具备患者身份合并功能； ——具备患者信息查询功能。 
6.1.3 医疗服务人员注册服务 
基本功能包括： ——具备新增医疗卫生人员注册功能； ——具备医疗卫生人员信息更新功能； 
——具备医疗卫生人员身份失效功能 ——具备医疗卫生人员身份合并功能； ——具备医疗卫生人员信息查询功能。 
6.1.4 医疗卫生机构（科室）注册 
基本功能包括： ——具备新增医疗卫生机构（科室）注册功能； ——具备医疗卫生机构（科室）信息更新功能； ——具备医疗卫生机构（科室）停用功能； ——具备医疗卫生机构（科室）信息查询功能。 
6.1.5 医疗卫生术语注册 
基本功能包括： ——具备术语和字典的批量导入导出功能； ——具备术语和字典的分类浏览功能； ——具备术语和字典的关系维护功能； ——具备术语和字典的版本管理； ——具备术语和字典的映射关系维护； ——具备向其他系统同步术语和字典功能。 
6.2 远程医疗数据资料整合功能 
6.2.1 数据采集功能 
功能包括： ——支持医疗数据资料的采集，从医疗应用系统或数据库获取数据。 ——支持按 DICOM 标准获取患者的影像资料，并进行存储、再现以及相应的后处理操作。 ——支持将病理切片转换成由完整数字图像组成的虚拟数字切片，至少包括20倍和40倍显微图像。 支持病理虚拟数字切片上传。 ——支持从电生理检查设备采集电生理数据，并进行无损的数据传输、存储和再现。电生理图支持 通过 Internet、移动网络、电话线等方式传输电生理检查数据。电生理图数据可存储为 XML、 DICOM 等通用数据格式。 ——支持床边监护仪等生命体征数据的实时传输。 ——在本规范中暂不规定与数据采集相关的服务和接口。 
6.2.2 申请功能 
基本功能包括： ——申请单提交 ——具备申请单接收功能； ——具备申请单查询功能。 
6.3 远程医疗数据资料存储服务功能 
根据远程医疗病例资料信息的分类，存储服务包括：患者基本信息存储库、电子病历信息存储库、 健康档案信息存储库、会诊信息存储库、影像数据存储库、教学资源存储库。基本功能包括： 
——具备接收文档、影像、视频数据资料功能； ——具备向索引库注册文档、影像、视频数据资料功能； ——具备向使用者提供文档、影像、视频数据资料功能。 
6.4 远程医疗数据资料管理功能 
6.4.1 数据资料管理功能 
对患者全病程档案进行管理，包括建档、注销、属地变更等。 
6.4.2 文档注册功能 
文档注册根据文档的内容维护每一个注册文档的元数据，并包括在文档库中存储的地址。文档注册 可根据文档用户的特定查询条件返回文档（集）。 
6.4.3 事件注册功能 
为实现远程医疗信息系统对病例资料信息的共享和交换，需要以远程医疗患者为单位，对患者获得 的卫生服务活动的事件信息进行注册，建立事件目录。目录中的每个条目由描述该事件的关键信息构成， 实际操作时，应该提取文档中与事件相关的元数据进行注册，同时，事件信息将被作为患者与文档之间 的关联关系，便于使用者可以通过事件的途径获取相关的文档。 
6.4.4 索引服务功能 
基本功能包括： ——具备静态文档注册功能，静态文档包括：患者的病例资料信息，以及事件信息所涉及的文档目 录及摘要信息； ——支持根据医疗事件或患者信息查询、展示相关医疗静态文档索引的功能。 
6.5 远程医疗数据资料调阅功能 
用于对文档、影像图片、病历文件等各类数据的浏览查阅。 
6.5.1 数据组装服务功能 
组装服务通过调用不同的系统组件生成多个患者数据的结果集，并把这些结果集组合成一定输出格 式。 
6.5.2 数据标准化服务功能 
标准化服务把特定的输入串修改成符合标准化的编码串。数据的格式和实质含义都可以转换。 
6.5.3 数据访问服务功能 
数据访问服务提供对单个患者病例资料文档或文档集的数据的查询和访问服务。 
6.6 远程医疗结果信息反馈功能 
基本功能包括： ——具备结果信息接收功能； ——具备结果信息查询功能。 
6.7 信息安全及隐私保护功能 
6.7.1 用户管理及授权服务 
基本功能包括： ——具备用户角色创建功能； ——具备用户授权功能； ——具备访问规则定制功能，并按规则访问数据的功能； ——具备记录用户权限操作日志功能。 
6.7.2 信息安全服务 
远程医疗信息系统应提供统一的信息安全服务，用户在信息交互时系统通过认证、授权等方式保证 信息安全。 
6.7.3 隐私保护服务 
远程医疗信息系统应提供患者隐私数据保护服务。 
6.7.4 审计追踪服务 
远程医疗信息系统应提供记录所有信息访问或信息更新操作日志，并提供数据的审计及操作追踪服 务。 
7 信息资源规范 
7.1 基础信息库 
7.1.1 基本要求 
远程医疗信息系统的基础信息库包括患者基本信息、医疗卫生服务人员信息、医疗机构（科室）信 息、医疗卫生术语。基础信息库由远程医疗信息系统的注册服务产生，为这些实体提供统一、完整、准 确的基本信息，并为这些实体提供唯一的标识。 
7.1.2 患者基本信息库 
患者基本信息遵循WS 445，包括服务对象标识、人口学、联系人、地址、通信、医保等数据元。 
7.1.3 医疗卫生服务人员信息库 
医疗卫生服务人员注册信息遵循WS 445，包括卫生服务者数据元。 
7.1.4 医疗卫生机构（科室）信息库 
医疗卫生机构（科室）信息遵循WS 445，包括卫生服务机构数据元。 
7.1.5 医疗卫生术语和字典库 
远程医疗信息系统的术语和字典库遵循WS 363、WS 364、WS 445等国家颁布的相关卫生数据标准， 参考国际卫生行业相关数据标准。 
7.2 远程医疗数据资料库 
7.2.1 文档存储库 
文档存储库责将基于活动的、符合标准的临床文档，以明晰、安全和持久的方式进行存储。文档存 储库内容遵循WS 365、WS 445。 文档存储库依据临床文档的内容类型，选择恰当的文档注册对这些文档进行注册，并对文档检索的 请求作出响应。电子病历共享文档遵循WS/T 500。 
7.2.2 影像存储库 
医疗影像存储要求完全遵循目前国际通用的DICOM3.0、HL7等国际标准，符合IHE框架，整个系统 具有高安全性、高可靠性、较高的兼容性和可持续扩展性。实现影像的接收、中转、打印，支持影像无 损与有损压缩存储模式。 
7.2.3 视频存储库 
视频存储库（包括图像存储与后处理，病例库的报告及管理）必须完全基于WEB架构，以方便日后 维护及远程教育。 在数据管理方面应具备较大的伸缩性，它可以集中管理远程教育工程中的所有素材，也可以将素材 按类型或按学科划分开来，单独进行管理，可将大素材库切分为多个小素材库。 
7.2.4 文档注册库 
文档注册库应提供文档存储库的文档索引信息，内容遵循原卫生部《电子病历基本架构与数据标准 （试行）》中文档信息模型中文档头的H.01文档标示、H.02服务对象标示、H.03人口学、H.04联系人、 H.05地址、H.06通讯、H.07医保、H.08卫生服务机构、H.09卫生服务者、H.10事件摘要数据组的规定。
 文档注册库按照临床文档的内容类型，可以存在一组不同类型的注册库，被文档存储库在临床文档 存储时使用。 
8 基础设施规范 
8.1 远程医疗网络 
8.1.1 网络建设原则如下： 
——可靠性:网络系统的稳定可靠是应用系统正常运行的关键保证，在网络设计中应选用已规模商 用的网络产品，合理设计网络架构，制订可靠的网络备份策略，保证网络具有故障自愈的能力， 最大限度地支持系统的正常运行； ——开放性:支持国际上通用标准的网络协议、国际标准的大型的动态路由协议等开放协议（如 IPV6 等），有利于以保证与其它网络之间的平滑连接互通，以及将来网络的扩展； ——安全性:通过设备机制及组网方案提高网络整体的安全性； ——可管理性:对网络实行集中监测、分权管理，并统一分配带宽资源。选用先进的网络管理平台， 具有对设备、端口等的管理、流量统计分析，及可提供故障自动报警。 
8.1.2 音视频数据网络质量及 QoS 要求如下： 
——网络时延小于 50ms； ——Jitter 尽可能低，不大于 20ms 最佳； ——丢包不大于 5%。 
8.2 远程医疗视讯系统 
远程音视频通讯功能需遵从H.323、SIP基本视频通讯协议实现。系统需具备视讯业务管理功能、视 频多点交换单元功能、音视频接入单元功能、录播功能。 远程医疗系统对音视频会议系统的性能质量需满足以下章节描述的要求，以保障不同音视频系统间 的互联互通和远程会诊的质量。 
8.2.1 业务管理系统技术要求 
——总体技术要求：  统一通讯管理系统支持 B/S 架构，实现设备管理，注册认证，会议管理，会议控制，报表 统计等功能；  GK 服务器要求：支持大容量的节点注册，实现设备的注册、鉴权；  网络要求：支持 IPv4 协议栈，建议支持 IPv6 协议栈，方便后续扩展。  用户权限管理要求：  需支持按组织结构管理用户权限，用户权限可以配置；  需支持分级分权管理，系统权限和资源按照企业组织结构树状管理，同一台 MCU 或者会场 能够分配给多个组织使用。 ——设备管理要求：  设备管理容量：平台可扩容管理多个设备及会场；  需支持设备（MCU 和会场）按组织结构方式管理；  支持管理主流视讯终端设备，并支持远程添加并管理 MCU 和终端设备，能够查看终端或者 MCU 的品牌型号、GK 注册状态、SIP 注册状态、MAC 地址，终端的视频能力，软件版本号 等信息，实时远程修改设备配置，例如远程开启、关闭 GK 注册，远程修改 H.323ID、E.164 号码、DNS 服务器地址等；  支持设备自动发现功能，设备（MCU 和终端）加入系统后自动被管理平台识别，发现设备 后可对设备进行信息查看和配置，并且支持对被管理设备的配置备份和远程恢复；  支持系统告警管理，实现远程查看被管理设备（终端和 MCU 等）告警信息，并且针对告警 类型进行分类，快速获取被管理设备的运行状态；  支持对被管理设备的日志进行远程查看；  支持对录播服务器设备进行远程管理和远程控制。 
8.2.2 MCU 技术要求 
——总体技术要求：  支持可扩容架构设计：采用嵌入式操作系统；能够通过增加板卡实现系统容量的平滑升级； 设备每块板卡上具备至少 2 路 1000Mbps RJ-45 电口和 2 路光纤接口，支持 IPV4，建议支 持 IPV6，方便后面扩展；  支持标清、高清、高标清混合会议和多点会议与速率适配: 支持每个参会终端均以不同的 协议（H.323/SIP）、不同的带宽（64K-8Mbps）、不同的音视频编码(H.263/H.264 等， G.722/G.711/AAC-LD 等)、不同的清晰度（CIF/4CIF/720P 30fps、60fps/1080P 30fps、 60fps）同时加入到一个会议中，且同时能够支持多组会议，会议组数不受混网、混速数 量的限制；  系统容量：可以通过人工指定可以将 MCU 的端口资源根据视频清晰度任意分配，达到资源 利用最大化，MCU 端口资源分配不用重启 MCU 设备；  支持多通道级联:下级 MCU 多个会场能够通过多个独立的视频通道传到上级 MCU。 ——音视频技术要求： 
 视频要求：支持国际标准视频协议包括：ITU-T H.261、H.263、H.263+、H.264 Basic Profile、 H.264 High Profile、H.264 SVC 视频协议。支持 1080P60 帧、1080P30 帧、720P60 帧、 720P30 帧，并向下兼容 4CIF、CIF 图像格式；  音频要求：支持国际标准音频协议包括：ITU-T G.711a、G.711u、G.722、G.728、G.722.1C、 G.729、iLBC 音频协议,支持具备 20KHZ 频响的宽频语音编码 G.719、AAC_LD、HWA_LD 音 频协议, 支持一个会场同时传输两路音频区分左右声道，实现立体声效果；  支持多画面：支持多种多画面类型，并支持多画面模式切换。支持自定义参会会场在多画 面中的显示位置。支持每端口多画面，支持参会的终端设备通过遥控器按键选择自己会场 所需的多画面组合方式，并且不影响其他会场清晰度、观看多画面方式。支持将辅流加入 多画面中，以便让不支持 H.239 的终端设备收到辅流信息；  支持双流：支持标准 H.239 双流和 BFCP 双流，支持静态双流和动态双流，辅流带宽可以 按需要手工设置，辅流最大支持 1080P 60fps 图像格式。支持辅流适配功能，在一个高清、 标清混合的会议中，能够实现不同视频解码能力的终端接收到不同清晰度的辅流信息，保 证不会因为某个参会会场辅流接收能力较低而影响其他会场。 ——安全与稳定技术要求：  支持主控板和媒体板热备份，且主控板在倒换过程中不影响正在召开的会议，支持双电源 冗余备份；  设备支持 H.235(AES256)、SRTP、TLS、HTTPS、SSH、SNMP V3 等媒体、信令、管理加密， 提供身份验证与加密通讯的安全通道，防止用户被仿冒，保护会议信息在传送过程中不被 截获翻译，全面保证会议信息安全；  MCU 设备具备较强的抗丢包能力，在 10% 丢包下，语音连续清晰，视频清晰流畅，基本感 觉不到丢包影响；在 20% 丢包下，语音较清晰连续，视频偶有卡顿。 
8.2.3 高清会议终端技术要求 
——总体技术要求：  建议采用嵌入式操作系统，不建议采用 PC、工控机架构；  建议提供多路高清视频输入、多路高清视频输出接口，支持 HDMI 和 VGA 接口；  建议支持多路音频输入和多路音频输出接口，具有标准的卡农头麦克风接口和 SPDIF 数字 音频接口； ——音视频技术要求：  视频支持 H.263、H.263+、H.264、H.264HP、H.264SVC 图像编码协议。图像格式支持 1080P50/60 帧、1080P25/30 帧、1080i50/60 帧、720P50/ 60 帧、720 P25/30 帧、4CIF， CIF；  音频支持 G.711、G.722、G.722.1、G.722.1C、G.728、G.719、G.729A、AAC-LD 等音频协 议，并且支持不少于三种 20KHZ 以上的宽频音频协议，支持双声道立体声功能；  支持标准 H323 下 H239 协议，支持标准 SIP 协议下 BFCP，支持主辅流达到 1080P 效果， 最高在主流 1080P60 帧的情况下，辅流支持 1080P60 帧；  支持召开点对点会议时，同时接收和发送辅流。 ——网络接入技术要求：  应具备良好的网络适应性，最大 20%网络丢包下,图像流畅、清晰、无卡顿、无马赛克现 象，确保会议正常进行； 
 终端应支持 768Kbps 会议带宽下，召开 1080P60 帧高清会议，功能正常，音视频流畅； 512Kbps 会议带宽下，召开 1080P30 帧高清会议，功能正常，音视频流畅；384Kbps 会议 带宽下，召开 720P30 帧高清会议，功能正常，音视频流畅； ——系统功能与安全要求：  支持在 H.323 协议下，使用 H.235 信令加密；支持在 SIP 下，TLS、SRTP 加密；支持 AES 媒体流加密算法；  支持 LDAP 地址本，能够直接从地址本服务器下载、更新地址本条目，支持 LDAP 访问认证 和加密，同时支持网络地址本同步功能，通过地址本服务器更新联系人目录。 ——相关设备要求：  数字麦克风，支持 360 度全向拾音，最大拾音距离达到 5 米以上；  支持自适应回声抵消，自动增益控制，自动噪声摄制；  采样率不小于 48KHZ；  支持通过麦克风的触摸面板进行闭音和开音操作。 
8.2.4 网络录播系统技术要求 
网络录播系统支持以下技术要求： ——网络录播服务器支持 B/S 架构，可以通过 WEB 访问，实现点播、直播功能； ——系统支持 IPV4 协议栈，支持 IPv4 单独组网，建议支持 IPv6 单独组网或者 IPv4/IPv6 混合组 网，方便后续扩容； ——网络录播系统最大支持同时 30 组 1080P30 会议录制； ——支持同时录制一路高清和一路标清图像，各分支节点根据网络状态选择高清或标清点播观看；
 ——系统支持会议的双流录制，辅流录制支持 1920*1080 高清录制； ——支持单点、点对点和多点会议的录制； ——支持对录制会议的过程进行控制，包括：录制、暂停、停止、选择录制源； ——支持 PC、IOS、Android 手机、PAD 平台直播和点播录播服务器视频； ——支持浏览器免插件直播和点播； ——支持在 PC 浏览器上预览录播图片和文字索引； ——支持直播、点播过程中主辅流和声音同步播放； ——PC 浏览器直播、点播时，支持对画面布局进行切换； ——浏览器进行点播时，用户可以对点播内容进行暂停（播放）、定位、停止、全屏（取消全屏）、 音量调节等操作。 
8.2.5 视频会议系统互联互通技术要求 
支持以下技术规格： ——视频支持 H.263、H.263+、H.264、H.264HP、H.264SVC 图像编码协议。图像格式支持 1080P50/60 帧、1080P25/30 帧、1080i50/60 帧、720P50/ 60 帧、720 P25/30 帧、4CIF， CIF； ——音频支持 G.711、G.722、G.722.1、G.722.1C、G.728、G.719、G.729A、AAC-LD 等音频协议， 并且支持不少于三种 20KHZ 以上的宽频音频协议，支持双声道立体声功能； ——支持在 H.323 协议下，使用 H.235 信令加密；支持在 SIP 下，TLS、SRTP 加密；支持 AES 媒体 流加密算法； ——支持标准 H323 下 H239 协议，支持标准 SIP 协议下 BFCP，支持主辅流达到 1080P 效果，最高 在主流 1080P60 帧的情况下，辅流支持 1080P60 帧。 
8.3 通用 IT 基础设施 
8.3.1 通用基础软件 
遵循WS/T 447-2014中8.2。 
8.3.2 通用硬件 
遵循WS/T 447-2014中8.3。 
8.3.3 机房环境 
遵循国内标准和规范，并参考国际上现有的标准和规范。 
9 安全规范 
9.1 安全设计原则 
遵循WS/T 447-2014中9.1章节。远程医疗信息系统安全等级保护的安全级别设定，参照同层级区域 卫生信息平台安全等保级别。 
9.2 物理安全 
遵循WS/T 447-2014中9.3.1章节。 
9.3 系统安全 
遵循WS/T 447-2014中9.3.3章节。 
9.4 网络安全 
9.4.1 网络结构安全 
网络结构安全要求如下： ——网络各个部分的带宽要保证接入网络和核心网络满足业务高峰期需要； ——按照业务系统服务的重要次序定义带宽分配的优先级，在网络拥堵时优先保障重要主机； ——根据各部门的工作职能、重要性和所涉及信息的重要程度等因素，划分不同的网段或 VLAN； ——各类网络设备，包括路由器、交换机、MCU 等设备应具有电信入网证； ——网络关键设备，如核心交换、防火墙、应用服务器、安全接入设备、数据库服务等采用双机热 备技术，使整个网络业务处理能力具备冗余空间。 
9.4.2 网络隔离 
网络隔离要求如下： ——应通过网络分区，明确不同网络区域之间的安全关系，在不同中心之间数据共享关口设置安全 设备； ——应采用防火墙隔离各安全区域； ——应用系统间应具备访问控制功能。 
9.4.3 网络接入 
远程医疗信息系统数据中心的出口应部署Anti-DDoS进行安全防护，为保证业务不中断，应具有秒 级的防护响应能力；应具备100+种DDoS攻击类型防御，包括IPv6攻击防护，对于攻击零误判。 
9.4.4 入侵检测与防御 
入侵检测与防御要求如下 ——应具备持续更新的特征库， 保障 99%以上的检测率； ——应支持对关键路径应支持深度报文检测，支持不小于 1000 多种应用协议识别； ——应支持一体化策略的配置方式，统一策略配置入口； ——应支持 IPV6 技术，方便系统以后的扩展。 
9.4.5 网络传输 
偏远地区或县级医疗机构通过Internet接入市级数据中心需要保证关键数据在传输过程中不被监 听或者篡改。 网络传输要求如下： ——数据传输需要采用 IPSecVPN/SSL VPN 加密技术传输； ——应支持国密算法保证远端医疗机构或移动终端的可信接入； ——安全接入网关应支持双机热备。 
9.4.6 网络安全审计 
网络安全审计要求如下： ——应对外发文件及内容进行审计记录，通过对审计数据库的查询、统计，追踪可疑的泄密行为；
 ——应依据预置或用户定义敏感数据关键字，对 Web、IM、Mail 的内容进行检测，防止包含关键信 息的数据流出企业； ——应保留行为日志，响应公安部相关要求，防止法律风险；  ——应定位违规行为，发现潜在的不良用户，预防信誉风险。 
9.5 应用安全 
遵循WS/T 447-2014中9.3.5章节。 
9.6 数据安全 
9.6.1 数据采集安全保障 
数据采集安全保障要求如下： ——数据采集应确保系统采集数据的真伪性，具有辨别数据伪造的能力； ——应采用统一的数据采集通道确保医疗信息资源数据的采集安全； ——应对医疗信息资源进行安全分级，指定不同的采集手段，对不同级别的医疗信息资源进行采集。
 
9.6.2 数据存储 
数据存储要求如下： ——应采用碎片化分布式离散存储技术保存医疗信息资源，本地应有大于 2 份的数据副本，数据应 强制分片后存储于不同机架上； ——应在进行存储资源回收时删除存储的元信息，对逻辑卷的每一个物理比特位进行清“零”覆写， 保证不能通过软件方式恢复其原有数据； 
——应使用 SSL 实现端到端传输层加密，采用对称加密密钥实现对用户的签名验证和存储请求加 密、采用 MD5 算法实现对消息体的加密； ——应创建数据存储区域隔离，不同等级的安全数据采用不同的防护措施进行数据隔离； ——应提供对于数据存储访问的权限控制；创建相应的访问制度和设定专门人员管理数据存储权限；
 ——存储产品应支持自主可控、安全可靠的要求,并通过中国信息安全测评中心 EAL 评测。 
9.6.3 数据传输 
数据传输要求如下： ——应采用加密或其他有效措施实现虚拟机镜像文件、系统管理数据、鉴别信息和重要业务数据传 输保密性； ——应能够检测到虚拟机镜像文件、系统管理数据、鉴别信息和重要业务数据在传输过程中完整性 受到破坏，并在检测到完整性错误时采取必要的恢复措施； ——应在业务数据、控制数据及管理数据的传输通道上都有冗余保护，各个通道之间的相互隔离， 并单独完成故障检测、修复和隔离。 
9.6.4 数据的删除 
数据的删除要求如下： ——应能够提供手段协助清除因数据在不同中心间迁移、业务终止、自然灾害、合同终止等遗留的 数据； ——应保证磁盘存储空间被释放或再分配给其他用户前得到完全清除； ——应保证主机内存被释放前得到完全释放； ——应提供手段清除数据的所有副本； ——应提供技术手段禁止被销毁数据的恢复。 
9.6.5 数据的备份与恢复安全 
数据的备份与恢复安全要求如下： ——应提供数据本地备份与恢复功能，完全数据备份至少每天一次，备份介质场外存放； ——应提供异地实时备份功能，利用通信网络将数据实时备份至灾难备份中心； ——应提供快速的虚拟机恢复能力； ——应支持基于磁盘的备份与恢复。 
9.7 视讯系统安全 
视讯系统安全要求如下： ——信令媒体流加密应提供端到端、端到系统侧、多点会诊等全网全业务信令； ——整个注册过程中应采用 H.235 信令加密或 TLS 加密方式，未经过认证的系统不能接入到当前的 远程医疗系统； ——专家侧主动召集多方远程会诊时，应提供经过系统验证的账号和密码才能完成； ——应设立主持人/主席控制机制，提供口令验证机制，其他会诊参与方没有获取口令的情况下， 不能对会议过程进行控制； ——跨局域网之间的网络连接应该提供基于 VPN 或者固定端口方式穿墙； ——应提供数据配置安全功能，支持为每个终端设置数据配置口令； ——应提供远程 Telnet 、WEB Server 功能，同时为每种业务分配用户名和密码； ——应支持业务接口板（含主控板和业务板）1＋1 的热备份，支持 IP 网口的 1＋1 的热备份，网口业务切换时不影响正在召开的会议，支持电源模块的 1+1 备份。 
10 性能要求 
10.1 最小接入系统数 
10.2 最小并发用户数 。 
10.3 基础服务平均响应时间 
10.4 远程医疗数据资料整合服务平均响应时间 
10.5 远程医疗数据资料服务平均响应时间 
 

来源：https://blog.csdn.net/huang714/article/details/114060552
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！