Medical Information and Pharmacovigilance: AE Intake, Escalation and Reconciliation

Medical Information teams answer product questions, but a question can also disclose a suspected adverse reaction. This article explains how to design the intake, escalation, follow-up, reconciliation, training and oversight controls that preserve the reporter's account and connect medical enquiries to the pharmacovigilance system.

Take test

Medical Information and Pharmacovigilance: AE Intake, Escalation and Reconciliation

Medical Information teams respond to questions about medicines: how to prepare or administer a product, what the product information says, how a device works, or what evidence is available for a clinical question. During that conversation, a caller may also mention that a patient developed a symptom, a dose was taken incorrectly, treatment did not work, or a product may have been defective.

The purpose of the contact does not decide whether safety information is present. A caller can ask a routine product question and still report a suspected adverse reaction. The operating model therefore needs to recognise the safety content, preserve what the person said, transfer it promptly to pharmacovigilance (PV), and show that the handoff reached its destination.

This article is about that operational interface. It does not repeat the full rules for individual case safety report (ICSR) validity, source classification, or regulatory submission clocks. For those subjects, see the companion pages on ICSR sources, case intake and triage, and Day Zero.

1. The operational problem

Medical Information is often a first receiver of information, even when the employee answering a call is not a PV specialist. Information can arrive by telephone, email, web form, messaging service, field-medical contact, product-support channel, or through a contractor. The risk is not limited to a person failing to recognise an event. A report may be recognised but still be delayed, reduced to a short paraphrase, left in an inquiry system, or lost when a vendor sends a periodic file.

A reliable interface treats the safety transfer as a controlled process with a visible start, an accountable owner, a confirmed destination, and a record of exceptions. It does not require every medical enquiry to become a safety case. It does require a dependable way to find the enquiries that contain possible safety information.

The basic sequence is:

  1. receive and time-stamp the contact;
  2. listen for possible safety information while responding to the enquiry;
  3. capture the source account without filtering it through a causality judgement;
  4. route the safety information through the defined PV channel;
  5. confirm receipt and resolve failed or incomplete transfers; and
  6. reconcile the enquiry population against PV intake records at a justified interval.

These controls connect two different services. Medical Information answers the question within its remit. PV assesses and processes the suspected adverse reaction under the applicable system. One contact may create work in both systems, and those records need enough linkage to be traceable.

2. Terms used in this article

An adverse event (AE) is an untoward medical occurrence after use of a medicine, without requiring a causal relationship. A suspected adverse reaction is an event reported with a suspicion of a relationship to a medicinal product. An ICSR is the structured safety report used to document an individual patient's case. Medical Information (MI) means the function that responds to product and medical enquiries; organisational names and scope vary.

The person making an enquiry may be the patient, a carer, a healthcare professional, a distributor, or another third party. The person supplying the safety facts is the primary source for those facts; the person asking a question is not always the patient or the reporter. The intake process should preserve those distinctions for PV review.

The words “AE intake” in the title refer to recognising a possible event during contact handling. They do not mean that MI personnel independently decide whether an event is medically caused by a product or whether the report meets all regulatory criteria for a valid ICSR. That determination belongs in the defined PV process.

3. Regulatory framework and the boundary of the obligation

The European Union (EU) framework combines legislation with detailed guidance. The distinction matters because an organisation may choose an efficient operating model, but it must not describe every design choice as a legal requirement.

Source What it establishes for this interface How to apply it
Directive 2001/83/EC and Regulation (EC) No 726/2004, as applicable Core marketing-authorisation-holder (MAH) pharmacovigilance responsibilities, including collection and reporting of suspected adverse reactions Apply the current legislation and the product/territory-specific rules
Commission Implementing Regulation (EU) No 520/2012, as amended Quality-system, training, record-management and pharmacovigilance-process requirements The consolidated legal text controls; check amendments and effective dates
GVP Module VI, Revision 2 EMA guidance for collection, management and submission of suspected adverse-reaction reports; unsolicited reports received through medical-enquiry or product-information services are described among spontaneous reports when they are not related to an organised data-collection system Use it to design a compliant process, while preserving the distinction between “should” guidance and legal “shall” requirements
GVP Module I Quality-system guidance on staff competence, training, escalation, records and system effectiveness Use it to define roles and prove the interface works
Company procedures and agreements The organisation's approved operational route, responsibilities and service expectations These make the chosen process executable; they cannot narrow the applicable legal reporting duty

GVP Module VI states that suspected adverse reactions not connected to an organised data-collection system and notified through medical-enquiry or product-information services should be considered as spontaneous reports. This does not mean that every product question is an ICSR. The content must first include a suspected adverse reaction, and PV must then assess the report under the applicable criteria. A question asking whether nausea is listed in the leaflet, without a patient experience or a report of a suspected reaction, is not by itself an adverse-reaction report. A caller who says, “I am calling about storage, and my father developed a rash after using it,” has introduced safety information that must enter the PV route.

The legal quality-system framework requires suitable pharmacovigilance resources, training, documented processes, records and compliance management. Module I explains how these responsibilities extend into the organisation: staff whose activities may affect PV, including Medical Information staff, should receive appropriate training; personnel should know what to do if they become aware of a safety concern; and mechanisms should support timely communication and escalation. The specific training content and operational handoff design should be proportionate to the role and risk.

The GVP index notes that Commission Implementing Regulation (EU) 2025/1466 amended Regulation 520/2012 and is applicable, with GVP updates to follow. As a result, do not rely on an old GVP paragraph as a substitute for checking the amended legal text. This article uses Module VI Revision 2 as current published guidance at the review date and points readers to the consolidated regulation for the binding text.

4. What “recognise and route” means

The first receiver should identify language that may describe a medical occurrence, worsening condition, lack of effect, overdose, medication error, misuse, occupational exposure, pregnancy exposure, or product-quality problem with a patient impact. This is a screening task, not a causality assessment.

A caller does not need to use the phrase “side effect.” “She has been short of breath since the second injection” or “the tablets did not control the seizures” may be safety-relevant. A complaint about a broken injector becomes safety-relevant if the caller also describes an injury, missed dose, or other patient consequence. A report can be incomplete and still need PV routing; missing details are a reason for PV follow-up, not a reason for MI to hold or discard the information.

The receiving employee should follow the approved prompt set, collect what is readily available, and avoid leading the reporter toward a preferred account. If the contact contains no safety information, the enquiry follows the usual MI process. If a possible event appears, MI records the original wording and activates the safety pathway while continuing any appropriate product-information work.

See the product-quality and PV interface article for the separate investigation pathway when a defect allegation and a patient event occur together.

5. Intake at the first contact

5.1 Start with an open conversation

The employee should let the caller describe the reason for contact in their own words. A neutral question such as “Can you tell me what happened?” is usually more useful than a sequence of questions that assumes the medicine caused a problem. If the caller mentions an event, the receiver can clarify the basic facts using the approved prompts.

The aim is not to conduct a complete PV interview while answering a medical question. It is to capture enough information to transfer a faithful and usable account, and to enable PV to follow up. The employee should not promise that the product caused the event, rule out a relationship, or tell the reporter that information is “not reportable.”

5.2 Capture facts and their source

A structured intake record should allow the employee to capture, where available:

Intake element Operational purpose
Contact date, time and channel Establish when and how the organisation first became aware of the information
Caller and reporter relationship Distinguish the person contacting the company from the person who supplied the event facts
Patient identifier or permitted alternative Support PV assessment while limiting unnecessary personal data
Product as described by the caller Preserve the reported name, strength, formulation, route and other identifying details
Event or experience in the reporter's own words Retain source meaning before medical coding or interpretation
Event timing, status and outcome if volunteered Help PV determine urgency and plan follow-up
Relevant circumstances volunteered Preserve context such as dose, use error, batch concern, concomitant treatment or pregnancy
Consent or contact preferences where relevant Support appropriate follow-up under applicable privacy and local requirements
MI enquiry reference and transfer details Link the enquiry record to the PV receipt or case reference

The source account should be captured verbatim where practical, or as a faithful, clearly attributed summary. Separate the reporter's words from the employee's interpretation. Do not infer a diagnosis, seriousness, causality, or treatment outcome that the caller did not provide. Preserve the original language where the system allows; if translation is needed, identify it as a translation and follow the PV procedure.

5.3 Maintain the enquiry record and the safety record

MI and PV may use separate systems. The MI record should retain the original enquiry context, the time of receipt and the transfer reference. The PV system should contain the safety information in its controlled case record. A cross-reference should make it possible for authorised staff to move from one record to the other without creating uncontrolled duplicate personal-data stores.

Access to identifiable information should be restricted to people who need it for their tasks. Intake fields should be designed to capture what is necessary for transfer and follow-up, not every detail that a caller could provide. Retention, access and disclosure should follow the applicable privacy rules and the organisation's record-management policy.

6. Time-stamp, assessment and transfer

The MI system should record the actual first-receipt date and time, with enough context to interpret the timestamp—for example, the time zone or system standard where contacts cross locations. A later PV entry time is not a replacement for the first-receipt record. If a call is transferred live, keep both the MI receipt time and the PV receipt or case-intake time.

This distinction supports accurate clock assessment. The internal transfer deadline is a company control; it should be set so that the PV function can meet the applicable regulatory timeline. It is not itself the regulatory Day Zero rule. Nor should the PV clock be reset merely because information has moved from an MI platform to a safety database. For the regulatory clock and special timing questions, use the Day Zero article.

A practical handoff includes the source account, the contact timestamp, available reporter and patient details, product and event facts, and a unique MI reference. The receiving PV queue or person should acknowledge receipt through a logged transaction, interface status, or controlled confirmation. An email sent is not evidence that the destination received and accepted the information.

The procedure should define what happens if the normal route is unavailable: the backup mailbox or telephone route, who monitors it, how receipt is confirmed, and how the information is entered into the PV system when service resumes. Urgent safety concerns require a clear escalation route to the designated PV decision-maker and management. The process should not require the MI employee to decide that a case is serious before escalation.

Operational targets should be explicit and risk-based. For example, a company may require same-day transfer or immediate live escalation for defined urgent categories, but a particular number of hours is not a universal EU transfer deadline unless a specific applicable rule or agreement makes it one. The MAH should justify its internal target against reporting duties, working arrangements, time zones, weekends, public holidays, vendors and system outages.

If mandatory details are absent, route what is known and let PV manage attempts to obtain missing information. A screen that forces completion of every field before submission can create a silent hold. Required data validation should distinguish information essential to send a transfer from information that may be unavailable at first contact.

7. Parallel work: answering the enquiry and following up the case

7.1 Two records, two purposes

A contact may create an MI enquiry and a PV report at the same time. The enquiry record tracks the question and the response. The PV record tracks the suspected adverse reaction, follow-up, evaluation and reporting. Neither record should be used as a substitute for the other.

An MI response can provide approved product information or direct the caller to an appropriate healthcare professional. It should not make an individual diagnosis or promise a causality conclusion. The PV process determines what additional information is needed and who should seek it. If the caller volunteers new safety information while MI is answering a later question, the new information should re-enter the PV route and be linked to the existing case where possible.

7.2 Follow-up ownership

Procedures should say who contacts the reporter for additional safety details. A common arrangement is for PV to own case follow-up, while MI may support a response or reconnect the reporter if that is the established process. Whichever model is used, the reporter should not receive conflicting or duplicate requests from separate teams without coordination.

Follow-up should be proportionate and non-leading. The GVP guidance cautions against asking a primary source to repeat information already supplied or complete unnecessarily extensive questionnaires, because this may discourage future reporting. Procedures can help staff distinguish an information request from a PV follow-up question, record attempts and outcomes, and route new information back into the case.

If the reporter declines follow-up, cannot be reached, or supplies no further detail, record that outcome in the PV system and the linked enquiry record as appropriate. Do not make the transfer conditional on consent to a later interview. Privacy requirements govern how personal data are handled; they do not justify ignoring a safety account that has already reached the organisation.

7.3 Product questions that change character

Sometimes the exchange starts as a routine enquiry but later becomes safety-relevant:

The employee should not finish the original question before opening the safety route. The contact timestamp remains anchored to when the organisation first received the safety information, not when the enquiry was closed or when the employee completed the narrative.

8. Roles and channel design

Responsibility needs to be clear across the whole path. “Everyone is responsible” is not enough if no one owns the queue, the acknowledgement, the reconciliation, or the outage procedure.

Role Typical responsibility in the interface
MI first receiver Recognise possible safety information, capture the source account and contact time, route it using the approved channel
MI team lead Ensure queue coverage, training, escalation access and review of unresolved transfers
PV intake / case-processing team Receive and assess information, create or update the case, follow up and determine reporting actions
PV system owner or quality function Maintain procedures, interfaces, records, monitoring and corrective action
QPPV / delegated PV oversight Maintain oversight of the PV system and receive escalations that could affect compliance or patient safety
Vendor or affiliate Perform only defined tasks under agreement, training, access and oversight controls
IT / system support Maintain reliable routing, audit trails, time records, access control and continuity arrangements

The company should map every safety-relevant channel, including channels it controls through a vendor or affiliate. If a vendor answers calls or manages a contact portal, the written agreement and work instructions should identify safety recognition, transfer, acknowledgement, outage handling, record access, training and monitoring responsibilities. The MAH retains oversight of its pharmacovigilance system even when operational tasks are outsourced.

Channel design should match the way people contact the organisation. A scripted call-centre flow may suit a high-volume phone line; an email queue needs controls for monitoring and forwarding; a web form may need a visible safety prompt without making the user complete a long form before they can submit. If field-medical staff or sales representatives can receive reports, they need a defined route and practical instruction for handing off information promptly.

The route should be tested end to end. A test should demonstrate that a possible safety contact becomes visible to PV, carries the original receipt time and source account, receives an acknowledgement, and can be traced back to the MI record. Test normal and failure paths, including weekend coverage or a simulated system interruption where relevant.

9. Reconciliation: proving that the handoff worked

9.1 Reconciliation is a control, not a second case review

A reconciliation compares defined records in one system with their expected counterparts in another. For MI and PV, the objective is to identify safety-bearing enquiries that have no corresponding PV receipt, and to identify PV cases whose MI source record cannot be located when one should exist. It is not a substitute for real-time routing, and it does not decide whether every enquiry is reportable.

GVP Module VI describes the need for confirmation and/or reconciliation when pharmacovigilance data are transferred within or between organisations under contractual arrangements, so that there is confidence notifications are received. Module I also expects records to support traceability and verification. These principles support a documented reconciliation control for the MI–PV interface. The exact systems, population, matching method and frequency should be defined by the organisation's risk assessment and procedures; there is no single universal calendar frequency for every MI operation.

9.2 Define the population before comparing it

A useful reconciliation starts with a clear source population. Depending on the operating model, it may include all MI contacts, all contacts flagged as potentially safety-related, or all contacts meeting defined product/event search criteria. If only flagged contacts are reconciled, the organisation should separately test whether the flagging process reliably identifies safety-bearing contacts. Otherwise a false-negative at intake never enters the comparison.

For each period, the MI population should be stable and reproducible. Document the systems and queues included, the extraction date, filters, time zone, period boundaries and responsible preparer. If call recordings or vendor logs are used, retain lawful access and a controlled means to review them without creating unnecessary copies.

9.3 Match records with more than one signal

An MI reference linked to a PV case number is the strongest routine match. Where an identifier is absent, trained reviewers may compare date and time, product, event, reporter, patient, channel and narrative fragments. A match based on one common feature—for example, product and date alone—may incorrectly combine different reports. Ambiguous matches should be reviewed and documented rather than silently accepted.

A practical status set might include:

The codes are operational examples, not regulator-mandated categories. The procedure should define what evidence supports closure and who is authorised to decide.

9.4 Reconcile in both directions

The MI-to-PV comparison tests whether safety-bearing enquiries reached PV. A reverse PV-to-MI comparison can identify cases attributed to MI or product-information services whose source interaction is missing, unlinked, or absent from the expected log. Bidirectional review can reveal different defects: a failed transfer, an incorrect source classification, a missing contact log, or an identifier that did not travel through the interface.

Reconciliation should produce a signed or system-attributed record of the population, comparison, results, exceptions, decisions, corrections and approvals. The evidence should let a reviewer recreate how each unmatched item was resolved.

10. Frequency, exceptions and corrective action

10.1 Choose a frequency that can detect harm in time

The organisation should set reconciliation frequency according to channel volume, event severity potential, handoff design, vendor performance, system reliability and the time available to correct a missed transfer. A near-real-time automated acknowledgement may reduce the need for repeated manual comparison of successful transmissions, but it does not prove that MI recognised every safety contact. A low-volume channel may still need a defined periodic review if an event could remain unrecognised for too long.

A risk assessment should explain the choice and the triggers for increasing review. Examples include a new contact platform, a process or vendor change, a rise in unlinked records, a delayed case, repeated transfer failures, a new product launch, or a serious concern about staff recognition. It should also state how the business will operate while a known interface defect is being corrected.

10.2 Triage unmatched records immediately

An unmatched possible safety contact is not merely a reconciliation statistic. The reviewer should locate the source account, verify its first-receipt timestamp, send it to PV without further delay, and notify the responsible manager when a regulatory clock or patient-safety issue may be affected. PV then assesses the case and any reporting obligation. Quality staff should determine whether the problem is isolated or systemic.

Root-cause review should examine where the control failed: was the event not recognised, was a form abandoned, did an interface reject the message, did a queue lack coverage, did a vendor use an obsolete instruction, or did a reviewer close an item without enough evidence? Each explanation requires a proportionate action. Updating a procedure may be insufficient if staff need training, an interface needs repair, or queue design must change.

Where a reporting deadline may have been missed, follow the applicable deviation and compliance processes, escalate to the appropriate PV oversight, assess the affected case, document the impact and determine any required corrective action. Do not assume that completing a later transfer erases the original failure.

10.3 Trend patterns, not just counts

Useful monitoring separates the failure modes. Consider the proportion of potential safety contacts transferred, acknowledgement delay, unmatched items, missing or inconsistent timestamps, open exceptions age, transfer failures by channel or vendor, and the proportion of intake records changed after PV review. Interpret metrics with their denominator and definition. “100% reconciled” is not meaningful unless the source population is complete and the matching rules are known.

A high number of contacts judged not safety-related does not by itself show poor quality. It may reflect appropriate screening, an overbroad search, or a need to improve prompts. A low count of safety contacts does not prove that no safety information was missed. Sample records from both flagged and unflagged MI contacts to assess recognition quality. Where practical, combine metrics with qualitative review and staff feedback.

10.4 Protect source fidelity and privacy

Keep the reconciliation record focused on the information necessary to trace the transfer. Use references rather than copying full case narratives or personal identifiers into general quality logs. Restrict access to call recordings and personal data; define retention and deletion under applicable law and policy. Preserve the audit trail for corrections, matching decisions and closure.

Reconciliation information may itself reveal a potential safety issue, a quality defect, a product complaint or a privacy incident. The procedure should route those discoveries to the appropriate function and retain the linkage between the finding and any resulting case, deviation or corrective action.

11. Training, procedures and oversight

11.1 Train to the actual receiving task

Training should reflect what a person actually does. A first-line MI employee needs to recognise possible safety language, ask neutral prompts, capture a source account, record the receipt time, use the correct route, identify an urgent escalation and respond to a failed transfer. A PV processor needs to acknowledge intake, preserve the incoming source material, assess the report and coordinate follow-up. A manager needs to oversee coverage, exceptions and performance.

The legal requirement for initial and continued PV training applies to personnel performing pharmacovigilance activities. GVP Module I also says that appropriate training should be considered for personnel whose work may affect the PV system, naming Medical Information among the examples. The training plan and records should be maintained as required by the applicable law. The precise curriculum and assessment method should be role-based rather than a generic presentation sent to all employees.

Training effectiveness can be evaluated through observed call simulations, scenario questions, review of transfer records, acknowledgement performance, or targeted sampling. These are ways to demonstrate competence; no particular quiz or pass score should be represented as a universal EU mandate unless another applicable rule specifies it.

11.2 Keep procedures aligned across functions

The MI procedure, PV intake procedure, vendor instructions, privacy notice and business-continuity plan must describe compatible routes. They should agree on: triggering language; minimum information needed to send; first-receipt timestamp; transfer channel; acknowledgement; urgent escalation; follow-up ownership; duplicate contacts; after-hours coverage; rejected or failed messages; record linkage; reconciliation; and escalation of deviations.

Change control should address system migrations, new support channels, vendor transitions, revised forms, product-specific programmes and changes to contact routing. Before a change goes live, confirm which queues receive messages, who monitors them, whether access is appropriate, and how old records remain traceable.

11.3 Oversight questions

Management and the QPPV should be able to establish that the process is designed, staffed, trained, monitored and corrected when it fails. Useful oversight questions include:

These questions examine effectiveness, not merely the existence of a procedure. GVP Module I provides the quality-system context for training, record management, escalation and monitoring. For broader vendor and system governance, cross-link relevant specialist articles rather than repeating them here.

12. Common failure patterns and illustrative examples

The examples below are hypothetical teaching scenarios. They do not describe actual inspection findings.

Example A: the event is buried in a product question

A caller asks how to store a prefilled syringe and adds that the patient developed facial swelling after the previous injection. The employee answers the storage question, then closes the enquiry without activating the safety route because the caller did not ask to report an adverse event.

What failed: The process treated the caller's purpose as a filter on safety content.

Better control: Use open prompts and train first receivers to recognise event language regardless of the main question. Record the caller's words and first-receipt time, transfer the information, and retain the MI-to-PV reference.

Example B: the transfer was sent but not received

An MI employee forwards a report to a shared PV mailbox. A mail rule rejects the attachment. The MI system records “forwarded,” so the monthly reconciliation treats it as complete.

What failed: Dispatch was treated as acknowledgement. The control confirmed an action by the sender, not receipt by the destination.

Better control: Use a logged interface acknowledgement or require the PV recipient to confirm receipt. Reconcile dispatches against accepted PV intake, include rejected messages, and assign open items to an owner.

Example C: time is lost in the vendor handoff

A call-centre vendor records a possible reaction on Friday evening but sends a weekly spreadsheet the following Thursday. The spreadsheet contains the date of export but not the original call time.

What failed: The contract and procedure did not preserve first-receipt timing or require a prompt safety transfer. The weekly reconciliation discovers a delay after it occurred.

Better control: Define real-time or risk-proportionate transfer expectations, retain the original call timestamp and time zone, provide an urgent route, and verify operation through testing and monitoring. Any internal service target should be designed around the applicable reporting obligations.

Example D: the report is rejected because data are incomplete

A web form requires a full patient date of birth and healthcare-professional name before submission. A carer who knows only the patient's age abandons the form. The organisation's dashboard counts only submitted forms.

What failed: The channel made fields that may be unavailable into barriers to transfer, and monitoring ignored abandoned contacts.

Better control: Permit partial reports and route available safety information. Review failed submissions and abandonment data where lawfully available. Design required fields to support rather than obstruct reporting.

Example E: duplicate follow-up confuses the reporter

MI and PV independently contact the same reporter for the event date and outcome. One asks whether the patient recovered; the other asks whether symptoms are ongoing. The reporter responds to only one team, and the systems do not share a reference.

What failed: Follow-up ownership and record linkage were unclear.

Better control: Coordinate follow-up through the approved owner, record attempts and outcomes, link the enquiry and case, and route any newly received safety information to PV.

These examples show why both real-time routing and periodic reconciliation are needed. Real-time controls reduce delay; reconciliation tests whether the full route worked and reveals blind spots in identification, technology, staffing or oversight.

13. Implementation checklist

A practical review of the MI–PV interface can use the following questions.

Scope and ownership

Recognition and capture

Handoff and follow-up

Reconciliation and evidence

Training and improvement

14. Key takeaways

References

  1. European Commission. Directive 2001/83/EC on the Community code relating to medicinal products for human use.
  2. European Parliament and Council. Regulation (EC) No 726/2004.
  3. European Commission. Commission Implementing Regulation (EU) No 520/2012, consolidated text applicable from 12 February 2026.
  4. European Commission. Commission Implementing Regulation (EU) 2025/1466 amending Regulation 520/2012.
  5. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP), Module VI, Revision 2, especially VI.B.1.1.1, VI.B.4–VI.B.5, VI.B.7 and VI.C.6.2.2.7.
  6. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP), Module I, especially I.B.6–I.B.7 and I.B.10–I.B.12.
  7. European Medicines Agency. Good pharmacovigilance practices (GVP): current modules, revisions and planned updates.

Regulatory Note

This article is an operational explanation for the EU pharmacovigilance context, reviewed on 2 October 2026. Binding obligations arise from applicable EU legislation and any relevant national requirements; GVP is regulatory guidance, and the recommended channel design, acknowledgement and reconciliation controls described here are implementation approaches whose details should be risk-based and documented. Confirm the current consolidated legislation, applicable procedures, product-specific obligations and competent-authority requirements when applying the article to a particular system.

Revision History

QPPV.com