Monday, February 22, 2010

The Vocabulator - a web based data dictionary

One of the challenges we face in preparing medical reports is the maintenance of a data dictionary or vocabulary.  Compounding this problem is the fact that the same term can have different meanings in different contexts and to different areas in a hospital.  For example, something as simple as the term: "patient" may have a different meaning to an attending physician than to a manager in the finance department.

Even in those places and cases where the definition of a term is consistent, it may not be widely known or understood.  For example, "Length of Stay" may have a standard definition such as "the number of days the patient is counted in the midnight census."  However, this might result in a patient who is in the hospital for two days with a length of stay of only one day;  i.e., only present for one midnight census.

I mentioned to one of my associates how great the New York Times web site was because I could simply double-click any word while reading and a definition would pop up.  He suggested that something similar might help us provide context sensitive definitions to our reports.  And so began my efforts to develop a tool to bring a data dictionary to our reports.

First, I had to list the constraints and objectives for developing the tool:

  1. Most of our internal web sites do not have external web access.  Therefore, the tool must be able to function without Internet access.
  2. The vocabulary must be very easy to create and edit.
  3. It would be nice if we could have a custom vocabulary for different sites and purposes.
  4. It must run on any web page on any host web server.
  5. It can't cause any latency or delays for our end users.
  6. It must be able to grow without requiring much, if any, maintenance as it grows.  In other words, if we change or add a term to the vocabulary, then it must immediately show up in all of our web consumer pages without requiring page edits or other modifications.
With some trial and error, I decided to host the core functionality in two primary components running on a single Microsoft IIS web server.  The first is a web service that serves up the vocabulary in a JSON response; and the second is a small set of JavaScript libraries.

In the next post, I will dig into the development details and some of the challenges I found - and include the source code for those who may have similar challenges.  However, to demonstrate the final product, the following paragraph is a fictitious example of how it might work:

This is an example of how the vocabulator tool might work.  Our hospital might see patients in the ED with FUO, TBP, or other complaints.  They will be seen PRN by the attending physician unless she is at 289.

Move your mouse over the highlighted words in the paragraph above such as "ED" to get a quick definition; or, press the linked word for a more complete definition in a pop up box. 
Note that the lookup of the words is handled asynchronously after the web page is displayed so that there is no performance impact to highlight each word.

In my next post, I will describe in detail how the tool works; but the key points here are that the edits required on the web  pages are very minor and easy to make and once made, the vocabulary running on the web service will automatically update each web page after it is first rendered and thus obviating the need to make additional edits as the vocabulary grows.

Sunday, February 21, 2010

Hosting Domains with Dynamic DNS

The folks over at Google do a great job of allowing folks to create simple web sites and I have helped our local homeowner’s association deploy a web site there.  However, for some things such as web services, it is better to host on a server I control and for those I have a small web server running at home. 

I also like to be able to use Remote Desktop Protocol to “remote in” to my home network from work and need the IP address to do so.  Unfortunately, our Internet Provider can and will change the IP address periodically since it is assigned via DHCP and this prevents me from hosting web services or remoting in.

Enter Dynamic DNS or DDNS.  With a DDNS service, you can quickly change the IP address associated with your domain name(s) when your IP address changes at home. 

For several years, I had GoDaddy host my domains and used ZoneEdit for the DDNS.  This worked great but due to a number of issues recently with GoDaddy, I moved my domains over to NameCheap and I’ve been very impressed with them so far.  The cool thing is that NameCheap also provides for DDNS and so I now have everything managed in one location.

At the end of this post, I’ll provide links to the DDNS code I wrote for both ZoneEdit and NameCheap; but, let me first describe the functionality I wanted.
  • I wanted a light-weight service that runs in the background automatically.  To accomplish this, the code runs as a background Windows Service that automatically starts when Windows restarts.  The benefit to me is that when Windows Update automatically cycles my server and it is assigned a new IP address by my ISP on startup, the service will automatically update my DNS settings at NameCheap.
  • I didn’t want to hammer the DDNS server when the IP address didn’t change.  To meet this, I store the current IP address and only send the update requests when it changes.
  • I needed to exclude the private addresses assigned on my network.  To meet this goal, in the ZoneEdit code, I have the exclusion list in the config file.  For the newer code for NameCheap, I hard code the exclusions to all the non-routable private networks and also provide for the ability to exclude certain addresses.
  • I needed to be able to add or remove domains or sub-domains without recompiling the application.  Both apps use configuration files to add or remove target domains.
  • And I needed logging to see if I had problems.  Both tools write to the Windows event log.
The ZoneEdit Code with a compiled version is here.

The NameCheap Code with compiled version is here.

I recommend that you examine and compile the code yourself; but, if you want you can use the pre-compiled version you must agree to do so at your own risk!  If you do, you need to install the service by using the “InstallUtil” utility that ships with Microsoft .NET and I’ve included for convenience.

Hosting small web sites or services at home can work with DDNS and I’ve provided a couple of tools to help you do this; but, if you have more than a few visitors, I strongly recommend that you go with a professional hosting organization and not try to run this at home.