Short Link: http://bit.ly/90cGhY
I predict:
Future extensible clinical groupware will coordinate delivery of EHR functionality to teams of users by combining modular components with executable process models whose usability (effectiveness, efficiency, and user satisfaction) will be systematically improved using business process management techniques.
Let’s break this long and complicated sentence into parts, understand them, and then understand the prediction as a whole.
- Future extensible clinical groupware
- will coordinate delivery of EHR functionality to teams of users
- by combining modular components
- with executable process models
- whose usability (effectiveness, efficiency, and user satisfaction)
- will be systematically improved
- using business process management techniques.
I’ll cover these topics (though in a different order) and important relationships among them.
Usability: Effectiveness, Efficiency, and User Satisfaction
The International Organization for Standardization definition of usability is frequently invoked:
“[T]he extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” (my emphasis, ISO 9241)
Great definition…but it just seems so, well, “-ish.” Clinical groupware needs a less abstract definition of usability that is more direct about groupware’s unique usability issues (see the sixth, seventh, eighth, ninth, and tenth quotes from my Clinical Groupware…Key Ideas post). How about: Clinical groupware usability is…
“The extent to which clinical groupware can be used by specified teams of users to coordinate activity and achieve specified collections of goals with overall effectiveness, efficiency and satisfaction in specified contexts of use.”
This definition of clinical groupware usability is consistent with the ISO definition, just more specialized in ways to make it practically relevant to clinical groupware usability. In either definition, notice the tuple: (specified users, specified goals, specified contexts). We will return to it in a later section.
That said, current discussions of EMR/EHR usability are shallow in two ways.
The first sense in which current discussions of usability are “shallow” I address in The Cognitive Science Behind EMR Usability Checklists. Usability checklists are the tip of the cognitive science iceberg. The rest of the iceberg is “deep” usability. UI/UX (user interface/user experience) expert Steve Krug suggests , how does one cite a tweet anyway? [Update!]) taking an intro to cognitive science course. I agree.
But this post is about the second sense in which most usability discussion is shallow. I distinguish between shallow and deep EMR usability (inspired by an imperfect analogy to ). In fact, thinking about extensible EMRs using modular components requires thinking about deep usability. Consider the following quote about usability:
“Usability is often considered only important for developing user interfaces. But the user interface is only the surface of many interdependent components, each with their own features that make them more or less usable. As a result, the overall usability of a system is actually the aggregate of how well individual components that make up the system work together.” (my emphasis, Designing Healthcare Solutions with Microsoft BizTalk Server 2004)
Discussions about EMR user interfaces are about shallow usability (that is, about the surface or “skin” of an EMR). Deep usability is about the usability of individual components (seen and unseen) and how all those usabilities add up to total EMR system combined usability. In clinical groupware, deep usability spans time, space, content (multi-specialty), individual differences (potentially complementary, love the idea of team of experts versus expert team, especially the aviation and crew management connection, see my post EMR Workflow System Usability–Roots in Aviation Human Factors), group dynamics, organizational structure, and culture in ways that prevent use of traditional usability assessment methods.
Executable Process Models
Modules and components will not be enough to achieve deep EMR usability, unless one of those modules is an executable process model. This executable process model will likely be a workflow engine executing workflow or process definitions (also called “workplans” in some systems).
Otherwise we will just be stuck with another version of the traditional clickity-clickity-click-click-click, hunt-and-peck EHR that most physicians hate because they don’t want to be workflow engines–which is what I think most mean when they say they don’t want to be data entry clerks. Physicians (especially pediatricians, who run the lowest margin, highest volume businesses of any specialty) need the EHR workflow engine equivalent of a hyper-competent operating room nurse who automatically hands you the right data entry or order entry tool at the right time and place in the patient encounter.
In fact, that is the question: who or what is the workflow engine? If the answer is “who”, this is bad, because “who” is a person, a potentially expensive professional who should not be wasting their time doing what could be done more quickly, more consistently, and less expensively. If the answer is “what”, this is good, because “what” is a much less expensive inanimate object, the computer. If the computer can perform activities that don’t require a physician’s time and helps coordinate activities that do, then physicians will likely embrace clinical groupware and EMRs that include clinical groupware functionality.
Six years ago I attended the Health Summit held in Washington DC in 2004. I was the only representative from an EMR vendor serving small to medium size primary care clinics at the time (I checked the attendee list). Then Secretary Tommy Thomson, assembled assistant secretaries, and blue ribbon panelists laid out plans for a National Health Information Network. (Here’s an archived news report). Much discussion was devoted to the need to subsidize EMRs because of their effects of physician workflow and productivity. At the end of the conference folks lined up behind the aisle microphone to address the meeting. Finally, a white haired man, who identified himself as a solo family medicine physician, got the microphone:
“I don’t care if you give it to me free and then bribe me to use it, if it slows me down I won’t!”
Amen! (If anyone can point me to an archived transcript of the public comments I’d appreciate it.)
Business Process Management
Business Process Management is a “process optimization process.” On this blog . Consistent with an extensible-EMR-via-modular-component approach, BPM functionality is also provided by a set of modules (called a BPM suite) that can be used with process-aware information systems to achieve four categories of benefits. Combining EMR/EHR with BPM technology contributes to well understood, consistently executed, adaptively resilient, and systematically improvable clinical and administrative workflow,
- modeling and simulating all interaction patterns between physicians and other clinical and non-clinical staff, systems, and EMR components to create shared understanding about how to optimize care coordination processes and results; ( “well understood” )
- coordinating and managing the handoff of patient care tasks across organizational boundaries; ( “consistently executed” )
- providing real-time feedback to physicians and other care coordinators about care-in-progress to support patient care process adjustments; ( “adaptively resilient” )
- monitoring care coordination outcomes to performance targets, and continuously refining and adjusting care coordination process flows and rules. ( “systematically improvable” )
These four categories of BPM contribution to healthcare roughly mirror my own 2005 five part list of contributions of workflow automation to EMR usability: naturalness, consistency, relevance, supportiveness, and flexibility. I didn’t know as much then about business process management as I do now, but I think my past self’s intuitions were spot on (thank you future self, you’re welcome past self).
[TABLE=4]
Systematically comparing the 2005 column to the 2010 column would be a great post, especially since the five items on the left were motivated by usability concerns, not categories of BPM functionality. I’ll put a tickler in my ideas-for-future-posts.txt file.
Systematically Improved
However, I do want to address importance of flexible workflow to systematically improvable workflow.
- If workflow is not flexible, then it cannot be changed (without relying on a c# or Java programmer—no offense intended, since I am both myself).
- If workflow cannot be changed then it cannot be improved.
- If workflow cannot be improved then effectiveness, efficiency, and user satisfaction with workflow cannot increase.
- If effectiveness, efficiency, and user satisfaction cannot increase then higher levels of “deep” EMR usability can be achieved.
- Q.E.D.
Let’s address just one of these dimensions of deep EMR usability: EMR workflow efficiency. In 2005 I wrote about a BPM technique called process mining (called that by analogy to data mining):
“Workflow management systems generate tremendous amounts of time-stamped sequential data as a by-product of execution of process definitions by workflow engines. By analogy to data mining, analysis of such data (typically collected in log files) is called workflow or process mining [10]. Process mining can discover new and useful process definitions, compare process definitions to what users are really doing, and optimize existing process definitions—all of which can be used to improve ambulatory workflow.” ([10] reference: van der Aalst W and Weijters A. Process Mining: A Research Agenda. Computers in Industry 2004, 53(3):231-244.)
Process mining is an excellent example of BPM being a “process optimization process.” However, much of the best BPM academic and industrial research has occurred and been presented across the pond (both the little one and the big one). (Similarly, the first published reference to “Clinical Groupware” appears in Clemensen, Larsen, and Bardram’s 2004 Developing Pervasive e-health for Moving Experts from Hospital to Home. Simon Larson’s kind response to my emailed questions indicates that what we call clinical groupware appears to be part of a larger set of European research and industry initiatives called “pervasive healthcare.” Sounds like a future post to me.) The United States is a remarkable generator of new information technologies, from the large high tech companies to the university spin-offs to inventors who start in a garage. However, in this case the healthcare IT industry may have to look not just outside healthcare, but outside the US as well.
Coordinated Delivery of EHR Functionality to Teams of Users
I’ve dealt with this topic at length in three previous posts:
- Clinical Groupware: A Definition
- Clinical Groupware, Care Coordination, and EMR Workflow Systems: Key Ideas
- Ten Years Ago, Dallas HIMSS: Landmark Presentation on Modular EMR Workflow Groupware
However, so this section can stand on its own (hyperlinks on printed hardcopy don’t work—yet) I’ll include a definition of clinical groupware:
“Intentional care team processes and procedures pertaining to the observation and treatment of patients plus the tools designed to support and facilitate the care team’s work.”
An earlier version of the prediction beginning (and ending) this post included the phrase “delivery of traditional EHR functionality.”
“Traditional EHR” is a popular term these days—to apply to your competitors at least (see my Mirror, Mirror, On the Wall, Which EMR is Least Traditional of All?). This section is not about traditional EHRs, but rather the functionality traditionally provided. I like the eight category list provided in 2003 in Key Capabilities of an Electronic Health Record System: Letter Report to the Institute of Medicine. Feel free to review. (Disclaimer: I helped Dr. Jeff Cooper write his 2003 HIMSS Davies Award winning application based on these eight categories.)
I removed “traditional” from my prediction about the future of clinical groupware because we will see new and decidedly untraditional EHR functionality delivered and coordinated by clinical groupware.
Modular Components
An EHR workflow management system is the workflow management system used to generate a specialty-specific EMR workflow system (see EMR Workflow Systems for further explanation). It is a platform for launching and managing EMR components just as an operating system is a platform for launching and managing user applications and software services. Both are “an agreement that the platform provider [gives] to the software developer that logic code will interpret consistently.”
(http://en.wikipedia.org/wiki/Computing_platform)
EMR workflow systems are extensible by virtue of being generated by EHR workflow management systems. Extensibility “means the system is designed to include hooks and mechanisms for expanding/enhancing the system with new capabilities without having to make major changes to the system infrastructure.”
(http://en.wikipedia.org/wiki/Extensibility)
An EMR “software extension is a computer program designed to be incorporated into another piece of software in order to enhance, or extend, the functionalities of the latter. On its own, the program is not useful or functional.”
(http://en.wikipedia.org/wiki/Computing_platform)
EHR software extensions are components. Generically, a component “is any smaller, self-contained part of a larger entity.” However, I like even better (due to its early medical informatics context) Berkowicz, Barnett, and Chueh’s definition:
“A component is an encapsulated functional element that can be used as a building block in application construction. Components can be reused if the format of the data upon which they operate is fully specified, and if a consistent environment for application.” (1998, Component Architecture For Web Based EMR Applications).
As long as a component adheres to the EHR workflow platform API (application programming interface), it can be incorporated into a process definition and executed. It doesn’t matter who created the component, the EHR platform vendor or a third-party source. Super users can add installed components to EHR workflow management system process definitions without being .NET programmers.
Components need configuration to behave usefully. You may already be familiar with application configuration files (XML and otherwise). A configuration object is a collection of declarative data that determines component and platform behavior in response to particular environmental inputs (from users and other sources). Configuration objects, stored as fields in tables, can be exported and imported to share EHR customizations.
Finally, EHR workflow management system modules are collections of related components, and configuration data that determine component behavior to accomplish specific sets of logically related goals useful to specific classes of users (such as pediatricians, allergists, and obstetricians) in response to specific environmental inputs. “Module” is based on analogy to circuit boards on which are assembled electrical components such as resistors, diodes, and transistors (as I used to etch my own boards, I’m glad to find that hobbyists still do).
From Wiki (my contributions are strategically placed ellipses and emboldened bracketed annotations):
“[M]odules represent a separation of concerns [such as the concerns of pediatricians versus allergists versus obstetricians], and improve maintainability by enforcing logical boundaries between components….Modules are typically incorporated into the program through interfaces [EHR platform component APIs]. A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are detectable by other modules. The implementation contains the working code that corresponds to the elements declared in the interface…One of the key aspects behind Modular Programming is the ability to separate concerns such that none or few modules depends upon other modules of the system. To have as few dependencies as possible is of utmost importance. Another key aspect is that when creating a Modular System, instead of creating a Monolithic application [traditional EHRs, in the views of many] where the smallest piece is the whole application itself, one creates several smaller Modules which, when composed together, will create the whole system….This makes Modularized Designed systems, if done right, far more reusable [by developers, and, increasingly, users too] than a traditional Monolithic design since all or many of these Modules may be reused in other projects. In addition it also makes breaking projects up into several smaller projects through divide and conquer easier….Modularized Programming is a loosely defined concept. With no official definition, it is the programming technique of composing loosely coupled modules, and forming them together into a complete system.” (http://en.wikipedia.org/wiki/Modular_programming)
While a definition of clinical groupware should not invoke software modules, components, and sharable content and behavior (proprietary and monolithic groupware and clinical groupware applications surely exist), they are nonetheless important aspects of progressive modern software architecture and development practice. They make it easier to create what needs to be created, clinical groupware or otherwise. Since clinical groupware should rely on the best software development architecture available, clinical groupware should indeed rely on modules and components and sharable content and behavior.
Future Extensible Clinical Groupware
Note the parallels between my descriptions of EMR usability and EMR extensibility.
[TABLE=5]
EMR extensibility is the other side of the deep EMR usability coin. Deep EMR usability requires (1) combining the right components, collected into the right executable bundles (modules), achieving the right sets of logically related goals, for the right classes of expected users, in response to correctly predicted environmental inputs *and then* (2) application of a “process optimization process” to systematically improve overall usability dimensions of effectiveness, efficiency, and user satisfaction. The first step gets you in the ball park; the second step hits it out. The only practical means by which this will be achieved will be if modular EMR/EHR/clinical groupware systems also include within their very technological nature the ability to systematically change internal processes and workflows to better meet set objectives while working in typical environments.
For these and other reasons I predict:
Future extensible clinical groupware will coordinate delivery of EHR functionality to teams of users by combining modular components with executable process models whose usability (effectiveness, efficiency, and user satisfaction) will be systematically improved using business process management techniques.
https://wareflo.com/kickbiking 
Sorry Harper, you just don’t have enough hair to exhibit the dog halo effect.
Mediocre halo effect, but a magnificent shadow!
Good candidate, face stage left please. 
Thank you! We’ll let you know.
Hey! There’s a lion loose in the park. Doesn’t anyone notice?
Now that’s what I’m talking about! Perfect 10!
I know how you feel Harper. I don’t want to leave either.
