A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. —  John Gall, General Systemantics, 1975

We all want to get to the grand solution, the program that solves all of our problems.  In LTSS,the grand solution is the coordination of all service providers to insure that the individual receives the services that address his or her needs —  in an acceptable manner to achieve the outcomes that he or she values most.  Coordination means that all important issues are addressed with neither gaps nor duplicated services.

Imagine if, for each patient/client, you could do the following:

1. Create a list of all actively engaged service providers and the services they currently provide,
2. Create a comprehensive list of active issues,
3. Rapidly identify unmet needs and address them,
4. Receive real time notification of admission or discharge from the hospital, ED, SNF or hospice.

These are all complex tasks, and yet even within this list there are increasing levels of complexity because some of these tasks can only be performed if other tasks are done.  In order to create a comprehensive list of active issues (#2), we need to know everyone who is out there providing services to address specific needs (#1).   Before we can identify gaps (#3) we have to combine item #1 with item #2.  In order to send a notification of a change in site of care, we have to know the list of engaged providers (#1) and how to contact them.  And, a change in site of care (#4) may result in a revision of unmet needs (#3), active issues (#2) and providers required to address them (#1).

The primary lesson to be drawn from these observations is that it is possible to create increasingly complex processes by combining less complex processes together.  We were able to build on the list of service providers (less complex) and the list of active issues (less complex) to create a process to identify unmet needs (more complex).  In turn, these three process could be building blocks of even more complex processes needed for comprehensive care coordination, outcomes measurement, and population health management.

However, a man named John Gall warned us that it is actually a critical success factor to begin with the simple. Gall’s Law (at the beginning of this post) is a rule of thumb for systems design from his book Systemantics: How Systems Really Work and How They Fail (1971).

As Wikipedia says, this law is essentially an argument in favour of underspecification: it can be used to explain the success of systems like the World Wide Web and Blogosphere, which grew from simple to complex systems incrementally, and the failure of systems like CORBA , which began with complex specifications.

As we think about the the complex processes that will ultimately be enabled by the UTP, we can deconstruct each them as well.  What we find is that each of complex task is built upon a series of less complex tasks.  For example, in order to create a list of all actively engaged service providers, we need a process to identify each service provider individually and what services they are providing to this individual.  This combination results from the list of services that the agency provides to potential referrers and the contact information that it provides with any request. The identification of the individual is needed to obtain consent to share information. These are basic business processes essential to providing services and are reliably collected and exchanged now. These high value activities form the basis of the UTP.

The fundamental processes needed to develop the UTP are:

1. Identify the most basic exchanges in the system,
2. Determine the information needed to support these exchanges, and
3. Establish a shared meaning for the information.

With this foundation, we can create increasingly more complex processes and support them with standardized information that can be used anywhere in the system.   We build the UTP upon simple, efficient and reliable exchanges that have demonstrated that they work.

Start small to build a complex system that works.