Microsoft .NET Case Study: Hospital Medical Record Order Entry

RECSTORE, Inc., a publically traded outsource medical records storage company (more), wanted to make it easier for its client hospitals to order medical records. We are using the pseudonym "RECSTORE" to protect their confidentiality from search engines. RECSTORE had already developed an application called DeliverExpress to manage the retrieval of medical records with a high-performance user inteface. However, ease-of-deployment became more important than user interface conveniences. This is the story of how we developed a new web interface for DeliverExpress. As of this writing, the DeliverExpress Web Edition is now being used by over 1,000 health care professionals in hospitals throughout Northern California.

Web Order Entry for an Outsource Medical Record Storage Service

The previous user interface for DeliverExpress was based on Oracle Forms. It had a rich set of controls that gave users immediate feedback whenever a single data entry field was changed. However, the implementation had the following drawbacks:

• Every Oracle Forms PC consumes a portion of an Oracle server license.
• Oracle Forms runtime software had to be installed and maintained on each client PC.

RECSTORE wanted a system that could grow without incurring more Oracle licensing fees. And its client hospitals needed a system that did not require any special client software to be installed. These needs plus some competitive pressure led them to the DeliverExpress Web Edition. A Microsoft .NET Remoting solution was considered, but rejected because it would require the .NET Framework to be installed on all client PCs.

The DeliverExpress web interface isn't very pretty, but it was accepted by all five of the beta test hospitals. Below we recount the technical challenges that we faced and how we overcame them on the road to a successful product launch.

Robust Security

Login page (click to enlarge)

Patient hospital medical records are very sensitive documents. RECSTORE must prevent patient from falling into the wrong hands. To minimize risk, the security facilities we selected for DeliverExpress Web Edition include:

• Virtual Private Netword (VPN) to insure that only authorized people and PCs are allowed to access the system.
• Secure Sockets Layer (SSL) to prevent packet-sniffing and credential theft. All messages are encrypted so that then cannot be interpretted even if they are intersepted.
• .NET forms authentication that writes encrypted cookies on client PCs to prevent impersonation attacks. Before .NET processes a web page request, it checks to see that the request includes an authenticated cookie. If not, it automatically redirects the user to the login page.
• Session cache validation to prevent replay attacks. Before DeliverExpress processes a web page request, it checks to see that the user session has valid data in its session cache. If not, it automatically redirects the user to the login page.
• Stored procedure calls to Oracle to preclude SQL injection attacks.

The decision to use stored procedures also makes it easy to change the underlying database schema without impacting the user interface.

Client-Specific Record Identifiers Required Custom Web Page Controls

Login page (click to enlarge)

Each client hospital identifies medical records differently. Even within the same hospital, different departments use different keys to identify patient records. Therefore, the DeliverExpress user interface must be rule-based so that it displays only the key fields that pertain to the currently selected client site and record system. This requirement led us to develop the following ASP.NET custom web controls that are defined at runtime according to the rules:

• An array of text boxes for capturing search criteria. For this we chose to add columns dynamically to the ASP.NET WebControls.Table.
• A grid for displaying retrieved records. For this we chose to add columns dynamically to the ASP.NET WebControls.DataGrid. It includes a checkbox column so that hits can be selected for the next order.
• A data entry grid for capturing pull record identifiers that may not be in the database. To make this even more interesting, the ad-hoc data entry grid must also display the records already selected. Each row must include a checkbox to make it easy to deselect and thereby delete a record from the selected items list. And the columns of previously selected records must appear read-only except for the reasons and comments that might be entered or changed for any selected record prior to ordering. This custom control was subclassed from the ASP.NET WebControls.Table

The decision to use stored procedures also makes it easy to change the underlying database schema without impacting the user interface.

Three-Tiered Software Architecture

DeliverExpress is divided into presentation, business logic and data access layers. Behind the scenes, medical record catalogues were in the process of migrating to a shared schema. To hide schema changes from the user interface, the business logic is implemented in Oracle stored procedures. Thus, DeliverExpress ASP.NET solution is divided into three ASP.NET projects:

• One project that contains all the ASPX pages
• Another project that contains all the custom web controls and
• A business logic/DAL project. This contains classes for all the business objects accessed by Oracle stored procedures and a class called clsOracle that encapsulates the Oracle data connection and common methods such as filling a datatable.

The decision to use stored procedures also makes it easy to change the underlying database schema without impacting the user interface.

Less Is More

REXSTORE was accustomed to its robust Oracle Forms interface and was loath to give up any of its conveniences. The central tension in converting a fat client interface to a thin web client is the relative lack of client program logic. Fat clients can respond instantly when invalid data is entered. Information can be cached on the client or partially hidden within multi-column scrolling lists. Unless there is a considerable investment in javascript, the web page equivalent of a fat client form appears to be less friendly. The user fills out the entire form and wait for their request to be processed by the Web application server. Even if you implement data entry validations in javascript so that errors are trapped on the client, you still have to repeat the validations on the server to be safe.

Here are the major trade-offs we made in order to deploy simple HTML web pages:

• Instead of client-side logic to trap a data entry error the moment it occurs, we perform validations on the server. If errors are detected, error messages are displayed next to the offending text boxes.
• Instead of a multi-column scrolling list supported by Oracle forms, we display all grid rows on the page and rely on the web page scroll bar to manage hidden rows.

The debate about how to preserve fat client ease-of-use in our web pages came to a head over the multi-column scrolling list provided by Oracle Forms. RECSTORE wanted the records already selected to be partially hidden so that the user would not have to scroll the web page to see previous selections. Furthermore, the selected records grid required a checkbox column to make it easy to remove records. Unfortunately, standard web page controls are encoded in HTML and the only scolling list facilities that HTML provides is the select tag and frames. Select tags are only useful for menu selections because they only support one value per row and no embedded controls such as checkboxes.

To get a scrolling list that does support multiple columns and controls on each row, a web page has to download and install a program that will be executed on the client when the web page is loaded. Such web page programs are typically implemented as either ActiveX Controls or Java applets. An ActiveX control is a Windows COM component that is precompiled to machine code. Therefore, it will only work on PCs that run Windows and support the machine code. OS updates can cause COM components to fail. Java applets promise to run everywhere but don't. The Java applet we use in Staffschedule.com failed on some Macs and had to be modified to support Windows XP. Such problems can cause unexpected and expensive maintenance efforts because it is so time consuming to replicate the problem.

We considered the following alternatives for getting scroll bars inside the page:

• Support scroll-bar like behaviour on the server. The page size remains fixed but the user must wait for the page to refresh to see hidden rows. This would mean that the user would have to wait 1-3 seconds each time they scroll.
• Rewrite the application using .NET Forms and .NET remoting. .NET remoting offers all the flexibility of a client-side program with single-source deployment on the server. The only catch is that you need to install the .NET Framework on every PC. And .NET Windows Forms use an entirely different set of GUI controls than .NET Web Forms. So, the presentation layer would have to be re-written.

Whenever your application relies on compiled, client-side code you are getting away from one of the biggest web application benefits: zero client setup. In the end, RECSTORE decided that less is more and decided to live with vanilla HTML web pages and the browser window scroll bar. They were pleasantly surprised with the beta test results:

• DeliverExpress Web Edition installed quickly on the test server.
• All five beta test sites accepted the new interface. The consensus was that it is intuitive and easy to use.