电子病历互联互通接口规范专家共识（2025版）

电子病历互联互通接口规范专家共识（2025版）随着信息技术的飞速发展以及医疗健康大数据应用的不断深入，电子病历作为医疗信息系统的核心载体，其互联互通已成为提升医疗服务质量、优化医疗资源配置、实现区域医疗协同以及支撑临床科研与公共卫生决策的基石。为适应新形势下医疗信息化建设的需要，进一步规范电子病历信息的互联互通接口设计，确保数据交换的安全性、标准化与高可用性，特制定本专家共识。本共识旨在为各级医疗机构、软件开发商及系统集成商提供统一的技术指引，推动跨机构、跨区域医疗数据的无缝流动与共享。第一章总则与建设原则1.1背景与目标当前，我国医疗信息化已从单纯的业务流程数字化向数据驱动的智慧化阶段转型。然而，不同厂商、不同时期建设的医疗信息系统之间依然存在“信息孤岛”现象，数据标准不一、接口规范混乱等问题严重制约了医疗大数据的价值挖掘。本共识的核心目标是建立一套通用、开放、扩展性强的电子病历互联互通接口规范，实现电子病历数据在医疗机构内部及区域间的语义互操作性，确保数据在传输、存储和使用过程中的完整性、一致性和安全性。1.2建设原则电子病历互联互通接口建设应遵循以下核心原则：1.标准化优先原则：严格遵循国家卫生健康委员会及国际通用的医疗卫生信息标准，包括但不限于HL7V3/CDA、HL7FHIR、DICOM、ICD-10/11、CPT等，确保数据格式的统一。2.平台中立性原则：接口设计应独立于特定的硬件平台、操作系统和数据库系统，采用通用的网络协议（如HTTP/HTTPS、RESTful架构），降低系统耦合度。3.安全性与隐私保护原则：必须建立完善的数据加密、身份认证、访问控制及审计追踪机制，严格遵循国家数据安全法和个人信息保护法要求，确保患者隐私不被泄露。4.向前兼容与可扩展性原则：接口规范应具备良好的版本管理机制，在支持现有业务的基础上，预留扩展接口，以适应未来业务逻辑的变更和新数据的接入。5.以患者为中心原则：所有数据交换的索引和归集应以患者主索引（EMPI）为核心，确保同一患者在不同系统、不同机构中的医疗数据能够准确关联。第二章总体架构体系2.1逻辑架构电子病历互联互通接口的逻辑架构应分为四层：数据资源层、数据交换服务层、接口服务层和应用层。数据资源层：包含医院各业务系统（HIS、EMR、LIS、PACS等）的原始数据，经过ETL清洗转换后形成标准化的数据存储。数据交换服务层：负责数据的路由、转换、协议适配及消息队列管理，是实现互联互通的核心引擎。该层应支持同步与异步两种交换模式。接口服务层：对外提供标准的API接口（如RESTfulAPI、WebService），封装了身份认证、权限控制、流量控制等非功能性需求，向应用层提供统一的服务视图。应用层：包括区域卫生信息平台、医院信息平台、临床决策支持系统、科研大数据平台等具体业务应用，通过调用接口层获取数据服务。2.2交互模式根据业务场景的不同，接口交互模式主要分为以下三类：1.实时查询模式：适用于医生在诊疗过程中急需获取患者既往病史、检查检验结果等场景。采用请求/响应机制，要求低延迟、高并发。2.批量数据交换模式：适用于区域数据归集、夜间接入等非实时场景。采用文件传输或批量插入方式，需支持断点续传和完整性校验。3.消息订阅与推送模式：适用于院前急救、转诊通知、危急值报警等主动通知场景。基于发布/订阅模型，确保消息的实时送达。第三章数据元与术语标准规范3.1数据元标准化为实现数据的语义互操作，必须对核心数据元进行严格定义。每一个数据元应包含标识符、名称、类型、长度、值域范围等属性。患者标识类：包括患者身份证号、医保卡号、就诊卡号、跨机构主索引号。其中，跨机构主索引号应由区域卫生信息平台统一分配，作为患者身份唯一识别依据。医疗卫生机构类：机构名称、组织机构代码、医疗机构等级、行政区划代码等。医疗卫生人员类：医务人员姓名、执业证书编码、科室代码、职务/职称等。诊疗活动类：门诊/住院号、就诊时间、就诊类型、诊断编码（ICD-10/11）、手术操作编码（ICD-9-CM-3）等。接口传输中，所有日期时间格式必须统一采用ISO8601标准（YYYY-MM-DDTHH:mm:ss+TimeZone）。3.2术语与编码体系术语映射是互联互通的核心难点。接口规范应明确采用国家标准或行业标准作为基础值域，对于各系统私有代码，必须提供与标准代码的映射表。诊断编码：统一使用国家临床版ICD-10或ICD-11，鼓励向SNOMEDCT（系统医学临床术语集）映射，以支持高精度的语义检索。检验检查编码：推荐使用LOINC（观测指标标识符逻辑命名与编码系统）作为检验项目的标准编码，同时兼容当地卫健委发布的检验项目字典。药品物资编码：统一采用国家医保药品编码，确保药品信息在处方流转和医保结算中的准确性。科室与人员编码：遵循WS/T448等卫生信息相关标准。第四章接口交互技术规范4.1通信协议推荐使用HTTP/1.1或HTTP/2作为底层传输协议，基于RESTful架构风格设计接口。对于对性能要求极高的内部系统间调用，可采用gRPC或二进制协议，但需提供标准化的网关转换层。所有数据传输必须通过TLS1.2或更高版本加密，防止数据在传输过程中被窃听或篡改。4.2消息格式数据交换的报文格式推荐采用JSON（JavaScriptObjectNotation）和XML两种格式，其中JSON作为首选格式，以降低解析开销并提高可读性。统一响应结构：无论业务成功与否，接口返回的数据包必须遵循统一的数据结构，包含状态码、消息体、时间戳及签名信息。资源导向设计：借鉴FHIR（FastHealthcareInteroperabilityResources）标准，将实体抽象为“资源”（Resource），如Patient资源、Observation资源、MedicationRequest资源。每个资源通过URL进行唯一寻址。4.3身份认证与鉴权机制为确保接口调用的安全性，必须建立严格的准入机制。1.身份认证：推荐采用OAuth2.0（OpenIDConnect）标准协议。调用方需先通过授权服务器获取AccessToken，Token应包含有效期、授权范围及调用方身份信息。2.签名机制：对于敏感数据操作（如处方开具、病历修改），除Token验证外，还需对请求参数进行数字签名（如RSA-SHA256），服务端需验证签名的正确性以确保请求未被篡改。3.时间戳防重放：请求报文中需包含发送时间戳，服务端需设定时间容差窗口（如5分钟），拒绝处理过期请求，防止重放攻击。4.4异常处理与日志系统应定义详尽的错误代码表，覆盖参数校验错误、权限不足、业务逻辑错误、系统内部错误等场景。错误代码规范：采用6位数字编码，前两位代表模块分类，中间两位代表错误类型，后两位为具体序号。日志审计：所有接口调用请求与响应必须留痕，日志内容应包括调用方IP、请求URI、参数内容、处理耗时、响应状态码等。日志数据需定期归档，保存时间不少于6个月，并支持快速检索与分析。第五章业务功能域接口规范5.1患者信息域（PatientIdentityManagement）患者信息是所有医疗数据的关联主键。患者索引查询：通过身份证号、姓名+手机号等组合条件检索患者基本信息及跨机构主索引ID。接口需支持模糊查询与精确匹配。患者信息注册与更新：当患者首次就诊或信息变更时，系统应触发注册或更新请求。需支持增量更新，避免覆盖非本机构维护的原始数据。跨机构身份匹配：提供基于概率匹配算法的接口，用于在数据归集时自动识别不同机构中的同一患者。5.2门诊病历域（OutpatientMedicalRecord）门诊病历文档获取：支持按照就诊流水号、时间段获取历次门诊病历摘要（主诉、现病史、既往史、体格检查、诊断等）。处方信息获取：获取处方明细，包括药品名称、规格、剂量、用法用量、频次、总量、开具医生及发药状态。数据结构应符合电子病历共享文档规范。门诊流程流转：包括挂号、分诊、接诊、缴费、取药、治疗等节点的状态查询接口，支持外部系统实时追踪患者就诊轨迹。5.3住院病历域（InpatientMedicalRecord）住院病历数据量大且逻辑复杂，接口设计需分层次提供。病案首页数据接口：病案首页是住院数据的精华，接口需提供涵盖患者基本信息、诊断信息、手术信息、费用信息等结构化数据的提取。住院病程记录：提供入院记录、首次病程、日常病程、手术记录、出院记录等文档的流式读取或分页读取接口。文档应以HTML或CDA标准格式返回。医嘱信息接口：涵盖长期医嘱、临时医嘱的录入、作废、执行与停止操作。医嘱接口需具备高并发处理能力，并保证医嘱执行的原子性。5.4检验检查域（Laboratory&Radiology）申请单与报告单同步：支持检验检查申请单的推送及报告结果的回传。报告内容包括项目编码、项目名称、结果值、单位、参考范围、异常标识及图文报告的访问链接。危急值报告接口：建立高优先级的实时推送通道，当产生危急值时，立即通知相关临床医生工作站，并需接收阅知确认回执，形成闭环管理。影像数据访问：不直接传输DICOM原始文件，而是返回影像在PACS服务器中的StudyInstanceUID、SeriesInstanceUID及访问地址（WADO-RS/URI），由请求方根据权限调阅。5.5用域与护理域医嘱执行记录：提供护士执行医嘱的时间、执行人、途径（口服、静脉注射等）及患者反馈信息的记录接口。护理评估单：支持生命体征、疼痛评分、跌倒风险评估、Braden评分等护理数据的结构化采集与查询。第六章数据交换安全与隐私保护6.1数据脱敏与最小化原则接口数据输出应严格遵循“最小必要原则”。对于非直接诊疗必需的敏感信息（如患者家庭住址、联系电话、身份证号），在向非授权第三方或科研平台提供数据时，必须进行去标识化或匿名化处理。分级脱敏策略：根据调用方的权限等级，返回不同粒度的数据。例如，科研分析视图仅包含年龄（而非出生日期）、区域（而非具体住址）。动态脱敏：在数据输出瞬间进行脱敏转换，确保数据库中原始数据与接口展示数据的物理隔离。6.2全链路审计监控构建全链路的审计体系，对每一次数据访问行为进行记录、分析和告警。行为分析：基于大数据分析技术，识别异常的批量下载、非工作时间高频访问等潜在违规行为，并触发阻断机制。区块链存证：建议引入区块链技术，对关键诊疗数据的跨机构流转哈希值进行上链存证，确保数据流转过程可追溯、不可篡改，为医疗纠纷定责提供依据。6.3接口防护部署API网关作为统一入口，提供流量控制、熔断降级、防SQL注入、防XSS攻击等安全防护功能。针对高频查询接口实施严格的速率限制，防止恶意刷接口导致系统瘫痪。第七章接口性能与运维规范7.1性能指标接口服务应满足以下关键性能指标（KPI）：响应时间：常规查询接口平均响应时间应小于200毫秒，复杂文档获取接口响应时间应小于1秒。并发能力：核心业务接口应支持至少1000TPS（每秒事务数）以上的并发处理能力，且在高负载下CPU占用率不超过80%。可用性：接口服务年度可用性应达到99.9%以上，即全年不可用时间应少于8.76小时。7.2版本控制策略接口版本管理是维护系统稳定性的关键。URL版本控制：在API路径中包含版本号，如`/api/v1/patient/{id}`。兼容性原则：新版本发布时，旧版本应在通知期（如6个月）内保持稳定运行，避免客户端因服务端升级导致业务中断。弃用通知：当计划弃用某个接口时，必须在响应头中包含`Deprecated`字段，并在接口文档中显著标注替代方案。7.3健康检查与运维监控接口服务必须提供标准的健康检查接口（如`/health`或`/status`），返回服务器的存活状态、数据库连接状态及关键依赖服务的连接情况。监控指标：实时监控QPS、成功率、平均延迟、P99延迟等关键指标。告警机制：设定合理的告警阈值，一旦错误率超过0.1%或响应时间超过阈值，立即通过短信、邮件等方式通知运维人员。第八章互联互通测评与验收8.1测试环境与数据准备为确保接口符合本共识规范，验收方应搭建独立的测试环境，并准备不少于5家不同厂商系统产生的模拟数据集，覆盖内、外、妇、儿等主要临床科室，以及常见病种和标准数据集。8.2测试用例与自动化测试制定详尽的接口测试用例集，覆盖功能性测试、安全性测试、性能测试及异常场景测试。自动化测试工具：鼓励使用Postman、JMeter或自主研发的自动化测试平台，编写脚本对接口进行批量回归测试，验证参数校验、数据格式、业务逻辑的正确性。一致性测试：重点测试数据元定义是否符合WS445等国家标准，术语编码是否映射正确，数据格式是否符合JSONSchema定义。8.3评分与认证建立统一的接口合规性评分体系。评分维度包括标准符合度（40%）、功能完整性（30%）、安全合规性（20%）、性能表现（10%）。总分超过80分且无关键缺陷（如高危安全漏洞、核心数据缺失）方可视为通过互联互通接口认证。第九章附则与技术演进9.1云原生与微服务适配随着医疗云架构的普及，接口规范应逐步向云原生架构演进。支持容器化部署，利用服务网格（ServiceMesh）技术治理微服务间的通信，实现流量管理、负载均衡和服务间认证的透明化。9.2人工智能赋能接口未来接口规范应考虑AI辅助诊断的需求，提供标准化的数据输入输出通道，支持医学影像、生理波形等非结构化数据的标准化标注与传输，为AI模型的多中心训练与部署提供数据底座。9.3解释权与修订本共识由相关医疗信息化专家委员会负责解释。随着国家标准的更新及技术的演进，专家组将定期对本共识进行修订和完善，原则上每两年进行一次全面评估。附录A：接口响应状态码定义表状态码含义说明处理建议200OK请求成功，数据正常返回业务正常处理400BadRequest请求参数错误、参数类型不匹配或缺失必填项检查请求报文格式，修正参数后重试401Unauthorized未授权，Token无效或过期重新获取Token后发起请求403Forbidden禁止访问，调用方无权限访问该资源核对申请的权限范围，联系管理员授权404NotFound请求的资源不存在（如患者ID不存在）检查请求URL及资源ID是否正确409Conflict资源冲突，如重复创建已存在的患者检查业务逻辑，执行查询或更新操作429TooManyRequests超过接口调用频率限制降低调用频率，等待时间窗口重置500InternalServerError服务器内部未知错误检查服务端日志，联系技术支持503ServiceUnavailable服务不可用，通常因维护或过载稍后重试或查看系统维护公告附录B：常用FHIR资源映射示例表中文数据集名称推荐FHIR资源类型核心字段映射说明备注患者基本信息Patientidentifier(身份证号/医保卡),name,birthDate,gender,telecom必须包含EMPI扩展标识就诊记录Encounteridentifier(就诊流水号),class(门诊/住院),type(就诊类型),period(起止时间),serviceProvider(就诊机构)关联Patient资源诊断信息Conditionsubject(患者),code(诊断编码ICD/SNOMED),clinicalStatus(临床状态),verificationStatus(验证状态),recordedDate(确诊时间)可作为Encounter的子资源检验结果Observationsubject(患者),code(检验项目LOINC),valueQuantity(结果值),