Smarter Planet solutions with sensor monitoring, Part 3: Building a smarter medical device monitoring solution

Smarter Planet™ initiatives are playing a major role in how technology is shaping our interactions with the world around us. Common to many of these initiatives is the observation and processing of sensor data to extract insights from the physical world. Part 3 in this series looks at a hypothetical remote medical patient monitoring system intended to improve the quality of patient care while reducing costs. This discussion describes how information from different types of connected devices can be remotely collected, merged, filtered, and reliably transmitted to a central monitoring system where healthcare providers can monitor, diagnose, and possibly even treat patient conditions. A connected healthcare system enables the entire system to become more intelligent, while adding significant value with increased accuracy, improved response times, reduced costs -- and an overall improvement in healthcare experience and results. This content is part of the IBM WebSphere Developer Technical Journal.


Tim Hanis (, WebSphere Sensor Events Chief Architect, IBM

Tim Hanis is the lead architect in WebSphere Sensor Events development at IBM in Research Triangle Park, NC. He has led a number of development projects within IBM and has extensive experience helping customers solve business problems with WebSphere products.

developerWorks Contributing author

Allen Smith ( ), Senior Software Engineer, IBM

Allen Smith is a Senior Certified IT Specialist in IBM's Application and Integration Middleware Software group in Research Triangle Park, North Carolina. He works with business partners to design and implement sensor based solutions using WebSphere Sensor Events. You can contact Allen at

developerWorks Contributing author

John Senegal (, WebSphere Sensor Events Lead Developer, IBM  

John Senegal is the lead developer for WebSphere Sensor Events Server at IBM in Research Triangle Park, NC. He has broad experience working with IBM customers and partners building solutions using IBM tooling and middleware.

Ken Greenlee (, Advisory Software Engineer, IBM  

Ken Greenlee is an Advisory Software Engineer with the WebSphere Sensor Events team at IBM in Research Triangle Park, NC. He has extensive Java/WebSphere experience and is responsible for many components within the WebSphere Sensor Events server product. He has worked with customers to create solutions based upon the WebSphere Sensor Events software stack. He has reached the third patent plateau, most on RFID technologies.

Bruce Hyre (, Senior Software Engineer, IBM  

Bruce Hyre is a Senior Software Engineer with the IBM Sensor Solutions in Research Triangle Park, North Carolina. He specializes in the design and integration of WebSphere Sensor Events with business partners and device manufacturers.

27 January 2010

Also available in Chinese


Traditionally, patient healthcare monitoring is performed live, in person. A patient must visit a healthcare facility to have his or her vital statistics collected and analyzed for warnings, trends, and anomalies. This is a significant manual process, consuming both patient and medical provider time and resources. It is also an inconvenient and imperfect process. The effectiveness of healthcare is critically linked to the time it takes to identify and diagnose conditions that are likely to adversely affect a patient’s health. Frequent and consistent health monitoring, therefore, can help improve healthcare results while reducing overall cost.

This article describes how home health monitors integrated with IBM® WebSphere® Sensor Events can be used to create a smarter healthcare solution. In describing how using IBM technology in these solutions can help deliver improved health care though better patient monitoring, this article will:

  • Discuss a sample healthcare solution and its components.
  • Define the architecture of the solution.
  • Describe an example use case to demonstrate specific aspects of the solution.
  • Explain the provided use case sample code.

Health monitoring

Healthcare costs have been rising at alarming rates for decades. Beyond finding new treatments and cures for existing conditions, the healthcare industry has increased its focus on prevention and early intervention in an effort to help alleviate preventable illnesses and their associated costs. In addition, though, is the cost of long-term monitoring and treatment. To make a treatment effective, it must be tailored individually to each patient, and can change over time as the patient’s condition changes. A significant part of the challenge for both early detection and ongoing treatments is the time and cost involved in patient monitoring

If the amount of manual professional involvement that was required in detecting and monitoring patient health could be reduced without sacrificing -- in fact, potentially improving -- the effectiveness and timeliness of a response when a true event occurred, the better the patient experience and outcome would be, while at the same time reducing the overall costs.

Another way to think of this is visibility into patient health (and if you have read the other articles in this series, visibility should be a familiar theme). A pioneer in home health monitoring, Continua Health Alliance is a non-profit, open alliance of healthcare and technology companies working on issues of personal healthcare. Through this alliance, standards around vital sign monitoring (or remote patient monitoring) through basic life monitoring are being addressed to define integration points for pulse and blood pressure data, weight scale, glucose meters, fitness monitors, medications monitors and so on, that would ultimately enable this kind of comprehensive visibility.

The solution is for healthcare systems to become smarter.

  • Instrumented

    As discussed in previous articles, the first step to becoming smarter is through instrumentation. It is instrumentation that will provide the foundation for health visibility. In healthcare, instrumentation means medical instruments, such as heart rate monitors, pulse oximeters, glucose meters, and blood pressure monitors.

    Today, many doctor’s offices have electronic health monitors that increase the reliability and accuracy of readings, and some are even possible for less-skilled people to use with the same reliability. The number of these types of devices continues to grow, as does the applicability for home use with remote health data collection. For example, exciting new devices are coming on the market, such as dosage monitors that can notify a healthcare system when medication is taken.

  • Interconnected

    Even though they are digital, most readings taken today are still performed and transcribed manually. They also reside primarily at the doctor’s office and, therefore, still require an office visit, the involvement of a medical professional to take and transcribe the readings onto the patient’s chart, and a doctor to review the physical chart and interpret the findings. This basic process is time-consuming, expensive, and inconvenient, particularly for seriously ill, chronic, immobile, or elderly patients.

    To enable the next level of advancement in healthcare monitoring and cost reduction, two things need to happen: these instruments need to move out to the patient, and the instruments need to be connected to the healthcare providers themselves. Without a connection, remote monitoring is of no more value than in-office readings. This connection also means that multiple healthcare providers can benefit from the live data: a patient with multiple conditions could be tracked by several doctors and specialists simultaneously. A health management organization could also monitor the data, provide recommendations, or approve referrals or advanced treatment with faster turnaround, since they would already have all of the patient’s monitored statistics. This would also help reduce the opportunity for medical fraud, since the insurer would have access to the raw medical data.

  • Intelligent

    When this monitored sensor data becomes visible to the healthcare providers participating in a patient’s care, the whole system can become intelligent: the sensor readings can be intelligently monitored, the routine can be automated every-day, low-value operations that can typically waste health provider time and resources can be eliminated.

    For example, blood pressure, glucose, and oxygen readings must be taken regularly, but in most cases, if they are within reasonable and normal ranges, there is no need for a healthcare professional to be alerted. In the case of anomalies, such as elevated heart rate, low blood-pressure, elevated blood sugar (glucose), or high temperature (indicating fever or the possible the onset of an infection), then a doctor would be informed. Similarly, a longer-term trend, such as increased weight over time (which could indicate stress for a heart failure patient or fluid retention for a diabetic) would also interest a doctor.

    It is not uncommon for a decision to send a patient home to be influenced by cost containment concerns; the healthcare system is trying to balance the need for constant monitoring and readily available doctors against the cost of keeping the patient in a care facility. A reasonably stable patient might be sent home with remote monitoring. Most patients will likely do well with this, with no further intervention necessary; if an event does occur, the healthcare system will catch it and respond. Today, however, this involves a complex system of secondary health monitoring and home-care agencies adding cost to the treatment. In one example, a pharmacist could only monitor 40 patients at a time, had to call each patient weekly (if not daily), collect status and self-administered readings, verify equipment condition (battery, blockage, and so on), and verify medication dosing and quantity on-hand.

    With a connected medication monitor, the system could monitor dosing remotely and intelligently raise an alarm if a patient misses doses, or takes a medication incorrectly or inappropriately. For mild infractions, with an intelligent, connected notification system, family members could be alerted to handle simple, non-critical interventions, further reducing costs.

Solution architecture

Through the process of instrumentation, interconnection, and intelligence, a supply chain system with major challenges is transformed into a system that is smarter: more accurate, more reliable, more efficient, and more open, which ultimately makes it much more valuable.

Figure 1. Smarter healthcare reference architecture
Figure 1. Smarter healthcare reference architecture

Elements of this healthcare reference architecture (Figure 1) include:

  • Data capture

    When implementing a smart healthcare system, the Data Capture and Delivery component is the main integration point for connected devices, being the first stop in the chain of processing between the sensor device and the IBM WebSphere Sensor Events server. The data capture component of WebSphere Sensor Events consists of a software stack that resides on or near the sensor device. It provides a framework to build device adapters for device communications, a location for business logic with low latency requirements, and actively manages devices such as scanners, conveyor belts, diverters, and so on. In a smart healthcare system, sensors will be wireless, USB, Ethernet, or serially-connected medical monitoring devices, such as blood pressure (BP), glucose, heart rate, EKG, and pulse-oximeter monitors. Data Capture and Delivery provides a framework to normalize, filter, smooth, and summarize the data, either eliminating extraneous data or compressing the data volume to reduce the bandwidth and server load. Data Capture and Delivery also buffers the data, handling unreliable communications so that application logic doesn’t have to.

  • WebSphere Sensor Events

    This article will not cover the function or purpose of the WebSphere Sensor Events Gateway component because it was discussed in Part 2, and its role in the solution architecture does not change for a smarter healthcare solution. However, the role and services provided by the WebSphere Sensor Events server does change. Here, the WebSphere Sensor Events server becomes what is known as a Remote Patient Monitoring Server (RPMS), which is part of an overall Remote Patient Monitoring System that includes medical devices connected to a medical device gateway, which connects to an RPMS.

  • WebSphere Business Events

    The true value in the RPMS is the ability to discover important patterns or an alarming reading in the medical device message as it flows through the system. WebSphere Business Events fulfills that role in this reference architecture. It provides a platform for solution builders and users to write detection rules on patterns of data. When the pattern is detected, some action can be performed, such as notifying a doctor or attending nurse, or forwarding the event to an Electronic Health Record (EHR) system. If necessary, a WebSphere Business Events rule could drive an action all the way down to the medical device itself, perhaps to get more data, force another reading to verify the reading in question, or increase the monitoring frequency for even closer monitoring.

  • WebSphere Business Monitor

    WebSphere Business Monitor provides the facilities for care providers to easily monitor WebSphere Business Events or WebSphere Sensor Events output for suspicious trends. The monitoring could be in the form of various dashboards, charts, or graphs. Care providers could then use this data for decision support to forward the information to the EHR system or to IBM Cognos® Business Intelligence for further analytic support using other patient history records.

  • IBM Cognos Business Intelligence

    The data from the medical devices has arrived in the PRMS and has been persisted. WebSphere Business Events has monitored the events based on the required rule set. WebSphere Business Monitor has displayed the patterns in the data coming from the device. Although the device data provides caregivers with a wealth of knowledge that did not previously exist, the device data alone is not always enough for a complete diagnosis. For caregivers to be able to provide actionable recommendations, the solution must be capable of providing analytics. IBM Cognos is the platform that provides the necessary analytics for medical professionals to give fast but accurate recommendations, based on patient history and based on what was successful for similar patients with similar ailments. There are several EHR systems that include Cognos for its analytics capabilities.

  • Electronic Health Record system

    An EHR system is the master repository for health records for a patient. The repository stores the relevant medical device data, lab results, doctor visits, hospitalization records, and so on. This part of the architecture is outside of the scope of this article, but it is important to note that in a full smarter healthcare solution, an EHR system is a requirement.

Connecting healthcare devices to WebSphere Sensor Events

For cost and complexity reasons, most devices do not have wide-area networking capabilities. More than likely, they are Bluetooth, RS-232 serial, USB, or maybe Wi-Fi, so they must be locally connected (imagine every monitor having its own cell data modem and associated plan costs!). You need a local, central connection point that supports the above connection types. All devices of the same type, but different manufacturer, should be normalized at the API, in the data format, and in the lifecycle management (that is, deployment, starting, stopping, configuration, and removal).

Each device interface needs to manage the connection to the device, interface through the custom device protocol, and present a normalized, outward-facing API. It then needs to collect and process the data, filtering it and normalizing it into a standard format, then manage the communications and submit the event to the server. Each device is also a platform for local business logic where fast response, low latency, load distribution, bandwidth conservation, and high reliability are needed. This is the role that Data Capture and Delivery plays.

In the case of our sample connected health system, Data Capture and Delivery serves as a collection and control point for the connected but less-intelligent devices. There would be one data capture health gateway in each home, for all family members, giving the family a way to manage their own data -- a significant concern in the age of personal information security. Data Capture and Delivery exists for all of these reasons.

To interface the health care devices used in the sample scenario, a custom device agent bundle was created using the IBM Data Capture and Delivery Toolkit for WebSphere Sensor Events (see Resources). This bundle requires three classes to handle each of the three key responsibilities:

  • Activator: Manage the agent’s lifecycle (start, stop).
  • Advisor: Configure the agent and update it if the configuration changes.
  • Agent: Implement the business logic.

For clarity, the classes are split into two packages to separate the business logic or model code ( from the code responsible for creating and configuring the agent ( While the process of creating an agent is somewhat complex, the data capture component provides a set of lightweight class hierarchies that greatly simplify the implementation. In most cases, this entails just subclassing one of the framework classes, and overriding one or more hook methods as needed, depending how unique or complex your requirements are.

The Activator class (DeviceAdapterAgentActivator) is responsible for determining when to create the agent, based on the services it imports. Once the required services have been imported, it then creates the advisor. The Activator class subclasses AbstractManagedServiceFactoryActivator to inherit most of the behavior needed to do this. Since you have an agent that might have many instances (that is, one configured for each attached device) the managed service factory interface is used. This interface enables you to create different instances of the agent based on different configurations. In this case, there are no imported services, no conditions to check, and no need to customize the way the agent is configured, so the activator is simple: It simply creates the appropriate advisor (DeviceAdapterAgentAdvisor). The agent does import packages but the framework takes care of this for you and calls the doCreateAdvisor() method once they have been imported. So, in this simple case, all that method does is create the advisor and return it (Listing 1).

Listing 1
protected AbstractManagedServiceFactoryAdvisor doCreateAdvisor() {
	return (new DeviceAdapterAgentAdvisor());

The Advisor class (DeviceAdapterAgentAdvisor) is responsible for managing the agent’s configuration. This means creating the model class and services, and feeding them configuration information at startup, and later if there are configuration changes. Again, you subclass a framework class (AbstractManagedServiceFactoryAdvisor) and override only the hook method(s) needed to create the behavior required for this case. Here, you just want to create an instance of your class as the service agent at the proper time. If there is a live update to the configuration, you will let the framework destroy it, and you’ll just create a new one with the new configuration (the hook method update() is available if you would rather update the current configuration than destroy and create).

The method doCreate() is called when it is time to create the agent, and the new configuration properties are automatically passed in by the framework in the properties argument. You create the DeviceAdapterAgent instance and pass those configuration properties along to the constructor (Listing 2).

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

You now have the agent instance created. Your DeviceAdapterAgent is subclassed from AbstractAgent, which provides many common behaviors for agents: handling incoming events, publishing events, error handling and logging, tracing, property handling, and so on. Now you need to initialize it, and open the socket for the medical device to connect to.

In the process of activation, the framework calls the binding() method on your agent. Here, you call your own method openListener(). This is the method that does all the work for the sample application; it does some setup (opens ServerSocket), then starts a loop to accept the incoming connections.

When it gets a connection, it reads and parses the data from the device (BP=120/, looking for the reading (event) type and value, and the e-mail address for notification (this is only to simplify the e-mail notification in the server).

To send an event in Data Capture and Delivery to the server, you create a hashtable with the event type (key: eventType) and the message itself (key: value) in a nested hashtable. From the example, the message contents are shown in Listing 3.

Listing 3
name: diastolic_reading, value: 80
name: emailAddress, value:
name: systolic_reading, value: 120

And the nested hashtables look like Listing 4.

Listing 4
	name: eventType, value: HHL/HomeHealthEvent/BP
	name: value, value: {
		name: diastolic_reading, value: 80
		name: emailAddress, value:
		name: systolic_reading, value: 120}

Finally, any metadata is stored as another hashtable, at the key dataExtensions. The sample uses metadata to store the event type to simplify processing in WebSphere Business Events. The final nested hashtable is shown in Listing 5.

Listing 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:
		name: systolic_reading, value: 120}

Thus, the code to create the event hashtable is shown in Listing 6.

Listing 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);

In a more complex system, you might have downstream agents that subscribe to one or more of the topics coming out of the device agent using the message handler handlePublishArrived(String topic, Dictionary event). For example, if you had a pulse-oximeter that the patient wore all the time, you wouldn’t want to overload the server with every reading, so you might write an agent to batch them up, or summarize them, or maybe drop "normal" readings and only send an event when a value exceeded a reasonable range. In this simple case, you just want to publish this message to the server. The AbstractAgent superclass provides you with the publish(String topic, Hashtable eventMessage) method, so the publish is simply:

publish(healthEventTopicPrefix + deviceEvent, msg);

From there, the event flows through the EventTransformAgent (via configuration you will import) to convert it to XML, through the NotificationServiceBridgeAgent to the MicroBroker, where it is buffered and optionally persisted, and finally sent to the WebSphere Sensor Events gateway for processing.

Sample scenario

The sample scenario is based on the connected personal health model, which extends healthcare treatment beyond traditional clinical settings into the patient’s home.

The patient in this example has several health related concerns:

  • History of high blood pressure.
  • Taking medication to lower cholesterol.
  • Has diabetes.

To help the patient better manage his health and reduce the frequency of doctor and hospital visits, his doctor has enrolled him in a trial program that remotely monitors his blood pressure, medication compliance, and glucose levels.

As part of the trial, the patient has installed a blood pressure monitor, a medication monitor, and a glucose meter in his home. These devices are connected to a device referred to as a home health gateway. This gateway interfaces with the in-home health devices to capture data and forward it to a remote patient monitoring system. In this scenario, the WebSphere Sensor Events data capture component runs on the home health gateway. The Data Capture and Delivery stack is responsible for interfacing with the medical devices, filtering and smoothing the raw data, and forwarding the data to the remote patient monitoring system running on the WebSphere Sensor Events server.

When the events arrive at the WebSphere Sensor Events server, they are picked up by the WebSphere Business Events Reusable Component, which converts incoming sensor events into a format consumable by WebSphere Business Events and forwards them (via a JMS message queue) to the WebSphere Business Events runtime for processing. WebSphere Business Events evaluates the incoming events, applies logic defined for the event type, and invokes one or more actions determined by executing the logic:

  • For blood pressure events, the WebSphere Business Events logic determines if the patient’s blood pressure reading is normal or if they have pre-hypertension, hypertension, or hypotension. WebSphere Business Events sends a notification back to the patient informing him of his blood pressure category, and triggers an e-mail alert to his doctor whenever his blood pressure readings indicate hypertension of hypotension.
  • The patient has been prescribed a statin drug called CholElim to lower his cholesterol. The patient’s doctor has instructed him to take the medication once a day. Compliance with the doctor’s instructions is determined using a medication monitor. The medication monitor detects the opening of a specially designed "blister pack" containing the CholElim tablet. The medication monitor records the opening of the blister pack along with the time it was opened. This data is captured in a medication monitor event. The WebSphere Business Events logic defined for medication monitor events determines if the patient consumed the required daily dosage of CholElim. WebSphere Business Events sends a notification back to the patient informing him of his medication compliance. A notification is sent to the patient’s doctor if he fails to take his required medication.
  • To better manage his diabetes, the patient has a glucometer (glucose meter) installed in the home. In this example, you want to analyze the glucose events to determine if the patient’s blood sugar indicates hyperglycemia or hypoglycemia. WebSphere Business Events logic has been implemented to receive the event and respond to the patient, but not to actually analyze the blood sugar levels. The intent is to provide the framework for receiving and responding to the glucose events and for you to add the logic to actually analyze the events.

Implementing the sample

In an actual implementation, blood pressure monitors, medication monitors, and glucometers would be used to monitor and collect the patient’s health data. Data capture device agents would interface with these devices via Bluetooth, USB, TCP, or some other protocol to capture the data. To simplify this example, a Web application called SmarterHealth is supplied with the sample application materials (see Download) to substitute for these devices. A data capture device agent (also provided) will interface with the SmarterHealth servlet using a socket connection to capture the data.

The SmarterHealth Web page (Figure 1) enables you to enter blood pressure, medication compliance, and glucose readings and send those readings to the data capture device agent. Patient notifications sent from WebSphere Business Events are displayed at the bottom of the SmarterHealth Web page. Doctor e-mail notifications sent from WebSphere Business Events are sent to the e-mail address entered in the Doctor email address field.

Figure 2. SmarterHealth Web page
Figure 2. SmarterHealth Web page

Application flow

When you click the Send Measurement button on the SmarterHealth Web page, the SmarterHealth servlet extracts the event readings from the HttpServletRequest object, opens a socket to the data capture device agent, and sends the data (Figure 3).

Figure 3. Application flow
Figure 3. Application flow

The data capture device agent interprets the event, parses the data, constructs the required objects, and publishes a message to the topic associated with the event. The messages are published with these topic names:

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

These topics are configured to WebSphere Sensor Events to be forwarded from the data capture device to the WebSphere Sensor Events server for additional processing. Events forwarded from the data capture component are converted from the data capture format to ISensorEvent XML and sent to the WebSphere Sensor Event server gateway. The gateway converts the XML to an ISensorEvent object and publishes the object onto the WebSphere Application Server service integration bus (SI bus) messaging engine configured for WebSphere Sensor Events. The topics are constructed from data passed in the ISensorEvent XML and match those used in Data Capture and Delivery . Once the event object is published, the publish and subscribe messaging engine (pub/sub) delivers the event to all subscribed Java™ 2 message-driven beans.

The WebSphere Business Events Reusable Component is a message-driven bean responsible for converting ISensorEvent objects into XML formatted messages consumable by WebSphere Business Events. When configured to subscribe to the HomeHealthEvent topics, the WebSphere Business Events Reusable Component will convert the ISensorEvent objects into the required XML format and send it to WebSphere Business Events via JMS.

WebSphere Business Events evaluates the incoming events, applies logic defined for the event type, and invokes one or more actions determined by executing the logic. In the sample scenario, these actions consist of patient and doctor notifications. Patient notifications are sent to the SmaterHealth servlet via an HTTP POST, and doctor notifications are sent via e-mail.

Event conversion

ISensorEvent objects contain a header, payload, and payload metadata. The header provides information about where and when the event was observed, the payload contains the event data (for example, systolic and diastolic readings), and the payload metadata contains additional data about the event (Listing 7).

Listing 7. Sample ISensorEvent object
	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}
	attributes: {
	name: wbe.eventname, value: BP, type: 18}
	groups: {
	name: value
		attributes: {
		name: diastolic_reading, value: 80, type: 12
		name: emailAddress, value:, type: 18
		name: systolic_reading, value: 120, type: 12}}

As mentioned earlier, the WebSphere Business Events Reusable Component converts ISensorEvent objects into the XML format required by WebSphere Business Events. This conversion process creates corresponding header, payload, and payload metadata elements in the WebSphere Business Events event XML, as shown in Listing 8.

Listing 8. Sample WebSphere Business Events event XML
<?xml version="1.0" encoding="UTF-8" ?>
<connector name="WebSphere Sensor Events Server" version="6.2">
  <connector-bundle name="BP" type="event">
      <sourceId type="String">H1</sourceId>
      <eventType type="String">HHL/HomeHealthEvent/BP</eventType>
      <dateTime type="DateTime">2010-01-19T12:04:14-0500</dateTime>
      <emailAddress type="String"></emailAddress>
      <systolic_reading type="Integer">120</systolic_reading>
      <diastolic_reading type="Integer">80</diastolic_reading>
  <loginfo>An event of type: HHL/HomeHealthEvent/BP has arrived from  
   location: H1</loginfo>

The WebSphere Business Events Reusable Component uses the wbe.eventname attribute value (from the payload metadata) to set the value of the <connector-bundle> element name attribute. This value is appended to the strings: IBMSE_Header, IBMSE_PayloadMetaData, and IBMSE_Payload when constructing the header, payload, and payload metadata elements in the WebSphere Business Events XML. These names are important because they are required when creating event definitions in WebSphere Business Events. The wbe.eventname attribute values used in the sample application are:

  • BP
  • MedMonitor
  • Glucose.

Application logic

In the sample application, all the application logic is implemented in WebSphere Business Events, and is defined using these components:

  • Touchpoints: Define collections of events and actions that represent external applications that send events to and receive notifications from WebSphere Business Events.
  • Events: Define input received from external applications. Events trigger the execution of business logic by WebSphere Business Events. The events in the sample application originate from WebSphere Sensor Events.
  • Actions: Define the notifications sent from WebSphere Business Events to external applications or systems. The patient and doctor notifications described earlier are actions triggered by WebSphere Business Events when it runs the business logic defined by the sample application.
  • Intermediate objects: Composite business objects with that data can come from multiple sources. The data might come from an incoming event, be calculated, or be retrieved from an external data source. In the sample application, all the intermediate objects are populated with data from incoming events. The business logic run by WebSphere Business Events operates on intermediate objects.
  • Interactions sets: Contain one or more interaction blocks that define the business logic to be run by WebSphere Business Events when it receives an event.
  • Filters: Define the rules evaluated by WebSphere Business Events to determine whether or not an action should be taken.

Events and actions

The SmarterHealth-WBE.xml project file defines a touchpoint called WSE Events to hold the event definitions. Under this touchpoint, you define events called BP, MedMonitor, and Glucose with corresponding event object definitions, called IBMSE_Payload_BP, IBMSE_Payload_Glucose, and IBMSE_Payload_MedMonitor. Event object definitions were not added for the header and payload metadata elements because they do not contain any data required to implement this scenario.

Figure 4. SmarterHealth events
Figure 4. SmarterHealth events

Event object fields are defined for (and must match) the data passed in the event XML. The names and data types used in this scenario are:

  • 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)

The doctor’s e-mail address is passed on each event to simplify the scenario. In a real implementation, each event would include some type of patient identifier that would be used to find the doctor’s e-mail address from an external data source.

This sample scenario requires that you send notifications to the patient whenever a home health event is processed, and to the patient’s doctor whenever there is a problem. The SmarterHealth-WBE.xml project file defines a touchpoint called Notifications. Under this touchpoint you define actions called Patient Notification and Doctor Notification. The Patient Notification action uses an HTTP connection and the Doctor Notification uses an e-mail connection. Variants of the Doctor Notification action are created for e-mail notifications indicating hypertension, hypotension, and medication non-compliance. The hypertension and hypotension e-mail notifications includes the patient’s systolic and diastolic readings.

Figure 5. SmarterHealth actions
Figure 5. SmarterHealth actions

The Patient Notification action definition includes an action object field called analysis. This field is used to pass information to the SmarterHealth servlet for display to the patient. The HTTP connection settings for the action are:

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

The e-mail connection settings for the Doctor Notification action are:

  • Method: POST
  • Host: Specify an SMTP relay that permits external access and forwarding.
  • Port: 25
  • Format : Text Email

Intermediate objects

The SmarterHealth-WBE.xml project file defines intermediate objects called BP, Glucose, MedMonitor, and Doctor. These intermediate objects have the following fields and data types:

  • BP
    • systolic (Integer): populated with data from BP events.
    • diastolic (Integer): populated with data coming from BP events.
  • Glucose
    • level (Integer): populated with data coming from Glucose events.
  • MedMonitor
    • compliance (Boolean): populated with data coming from MedMonitor events.
  • Doctor
    • emailAddress (String): populated with data coming from BP, Glucose, and MedMonitor events.
Figure 6. SmarterHealth intermediate objects
Figure 6. SmarterHealth intermediate objects


As mentioned earlier, filters define the rules evaluated by WebSphere Business Events to determine whether or not an action should be taken. Filters operate on one or more intermediate object fields by applying conditions to these fields. The sample scenario, for example, requires that you define a filter to determine whether or not a patient’s blood pressure reading is normal. A normal blood pressure reading requires a systolic value of 91-119 and a diastolic value of 61-79. To create a filter to check for normal blood pressure, you would apply conditional logic to the BP intermediate object fields systolic and diastolic, as shown in Figure 7.

Figure 7. Normal blood pressure filter
Figure 7. Normal blood pressure filter

The SmarterHealth-WBE.xml project file defines additional blood pressure filters for pre-hypertension, hypertension, and hypotension. The filter for medication compliance is much less complex; it simply checks to see if the compliance MedMonitor intermediate object field is true.

Figure 8. SmarterHealth filters
Figure 8. SmarterHealth filters

No filters are provided for evaluating glucose readings. Again, the sample application provides the framework for receiving and responding to the glucose events, but does not provide the logic to analyze them. To add this logic you’ll need to create one or more filters and use them in the glucose interaction set and interaction blocks defined in the SmarterHealth-WBE.xml project file.

Interaction sets

The final WebSphere Business Events components required to implement the sample scenario are the interaction sets and interaction blocks. These components define the business logic executed by WebSphere Business Events when it receives an event. For medication compliance, the sample scenario requires that you examine the medication monitor reading to determine if the patient has opened the blister pack containing his daily dosage of CholElim. If the patient opened his medication, the compliance reading will be true, otherwise false. A notification is sent to the patient indicating his medication compliance or non-compliance, and to his doctor for medication non-compliance only. To implement this logic, you would need to define an interaction block that uses the previously described medication compliance filter. If the filter evaluates to true, you send a notification to the patient indicating medication compliance. To handle medication non-compliance, you would add an otherwise interaction block, as shown in Figure 9.

Figure 9. Medication Monitor Check interaction set
Figure 9. Medication Monitor Check interaction set

The SmarterHealth-WBE.xml project file defines additional interaction sets and blocks required to process blood pressure and glucose readings (Figure 10).

Figure 10. SmarterHealth interaction sets
Figure 10. SmarterHealth interaction sets

Setup and configuration

To setup and configure the sample application:

  1. Load the contents of the SmarterHealth-WBE.xml project file into the WebSphere Business Events repository:
    1. Start WebSphere Business Events Design Data.
    2. Use the File menu function to open the SmarterHealth-WBE.xml file.
    3. Click Tools > Repositories... to display the Repository window.
    4. Click the WBE Runtime tab.
    5. Click OK on the Repositories in the Repositories Properties window.
    6. Enter admin/admin value for the ID and password, and click Login.
    7. Click the Project tab, select all the project assets, then click Add In to add all the project assets into the repository.
    8. Close the Repository window and close WebSphere Business Events Design Data. When prompted to save changes, click No.
  2. Install the SmarterHealth Web application into the same application server instance on which WebSphere Sensor Events is installed. To install the application, you’ll need to open the WebSphere Application Server administrative console and use the Install New Applications function (Applications > Install New Applications). On the Preparing for the application installation page, use the Browse function to navigate to the SmarterHealthEAR.ear file provided with this article.
  3. Copy the file provided with this article to the bundle repository. For a default installation, the location of the bundle repository is: C:\Program Files\IBM\HTTPServer\htdocs\en_US\bundles.
  4. Import the SmarterHealth-DeviceAgent-config.xml and SmarterHealth-WSE-config.xml configuration files. To import the configurations, open the WebSphere Sensor Events administrative console and click on Import Configurations in the left navigation pane. Use the Browse button to navigate to the configuration files provided with this article.
  5. Append this string to the end of the message selector in the WBERUCAS JMS activation specification:

    OR ibmse LIKE '%/HomeHealthEvent/%'

    To update the message selector, open the WebSphere Application Server administrative console and select Resources > JMS > Activation specifications. Click on the WBERUCAS activation specification and append the string shown above to the end of the existing message selector. Click Apply and Save to save the changes to the master configuration.
  6. Restart WebSphere Application Server:
    1. Stop the Windows service IBM WebSphere Application Server V6.1 – PremisesNode.
    2. Start the Windows service IBM WebSphere Application Server V6.1 – PremisesNode.
  7. Copy the smarterhealth-bundles.txt bundle list file provided with this article to the WebSphere Sensor Events bundlelist directory. For a default installation, the location of this directory is: - C:\Program Files\IBM\HTTPServer\htdocs\en_US\bundles\bundlelists
  8. Rename the WebSphere Sensor Events DTS config.ini file to config.sav. For a default installation, the location of the config.ini is: C:\Program Files\IBM\RFID\dts\configuration.
  9. Copy the config.ini provided with this article to the C:\Program Files\IBM\RFID\dts\configuration directory.
  10. Stop the Windows service IBM WebSphere Sensor Events DT Service.
  11. Open a command prompt window and switch to the C:\Program Files\IBM\RFID\dts directory.
  12. Run the resetdts.bat file to reset the DTS runtime environment.
  13. Run dts.bat to start DTS.
  14. Start the WebSphere Business Events Connectors.

Running the sample application

To run the sample:

  1. Open the SmarterHealth Web page by navigating to: http://<sensor_events_host_name>:9080/devworks/SmarterHealth. (This sample application requires Microsoft® Internet Explorer to work properly.)
  2. Enter values for the event you want to test and select the event’s radio button. If you are entering event values that trigger a doctor notification, you’ll need to enter a valid e-mail address as well
  3. Click the Send Measurement button to send the event data to the Data Capture and Delivery device agent and start the processing.


If you setup and configured the sample application correctly, you will see the patient notification displayed at the bottom of the SmarterHealth Web page. If the event values entered trigger a doctor notification, an e-mail should will be sent to the address entered in the Doctor email address field.


While this article described how a simple in-home health monitoring device, gateway, and monitoring system are implemented, there are clearly many more domains where this architecture applies. Anywhere that data coming from remotely connected devices needs to be collected, stored, processed, analyzed, or monitored is a prime candidate.

This article series has been exploring how the key aspects of Smarter Planet -- instrumentation, interconnection, and intelligence -- are realized through sensor solutions and using WebSphere Sensor Events and WebSphere Business Events. By now, you can imagine the possibilities of leveraging the full power of event processing tools like WebSphere Business Events for continuous, real-time event analysis and condition detection. Further, you can leverage analytics tools like Cognos to interrogate persisted data and provide the business intelligence to deliver patient analysis, reports, dashboards and scorecards.

It all starts with visibility to new data; in this example, home health monitoring data. That new data becomes part of your interconnected healthcare solution, which leads to new intelligence, and ultimately to improved patient care and an overall reduction in health care costs.


Code sampleSmarterHealth.zip49 KB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Smarter Planet solutions with sensor monitoring, Part 3: Building a smarter medical device monitoring solution