Building Clinical Care Software Systems, Part V: Supporting Clinical Work

We are now at the top layer of the clinical care system architecture. In this layer, the concern is how to best provide support for common clinical work needs such as collaboration or decision support.  This is very different from EHR system designs inspired by paper charts where the goal is replication of chart features.  For example, EHR systems often have problem lists, medication lists, note-writing features, and such as their main interface elements.   The informational properties of these chart features are important. However, providing information and supporting clinical work, while related, are not the same thing—as demonstrated by an increasing number of usability and workflow complaints.

Clinical Care System 4 Component Architecture

Historically, the way clinical professionals do their jobs–the steps they take, the types of decisions they face, what happens 100 times each day and things that happen only once—has not been a major research focus for clinical system design.   Fortunately, this is changing.    The NIST human factors and usability reports and AHRQ workflow materials provide valuable free information for software designers that previously could only be obtained at significant cost. Even better, clinicians are getting into the act.

Electronic Health Record Functionality Needed to Better Support Primary Care, a consensus statement from a group of professional societies, offers exactly the kind of information software designers need to build systems that intimately support clinical work.

Here is the authors’ statement of their aims and methods:

This article presents a consensus statement from the American Academy of Family Physicians (AAFP), American Academy of Pediatrics (AAP), American Board of Family Medicine (ABFM), and North American Primary Care Research Group. It identifies gaps in current EHR functionality and makes enhancement recommendations to better support primary care. The IOM attributes of primary care were used to define primary care needs, and stage 2 MU eligible provider objectives were used to define EHR functionality. Steps to reach consensus included (1) assigning each MU objective to the primary care attribute it supported, (2) identifying unmet needs within each attribute, and (3) obtaining iterative input from organization members and 148 practicing clinicians. Initial work was carried out by the 43 members of the NAPCRG Health Information Technology (HIT) working group (primary care HIT leaders from 38 institutions internationally). Practicing clinicians were identified from four practice-based research networks and included family physicians (n=78), internists (n=16), pediatricians (n=18), mid-level providers (n=12), nurses (n=15), and informatics staff (n=9) from 15 states in urban, suburban, and rural communities. Participant consensus was sought during each step.

The paper presents attributes of primary care matched to descriptions of EHR functionality that the group believes are required to support those attributes.   The list of attributes is extensive, so only two of the seven are listed below.

Electronic health record (EHR) and information technology enhancements not addressed by meaningful use (MU) and needed to better support primary care:

Primary care attribute: coordination – Expand capacity for EHRs to receive and aggregate information from all settings so primary care clinicians can proactively coordinate care
– Provide functionality to help coordinate care among teams internally within offices and externally across organizations and systems- Track and coordinate ancillary and enabling services (e.g., case management, transportation, interpretation, social services, financial assistance)- Create a dashboard that synthesizes and prioritizes information about individual, and panels of, patients
Primary care attribute: sustained care – Track and support continuity of care- Track and support care over time


The paper makes it clear that clinical work is role-based, collaborative, non-linear and integrative.    These attributes of clinical work must be reflected in software designs.
One great thing about this paper is that it reveals what clinicians believe they might want from a clinical care system.  This is huge.  However, the best part about this is not that clinicians are saying what they want in terms of software features–even though that in itself is a very good thing. Rather, it is that clinicians are beginning to give serious thought to what they do day after day, both why and how.  It is exactly this kind of information that is needed to design next-generation clinical care systems.

Look at the coordination attribute.  The paper calls for software that can coordinate care among teams within practices and with external sites.  I would have killed for this feature when I practiced.    The amount of time I spent calling and responding to home care nurses, family members, consultants, and insurance companies was too large a percentage of my clinical time.   Cutting that back by even 10% would have been a huge improvement.   The mundane things take far too much time, and systems designed to support clinical work should make the 100-times-a-day tasks much easier.  But first, someone has to point out what those tasks are.

Being able to track chronic diseases over time, in detail, across providers and care settings would also be a productivity boon for primary care providers (sustained care attribute).  I had so many patients who were seeing specialists at other hospitals and trying to keep up with what was going on wasted a lot of time.   Yes, getting notes from other providers and facilities helped, but then managing the notes became an issue.  Having the notes meant going through them and cross-referencing meds, symptoms, and diagnoses.   Often, I still had to make calls to figure out exactly what happened.  Tracking chronic conditions over time requires more than access to documents; it also requires a mechanism to build and manage timelines and events.

As more clinical groups make their wishes known, the next step is turning them into real software—no small feat.   It is certainly not something I expect the average EHR vendor to tackle single-handedly.   The cost and resources required would be too much because there are so many basic research issues here.  There are no models for clinical work and no reference user interface designs. Turning desired features into real software will require deep, long-term collaborations between clinicians, informaticists, software engineers, workflow specialists, usability experts, and many others.   It is certainly more involved than adding a few features to current systems, or exchanging electronic documents.

So much time and energy have been put into systems conceived as electronic replacements for paper charts that we have lost track of the fact that care delivery, not updating a chart, is the goal of clinical work.  Electronic charts have their place, but support for clinical work requires more.

Well, this brings the series to a close.   Building systems that intimately support clinical work requires a rethinking of what clinical care systems are and should be.   Doing so also requires an approach that cleanly separates the hard issues so that each may be properly investigated. The clinical care system architecture discussed in this series is but one possible approach to designing next-generation systems.

EHR systems (and EMRs before them) have been around for a while, and from the national adoption experiment conducted by way of the incentive programs, we have learned that supporting clinical work electronically is more complex than initially believed.  Why not try a new approach?



  1. EHRs and Clinical Care System are both different, having different approach, functions, usability, and workflow design; however, what EHRs are missing at this level is something what Clinical Care Systems are in a position to provide. Keeping this thought, I think someone should think of a platform where both the systems, EHRs and Clinical Care Systems, work in an integrated scenario. That should provide us the level of healthcare we all are looking for.

    1. Raj, thanks for your comment. I think it is inevitable that systems evolve so that CCSs and EHRs co-exist on the same platform.

  2. i agree with what you are saying and have so since i finished my residency 5 years ago in family med. since then i have spent my energy on trying to fix this issue, and have been running a prototype system that meets most of the above goals. the bigger problem is that there is no mechanism through which clinicians can efficiently and effectively make changes to these systems. we need to have a network of clinical research clinics where clinical students can be given the first step towards continually developing what we use. obviously only a small number of clinicians will care to do so, but that is fine. unlike most of the foundational sciences which clinicians are well founded in, computing systems are not explored at all. have you come across any actual steps towards health system research clinics in medical schools, or elsewhere? thanks and keep up the great writing, i’ve loved reading it.

    1. Jim, glad that you enjoy the blog. You are correct much more needs to be done to make clinical computing into a formal research and teaching discipline. I am aware of three announced initiatives where academic centers have partnered with vendors. Oregon Health Sciences is working with Epic and, if I remember correctly, Hopkins is working with Kaiser. However, I don’t have any links to back up these statements. Aside from these possible initiatives, I am not aware of any others.


Leave a Reply

Your email address will not be published. Required fields are marked *