Location: Remote (U.S. only, excluding Alaska and Hawaii)
Job Type: Full-time
Innolitics is a remote-first medical device consultancy that brings software engineering, AI/ML validation, cybersecurity, regulatory affairs, and quality management together on one team. Since 2012, we've helped 70+ medical devices reach market, including 50+ FDA clearances. Learn how we take devices from concept to clearance.
We're hiring a Quality Assurance Specialist to lead implementations of Medtech OS—our Notion-based quality management system—and provide ongoing quality services to medical device companies, especially teams developing software and AI/ML-enabled devices.
You'll help clients turn quality requirements into practical, sustainable ways of working. Engagements include building a QMS from the ground up, remediating an existing QMS, implementing Medtech OS, training client teams, and providing ongoing support for day-to-day quality activities.
You may support submission-related projects only where they intersect with the QMS, including design controls, risk management, software lifecycle processes, and audit-ready quality records, but this role is focused on the quality side of things. If you’re interested largely in the regulatory side, please apply to one of our other positions.
This position is fully remote, with 3–4 trips per year, including client or conference travel and our annual company retreat.
Use the Apply Now button below to submit your resume and cover letter. Your cover letter should be three or four short paragraphs explaining why this position in particular interests you and why you're a great fit.
In the cover letter, briefly explain:
We'll review your application and contact strong matches. The process includes interviews, a short take-home exercise, and two reference checks.
Send your resume and cover letter.
What the job looks like
The posting above lists what we look for. This part shows the work itself: the disciplines you own and the tasks you do at each stage of a project. Read it and decide whether you would enjoy doing this work.
Knows
Quality
You can do every task in this lane yourself and lead others through it.
Aware of
Regulatory
You know what this lane produces, when your work depends on it, and whom to ask.
Scroll sideways to see all eight stages.
Quality agreement. DHF template, QMS roles, training. Start the supplier list.
For a quality assurance specialist: Knows
Settle whose QMS governs the work with regulatory and the client before kickoff ends. Train engineering on the procedures they will be audited against.
Open the task page: decisions, examples, articlesYour lane, stage by stage
Each stage lists the quality work, the decisions you make, and the one conversation with another discipline that most often decides whether the stage goes well.
Kickoff and plan · Month 0–1
Before design work starts, the team decides which quality management system the project runs under: the manufacturer's own, the development partner's, or a new one built for the device. A quality agreement then records which party carries each quality system obligation. The design history file is started from a template, quality system roles are assigned in the development plan, the team is trained on the procedures it will follow, and an approved supplier list is opened.
Decisions you make:
Read more:
How each decision is made: Choosing the quality system and setting up the design history file
Study design and pre-sub · Months 1–4
Once the intended use and study design are settled, the requirements, user needs and the datasets they depend on are reviewed, approved and placed under document control. From that point every change goes through change control. In parallel, the suppliers who will produce evidence are qualified: data providers, the annotation platform, annotators and reader sites. Their selection criteria, training and contracts are recorded before the work begins.
Decisions you make:
Read more:
How each decision is made: Putting design inputs and study suppliers under control
Risks and requirements · Months 2–4
Quality approves the risk management plan, which fixes the severity and probability scales, the acceptability matrix and the criteria for residual risk before risk analysis begins. As requirements and risk controls are written, quality checks that each risk control traces to a requirement and each requirement traces to a verification protocol. The phase 1 design review closes the stage, with at least one reviewer who did not do the work.
Decisions you make:
Read more:
How each decision is made: Approving the risk plan and checking traceability
Build sprints · Months 4–14
During build sprints every code change goes through a pull request that a second engineer reviews against a checklist before it merges, and automated tests must pass first. Problems found along the way go into an anomaly log with a link to risk. A short design review at the end of each sprint confirms that requirements, design documents and tests moved with the code. Training records show each person was trained on the procedures before doing the work.
Decisions you make:
Read more:
How each decision is made: Controlling change during build sprints
Verification · Months 14–16
Quality makes sure every verification protocol is reviewed and approved, with pass and fail criteria fixed, before anyone runs it. During execution, quality records who ran each test, on which software version and on what date. Every failed test or deviation gets a written disposition, and any code change it causes gets a regression analysis. The exact build that passed is then archived so it can be rebuilt and inspected later.
Decisions you make:
Read more:
Validation and submission · Months 16–17
After validation, quality runs the final design review. The team confirms that verification and validation are complete, residual risk is acceptable, and the release build and its labeling are ready to be handed to production. For software, design transfer means the build, installation instructions and labeling move under release control. Quality then audits the design history file against the development plan and collects the approval signatures, including the truthful and accurate statement for the submission.
Decisions you make:
Read more:
How each decision is made: Final design review and DHF audit
FDA review · About 5 months
Deficiency responses often change software, labeling or test protocols. Quality makes sure each change goes through the same change control as any other release, with a new version number, regression analysis, re-verification and updated design documents. While FDA reviews the file, quality also stands up the processes the company needs before it can legally sell, such as complaint handling, CAPA and medical device reporting.
Decisions you make:
Read more:
After clearance · Ongoing
After clearance the manufacturer registers its establishment, lists the device, and issues a unique device identifier for each software build. Quality then runs the routine processes FDA inspects: complaint files, medical device reporting, CAPA, change assessment for each release, internal audits and management review. These processes produce the evidence that the cleared device is still the one being shipped and that field problems are found and acted on.
Decisions you make:
Read more: