Blackboard: An Architectural Pattern for Supporting Care Coordination?

by Jerome Carter on February 23, 2015 · 1 comment

When it comes to creating electronic systems that support clinical care, the dominant paradigm has been the electronic health record. The reason for this is obvious; for decades the paper record has had a central role in care delivery.   However, as care delivery comes to embrace care coordination, patient engagement and shared decision-making, it is becoming obvious to all that a patient repository of information is but one of the components that are needed to support these facets of clinical care.

As always, building systems to support any activity requires input from those doing the work. Because my background is general internal medicine and primary care, systems that support primary care are of particular interest. We all know that patient care requires access to up-to-date patient information – the domain of the EHR, but what about the clinical work activities that require collaborative use of patient information? How are these activities best supported electronically? Fortunately, clinicians are becoming more vocal about their work support needs (1, 2).

In Electronic health record functionality needed to better support primary care Krist, et al. provide a list of functions that could support care coordination better than current systems (2).

  • Expand capacity for EHRs to receive and aggregate information from all settings so primary care clinicians can proactively coordinate care
    • Provide ‘out of the box’ health information exchange functionality to access all relevant health information
    • Support timely health information exchanges so clinicians can aggregate information at the point of care
    • Ensure vendor agnostic standardization of data
    • Store and exchange all structured data linked to standardized meta-data identifiers
    • Import discrete data from exchanges into the EHR (not just view data)
  • Provide functionality to help coordinate care among teams internally within offices and externally across organizations and systems
    • Allow the electronic formation of clinical teams with defined roles for members
    • Ensure that electronic tasks are distributed on the basis of defined roles
    • Create tools to track the progress of tasks across team members
  • Track and coordinate ancillary and enabling services (eg, case management, transportation, interpretation, social services, financial assistance)
    • Provide secure communication with coordination services
    • Maintain a shared library of local coordination services tailored to the individual
    • Create and maintain ‘benefits formularies’ delineating coverage of medications, tests, procedures, and services
  • Create a dashboard that synthesizes and prioritizes information about individual, and panels of, patients
    • Identify and sequence visits with other clinicians, changes in medication and diagnoses, and key results
    • Identify urgent messages or whether patients have been to an acute care facility or admitted to the hospital

These functions help to manage care processes that are focused around interactions between various types of clinicians across different care settings. They show the extent to which communication of decisions, intentions, and outcomes are a central component of primary care.   Supporting these functions in software requires tools to manage and track messages, create and manage virtual teams, locate and allocate resources, and other functions beyond accessing patient information.   The electronic health record is necessary for this functionality, but alone is not sufficient to provide it. I find the call for new collaboration and communicating features interesting, and while thinking about requirements for such systems, began thinking about blackboards.

A little about software architecture
Software, like buildings, have an architecture.   An architecture is a high-level view of a system including its components, how those components interact, and how they are physically deployed.   There are architectural patterns for systems just as there are design patterns for programming code (3) (see Design Patterns: The New Black). A pattern is a general approach to a specific design challenge, not a packaged solution to a problem.

(One of the most common patterns is Model-View-Controller (MVC) (see SaaS EHRs, MVC, Flexibility and Innovation).   The MVC pattern has been widely adopted and is the dominant pattern used for interactive web and mobile applications.  LAN-Based EHR systems were based on n-tier client/server arrangements. )

The blackboard architectural pattern has been around for a while. The architecture originated within the field of artificial intelligence as a way to support collaboration in solving problems where the exact strategy required to achieve the solution was unclear (3).   Corkill offers a scenario to explain how blackboard systems work (4):

Blackboard-based problem solving is often presented using the following metaphor: Imagine a group of human specialists seated next to a large blackboard. The specialists are working cooperatively to solve a problem, using the blackboard as the workplace for developing the solution. Problem solving begins when the problem and initial data are written onto the blackboard. The specialists watch the blackboard, looking for an opportunity to apply their expertise to the developing solution. When a specialist finds sufficient information to make a contribution, she records the contribution on the blackboard, hopefully enabling other specialists to apply their expertise. This process of adding contributions to the blackboard continues until the problem has been solved. This simple metaphor captures a number of the important characteristics of blackboard systems …

When I think of the number of virtual teams I participated in when practicing, the thought of a blackboard-style system seems like the perfect tool for the work done. At any given time, primary care clinicians are interacting with agencies, patients, families, subspecialists, facilities, and others.   Keeping the phone calls, forms, meetings, requests and everything else straight is an essential part of primary care.

Obviously, building a system with blackboard-type capabilities is a major undertaking, but the value of patterns is that they offer a general direction and let one know what has been tried and what has worked. Studying implementations, one can glean general design ideas from existing systems. For example, according to Hanmer (3), multi-player gaming systems have adopted this architectural pattern.

In the search for innovative solutions to clinical care system design challenges, it makes sense to look at areas where the problems are analogous to those that occur in health care.  When it comes to supporting complex care coordination and communication scenarios, blackboards offer hints that could be useful to clinical software designers. Assuming a modular design, blackboard functionally could be built into a component that is activated or added to the core system only when desired (see Building Clinical Care Software Systems, Part I: Issues and Challenges).

As the demands of clinical care become more complex, new system designs will be required. From where I sit, the blackboard pattern is worth investigating.

  1. Krist AH, Beasley JW, Crosson JC, Kibbe DC, et al.Electronic health record functionality needed to better support primary care. J Am Med Inform Assoc. 2014 Jan 15. [E]
  2. Sinsky CA, Beasley JW, Simmons GE, Baron RJ.Electronic health records: design, implementation, and policy for higher-value primary care. Ann Intern Med. 2014 May 20;160(10):727-8.
  3. Hanmer RS. Pattern-oriented Software Architecture for Dummies. Hoboken, NJ: Wiley, 2013.
  4. Corkill DD. Blackboard Systems. Blackboard Technology Group, Inc. Accessed at :http://gbbopen.org/papers/ai-expert.pdf
Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 1 comment… read it below or add one }

Sandra Raup February 23, 2015 at 4:41 PM

Excellent thoughts – I’m not certain about how this works technologically but I agree that it’s necessary in principle. I also think that at least for complex care, patients &/or families need to be included in the team. They often are left with complex tasks and need help when they need it, not 2 weeks later at a scheduled appointment. Here’s a long but excellent paper from 2012 explaining family caregiver issues that I think is particularly well done: http://www.aarp.org/content/dam/aarp/research/public_policy_institute/health/home-alone-family-caregivers-providing-complex-chronic-care-rev-AARP-ppi-health.pdf

Reply

Previous post:

Next post: