Four Levels Of Project Management In Healthcare

As seen in the August 2011 edition of Life Science Leader magazine.
By Peter Smith, Ph.D.

Project Management in the healthcare industry has its own set of challenges. These arise from the industry’s need to comply with a series of international regulations which ensure the health and safety of patients. The FDA and international agencies enforce compliance with these regulations by means of random audits. The consequences of non-compliance can be quite severe, ranging from fines to a halt in production. It is this extra burden of regulatory compliance and the resulting additional levels of complexity, especially the need for copious documentation, which make projects in healthcare take at least twice as long as equivalent projects in other industries.

The Four Levels
To understand how this plays out, I will focus on the area of computer systems development in healthcare and will make the case that there are four levels of project management going on in parallel in this environment. These are (1) a classical project management process, (2) a systems development process, (3) a validation process, and (4) a qualification process.

Classical Project Management
This is what we learn in project management 101 — charters, resources, timing, work breakdowns, communications, budgeting, issue resolution, and closure. All these skills are in play, and the overall success of the project depends on these. However, there is more.

Systems Development
Developing an IT system in healthcare requires a formal development process which the regulatory agencies expect to be defined, published, and executed. The process has to demonstrate control of its environment and the ability to avoid arbitrary decisions that result in unreliable systems that may eventually compromise patient safety. There is no mandate on which systems development methodology to follow (for example waterfall or iterative) as long as one is followed. The tricky part is always the development of user requirements which by nature change and evolve. Once this issue is addressed, the insistence on a defined process provides consistency, reproducibility, and independence from personalities that lead to a quality system. So far there is nothing extraordinary here, but there is more.

Validation
The unique aspect for healthcare now asserts itself because of the need to validate computer systems. Validation is usually defined as demonstrating that a system meets requirements and fulfills its intended use. That’s why system development requirements have to be defined. With the recent growth of the agile rapid development methodology, the relationship between requirements which are by design quickly translated into deliverable code, and the validation of those requirements is still evolving. The word “demonstrating” becomes critical because this means the documentation and testing of requirements and intended use criteria. And this means paper. I often use the analogy of receipts — if I say on my expense statement I spent $30 on lunch while traveling, I need to be able to produce a paper receipt that proves, indeed, this is where and when I spent this sum if the expense is to be accepted by the accountants.

Although the regulations do not specify exactly what has to be done to validate a system, there is a generally recognized set of expectations and approaches, which can be summarized as planning, requirements specification, testing, and reporting. In other words, the approach is planned, and the intentions stated, what is needed is defined and then tested to show that the system meets those needs. And finally, a report is produced to summarize how the plan has been executed. The concept of basing testing on the risks involved (to patient safety) adds another dimension to the discussion. This “best practices” approach is widely accepted and is known as the “V” model. But there is more.

Qualification
It is just as important to demonstrate that the software in use runs on properly supported hardware (i.e. infrastructure). We do not build a house on sand, and we do not run software on uncontrolled hardware. The process of documenting the hardware side of a system is known as “Qualification.” Infrastructure includes not only the physical servers, but the network with its routers and switches, and even the operating systems and middleware that ties it all together. The key distinguishing feature of infrastructure is that it is application agnostic: in other words, the hardware does not care which application runs on it. It is often called a platform; that is, a foundational layer separate from the application layer. Infrastructure is becoming more and more a commodity or a utility, providing computing services to the application layer. As I have discussed in an earlier article on this topic, the segregation of the two sides of the system does not mean they ignore each other. There has to be a “handshake” across the line (which is not a wall), and this handshake is the system requirements document that defines what the application requires, and what the infrastructure experts use to build a system to meet those requirements.

The process of qualification follows the V model with one critical exception: there are no user requirements for qualification since users view the infrastructure as a utility like electricity or water, and how it is delivered is irrelevant. They have no requirements of it other than it is there. And therefore the corresponding testing of user requirements, the performance qualification, is not part of qualification which otherwise requires the same level of planning, designing, testing, and reporting as validation.

The Interactions
So if we recognize these four levels, how do they interact? Basically they run in parallel. In healthcare companies with enough resources, there can be four managers associated with the project: the project manager, a systems development manager, the validation manager and the qualification manager.

The project manager is concerned about budgets, timelines, resources, issues and communication, and ensures the various other managers are on schedule.

The systems development manager is concerned about requirements gathering, coding, testing, building and implementing. Or if this is a vendor supplied system (that is a COTS or commercial off-the-shelf system), concerns include matching requirements with functionality, implementing, testing and releasing. If the system has to be validated, he works closely with the validation manager to share documentation and progress.

The validation manager does not care how the system was built or implemented, but only that it is documented as meeting the user needs and tested for quality, data integrity and security. On the other hand the validation process mirrors the systems development process so there is usually some degree of interchange, for example, in requirements or testing plans.

The qualification manager has an even narrower focus insofar as the project requires him to supply and support a certain level of hardware capabilities which he then implements, tests, and documents.

Clearly the project manager in this environment has to conduct a great deal of orchestration and coordination to make sure all the activities are sequenced and on schedule. He will spend most of his time communicating with regard to the various subprojects, resolving issues, managing resources and budgets, and reporting to the stakeholders who are sponsoring the project.

No one said this is an easy assignment. However, it is not total disarray. There are formal “handshakes” between the streams — the User Requirements from the Systems Development stream form the basis for User Requirements in Validation (although the latter is a quality controlled document). Specifications in Validation form the basis of the Infrastructure qualification. There are also dependencies which tie the streams together: validation cannot be completed until the infrastructure is qualified (testing must take place in a qualified environment). The system cannot be released to users until it is validated.

High Cost, Valuable Benefits
Each of the four activities requires a separate detailed discussion. It is their high-level interaction that is the point here. The cost of this coordination is high but the benefit is the assurance that our pharmaceutical products, drugs or devices have been tested and manufactured to the highest levels of quality, and that the systems that control their production are under control and managed for security, change, and data integrity.

About The Author
Peter Smith, Ph.D., is a project manager with iGate-Patni. He has over 25 years of IT management experience in a variety of international research organizations. Dr. Smith has also been active in several large pharmaceutical organizations in all areas of validation and compliance.