Medtech Operating System
Accelerating Medtech
MOS is a set of open source AI skills for medical device development. The key is context. MOS works from your company's own files — your technology, clinical scope, regulatory parameters, and commercial goals inform the AI tasks and make the output accurate and relevant.
The files your company already has — intended use, user needs, risk file, design inputs. MOS calls this your context, and it is what makes the work specific to your device.
Each skill is a package you download: written instructions and the templates it fills, with shared scripts for the steps that must be exact. Versioned and replaceable.
An AI that can read and write files in a folder — Claude Code, or another coding agent your company approves. Point it at the folder and ask for a skill by name. It reads your context, asks about the gaps, and writes a draft back into your own files.
01
Nobody goes to school for medtech.
There is no degree that teaches you how to run design controls, scope a clinical study, choose a regulatory pathway, or price a device. People learn by doing it wrong first. Three things make that worse than it needs to be.
-
The knowledge is tribal
It lives in the heads of people who have done it before, and it leaves when they do.
-
Every company does it differently
A design review at one company looks nothing like a design review at the next, so experience transfers poorly.
-
Even the words differ
User needs, user requirements, product requirements and design inputs mean different things at different companies, which makes it hard to learn from anyone outside your own walls.
MOS exists to fix all three at once. One shared structure, one vocabulary, and a set of skills that carry what experienced people know into work you are doing right now — so the next person does not have to learn it by getting it wrong first.
02
How MOS works: context from your own data
The name is literal: your context is the file system, the lifecycle map is the process map, and the skills are the applications that run against both.
Most medtech resources are generic because they have to be — they know nothing about your device. So you get a risk table with example hazards for a catheter you are not building, and the real work starts after you have downloaded it.
So MOS runs on three parts instead. You already have the one that matters most.
-
01
You own it
Your intended use, user needs, risk file, design inputs — whatever your company has already written. This is what makes the work specific to your device.
-
02
You download it
A folder holding written instructions and the templates it fills, with shared scripts for the steps that must be exact. One job each, versioned and replaceable.
-
03
You set it up once
A coding agent — an AI that works in your files, not a browser chat window. Claude Code, or another your company approves. Skills are plain Markdown plus a few Python scripts; setup checks for Python and asks before installing it.
What you approve becomes what the next skill reads, so your context compounds as you work. The templates are the cheap part.
03
The whole lifecycle, not one slice
Seven phases across technical, clinical, regulatory and commercial work. Most existing resources cover a single slice — the gaps between slices are where projects actually fail. Select a phase to see what it covers.
Feasibility and technology options
Unmet need and standard of care
Preliminary classification and pathway
Market size and competitive landscape
Every phase side by side, plus what each discipline covers
Product requirements and architecture
Target population and endpoints
Intended use, indications for use, risk plan
Value proposition, pricing hypothesis, reimbursement path
Every phase side by side, plus what each discipline covers
Design inputs and outputs, design reviews
Early human factors and clinician input
Risk file, design controls, supplier controls
Cost of goods and business case
Every phase side by side, plus what each discipline covers
Verification testing, biocompatibility, software validation
Usability validation, pilot or pivotal study
Test plans and reports, traceability
Launch readiness and KOL engagement
Every phase side by side, plus what each discipline covers
Technical file assembly
Clinical evidence summary
510(k), De Novo, PMA, CE mark; submission strategy
Payer strategy and coding
Every phase side by side, plus what each discipline covers
Design transfer and manufacturing readiness
Training materials
Labeling, registration, QMS readiness
Sales model, pricing, distribution
Every phase side by side, plus what each discipline covers
Design changes and CAPA inputs
Post-market clinical follow-up
Complaints, vigilance, surveillance
Adoption, expansion, next indication
Every phase side by side, plus what each discipline covers
04
What exists today
Where each part of the system stands right now. Everything published is open to read and use; everything else is being built.
Charter Purpose, principles, governance, licensing
PublishedLifecycle map v0.1 skeleton — open for debate
DraftContext standard v0.3 — the eight domains, the folder layout, and where your data goes
DraftSkills Release 0.2.0: setup, user needs, differentiation, product code, precedent search, reimbursement and indications strategy. Each is a draft until three people have run it on real work
DraftEducation layer Classroom videos
In progressStart here
The 7-Day Challenge in the Medtech Mindset Classroom runs one skill a day, from setup to the versions of your indications side by side, each with its pathway, evidence, time and cost. Bring a real device or make one up.