By JEROME CARTER, MD

Increasingly, research is becoming available that reveals the weaknesses and strengths of health information technologies.   Everything from infusion pumps to EHR systems have been subjected to analysis.  The new flow of information is wonderful to behold because it wasn’t too long ago that little in the way of actionable HIT research was available.

Research on usability, interoperability, and patient safety can lead to better clinical care software. From these studies, we are learning important information about workflow disruptions, clinician information needs, user interface issues, errors, etc. Now that we have more research, how do we use it to produce better products, to address the needs of HIT users?

Who actually builds HIT products?  Software engineers. They turn feature requests and requirements lists into working software making software engineers a rate-limiting component of any process leading to new products. Therefore, at some point, research must make it into the hands of software engineers who then covert it into objects, methods, APIs, and data store specifications. 

The call for safer, more usable systems is, in essence, a call for systems that do not cause workflow disruptions, that present information when needed, that do not have burdensome data entry requirements, and that allow for easy interactions between care team members.   The call is for clinical care assistants, not data repositories.   The differences between data repositories and clinical care assistants are deep and architectural.  The former are data-centric and are optimized for data entry and retrieval; the latter are process-centric and are optimized for task support.   This architectural divide has significant consequences for software development practices.   

Data-centric systems tend to rely on forms as major user interface components, and understandably so.  Visual Basic was a huge boon to form-based development. Using Visual Basic for data-centric software development is a straightforward process.   Once requirements and a data model exist, creating data entry screens is a no-brainer.  VB will actually generate basic forms for you.    Of course, using VB does not preclude process-aware development.  My point is that VB and similar form/screen-focused development tools are optimized for form-based development. 

Process-centric systems use the same data as data-centric systems, plus some.   Process-aware systems must have a means of tracking processes, the information they require, and  process state (i.e., what steps are currently executing).   As such, process-aware systems are generally more complex architecturally.  If new HIT products are going to answer the calls for software that assists, then new software designs are needed, and those designs will be more complex than those of current systems. 

Clinical Work Models
In order to build process-aware systems we need a means of representing clinical processes in a computable form.  We also need analysts, architects, and engineers who understand clinical processes well enough to convert user requests, requirements specifications and such into working code. Finally, we need a representation format that can be shared among those who create the software and those who will use the software produced.  There is no current representation format that serves all of these purposes well. 

All software contains algorithms.  So, a question that must be asked at some point in HIT development is how does clinical software differ from other software.  Do care-specific algorithms exist?  Are there patterns in clinical work that, if not unique to clinical care, are fundamental to patient care?   While informaticists may be primarily responsible for answering these questions, software engineers will have primary responsibility for rendering them in software.

Workflow Technology is a Must

Any non-trivial workflow consists of a complex series of steps that may require branching logic and data for choosing a path.  Interactions–people-people and people-technology–must also be accounted for when computerizing workflows.  Now, imagine every vendor trying to build a proprietary workflow capability inside their systems.  How many hours would be wasted by such an effort?   Workflow engine technology has been around for a while now.  It makes much more sense for HIT developers to explore current workflow tech than to try to roll their own.  And here again, we see that software engineers must assure the viability of the final implementation.

Education is Key
If a switch to process-aware systems that assist clinicians is to occur, then we must make it easy for software engineers to become familiar with workflow technology, clinical work, and  clinical process representations.   There is little available now that fills this need.   Current efforts aimed at software engineers seem to focus on large, multi-billion dollar companies.  Yet, every call for more innovation insists that small companies and individuals should be tapped.  What mechanisms exist for small shops or curious software engineers (or anyone interested in clinical care software design) to learn about clinical processes or clinical work in the context of software development?  There is no “Principles and Practices of Clinical Software Design” book.  Seminars at national conferences tend to present research that reflects that seen in journals and not practical topics such as “Object models and methods for problem list management.”   More code-level discussions of clinical software are needed.    

I do not believe that clinical care software design is something simple that can be learned in a few months.  While it might be possible to create an SQL database and forms to populate it with clinical data in a few months, a process-aware clinical care assistant with an information model and interoperability takes much more thought.   We need degree programs and targeted continuing education to create a cadre of software engineers who are specialists in clinical software. 

A Seat at the Table
Discussions of clinical software tend to focus on the user interface and surface features, not the detailed design (i.e., code); yet, code is the source of all capabilities.  Those given the responsibility for creating software must be included in software analyses because they can uncover the specific connections between the problems experienced by clinicians and the code from which those problems arise.  Too often, there are multiple layers between those who are writing code and presiding over the architecture and those using the software.  Progress requires that software engineers be seated at the table with clinicians, human factors specialists, informaticists, and policymakers when clinical software issues are discussed.

Building the next generation of clinical care systems requires throwing off the old paradigm of data repository + graphical front-end to adopt a new one based on processes.   Without software engineers who are conversant in all aspects of clinical software design, discussions will remain nothing more than talk.  Let’s make sure they have an equal seat at the table.

Dr. Jerome Carter is an informaticist and CEO of Informatics Squared, Inc.  He writes the EHR Science Blog and recently created Clinical Workflow Center, a website dedicated to clinical workflow education and practice.