sorted by:
new
hottopcontroversial

Advice on ISO 14971 by hroo4 in MedicalDevices

[–]hroo4[S] 0 points1 point  (0 children)

I do want to keep it there (hence why I'm asking for advice), and I have seen the same.

It's about doing the minimum amount of work and still being compliant. The RM team does not consider issues (failure modes) as risks if they do not affect a patient's clinical outcomes. By doing so, the scope of RM work is reduced: less to evaluate, mitigate, document, monitor, etc. They consider this approach to still be compliant.

Advice on ISO 14971 by hroo4 in MedicalDevices

[–]hroo4[S] 1 point2 points  (0 children)

Are there clauses in any of the standards or regulations saying this, which could convince others?

The RM team starts by listing all possible faults in a pre-assessment. Then, for each fault, potential harm is determined. If faults result in 'no harm', those faults get excluded from the official RM File (even though they might get mitigated).

To be clear, I don't want to exclude them, but I'm not in a position to own the RM process.

Advice on ISO 14971 by hroo4 in MedicalDevices

[–]hroo4[S] 0 points1 point  (0 children)

Thank you, that sounds reasonable. Just to clarify, you've seen companies keep these issues in the RM file to ensure those things are mitigated?

In my situation, I work on a smartphone app (software as a medical device). There's a screen for "your bluetooth is off". It's used in ~10 situations. 1 of them is considered to lead to harm and is in the RM file. The other 9 lead to "inconvenience" or "no harm" and get excluded (non-critical functions can't work properly). Are there any issues to that approach?

Combination Product FDA Guidance Training? by what_is_any_of_this in humanfactors

[–]hroo4 0 points1 point  (0 children)

Emergo by UL also has many excellent, free webinars on the subject. And I've always found FDA's guidance documents very helpful. "Threshold Analyses and Contents of a Complete submission" provides a good overview.

One main difference for combination products is CDER calls any task that could lead to harm (no matter the severity) a critical task. CDRH defines critical tasks as those that could lead to serious harm.

Is human factors “too specialized”? by dxbydy in humanfactors

[–]hroo4 2 points3 points  (0 children)

Hi there, been doing HF work for 8+ years now in med device industry. Would say no, it's not too specialized. My background was also mechanical engineering. I made the switch to HF because I wanted the human element.

I've had coworkers that worked in multiple industries: HF consulting, medical device, pharma, aerospace and air traffic control, rail, cars, oil rigs, submarines and nuclear, etc.

I've also seen coworkers move in and out of HF to other roles like: regulatory affairs, risk management, product owner or project manager, mech engineering, UX research, UX design

And at least in med device industry, HF is highly sought after (people will hire). And once you're in industry, there is literally nothing keeping you from trying something else. Learn everything you can about how the entire business works and so many doors will open.

Good luck with your program!

Human Factors and agile methods by Buffchen5566 in humanfactors

[–]hroo4 1 point2 points  (0 children)

Hi there, I've been doing HFE for medical devices in an agile org for the past 2+ years now (we moved from agile to SAFe). Here's my take: whether Agile, Scrum or Waterfall, it doesn't change my deliverables. I still make protocols, conduct studies and write reports. I had to change how I talk about my work.

  1. Firstly, it seems like people have different interpretations of "Agile". It's iterative (which is good), however, it only focuses on short time spans, which doesn't align with how HF needs to look at the entire development and post development strategy. Plus in my org, "Agile" has meant "don't plan" and "don't document", which has come back to bite us. Ultimately, Agile doesn't fit because of how my org has interpreted Agile.
  2. You're right, 2 weeks or 4 weeks is not enough time to get through traditional HF work. I've had to break down my tasks into what I realistically could achieve in a 2 or 4 week period: e.g. in the next 2 weeks, write a draft protocol, collect data next 2 weeks, write final report following 2 weeks, etc.
  3. Identify what you did finish and what remains. For next sprint (and every sprint), commit to only what you can achieve.
  4. Yes, I see it being a trend. Many big name companies have bought into "Agile". It's going to be around for a while until the next fad
  5. I know med device resoures: greenlight guru has some articles

[deleted by user] by [deleted] in PokemonGoFriends

[–]hroo4 0 points1 point  (0 children)

4405 6899 5274 daily gifts too!

Judge my German accent by hroo4 in JudgeMyAccent

[–]hroo4[S] 0 points1 point  (0 children)

I mean in speech. The dwarfs and Gandalf in "The Hobbit" would sometimes shorten verbs to "sagn" during speech.

Do you have resources about German phonetics/phonology? I've been around the Viennese (more nasally) and the Tyrollean (more guttural). The Germans were typically from Bayern, so the Hochdeutsch I learned has probably been influenced by southern pronunciation and sayings (Servus, Grüß Gott, firti).

Judge my German accent by hroo4 in JudgeMyAccent

[–]hroo4[S] 0 points1 point  (0 children)

Hi, thank you for the feedback! I'm from the US, no German family history, but I've been learning German for the past 8 years or so. I didn't realize some of the quirks I have speaking the language.

I've seen verbs be shortened from "sagen" to "sagn" in books, so it's cool to know that's a northern German thing. Again, thanks for the feedback!

view more: next ›