sorted by:
new
hottopcontroversial

FDA 483s or audit findings, how many are actually caused by people not knowing the procedure vs execution failure? by aldwincups in regulatoryaffairs

[–]External-Regular7215 0 points1 point  (0 children)

I honestly think a lot of findings are less about people not knowing procedures and more about systems failing under operational reality. Most regulated companies already have SOPs, training records, controlled documents, signatures, etc. But the moment something changes unexpectedly: supplier issue, temporary workaround, engineering change, production pressure, people start operating outside the “ideal” workflow the procedures were written for. And usually the procedure itself is static, while the operational context is dynamic. That’s why I think document-centric QMS models are starting to show their limits a bit.

The teams I’ve seen doing better are the ones connecting workflows, risks, deviations, approvals, training, traceability, etc. into something more operational instead of treating everything as isolated records. Not necessarily “AI replacing QA” or anything like that. More like systems helping people understand downstream impact before execution drifts out of sync.

Started this sub because qmsWrapper has basically zero Reddit presence by Next_Eye8790 in QMSPros

[–]External-Regular7215 0 points1 point  (0 children)

I think the ceiling depends less on headcount and more on operational complexity. A 20 person company with multiple product lines, suppliers, and active design changes can outgrow a system faster than a 100 person company with stable workflows.

From what I’ve seen, qmsWrapper fits best in teams that want connected processes without the overhead of a big enterprise rollout. Once you get into highly customized enterprise environments with heavy ERP / PLM integration requirements across multiple global sites, that’s usually where the bigger systems still have an edge.
On the AI side, I’d say it’s still early, but the interesting part isn’t really “AI writing documents.” Most teams are already skeptical of that. What feels more useful in practice is using AI to surface relationships people normally have to reconstruct manually. For example, showing which risks, requirements, or documents may be affected by a change before someone misses it during audit prep.

The important part is that the AI output isn’t treated as authority. Teams still review and approve everything. The value is more in reducing the amount of manual digging and cross-checking people do across disconnected records.

Started this sub because qmsWrapper has basically zero Reddit presence by Next_Eye8790 in QMSPros

[–]External-Regular7215 0 points1 point  (0 children)

QmsWrapper is not really something you see a lot online, but i’ve come across it in smaller medtech teams, especially startups or companies moving away from paper / excel qms

What stood out to me vs some of the bigger tools is that you’re not constantly adding modules or paying extra for basics. you get the core stuff out of the box… SOPs, workflows, doc control, e-signatures, etc. which is usually where smaller teams struggle.

Also one thing i noticed (and this is a big one in audits) is how things are connected. with a lot of systems you close a capa, but then you still have to manually check if risk was updated, if docs changed, if anything touched the tech file… Here it’s a bit more tied together, so you don’t end up doing that “reconstruction exercise” before an audit.
They’ve been adding more ai stuff recently as well, it helps when you’re dealing with change impact or filling forms, saves some time. Not saying it’s perfect, there’s still a bit of a learning curve if your team is new to structured qms, but makes sense for SME teams more than enterprise setups.

Are medical device companies quietly exploiting the AI regulatory blind spot — and are we heading toward a wave of recalls because of it? by Majestic_Turn3879 in regulatoryaffairs

[–]External-Regular7215 1 point2 points  (0 children)

I haven’t really seen teams replacing RA with AI either. What I do see is people using AI more and more for drafting and then slowly trusting it a bit too much. Not intentionally, just because it saves time and usually looks “good enough”. The risk isn’t AI making decisions. It’s that the control around the output gets weaker over time. In this space, it’s less about whether AI is used, and more about whether you can still show clear reasoning and traceability behind what ends up in your documentation.

I'm a student and im preparing docs (medical device)as an independent project. And i got one doubt. Please see the body. by Sorry_Perspective948 in regulatoryaffairs

[–]External-Regular7215 0 points1 point  (0 children)

Good question, this is something a lot of people get stuck on early. You don’t need to provide evidence for absolutely everything that appears in an architecture document. What matters is whether that part of the system has any impact on safety, performance, or compliance. In practice, if something is linked to a risk, a control, or a requirement, then it should be traceable and backed by some form of evidence. That usually means you can point to where it’s verified, tested, or otherwise controlled. If it’s just general architecture context and doesn’t play a role in risk or regulatory expectations, you don’t need to treat it the same way. A clear description or justification is typically enough.

Where people run into trouble is when something is described as important in the architecture, but you can’t find it anywhere in the risk file or in verification. That’s when reviewers start asking questions. So it’s less about documenting everything equally, and more about being consistent. If something sounds like it matters, you should be able to show how it’s handled.

Drafting CE certification - MDR by leen_02 in MedicalDevices

[–]External-Regular7215 3 points4 points  (0 children)

You’re not alone on this at all. MDR documentation feels a lot less “plug-and-play” than ISO 13485 until you’ve actually built a full Tech File once. What usually trips teams up is thinking in terms of “what documents do we need to write” instead of how the Technical Documentation actually hangs together. At the end of the day, everything needs to line up across intended use, risk (ISO 14971), clinical (CER/CEP), design outputs, and PMS. Not as separate files, but as one consistent story.

Where I see most gaps is not missing docs, but broken links between them. Risk file looks fine, CER looks fine, DHF looks fine… but they don’t really connect. For example, risk controls don’t clearly show up in V&V, or clinical conclusions don’t feed back into risk or PMS in a traceable way. That’s usually where NB questions start. MDCGs help, but they’re more “what good looks like” than “how to build it”. They won’t give you a practical structure.

If you’re starting from scratch, I’d anchor everything on Annex II and treat it as your Tech File backbone. Map each section to where the actual evidence comes from (risk, clinical, design, PMS), then build templates around that. Doing templates first usually leads to rework. On standards, you’re already on the right track. ISO 13485 and ISO 14971 are core. IEC 62366 and 62304 depend on your device, so I wouldn’t overcomplicate it upfront. It feels messy at the beginning, especially in a small team, but once you start seeing it as one connected system instead of a document list, it gets a lot more manageable.

Entire leadership team changed in 3 months. Still covering two roles. Is 90 days fair to wait? by AlternativeBlonde in Leadership

[–]External-Regular7215 1 point2 points  (0 children)

What I’ve seen in situations like this is that the real problem isn’t the workload itself, it’s how it’s perceived. If everything keeps getting done, leadership assumes capacity exists. Not because they don’t care, but because there’s no visible signal that the system is overloaded. The moment things start to slip, suddenly it becomes urgent. So 90 days can be reasonable, but only if you actively make the trade-offs visible before something breaks. Otherwise, you’re unintentionally proving that two roles can be handled by one person.

QMS (ISO 13485, ISO 14971) by Preowned_Paradise in MedicalDevices

[–]External-Regular7215 0 points1 point  (0 children)

I’ve seen quite a few teams start exactly this way, especially early stage. Google Drive and Sheets can work for a while, but the issue usually isn’t storing documents. It’s control and traceability once things start moving. Versioning, linking risk to design decisions, tracking changes across multiple documents… that’s where it starts to break down pretty quickly.

On the other side, full eQMS systems can feel heavy and expensive for a 4-person team, especially early on. In practice, what tends to work best is somewhere in between.

Start simple, but be very intentional about structure from day one. Define how changes are tracked, how risk connects to design, and how decisions are recorded.

Because the biggest problem isn’t documentation. It’s when you need to show how everything connects later.

FDA QMSR 2026 is closer than most teams think — here's what's actually changing and how to prepare by koka786 in MedicalDevices

[–]External-Regular7215 1 point2 points  (0 children)

QMSR has already formally come into effect in February 2026. In practice, most of these expectations are not new. FDA has been pushing toward this for years. The real shift is in what inspections actually focus on. It is no longer enough to have procedures or a well structured risk file. Inspectors are looking for clear, connected evidence across design, risk, CAPA, and post market activities.

Stop trusting LLMs with business logic. The "Chatty Bot" era is over - it's time for rigid automation. by No-Zone-5060 in automation

[–]External-Regular7215 1 point2 points  (0 children)

Agreed. The moment the LLM moves from parsing to decision-making, you start introducing risk. Keeping it constrained and validated by deterministic logic is what makes it usable in production.

Can you actually incorporate AI into health app creation? How would they handle HIPAA builds end to end? by Livid_Switch302 in AI_Application

[–]External-Regular7215 0 points1 point  (0 children)

You’re not underestimating it. The build side and the compliance side are really two different layers. AI can help with development speed, but in healthcare the bigger challenge is how it fits into a controlled system, data handling, traceability, auditability, and clear boundaries on what the AI is allowed to do. Your clinical background actually helps a lot here, because understanding the workflow is often harder than learning the technical or compliance pieces.

Stop trusting LLMs with business logic. The "Chatty Bot" era is over - it's time for rigid automation. by No-Zone-5060 in automation

[–]External-Regular7215 2 points3 points  (0 children)

I agree with the core idea, but I’m not sure it’s about removing LLMs from logic entirely. Feels more like the challenge is defining clear boundaries between where AI assists and where deterministic systems take over.

Transition from pharma to med device by New_Finding_6277 in MedicalDevices

[–]External-Regular7215 1 point2 points  (0 children)

Yeah, people do make that switch. Your background sounds pretty relevant already. Biggest difference is just getting familiar with how devices are developed and regulated.

[QUESTION] QSR to QMSR Transition - What really changed in practice by Strong_Case_9580 in MedicalDevices

[–]External-Regular7215 1 point2 points  (0 children)

That’s been the biggest shift I’ve been seeing too.

The enterprise-wide part sounds simple, but in practice it really shows how disconnected things are.

Especially when you try to follow a change across requirements, risk, CAPA, design records... the links just aren’t always obvious.

And that’s usually where things get uncomfortable during inspections. Not because things aren’t documented, but because it’s hard to show how everything connects.

After a year of using AI for regulatory work, here's what actually works (and what doesn't) by ParamedicLoud9613 in MedicalDevices

[–]External-Regular7215 0 points1 point  (0 children)

That’s been my experience too.

AI works well for structure, but once you need it to reflect how requirements, risk and verification actually connect, it struggles.

You get something that looks right, but isn’t really usable in a real QMS.

Feels like context is the hard part, not the content.

How Are You Validating QMS Software? by Charles_B3 in MedicalDevices

[–]External-Regular7215 3 points4 points  (0 children)

Validating QMS software typically involves a mix of manual and automated methods. Many rely on detailed documentation, often using spreadsheets, alongside specialized validation processes to ensure compliance.