From Idea to System: A Story of Architecture and Design

The Idea
Drs. Jane Doe and John Smith are subspecialists with three practice locations in Western City, USA.   All of their patients are obtained via referrals. Unfortunately, they have not been able to find an EHR system that meets their needs, so they have decided to build one – SubspecialtyEHR.

The Development Process: Waterfall vs. Agile
All software starts with an idea.   Architectural and design principles are used by software engineers to turn ideas into systems.   While, there is a great deal of “art” involved in the process, experience has taught me that a few principles applied consistently can go a long way. (Please read Software Architecture and Design, First Steps if you need an introduction to basic concepts.)

No one disputes the big steps that occur in creating and deploying software: requirements, design, coding, testing/debugging, and implementation.  The controversy turns on how to do them.   The classic waterfall method assumes that each step happens in sequence, which in turn assumes that a system can be fully specified with all requirements known before coding starts.   This approach falls into the category of big design up front.  While it may work, it is not the best approach to use when building custom software because it doesn’t embrace continual feedback from the client.  Further, when feedback is frequent, the process bogs down.   Agile development, along with similar approaches, assumes from the outset that change is inevitable, and continual feedback is expected.

The term agile covers a lot of territory, from a set of software development practices to something akin to a religion.  In any case, the assumption underlying this approach is that requirements are difficult to know fully in advance, and that they often change.   (Meaningful use proves this point well.)

Gathering Requirements
Drs Doe and Smith have  a vision for SubspecialtyEHR; the next step is figuring out exactly what they have in mind.  User stories and use cases are two methods employed to determine what users want to do with their systems. User stories are favored by those in the agile camp.   They are short sentences that describe a goal the user wants to accomplish using the software (e.g. “ As a doctor, I would like to be able to view all recent abnormal labs for my patients.”).   User stories have test/acceptance cases associated with them that describe a software function (e.g., “Test case: When viewing results, abnormal values are highlighted in red.”).

Use cases are more detailed than user stories and contain scenarios.  A scenario is the series of steps a user performs when interacting with the software to reach a goal.  Ultimately, user stories and use cases have the same objective – defining how a user interacts with a system.

The key concept to keep in mind about agile development is that it emphasizes iteration—gather requirements, build, test, repeat.  Iterations are short (one month or less).   This approach quickly provides something for users to see and respond to.  Design flaws can be detected faster and earlier when using an iterative approach. This is the main reason developers moved away from the classic waterfall model to agile, rapid application development (RAD), and other iterative development methods.

Design vs. Architecture
The terms design and architecture are used differently in software engineering lingo as compared everyday conversation.   Non-developers tend to use the terms as synonyms that describe everything from how the system looks and acts to how it fits together.    Developers usually (nothing is 100%) use architecture to describe how the main components fit together to create a system.

A system’s architecture is a high-level view of its key components and their interactions (1,2).  Since architecture addresses components and their interactions, issues such as availability, response times, and security are architectural concerns. Architectures also come in various styles.  Everyone is familiar with client/server, which is the architectural style typical of of LAN-based and web-based applications.

SubspecialtyEHR has to provide access to three locations that use a combination of desktop and mobile clients.  Thus, the architecture must allow for remote access to a server, work with desktops and mobile devices, provide 24/7 access, be able to send data to referring clinicians, and provide security.

Using these constraints, a reasonable architecture might include a cloud-based data store; interface components suitable for desktops, tablets and smartphones; an interface to the local HIE; an interface to a third-party reporting engine, etc.   The key point to remember is that the architecture is a high-level, big-picture view of a system.

Design (referred as detailed design according to the IEEE Software Engineering Book of Knowledge (SWEBOK) generally covers the internals of the software; that is, the code that provides the needed features and functions.    Two of the most important design concepts are coupling and cohesion.   The design principles mentioned in Software Architecture and Design, First Steps are guidelines that lower coupling and increase cohesion.  Taken as a group, design principles promote software designs that are tolerant to change. Because, after all, that is how life works—change is a constant.

Software Design Patterns
Design patterns are solution templates for common types of programming problems.   They are the software version of not reinventing the wheel.    Learning designs patterns has been one of the most rewarding aspects of my recent studies.   (Read Design Patterns: The New Black for a more in-depth discussion.)

Minimal Viable Product
The minimal viable product (MVP) concept is simple–build a system that has the least number of features necessary to make it useful. Then iteratively add features and functions based on user needs and feedback.  This assures that no one spends years building systems that are partly obsolete by the time they are implemented.     For SubspecialtyEHR, the MVP might be ready in as few as 8-10 months and, perhaps, provide only basic functionality (demographics, problem and medications lists, one-way lab interface, simple progress note, remote access).  The beauty of this approach is that Drs.  Doe and Smith, along with their staff, will be able to determine exactly how their system performs and what features it offers.   This approach could be costly for a single practice if they had to start from scratch. However, if a good object-oriented, open source EHR framework were available (as opposed to a complete EHR), the costs incurred to add new functionality could be very reasonable.

A single post is, admittedly, is not the best medium for explaining the complexities of software development, architecture, and design.   Still, I hope this post, along with the links provided, helps to clarify what developers are doing and talking about.

1.       Microsoft Application Architecture Guide, 2nd Edition (2009).   Accessed Feb 15, 2013.

2.       Software Engineering Institute. What Is Software Architecture? Accessed Feb 15, 2013.


Leave a Reply

Your email address will not be published. Required fields are marked *