“Be careful about reading health books. You may die of a misprint.”
Over the last few chapters we have gained an understanding of the HealthVault API (Chapter 3), learned about building a HealthVault web application with a focus on the HealthVault data types (Chapter 4), and built an engaging mobile application (Chapter 5). An application’s life cycle typically involves testing the application, releasing it to the user, and then monitoring it for anomalies, tasks that entail special requirements in a HealthVault context. This chapter will highlight best practices for releasing, maintaining, and marketing HealthVault applications to end users.
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.