Do you need to speed up the process of finding an EHR solution that is good enough? Eberhardt Rechtin, in a wonderful little book called "Systems Architecting: Creating and Building Complex Systems," lists a number of heuristics that I find useful.
"Heuristic” - a word of Greek origin - is a word used to describe the practice of using experience-based techniques for problem solving, learning, and discovery. Heuristic methods are used to speed up the process of finding a good enough solution, where an exhaustive search is impractical. Examples of this method include using a "rule of thumb,” an educated guess, an intuitive judgment, or plain common sense, according to Wikipedia.
Do you need to speed up the process of finding an EHR solution that is good enough? Eberhardt Rechtin, in a wonderful little book called "Systems Architecting: Creating and Building Complex Systems," lists a number of heuristics that I find useful. If you are near a university engineering library you may be able to find it but, unfortunately, it appears to be out of print so I thought I would pass along a few of his rules of thumb.
• Murphy's Law: If anything can go wrong it will.
• The simplest solution is usually the correct one.
• The greatest leverage is gained by carefully designing the interfaces between components.
• Success is defined by you when you try to use a product, not by the builders, who are understandably proud of their creation.
• Look for components that are insensitive to unknown or uncontrollable events and that continue to do something useful even if degraded.
• When designing a new system all the serious mistakes are made on day one. Like shoes that don't fit in the store, these problems don't get better with time.
• Don't assume that your initial list of requirements or your initial conception of the problem is best, or even right.
• System structure should resemble functional structure.
• Before flight, it's opinion. After flight, it's obvious.
• Triage. Let the dying die. This goes for systems too.
• Within a given class of product, the failure rate is linearly proportional to the cost.
• Quality has to be built in. It can't be added later by inspection, testing or workarounds.
• A system optimized for the expected (routine) will be unlikely to encounter anything routine; 80 percent of our time and effort is consumed managing the exceptions. If the system can't help manage the exceptions then it can do little to reduce the workload.
Years ago I was in awe of the big systems used in hospitals. I assumed then, as you may now, that size implies complexity and complexity required special expertise to build and necessitated high price. Then I had occasion to develop an Admission, Discharge, and Transfer (ADT) and clinic-scheduling systems for my facility so I rolled up my sleeves and started designing. Six weeks later an ADT system was up and running at a cost of about $7,500. Ten weeks later the clinic-scheduling system was put into service. The ADT processed approximately 250,000 admissions before it was replaced by a new $25,000,000 system that did little more than continue to assign patients to beds. The scheduling system ran for ten years (until the hardware died) during which time it processed approximately 500,000 visits.
This experience led me to formulate the Order of Magnitude Heuristic. Instead of starting with the assumption that a system is going to cost megabucks and then feeling relieved when the quoted price is only 0.8 megabucks, start by assuming that you have only $10 to spend. The next step is to devote a serious amount of brainstorming to devising a $10 solution to your problem. If $10 doesn’t solve the problem (and it probably won’t), increase the budget by a factor of ten and brainstorm again. By the time you get to $10,000 and certainly before reaching $100,000, you may very well find that you have attractive options.
This doesn’t mean that commercial EHR software is necessarily flawed or overpriced. It does mean that a particular product maybe more complicated than it needs to be for you, that it organizes the work in a way that would be counter-productive to you and that it may include modules and functions that are useful to some potential customer, but not to you. If you need the features and the complexity, the cost is probably justifiable. On the other hand, don’t assume that any problem is too complicated for you to solve or that it’s so complicated that it necessarily has to be expensive. By starting with a ridiculously small budget and exhausting its possibilities before you allow yourself to consider spending more, you may find that you arrive at a simple, adequate solution that meets your needs.
Learn more about Daniel Essin and our other contributing bloggers here.