Connecting a Back-End Clinical System to HealthVault

Introduction

This document provides HealthVault solution providers with information about how to connect back-end clinical systems to HealthVault. For the purposes of this document, a back-end clinical system is defined as a system used in a clinical setting where there is no online front-end for the patient. When this type of system is involved in sending or receiving information to/from patient HealthVault records, the basic problem that needs to be solved is how patients authenticate themselves online. In other words, how do you make sure that patient data is sent to the right person’s HealthVault record?

Basic Tenets

1. The patient’s HealthVault record is controlled by the patient (and/or a person they’ve chosen to help manage their health information).
   
   • The patient has the right to create, read, update, and delete any data.
   • Access to the HealthVault data must be authorized by the patient, and the patient can revoke someone’s access at any time.
2. The patient’s clinical record is controlled by the provider.
• The provider is responsible for the data that gets saved into the patient’s clinical record.
• The provider is responsible for determining what information is appropriate as the basis for medical decisions.
• The provider must adhere to relevant state and federal regulations with respect to the patient’s clinical information.

Scenarios

Once the connection between the clinical record and patient’s HealthVault record has been made, the patient and provider can exchange data in the two records according to the Basic Tenets above. Some sample scenarios are listed below, and related stories can be found at Patient and Provider Data Exchange Stories.

• John is discharged from the hospital, receives a copy of his discharge summary in his HealthVault record, and provides it to his other doctors.
• Denise stores her baby's health information electronically and uses a PHR to manage her family’s health information.
• Lina, who has diabetes, monitors her blood glucose at home, and sends the data to her doctor electronically.
• Cecilia, an elderly “snowbird” with doctors in different states, keeps track of her medication lists in HealthVault.
• Kai moves to a new city with health information that he received from his prior doctor, and sends it to his new doctor.

High-Level Patient & Provider Workflows

Setup

1. The provider practice and the patient discuss their interest in providing information to each other through HealthVault. The practice follows its own processes if it requires any documentation of the patient request.
2. From their clinical system, the practice creates an identity code for the patient. They also agree on a verification question and answer that the patient is asked online after entering this code. The clinical system calls in to HealthVault to create this code, and in addition to the verification question and answer, it provides to HealthVault a unique ID and a friendly name for the patient. Note that the unique ID does not need to be the clinical patient identifier; it is completely at the discretion of the clinical system.
3. The practice delivers the identity code to the patient, along with instructions about HealthVault. This delivery can be done in different ways, such as by printing the details from the clinical system or by telephoning the patient, and the delivery mechanism is at the discretion of the practice.
4. At home, the patient visits https://account.healthvault.com/PatientWelcome.aspx, signs in to the patient's HealthVault account, and enters the identity code that the patient received from the provider’s practice. Next, the patient answers the verification question as an additional safeguard against unauthorized use of the code.
5. In the patient's account, the patient selects the record to which the patient wants to give the provider access, and approves the specific access that the provider is requesting—for example, viewing medications and allergies in the patient's HealthVault record.
6. Every night, or on some other schedule, the practice’s clinical system calls in to HealthVault to check whether any new patients have given it access to their HealthVault records. For each new patient, HealthVault provides to the clinical system the unique ID that it originally passed in, as well as the HealthVault account ID and HealthVault record ID for that patient.
7. The practice’s clinical system stores the returned HealthVault account ID and record ID along with the patient’s health information for future use.

You can view a brief demo of this workflow.

Note: Both the patient and the practice have the ability to discontinue the connection, at any time, for any reason.

Data Sharing

As explained in the Scenarios section above, many data exchange scenarios can be enabled once the connection between the clinical record and the patient’s HealthVault record has been set up. Two example data transfer workflows are described below, but the clinical system has the flexibility to facilitate specific workflows for their provider customers.

Provider sending information to the patient

1. After a visit with the patient, the provider practice can initiate the sending of information in the patient’s clinical record to the patient’s HealthVault record, through an interaction within the clinical system. The clinical system may also have functionality to send the information automatically after the patient’s clinical record has been updated.
2. The clinical system uses the HealthVault API to update the patient’s HealthVault record appropriately.
3. The patient views and interacts with the information in the patient's HealthVault record through a HealthVault-compatible application or PHR.

Provider receiving information from the patient

1. The patient is a diabetic and monitors his blood glucose at home with a HealthVault-compatible device. Periodically, he uploads his blood glucose measurements to his HealthVault record.
2. Before the patient’s quarterly visit, the provider practice pulls the last few months of blood glucose data from the patient’s HealthVault record into his clinical record, through an interaction within the clinical system. The clinical system may also have functionality to transform the data into a format that is more meaningful for the doctor—for example, a chart that highlights out-of-range values.
3. The provider views the copy of the received patient data through an interaction within the clinical system.

Patient User Experience

Setup

This section shows screenshots of the user experience on HealthVault.com, added to the Setup workflow steps.

1. The provider practice and the patient discuss their interest in exchange information through HealthVault. The practice follows its own processes if it requires any documentation of the patient request.
2. From their clinical system, the practice creates an identity code for the patient. They also agree on a verification question and answer that the patient is asked online after entering this code. The clinical system calls into HealthVault to create this code, and in addition to the verification question and answer, it provides to HealthVault a unique ID and a friendly name for the patient. Note that the unique ID does not need to be the clinical patient identifier; it is completely at the discretion of the clinical system.
3. The practice delivers the identity code to the patient, along with instructions about HealthVault. Delivery can be done in different ways, such as printing the details from the clinical system or telephoning the patient, and the delivery mechanism is at the discretion of the practice.
4. At home, the patient visits www.healthvault.com/patient, signs into the patient's HealthVault account, and enters the identity code received from the provider’s practice. Next, the patient answers the verification question as an additional safeguard against unauthorized use of the code.

Figure 1: Welcome page

Figure 2: Patient signs in to HealthVault

Figure 3: Patient enters the identity code received from the doctor

Figure 4: Patient answers the verification question

5. In the patient's account, the patient selects the record to which the patient wants to give the provider access, and approves the specific access that the provider is requesting—for example, viewing medications and allergies in the patient's HealthVault record.

Figure 5: Patient selects the record in his or her account to which the patient wants to give the provider access

Figure 6: Patient approves the access that the provider's practice is requesting

In the screenshot above, if any of the data types have a “No” in the Required? column, the user sees a check box, and has the option of either authorizing or not authorizing the provider to access data of that type.

Figure 7: Success page

6. Every night, or on some other schedule, the practice’s clinical system calls in to HealthVault to check whether any new patients have given it access to their HealthVault records. For each new patient, HealthVault provides to the clinical system the unique ID that it originally passed in, as well as the HealthVault account ID and HealthVault record ID for that patient.
7. The practice’s clinical system stores the returned HealthVault account ID and record ID along with the patient’s clinical record for future use.

Patient Leaves Practice

If the patient leaves the provider practice or no longer wants the provider to have access to their HealthVault record, the patient can remove access within HealthVault.

Figure 8: Revoking the practice's access

Technical Documentation

Please note that the database tables shown in this section are for illustrative purposes only.

Definitions

The information in this section focuses on the following types of clinical systems:

• A single-practice system
  

  For example, a traditional EMR or lab ordering system

  The system is either installed at a single organization (for example, a provider practice), or hosted on behalf of an organization. The system is configured with a single HealthVault app ID that is tied to the organization.

• A multi-physician or multi-practice online service
  

  For example, an online EMR or e-prescribing service

  The service enables multiple physicians or practices to register and use its services. Each independent physician or practice must be represented by a unique app ID when making calls to HealthVault. Consumers may prefer to grant access to specific physicians or groups. To isolate access to HealthVault account data to specific users, each such user must be assigned a unique HealthVault app ID. Assigning each physician or group its own HealthVault app ID can help limit access appropriately.

Please see Using Master and Child Application IDs for more information on this topic. Some of the details below differ depending on which category the clinical system falls in.

API

The latest .NET API has a new namespace called Microsoft.Health.PatientConnect. This namespace provides the classes needed to implement this workflow. You can view a list of all the method schemas for the corresponding XML API.

These new APIs are referenced in context below.

Tasks

Creating the Identity Code for the Patient

For illustrative purposes, let’s assume that the clinical system has an internal patient table with the following columns and sample data:

In the table, HV_Person_ID and HV_Record_ID are required for the clinical system to make calls in to HealthVault and access the patient’s information. They are Null because the connection has not yet been set up.

After the provider practice and the patient agree to share information through HealthVault, the physician creates the identity code for the patient through an interaction with the physician’s clinical system.

The clinical system calls the following API to create the identity code:

• .NET API – Create() on the PatientConnection class
• XML API – CreateConnectRequest

Parameters include:

• A unique string representing the patient to the clinical system (for example, an encrypted form of “Patient_ID” from the above table)
• The verification question and answer: The clinical system or provider practice can decide what to use. HealthVault doesn’t care what it is; only that it is a question with a case-insensitive answer that is intended to be known only by the patient.
• A friendly name for the patient: This name is needed, for example, in the case in which a parent is trying to set up connections for all their children. The friendly name helps the parent tell the identity codes apart.

HealthVault generates an identity code for the patient and passes it back to the clinical system. The clinical system can help the practice provide this code and instructions to the patient; sample instructions are listed in the Appendix of this document, which can be printed for the patient.

HealthVault also adds the request to its Pending_Requests table, and waits for the patient to visit HealthVault.com:

In the above table, "Number_Of_Tries" limits the number of guesses at the verification question in case the identity code is intercepted or mistyped, and "Expiration" is a HealthVault-configurable value planned initially to be set to 2 weeks. After this time, the patient has to get a new identity code from their physician.

Handling the Case in which the Patient Loses their Identity Code

If the patient loses their identity code and is worried about its misuse, they can tell their provider to delete it.

The clinical system calls the following API to delete the identify code:

• .NET API – DeletePending() on the PatientConnection class
• XML API – DeletePendingConnectRequest

Checking for New Patients and Completing the Connection

Every night, or on some other schedule, the practice’s clinical system can call the following HealthVault API to see if any new patients have given it access to their HealthVault records:

• .NET API – GetValidatedConnections() on the PatientConnection class
• XML API – GetAuthorizedConnectRequests

In the case of a Multi-physician/practice Online Service, connection requests are sent back for all child app IDs, so that the service doesn’t need to make a separate call on behalf of each child app.

HealthVault responds with a collection of newly accepted requests and the following information is included:

• The child app ID of the relevant provider/provider practice
• The unique string representing the patient to the clinical system
• The patient’s HealthVault Person ID (for example, “HV_Person_ID” in the following table)
• The patient’s HealthVault Record ID (for example, “HV_Record_ID” in the following table)

At this point, the internal patient table in the clinical system looks like this table, with sample data:

Reading and Writing Data to the Patient’s Record

Now that the patient’s clinical record is connected to their HealthVault record, the clinical system can access the patient’s HealthVault information using the corresponding HV_Person_ID and HV_Record_ID.

Because the clinical system is authorized to access the patient’s HealthVault record but the user is not actually signed in, the clinical system creates an offline Web connection. This article has information on how to create this connection using the HealthVault SDK.

If the clinical system already outputs an ASTM CCR or an HL7 CCD, providers should seriously consider dating it appropriately and writing it to the patient’s HealthVault account as a snapshot of their health information. This snapshot can be highly valuable to the patient because they can reconcile the data in it, and share it with their other providers/caregivers. Also, if the clinical system has the capability to digitally sign information, it can add a digital signature that can later be used to verify the source of the data. We can provide you with some additional technical information about this feature, if you are interested.

The clinical system can also copy discrete items of information from the patient’s clinical record to HealthVault (into HealthVault data types), but it’s important to do a “smart copy” that doesn’t write duplicates into the patient’s record.

Lastly, the clinical system can choose to read discrete items of information from the patient’s HealthVault record, to keep up to date on the patient’s health—for example, a medication list or blood glucose measurements.

The current HealthVault data model includes the list of data types, the vocabularies, and .NET wrapper classes. If you feel that the existing data types do not meet your needs, please discuss it with us because new data types are added frequently. Also, please point your RSS readers to our data model blog, where we announce the data types that we are currently working on, and gather input from the HealthVault community.

Patient Leaves Practice

If the patient leaves the provider practice, or requests that the practice no longer connect to HealthVault, the clinical system should sever its connection to the patient’s HealthVault record. This API will be available in a future release.

Appendix

Example Instructions for the Provider Practice to Give to the Patient

(Provider letterhead)

Dear Patient:

<Provider Practice Name> is working with Microsoft^® HealthVault^TM to enable you to exchange health information with us using a personal computer. Here’s how you can participate:

1. Connect your personal computer to the Internet.
2. Go to http://www.healthvault.com/patient.
3. Create a new free HealthVault account, or sign in to your existing HealthVault account if you already have one. You need a free Windows Live ID to create a HealthVault account. If you have a Hotmail, MSN, Messenger, or Windows Live account, you can use it as your Live ID. If you don’t have a Live ID, you can create one using any e-mail address.
4. Enter your identity code. This code allows HealthVault to identify which health records to connect with. Your identity code is: Q2W3-E4R6-T6Y7-U9P2-L3K4 (replace this example with the patient's actual identity code).
5. Answer the verification question whose answer you shared with us. This exchange helps prevent unauthorized use of your identity code. You see the question after you enter the identity code.
6. Confirm that you are connected to the right clinic. You should see our name on the screen. Click Yes.
7. Select the HealthVault record that stores the information for: <Patient friendly name>. When you create a HealthVault account, HealthVault creates a health record for you. You can add more health records for other members of your family.
8. HealthVault asks you for permission to give <Provider Practice Name> access to your HealthVault health record, so that <Provider Practice Name> can view and copy information to your account. Please review and approve the access request. If you don’t approve it, <Provider Practice Name> cannot exchange health information with you using HealthVault.

When the steps above are complete, you are ready to exchange information with us in either or both of these ways:

• <Provider Practice Name> adds information to your HealthVault record. To see this information, please sign in at http://www.healthvault.com, click Health Details, and then select the type of information we have added:
  ______________________________[list data types]______________________________________________
• <Provider Practice Name> accesses and can make a copy of information in your record. Your doctor discusses with you the type of information we use and how you can add it to your record.