DFSS Study: Develop Software to Track Drug Side Effects

Integrating Design for Six Sigma (DFSS), IDOV (identify, design, optimize, validate) roadmap and selected DFSS tools in the information technology (IT) system development methodology can strengthen the business focus of IT system delivery. Adding additional steps at the beginning and end of the traditional system development cycle for DFSS can support the better understanding of the business process and the customer requirements involved, and allow the organization to realize proven business results as well as continuously monitor process metrics.

A pharmaceutical company, Medistar, applied DFSS tools to develop a new pharmacovigilance system (captures and analyzes observed drug side effects) in association with the launch of a new drug. Such a system is necessary since after its market launch a drug is exposed to a much larger population than in the clinical studies conducted during the drug development. This can lead to a change in the known safety profile of a drug. Medistar recognized the need for an updated system using newer technology. Under the old system a physician manually completed a registration form and mailed it to the respective field service agent who then transferred the information manually into yet another system. The information regarding the adverse effect was then forwarded to the pharmacovigilance team. This process was slow, cumbersome and could take several days – too long given the potential consequences of an unidentified risk.

With the launch of the new drug Medistar wanted to play it safe – every side effect should be immediately identified and addressed. From capturing all relevant patient data to the medical director making a decision, all major process steps and influence factors were in the process-scope of the project.

The Identify Phase

At the beginning of the identify phase the project sponsor, the medical director of Medistar and the project manager agreed on a team with representatives from the IT department and pharmacovigilance organization. One of the team’s first tasks was to identify the system needs and what business processes it needed to address. The goal was to understand the process, its internal and external customers and their requirements before developing the system. Therefore, the team developed a high-level process map using SIPOC (suppliers, inputs, process, output, customers). The developers of the SIPOC map recognized that not every adverse event would necessarily entail a counter measure.

Figure 1:SIPOC

The next step was comprehensive voice of the customer (VOC) data collection. The team interviewed representatives from the pharmacovigilance teams, the medical director and the chief executive officer of the company. Most of the customers immediately referred to IT software requirements instead of expressing their needs and expectations with regards to the business processes lying behind the system. Only by repeatedly challenging the answers were the customers’ true process related needs identified. The team translated those requirements into measurable CTQs (critical to quality), which served as the basis for defining key performance indicators (KPIs) for the new pharmacovigilance process.

The translation of customer needs into CTQs and their prioritization was done using quality function deployment (QFD). Accordingly, the two main CTQs of the “should-be” process were the time between a side effect (or event) reported to Medistar and notification of the medical director, and the frequency with which the medical director could make a decision based on this information.

Figure 2: QFD 1

All CTQs were summarized with target values and tolerances in a design scorecard. This was used throughout the project to measure and document the system performance. Since the company already had a pharmacovigilance system in place (with reduced functionality), as-is performance data for the first four CTQs were collected and included in the scorecard.

Figure 3: Design Scorecard

The Design Phase

At the beginning of the design phase, the team created a detailed process of the should-be process. This showed detailed process steps and responsibilities as well as first requirements with regards to the new pharmacovigilance system.

Figure 4: Should-be Process Map

Using this map the team started defining the user requirement specifications (URS) for the system. In a workshop with previously interviewed customers URS were identified and – in order to ensure that all previously identified CTQs were considered – a QFD 2 matrix was used to map and prioritize the URS against the CTQs. The main priorities from a user perspective were a user-friendly input mask and the ability to automatically create summaries and detailed reports.

Figure 5: QFD 2 CTQs and User Requirements

In addition to the above requirements other technical, system and data requirements were defined. For example, the system should include a security system with user access, including permanent access to all information for the health authorities and other specific standards imposed by the company.

On the basis of this information an initial conceptual design of the new pharmacovigilance system was developed, and it was revealed that an off-the-shelf solution was not available. An existing software system, however, could be customized to meet the needs.

Another important step in the design phase was the development of functional specifications in accordance to the previously described system requirements. The team opted for the application of QFD 3, as this could guarantee traceability of the requirements. The team began to define service level requirements for the future maintenance and support organization of the pharmacovigilance system.

The Optimize Phase

The optimize phase was typical for a software development project. It included a detailed adaptation of the software according to the customer needs and the establishment of necessary testing and validation procedures. For the description of test cases the previously created QFD 3 was helpful and provided an overview of system requirements and functional specifications.

The Verify Phase

The added value of DFSS tools in the last phase of software development was to ensure the effective handover of the IT system to the process owner – the head of the pharmacovigilance team.

In coordination with the team leader, the project team developed a dashboard to monitor the process performance. Based on previously defined CTQs key performance indicators (KPIs) were defined – how often they had to be calculated, by whom, and to whom they had to be reported.

Graphic 6 provides an overview of the different aspects of the dashboards.

Figure 6: Dashboard Definition

During the verify phase the users were trained on the new system and the old pharmacovigilance system was shutdown. The transition from the old system to the new went well and was in place prior to Medistar launching the new drug.

Continue reading

Creating a Recruiting Process: DFSS for Process Design

The following case study illustrates how a pharmaceutical company applied selected DFSS (Design for Six Sigma) tools to develop a new recruiting process for sales representatives. Tools and activities are described along the IDOV (Identify, Design, Optimize, Verify) phases, which served as a guiding roadmap through this process design project.

Identify

The need to completely redesign the recruiting process resulted from two weakness in the existing process. First, with an average of 60 days to fill a vacant sales representative position, it simply took too long. Second, due to a growing market in the upcoming three years, an increase of the sales force by 10 percent was planned, and the company wanted to organize its hiring process to make it as effective and efficient as possible.

Every day without a sales rep in a specific region meant a significant loss of revenue. Therefore, all vacant positions in Europe were in scope of the project. The process cycle time was measured from the point of time when the previous sales rep quit the job until the first working day of the new sales rep.

Under the project lead of a human resources (HR) associate, a team with representatives from sales and HR was established. Additionally, a steering committee with members from the same departments and from IT and Controlling was set up. They would meet at the end of each IDOV phase to review the project progress and to make go or no-go decisions for the next phase.

As one of the first steps, the team conducted a voice of the customer (VOC) data collection. Twenty district managers and four HR representatives who had all been involved in at least one recruiting process in the past were interviewed. The main questions to determine the customer needs, their relative importance and measurable CTQs (critical to quality) were:

◈ Which aspects of the recruiting process are important to you?
◈ On a scale from 1 – 5, how important are these aspects for you?
◈ How would you measure that the process is performing according to your needs, and how would you know that your expectations are not met?

The results from this internal VOC were structured via quality function deployment (QFD), as shown in QFD 1 in Figure 1. This showed that in addition to the recruiting cycle time, the most important CTQs were:

◈ How often the new employee could already be selected during the first interview round (i.e., no need to run a second round of interviews)
◈ How long it takes to establish the interview schedule
◈ How often the new employee agreed to the initially offered compensations and benefits (i.e., no re-negotiation of the contract)

Figure 1: QFD 1

The most important CTQs were summarized in a design scorecard (Figure 2). Using historically collected data, a first baseline could be established that showed the performance of the customer requirements at the project start. This baseline information was also used to set the project goals.

Figure 2: Design Scorecard

Design

At the beginning of the Design phase, the team conducted a functional analysis. In a process design, functions are the high-level process steps. Developing functions enabled the team to define the necessary steps of the recruiting process without immediately having to think about solutions, detailed concepts or a detailed process design.

The team used a function tree (Figure 3) to analyze the process steps. This allowed for a definition of the process on levels 1 and 2.

Figure 3: Function Tree

In order to determine those functions that would contribute most to meet the customer requirements, the team used the QFD 2 (Figure 4). This highlighted that the next step, the detailed process development, should mainly focus on these process steps:

◈ Create requisition

◈ Interview candidates

◈ Prepare compensation and benefits package

Figure 4: QFD 2

Optimize

The Optimize phase started with the detailed process design. Using a deployment flow chart, detailed process steps, roles and responsibilities for the previously prioritized level 2 processes were defined. Figure 5 shows the process for planning and conducting the candidate interviews as an example.

Further detailed process design elements were:

◈ Conduct an agency briefing meeting with HR, the hiring district manager and an external agency

◈ Standardize the number of interviewers and interviewees

◈ Parellelize the processes, interview candidates and prepare the contract

Figure 5: Detailled Process Mapping

Furthermore, detailed design elements in the categories of information systems, human resources and templates and tools, as well as supplier quality were developed for the same five prioritized processes steps. Figure 6 shows these design elements per process step. Among others, the team decided to establish an internal talent data base, to develop and conduct mandatory interviewer trainings, to create specific templates and guidelines for interviews, and to collaborate only with pre-qualified agencies.

Figure 6: Detailed Design Elements

As a last step in the Optimize phase, a risk analysis for the new process was conducted using the failure mode and effects analysis (FMEA) approach. The objective was to identify potential failure modes and their potential causes upfront so that appropriate mitigation actions could be determined. An extract of this FMEA is shown in Figure 7.

Figure 7: FMEA

Verify

The DFSS team piloted the implementation of the new recruiting process in three regions and collected new data for the CTQs. They also gathered and analyzed information with regard to the highest prioritized failure modes from the FMEA. In doing this, they wanted to validate what the critical process steps were that had to be controlled as leading indicators of the desired (lagging) process performance.

Based on the pilot experiences, the team made final modifications of the process. Among others, they decided to have the contract already prepared before the second interview date (even if that meant that up to three contracts had to be created in case three candidates were still left). All critical process steps, leading and lagging indicators, and a reaction plan were summarized in a process management chart (Figure 8).

Figure 8: Process Management Chart

After this successful completion of the pilot phase, the team handed the new process over to the process owner, in this case the head of HR. She was responsible for the implementation of the process in Europe. Six months later the first results of the implementation could be measured, and they fully met the expectations of all stakeholders.

Continue reading