HealthVault Mirror Application
Environment Locations
Development environment for technical staff:
https://webapp3-dev.asu.edu/healthvault/
QA Testing Environment:
https://webapp3-qa.asu.edu/healthvault/
Live Production Server:
https://webapp3.asu.edu/healthvault/
The Development and QA environments integrate with Microsoft’s “PPE” HealthVault instance (“PPE” is
an abbreviation for “Pre-Production Environment”). This is separate from the production HealthVault
instance, so please note that health record data will not be the same as in production.
Document Conventions
All setup screens are password-protected (by ASURITE login) and require special access to the system.
These screens will be referred to as “admin”, “administrative”, or “staff”.
Screens that are available to anyone with an ASURITE login will be referred to as “public”.
Mouse click steps or actual text that should be typed will be denoted as follows. For example, if the
instructions call for clicking on the “Stations” link of the Configuration menu, it will read as:
Configuration | Stations
Application Overview
The HealthVault Mirror Application acts as a bridge between Microsoft’s HealthVault service and the
systems at ASU (notably, My ASU and a separate research database) that use health data provided by
HealthVault. The mirror application periodically retrieves health data from a HealthVault web service,
stores that information in its local database, and then makes that data available for use elsewhere,
primarily the activity indicators shown on My ASU (part of the Campus Services tab). This data transfer
includes some simple calculations, such as BMI (Body Mass Index). The mirror application only has
access to health data for persons that have authorized access to ASU via My ASU (that access can be
revoked via the HealthVault website). The overall process of retrieving this information is referred to as
synchronization, the result of which a local copy of data that “mirrors” what is available in HealthVault.
A second major function of the mirror application is to monitor weight kiosks or other “stations” that
provide data to HealthVault. Those stations do not provide health data (e.g., weight readings) directly
1
HealthVault Mirror App; version 1.0
April 2014
to the mirror application, but do communicate directly with the mirror application to provide their
status. This communication includes “pings” that are sent to the mirror application on a periodic basis so
that the online/offline status of the stations can be monitored. Some stations may also provide log files
to the mirror application for the purpose of troubleshooting problems.
For other information about HealthVault or ASU’s integration with HealthVault, please see the following:



https://www.healthvault.com/
The “Campus Services” tab on My ASU
(https://webapp4.asu.edu/myasu/student/campusservices)
https://active.asu.edu/
Application Permissions
An ASURITE login is required to access any of the screens in the mirror application. As of January 2014
there are no public screens, other than the application’s home page, so an additional role is required to
access any significant functionality.
There are two main roles in the mirror application: “Admin” and “Monitor”. These roles grant access to
the various screens described below. Admin users have access to all of the screens; users with the
“Monitor” role only have access to screens related to stations (including alert recipients).
Search
The search screens can be found from the left-side navigation menu. You must be signed-in to view the
search screens (see the section above about application permissions).
Associations
Search | Associations
An “association” identifies a HealthVault health record, and is used to track the synchronization status
on a per-record basis. The association contains a unique HealthVault record identifier in GUID format
(GUID’s appear as a long string of hexadecimal characters separated by hyphens). There is also a unique
person identifier; the person id identifies the person that authorized ASU to access the record. Both of
these ID’s are determined by HealthVault, not the mirror application. (Note that HealthVault allows a
person to potentially access multiple health records – their own health record plus records for others,
such as a spouse or child. However, only one of these health records will be available to ASU, based on
what the person chose while linking My ASU to HealthVault.)
Associations are not created or edited by the mirror application user interface (UI); this information is
created automatically in the mirror application as part of the synchronization process. The locally-stored
information includes timestamps that show when the health record was last updated in HealthVault (as
determined during the last synchronization) and the last time that data was synchronized into the mirror
app for that record. These two timestamps will generally be the same unless there has been no data
2
HealthVault Mirror App; version 1.0
April 2014
added to the health record (in that case you will possibly see timestamps where the time component is
5pm; this is an artifact of the synchronization process since the timestamps are stored relative to UTC,
initially at midnight of a prior date, but converted to Arizona time for display on the screen).
Record ID
A GUID to filter the associations by the HealthVault record id.
Person ID
A GUID to filter the associations by the HealthVault person id.
HV Date Modified
A date range for filtering associations by the date/time that the health record was last updated in
HealthVault. Either leave both textboxes blank or specify both a begin date and end date (the begin
date and end date can be the same to search for a single date).
HealthVault User Lookup
Search | HV Lookup
This search screen directly queries HealthVault for information about the health records that have been
authorized for access by ASU. It may show information that is not part of the associations.
Important: this screen provides access to sensitive information; it allows a particular health record to be
tracked to a particular person, which is generally not possible with the “association” data. Please treat
the results as confidential.
The search criteria are as follows:
Record ID
A GUID to filter the results by the HealthVault record id.
Person ID
A GUID to filter the results by the HealthVault person id.
Name
The name of the person to find records for; this can be a complete name or a partial name (the name is
matched by substring, not specifically the first name or last name).
The search results include the following information:
Name
The person’s name as it appears in HealtVault.
Person ID
The unique person identifier for the HealthVault user.
3
HealthVault Mirror App; version 1.0
April 2014
Primary Record
This field is a record identifier. The use of the term “primary” here is arbitrary; the value identifies a
health record that has been “selected” as the default record for the application, but the mirror
application doesn’t specifically use that selection. However, the id will likely match the record id in an
“association” entry, so in that sense it identifies the person’s HealthVault record for ASU.
Authorized Records
This is a subset of several related fields, as described below. There may be multiple authorized records,
displayed on separated rows, for a particular primary record. As mentioned above, a person may have
access to multiple health records, such as for a spouse and/or children; however, typically only one
record per person is authorized for ASU.
Name
A person’s name as it appears in HealthVault.
Record ID
A HealthVault record identifier.
Type
This shows the relationship between the person that authorized access to the health record and the
person that the record is for. In almost all cases this will be “Self”, since students will authorize access
only for their own health record; however, examples of other relationship types are “Spouse”, “Son” and
“Daughter” (this is not a complete list).
Auth Status
The authorization status is an indication of whether the application is allowed to access the health
record. (The significance of this status has not been fully evaluated, but “NoActionRequired” is the
typical value; other statuses might indicate that health data won’t be retrieved in synchronizations. For
the specific case where the person has removed ASU’s access to the record, the observed behavior is
that the record will no longer appear at all in the results of this lookup. Note, though, that the
association entry will still be available.)
State
This is a general state of the health record, not specific to the authorization for ASU. This value will
typically be “Active”, though other statuses may appear if the health record has recently been deleted in
HealthVault.
Job History
Search | Job History
The job history shows a log of system processes, especially those processes that interface with
HealthVault. This includes the “pull” process, which synchronizes data from HealthVault, and “push”,
which sends data to HealthVault. (As of January 2014 the app does not have any data to actually send
*to* HealthVault, other than certain data that can only be added by developers via separate testing
4
HealthVault Mirror App; version 1.0
April 2014
functionality. The production mirror app will not push any data to HealthVault.) Other jobs, such as
those used for system monitoring, do not currently log entries in this history.
Job Action
A drop-down selection for common job types. The default blank selection includes all jobs.
Status
Show all history entries, only those that indicate that a job failed, or only those for successful job runs.
Note that the filtering for failed jobs (indicated as “Not Successful”) is not an inclusive filter for specific
error statuses; it is simply the opposite of the “Successful” filter, excluding job runs that were successful
(I.e., the results might include multiple distinct status codes).
Message
This text value filters the job history using a substring match on the message associated with the job
entry, if any. Non-empty messages in the job history typically indicate an error.
Date
An optional date range to filter the job history according to the job start time. Either leave both
textboxes blank or specify both a begin date and end date (which can be the same value).
The search results include a unique identifier for the history entry, the timestamps for when the job
started and ended, the action (i.e., job type), a result status, an active indicator (whether the job is
currently running, or may still be running), and message. A message is typically only available for job
runs that failed. The “IP Address” and “Agent” fields provide information about what triggered the job.
The IP address will typically be in IPv4 format, but could be an IPv6 address. For job runs that are
triggered by users in the mirror application the Agent field will be a short code that identifies the
browser; where as an Agent value containing the string “Wget” usually indicates that the job was started
from a process that runs periodically.
Mirror
Search | Mirror
ASU’s copy of participating HealthVault data is referred to as “the mirror”. The data is local; stored at
ASU. This screen searches this mirror data. The results include information retrieved directly from
columns in the “hv_mirror” database table, as well as selected information extracted from an XML
payload received from HealthVault (specifically, an item name and item value, the contents of which will
vary depending on the type of item). Each of these mirror records is a particular data item from the
health record, such as a weight measurement or a summary of exercise activity for a particular day
(HealthVault refers to these items as “things”, so that term may appear in some places as well). Please
note that in the database table some datetime columns may have values represented in UTC while
others are in local Arizona time; however, the timestamps in the displayed results are converted to
Arizona time as necessary.
5
HealthVault Mirror App; version 1.0
April 2014
Record ID
A GUID to filter the results by the HealthVault record id.
Person ID
A GUID to filter the results by the HealthVault person id.
App ID
A GUID to filter the results by which application sent the item to HealthVault. Common values that may
be useful are listed below:



42dbc881-6833-439a-b91b-52307a68f230
This is an application identifier for ASU. For example, weight readings sent from the weight kiosk
will be associated with this identifier.
9ca84d74-1473-471d-940f-2699cb7198df
This application identifier, shown as “Microsoft Health Explorer”, is for data entered directly in
the HealthVault website.
f30edae4-0cd3-4585-b27a-2f0dcdd17ba1
This application identifier can be used to find Kersh KAM exercise items.
Text Search
An optional list of keywords, separated by spaces, to search for in the text of the XML payload. This does
not do any special processing on the xml; the xml payload is simply converted to a text string prior to
doing the search.
Date Modified
A date range for filtering items by the timestamp of when the item was created/updated in HealthVault.
To search for a single date specify the same value for both the begin date and end date.
The results can be ordered by the person identifier, record identifier, synch timestamp (i.e., when the
item was pulled into the mirror application), or the HealthVault timestamp for the item.
Note that the results provide a hyperlink to a separate screen that shows the details of a single mirror
record. The detail information includes the same information shown in the search results, as well as the
xml payload. Within the xml, the “data-xml” node shows the detailed item information, which will vary
based on the type of the item (e.g., weight reading, height measurement, exercise data, etc.).
Push Queue
Search | Push Queue
The push queue is a temporary holding location for data values that are to be sent to HealthVault. The
push queue is usually (or always) empty. The push queue can hold items for health records that have not
6
HealthVault Mirror App; version 1.0
April 2014
yet been linked to My ASU, so the record id and person id may not be available; such entries will remain
in the queue until the record is linked or until the queue entry is deleted by a user of the mirror app.
You can see the xml content of a queue entry in the search results by placing the mouse cursor over the
item name.
Record ID
A GUID to filter the results by the HealthVault record id. There may be entries in the queue that don’t
have an available record id.
Person ID
A GUID to filter the results by the HealthVault person id. There may be entries in the queue that don’t
have an available person id.
Stations
Search | Stations
This screen shows a list of stations that have been configured in the mirror application. Stations include
devices such as weight kiosks. There are hyperlinks to add a new station (on the right side of the page)
or edit existing ones.
The search criteria are as follows:
Name
The name filter matches either the configured station name or the actual machine name (these two
names are usually the same; see the configuration section for additional information).
Station Type
This is a multi-select drop-down list for the type of station; e.g., Weight Kiosk. Note that the list of
available station types is configurable; see the configuration section for additional information.
Active Status
This filters on the Show/Hide setting of each station.
The search results include the following information:
ID
This is a unique numeric identifier that is assigned by the system when a new station is configured.
Name
The name of the station, typically the same as the name of the machine (see the configuration section
for information on these names).
Type
The type of station; e.g. Weight Kiosk.
7
HealthVault Mirror App; version 1.0
April 2014
Status
The status displayed here is one of the following:





Online. This status means that a “ping” request has been received within the last 30 minutes.
Pings are short status messages that the stations send on a periodic basis to the mirror
application to indicate that the station is operational.
Degraded. The last ping received was at least 30 minutes ago but less than 45 minutes. This
status is an indication that the station’s operational state may have recently changed.
Offline. The last ping received was at least 45 minutes ago.
Inactive. There has been no recent ping request and the station’s Show/Hide setting is set to
“Hide”.
(blank). The displayed status is blank if there has been no ping request (recent or otherwise)
and the station’s Show/Hide setting is set to “Show". This condition likely indicates that the
station is new, and is either not running yet or hasn’t been configured correctly to send a
successful “ping”.
Note that the minute boundaries listed above for evaluating the age of the last ping are subject to
change. These cutoffs were chosen based on the default interval that stations such as weight kiosks use
to send the periodic ping requests (every 15 minutes, though that is also subject to change), and, to a
lesser degree, because of the fact that a station monitoring process to send email alerts likely runs once
an hour. The cutoff for stations to be considered online has to be higher than this default interval.
Last Ping
The date and time that the last ping request was received.
Elapsed
The difference, in minutes, between the date/time of the last ping and the current time.
Last Reading
For weight kiosks, this is the date and time that the kiosk last sent a weight reading successful y to
HealthVault. This timestamp is sent as part of the ping requests. Note, however, that this value is not
saved by the station when the machine is rebooted, so no value will be available if there has not been a
weight reading since the last time the machine was rebooted (which might happen on a daily basis).
Machine Name
This value is updated when a ping is received to indicate which machine was the source, but this value
may also get updated by the station edit page; see the configuration section for additional details.
IP Address
The IPv4 or IPv6 network address of the machine that sent the last ping for this station.
There is also a “Delete” link on each row to delete a station record, available to admin users only (i.e.,
not to users that only have the “Monitor” role). Clicking a delete link will show a confirmation prompt
before actually deleting the station record.
8
HealthVault Mirror App; version 1.0
April 2014
Station Logs
Search | Station Logs
The station logs shown here are log files that were uploaded from stations. These log files can be used
to troubleshoot problems with a particular station. Note that the some stations may not be able to keep
log files for a significant amount of time, so the log files can be uploaded to the mirror app for storage.
The search criteria are as follows:
Name
The name filter matches either the configured station name or the actual machine name (these two
names are usually the same; see the configuration section for additional information).
Station Type
This is a multi-select drop-down list for the type of station; e.g., Weight Kiosk. Note that the list of
available station types is configurable; see the configuration section for additional information.
Date
Date range filter for the timestamp that the log files were uploaded. This can be different than the date
that the log file was actually written by the station, which will be indicated in the name of the file. To
search for a single date specify the same value for both the begin date and end date.
The search results include the following information:
ID
This is a unique numeric identifier that is assigned by the system when the file is received.
File Name
The name of the log file as provided by the station. Note that this value is also a hyperlink to show the
details of the upload, including the content of the file.
File Size
The number of bytes that were uploaded for this file.
Station
The name of the station that uploaded the file.
Upload Timestamp
The date and time of when the mirror app received the file.
Users
Search | Users
This shows a list of accounts for people that have access to this application. Most of this is similar to the
“Persons” or “Users” screens available in other applications. Note that the link to add a new user is on
the right side of the page.
9
HealthVault Mirror App; version 1.0
April 2014
Configuration
The configuration screens can be found from the left-side navigation menu. You must be signed-in to
view the configuration screens (see the section above about application permissions).
Alert Recipients
Configuration | Alert Recipients
This screen shows a list of recipients for system status alerts. Alerts are sent when the status of one or
more stations changes, such as from “Online” to “Offline”. The process that sends the alerts runs on a
periodic basis, such as once an hour. Note that alert recipients are configured for a group of stations
according to their station type, not individual stations.
Configuration | Alert Recipients | Add new recipient
This link to add a new recipient entry appears on the right side of the Alert Recipients screen. Several of
the settings for recipient entries control how the email messages are constructed.
To Name
The recipient’s name or a name associated with the recipient’s email address.
Email
The email address of the recipient. Note that this value has no direct relationship with the email address
for user accounts; recipients don’t even need to be configured as users in the mirror application.
From Name
The name of the sender as it will appear to the recipient. This doesn’t need to be the name of a person;
this can be any suitable name, such as “ASU HV Mirror App”.
Station Type
The type of station for which this recipient will receive alerts. Only one type can be selected, but you can
create other recipient entries with the same email information to configure alerts for multiple types.
Show/Hide
This setting is an active flag that determines whether the recipient will receive alerts. It does not affect
visibility on the admin screens.
Mirror Settings
Configuration | Mirror Settings
This setting shows a grid of name/value pairs for settings that affect the mirror synchronization process.
Click the “Edit” button in the row of a particular setting to change its value; this will place the row in edit
mode, after which you can click “Update” to save a change to the value or “Cancel” to undo it (the name
of the setting is read-only). There’s a row at the bottom of the grid for adding new settings.
10
HealthVault Mirror App; version 1.0
April 2014
CAUTION: changing these settings can have significant impacts on the synchronization process. DO NOT
change the value of a setting unless you understand the impact.
The following is a list of the available settings. Disclaimer: this may not be a complete list and is not
intended as a complete explanation of their usage.
Name
appid
Description
The application identifier that the mirror application uses when
communicating with HealthVault.
DO NOT change this value.
audits_purge_cutoff
The number of days to keep entries in the job history. Entries older than the
date derived from this cutoff will be deleted when the synchronization runs.
A zero or negative value will disable this cleanup.
audits_update_orphans
Boolean value entered as an integer (1 means true, 0 means false). If a job,
such as the “pull” synchronization job, does not complete normally there’s a
possibility that the history entry will be stuck, showing that the job is active
when it actually isn’t currently running. This setting controls whether those
orphaned entries are automatically updated to an inactive status after an
implementation-defined timeout elapses (the timeout in this case is a
certain number of minutes). The job history will show a special status and
message for those entries that are updated as a result of this cleanup.
autocreate_associations
Boolean value (1 or 0). Determines whether the pull synchronization will
create “association” entries for health records that it has not previously
encountered. This value should be left as 1 (true); otherwise, health records
that are newly-linked from My ASU will not have data available.
calc_biometrics
This is an integer value that represents a calculation mode; it determines
whether biometrics data is updated at the end of the synchronization from
HealthVault. A value of 0 indicates that the calculation is disabled; a value
of 1 or 2 enables the calculation. For mode 1 the calculation will only be
performed if new health data is available; in mode 2 the calculation will be
performed for every synchronization even if no new data is available.
last_marked
The synchronization process uses this date/time value to determine what
new data to retrieve. This timestamp is not directly tied to the current time,
however; the value is the latest update timestamp of whatever data has
already been synchronized.
last_validated
This date/time value is similar to “last_marked”; however, it applies to a
different synchronization process that ASU is not using.
lookback_days
The number of days back to query data from Healthvault. This does not
affect the retrieval of new data; it is used to re-query older data to
determine what items have been removed from a health record (items
removed in HealthVault are removed from the mirror database as part of
the synchronization). The value determines a cutoff date for the query; the
date is relative to the most-recent update timestamp for a particular health
record.
lookback_days_bootstrap A number of days used to determine a cutoff date for the HealthVault
query. This setting is related to “lookback_days”, but is only used as a
default in case the normal lookback date can’t be determined (this happens
11
HealthVault Mirror App; version 1.0
April 2014
platform_url
shell_url
tracking_data_only
type_list
verbose_output
when no data has been obtained for a particular health record).
This is the HealthVault web service address. Note that there is a similar
setting in the application’s configuration file; the values should be the same
and correct for the particular environment.
This is another HealthVault address; however, it is not relevant for the
mirror app.
This is a Boolean value (1 or 0) that determines whether the mirror records
have detailed item information. Setting it to 1 (true) will disable storage of
the xml payload and other information. However, this may cause the
synchronization to fail or would have other impacts. DO NOT change this
value.
This is a comma-separated list of type identifiers. Each HealthVault item
(e.g., weight reading, exercise information, blood pressure reading, etc.) has
a unique type identifier; this list determines which types are actually
queried during the synchronization. For information on the available types
go to the HealthVault Development Center:
http://developer.healthvault.com/pages/types/types.aspx
This is a Boolean value (1 or 0) that determines how much information is
generated in the web page output when the synchronization process runs;
setting it to 1 will add more detailed information. This has no impact on the
level of information stored in the database.
Stations
Configuration | Stations
This shows a non-filtered list of stations. See the search section above for more information about the
displayed results.
Configuration | Stations | Add Station
This link to add a new station appears on the right side of the Stations screen.
Station Name
Enter the name of the station.
Important: you must enter the machine name. The original design of this field was for it to be the
machine name or some other user-determined name; however, in the current implementation this
value MUST be the machine name. Internally there is both the station name and a machine name;
however, the edit page updates both internal fields from this one field on the form when the station is
saved. Using a value other than the machine name will prevent the station from communicating
successfully with the mirror app (e.g., for ping requests or log file uploads).
Station Type
Select a station type (e.g., Weight Kiosk) from the drop-down list.
12
HealthVault Mirror App; version 1.0
April 2014
Access Code
This is a required password used to verify that messages from stations (e.g., ping requests) are coming
from an authorized source. The same value must be provided in the station’s configuration file. It is
recommended that the value be at least 20 characters long (maximum length is 50 characters).
Additional information about the access codes may be available in separate setup documentation for
the station software; e.g., for the weight kiosks.
Send Monitor Alerts
This checkbox determines whether this station is included in station monitoring. When this box is
checked, email alerts will be generated for configured recipients when the status of the station changes
(e.g., when it goes offline).
Show/Hide
This active flag determines the visibility of the station on certain screens (such as the Station Monitor)
and whether the station is included when generating email alerts for status changes.
Station Types
Configuration | Station Types
Each station has an associated type; for example, there is a type entry for weight kiosks. The list shown
on this screen shows a unique numeric identifier assigned when a type entry is created, along with other
properties of the type.
Configuration | Station Types | Add new station type
This link to add a new station type appears on the right side of the Station Types screen.
Type Name
This is the admin name for the type. It may be used on administrative screens or have other internal
uses.
Display Name
The name of the type as it will typically appear on other screens.
Show/Hide
This setting is an active flag that determines whether the type is included in type lists on other screens,
such as the type filters on the search screens. It does not affect visibility on the admin screens.
Users
Configuration | Users
This shows a list of accounts for people that have access to this application. Most of this is similar to the
“Persons” or “Users” screens available in other applications. Note that the link to add a new user is on
the right side of the page.
13
HealthVault Mirror App; version 1.0
April 2014
Control Panel
The control panel can be found from the left-side navigation menu. It is only available to admin users.
The control panel provides a way to run certain system processes that normally run behind-the-scenes,
such as hourly jobs; the control panel allows those processes to be run at any time. Click the link
corresponding to which process you would like to run; it will be started immediately and you will be able
to see the output.
These manual job runs are not processed any differently than normal (aside from a security check, which
in this case is based on the ASURITE login), so the job run will still be recorded in the job history (for
processes that normally record a history entry) and email notifications for job failures will be sent as
needed. Also, the control panel does not prevent the process from running a second time if it happened
to already be running through other means, so there is a possibility of concurrent job executions. This
may cause problems that would not normally occur, so try to avoid running processes around their
scheduled time (such as in the first few minutes of the hour).
Control Panel | Send system status alerts
This runs the station monitor that sends email alerts when a station’s status changes.
Control Panel | Pull items from HealthVault
This runs the mirror synchronization process to retrieve data from HealthVault.
Control Panel | Push items to HealthVault
This sends items in the push queue to HealthVault.
Job History
Job History
This link in the navigation menu shows a list of the most-recent entries in the job history (up to a certain
number of entries to limit the results to a single page, but otherwise not filtered).
Station Monitor
Station Monitor
This link shows a screen that is similar to the station search results; see the search section above for
additional details. There a few differences from the search screen, however, because this screen is
primarily intended for viewing only instead of accessing configuration (though it isn’t limited to that).
This screen automatically refreshes periodically (e.g., every 30 seconds). Inactive stations (“Show/Hide”
set to “Hide”) are excluded, and the “Delete” links are not provided on this page.
14
HealthVault Mirror App; version 1.0
April 2014
Error Logs
“Exception” errors encountered by the application are usually recorded in the database (unless, of
course, there is a problem connecting to the database). The screens here allow viewing and deleting of
error log entries.
Error Logs | Search Logs
There are various search criteria on this screen (not described in detail here); click the Search button to
see the results. Tip: the date range filter is optional, but if you specify a range, make sure that you
specify both a begin date and end date; and the end date may need to be one day later than the last day
that you wish to include in the range (this is a side-effect of how the query is written, and is different
than the other search screens).
Error Logs | View All
This link bypasses the criteria page and shows all active log entries (i.e., those that haven’t been updated
to be hidden).
15
HealthVault Mirror App; version 1.0
April 2014