你的位置:首页 > 信息动态 > 技术信息
信息动态
联系我们

电子病历系统的“结构化”到哪一步了?

2017-11-22 10:49:04??????点击:

  尽管电子病历这件事情热了好几年,最近还是被院长,甚至医院信息中心的人按住讨论“结构化”的具体含义。看来“言而无文,行之不远”,还是有必要静下心来写一段文字,把这个结构化的问题阐述一下。

  “结构化”伴随着电子病历而产生,也就是说,为了让计算机能够处理病历而发明了“结构化”。病历的核心是,医护人员对患者诊疗过程中的病情、症状、用药、处置能内容记录。但是,由于医疗服务的复杂性和患者个体的差异性,决定了这个记录天然就有“规范性”和“差异性”的双重属性。遗憾的是,计算机的天性是善于处理“规范性(结构化)”数据,对于非结构化数据的分析和利用,仅限于“全文检索”和“智能分词”这样的后期领域,例如,图书馆领域,或者医疗大数据利用等。但是,作为业务系统应用“非结构化”数据处理,计算机就力不从心了。因此,病历追求“结构化”,是在“人可读”和“计算机可读”之间的一个平衡。

  在“结构化”的道路上,电子病历系统有三个技术门槛需要过:

  第一个门槛是“节点化”, 即:用户在病历编辑器里面,可以看到病历片段被拆分成为一个个节点。从技术后台来说,每一个节点会保存为一个“值参对”,这样,数据库才有可能进一步处理这些数据。 从2002年开始,行业已经不断开发出专用的电子病历编辑器,用来处理病历模板中的节点,因此,这个技术门槛已经被当今大多数厂商逾越。

  第二个门槛是“结构化”, 即:需要时间节点之间的层级关系。举个例子来说,前一步“节点化”,实现后我们可以在后台快速查询,例如,查询某患者病历中的“血压舒张压:90毫米汞柱”这样一个值参对。但是现实中,我们需要回答的问题往往是:用药前舒张压,用药后舒张压,或者家族病史中的高血压范围。因此,在不知道上下文关系的情况下,仅仅保存“节点化”和“值参对”是没有意义的。病历节点的层级关系定义,就可以解决节点之间上下文逻辑关系的问题。在这个阶段,新增和删除节点,都需要对节点的应用场景(文档模板类型,节点所在章节等)做限定,并且根据一定规则给出唯一ID号,以便于节点项目的重用和查询。

  第三个门槛是“编码化”, 即:节点内数据内容的定义的限定。从技术后台来说,是节点取值的值域范围和数据类型;从临床业务上来说,则是关于诊断、检查、操作、用药的标准字典编码维护。有ICD-10 使用经验的工程师都知道,这不仅仅是个数据编码字典编制的问题,还涉及到不同临床专业、不同疾病条件下,对同一个客观主体的描述维度的统一问题。现实生活中,往往要根据具体使用目的不同,编制和对应不同的编码规则。医院信息平台中的术语注册服务,可以辅助解决部分编码数据统一和对应问题,但实际应用中,不可能实现100%的数据编码,往往需要在灵活性和规范性之间,找到一个投入产出比的平衡。

  这三大门槛的跨越程度,决定了一个电子病历系统的“结构化”成熟度。这其中既包括了系统本身对三大门槛的支持能力,也包括了系统中数据在三大门槛中的覆盖比例。举例来说,住院病案首页是节点化、结构化、编码化程度最高的病历数据,但是,我们不能仅仅凭借住院病案首页的数据处理能力,就来评价一个电子病历系统的结构化成熟度。

  因此,所谓结构化、半结构化,孰优孰劣之争基本上就是个伪命题。电子病历系统的结构化成熟度评价,需要在一个更加精密和多维度的指标体系中进行,这就是:“节点化、结构化、编码化”的后台支持能力,以及系统中相关模板数据对上述三个能力的实现程度。