Special Topics in Vendor-Specific Systems: System and Database
Architectures Used in Commercial EHRs
Audio Transcript
Slide 1: Systems and Database Architectures Used in Commercial
Electronic Health Records
In this unit we will discuss system and database architectures used in
commercial electronic health records (EHRs).
Healthcare organizations may have different requirements for an EHR.
Understanding the hardware and software architectures of various commercial
EHRs may help organizational planning and decision-making for selecting,
installing, and using an electronic health record.
Slide 2: Lecture Objectives
In this unit, you will learn about:
1. System and database architectures used in commercial EHRs and the need
for EHRs to exchange information Pharmacy, Laboratory and other systems.
2. We will discuss differences between thick and thin-client EHR deployments,
review operating systems and databases used by EHRs, including how database
architecture can impact performance and extensibility.
3. Lastly, we will also briefly discuss security, privacy, auditing and performance
monitoring.
Slide 3: What is an EHR?
Let’s begin by defining precisely what is meant by the term “Electronic Health
Record”, or EHR.
Generally speaking, an EHR is a software program providing a systematic
collection of electronic health information about individual patients. EHRs
exchange information with other clinical systems, such as those containing
Pharmacy, Laboratory, Radiology, or other information. EHRs store patient
health information in some type of database.
Slide 4: Sample EHR Architecture
This graphic shows a sample EHR architectural diagram. Client terminals
(typically desktop computers) communicate with the EHR Application Server.
Data are stored to and retrieved from a database, sometimes referred to as a
Clinical Data Repository. Ancillary systems, such as those containing pharmacy,
laboratory, or radiology information, exchange data with the EHR.
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
System and Database Architectures Used in Commercial EHRs
This material (Comp14_Unit5) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
1
Slide 5: EHR Hardware Platform
Sometimes in Electronic Health Record installations, we use the term “Back-end”
to refer to the Database server and Application server. The “Front-end” of the
system is where clinician interaction occurs—a desktop computer or perhaps a
mobile device.
Slide 6: EHR Hardware Platform (cont.)
A thick-client (or fat-client) application processes most or all of its business logic
on local computing resources (e.g., the desktop PC). Thick-client applications
provide rich functionality independent of a central server.
In contrast, a thin-client application relies on its server to process most or all of its
business logic.
Web-based applications are blurring the lines between thick-and-thin clients. For
example, Google Docs provides much of the functionality of thick-client office
software via the World Wide Web.
A common technology employed by EHR vendors to provide a thick-client user
experience without having to deploy EHR software to hundreds or thousands of
individual computers is the Citrix Independent Computing Architecture (ICA). ICA
is a proprietary protocol for an application server system that permits ordinary
Windows applications to be run on a suitable Windows server, and for any
supported client to gain access to those applications.
Slide 7: Example EHR Hardware Configuration
This graphic shows an example EHR Hardware Configuration that uses the Citrix
ICA protocol. Each production application server may host 20 or more application
sessions (in other words, user sessions of the EHR). A large EHR deployment
(for example, most hospitals or ambulatory practice facilities with more than 100
providers) will typically include test, development, and training environments.
Slide 8: EHR Software Platform
An EHR Software platform consists of the Operating system used by the backend servers and front-end clients, as well as the database software employed by
the system. Most EHRs use servers that run
Unix or Windows Server software. Front-end clients may use Windows, Linux,
and MacOS for desktop computers, or Blackberry, iPhone, or Android software
for mobile devices. Common database software used by EHRs includes IBM
DB2, Oracle, Microsoft SQL Server and InterSystems Caché.
Slide 9: Databases
Most EHR databases rely on either a Relational or Hierarchical data model.
Relational databases include IBM DB2, Oracle, Microsoft SQL Server; while
Caché is the most common hierarchical database.
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
System and Database Architectures Used in Commercial EHRs
This material (Comp14_Unit5) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
2
Slide 10: Relational Databases
A relational database is a collection of data items organized as a set of formallydescribed tables from which data can be accessed or reassembled in many
different ways without having to reorganize the database tables.
The standard user and application program interface to a relational database is
the structured query language, or SQL.
Slide 11: Hypothetical Relational Database Model
This graphic shows a hypothetical Relational Database Model. Separate tables
exist for Patient, Physician, and Inpatient Encounter. The tables can be joined
together to create SQL queries.
Slide 12: Hierarchical Databases
Unlike a relational database, hierarchical databases organize data into a tree-like
structure. The structure allows repeating information using parent/child
relationships. Each parent can have many children, but each child only has one
parent. In hierarchical databases, all attributes of a specific record are listed
under an entity type.
Slide 13: Hypothetical Hierarchical Database Model
This graphic shows a hypothetical Hierarchical Database Model for a collection of
patients. The tree-like structure is evident.
Slide 14: Vendor Comparison System Architectures
We will present a brief summary of vendor-specific System Architectures for
selected inpatient and ambulatory EHRs. EHR products evolve rapidly, so it is
important to seek up-to-date information from the vendors themselves or from
reliable sources. Two possible sources of EHR information are the Online
Buyer’s Guide published by the Health Information Management Systems
Society (HIMSS, pronounced “himz”), and the resources available from KLAS
(pronounced “class”) Research, LLC.
Slide 15: HIMSS Online Buyer’s Guide
This screen shows an example of the HIMSS Online Buyer’s Guide
Slide 16: KLAS Research LLC.
This screen shows the “Vendor Search” function on the KLAS Research website.
Slide 17: Epic
Epic offers an integrated suite of health care software centered around a
hierarchical MUMPS/Caché database. MUMPS [pronounced “mumps”] (which is
an acronym for Massachusetts General Hospital Utility Multi-Programming
System), or alternatively M, is a programming language created in the late
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
System and Database Architectures Used in Commercial EHRs
This material (Comp14_Unit5) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
3
1960s, originally for use in the healthcare industry. MUMPS is designed for multiuser database-driven applications. While it’s not especially common outside of
healthcare, it predates C and most other popular languages in current usage.
Slide 18: Epic
InterSystems Caché is a database management system from InterSystems
Corporation. It provides object and SQL access to the database, as well as direct
manipulation of Caché’s underlying data structures. Intersystems claims that
Caché is the world’s fastest object database. It runs on a variety of operating
systems.
Slide 19: Epic
This slide shows the technical specifications for the Epic EHR provided by the
vendor to KLAS. Be sure to check the website for up-to-date information.
Slide 20: Allscripts
The acute care EHR offering from Allscripts, Sunrise Clinical Manager, uses SQL
Server as its underlying database, and operates as a thick-client, Windows
Forms application. The application was developed using Microsoft .NET
technologies and is typically deployed via Citrix ICA.
Slide 21: Allscripts
This slide show Eclipsys’ (Allscripts) technical specifications reported to KLAS.
Slide 22: Quadramed
This slide shows Quadramed CPR’s technical specifications reported to KLAS.
Slide 23: NextGen EMR
This slide shows NextGen EMR’s technical specifications reported to KLAS.
Slide 24: eClinicalWorks EHR (ECW)
eClinicalWorks is a privately held company offering a single integrated system for
practice management, EHR, billing, and a personal health record. eClinicalWorks
is based on Java, MySQL, and Apache Tomcat. The expense of deployment is
$10,000 + equipment, although the Primary Care Information Project (PCIP)
enables physicians in New York City to obtain the software for $4,000 +
equipment.
Slide 25: Monitoring the EHR
Once an EHR has been installed, it is important to monitor its function and use.
Three areas of monitoring are:
Security and Privacy
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
System and Database Architectures Used in Commercial EHRs
This material (Comp14_Unit5) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
4
System Use, and
Performance
Slide 26: Security and Privacy
The Health Insurance Portability and Accountability Act of 1996 (HIPAA,
pronounced “hippa”) contains rules on privacy and security, forcing health care
organizations to address many facets of electronic health record security. The
HIPAA Security Rule specifies administrative, physical, and technical safeguards
that must be employed by covered entities, which include individuals or
organizations that provide healthcare services. Specifically, the Security Rule is
designed to assure the confidentiality, integrity, and availability of electronic
protected health information. The HIPAA Privacy Rule provides federal
protections for personal health information held by covered entities and gives
patients an array of rights with respect to that information.
Slide 27: Security and Privacy
The Health Information Technology for Economic and Clinical Health (HITECH)
Act, enacted as part of the American Recovery and Reinvestment Act of 2009
strengthened the HIPAA Privacy, Security, and Enforcement Rules. For example,
certain aspects of the Privacy and Security Rules now apply to the business
associates of covered entities. Moreover, individuals’ rights to access their
information are expanded, and the enforcement provisions of HIPAA have been
strengthened and expanded.
Slide 28: Recommended EHR Security Features
The American Health Information Management Association Workgroup on
Security of Personal Health Information recommends the following EHR security
features:
Role-based security that restricts access to predefined categories of patients,
encounters, and documents based on the access a user needs to perform his or
her job;
VIP status indicators that restrict access to information from specially identified
patients to those individuals with permission;
The ability to assign an alias to a patient or encounter to mask patient identity;
The ability to restrict patients from physicians who are not the “physician of
record” (e.g., attending, admitting, surgeon, and consulting);
The ability to block access to a specific progress note or lab result;
The ability to track versioning or mask sensitive entries for release of information;
and
Detailed audit logs that record data access and data entry, with the ability to
generate reports of actions performed by a specific user or for a specific patient.
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
System and Database Architectures Used in Commercial EHRs
This material (Comp14_Unit5) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
5
Slide 29: System Use
Most EHRs provide basic auditing capabilities that allow administrators to see
who viewed or edited information in a patient’s chart. Audit logs are beneficial for
enhancing information security, but if architected correctly, they can also provide
data about system use.
For example, a healthcare organization may want to answer questions such as:
How many clinicians are using the system?
What are peak times of system usage?
And, how much time do clinicians spend on specific tasks, such as note-writing?
Slide 30: Who Read Whose Notes?
This graphic depicts various relationships between different types of clinical
users to provide insight into reading and writing of clinical notes. This diagram
was generated using EHR audit logs, and lets us identify, for example, that more
nurses read resident physician notes than vice versa.
Slide 31: System Performance
EHRs should provide tools to assess system performance, including monitoring
database growth and response time and assessing memory and processor
utilization, especially during times of peak EHR use.
Equally important is tracking the actual experience of application users, which
can be done by measuring delays during screen transitions. It is always a good
practice to provide a mechanism for users to send feedback to system
administrators about performance issues.
Slide 32: System Performance Monitoring Example
This screen in this slide is a prototype dashboard for real-time monitoring of EHR
system use and performance. It was designed for the Allscripts Sunrise EHR by
a third-party software vendor, Corman Technologies, Inc. Dashboards like this
are helpful for administrators seeking to understand system use and can help IT
personnel track down performance issues.
Slide 33: Conclusion
This concludes the module on system and database architectures used in
commercial EHRs. In this module we began by defining EHRs, and EHR
hardware and software. Then we discussed relational databases and
hypothetical relational database model. We review various vendor systems,
along with system performance. Finally, we examined the Health Information
Technology for Economic and Clinical Health (HITECH) Act, enacted as part of
the American Recovery and Reinvestment Act of 2009 strengthened the HIPAA
Privacy, Security, and Enforcement Rules.
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
System and Database Architectures Used in Commercial EHRs
This material (Comp14_Unit5) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
6
Slide 34: References
No Audio
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
System and Database Architectures Used in Commercial EHRs
This material (Comp14_Unit5) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
7