A PAT project succeeds as much on people and organisation as on technology. An instrument still in service in five years is decided before the installation, and not in the sensor.
Three questions settle it, and all three belong to scoping. Who owns the model. What status the measurement will hold in your system. Who will keep it alive.
An instrument already installed, and out of use
The diagnosis is worth doing before any decision. Often the hardware is sound and what is missing is an owner, a model update and an alarm instruction. Sometimes the point was there from the start: the wrong measurement point, a quantity with no usable signature, an incompatible rate. Moving the measurement point or changing the quantity followed often reopens the file. What the audit examines, and what it produces.
What plays out between acceptance and the second year
What plays out between acceptance and the second year comes down to four points, and each of them is prepared: the handover when the project leader changes post, the threshold setting that keeps the alarm worth reading, the recovery rule after an equipment modification, and the right to retouch the model.
No text specific to PAT addresses the human factor — Ph. Eur. 5.25 Process analytical technology contains neither the word personnel, nor training, nor competence. The quality system texts, on the other hand, address it explicitly. ICH Q9(R1) gives subjectivity in risk assessment a section of its own (§ 5.3), places training and education among the objects of risk management (Annex II.1), and names « human-related » causal factors in root cause analysis (Introduction). ICH Q10 places human resources and training under management responsibility (§ 2.3 d and § 2.4 a), while ICH Q12 and Q14 carry knowledge. The human factor is therefore not outside regulation: it is addressed where nobody looks for it, in the quality system rather than in the measurement protocol. Which is why it is decided at scoping.
Who owns the model on the Monday after the project ends
A chemometric model is a living object with an owner, rather than a file delivered once. Three questions settled in writing before commissioning:
- Who owns the model. A named person, with a designated deputy. A department is not a name, and neither is the project.
- Who may modify it. An update touches a production decision: change management, written justification, independent verification, a trace.
- Who is trained. Two people per critical audience, so the knowledge stays in the team; and the training is recorded (EudraLex vol. 4, chapter 2, § 2.11).
Who owns the model by default?
When the question goes unasked it settles itself: the integrator stays the de facto owner, and the client depends on a phone call for the smallest change.
We prefer the reverse. The model, its documentation and its data sets belong to the operator from delivery, and its upkeep becomes an internal competence. ICH Q14 provides for exactly that, in the words of its section 8: « Model reassessment is performed within the PQS and utilises knowledge management and risk assessment. » Reassessing a model is an act of the quality system, not the initiative of an isolated expert. Training and autonomy.
What triggers an action, and what stays a display
A measurement can hold four statuses. Moving from one to the next changes the nature of the project, and it is the most structuring integration question.
| Status of the measurement | What the system does with it | What it implies |
|---|---|---|
| Display | A curve visible in the control room | No requirement, and no value either unless someone looks at it |
| Record | The datum is historised and can be consulted | Time stamping, attribution, retention: the datum becomes a record, with its integrity requirements |
| Alert | An operator is called on | A written instruction: what is done when it sounds, and who decides |
| Action | The measurement drives a setpoint or a stop | The domain of method validation. The most demanding, and the one that produces an automatic gain |
Many projects stop at the first or second status without saying so, then wonder where the benefit went. A measurement that triggers no action documents. That is sometimes exactly what is wanted, and it is owned at scoping.
The link to the supervision system then raises two concrete questions. Which way the information travels, read-only or steering. And who else can write into the instrument. A communication server that stays active when the instrument software is closed, and accepts third-party clients for writing, sits awkwardly with the notion of a closed system. That point is documented and framed by procedural controls. Where "21 CFR Part 11 ready" and a validated system part company.
Line operators often know before the instrument
Operators know when a batch “feels wrong”: from the sound of the mixer, the look of the product at the outlet, the time the valve takes to settle. They are right far more often than dashboards assume, and technical projects regularly miss this knowledge.
An instrument that contradicts this knowledge gets rejected, however accurate it is. An instrument that confirms it and makes it transmissible gets adopted. The difference lies in how the project is run, not in the performance of the sensor.
In practice, three steps.
- Ask them before choosing the measurement point. They know where the product is representative, and that information is worth many trials.
- Show them the first curves at the same time as the engineers. Set their judgement against the signal, batch by batch, including when the two diverge.
- Say what the measurement is for. A sensor perceived as a tool for monitoring people produces workarounds, not quality.
An alarm that sounds too often stops being an alarm
It is the quietest mechanism. A threshold too tight at start-up, a few false alerts per shift, and acknowledging becomes a reflex. Six months later, the one alarm that mattered goes unnoticed. And the system is held responsible for an incident it had signalled.
The remedy comes down to four points.
- Set thresholds on the variability actually observed, not on the specification.
- Count alarms per shift, and treat that number as a health indicator of the system.
- Attach an action instruction to each alarm, otherwise it is only a sound.
- Review the thresholds after a few months of routine.
Two deliverables that make the project last
Documentation that gets updated
The initial validation report describes a state, and that state moves at the first probe change. What serves in routine fits in a few pages: operating procedure, acquisition parameters, a log of model versions with the reason for each change, a list of cases already encountered and how they were handled. Kept by the model owner, and filed where the team will look for it.
This is knowledge management in the sense of ICH Q10 (§ 1.6.1), linked to change management by ICH Q12. The text describes “a systematic approach to acquiring, analysing, storing and disseminating information” and imposes no particular tool: what is expected is that the reason for decisions survives the departure of whoever took them.
Training to use, or training to understand
Two distinct needs, often merged into a single training day.
Training to use: start, stop, read, react. It concerns many people, and is repeated with each new arrival.
Training to understand: why the signal responds, what a validity domain is, how to tell an instrumental drift from a process drift. It concerns only a few people, and it is the one that means you no longer need to call us.
What happens when the equipment or the formula changes
A change of excipient supplier, a new vessel size, a probe replaced after breakage: each can carry the model outside its domain of validity, and each arrives without notice.
The recovery is planned from the start, as a rule known to operations.
- Which changes call for a verification.
- On how many batches.
- With which acceptance criterion.
- Who declares the return to service.
Replacing a probe with one of the same model is not neutral: two identical instruments give slightly different spectra, and model transfer is a piece of work in itself. Where the rule exists, a modification is a bounded operation. Two instruments, two figures.
What a service contract actually buys
Most maintenance contracts sell a volume of hours. The question to ask lies elsewhere: what weighs in production is the measurement being down while you wait.
The form that seems right to us is a strictly additive grid: each level takes over the previous one in full and adds one line, never removing anything.
- Support by telephone and email, with an announced response time.
- User training, renewable when new people arrive.
- Software updates, and information on what they change.
- Annual on-site review, with performance validation: does the instrument still do what it did at qualification.
- Instrument warranty extended for the duration of the contract.
- Replacement instrument made available during repair.
The last two levels sell availability, not technician time. It is the only quantity that counts from the production point of view. An automatic continuity clause also avoids uncovered periods between two renewals, which is when breakdowns happen.
A successful project is recognised by the fact that the team no longer needs us. The model belongs to the operator. Someone knows how to keep it alive. Operators rely on it to decide, and an equipment modification triggers a known procedure rather than an emergency call.
An instrument still in use in five years is worth more than a dependency contract.
Frequently asked questions
At what point should these questions be dealt with?
At scoping, even before choosing the technology. The model owner, the status of the measurement, the training plan and the takeover rule are decided on one page, early. Dealing with them after installation means negotiating resources for a project already considered finished.
Should the measurement be connected to the control system from the start?
Rarely. Starting with display and recording makes it possible to observe the real variability, to set thresholds on data and to win the confidence of the teams. Moving to action is prepared afterwards. The reverse (slaving a process straight away to a young model) produces untimely stops and lasting mistrust.
How do you know whether the deployment has succeeded?
Six indicators, recorded one year after commissioning.
- The number of alarms per shift, and the proportion followed by an action.
- The number of days the measurement was unavailable.
- The number of people able to intervene.
- The date of the last documentation update.
- Model drift, followed on its residuals.
- The gain obtained, set against what the installation required.
None of them is about accuracy. All of them are about use.
Who carries the project, and what gets said on the floor
A named owner, and a team that cuts across departments. An in-line measurement touches production, quality, the laboratory, maintenance, IT, automation, regulatory affairs and management. None of them can carry it alone, and the project moves at the speed of whoever was left off the invitation. What works: one person inside the company named as the owner, and a small group where each department is represented by someone who decides rather than someone who reports back, meeting on a fixed and short cadence.
ICH Q9(R1) says the same for quality risk management, at its section 4.1: those activities are « usually, but not always » undertaken by interdisciplinary teams, and a team so formed should bring together experts from the relevant areas — the quality unit, product development, engineering, regulatory affairs, production operations, supply chain, statistics. And ICH Q10 places human resources and training under management responsibility (§ 2.3 d and § 2.4 a) — which is why management sits in the group.
The owner does not need to be the best spectroscopist on site. They need to know the process, to be listened to in the control room, and to have the time. The projects that hold are the ones where that person was named before the first trial.
What gets said, and what each remark asks for
Seven remarks come back from one site to the next. Each is a fair question, and each has an answer.
| What gets said | What it asks for |
|---|---|
| “The machine will decide instead of me” | The written split between what triggers an action and what stays a display. While the measurement informs, it does not command: that is a decision, and it belongs to scoping. |
| “This is too complicated for us” | Training that explains what the curve represents, not only which buttons to press. The difference shows on the first difficult batch. |
| “We managed perfectly well without it” | True, and that know-how is exactly what there is to capture. The measurement makes visible what the operators already know, and makes it transferable. |
| “Sensors will replace us” | The work moves from checking to steering. The people who read the trajectory are the people who hold the line. |
| “And if the instrument is wrong?” | A model that can say “I do not know”. Out-of-domain diagnostics and residual monitoring flag the sample the model has never seen: that is what makes the value defensible, and it is worth showing the teams. |
| “We see more variation since we started measuring” | Naming where that visibility comes from: the variation was already there, the measurement gives it resolution. That is what opens the way to acting on it. |
| “That is one more task for us” | An in-line measurement replaces a sampling operation rather than adding to it. The count is made at scoping: how many samples per batch disappear, and how many minutes per shift. |
Show
On your own product, early, with nothing committed. A spectrum taken on their own material carries more than a presentation.
Involve
The people who run the line decide the measurement point with you. A sensor someone helped to place does not get unplugged.
Credit
The first curve that explains a difficult batch does the work of ten meetings. Show it, and say who obtained it. A convinced operator then teaches colleagues better than we do: the cheapest and most durable relay there is.
Four steps, in this order
- Raise awareness before choosing: a short workshop with every department in the room, so the vocabulary is shared before the trade-offs.
- Involve during the proof of concept: the trials run with the teams, at their station, on their product.
- Train before commissioning. A measurement explained before it arrives is a measurement people look at.
- Hand over: the owner takes the lead, and maintaining the model has a name on the org chart. What that asks for over time.
Let us talk about what happens after the installation, while there is still time to decide it.
Forty-five minutes is enough to settle who will own the model, what status the measurement will hold in your system, and what a service contract should secure for you.