Project Health Design
University of Washington
Chronic Disease Management between Office Visits RWJF Grant #: 59882
Design Documentation and Core Component Testing Report
Design Documentation
This description was intended to facilitate sharing of design elements across
Project HealthDesign teams and, in compliance with the RWJF open source
requirements, enable others to use components of your design.
Introduction
HealthReachMobile is a personal health information delivery system designed to
help patient to co-manage chronic illness from any location. This is
accomplished through wireless collection of patients’ physiological data and
lifestyle behavior as they happen. Patients receive progress feedbacks and
positive reinforcements via email messages and graphical charts on their mobile
phones.
Design Considerations
Hardware constraints
HealthReachMobile system should be run on server level systems. The minimal
requirements for adequate performance include:
a. Quad-core CPU
b. 4+ GB memory
c. RAID configured hard drives with at least 50 GB
Client devices consist of Windows Mobile SmartPhone and web browsers. The
SmartPhone should be running Windows Mobile 2005 or later. Web browsers
should support Outlook web.
Software requirements
HealthReachMobile was developed on Windows platform and leverages specific
Microsoft products. The following products are required for the building and
operation of HRM.
a. Windows Server 2003
b. SQL Server 2007
c. Exchange 2007
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
d. Visual Studio 2005
Other versions of these applications and OS have not been tested.
Network layout
The network layout we use for HRM is shown in figure 1. The network consists
of three servers. HRM2 is the domain controller and directory server. HRM5
hosts Exchange and HRM applications including management tool and glucose
uploading services. HRM3 hosts SQL Server 2007 and the hrm database.
Figure 1: HRM network layout
Performance
System Architecture
Three tiered design
2
HRM architecture consists of three major components (Figure 2): data
management systems (Figures 2A, 2B, and 2C), middleware application services
and libraries (Figure 2D), and client devices (Figure 2E).
Figure 2: HRM system architecture
Data management tier: (Figure 2A, 2B, and 2C)
HRM data management consists of internal and external data sources. The
internal HRM database (Figure 2B) stores system information including: user
profiles, glucose readings, food images, message templates, outgoing
messages, and user responses. Access to HRM data records is mediated by
TSQL scripts. Stored procedure scripts improve data management through
centralized administration, maintenance, and security for all requests to the
database.
External applications providing additional system function are accessed through
custom data connectors. For example, the data connector to CliniPro Server
3
(Figure 2A) utilizes XML over socket to exchange information. Data
management with the Exchange server (Figure 2C) is done via Database Mail
and a custom Exchange plug-in.
Middleware tier: Services and libraries (Figure 2D)
HRM services are computer software which provides the business logic for the
system. The most important component at this middle level is HeathReachLib
library. HealthReachLib provides data mapping to and from the data
management subsystems to connecting applications. Thus, all HRM applications
and services utilize HealthReachLib library for data objects management and
processing.
Presentation tier: Client devices (Figure 2E)
The presentation component manages user inputs, sends requests to the
system, and displays results. For example, Outlook Mobile on the SmartPhone
provides the presentation and user interface to the automated messaging
application.
Using email for realtime two-way messaging
The system is set up to support messaging logic that consists of a question or
statement followed by a number of responses. Responses trigger follow up
messages, which in turn have other responses in a branching chain. For
practical purposes, we kept the maximal message chain to four levels deep. The
development and testing of this system was primarily part of a separate grant
funding the NICHE consortium (RWJF grant #052601). This system is described
in further detail in that grant’s final report.
Wireless automated glucose upload
We use the CyberFab wireless Bluetooth dongle and BlueTouch application to
send meter readings from the SmartPhone to GlucoseUploadService. The
BlueTouch application runs on the SmartPhone.
GlucoseUploadService
GlucoseUploadService is a custom socket-based service for glucose data
transfer from patients’ SmartPhones.
4
Automated graphical and statistical email feedback
Upon receipt of new glucose meter readings HRM system can send embedded
graphical email showing weekly averages, standard deviations, and other
statistics. The graphical charts are generated using Google Charting API.
Data Interfaces
Data connectors were developed for various backend and external applications
to exchange with HRM.
Data interface to CliniPro diabetes management suite (optional)
CliniPro for providers and Patient Partner for patients are linked applications for
diabetes co-management (Numedics, Portland Oregon
http://www.numedics.com/). A backend interface was developed to handle
transfer of uploaded patient glucose data to the CliniPro database residing on
University of Washington server ZUMA.
Data interface to CommonPlatform PHR (optional)
RWJF’s CommonPlatform is a PHR data management application. A backend
interface was developed to store and retrieve patient health information from the
Common Platform.
Patient Messaging Service
The external interface of HealthReachMobile is the Patient Messaging Service,
whose principle function is to integrate information from the Backend Applications
into messages for delivery to patients’ smart phones, PDA, or PC. It also
processes replies and configuration settings from patients and updates the
appropriate Backend Applications. The Patient Messaging Service leverages MS
Exchange for content delivery and PIM support. For example, clinic
appointments and medication schedules are reflected on patient’s phone
calendar after synchronizing with the Exchange server. Media clips can also be
delivered for a more enriching experience.
The service handles authentication, security, and logging of information served.
The service combines data sources from different EMRs providing a seamless
view of the data to the client device and patient.
Client Device Applications
HealthReachMobile patients uses an integrated suite of applications on their
smart phones to access the Personal Health Applications services. These
include:
1) MS Mobile Outlook client for messaging and PIM functions
5
2) A food capture application for patients to snap real-time pictures of their
meal for dietary analysis over time
3) An application to securely sends glucose and other physiological readings
uploaded via CyberFab’s Bluetooth reader to the smart phone for delivery
to the backend EMR
6
Summary of system design and data flow
Figure 4 summarizes the overall flow of HRM.
Figure 3: HRM data flow
7
The basic messaging workflow starts from number 1 on Figure 4:
1. PatientMessageManager (Figure 4.1) sets the type, frequency, and
interval to send content to the user.
2. The PatientScheduleService (Figure 4.2) service polls the database for
messages waiting and ready for delivery.
3. PatientScheduleService (Figure 4.3) sends outgoing messages to
Exchange for delivery to users’ SmartPhones.
4. The user receives and replies to the messages (Figure 4.4).
5. Exchange calls MessageAgent (Figure 4.5) which parses the user’s
response and updates the HRM database. If required, a follow-up
message is sent immediately to the user.
The process is repeated until the branching question/response chain is complete.
For glucose uploads, the GlucoseUploadService service saves the glucometer
readings to the HRM database and sends a copy of the readings to CliniPro for
patient or care provider review. Patients also receive a “thank you for uploading”
email, which lists the readings uploaded.
Summary of HRM applications:
Application server
 PatientMessageManager
o This application is used by the case manager to provision patients,
messages schedules, and contact patients.
 PatientScheduleService
o A Windows service which polls message schedules from HRM DB
and sends out messages to Exchange for delivery to patient’s
smartphone.
 MessageAgent
o A custom Exchange transport agent which processes incoming
emails from patients.
o It parses message content and embedded codes from the email
and updates the database.
 GlucoseUploadService
o A socket application which listens for glucose uploads connections
from client device.
o The readings are saved to HRM internal DB and CliniPro DB.
8
Client device applications
 Bluetouch
o This application from CyberFab communicates with glucometers
attached to the CyberFab Bluetooth dongle and sends the result to
the GlucoseUploadService.
 Mobile Outlook
o Microsoft email application for Windows Mobile devices.
o Use for communication with HRM via automated messages
System Description
Database design
HRM db is a relational database designed to run on SQL Server. The database
has a data manipulation language layer (DML) which provides access to the
underlying data structures. The DML scripts were written in T-SQL language and
are located in:
\DataServices\PatientMessaging\DatabaseInstaller\dml
Data definition language (DDL) for generating the database and indexes are in:
\DataServices\PatientMessaging\DatabaseInstaller\ddl
Core HRM library and applications
\DataServices\PatientMessaging\PatientMessageSharedLib classes:
 Config – SQL connection configuration class
 DataManager – Manages data objects, business logic, statistical
processing. Entry point to access the HRM DB and system from derived
applications.
 DaySchedule – Class mapping of the DaySchedule db object
 DBObject – Base class for database objects
 Followup – Class mapping of the Followup db object
 GlucoseReading – Class mapping of GlucoseReading db object
 Greeting – Class mapping of Greeting db object
 Message – Class mapping of Message db object
 Messages – Class to manage array of Message objects
 MessageTemplate – Class mapping of MessageTemplate db object
 MessageType – Class mapping of MessageType db object
9







Patient – Class mapping of Patient db object
Response – Class mapping of Patient db object
Responses – Class for managing arrays of Response objects
Schedule – Class mapping of Patient db object
SmartDevice – Class mapping of Patient db object
Time – Class to handle time storage
Util – Utility class containing statistics, math, and date functions
\DataServices\PatientMessaging\PatientScheduleService
 ScheduleServiceHandler – Polls HRM DB for messages to send out to
patients
 ScheduleServiceInstaller – Installs PatientSchedule Windows service
 ScheduleServiceMain
\DataServices\PatientMessaging\PatientMessageManager classes:
 Manager – Main class handing the display of the management and data
screens
 MediaEditForm - Dialog for editing media data
 MessageTypeForm – Dialog for editing message types
 ResponseEditForm – Dialog for editing response data
\DataServices\PatientMessaging\GlucoseUploadService classes:
 GlucoseUploadServiceHandler – Contains processing thread handling
meter uploads
 GlucoseUploadServiceInstaller – Handles installation of the Windows
service
 GlucoseUploadServiceMain – Main program entry
\DataService\PatientMessaging\Interfaces\CyberFabLib classes:
 MeterReadings – Handles the processing of the bytes array obtained from
socket data transfer via BlueTouch application on the smartphone.
Contains CyberFab (proprietary?) data structure.
Optional applications and services
CliniPro application
\DataService\PatientMessaging\Interfaces\CliniProLib classes:
 CliniProReadings – Formats HRM stored glucose readings into CliniPro
specific XML document for delivery to the CliniPro application
 SynClient – Handles asynchronous connection to the CliniPro server and
data transfers
10
CommonPlatform
\DataService\PatientMessaging\Interfaces\CommonPlatformLib classes:
 AccessUtil
 CommonPlatform – Main to access CommonPlatform interface and data
exchange
 HDAuthenticationService
 HDObservationService
 HDRegistryService
 HDUtil
 LogUtil
11
12
Core Component Implementation and Testing
The following section reports our experiences with implementing and testing the
Project HealthDesign technical specifications for the core components. Our
responses the required questions are in Arial, non-italics 10 point font and follow
each question.
1. What web services did you use, and which API calls (from the WSDL)
did you implement?
a. describe which data/functions you used the platform for, and which data you
stored or functions you implemented yourself
i. We used the common platform to store capillary blood glucose
levels from two different mobile PHAs designed for patients with
diabetes--the University of Washington’s HRM and
NST/Norway’s Few Touch system.
ii. We used the platform to exchange blood glucose values
between these two personal health applications for a single
user.
b. list the specific platform API calls that you used
i. Authentication
ii. Log in
iii. Observation—retrieving and inserting blood glucose levels
c. provide examples of data that you stored in the Medication and Observation
services
i. Capillary blood glucose measurements
1. Did not test annotation of these records.
2. Did not test multi-media attachments to these records.
d. provide examples of access control rules specified (e.g. provided access to
family members to view any data, add annotations, but not update or delete
anything, etc.)
i. Did not test access control rules beyond administrator and
individual user.
2. What problems did you encounter?
Also address the core components:
a. Functional deficiencies (e.g. it didn’t do what my PHA needed it to do in
these areas)
ii.
Authentication
1. None
iii.
access control features
1. None
iv.
medication lists
1. Did not use
v.
Observations
13
1. Could not distinguish between new blood glucose levels
and old blood glucose levels that had already been
sent—ie double enters observations.. Common platform
relies on the applications to do this filtering first before
sending to platform.
vi.
Suggest specific enhancements such as ‘add a new function that does
this’
1. Consider the ability to resolve double entry. This is really
a scope issue for the common platform and may better
address in future uses or adaptations of the platform.
b. Performance (it did what it needed, but too slowly, especially the following
operations)
i. Met our limited feasibility needs.
c. Robustness (it had bugs or was frequently unavailable)
Available whenever we needed it.
c. interoperability technology (I couldn’t get SOAP messaging working
the automatically generated code stubs had bugs, I had problems
with the SSL encryption
i. No problems.
3. Did you try to share data with other PHAs using the platform
components?
a. what specific data did you try to share (medications, specific types of
observations, access-control rules, user registry, etc.)?
i. We are in the process of sharing glucose data across two
personal health applications.
b. were you successful? if not, what problems did you encounter?
i. We are very close to successful. The two applications store
blood glucose values in different units. Conversion needs to
be set up on the application side, but common platform could
consider supporting a unit transformation, especially in
cases where an international standard is different than U.S
for units measures (eg capillary blood glucose levels).
4. Was the process of interfacing to the platform components
straightforward?
a. what was the programmatic mechanism you used to interface to the
platform (i.e. automatic code generation based on WSDL, direct SOAP
calls, etc.)?
i. Automatic cod generation and custom code
b. was the documentation adequate?
i. Yes
c. was the technical support provided by Project HealthDesign adequate?
i. Yes
d. do you have any suggestions for improving this process?
i. Ok for testing purposes.
14
ii. If goal is to scale to serve multiple users and applications
may need to consider different data transfer methods.
5. What would you change about the Project HealthDesign common
platform components to better meet the needs of your PHA and your
programming team?
The Common Platform components met our feasibility goals well. We have
particularly enjoyed the good service and communications we have had with
Walter Sujansky and his colleague Sam Faus.
15
16