CN114743625B - 一种电子健康档案管理方法、系统及计算机存储介质 - Google Patents
一种电子健康档案管理方法、系统及计算机存储介质 Download PDFInfo
- Publication number
- CN114743625B CN114743625B CN202210387606.XA CN202210387606A CN114743625B CN 114743625 B CN114743625 B CN 114743625B CN 202210387606 A CN202210387606 A CN 202210387606A CN 114743625 B CN114743625 B CN 114743625B
- Authority
- CN
- China
- Prior art keywords
- electronic health
- cloud
- doctor
- information
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/113—Details of archiving
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
Abstract
本申请涉及医疗服务的技术领域,尤其是涉及一种电子健康档案管理方法、系统及计算机存储介质,其包括:患者通过用户端建立电子健康档案,电子健康档案至少包括患者实名个人信息、就诊医院信息、就诊医师信息、医疗全过程信息、个人健康数据;云端接收电子健康档案,并将电子健康档案进行存储;医师端经过用户端的权限允许后,从云端内获取电子健康档案,并对电子健康档案进行查看、更新、推送等,并再将电子健康档案发送至云端内。本申请具有提高对电子健康档案的统一管理的效果。
Description
技术领域
本申请涉及医疗服务的技术领域,尤其是涉及一种电子健康档案管理方法、系统及计算机存储介质。
背景技术
目前随着科技的不断发展,过去患者去医院就医时采用的纸质病历档案已经被淘汰,取而代之的是电子健康档案,通过联网的电子健康档案,用户可以更方便快捷的对电子健康档案内的内容进行查看,以得知自身的医疗服务信息、健康状态等。
目前对于依附于互联网来使用的电子健康档案都是以分散式存储在个人用户及相对应的医院的电子档案库内,而没有一个完善的电子健康档案管理平台去对这些电子健康档案进行同一管理和调用,使得用户或医生在使用电子健康档案去进行诊断或查看时有较大的麻烦,且因为无法对数量庞大的电子健康档案进行统一管理,使得医生与患者进行交互时,对接效率较低且步骤繁琐。
发明内容
为了提高对电子健康档案的统一管理效果,本申请提供一种电子健康档案管理方法、系统及计算机存储介质。
第一方面,本申请提供的一种电子健康档案管理方法,采用如下的技术方案:
一种电子健康档案管理方法,包括以下步骤:
患者通过用户端建立电子健康档案,所述电子健康档案至少包括患者实名个人信息、就诊医院信息、就诊医师信息、医疗全过程信息、个人健康数据;
云端接收所述电子健康档案,并将所述电子健康档案进行存储;
医师端经过用户端的权限允许后,从所述云端内获取所述电子健康档案,并对电子健康档案进行查看、更新、推送等,并再将所述电子健康档案发送至所述云端内。
在其中一些实施例中,所述云端将所述电子健康档案进行存储包括:
根据所述电子健康档案内的就诊医院信息对所述电子健康档案进行一次分区;
将经过一次分区后的所述电子健康档案根据所述电子健康档案内的医疗全过程信息对所述电子健康档案进行二次分区,所述医疗全过程信息包括患者就诊的类型和科室;
将经过二次分区后的所述电子健康档案根据所述电子健康档案内的就诊医师信息进行三次分区。
在其中一些实施例中,所述医师端经过权限允许后,从所述云端内获取所述电子健康档案包括:
医师端向所述云端发送调用请求,所述调用请求包括医生个人信息;
所述云端判断所述调用请求中的医生个人信息与所述电子健康档案所处的分区内的就诊医师信息是否匹配;
若匹配,则通过所述调用请求;
若不匹配,则不通过所述调用请求。
在其中一些实施例中,当云端通过所述调用请求后,包括以下步骤:
所述调用请求还包括权限开关选项,所述云端将所述调用请求转送至用户端;
所述用户端接收所述调用请求,所述用户端根据所述调用请求中的医生个人信息选择是否对所述权限开关选项进行通过;
若所述用户端通过所述权限开关选项,则所述用户端向所述云端发送允许指令,所述云端接收到允许指令后将所述患者的电子健康档案发送至所述医师端;
若所述用户端不通过所述权限开关选项,则所述用户端向所述云端发送不允许指令,所述云端将所述不允许指令发送至所述医师端。
在其中一些实施例中,所述医师端对电子健康档案进行查看、更新包括以下步骤:
所述医师端对电子健康档案内的内容进行修改时,所述医师端向所述云端发送相应的更新指令,其中,所述更新指令预先按照重要性程度设置有权重值;
所述云端接收所述更新指令,并将所述更新指令相对应的权重值与阈值进行比较;
若所述权重值大于所述阈值,则所述云端根据所述更新指令对所述电子健康档案进行实时修改更新,并将更新后的电子健康档案发送至用户端,同时将被修改更新前的数据进行存储;
若所述权重值小于所述阈值,则所述云端将所述更新指令存储在所述电子健康档案所对应的更新等候区,所述更新等待区表征为用于临时存储权重值小于阈值的电子健康档案的区域,当所述患者登录用户端时,所述云端根据所述更新等待区内的更新指令对所述患者的电子健康档案进行更新,并将更新后的电子健康档案发送至用户端,同时将被修改更新前的数据进行存储。
在其中一些实施例中,所述云端将所述更新指令存储在所述电子健康档案所对应的更新等候区,包括以下步骤:
根据所述更新指令的权重值对所述更新指令进行排序,权重值较高的更新指令放置在所述更新等待区的前端,权重值较低的更新指令放置在所述更新等待区的末端,其中,所述更新等待区的前端表征于所述云端优先根据所述更新指令对所述电子健康档案进行修改更新的一端。
在其中一些实施例中,所述云端根据预设时间对所述云端内的电子健康档案进行数据清除,并根据清除的数据制作清理清单,并根据所述电子健康档案内的患者实名个人信息将所述清理清单发送至相对应的用户端。
在其中一些实施例中,所述云端根据预设时间对所述云端内的电子健康档案进行数据清除,包括以下步骤:
判断所述电子健康档案内被修改更新前的数据是否满足允许存储条件内,所述允许存储条件包括存储时间条件、存储次数条件等;
若不满足允许存储条件,则将所述电子健康档案内被修改更新前的数据进行数据清理;
若满足允许存储条件,则继续将所述电子健康档案内被修改更新前的数据进行存储。
第二方面,本申请提供的一种电子健康档案管理系统,采用如下的技术方案:
一种电子健康档案管理系统,包括用户端、云端和医师端,所述用户端连接于所述云端,所述医师端连接于所述云端,所述云端包括存储模块和权限模块,其中,
所述用户端用于供患者建立电子健康档案,所述电子健康档案至少包括患者实名个人信息、就诊医院信息、就诊医师信息、医疗全过程信息、个人健康数据等;
所述云端用于接收所述电子健康档案,并将所述电子健康档案存储在存储模块中;
所述医师端通过所述权限模块获得权限,并从所述云端内的存储模块内获取所述电子健康档案,并对电子健康档案进行查看、更新等,并再将所述电子健康档案发送至所述云端内。
第三方面,本申请提供的一种计算机可读存储介质,采用如下的技术方案:
一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述任一项电子健康档案管理方法。
综上所述,本申请至少包括以下有益技术效果:
患者通过用户端建立电子健康档案,电子健康档案内包括实名个人信息、就诊医院信息、就诊医师信息、医疗全过程信息、个人健康数据等内容,建立后的电子健康档案被统一存储在云端,其中每个患者的就诊医院、就诊医生都是不同的,云端则会将所有电子健康档案进行同一管理,而不是将电子健康档案分别存储在不同医院的库中,提高了同一管理能力,提高管理效果,而医生则可以在用过权限后,通过医师端对这些电子信息档案进行查看、更新、推送等。
附图说明
图1是本申请实施例中的流程图;
图2是本实施例中云端对电子健康档案进行存储时的流程图;
图3是本实施例中医师端获取查看电子健康档案权限时的逻辑判断示意图;
图4是本实施例中医师端对电子健康档案进行更新时的示意图;
图5是本申请实施例中云端对电子健康档案进行清除时的示意图。
具体实施方式
以下结合附图1-5对本申请作进一步详细说明。
本申请实施例公开一种电子健康档案管理方法。
如图1所示,一种电子健康档案管理方法包括以下步骤:
S100,患者通过用户端建立电子健康档案。
电子健康档案至少包括患者实名个人信息、就诊医院信息、就诊医师信息、医疗全过程信息、个人数据。
用户端为患者自身使用的平台,每个用户端皆对应于一个患者的个人健康档案数据。
患者实名个人信息包括患者的姓名、性别、身份证号、电话号、一名或多名亲人的手机号、生日、照片等个人信息。实名个人信息为代表患者个人的基本信息,后续也作为患者登录自己的电子健康档案的实名验证基础。
就诊医院信息包括患者就诊的医院的院名、地址、电话等信息,代表了患者就诊的医院。当患者去过多家医院进行治疗时,相对应的,就诊医院信息中含有所有就诊过的医院信息。
就诊医师信息包括对患者进行医学治疗、医学诊断、医学问询的医生的个人信息,如姓名、职称、专业名等。当患者有多名就诊的医生时,相对应的,就诊医师信息中含有多有就诊过的医师信息。
医疗全过程信息包括患者就诊时的电子病例信息和历史就诊信息,电子病例信息是患者在医院诊断治疗的全过程的原始记录,包含首页、病历记录、检查检验结果、医嘱、手术记录、护理记录、开药记录等。历史就诊信息包括患者历史挂号信息、就诊医师名、门诊日志等。
个人健康数据包括患者的身高体重、血压、血氧、血糖、患有的疾病种类、影像报告等在医院进行测量或检查检验出的健康指数,用于使患者对自身的健康程度进行查看。
其中,电子健康档案中各项数据具有关联性,即当患者当A医院就诊时,电子健康档案中的数据按照A医院的B医生对患者进行了C项检查,并展示了C项检查得出的检查结果D。每家医院的每个医生做得每个检查都一一对应且相互独立,方便患者进行查看。
患者在第一次注册电子健康档案且没有使用电子健康档案进行就诊时,只需在注册时填写患者实名个人信息即可,后续其他信息会随着就诊过程而进行更新。患者在注册电子健康档案时可以选择后续登录的方式,如设置密码、使用实名信息如身份证、电话号、刷脸等方式进行登录,进行登录后可以反复查看自己的电子健康档案中的内容。
S200,云端接收电子健康档案,并将电子健康档案进行存储。
云端为公有云服务,为一个通过现有技术搭建的云平台,用于对电子健康档案的数据进行储存及各类处理。
如图2所示,进一步的,云端对电子健康档案进行存储还包括以下步骤:
S210,根据电子健康档案内的就诊医院信息对电子健康档案进行一次分区。
S220,将经过一次分区后的所有电子健康档案再根据电子健康档案内的医疗全过程信息对电子健康档案进行二次分区。
其中,医疗全过程信息包括患者就诊的类型和相对应的科室。
S230,将经过二次分区后的电子健康档案再根据电子健康档案内的就诊医师信息进行三次分区。
例如在一次分区时,将就诊医院为A医院、B医院和C医院的电子健康档案进行一次分区,将三个医院的电子健康档案分别分区进行储存,即A医院的所有电子健康档案储存在一个区间,B医院的所有电子健康档案储存在一个区间,C医院的电子健康档案储存在一个区间。
然后对这些经过一次分区的方案进行二次分区。电子健康档案中存在患者就诊过的类型和科室,如患有糖尿病的患者需要在内分泌门诊进行就诊,所以类型为糖尿病,科室为内分泌科;又例如高血压患者需要在心血管门诊进行就诊,那么类型为高血压,科室为心血管内科,以此类推。由此看出,在二次分区时,电子健康档案会根据科室和类型分为两层,第一层为科室,第二层为具体患病类型。
最后因每个科室有多名医生,所以还需要对经过二次分区的电子健康档案进行三次分区,三次分区时根据电子健康档案中的就诊医师信息进行分区,如心血管内科的医生有医生A、医生B、医生C,则每个医生分为一类,将这个医生的所有患者的电子健康档案进行同一分区并与其他医生的患者的电子健康档案进行隔离。
例如,第一人民医院为一个区间,第二人民医院为一个区间,协和医院为一个区间,而第一人民医院下分为心血管内科区间、骨科区间、内分泌科区间,而心血管内科区间又分为心脏病区间、高血压区间,而高血压区间又分有A医生、B医生、C医生等等。而一个患者,他在第二人民医院就诊,需要治疗的是肺炎,就诊医师是H医生,云端便会根据电子健康档案中的这些信息将电子健康档案按照多次分区的方式精确的进行存储,这种分区方式不仅提高了云端对数量庞大的电子健康档案的分类、存储、管理,也使得医生或患者在找寻电子健康档案时可以更加清晰的进行查询。而当个别患者的电子健康档案发生错误、损坏、丢失时,管理云端的后台人员也可以根据电子健康档案内的信息对档案进行精准路径的查找,而不必在混乱、数量庞大的电子健康档案中进行大海捞针的工作。
其中需要注意的是,当用户刚刚建立电子健康档案时,因其电子健康档案内不存在就诊医院信息、医疗全过程信息和就诊医师信息,故这时不会对电子健康档案进行分区,而是把所有刚刚建立的电子健康档案进行统一单独管理,而当某个电子健康档案中出现了就诊医院信息、医疗全过程信息和就诊医师信息信息后,再将电子健康档案进行相对应的分区。
S300,医师端经过用户端的权限允许后,从云端内获取电子健康档案,并对电子健康档案进行查看、更新、推送等,并再将电子档案发送至云端内。
医师端为供医生所使用的平台。
其中,权限指的是医生可以获取电子健康档案以进行查看、更新、推送的限制,只有用户端解除了限制,医师端才可以获取电子健康档案,如用户端没有解除限制,则医师端无法获取电子健康档案。
查看是指医生获取到患者的电子健康档案都可以对电子健康档案内的内容进行观察。
更新是指医生获取到患者的电子健康档案后,可以根据检查检验出的结果、患病过程中各阶段等对电子健康档案中的医疗全过程信息及个人健康数据进行修改更新,例如检查检验结果、医嘱、手术记录、护理记录、血压指数、血糖指数等等。
推送是指医生根据患者的实时健康数据对患者推送相关的康复计划、医学知识等内容,医师端将这些内容进行推送后,这些内容将自动存储在电子健康档案中,后续可以通过用户端对这些内容进行查看。
如图3所示,医生经过权限允许后,从云端获取电子健康档案包括:
S310,医师端向云端发送调用请求,调用请求中包括医生个人信息。
S320,云端判断调用信息中的医生个人信息与电子健康档案所处的分区内的就诊医师信息是否匹配。
S321,若匹配,则通过调用请求;若不匹配,则不通过调用请求。
因每个患者的电子健康档案是具有隐私性的,故需要对查看患者的电子健康档案进行权限限制。当患者自己进行查看时,使用前文中的密码、身份证、电话号等实名信息、刷脸等方式。而医师端在获取患者的电子健康档案时则需要取得权限。
而当一名患者就诊过A医生和B医生后,只有A医生和B医生可以对患者的电子健康档案进行查看,而其他医生是没有权限对这名患者的电子健康档案进行查看。
当A医生使用自己的医师端向云端发送调用请求,且这个调用请求中包括A医生的医生个人信息,医生个人信息包括医生的姓名、职称、专业名等,如心血管内科教授A某某。
云端接收到调用请求后,会将调用请求中的医生个人信息与电子健康档案中所处分区内的就诊医师信息进行比较判断,若电子健康档案中的就诊医师信息中存在心血管内科教授A某某,则说明两者相匹配,云端通过调用请求,若电子健康档案中的就诊医师信息中不存在心血管内科教授A某某,则说明两者不匹配,云端不通过调用请求。
通过这种方法,云端先对调用请求进行一次筛选,判断医生查看的是不是自己就诊过的患者的电子健康档案,如果是的话,则云端通过调用请求,并发送至用户端。
S330,调用请求还包括权限开关选项,云端将调用请求转送至用户端。
S340,用户端接收调用请求,用户端根据调用请求中的医生个人信息选择是否对权限开关选项进行通过。
S341,若用户端通过权限开关选项,则用户端向云端发送允许指令,云端接收允许指令后将患者的电子健康档案发送至医师端。
S342,若用户端不通过权限开关选项,则用户端向云端发送不允许指令,云端接收到不允许指令后再将不允许指令发送至医师端。
当云端用过调用请求后,云端将调用请求转送至相对应的患者的用户端。其中,调用请求除了医生个人信息,还包括权限开关选项,权限开关选项用于使患者通过用户端对医师端发出的调用请求做出选择,选择通过或不通过。当用户端使用手机等移动设备时,权限开关选项可以为手机上可以进行选择交互的页面,页面上显示是“是”、“否”、“通过”、“不通过”等相关字样,同时医生个人信息也同步显示在相关页面上。
患者使用用户端对调用信息中的医生个人信息进行查看,查看后选择是否通过调用请求。
如果用户端通过了权限开关选项,则用户端向云端发送允许指令,云端接收允许指令后将患者的电子健康档案发送至医师端,医师端便可以获得患者的电子健康档案并对其进行查看、更新等。
如果用户端没有通过权限开关选项,则用户端向云端发送不允许指令,云端接收不允许指令后再将不允许指令发送至医师端。
进一步的,当用户端不通过权限开关选项时,患者可以填写一些不允许的理由,这些理由可以随不允许指令一同发送至医师端。
其中,权限开关选项通过的方式也很多,如验证码、选项交互等等。如当医生发出调用请求后,云端向用户端的手机号上发送验证码短信,而当患者因没有看到信息或更换手机号时,为了保证调用信息的及时性,可以通过在电子健康档案中寻找其他个人联系方式的方式进行验证,如发送至家人的手机号上等等。
如图4所示,当医师端对电子健康档案进行查看、更新包括以下步骤:
S350,医师端对电子健康档案内的内容进行修改时,医师端向云端发送相应的更新指令,其中,更新指令预先按照重要性程度设置有权重值。
重要性程度是根据多方面内容所判定的。如当患者对自己的心血管功能进行检查时,检查结果必然是重要性程度最高的,这时就赋予检查结果最高的权重,而随着检查结果一起的还包括挂号信息、缴费信息、取药信息、医嘱等,根据权重值由高到低可以排列为检查结果-取药信息-医嘱-缴费信息-挂号信息等。
而进行手术后,手术记录的权重值又会大于检查结果,根据不同情况,经过长时间的运营后,根据实际经验选择赋予权重值的方法。
S351,云端接收更新指令,并将更新指令相对应的权重值与阈值进行比较。
阈值是云端运营人员经过长时间的训练和实际使用后得出的一个权重平均值,在阈值以下的更新指令代表着其重要性不高,可以延后进行处理,而阈值以上的更新指令代表着其重要性较高,需要被及时处理。
S352,若权重值大于阈值,则云端根据更新指令对电子健康档案进行实时修改更新,并将更新后的电子健康档案发送至用户端,同时将被修改更新前的数据进行存储。
S353,若权重值小于阈值,则云端将更新指令存储在电子健康档案所对应的更新等待区,当患者登录用户端时,云端根据更新等待区内的更新指令对患者的电子健康档案进行更新,并将更新后的电子健康档案发送至用户端,同时将被修改前的数据进行存储。
更新等待区表征为用于临时存储权重值小于阈值的电子健康档案的区域。
如果当权重值大于阈值时,说明这一条更新指令较为重要,需要进行及时更新,这时会在医生进行修改发出更新指令的同时,云端实时对电子健康档案内的内容进行修改更新,如当患者的检查结果出来时,医生需要将检查结果的数据更新在电子健康档案当中,这时医生在修改时,云端判断出这条更新指令的权重值大于阈值,这时便实时对电子健康档案中的数据进行更新。
而当权重值小于阈值时,说明这一条更新指令的重要性较低,无需进行实时更新。这时会将更新指令先存储在电子健康档案相对应的更新等待区,等待用户端上线时,云端再对更新指令进行更新。如当患者因病在医院中买药,买完药,医生将药物信息、吃药时间、吃药注意事项、药品金额输入到电子健康档案中进行更新,这时医生往往会将药物信息、吃药时间、吃药注意事项预先告知患者且为了患者以往而要实时进行更新,而药品金额患者往往在付款后并不会特意关注,这时,药品金额更新的这一条更新指令的权重值明显低于阈值,所以不需要将药品金额这一项进行实时更新,而是储存在更新等待区内,等患者下一次再使用用户端进行登录时,云端再将药品金额信息进行更新。
这样做筛选了一部分高权重的更新指令和一部分低权重的更新指令,除了患病较为严重或患有慢性疾病需要每天查看电子健康档案的患者外,大部分患有感冒、发烧等病症的患者往往在使用过一次电子健康档案后,会在较长的时间内皆不去登录电子健康档案,这种情况下,所有更新指令都实时进行更新,会大大增加云端的运算工作量,而一些长时间不登录的电子健康档案或因为一些原因不再使用的电子健康档案,云端可以减少这类电子健康档案的更新频率,先过滤掉大部分重要性较低的更新指令,减少云端的云端工作量,而将更多的运算精力投入到临床重症患者的电子健康档案建设中。
其中,默认医师端对电子健康档案内的数据进行更新时,用户端会收到更新的通知。
更新后将被更新前的数据进行存储是为了方便患者和医生查看各种数据的动态变化,方便医生对后续治疗进行规划,也方便患者对自身健康问题进行观察。
进一步的,当医生使用医师端向患者的用户端推送相关的康复计划和医学知识等时,同样会有权重值的比较,例如康复计划的权重值是高于阈值的,当到了某个阶段或某个时间点需要改变康复内容时,云端将推送内容进行实时更新推送;而医学知识的权重明显低于阈值,因为患者往往不会特意关注医学知识,这时当有新的医学知识进行更新推送时,只有当用户端再次登录时,云端才将医学知识推送至用户端。
当患者对某些数据更新或某些内容的推送较为关注,而这些数据或内容的权重值低于阈值,可以通过用户端对这些数据或内容进行标记,经过标记后的数据或内容的权重值便会高于阈值,而得到实时更新。
云端将更新指令存储在电子健康档案所对应的更新等待区,还包括以下步骤:
S354,根据更新指令的权重值对更新指令进行排序,权重值较高的更新指令放置在更新等待区的前端,权重值较低的更新指令放置在更新等待区的末端。
其中,更新等待区的前端表征于云端优先根据更新指令对电子健康档案进行修改更新的一端,反之,更新等待区的末端表征于云端最后根据更新指令对电子健康档案进行修改更新的一端。
当处于更新等待区内的更新指令的数量大于两个时,显然更新指令会在更新等待区内形成队列,并根据队列的顺序,在用户端登录时以此进行更新,而这时权重值较高的更新指令便会位于更新等待区的前端,也就是队列的前端,而优先进行处理,而权重值较低的更新指令便会位于更新等待区的末端,也就是队列的末端,而较晚进行处理。
如图5所示,且在云端长时间的运营过程中,依然会有大量的电子健康档案频繁地进行更新、推送等服务,而在更新、推送过程中,有很多垃圾数据、过期数据、无用数据堆积在云端内,这时就需要对云端内地电子健康档案进行数据清楚,包括以下步骤:
S400,云端根据预设时间对云端内的电子健康档案进行数据清除,并根据清除的数据制作清理清单,并根据电子健康档案内的患者实名个人信息将清理清单发送至相对应的用户端。
清理清单内包括云端所有要进行清除的数据的名称、大小、最后更新的时间等。
云端定期将可以进行清理的数据进行清除,以此减少云端内数量庞大的电子健康档案的数据存储量,且在进行清除的同时,将清理清单发送至用户端供患者查看。
进一步的,当患者看到清理清单中包含有不想进行清除的数据,用户端可以对云端发出指令,以使云端对这些数据进行保留。
S410,判断电子健康档案内被修改更新前的数据是否满足允许存储条件内。
S411,若不满足允许存储条件,则将电子健康档案内被修改前的数据进行数据清理。
S412,若满足允许存储条件,则继续将电子健康档案内被修改更新前的数据进行存储。
允许存储条件包括存储时间条件、存储次数条件等。
存储时间条件表征于一个被修改更新前的数据,也就是历史数据在云端内存储的时间是否处于允许存储的时间限制内。如当一份数据在4月5日17:00发生更新,那么被修改更新前的数据,也就是历史数据将从4月5日17:00作为起始时间点,如果规定被修改更新前的数据允许存储24小时,那么在4月6日17:00之前的时间内,该历史数据处于允许存储的时间限制内,那么该数据继续被云端存储,但从4月6日17:01之后,该数据不处于允许存储的时间限制之内,那么便不满足允许存储条件,在下次到达定时清理的时候,该数据将会被清除。
存储次数条件表征于一个被修改更新前的数据,也就是历史数据在云端内被存储的次数是否处于允许存储的次数限制内。如规定允许存储的次数为5次,而一项数据先后更新了5次,A更新一次变成A1,并将A作为被修改更新前的数据进行存储;A1更新一次变成A2,并将A1作为被修改更新前的数据进行存储,一次类推,更新5次后,最新的数据为A5,而A、A1、A2、A3、A4这五项作为被修改更新前的数据,也就是历史数据进行存储,这时已经到达了允许存储的次数,所以在清理数据时A、A1、A2、A3、A4这五项是不会被清除的,当又发生了一次更新后,最新的数据变成了A6,而A、A1、A2、A3、A4、A5则被被存储,这时存储的数据的次数便大于了允许存储的次数限制,所以需要清理其中的一项数据,按照时间先后顺序将最早的数据进行清除,也就是数据A。
通过这种方法将一些无用的、多余的数据进行清除。有些情况下,很多患者会在病情痊愈后的长时间内都不会登录或使用电子健康档案,这时频繁的更新和推送会使得云端的存储量大大增大,这时就需要对长时间不用的或数据量过多的数据进行清除。
在另一个实施例中,公开了一种电子健康档案管理系统,包括用户端、云端和医师端。用户端连接于云端,医师端连接于云端,云端包括存储模块和权限模块。
用户端用于供患者建立电子健康档案,用户端在本实施例中为供患者通过移动端使用的APP平台。
云端用于接收电子健康档案,并将电子健康档案存储在存储模块中。云端为服务云平台,是基于技术人员运营的平台。
医师端通过权限模块获取权限,并从云端内的存储模块内获取电子健康档案,并对电子健康档案进行查看、更新等,并再将电子健康档案发送至云端内。医师端在本实施例中为供医生通过移动端使用的APP平台。
进一步的,云端内还包括更新模块、推送模块和清除模块。更新模块基于医师端发出的更新指令而对电子健康档案内的数据进行更新,推送模块基于医师端的操作而向电子健康档案所对应的用户端发送康复计划、医学知识等内容,清除模块用于定时清除电子健康档案内的垃圾数据、无用数据等。
其中,用户端和医师端上都各自具有特有的功能。
如用户端上有在线问诊功能,相对的,医师端上具有在线答诊功能,患者通过在线问诊功能进行问诊,问诊的内容通过云端转送至相应的医生的医师端上,医生接收到问诊的内容后通过在线答诊的功能对患者的问题进行答复,并将答复的内容通过云端进行转送至用户端。
再例如,用户端上具有医疗保健查看功能、医院医生信息浏览功能、康复食谱、康复运动打卡功能等等,而医师端则具有提醒复诊功能、学术交流功能等等。
在另一个实施例中,还公开了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现上述的健康档案管理方法。
实施原理为:
患者通过用户端建立电子健康档案,电子健康档案内包括实名个人信息、就诊医院信息、就诊医师信息、医疗全过程信息、个人健康数据等内容,建立后的电子健康档案被统一存储在云端,其中每个患者的就诊医院、就诊医生都是不同的,云端则会将所有电子健康档案进行同一管理,而不是将电子健康档案分别存储在不同医院的库中,提高了同一管理能力,提高管理效果,而医生则可以在用过权限后,通过医师端对这些电子信息档案进行查看、更新、推送等。
以上均为本申请的较佳实施例,并非依此限制本申请的保护范围,故:凡依本申请的结构、形状、原理所做的等效变化,均应涵盖于本申请的保护范围之内。
Claims (5)
1.一种电子健康档案管理方法,其特征在于:包括以下步骤:
患者通过用户端建立电子健康档案,所述电子健康档案至少包括患者实名个人信息、就诊医院信息、就诊医师信息、医疗全过程信息、个人健康数据;
云端接收所述电子健康档案,并将所述电子健康档案进行存储,具体的:
根据所述电子健康档案内的就诊医院信息对所述电子健康档案进行一次分区;
将经过一次分区后的所述电子健康档案根据所述电子健康档案内的医疗全过程信息对所述电子健康档案进行二次分区,所述医疗全过程信息包括患者就诊的类型和科室;
将经过二次分区后的所述电子健康档案根据所述电子健康档案内的就诊医师信息进行三次分区;
医师端经过用户端的权限允许后,从所述云端内获取所述电子健康档案,并对电子健康档案进行查看、更新、推送,并再将所述电子健康档案发送至所述云端内;
所述医师端经过权限允许后,从所述云端内获取所述电子健康档案包括:
医师端向所述云端发送调用请求,所述调用请求包括医生个人信息;
所述云端判断所述调用请求中的医生个人信息与所述电子健康档案所处的分区内的就诊医师信息是否匹配;
若匹配,则通过所述调用请求;
若不匹配,则不通过所述调用请求;
所述调用请求还包括权限开关选项,所述云端将所述调用请求转送至用户端;
所述用户端接收所述调用请求,所述用户端根据所述调用请求中的医生个人信息选择是否对所述权限开关选项进行通过;
若所述用户端通过所述权限开关选项,则所述用户端向所述云端发送允许指令,所述云端接收到允许指令后将所述患者的电子健康档案发送至所述医师端;
若所述用户端不通过所述权限开关选项,则所述用户端向所述云端发送不允许指令,所述云端将所述不允许指令发送至所述医师端;
所述医师端对电子健康档案进行查看、更新包括以下步骤:
所述医师端对电子健康档案内的内容进行修改时,所述医师端向所述云端发送相应的更新指令,其中,所述更新指令预先按照重要性程度设置有权重值;
所述云端接收所述更新指令,并将所述更新指令相对应的权重值与阈值进行比较;
若所述权重值大于所述阈值,则所述云端根据所述更新指令对所述电子健康档案进行实时修改更新,并将更新后的电子健康档案发送至用户端,同时将被修改更新前的数据进行存储;
若所述权重值小于所述阈值,则所述云端将所述更新指令存储在所述电子健康档案所对应的更新等候区,所述更新等候区表征为用于临时存储权重值小于阈值的电子健康档案的区域,当所述患者登录用户端时,所述云端根据所述更新等候区内的更新指令对所述患者的电子健康档案进行更新,并将更新后的电子健康档案发送至用户端,同时将被修改更新前的数据进行存储;
所述云端将所述更新指令存储在所述电子健康档案所对应的更新等候区,包括以下步骤:
根据所述更新指令的权重值对所述更新指令进行排序,权重值较高的更新指令放置在所述更新等候区的前端,权重值较低的更新指令放置在所述更新等候区的末端,其中,所述更新等候区的前端表征于所述云端优先根据所述更新指令对所述电子健康档案进行修改更新的一端。
2.根据权利要求1所述的一种电子健康档案管理方法,其特征在于:所述云端根据预设时间对所述云端内的电子健康档案进行数据清除,并根据清除的数据制作清理清单,并根据所述电子健康档案内的患者实名个人信息将所述清理清单发送至相对应的用户端。
3.根据权利要求2所述的一种电子健康档案管理方法,其特征在于:所述云端根据预设时间对所述云端内的电子健康档案进行数据清除,包括以下步骤:
判断所述电子健康档案内被修改更新前的数据是否满足允许存储条件内,所述允许存储条件包括存储时间条件、存储次数条件;
若不满足允许存储条件,则将所述电子健康档案内被修改更新前的数据进行数据清理;
若满足允许存储条件,则继续将所述电子健康档案内被修改更新前的数据进行存储。
4.一种电子健康档案管理系统,引用权利要求1所述的一种电子健康档案管理方法,其特征在于:包括用户端、云端和医师端,所述用户端连接于所述云端,所述医师端连接于所述云端,所述云端包括存储模块和权限模块,其中,
所述用户端用于供患者建立电子健康档案,所述电子健康档案至少包括患者实名个人信息、就诊医院信息、就诊医师信息、医疗全过程信息、个人健康数据;
所述云端用于接收所述电子健康档案,并将所述电子健康档案存储在存储模块中;
所述医师端通过所述权限模块获得权限,并从所述云端内的存储模块内获取所述电子健康档案,并对电子健康档案进行查看、更新,并再将所述电子健康档案发送至所述云端内。
5.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至3中任一项所述的健康档案管理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210387606.XA CN114743625B (zh) | 2022-04-14 | 2022-04-14 | 一种电子健康档案管理方法、系统及计算机存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210387606.XA CN114743625B (zh) | 2022-04-14 | 2022-04-14 | 一种电子健康档案管理方法、系统及计算机存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114743625A CN114743625A (zh) | 2022-07-12 |
CN114743625B true CN114743625B (zh) | 2022-12-02 |
Family
ID=82282008
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210387606.XA Active CN114743625B (zh) | 2022-04-14 | 2022-04-14 | 一种电子健康档案管理方法、系统及计算机存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114743625B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117313062B (zh) * | 2023-11-22 | 2024-02-27 | 广州市挖米科技有限责任公司 | 一种医疗电子健康档案授权共享与管理系统 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010052638A1 (en) * | 2008-11-04 | 2010-05-14 | Jessie Dias-Alf | Electronic health record management method and system |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102043982A (zh) * | 2009-10-13 | 2011-05-04 | 西尼卡那国际咨询(北京)有限公司 | 面向居民个人的电子健康档案系统 |
TW201419005A (zh) * | 2012-11-14 | 2014-05-16 | Inst Information Industry | 雲端檔案存取系統、方法及其電腦可讀取紀錄媒體 |
US10424033B2 (en) * | 2013-03-15 | 2019-09-24 | Breg, Inc. | Healthcare practice management systems and methods |
CN104317956A (zh) * | 2014-11-13 | 2015-01-28 | 北京奇虎科技有限公司 | 基于云端服务器的查询、存储空间清理方法和系统 |
CN104766024B (zh) * | 2015-03-13 | 2017-10-27 | 河南群智信息技术有限公司 | 基于云平台的医疗系统病例信息存储调用方法 |
CN109273064A (zh) * | 2018-09-17 | 2019-01-25 | 东南大学 | 一种基于生物标识的电子健康档案系统 |
CN109559812B (zh) * | 2018-12-05 | 2021-09-03 | 易必祥 | 基于移动互联网的医生咨询方法及系统 |
CN109887566B (zh) * | 2019-02-26 | 2020-12-18 | 卫宁健康科技集团股份有限公司 | 电子健康档案的智能管理方法及系统 |
CN112115463A (zh) * | 2019-06-20 | 2020-12-22 | 深圳迈瑞生物医疗电子股份有限公司 | 医疗监护系统及其患者信息访问方法、存储介质 |
CN110993122A (zh) * | 2019-11-01 | 2020-04-10 | 广东炬海科技股份有限公司 | 一种基于云计算的医疗健康信息管理系统 |
CN111653327A (zh) * | 2020-05-29 | 2020-09-11 | 上海电机学院 | 一种基于微信小程序的云病历系统 |
CN112185522A (zh) * | 2020-09-27 | 2021-01-05 | 上海联影医疗科技股份有限公司 | 一种信息处理方法、装置及终端 |
CN112905882A (zh) * | 2021-02-07 | 2021-06-04 | 厦门兆信物之联智能科技有限公司 | 一种基于大数据挖掘的电子健康档案服务的云平台门户系统 |
CN114334063A (zh) * | 2021-12-31 | 2022-04-12 | 华南理工大学 | 一种医疗病历分级管理系统 |
-
2022
- 2022-04-14 CN CN202210387606.XA patent/CN114743625B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010052638A1 (en) * | 2008-11-04 | 2010-05-14 | Jessie Dias-Alf | Electronic health record management method and system |
Non-Patent Citations (2)
Title |
---|
A Web-Based System for Family Health Record;Stefano Bonacina 等;《2007 29th Annual International Conference of the IEEE Engineering in Medicine and Biology Society》;20071022;第3652-3656页 * |
居民电子健康档案管理平台研究与设计;张红伟等;《医学信息学杂志》;20160925(第09期);第52-56页 * |
Also Published As
Publication number | Publication date |
---|---|
CN114743625A (zh) | 2022-07-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8527295B2 (en) | System and method for aggregating and providing subscriber medical information to medical units | |
US9147041B2 (en) | Clinical dashboard user interface system and method | |
US6450956B1 (en) | System and method for treatment and outcome measurement analysis | |
JP5636588B2 (ja) | 救急患者治療支援システム | |
US20030200119A1 (en) | Method and system for accessing healthcare information using an anatomic user interface | |
JP2005522768A5 (zh) | ||
WO2003087996B1 (en) | System for collecting storing presenting and analyzing immunization data having remote stations in communication with a vaccine and disease database over a network | |
US20090248445A1 (en) | Patient database | |
CA2470027A1 (en) | Management systems and methods | |
JP2002132952A (ja) | 慢性病と健康のオンラインを管理する方法及びシステム | |
WO2014042942A1 (en) | Clinical dashboard user interface system and method | |
US20110313258A1 (en) | Method and apparatus for soliciting an expert opinion from a care provider and managing health management protocols | |
US20160098542A1 (en) | Medical diagnosis and treatment support apparatus, system, and method | |
US20080103814A1 (en) | System and method for an integrated disease management system | |
CN112488858A (zh) | 一种慢病数据管理方法和系统 | |
US20210151140A1 (en) | Event Data Modelling | |
CN114743625B (zh) | 一种电子健康档案管理方法、系统及计算机存储介质 | |
US20080114613A1 (en) | Integrated Electronic Healthcare Management System | |
Takkar et al. | Development of Diabetic retinopathy screening guidelines in South-East Asia region using the context, challenges, and future technology | |
US20180308584A1 (en) | Acute care predictive analytics tool | |
US20040193447A1 (en) | Website messaging system for public health information | |
US20220262529A9 (en) | Clinical Notifications | |
CN113724846A (zh) | 就诊数据处理方法、装置、存储介质及设备 | |
Hamid et al. | Telemedicine for healthier community development in Pakistan | |
US20060031093A1 (en) | Computerized method and system for communicating agreements and/or discrepancies in image interpretation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |