This summer was very productive. I was able to jump into the human factors literature, test out BPM suites, and get into the nuances of Swift (more than a few). All the while, I have been reflecting on designing clinical software. The really great thing is I have been able to experiment to my heart’s content. Blog posts over the last few months reflect my evolving understanding of what it takes to design process-aware software for clinicians. The feedback from these posts has been so positive that I decided to put together a mini-curriculum for those who wish to develop a deeper understanding of clinical software design. Here, then, are my suggested readings.
Until this summer, I had not read much of the HF literature. My only exposure had been via usability research and reports. Cognitive task analysis (CTA) was the main focus area with task analysis (hierarchical and GOMS) tossed into the mix. I read portions of a cognitive engineering book, which I did not find all that helpful – too many words and few concrete ideas. Cognitive task analysis proved to be the most helpful. Concept maps were not something I had made use of before, at least not formally. Probably everyone who interviews people about what they do has used some form of Critical Decision Method or Think Aloud to gather information. Having read CTA, I think I will be a better interviewer when trying to figure out processes and information needs. GOMS sounds great in theory, but I found it cumbersome. Hierarchal task analysis is just common sense.
Usability Book of Knowledge
Creating a compelling UI is difficult. One has to deal with visual aspects (colors, fonts, etc.) as well as information needs. Current EHR systems have a sort of fire hose approach – put everything in the UI and let the user figure out what they need. Essentially, this is like making all pages of a paper chart visible simultaneously. It’s noisy.
When I think back to how I practiced, I rarely used the chart as anything other than a reference. I read over the chart before entering the exam room. Rarely, did I look at it while interacting with a patient unless I needed to check dates or old test results. Findings from patient interactions were jotted down using a template I designed; notes were dictated later. Being forced to write notes while the patient was present would have thrown off my entire schedule. Thinking about my practice habits made me consider what type of interaction I would want with an electronic system. A crowded display of patient data would not have fit my needs, especially if I had to write notes while seeing patients.
Chart accesses are only a small part of any clinical care process. Clinicians spend more time thinking and interacting than reading chart data. Therefore, it doesn’t make sense for a screen of patient data to be the main design precept for a clinician’s user interface. After jotting down a set of things I would have wanted in an interface, I decided that, as when using paper charts, I only wanted patient data displays at specific times (and then only a specific elements). Such a display would be controlled by me and offer support for what I wanted to do — what I am calling a “buffet” approach to UI content.
When it comes to clinical UI design, not much has been available until recently. The general design book by Tidwell provides useful insights. Overall, there are more complaints about UIs than specifics on how to fix them. The buffet idea might have legs…
There are a lot of computer programming books. Most are not that good. Too many explain elementary concepts in detail and never show how to move into advanced territory. Knowing a programming language and knowing how to design software are two very different things. Good programmers are not necessarily good designers.
I got a fresh look at software design challenges this summer while trying to help someone learn object-oriented analysis and design. We went through the entire design process from vague idea to use cases to requirements to class diagrams and basic UI mockup. The design process is a cycle. Fully specifying even a simple app proved to be impossible – no waterfall method here! Use cases had to be revisited and new ones added, which, of course, rippled through the project. Without a doubt, the Head First OOA&D book has proven to be the most helpful. It explains the process and rationale behind OOA&D well without too many unnecessary words. (Many software architecture books are wordy and conceptual). In this regard, SWEBOK is a breath of fresh air. It is concise and points to other resources for in-depth discussions.
Workflow materials are all over the map. While everyone uses a mixture of interviews, observations, and document reviews to discover and analyze processes, modeling techniques differ. Software designers express processes with use cases and activity diagrams. BPM analysts use BPMN or YAWL. Flowcharts and swim lanes are used by everyone else.
Clinical workflow analysis and modeling can be useful in numerous situations. The two main groupings are:
- Efficiency, safety, and productivity of clinical processes (how a clinical entity functions in delivering care)
- Decision support
- Patient safety
- Practice efficiency
- Data quality
- Care quality
- Clinician interaction with clinical software
- Software design
The analytical methods used and the types of models created are determined by the problem being studied. It would be nice to have clinical adaptations of BPMN or YAWL to use as modeling tools.
Articles & Reports
Ko RKL. A computer scientist’s introductory guide to business process management (BPM). Crossroads 15, 4, Article 4 (June 2009). A gentle intro to BPM.
Examining the Relationship Between Health IT and Ambulatory Care Workflow Redesign – Read this report to get a feel for how HF experts approach workflow analysis.
For some reason, data quality gets less press than data exchange or interoperability. This strikes me as odd since exchanging data without knowing its quality seems like a bad idea. EHR systems have propriety data schema and there are no independent measures of data quality. As a result, there is no choice but to accept the vendors’ word that their systems maintain quality. Still, data quality is a topic worthy of study for anyone designing clinical systems.
Articles & Reports
Weiskopf NG, Weng C. Methods and dimensions of electronic health record data quality assessment: enabling reuse for clinical research. J Am Med Inform Assoc. 2013 Jan 1;20(1):144-51.
Institute of Medicine
Digital Data Improvement Priorities for Continuous Learning in Health and Health Care – Workshop Summary, 2012
Data breaches have become so common in health care that they are no longer really news. There are plenty of standards for data security, but every breach suggests those standards are being ignored. If you plan to create clinical software, please take security seriously.
National Institute of Standards and Technology
NIST Cybersecurity Practice Guide, Special Publication 1800-1: Securing Electronic Health Records on Mobile Devices, 2015
Cyber Security Framework Draft, 2013
Technical Safeguards (HIPAA)
Mobile systems are becoming more powerful. As expected, 64-bit chips are gaining ground on laptops performance wise. As things stand, 2017 seems like the year that mobile chips will come into their own. Apple’s forthcoming iPad Pro already seems quite capable. While chips are important, the remaining infrastructure pieces are also keeping pace.
After developing with PHP for the web, mobile feels like going back to desktop development. It’s possible to write for specific hardware capabilities. I appreciate the fact that around 90% of iOS users upgrade to the latest version. Swift has enough quirks, especially in terminology, to be irritating at first. For example, Swift’s public, private, and internal access levels differ in meaning from C# and Java. What everyone else calls interfaces, Swift calls protocols. The behavior of constant structs, objects, and arrays can be confusing at times as well. Every Swift book I’ve looked at is basic, so I cannot recommend any as being great. For those with programming experience, Apple’s book plus a good Xcode book, might be all that is needed. For beginners, web-based tutorials are as good as any book I’ve read.
The growth in non-relational data stores is one of the most exciting recent information technology developments. Relational databases have influenced EHR system design as much as charts have. Fifteen years ago, relational systems were the only viable choice for clinical software, today that is no longer the case. Although document databases such as MongoDB, receive more attention, I find graph databases much more intriguing.
As the name implies, graph databases are based on graph theory, a branch of mathematics. As it turns out, the world is full of graphs. Workflows, ontologies, social networks, family trees, maps, and spread of infectious diseases can all be modeled as graphs and stored more efficiently in a graph database. Other than tradition, there is no reason that a clinical care system cannot use NoSQL data stores or make use of more than one data store. We now have more database tools than ever before; why not imagine beyond two-dimensional tables?
Well that’s it—a mini-curriculum for learning to design clinical software. No, I did not offer anything for interoperability or data exchange because there is plenty written about both topics and other informatics standards. Looking over this list, I can see the outline for a graduate level course. Clinical workflow analysis would be a separate course. Happy reading!