Getting Started Guide for Potential HealthVault Solution ProvidersUpdated March 11, 2008 This Getting Started Guide is intended for people interested in Microsoft HealthVault who are coming from the business side of the house, rather than the developer side. It includes the non-technical steps required to become a HealthVault solution provider, so that you can decide whether that is something you want to pursue. What It Means to Be a HealthVault Solution ProviderHealthVault does the following: - It provides a repository where people can store and control access to their medical information: everything from lab results and hospitalization records, to blood pressure readings taken at home, to their race times for weekend 5K fun runs, to dietary records.
- It enables people to download information from the applications and devices of HealthVault solution providers to their HealthVault records
- In accordance with permissions granted by the user, HealthVault enables solution provider applications and devices to create, read, update, and delete information in user HealthVault records
- It provides specialized Search capability for health information. Advertising and links for solution provider applications and devices relevant to the subject of the search are displayed with the search results.
Solution Provider BenefitsWhen you create an application that works with HealthVault, you can deliver richer experiences to your users while lowering your costs by leveraging our investments in storage and authentication, and reducing the need for multiple program interfaces. HealthVault enables solution providers to: Leverage the storage platform and connectivity servicesHealthVault provides a set of services that solution providers can use to more rapidly build and scale their applications. By building applications natively on the HealthVault platform, solution providers can use the storage services of Microsoft. Our storage services provide access-controlled, high-availability storage managed under Microsoft security policies, which we scale as needed. For devices, developers can write custom drivers to interact with HealthVault. The device drivers share a common interface through Windows Portable Device. HealthVault Search is a vertical health search tool designed to work with the platform. The search services can be used to provide search functionality within applications, allowing consumers, for example, to do in context definitions of medical terms. Create new business opportunitiesHaving the ability to work with aggregated data allows for a whole new set of consumer applications for health. Never before have developers been able to build applications that, with the user's permission, can bring together lab values, device data, medication information, and more to provide patients and caregivers with the ability to better manage their health conditions. When you create a HealthVault-compatible application, it makes it easy for your users to use health information that they've already stored and recorded. This ease of use can motivate more users to sign up for, and use, your service. Moreover, new business models are emerging—applications offered as subscriptions, or used to support other services tied to customer retention, or as a way to extend the services into the home, where the costs of care may be less. Bring increased traffic and visibilityAll applications created by HealthVault solution providers are listed in the HealthVault Program Directory. They may also be placed in relevant HealthVault Search sponsored results, helping individuals discover your applications when they are searching on relevant topics. Three Phases to Becoming a HealthVault Solution ProviderThere are three phases to becoming a HealthVault solution provider: - Learn about HealthVault:
- Read information
- Watch webcasts
- Examine the applications of other solution providers
- Run the sample applications in the SDK
- Design and Build:
- Create an account in the developer environment and edit the code in the sample applications
- Get an ApplicationID, which enables you to put your own logo, application name, and description on the application authorization page, and enables developers to set up offline data access (allowing your application to access user data when the user is not signed in to HealthVault), to use OpenQuery functionality (to access user information on a linked server), and to use Send Email functionality.
- Verify that your application and operation meet the operating and privacy requirements.
- Implement
- Sign a solution provider agreement.
- Go live: Connect your product so that it can communicate with HealthVault.
Phase 1: Learning about HealthVaultA variety of Web sites offer information about Microsoft HealthVault. Here are some links where you can read about what HealthVault has to offer. At http://www.healthvault.com is the consumer-facing introductory page that summarizes what HealthVault has to offer the consumer. On this page you can see our solution provider health and fitness applications and devices. At http://www.microsoft.com/presspass/events/healthvault/default.mspx is the HealthVault Virtual Pressroom. At http://msdn2.microsoft.com/en-us/healthvault/default.aspx is the home page of the MSDN HealthVault Developer Center, which has mostly technical information, but you may find some of it useful. MSDN HealthVault Developer CenterThis section describes the information available from the MSDN HealthVault Developer Center. Much of this information is for technical personnel, but some pieces are also helpful for business personnel. On the Home tab: - For non-technical people, there isn’t much reason to download the SDK (software development kit). If your developers have installed the SDK, you may want to ask them to show you the sample applications that can serve as a starting place for experimenting and developing a new HealthVault application.
- You may want to skim through Getting Started with the Microsoft HealthVault SDK, which is available for both online viewing and downloading. This document is intended for a technical audience, but you may find some of the information useful.
- View the HealthVault blog written by Microsoft HealthVault developers. Most of this information is highly technical, but if you scroll through the blog, you can also find things like:
- a recorded conversation with Sean Nolan, Microsoft’s Chief Architect for HealthVault, which is non-technical and provides a good overview of HealthVault.
- a recorded interview with Peter Neupert, the Vice President of Microsoft’s Health Solutions Group.
- Connect to the HealthVault consumer Home page, where individuals can:
- connect to the Windows Live ID page to begin the process of creating a personal HealthVault account
- connect to the Windows Live ID page to sign in to an existing HealthVault account
- use HealthVault Search to search for health-related information
- connect to the Microsoft Download Center page where you can download the installer for HealthVault Connection Center
The Go Live guide lists the items you need to provide to get your application live on HealthVault. Going live is covered in detail in the Going Live section of this Getting Started guide. Phase 2: Design and Build a HealthVault-Enabled ApplicationCreate an Account in the Developer EnvironmentAnyone can open a HealthVault account in the consumer environment and/or in the developer environment. You need a Windows Live ID to create an account. The HealthVault developer environment is separate from but functionally equivalent to the HealthVault consumer environment. This separation allows a developer to create an account in the developer environment, set up fictitious HealthVault accounts for fictitious HealthVault users, and experiment by changing the code in the sample applications. No actual personally identifiable information should be stored in the developer environment. Get an ApplicationIDAt some point, your developers will want to do things that cannot be done with the ApplicationIDs of the sample applications. For example: - Adding your logo, descriptive text, and configuration information to be displayed in HealthVault
- Offline access, which means that your application can update a customer’s HealthVault record (in accordance with permissions they have given your application) when the customer is not signed in to HealthVault.
- OpenQuery functionality (used to query data on a linked server)
- Send Email functionality (you provide your domain name when you request this functionality)
At this point, we recommend that you review the operating requirements and security requirements. Meeting these requirements is essential to becoming a HealthVault solution provider. You can generate an ApplicationID, or ask that one be created for you. To get an ApplicationID, you need to provide the following items: Non-Technical Items| Logo | A logo that represents the application; it does not need to be the same as the Company Logo in the Application Directory. Size: 145 px (w) x 145 px (h); 120 KB max. | Application name | Name of the application that will be used to identify it. For example, it will be shown to the user when they are authorizing the application for access to their HealthVault record. | | Short description | Summary of the application that is shown to the user when they authorizing the application. Suggested character limit is 200. |
Technical Items| Data access reason | End-user-facing text that accurately describes the reasons for needing access to the data types that the application is requesting access to. This is shown to the user when they are authorizing the application. | | Data access while the user is logged in | For each data type, specify the type of access that the application requires (read, update, create, delete). You can find a list of types in the Learn section of the HealthVault Dev Center on MSDN. | | Data access while the user is not logged in | For each data type, specify the type of access that the application requires (read, update, create, delete). You can find a list of types in the Learn section of the HealthVault Dev Center on MSDN. | | ApplicationID | The ApplicationID that you are using and expect to go live with. | | Public certificate | A 2048-bit key that corresponds to the private key that the application will be using to identify itself to HealthVault. | | Access to create an OpenQuery | [yes/no] Do you require this? This may require an extra clause in your solution provider agreement. | Access to send e-mail through HealthVault | [yes/no] Do you require this? This may require an extra clause in your solution provider agreement. Provide the domain name from which e-mail will originate. | | Action URL | The HealthServiceActionPage URL that will handle the following target values: Home, ServiceAgreement, Help, AppAuthReject, AppAuthSuccess, SelectedRecordChanged, ShareRecordSuccess, ShareRecordFailed, Privacy, and SignOut. |
Phase 3: ImplementYou need to provide several items before your application or device can go live on HealthVault. The following two tables list the non-technical and technical items. All of these items should be sent to HVAppID@microsoft.com. Non-Technical ItemsThese items are needed if you want your application included in the HealthVault Application Directory. The items in italics are items that you previously provided to obtain an ApplicationID; you need to provide these items again to go live. | Logo | A logo that represents the application; it does not need to be the same as the Company Logo in the Application Directory. Size: 145 pixels (w) x 145 px (h); 120 KB max. | | Company Logo | The solution provider's corporate logo appears on both the Web site listing page and on the Web site profile page. This logo is the official corporate logo only. It should not include any positioning taglines or marketing messages. Logo artwork should be prepared to fit within a space of 100 pixels wide by 40 pixels high. Logos should be sharp, easily readable, and rendered in full color on a white or transparent background in PNG format. | | Company Name | The solution provider's consumer brand name appears on both the Web site listing page and on the Web site profile page. | Corporate Web Site | Links to the solution provider's corporate Web site appear on both the Web site listing page and on the Web site profile page. This URL should link to the home page of the solution provider's corporate Web site. | | Application Name | Name of the application that will be used to identify it. For example, it will be shown to the user when they are authorizing the application for access to their HealthVault record. | | Short Description | Description of the application that is shown to the user when they authorizing the application. Suggested character limit is 200. | | Web Site Name | The name of the Web site appears on both the Web site listing page and on the Web site profile page. | | Web Site Address | A link to the Web site appears on the Web site profile page. This URL should link to your home page. | | Web Site Description | A short summary description of the Web site appears on both the Web site listing page and on the Web site profile page. This description should be no longer than 30 words. | | Web Site Version Number | The version number of the Web site appears on the Web site profile page. If available, a link to the Web site’s version history may be added next to the version number. This URL should link to the version history on the partner’s own corporate Web site. | | Web Site Screen Shots | Screen shots of the Web site appear on the Web site profile page, accompanied by captions. The captions under each screen shot should be short, descriptive, and no longer than 5 words. There is a strict limit of three screen shots per Web site profile page. Screen shots should be in full color and fit within a space of 150 pixels wide by 100 pixels high. For security reasons, the file format must be PNG. | | License Agreement | A link to the legal terms that appear on the Web site profile page. This URL should link to the terms on your site that apply to your application. | | Privacy Statement | A link to the Privacy Statement that appears on the Web site profile page. This URL should link to the privacy statement on your site that applies to your application. | | Detailed Information | More detailed information and links about the application can appear on the Web site profile page. The content of the information appearing on this page must be accurate and relevant to the benefits of how the Web site works with Microsoft HealthVault. The content in this section should be no longer than 300 words. | | Contact Information | Support contact information (phone/email/URL) that Microsoft Customer Support can refer an end-user to, as appropriate. | | Solution Provider Agreement | You work with the HealthVault Business Development team to complete a solution provider agreement. You can kick off this process by e-mailing HVBD@microsoft.com. |
Technical Items| Data access reason | End-user-facing text that accurately describes the reasons for needing access to the data types that the application is requesting access to. This is shown to the user when they are authorizing the application. | | Data access while the user is logged in | For each data type, specify the type of access that the application requires (read, update, create, delete). You can find a list of types in the Learn section of the HealthVault Dev Center on MSDN. | | Data access while the user is not logged in | For each data type, specify the type of access that the application requires (read, update, create, delete). You can find a list of types in the Learn section of the HealthVault Dev Center on MSDN. | ApplicationID | The ApplicationID that you are using and expect to go live with. | | Public certificate | A 2048-bit key that corresponds to the private key that the application will be using to identify itself to HealthVault. | | Access to create an OpenQuery | [yes/no] Do you require this? This may require an extra clause in your solution provider agreement. | | Access to send email via HealthVault | [yes/no] Do you require this? This may require an extra clause in your solution provider agreement. Provide the domain name from which e-mail will originate. | | ActionURL | The HealthServiceActionPage URL that will handle the following target values: Home, ServiceAgreement, Help, AppAuthReject, AppAuthSuccess, SelectedRecordChanged, ShareRecordSuccess, ShareRecordFailed, Privacy, and SignOut. | | Automatic user sign in | Specify whether or not your users should be able to elect to be signed in automatically the next time they return to your application, and if so, specify how many seconds the user should stay signed in for (unless they click 'sign out' or delete their cookies). | | Add Shortcut to Connection Center | A link to a signed MSI that the user can download and run that will install a shortcut for the partner Web site in their HealthVault Connection Center. This URL should link to the MSI hosted on the partner's own Web site. We will be providing you with a sample MSI that you can use as a template. |
Final ValidationVerify that your application and operations meet the HealthVault Operating Requirements and Privacy Requirements. Verify that any use of Microsoft logos or trademarks complies with UI guidelines and with any related trademark guidelines Microsoft provides. Once your agreement is signed and your configuration is correct, Microsoft will allow your servers to interact with the HealthVault consumer environment as permitted by your configuration and agreement. You may then do your own final validation and testing before going live with your site. | |