一种电子病历结构化数据组织方法及实现系统

技术领域

本发明涉及数据库设计技术领域，涉及一种电子病历结构化数据存储设计方法。

背景技术

电子病历是医院管理网络化在医疗领域的必然产物，随着医疗信息化建设的逐步推进,大多数的医院应用了电子病历系统。电子病历中包含病人在医院诊断治疗全过程的原始记录，蕴含着丰富的数据信息。由于电子病历中所蕴含的信息多为半结构化数据，大量的数据信息不能够被计算机所识别，从而增加了利用电子病历数据信息的难度，为了更好的利用电子病历中蕴含的丰富信息，就需要对电子病历进行结构化存储设计。此外，越来越多的人利用电子病历中所蕴含的信息进行特定的医疗知识图谱构建，但他们大多都是直接从原始的电子病历信息直接进行数据处理得到的，这样做的缺点是每次建立不同的图谱或进行不同的查询都需要对原始病历数据进行预处理和计算。因此需要定义一种对病历数据处理后的数据组织方式,对电子病历结构化数据存储进行设计则成为重要的课题。

数据库系统的研究从20世纪60年代至今，几十年过去了，取得了非常辉煌的成就，形成了非常丰富的理论知识体系，但是却很少有人对电子病历数据进行更进一步的细化，对电子病历中非结构化或者半结构化数据进行设计，也没有更加系统的对电子病历数据进行统一的设计和存储。传统电子病历仅仅只是记录了每一次就诊的病历，并没有把患者的患病按照时间进行管理。

为了更加高效的存储和利用电子病历蕴含的丰富信息，对电子病历中的信息更进一步的划分，减少对电子病历信息的重复提取，提高信息的挖掘效率，更加方便的进行科学研究。基于这一目标，本发明提出了一种全新的电子病历结构化数据存储方案。

发明内容

针对上述问题，本发明提出一种全新的电子病历结构化数据存储以及展示方案，主要分为两个部分。

第一项发明内容是提出一种以病人为中心的全新电子病历结构化数据存储方案，设计出电子病历结构化存储方案的逻辑模型并将逻辑模型转换成实际的物理模型存储数据库之中。本发明的逻辑模型提出病人、放射物品接触史、月经信息、工作史、疾病、接种史、就医、家族史、诱因、日期、过敏史、检查、居住史、嗜好、症状、治疗、婚育、药物等概念，具体的逻辑模型见附图1。本发明的物理模型采用Neo4j图数据库进行物理存储。

第二项发明内容是基于第一项发明内容设计并开发了软件系统，该软件系统分为前端展示操作以及后端数据处理两个部分。前端提供友好的可视化界面,以关系图的方式展示病人的各相关信息，并提供新增、编辑和查询功能。

本发明提出的一种电子病历结构化数据存储设计方法能够友好的展示病人相关信息，相对传统电子病历，本发明提出的方法能够更细化的存储病人相关信息并且能够根据时间线查看病人的患病时间轴以及采取的治疗、检查等措施，并能够全面存储疾病以及采取的治疗等过程，能够非常方便的为疾病知识挖掘提供数据源。

附图说明

图1电子病历结构化设计逻辑模型图。

图2病人信息管理列表图。

图3新增/编辑病人信息图

图4病人病历信息图

图5状态转换图

图6新增/编辑节点图

图7新增关系提示图

图8病人患病情况时间线图

图9相似症状病人列表图

具体实施方式

以下结合附图和实施实例对本发明进行详细说明。

一种电子病历结构化数据存储设计方法，该方法包括如下步骤：

步骤一：对原始电子病历进行细化，细化到合理的颗粒度。原始电子病历除了病人基本信息外还包含主诉、现病史、既往史、月经史、婚育史、个人史、家族史。除病人基本信息外其他信息主要分为两大类，一类是与病人本次来就诊关联度较大的信息如主诉、现病史、既往史(既往患病可能与当前病相关联),另一类信息与本次就诊关联度不高的信息如个人史、家族史等。下面是本发明分别对着两类信息的颗粒度细分。

病人基本信息：用于记录病人的基本信息。属性有姓名、性别、出生日期、出生地、民族、就诊卡号、证件号、证件类型、初潮年龄、绝经年龄。

对于第一类信息，由于现病史的内容包含了主诉的内容，故本发明只考虑现病史和既往史信息。考虑到现病史描述的是病人发病、发展、诊断以及治疗的动态过程，为了体现出这个动态的过程本发明提出一个日期的概念，将病人发病、治疗的整个过程用时间进行串联。由于当前就诊记录的现病史会成为下次就诊的既往史，所以本发明摒弃现病史和既往史的概念，并引入了症状、诱因、治疗、药物、检查、疾病、就医等新的概念。下面一一介绍。

日期：日期包含两个属性日期和是否精确属性。其中日期用于保存发生的日期，是否精确属性用于描述该日期是否是准确值。原始电子病例中记录时间方式多样，除了“2020年5月1日”这种精确记录的方式，也有“大约三月前”这种相对模糊的记录方式。为了方便日后按照时间排序，本发明中日期属性均采用这种精确方式记录。考虑到病人也会记不清楚具体的日期，所以引入是否精确属性用于区分当前日期是否是精确的。

症状：症状包含症状描述、症状程度、症状趋势、频率、持续时间、伴随症状描述、无症状说明这些属性。其中症状描述主要是描述病人发病的症状特征，如“头部疼痛、恶心”等。同样的症状也有程度上的区分，故本发明对症状引入了症状程度这一属性，如“轻度”、“重度”。症状趋势是相对于上一次记录相同症状症状的发展趋势，如“三月后上述症状再次出现并加重”,那么此处用加重来记录下症状发展过程的趋势情况。频率这一属性用于记录病人症状发生的频率，如“每周两到三天”等。持续时间用于表示该症状持续了多久，如“这一状况持续了半年”。伴随症状描述用于记录病人症状所伴随的一些症状,如“头痛伴随恶心”。无症状说明用于记录病人没有的一些症状，如“无腹部疼痛”。

诱因：诱因用于记录用户出现某些症状产生的原因以及状态。其属性有状态描述、诱因描述、持续时间和趋势。如“误食洗发水，恶心呕吐半小时”这里的诱因描述是“误食洗发水”，持续时间则是“半小时”。此处的持续时间属性与症状中的持续时间属性有所不同，此处为症状每次发作的持续时间，而症状中的持续时间属性描述的是整个症状的持续时间。再如“坐起后加重”。状态描述是“坐起后”,趋势为“加重”。此处趋势属性与症状中趋势属性不同，此处描述的是某个状态下症状的相对趋势，而症状中趋势属性描述的是症状整体的趋势。

就医：就医用于记录用户在医院的就诊信息，包括在其他医院进行的就医信息。包含就诊医院、就诊科室、就诊方式、病程描述、就医结果等属性。每当病人来医院进行就医时，就需要为本发明中的就医实体中添加一条记录，用于记录病人本次的就医过程。此外，若病人在来就医之前去过其他医院并且之前没有记录过该信息，也需要将就医信息记录到本实体之中。例如“就诊于A医院,予以静脉输液治疗，症状有所好转”。就诊医院则是A医院，就医结果是症状有所好转。

治疗：治疗用于记录病人在治病过程中的诊治过程。属性为治疗名称、治疗方式、治疗结果描述、治疗频率。例如“予以十二指肠手术治疗，手术成功”。治疗名称为十二指肠手术治理，治疗方式为手术治疗，治疗结果为手术成功。对于一些长期治疗的疾病，例如高血压，往往采用药物治疗并含有治疗频率，例如“服用某降压药一天一次”，这里的治疗频率为一天一次。

药物：用于描述治疗过程中使用的药物。属性为药物名称、药物剂量、使用方式。例如“输液500Ml葡萄糖症状得到好转”，这里的药物名称为葡萄糖，使用方式为输液,药物剂量为500Ml。

检查：用于记录患者治疗过程中所做的各项检查。属性为检查名称、检查信息描述、检查结果说明。例如“CT检查发现左肺下叶背段结节，考虑肺部炎症”，检查名称为CT检查，检查信息描述为“左肺下叶背段结节”,检查结果为“考虑肺部炎症”。

疾病：用于记录患者确诊或者推断出来的疾病。属性为疾病名称、是否确诊。考虑到某些医院能力有限，无法做出明确判断，只能推断出某系疾病，故用是否确诊属性来区分推断和确诊。

月经信息：月经信息随与疾病没有直接关联，但每次就诊月经信息均是变化的，所以也将其归为第一类信息，其属性有行径天数、行经量、月经周期、是否有血块、颜色描述、其他描述。原电子病历中一般在月经史中记录初潮年龄、绝经年龄，由于初潮年龄和绝经年龄是固定的，故将这两个属性放入病人属性中。

对于第二类信息，该类信息与此次就诊并无直接关联，但这些信息可能与病人患病有着一些潜在的关系，为了数据的完整新，这类信息也将一一存取。原电子病历中，这些信息主要有婚育史、个人史、家族史。本发明将这些信息进一步细化，细化出工作史、居住史、家族史、放射物品接触史、接种史、过敏史、婚育情况。下面一一介绍。

工作史：因为某些疾病与工作有着潜在的关系，故使用工作史记录病人的工作情况。其属性有职业名称、职务名称、开始时间、结束时间、工作地点。由于一个人可能在不同的时间段有不同的工作，故本发明使用开始时间和结束时间来区分不同的时间段，若工作至今未边，则该结束时间留空即可。例如“2001年1月至今在西藏当兵”。职业名称为兵，开始时间为2001年1月，结束时间留空，工作地点为西藏。若患者下一次来就诊时，已经更换工作，此时便可以更新此工作的结束时间。

居住史：用于记录病人居住情况。其属性有开始时间、结束时间、地区名称、是否疫区。同样居住史可能有多个时间段,用开始时间和结束时间进行区分。例如“久居于四川”。地区名称为四川，是否疫区为否，开始时间为该患者出生日期，结束日期留空。

家族史：用于记录家族成员的一些患病情况。其属性为成员关系、患病名称、患病描述、患病年龄(初始患病年龄)、患病时间。例如“父亲于2005年5月(60岁)患脑瘤”。成员关系为父亲，患病名称为脑瘤，患病年龄为60岁，患病时间为2005年5月。

放射物品接触史：用于记录放射物品接触信息。其属性包括接触时间、接触描述、放射物品名称。例如“2015年3不小心吸入少量氡气”。接触时间为“2015年3月”，放射物品名称为“氡气”，接触描述为“不小心接触少量氡气”。

接种史：用于记录病人接种信息。其属性有接种物品名称、接种时间、接种描述。若接种分为多次接种，则记录为多条记录。例如“2021年1月第一次接种新冠疫苗，2021年2月第二次接种新冠疫苗无均无不良反应”。第一条接种史信息为：接种物品为“新冠疫苗”，接种时间为“2021年1月”，接种描述为“无不良反应”。第二条接种史信息为：接种物品为“新冠疫苗”，接种时间为“2021年2月”，接种描述为“无不良反应”。

过敏史：用于记录用户一些过敏情况。其属性有过敏原、过敏描述、过敏开始时间、过敏结束时间。例如“2011年3月开始对花粉过敏，吸入少量花粉则全身痒”，过敏原为“花粉”，过敏开始时间为“2011年3月”，过敏描述为“吸入少量花粉则全身痒”，过敏结束时间为空表示一直处于过敏状态。

婚育情况：记录病人的婚育情况。其属性为开始时间，结束时间，以及婚育描述，婚姻阶段。考虑到病人会有多次婚育，固使用开始时间和结束时间来区分时间段。例如“2011年5月结婚，育有一儿一女，均健康”。开始时间为“2011年5月”，结束时间留空，婚育描述为“育有一儿一女均健康”，婚姻阶段为“一婚”。若后期再有子嗣等情况，则更新前面一条的结束时间，并新增一条婚育情况记录。

步骤二：根据步骤一所得到实体完成其逻辑模型设计。具体的逻辑模型如附图1所示，下面对逻辑模型进行说明。

电子病历是基于计算机的病人记录，故本发明以病人为中心。对于步骤一中第一类信息，为了方便将其用时间串联起来，将病人和日期进行一对多的关联。一个日期下可以确诊或推断多个疾病、实施多个治疗、进行多次就医、拥有多个症状，进行多个检查，故将日期与疾病、治疗、就医、症状、检查进行一对多的关联。一个症状可能出现多个诱因，故将症状与诱因进行一对多关联。一个治疗会采用多种药物，故治疗与药物进行一对多的关联。此外，为了保证数据完整性，本发明将就医与检查、疾病、治疗进行一对多的关联，这样就能清楚的知道此次检查、治疗是再哪次就诊时进行的；确诊或者推断出来的疾病是在哪次就诊时进行的。同时也将就医与月经信息进行一对多的关联，以便保存每次就医下患者的月经信息。将检查和疾病进行一对多的关联，方便保存某次检查推断出病人的疾病。为了将相关联的日期紧密联系在一起，每个日期都可以有一个指向另一个日期的边，用于表示本次疾病等相关联的上一个日期，例如2020年1月出现咳嗽，2020年2月咳嗽加重并检测出肺癌，最后治疗成功，2021年2月肺癌复发继续治疗。这三个时间线期间病人可能有其他症状或者疾病，例如2020年8月恶心呕吐患胃癌，为了将前三者进行紧密关联，可以将日期2021年2月指向日期2020年2月，将日期2020年2月指向日期2020年1月。对于步骤一种第二类信息，由于其与病人疾病的发展演变没有直接联系，故将其直接与病人想关联。

步骤三物理模型设计。利用步骤二设计好的逻辑模型，本发明将其运用到Neo4j图数据库之中。将本发明逻辑模型中的病人、放射物品接触史、月经信息、工作史、疾病、接种史、就医、家族史、诱因、日期、过敏史、检查、居住史、嗜好、症状、治疗、婚育、药物这些类别全部作为Neo4j图数据库中的节点，逻辑模型中的边对应数据库中有向边进行存储。此外，为了能够高效的根据症状查询与之相似的症状，本发明为症状节点的症状属性创建了全文索引。

步骤四系统开发。为了提供友好的展示界面，方便用户进行电子病历录入和修改。本发明开发了电子病历系统。本系统主要采用前后端分离架构。前端负责提供用户可视化界面，后端响应前端请求做出响应处理并返回给前端响应数据。本发明的电子病历结构化存储方案是以病人为中心，故本系统构建电子病历主要分成2个步骤。

步骤1病人信息管理。病人信息管理是指对病人的基本信息进行管理，例如病人的姓名、出生年月等。本发明提供给用户搜索病人姓名的功能，通过输入病人姓名查询出相应的病人信息，同时提供对病人进行信息修改的功能。本系统也提供了新增病人的功能，通过输入病人基本信息将病人基本信息录入步骤二所提供的Neo4j图数据库之中。查询病人和新增(修改)病人信息如图2和图3所示。

步骤2病人病历信息管理。步骤1中选中需要查看的病人，点击查看病历，后端将该病人所有相关的电子病历信息返回给前端进行展示，展示效果如图4所示。同时本发明提供新增节点、新增关系、删除节点、删除关系、编辑节点功能。本发明通过状态来控制新增节点、编辑节点等功能的使能状态。状态主要分为初始状态、选中节点状态、选中边状态、新增节点状态、编辑节点状态、新增关系状态、选择第一个节点状态。初始状态使能新增节点、新增关系。选中节点状态使能删除边按钮，选中节点状态使能编辑节点和删除节点，具体的状态转换图如图5所示。

病人病历信息管理主要有以下几个功能。

查询病人所有信息：进入病人详情页面时则查询出与改病人相关的所有节点和边。通过病人id为过滤条件，快速找到病人节点，再从该节点出发寻找四层以内的所有边和节点返回到前段进行渲染显示。

新增节点：点击新增节点按钮，显示新增节点界面如图6所示。选择左侧不同的节点类型，填写不同的节点信息，点击确认即可将该节点保存至数据库，同时前端界面也将显示刚才新增的节点。

编辑节点：点击节点进入选中节点状态，再点击编辑节点，回显相应节点的节点信息，修改需要修改的信息，点击确认即可更新图数据库中的数据并且前端该节点的显示信息也得到了修改。

删除节点：点击节点进入选中节点状态，再点删除节点。数据库删除该节点并删除与该节点相关联的边，前端也同时删除该节点以及与其相关联的边，最终进入初始状态。

新增关系：点击新增关系进入新增关系状态，由于本发明所设计的后结构化存储结构并非所有节点可以相连，固点击第一个节点之后本发明系统提示可选的结束节点类型(如图7所示)，再根据提示点击第二个节点,后端数据库中添加相应类型的边，同样前端同步增加相应的边。若未按照相应的提示选择相应类型的边，那么将提示类型错误的提示。

删除关系：点击想要删除的边进入选中边状态，再点击删除边。数据库删除该边，同时前端显示也删除对应的边最终返回初始状态。

查看病人患病时间线：点击查看病人时间线按钮弹出病人不同时间段所进行的治疗、就医、症状、检查等信息。同查询病人所有信息一样，也是从病人id出发查询相关联所有节点。再将节点进行过滤，筛选出所有时间节点，再通过时间节点进行找到每个时间节点的症状、就医、治疗等信息进行封装，最后在前端按照时间轴的形式进行展示，如图8所示。

查看相似症状病人：点击图8时间线中症状右侧查看相似病人按钮，查询与之有相似症状的最相似的几个病人，如图9所示。为了提高查询效率，避免全症状节点扫描，本发明为症状节点的症状属性建立了全文索引。调用全文索引的数据库过程查询出最相似的几个症状节点，再查找通过日期节点到该症状节点有边的病人节点。例如某患者的症状为“胸疼、气短”则所使用的cypher查询语句为db.index.fulltext.queryNodes("symptomFullIndex","胸疼、气短")YIELD node with id(node)as NodeId match(p:Patient)-->(d:EventDate)-->(s:Symptom)where id(s)＝NodeId return p limit 10

应当理解，虽然本说明书根据实施方式加以描述，但是并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为了清楚起见，本领域的技术人员应当将说明书作为一个整体，各个实施方式中的技术方案也可以适当组合，按照本领域技术人员的理解来实施。

上文所列出的一系列详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用于限制本发明的保护范围，凡是未脱离发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。