Offerings and example engagements for Medical devices and MedTech — not published client case studies.
Why · How · What
Why
In MedTech the regulatory record and the operational record have to stay aligned. A device that exists in the ERP but not in the regulatory systems creates submission, recall and commercial risk — and those systems were almost never designed together.
How
Treat regulatory data as production data — same lineage, same validation, same audit trail you would give a financial ledger.
What
UDI and device data consolidation, EUDAMED and submission pipelines, complaint and vigilance data flow, field and consignment inventory, SAP and Salesforce integration, validated environments.
Why this matters now
For EU MDR and IVDR economic operators, four EUDAMED modules became mandatory to use from 28 May 2026 following Commission Decision (EU) 2025/2371: actor registration, UDI/device registration, notified bodies and certificates, and market surveillance. Exact obligations depend on role, device category and the applicable transition rules. This is not legal advice — confirm requirements with your regulatory counsel and the European Commission EUDAMED overview.
Industry guidance commonly cites a further registration window around 28 November 2026 for certain devices already on the market before 28 May 2026 that continue to be placed afterwards. Treat dates and scope as jurisdiction- and product-specific.
For most manufacturers this is a data problem before it is a filing problem. Device information typically sits across quality systems, regulatory databases, product lifecycle tools and spreadsheets, and submission records need to stay consistent with technical documentation, labelling and certificates.
Scopes of work
Example engagement — illustrative. Typical scopes of work, not named client case studies.
Legacy device registration before the November deadline
Why it happens
New devices got registered because someone owned the launch process. The legacy back-catalogue never had an owner, and its attributes are scattered across PLM, the regulatory information system, SAP material master, labelling files and spreadsheets held by individual regulatory staff. Nobody has ever had to make those five sources agree.
How we work it
We build a single reconciled device record joining every source, and name each attribute that has no authoritative owner rather than picking one silently. Records are validated against the EUDAMED data model and cardinality rules before submission, and checked for consistency against technical documentation, labelling and certificate data. Submission runs in bulk with per-record status tracking, so regulatory affairs works a queue of genuine exceptions instead of chasing rejections.
What you end up with
A reconciled dataset with per-attribute source and gap analysis, pre-submission validation, and a tracked run where a failure is a queued exception rather than a discovery.
One device, five systems, five versions of the truth
Why it happens
Each function bought the system that suited it and mastered the attributes it cared about. PLM owns engineering truth, SAP owns commercial truth, the regulatory database owns submitted truth, and none was designed to defer to another. Every function is correct within its own boundary.
How we work it
We profile every attribute across all systems and quantify the divergence, then define the system of record per attribute rather than per system — which is the decision most programmes get wrong. A mastered record is built with lineage back to each source and published as the feed downstream systems consume, with divergence instrumented so new drift becomes visible instead of accumulating.
What you end up with
An attribute-level system-of-record map the functions have agreed, a mastered record with lineage, and drift measured rather than rediscovered at the next audit.
Implants and instrument sets live in hospital consignment, in loaner kits in transit and in sales-rep car boots. The systems were built to track warehouse stock, not stock that moves with a surgeon’s schedule. So the ERP position and the physical position diverge continuously, which is a revenue recognition problem, an expiry and recall problem and a working-capital problem at the same time.
How we work it
We integrate the field inventory system, SAP and the case-scheduling or CRM record around a single kit and lot identity, then reconcile scanned events against system movements on a schedule and classify the variances by cause. Kit cycle time is instrumented from despatch to return to re-availability, expiry and lot status surfaced at the point of use, and exceptions routed to whoever can physically resolve them.
What you end up with
Scheduled physical-to-system reconciliation with variances classified, kit cycle time measured end to end, and expiry exposure visible by location.
Complaints enter through customer service, sales reps and distributors, each in its own format, because each channel was built independently. The regulatory reporting clock starts at intake, and incomplete intake data means triage begins with chasing rather than assessing.
How we work it
We define a canonical complaint record and map every channel to it, validating completeness at the point of entry rather than in triage. Device, lot and UDI linkage is automatic so device history is available immediately. Time-to-triage and time-to-decision are instrumented against the reporting clock, with an immutable audit trail of every state change.
What you end up with
A canonical complaint record with channel-level validation at intake, automatic device and lot linkage, and reporting timelines instrumented rather than estimated.
Certificate and device data that has to stay aligned
Why it happens
Certificate scope, device classification and technical documentation must stay mutually consistent, but they are maintained by different people on different cycles. Notified-body capacity and legacy certificate transitions remain constrained across the EU framework. Inconsistency delays linkages that gate market access.
How we work it
We model the certificate-to-device relationship as data, with scope, expiry and conditions, and reconcile it continuously against registered device attributes. Expiring certificates alert against the transition timeline, exceptions arrive as a weekly report regulatory affairs can actually work, and evidence of each check is retained for inspection.
What you end up with
A continuously reconciled certificate-to-device map with expiry alerting, a weekly exception report, and retained check evidence.
Validated cloud environments without validating by hand
Why it happens
The qualification approach was designed for physical infrastructure that was installed once and changed rarely. Cloud infrastructure is recreated on every deployment, so manual qualification either blocks delivery or gets skipped, and both outcomes are bad.
How we work it
Infrastructure is defined as code with installation and operational qualification expressed as automated tests, so qualification evidence is generated by the pipeline run itself. Every change traces back to a requirement, audit trails stay immutable, and the validation rationale is written for inspection before the build rather than reconstructed for it afterwards.
What you end up with
Qualified environments provisioned from code, evidence produced automatically by the pipeline, and a validation approach documented in advance.
