Revisiting Connectivity Models and Solutions Architectures
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.
HealthVault + Your Client Applications
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.
Choose Your Data-Types
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:
- If you are using one of our SDK’s to build your solution, then you can use predefined library classes encapsulating our data-types. With the .NET SDK, data-type classes are referenced from the Microsoft.Health.ItemTypes.dll assembly file. Using these classes trivializes creating data-type object instances, object serialization, and transferring data to/from HealthVault. Our new Win8 library includes a modernization of these classes specifically useful within the Windows Runtime execution environment.
- If you are not able to use an SDK within your solution, then you’ll need to deal with data-types formatted as XML or JSON. This is often the case if your solution runs in an execution sand-box such as Silver Light, as client-side script running within a browser, or on an embedded device. You may need to “roll-your-own” data-handling classes, copy them from SDK source files, or perhaps auto-generate classes from schema using a tool like XSD.exe. The amount of development involved depends upon the number and complexity of data-types you’ll be using.
- Each HealthVault integrated application is custom-configured to access specific data-types. You utilize the HealthVault Application Configuration Center to define data-access rules for your application along with corresponding specified data-types. HealthVault uses this configuration information to limit your application to as-specified and user-authorized fields within HealthVault records.
- Spend some time thinking thru data-centric scenarios. For example, typical clinical-trial scenarios require that data-measurements can’t be changed. In that case, use the HealthVault “immutable” data-type attribute.
- Consider using the Care Plan data-type or the Continuity of Care document type if your solution will be providing summary information to patients and especially if that information is important for sharing with other providers.
- Will you be rendering the data to a UI, perhaps a browser? Consider utilizing the transforms provided with HealthVault platform services to ease your development burden.
Choose Your Connectivity Model
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:
- If you anticipate both a web-portal usage scenario as well as a back-end clinical system usage scenario, then you’ll need a combination of both Online and Offline connectivity.
- It’s possible to have aspects of all connectivity models within a sophisticated distributed solution scenario. You may consider utilizing a Master-Child ID HealthVault Application configuration in that case. Otherwise, you’ll either have a single Application ID with multiple access-rule definitions or a number of Application ID’s with individual access-rule definitions.
- Direct connectivity requires nothing more than an exchange of Trust between your organization and HealthVault operations. You may wish to join the Automated Blue Button Initiative and participate in Trust Bundles wherein multiple business entities exchange Trust collaboratively as groups.
- Direct connectivity is a great way to accomplish Meaningful Use certification criteria. Leverage HealthVault to achieve patient View, Download, and Transmit (VDT) objectives and subsequently request a report of completed VDT activities.
Choose Your HealthVault Features
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:
- Your solution’s patient and patient-record interactions will determine your choice of platform feature-area integration. Consider the workflows involved and design accordingly.
- Perhaps you want to utilize more than one workflow feature area from within the same solution. Consider implementing a central service from which multiple subsystems may share a common HealthVault connection.
- A usage scenario options matrix is published here.
Choose Your Solution Platform
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:
- Market reach. Are you developing for mobile? You will likely need to consider designing for code-portability which may drive your solution design to a web-service model with as much “common-code” on the client device as is possible.
- Enterprise or Consumer? Consumer applications typically correspond in a one-to-one manner. That is, one application user to one HealthVault record. Enterprise applications, however, may exhibit a many-user to many-record usage model. This becomes very important as you imagine who your target users may be. A physician or nurse using a tablet device may wish to scroll a list of patient records, select one or more, and exchange information with the selected person or group. Hence, SODA connectivity running on a tablet platform may be appropriate for Consumer while the Enterprise scenario requires more design decisions and corresponding system integration considerations.
- An interesting new platform option is the Windows Runtime introduced with Windows 8. Windows Runtime applications are distributed via the Windows Store (an Enterprise-scoped distribution option exists as well). A first-party HealthVault Windows Store application is available to consumers for free. In fact, you may leverage the same code library as our Windows Store app to build your Windows Store application.
HealthVault + Your Web Service + Your Client Apps
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:
- Serve as a HealthVault interface for an Enterprise domain enabling both a departmental system deployment model as well as an Enterprise tablet device deployment model.
- Centralize a write-once, deploy-once, HealthVault connectivity and feature integration solution. The proxy service is the only subsystem component with the need to understand HealthVault connectivity and HealthVault feature API’s. All client-app types need only understand how to integrate with the proxy-service itself (more on this momentarily).
- Expose a subset of HealthVault features including Data-Access, Patient Connect, DOPU, and as a Direct Gateway. The SODA connectivity model wouldn’t make sense within the proxy-service as it is intended instead as a direct-to-HealthVault connectivity model. The Online connectivity model might be combined with the Proxy Service if an interactive Patient-Portal experience is required. In that case, the proxy service would effectively host both a web-app as well as a web-service with corresponding Online and Offline configuration rules.
- HealthVault currently doesn’t expose services directly as REST, SOAP, or OData. Hence, the proxy-service provides an opportunity to implement these standards on behalf of HealthVault. Thereby, increasing the richness of client usage scenarios.
- HealthVault is a very XML friendly platform. A proxy service may provide a translation function wherein XML content is transformed to whatever client data-model desired; JSON, for example.
- Serve as a central-point for organizational analytics, profiling, or security management.
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.