本申请涉及医疗卫生业务、数据处理领域，具体而言，涉及一种医疗卫生信息系统以及其实现方法。
背景技术：
医疗卫生信息系统是专门应用于医疗卫生服务机构和场景下的专业信息系统。可以独立运行的系统也为数众多，分门别类服务于医疗卫生业务的方方面面。
目前，大多数医疗卫生信息系统架构介于点对点数据和平台化数据共享之间。基于企业级系统总线(esb)的方式属于较高技术层次的平台化数据共享，子系统只需要接入平台，其他介入平台的系统就可以共享其数据，n个子系统只需要n个数据连接。
发明人发现，平台化数据共享具有一定的缺陷，比如，缺乏对于数据标准的内在限定，导致平台数据质量低、数据混乱。同时由于采用总线技术和平台化管理的架构，其实施成本较高，在一些业务量小的场景下，也无法较好的实施。进一步，子系统间的操作界面也难以形成统一，需要在多个子系统之间进行切换。
针对相关技术中缺少标准化的医疗卫生信息系统的问题，目前尚未提出有效的解决方案。
技术实现要素：
本申请的主要目的在于提供一种医疗卫生信息系统以及其实现方法，以解决缺少标准化的医疗卫生信息系统的问题。
为了实现上述目的，根据本申请的一个方面，提供了一种医疗卫生信息系统。
根据本申请的医疗卫生信息系统包括：资源池模块，用于储存与医疗卫生信息相关的标准化数据；事务模块，用于从所述资源池模块中获取标准化对象的标准化业务数据。
进一步地，系统还包括：用户界面管理器，用于作为访问医疗卫生信息的入口以及显示所述标准化对象的医疗卫生信息文档。
进一步地，系统还包括：标准化控制器，用于验证所述事务模块中对所述标准化对象的模板构造或变量赋值是否满足标准化。
进一步地，所述事务模块包括：对象控制器，用于接收对象调用请求；根据所述对象调用请求从所述资源池获取业务数据，并对所述标准化对象的变量赋值。
进一步地，所述事务模块包括：文档构造器，用于接收文档获取请求；根据所述文档获取请求从所述资源池获取业务数据，构造所述标准化对象的标准化模板。
进一步地，系统还包括：访问控制器和过程控制器，所述访问控制器，用于控制访问所述医疗卫生信息系统的用户权限；所述过程控制器，用于根据业务调用请求，储存所述标准化对象会话时需要的用户属性及用户配置信息。
进一步地，所述资源池模块包括：业务数据、系统管理数据以及标准元数据。
为了实现上述目的，根据本申请的另一方面，提供了一种医疗卫生信息系统的实现方法。
根据本申请的医疗卫生信息系统的实现方法包括：储存与医疗卫生信息相关的标准化数据至资源池；从所述资源池中获取标准化对象的标准化业务数据；在用户界面显示所述标准化对象的医疗卫生信息文档。
进一步地，方法还包括：验证所述事务模块中对所述标准化对象的模板构造或变量赋值是否满足标准化的步骤。
进一步地，方法从所述资源池中获取标准化对象的标准化业务数据包括：从所述资源池中根据医疗卫生信息类型，获取所述标准化对象的医疗卫生信息；从所述资源池中根据第二用户的唯一标识，获取已实例化的所述第二用户的对象实体，并对所述对象实体的模板中的变量赋值。
在本申请实施例中，采用资源和事务两个层次的方式，通过资源池模块，用于储存与医疗卫生信息相关的标准化数据，达到了事务模块，用于从所述资源池模块中获取标准化对象的标准化业务数据的目的，从而实现了可以在资源池模块完善并强制标准化，在事务模块解决业务系统的集成的技术效果，进而解决了缺少标准化的医疗卫生信息系统的技术问题。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本申请第一实施例的医疗卫生信息系统结构示意图；
图2是根据本申请第二实施例的医疗卫生信息系统结构示意图；
图3是根据本申请第三实施例的医疗卫生信息系统结构示意图；
图4是根据本申请第四实施例的医疗卫生信息系统结构示意图；
图5是根据本申请第五实施例的医疗卫生信息系统结构示意图；
图6是根据本申请第六实施例的医疗卫生信息系统结构示意图；
图7是根据本申请第一实施例的医疗卫生信息系统实现方法流程示意图；
图8是根据本申请第二实施例的医疗卫生信息系统实现方法流程示意图；
图9是根据本申请第三实施例的医疗卫生信息系统实现方法流程示意图；
图10是本申请中的医疗卫生信息系统架构原理图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
本申请中的医疗卫生信息系统，在集成过程中以医疗卫生信息标准化为前提，将子系统的业务和数据进行拆分，并在资源池模块按照标准的格式和类型进行存储。在事务模块中的事务分为：界面、对象和数据三个层次；方便设计，降低使用门槛。此外，系统中通过将用户界面动态集成，将所有事务以统一的方式展示到单一界面，保证系统的兼容性的同时简化操作，不用频繁切换子系统。此外，本申请中的医疗卫生信息系统可实现最小化部署，并根据需要在运行过程中进行资源池标准化数据的扩容。而通过面向事务和面向对象的设计架构，可以结合内存计算对象和进程保持，在医疗卫生信息系统中具有大量的性能优化空间。
如图1所示，该系统包括如下的模块，包括：资源池模块10，用于储存与医疗卫生信息相关的标准化数据；事务模块20，用于从所述资源池模块中获取标准化对象的标准化业务数据。在所述资源池模块10中将业务数据进行完善并标准化处理。优选地，在所述资源池模块10中包括：业务数据、系统管理数据以及标准元数据。其中，业务数据涵盖了所有子系统中医疗卫生信息相关的数据。系统管理数据中主要为系统的管理员提供相关的用户身份和登录权限管理。标准元数据为描述数据的数据，可以用于描述数据属性的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。
需要注意的是，在本申请的实施例中并不对上述标准元数据进行限定，本领域技术人员可以根据实际使用场景进行业务标准数据配置。
进一步，在所述事务模块20中在事务层面解决业务系统的集成。所述事务模块20用于从所述资源池模块10中获取得到标准化对象的标准化业务数据。如上所述，由于在所述资源池模块10中储存了与所述医疗卫生信息相关的标准化数据，所以在事务模块20可以通过多种方式调用并获取得到医疗卫生信息相关的业务数据以及还可以获取包括用户界面的标准数据。
通过上述资源池模块10中的标准化数据的储存，可以满足事务模块20从所述资源池模块10获取标准化对象的标准化数据。需要注意的是，所述标准化对象可以是：医疗卫生信息相关的患者对象、医疗卫生信息相关的医学文档对象等，在本申请中并不进行限定。
从以上的描述中，可以看出，本申请实现了如下技术效果：
在本申请实施例中，采用资源和事务两个层次的方式，通过资源池模块10，用于储存与医疗卫生信息相关的标准化数据，达到了事务模块20，用于从所述资源池模块中获取标准化对象的标准化业务数据的目的，从而实现了可以在资源池模块10完善并强制标准化，在事务模块20解决业务系统的集成的技术效果，进而解决了缺少标准化的医疗卫生信息系统的技术问题。
根据本申请实施例，作为本实施例中的优选，如图2所示，系统还包括：用户界面管理器30，用于作为访问医疗卫生信息的入口以及显示所述标准化对象的医疗卫生信息文档。在所述用户界面管理器30可动态集成，并将所有事务以统一的方式展示到单一界面。比如，动态集成医疗卫生信息中的医疗影像信息和医疗卫生信息中的临床信息。
具体地，用户界面管理器30作为用户的访问入口，用于生成用户访问界面，并将业务过程中的数据变化反映出来。具体到某一个事务的界面，可以预先定制业务界面，也可以采用通过关键词动态生成。
根据本申请实施例，作为本实施例中的优选，如图3所示，系统还包括：标准化控制器40，用于验证所述事务模块20中对所述标准化对象的模板构造或变量赋值是否满足标准化。所述标准化控制器40通过从所述资源池模块10获取标准数据metadata后，用于验证所述事务模块20中所述标准化对象的模板构造是否满足标准化条件。模板构造可以包括：数据的类型和的格式。即在所述标准化控制器40中验证构造、调用的数据的类型和的格式是否满足标准化校验。此外，所述标准化控制器40通过从所述资源池模块10获取标准数据metadata后，用于验证所述事务模块20中所述标准化对象的变量赋值是否满足标准化条件。可以通过事务模块20的相关模块根据访问请求，调用业务数据进行变量赋值。
具体地，在标准化方面也分为数据、文档、对象和界面四个层次。比如，打开一个患者病历首页界面，首先需要构造患者作为标准化对象；其次，是获取首页界面的标准数据组成(界面)；接着，构造每一个组成部分的内容，并将每一个标准化的属性描述构造成一个文档，每一个文档再由一个标准结构和大量业务数据组成。
需要说明的是，在调用用户界面、对象的过程中，每次完成构造或赋值，均需调用标准化控制器40进行标准化验证。
根据本申请实施例，作为本实施例中的优选，如图4所示，所述事务模块20包括：对象控制器201，用于接收对象调用请求；根据所述对象调用请求从所述资源池获取业务数据，并对所述标准化对象的变量赋值。所述对象控制器201根据所述对象调用请求从所述资源池获取业务数据后并对所述标准化对象的变量赋值。所述对象控制器201还可以查询系统中是否实例化标准对象的对象实体，并对未实例化的对象实体进行赋值。比如，对象控制器201判断某一患者的医疗影像信息是否实例化，如果没有实例化，则通过从所述资源池模块10获取业务数据后进行赋值。上述实例化是指，用类创建对象的过程。
根据本申请实施例，作为本实施例中的优选，如图5所示，所述事务模块包括：文档构造器202，用于接收文档获取请求；根据所述文档获取请求从所述资源池获取业务数据，构造所述标准化对象的标准化模板。所述文档构造器202接收文档获取请求，并从所述资源池获取业务数据，然后构造所述标准化对象的标准化模板。通常在当遇到复杂结构时比如需要查看多个子系统上的医疗卫生信息，则需要调用文档构造器202完成文档的整体构造，包括对象的标准数据结构和变量的赋值。
根据本申请实施例，作为本实施例中的优选，如图6所示，系统还包括：访问控制器50和过程控制器60，所述访问控制器50，用于控制访问所述医疗卫生信息系统的用户权限；所述过程控制器60，用于根据业务调用请求，储存所述标准化对象会话时需要的用户属性及用户配置信息。所述访问控制器50负责系统的访问控制，通常可以指auth权限管理。所述过程控制器60负责根据不同的业务调用请求，储存或登记所述标准化对象会话时需要的用户属性及用户配置信息，确保调用过程的顺利进行。所述过程控制器60通常可以指session。即在进行web端访问时，服务器为每个用户(医生)浏览器创建一个会话对象。
需要说明的是，在本申请的实施例中并不对访问控制器50进行具体限定，本领域技术人员可以根据实际使用场景进行配置。
还需要说明的是，在本申请的实施例中并不对过程控制器60进行具体限定，本领域技术人员可以根据实际使用场景进行配置。
需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
根据本申请实施例，还提供了一种用于实施上述医疗卫生信息系统的实现方法，如图7所示，该实现方法，具体包括：
步骤s102，储存与医疗卫生信息相关的标准化数据至资源池；
在所述资源池中将业务数据进行完善并标准化处理。优选地，在所述资源池中包括：业务数据、系统管理数据以及标准元数据。其中，业务数据涵盖了所有子系统中医疗卫生信息相关的数据。系统管理数据中主要为系统的管理员提供相关的用户身份和登录权限管理。标准元数据为描述数据的数据，可以用于描述数据属性的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。
需要注意的是，在本申请的实施例中并不对上述标准元数据进行限定，本领域技术人员可以根据实际使用场景进行业务标准数据配置。
步骤s104，从所述资源池中获取标准化对象的标准化业务数据；
从所述资源池中获取得到标准化对象的标准化业务数据。如上所述，由于在所述资源池中储存了与所述医疗卫生信息相关的标准化数据，可以通过多种方式调用并获取得到医疗卫生信息相关的业务数据以及还可以获取包括用户界面的标准数据。
通过上述资源池中的标准化数据的储存，可以满足从所述资源池获取标准化对象的标准化数据。需要注意的是，所述标准化对象可以是：医疗卫生信息相关的患者对象、医疗卫生信息相关的医学文档对象等，在本申请中并不进行限定。
步骤s106，在用户界面显示所述标准化对象的医疗卫生信息文档。
在用户界面用于作为访问医疗卫生信息的入口以及显示所述标准化对象的医疗卫生信息文档。在在用户界面可动态集成，并将所有事务以统一的方式展示到单一界面。比如，动态集成医疗卫生信息中的医疗影像信息和医疗卫生信息中的临床信息。
具体地，在用户界面作为用户的访问入口，用于生成用户访问界面，并将业务过程中的数据变化反映出来。具体到某一个事务的界面，可以预先定制业务界面，也可以采用通过关键词动态生成。
根据本申请实施例，作为本实施例中的优选，如图8所示，还包括：验证所述事务模块中对所述标准化对象的模板构造或变量赋值是否满足标准化的步骤。
上述步骤具体包括：通过从所述资源池获取标准数据metadata后，用于验证所述标准化对象的模板构造是否满足标准化条件。模板构造可以包括：数据的类型和的格式。即在所述标准化验证步骤中验证构造、调用的数据的类型和的格式是否满足标准化校验。此外，在所述标准化验证步骤中通过从所述资源池获取标准数据metadata后，用于验证所述标准化对象的变量赋值是否满足标准化条件。可以通过的相关模块根据访问请求，调用业务数据进行变量赋值。
具体地，在标准化方面也分为数据、文档、对象和界面四个层次。比如，打开一个患者病历首页界面，首先需要构造患者作为标准化对象；其次，是获取首页界面的标准数据组成(界面)；接着，构造每一个组成部分的内容，并将每一个标准化的属性描述构造成一个文档，每一个文档再由一个标准结构和大量业务数据组成。
需要说明的是，在调用用户界面、对象的过程中，每次完成构造或赋值，均需调用上述标准化校验步骤进行标准化验证。
根据本申请实施例，作为本实施例中的优选，如图9所示，从所述资源池中获取标准化对象的标准化业务数据包括：
步骤s1041，从所述资源池中根据医疗卫生信息类型，获取所述标准化对象的医疗卫生信息；
根据所述对象调用请求从所述资源池获取业务数据后并对所述标准化对象的变量赋值。还可以查询系统中是否实例化标准对象的对象实体，并对未实例化的对象实体进行赋值。比如，判断某一患者的医疗影像信息是否实例化，如果没有实例化，则通过从所述资源池获取业务数据后进行赋值。上述实例化是指，用类创建对象的过程。
具体地，可以是指用户(医院用户)在用户界面中输入实验室(检验科)检查检验报告(简称lis报告)，或者点击界面中的快捷关键词lis报告。用户界面从资源池中读取关键词lis报告的标准化界面，标准化界面由对象索引输入界面和lis报告，即检查检验报告主内容。
步骤s1042，从所述资源池中根据第二用户的唯一标识，获取已实例化的所述第二用户的对象实体，并对所述对象实体的模板中的变量赋值。
根据所述对象调用请求从所述资源池获取业务数据后并对所述标准化对象的变量赋值。其中，第二用户的唯一标识是指患者的就诊号或身份证等身份标识。
具体地，可以是指用户(医院用户)输入患者(第二用户)就诊号或者扫描患者身份证并提交。
如图10所示，可以对本申请的实现原理进行详细说明。
本申请实施例中提供的医疗卫生信息系统是一种面向事务的系统架构，通过将系统分成资源和事务两个大的层次，在资源层次完善并强制标准化，而在事务层面解决业务系统的集成。如图10所示，包括了：资源池、标准化控制器、用户界面管理控制器、对象控制器、文档构造器以及过程控制器和访问控制器。
其中，在资源池中包含业务、标准和管理三类数据，在资源池以外均为事务层次，访问控制器负责访问控制。
在标准化控制器中，按照该标准化控制分为数据、文档、对象以及界面四个层次。具体地，当打开一个患者病历首页界面，首先需要构造患者标准化对象，其次是获取首页界面的标准组成，接着构造每一个组成部分的内容，并将每一个标准化的属性描述构造成一个文档，每一个文档再由一个标准结构和大量业务数据组成。
在用户界面管理控制器中，作为用户的访问入口，负责生成用户访问界面，并将业务过程中的数据变化反映出来。具体到某一个医疗卫生信息相关事务的界面，可以预先定制医疗卫生信息相关业务界面，也可以采用通过关键词动态生成。
具体地，以用户查询某一患者的检查检验报告为例，该医疗卫生信息相关事务的运行过程如下：
步骤一：医院医师在用户界面管理控制器中输入检查检验报告(简称lis报告)，或者可以点击界面中的快捷关键词lis报告按钮。用户界面管理控制器从资源池中读取关键词lis报告的标准化界面。该标准化界面由绑定对象控制器的调用对象索引输入界面和检查检验报告主内容。
步骤二：用户输入患者就诊号或者扫描患者身份证并提交，触发对象控制器查询和过程控制器登记，过程控制器登记该事务。
步骤三：对象控制器查询平台是否已经实例化该患者的对象实体，如果已经实例化，则通知用户界面管理控制器直接按照步骤一种获取的检查检验报告主内容界面进行变量填充；如果完成全部变量的填充，则展现给用户完整的检验科信息报告，流程结束。如果发现患者对象的部分变量并未赋值，则要告知对象控制器进行必要的变量赋值。
步骤四：对象控制器根据需要调用业务数据进行变量赋值，当遇到复杂结构时，则需要调用文档构造器完成文档的整体构造，包括数据结构和数据赋值。
步骤五：以上述过程中在调用用户界面管理控制器、对象控制器和文档构造器的过程中，每次完成构造或赋值，均需调用标准化控制器进行标准化验证。
显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。