IT and Quality Partnership for Compliance, Effectiveness and Efficiency
In the medical device industry, to deliver safe, effective products to the marketplace and be compliant to global laws and regulations, IT and Quality must work together to design and implement systems that deliver real time data, reporting, and analysis to support the Quality Management System. Integrated Quality Management System (QMS) applications, product life cycle applications, manufacturing execution system (MES) applications are large systems that require extensive, complex design, configuration, and implementation. Either function operating in a vacuum leads to creating workarounds, manual processes and increased head count resulting in inefficiencies and potential compliance gaps. This article will explore what a QMS is, why IT and Quality partnership is critical, and lessons learned from previous QMS implementations.
What is a QMS?
American Society for Quality defines a QMS as a formalized system that documents processes, procedures, and responsibilities for achieving quality policies and objectives. A QMS helps coordinate and direct an organization’s activities to meet customer and regulatory requirements and improve its effectiveness and efficiency on a continuous basis. The QMS is made up of various subsystems that control and monitor all stages of the product from design to customer feedback and field data. These subsystems are integrated and connected. That is to say that inputs and outputs move between these subsystems. See figure 1 for a high level QMS process map that illustrates the integration and connectivity. These subsystems are unique processes with their own set of requirements and deliverables.
To be a valuable and engaged partner, you must have an understanding of the QMS Architecture and of the laws and regulations that govern it. Architecture shows how subsystems interact with each other. The laws and regulations dictate requirements and what evidence is needed from the QMS. Generally the evidence comes in the form of records and reporting. Due to schedule and budget constraints, IT systems can be implemented without fully understanding what is needed and required. In addition to regulatory requirements, scalability (for harmonization, acceptance, and implementation within other business units of the corporation as well as acquisition integration), and ease of use require consideration and due diligence.
To be a valuable and engaged partner, you must have an understanding of the QMS Architecture and of the laws and regulations that govern it
Figure1: Quality Management System Map
The following lessons have been learned from previous QMS application implementations:
Lesson #1: Mapping the processes. Before purchasing, designing or configuring any application to support the QMS, the targeted subsystem(s) must be processed mapped. Processing mapping identifies inputs, outputs, interfaces, data flows, improvement opportunities, efficiencies, and reporting.
Lesson #2: Extensive end-user involvement. End-users are critical in process mapping and truly understanding how a process works. Often managers and higher levels of the organization have a perspective on how they think a process works versus how it actually works. To learn a process, talk to the people that work with that process.
Lesson #3: User Requirements. The requirements (especially reporting) that come from process mapping provide user requirements. The amount of reporting and reporting flexibility (ad hoc) can surprise application implementation teams. Quality processes and oversight demands real time data for some processes and extensive reporting for most processes. Outputs from lessons 1 and 2 above feed right into the User Requirement Specification. This key process and document drives the application design or purchase. The work and effort put into these first 3 lessons will pay handsome dividends.
Lesson #4: Application field helper text and guidance. Evidence of QMS compliance is often records. Good, defendable records are accurate, correct, complete, and stand alone. Application fields are often open text fields. Is this a good practice? Where data and options are static and predictable, drop down fields work great. You will never be able to completely get away from open text fields. Helper text in the field indicating what should go into the text field will mitigate record compliance issues.
Lesson #5: Piloting before go-live, fully utilizing the test environment. Piloting new processes and new applications minimizes issues, problems, mistakes, and delays. Most application development processes use a development environment, test environment, and production environment. Allowing end-users to pilot the application in the test environment yields useful feedback on what doesn’t work as intended, missing linkages, process alignment with the application (timing issues), and bugs/issues not anticipated.
Lesson #6: QMS application workflows right out of the box. Several companies in the QMS application space offer products that have defined workflows. These companies market these products as best practices and compliance. They also have various levels of programming and configuration available to customize and meet organization needs/requirements. The organization should robustly challenge itself to determine whether they will alter their processes and adopt the workflows out of the box or change the application to match their processes.
Lesson #7: Maintenance and changes. All QMS applications will require maintenance on a regular basis and changes. Quality should have input and oversight on maintenance and changes to QMS applications. Things to consider: Does the maintenance or change impact the validation of the application? What validation scripts need to be executed to prove that the application is still in the validated state? Will any of the changes impact requirements and cause compliance gaps? Is there any impact on the records or reporting? Do maintenance and change activities follow an approved process with appropriate documentation?
Lesson #8: Defending the system. The medical device industry is constantly inspected and audited by global regulatory agencies. During these activities, both Quality and IT are required to defend their systems. Quality will defend processes, execution to those processes, evidence of meeting requirements in the form of records and reporting. IT will defend application validations, interface validations between applications, report validations, Part 11 Compliance, data backup and security.
In conclusion, there is a critical need and opportunity for Quality and IT to join in partnership to focus on delivering QMS applications that meet regulatory requirements, are efficient and easy to use. As in most IT and Quality discussions the end-user is key in identifying and capturing requirements. These strategies drive delivery of safe, effective products to the market to help patients around the world. Value and compliance (cost avoidance) are additional benefits to the organization.