Change Defence: Designing For Tomorrow

While I have spent most of the past 33 years in health IT, I have had several interspersed ‘sabbaticals’ into other business areas, which included ship building, financial management, public utilities, accounting and stock brokerage. These have helped to balance my perspectives as to the relevance and impact of IT on these industries, as well as my main interest, public health.

Achieving something really tangible in healthcare with software is a tough gig. The environment is unlike anything else in business enterprise. One of the standout differences between healthcare software versus business applications is the likelihood of change. Healthcare software applications are regularly subjected to functional inadequacy and/or redundancy due to the ongoing evolution and change to treatment regimes. One day there is a new type of diagnostic procedure to accommodate, the next there is a new standard definition affecting the breakdown of an entity status. It is impractical and fiscally inefficient to be running off for programming changes every time one of these events occur.

Over the past ten years I have been involved with several developments where attempts were made to take an approach with software design that could accommodate change without resort to constant programming changes. The advent of object-oriented programming with event-driven operating systems has made this much easier to achieve.

Let’s look at a very simple example. A very common type of data item is a selection from a list, most commonly provided by a pull-down combo box. A situation can arise where there is a need to subdivide an existing item into two separate items. In this case it is likely to be impossible to convert the existing combined value into the two new component values. How do you move from one need to another in this case? Firstly, ensure that all lookup tables have a boolean column to denote ‘redundancy’. For the sake of our example we will call our column “deprecated”. Our existing list item Alpha has become redundant so we mark the deprecated column as true. New items Beta and Gamma are added appropriately to the lookup list with deprecated value of “false”.

When the application runs, the query to populate the list control is qualified by “where deprecated=false”, so that Alpha will not appear, but Beta and Gamma will. This prevents item Alpha being selected inappropriately. But what do we do if we wish to view a screen of data where Alpha was selected as the value at that time? Remember, with most combo boxes and especially web page pulldown controls, you cannot even display an item if it is not in the list.

To get item Alpha to display, we have to put the item in the list. Easy - in the code that synchronises the data value to the control, you raise an event when the data value cannot be matched to any item in the list. I call mine a “syncFailure” event, which also returns and exposes the value of the foreign key that caused the event to be raised. The event code then reads the database lookup table for an entry to match the key argument, and if found, adds the details to the bottom of the existing selection list, then calls another synchronise method on the list. This causes item Alpha to appear selected in the list and allows the user to change the value to any other, including the new Beta and Gamma items, as well as allows re-selection of item Alpha. However, once another value is chosen and the record written to the database, item Alpha would no longer appear the next time the parent data record was revisited.

From personal experience this simple approach has been worth it’s weight in gold. However, it is necessary to use a development tool that supports object-oriented methodologies, eliminating several popular current products. I have been involved with other approaches to the same problem, including the qualification of date ranges to qualify lookup values. The complexity of the implementation tended to detract from the result.

From a philosophical perspective, I have always found that there is more than one way to solve a problem or a challenge (the “skinning of cats” comes to mind here). I am always attracted to the simplest solution, as this is usually the most robust and reliable method. Many of my colleagues seem to differ in opinion, preferring to use the most complex methodology to prove how ‘smart’ computers can be.

Another strategy for “change defence” is to re-examine the definition of an application’s entities. Too often there is undue emphasis placed on today. Let us look at a second example of how to improve this situation.

The result of a specific diagnostic test is an integral component of any treatment regime application. The most common scenario is where the name of the specific test is put into a lookup table entry (e.g. blood test, pap smear, biopsy) and matching results for each test are created. However, every time either a new test is required or a structural change to an existing one is needed (i.e. two result values provided instead of a single value), some amount of programming is required to implement the change. But if the definition of the diagnostic test is taken to an abstract level, the need for reprogramming can be eliminated.

This is done by simply defining that any diagnostic test comprises a procedure, an “origin” (i.e. site or source) and one-to-many results where each result can be either a number, a list pick, an image, text (short or memo), letter, 3 part boolean value (true/false/neither, yes/no/neither, positive/negative/neither), date, or time value. For procedures where the “origin” is obvious (e.g. blood test) then an origin of ‘Implied’ can be used.

It is not difficult to write a module for an application that allows the user to define any new test, or modify an existing one, with the latter including the ability to remove a result (with deletion of existing data), add or insert a new result, or change the sequence and other result attributes.

Other obvious data attributes can be added to suit. For example, number range checking, future date inhibition, use of “common” lists across many tests, mandatory flags, default values, etc - you can go ballistic! This is not too difficult really, and once done you have a design that can be applied to pathology tests, imaging, ultrasound, investigatory surgery, etc.

In my own domain, I have also extended this approach to drug administration, treatment “events” and prognostic factors. In practice, it has empowered the application user and removed the need for expensive time delaying reprogramming. Most business processes in a hospital environment can be broken down to an abstract level - including numbering and identification systems - which moves us to our third and last example of “change defence”.

When a patient receives treatment at a hospital, whether as an inpatient or an outpatient, there is a need to record numerous identification numbers. There are two obvious primary numbers (i.e. Unit Record and Medicare) but there can be several others, such as referring hospital UR number, health fund membership number, DVA number, trial number, etc. By taking a simple abstracted approach, you can define functionality that will allow any formal numbering system to be created and used, even extending its use into patient search functionality. The simple abstracted elements are just “number value” (alphanumeric), “category” and “organisation” (if not implied).

When developing healthcare software in the 1980s, it was always a case of replacing a manual system with a computerised form, rather like shelling peas. There was nothing like the complications that are encountered when a project is formed to migrate an application to a replacement. One large dataset that I am involved with is currently using its third form of application software, and that is now over 8 years old and in need of urgent upgrade. Computer systems are often “designed” without any design consideration that they in turn will become redundant within a few years.

It has an unusual influence on one’s approach if you design a new or updated application with a view that what you are creating will in turn be obsolete within a relatively short space of time. And isn’t that the ultimate change?

Michael Murfitt has been practising as a Health IT professional since 1974. He has been running his own business, Thunderbird Software, since 1998 and works in Ocean Grove, Victoria.

Posted in Australian eHealth

You need to log in to post comments. If you don't have a Pulse+IT website account, click here to subscribe.

Sign up for Pulse+IT eNewsletters

Sign up for Pulse+IT website access

For more information, click here.