Usable Clinical Groupware Requires Modular Components and Business Process Management

Short Link:

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.

  1. Future extensible clinical groupware
  2. will coordinate delivery of EHR functionality to teams of users
  3. by combining modular components
  4. with executable process models
  5. whose usability (effectiveness, efficiency, and user satisfaction)
  6. will be systematically improved
  7. 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, “singleware-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 (tweeted about here, 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 shallow versus deep models of medical reasoning). 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 I’ve written extensively about BPM in healthcare. 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,

  1. 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” )
  2. coordinating and managing the handoff of patient care tasks across organizational boundaries; ( “consistently executed” )
  3. providing real-time feedback to physicians and other care coordinators about care-in-progress to support patient care process adjustments; ( “adaptively resilient” )
  4. 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).


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:

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.”

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.”

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.” 

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.” (

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.


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.

Zowie! Tweets of the Week, February 28, 2010: HIMSS, Carnations, Visual Workflow, Pediatric EMR UI/UX

Tweeting Live from HIMSS, March 1-4, Atlanta: Pediatric & Primary Care, EMR/EHRs, Clinical Groupware, Workflow Automation, Usability/User Experience, & Kickbiking

Short Link:

Here are the most recent 20 tweets from @EMRGroupware: Auxiliary account used by @chuckwebster for real-time, high-frequency, event-related Twittering (not wishing to flood timelines following @chuckwebster). Next use: HIMSS March 1-4, Atlanta. Feel free to follow and respond to me (temporarily at @EMRGroupware) on Twitter (my replies with links to your tweet should show up below), or comment directly to this post.


For older tweets visit @EMRGroupware

Sunday in the Park Watching Dogs and Thinking about Clinical Groupware

I do some of my best thinking while watching dogs gambol in the park (for example, see Does Your Pediatric EMR’s Form Follow Function, or Does Its Function Follow Form?).

A couple of days ago I drafted a definition for clinical groupware (Clinical Groupware: A Definition). There are things I like about it (with respect to the five requirements for a good definition) but it is by no means perfect (few definitions are). I needed to let my thinking on the subject incubate, the second step in the Wallas five step model of creativity: 1) preparation (which I’d already done to write  Clinical Groupware, Care Coordination, and EMR Workflow Systems: Key Ideas), 2) incubation, 3) intimation, 4) illumination, and 5) verification.

“Incubation is defined as a process of unconscious recombination of thought elements that were stimulated through conscious work at one point in time, resulting in novel ideas at some later point in time…The experience of leaving a problem for a period of time, then finding that the difficulty evaporates on returning to the problem, or even more striking, that the solution “comes out of the blue”, when thinking about something else, is widespread. Many guides to effective thinking and problem solving advise the reader to set problems aside for a time.” (

So I went to Atlanta’s Piedmont Park and enjoyed myself. As ideas occurred to me (intimation and illumination) I wrote them in a notebook. I would have tweeted them (@chuckwebster), but they were too fragmented and half-baked even for Twitter.

I’ll write a blog post based on all that cogitating. Your reaction to it will complete the last stage of the creative process: verification (for at least this cycle of revision of the clinical groupware definition). Stay tuned!

Until then, here are the pictures (and an introductory video).

[flv: 320 240]

Pan of Piedmont Park and Explanation of the Dog Halo Effect

harper-webSorry Harper, you just don’t have enough hair to exhibit the dog halo effect.

feathers-webMediocre halo effect, but a magnificent shadow!

dog-halo21Good candidate, face stage left please. 

dog-halo1-webThank you! We’ll let you know.

lion-webHey! There’s a lion loose in the park. Doesn’t anyone notice?
(Exotic wild animals at large in Atlanta are becoming commonplace. )

 dog-haloNow that’s what I’m talking about! Perfect 10!

dont-want-to-leave-webI know how you feel Harper. I don’t want to leave either.

Thank you Graham Wallas, for making work so much fun.

Hey, someone’s been chewing on my notebook–Harper!

Zowie! Tweets of the Week, February 21, 2010: Anniversary, Clinical Groupware, Don’t Mimic Paper, Aviation’s Glass Cockpit Analogy

Clinical Groupware: A Definition

Short Link:

[CW: “Clinical Groupware, as a phrase, has fallen out of favor. It was relentlessly marketed with any attention to what it really means. Of course, what it means is more important than what it’s called. And the idea of “groupware” for clinicians is still a great idea.]

Last week I highlighted several dozen quotes about groupware, coordination, and workflow, and supplied commentary about their relevance to clinical groupware. This week I thought I’d take a stab at defining “clinical groupware” itself.

But first, what constitutes a good definition?


Southern Rose Buggy Tours
Beaufort, South Carolina
(From my recent vacation there)

While a graduate student in Intelligent Systems, I worked on lexicons for use by natural language processing systems. Lexicography is the science of creating dictionaries, which (I think obviously) includes the science of creating definitions. A good definition meets five requirements. I’ll use “horse” as an example.

A good definition:

  1. Describes essential, not incidental, attributes of the thing or concept being defined. For example, while many horses are brown, “brown” is not part of the definition of a horse. Fast horses are more valuable than slow horses, but slow horses are horses nonetheless.
  2. Avoids circularity. A horse cannot be defined simply as a member of the species equus.
  3. Is not too specific or too general. The definition of a horse should be somewhere between that of a Shetland Pony and a mammal, true of everything that is a horse and falsely applied to everything that is not a horse.
  4. Avoid obscurity. Use widely understood terms with clear meaning. A horse is a four-legged, solid-hooved, plant-eating domesticated mammal commonly ridden to perform work or obtain entertainment. (If you ask “Is a camel therefore a horse?” you’ve made my point. My definition is too general with respect to the third requirement on this list.)
  5. A definition should be positive (what a thing or concept *is*) not negative (what a thing or concept is *not*), though sometimes this cannot be avoided (as is the case if blindness is defined to be the absence of vision). A horse is not a camel, but camels should not be invoked in the definition of a horse.

If you can think of exceptions to these requirements, I am not surprised. Creating dictionaries (and lexicons for natural language parsers) is exacting *and* frustrating. Word meanings subtly change from context to context. There are exceptions. I don’t think I ever created a perfect definition. But sometimes you can create a definition good enough for a specific purpose.

Speaking of which, my purpose is to craft a definition of clinical groupware.

I don’t have to start from scratch, since early CSCW (Computer-Supported Collaborative Work) researchers have already done some work for me. In 1982 Peter and Trudy Johnson-Lenz proposed this definition for groupware:

“GROUPWARE = intentional GROUP processes and procedures to achieve specific purposes + softWARE tools designed to support and facilitate the group’s work”

“Groupware” is a portmanteau word created by blending the morphemes  from “group” and “software.”

“Clinical” is an adjective modifying the “groupware” noun. “Clinical” means “pertaining to observation and treatment of patients,” so how about the following 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.”

I think this definition of clinical groupware meets all five requirements for a good definition:

  1. The definition describes essential, not incidental characteristics.
  2. It doesn’t define “clinical groupware” circularly in terms of either “clinical” or “groupware” (which is why I did not use “software tools”).
  3. The definition is not too general or too specific. For example, it avoids the undue specificity (in this non-pediatric context) of my use of the Johnson-Lenz definition of groupware to describe pediatric groupware in a previous post.
  4. It uses terms commonplace within the community of its intended audience.
  5. The definition is positive. For example, it does not define clinical groupware as being the opposite of traditional EMRs (whatever that would mean, since there are so many different ways to be the opposite of traditional EMRs).

This definition of clinical groupware is based on a well-reviewed definition of groupware. There are many varieties of clinical groupware, but I think the definition is flexible enough to apply to examples of clinical groupware (such as pediatric groupware) while being specific enough to be useful in discussion and communication. It focuses on what clinical groupware *is* and the goals it serves, not *how* it performs them. Being too prescriptive runs the risk of stifling innovation. I am a fan of workflow engines executing process definitions (called “workplans” in the EncounterPRO Pediatric EMR) and radar views supporting shared mental models, but there are other kinds of clinical groupware. I hope the definition can accommodate them as well.

Just in case you skipped to the last paragraph first (which I do sometimes to understand where an article is going before I decide to read it in entirety), here is my proposed definition for clinical groupware:

“Intentional care team processes and procedures pertaining to the observation and treatment of patients plus the tools designed to support and facilitate a care team’s work.”

Care Coordination and EMR Workflow Systems: Key Ideas

Short Link:

As the phrase “clinical groupware” gains currency [UPDATE: well, it gained and then lost that, but what it means is just as important today!], it’s worth considering the history of groupware in general, and workflow in particular, to understand the relationship between EMR workflow systems and clinical groupware. This relationship is at the technological heart of the care coordination problem.

Workflow systems are a form of groupware, and EMR workflow systems are a form of clinical groupware. Jonathan Grudin, in a 1994 Communications of the Association for Computing Machinery article (second most cited for “groupware” in Google Scholar) wrote:

“Desktop conferencing, videoconferencing, co-authoring features and applications, electronic mail and bulletin boards, meeting support systems, voice applications, workflow systems, and group calendars are key examples of groupware.” (Groupware and Social Dynamics: Eight Challenges for Developers, 1994, my emphasis)

Last week I described the landmark 2000 HIMSS presentation and proceedings paper about a workflow-based clinical groupware system installed in ten pediatric practices and one family medicine practice. In it I quoted from two early (1988 and 1992) collections of readings about groupware. I found so much relevant material that I collated, annotated, and published it (see below) so it can become part of a larger conversation about clinical groupware. I’ll refer to this material in future posts.


 From My Bookshelf

[TABLE=3]It is fitting to close this litany of groupware, coordination, and workflow quotes and comments with one more wrinkle, what Frisse, Schnase, and Metcalfe call “The Problem of Language: The efforts to integrate information from disparate sources into a single, unified, computer-based patient record are challenged more by the enormous range of human expression than by technology” (Models of Patient Records,1994). Using the phrase “medical groupware,” not “clinical groupware”, they eloquently describe the importance of medical “conversation” to clinical groupware (see my earlier posts on syntactic, semantic, pragmatic, and “conversational” EMR interoperability):

Models for Patient Records

“When performance is defined as the result of collective efforts rather than as the result of the actions of an individual, software systems supporting these activities may be labeled under the popular rubric groupware….Although it is tempting to think of these activities as “transactions” it is equally valid to consider them “conversations” related to the solution of specific tasks….Using conversations as a central metaphor for handling patients’ records reflects workflow in a clinical setting….the introduction of groupware designed to facilitate conversations will allow for the acknowledgement and representation of the centrality of human conversation rather than force individuals to reconstruct these conversations through examination of data tables and unstructured patient records….medical groupware helps us redefine where our information systems are going and reflect on their origins and true purpose….it should be remembered that the system is nothing more or less than the community of individuals who collectively care for one another.” [CW: my emphasis]

Some workflow systems literally model, execute, and monitor speech acts (proposals, counter-proposals, promises, excuses, and so on). If we are to move from “conversation” as an interesting metaphor, to practical ways to coordinate the “community of individuals who collectively care for one another,” we will need both the informal and spontaneous clinical groupware, and the more formal and prescriptive clinical groupware known as EMR workflow systems. Their strategic combination is at the technological heart of the care coordination opportunity.


  1. Baecker, R. Part I: Introduction, Baecker, R. (Ed.) Readings in Groupware and Computer-Supported Cooperative Work: Assisting Human-Human Collaboration, Morgan Kaufmann, 1992.
  2. Coleman, D. & Khanna, R., Groupware: Technology and Applications, Prentice Hall, 1995.
  3. Ellis, C, Gibbs, S, & Rein, G, Groupware: Some Issues and Experiences, Communications of the ACM, Volume 34, No 1, January, 1991.
  4. Flor, N, & Hutchens, E. Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance, In Joenemann-Belliveau, T, Moher, T. & Robertson, S. (Eds.) Empirical Studies of Programmers, Fourth Workshop, Ablex, 1991.
  5. Frisse, M, Schnase, J, Metcalfe, E, Models of Patient Records, Vol 69, No 7, July 1994, Academic Medicine.
  6. Grief, I. (Ed.) Computer-Supported Cooperative Work: A Book of Readings, Morgan Kaufmann, 1988.
  7. Grudin, J. Groupware and Cooperative Work: Problems and Prospects, In Laural, B (Ed.), The Art of Human Computer Interface Design, Addison-Wesley, 1990.
  8. Johnson-Lenz, P. & Johnson-Lenz, T. Groupware: The Process and Impacts of Design Choices. In Kerr, E. & Hiltz, S. (Eds.), Computer-Mediated Communication Systems: Status and Evaluation, Academic Press, 1982.
  9. Khoshafian, S. & and Buckiewicz, M., Introduction to Groupware, Workflow, and Workgroup Computing, Wiley, 1995.
  10. Malone, T. & Crowston, K, What is Coordination Theory and How Can It Help Design Cooperative Work Systems, In Halasz, F. (Ed.) CSCW 90: Proceedings of the Conference on Computer-Supported Cooperative Work, Los Angeles, Oct 7-10, 1990, ACM.
  11. Rodden, T. & Blair, G. CSCW and Distributed Systems: The Problem of Control, Bannen, L., Robinson, M, & Schmidt, K, (Eds.) Proceedings of the Second European Conference on Computer-Supported Cooperative Work, Sept 25-27, 1991, Amsterdam.

Zowie! Tweets of the Week February, 14, 2010: Snow, Traditional EMRs, Usability, Workflow, Expected Utility

Thank You to MedicExchange TV Industry News for Mentioning this Blog

Short Link:

Thank you to MedicExchange TV Industry News for mentioning my blog (on “EHR workflow management and business process management concepts, technologies, and products”) at about 4:30 into this week’s video segment.

I am always delighted to hear someone other than myself utter the words “EMR” or “EHR” and “workflow management” and “business process management” in the same sentence. It’s why this blog exists. It’s why I posted this video of an interview with a pediatrician speaking about EMR workflow management and business process management in his solo practice.


Thanks again to MedicExchange TV Industry News!

Washington, DC, Blizzard of 2010 Photos and Videos

Short Link:

The DC Blizzard of 2010 (January 5-6, fourth most snow in DC weather history) is over except for the shoveling [CW: Ha! See P.S.S!]. Today, Sunday, is clear and cold. Yesterday the falling snow was so dense (up to 3 inches an hour) that sometimes it felt like I was walking through snow soup. Here are some of my favorite photos and videos…


This is my favorite. We’re looking west toward the Chinatown Friendship Arch. The green traffic lights add a touch of irony–there are no cars on the road, just people and dogs (though technically, there *are* cars on the road; dimly visible on the other side of the arch, are a number of stranded vehicles).



Transplants to DC from colder climes broke out their winter equipment.



I was not to be outdone: kickbikes for summer and kicksleds for winter.



One snowboard dudesss suggested that I get a Snow Jack tattoo. (Nope.)



Could I have a table outside, please?



Saturday evening: while I did not see the sun, I did see peripheral evidence of a lovely sunset. That’s the top of the Washington Monument to the left.




[flv: 320 240]Winter storms are time machines.

[flv: 320 240]7AM Chinatown Friendship Arch

[flv: 320 240]Wow! I didn’t DC had snow blowers!
(And no, I don’t know why WordPress centered three Flash videos but left justified the next three, despite my straight-forward HTML tags.)

[flv: 320 240]One, Two, Three, Four, Five!

[flv: 320 240]I’ll have a table outside please.

[flv: 320 240]All over except the shoveling.



One day later…


See, we’re half way dug out already!

P.S.S. Four days later we get hit with another blizzard, officially making this the snowiest winter in DC history.

[flv: 320 240]They’re baaack!



Look familiar? While I did not “get the shot”, for short periods the steeple was invisible.


 Reminds me of those statues on Easter Island!

 [flv: 320 240]In search of Starbucks

[flv: 320 240]A “Sunny” Blizzard



[flv: 320 240]Me, Standing on Ten Foot High Pile of Snow