南京都昌信息科技有限公司 袁永福
【都昌电子病历编辑器】-【结构化、纯前端、电子病历8级】
》》前言
去年我参加了2024上海智慧档案高峰论坛，在这个论坛上，OFD标准的责任编辑、中国电子标准院信息化研究室陈亚军主任向所有参会者公开分享了"文件即接口"的理念。我认同这个理念，并从这个理念出发，结合医院信息化行业特点，推导出了"我的一生.OFD"。
》》电子文件
首先要解释"文件即接口"中的"文件"这个概念，这里的文件特指"电子文件"，对此陈主任给出的定义是：组织或个人在履行法定义务或进行业务事务过程中作为证据和资产生成、接受并保存的信息。能清晰的表达所有参与方的承诺。
这个定义让我们用一种全新的角度来审视电子病历文档。
电子病历文档是医生经过医疗行为产生的文档。在这个过程中，医生是经过严格认证的；医疗过程是受到严格监管的；病历文档是经过严格评定的；医生自然人、医院法人等各参与者都承诺病历文档所含信息真实有效，足以被司法机关采信。
所有的病历文档，包括病案首页、病程记录、护理记录、医嘱单、影像报告单、出院小结、死亡记录等等等。都符合这个"电子文件"的特征。
当然医院中还有非文档类数据，很多也可以转换为病历文档。比如数据库中一条条医嘱记录，出院的时候可以转换为医嘱单文档来归档。这样大部分医疗数据都可以转换为报表文档而进行归档。
因此从医政医务管理的角度上看，医院应该进行以病历文档为中心的信息化建设。
》》文件即接口
文件即接口就是针对各个松散的异构系统进行信息集成，不用传统的专项数据接口进行连接，而是用电子文件来传递数据。而这种情况和医院的生产环境很相似。
在很多医院内部，各种系统来自多个厂商，系统之间关联很松散，各个厂商技术路线自由，水平参差不齐。此时要实现院内数据互联互通，医院需要依赖厂家制作很多专项数据接口，技术规格多种多样，品质随缘，难以统一和管理，存在很多难题，这是医院群体中普遍存在的痛点。
而采用文件即接口的方式，甲方可以比较容易要求相关厂商都采用统一的通用文件格式作为介质来交换数据，技术路线统一，简化数据接口的开发和运维；系统能把可以提供的数据全都给出去，减少接口的重复开发。而且电子文件的传输、处理和存储也简单和规范。
》》数据碎片化
另外从数据的本质上看，患者是一个自然人，也就是一个四维时空实体，应该产生出四维的数据。而实际上单个系统就像局部摄像，获得的是患者某个部分的某个时刻的快照。患者一生就医产生了很多数据并全部记录下来，因此实际上四维数据是全的，但却成为一个个碎片分散在各地，并且被各种系统紧紧的绑住而无法抽离。如何将这些数据碎片收集并组织一个完整的四维数据实体呢？如果靠一个个地理上稀疏分散的追求利润最大化的开发商制作大量专项数据接口，那基本上是不可能完成的任务。因此长期以来，四维数据实体得不到建立，医疗数据要素一直得不到充分利用。
》》我的一生.OFD
利用"文件即接口"的理念，让这个不可能的任务变得有点可能了。此时我提出了一个概念"我的一生.OFD"。下图是其原理图：
所谓"我的一生.OFD"是设想出一个OFD文件，它存储在某个各方认可的权威数据库中，一个自然人对应一个OFD文件，可以用身份证号作为主索引。由于OFD格式支持一个文件包含多个文档，因此这个OFD包含了这个人的所有医疗文书，以时间作为主索引。
比如第一个就是其母亲的产检记录，然后依次是出生记录，儿童疫苗接种记录，各种体检报告，门诊记录，住院记录，手术记录，医技报告单等等等，最后是死亡记录。这个OFD文件称之为母体文件，蕴含了所有的医疗数据要素。
在某种强制机制下，所有的医疗机构在将病历文档进行归档时都以OFD的格式抄送给母体数据库，和对应的自然人的OFD文件进行合并。这样使得"我的一生.OFD"越来越大，能最大程度的实现自然人的四维数据的描述和存储。因此"我的一生.OFD"的信息含量远超任何单一系统，可用于实现最接近真实状态的四维数字孪生。
母体数据库应该受到高等级的安全保护，经过患者同意，医生可以请求调阅"我的一生.OFD"中的部分文档，实现病历数据互联互通。
医疗机构上传的OFD文件应该包含原始病历数据来方便机器阅读。这样在强监管下，人工智能系统可以分析母体文件中的数据，获得预期的结果。
另外由于医疗主管部门手握最全的数据，这也能减少它给医院布置数据上报的作业。
另外更进一步的设想，"我的一生.OFD"就是一个筐，啥都能装，理论上公安、社保、民政等出具的涉及单个自然人的OFD文件都可以放进去。
》》技术陷阱
如何实现"我的一生.OFD"，技术上也不难，但一定要注意，"我的一生.OFD"在实现手段中存在一个巨大的技术陷阱，那就是纯粹的OFD只是版式文件，通过PDF转换器或者虚拟打印机等外挂技术生成的OFD文件会丢失大量关键信息，严重降低"我的一生.OFD"的实际效果。举个例子，如下图所示：
这是一个护理记录单，对于机器阅读，确实能识别出红圈中的文本"23"，但不能识别出这个"23"表示是病人张三在住院期间的2024年1月9日10:00的呼吸速度，这会造成重要信息的丢失，类似的例子还有很多。因此外挂生成的OFD文件对于人阅读来说是足够用；但对于机器阅读来说，那就是营养不良，枯瘦如材。
只有HIT系统原生态的支持OFD技术才能避免这个陷阱。利用OFD的灵活扩展机制，HIT系统可以主动将病历的关键信息追加到OFD文件中，也就是给OFD文件补充营养，使其白白胖胖，更适合成为机器阅读的原料。
》》实现方法
实现"我的一生.OFD"有一个比较简单的方法就是升级医院软件系统中的病历编辑器，如下图所示：
医生确认病历归档时，软件系统再通知编辑器生成补过营养的OFD文件并单独抄送给母体数据库，业务系统的其他功能都不变，这样对现有系统改造不大。
在很多实际运行的系统中，用户使用编辑器能展示多种多样的数据，除了临床病历文书，还有医嘱单、护理记录单、申请单、报告单、费用明细表等等。这些数据都可以通过这种形式抄送给母体数据库。
一个自然人一生所生成的病历文件可能成千上万，如果都放在一个OFD文件则单个文件过大，系统性能不够好，因此可以使用一个关系型数据表来存储数据以便保证性能，这个表主要有三个字段：
字段1：身份证号或者其他有效的唯一性的证件号码。
字段2：精确到秒的时间，比如采用yyyyMMddHHmmss格式。
字段3：上传的OFD文件的二进制原始内容。
另外当多个区域各自实现"我的一生.OFD"，由于都是采用身份证号和时间作为主索引，因此多个母体数据库进行合并也比较简单。这样"我的一生.OFD"既可以从基层开始做起，也可以从顶层开始做起，实现路径比较自由，降低实现难度。比如一个县级卫健委，如果觉得自身条件合适，不管别人怎么做，自己先做这个"我的一生.OFD"，辖区内个别医院进展缓慢也不影响系统运行，而且未来和上级数据库合并也方便。
》》对于OFD国家标准
之前医疗数据互联互通落地比较艰难，其中有一个很大的原因是大家对文档存储格式没有达成一致，而"信创+OFD"给了大家一个达成共识的契机。而且OFD特有的自由扩展的能力为OFD适应HIT业务提供了很多可能性。因此OFD能帮助HIT行业解决一些难题，这就能加速OFD这个国家标准在HIT行业中的推广应用。
》》小结
"我的一生.OFD"原理简单，技术难度也不大，对现有系统改造小，对各方的既得利益影响不大，推广起来应该也不是很难，却能提供一个大家都认同的方式来实现全院或者全区域的病历数据互联互通，为激活医疗数据要素新增一个可选手段，因此值得医院和医疗主管部门认真研究。