Part 2 of a three-part series of articles written by a
veteran software developer who has worked extensively in the EMR
industry. The article series is published on his behalf. His comments
are directed broadly at the industry. Read Part 1 Read Part 3
There are three key areas that I see as the most problematic:
- Poor User Interface (UI) Design
- Lack of Quality Assurance
- New Technologies
Poor User Interface (UI) DesignThe development of our current EMR systems usually started with selection of an SQL database, creation of the tables and links between the tables, then development of the client system. This resulted in clients with user interfaces that were heavily influenced by the database schema, not by how the user would want to see the data. (Define the Client)
One can see the result of this development approach in the most vital part of an EMR — the patient chart. In clinics that are still paper based, a patient’s chart is a collection of documents, lab reports, clinical notes, etc. that are usually sorted chronologically. The doctor can quickly flip through the pages to gain an understanding the patient’s history and current conditions. In EMR systems the client chart is often a jumble of data grids in separate tabs or windows. This results in lab results on one page, procedures on another, consults on a third, etc. Even in EMR systems with a Cumulative Patient Profile (CPP) the CPP tends to look like a bunch of grids cut and pasted together. The data is organized the way a programmer would organize it, not the way a doctor would.
In designing user interfaces I use a technique call Task Analysis. With this method you break down each task a user would perform into individual steps, and then mock-up the steps one window at time. For this I like to use old fashioned pen and paper. I draw each window on a page of paper and walk through a task one page at a time. Drawing the windows by hand is a good way to judge the complexity of the information the user is looking at. If it takes more than a few seconds to draw the window, then it is too complex and you probably have items in the window that are irrelevant to the task being performed. If you find there are too many windows, they may need to be combined into one so they can be executed in a single step. I repeat this for each task that has been identified. Once completed, I take the stack of pages to a user and have them walk through each of the tasks one page at a time. This technique is also a good way to analyze an existing user interface, drawing the pages and walking through the steps. Simplicity is key. However, most EMR systems I have looked at fail in this regard.
Years ago, when designing software for Win 95 and XP and 640×480 screens, data density was a big deal. We used to calculate data density by measuring the area taken up by data compared to the entire screen. Having multiple windows open at the same time was a problem with Win 95 and XP, so you tried to fit as much data as possible into small screens. These days the opposite is true. With Windows 7 and large wide monitors, good UI design means an uncluttered display and sparse data. This makes it easy for a user to comprehend at a glance what is on the screen. There are many ways to display more information; most current EMRs still have densely populated windows. This is the result of designing around database tables.
Lack of Quality Assurance
Over 10 years ago the term “Test Driven Development” was coined. This referred to the concept of writing tests to check the functionality of each section of code as you developed it. This forced developers to separate code into small, testable chunks or Units and the tests were called Unit tests. Frameworks were developed to create and run Unit Tests for almost every programming language. It was a huge leap forward in improving both the quality of code and the pace of development. Test Driven development and Unit testing quickly became standard practice, or so I thought until I started working for EMR companies. The companies I worked for did some Unit testing; however, it was not standard practice and the amount of code tested was limited.
Unit testing has its limits, programmers only write tests to make sure their code does what it is supposed to do. By inserting X, one tests in order to produce Y. This is called Positive testing. An equally useful form is Negative testing. If one inserts Z, or anything other than X, what is produced? Programmers regularly perform Positive Unit tests, but rarely Negative tests.
Another way of testing applications is running automated test scripts on the actual application as a whole. This is called QA testing. It predates Unit testing and requires special tools. It also requires a different type of programmer. QA testing needs to include both Positive and Negative testing. In the latter case the QA person creates tests to see what happens if the user does something unexpected or that they should not be allowed to do. QA tests also make sure that the application meets design specifications. More importantly for EMR systems the QA tests check that data entered in one part of the system appears correctly in another. This is important to ensure that updated patient health data appears correctly in other areas of the EMR.
A robust system cannot be developed without strong quality assurance and good QA is as intensive as programing the system being tested. Mature software companies have requirements for the size of the QA team. Microsoft has a ratio of 1:1 in that there is one QA position for every programer in the development team. Other companies have different ratios, but the important thing is that these ratios are maintained. As the development team grows, the QA team should also grow.
None of the EMR companies I worked for had set requirements for the size of the QA team. The QA teams were small and with each release, they found themselves scrambling to adjust their test suite for all the changes the developers had made. This left gaps in the test coverage and releases often went out without the QA process completed. The quality of the product is directly related to the amount of QA that is performed prior to release. This is important in critical healthcare applications such as EMRs.
Some will argue that EMR systems should stick with established technologies and that the risk of using new technologies is too high. The difference between “New” and “Established” in the high tech industry has been shrinking for years and now is almost nonexistent. As one well regarded development manager told his team designing a new system: “Use things that are going to work great in two years.” Canadian EMR companies tend to use older technologies.
About 12 years ago, the industry started to realize that SQL databases had their limitations and alternate database systems were re-introduced and new database systems developed. This was dubbed the NoSQL movement and today NoSQL databases are behind many of the websites you use every day. It is not unusual for a site to use more than one type of database.
NoSQL databases store data in a number of different formats, each suited to a different type of data. One category of NoSQL database is the document database. These databases do not have a fixed schema like an SQL database, but are dynamic with the schema being generated as documents are added to the database.
The SQL database model is well developed and understood, but EMR systems deal with a number of different types of data. Managing client lists, scheduling appointments and billing operations are things that SQL database are well suited for, but this is just a small component of an EMR system. The client chart is made up of completely different types of data. Most of this data comes in via EDT interfaces as HL7 files. EMR companies often have teams working on just the EDT code in order to shoehorn this data into a SQL database. Document databases are well suited to EMR chart data as most digital data is in HL7 format, which at its heart is a document format. However, I don’t know of a single EMR system that uses anything other than a SQL database.
There is almost a daily growth in the number of tablets computers. The next generation of doctors will have gone through training with tablets in their lab coats and will be expecting to use them in clinical practice settings. While some EMR vendors do have “tablet” applications, I was unable to get much information about them and I am skeptical of how useful they really are. The tasks you would want to manage on a tablet are not the same tasks you would on a desktop. Even when completing the same task on a tablet, the user interface for a tablet needs to be completely different. Tablets come with built in cameras for still images, video and audio recording, which opens up many new ways of capturing data during an encounter. A good EMR client on a tablet should be designed and developed separately from the desktop or web app version. There are also security considerations that need to be considered with tablet applications. Tablets are easily lost or stolen. Can you remotely wipe all data from your tablet that has gone missing? There are security systems that provide this function as well as other security functions needed on tablets with access to sensitive data, but I am unaware of EMR vendors that have made use of them and I would not use one that was not secured by one of these systems.
The next article will focus on the evolution of the EMR market in Canada and a vision of the path forward for EMRs from a developer’s perspective.