These tools, often adopted by other industries, can help insurers improve health care delivery
A healthy workforce is critical to the success of an organization or a society. Properly managing the delivery of health care is thus an important function of modern health care systems. However, health care delivery today is rife with waste and inefficiency. Kohn et al. (2000) estimated 50,000 to 100,000 lives are lost each year because of medical errors. Schoen et al. (2006) found that 42 percent of the responders in a survey, “Public Views on Shaping the Future of the U.S. Health System,” felt that the health care system was inefficient. In 2011, Schoen found that efficiency in the U.S. health care system remained low, costs rose and disparities persisted. This although health care accounts for over 17 percent of U.S. gross domestic product (OECD, 2012). Researchers have identified several common causes of waste in health care.
Common causes of inefficiency
- Long turnaround time
- Inconsistent cycle time
- Staff task–skill mismatch
- Use of premium staff
- Unnecessary/inappropriate stay
- Prescription/medication errors
- Unnecessary testing
- Excessive reiteration for procedures/admissions/testing
- Procedure/contract noncompliance
- Inappropriate level of care
- Conditions/infections acquired during care delivery
There seems to be a consensus that problems in health care delivery need resolutions. Systematic approaches from other fields can be applied to reach such resolutions.
Product engineering is a multidisciplinary approach geared toward designing, developing and managing a product through its life cycle. A product could be tangible or intangible vis-à-vis hardware, software or processed materials. Job responsibilities of a product engineer include, but are not limited to, material selection, cost control, manufacturability/serviceability assurance, testing, quality assurance, reliability/warranty issues, product releases, and changes. A product engineer needs to be knowledgeable about physical sciences. The engineer also needs to be competent in project management and have statistical and mathematical competencies. Above all, however, a product engineer needs to be an efficient problem solver. There are many tools — structured methods — which are employed by product engineers. Listed are five methods that can prove useful in health care management.
Five engineering tools
Is–Is not problem analysis. The Is-Is not team approach can be used to clearly define a problem or failure. This method answers four questions associated with a problem: what, where, when, and how often. The differences highlighted by these four questions are then used to arrive at the clear description of a problem. In some cases the Is–Is not problem analysis can help reach the most probable cause. However, it must be noted that each cause will have to be verified with actual testing. The Is–Is not worksheet (see below) provides an illustration of the four questions asked by this method. Once the Is–Is not review has been completed, the differences or distinctions can be analyzed to arrive at a concise description of the problem or failure. The following hypothetical example can further illustrate this method: A new cleaning company was hired by ABC hospital for its satellite locations. Soon after, many of the hospital staff started developing a rash. The rash didn’t afflict all the staff — neither did it affect all the shifts. The rash occurred only on the face, arms, and hands. This scenario is perfect for Is–Is not problem solving.
|Is–Is not work sheet|
|What exactly is the problem?
What is the object/subject?
What is the defect?
|Rash||Not other ailments||Something touches the skin|
|Where exactly does the problem occur?
Location in the process/subject
Location on the object
|Satellite locations||Main hospital||Different cleaning supplies & contractors|
|When exactly did the problem occur?
When during the life/process cycle
|How often did the problem occur?
% of object/subject affected
How many defects
|Face, arms, hands||Other body parts||Exposed surface|
|Probable cause||Ingredients in the new cleaning supplies in humid conditions irritate exposed skin.|
Fish-bone diagram. Once the problem has been clearly defined, the fish-bone diagram can be used to identify the various causes associated with the problem. In order to complete a fish-bone diagram, a team must brainstorm to illustrate the effects of various factors that have a role to play in the problem. A fish-bone diagram is also known as the Ishikawa diagram and starts with a broad arrow pointing towards the problem statement. Branches representing various factors influencing the problem are then connected to the broad arrow.
Fish-bone diagram with 5-times why approach
Some commonly used factors include:
6 Ms. (Wo)Man, Method, Materials, Measurement, Man, and Mother nature/environment. This set of factors is commonly used in the manufacturing/plant environment. In a health care setting these factors can be represented in a laboratory.
8 Ps. Procedures, Processes, Policies, People, Promotion, Price, Product, and Place. This set of factors is commonly used in the administrative setting. In a health care setting these factors can be used to analyze patient data in the handover from one department to the next.
4Ss. Skills, Surroundings, Suppliers, Systems. This set of factors is commonly used in the service industry. In a health care setting these factors can be used in an emergency room triage.
The 8Ps and 4Ss factors have been used in the service sector, especially in accounting, sales, customer service, and administration. These factors exist in many subsectors associated with health care delivery. For example, health insurance companies can use factors similar to 8Ps or 4Ss to construct a fish-bone diagram.
The team then brainstorms to identify causes associated with each of the factors. Typically, this is repeated by employing the 5-times why rule. Quite simply, this entails repeatedly asking the question why until the root cause is reached. The 5-times why tool is commonly used by Six Sigma DMAIC (Define Measure Analyze Improve Control) practitioners who as a rule of thumb maintain that in five iterations one can peel away the layers of symptoms to reach the root cause of a problem.
Once this step is completed, the team can then subjectively arrive at the most probable causes by studying the plausibility and/or feasibility of each branch. The team could also choose to assign red, yellow, and green colors to various causes to highlight its likelihood of occurrence. The fish-bone diagram thus provides a comprehensive visual representation of the cause-effect relationship. For a fish-bone diagram for a hypothetical scenario associated with high turnover of triage nurses, see the illustration above.
Decision matrix. A decision matrix is a team-based brainstorming tool that can help to evaluate and prioritize a list of alternatives. A decision matrix can also come in handy when decisions need to be based on several criteria. A set of criteria is established first by the team to evaluate the alternatives. Each criterion is then assigned a weight based on importance. Typically, the higher the weight, the more the importance associated with a criterion. A scale of 1–100 could be used for weighing the criteria. The team then evaluates each alternative for each criterion. A ranking/ rating scale of 1–10 can be used to compare alternatives for a given criterion. Again, the higher the score, the better the alternative. The weighting and ranking scores are then multiplied to calculate the weighted evaluation. Subsequently, the summation of the weighted evaluations can help identify the best possible alternative in a quantitative matter. An electronic spreadsheet, for example Microsoft Excel, is best suited for a decision matrix. Below is a decision matrix involving the selection of a health care waste removal vendor.
A simplified example of a decision matrix
|Clean Co.||Green Inc.||Fast Clean Ltd.|
|Weight||Rating||Weighted evaluation||Rating||Weighted evaluation||Rating||Weighted evaluation|
Value stream mapping. VSM is a tool that can be used to identify sources of wasteful activities in a given process. Once identified, specific corrective actions can be initiated to remove the source of the waste. Researchers report that VSM can help to reduce cycle time and costs while improving quality. With use of specific symbols, a map can be drawn which highlights bottlenecks in the process from start to finish. Software packages such as Visio, eVSM, iGrafx and, Edraw Max could be used to draw value stream maps. Furthermore, the waste can be quantified in terms of waiting time between various process steps. A cross-functional team, involving people with different functional expertise working toward a common goal, is indispensable for the success of VSM. For a hypothetical application of VSM in an emergency room, see the illustration below.
An example of a current state value stream map
Guidelines to perform analysis using VSM include:
- Creating current value stream map to identify existing problems.
- Quantifying wasted efforts preferably in terms of wait/inventory time.
- Brainstorming possible corrective actions.
- Creating the ideal future state map with an assumption that corrective actions will be implemented.
- Quantifying new wait/inventory time and potential improvement/difference between current state and future state.
- Implementing the corrective actions.
- Verifying whether corrective actions had the anticipated effect.
Failure mode effect analysis. Failure mode effect analysis (FMEA) is a technique that was first used by the U.S. military. Today this systematic proactive tool is used in a whole range of industries, including health care. In fact the Joint Commission on Accreditation of Healthcare Organizations’ Standard Req. L.D. 5.2 is dedicated to Health-FMEAs. Stalhandske et al. (2009) illustrated numerous examples where FMEAs have been implemented in a health care setting.
Failure mode effect analysis form sheet template
FMEA is a cross-functional, team-based approach for identifying risks in a product or a process. Once the risks are identified, they are pro-ranked. This is followed by identification of preventive and/or detection actions by the team collectively. Just as with VSM, once the actions are implemented risks need to be re-evaluated to establish whether or not they had the desired effect. Three important terms associated with FMEA are:
- Failure modes — describing what can go wrong.
- Failure causes — reasons for manifestation of the failure modes.
- Failure effects — consequences of failure modes to higher level systems/assemblies.
The risks are ranked in terms of a risk priority number (RPN). The RPN is a multiplicative product of severity (S), occurrence (O), and detection (D) associated with a specific risk. S can be described as a quantification of effects associated with a failure mode. O can be defined as a likelihood that a failure cause would happen given the preventive measures in place. D can be defined as likelihood that a failure cause or the associated failure mode can be detected given the detection measures in place. The S, O, and D are assessed on a scale of 1 to 10, where 10 is the worst case rating. Ranking/valuation tables for S, O, and D are published by various organizations such as the Society of Automotive Engineers.
The five tools presented could be very useful for health care managers and providers alike. It is worth reiterating that all of these tools require a team effort, especially cross-functional, efficient teams. Team members using these tools can be classified as:
- Core members: A group of 4 to 6 people without whom progress cannot be made. Core team can be assisted by knowledgeable moderator who can guide them.
- Ad hoc members: Subject matter experts invited as needed.
Continuous improvement through product engineering tools
While the VSM and FMEA are proactive in nature the IS-IS Not, fish-bone diagram and decision matrix can help solve problems that have already occurred. With the increasing demands on health care resources, continuous improvement is critical to the economic feasibility of any health care organization. These five product engineering tools could prove potent supplements to such an effort.
Preetinder S. Gill has more than 10 years of product engineering/management experience in the North American automotive industry. He holds a master’s degree in mechanical engineering from the University of Michigan. His PhD research focuses on health care management.
Our most popular topics on Managedcaremag.com
Paul Lendner ist ein praktizierender Experte im Bereich Gesundheit, Medizin und Fitness. Er schreibt bereits seit über 5 Jahren für das Managed Care Mag. Mit seinen Artikeln, die einen einzigartigen Expertenstatus nachweisen, liefert er unseren Lesern nicht nur Mehrwert, sondern auch Hilfestellung bei ihren Problemen.