CN105512985A - 基于openEHR标准的糖尿病电子病历数据存储方法 - Google Patents

Abstract

本发明公开了一种基于openEHR标准的糖尿病电子病历数据存储方法，包括如下步骤：数据插入：将转换得到的openEHR对象映射为Bson对象，通过MongoDB封装的写入方法将数据写入数据库；数据查询：通过给定的数据标识信息从数据库中取出相应的数据，映射为Java对象返回。

Description

基于openEHR标准的糖尿病电子病历数据存储方法

技术领域

本发明涉及一种基于openEHR标准的糖尿病电子病历数据存储方法，包括数据库选型、openEHR标准格式电子病历数据结构设计、数据插入和查询接口的设计。

背景技术

我国亚健康人群比例升高，心脏病、中风、癌症、慢性呼吸系统疾病和糖尿病等慢性病是已成为目前世界上最主要的死因，人们对电子病历自主管理的需求与日增加。随着健康服务行业的发展，一些以个人健康管理为目标的健康管理系统开始出现，它们搜集和管理人们的个人健康信息，并以此为基础监测、分析和评估人们的健康水平，并采取干预行动改善健康水平。

但是目前我国健康服务行业属于发展初期，健全、一体化的健康管理系统并未出现，尤其是目前各家医院的电子病历数据格式缺乏规范、健全的体系，导致个人健康信息的无标准和不统一，这很容易造成数据重复，不一致，遗漏缺失等问题，这也给电子病历数据自主管理和基于健康信息的数据分析和健康服务带来了困难。

因此为了更标准、更有效地组织和管理病人在各家医院机构的个人健康信息，需要将普通电子病历数据转换为几种标准格式进行存储，并提供标准格式电子病历下载接口给用户，这样用户在可以获得自己在每家医院的标准格式电子病历数据，这对于统一化管理个人健康数据，为病人自主管理电子病历都是具有实际意义和应用价值的。

发明内容

本发明要解决的技术问题是提供一种简单的基于openEHR标准的糖尿病电子病历数据存储方法。

为了解决上述技术问题，本发明提供一种基于openEHR标准的糖尿病电子病历数据存储方法，包括如下步骤：数据插入：将转换得到的openEHR对象映射为Bson对象，通过MongoDB封装的写入方法将数据写入数据库；数据查询：通过给定的数据标识信息从数据库中取出相应的数据，映射为Java对象返回。

作为对本发明所述的基于openEHR标准的糖尿病电子病历数据存储方法的改进：所述数据库为MongoDB数据库。

作为对本发明所述的基于openEHR标准的糖尿病电子病历数据存储方法的进一步改进：所述转换得到的openEHR对象为糖尿病openEHR电子病例；所述糖尿病openEHR电子病历以文档的形式存储在MongoDB数据库中，每一份电子病历都是MongoDB中一份唯一的document，以嵌套的key-value对形式存储具体的数据，其中的每一项都有其自有的类型。

作为对本发明所述的基于openEHR标准的糖尿病电子病历数据存储方法的进一步改进：所述糖尿病openEHR电子病例包括head部分和body部分；所述head部分包括：_id、_class、source、age、birthday、patientId、compositionId、templateId、applied、created、authorized；所述body部分包括：contentItems，该项中包含contextPath、archetypeId、datetime、doctors和valueItems。

作为对本发明所述的基于openEHR标准的糖尿病电子病历数据存储方法的进一步改进：所述字符串类型的_id唯一标识了这份document，即openEHR电子病历，在MongoDB中存入的每份文档，都会由MongoDB分配一个唯一的id；所述字符串类型的_class标识了使用哪一个类来映射该份document；所述字符串类型的source标识了该份电子病例的来源；所述字符串类型的age表示病人的年龄；所述字符串类型的birthday表示病人的生日，是一个时间戳；所述字符串类型的patientId表示该份电子病例的病人的Id，每个病人都有一个唯一的patientId，该病人的所有电子病历都有相同的patientId；所述字符串类型的compositionId表示该份电子病历的Id，没一份电子病历都有一个唯一的compositionId，通过该compositionId找到一份唯一的电子病例；所述字符串类型的templateId表示了该份电子病例所对应的模板；所述字符串类型的applied、created、authorized分别表示了该份电子病例的使用、创建和审核时间，是以时间戳的形式表示的；所述字符串类型的contextPath表示该项原型在模板中的路径；所述字符串类型的archetypeId表示了该原型的Id；所述字符串类型的datetime是一个时间戳，表示其生成时间；所述字符串类型的doctors表示医生相关的信息；所述字符串类型的valueItems表示具体的检查项信息。

作为对本发明所述的基于openEHR标准的糖尿病电子病历数据存储方法的进一步改进：所述body部分，是一个Array类型的contentItems，其中的每一项都是Document类型的，一个Document对应着模型层的一个Java对象。

本发明是基于openEHR实现的，openEHR是由欧洲openEHR机构提出的一种在健康信息领域的开源和开放的标准规范。它描述了电子健康档案数据的管理，存储，检索和交换方式，采用两层建模的方式实现了医疗知识和具体临床信息的分离,即参考模型和原型模型。参考模型定义了医疗信息中比较稳定的概念，例如通用的数据结构和基本类型等。原型模型由原型(archetype)和模板(template)组成，是相对容易变化的医疗领域知识模型。原型是对参考模型的约束，模板是在原型的基础上是更高层次的结构，使用原型并对其进行进一步约束以满足特定医疗医务需求；openEHR的“open”表明它是开放的EHR规范，有很多相应的开源项目正在进行，这将有利于加快标准化的形成和实现整个健康领域的语义互通。

附图说明

下面结合附图对本发明的具体实施方式作进一步详细说明。

图1糖尿病openEHR电子病历数据存储结构；

图2糖尿病openEHR电子病历数据插入流程；

图3糖尿病openEHR电子病历数据查询流程。

具体实施方式

实施例1、图1～图3给出一种基于openEHR标准的糖尿病电子病历数据存储方法，其选用openEHR作为标准化的电子病历数据存储规范。

本发明要实现的是openEHR格式糖尿病电子病历数据的数据存储结构设计、数据插入和查询接口的设计。而本发明基于MongoDB数据库实现，其MongoDB是一个基于分布式文件存储的数据库，是一种文档型的非关系型数据库。MongoDB支持的数据结构非常松散，是类似Json的Bson格式，因此可以存储比较复杂的数据类型。MongoDB对数据结构要求不严格，表结构可变，不需要像关系型数据库一样要预先定义表结构，非常适合用于存储医学电子病例。医学电子病例的结构是多变的，各份电子病例之间的结构也可能存在差异，MongoDB由于其模式自由的特点，对于存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义，更适合用于存储医学电子病例。ongoDB支持的查询语言非常强大，其语法类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。因此本发明选择MongoDB作为存储的数据库。

本发明主要由以下的两个步骤完成：

数据插入：即将转换得到的openEHR对象映射为Bson对象，通过MongoDB封装的写入方法将数据写入数据库。

数据查询：即通过给定的数据标识信息，如EHRId，从MongoDB数据库中取出相应的数据，映射为Java对象返回。

主要实现糖尿病openEHR电子病历数据存储结构的设计和数据插入、查询方法如下。

1、糖尿病openEHR电子病历数据存储结构的设计：

糖尿病openEHR电子病例以文档的形式存储在MongoDB中，每一份电子病历都是MongoDB中一份唯一的document，以嵌套的key-value对形式存储具体的数据，其中的每一项都有其自有的类型，这个类型和模型层中的Java类型是相对应的。

一份糖尿病openEHR电子病例在MongoDB中的存储结构如下：

_id、_class、source、age、birthday、patientId、compositionId、templateId、applied、created、authorized构成了数据的head部分，contentItems构成了数据的body部分。

以上所述的字符串类型的_id唯一标识了这份document，即openEHR电子病历，在MongoDB中存入的每份文档，都会由MongoDB分配一个唯一的id；字符串类型的_class标识了使用哪一个类来映射该份document，这里是CompositionEntity这个类；字符串类型的source标识了该份电子病例的来源，目前支持两种source，2000和3000,2000表示该份电子病例是手动录入的，3000表示该份电子病例是从医院数据后台导入的；Int32类型的age表示病人的年龄；Int64类型的birthday表示病人的生日，是一个时间戳；字符串类型的patientId表示该份电子病例的病人的Id，每个病人都有一个唯一的patientId，该病人的所有电子病历都有相同的patientId；字符串类型的compositionId表示该份电子病例的Id，没一份电子病例都有一个唯一的compositionId，通过该compositionId可以找到一份唯一的电子病例；字符串类型的templateId表示了该份电子病例所对应的模板；Int64类型的applied、created、authorized分别表示了该份电子病例的使用、创建和审核时间，是以时间戳的形式表示的。

数据的body部分是一个Array类型的contentItems，其中的每一项都是Document类型的，一个Document对应着模型层的一个Java对象。这是一种有层次的嵌套关系，这使得数据的结构比较自由，不会限定在某一种特定的模式下，文档的结构是灵活多变的。ContentItems中的每一项对应着openEHR中的一个原型，而最外层的Document则对应着最外层的原型COMPOSITION。这种数据存储的形式和openEHR体系结构是一致的。

该项中包含contextPath、archetypeId、datetime、doctors和valueItems，字符串类型的contextPath表示该项原型在模板中的路径，是openEHR知识中的概念，表示该原型在模板中的相对位置，这里是/content[at0006]；字符串类型的archetypeId表示了该原型的Id，即表示该原型是哪个原型，这里archetypeId为openEHR-HER-OBSERVATION.Tanghuaxuehongdanbai.v1，表示该原型为“糖化血红蛋白”的原型，是属于OBSERVATION类型的原型；Int64类型的datetime是一个时间戳，表示其生成时间；Array类型的doctors表示医生相关的信息，这里嵌套了两个Document，分别表示了送检医生，张医生和审核医生，李医生；Array类型的valueItems表示具体的检查项信息，这里valueItems包含了三个子项，每一项表示了一个检查项，code表示该检查项在该原型中的路径，dataValue是一个组合的字符串，包含了三个信息，即该项的数据类型、数据的值和单位，这里的原型和项的层次和openEHR知识体系结构也是相一致的。这里的第一项，code为at0004，根据该code，可以在原型中唯一找到对应的项，这里的at0004在“糖化血红蛋白”原型中的项为“糖化血红蛋白A1c”，其数据类型为DV_QUANTITY，即为值类型，openEHR中还有表示文本类型的DV_TEXT等；5和％表示其单位为％,且值为5，即5％；第二项表示“糖化血红蛋白A1ab”，在原型中的路径为at0005，其值为DV_QUANTITY类型，1％；第三项表示“糖化血红蛋白A1”，在原型中的路径为at0006，其值为DV_QUANTITY类型，7％。

2、糖尿病openEHR电子病历数据插入和查询接口：

糖尿病openEHR电子病例数据的插入是将由原始数据映射转换而得的JavaBean对象存入MongoDB的过程，这里的JavaBean对象即CompositionEntity，一个CompositionEntity代表了一份openEHR电子病例数据，对应于MongoDB中的一份Document，CompositionEntity对应于文档最外层的Document，其内部包含的对象，如contentItems等，则对应于最外层Document的子Document。

Compositionentity即为构造好的封装了openEHR电子病例数据的JavaBean对象，mongoTemplate是通过spring依赖注入的方式构造的用于对MongoDB进行操作的对象，这里使用的是org.springframework.data.mongodb.core.MongoTemplate，调用其insert方法，传入两个参数，要存储的CompositionEntity对象和所要存入的目的collection的名字，将该CompositionEntity对象转换为Bson对象后，存入MongoDB的collectionName所指定的collection中。

糖尿病openEHR电子病例数据的查询是通过一定的标识信息，如id等，从MongoDB中取出对应的openEHR电子病例数据。如下所示是通过EHRUuid，即每份电子病例数据唯一的id信息，从MongoDB中查询对应的电子病例数据。

这里用到了两个查询相关的Java类，Criteria和Query。Criteria使用的是org.springframework.data.mongodb.core.query.Criteria，构成了一个条件查询的具体查询要求，Query使用的是

org.springframework.data.mongodb.core.query.Query，构成了一次查询任务，Query中包含Criteria。

首先构造Criteria对象和Query对象，通过and和is给Criteria对象增加约束条件，这里表示“compositionId”为“EHRUuid”的，将该Criteria对象加入到Query对象中，通过mongoTemplate的findOne方法，从collectionName所指定的collection中实现query对象所代表的查询任务，并将查询所得的数据映射到CompositionEntity类，返回所得的CompositionEntity对象。根据查询条件Criteria的不同，可以实现不同的查询。

最后，还需要注意的是，以上列举的仅是本发明的一个具体实施例。显然，本发明不限于以上实施例，还可以有许多变形。本领域的普通技术人员能从本发明公开的内容直接导出或联想到的所有变形，均应认为是本发明的保护范围。

Claims (6)

1.基于openEHR标准的糖尿病电子病历数据存储方法，其特征是：包括如下步骤：

数据插入：

将转换得到的openEHR对象映射为Bson对象，通过MongoDB封装的写入方法将数据写入数据库；

数据查询：

通过给定的数据标识信息从数据库中取出相应的数据，映射为Java对象返回。

2.根据权利要求1所述的基于openEHR标准的糖尿病电子病历数据存储方法，其特征是：所述数据库为MongoDB数据库。

3.根据权利要求2所述的基于openEHR标准的糖尿病电子病历数据存储方法，其特征是：所述转换得到的openEHR对象为糖尿病openEHR电子病例；

所述糖尿病openEHR电子病历以文档的形式存储在MongoDB数据库中，每一份电子病历都是MongoDB中一份唯一的document，以嵌套的key-value对形式存储具体的数据，其中的每一项都有其自有的类型，这个类型和模型层中的Java类型是相对应的。

4.根据权利要求3所述的基于openEHR标准的糖尿病电子病历数据存储方法，其特征是：所述糖尿病openEHR电子病例包括head部分和body部分；

所述head部分包括：

_id、_class、source、age、birthday、patientId、compositionId、templateId、applied、created、authorized；

所述body部分包括：

contentItems，该项中包含contextPath、archetypeId、datetime、doctors和valueItems。

5.根据权利要求4所述的基于openEHR标准的糖尿病电子病历数据存储方法，其特征是：所述字符串类型的_id唯一标识了这份document，即openEHR电子病历，在MongoDB中存入的每份文档，都会由MongoDB分配一个唯一的id；

所述字符串类型的_class标识了使用哪一个类来映射该份document；

所述字符串类型的source标识了该份电子病例的来源；

所述字符串类型的age表示病人的年龄；

所述字符串类型的birthday表示病人的生日，是一个时间戳；

所述字符串类型的patientId表示该份电子病例的病人的Id，每个病人都有一个唯一的patientId，该病人的所有电子病历都有相同的patientId；

所述字符串类型的compositionId表示该份电子病历的Id，没一份电子病历都有一个唯一的compositionId，通过该compositionId找到一份唯一的电子病例；

所述字符串类型的templateId表示了该份电子病例所对应的模板；

所述字符串类型的applied、created、authorized分别表示了该份电子病例的使用、创建和审核时间，是以时间戳的形式表示的；

所述字符串类型的contextPath表示该项原型在模板中的路径；

所述字符串类型的archetypeId表示了该原型的Id；

所述字符串类型的datetime是一个时间戳，表示其生成时间；

所述字符串类型的doctors表示医生相关的信息；

所述字符串类型的valueItems表示具体的检查项信息。

6.根据权利要求5所述的基于openEHR标准的糖尿病电子病历数据存储方法，其特征是：所述body部分，是一个Array类型的contentItems，其中的每一项都是Document类型的，一个Document对应着模型层的一个Java对象。