Design Patterns: The New Black

by Jerome Carter on July 16, 2012 · 2 comments

Regardless of the domain, a reasonable approach to solving a problem begins by determining if a solution already exists.    In other words, don’t reinvent the wheel.  In software development, this idea is an accepted way of doing business as evidenced by code libraries, algorithm manuals, and things such as user interface components.    Software design patterns (SDPs) are yet another addition to the developer’s toolkit.   However, SDPs are not pre-baked code that can be inserted into a project. Rather, they are more akin to best practices for addressing specific types of recurring software coding needs.

The term “design patterns” originates from a book published in 1994, Design Patterns: Elements of Reusable Object-Oriented Software. Through their work, the authors, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, referred to as the Gang of Four (GoF), made a significant contribution toward helping developers learn how to apply object-oriented programming (OOP) principles in designing real-world software.   To say that it grabbed everyone’s attention would be an understatement.   There has been only one edition of the book, and yet, 18 years later, it is still a top-seller on Amazon.

The book contains programming wisdom such as suggesting that inheritance, a foundational OOP feature, should be used less frequently in deference to composition (using interfaces to provide capability) when creating objects and building software.  Anyone who has gotten lost trying to follow a clever programmer’s endless inheritance tree can appreciate this advice.

Perhaps more philosophical and theoretical than practical (at least to me), Design Patterns: Elements of Reusable Object-Oriented Software, can be challenging for someone with no formal training in computer science or object-oriented design.   Fortunately, there is a great introductory text for the rest of us, Head First Design Patterns. Published in 2004, it not only makes patterns accessible, it also makes the mysteries of object-oriented programming less, well… mysterious.  If you are interested in modern software design techniques, read this book (read the GoF book later, once your horizons have significantly expanded).  So, what does this have to do with EHRs?

As mentioned before, design patterns are a best practices approach to solving common software development issues. The GoF book lists more than 20 patterns. One of those, the Observer pattern,  offers a good example of how design patterns can aid in EHR design.

Drug-drug interaction checks are a common safety feature of EHRs. An interaction check occurs when a new medication is added to a patient’s medication list.  The addition of the new medication is an event that triggers a series of actions in the EHR, which may happen as follows:

  1. Add Medication (an event)
  2. Initiate Task – Interaction Check
    1. Check to see if patient has other medications
      1. i.      If no other medications–end procedure
      2. ii.      If additional medications exist
        1. Check for drug-drug interaction
          1. If no interaction found–end procedure
          2. If interaction found–give alert

Observe that the addition of a new medication is the event that triggers the “Interaction Check” task. Below is a pseudocode example of an add new medication procedure.

PROCEDURE Add_New_Medication
BEGIN
   Select drug from formulary
   /* Do Interaction Check */
        IF No Interaction
             Add Drug to Medication_List
        ELSE
             Alert “Interaction Present!”
        END
END

Now, consider what happens when clinicians using the EHR decide they want to add allergy checks whenever a new medication is added to a patient’s list.   The obvious thing to do is to go back to the Add_New_Medication procedure and add an “Allergy Check” task as shown below.

PROCEDURE Add_New_Medication
BEGIN
   Select drug from formulary
   /* Do Interaction Check */
       IF No Interaction
           /* Do Allergy Check */
               IF No Allergy
                   Add Drug to Medication_List
               ELSE
                   Alert “Patient is Allergic!”
               END
      ELSE
           Alert “Interaction Present!”
      END
END

From a programming standpoint, adding the Allergy Check task is not that difficult. However, it raises an important software development issue (i.e., every time a new feature is desired, programmers have to alter the existing programming code).   The problem is that every time working code is altered, there is a chance that errors will be introduced, which can be costly and frustrating. Since users commonly ask for additional features, there are many opportunities to introduce errors.   Ideally, one should be able to add new features to software systems without disturbing working, error-free code that is already in place.   This is where modular software design comes into play.

Now let’s take a look at the Observer pattern. The Observer pattern provides a way to manage events and notifications in a modular manner.  In a way, it is used to “broadcast” an event.  Look at the Observer diagram.  The Subject is the broadcasting object and the Interaction Check and Allergy Check objects are the Observers (listeners).

In our object-oriented model, the Add_Medication event causes the Subject to notify the Observers that a new medication is being added to the patient’s medication list.  Once alerted, the Interaction Check and Allergy Check tasks execute.  The Interaction Check and Allergy Check tasks are no longer a part of the Add_New_Medication procedure. Instead, they are independent objects that communicate via messages.   We’ve gone modular!

Think about what this means for adding or upgrading software features.   Say, for example, we want to add the ability to determine whether a patient has a diagnosis, such as chronic renal failure, that can alter a drug’s clearance.  In the pre-observer pattern software, we would have to alter the Add_New_Medication procedure. Now, using the Observer pattern, we simply create a new Diagnosis Check observer object  and register it to receive broadcasts of the Add_Medication event.   New functionality has been added without disturbing working code and potentially introducing errors!

Design patterns are a key element of modern software design. They are not a panacea, but they do provide developers with a means of addressing common software design challenges without reinventing the wheel.

 

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 2 comments… read them below or add one }

Scott Bower May 7, 2014 at 10:10 AM

Brilliant. It never occurred to me to use software design patterns to describe UX patterns in healthcare, and, frame alert based systems design.

Reply

Jerome Carter May 7, 2014 at 10:55 AM

The concept of patterns is proving to be more useful than I imagined when first learning about them. Stepping back from the trees offers new perspectives on many aspects of software design. Health care is replete with patterns.

Reply

Previous post:

Next post: