HealthVault SDK 1.0 introduces an interesting capability by which an HealthVault application can read their application certificate from a file. Eric has some details about this on his blog.

I’m going to describe how this capability of reading an application’s certificates from the file store could be used to run HealthVault application on Windows Azure. Here are the steps to get a simple HealthVault application (which I call HelloHV) running on Windows Azure:

1. Install the Azure SDK and HealthVault SDK. Create your HealthVault application as a Web Role.
2. Configure and create an HealthVault application using the application manager utility in HealthVault SDK. Make sure you set the Action-Url to http://<yourapp>.cloudapp.net/Redirect.aspx  using the Application Configuration Center.
3. Copy the Redirect.aspx & Redirect.cs from HealthVault samples (HelloWorld in HealthVault SDK) in to your application and add reference to HealthVault assemblies (you can find them in C:\Program Files\Microsoft HealthVault\SDK\DotNet\Assemblies)
4. Add the HealthVault related config settings to your WebRole’s Web.Config, the easiest way to do this would be copy the relevant key(s) from a sample in HealthVault SDK. Here is an illustration :

   <appSettings>
     <add key="ApplicationId" value="01e21bd1-cb13-40d6-8f01-596286827d6d"/>
     <add key="ShellUrl" value="https://account.healthvault-ppe.com/"/>
     <add key="HealthServiceUrl" value="https://platform.healthvault-ppe.com/platform/"/>
     <!-- when we call the SignOut() method on HealthServicePage,
          it redirects us to the page below -->
     <!--<add key="NonProductionActionUrlRedirectOverride" value="Redirect.aspx" />-->
     <!-- The redirect page (specified above) uses these keys below to redirect to different
          pages based on the response from the shell -->
     <add key="WCPage_ActionHome" value="default.aspx"/>
     <add key="WCPage_ActionAppAuthSuccess" value="HelloHV.aspx"/>
     <add key="ApplicationCertificateFileName"
          value="~\cert\WildcatApp-01e21bd1-cb13-40d6-8f01-596286827d6d.pfx"/>
   </appSettings>

5. While testing on your local machine uncomment the following line in the Web.Config, this will allow HealthVault to communicate with your local machine. However make sure that this is commented when you publish the application.  Alternatively the following key can also be stored in UserApplicationConfigs.xml, if you maintain one for your development.

   <!--<add key="NonProductionActionUrlRedirectOverride" value="Redirect.aspx" />—->

   Gotacha1: Windows Azure changes the port numbers for your application so its hard to make it work without using the action-url configured for your application in Application Configuration Center.

6. In your Default HealthVault Page Make sure you read the certificate for your application from a local file (you can also use Azure Storage).

   Gotacha2: HealthVault SDK expects the ApplicationCertificateFileName to be absolute filename, this is impossible to determine for a cloud system like Azure. However we can get the absolute path by changing the value of the key at run-time.

   
   public partial class HelloHV : HealthServicePage
   {
       protected void Page_PreInit(object sender, EventArgs e)
       {
           ConfigurationSettings.AppSettings["ApplicationCertificateFileName"] =
               MapPath(@"~\cert\WildcatApp-01e21bd1-cb13-40d6-8f01-596286827d6d.pfx");
       }
   
       protected void Page_Load(object sender, EventArgs e)
       {
   
   ..
   

7. Hit Run and see your Hello HealthVault  application in action!!

Now the show time:

Check out a simple (HelloHV application) running on Windows Azure here.

The associated code for this application is shared here.

Remember to switch to SSL and secure your application certificate (using password or Azure Storage) before you consider taking an application running on Windows Azure live as a production HealthVault application.

I have previously posted about Understanding Health Ontologies and Standards. In this post I’ll focus on SNOMED-CT (Systematized Nomenclature of Medicine Clinical Terms). SNOMED-CT is the most comprehensive vocabulary to express clinical terms – it spans languages, specialties and geographic borders.

SNOMED-CT includes:

• Terms or synonyms relating to a clinical concept
• Links between different concepts

To give you a taste here is an example of Blood pressure reading represented using SNOMED-CT from the linked paper (“Towards semantic interoperability in healthcare: ontology mapping from SNOMED-CT to HL7 version 3”, Amanda Ryan):

In addition to having a model to represent concepts and linkages the biggest draw of SNOMED CT is a staggering number of coded qualifiers (which belong to one concept or other). According to IHTSO there are about 311,000 actively used SNOMED CT concepts.

You can register for SNOMED CT here. Its free for companies and individuals in United States, however your registration is processed by NLM and it might take over 3 days to receive a confirmation and access.

Once you are through with registration and have an account, start by downloading the core subset of SNOMED CT concepts here, this list consists of about 5000 most frequently used terms by institutions across US. Its a good set to get familiar with, it consists of the following concept area:

• Clinical finding        : 4,550 codes in total
• Procedure            :   414 codes in total
• Situation with explicit context    :   132 codes in total
• Event                :    38 codes in total
• Body structure            :    46 codes in total
• Social context            :     2 codes in total

We can use BCP to copy the files from SNOMED CT Core in to our local database, and do more interesting queries & data analysis like find distribution on these terms, co-relate problems vs. findings and of course work on the larger SNOMED CT database to find synonyms etc.; but I’ll keep that for another day. Here very quickly I’ll show how one can use a web-based browser, Snowflake, http://snomed.dataline.co.uk/ (requires registration) to lookup a SNOMED code and see what else it relates to. We can see that in line 3 above SNOMED CT concept 10085004 is marked as Metatarsalgia (finding), however using the Snowflake browser we can see in that in addition to being a finding this concept is a problem as well.

This was just tip of the ice-berg, please leave comments for future posts / areas to consider in the Ontology domain.

Further reading / relevant links:

• LexGrid: Wiki

In this series:

1. Understanding Vocabularies. Wait! What did you say?
2. Understanding Vocabularies #2 – HealthVault Recommendations
3. Understanding SNOMED CT

Jared Diamond makes a case that our recent history has been shaped by Guns, Germs and Steel. In this century we have seen in various ways how Guns, Germs and Steel wield their power. Currently, we are dealing with one such power fit of *Germs*. They say, flu is in the air, beware!

Earlier this year I had made a post about tracking Swine Flu using Ushahidi’s software. Various folks online have tried to help raise awareness of the pertinent epidemic, most noticeably CDC has launched a comprehensive website flu.gov to inform us better. Microsoft has launched the H1N1 Response Center and Google is helping through Flu trends.

Most common flu is the seasonal flu, which every year takes a toll of about 36,000 lives from late fall (Nov) to early Spring (March) and effects about 5-20 percent of population. This season we have a risk for a getting hit by swine flu (H1N1) which can cause more deaths, and there is an even deadlier version – the avian flu (H5N1).

So what should you do?

• Wash your hands and avoid close contact with sick people.
• Consider taking the Flu shot from a facility near you
• If you feel Flu, take a Flu assessment powered by HealthVault .
• Spread Flu Awareness – may be use the widget below:

Here is the code to copy this widget to your blog / website:

<iframe height="200" src="http://www.reemedix.com/misc/fluwidget.html"
    frameborder="0" width="300" scrolling="no">
</iframe>

Recently the ASP.NET MVC framework came out of beta and has garnered a lot of developer interest. This framework tries to provide interesting things like – total control over HTML, human readable URLs, AJAX, and facilitates test driven development. Successful web development frameworks like Ruby on Rails (ruby), Django (python) and Spring (Java) – also enable these characteristics. So cleary, there is some traction and tread for web frameworks to facilitate the Model, View, Controller paradigm.

There are quite a few challenges with regards to HealthVault SDK to work in this realm. The standard HealthServicePage no longer works in a controller paradigm. Eventually the SDK will need to provide a HealthServiceController, but until then I’ll try and explain how we can use the current SDK to work in an ASP.NET MVC world.

As I have explained earlier in my ruby series HealthVault authenticates an application in three contexts – anonymous, the application itself and the application in presence of user information. In this series I will try to take the same approach and explain how we can do the same with ASP.NET MVC.

It’s relative easy to talk to HealthVault via the anonymous GetServiceDefination method. Here is the heart of the code which enables this:

   1: public ActionResult Index()

   2: {

   3:     ViewData["Message"] = "Welcome to HealthVault ASP.NET MVC!";

   4:     

   5:     // Do an anonymous connection with HealthVault using the Hello World application id

   6:     ApplicationConnection appConnection = new ApplicationConnection(

   7:         new Guid("05a059c9-c309-46af-9b86-b06d42510550"),

   8:         "https://platform.healthvault-ppe.com/platform/");

   9:     // Get the service defination from HealthVault platform

  10:     ServiceInfo sInfo = appConnection.GetServiceDefinition();

  11:     // Pass the data for viewing

  12:     ViewData["ServiceInfo"] = sInfo.HealthServiceUrl.ToString();

  13:     return View();

  14: }

Next time: How to authenticate your application with HealthVault through ASP.NET MVC

In my last article in the vocabulary category, I described the need for semantically enabled data and how different categories of health data have different standard vocabulary / ontology associated with them. In the following table I attempt to summarize the recommended vocabularies for different HealthVault types.

Disclaimer: Please note this is not a definitive or complete list, and I will update the table as I discover inconsistencies. The definitive source are the XSDs associated with HealthVault data types.

As  you can notice above we recommend ICD-9, RxNorm, LOINC, NDC. x12-de-1130, x12-de-335. We do prefer SNOMED-CT as well, however the application using it need to have license for it.

Having written the above I would like to match that with what Dr. Halamka recommends in his post. Note that I mention content column for completeness, however its not useful for comparison.

Next Time: I’ll try to update the above tables with more details and try to come with recommendations of which clinical type (in the Data column above) would potentially match with which HealthVault type.

As usual leave your suggestions in the comments.