Vendor track workspace
Regulatory Readiness Blueprint
Everything you have written in the vendor track, in one place. Sections fill in as you complete the modules that produce them.
A · Product boundary
- Are you describing the whole product or one specific function or module?
- —
- Product or function name, as the team actually calls it
- —
- Current version or release identifier
- —
- Is this function being added to a product already placed on the market?
- —
- Module dependencies
- —
- What other modules or shared functionality does it depend on, and what depends on it?
- —
- Which external devices or systems does it operate, configure, control, enable or assist?
- —
- Name of that device or system, if any
- —
- Is the linked device a medical device, an IVD, or unknown?
- —
B · Workflow and outputs
- Inputs — what information can enter in any supported configuration?
- —
- Processing — what does the software do to those inputs?
- —
- Processing, in your own words
- —
- Generated output — what new information does it derive?
- —
- Pass-through output — what does it only transmit or display unchanged?
- —
- Outputs, in your own words
- —
- Users — who directly receives or uses the output?
- —
- Subject — who or what is the output about?
- —
- Downstream action — what is someone expected to do because of the output?
- —
- Patient-specific routes — how can individual patient information reach or leave the product?
- —
- Healthcare or health context
- —
- Human review before anything happens
- —
- How far the software can act by itself
- —
- Potential consequence of a wrong output
- —
- Time-critical or emergency use?
- —
C · Claims inventory
- Formal intended-purpose wording, if one exists
- —
- Website or marketing wording
- —
- Sales or procurement wording
- —
- Demo screenshots or example outputs that imply a use
- —
- Restrictive disclaimers used
- —
- Exact disclaimer wording
- —
- Any claimed technical control — what mechanism actually enforces it?
- —
- Can someone outside the team verify that mechanism?
- —
D · Draft intended purpose
- Saved statement
- No intended-purpose version saved yet (Module 2).
E · Qualification assessment
- Qualification assessment
- Complete Module 2 to record this section.
Signals and questions are inputs to a professional qualification review. They are not a determination of device status or of which framework applies.
F · Preliminary classification position
- Classification position
- Complete Module 3 to record this section.
The class hypothesis is entered by the learner and is preliminary. It requires confirmation by a competent regulatory reviewer.
G · Conformity strategy
- Product or function, version and supported configurations in scope
- Complete Module 4 to record this section.
The route and notified-body entries are learner hypotheses for discussion. Nothing here states which conformity assessment route applies or whether a notified body is required.
H · Clinical evidence plan
- Product or function and the intended-purpose wording this plan is written against
- Complete Module 5 to record this section.
Gaps and actions are the learner's own. Nothing here states that the evidence is sufficient or that a clinical investigation is or is not required.
I · EU AI Act overlay
- AI system or AI component, version and what it does
- Complete Module 6 to record this section.
Role, route and high-risk entries are learner hypotheses. Nothing here determines AI Act high-risk status or the obligations that follow from it.
J · QMS and lifecycle plan
- Lifecycle owners — who owns which decision, and what record proves it
- Complete Module 7 to record this section.
Status entries are the learner's own view of each section. They are never scored, summed or converted into a readiness percentage.
Handoff for professional review
Confirm the qualification premise and, if it is a device, the applicable framework.
Confirm or correct the preliminary classification position and its rationale.
Confirm the applicable conformity assessment route and any notified-body involvement.
Review the claims inventory against the evidence plan and say which claims are not yet supportable.
Confirm the AI Act actor role and whether any high-risk route applies to this system.
Review the QMS and lifecycle plan against what the organisation can actually operate.
Free product text stays in this browser. Nothing in this Blueprint is a compliance score or a CE-readiness score, and no section states device status, framework applicability, a confirmed class, a conformity route, notified-body necessity or AI Act high-risk status.
Sections are written in the course. Open the vendor track