Quick intro, your post-market snapshot

• Tell me about the products your team actively monitors after release and the regulated markets where they sell
• In the last 12 months, how many complaint reports did your organization capture on average per month Options: Fewer than 10, 10 to 50, 51 to 200, 201 to 1,000, More than 1,000, Unsure
• Select the primary systems that currently hold your complaint, field service, and adverse event records Options: Primary CRM, Field service system, Adverse event / vigilance database, Document management / QMS, Spreadsheets or local files, Other
• Who on your team currently owns periodic safety report generation and regulatory submissions Options: VP Quality / Head of Post-Market, Regulatory Affairs Director, Post-market surveillance manager, Clinical safety lead, Shared responsibility, Other
• Describe the typical timeline and handoffs from first complaint receipt to final regulatory submission in your current process

Which processes silently eat your team's time

• If you had to point to the single reporting task that consistently consumes the most team hours each month, what is it
• Estimate the monthly full time equivalent hours your team spends on data cleaning, coding, and preparing trending analyses Options: Under 20 hours, 20 to 80 hours, 80 to 200 hours, 200 to 500 hours, More than 500 hours
• Which manual steps in your current workflow create the largest risk of losing audit traceability Options: Manual re-entry from CRM to QMS, Ad hoc spreadsheet analysis, Untracked report edits, Email-based approvals, Other
• When regulatory deadlines are tight, which roles are most often pulled into the firefight to produce evidence Options: Regulatory Affairs, Quality / QA, Clinical Safety, IT / Integrations, Product / R&D, Legal
• What single data gap or missing connector would stop you from kicking off a pilot with an external platform

Which missed signals cost you most and why

• Tell me about a recent example where an emerging trend or safety signal was detected late and the consequences that followed
• Name the data source that most often contains the earliest indicators for those late signals Options: Customer complaints in CRM, Field service reports, Adverse event reports, Published literature, Distributor service logs, Other
• Which methods are you using today to detect trends, and how frequently are those methods reviewed or tuned Options: Automated algorithmic trending, Rule-based manual thresholds, Monthly manual analyst review, Ad hoc investigation, Not doing formal trending
• How confident are you that your current thresholds would detect a doubling of incident rate within three months Options: Very confident, Somewhat confident, Not confident, We have no way to measure
• If a missed signal could trigger a recall or major regulatory action, briefly estimate the business consequence you would expect

Alternatives on the table and what would keep you with them

• List the solution options you are actively evaluating right now and indicate which one currently feels like the favorite
• Select which description best matches your incumbent approach for post-market surveillance Options: Existing vendor / platform, Internal build, Consultant-supported process, Spreadsheet-driven manual process, No formal approach
• Describe what would need to be provably true about your current approach for you to keep it instead of changing
• Has anyone internally proposed solving this entirely without an outside vendor, and if so who would own that effort Options: Yes, product/R&D, Yes, IT, Yes, quality/regulatory, No internal proposal, Other
• What criterion would make you walk away from all external options and commit to an internal build instead

Data and integrations that will make or break this

• Identify the one integration point that, if unavailable, would block the project and explain why
• Choose the systems your team can realistically provide API or extract access to within four weeks Options: Primary CRM, Field service management, Adverse event database, Document management / QMS, EHR / clinical system, Other
• Who owns the technical integration work and do they have dedicated bandwidth to support a pilot Options: Internal integration/IT team with capacity, Internal team but limited capacity, Third-party integrator available, No owner assigned yet
• Estimate the percent of your historical records that are coded or structured versus free text Options: 0 to 20 percent structured, 21 to 50 percent structured, 51 to 80 percent structured, More than 80 percent structured, Unsure
• Given a scenario where historical data cannot be extracted within your target timeline, would you prefer to pause, narrow the pilot scope, or proceed with limited data and why Options: Pause until extractable, Narrow pilot to available sources, Proceed with limited data, Unsure

Regulatory timelines and non-negotiables

• Name the next regulatory deadline for any of your product families that cannot slip without material consequence
• Choose the regulatory regimes you must routinely report to Options: US FDA vigilance / MDR, EU MDR / IVDR, National competent authorities outside EU/US, Notified Body reporting, Other
• When a periodic safety report is due, which internal review or approval steps add the most delay Options: Clinical review, Quality approval, Regulatory sign-off, Legal review, Data assembly and validation
• Identify the validation or documentation deliverable that is non-negotiable before your quality unit will accept new software for regulatory use Options: Validation protocol and test scripts, Traceability matrix, CSV import validation, User acceptance test results, Documented 21 CFR Part 11 controls, Other
• Would lack of demonstrable MDR or IVDR alignment during the pilot stop you from deploying to production Options: Yes, stop, No, accept with mitigation, Depends on remediation plan, Unsure

Signals of success your leadership will demand

• Pinpoint the single measurable improvement you would need to see in the first 90 days to consider the pilot a success and explain why
• Provide the baseline number for that metric so we understand your starting point
• Rate the priority of improvements across these categories Options: Faster time to regulatory submission, FTE hours saved, Earlier detection of safety signals, Reduction in audit findings, Faster CAPA closure
• Would a 30 percent reduction in time to regulatory submission be sufficient for you to recommend full adoption after pilot Options: Yes, No, Maybe, depending on other results

Who needs to say yes and what will sway them

• Pinpoint the final decision maker for pilot to production and list the specific evidence they will require
• Pick the internal stakeholders who must be involved in validation and acceptance Options: VP Quality, Regulatory Affairs Director, QA/RA SME, IT/Integration Lead, Clinical Safety Officer, Legal / Contracts, Operations
• Share an example of the evidence pack you would require to sign off, for example validation scripts, traceability matrix, or report templates
• Indicate whether your quality unit would withhold approval if traceability in the evidence pack is insufficient, or accept with defined remediation steps Options: Withhold approval, Accept with remediation plan, Case by case

Nonstarters, constraints, and practical blockers

• List the top three practical constraints that would prevent a production rollout within six months
• Pick which of these constraints are currently unmet Options: Dedicated integration engineer, Data extraction permissions, Validation sign-off, Budget approval, Legal or data processing agreement, Other
• Provide the earliest date by which your team could provide the access and resources listed above
• State the single constraint that would stop this project from moving forward if it is not resolved

Agreement triggers and next steps that accelerate a decision

• Outline the items that would let you sign a statement of work within two weeks after a successful pilot
• Mark which of these commercial or contractual items would accelerate your procurement Options: Trial pricing / limited scope PO, Standard SOW template, Pre-approved data processing agreement, Pre-agreed acceptance criteria, Validation deliverables included, Other
• Indicate the roles that must be included in the final procurement conversation to remove last-minute delays Options: Procurement, Legal, VP Quality, IT/Integration, Finance, Other
• Specify the one test or deliverable that, if completed successfully, would remove the main objection from procurement or legal
• Propose a target date for a follow-up to review collected artifacts and align final acceptance criteria Options: Within 1 week, Within 2 weeks, Within 1 month, Within 2 months, TBD

• Solution Experience Session

• Confirm the current state and its cost
• You confirm that the demonstrated ingest and normalization eliminate the manual rekeying described in Discovery.
• Run a sample ingest of the provided representative dataset and deliver the field mapping and normalization report before the follow-up session.
• You confirm the detection and trending shown would surface the types of emerging safety signals you are currently missing.
• Ingest a representative complaint example
• Produce a draft PSUR or PMS for the product family used in the session and deliver it for review.
• Provide a representative complaint dataset, a recent PSUR or equivalent report, and a list of critical product families to use in the proof.
• You confirm the generated PMS/PSUR draft meets your regulator-ready expectations and materially reduces report preparation time.
• Demonstrate signal detection and trending on your data
• Confirm the regulatory report acceptance criteria and any internal review checkpoints to validate the draft outputs.
• You agree the outstanding validation artifacts and a timeline for final acceptance testing.
• Generate a regulator-ready report from your example set
• Validate that this matches your needs
• Schedule a follow-up validation session with stakeholders to review delivered artifacts and vote on acceptance.
• Agree next steps and remaining evidence

• Solution Experience Session
• Solution Experience Deck
• Solution Brief — Ingestion and Regulatory Reporting

• meeting
• slides
• document

• Connect source CRM complaint feed
• Import and normalize historical complaint records
• Map and classify complaint intake fields
• Integrate field service and maintenance records
• Configure trending algorithms and alert thresholds
• Activate automated signal detection workflows
• Configure EU MDR and FDA vigilance report templates
• Automate regulatory report generation and submission
• Setup literature and external data monitoring feeds
• Link CAPA records to surveillance signals
• Build device-family performance dashboards
• Deliver validation package (IQ/OQ/PQ) and audit trail
• Provide end-user training and platform onboarding

Connect source CRM complaint feed

• Which integration method do you prefer for connecting your source CRM complaint feed (select the primary method)? Options: Real-time API/Webhook, Scheduled batch (SFTP/ETL), CSV export and manual ingest, Middleware / Integration platform, Other
• How many distinct CRM instances or business units must be connected (e.g., separate country/legal entity CRMs)? Options: 1, 2-5, 6-20, More than 20
• Who from your team will provide API credentials and approve connector tests for the CRM integration?
• When do you need the CRM feed to start syncing live complaint records (target go-live date)? Options: Within 2 weeks, 2-6 weeks, 6-12 weeks, Flexible / TBD
• Confirm whether the source CRM exposes complaint attachments (photos, PDFs) via the integration endpoint or if attachments will be sent separately. Options: Attachments via API/endpoint, Attachments via separate SFTP/transfer, No attachments available, TBD
• Specify any regulatory metadata required on each complaint record for downstream reporting (examples: device UDI or catalog number, incident date, patient outcome, country of event).

Import and normalize historical complaint records

• How many historical complaint records (approximate count) need migration into the surveillance database? Options: Less than 5,000, 5,000-25,000, 25,000-100,000, More than 100,000
• Which export formats are available for your historical data (select all that apply)? Options: CSV/Excel, Database dump (SQL), XML, Proprietary export, Other
• Identify the acceptable migration completeness threshold for historical complaints and their attachments (percentage of records that must be present and validated at migration close). Options: 95%, 98%, 99.5%, Custom value
• Specify whether historical records require normalization to clinical coding such as MedDRA terms or custom device failure taxonomy before trending. Options: Normalize to MedDRA, Normalize to custom device taxonomy, No coding normalization required, TBD
• Provide the primary fields that must be preserved and validated during normalization for regulatory retention (examples: report ID, event date, device serial/UDI, manufacturer action).
• What evidence will confirm successful historical import and normalization (e.g., sample record checklist, reconciliation count, checksum reports)? Options: Record-level reconciliation report, Random sample validation checklist, Automated checksum / row-count comparison, All of the above, Other

Map and classify complaint intake fields

• Which complaint intake fields must be mapped from your source CRM into the platform schema (examples: complaint type, complaint severity, device UDI, reporter role, corrective action taken)?
• How will you classify complaint root cause categories for trending (select preferred schema)? Options: Manufacturer-defined failure taxonomy, Standard taxonomy provided by platform, MedDRA for event terms plus device taxonomy, Hybrid
• Who will be the authoritative owner for mapping decisions and classification rules within your organization?
• When configuring automated classification, which accuracy threshold do you require before auto-accepting system-assigned classifications? Options: 70%, 80%, 90%, Manual review only
• Specify any custom dropdown values or free-text fields in your intake that must be preserved exactly (examples: complaint sub-type codes, local language notes).
• Will legacy complaint numbering or regulatory report IDs need to be retained and surfaced in every generated vigilance report? Options: Yes, retain and surface, Retain only internally, Do not retain, TBD

Integrate field service and maintenance records

• Which field service systems or record types must be ingested (examples: service visit reports, repair logs, preventive maintenance records)?
• How frequently should field service records be synchronized for trend correlation with complaints (options relate to event correlation sensitivity)? Options: Real-time / daily, Daily batch, Weekly batch, Monthly batch
• Who on your service organization will approve access to repair histories and serial-number level maintenance logs?
• Specify the minimum field set required from service records to enable root cause linking (examples: work order ID, repair action code, replaced part number, technician notes, hours in service).
• Are there regulatory constraints on sharing service-record PII (patient/customer identifiers) that require redaction before ingestion? Options: Yes, PII must be redacted, No, full records allowed, Partial redaction required, TBD
• Indicate whether you require device serial-level reconciliation between CRM complaints and service records during ingestion. Options: Yes, mandatory serial match, Preferred but not mandatory, No

Configure trending algorithms and alert thresholds

• Which trending methodologies do you want enabled for initial scope (examples: rolling-rate per 1,000 units, cumulative sum (CUSUM), signal-to-noise ratio)? Options: Rolling-rate per exposure, CUSUM / statistical process control, Simple count over time, Custom algorithm
• How many product families or device models should have distinct trending profiles and thresholds configured? Options: 1-5, 6-20, 21-50, More than 50
• Who will own threshold adjustments and approvals when a trend baseline changes (e.g., new launch or corrective action)?
• Specify an alert severity mapping to internal workflows (examples: informational, investigate, escalate to RA/QA within 48 hours).
• When a trend crosses a threshold, which downstream actions must be automated (select all that apply)? Options: Create surveillance case, Notify RA/QA by email, Open CAPA draft, Generate preliminary regulatory package, Other
• Indicate the minimum statistical confidence or rate increase required to flag a signal for initial review (examples: 20% increase vs baseline, p-value threshold). Options: 10% increase, 20% increase, 50% increase, Custom statistical threshold

Activate automated signal detection workflows

• Which signal detection workflows should be automated as part of scope (examples: duplicate clustering, temporal-spatial clustering, device model cross-reference)? Options: Duplicate clustering, Temporal spike detection, Spatial/lot clustering, Cross-model association, Other
• How should the workflow route suspected signals for first-line triage (examples: safety engineer queue, RA review, product team)? Options: Safety engineer triage, Regulatory affairs review, Product engineering review, Automated rules only
• Who will define the triage priority rules that move a detected signal to formal investigation?
• Specify whether automated enrichment is required when a signal is detected (examples: attach service records, literature hits, clinical complaints). Options: Yes, attach enrichment artifacts, No enrichment, Enrich on request
• Indicate the maximum acceptable time-to-first-notification after a signal detection during business hours. Options: Within 1 hour, Within 4 hours, Within 24 hours, Next business day
• Provide any required exclusions or rules to suppress known noise (examples: planned recalls, known device changes, seasonal patterns).

Configure EU MDR and FDA vigilance report templates

• Which regulatory report templates must be configured in scope (select all that apply)? Options: EU MDR serious incident report, EU periodic safety update (PSUR/PMSR), FDA Medical Device Report (MDR), EUDAMED submission-ready package, Other
• How many distinct device families require separate template variations due to different clinical intended use or risk class? Options: 1-3, 4-10, 11-25, More than 25
• Who will approve regulatory narrative language and sign-off for auto-populated report sections?
• Specify required regulatory attachments for each template (examples: sample cases, field corrective action reports, clinical evaluation excerpts).
• Indicate whether electronic submission formats are required (examples: XML for EUDAMED or FDA electronic formats) and which you need. Options: EUDAMED XML, FDA eMDR format, PDF-only, Both XML and PDF, TBD
• State the desired sign-off workflow for completed vigilance reports (examples: single RA approver, RA plus QA countersignature). Options: Single RA approver, RA + QA countersignature, RA + Legal, Custom approval flow

Automate regulatory report generation and submission

• Which submissions do you want automated end-to-end (from detection to regulator submission) versus generated as draft for manual review? Options: Fully automated submission, Draft generation then manual submit, Draft only, no automation, Hybrid
• How often should periodic reports be generated automatically (examples: monthly safety summaries, quarterly PSUR drafts)? Options: Monthly, Quarterly, Annually, Custom schedule
• Who will hold the regulatory account and credentials for direct electronic submissions (e.g., EUDAMED, FDA portal)?
• Specify required validation evidence for automated submission pipelines (examples: submission sandbox test, signed submission log).
• What defines successful automated submission for your organization (acceptance by regulator, platform receipt confirmation, signed audit trail)? Options: Regulator acceptance, Platform submission confirmation + audit trail, Both regulator acceptance and audit trail, Other
• What evidence will you require to accept the automated submission capability during handoff (examples: sample submission in regulator sandbox, reconciliation report)? Options: Sandbox submission proof, Submission reconciliation report, Signed acceptance by RA lead, All of the above

Setup literature and external data monitoring feeds

• Which external sources should be monitored for literature and safety signals (examples: PubMed, regulatory safety notices, device registries, social media)? Options: Peer-reviewed databases (e.g., PubMed), Regulatory safety bulletins, Device registries, Industry news and bulletin feeds, Other
• How frequently should literature feeds be polled for new hits for active product portfolios? Options: Daily, Weekly, Monthly, Custom cadence
• Who will set relevance rules for literature screening (examples: device model match, clinical outcome keywords, patient population filters)?
• Specify the minimum metadata to capture from each literature hit to support regulatory citations (examples: DOI, PMID, abstract, publication date, matching device model).
• Indicate whether you require automated citation linking into vigilance reports and which citation style or reference identifiers to use. Options: Auto-link citations to reports using DOI/PMID, Manual citation selection, No automated linking
• Identify any paywalled or subscription sources that require credentials for feed access and whether your team will supply those credentials. Options: We will supply credentials, Platform to procure access, No paywalled sources required, TBD

Link CAPA records to surveillance signals

• Which CAPA systems or record types should be linked to surveillance signals (examples: internal CAPA system, corrective action change logs, supplier corrective actions)?
• How should a detected signal convert into a CAPA artifact (examples: auto-create CAPA draft, create linked investigation ID, notify CAPA owner)? Options: Auto-create CAPA draft, Create linked investigation record, Only notify CAPA owner, Other
• Who will be the owner of CAPA linkage rules and who approves automatic CAPA creation?
• Specify required data fields from surveillance signals to populate CAPA records (examples: root cause hypothesis, affected lot/serials, supporting evidence links).
• Indicate whether CAPA closure criteria should automatically check back against live trends to verify resolution. Options: Yes, automatic verification, Manual verification required, No automatic check
• List any regulatory reporting requirements that must be triggered on CAPA open or close (examples: notify competent authority within X days).

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Order Form (Subscription Agreement)
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• HIPAA Business Associate Addendum (BAA) — conditional
• Data Access Authorization
• Validation & CSV Deliverables
• Security & Privacy Addendum
• Acceptance Test Protocol and Go‑Live Certificate
• Change Order Agreement
• Governance & Steering Committee Charter
• Source Code Escrow Agreement (optional)

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate — Outcome Acceptance and Wind-down Check (around day 90)
• Quarterly Success Review (operational quarterly)
• Annual Outcomes and Lessons Learned

• Update the KPI dashboard with the latest weekly active user and reporting-time trends and circulate to stakeholders.
• Re-confirm acceptance criteria and owners
• Publish the acceptance decision record that lists pass/fail per criterion and the buyer signatory details.
• Execute the incumbent system decommission or retention actions and publish the archive/migration confirmation.
• Open remediation tickets for any failed criteria with resolution owners and target dates.
• Trend review for adoption and reporting efficiency
• Validate that weekly active users and average time to generate MDR/PSUR reports remain within acceptable variance of Solution Scope targets or have a remediation plan.
• Ensure all high-priority CAPA linkage requests have owners and target closure dates.
• Agree the prioritized enhancement list to be worked in the next quarter and the expected delivery windows.
• Capture and assign all high-severity blockers with target resolution dates.
• Open or update CAPA linkage tickets with target resolution dates and publish the status summary.
• Publish the prioritized enhancement list for the next quarter with expected delivery windows.
• Annual outcome validation
• Confirm whether annual compliance on-time report submission rate and total hours saved met the Solution Scope targets.
• Capture and publish a lessons-learned summary with at least three specific process improvements.
• Establish the persistent shared channel and governance process for issues, CAPA linkages, and enhancements for the next year.
• Publish the annual outcomes report with evidence for compliance rates and hours-saved calculations.
• Publish the lessons-learned summary and recommended process changes.
• Record and communicate the agreed persistent shared channel and governance steps for CAPA linkage and enhancement requests.
• Confirm go-live validation checks show connectors and ingestion running with no critical failures.
• Confirm the list of named owners for acceptance criteria recorded in Solution Scope.
• Publish the go-live validation report including ingestion counts and error summary.
• Create remediation tickets for each high-severity blocker with target resolution dates.
• Confirm access lists and provision missing accounts required for adoption tracking.
• Present first KPI results vs Solution Scope targets
• Determine whether percentage of complaint records integrated and hours per week on manual reporting are trending toward Solution Scope targets.
• Agree specific root-cause actions with dates to address any metric gaps before the acceptance gate.
• Confirm timeline to the acceptance gate and the criteria that will be rechecked at that meeting.
• Publish a remediation plan that lists data fixes, field-mapping updates, and their target completion dates.
• Adjust algorithm thresholds or classification rules identified as causing false positives or missed signals.
• Run a scoped data re-ingestion for identified missing records and report the updated integration percentage.
• Restate acceptance criteria from Solution Scope
• Produce a documented acceptance decision with pass/fail status for each Solution Scope criterion and capture the buyer's named signatory for enterprise ratification.
• Confirm incumbent system is either decommissioned or formally retained read-only with data archived or migrated and a cutoff date agreed.
• Agree remediation items and a re-evaluation timeline for any failed or conditional criteria.
• Present outcome data against each acceptance criterion
• Lessons learned and process improvements
• Deployment and migration validation
• Open issues and CAPA linkage status
• Diagnose root causes for gaps
• Enhancement and backlog prioritization
• Early adoption and usage signals
• Document pass/fail per criterion and capture acceptance decision
• Review trending and signal-detection performance
• Confirm persistent governance and shared channel
• Open defects and blockers
• Incumbent system wind-down status
• Agree corrective actions and timeline to acceptance gate
• Short operational actions and next steps
• Annual action plan
• Agree remediation plan for any failed criteria
• Agree immediate remediation actions