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) Design
The 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.
New Technologies
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.
NoSQL Databases
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.
Tablets
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.
I really enjoyed reading this -- it's a refreshing perspective. Nice to see pragmatic, modern technology techniques discussed in a HIT context.
I especially enjoyed the nod to NoSQL databases. In my years with medical record systems, I've come to the same conclusion. The contortions you need to make to force semistructured medical record data into relational tables is nuts. NoSQL provides a very promising way forward: indexed semistructured document storage seems like a really good fit for medical records data. Has anybody heard of one of these databases used in production for an EMR?
I loved your comment "There are many ways to display more information". I refer interested readers to the life-changing essay "Magic Ink" by Bret Victor for what this could mean: http://worrydream.com/MagicInk/
One additional wrinkle I'd like to point out with UI design. Modern task-driven (or, as my HMI expert likes to say "information space analysis-driven") UI design is key, as you point out.
With vertical market software like EMRs, you end up in a "long tail" situation: 80% of the tasks and workflows are shared, and 20% are not, but those "special" 20% are critical to each user. There are many kinds of physicians and related care providers, and many types and sizes of care settings. A specialist in a large clinic environment with medical students has different workflows than a general practitioner in a small clinic with just a nurse and a receptionist out front.
These various workflows result in different data fields being captured, different requisition workflows, etc.
It is important to capture the commonalities of all of these clinics (it's true that users tend to think that their workflows are more unique than they are in practice), that covers off the 80% use cases and workflows. The remaining 20% use cases tend to be specialized.
The four ways I know to resolve this are: (1) limiting your market to a small subset of the market, (2) lowest common denominator, which makes your product a lot less appealing, (3) being everything for everyone, which ends up with a crazily complex UI, or (4) allowing customization or specialization for private workflows.
I prefer (4), although I could probably be convinced that (3) with a really good UI designer combined with some limitations of market could be pulled off.
Entertainingly, financial apps (like in insurance companies) have this same issue. In practice, these kinds of institutions tend to have IT staff that can custom write or otherwise customize their software. EMR software has different economics: the typical clinic can't afford to get software customized (although this approach is indeed possible, if you've got the cash or skillset).
Excellent article, thank you very much! I look forward to reading the next part!
-Shawn Vincent.
--
VP R&D, MD Practice Software LP
Posted by: Shawn Vincent | October 16, 2012 at 06:45 PM