Over the past few weeks, we’ve participated in healthcare solution development events at the University of Louisiana and in Silicon Valley. These events were designed to spark healthcare informatics innovation using team-competition and incentives, including cash prizes. We enjoyed many aspects of these events (Fred Trotter’s soap-box session stands-out) and consider it a privilege to have met so many dedicated and wonderful people. As I observed event participants discussing and prototyping their solutions, a key takeaway for me was a perception of confusion about just how to get-started developing for HealthVault. In certain respects, the HealthVault platform is a simple XML over HTTP web-service. But, there is much more to it than that, and; in practice, perhaps few would choose to use the service without an encapsulating client-side SDK anyway. Much of our developer documentation necessarily details the platform’s foundational XML over HTTP implementation with perhaps inadequate coverage of corresponding feature-areas as abstracted by our SDK classes and constructs. Navigating our platform features from a “getting-started” perspective, and especially during a 48 hour competition, can be challenging. Herein, we hope to clarify a few key solution design-options that map onto platform functionality and identify corresponding “getting-started” decisions.
Download a PDF version of this article.
The following image illustrates that HealthVault Platform Services are exposed via a number of feature-areas. Some of these features are unique for a web-service in that they encapsulate workflow involving interaction with real people. If our web-service involved only content browsing, selection, and consumption, then it would be much more recognizable relative to common web-service abstractions. Consequently, a first-step conceptually is recognition that you may be dealing with uncommon terminology and unfamiliar extensibility models. Let’s explore this illustration further.
Refer to the lighter-blue graphic in the middle of the illustration directly above. Though not comprehensive, this feature-list is key to understanding solution integration options. For example, it’s readily apparent that the platform exposes a data-access API and that most operations utilize a PersonID and a RecordID parameter to uniquely target a HealthVault record. Also, note the top-most green text-block to the right under the heading “Your Client App(s)”. As a solution designer, a first decision is simply to identify what operations (e.g. create, read, update, delete) are required upon which data-types hosted within a HealthVault record. Do you need to know what data-types are available? Browse over to developer.healthvault.com. Notice the link therein to the Health Types Schema Browser.
Special considerations for data-types:
HealthVault exposes a rich set of client application connectivity options. Why do we need many options? Recall that your application will be participating in one or more workflow activities involving real people who may or may not be using your application interactively when HealthVault platform interaction occurs. This is an important design-to point best described by scenario example. Note that many HealthVault solutions utilize more than one connectivity model depending upon aspects of the overall solution architecture. Again, developers utilize the HealthVault Application Configuration Center to define their application connectivity requirements that correspond directly to connectivity model decisions.
The Software on Device Authentication (SODA) connectivity model applies when you are writing an application that will most likely run with user-interactivity on a personal computer. A SODA application typically accesses only a single HealthVault record at once. This connectivity model was conceived in order to simplify management of secure access to the HealthVault platform from widely distributed client-application installations. Platform interactivity occurs securely within a shared-key encrypted session. This avoids the complexity of managing a Public Key Infrastructure as certificate exchanges are not required. Of course, the various HealthVault SDK’s encapsulate the SODA model functionality and most client applications thus inherently benefit without further development beyond invoking the connection methods.
Online connectivity applies to web-page applications (e.g. Patient Portals) wherein HealthVault data-access occurs within a user-interactive browser session. Typically, user authentication initiates secure site access along with corresponding HealthVault application access. As most Online applications are deployed within data-centers, certificate based security is much more viable. Hence, Online applications are configured to use a private-key certificate in which the corresponding public-key has been previously shared with the HealthVault platform using the HealthVault Application Configuration Center. When using the HealthVault SDK, developers may derive their web-pages from HealthVault base classes that encapsulate Online application functionality.
Offline connectivity is appropriate when your solution requires access to HealthVault records anytime and without user interactivity. A one-time Patient Connect workflow process (described further below) is required of Offline applications. Thereafter, your Offline application may simply invoke record access as needed. This access occurs indefinitely or until the access authorization is explicitly removed; either by the account owner or by the Offline application itself. Offline application authentication is also certificate based with corresponding Offline data-access rules defined using the HealthVault Application Configuration Center. When using the HealthVault SDK, developers may leverage the OfflineWebApplicationConnection class to initiate an Offline connection.
Direct connectivity refers to a secure messaging (i.e. secure email) HealthVault platform facility. The Direct Project served as the genesis of loosely-connected consortium providing secure data-transfer for healthcare providers and their patients. Each HealthVault consumer receives a free secure email inbox (e.g. firstname.lastname@example.org). Solution providers may simply integrate with a secure email server gateway in order to exchange information with HealthVault account owners. What if you don’t know whether or not a patient has a HealthVault account? No worries, just send your message to a special HealthVault Direct address (i.e. email@example.com) and specify the patients insecure email address in the subject line (e.g. firstname.lastname@example.org) and HealthVault will enable that patient to both create an account and receive your message. You may also attach standard healthcare documents (e.g. Continuity of Care Documents) and HealthVault will import the information into the appropriate Health Information fields of the patient’s HealthVault record.
Special considerations for connectivity models include:
It’s somewhat easy to confuse connectivity models with other platform features because there are close relationships between them. As mentioned, an Offline application will typically utilize a workflow named Patient Connect to gain authorized access to a HealthVault record. Hence, it’s common to refer to Offline connectivity and Patient Connect synonymously. However, it’s preferable to separate these as Patient Connect is more a type of workflow than a connectivity model. We won’t explore many HealthVault platform features in this section, but rather discuss a few that become important for HealthVault solution designers.
A Patient Connect workflow is typically used within a solution that requires access to HealthVault records without a user-interactive session. Patient Connect is often combined with Offline connectivity (discussed above). The classic use-case is one of new patient registration. In a clinical setting, you want to both establish a patient record within your back-end clinical systems as well as establish access to the new patient’s HealthVault record. Your application initiates Patient Connect by sending a request to HealthVault including a local patient ID and a secret question/answer known by the patient. HealthVault responds with an access token along with a welcome URL. You provide this information to your new patient (e.g. either via email or via a kiosk). When the patient browses to the URL, HealthVault validates the access token and guides the patient through account access/creation and authorization of your Offline application. Once this workflow is completed, your application may query HealthVault for a list of authorized accounts and associate those with entries within your patient database. You subsequently interact with HealthVault programmatically using the patient HealthVault PersonID and RecordID.
DOPU, meaning Drop-Off and Pick-Up, is a workflow in which your application sends information to HealthVault but with no direct HealthVault record access. Like Patient Connect, you initiate DOPU by sending a request to HealthVault including attached healthcare information. You also provide your email address, the patient’s email address, text representing an email to the patient, and a secret question/answer know by the patient. HealthVault stores this information, returns a package ID, and subsequently sends your email message to the specified recipient. The patient will receive instructions via email for on how to retrieve the information securely. Any attached information recognized as HealthVault data-types are optionally imported into the recipient's HealthVault record. This feature enables a very loosely-coupled patient-provider information exchange.
I’ll mention support for Devices as a platform feature as well. Many healthcare devices are listed within the HealthVault Device Directory. Some of these devices are very capable providing directly integrated HealthVault connectivity via Wi-Fi or mobile networks. Others leverage companion personal computer applications, importing data via USB for example. Alternatively, devices vendors may leverage the HealthVault Connection Center application and USB connectivity to transfer data to HealthVault records. Interestingly, the HealthVault Connection Center application also provides image file uploading functionality (e.g. DICOM images).
Direct Messaging is also a workflow-oriented platform feature (in addition to a connectivity model). What could be more intuitive than sending an email with attachments from your clinical solution? Currently, HealthVault users will need to enable the integrated HealthVault Message Center in order to utilize their inbox and subsequently transmit information to providers.
Special considerations for HealthVault features include:
We probably already have an SDK or code-library for your target solution platform. Again, an SDK is not strictly required for HealthVault solution integration. But, if you use one, you won’t have to write a lot of protocol handling, security constructs, and data-type parsing and serialization code. Our SDK list is here along with a number of corresponding samples.
Special considerations for solution platforms include:
You may require a solution architecture in which multiple client applications utilize the same HealthVault subscription. The following image illustrates this model. This design would be ideal for an enterprise clinical system servicing multiple departments with a variety of client-app types. Let’s walk-thru the illustration in more detail.
In the middle of the image is a “cloud provider” hosted “HealthVault Proxy Service”. This service encapsulates all connectivity with the HealthVault Platform and is configured as an Offline application from a HealthVault perspective. It serves primarily as a stateless router of HealthVault access requests from any number of Mobile, Enterprise, or Device applications (illustrated on the lower-right of the image). Ideally, this Proxy Service would accomplish several functional requirements for the client-app community including:
In fact, this is the solution architecture that our Dynamics CRM partner’s are utilizing to implement Population Care Management solutions. The use of a proxy service is actually necessitated by the Dynamics CRM solution extensibility sand-box. The HealthVault SDK assemblies are restricted from use in the solution sand-box for a number of reasons including the use of system cryptographic methods. However, code running within the sand-box is completely capable of call-outs to web-services. It’s important to note that the proxy service need not be hosted in the cloud at all. In fact, it could reside on the same server or within the same domain data-center as the Enterprise client systems.
As you may have guessed, this article is a segway to subsequent articles focused on exactly how to implement a HealthVault “bridge” solution architecture. A number of motivations culminate in this exercise. One is that modern application design is largely focused on cloud-services composition instead of on isolated application design. Imagine a clinical office utilizing Office365, Dynamics Online, Windows Azure, Lync or Skype, and HealthVault as platform technologies for their healthcare informatics needs. With a bit of customization, these subscription-based services would fulfill a significant amount of business process technology requirements.