Data Process Mapping

In a presentation on practical applications of data integrity for laboratories at the March 2019 MHRA Laboratories Symposium held in London, UK, MHRA Lead GCP and GLP Inspector Jason Wakelin-Smith highlighted the important role data process mapping plays in understanding these challenges and moving down the DI pathway.

He pointed out that understanding of processes and systems, which data maps facilitate, is a key theme in MHRA’s GxP data integrity guidance, finalized in March of 2018. The guidance is intended to be broadly applicable across the regulated practices, but excluding the medical device arena, which is regulated in Europe by third-party notified bodies.

IPQ. MHRA Inspectors are Advocating Data Mapping as a Key First Step on the Data Integrity Pilgrimage

Data process maps look at the entire data life-cycle from creation through storage (covering key components of create, modify and delete) and include all operations with both paper and electronic records.   Data maps are cross-functional diagrams (swim-lanes) and have the following sections:

  • Prep/Input
  • Data Creation
  • Data Manipulation (include delete)
  • Data  Use
  • Data Storage

Use a standard symbol for paper record, computer data and process step.

For computer data denote (usually by color) the level of controls:

  • Fully aligned with Part 11 and Data Integrity guidances
  • Gaps in compliance but remediation plan in place (this includes places where paper is considered “true copy”
  • Not compliant, no remediation plan

Data operations are depicted utilizing arrows.  The following data operations are probably most common, and are recommended for consistency:

  • Data Entry – input of process, meta data (e.g. lot ID, operator)
  • Data Store – archival location
  • Data Copy – transcription from another system or paper, transfer of data from one system to another, printing (Indicate if it is a manual process).
  • Data Edit – calculations, processing, reviews, unit changes  (Indicate if it is a manual process)
  • Data Move – movement of paper or electronic records

Data operation arrows should denote (again by color) the current controls in place:

  • Technical Controls – Validated Automated Process
  • Operational Controls – Manual Process with Review/Verified/Witness Requirements
  • No Controls – Automated process that is not validated or Manual process with no Review/Verified/Witness Considerations
Example data map

The role of a data steward

With data integrity on everyone’s mind the last few years, the role of a data steward is being more and more discussed. Putting aside my amusement on the proliferation of stewards and champions across our quality systems, the idea of data stewards is a good one.

Data steward is someone from the business who handle master data. It is not an IT role, as a good data steward will truly be invested in how the data is being used, managed and groomed. The data steward is responsible and accountable for how data enters the system and ensure it adds value to the process.

The job revolves around, but is not limited to, the following questions:

  • Why is this particular data important to the organization?
  • How long should the particular records (data) be stored or kept?
  • Measurements to improve the quality of that analysis

Data stewards do this by providing:

  • Operational Oversight by overseeing the life cycle through defining and implementing policies and procedures for the day-to-day operational and administrative management of systems and data — including the intake, storage, processing, and transmission of data to internal and external systems. They are accountable to define and document data and terminology in a relevant glossary. This includes ensuring that each critical data element has a clear definition and is still in use.
  • Data quality, including evaluation and root cause analysis
  • Risk management, including retention, archival, and disposal requirements and ensuring compliance with internal policy and regulations.

With systems being made up of people, process and technology, the line between data steward and system owner is pretty vague. When a technology is linked to a single system or process it makes sense for them to be the same person (or team), for example a document management system. However, most technology platforms are across multiple systems or processes (for example an ERP or Quality Management System) and it is critical to look at the technology holistically as the data steward. I think we are all familiar with the problems that can be created by the same piece of data being treated differently between workflows in a technology platform.

As organizations evolve their data governance I think we will see the role of the data steward become more and more part of the standard quality toolbox, as the competencies are pretty similar.