Portfolio – Selected Work (EN)

Portfolio – Selected Work

🎯 At a glance

• Focus: Examples of connector work in MedTech and healthcare that centre on structure, documentation, and processes.

• Scope: Anonymised cases showing how I make technical content, workflows, and research overviews clearer and more usable.

• What this is not: A complete project list or client reference catalogue – it highlights ways of working, not names.

How to read this portfolio

1. Context – What kind of environment and problem are we dealing with?

2. My role – Where did I contribute, and what was explicitly not my responsibility?

3. What I did – Concrete structural / documentation / process work.

4. Result – What became clearer, easier, or more robust for the team?

Example 1 – Structuring a technical description for mixed audiences

• implementation details,

• regulatory‑relevant statements,

• and internal design notes.

• Split the existing document into a core description and two separate annexes (implementation‑focused notes and internal design rationale).

• Introduced a clear, repeatable outline: overview, intended use, system components, information flows, safety‑relevant aspects.

• Marked sections that are particularly relevant for regulatory and risk documentation, so RA/QA could reference them more easily.

• Simplified wording in key sections so they are understandable beyond the core development team.

• One central technical description usable by both engineering and RA/QA.

• Easier reuse in related documents (e.g. risk analysis input, internal training material).

• Less friction in discussions, because structure and terminology are now shared.

• Review discussions became more focused on substance, less on "where is what" in the document.

Example 2 – Mapping a documentation process from idea to approved document

• how a new document type is initiated,

• who must review and approve it,

• and how changes should be handled over time.

• Conducted short, structured conversations with key stakeholders (development, QA/RA, management) to collect their current view of the process.

• Created a simple process map from “idea / need for a document” to “approved, stored, and communicated document”.

• Clarified RACI‑style roles (who initiates, who drafts, who reviews, who approves, who needs to be informed).

• Documented decision points and escalation paths in a way that can be embedded into existing quality documentation.

• A shared, visual process description that can be used in onboarding and internal discussions.

• Clearer expectations about who needs to be involved at which step.

• A practical basis for future QMS work, without pretending that a full QMS redesign has already happened.

• The process description could be referenced directly in audit preparation instead of being rebuilt each time.

Example 3 – Targeted research summary for a new MedTech topic

• Identified and collected relevant standards, guidance documents, and position papers.

• Prepared a short, referenced overview document with:
• key messages per source,
• a simple comparison table,
• and notes on where different sources focus (risk, process, documentation, roles).

• Suggested where this information might impact existing internal processes (e.g. documentation, risk thinking, handover between roles).

• The team had a clear starting point for discussion with their own RA/QA experts and external advisors.

• Less time spent on “finding the right PDFs”, more time on deciding how to respond.

• A documented base they can later extend or revise as the regulatory landscape evolves.

• Follow‑up work with external advisors could build on one common, referenced overview instead of separate, ad‑hoc notes.

Internal portfolio database