Bidding The Hierarchical Database Adieu
Colorado Peach Orchard, August 2012. No better peach can be found than straight off the tree.
Jeff Atwood over at the Stack Exchange recently posted his thoughts on the differences between Flat or Threaded style web discussion forums. To save you the trouble of clicking, a flat discussion thread would be one where the comments are linear, a threaded style would be where they are nested, or hierarchical. How is this related to Health Informatics, you might ask? Well, let me show you the number one issue he has with the threaded structure:
1. It’s a tree
Poems about trees are indeed lovely, as Joyce Kilmer promised us, but data of any kind represented as a tree…isn’t. Rigid hierarchy is generally not how the human mind works, and the strict parent-child relationship it enforces is particularly terrible for fluid human group discussion. Browsing a tree is complicated, because you have to constantly think about what level you’re at, what’s expanded, what’s collapsed…there’s always this looming existential crisis of ‘where the heck am I?’ Discussion trees force me to spend too much time mentally managing that two-dimensional tree more than the underlying discussion.
So what else do we know in healthcare is stored and processed in the hierarchical tree formation? Certain EHRs and other Health Information Management systems of course. Not all are set up like this, no, but major players like Epic and Meditech are. This type of structure was originally sought out because of the more efficient way it could be processed by a computer back in the 60s and 70s. Well…that was the past. Note the specific comment above about how the “strict parent-child relationship is particularly terrible for fluid human group discussion.” Yet, isn’t that what the progress note is supposed to be? A fluid human group discussion about the patient’s current health status, the causes behind the patient’s problems, and the plan of attack? Sadly, I think 99% of EHR vendors today miss that point. They’re so focused on making it a documentation tool that they neglect the fact that it’s really supposed to be a communication tool. Interestingly, one of the major complaints I always hear from physicians is that they always have to take a minute to think about where they are at and where they need to go in the system to get the information they need.
I’ve mentioned before that EHRs should be designed to reduce the mental burden of the practitioner, not increase it. Therefore, it would be wise for anyone developing a healthcare-related software system to avoid the “traditional” industry standard of utilizing technology with a hierarchical structure. If I have to hear an EHR vendor talk about how “robust” their product is because it is hierarchically structured, I might have to throw a dictionary in their face (the hard cover kind, not a link to dictionary.com which wouldn’t be as attention grabbing). Robust means that at best the product won’t break and we all know EHRs break pretty easily regardless of structure.
So let’s bid everything that has come from MUMPS or anything similar, adieu. Let’s think about how humans communicate information and build a system around that. Facebook, Tumblr, and Twitter are successful not because they allow people to document their lives, but because they allow them to share and communicate with others. Documentation is just something that was part of the process.
Aaron Berdofe, MHI - Health Informatics 