Enterprise data platform engineering for MedTech, built around the question a device company should be able to answer in minutes and usually cannot: what has happened to this serial number?
A unit is designed, built, shipped, installed, configured, serviced, upgraded and eventually generates a complaint. Each event is recorded in a different system, under a different identifier. Reconstructing its history can take days and several people.
Engineering knows it by part number and revision. Manufacturing knows it by work order and build record. Supply chain knows it by shipment and distributor. Service knows it by asset tag or whatever the hospital wrote down. Quality knows it by complaint reference. The physical device is one thing and the enterprise holds six partial representations of it, none of which were designed to reconcile with the others because each system was procured to solve its own problem well.
The consequence is that every cross-functional question becomes a project, and the questions that matter most in a device company are all cross-functional.
Identity differs by
function
Part number, work order, serial, asset tag and complaint reference all describe the same unit and none of them join.
Systems were bought to solve local problems
PLM, MES, ERP, QMS, CRM and service platforms each do their job well and were never intended to interoperate.
Cross-functional questions become projects
Which means they are asked rarely, answered partially and never repeated the same way twice.
Definitions differ across functions
Installed base, active device, failure and field action mean different things to service, quality and commercial.
Analytics and AI readiness is blocked upstream
Inconsistent definitions, incomplete relationships and unreliable pipelines limit reporting and modelling regardless of which tools are selected.
The urgent questions arrive during an investigation
When a reconstruction taking a week is a reconstruction happening at the worst possible time.
Most MedTech data platform programmes begin with ingestion and discover the identity problem during the first cross-domain question. Resolving device identity across the lifecycle is the foundational work, it is unglamorous, and every analytical capability the business actually wants depends on it existing.
Step 1
Start from the questions the business cannot currently answer, since those define what the platform must join.
Step 2
Resolve device identity across the lifecycle, mapping part, build, serial, asset and complaint references to one unit.
Step 3
Model the device as a timeline rather than a record, because its configuration, location and owner all change.
Step 4
Preserve the source form alongside the integrated model, since reconciliation decisions get revised.
Step 5
Define the contested terms once, because installed base and active device mean different things per function.
Step 6
Connect device telemetry to the physical unit, which is the join most device platforms do not currently have.
Step 7
Build data products around business entities rather than source system tables, so a consumer does not need to understand six schemas to ask one question.
Step 8
Build traceability as a platform property, so an investigation is a query rather than a reconstruction.
Step 9
Establish governance proportionate to use, since quality and regulatory consumers need more than commercial ones.
Step 10
Make the platform answer the original questions, and measure it on that rather than on sources integrated.
A device is a timeline, not a row. Tracking configuration, firmware, ownership and service history over time enables accurate answers to historical questions and supports reliable investigations.
General lakehouse, pipeline and warehouse engineering is covered on our data platform pages. These are the capabilities specific to a company whose core entity is a physical device moving through the world.
Capture and Understand
Device Identity Resolution
Mapping part, build, serial, asset and complaint references to one physical unit across the systems that each hold a fragment.
Cross-System Integration
PLM, MES, ERP, QMS, CRM, service and device platforms connected with their identifiers reconciled rather than loaded alongside each other.
Device Telemetry Integration
Connected device data joined to the physical unit, the build record and the service history, which is usually the missing link.
Supplier and Component Lineage
Which lot went into which unit, which is the join an investigation needs and which frequently stops at the work order.
Model
Device Lifecycle Modelling
The unit as a timeline of states covering configuration, firmware, location, owner and status, each with effective dates.
Canonical Semantic Layer
Installed base, active device, failure, field action and the other contested terms defined once with an owner.
Lakehouse & Warehouse Architecture
Storage and modelling designed around consumption, covered on our platform pages and applied to device data volume.
Source Preservation
Original forms retained alongside the integrated model, so a reconciliation decision can be revisited rather than being permanent.
Serve and Govern
Traceability as a Query
Full device history retrievable directly, so an investigation starts with an answer rather than a reconstruction project.
Analytics and AI Enablement
Governed datasets for quality, service, commercial and engineering consumers, each at the rigour their use requires.
Governance and Lineage
Ownership, definitions, lineage and quality monitoring, covered in depth on our data governance page.
Platform Operations
Pipeline reliability, data freshness, cost against installed base growth and the monitoring that makes failures visible.
These are the questions device companies most want answered and most struggle to answer. The third column is what the join requires, and the pattern is that each needs two or three systems that do not currently reconcile.
| The Question | Who Asks It | What the Join Requires |
|---|---|---|
| Which units contain this component lot | Quality, during an investigation or recall assessment | Supplier receipt to build record to serial to shipment destination |
| Are failures concentrated in one build period | Quality and manufacturing | Complaint and service records joined to build date, line and shift |
| Does this firmware version fail more often | Engineering and post-market | Device telemetry and firmware history joined to complaints and service |
| What is our actual installed base | Commercial, service and quality | Shipment, installation, service activity and decommissioning, reconciled |
| Which devices are affected by this field action | Quality and regulatory | Build characteristics to serials to current location and owner |
| Why does this customer have more failures | Service and commercial | Service history joined to configuration, environment and usage telemetry |
| What did inspection see on this unit | Quality, during a complaint investigation | Manufacturing inspection records joined to serial and complaint |
Installed Base: One Number, Multiple Definitions
Commercial, service, quality and finance teams often report different installed base figures because each relies on different source data. Reconciling shipment, installation, ownership and decommissioning records establishes a trusted installed base for reliable reporting and post-market analysis.
A MedTech data platform integrates sources with genuinely different characteristics, and treating them with one ingestion pattern produces a platform that handles none of them well. The third column is what each actually demands.
| Source | What it looks like | What it demands |
|---|---|---|
| Device telemetry | High volume, continuous, arriving from the field | Volume engineering, late arrival handling and device identity resolution. |
| Manufacturing systems | Structured, high volume, batch oriented | Lineage from component lot through build to serial number. |
| Quality systems | Lower volume, high consequence, heavily governed | Traceability, retention and controlled access. |
| Service and field systems | Semi-structured, frequently free text, inconsistent | Extraction and reconciliation to the device, covered on our Document AI page. |
| Supply chain and ERP | Structured, transactional, commercially sensitive | Component lineage and the shipment-to-installation gap. |
| Engineering and PLM | Document heavy, revision controlled, slow changing | Revision applicability mapped to the units actually built to each revision. |
A commercial dashboard and a traceability record extracted during an investigation sit on the same platform and carry entirely different obligations. Applying quality system controls to everything makes the platform slow and expensive. Applying none makes the evidence indefensible. The useful architecture separates the two explicitly, which is a governance decision taken at design rather than a control applied afterwards.
Traceability
- Device history reconstructable for any serial at any past date, which is the platform core obligation
- Lineage from any reported value back to its source system and record
- Component and lot lineage maintained to serial level rather than to work order
- Historical states preserved, since the question is always what was true at the time rather than now
Governance
- Contested definitions owned by a named function, particularly installed base and device status
- Quality system data governed to its own obligations rather than to general platform standards
- Change to definitions, models or transformations governed as a release, since each restates history
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, ISO 13485, GxP expectations and electronic record requirements
Security
- Access governed by purpose as well as role, since commercial and quality consumers need different scopes
- Patient-associated device data handled to the obligations your counsel defines, covered on our privacy page
- Customer and supplier commercial information protected to the relevant agreements
- Export and bulk access monitored, as the largest disclosure surface in any integrated platform
Evidence
- Applicability, interpretation and validation strategy determined by your quality and regulatory functions rather than by us
- Datasets frozen behind any submitted or published analysis
- Retention aligned to the obligation on each data class rather than applied uniformly
- Evidence producible without an engineering exercise each time it is requested
Pipeline monitoring reports whether jobs ran, how long they took and whether anything errored. None of that establishes whether the data arriving is correct, complete or still means what it meant last month. The failures that matter in an integrated device platform are semantic rather than operational, and they pass every technical check.
Identity resolution rate
The proportion of records successfully joined to a device, since unmatched records disappear from every analysis.
Completeness against expectation
Devices expected to report against devices reporting, since absence is the signal and absence produces no error.
Definition stability
Whether a metric still means what it meant, since a definition change restates history with no data event.
Freshness per source
Because the dashboard presents a weekly extract and live telemetry identically.
Volume against installed base
Since data volume should track units shipped, and divergence indicates a connectivity or ingestion problem.
Cost per device per year
Which is the economic measure for a platform whose volume grows with the business.
Data platforms are usually reported as sources integrated and pipelines running. The outcome that matters in a device company is whether the questions that used to take a week now take an afternoon, and whether anybody trusts the answer.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Reconstruct Without Five Spreadsheets | Whether you can identify the correct configuration, retrieve manufacturing history, identify component lots, link supplier and inspection records, determine the firmware at a given time, retrieve quality events, associate service history, connect complaints, identify each record source, explain the transformations and reproduce the result later. | If this needs extensive manual reconciliation, the platform has not yet done what it exists to do. |
| Serial Number Reconstruction Time | Time to produce a complete device history for one unit. | The clearest measure of whether the platform delivers on its purpose. |
| Identity Resolution Rate | Records successfully joined to a device, by source. | Unmatched records represent devices missing from analysis. |
| Lot-to-Serial Coverage | Component lineage traceable to an individual unit rather than only to a work order. | Determines how wide a field action has to be. |
| Installed Base Agreement | Whether commercial, service, quality and finance teams report the same installed base figure. | The denominator used in most post-market analysis. |
| Historical Reconstructability | Whether the platform can establish what was true on a specific past date. | Investigation questions depend on historical accuracy. |
We will run the serial number reconstruction exercise on a real unit, assess whether device identity can be resolved across your systems, establish whether component lineage reaches serial level, examine the installed base definitions in use, and identify which cross-functional questions the platform would make answerable.
Bring us a healthcare workflow that consumes too much staff time, depends on manual processes, crosses multiple systems, or could benefit from more intelligent automation.
One conversation tracing a real device through your systems, and a written identity, lineage and reconstructability assessment.
Security & Compliance
