CN106997575A - 一种医患关系管理系统的处理方法 - Google Patents

一种医患关系管理系统的处理方法 Download PDF

Info

Publication number
CN106997575A
CN106997575A CN201710086589.5A CN201710086589A CN106997575A CN 106997575 A CN106997575 A CN 106997575A CN 201710086589 A CN201710086589 A CN 201710086589A CN 106997575 A CN106997575 A CN 106997575A
Authority
CN
China
Prior art keywords
patient
doctor
relation
preliminary examination
relationship
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.)
Pending
Application number
CN201710086589.5A
Other languages
English (en)
Inventor
江伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guahao Net Hangzhou Technology Co Ltd
Original Assignee
Guahao Net Hangzhou Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Guahao Net Hangzhou Technology Co Ltd filed Critical Guahao Net Hangzhou Technology Co Ltd
Priority to CN201710086589.5A priority Critical patent/CN106997575A/zh
Publication of CN106997575A publication Critical patent/CN106997575A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/22—Social work or social welfare, e.g. community support activities or counselling services
    • G06F19/32—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Primary Health Care (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Child & Adolescent Psychology (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)

Abstract

本发明是一种医患关系管理系统，特别涉及一种医患关系管理系统的处理方法。按以下步骤进行：医患关系处理目的→医患关系结构分析→医患关系的设计原则→医患关系功能操作流程。一种医患关系管理系统的处理方法更加便于管理，多角度查询。

Description

一种医患关系管理系统的处理方法
技术领域
本发明是一种医患关系管理系统，特别涉及一种医患关系管理系统的处理方法。
背景技术
随着微医业务的发展，业务越来越庞大和复杂，原来的系统承载了太多的业务，无法单独的发展，以及横向和纵向的扩展。维护和开发也变的越来越难。为了满足业务发展的需要，势必要切成各种微服务，来满足业务增长带来的各业务的协作要求。
医患关系做为比较独立的业务，就在此环境中被切分了出来，成立了医患关系管理系统。从而为后续微医业务的横向扩展提供了解决方案。
另一方面，医生和患者的关系随着业务的发展也正在发生各种变化，其本身的需求和复杂度也在提升。本身业务的重要性也变得越来越大，为了更好满足微医对于医患关系的管理，把其作为一个单独的系统独立出来也变的势在必行；
发明内容
本发明主要是解决现有技术中存在的不足，能保证整体系统的高可用性和稳定性的一种医患关系管理系统的处理方法。
本发明的上述技术问题主要是通过下述技术方案得以解决的：
一种医患关系管理系统的处理方法，按以下步骤进行：
(一)、医患关系处理目的：
建设高可用，海量数据，扩展方便的医患关系系统，实现医患关系的沉淀和行为分析，及管理；
医患关系系统主要实现以下目标：
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患者足迹：
患者足迹功能是指医患系统整合所有事件，对患者的主要业务进行按时间线展示。

Claims (1)

1.一种医患关系管理系统的处理方法，其特征在于按以下步骤进行：(一)、医患关系处理目的：
建设高可用，海量数据，扩展方便的医患关系系统，实现医患关系的沉淀和行为分析，及管理；
医患关系系统主要实现以下目标：
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患者足迹：
患者足迹功能是指医患系统整合所有事件，对患者的主要业务进行按时间线展示。
CN201710086589.5A 2017-02-17 2017-02-17 一种医患关系管理系统的处理方法 Pending CN106997575A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710086589.5A CN106997575A (zh) 2017-02-17 2017-02-17 一种医患关系管理系统的处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710086589.5A CN106997575A (zh) 2017-02-17 2017-02-17 一种医患关系管理系统的处理方法

Publications (1)

Publication Number Publication Date
CN106997575A true CN106997575A (zh) 2017-08-01

Family

ID=59431032

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710086589.5A Pending CN106997575A (zh) 2017-02-17 2017-02-17 一种医患关系管理系统的处理方法

Country Status (1)

Country Link
CN (1) CN106997575A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111524584A (zh) * 2020-04-23 2020-08-11 湖北亲缘互联传承网络有限公司 一种医生经线上甄选自己专长病患并预约的就医系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102663511A (zh) * 2012-04-17 2012-09-12 苏州风采信息技术有限公司 一种医院门诊网上预约系统
CN102708415A (zh) * 2012-04-17 2012-10-03 苏州风采信息技术有限公司 一种医院预约挂号系统
CN103353959A (zh) * 2013-06-29 2013-10-16 上海交通大学医学院附属新华医院 一种用于急诊预检分诊的移动终端、系统及方法
CN103632227A (zh) * 2013-11-26 2014-03-12 吴谨准 一种儿科急诊预检分诊系统及分诊方法
CN105719214A (zh) * 2016-03-16 2016-06-29 镇江市第一人民医院 一种挂号转诊系统及其方法
CN105869097A (zh) * 2016-05-26 2016-08-17 丁腊春 一种基于云平台的o2o医疗信息系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102663511A (zh) * 2012-04-17 2012-09-12 苏州风采信息技术有限公司 一种医院门诊网上预约系统
CN102708415A (zh) * 2012-04-17 2012-10-03 苏州风采信息技术有限公司 一种医院预约挂号系统
CN103353959A (zh) * 2013-06-29 2013-10-16 上海交通大学医学院附属新华医院 一种用于急诊预检分诊的移动终端、系统及方法
CN103632227A (zh) * 2013-11-26 2014-03-12 吴谨准 一种儿科急诊预检分诊系统及分诊方法
CN105719214A (zh) * 2016-03-16 2016-06-29 镇江市第一人民医院 一种挂号转诊系统及其方法
CN105869097A (zh) * 2016-05-26 2016-08-17 丁腊春 一种基于云平台的o2o医疗信息系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111524584A (zh) * 2020-04-23 2020-08-11 湖北亲缘互联传承网络有限公司 一种医生经线上甄选自己专长病患并预约的就医系统

Similar Documents

Publication Publication Date Title
Brown et al. VistA—US department of veterans affairs national-scale HIS
Altuwaijri Electronic-health in saudi arabia
Choi et al. MobileMed: a PDA-based mobile clinical information system
CN104601688A (zh) 一种无线远程医疗系统
WO2005008558A2 (en) Terminology management system
Al-Sakran Framework architecture for improving healthcare information systems using agent technology
Kuhn et al. Expanding the scope of health information systems
CN103839125A (zh) 医院信息一体化管理平台系统
Kanter et al. Millennium global village-net: Bringing together millennium villages throughout sub-Saharan Africa
CN106997575A (zh) 一种医患关系管理系统的处理方法
CN109545320A (zh) 基于数据处理的取药异常确定方法和终端设备
Abdullah et al. Enhancement of the cervical cancer screening program in Malaysia: a qualitative study
US20180046768A1 (en) System for tracking patient wait times at a healthcare clinic
Oluoch et al. Do interoperable national information systems enhance availability of data to assess the effect of scale-up of HIV services on health workforce deployment in resource-limited countries?
Dixon et al. Facilitating HIE in Denmark: the story of MedCom, a Danish health information organization
Lesselroth et al. Naturalistic usability testing of inpatient medication reconciliation software
Moahi ICT and health information in Botswana: towards the Millennium Development Goals
Kuo et al. The implement of RFID in emergency medicine
CN113113099A (zh) 一种伤员后送系统
CN114282880A (zh) 一种业务办理引导方法及其装置、计算机可读存储介质
CN112990506A (zh) 针对检测的预约方法、装置、设备及可读存储介质
Xiao et al. Developing a standard protocol for clinical data exchange and analysis
CN109545339A (zh) 一种医疗资源管理方法、服务器及系统
US20080004911A1 (en) System and method for processing health information
Rivett et al. The Cell-Life Project: Converging technologies in the context of HIV/AIDS

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
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20170801