1. FHIR接口测试全景

FHIR（Fast Healthcare Interoperability Resources）并不是一个单纯的“数据格式”，而是一套把医疗数据模型、RESTful 交互语义和一致性约束打包在一起的互操作规范。做 FHIR 接口测试，第一步不是打开 Postman 发请求，而是先看清被测对象到底由哪些层次构成：资源（Resource）定义“数据长什么样”，RESTful 交互定义“怎么读写这些数据”，能力声明（CapabilityStatement）定义“服务端承诺支持什么”，而一致性验证则回答“实际行为是否兑现了承诺”。这四层共同决定了测试用例的边界与断言方式。

FHIR 协议核心对象：从资源到交互单元

FHIR 的最小数据单元是 Resource。以患者为例，一个 Patient 资源包含 id、identifier、name、gender、birthDate 等元素，其中 id 是服务端分配的逻辑标识，identifier 才是业务系统里的病案号、医保号等真实标识。测试时必须区分这两者：用 Patient/123 读取的是服务端资源实例，而用 identifier 查询走的是搜索交互，两者的断言点完全不同。

资源之上是“交互单元”。FHIR 把对资源的操作抽象为 RESTful 动词与路径的组合：GET [base]/Patient/123 是读取，POST [base]/Patient 是创建，PUT [base]/Patient/123 是更新，DELETE [base]/Patient/123 是删除，GET [base]/Patient?name=张 是搜索。每个交互都有明确的 HTTP 状态码、响应体结构和错误处理约定。例如创建成功应返回 201 Created 并携带 Location 头，更新成功返回 200 OK 或 201，读取不存在返回 404，参数非法返回 400 并附带 OperationOutcome。这些不是“建议”，而是测试中可直接断言的硬性契约。

RESTful 交互模型与一致性验证的边界

很多初学者会把“接口能返回 JSON”当成测试通过，这是最大的误区。FHIR 一致性验证至少包含三个层次：语法一致性（JSON/XML 结构是否符合资源定义、必填元素是否存在、数据类型是否正确）、语义一致性（编码是否来自指定值集、引用是否可解析、搜索参数是否按规范解释）、行为一致性（CapabilityStatement 声明的交互是否真的可用、状态码和错误结构是否符合规范）。

测试与一致性验证的边界在于：测试关注“给定输入，输出是否符合预期”，一致性验证关注“服务端是否按 FHIR 规范声明并实现其能力”。前者是点状的用例执行，后者是面状的契约核对。一个完整的 FHIR 测试项目，应当先用 CapabilityStatement 建立“能力基线”，再针对每个声明的交互设计正向与反向用例，最后用校验器（如 HL7 FHIR Validator）对响应资源做结构与术语校验。

课程实战项目介绍

本课程围绕一个贯穿始终的实战项目展开：对一个模拟的“区域健康信息平台 FHIR 服务端”进行接口测试与一致性验证。该服务端声明支持 Patient、Observation、Encounter 三类资源的读取、创建、更新、删除和搜索交互，并对外暴露 /metadata 端点返回 CapabilityStatement。项目分为四个阶段：第一阶段读取并解析 CapabilityStatement，建立能力基线；第二阶段针对每个声明的交互编写正向用例，验证状态码、响应体结构和关键字段；第三阶段构造反向用例，包括缺失必填元素、非法编码、不存在的资源 ID、越权访问等，验证错误处理是否符合 OperationOutcome 规范；第四阶段使用 HL7 FHIR Validator 对采集到的响应资源做批量校验，统计语法与语义层面的不一致项，形成一致性验证报告。

在工具选择上，课程使用 Postman 或 curl 发送 HTTP 请求，用 JSON Schema 与 FHIR 官方 StructureDefinition 做结构校验，用 Inferno 或 Touchstone 做交互级一致性测试。示例参数均以教学为目的构造，例如测试患者 Patient/example-001，其 identifier 使用系统 http://hospital.example.org/mrn 和值 MRN-20240001，name 为 张伟，gender 为 male，birthDate 为 1985-03-12。这些数据用于演示请求构造与断言编写，不代表任何真实患者信息。

需要特别注意的是，FHIR 的版本差异会直接影响测试断言。R4、R4B、R5 在资源元素、搜索参数和交互细节上存在变化，例如 R5 对部分资源的必填元素和术语绑定做了调整。测试前必须确认被测服务端声明的 FHIR 版本，并选用对应版本的 StructureDefinition 和校验器。忽略版本差异，是导致“误报”和“漏报”的常见原因。

最后，一致性验证不是一次性的动作，而应嵌入持续集成流程。每次服务端发布新版本，都重新拉取 CapabilityStatement、重跑核心用例、重新执行资源校验，并对比历史报告中的不一致项数量与类型。只有这样，FHIR 接口测试才能从“手工点测”升级为可重复、可度量、可追溯的工程实践。