“Why Legos?” you might ask.
Legos® are the theme of the Universal Transfer Protocol. In many ways they model the many discrete data elements that must accompany the client/patient as he/she transfers from one provider to the next. Just as Legos® can be put together to make different objects, discrete data elements can be combined to create specific messages. Both the blocks and the data elements can be re-used and re-combined to make new objects and messages.
The reason you can do this with Legos® is that they are “standardized and interoperable” (see our post, Oy. Such a Headache You Give Me.). They all share a standard size and shape. The pegs are the same length and distance apart regardless of the color of the block. The Lego is the ultimate interchangeable part. They can be added to other Legos® to make larger and more complex shapes. In order to create data elements that can be reused and exchanged, they must be standardized and interoperable as well.
Building Complex Systems by Iterating from Simple Systems
All complex systems that actually work evolve from simple systems that actually work. If we are to successfully evolve a UTP that supports complex systems of interaction — a UTP that actually works — we must start with a core simple model, then iterate and evolve:
- Start with simple, modular blocks
- Establish efficient work flows
- Combine modules to produce more complex relationships
- Expand modules to produce more extensive information exchange
- Each neighborhood builds its own intercommunications plan using the same modules combined differently
We are not building a form. What we are building is more like sets of Legos: Individual data elements, that everyone recognizes, that can be combined to produce what the receiver of the information requires. We all need many of the same Legos; none of us needs all of them; but each of us requires Legos that others may not need. The variation in what we each need is what makes it impossible to make a “form.” What we have to be able to create are like bags containing different combinations of Legos.
Each high value activity requires the exchange of information. The UTP process for an activity starts with identifying the critical data elements, the Legos® if you will, needed to support the activity.
Our plan is to start with the simplest activity, one that requires the fewest number of data elements. Not only is this easier (fewer elements to select) but it also lets us re-use these elements in the next most complex data set, re-use many of those in the next data set and so on.
Ultimately all information flow will be electronic, but our iterative process allows us to determine what that information should be, well before electronic exchange is ubiquitous. By the time the electronic information is flowing, the iterative UTP development process will have evolved to the point that we are exchanging the right information to meet the needs of LTSS providers — that we have the right legos, and we know how they need to be grouped together.