SaaS EHRs, MVC, Flexibility and Innovation

by Jerome Carter on April 1, 2013 · 0 comments

Around the time of HIMSS each year, I usually reach out to EHR vendors to learn about new products and updates.  This year my attention was focused on cloud-based systems and how they are evolving.   Much of my interest in SaaS EHR systems stems from a desire to better understand how software designs enable innovations and flexibility—the underlying theme of EHR Science.   Flexible EHR systems that allow for experimentation with components/functions/feature sets encourage tinkering, and by extension, innovation.  Flexibility can be introduced at two levels–that of the software’s internal design and through the system’s global architecture.  SaaS systems can easily take advantage of both.

It’s a given that flexible systems are loosely-coupled and highly-cohesive, and both are properties that can exist at both internal and global architectural levels. The model-view-controller (MVC) design pattern, which is being used increasingly for web applications, embodies these properties.

Internal Design Flexibility
The MVC pattern is not new.  It has been around since the early days of the Smalltalk programming environment in the 1980s.   It was created to deal with user interface requirements for highly-interactive, graphical applications.   MVC really caught on big-time after its debut in 2005 as part of the Rails platform for the Ruby programming language.  Since then, Rails-like frameworks have been created for nearly all programming languages, and MVC has become a de facto standard for web applications.

As the name implies, MVC applications consist of three types of components. Models hold data and business logic, controllers contain application logic, and views provide presentation capabilities.   How the components should interact is, to a certain degree, a matter of debate.  Some insist that controllers always stand between models and views; others, that models update views.

I find the debate amusing because design patterns, defined as “a solution to a problem in context,” ** must be adapted to the problem at-hand.  Because, while everyone might have a shared idea of what a design pattern is at the conceptual level, it still has to be rendered in code by an individual according to his/her understanding.  Therefore, ultimately, what is built comes from the mind of the developer.  In the diagram below, controllers sit between models and views, and models do not communicate with views.

MVC1

An alternate version is illustrated in this diagram taken from the Wikipedia MVC article.
MVC-Process

Framework implementations vary in their support for one arrangement over the other.   Personally, I try to avoid philosophical debates about technical matters.    What really matters is not the specific flavor of MVC a framework implements, but how well the actual code adheres to key design principlesand performs in the real world.

One important feature of the MVC pattern is that applications built using it contain multiple models, views, and controllers.  This permits an additional layer of separation between application logic and components.  In an EHR system, there might be sets of models, views and controllers for each major function area. For example, there might be MVC sets for demographics, medications, labs, notes, preventive care, etc. as seen below.

MVC 2

The beauty of this arrangement is that the functional units of an MVC EHR can be built, tested and updated independently of one another.   Breaking an application up into small pieces in which each piece has a very specific function leads to software that is highly-cohesive and loosely-coupled.

Aside from the benefits seen during development and upgrades, using MVC provides advantages in dealing with the ever-evolving EHR market.   Views are very loosely connected to controllers and are independent of one another.   Mobile computing is an example of how this confers a competitive advantage.   Say that you have an MVC EHR that was initially designed for viewing through a desktop browser.   A mobile-compatible view could be designed, tested and added to the system without ever disturbing the desktop views that are already in place. The models would be oblivious to any changes in the views.   This is exactly the type of flexibility that supports innovation.

Architectural-level Flexibility
As mentioned above, coupling and cohesion principles apply to global architecture as much as they do to internal software design.  At the architectural level, access to services via APIs imparts useful flexibility to applications.    Communicating through APIs enables one application to make use of capabilities found in another.  For example, if a provider organization implements an EHR after having had a disease registry in place for years, one could pass information between the two using an API.  Doing so might allow the EHR to add a new patient to the registry or query the registry for a specific set of patients.  The same approach could be used for linking an EHR to a drug database to perform drug interaction checks.  Communicating systems need not be near each other; the drug database could be anywhere in the world.

My talks with vendors were informative.  SaaS  EHR vendors are embracing MVC, APIs, and related technologies.  It remains to be seen whether or not  these architectural/design choices will lead to more innovative products or even provide a competitive advantage.  In any case,  I was impressed by what I saw and  look forward to seeing what next year brings.
____________________________

** Freeman E, Freeman E, Bates B, Sierra K, Robson E. Head First Design Patterns. O’Reilly Media, 2004

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: