Medical Device Software Development
Pinetics develops embedded software and firmware for medical devices, working to the IEC 62304 software lifecycle and ISO 14971 risk management, inside our customers’ ISO 13485 quality systems. The documentation a 510(k), CE or CDSCO submission requires is produced as the work proceeds, in the form your quality system expects, rather than reconstructed at the end.
Standards We Work To
Which standards does medical device software have to meet?
We scope every medical programme against the standards that decide whether it can be sold: IEC 62304 for the software lifecycle, IEC 60601-1 and its collateral parts for electrical safety, EMC and alarms, and ISO 14971 for risk management, all inside your ISO 13485 quality system.
We work to the market route as well, whether that is an FDA 510(k), EU MDR, UK MHRA or India’s CDSCO. The standard is agreed before engineering starts, because it decides the documentation burden, the test plan and the cost. Agreeing it late means redoing work you have already paid for.
Beyond medical. Our industrial and IoT work brings the neighbouring standards with it: IEC 61010, IEC 61508, the IEC 61000 series, IP ingress ratings, and FCC, CISPR and EN 55032 for export markets. They matter the moment a medical device has to survive a real environment or a real factory.
- IEC 62304 · Medical device software lifecycle: software development plan, safety classification, SOUP list and software bill of materials, traceability from requirement to test
- IEC 60601-1 · Electrical safety and essential performance: isolation strategy, creepage and clearance, risk-relevant design decisions recorded
- IEC 60601-1-2 · Electromagnetic disturbances: EMC test plan and pre-compliance at an accredited laboratory
- IEC 60601-1-8 · Alarm systems: alarm priority, latency and failure behaviour treated as safety requirements
- IEC 60601-1-11 · Home healthcare environment: environmental and usability constraints designed in, not retrofitted
- ISO 14971 · Risk management: hazard analysis feeding design input, residual risk traced to mitigations
- ISO 13485 · Quality management: outputs delivered in the form your QMS expects, supplier audits supported
- IEC 62366-1 · Usability engineering: use-related risk analysis, user interface specification, and formative evaluation feeding back into the risk file
- FDA 510(k) · EU MDR · UK MHRA · CDSCO: documentation produced as the work proceeds, in the shape the submission needs
How We Work
How is a medical device programme structured?
A phased programme running from kick-off to design transfer, with a formal design review closing each phase. A phase does not end because the calendar says so. It ends when its exit criteria are signed.
Kick-off, quality system setup and architecture
We agree to the quality system, the plan and the requirements first, then the architecture. The architecture gate closes on artefacts, not opinions. Where you already have a prototype, the first gate is an audit and baseline review of what actually exists before anyone commits to a schedule or a cost. Every step is planned and time-tested.
- Baseline review of anything that already exists
- Signed hardware and software interface control document
- Accepted power budget with worst-case envelope sizing
- Accepted thermal feasibility study and signed cybersecurity architecture decision
Schematic, layout and firmware
Schematic design, PCB layout and design for manufacture, with firmware running in parallel rather than waiting for boards. Every design stage is paired with its own review and rework step, so a second engineer catches a defect before it reaches fabrication. Layout is reviewed against what your chosen fabricator can actually hold, not against theory.
- Schematic design, then independent schematic review, then rework
- Layout, then layout review against real fabricator capability, then rework
- Firmware developed in parallel and proved on an evaluation kit first
Verification, EMC pre-compliance, certification
Prototype build, bring-up and engineering validation, then verification against the requirement and design validation against user needs, and EMC pre-compliance at an accredited third-party laboratory. Medical device documentation runs continuously through the programme and is consolidated at the end, and then a design transfer.
- Board bring-up, rail by rail, interface by interface
- Verification against the agreed requirement, then design validation
- EMI and EMC pre-compliance at TÜV Nord, TÜV Rheinland, ARAI and other internationally accredited laboratories
- Design transfer: source, design files, manufacturing data and test evidence
Safety-Relevant Behaviour
How should safety-relevant software behaviour be tracked?
Safety-relevant behaviour is logged and closed like any other defect. On one connected-health wearable this included a device raising an emergency alert with no skin contact and no key press, an alert reaching the cloud a cycle later than it should have, and a heart-rate confidence index collapsing to zero after an alert reset. A device that alarms when it should not is a hazard, and so is a device whose alarm arrives late.
Traceability
Will the documentation survive an audit?
Design files carry a structured configuration-management code that ties every schematic, layout and review finding to a specific customer, board and revision. Board revisions are tracked as their own work streams. That is the traceability a regulated audit asks for, produced as a by-product of how we work rather than assembled afterwards. This is what FDA design controls under 21 CFR 820.30 ask for, and what populates a design history file (DHF): design inputs, outputs, reviews and changes, each with a date and a named owner.
- Named reviewer and named owner on every finding
- Written client sign-off at every gate
- Configuration codes tying each document to a board revision
- Reuse baselines audited before they are trusted
Device Types and Classes
What kinds of medical devices need custom embedded software?
We build the electronics and software inside active medical devices, across therapy, diagnostics, monitoring and surgical support. Our work spans cardiac and vascular, respiratory, wound care and tissue therapy, surgical instruments and robotics, patient warming and temperature management, and remote and home monitoring across paediatric, adult and geriatric care.
Regulators separate software embedded in a device from software as a medical device (SaMD), which is itself the device. IEC 62304 governs the lifecycle of both, and the discipline is the same either way: safety classification for every software item, a documented SOUP list, and traceability from requirement to test. Our delivered work to date is the embedded and connected side, the software inside the instrument and the software around it, and the same process carries across to a standalone SaMD product.
Where the real difficulty sits. Most medical programmes that come to us are doing something that has not been done in quite that way before. The difficulty is rarely the electronics on their own. It is holding a novel idea and a regulatory pathway in the same hand: proving a new sensing method while keeping the risk file coherent, or reaching a power budget that a home-use device needs without weakening an alarm the standard requires.
That is the work we are built for. Our engineers learn a new clinical domain, a new sensing modality or a new silicon platform as a normal part of a programme, and our founders are engineers who are in the room while it happens.
Clearing compliance is part of the job. Understanding the standard is not the same as clearing it. We treat EMI and EMC testing at the accredited laboratories named above as a scheduled, costed task, budget a test cycle per hardware revision so a re-spin cannot silently skip re-testing, and produce the documentation in the form your submission needs.
United States · FDA
Class I, Class II and Class III under 21 CFR. The class and the software safety classification together decide the evidence you must produce, and on a 510(k) route the predicate shapes the testing. We scope the work to whichever class your device falls in.
European Union · EU MDR 2017/745
Class I, IIa, IIb and III. Rule 11 of the Annex VIII classification rules places most medical device software above Class I, so technical documentation, clinical evaluation and notified body involvement are scoped from the first gate.
United Kingdom · MHRA
Class I, IIa, IIb and III under the UK Medical Devices Regulations 2002, with UKCA marking for the Great Britain route. Close to the EU classes in shape, but a separate conformity route, so we plan the evidence for both markets together.
India · CDSCO
Class A, B, C and D under the Medical Devices Rules 2017, ordered from low to high risk. We produce what a manufacturing licence or import registration needs alongside the export route, rather than as a second exercise.
The class changes the evidence you must produce, not whether we can engineer it. We work from low-risk accessories through to devices where a software failure is a patient hazard, and we scope documentation and testing to the class and the market route from the first gate.
Why Pinetics
How do you verify a medical device development partner delivers?
100,000+ engineering hours delivered, and counting.
Every hour is booked to a named task, not a monthly lump sum, so you can see exactly what a month bought. Every design stage is reviewed by an engineer who did not draw it, and every finding is logged as a tracked defect with a named owner and closed before release. Every gate needs your written sign-off before the next one starts.
That is the whole argument. Not that we are large, but that nothing on your programme is invisible to you.
What we bring
- A multi-role core delivery team, with specialists engaged per phase
- Programme management for the full duration, not just at reviews
- Independent review at every design stage, before fabrication
- Accredited third-party EMI and EMC testing, budgeted per hardware revision
- Every hour booked to a named, trackable task
- A software bill of materials (SBOM) delivered with the documentation
- Supplier audits supported
Expertise
Founder-led engineering. Our leadership carries 20+ years in electronics and firmware and stays in the room on medical programmes, rather than handing them to a delivery layer.
Technology
Silicon, sensing and connectivity chosen for the device, not for our convenience. We weigh the platform against the power budget, the safety classification and the update path before the schematic is drawn.
Customer Focus
You own the IP, you sign every gate and you see every hour. Scope, acceptance criteria, obligations, term and termination are agreed in the statement of work before any engineering begins.
Common Questions
How do you choose a medical device software development company?
Ask what the exit criteria are for the architecture gate, which standards the work will be scoped against, when EMC testing happens and at which accredited laboratory, who signs off each gate, how effort is tracked, and what you receive at handover. Answers that name an artefact, a date or a number are real answers.
No, and that is deliberate. We work inside our customers’ quality management systems. The QMS a notified body or the FDA audits is the device manufacturer’s, not their design partner’s, so a second certificate would add regulatory cost to your programme without adding evidence to your submission. If your quality system requires a supplier audit, we support it.
A software development plan, a safety classification for every software item, a documented SOUP list for anything you did not write, and traceability running from each requirement through design to the test that proves it. We produce these as the work proceeds, in the form your quality system expects.
Both, and most clients who come to us for medical work want them together. We design the schematic and PCB, write the firmware, bring the boards up, run verification and take the hardware through EMC pre-compliance. Splitting hardware and software across two suppliers is where most integration defects are born.
The first gate is an audit and baseline review: what works, what is reusable and what has to be redone, before anyone commits to a schedule or a cost. Reuse in a regulated context is only safe when its provenance is documented, so the reuse baseline is itself a gate item.
The cybersecurity architecture decision is a signed exit criterion of the architecture gate, before schematic design starts. It is not deferred to a late-stage review, because the threat model shapes the hardware, the update path and the data flow, and all three are expensive to change afterwards. We build the software bill of materials (SBOM) an FDA submission asks for from the documented SOUP list, and deliver it with the rest of the documentation.
You do, and it is set out explicitly in the statement of work before any engineering begins, alongside scope, acceptance criteria, both parties’ obligations, term and termination. At design transfer you receive the source, design files, manufacturing data and test evidence.
Yes. We scope work against the market route from the first gate, whether that is an FDA 510(k), EU MDR, UK MHRA or India’s CDSCO, and produce the documentation in the shape that submission needs. We deliver to clients in the United States and Europe and run reviews directly with them in English.
It depends on the class and the market route far more than on the code. What we can commit to is the shape: a phased plan with a formal design review closing each phase, and a phase that ends when its exit criteria are signed rather than when the calendar runs out. We give you the gate plan before you commit.
Both. We work with companies taking a first device through its first regulatory cycle, which is exactly when getting the standard and the documentation right early saves the most money, and with established manufacturers adding to an existing portfolio. Our founders are engineers and are in the room on both.