Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/TS 27790:2009 — 健康信息学——文档注册框架
ISO/TS 27790:2009 | 医疗文档注册标准
ISO/TS 27790:2009 标准概述
ISO/TS 27790:2009《健康信息学——文档注册框架》定义了一种用于在分布式系统间注册、发现和检索医疗文档的参考架构。该框架基于 ebXML 注册信息模型（ebRIM），并与 IHE 跨企业文档共享（XDS.b）集成配置文件协调一致。它为世界各地的许多国家和区域健康信息交换提供了骨干架构，使临床医生能够发现患者文档，无论这些文档最初在何处创建。该标准由 ISO/TC 215 制定，解决了医疗文档往往分散在多个独立系统中——医院 A 的 EHR、专科医生 B 的诊所系统、药房 C 的配药记录——而临床医生在护理点没有简单方法发现给定患者所有相关文档的根本挑战。
如果您正在设计区域健康信息交换系统，ISO/TS 27790:2009 结合 IHE XDS.b 配置文件是当前最成熟、部署最广泛的架构模式。超过 20 个国家已采用此框架作为其国家电子健康基础设施的基础。
文档注册框架将注册功能（元数据管理和文档发现）与存储功能（文档存储和检索）分离开来。这种分离允许各组织在维护本地存储库的同时参与联邦注册网络。注册库存储关于每份文档的标准化元数据——包括患者标识符、文档类型、作者、医疗机构、服务日期和保密级别——并在响应查询时返回存储库位置。重要的是，注册库不存储实际文档内容，仅存储元数据，这简化了安全和隐私合规性（注册库本身不包含临床敏感数据，只包含指向数据存储位置的指针）。
该框架还定义了一个提交集概念，用于对来自单次就诊或护理事件的相关文档进行分组。例如，住院期间生成的所有文档（入院记录、病程记录、护理记录、出院小结）可以作为具有共享元数据属性的集合提交。这种分组在后续查询中得以保留，允许临床医生检索完整的护理事件，而无需零散的文档发现。
架构与元数据模型
ISO/TS 27790:2009 定义的架构由五个主要角色组成：文档注册库、文档存储库、文档源（提交文档）、文档消费者（查询和检索文档）和患者身份源（提供患者标识符交叉引用）。这些角色通过配套的 IHE 技术框架中定义的标准化事务进行交互。角色之间的关注点分离支持模块化部署方式——组织可以从简单的注册库加存储库配置开始，随着互操作性需求的发展，逐步添加身份交叉引用、社区网关和审计追踪功能。
| 元数据属性 | 描述 | 可查询 | 义务 |
|---|---|---|---|
| patientId | 所属域中的患者标识符 | 是 | 必填 |
| classCode | 高级文档类别（如放射报告、出院小结） | 是 | 必填 |
| typeCode | 类别内的具体文档类型（如胸部X光报告） | 是 | 必填 |
| practiceSetting | 临床专科（如心脏病学、肿瘤学、放射学） | 是 | 必填 |
| authorPerson | 文档作者或创建者 | 是 | 必填 |
| authorInstitution | 文档创建机构 | 否 | 可选 |
| confidentialityCode | 访问控制级别（正常、受限、非常受限） | 是 | 必填 |
| creationTime | 文档创建日期和时间 | 是 | 必填 |
| serviceStart/Stop | 文档记录的临床服务周期 | 否 | 可选 |
| mimeType | 文档格式（如 application/pdf, text/xml） | 否 | 必填 |
| hash | 用于完整性验证的文档内容哈希（最低 SHA-1） | 否 | 必填 |
| size | 文档大小（字节） | 否 | 必填 |
| languageCode | 文档语言（如 en-US, zh-CN） | 是 | 可选 |
文档哈希属性是一个关键但经常被忽视的安全功能。消费系统在检索后应始终验证哈希以确保文档完整性。未经此检查，未检测到的数据损坏或篡改可能危及临床决策。该标准强制要求使用 SHA-1 或更强的哈希算法。
工程师实施模式
对于实施 ISO/TS 27790:2009 的系统架构师和工程师，有几个设计决策会显著影响系统性能和可靠性。首先，元数据数据库技术的选择至关重要：关系型数据库（PostgreSQL、Oracle）提供强大的 ACID 合规性和成熟的工具链，而 NoSQL 存储（MongoDB、Couchbase）为查询密集型工作负载提供更好的水平可扩展性。使用关系型存储作为注册库、对象存储（AWS S3、MinIO）作为文档存储库的混合方法越来越普遍。注册库通常经历的读取密集型工作负载（查询远多于提交），因此在 patientId、creationTime 和 classCode 属性上的查询优化至关重要。
其次，文档生命周期管理必须考虑替换、转换和删除操作。标准定义了一个提交集概念，用于对相关文档进行分组（例如，来自单次患者就诊的所有报告）。当文档被替换时（例如修订后的放射报告），注册库将旧条目标记为已弃用但保留用于审计追踪目的——这种模式类似于 git 提交历史，旧版本被保留但最新版本被清晰标示。这种方法确保临床团队始终可以重建历史记录，同时清晰地看到哪个版本是当前的。替换链通过关系属性进行追踪，将每个文档版本与其前身和后继版本关联起来。
第三，跨社区文档共享需要解析跨所属域的患者身份。框架中的患者身份源角色使用确定性匹配（精确标识符）或概率性匹配（人口统计相似度评分）处理交叉引用。工程师应为临界情况实施可配置的匹配阈值和人工审核队列。该标准还推荐了一种”患者身份源”机制，主动向所有连接社区分发身份更新，减少因过时患者标识符导致的查询失败可能性。
ISO/TS 27790:2009 框架支撑着多个国家电子健康基础设施，包括加拿大 Health Infoway、澳大利亚 My Health Record 系统以及多个欧洲国家健康信息交换系统，如奥地利、瑞士和捷克共和国的系统。
一个常见的部署陷阱是在提交时对元数据质量关注不足。如果文档源提交的元数据不完整或不一致，注册库的搜索效用会迅速下降。实施验证规则和自动元数据丰富（例如，根据作者部门自动填充执业环境，对照患者身份源验证 patientId）以保持注册库质量和搜索有效性。
常见问题
问1：ISO/TS 27790:2009 与简单的文件服务器有何不同？
答：与文件服务器不同，注册库独立于文档内容维护结构化的、可查询的元数据。这使得临床查询如”查找患者 X 在过去 30 天内创建的所有心脏病学报告”无需扫描实际文档内容即可完成。注册库还支持文件服务器无法提供的文档生命周期管理、版本控制和跨社区发现功能。
答：与文件服务器不同，注册库独立于文档内容维护结构化的、可查询的元数据。这使得临床查询如”查找患者 X 在过去 30 天内创建的所有心脏病学报告”无需扫描实际文档内容即可完成。注册库还支持文件服务器无法提供的文档生命周期管理、版本控制和跨社区发现功能。
问2：该框架是否支持临床文档模板（如 CDA、FHIR Document）？
答：是的。mimeType 元数据属性可以指示结构化文档格式，如 CDA 文档的 text/xml。许多实现在注册框架中使用 HL7 CDA 文档，而 FHIR DocumentReference 是注册库概念的 RESTful 映射。
答：是的。mimeType 元数据属性可以指示结构化文档格式，如 CDA 文档的 text/xml。许多实现在注册框架中使用 HL7 CDA 文档，而 FHIR DocumentReference 是注册库概念的 RESTful 映射。
问3：注册架构的扩展限制是什么？
答：现场经验表明，单个注册实例在适当索引的情况下可以支持数百万条文档条目。对于更高规模，联邦模型允许多个注册库通过基于社区的网关连接，每个网关处理自己的所属域。已知最大的部署在联邦注册库中管理数千万份文档。
答：现场经验表明，单个注册实例在适当索引的情况下可以支持数百万条文档条目。对于更高规模，联邦模型允许多个注册库通过基于社区的网关连接，每个网关处理自己的所属域。已知最大的部署在联邦注册库中管理数千万份文档。
问4：鉴于 FHIR 的兴起，本标准仍然相关吗？
答：完全相关。文档注册框架通过提供管理大规模、长寿命文档存储库的基础设施来补充 FHIR。FHIR 的 DocumentReference 资源与注册库元数据模型密切对应，许多现代实现在 ISO/TS 27790 注册库前端暴露 FHIR API。
答：完全相关。文档注册框架通过提供管理大规模、长寿命文档存储库的基础设施来补充 FHIR。FHIR 的 DocumentReference 资源与注册库元数据模型密切对应，许多现代实现在 ISO/TS 27790 注册库前端暴露 FHIR API。
