EHRs and Architectural Styles, Peeking Under the Hood

EHR buyers have a choice of three delivery formats: classic client/server (C/S) (i.e., local area network-based), application service provider (ASP), and software as a service (SaaS).  Knowledge of the actual differences between these options renders decision-making less sensitive to marketing ploys.  The best way to understand the differences is by looking at a few software architecture basics.

The Microsoft Application Architecture Guide, 2nd Edition describes several key software architectural styles divided into four categories.

Deployment Styles
Client/Server – Segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures.

N-Tier / 3-Tier
– Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.

Structural Styles
Layered Architecture – Partitions the concerns of the application into stacked groups (layers).

Object-Oriented – A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.

Component-Based Architecture – Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.

Communication Styles
Service-Oriented Architecture (SOA) – Refers to applications that expose and consume functionality as a service using contracts and messages.

Message Bus – An architecture style that prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other.

Domain Styles
Domain Driven Design – An object-oriented architectural style focused on modeling a business domain and defining business objects based on entities within the business domain.

Architectural styles are not mutually exclusive. In fact, applications usually combine several styles.

Now that you’ve had a mini-primer on architectural styles, let’s look at the EHR options.   First, all three options (classic C/S, ASP, SaaS) use the client/server architecture style—the first over a LAN, and the last two, over the internet.  Therefore, the term, “client/server”, lacks precision as a means of separating one option from another architecturally. (Being that this is the EHR Science blog, precision is important.)  Since both ASP and SaaS systems are accessed via the Internet, understanding how they differ also requires moving beyond terms such as web-based or internet-based.  Thus, we need a better way to describe the meaningful differences (no pun intended) between these formats.  A reasonable approach is to think of EHR delivery formats in terms of: 1) where the server is located, 2) who controls access to the server, and 3) how many users from different practices share the same application.

Classic Client/Server (C/S)
Server Location: practice site
Server Control: practice personnel
# Practices Sharing Application: 1

Once Windows NT was introduced in the 90s, it, along with the increasing availability of server-based relational database management systems, made it possible to create affordable EHRs for any size medical practice.  Many current EHR products hail from this era.  The EHR is installed at the practice site and the practice must pay, up-front, for hardware (computers, servers, printers, etc.), software licenses, and information technology (IT) support.   Classic client/server has the highest start-up costs of the three options.  The EHR is accessed over a local area network.

Application Service Provider (ASP)
Server Location: ASP data center
Server Control: ASP personnel
# Practices Sharing Application: 1

Maintaining a server can be expensive and time consuming.  In the ASP EHR model, the server is located at the ASP’s data center.  This arrangement lowers costs for server maintenance by lowering practices’ IT personnel needs.   If the EHR vendor acts as the ASP, this model will make EHR maintenance (e.g. updates, interfaces, bugs fixes, code sets, etc.) simpler, and possibly cheaper, as well.    Users access the EHR over the Internet. Payment models vary, but subscriptions are common.

Software as a Service (SaaS)
Server Location: SaaS data center
Server Control: SaaS personnel
# Practices Sharing Application: >1 (no predefined limit)

Software as a service is the newest option.   Regrettably, SaaS has fallen victim to marketing hype. However, using the NIST definition of SaaS easily clears matters up.   SaaS software is multi-tenant (i.e., multiple users share the same application).  This is a key factor that differentiates SaaS from ASP.  As with ASPs, EHR maintenance is simpler than with classic client/server software.  SaaS EHRs are subscription services, and possibly have the lowest up-front costs of the three models.

From the standpoint of software architecture and design, classic C/S applications written for use on a LAN often are very similar to their ASP cousins.  In fact, one can turn a classic C/S application into an ASP application in a series of well-defined steps.   However, SaaS (remember we at EHR Science use the NIST definition) applications are written to take advantage of cloud properties (see Cloud Computing 101). Turning classic C/S or ASP applications into true cloud applications usually requires some work.

My goal for this post has been two-fold: first, to clarify the differences between EHR delivery formats, and second, to provide a little more insight into how applications are constructed.  While it may seem somewhat technical, it is useful information.  Increasingly, I am noticing more instances in which what appear to be disagreements between developers/software engineers and clinicians (and even informaticists) over various aspects of clinical systems are actually misunderstandings due to the lack of a shared vocabulary.  If you wish to know more about software architecture and software engineering, I suggest the books mentioned in the post, Software Architecture and Design, First Steps.   Precision counts.



Leave a Reply

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