一种查询血液信息的方法及应用服务器的制造方法

文档序号:10471109阅读:360来源:国知局
一种查询血液信息的方法及应用服务器的制造方法
【专利摘要】本发明公开了一种查询血液信息的方法,所述方法包括:应用服务器接收终端用户发送的血液查询请求,所述血液查询请求至少携带血型信息;所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器查询血液库是否需要提供所述血型信息的相应血液;所述应用服务器接收所述数据库服务器发送的响应信息,所述响应信息携带所述血液库中需要提供相应血液的标识;所述应用服务器将所述响应信息发送给所述终端,以使所述终端用户实时根据血液库的需求进行献血。本发明同时还公开了一种应用服务器。
【专利说明】
一种查询血液信息的方法及应用服务器
技术领域
[0001]本发明涉及电子技术,尤其涉及一种查询血液信息的方法及应用服务器。
【背景技术】
[0002]目前血站对于血液的需求情况信息主要依靠传统方式每日公布。比如,在采血点门口公告板上,每天公布每种血型当天的血液需求量信息,采血点一般设置在火车站前、商业步行街等人流较密集的地区。另一种方式是通过当地传统社会媒体,比如广告大屏幕等发布信息。除此之外,如果用户想要主动查询血液需求情况,部分城市的血液中心(以下简称血站)也提供了电话查询的方式。
[0003]现有的血液需求信息发布方案有很多的问题:
[0004]第一,用户获取血液需求信息困难,由于血液需求信息不能通过互联网渠道查询,只能通过小黑板、广告等传统媒体进行非实时性的发布,信息覆盖范围较小,信息受众有限。而对于想要了解需求信息而又不在血液采集点的用户来说,获取信息较为困难。
[0005]第二,血液需求信息实时性差,血液的使用情况常常由于突发事件的发生而需求量波动非常大。血液的流转、使用情况需要及时更新发布给公众,否者公众无法把握最新的血液需求情况。
[0006]第三,降低了公众的献血意识。目前很多城市出现献血量低,血液资源极度紧张的情况。然而,这种情况很大程度上是因为公众获取信息不便捷,获取信息的成本较高造成的,对于曾经有过献血经验的人,不了解当前血液需求的急迫程度;对于很多初次的献血者,不了解献血地点、流程、福利政策、禁忌等相关信息,对献血持有怀疑态度甚至是恐惧感,这就令公众难以形成献血意识和习惯。
[0007]第四,对于特殊血型的献血者,这部分用户属于需要特殊记录的用户,因为特殊血型的血量往往极为稀缺,当出现突发情况时,需要紧急联系这些人来献血。但是这就带来了两个问题:一方面,血站对特殊血型用户信息记录不全,只有曾经献过血的用户,血站才知道信息,只能通过血站来搜集这部分人的信息,而缺乏用户主动汇报信息的渠道,即使是血站记录的用户信息也会随着用户手机号码变更,家庭住址变更等生活信息的变更而带来信息失效的情况,如果用户联系方式变更,即使愿意献血也联系不上。另一方面,发生紧急状况时,血站联系多个献血者时,不知道哪些人距离近,哪些人距离远,只能通过打电话沟通的方式,而这种依次打电话沟通的方式具有很强的随机性,往往找到的不是距离最近的献血者,造成了时间的延误,增加了患者的抢救时间。
[0008]第五,献血者对自身曾经的献血经历无法查询,不便于合理地安排献血周期和献血的频率,也无法联系血站做献血预约和献血提醒。
[0009]第六,当某种血型出现库存危机,难以满足需求时,血站缺乏更好的向公众发布信息的有效渠道,也难以做到按照需要的血型信息发出精确通知,浪费了大量宝贵时间。

【发明内容】

[0010]有鉴于此,本发明实施例为解决现有技术中存在的至少一个问题而提供一种查询血液信息的方法及应用服务器,能够及时公布血液信息,从而挽救患者的生命。
[0011]本发明实施例的技术方案是这样实现的:
[0012]第一方面,本发明实施例提供一种查询血液信息的方法,所述方法包括:
[0013]应用服务器接收终端发送的血液查询请求,所述血液查询请求至少携带血型信息;
[0014]所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0015]所述应用服务器接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0016]所述应用服务器将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0017]第二方面,本发明实施例提供一种应用服务器,所述应用服务器包括第一接收单元、第一发送单元、第二接收单元和第二发送单元,其中:
[0018]所述第一接收单元,用于接收终端发送的血液查询请求,所述血液查询请求至少携带血型信息;
[0019]所述第一发送单元,用于将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0020]所述第二接收单元,用于接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0021]所述第二发送单元,用于将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0022]本发明实施例提供的查询血液信息的方法及应用服务器,其中,应用服务器接收终端用户发送的血液查询请求,所述血液查询请求至少携带血型信息;所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器查询血液库是否需要提供所述血型信息的相应血液;所述应用服务器接收所述数据库服务器发送的响应信息,所述响应信息携带所述血液库中需要提供相应血液的标识;所述应用服务器将所述响应信息发送给所述终端,以使所述终端用户实时根据血液库的需求进行献血,如此,能够及时公布血液信息,从而挽救患者的生命。
【附图说明】
[0023]图1为本发明实施例三层架构的结构示意图;
[0024]图2为本发明实施例二查询血液信息的方法的实现流程示意图;
[0025]图3为本发明实施例三查询血液信息的方法的实现流程示意图;
[0026]图4为本发明实施例四查询血液信息的方法的实现流程示意图;
[0027]图5为本发明实施例五查询血液信息的方法的实现流程示意图;
[0028]图6为本发明实施例六应用服务器的实现流程示意图;
[0029]图7为本发明实施例八应用服务器的实现流程示意图;
[0030]图8为本发明实施例九应用服务器的实现流程示意图;
[0031]图9为本发明实施例十查询血液信息的方法的实现流程示意图。
【具体实施方式】
[0032]下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。
[0033]实施例一
[0034]本发明实施例提供一种查询血液信息的方法,该方法是基于互联网技术和位置技术实现血液信息实时查询,以及用户与血液中心需求信息的平台(以下简称血液中心平台)进行血液信息交互的方法。为实现上述的查询血液信息的方法,本发明实施例先提供一种血液信息公布系统,图1为本发明实施例三层架构的结构示意图,如图1所示,该系统采用三层架构,该三层架构包括位于IN区域的数据库、位于DMZ区域的应用服务器,位于OUT区域的应用客户端,各个区域之间通过网络防火墙隔离,其中IN区域(inside区)也叫内区,是网络安全区,安全级别最高,需要重点保护;一些重要的办公设备比如数据库服务器一般都需要放在IN区;DMZ区域是为了解决安装防火墙后外部网络不能访问内部网络服务器的问题,而设立的一个非安全系统与安全系统之间的缓冲区,这个缓冲区位于企业内部网络和外部网络之间的小网络区域内;0UT区域(outside区)也叫外区,是公共网络,安全级别最低,OUT区需要暴露在互联网上,以便广泛互联网用户能够访问,不过相应的承受的网络攻击最多。其中:
[0035]数据库:数据库系统记录了献血者档案和全部的血液流转信息。献血者档案记录着曾经献过血的用户信息,或者虽然没有献过血但有献血意愿的用户信息。用户信息可以是用户曾经通过客户端上提交的用户信息,或者,血液中心平台的系统管理员录入的用户信息,其中,客户端在通过应用服务器与数据库通讯。血液流转信息要能够实时精确地记录每份血液的各项流转信息,血液流转信息包括血液的血型、提供者、入库时间、存放地点、状态、使用时间等。考虑到数据的安全性,需要把核心数据库放在血站局域网IN区内。需要说明的是,数据库可以位于数据库服务器上,数据库服务器可以根据应用服务器发送的查询请求查询与所述查询请求相匹配的血液流转信息,例如,用户通过终端向应用服务器发送查询请求,应用服务器查询相应的血液流转信息,然后将血液流转信息发送给终端;当然应用服务器还可以只发送请求给数据库服务器,然后由数据库服务器发起查询,以获得与所述查询请求相匹配的血液流转信息,最终由应用服务器返回给终端。其中用户可以是血液的提供者、也可以是血液的输入者(患者),当用户为血液的提供者时,所述查询请求至少包括提供者的用户身份信息,如提供者的身份证号码,这样血液的提供者就可以了解到自己献的血液最终由谁所使用;当用户为患者时,所述查询请求可以包括血液上的条形码信息,这样患者也可以了解到自己所使用的血液的相关信息。
[0036]应用服务器:应用服务器负责业务逻辑的实现。应用服务器向内与数据库相连,血液中心平台的系统管理员可以对数据库中的数据进行编辑,例如插入、修改和读取数据库中的数据。同时应用服务器需要与运营商提供的位置信息服务器相连,在紧急情况下,可以按照用户标识信息获取批量用户的位置信息,其中用户标识信息可以为用户的手机号码。应用服务器向外与应用程序客户端相连,只有通过应用程序客户端才能连接到应用服务器,为用户提供服务。应用服务器还可以连接短信网关,当有需要时会根据用户的手机号码发布需求信息。需要说明的是,献血者档案记录也可以存放于应用服务器上;当存放于应用服务器上时,应用服务器可以直接获取到用户信息,当献血者档案记录存放于数据库上时,应用服务器可以向数据库服务器发送请求以便请求用户信息。
[0037]客户端:客户端软件是血液信息向互联网开放的入口。用户通过互联网页面或手机应用程序(以下简称应用,APP)与应用服务器相连,从数据库中查询实时的血液需求量信息。普通用户可通过面向互联网普通用户的客户端进行血型登记,设置个人详细信息、献血意愿状态;用户可以输入姓名、血型、手机号码等信息,当用户设置自身状态为“愿意献血”时,血站一旦发生紧急情况继续大量的某类血型时,将主动联系这些有献血意愿的献血者;当用户认为最近自身的身体状况不佳不适宜献血时,可把自身状态设为“不愿献血”,血站将不会联系这类用户。
[0038]上述的血液信息公布系统能够实现的功能如下:
[0039]I)实现通过互联网查询当地血站需求信息的平台,便于社会大众了解最新的情况;
[0040]由于血液信息是随着患者和献血者的多少而不断动态变化的,并且这种变化没有规律,经常遇到突发情况。公众往往并非缺乏献血意识,而是缺乏最新信息。本发明实施例通过互联网技术和数据库技术,帮助公众将实时地了解各类血型的最新需求信息,当发现自己的血型库存量极低并且自己当前也有献血的意愿,身体条件也比较健康的时候,用户就可能主动去献血,其中,血型库存量极低时血站库存发出警示,以便通知用户及时献血。
[0041]2)使用位置定位技术寻找距离最近的献血者,提高了获取血液的速度和成功率;
[0042]本发明实施例可以用位置定位技术对献血者进行定位和测量路程距离。遇到紧急情况需要输血时,可以优先求助附近的用户。由于RH阴性等稀有血型分布的数量极少,当对RH阴性等稀有血型有需求时,血站和病人家属都是不惜一切代价把能够贡献这种血型的用户找到,血站和病人家属之所以要不惜一切代价是因为用血往往是人命关天的大事。以往按照掌握的电话分别打一遍的方式不是很科学,因为血站和意愿不知道这些人的当前位置,联系顺序具有很大的随机性。于是可以使用位置定位技术,通过用户手机获取位置信息,批量定位多个用户的位置在地图上同时呈现,于是就可以找到距离血液需求地点最近的用户。
[0043]3)借助互联网和数据库技术,向用户提供了登记和修改自身信息以及表示献血意愿的渠道;
[0044]用户可以在系统中等级自身的基本信息,包括:血型、年龄、联系方式、身份证号。用户还可以设置自身的献血意愿,表示了自身的意愿对于与血站的沟通非常重要。当设置意愿为“愿意献血”的时候,用户平时不必关注任何献血信息,血站可以主动联系这部分用户;当用户感觉自己最近身体不适,暂时不想献血,或者出差在外,没有条件献血的时候,就可以把自身的状态设置成“暂不愿意”,血站就不会再联系用户。
[0045]如果血站仅仅掌握曾经去过血站献血的用户,那么用户的数量就会很有限的。让用户能自主地录入和修改个人信息能够大幅度地增加血液来源;并且用户能够更新自己的联系方式,对于维护信息的有效性具有重要作用。除此之外,用户还可以通过该系统查询以往自身献血经历以及可享受到的政策等信息。
[0046]实施例二
[0047]基于上述的实施例一,本发明实施例提供一种查询血液信息的方法,应用于上述的应用服务器,图2为本发明实施例二查询血液信息的方法的实现流程示意图,如图2所示,所述方法包括:
[0048]步骤201,应用服务器接收终端发送的血液查询请求,所述血液查询请求至少携带血型信息;
[0049]这里,用户通过终端发送包括血型信息的血液查询请求,用户在身体状态良好的时候决定献血,然后通过手机将血液查询请求发送给应用服务器,该血液查询请求中携带有用户自己的血型信息。其中,终端可以为智能手机、平板电脑、台式机电脑、笔记本电脑等设备。
[0050]步骤202,所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0051]步骤203,所述应用服务器接收所述数据库服务器返回的血液查询响应;
[0052]这里,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;血液需求信息可以为与血型信息向匹配的血液量信息,血液量信息可以采用多种形式来体现,例如,A血型告急急需血源;B血型充足,暂不需要输血。
[0053]步骤204,所述应用服务器将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0054]本发明实施例中,所述方法还包括:
[0055]所述应用服务器接收终端发送的更新请求,所述更新请求包括用户身份信息,以及所述更新请求用于请求更新用户信息中的至少一项信息;
[0056]所述应用服务器获取与所述用户身份信息对应的用户信息,并根据所述更新请求同步所述与所述用户身份信息对应的用户信息。
[0057]本发明实施例中,应用服务器接收终端用户发送的血液查询请求,所述血液查询请求至少携带血型信息;所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器查询血液库是否需要提供所述血型信息的相应血液;所述应用服务器接收所述数据库服务器发送的响应信息,所述响应信息携带所述血液库中需要提供相应血液的标识;所述应用服务器将所述响应信息发送给所述终端,以使所述终端用户实时根据血液库的需求进行献血,如此,能够及时公布血液信息,从而挽救患者的生命。
[0058]本发明实施例综合使用移动互联网技术和数据库技术等多项信息技术,提供一种关于献血信息公布的方法,是互联网数据业务在医疗行业和公益事业上的应用,主要针对而日常生活中医院和血站等用血单位经常缺乏足量的献血人数而处于血液紧缺的状态,而另一方面人们对于无偿献血中各种血型需求量了解不及时,对这项公益事业想要关注却缺乏可获得信息的渠道的情况提出的解决方案。
[0059]实施例三
[0060]基于上述的实施例二,本发明实施例提供一种查询血液信息的方法,应用于上述的应用服务器,图3为本发明实施例三查询血液信息的方法的实现流程示意图,如图3所示,所述方法包括:
[0061]步骤301,应用服务器接收所述终端通过互联网网页或应用程序发送的所述血液查询请求;
[0062]步骤302,所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0063]步骤303,所述应用服务器接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0064]步骤304,所述应用服务器将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0065]本发明实施例中,所述方法还包括:
[0066]所述应用服务器接收终端发送的更新请求,所述更新请求包括用户身份信息,以及所述更新请求用于请求更新用户信息中的至少一项信息;
[0067]所述应用服务器获取与所述用户身份信息对应的用户信息,并根据所述更新请求同步所述与所述用户身份信息对应的用户信息。
[0068]实施例四
[0069]基于上述的实施例三,本发明实施例提供一种查询血液信息的方法,应用于上述的应用服务器,图4为本发明实施例四查询血液信息的方法的实现流程示意图,如图4所示,所述方法包括:
[0070]步骤401,应用服务器接收终端发送的血液查询请求,所述血液查询请求至少携带血型信息;
[0071]步骤402,所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0072]步骤403,所述应用服务器接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0073]步骤404,所述应用服务器将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0074]步骤405,所述应用服务器存储所述终端对应用户的血型信息;
[0075]步骤406,所述应用服务器定位所述用户的位置信息,并获取所述用户的用户信息;
[0076]这里,用户信息可以从献血者档案中获取,献血者档案记录着曾经献过血的用户信息,或者虽然没有献过血但有献血意愿的用户信息。
[0077]步骤407,所述应用服务器根据所述位置信息和所述用户信息向所述用户推送献血建议信息;
[0078]这里,所述献血建议信息用于使得具有所述用户信息的用户及时了解到与自己血型匹配的血液量已经不能满足需求,需要及时献血。
[0079]本发明实施例中,所述用户信息包括年龄、性别、血型、联系方式、家庭住址、当前身体状态、献血意愿、最近一次献血的时间,其中,所述当前身体状态包括身体良好和身体欠佳,所述献血意愿包括愿意献血和不愿意献血。
[0080]本发明实施例中,所述方法还包括:
[0081]所述应用服务器接收终端发送的更新请求,所述更新请求包括用户身份信息,以及所述更新请求用于请求更新用户信息中的至少一项信息;
[0082]所述应用服务器获取与所述用户身份信息对应的用户信息,并根据所述更新请求同步所述与所述用户身份信息对应的用户信息。
[0083]实施例五
[0084]基于上述的实施例,本发明实施例提供一种查询血液信息的方法,应用于上述的应用服务器,图5为本发明实施例五查询血液信息的方法的实现流程示意图,如图5所示,所述方法包括:
[0085]步骤501,应用服务器接收所述终端通过互联网网页或应用程序发送的所述血液查询请求;
[0086]这里,所述血液查询请求至少携带血型信息。
[0087]步骤502,所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0088]步骤503,所述应用服务器接收所述数据库服务器返回的血液查询响应;
[0089]这里,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0090]步骤504,所述应用服务器将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0091]步骤505,所述应用服务器存储所述终端对应用户的血型信息;
[0092]步骤506,定位所述多个用户对应的多个位置信息,计算所述多个位置信息与所述应用服务器的距离信息,判断所述距离信息是否在预设范围内,将在预设范围内的距离信息对应的位置信息确定为定位出的位置信息,并获取所述用户的用户信息;
[0093]这里,应用服务器所定位的用户的血型信息可以是普通的血型信息如A型血、B型血等,优选地,可以是稀有血型,所述稀有血型包括RH阴性血型、丽SSU血型、P血型、D缺失型血型、DUFFY血型等血型。
[0094]步骤507,根据所述位置信息和所述用户信息向所述用户推送献血建议信息。
[0095]本发明实施例中,步骤507,所述根据所述位置信息和所述用户信息向所述用户推送献血建议信息,包括:
[0096]步骤5071,确定所述位置信息的优先顺序;
[0097]这里,所述位置信息的优先顺序可以是关于距离的大小,优先顺序较高的为距离比较小的,即距离短的。
[0098]步骤5072,根据所述位置信息的优先顺序和所述用户信息,向所述用户推送献血建议信息。
[0099]本发明实施例提供的方法,借助位置技术精确地获得当前各个候选献血者的位置信息,在血站需要紧急联系特殊血型献血者时,通过位置批量获得多个候选者的位置,通过比对各个献血者距离血液需求地点的位置生成距离由短到长的候选者排序,选择距离最近的候选者联系献血,进而能够最大限度地节省寻找献血者的时间,为挽救患者生命争取宝贵的时间。
[0100]本发明实施例中,所述方法还包括:
[0101]所述应用服务器接收终端发送的更新请求,所述更新请求包括用户身份信息,以及所述更新请求用于请求更新用户信息中的至少一项信息;
[0102]所述应用服务器获取与所述用户身份信息对应的用户信息,并根据所述更新请求同步所述与所述用户身份信息对应的用户信息。
[0103]本发明实施例提供的技术方案,为用户提供了修改个人联系方式的渠道,避免因个人联系方式变更,血站无法联系到献血者的情况。
[0104]实施例六
[0105]基于前述的方法实施例,本发明实施例提供一种应用服务器,图6为本发明实施例六应用服务器的实现流程示意图,如图6所示,该应用服务器600包括第一接收单元601、第一发送单元602、第二接收单元603和第二发送单元604,其中:
[0106]所述第一接收单元601,用于接收终端发送的血液查询请求,所述血液查询请求至少携带血型信息;
[0107]所述第一发送单元602,用于将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0108]所述第二接收单元603,用于接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0109]所述第二发送单元604,用于将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0110]本发明实施例中,所述应用服务器还包括第三接收单元和第二获取单元,其中:
[0111]所述第三接收单元,用于接收终端发送的更新请求,所述更新请求包括用户身份信息,以及所述更新请求用于请求更新用户信息中的至少一项信息;
[0112]所述第二获取单元,用于获取与所述用户身份信息对应的用户信息,并根据所述更新请求同步所述与所述用户身份信息对应的用户信息。
[0113]实施例七
[0114]基于上述的实施例六,本发明实施例提供一种应用服务器,该应用服务器包括第一接收单元、第一发送单元、第二接收单元和第二发送单元,其中:
[0115]所述第一接收单元,用于接收所述终端通过互联网网页或应用程序发送的所述血液查询请求,所述血液查询请求至少携带血型信息;
[0116]所述第一发送单元,用于将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0117]所述第二接收单元,用于接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0118]所述第二发送单元,用于将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0119]实施例八
[0120]基于上述的实施例六,本发明实施例提供一种应用服务器,图7为本发明实施例八应用服务器的实现流程示意图,如图7所示,该应用服务器700包括第一接收单元701、第一发送单元702、第二接收单元703、第二发送单元704、存储单元705、定位单元706、第一获取单元707和推送单元708,其中:
[0121]所述第一接收单元701,用于接收所述终端通过互联网网页或应用程序发送的所述血液查询请求;
[0122]所述第一发送单元702,用于将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0123]所述第二接收单元703,用于接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0124]所述第二发送单元704,用于将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0125]所述存储单元705,用于存储所述终端对应用户的血型信息;
[0126]所述定位单元706,用于定位所述用户的位置信息;
[0127]所述第一获取单元707,用于获取所述用户的用户信息;
[0128]所述推送单元708,用于根据所述位置信息和所述用户信息向所述用户推送献血建议信息。
[0129]本发明实施例中,所述用户信息包括年龄、性别、血型、联系方式、家庭住址、当前身体状态、献血意愿、最近一次献血的时间,其中,所述当前身体状态包括身体良好和身体欠佳,所述献血意愿包括愿意献血和不愿意献血。
[0130]实施例九
[0131]基于上述的设备实施例,本发明实施例提供一种应用服务器,图8为本发明实施例八应用服务器的实现流程示意图,如图8所示,该应用服务器800包括第一接收单元801、第一发送单元802、第二接收单元803、第二发送单元804、存储单元805、定位单元806、第一获取单元807和推送单元808,其中,所述定位单元806包括定位模块8061、计算模块8062、判断模块8063和第一确定模块8064,其中:
[0132]所述第一接收单元801,用于接收终端发送的血液查询请求,所述血液查询请求至少携带血型信息;
[0133]所述第一发送单元802,用于将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息;
[0134]所述第二接收单元803,用于接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息;
[0135]所述第二发送单元804,用于将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。
[0136]所述存储单元805,用于存储所述终端对应用户的血型信息;
[0137]所述定位模块8061,用于定位所述多个用户对应的多个位置信息;
[0138]所述计算模块8062,用于计算所述多个位置信息与所述应用服务器的距离信息;
[0139]所述判断模块8063,用于判断所述距离信息是否在预设范围内;
[0140]所述第一确定模块8064,用于将在预设范围内的距离信息对应的位置信息确定为定位出的位置信息。
[0141]所述第一获取单元807,用于获取所述用户的用户信息。
[0142]所述推送单元808,用于根据所述位置信息和所述用户信息向所述用户推送献血建议信息;
[0143]本发明实施例中,所述推送单元808包括第二确定模块8081和推送模块8082,其中:
[0144]所述第二确定模块8081,用于确定所述位置信息的优先顺序;
[0145]所述推送模块8082,用于根据所述位置信息的优先顺序和所述用户信息,向所述用户推送献血建议信息。
[0146]实施例十
[0147]图9为本发明实施例十查询血液信息的方法的实现流程示意图,如图9所示,为了便于叙述,假设的情景是这样:假设用户是一个之前从未献过血,并有献血意愿,去了血站献了一次血之后发现自身为RH阴性血。第一次献血之后手机号码和家庭住址发生变更,用户有继续献血的意愿修改了个人信息。用户献血之后,过了一年时间,发现血站RH阴性血的库存量(库存量可以简称存量)已用完,而自身的身体状况又较好,愿意再次献血,因为这样做的话,对自己和他人都有利,于是用户发生就进行第二次献血。之后突然发生了一个紧急事件,一名RH阴性患者出现大出血,需要较多的血量。系统管理员通过位置计算发现该用户距离事发地点最近,于是依据用户预留的电话号码找到用户,用户第三次献血,其中系统管理员可以是血液中心平台的工作人员。
[0148]步骤901,了解献血地点及注意事项;
[0149]具体地,用户登陆血液信息管理平台,了解到献血的相关知识以及距离自己最近的献血地点。
[0150]步骤902,献血;
[0151]具体地,用户选择了身体状况较好的一天去血站献血。献血过程中,血站采血人员为其化验血型的时候发现其为RH阴性血型,并为其建立了献血者档案,登记了其姓名、年龄、血型、联系方式、家庭住址等用户信息。
[0152]步骤903,向应用服务器提交血液流转信息;
[0153]具体地,献血完成后,血站采血人员在血袋上贴上条形码,条形码上记录了献血信息,血站人员通过扫描条形码或者通过血站客户端录入的方式记录新增血液流转信息,新增血液流转信息被通过移动互联网络与应用服务器交互。
[0154]步骤904,更新血液流转信息;
[0155]具体地,新增加的血液流转信息通过应用服务器,记录到数据库中,血液流转信息包括血型、血量、献血者(又称血液提供者)、献血日期等信息,数据库更新各种血液的库存量信息以及需求信息。
[0156]步骤905,更新联系方式;
[0157]具体地,若用户的联系方式和家庭住址发生变更,用户通过手机APP登录到献血平台,修改了自身的联系方式和家庭住址,用户个人信息通过移动互联网记录到数据库中。
[0158]步骤906,使用血液,再次更新数据;
[0159]具体地,所述更新的数据包括血液流转信息,以及其他的信息如该血型血液的库存量以及对该血型血液的需求信息;用户的血液被患者使用,血液出库,血液存量减少。在出库时,血站系统管理员通过客户端向数据库录入血液减少信息,数据库再次更新血液的存量信息以及需求信息。
[0160]步骤907,了解需求信息;
[0161]具体地,用户可以随时登陆APP,联系主动献血;例如,时隔一年后,用户使用手机APP登录到血站信息平台,发现自己血型的库存量已接近用完,用户认为自己应该再次献血,这对于自身和他人都有益处,于是再次来到血站献血。
[0162]步骤908,第二次献血,采血后库存增加,更新数据;
[0163]具体地,用户去血站第二次献血,执行步骤203和步骤204,数据库血量信息更新。
[0164]下面给出一种血站信息平台通过位置定位搜索用户进行倡议献血的场景。
[0165]步骤909,急需大量输血;例如,一名RH阴性血型患者发生大出血事故,急需大量输血而,向血站求助。
[0166]步骤910,发现血液库存不能满足需求;
[0167]具体地,血站库存中血液量不足,远远满足不了需求;
[0168]步骤911,通过位置定位发现候选者中对事发地点最近的用户;
[0169]具体地,血站信息平台的管理员查询平台上保存的多名RH阴性志愿者的信息,结合位置定位功能,同时对这些RH阴性志愿者进行定位,按照位置距离计算功能,优先联系距离较近的志愿者。
[0170]本提案实施例提供的技术方案,可以根据距离远近,快速联系距离较近的志愿者,然后联系距离较远的志愿者,因距离用血地点近的志愿者,可以快速赶到献血地点,能够节省大量的时间。
[0171]步骤912,直接赶到事发地点,第三次献血,患者生命被挽救;
[0172]具体地,志愿者前往事发地点为患者输血,血源得到了保证,因此患者的生命得到挽救。
[0173]这里需要指出的是:以上应用服务器实施例的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果,因此不做赘述。对于本发明应用服务器实施例中未披露的技术细节,请参照本发明方法实施例的描述而理解,为节约篇幅,因此不再赘述。
[0174]应理解,说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此,在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外,这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解,在本发明的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
[0175]在本申请所提供的几个实施例中,应该理解到,所揭露的设备如应用服务器和方法,可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,如:多个单元或组件可以结合,或可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。
[0176]上述作为分离部件说明的单元可以是、或也可以不是物理上分开的,作为单元显示的部件可以是、或也可以不是物理单元;既可以位于一个地方,也可以分布到多个网络单元上;可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
[0177]另外,在本发明各实施例中的各功能单元可以全部集成在一个处理单元中,也可以是各单元分别单独作为一个单元,也可以两个或两个以上单元集成在一个单元中;上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
[0178]本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:移动存储设备、只读存储器(Read Only Memory,ROM)、磁碟或者光盘等各种可以存储程序代码的介质。
[0179]或者,本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括:移动存储设备、R0M、磁碟或者光盘等各种可以存储程序代码的介质。
[0180]以上所述,仅为本发明的【具体实施方式】,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以所述权利要求的保护范围为准。
【主权项】
1.一种查询血液信息的方法,其特征在于,所述方法包括: 应用服务器接收终端发送的血液查询请求,所述血液查询请求至少携带血型信息; 所述应用服务器将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息; 所述应用服务器接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息; 所述应用服务器将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。2.根据权利要求1所述的方法,其特征在于,所述应用服务器接收终端发送的血液查询请求,包括: 所述应用服务器接收所述终端通过互联网网页或应用程序发送的所述血液查询请求。3.根据权利要求1所述的方法,其特征在于,所述方法还包括: 所述应用服务器存储所述终端对应用户的血型信息; 所述应用服务器定位所述用户的位置信息,并获取所述用户的用户信息; 所述应用服务器根据所述位置信息和所述用户信息向所述用户推送献血建议信息。4.根据权利要求3所述的方法,其特征在于,所述用户为多个时,所述所述应用服务器定位所述用户的位置信息,包括: 所述应用服务器定位所述多个用户对应的多个位置信息; 所述应用服务器计算所述多个位置信息与所述应用服务器的距离信息,判断所述距离信息是否在预设范围内,将在预设范围内的距离信息对应的位置信息确定为定位出的位置?目息O5.根据权利要求4所述的方法,其特征在于,所述根据所述位置信息和所述用户信息向所述用户推送献血建议信息,包括: 所述应用服务器确定所述位置信息的优先顺序; 所述应用服务器根据所述位置信息的优先顺序和所述用户信息,向所述用户推送献血建议信息。6.根据权利要求1至5任一项所述的方法,其特征在于,所述方法还包括: 所述应用服务器接收终端发送的更新请求,所述更新请求包括用户身份信息,以及所述更新请求用于请求更新用户信息中的至少一项信息; 所述应用服务器获取与所述用户身份信息对应的用户信息,并根据所述更新请求同步所述与所述用户身份信息对应的用户信息。7.—种应用服务器,其特征在于,所述应用服务器包括第一接收单元、第一发送单元、第二接收单元和第二发送单元,其中: 所述第一接收单元,用于接收终端发送的血液查询请求,所述血液查询请求至少携带血型信息; 所述第一发送单元,用于将所述血液查询请求发送给数据库服务器,以触发所述数据库服务器根据所述血型信息确定血液库中的血液需求信息; 所述第二接收单元,用于接收所述数据库服务器返回的血液查询响应,所述血液查询响应携带所述血液库中所述血型信息对应的血液需求信息; 所述第二发送单元,用于将所述血液查询响应发送给所述终端,以使所述终端对应的用户实时根据所述血液需求信息进行献血。8.根据权利要求7所述的应用服务器,其特征在于,所述第一接收单元,用于接收所述终端通过互联网网页或应用程序发送的所述血液查询请求。9.根据权利要求7所述的应用服务器,其特征在于,所述应用服务器还包括存储单元、定位单元、第一获取单元和推送单元,其中: 所述存储单元,用于存储所述终端对应用户的血型信息; 所述定位单元,用于定位所述用户的位置信息; 所述第一获取单元,用于获取所述用户的用户信息; 所述推送单元,用于根据所述位置信息和所述用户信息向所述用户推送献血建议信息。10.根据权利要求9所述的应用服务器,其特征在于,所述用户为多个时,所述定位单元包括定位模块、计算模块,判断模块和第一确定模块,其中: 所述定位模块,用于定位所述多个用户对应的多个位置信息; 所述计算模块,用于计算所述多个位置信息与所述应用服务器的距离信息; 所述判断模块,用于判断所述距离信息是否在预设范围内; 所述第一确定模块,用于将在预设范围内的距离信息对应的位置信息确定为定位出的位置信息。11.根据权利要求10所述的应用服务器,其特征在于,所述推送单元包括第二确定模块和推送模块,其中: 所述第二确定模块,用于确定所述位置信息的优先顺序; 所述推送模块,用于根据所述位置信息的优先顺序和所述用户信息,向所述用户推送献血建议信息。12.根据权利要求7至11任一项所述的应用服务器,其特征在于,所述应用服务器还包括第三接收单元和第二获取单元,其中: 所述第三接收单元,用于接收终端发送的更新请求,所述更新请求包括用户身份信息,以及所述更新请求用于请求更新用户信息中的至少一项信息; 所述第二获取单元,用于获取与所述用户身份信息对应的用户信息,并根据所述更新请求同步所述与所述用户身份信息对应的用户信息。
【文档编号】G06F19/00GK105824815SQ201510002857
【公开日】2016年8月3日
【申请日】2015年1月4日
【发明人】孙秀峰
【申请人】中国移动通信集团辽宁有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1