定义
FHIR（Fast Healthcare Interoperability Resources）是 HL7 组织发布的新一代医疗互操作标准（HL7 FHIR R4/R5），基于 RESTful API、JSON/XML、RDF 等现代技术，实现医疗数据资源的标准化交换。FHIR 定义患者（Patient）、医嘱（ServiceRequest）、检验（Observation）、影像（ImagingStudy）等 150+ 资源类型，支持 Web 端、移动端、IoT 设备、区块链等接入。
FHIR 与 HL7 v2、HL7 v3、CDA 相比更易实现、更灵活、更适配云原生架构。医疗系统、健康 APP、可穿戴设备、远程监护设备等通过 FHIR 实现数据交换。物联网卡为 FHIR 医疗数据交换提供安全连接，满足 HIPAA、等保、GDPR 等合规要求。
技术特点
FHIR 支持 REST、消息、文档等多种交互模式。具备扩展机制（Extension）、引用（Reference）、搜索（Search）等能力。与 SMART on FHIR 结合可实现 OAuth 授权与 App 互操作。FHIR 被 FDA、ONC、各国卫生部门广泛采纳。
应用场景
FHIR 应用于医院信息系统、电子病历、健康管理平台、远程医疗、医联体、医保结算、临床试验等。典型场景包括：患者信息查询、电子病历共享、检验结果互认、健康数据上报、可穿戴设备数据接入等。达希物联为 FHIR 医疗场景提供 VPDN 专网、专用 APN、实名认证及智慧医疗解决方案。
资源查询穿过蜂窝出口
检索与订阅在流量上的差别
FHIR 在物联网卡上的含义，是医疗资源用统一的资源地址来读写，而不是在链路上再发明一套私有报文。患者、检验观察、影像检查引用都是可单独获取的资源。经蜂窝出去的，多是院外网关、移动医护或家用设备侧的客户端。一次查询返回一页资源，订阅则是资源变化后由服务端推送。两者对卡的占用完全不同：查询是突发、可暂停；订阅是长时间挂着连接，心跳和通知混在一起。
卡不解释资源内容，它只决定这些请求能否到达指定主机、中途会不会被地址策略丢掉。把整页检索放在小流量套餐上，分页令牌会让客户端不停追下一页，流量曲线像故障。与更早的消息标准相比，可参见HL7；涉及可识别健康信息出境或跨境传输时，还要同时满足HIPAA一类隐私约束，不能只因为接口“能通”就放行。
限定主机与证书的使用条件
使用条件是目标主机名固定、证书可校验、客户端身份和患者授权分开。卡侧白名单应写主机名或地址段，而不是放行全部互联网。家用设备若只上报自己的测量值，应使用设备凭证，不能携带可以遍历全院患者的账号。断线后的补拉要有水位：只补上次成功的资源版本之后的变化，而不是每次重连都从第一页重拉。
套餐按“通知次数加偶发查询”估算，不要按医院内网的接口调用量去买。网关汇聚多个床旁设备时，一张卡对应网关，资源里的设备编号仍要各自唯一，避免平台把不同病床的观察写进同一条时间线。
分页拉取把套餐打满
容易出错的是客户端把搜索条件留空，蜂窝上 Equivalent 于把资源库往外倒。失败重试不带退避，会在证书错误时每秒打满链路，卡被风控暂停后，真正的危急值通知也出不去。订阅与查询共用一个超时，通知稍有延迟就被当成断线并全量重建，流量和重复数据一起出现。
时钟不准会让“最后更新时间”筛掉新记录或重复插入旧记录。调试阶段用个人令牌跑在生产卡上，令牌写进日志后，任何拿到详单或日志的人都能继续查询。上线前应看一次空条件搜索是否被拒绝、重连后是否只补增量、详单里是否出现不该出现的患者姓名。
订阅通知还有顺序问题。网络抖动时，后发生的观察结果可能先到，先发生的后到。若平台按到达顺序覆盖“最新值”，病人的旧血压会盖住新血压。每条资源应带自己的采集时间和版本，后到的旧版本不得覆盖新版本。分页令牌过期后应要求客户端缩小时间窗重查，而不是从第一页把历史全部再拉一遍，否则一张小流量卡会在一次重连里用完整月额度。设备凭证和用户凭证不要放在同一个请求里混用：设备只能提交自己的测量，用户凭证才能按授权范围查询他人。网关代传多个设备时，每个资源仍要写明源设备，不能都记成网关的卡号。卡号出现在审计里是为了追传输路径，不能当作患者或设备的临床标识。
搜索参数里的日期若用本地时区、服务端用另一时区，同一天的观察会被切到相邻两天，看起来像缺数。请求里应使用约定好的时区或直接用绝对时间。引用其他资源时只传标识，不要把被引用对象的全文再嵌进来，否则一次查询的体积会随嵌套膨胀，把为小报文准备的套餐打满。