Well-written software goes through multiple test cycles, including both automated and manual tests. This section outlines some valuable test scenarios around HealthVault account management, API interfaces, and data types, which you should consider in addition to other tests.

HealthVault enables people to share and manage multiple health records. In Chapter 3, we covered account management and ways to configure record switching. You need to ensure your application works with a HealthVault account that has multiple records. The best way to achieve this is to create several test accounts with multiple health records and try your application with them.

Another important aspect of account management is sharing. You can test this by sharing a HealthVault record with another person and then making sure that person can authenticate your application in association with that record. In case of insufficient permissions, your application should show an error message.

HealthVault provides an XML-based Web API. This API is accessible through programming libraries available through various HealthVault libraries and SDKs, as discussed in Chapter 3. While developing an application, you should pay special attention to any failure codes returned from HealthVault. In fact, make sure you log nonsuccess return codes from API calls to HealthVault so that you can investigate the reasons for failure. HealthVault provides a comprehensive list of status codes returned by the service at http://msdn.microsoft.com/en-us/library/hh567902.aspx. Particularly interesting is CREDENTIAL_TOKEN_EXPIRED, which your application should handle by requesting a new credentials token from HealthVault. The HealthVault .NET SDK and Mobile SDKs handle this status appropriately for you. In case you see the INVALID_XML status code, you should look closer at your request to make sure the XML is valid for various HealthVault methods and data type schemas, which are available at http://developer.healthvault.com.

HealthVault enables a coherent and well-adopted data ecosystem. It is very important to make sure that your application works well in this data ecosystem and uses the HealthVault data types appropriately. Chapter 4 explains HealthVault data types in detail. The best way to make sure you are reading a data type appropriately is to create a few instances of the type you are consuming with various possible permutations and combinations and then access them in your application. Get Real Consulting offers a great tool called HealthVault X-ray (http://xray.getrealconsulting.com/) that enables you to create myriad instances of the data type you are consuming in an appropriate test account.

The second aspect of working with the data types is to make sure that the information you are writing is consumable by other applications. The HealthVault team offers a tool called HealthVault Data Checkup at http://datacheckup.healthvault-ppe.com/hvappcheckup. This tool works against data written by your application in a test record and finds any compatibility issues. Currently, the HealthVault Data Checkup tool supports only a limited number of types. Another mechanism to ensure that your application plays well in the HealthVault ecosystem is to copy your test records through HealthVault X-Ray in a production test account, authorize other HealthVault applications to access this account, and then confirm that the information is consumable by these applications.

Frequently, applications code properties of HealthVault data types improperly or are not able to parse a flexible date format as used in HealthVault. Review Chapter 4 to make sure you handle these cases.

After testing your application thoroughly, including the conditions listed in the previous section, you are ready to release it to end users. The HealthVault team has documented the release process, termed the Go-Live Process, on the HealthVault Developer Center at http://msdn.microsoft.com/en-us/healthvault/bb962148.

The first step in this process it to ensure that you have signed a business agreement with HealthVault and have an identifier associated with your partner account. This is a nontechnical step and can be done long before your application is ready to be released.

Having established a partner account with Microsoft, you can submit a request to the technical team to review your application in the preproduction environment and push it to the HealthVault production environment. The review typically tests that your application plays well in the HealthVault ecosystem and uses the brand appropriately.

Once your application is available for the world to use, an important step is to network with fellow applications! This can be done using the wiki provided by the HealthVault team at http://partners.mshealthcommunity.com/hv_eco/w/wiki/partner-directory.aspx. In addition to business networking, this wiki is used by applications to notify the development community of any extensions to data types that they have implemented. Having well-documented extensions available makes it easy for other applications to work with data created by your application, giving you the benefit of network effects.

The last step in your Go-Live Process is to make sure that your application is discoverable to end users. This typically means working with the HealthVault team to become part of their application directory at http://www.healthvault.com.

Congratulations on getting that application out there! Whether you have created a client or a web application, it’s very important to monitor its health.

You should log all the failed calls to the HealthVault web service. For additional debugging, the HealthVault SDK provides a tracing mechanism that you can use to log all the request responses. The mechanics of this are detailed at http://msdn.microsoft.com/en-us/library/ff803626.aspx. The HealthVault team monitors their development forums, available at http://www.msdn.com/healthvault, and you can use them to report any anomalies or failures in the service.

Each release of the HealthVault .NET SDK is supported for two years, and the team frequently adds enhancements and bug fixes to the newer releases. SDKs and libraries available in other language—Java, Python, etc.—are also updated by the community. As part of maintaining your application, you should make sure you monitor the underlying libraries so that you can upgrade your service to use the most robust offerings.

Another important aspect of maintaining a HealthVault application is to maintain its security artifacts, such as the application certificate and user tokens. HealthVault uses X509 certificates to authenticate web applications; you should make sure that the certificates you use for your application have the appropriate validity to function for a long time. HealthVault uses long-lived user tokens for client applications, and you should make sure that these applications frequently refresh the tokens.

Having a well-tested, well-maintained, and usable application will frequently result in a number of feature requests from users, which is not a bad problem to have! Many of these feature requests will necessitate support for additional HealthVault data types.

When you update your application to access new HealthVault data types, you must request the user to reauthorize your application so that it can access these additional data types. Another feature available from HealthVault is optional rules, which are data type authorization rules that ask permission only for additional data types. In addition to providing a smooth upgrade curve, optional rules also enable you to run an older version of your application side by side with the new version in case your users prefer not to upgrade. You can read more about optional rules at http://msdn.microsoft.com/en-us/library/ff803609.aspx.

Updating the data type rules of an application is not automatic, and an application typically needs to go through the HealthVault Go-Live process at http://msdn.microsoft.com/en-us/healthvault/bb962148 to release updates in the HealthVault production environment.

Throughout this book, we have worked with HealthVault as it is available in United States. However, HealthVault has a growing list of implementation partners, and the platform is available in Canada, the UK, and Germany as of this writing. You can work with the HealthVault team to explore releasing your application in each of these countries.

The important aspect to keep in mind is that HealthVault as a service is completely globalized and internationalized. The request and response string that HealthVault displays to a user can be changed to appropriate locales. In fact, you can also make a Spanish version of your application available in the United States. The HealthVault Application Configuration Center, through its Localize tab, allows developers to configure their applications with Spanish strings so that when a user with Spanish browser settings accesses HealthVault, the application’s authorization screen is shown with the appropriate language. The HealthVault Shell redirect interface, which is discussed in detail in Chapter 3, also respects an lcid=Locale ID parameter in its query string to show the appropriate display language in the user interface.

Additionally, HealthVault offers an internationalized set of units and time formats to allow applications to work with appropriate standards in the target country.

With this information, you are all set to stride into the exciting world of enabling Quantified Self with HealthVault!

This section highlights some important resource available for HealthVault development.