Well, 2014 is nearly over, and it is time to start looking ahead to what next year might bring. For me, 2014 has been a milestone year. When EHR Science began in 2011, I had three main goals: connect with other HIT developers, learn new technologies, and discover new approaches to designing EHR systems. Happily, I managed to achieve each of these goals plus a few that showed up along the way.
As of today, I have worked through two (and counting) discrete math books, made sense of design patterns, and managed to actually understand what Wil van der Aalst is talking about. As much as possible, I have shared my discoveries. Now, having completed my studies, it is time to start doing. So, in the tradition of my yearly December updates, here is what to expect from EHR Science in the coming year.
A theory of clinical systems
EHR systems are being assailed for usability and safety issues. The key issue is that they are not optimal for supporting clinical work. Simply tweaking a few things here and there in the user interface or agreeing on better interoperability standards alone cannot fix the problems identified in current EHR systems. Support for clinical work must be integral to system designs. We need a single framework that can precisely describe clinical work and be used for everything from optimizing a practice to designing software. Ideally, that framework should be mathematical.
For years, I have been looking for a model, framework, theory – anything really – that would make clinical software design more of a science and less of an art. Finally, I think I have something worth sharing. For the last few months, I have been working on getting the math notation right and reviewing related papers. Now, the question is how to share it. An academic article might be appropriate, but there is a lot more to explain than could fit in 4000-word article. Since there are no theoretical biomedical informatics journals, I am not sure where to submit a paper. I suppose an eBook is also a possibility. Suggestions??? (Of course, it could also be absolute nonsense…)
Mobile-first clinical apps
Reimagining requires liberating oneself from tradition. In the case of clinical software, this means letting go of desktop-first, LAN-first, and web-first designs. All of these remain viable platforms for deploying software, yet they lack features that exist on mobile systems. What is possible in terms of software features is significantly different from seven years ago. Workflow technology has matured, wireless speeds are fast — even over cellular networks — cloud storage and sound/video/sensor capabilities are good and rapidly evolving. Mobile-first means rethinking clinical software in terms of these new capabilities and from the standpoint of always having a 64-bit computer at hand.
Record/archive concepts have been the guiding design paradigm for most of the history of clinical software; why not try clinical productivity as a design goal?
Expect a few Swift/iOS programming posts as I try to free my mind from traditional clinical software design influences.
Math and clinical concepts
Two discrete math books… Yeah, there will be a few math posts.
Academic article reviews
The last AMIA symposium had a decent number of presentations on workflow and usability. Both topics are also appearing more frequently in academic journals. I have begun to keep a folder of articles that seem to be good for review and commentary. Should everything go as planned, article reviews will become more frequent. If so, they will be in addition to the regular Monday post. We’ll see…
NoSQL is not the enemy of relational
The number of NoSQL data stores is overwhelming. Wading through them takes patience and a willingness to endure cryptic installation instructions. Initially, I tried a few NoSQL systems because, well, that’s what programming geeks do. In many ways, getting a handle on NoSQL is similar to going mobile-first with software design—one has to step outside of tradition. For the last 30 years or so, relational has been the way to go, so everyone understands and reflexively thinks relational. Tradition dictates that everything be massaged (or pounded) to fit into two-dimensional tables. Until recently, there was no reason to challenge that way of thinking. Having tried MongoDB (documents), and to a lesser extent Neo4J (graphs), I am beginning to get a better feel for when and why one would choose them over a relational store.
Graph databases are interesting because they allow one to easily model networks/graphs. The world is full of graphs. For example, an infectious disease outbreak can easily be modeled as a graph of contacts and disease occurrences. This information could fit into a relational database, but fits more easily and more naturally into a graph database. Neo4J has been bumped twice from my post queue; I hope to rectify this.
My database explorations have not been limited to NoSQL. PostgreSQL has caught my eye as well. PostgreSQL is fast, mature, has tons of features, and it’s free. Intriguingly, it now has NoSQL-ish capabilities…
Everything is a workflow — everything
At some level, software selection/implementation, practice optimization, usability, safety, decision support, and many software design challenges are workflow issues. Problems and successes in each of these areas can be restated as either enhancements or disruptions to workflows. The centrality of workflow in understanding so many clinical informatics issues is overlooked, possibly because most workflow analyses focus predominantly on control-flow issues and ignore information flows and resource interactions.
Workflow analysis as a problem-solving tool and workflow technology will receive a lot more attention in 2015. Next week’s post will provide more detail on workflow plans.
I have enjoyed hearing from everyone. Keep the questions, suggestions, and tips coming!