How to share data with a physician

A common scenario we‘ve seen in hospital-based applications is the persistent need for a patient to share medical information with a doctor or group of doctors. In cases like this, both privacy concerns around medical information and requirements for ease of data use will influence the solution used.

Scenario

Consider a situation where a user has uploaded all their data, either through a device or through another application (including the HealthVault Shell), into his or her HealthVault record. The user now wants to consult a physician based on information that they’ve uploaded, and wants to provide all the necessary and relevant data at their consultation.

How can we achieve this using HealthVault?

1. Accessing data by building a HealthVault application

The last section will show you clearly that the Shell was not designed for sharing a patient’s HealthVault record with doctors. How is an application a better method to exchange information? Let’s consider both the online and offline application architectures. The online applications require the user to be present when the physician’s system accesses their HealthVault record. An online application also requires the user to sign in to HealthVault each time the physician system needs fresh access to the data. These two reasons make the online scenario unacceptable for a patient who wants to give their doctor ongoing access. If we consider the offline architecture, both of these requirements are removed. The user can grant the data permissions to the application just once, and then the application can directly handle the data without any user interaction. This makes it easy for the physician to retrieve the data whenever they want once the access is authorized with the application.  Thus, the offline architecture is the best option for an application to allow the patient to provide their data in this scenario.

A sample workflow for this scenario looks like this: The hospital has a HealthVault-integrated offline application in which registered patients can log in and allow exchange of health information with HealthVault. The application will also have a login window where physicians can log in to access patient data. After registering at the hospital, the patient will go to the application and log in using the credentials they acquired during registration. The patient then links their HealthVault record to the hospital application through an authorization process. When a physician wants to see data for a particular patient, they log into the application and then choose the particular patient using a unique patient ID. The application will pull the data from the corresponding HealthVault record and render it to the physician. The application can manage which data types are shown to the logged-in physician, the level of access, and how to show the data; for example by plotting it as a graph or just showing the raw data.

Advantages and Disadvantages

The physician’s login and access rights can be created when they join the hospital. The application can be designed to present any forms desired for patient notice or consent. And the physician can easily choose whose data to view in the application. As the application renders the data in the expected way, the physician can better focus on data analysis rather than data formatting.

Now, let’s look at this scenario from the patient’s perspective. A user authorizes access by the application broadly. This is acceptable for most scenarios, but what if the user wants more control over their data? What if they want to share this information with only a specific physician, or they want to share only a specific set of relevant data? These scenarios cannot be addressed in this solution.

As the application is using the offline architecture, both the Person ID and Record ID of the user need to be stored in a secured local database. This adds an additional overhead. In addition, the application must implement a method to let the physician log in to the system and link their own login information to the patient’s information.

2. Accessing filtered data through a HealthVault application

This application flow mimics the one above for most of this scenario. The difference arises when the user logs in to the application. The user will be shown a list of physicians from which they can select the names of those they’d like to share their data with. Users will have been given the physician’s name during the registration process itself, or by contacting the hospital prior to their appointment. Similar scenarios occur for the physician login. Instead of being shown all available patients, the physician’s access can be limited to only those patients who have given them permission to see their data. A sophisticated system can let the user choose a date range and a set of data types to be accessed. Please note that this flow is different only in the way an application uses the data and it is not related to the HealthVault platform in any way. The Privacy and Term of Use statements of the application should specify these conditions appropriately.

Advantages and Disadvantages

Allowing users to choose how their data will be exposed by the application may be the best option in many cases. This puts users at ease when working with the application, as they know that the application only provides access to those they have selected.

Like the second scenario, this method requires the storage of the user’s login information in a database and the implementation of a login mechanism for physicians. Additionally, this method adds extra complexity to the application logic by which the physician’s information is linked to the patient’s information. When the user logs in and chooses doctors they want to access their data, a mapping of the user’s data with the physician’s information should be created by the application. One way to do this is to use another column to store the mapping information in the DB table in which the user’s information is stored. When a doctor chooses a user, the application should first validate this request with the already-created user mapping information. If the request is valid, i.e., the user has given the physician permission to view the patient data, then a dynamic linking of the physician’s information with the user’s data will occur. This adds an additional complexity to the application design.

Now let us compare the above two approaches.

Feature \ Method	Through HealthVault App	HealthVault App with filtering
Security and Privacy Concerns	Addressed by the App	Addressed by the App
Physician need a HealthVault account	No	No
Additional record sharing step is needed	No	No
Data sharing level	Decided by the App	Decided by the App
Easy for Physician to choose the patient	Yes	Yes
Patients can choose Physicians	No	Yes
Need for local database	Yes	Yes

Can we use the Shell Sharing feature?

As shown above, the Shell provides a method for a user to share their record with another person. However, HealthVault accounts are not offered for professional or non-personal use. This is a very good way to let relatives or friends help manage health information, for example a family member who needs to control the health information of a child or aging parent. When sharing the data, the user can specify the access level, which includes read access, the ability to view and modify, and full access as a custodian.  Additionally, a user can control which data types will be shared, and whether there is an expiration date on the shared access. The sharing feature does not prevent the user from sending a sharing invitation to anyone they choose, including their doctor. Once the doctor receives the sharing invitation, they would have the ability to accept it, open a personal account, and see the user’s shared data in their own HealthVault account. Though this satisfies the basic data sharing function, it violates HealthVault’s service terms, and this shouldn’t be used as a solution for this scenario. Let us discuss the reasons in the next section.

Problems

Sharing data directly through the HealthVault Shell addresses certain security and privacy concerns for account-holders, as the Shell includes access control features described above.

A deeper look, however, reveals a number of concerns with this method. First, this scenario requires the physician to have a HealthVault account and Live ID of their own and use this account as part of healthcare service. This use case does not fall within HealthVault’s terms of service and is not acceptable for any HealthVault integration. In addition, most healthcare organizations would have other requirements for their information management systems. For example, as a personal service for consumers, Microsoft doesn’t act as a business associate under HIPAA in connection with HealthVault records, and doesn’t include the kind of data management features that a healthcare practice would want to help control its operation.