内容


使用传感器监控的 Smarter Planet 解决方案,第 3 部分

构建更加智能的医疗设备监视解决方案

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 使用传感器监控的 Smarter Planet 解决方案,第 3 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:使用传感器监控的 Smarter Planet 解决方案,第 3 部分

敬请期待该系列的后续内容。

简介

过去,需要在现场亲自对病人的健康情况进行监视。病人必须访问某种医疗设备来收集并分析他或她的关键统计数据,从而获得有关其所患疾病的警示、趋向和异常。这是一个庞大的手动过程,病人和医疗服务提供者都需要投入时间和资源。并且,这也是一个不方便的和有缺陷的过程。医疗保健的有效性决定了用于找出并诊断那些有可能危害病人健康的疾病需要多长时间。因此,频繁的、一致的健康监视可以帮助改进医疗保健的效果,同时降低整体成本。

本文将描述家庭健康监视器与 IBM® WebSphere® Sensor Events 的集成如何用于创建一个更智能的医疗解决方案。在描述在这些解决方案中使用 IBM 技术如何帮助通过更好的病患监视实现改善的医疗看护时,本文将:

  • 讨论一个样例医疗解决方案及其组件。
  • 定义该解决方案的架构。
  • 描述一个示例用例来演示解决方案的各个方面。
  • 解释用例的样例代码。

健康监视

医疗成本在过去几十年中以惊人的速度增长。除了针对目前的疾病发现新的治疗方法外,医疗行业也进一步关注了疾病的预防和早期干预,从而帮助避免一些可以预防的疾病及其相关成本。但是,随之出现的是长期监视和治疗的成本。为了实现有效的治疗,必须针对每个病患进行量身定制,并且会随着病人病情的变化而随时间改变。面向早期检测和持续治疗的一大挑战就是病患监视所涉及的时间和成本。

如果在检测和监视病人健康的过程中能够减少专业人员的干预,同时不会影响监视的质量 —— 事实上,有可能会改善监视质量 —— 保证在发生病情变化时响应的有效性和及时性,那么将获得更好的病患体验和结果,同时可以降低整体成本。

另一种思考方式就是提供病人健康状况的可见性(如果您阅读了本系列的其他篇文章,那么应该熟悉这个主题)。家庭健康监视的先行者 Continua Health Alliance 是由关注个人健康护理的医疗保健和技术公司组成的非营利性质的开放联盟。这个联盟主要致力于基本生命监视过程中围绕生理信号监视(或远程病患监视)的标准,从而确定脉搏与血压数据、体重计、葡萄糖测定仪、体能监视器、药物监视器等等之间的结合点,这样最终会实现对病人健康状况的全面了解。

针对医疗系统的解决方案变得越来越智能

Instrumented仪表化(Instrumented)

此前的文章 所讨论的一样,智能化的第一步是通过仪表化实现。仪表为健康的可见性提供了基础。在医疗保健中,仪表意味着医疗设备,比如心率监视器、脉搏血氧计、葡萄糖测定仪以及血压监测计。

如今,许多医生的办公室都使用电子监控监测仪,提高了仪表读数的可靠性和准确性,一些仪器甚至适合那些非专业人士使用,并且也能够获得相同的可靠性。这类设备的数量在不断增长,在家庭中将这些设备与远程健康数据收集结合起来也变得越来越可行。例如,令人兴奋的新设备出现在市场上,比如药物剂量监测器,它可以在使用药物时通知医疗系统。

Interconnected互相连接

尽管这些设备都实现了数字化,但是如今获取的大部分读数仍然需要手工执行和抄写。它们仍然主要存在于医生的办公室,因此,仍然需要患者去医院看病,需要医疗专业人员来获取仪表读数并将它们抄写到病人的记录表,医生需要阅读这个图表并解释检查结果。这个基本的过程耗费时间、成本很高并且也不方便,对于那些患有重病、长期疾病、失去活动能力或年纪较大的病人,更是如此。

为了将医疗监视和成本缩减推进到一个新的高度,需要实现两件事情:需要将这些仪器从医生的办公室移动到患者那里,需要将这些仪器与医疗服务提供者连接起来。如果无法实现连接的话,远程监视并不比办公室内的读数更有价值。这种连接还意味着多个医疗服务提供者可以从实时数据获益:多名医生和专家可以同时跟踪一名身患多种疾病的病人。一个健康管理组织也可以监视数据、提供建议,或者批准病人转诊或进行见效更快的高级治疗,因为他们已经具备了病人的所有被监视的统计数据。这还有助于减少医疗诈骗,因为保险公司将需要访问原始的医疗数据。

Intelligent智能

当被监视的传感器数据可以由参与到病人治疗的医疗服务提供者查看时,整个系统就变得智能化:可以智能地监视传感器数据,可以每天自动化完成一些例行工作,可以避免经常会浪费医疗服务提供者的时间和资源的低价值操作。

例如,血压、葡萄糖和氧气读数必须定期读取,但是大部分情况下,如果它们保持在一个合理的、正常的范围,那么就不需要向医护人员发出警报。对于异常读数,比如心率升高,血压降低、血糖(葡萄糖)升高或体温升高(预示着发烧或发生感染),那么将需要通知医生。类似地,对于更长期的趋势,比如体重随时间增加(对于心力衰竭的病人表示心脏承受了压力,对于糖尿病患者意味着体液渚留),那么医生也会对这些数据感兴趣。

将病人送回家的决定常常受到成本控制的影响;针对病人呆在护理病房的成本,医疗系统尝试平衡对持续监视和随时预备可用医师的需求。一个病情比较稳定的病人可以被送回家并使用远程监视。大多数病人都可以通过这种方式得到良好的治疗,不需要进一步的干预;如果确实发生了某种状况,医疗系统将捕捉到它并进行响应。然而,如今涉及了一个更复杂的系统,包括备用健康监视和家庭护理机构,从而增加了治疗的费用。比如,一名药剂师一次只能监视 40 名病人,需要每周给每一名病人打电话(如果不是每天的话),收集状态和自我治疗读数,检查设备条件(电池、堵塞等等),并检查手头的药物剂量和数量。

通过连接到一个药物监视器,系统可以远程地监视用药量,并在病人忘记服药或用错药或服药不当时智能地发出警告。对于轻度的违规行为,通过使用智能的、连接的通知系统,家庭成员将收到警告并进行简单的、不重要的干预,从而进一步降低了治疗开销。

解决方案架构

在仪表化、连接化和智能化的整个过程中,一个困难重重的供应链系统被转化为一个更加智能的系统:更准确、更可靠、更高效以及更开放,并最终变得更有价值。

图 1. 更智能的医疗参考架构
图 1. 更智能的医疗参考架构
图 1. 更智能的医疗参考架构

这个医疗参考架构(图 1)的组成元素包括:

  • 数据捕捉

    在实现一个智能医疗系统时,Data Capture and Delivery 组件构成了连接设备的主要集成点,成为了传感器设备与 IBM WebSphere Sensor Events 服务器之间的处理链的第一站。WebSphere Sensor Events 的数据捕捉组件包含一个软件堆栈,这个软件堆栈驻留在传感器设备中,或接近于传感器设备。它提供了一个框架来为设备通信构建设备适配器,面向具有低延迟需求的业务逻辑,并积极地管理设备,比如扫描器、传送带、分流器(diverter)等等。在一个智能医疗系统中,传感器将是无线的,USB、Ethernet 或串行连接的医疗监视设备,比如血压(BP)、葡萄糖、心率、EKG 以及脉搏血氧计。Data Capture and Delivery 组件提供了一个框架来规范化、过滤、整理和总结这些数据,去掉无关的数据或是压缩数据量来减轻带宽和服务器负载。Data Capture and Delivery 还可以缓冲数据,处理不可靠的通信,这样就不需要由应用程序逻辑来执行这项工作。

  • WebSphere Sensor Events

    本文将不会介绍 WebSphere Sensor Events Gateway 组件的功能和作用,因为这已经在 第 2 部分 讨论过,并且它在解决方案架构中的角色并没有在智能医疗解决方案中发生变化。然而,WebSphere Sensor Events 服务器的角色和提供的服务确实发生了改变。在这里,WebSphere Sensor Events 服务器变为被称作 Remote Patient Monitoring Server (RPMS) 的服务器,这是完整 Remote Patient Monitoring System 的一部分,这个系统包含了连接到一个医疗设备网关的各种医疗设备,而医疗设备网关连接到了 RPMS。

  • WebSphere Business Events

    RPMS 的真正价值在于能够在医疗设备消息流经系统时从中发现重要的模式或值得引起注意的读数。WebSphere Business Events 在这个参考架构中履行了这一职责。它为解决方案构建者和用户提供了一个平台,用于编写有关数据模式的检测规则。当检测到一个模式后,将执行某些操作,比如通知医师或看护护士,或者将事件转发给 Electronic Health Record (EHR) 系统。如果需要的话,一条 WebSphere Business Events 规则可以驱动某个操作,一直到医疗设备本身,也许为了获得更多数据,会使用另一个读数来检查存在疑问的读数,或者提高监视的频率来实现更密切的监视。

  • WebSphere Business Monitor

    WebSphere Business Monitor 为医疗服务提供者提供了各种设施来更轻松地监视 WebSphere Business Events 或 WebSphere Sensor Events 输出,从而找出可疑的趋势。监视可以采用各种指示板、图表或图形的形式。医疗服务提供者随后可以使用这些数据来决定是否将信息转发给 EHR 系统或 IBM Cognos® Business Intelligence,以使用其他病人历史记录来进行进一步的分析。

  • IBM Cognos Business Intelligence

    来自医疗设备的数据被发送到 PRMS 并被持久保存。WebSphere Business Events 将根据所需的一组规则监视事件。WebSphere Business Monitor 显示来自设备的数据呈现的模式。尽管设备数据为医生提供了大量以前没有的信息,但是仅仅使用设备数据还不足以进行完整的诊断。医师要想提供具有可行性的建议,解决方案必须能够提供分析功能。IBM Cognos 是一个为医疗人员提供了必要的分析功能的平台,使他们能够根据病人的病史和患有类似疾病的病人的成功治疗案例迅速给出准确的建议。有一些 EHR 系统包含了 Cognos 实现其分析功能。

  • Electronic Health Record 系统

    EHR 是用于存储病人健康档案的主存储库。该存储库存储了相关的医疗设备数据、实验室结果、看病历史、住院记录,等等。架构的这一部分超出了本文的讨论范围,但需要注意的是,EHR 系统是一个完整的智能医疗解决方案的不可或缺的部分。

将医疗设备连接到 WebSphere Sensor Events

出于成本和复杂性的考虑,大多数设备并不具备广域网联网功能。它们很可能使用 Bluetooth、RS-232 串行、USB,或者是 Wi-Fi,因此它们可能只能够在本地连接(想象一下每个监视器都具备它自己的 cell 数据调试解调器和相关的计划成本!)。您需要一个本地的中央连接点,它能够支持以上几种连接类型。来自不同制造商的同一类型的所有设备都应该在 API 中对数据格式和生命周期管理(即部署、启动、停止、配置和移除)进行规范化。

每个设备接口都需要管理与设备的连接,通过定制的设备协议进行交互,并提供一个规范化的、面向外部的 API。它随后需要收集和处理数据,对数据进行过滤并规范化为一种标准格式,然后管理通信并把事件提交给服务器。每个设备都是一个面向本地业务逻辑的平台,需要满足快速响应、低延迟、负载分配、带宽节约和高可用性。这正是 Data Capture and Delivery 扮演的角色。

对于我们的样例连接健康系统,Data Capture and Delivery 充当了一个收集和控制点,面向那些已经进行了连接但不太智能的设备。在每个家庭中将有一个数据捕捉健康网关,面向所有家庭成员,为他们提供了一种方法来管理自己的数据 —— 在重视个人信息安全性的时代,这是一项重要的考虑。Data Capture and Delivery 因为所有这些原因而存在。

要与样例场景中使用的医疗设备交互,将使用 IBM Data Capture and Delivery Toolkit for WebSphere Sensor Events 创建一个定制的设备代理包(参见 参考资料)。这个包需要使用三个类来处理以下三种关键职责:

  • Activator:管理代理的生命周期(启动,停止)。
  • Advisor:配置代理并在配置改变时更新代理。
  • Agent:实现业务逻辑。

为了清晰起见,这些类被划分到两个包,以将业务逻辑或模型代码(devworks.sample.smarter.health.deviceadapter)从负责创建和配置代理的代码(devworks.sample.smarter.health.deviceadapter.bundle)中分离出来。虽然创建代理的流程有一点复杂,但是数据捕捉组件提供了一组轻量级的类结构,可以极大地简化实现。在多数情况下,这个结构仅仅是根据需求的独特性和惟一性对其中一个框架类划分子类,并根据需要覆盖一个或多个 hook 方法。

Activator 类(DeviceAdapterAgentActivator)负责根据它导入的服务确定何时创建代理。一旦所需的服务被导入后,它将创建 advisor。Activator 类对 AbstractManagedServiceFactoryActivator 划分子类,以继承所需的大多数行为。由于您已经有一个可能具备许多实例(即针对每个连接的设备进行了配置)的代理,将使用托管的服务工厂接口。这个接口使您能够根据不同的配置创建代理的不同实例。在本例中,不存在导入的服务,没有检查任何条件,并且也不需要定制代理的配置方式,因此 activator 非常简单:它仅仅创建相应的 advisor(DeviceAdapterAgentAdvisor)。代理确实导入了包,但是框架将负责为您执行这个操作,并将在导入包后调用 doCreateAdvisor() 方法。因此,在这个简单示例中,这个方法所做的就是创建 advisor 并返回它(清单 1).

清单 1
protected AbstractManagedServiceFactoryAdvisor doCreateAdvisor() {
	…
	return (new DeviceAdapterAgentAdvisor());
	}

Advisor 类(DeviceAdapterAgentAdvisor)负责管理代理的配置。这意味着创建模型类和服务,并在启动阶段向它们提供配置信息,如果配置改变的话,还将在后面的阶段提供配置信息。再次对框架类(AbstractManagedServiceFactoryAdvisor)划分子类并只覆盖用于创建本例中所需行为的 hook 方法。这里,只需要在服务代理处于适当时刻时创建类的实例。如果配置发生了实时更新,您将需要让框架破坏它,然后只需创建具有新配置的新实例(如果您宁可更新当前配置而不是破坏并创建它,那么可以使用 hook 方法)。

方法 doCreate() 将在创建代理时调用,而新的配置属性将由框架自动传递到属性参数中。您将创建 DeviceAdapterAgent 实例并将这些配置属性一起传递到构造函数(清单 2)。

清单 2
protected AbstractAgent doCreate(String pid, Dictionary properties, 
  IBundleActivationManager manager) {
	DeviceAdapterAgent agent = new DeviceAdapterAgent(properties);
	manager.addExportedService(IAgent.class.getName(), agent, properties);
	return (agent);
	}

您现在已经创建了代理实例。您的 DeviceAdapterAgent 来自于 AbstractAgent,后者为代理提供了许多常见行为:处理传入的事件、发布事件、错误处理和日志记录、跟踪、属性处理等等。现在您需要对它进行初始化,并打开 socket 以让医疗设备连接到它。

在激活过程中,框架将对您的代理调用 binding() 方法。这里,您将调用自己的 openListener() 方法。这个方法对样例应用程序完成所有的工作;它执行了一些设置(打开 ServerSocket),然后启动一个循环来接受进入的连接。

当获得一个连接后,它将读取并解析来自设备的数据(BP=120/80:mydoctorMD@xyz.com),查找读数(事件)类型和值,以及用于通知的电子邮件地址(只是为了简化服务器中的电子邮件通知)。

要将 Data Capture and Delivery 中的事件发送给服务器,将在一个嵌套的散列表中创建一个散列表,包含事件类型(键:eventType)和消息本身(键:value)。从示例中可以看到,消息内容如清单 3 所示。

清单 3
name: diastolic_reading, value: 80
name: emailAddress, value: mydoctorMD@xyz.com
name: systolic_reading, value: 120

嵌套的散列表如清单 4 所示。

清单 4
	name: eventType, value: HHL/HomeHealthEvent/BP
	name: value, value: {
		name: diastolic_reading, value: 80
		name: emailAddress, value: mydoctorMD@xyz.com
		name: systolic_reading, value: 120}

最终,所有元数据都被存储为另一个散列表,其键为 dataExtensions。样例使用元数据存储事件类型,从而简化 WebSphere Business Events 中的处理。最后一个嵌套散列表如清单 5 所示。

清单 5
	name: eventType, value: HHL/HomeHealthEvent/BP
	name: dataExtensions, value: {
		name: wbe.eventname, value: BP}
	name: value, value: {
		name: diastolic_reading, value: 80
		name: emailAddress, value: mydoctorMD@xyz.com
		name: systolic_reading, value: 120}

因此,创建事件散列表的代码如清单 6 所示。

清单 6
eventData = new Hashtable();
msg = new Hashtable();
dataExtensions = new Hashtable();
...	
if (deviceEvent.equals("BP")) {
	...
	eventData.put("systolic_reading", systolic);
	eventData.put("diastolic_reading", diastolic);
	dataExtensions.put("wbe.eventname", "BP");
} 
...
eventData.put("emailAddress", emailAddress);
eventData.put("dataExtensions", dataExtensions);
msg.put("eventType", healthEventPrefix + deviceEvent);
msg.put("value", eventData);

在一个更复杂的系统中,您可能具有一些下游代理,它们使用消息处理函数 handlePublishArrived(String topic, Dictionary event) 订阅来自设备代理的一个或多个主题。例如,如果病人始终配带一个脉搏血氧计,那么您不希望服务器因为处理所有读数而超载,因此您可能会编写一个代理来进行批处理,或者对这些读数进行归纳,或者去掉 “正常的” 读数并只在值超过合理范围时发送事件。在本文的简单例子中,您只需要将消息发布到服务器。AbstractAgent 子类提供了 publish(String topic, Hashtable eventMessage) 方法,因此发布变为:

publish(healthEventTopicPrefix + deviceEvent, msg);

从这里,事件将流经 EventTransformAgent(通过您将导入的配置)以转换为 XML,从 NotificationServiceBridgeAgent 流入 MicroBroker,在 MicroBroker 中被缓冲并有选择地持久化保存,最终发送给 WebSphere Sensor Events 网关以进行处理。

样例场景

样例场景基于连接的个人健康模型,后者对医疗治理进行了扩展,超越了传统的临床模式,进入到患者的家里。

本例中的患者有一些健康问题:

  • 具有高血压历史。
  • 服用降低胆固醇的药物。
  • 患有糖尿病。

为了帮助这名病人更好地管理自己的健康并避免频繁地去医院,他的医生让他加入一个试验项目中,该项目可以远程地监控他的血压、服药情况以及葡萄糖水平。

作为这项试验的一部分,这名患者在自己的家中安装了一个血压监视器、一个药物监视器和一个葡萄糖测定仪。这些设备都被连接到一个称为家庭健康网关的设备上。这个网关与家庭内部的健康设备交互,可以捕捉数据并将数据转发给远程的病人监视系统。在这个场景中,WebSphere Sensor Events 数据捕捉组件运行在家庭健康网关之上。Data Capture and Delivery 堆栈负责与医疗设备交互,过滤并整理原始数据,并将数据转发给运行在 WebSphere Sensor Events 服务器之上的远程病人监视系统。

当事件到达 WebSphere Sensor Events 服务器,它们将被 WebSphere Business Events Reusable Component 获取,WebSphere Business Events Reusable Component 将传入的传感器事件转化为一种可由 WebSphere Business Events 使用的格式,并将(通过一个 JMS 消息队列)它们转发给 WebSphere Business Events 运行时以进行处理。WebSphere Business Events 将对传入的事件进行评估,应用针对事件类型定义的逻辑,并调用一个或多个操作,这些操作通过执行下面的逻辑确定:

  • 对于血压事件,WebSphere Business Events 逻辑判断病人的血压读数是否正常,或者他们是否处于高血压前期、高血压或低血压。当病人的血压读数表示他处于低血压中的高血压(hypertension of hypotension)时,WebSphere Business Events 将向患者发回一个通知,说明他的血压情况,并向他的医师触发一个电子邮件警告。
  • 病人曾经服用一种名为 CholElim 的药物来降低他的胆固醇。该病人的医师嘱咐他一天服一次药。病人是否遵循医生的嘱咐将由一个药物监视器确定。这个药物监视器将检测包含 CholElim 药品的特别设计的 “铝塑包装” 中打开的小孔。药物监视器将记录铝塑包装的小孔以及它被打开的时间。这个数据在一个药物监视器事件中捕捉。WebSphere Business Events 针对药物监视器事件定义的逻辑判断病人是否按照所需剂量服用 CholElim。WebSphere Business Events 将向患者发送一条通知,说明他的服药情况。如果他没有按照规定服药的话,那么将向他的医师发送一条通知。
  • 为了更好地治疗他的糖尿病,病人在自己家里安装了一个葡萄糖测定仪。在本例中,您需要分析有关葡萄糖的事件来确定病人的血糖是否过高或过低。实现了 WebSphere Business Events 逻辑来接收事件并对患者进行响应,但是不会实际地分析血糖的水平。这里的目的是提供一个框架来接收和响应葡萄糖事件,并让您添加逻辑来对事件进行分析。

实现样例

在一个实际实现中,将使用血压监视器、药物监视器和葡萄糖测定仪来监测和收集患者的健康数据。数据捕捉设备代理将通过 Bluetooth、USB、TCP 或其他用于捕捉数据的协议与这些设备进行交互。为了简化这个例子,为样例应用程序提供了一个名为 SmarterHealth 的 Web 应用程序(参见 下载)来代替这些设备。数据捕捉设备代理(也是附带的)将使用一个 socket 连接与 SmarterHealth servlet 交互,从而捕捉数据。

SmarterHealth Web 页面(图 1)使您能够输入血压、服药情况和葡萄糖测定仪的读数,并将这些读数发送到数据捕捉设备代理。由 WebSphere Business Events 发送的病人通知将显示在 SmarterHealth Web 页面的底部。由 WebSphere Business Events 发送给医师的电子邮件通知将被发送给 Doctor email address 字段中输入的电子邮件地址。

图 2. SmarterHealth Web 页面
图 2. SmarterHealth Web 页面
图 2. SmarterHealth Web 页面

应用程序流

当单击 SmarterHealth Web 页面的 Send Measurement 按钮时,SmarterHealth servlet 从 HttpServletRequest 对象提取事件读数,打开一个通向数据捕捉设备代理的 socket,并发送数据(图 3)。

图 3. 应用程序流
图 3. 应用程序流
图 3. 应用程序流

数据捕捉设备代理将解释事件、解析数据、构建所需的对象,并将消息发送给与事件相关的主题。消息将使用以下主题名称发布:

  • /HomeHealthEvent/BP
  • /HomeHealthEvent/MedMonitor
  • /HomeHealthEvent/Glucose

这些主题针对 WebSphere Sensor Events 进行了配置,将从数据捕捉设备转发到 WebSphere Sensor Events 服务器以进行额外的处理。来自数据捕捉组件的事件将由数据捕捉格式转换为 ISensorEvent XML,并被发送到 WebSphere Sensor Event 服务器网格。网格将 XML 转换为一个 ISensorEvent 对象并将其发布到 WebSphere Application Server 服务集成总线(SI 总线)消息传递引擎(针对 WebSphere Sensor Events 进行了配置)。主题从 ISensorEvent XML 中传递的数据构建并匹配 Data Capture and Delivery 中使用的主题。一旦事件对象被发布后,发布和订阅消息引擎(pub/sub)将事件交付到所有订阅的 Java™ 2 消息驱动 beans。

WebSphere Business Events Reusable Component 是一个消息驱动 bean,负责将 ISensorEvent 对象转换为可由 WebSphere Business Events 消费的 XML 格式的消息。当配置为订阅 HomeHealthEvent 主题时,WebSphere Business Events Reusable Component 将把 ISensorEvent对象转换为所需的 XML 格式,并通过 JMS 发送给 WebSphere Business Events。

WebSphere Business Events 对传入的事件进行评估,应用针对事件类型定义的逻辑并调用一个或多个操作(通过执行逻辑确定)。在样例场景中,这些操作包括发给病人和医师通知。病人通知通过一个 HTTP POST 发送给 SmaterHealth servlet,而医师通知则通过电子邮件发送。

事件转换

ISensorEvent 对象包含了一个头部、有效负荷和有效负荷元数据。头部提供了有关在何时以及什么位置观察到事件的信息,有效负荷包含了事件数据(例如,心脏收缩和舒张的读数),而有效负荷元数据包含了有关事件的额外数据(清单 7)。

清单 7. 样例 ISensorEvent 对象
ibmse_header
	attributes: {
	name: sourceId, value: H1, type: 18
	name: eventType, value: HHL/HomeHealthEvent/BP, type: 18
	name: dateTime, value: 2010-01-19T17:04:14.328Z, type: 5}
ibmse_payloadMetaData
	attributes: {
	name: wbe.eventname, value: BP, type: 18}
ibmse_payload
	groups: {
	name: value
		attributes: {
		name: diastolic_reading, value: 80, type: 12
		name: emailAddress, value: mydoctorMD@xyz.com, type: 18
		name: systolic_reading, value: 120, type: 12}}

如前所述,WebSphere Business Events Reusable Component 将 ISensorEvent 对象转换为 WebSphere Business Events 所需的 XML 格式。这个转换过程在 WebSphere Business Events 事件 XML 中创建相应的头部、有效负荷和有效负荷元数据元素,如清单 8 所示。

清单 8. 样例 WebSphere Business Events 事件 XML
<?xml version="1.0" encoding="UTF-8" ?>
<connector name="WebSphere Sensor Events Server" version="6.2">
type="event">
  <connector-bundle name="BP" type="event">
    <IBMSE_Header_BP>
      <sourceId type="String">H1</sourceId>
      <eventType type="String">HHL/HomeHealthEvent/BP</eventType>
      <dateTime type="DateTime">2010-01-19T12:04:14-0500</dateTime>
    </IBMSE_Header_BP>
    <IBMSE_PayloadMetaData_BP></IBMSE_PayloadMetaData_BP>
    <IBMSE_Payload_BP>
      <emailAddress type="String">mydoctorMD@xyz.com</emailAddress>
      <systolic_reading type="Integer">120</systolic_reading>
      <diastolic_reading type="Integer">80</diastolic_reading>
    </IBMSE_Payload_BP>
  </connector-bundle>
  <system>9.37.234.150</system>
  <timestamp>2010-01-19T12:04:16-0500</timestamp>
  <loginfo>An event of type: HHL/HomeHealthEvent/BP has arrived from  
   location: H1</loginfo>
   </connector>

WebSphere Business Events Reusable Component 使用 wbe.eventname 属性值(来自有效负荷元数据)来设置 <connector-bundle> 元素名属性的值。当在 WebSphere Business Events 中构建头部、有效负荷和有效负荷元数据元素时,该值被附加到字符串 IBMSE_Header、IBMSE_PayloadMetaData 和 IBMSE_Payload 中。这些名称非常重要,因为在 WebSphere Business Events 中创建事件定义时需要使用它们。样例应用程序中使用的 wbe.eventname 属性值为:

  • BP
  • MedMonitor
  • Glucose。

应用程序逻辑

在样例应用程序中,所有应用程序逻辑都在 WebSphere Business Events 中实现,并且使用以下组件定义:

  • 接触点(Touchpoints):定义事件和操作集合,它们表示向 WebSphere Business Events 发送事件并从 WebSphere Business Events 接收通知的外部应用程序。
  • 事件:定义接收自外部应用程序的输入。事件触发了 WebSphere Business Events 对业务逻辑的执行。样例应用程序中的事件来自 WebSphere Sensor Events。
  • 操作:定义从 WebSphere Business Events 发往外部应用程序或系统的通知。前面描述的病人和医师通知是由 WebSphere Business Events 在运行由样例应用程序定义的业务逻辑时触发的操作。
  • 中间对象:将业务对象与来自多个源的数据组合起来。这些数据可能来自传入的事件,可能进行了计算,或者检索自外部数据源。在样例应用程序中,所有中间对象都使用来自传入事件的数据填充。由 WebSphere Business Events 运行的业务逻辑将处理中间对象。
  • 交互集:包含一个或多个交互块,它定义了 WebSphere Business Events 在收到事件时将要运行的业务逻辑。
  • 过滤器:定义一些规则,WebSphere Business Events 将评价这些规则以确定是否应当采取某个操作。

事件和操作

SmarterHealth-WBE.xml 项目文件定义了一个名为 WSE Events 的接触点,用于保存事件定义。在这个接触点之下,您使用相应的事件对象定义 IBMSE_Payload_BP、IBMSE_Payload_Glucose 和 IBMSE_Payload_MedMonitor 定义了名为 BP、Glucose 和 MedMonitor 的事件。没有针对头部和有效负荷元数据元素添加事件对象定义,因为它们不包含实现该场景所需的任何数据。

图 4. SmarterHealth 事件
图 4. SmarterHealth 事件
图 4. SmarterHealth 事件

为事件 XML 中传递的数据定义了事件对象字段(并且必须匹配)。本场景使用的名称和数据类型分别为:

  • IBMSE_Payload_BP
    • systolic_reading (Integer)
    • diastolic_reading (Integer)
    • emailAddress (String)
  • IBMSE_Payload_Glucose
    • glucose_reading (Integer)
    • emailAddress (String)
  • IBMSE_Payload_MedMonitor
    • compliance_reading (Boolean)
    • emailAddress (String)

为了简化场景,每一个事件都传递了医生的电子邮件地址。在一个真实的实现中,每个事件都将包含某种类型的病人标识符,用于从一个外部数据源查找医生的电子邮件地址。

这个样例场景要求您在处理一个家庭健康事件时向病人发送通知,而当出现一个问题时,向病人的医生发送一个通知。SmarterHealth-WBE.xml 项目文件定义了一个名为 Notifications 的接触点。在这个接触点之下,您定义了名为 Patient Notification 和 Doctor Notification 的操作。Patient Notification 操作使用一个 HTTP 连接,而 Doctor Notification 使用一个电子邮件连接。将针对表示高血压、低血压和错误的药物服用的电子邮件通知创建不同的 Doctor Notification 操作。表示高血压和低血压的电子邮件通知包括了病人的心脏收缩和心脏舒张读数。

图 5. SmarterHealth 操作
图 5. SmarterHealth 操作
图 5. SmarterHealth 操作

Patient Notification 操作定义包括一个名为 analysis 的动作对象字段。该字段用于将信息传递给 SmarterHealth servlet 以显示给病人。这个操作的 HTTP 连接设置为:

  • Protocol:http
  • Host:localhost
  • Port:9080
  • Directory:/devworks/SmarterHealth/
  • Format:HTML Form
  • Method:POST

Doctor Notification 操作的电子邮件连接设置为:

  • Method:POST
  • Host:指定一个允许外部访问和转发的 SMTP 中继(relay)。
  • Port:25
  • Format:Text Email

中间对象

SmarterHealth-WBE.xml 项目文件定义了名为 BP、Glucose、MedMonitor 和 Doctor 的中间对象。这些中间对象具有以下字段和数据类型:

  • BP
    • systolic (Integer):使用来自 BP 事件的数据填充。
    • diastolic (Integer):使用来自 BP 事件的数据填充。
  • Glucose
    • level (Integer):使用来自 Glucose 事件的数据填充。
  • MedMonitor
    • compliance (Boolean):使用来自 MedMonitor 事件的数据填充。
  • Doctor
    • emailAddress (String):使用来自 BP、Glucose 和 MedMonitor 事件的数据填充。
图 6. SmarterHealth 中间对象
图 6. SmarterHealth 中间对象
图 6. SmarterHealth 中间对象

过滤器

如前所述,过滤器定义将由 WebSphere Business Events 评估的规则,以确定是否应该采取某个操作。通过向这些中间对象字段应用条件,过滤器将对一个或多个中间对象字段进行操作。例如,样例场景要求您定义一个过滤器来确定病人的血压读数是否正常。正常的血压读数要求心脏收缩值在 91-119 之间,而心脏舒张值在 61-79 之间。要创建一个检查正常血压的过滤器,需要向 BP 中间对象字段 systolic 和 diastolic 应用条件逻辑,如图 7 所示。

图 7. 正常的血压过滤器
图 7. 正常的血压过滤器
图 7. 正常的血压过滤器

SmarterHealth-WBE.xml 项目文件为高血压前期、高血压和低血压定义了额外的血压过滤器。针对药物服用情况的过滤器远远没有这么复杂;它只需要检查 compliance MedMonitor 中间对象字段是否为 true。

图 8. SmarterHealth 过滤器
图 8. SmarterHealth 过滤器

没有提供过滤器来评估葡萄糖读数。同样,样例应用程序提供了框架来接收和响应与葡萄糖有关的事件,但是没有提供用于执行分析的逻辑。要添加这种逻辑,您需要创建一个或多个过滤器并在 SmarterHealth-WBE.xml 项目文件中定义的 glucose 交互集和交互块中使用它们。

交互集

实现样例场景所需的最后一个 WebSphere Business Events 组件是交互集和交互块。这些组件定义了 WebSphere Business Events 在接收到事件时执行的业务逻辑。对于药物服用情况,样例场景需要您检查药物监视器读数来判断病人是否打开了包含其日常服用的 CholElim 计量的铝塑包装。如果病人打开了他的药品,那么遵从性读数将为 true,否则为 false。一项通知将被发送给病人,表示他是否遵从医嘱,并且只有在他不遵从医嘱的情况下向他的医师发送通知。要实现这个逻辑,将需要定义一个交互块,使用前面描述的表示服药情况的过滤器。如果过滤器被计算为 true,您将向患者发送一条通知,说明他的服药情况。要处理患者不遵从医嘱的情况,需要添加一个不同的交互块,如图 9 所示。

图 9. Medication Monitor Check 交互集
图 9. Medication Monitor Check 交互集
图 9. Medication Monitor Check 交互集

SmarterHealth-WBE.xml 项目文件定义了用于处理血压和葡萄糖读数的交互集和交互块(图 10)。

图 10. SmarterHealth 交互集
图 10. SmarterHealth 交互集

设置和配置

要设置并配置样例应用程序:

  1. 将 SmarterHealth-WBE.xml 项目文件的内容加载到 WebSphere Business Events 存储库:
    1. 启动 WebSphere Business Events Design Data。
    2. 使用 File 菜单项打开 SmarterHealth-WBE.xml 文件。
    3. 单击 Tools > Repositories...,显示 Repository 窗口。
    4. 单击 WBE Runtime 选项卡。
    5. 单击 Repositories Properties 窗口中的 Repositories 上的 OK
    6. 为 ID 和密码输入 admin/admin 值,并单击 Login
    7. 单击 Project 选项卡,选择所有项目资产,然后单击 Add In 以将所有项目资产添加到存储库。
    8. 关闭 Repository 窗口并关闭 WebSphere Business Events Design Data。当提示保存更改时,单击 No
  2. 将 SmarterHealth Web 应用程序安装到 WebSphere Sensor Events 所在的同一个应用服务器实例中。要安装应用程序,将需要打开 WebSphere Application Server 管理控制台并使用 Install New Applications 功能(Applications > Install New Applications)。在 Preparing for the application installation 页面,使用 Browse 功能导航到 本文提供的 SmarterHealthEAR.ear 文件。
  3. 将本文提供的 devworks.sample.smarter.health.deviceadapter_1.0.0.jar 文件复制到包存储库中。对于默认的安装,包存储的位置为:C:\Program Files\IBM\HTTPServer\htdocs\en_US\bundles。
  4. 导入 SmarterHealth-DeviceAgent-config.xml 和 SmarterHealth-WSE-config.xml 配置文件。要导入配置,打开 WebSphere Sensor Events 管理控制台并单击左侧导航面板上的 Import Configurations。使用 Browse 按钮导航到本文提供的配置文件。
  5. 将这个字符串附加到 WBERUCAS JMS 激活规范中的消息选择器的末尾:

    OR ibmse LIKE '%/HomeHealthEvent/%'

    要更新消息选择器,打开 WebSphere Application Server 管理控制台并选择 Resources > JMS > Activation specifications。单击 WBERUCAS 激活规范并将上面所示的字符串附加到现有的消息选择器的末尾。单击 ApplySave,将修改保存到主配置中。
  6. 重启 WebSphere Application Server:
    1. 停止 Windows 服务 IBM WebSphere Application Server V6.1 – PremisesNode。
    2. 启动 Windows 服务 IBM WebSphere Application Server V6.1 – PremisesNode。
  7. 将本文提供的 smarterhealth-bundles.txt 包列表文件复制到 WebSphere Sensor Events bundlelist 目录。对于默认的安装,这个目录的位置为:C:\Program Files\IBM\HTTPServer\htdocs\en_US\bundles\bundlelists
  8. 将 WebSphere Sensor Events DTS config.ini 文件重命名为 config.sav。对于默认安装,config.ini 的位置为:C:\Program Files\IBM\RFID\dts\configuration。
  9. 将本文提供的 config.ini 复制到 C:\Program Files\IBM\RFID\dts\configuration 目录。
  10. 停止 Windows 服务 IBM WebSphere Sensor Events DT Service。
  11. 打开一个命令提示窗口并切换到 C:\Program Files\IBM\RFID\dts 目录。
  12. 运行 resetdts.bat 文件以重置 DTS 运行时环境。
  13. 运行 dts.bat 以启动 DTS。
  14. 启动 WebSphere Business Events Connectors。

运行样例应用程序

要运行样例:

  1. 通过导航到以下位置打开 SmarterHealth Web 页面:http://<sensor_events_host_name>:9080/devworks/SmarterHealth。(样例应用程序需要 Microsoft® Internet Explorer 能够正常工作)。
  2. 为希望测试的事件输入值并选择事件的单选按钮。如果输入了触发医生通知的事件值,那么还将需要输入一个有效的电子邮件地址。
  3. 单击 Send Measurement 按钮以将事件数据发送给 Data Capture and Delivery 设备代理,并启动处理流程。

如果正确设置并配置了样例应用程序,您将看到病人通知显示在 SmarterHealth Web 页面的底部。如果输入的事件值触发了一个医生通知,那么电子邮件将被发送给在 Doctor email address 字段中输入的邮件地址。

结束语

虽然本文描述了如何实现一个简单的家庭健康监视设备、网关和监视系统,但是这个架构显然可以应用到更广泛的领域。只要来自远程连接设备的数据需要进行收集、存储、处理、分析或监视,那么都适合使用这个架构。

本系列文章一直在探讨如何使用传感器解决方案以及 WebSphere Sensor Events 和 WebSphere Business Events 实现 Smarter Planet 的关键方面 —— 仪表化、相互连接和智能化。目前为止,想象一下充分利用 WebSphere Business Events 之类的事件处理工具实现持续的、实时的事件分析和条件检测的可能性。并且,您可以利用 Cognos 之类的分析工具来研究持久化数据并提供商业智能来交付病人分析、报告、指示板和计分卡。

一切都始于对新数据的可见性;在本例中,指的就是家庭健康监视数据。这些新数据成为了彼此连接的医疗解决方案的一部分,这将导致产生新的智能,并最终实现更好的病人护理和更低的整体医疗成本。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=490952
ArticleTitle=使用传感器监控的 Smarter Planet 解决方案,第 3 部分: 构建更加智能的医疗设备监视解决方案
publish-date=052010