Register: Hybrid System Inventory and Governing Record Declaration

This is a ready-to-use register. It is the list every other hybrid control depends on: you cannot declare a governing record, schedule a reconciliation, or show a migration plan for a hybrid nobody has written down, and the most common opening question on this topic is simply “how many hybrids do you have?” Replace every <<FILL: ...>> placeholder, keep one entry per hybrid, and route the register through your normal document control, review, and approval. Four filled specimen entries follow, covering deliberately different hybrid patterns. Maintaining this register does not by itself create control; it makes the population visible so the rest of the programme can act on it. Verify each cited regulation against the current source before you rely on it, and treat this as general guidance to adapt rather than legal or regulatory advice.

The procedure that governs how these hybrids are controlled and reconciled is the companion hybrid record control and reconciliation SOP. The background reasoning is in hybrid paper-and-electronic records.

Document control header

How to use this register

1. Set the document number, owner, and approvers in the header.
2. Enter one row per hybrid. A record is hybrid when three questions all answer yes: does a system generate electronic data for this activity, is any part of the official record on paper, and are both halves needed to reconstruct the activity.
3. Build the initial population from your GxP computerized system inventory and your instrument list, then confirm every candidate by watching a real execution. Desk review alone reliably misses the balance whose only output is a printed slip taped into a logbook, and the spreadsheet that re-keys results for a trend chart.
4. Complete Part A (identification and declaration) and Part B (controls, gaps, and plan) for every entry. The two parts share the Hybrid ID as the key, so they can be maintained as one table in a controlled spreadsheet or as two linked tables in a document.
5. Route every governing-record declaration through Quality Assurance approval before the entry is considered complete. An entry with an unapproved declaration is an open action, not a finished row.
6. Keep the register under change control. Reconcile it on the cadence in the header and update it on any trigger listed in the review section.

Field definitions and completion rules

Part A: identification and declaration

Part B: controls, gaps, and plan

Hybrid pattern codes

An entry can carry a primary pattern and a secondary note. A paper batch record that also depends on a historian is P2 for the record as a whole and P3 for the specific parameters that exist continuously in the historian and hourly on paper. Record the primary code and describe the secondary condition in the declaration basis.

Declaration basis codes

Apply these tests in order and stop at the first that resolves. Record the code that resolved it.

A declaration recorded as D2 with the printout named as the original is not approvable. That combination is the single most cited hybrid failure and the register should make it impossible to record silently.

Completing the open control gap and remediation columns

Write gaps as observable conditions, not as judgements. “Shared Windows login on the acquisition workstation, three named users share one credential” is a gap. “Weak access control” is not, because nobody can later prove it was closed. Each gap needs a corresponding remediation row with a named individual owner, not a department, and a target date that survives contact with a real project schedule. Where a gap cannot be closed before the system is replaced, record the compensating control and the residual risk explicitly rather than leaving the remediation column optimistic. A register full of overdue target dates is worse evidence than a register that states honestly which gaps are being carried until migration and why.

Review cycle and triggers

1. Reconcile the register <<FILL: cadence, e.g. quarterly>>: confirm every entry is still accurate, every remediation date is current, and no new hybrid has appeared.
2. Perform a full review at least <<FILL: cadence, e.g. annually>>, including at least <<FILL: number>> entries verified by direct observation of a real execution rather than by document review.
3. Update immediately, outside the cycle, on any of these triggers: a new system or instrument is introduced; an existing system is upgraded, networked, or re-hosted; a method, form, or process step changes how the record is created; a deviation or audit finding reveals a hybrid that was not listed; a hybrid is retired.
4. Route every change through change control per <<FILL: SOP-ID for change control>>.
5. Feed the register into the quality management review per <<FILL: SOP-ID for management review>>, reporting at minimum the total count, the count by risk class, the number of open gaps, and progress against migration waves.

Retention

Retain the register and each superseded version for <<FILL: retention period, e.g. the life of the quality system plus the longest applicable record retention period>>. Superseded versions matter more here than in most registers, because they are the evidence of what was declared as the governing record at the time a historical batch or study record was created. Do not overwrite entries in place without preserving the prior version.

Acceptance criteria for the register

• Every GxP instrument, system, and process has been classified as pure-paper, pure-electronic, or hybrid, with a recorded rationale, and the register accounts for the hybrid population.
• Every entry names one declared governing record, with a basis code and Quality Assurance approval.
• No entry declares a printout as the original for dynamic data.
• Every entry names a machine-generated identifier that appears on both halves, or logs the absence of one as a control gap with remediation.
• Every open gap has a named owner and a target date, and overdue items are visible rather than silently rolled forward.
• Every entry carries a risk class traceable to the hybrid data integrity risk assessment, and a migration wave traceable to the retirement plan.
• At least <<FILL: number>> entries per review cycle were verified by direct observation, and the observation date and observer are recorded.

References

21 CFR 211.68 (automatic, mechanical, and electronic equipment), 211.180 (general records requirements), 211.194 (laboratory records). 21 CFR Part 11 (electronic records and electronic signatures), in particular 11.10, 11.50 (signature manifestations), and 11.70 (signature and record linking, including handwritten signatures executed to electronic records). EU GMP Annex 11 (Computerised Systems) and EU GMP Chapter 4 (Documentation). FDA guidance, Data Integrity and Compliance With Drug CGMP, Questions and Answers (December 2018). MHRA GXP Data Integrity Guidance and Definitions (March 2018). PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. ICH E6 Good Clinical Practice, for clinical source and certified copy expectations. ICH Q9, Quality Risk Management, for the risk basis of criticality and prioritisation.

Confirm the current version and clause numbers of each reference before issue.

Blank register

Part A

Part B

Revision history

Approvals

Filled specimen

Four entries follow, chosen because they fail in different ways. Company, systems, names, and dates are illustrative; replace them with your own. Each entry is shown as Part A followed by Part B so the full row is readable.

HYB-001: standalone chromatography workstation, release assay

Part A

Part B

HYB-002: analytical balance with printout counter, dispensing

Part A

Part B

HYB-003: paper batch record dependent on the historian and DCS

Part A

Part B

HYB-004: clinical site paper source document feeding the EDC system

Part A

Part B

What makes these four entries useful as a set is that they resolve to four different governing records for four different reasons. Only the chromatography entry lands on the electronic half. The balance lands on paper because the instrument keeps nothing. The batch record splits, because the historian genuinely holds a record the paper only samples. The clinical entry splits along a field list defined per study. A register that records “electronic” for every row has almost certainly not applied the decision tree.

Common inspection findings this register prevents

• The firm cannot state how many hybrid records it has, and the count offered during the inspection differs from the count in the quality system.
• A hybrid is found in use on the floor that appears nowhere on any inventory, most often a standalone instrument or a spreadsheet that re-keys results.
• No document states which half of a record is the original, so different reviewers treat different halves as authoritative.
• A printout is recorded as the original for dynamic electronic data, and the electronic data behind it is uncontrolled or was deleted.
• The paper batch record is not recognised as a hybrid at all, so nobody reviews the historian data it depends on.
• Split-field records are forced into a single declaration, leaving the fields that exist on only one half without any declared owner or control.
• Control gaps are described in general terms that cannot be verified as closed, and remediation dates roll forward with no visible owner.
• The register exists but was last updated before two systems were upgraded and one was networked, so its risk classes and gaps no longer describe reality.

How to adapt this register

1. Set the document number, owner, approvers, and review cadence in the header, and point the governing SOP field at your real hybrid control procedure.
2. Build the first population from your system inventory and instrument list, then budget time to walk the floor and the laboratory. Expect the observed count to exceed the desk count, and record the difference as a finding about the inventory process rather than quietly correcting it.
3. Name the actual machine-generated identifier each system produces in the link mechanism field. This is the highest-value field in the register and it is entirely system-specific.
4. Add or remove GxP domain values to match your operations. A cell and gene therapy site will want chain of identity and chain of custody records in scope; a distribution site will want temperature records and shipment documentation.
5. Bind the risk class column to your hybrid data integrity risk assessment and the migration wave column to your retirement plan, so the three documents cannot drift apart.
6. Decide where the register physically lives. A controlled spreadsheet is acceptable if it is itself under validation and access control appropriate to its use; a register maintained in an uncontrolled file with no version history undermines the point of the exercise.
7. Confirm every regulation in the references section against the current published version before issue.