OFD-H如何连接人读、机读与医疗AI。
设想两家医院交换一份血常规报告。
接收方医生能清楚看到“血红蛋白135 g/L”，但接收系统是否知道135对应哪个项目？单位是什么？它属于哪次检验？
这不是一回事。
一份文件可以同时服务两种读者
OFD-H一方面通过版式页面让人看到稳定的报告，另一方面允许通过标引、附件及机读信息提供机器能够解析的内容。
第7.5条对实际包含的机读信息提出XML、JSON等半结构化文件以及UTF-8编码、GB 18030字符支持等要求。
其目标是减少对截图OCR和临时文本识别的过度依赖。
能提取文字，不等于理解医学语义
扫描病历经过OCR，可以找到“血红蛋白”四个字，但系统不一定知道它与某项标准化检验代码的关系。
同样，两个系统即便都使用JSON，一个字段叫hemoglobin，另一个叫HB，如果没有统一的语义和单位约定，数据依然可能不能直接计算。
OFD-H解决重要的文件载体问题，但并不替代诊断、检验、药品等医疗语义规范。
比有没有JSON更重要的是一致性
如果OFD-H页面写着135，机读JSON写着153，那么看起来“结构化更先进”的文件反而引入新风险。
工程上应在文件形成前验证页面和机读数据来源一致，并让数字签名按适用规则保护相关病历内容。
AI读取这样的数据，也应保留来源和证据，而不是只相信一个孤立数值。
不是每一份OFD-H都被强制要求附带完整医疗JSON
历史扫描病历、简单文书和临床结构化报告的成熟度不同。
标准对机读信息的组织提出规范，但并非无条件要求所有OFD-H含有完整的结构化医疗数据。
医院可以优先从新生成的检验报告、出院记录等标准化程度较高的场景做起。
AI时代更有价值的医疗文件，不只是便于模型“读到文字”，而是能把人看到的内容、机器消费的数据和可信来源关联起来。
资料依据与阅读边界
依据 GB/T 48666—2026 正式文本。本文为实践解读，不替代标准原文，也不表示 MediQ 产品已通过符合性认证。