Care Coordination and Clinical Care Systems: A Look at Clinical Work Support Needs

By encouraging adoption of HIT, the EHR incentive programs have forced everyone to deal with the realities of current EHR system designs. In fact, this might be one of the most significant outcomes of the entire program. Now that there is a general acceptance that HIT needs to evolve in order to better support clinical work, more research is becoming available that details how clinical professionals work and the nature of their information management needs.

Prior to the incentive programs, there was a mostly unchallenged assumption that EHR systems were capable of supporting clinical work needs. The national experiment in EHR adoption has proven this assumption to be false — but not in a bad way (I have no interest in bashing current products). Rather, in disproving the initial assumption, the incentive programs have engendered a level of research into clinical work, interoperability, safety, and clinical software design that I doubt would have ever happened absent the ONC’s efforts.

The work of Richardson, Vest, et al. (1) on HIT support for care coordination is a perfect example of why this a wonderful time to be an informaticist with a passion for clinical software design. Like many recent papers that look at work support needs, this paper provides valuable information on software requirements that come directly from working clinicians. Such information is useful to anyone designing clinical software. Fortunately, after being scarce for so long, this type of information is becoming more available. Private developers have in-house clinical advisors, but often cannot manage to gather detailed data from multiple sources in ways that researchers can. When detailed information on clinical work support needs is published, it lowers the barrier for everyone designing clinical software.

The authors investigated the use of HIT within patient-centered medical homes (PCMHs) with a specific focus on care coordination activities and how well installed HIT systems supported care coordination needs. Three PCMH sites were chosen and semi-structured interviews were conducted with 28 participants. Participants represented a cross-section of PCMH personnel (clinicians, HIT vendor reps, policy makers, care coordinators, etc.). The authors described interview content as follows:

…Participants described their current use of, and needs for, care coordination health IT, which we define and describe as five inter-related areas: monitoring tools, notification tools, collaborative tools, reporting tools, and interoperability. Although the sites differed in governance and payment models, our team found many commonalities among health IT solutions. Representative quotes from each of the areas convey participants’ perceptions of the current and ideal state of health IT for care coordination in PCMHs.

From the interviews, five areas of need were noted: monitoring, notification, collaboration, reporting, and interoperability.

Monitoring
One of the things I found most appealing about this paper was the peek inside it affords in seeing how sites were trying to meet their work support needs. For example, the authors note that data repositories and condition-based registries had been built by some sites in order to monitor specific conditions. One site was working on an algorithm to identify high-risk patients. Particularly interesting were the means used by some care managers to monitor patients. The authors state:

However, participants also noted that their care managers were attempting to monitor patient activities using homegrown tools built from Excel spreadsheets, Microsoft Access data- bases, and various paper forms. Since these patient data existed apart from EHRs or any other means of integrated health IT, there were obvious barriers in notifying care coordinators of a patient’s status.

Looking ahead, participants described a need for monitoring tools that PCMHs could use to generate patient panels, using real-time clinical data to proactively manage patients with complex conditions, mitigate harm, and control costs: “ . . . [for] a really simple need . . . most EHRs do an okay job. But for those complex care needs . . . it’s just not working well.”

Monitoring is an obvious part of care coordination and population management. Adding such tools on top of current EHR products requires the presence of a modular software architecture and a flexible information model. The information model is particularly important. Notice I did not say “data model,” which is a different animal. Information models exist at a level above data models and provide flexibility by separating information use (access, storage, semantic constraints, etc.) from the storage format. By adding such a layer, one can make applications agnostic to the data storage technology and format, making it easier to use the same underlying data in different ways.

Notification
Keeping track of anything over time requires a means of alerting when something changes. Notification capability is the type of feature that doesn’t receive much attention until really needed. Before smartphones, easy-to-use notifications were not generally available. Having had a smartphone for three years, I wonder how life even worked before notification systems. Participants in the study noted a few specific areas of concern.

The discussions around notification tools led many participants to identify needs for health IT tools that help notify all members of assigned healthcare team about changes or updates to a patient’s status. They particularly requested that care managers, who were utilized in all three sites, receive notifications to better coordinate care. Participants also high-lighted the need for tools that could support care managers by notifying when patient transitions across care settings occurred or were planned to occur and for making available care manager data for other caregivers to view.

The allusion to the need for notification on changes in patient status raises another design issue that I have been pondering more in recent months — that of patient state (see What is the Smallest Viable Unit of Clinical Data?). Having data about a patient is not the same as having a computable representation of one, and notifications, like CDS, would be addressed much better via a patent state matrix rather than a series of databases queries. I consider the development of computable patient representations to be a central challenge of clinical informatics, if we are to develop smart clinical assistants.

Collaboration
Clinical care is a collaborative endeavor, so it is no surprise that those who work in teams and across sites place a high value on collaboration tools.

…multiple participants described a need for dynamic electronic care plans that help teams of clinicians quickly get up to speed on a patient’s status and come to an agreement on goals for that patient. They were undertaking the research themselves because neither their current EHR systems nor any other types of health IT supported this perceived need. PCMH C participants reported conducting their own internal research into ways that condition-specific care plans could effectively support team-based care.

Participants also described needs for cross-clinic cooperative tools that could better coordinate care with affiliated as well as non-affiliated practice sites for specialty care. Once again, electronic care plans shared across practices were hypothesized to be one potential solution for organizing and documenting care across distributed teams: “ . . . it all comes down to the information sharing of assessments, and the care plans, and goals, and having that all available in one place for every- body who’s part of the treatment team; even if they’re . . . in different settings of care.”

Meeting collaboration needs requires more than a user-interface and database access. While all areas mentioned in the study have workflow-related requirements, collaboration is a poster child for workflow technology. Sure, HIT vendors could roll their own workflow tech or build static workflow capability into systems; however, the day when either made sense has surely passed. EHR systems have static workflows and adding new code to current EHR systems every time a new work support need arises makes no sense. Workflow technology is the only currently available approach that makes the problem tractable. The downside of this realization is that current systems would need substantial rewrites to make use of workflow tech; the upside is that the future is coming — no matter what.

While only a few vendors dominate the EHR market today, the clinical care system market of tomorrow is wide open to the first company that offers modular systems with an information model and workflow tech as foundational components (see The EHR Market and Biology 101 and Disruption in the EHR Market: Will Anyone See It Coming? ). When systems appear that solve significantly more problems than they create, selling them will not be the issue — standing in line will.

Reporting
Just as collaboration is a poster child for workflow technology, reporting has that same dubious honor for information models. When it comes to data models for EHR systems, if you have seen one, then you have seen one. There are no rules, no commonly acceptable representations, formats, etc., used by all vendors. In an RDBMS, the data model constrains the meaning of data elements, and tweaking the data model can have unintended consequences unless done with extreme care. If the data are fairly straightforward (e.g., accounts receivable) then the meanings are not hard to glean from looking at the data model. Try the same thing in an EHR system that has evolved over years and uses model conventions that are unique to that vendor.

openEHR-esque approaches to separating the data model from data semantics directly address reporting problems at the most fundamental level. With the above in mind, it is no surprise to learn that reporting was a challenge for study participants.

A common observation was that PCMHs spent a great deal of effort, and money, trying to report their EHR data, even though they were reportedly adhering to the continuity of care document standard (CCD) for interoperability: “ . . . one of the largest issues is with the [EHRs] where the [medical] office[s] cannot build their own reports . . . they have to put in a ticket request [that] a report be created.”

The major conclusions from this study suggest that existing health IT needs to evolve from digitized patient record repositories into interoperable electronic collaboration platforms that support both individual patients and patient populations to enable PCMH care coordination efforts. We recommend focusing health IT advances on improving monitoring, notification, collaboration, reporting, and interoperability within and among PCMHs. Focusing technological solutions in these areas can offer transformative approaches to improving care coordination and quality.

Care coordination requirements clearly point to work support needs that necessitate flexible data management capabilities and workflow technology. Realization of next-generation clinical care systems requires more research like that undertaken by the authors along with a greater appreciation that clinical software requires models of work, and not simply models of data. Electronic records, in concept and rendition, address most directly those aspects of clinical care that are addressed by paper charts. Attempting to force EHR systems to exceed their original design conceptualizations will only continue to disrupt the work of busy clinicians while delaying serious investigation into better metaphors for clinical software designs.