一种医患关系管理系统的处理方法与流程

本发明是一种医患关系管理系统，特别涉及一种医患关系管理系统的处理方法。

背景技术：

随着微医业务的发展，业务越来越庞大和复杂，原来的系统承载了太多的业务，无法单独的发展，以及横向和纵向的扩展。维护和开发也变的越来越难。为了满足业务发展的需要，势必要切成各种微服务，来满足业务增长带来的各业务的协作要求。

医患关系做为比较独立的业务，就在此环境中被切分了出来，成立了医患关系管理系统。从而为后续微医业务的横向扩展提供了解决方案。

另一方面，医生和患者的关系随着业务的发展也正在发生各种变化，其本身的需求和复杂度也在提升。本身业务的重要性也变得越来越大，为了更好满足微医对于医患关系的管理，把其作为一个单独的系统独立出来也变的势在必行；

技术实现要素：

本发明主要是解决现有技术中存在的不足，能保证整体系统的高可用性和稳定性的一种医患关系管理系统的处理方法。

本发明的上述技术问题主要是通过下述技术方案得以解决的：

一种医患关系管理系统的处理方法，按以下步骤进行：

(一)、医患关系处理目的：

建设高可用，海量数据，扩展方便的医患关系系统，实现医患关系的沉淀和行为分析，及管理；

医患关系系统主要实现以下目标：

1)建立一个能够管理医患关系的关系平台，能对微医主流业务的医患关系进行沉淀分析；

2)建立一个开放和基于标准的架构体系，能对上层业务系统提供良好的访问接口api；

3)提供一个方便扩展的解决方案框架，已满足微医后续业务的发展需要；

4)对于线上的出现的问题能够快速感知、定位并解决；

5)建立一个高可用，低延时，海量数据处理的高可用系统；

面向的使用人员：

1)公司上层各业务系统；

2)数据仓库的开发人员；

3)公司运营人员；

4)各个关联系统开发人员；

(二)、医患关系结构分析：

为了更好的实现医患管理的需求，需要对那些关系需要进行管理，哪些关系不需要进行管理，有个比较清晰的界线；

而对已经建立关系的数据又要分类管理，比如有些关系一旦建立是不允许解除的，有些关系可以解除，有些关系是有时效性的，过了某个时间点会自动失效；

在关系的基础上，又存在主流业务的分类，及疾病、治疗、症状相关标签的标识；满足多维度多视角的关系查询及分析；

需要划分为以下几个主要功能模块：

1)医患业务数据收集模块；

2)数据的分析沉淀模块；

3)数据的高效查询模块；

4)特定业务功能模块；

(三)、医患关系的设计原则：

数据收集模块的设计原则为：

1)数据源要可靠，稳定；

2)消息处理效率要高；

3)有标准通用的模型来处理；

数据收集通过发布/订阅模式的消息中间件来实现；

数据的发布方通过标准的消息中间件协议，定义微医规范的消息体进行事件的发送；接受方订阅该事件，在获取事件数据后，对数据进行处理；

消息中间件方式使发送方可以异步的进行程序处理，提升了程序的效率，和消息传输的可靠性；

分析沉淀模块的设计原则为：

1)通用的可灵活扩展的抽取规则；

2)流程事件消息处理的高效性；

3)良好的底层数据存储设计，可持续性可扩展；

分析沉淀模块采取合理的分层结构，各层职责明确；逻辑清晰；分层的优

点就是可以灵活适配业务改变，可以根据需要灵活的扩展；

数据查询模块的设计原则为：

1)支持高并发的访问要求；

2)暴露的接口尽量简洁清晰，职责明确；

特定业务模块目前有：

1)患者报到；

2)自建患者；

3)重点关注；

4)随访开关；

(四)、医患关系功能操作流程：

医患关系系统(epms)会根据不同的业务对关系进行分类，目前有持久性关系和临时性关系；

持久性关系：

是指一旦业务发生并建立医患关系，是不允许解除的；比如预约挂号产生的医患关系，一旦建立了就成事实，不能人为的解除关系；

临时性关系：

是指临时性业务产生的医患关系，有一定的时效性，或者由其他业务触发解除关系；比如：医院预检关系，首先护士会触发建立医生和患者的预检关系，一旦过了指定时间患者没有去预约，或者患者已经预约成功，这个关系就自动失效了；

总体流程说明：

1)事件收集模块通过mq对各事件进行收集并处理；

2)对指定的事件抽取医患关系并保存；

3)对特殊的关系创建标签；

4)对这些数据进行结构化处理，高效的提供查询接口服务；

4.1预约挂号抽取医患关系流程：

在用户预约挂号后，会产生这个用户患者和他挂号去就诊的医生的关系；这种关系就是预约挂号产生的医患关系，并且患者会在预约挂号时描述疾病相关信息，这些信息可以抽取成标签关联到产生的医患关系上；

流程说明：

1)患者在微医进行预约挂号业务下单成功；

2)epms接收到了该事件，建立了医患关系；

3)异步：患者在这个过程中进行病情主诉完善，通知epms；

4)异步：医生在完成现场诊断后，填写医生诊断，通知epms；

5)异步：患者自己新增病例，通知epms；

4.2自建患者转诊流程：

转诊时医生选择患者进行操作，如果该患者没有注册微医账号，则转诊无法进行下去，这时需要医生自建一个患者进行转诊；

流程说明：

1)医生在转诊时发现该患者不是微医注册患者；

2)填入患者基本信息，新建该患者；

3)新建成功，发起转诊，进入预约挂号流程；

4)预约挂号成功，通知epms；

4.3预检关系流程：

预检关系是指，用户首先提交一个预检单(而不是直接看到排班)，预检单会提交到医院护士那里，然后由护士来给患者分配医生名片，患者只能点击这个医生名片对应的医生排班进行预约挂号；

说明：

流程一：患者还没有经过预检台：

1)患者点击某个医生的排班详情页，appserver请求预检关系查询接口；

2)医患系统返回预检关系查询结果；

3)appserver对结果进行判断，a.如果没有预检关系，或者预检关系已失效,跳转到预检台；b.如果有预检关系并且有效，进入排班详情页走下单流程；

流程二：患者经过了预检台，护士发送了医生名片；

1)护士发送医生名片给了患者，appserver调用医患的建立预检关系接口，建立预检关系；(state＝有效)

2)患者点击医生名片，appserver调用预检关系查询接口；

3)检查预检关系是否在有效期内(默认24小时)，如果超过了有效期，更新预检关系为失效，返回结果；

4)appserver检查返回的结果：a.预检关系无效，跳转到预检台；b.预检关系有效，走下单流程；

异步：

5)医患系统监听ws的下单mq，如果是配置的医院(上海市儿童医院)的订单，进入下面流程；

6)以该订单中的expert_uuid+patientid去查询是否有预检关系：a.有，把预检关系置为无效，返回结果；b.没有，程序继续；

4.4患者报到：

患者报到是指患者主动对自己想要去预约挂号的医生提交病情描述相关基础信息，从而建立医患关系，方便后续的就诊以及复诊；

流程说明：

1)患者端申请报到；

2)患者填写疾病信息、其他基本信息，进行提交；

3)医生端接收到患者提交的报到申请，决定【接收】/【忽略】；

4)如果医生接收请求，医患系统会建立两者的医患关系；

4.5患者足迹：

患者足迹功能是指医患系统整合所有事件，对患者的主要业务进行按时间线展示。

因此，本发明提供的一种医患关系管理系统的处理方法，更加便于管理，多角度查询。

附图说明

图1是本发明的功能结构设计图；

图2是本发明epms与其他系统的关系图；

图3是本发明的总体流程图；

图4是本发明中预约关系抽取医患流程图；

图5是本发明中自建患者转诊流程图；

图6是本发明中预检关系流程图；

图7是本发明中患者报到流程图。

具体实施方式

下面通过实施例，并结合附图，对本发明的技术方案作进一步具体的说明。

实施例：如图1、图2、图3、图4、图5、图6和图7所示，一种医患关系管理系统的处理方法，按以下步骤进行：

(一)、医患关系处理目的：

建设高可用，海量数据，扩展方便的医患关系系统，实现医患关系的沉淀和行为分析，及管理；

医患关系系统主要实现以下目标：

6)建立一个能够管理医患关系的关系平台，能对微医主流业务的医患关系进行沉淀分析；

7)建立一个开放和基于标准的架构体系，能对上层业务系统提供良好的访问接口api；

8)提供一个方便扩展的解决方案框架，已满足微医后续业务的发展需要；

9)对于线上的出现的问题能够快速感知、定位并解决；

10)建立一个高可用，低延时，海量数据处理的高可用系统；

面向的使用人员：

1)公司上层各业务系统；

2)数据仓库的开发人员；

3)公司运营人员；

4)各个关联系统开发人员；

(二)、医患关系结构分析：

为了更好的实现医患管理的需求，需要对那些关系需要进行管理，哪些关系不需要进行管理，有个比较清晰的界线；

而对已经建立关系的数据又要分类管理，比如有些关系一旦建立是不允许解除的，有些关系可以解除，有些关系是有时效性的，过了某个时间点会自动失效；

在关系的基础上，又存在主流业务的分类，及疾病、治疗、症状相关标签的标识；满足多维度多视角的关系查询及分析；

需要划分为以下几个主要功能模块：

5)医患业务数据收集模块；

6)数据的分析沉淀模块；

7)数据的高效查询模块；

8)特定业务功能模块；

(四)、医患关系的设计原则：

数据收集模块的设计原则为：

4)数据源要可靠，稳定；

5)消息处理效率要高；

6)有标准通用的模型来处理；

数据收集通过发布/订阅模式的消息中间件来实现；

数据的发布方通过标准的消息中间件协议，定义微医规范的消息体进行事件的发送；接受方订阅该事件，在获取事件数据后，对数据进行处理；

消息中间件方式使发送方可以异步的进行程序处理，提升了程序的效率，和消息传输的可靠性；

分析沉淀模块的设计原则为：

4)通用的可灵活扩展的抽取规则；

5)流程事件消息处理的高效性；

6)良好的底层数据存储设计，可持续性可扩展；

分析沉淀模块采取合理的分层结构，各层职责明确；逻辑清晰；分层的优点就是可以灵活适配业务改变，可以根据需要灵活的扩展；

数据查询模块的设计原则为：

3)支持高并发的访问要求；

4)暴露的接口尽量简洁清晰，职责明确；

特定业务模块目前有：

5)患者报到；

6)自建患者；

7)重点关注；

8)随访开关；

(五)、医患关系功能操作流程：

医患关系系统(epms)会根据不同的业务对关系进行分类，目前有持久性关系和临时性关系；

持久性关系：

是指一旦业务发生并建立医患关系，是不允许解除的；比如预约挂号产生的医患关系，一旦建立了就成事实，不能人为的解除关系；

临时性关系：

是指临时性业务产生的医患关系，有一定的时效性，或者由其他业务触发解除关系；比如：医院预检关系，首先护士会触发建立医生和患者的预检关系，一旦过了指定时间患者没有去预约，或者患者已经预约成功，这个关系就自动失效了；

总体流程说明：

5)事件收集模块通过mq对各事件进行收集并处理；

6)对指定的事件抽取医患关系并保存；

7)对特殊的关系创建标签；

8)对这些数据进行结构化处理，高效的提供查询接口服务；

4.1预约挂号抽取医患关系流程：

在用户预约挂号后，会产生这个用户患者和他挂号去就诊的医生的关系；这种关系就是预约挂号产生的医患关系，并且患者会在预约挂号时描述疾病相关信息，这些信息可以抽取成标签关联到产生的医患关系上；

流程说明：

6)患者在微医进行预约挂号业务下单成功；

7)epms接收到了该事件，建立了医患关系；

8)异步：患者在这个过程中进行病情主诉完善，通知epms；

9)异步：医生在完成现场诊断后，填写医生诊断，通知epms；

10)异步：患者自己新增病例，通知epms；

4.2自建患者转诊流程：

转诊时医生选择患者进行操作，如果该患者没有注册微医账号，则转诊无法进行下去，这时需要医生自建一个患者进行转诊；

流程说明：

5)医生在转诊时发现该患者不是微医注册患者；

6)填入患者基本信息，新建该患者；

7)新建成功，发起转诊，进入预约挂号流程；

8)预约挂号成功，通知epms；

4.3预检关系流程：

预检关系是指，用户首先提交一个预检单(而不是直接看到排班)，预检单会提交到医院护士那里，然后由护士来给患者分配医生名片，患者只能点击这个医生名片对应的医生排班进行预约挂号；

说明：

流程一：患者还没有经过预检台：

1)患者点击某个医生的排班详情页，appserver请求预检关系查询接口；

2)医患系统返回预检关系查询结果；

3)appserver对结果进行判断，a.如果没有预检关系，或者预检关系已失效,跳转到预检台；b.如果有预检关系并且有效，进入排班详情页走下单流程；

流程二：患者经过了预检台，护士发送了医生名片；

1)护士发送医生名片给了患者，appserver调用医患的建立预检关系接口，建立预检关系；(state＝有效)

2)患者点击医生名片，appserver调用预检关系查询接口；

3)检查预检关系是否在有效期内(默认24小时)，如果超过了有效期，更新预检关系为失效，返回结果；

4)appserver检查返回的结果：a.预检关系无效，跳转到预检台；b.预检关系有效，走下单流程；

异步：

5)医患系统监听ws的下单mq，如果是配置的医院(上海市儿童医院)的订单，进入下面流程；

6)以该订单中的expert_uuid+patientid去查询是否有预检关系：a.有，把预检关系置为无效，返回结果；b.没有，程序继续；

4.4患者报到：

患者报到是指患者主动对自己想要去预约挂号的医生提交病情描述相关基础信息，从而建立医患关系，方便后续的就诊以及复诊；

流程说明：

4)患者端申请报到；

5)患者填写疾病信息、其他基本信息，进行提交；

6)医生端接收到患者提交的报到申请，决定【接收】/【忽略】；

4)如果医生接收请求，医患系统会建立两者的医患关系；

4.5患者足迹：

患者足迹功能是指医患系统整合所有事件，对患者的主要业务进行按时间线展示。