1. Introduction

As healthcare costs keep increasing and governments are encouraging to adopt EMRs, healthcare organizations are currently at variant stages in their automation with the goals of reducing costs and increasing operational efficiency. One challenge they face is how to adapt their current business processes to a computer-centred model of operations. Merely taking existing business processes and transferring them from paper to computer will not yield a high return on investment (ROI). This ROI, while eventually can be translated into monetary value, can also be looked at as increase in efficiency, reduction of medical errors, and reduction of process time. Recent studies show that waste in the U.S. healthcare system costs as much as $700 billion annually (Poole, 2010).

In this paper, the focus is on the role the Systems Analyst (SA) can play in contributing to identifying problems with current business processes and designing the right systems that will yield the desired results. Furthermore, it is proposed that SAs familiarize themselves with Lean Quality Management approaches, specifically Six Sigma, and apply it during the requirements gathering, analysis, and system design phases of the System Development Life Cycle (SDLC). Six Sigma is being used more each day in all aspects of healthcare ranging from applying it to improve diagnostics of chest pain (Kumar & Thomas, 2010) to improving surface precision of optical lenses in the injection-molding process (Lo, Tsai, & Hsieh, 2009).

With a significant number of tasks being automated, the role of a SA and a business analyst can merge together, and therefore, the system analyst must be capable of performing the role of a business analyst, with the added benefit of the deep understanding of technology. This helps the SA assess the potential value of automation and design the system accordingly.

Six Sigma can be helpful for SAs both when designing a new system or assessing modifications to current systems. While using some of these measures might prolong the period of requirements gathering and system analysis and design, they can ensure that the system addresses all the potential problems in the organization which the system can resolve. This saves organizations from transferring current processes from paper to computers without solving current problems, but rather adding potential system problems on top of existing ones due to expected system failures and cost & time of implementation.

1.1 What is Six Sigma?

Six Sigma’s core philosophy focuses on reducing variability of outcomes and measuring quality in terms of defects in production or services processes, with the ultimate goal of reaching 3.4 defects per million products/services, or 6 standard deviations from the process mean, hence the name Six Sigma.

By implementing tightly controlled processes, Six Sigma aims at reducing output variability, through providing clear approaches and tools to define problems, collect and statistically analyze data to determine sources of variations and opportunities to improve. After that, business processes are either modified or completely reengineered to resolve problems, while being constantly monitored to evaluate the success of the changes. (DelliFraine, Langabeer, & Nembhard, 2010)

Six Sigma provides a general approach to quality improvement such as DMAIC and DMADV with the support of many tools including SIPOC, FMEA, Fishbone Diagrams, and Root-Cause Analysis to name a few. All these tools are utilized to reach conformance to customer requirements, eliminate defects, and reduce process variability.(DelliFraine, Langabeer, & Nembhard, 2010)

1.2 History of Six Sigma

There are several predecessors that influenced the inception of Six Sigma dating back to the 1700s when Carl Fredrik Gauss introduced the concept of the normal curve, and then in the 1920 when Walter Shewhart proposed that three sigma from the mean is the point where a process requires correction when looking at product variations in manufacturing. later, many quality measurement tools were combined to reach the modern definition and frame work of Six Sigma. (ISixSigma, 2011)

Six Sigma was developed in the mid-1980s at Motorola as a methodology to reduce errors in manufacturing. Only until 1999 that Six Sigma became popular in Healthcare. (DelliFraine, Langabeer, & Nembhard, 2010). After implementing Six Sigma, Motorola reported that by implementing it, they were able to save more than $16 Billion up to date. (ISixSigma, 2011). Since then, Six Sigma has been adopted world wide by various organizations and industries. By late 1990s, two thirds of the Fortune 500 companies began Six Sigma projects to improve their internal operational efficiency.

1.3 Importance of Six Sigma for SAs.

A question that might be asked here is, How can Six Sigma benefit a SA? Personally, I prefer to phrase the question differently to: Why should the SA understand Six Sigma? (Poole, 2010) provide a good answer stating that it is important to look at processes in light of automation. Applying technology alone does not improve processes. If we automate existing processes exactly as they were done manually, we would miss out on all the potential that automation can provide us. “Key Process input Factors from suppliers and their performance requirements may be overlooked” (Karr, 2011). Business Process Reengineering can be defined as the first primary benefit of using Six Sigma methodologies to document and analyze user and system requirements.

The second major benefit can be considered the improved and automated monitoring over each step/process. Monitoring process efficiency cannot take place without systems that collect and properly process the needed data. For example, a study conducted in a Residency Clinic showed that observing and implementing incremental changes in workflow can significantly improve efficiency. A direct correlation between process efficiency and patient compliance with scheduled disease management appointments was concluded (Fischman, 2010). This means two things for SAs: A) SAs must understand the details of the process and the factors that affect efficiency, and B) design systems that facilitate quality improvement by adding quality measures and controls in the systems they design.

A third major benefit of adopting a Lean Six Sigma approach to software design in Healthcare lies in the need for adaptive and scalable systems that can keep up with Continuous Quality Improvement measures. SAs must design systems with a controlled, yet high level of customizability. This serves to keep up with the dynamically changing requirements. Quality Improvement should be at the heart of designing software for clinical settings.

Lastly, since a Six Sigma approach to documenting business processes tends to go beyond the direct system boundaries, fundamental shifts in how healthcare is being delivered, such as Participatory Medicine, would alter our definition of an EMR user. While clinicians are the direct users of the system, patients are one of the primary customers of the system outputs, and therefore, a SA must design a system in a way that captures, processes, and outputs data that contributes to the goal of improving a patient’s health and improves the quality of care.

2. Evaluation of Six Sigma

2.1 General Methods:

There are two general methods followed in a Six Sigma Project, DMAIC and DMADV. Each is defined in the following sub-sections with examples of their use in healthcare and how understanding those approaches can help a System Analyst design a better system.

2.1.1 DMAIC

Various organizations such as the SSFHS which owns 13 hospitals and a number of other facilities in Indiana and Illinois have a comprehensive Lean Six Sigma program where they utilize DMAIC for many internal projects (Poole, 2010). Moreover, DMAIC was used by a group of Nurse Practitioners to examine and expand their role in improving patients’ healthcare during and post-hospitalization. The recommendations included greater nurse involvement in patient education and counselling, as well as improving communication with patients (Kumar & McKewan, 2011). DMAIC is used for studying and modifying existing business processes and it consists of five phases. The following is an example of how DMAIC can be used to help the SA design a better system that will improve operational efficiency in the Operating Room:

  1. Define: where the problem is defined in terms of the customer’s requirements and the project’s goals. This can help the SA understand the problem or process that the system is supposed to address and resolve. Let us assume that our problem was defined as poor pre-operative, intra-operative, and post-operative documentation.
  2. Measure: where data and aspects relating to the current process are gathered and presented in a measurable form. This helps the SA quantify the problem and the shortcomings. In our example, let us assume that we identified that 50% of surgical complications were due to poor documentation.
  3. Analyze: where we analyze the data gathered, define the relationships and perform Root-Cause Analysis to pinpoint defects within the current process. In our scenario, the SA discovered through the Root-Cause Analysis that poor documentation was caused by incomplete or improperly filled forms.
  4. Improve: where the process and current systems are re-designed to address the problems identified in the previous phase. This helps the SA in utilizing automation to address and reduce or eliminate the problems identified in the Root-Cause Analysis. In our scenario, the SA would include field checks in the system that ensure all mandatory fields are filled, and also that, where applicable, limited data entry options are used (e.g. Drop-down menus), to ensure that no incorrect information is entered. In this way, the system design becomes more relevant to solving real problems in a hospital.
  5. Control: where the process in the system is designed to monitor and report any deviations in real-time. This helps the SA in adding more controls to the system that simplify process monitoring and implementation of corrective measures. In our scenario, monitoring and controls can be in the form of an automated Decision Support System that allows chart reviewers to mark improperly filled fields and A) send automated reports to the physicians, and B) collect historical data of which fields where filled out improperly the most, and alert users when filling them out.

2.1.2 DMADV

DMADV is used when designing a new product or process and it also consists of 5 phases. The following is another scenario from healthcare where employing such a methodology can help the system analyst when designing a system for a new process to allow patients access to their EMRs:

  1. Define: where we define the purpose of this new process. In our case, this would be a definition of patients’ needs to access their EMRs.
  2. Measure: where we identify aspects that are Critical to Quality, risks, and technological limitations. For a SA, this means understanding what current technologies can offer to allow patients access to their EMRs (e.g. Extracting information from the local database and viewing it in a Web Browser, with the proper authentication), and assessing the risks attached to providing such access over the internet.
  3. Analyze: where we create the high level design of the system. This is where the SA creates the abstract of the system, outlining the major components and functionality. In our case, those would include defining the different objects and components of the system, which include, but are not limited to, Personal Health Information, Access Policies, Technologies to be used, overall processes for access, and authentication.
  4. Design: where we create the specific details of each process, step, and screen in the system. This is where the SA would dive into the details of the system.
  5. Verify: where we test the design to ensure that the system meets the goals, within the set controls. This is where the SA may discover gaps in the design, and go through multiple iterations with the developers to ensure that the system operates at an optimal level and that patients are able to access their PHI securely, and in a fashion that helps them read and understand the provided information.

2.2 Tools:

Throughout the DMAIC and DMADV phases, Six Sigma provides a variety of tools that can be used to document and analyze business processes. This section looks at four tools and outlines how a SA can benefit from each one when designing a system in a healthcare setting.

2.2.1 SIPOC (more relevant to a complete system implementation)

SIPOC is a Six Sigma tool for documenting business processes. A SA can use SIPOC to document the current state of a system and the user requirements. It is important to identify the needs of clinical employees and designs systems and processes in a way that enables them to focus on their core work. Examining processes cross-departmentally will reduce waste, including overproduction of medication, procedure kits, or recording the same information about a patient several times (Poole, 2010). SIPOC can help a system analyst achieve that through its highly structured approach that mimics in a way how a system works, per user and across all the departments that use the system. SIPOC stands for:

  • Supplier: in the case of a system, the supplier here indicates the entity that provides the initial information to initiate a process. Let us assume that the supplier is a Physician who wants to write a prescription for a patient.
  • Input: the data and instructions provided by the supplier that trigger the process. This helps the system analyst identify the initial system inputs in detail. In our scenario, the input would be the different data elements recorded in the prescription including medication name, dose, frequency, etc.
  • Process: this is where the process is outlined in detail. Combining additional quality measures about each step in the process can help the SA not only in understanding the business process, but also understanding the data elements of each step, the business rules, and key performance indicators and controls at each step. Implementing controls such as drug-drug interactions can help alert the physician if he/she was not aware of a specific medication that the patient is currently taking.
  • Output: the data output of the process. This can help the SA in designing the specific aspects of the system outputs including reports. This can be the prescription with instructions, as well as inventory reports inside the pharmacy.
  • Customer: the customer who receives the outputs of the process. This can include individuals, organizations, and even databases. This helps the system analyst understand the customer of the outputs and modify the design of the system to meet the goals of that customer. In our case, the customer is the patient receiving the instructions, the pharmacy department with the aggregated dispensing reports, and the database of the Pharmacy Information System.

2.2.2 FMEA

FMEA stands for Failure Mode and Effect Analysis which is a procedure for analysis of potential failure modes within a system, then classifying the identified risks by severity and likelihood to occur. FMEA is more focused on analyzing historical data to identify mistakes in the past and avoiding them in future products/processes. Failure Modes can be defined as errors in a process, design, or product, both potential and actual, while Effect Analysis is the process of identifying and outlining the consequences of those errors. Computerized medication systems can help identify patterns of medication dispensing delays, pin point the root cause and minimize the problem (Karr, 2001).

For a system analyst, FMEA can be used in two ways, A) in assessing the risks involved in the process of designing and implementing a system and B) in reviewing the documented business processes and identifying the shortcomings of these processes and including controls in the system design that will reduce or eliminate those errors.

The first step in FMEA involves filling out the FMEA Worksheet which is a standard template that lists each function in a system/process, potential failure mode and effects, potential causes, occurrence rating, and current controls to name a few. The second step is to analyze the occurrences and causes of Failure Modes. This is done by benchmarking to similar processes and products where each Failure Mode is documented and rated on a scale from 1-10 where 1 indicates No Known Occurrences and 10 being Very High where failure is almost inevitable. This can help a SA anticipate, from experience and comparing similar systems implemented, what are the most problematic areas and plan accordingly.

The second step in FMEA is assigning and analyzing the severity of each Failure Mode on the process itself, which leads to the definition of Failure Effects in functional terms. Again, a scale of 1-10 is used to assess the severity of each Failure effect with 1 indicating No Effect and 10 indicating that the process or system might be hazardous or will seize to operate. This can help the SA prioritize which Failure Modes to address first, especially when there is a lack of resources and the system has to go through multiple iterations during development.

The third and final step in FMEA is the detection and testing of the efficiency of new system functionality and process modifications in reducing or eliminating those Failure Modes. A 1-10 scale is used to assess the potential for catching an error with 1 indicating with certainty that the error will be caught during testing and 10 indicating that the error will not be detected during testing. For a system analyst, this could be a good tool to think about when designing the system as it will affect the Quality Assurance measures and user acceptance testing.

2.2.3 Root-Cause Analysis (more frequently used to address specific problems but can be used for wider scopes)

Root-Cause Analysis is another tool used in Six Sigma to help identify the reasons why a certain problem occurred, the characteristics of the problem and what needs to be changed to prevent this problem from happening again. For a SA, this is very important during the design phase of any system after the business processes have been define. Understanding the root causes and their characteristics can help the SA incorporate controls and functions in the system that help prevent those problems in the future. With healthcare being a highly specialized industry, one of the important skills that an SA must have is a clear understanding of the terminology and processes, which will allow the analyst in turn to communicate with clinicians and better understand the root causes.

Root-Cause Analysis has several steps that start with defining the problem, then gathering qualitative and quantitative data, followed by identifying the cause(s), then classifying those causes. After that, correction actions must be outlined and the most effective solutions are implemented and evaluated. This helps a SA evaluate all the possibilities in designing a system and selecting the most appropriate solution. For example, when designing a Pharmacy Information System, if historical data shows medication errors were related to unclear instructions, the analyst can design a system that captures and displays data in a structured and unified manner that eliminates confusion. Solutions could include check-boxes, drop-down menus, or smart lists that provide suggestions as a clinician starts typing. Making a decision on which option is the best should be based on which option has the least potential for errors while being the most user friendly.

One of the structured approaches that can be used under a Root-Cause Analysis is the Management Oversight Risk Tree, which can be very helpful for a SA in understanding the bigger picture of the environment for which the system is being developed. It presents several key topics that must be taken into account including but not limited to materials, man power, equipment, environment, and methods.

2.2.4 Cause-and-Effect Diagram (Ishikawa Diagram)

The Ishikawa or Fishbone Diagram is another tool used in a Six Sigma study that helps identify the causes of certain events. In this approach, multiple potential causes which yield an undesired result are analyzed. Causes in the Ishikawa Diagram are classified under six major categories including People, Methods, Machines, Materials, Measurements, and Environment.

For the items above, there are several questions that could be asked in order to gain a better understanding of the causes and their effects. Those questions include inquiries about communication, compliance, use of appropriate tools, use of appropriate measures, was sufficient training provided, etc. For a SA, a lot of these questions can provide a much clearer picture of the organization, its practices, and potential areas where automation and system controls can eliminate those problems.

2.2.3 Criticisms of Six Sigma in Healthcare

While there are a number of criticisms of Six Sigma, the focus here will be on those relating to its use in Healthcare. One study concluded after a literature review of 177 articles on Six Sigma and Lean Methodologies in healthcare, over the past 10 years, that only 34 reported positive outcomes and only on third of them included statistical evidence linking approaches to outcomes (DelliFraine, Langabeer, & Nembhard, 2010).

Applying new methodologies in healthcare can have a different set of challenges, that can be independent of the shortcomings of those methodologies themselves. For example, in order to control a process, it must be clearly defined and standardized. As stated by (Karr, 2001), clinicians object to the term “Standardized Work” while it is the same in a way as “Best Practices”. Since Six Sigma lacks industry-specific terminology, using new expressions not used in healthcare might communicate the wrong idea. Therefore, the SA must be aware of the industry’s terminology equivalents and use those instead.

Another criticism for Six Sigma and quality methodologies in general, as outlined by Poole (2010) is that quality standards in other industries do not apply to healthcare. While this is true in terms of specific measures implemented to resolve problems in those other industries, the approaches and frameworks are still transferable to quality initiatives in healthcare, and to system analysis and design for healthcare as well.

3. Conclusion

While there are criticisms for applying Quality Improvement measures from other industries to healthcare, we can conclude from the examples provided above that using Six Sigma can yield high improvements to business processes in healthcare. Specifically, SAs responsible for gathering requirements, analyzing processes and designing systems need to follow structured approaches that will help them design systems that solve current problems and implement controls that help monitor current processes.

Using approaches such as DMAIC and DMADV along with specific tools such as SIPOC, Root-Cause Analysis, Cause-and-Effect Diagrams, and FMEA can add high value to the work of a system analyst when assessing modifications to currently implemented systems as well as when designing new systems. Adopting a Continuous Quality Improvement approach can help the SA think of incorporating scalability and flexibility aspects that simplify system modifications that meet the ongoing quality studies.

4. References

DelliFraine, Jami L., Langabeer, James R. II, Nembhard, Ingrid M. (2010). Assessing the Evidence of Six Sigma and Lean in the Health Care Industry. Quality Management In Health Care,19(3), 211-225

Fischman, D. (2010). Applying Lean Six Sigma Methodologies to Improve Efficiency, Timeliness of Care, and Quality of Care in an Internal Medicine Residency Clinic. Quality Management In Health Care, 19(3), 201-210.

KARR, T. (2011). DETERMINING WHAT HEALTHCARE SHOULD BE. Industrial Engineer: IE, 43(9), 45-48.

Kumar, S., & Thomas, K. M. (2010). Utilizing DMAIC Six Sigma and Evidence-Based Medicine to Streamline Diagnosis in Chest Pain. Quality Management In Health Care,19(2), 107-116.

Kumar, S., & McKewan, G. W. (2011). Six Sigma DMAIC Quality Study: Expanded Nurse Practitioner’s Role in Health Care During and Posthospitalization Within the United States. Home Health Care Management & Practice, 23(4), 271-282. doi:10.1177/1084822310388385

Lo, W. C., Tsai, K. M., & Hsieh, C. Y. (2009). Six Sigma approach to improve surface precision of optical lenses in the injection-molding process. International Journal Of Advanced Manufacturing Technology, 41(9/10), 885-896. doi:10.1007/s00170-008-1543-0

Poole, K. (2010). THE GRADUAL LEANING OF HEALTH SYSTEMS. Industrial Engineer: IE, 42(4), 50-55.

ISixSigm, The History of Six Sigma (2010). Retrieved December 5, 2011 from http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1505:the-history-of-six-sigma&Itemid=155

Tagged with: • • • • • • • • • •

Like this post? Subscribe to my RSS feed and get loads more!