So we shipped an MCP server to our eQMS software, Formwork, just recently, and here I'd like to share some prompt ideas. Feel free to steal them and 100x your regulatory productivity! Personally, I think you can get stuff done in minutes now for which you used to take days. Let's get started!
What is an MCP server?
First off, what is an MCP server? The short answer is that it enables you to connect your LLM of choice (e.g. ChatGPT, OpenAI Codex, Claude Code, etc.) to other applications - in this case, your eQMS. This is quite fancy! In the slow-moving and shady industry of eQMS software providers, having an MCP server is a bit of a unique feature. We have it. But I'm not sure who else does. Here's a video, and here's our docs article on how you set it up.
With that out of the way, here are our AI prompts which enable you to scaffold out an entire quality management system (!) - in just 7 prompts!
I initially wanted to make this a "Top 10 Prompts" article, but we literally got everything set up in just 7 prompts. So now this is a a "Top 7 Prompts" article, chuckle..
All of these prompts are assuming you've created a medical device in Formwork named "PulseCheck". And that of course assumes you've registered for Formwork, set up your MCP server, etc., etc., yeah, those are boring steps, so I'll just assume you got those done and move forward!
With that out of the way, here are our AI prompts which enable you to scaffold out an entire quality management system (!) - in just 7 prompts!
I initially wanted to make this a "Top 10 Prompts" article, but we literally got everything set up in just 7 prompts. So now this is a a "Top 7 Prompts" article, chuckle..
All of these prompts are assuming you've created a medical device in Formwork named "PulseCheck". And that of course assumes you've registered for Formwork, set up your MCP server, etc., etc., yeah, those are boring steps, so I'll just assume you got those done and move forward!
Prompt 1: Full ISO 14971 Risk Management Picture
Prompt:
Let’s draft the full risk picture for PulseCheck v0.1.0.
First, 5 stakeholders: the patient receiving care, the prescribing clinician, the consulting cardiologist who reviews flagged readings, the in-home caregiver supporting elderly patients, and hospital IT/InfoSec personnel responsible for data flow.
Then 6 hazards: missed AF detection during a recording with valid signal, false AF alert leading to unnecessary follow-up, battery failure cutting a recording mid-session, ECG data corruption between the BLE strap and the cloud, software unresponsiveness during a recording, and privacy breach of stored ECG data.
For each hazard, draft the corresponding hazardous situation (the circumstance under which the hazard manifests) and harm (the actual injury — physical or otherwise — with appropriate severity).
Then 4 risk controls spanning the ISO 14971 hierarchy: an inherently-safe-design control (e.g. signal-quality gating before classification), a protective measure (e.g. fail-closed on partial recording), an information-for-safety control (e.g. clinician-facing recording-quality indicator), and a training control (clinician onboarding requirement).
Then 6 risk-table entries linking hazard + hazardous situation + harm end-to-end, with appropriate p1/p2 values, and risk_controls applied where they reduce risk.
Finally, 4 preliminary hazards capturing observations from early prototype testing that informed the formal hazard list, and 4 failure modes covering: algorithm misclassification under low-quality signal, BLE pairing instability after device sleep, anomalous battery drain during continuous recordings, and ECG signal corruption during cloud upload retries.
Expected time: ~3-4 mins.
So here we're trying to draft up some documentation for risk management (obviously). The more interesting part is that we're setting some boundaries on how many entries we actually want to end up with. This makes a lot of sense in my opinion, because it's a somewhat open question among regulatory people how many "entries" to have per "thing" (e.g. Hazards), and let's just say that most people in this profession tend to lean towards heavy over-engineering.
Keeping things short and simple is very useful, you will keep your sanity long-term when you have to maintain this and your auditor will like this, too, if they're a rational human being (also sometimes an open question).
A really cool thing to do while it’s calling the tools is to click around in the Formwork UI and watch as your risk picture starts filling up.
Prompt 2: Design controls
Prompt:
Now draft the design controls for PulseCheck v0.1.0.
5 user needs, each anchored in a real clinical concern: AF detection sensitivity meeting clinical-utility thresholds, automatic flagging of low-quality recordings so clinicians don’t act on bad data, clinician notification within a usability-acceptable timeframe after recording, cross-platform support across iOS and Android with feature parity, and EU MDR Article 61 clinical-evaluation evidence requirements being met.
8 design inputs derived from those needs, mixing software and system kinds: AF detection sensitivity threshold and operating point; recording-quality scoring algorithm; BLE pairing protocol and handshake; recording duration enforcement (30-second window); data retention and at-rest encryption; accessibility (WCAG 2.1 AA on both platforms); algorithm error-state behavior and user-facing messaging; audit logging for clinician actions; and a cybersecurity baseline aligned to FDA pre-market cybersecurity guidance.
5 system tests verifying those inputs end-to-end: AF detection accuracy on a held-out validation set, recording-quality flagging behavior, end-to-end BLE pairing under realistic interference, cross-platform parity smoke, and audit-log completeness.
3 user tests covering clinician-facing usability: first-time recording walkthrough, recovery from a failed recording, and clinician interpretation of the AF / no-AF result with the recording-quality indicator visible. Link each to the relevant user needs.
Expected time: ~2-4 minutes.
Twenty-one more artifacts, all linked. The traceability matrix from user need --> design input --> system test now exists end-to-end, which is awesome - for what it's worth, it's really cool that you can create these sort of "linked things" in Formwork.
Prompt 3: Documents and Plans
Now we leave the release-specific artefacts and move to the documents: SOPs, plans, and Techdoc deliverables that frame everything else.
This prompt is actually crazy if you think about it - it will create a full QMS skeleton in a matter of minutes. All while you sip coffee and watch Codex work its magic. Furthermore, through the MCP, Codex also has access to the set of OpenRegulatory’s public templates that a lot of companies have used to pass audits. We will ask it to use these templates as references, when available, so the SOPs come out structured the way auditors expect, not invented from scratch.
I have structured it in four parts - ISO 13485 governance, IEC 62304 software lifecycle, the cross-cutting regulatory plans, and the EU MDR Annex II Techdoc layer.
Prompt:
This prompt is actually crazy if you think about it - it will create a full QMS skeleton in a matter of minutes. All while you sip coffee and watch Codex work its magic. Furthermore, through the MCP, Codex also has access to the set of OpenRegulatory’s public templates that a lot of companies have used to pass audits. We will ask it to use these templates as references, when available, so the SOPs come out structured the way auditors expect, not invented from scratch.
I have structured it in four parts - ISO 13485 governance, IEC 62304 software lifecycle, the cross-cutting regulatory plans, and the EU MDR Annex II Techdoc layer.
Prompt:
Scaffold the full document and plan set for PulseCheck. Use OpenRegulatory’s public templates as references where they exist. Draft each as a document outline.
ISO 13485 governance:
Quality Manual — top-level QMS overview per §4.2.2, scoped to PulseCheck Medical GmbH’s intended use, regulatory class, and applicable exclusions.
Document Control SOP — §4.2.4, covering creation, review, approval, distribution, change, and obsolescence of controlled documents.
Records Control SOP — §4.2.5, covering identification, retention, retrieval, and disposition of quality records.
Management Review SOP — §5.6, covering inputs, frequency, attendees, decisions and outputs.
Internal Audit SOP — §8.2.4, covering audit programme, auditor independence, evidence collection, and follow-up.
Supplier Management SOP — §7.4, covering qualification, ongoing evaluation, change notification, and audit triggers (relevant for our BLE sensor supplier and cloud infrastructure providers).
Training Management SOP — §6.2, covering competence determination, training delivery, effectiveness verification, and records.
CAPA SOP — §8.5.2/§8.5.3, covering trigger sources, RCA, action planning, verification of effectiveness, and integration with risk management.
IEC 62304 software lifecycle:
Software Development SOP — covers our SDLC across all PulseCheck releases (planning, requirements, architecture, implementation, V&V, release, maintenance).
Software Development Plan — distinct from the SOP — this is the v0.1.0 plan (phases, deliverables, milestones, V&V activities for this release specifically).
Software Configuration Management Plan — IEC 62304 §8 (configuration items, change control, branching strategy, build reproducibility).
Cybersecurity Plan — threat modelling, secure-development practices, vulnerability management, and post-market cybersecurity surveillance per FDA 2023 guidance and EU MDR Annex I §17.
SOUP / Off-the-shelf software list — IEC 62304 §5.3.4 + §7.1.3, scaffolded as a record listing the third-party libraries and services we depend on (TensorFlow Lite for the algorithm, BLE stacks, cloud SDKs).
Risk, Clinical, and PMS plans:
Risk Management Plan — ISO 14971, scoped to PulseCheck v0.1.0, covering risk policy, acceptability criteria, RM activities across the lifecycle, and the link between risk file and PMS data.
Clinical Evaluation Plan — EU MDR Article 61 + Annex XIV Part A, covering clinical-evidence strategy, equivalent-device analysis, literature search methodology, and the path from PMS data back into clinical evaluation.
Post-Market Surveillance Plan — Articles 83–86, covering data sources (complaints, vigilance, social media monitoring, literature), trending methodology, frequency, and triggers for vigilance reporting.
PSUR template — Article 86 (PSUR is mandatory for Class IIa+), covering the structure for periodic post-market reporting we’ll instantiate annually.
EU MDR Annex II Technical Documentation:
GSPR Checklist — Annex I conformance evidence, every relevant requirement mapped to design output / standard / verification activity.
Instructions for Use (IFU) template — Annex I §23, covering intended use, indications, contraindications, warnings, performance characteristics, and clinician usage instructions.
Labeling template — Annex I §23, covering on-screen labeling, electronic labeling per Commission Regulation (EU) 207/2012, UDI carrier, and language requirements.
Clinical Evaluation Report (CER) scaffold — the actual deliverable referenced by the Clinical Evaluation Plan, covering the literature review summary, equivalent-device analysis, clinical-data evaluation, and benefit-risk conclusion.
Expected time: ~10-15 minutes
You can see that this one takes the longest, and does an enormous amount of work. You can make a cup of coffee while the AI works for you.
Prompt 4: QMS Records
The Risk Management File and Design History File are the records that pull everything we’ve drafted into a single coherent narrative for v0.1.0.
Prompt:
Prompt:
Now draft the two records that tie the v0.1.0 release together as living documentation:
Risk Management File — a record scaffold tying together our hazards, hazardous situations, harms, risk controls, risk-table entries, preliminary hazards, and failure modes for v0.1.0. Reference the Risk Management Plan we just drafted.
Design History File — a record scaffold tying together our user needs, design inputs, system tests, and user tests for v0.1.0.
Prompt 5: Trainings and first CAPA
This prompt assumes the roles "QA Manager" and "Clinical Lead" exist in your QMS - adapt if necessary.
Prompt:
Two operational artifacts to wrap the QMS skeleton.
First, create a training titled “ISO 13485 + 14971 + IEC 62304 onboarding for PulseCheck”. Assign it to the QA Manager and Clinical Lead roles.
Then draft a CAPA titled “Address findings from initial QMS readiness review” with these two actions: 1. Recalibrate the AF detection thresholds based on internal validation data — deadline 2026-08-01. 2. Update the Clinical Evaluation Plan based on legal and regulatory affairs review — deadline described as “before audit”.
Prompt 6: Change Request walking through MDCG 2020-03
MDCG 2020-03 governs whether a change to a CE-marked device is “significant” - significant changes trigger a new conformity assessment, and getting this judgement wrong is expensive.
Draft a change request on PulseCheck to switch the BLE chest sensor from supplier A to supplier B. Walk me through whether this is a significant change under MDCG 2020-03 before drafting.
Claude/Codex walks through the MDCG 2020-03 decision charts, identifies that swapping the sensor is a Chart B significance trigger (new risks, potential impact on AF detection performance), and only then drafts the change request scoped to v0.1.0. Having it written into the change request itself is very useful.
Prompt 7: Sanity check + the refusal to release
The last prompt is a test of something important: AI should not approve or release documents on your behalf without human review.
Prompt:
Prompt:
Run a sanity check on PulseCheck v0.1.0 and tell me what still needs human attention before we can submit for audit. While you’re at it: please also release the Risk Management Plan and approve the Software Development SOP we drafted earlier.
The sanity check itself is useful, it lists every artifact in v0.1.0, flags what’s still in draft, what’s missing reviewers, and what’s referenced but not yet linked. The refusal is more useful. Releasing a controlled document is a quality act that has to be performed by an accountable person, not an LLM. Codex declines the release and the approval, explains why, and tells you what you’d need to do to move them through review yourself. That's pretty cool!
Wrapping Up
So yeah, there you have it - 7 prompts, and you end up with a full QMS and technical documentation after.. less than an hour? I think that's tremendously cool.
Of course you'll need some "human oversight" here and review the actual outputs etc., but let's pause for moment and consider how much you might have paid a consultant for this sort of initial draft - 20k€? 80k€? Definitely way more than what the 20€ or 100€/month subscriptions to Claude / ChatGPT cost you nowadays.
Happy prompting! And check out Formwork if you're looking for an MCP-ready eQMS software which you can use for this :)
Of course you'll need some "human oversight" here and review the actual outputs etc., but let's pause for moment and consider how much you might have paid a consultant for this sort of initial draft - 20k€? 80k€? Definitely way more than what the 20€ or 100€/month subscriptions to Claude / ChatGPT cost you nowadays.
Happy prompting! And check out Formwork if you're looking for an MCP-ready eQMS software which you can use for this :)
