EHR Systems are complex entities, and that complexity has downstream effects that are increasingly noticeable in the form of user complaints. EHR system complexity is a direct result of having to address so many competing requirements. We expect a lot of EHR systems. We expect them to meet domain-specific requirements–HIPAA, MU, legal record, workflow, decision support—while staying current with the latest technologies and platforms. Obviously, these expectations have to be addressed through design and architecture choices. However, change, which is constant, can make any architecture/design problematic in short order.
The innate complexity of EHRs is not likely to diminish; in fact, it most likely will increase. Therefore, a key challenge for EHR designers is building systems that can both manage complexity and evolve gracefully. The problem, of course, is how to design for the future without having any idea of what the future holds.
The All-in-one EHR Model
Let’s look at an EHR system from the standpoint of major functional areas/properties (at least this is how I look at them). At the lowest level, we have functional properties that are common to any complex software system. In many architecture references, these are referred to as cross-cutting concerns.
- Error management
- Communications (including data exchange)
- Data Stores
The next level up encompasses clinically-relevant concepts that are rendered in computational form:
- Medication List
- Problem List
- Test Results
The top level consists of functions that interact with or rely on those found in one or more lower levels.
- User Interface
- Problem-specific Workflows (disease-based management protocols)
- Decision Support
- Quality Reporting
- Configuration Management
Using Modularity to Manage Complexity
As a basic design principle, modularity works, whether for cars or for software. Modularity, when properly executed, allows systems to be built from components that have been designed, tested and optimized for specific uses. As such, modularity supports and enhances scalability (adding more users or computing units) and extensibility (adding more features/functions) without significant rewrites of existing programming code. Another way of saying this is modularity allows for loosely-coupled and highly cohesive systems (see Coupling and Cohesion: A View of Software Design from the Inside Out).
Breaking Complex Systems into Functional Units
Modularity can be seen in many types of software systems. Plug-ins for content management systems and apps for smartphones are two good examples, and both are pertinent for EHR designers. The use of application programming interfaces (APIs) in web applications allows for modular applications that interact over the Internet. (An API is simply a specification that describes how to interact with a software component.) This is not new; SOAP and remote procedure calls (RPCs) have been around for a while. What has me excited is the degree of openness increasingly exhibited by companies who make their homes on the web. Twitter, Instagram, Facebook, Salesforce, LinkedIn and the like are publishing APIs that provide developers with access to data and/or services. This is new.
If clinical software vendors routinely provided public APIs for use by outside developers, consider what it would mean for EHR designers. Instead of building every functional EHR subcomponent in-house, some functionality could be accessed via an API from an outside vendor. This would lower development time and costs while making systems more adaptable. The diagram below depicts an EHR system that connects to a workflow engine, disease repository, and billing system through standard APIs provided by the products’ sellers.
My past encounters with web services and APIs were always in the context of SOAP messages. SOAP is a web service protocol that relies on XML. SOAP-based web services work, and I am all for them. However, recent evaluations of NoSQL data stores introduced me to RESTful APIs/web services and JSON-based data exchange (see Exchanging Data with JSON), and having looked at Representational State Transfer (REST), I’m hooked. REST is a cleaner, simpler, and more elegant way of moving information between two applications.
REST, unlike remote procedure calls or SOAP, is not a protocol, it is an architectural style. Since it is a type of architecture and not a protocol, it is up to the designer of a RESTful service to adhere to the principles (i.e., this allows for variations in implementation quality and encourages—shall we say–debates). REST, being based on the HTTP protocol, is ideal for Internet-based interactions.
Access to resources via REST-based (RESTful) APIs is handled using URLs, which are familiar to everyone who has used a browser. As a result, RESTful APIs are usually quite readable (take a peek at LinkedIn’s). REST was proposed in the PhD dissertation of Roy Fielding in 2000, and it has been slowly gaining ground since. According to Dr. Fielding, the REST architecture has the following properties:
|Client/Server Architectural style||Servers house information that clients seek to access. Clients could be browsers, other servers, web applications, etc. Using a C/S architecture promotes scalability and extensibility.|
|Stateless||The server does not keep track of session state; the client does. In addition, all requests for data must contain all the information needed to satisfy the request. This decreases server processing and resource use, which also improves scalability|
|Client-side cached data||Data are labeled in terms of whether they can be safely cached. If so, network use is lowered because repeat requests may be fulfilled from the client cache instead of another server request.|
|Uniform interface||All requests are made through a standard interface|
|Layered||Components within a REST architecture are layered, permitting separation of concerns and flexibility in overall system design|
Table 1 – Key REST Properties
When combined, the above properties yield an architecture that is ideal for large-scale web applications.
In the final installment of this post, we will look at the practical implications of REST architecture. See you then.