Portfolio – Udvalgte arbejder
🎯 Kort overblik
- Fokus: Eksempler på connector‑arbejde inden for MedTech og sundhedsvæsen med fokus på struktur, dokumentation og processer.
- Omfang: Anonymiserede cases, der viser, hvordan jeg gør teknisk indhold, arbejdsgange og research‑overblik klarere og mere anvendelige.
- Hvad dette ikke er: Ikke en komplet projektliste eller kundereferencer – det handler om arbejdsmåder, ikke navne.
Denne side giver et kort, webvenligt overblik over udvalgte opgaver som connector og teknisk skribent inden for MedTech og sundhedsvæsenet. Eksemplerne bygger på et internt portfolio‑workspace, hvor jeg vedligeholder mere detaljerede noter, versioner og refleksioner.
Fokus er på struktur og anvendelsesscenarie, ikke på at nævne konkrete organisationer.
Language / Sprache / Sprog
English – Portfolio – Selected Work · Deutsch – Portfolio – Ausgewählte Arbeiten · Dansk (aktuel)
Sådan er portfoliet opbygget
Hvert eksempel beskrives ud fra fire spørgsmål:
- Kontekst – Hvilket miljø og hvilken type problem arbejder vi med?
- Min rolle – Hvor bidrager jeg, og hvor ligger ansvaret ikke hos mig?
- Hvad jeg gjorde – Konkrete struktur‑, dokumentations‑ eller procesopgaver.
- Resultat – Hvad blev klarere, lettere eller mere robust for teamet?
Mere detaljerede arbejdsversioner (inkl. udkast, alternative strukturer og læringsnoter) ligger i en intern portfolio‑database.
Eksempel 1 – Strukturering af en teknisk beskrivelse til blandede målgrupper
Kontekst
Et lille MedTech‑team havde en teknisk beskrivelse af et device og tilhørende software, som var "vokset frem over tid". Teksten blandede:
- implementeringsdetaljer,
- regulatorisk relevante udsagn,
- og interne designnoter.
Dokumentet var svært at bruge som fælles reference på tværs af udvikling, QA/RA og ledelse.
Min rolle
Støtte til struktur, klarhed og opdeling efter målgrupper, ikke klinisk eller regulatorisk godkendelse. Ansvar for den endelige faglige korrekthed lå hos interne RA/QA‑roller.
Hvad jeg gjorde
- Delte det eksisterende dokument op i en kernebeskrivelse og to bilag (implementeringsnære noter og intern design‑rationalitet).
- Indførte en tydelig, gentagelig disposition: overblik, anvendelsesformål, systemkomponenter, informationsflows, sikkerhedsrelevante aspekter.
- Markerede afsnit med særlig relevans for risiko‑ og regulatorisk dokumentation, så RA/QA lettere kunne referere til dem.
- Forenklede centrale formuleringer, så de også kunne forstås uden for kerneudviklingsteamet.
Resultat
- Én central teknisk beskrivelse, der kan bruges af både udvikling og RA/QA.
- Lettere genbrug i relaterede dokumenter (fx input til risikovurdering, intern træning).
- Mindre friktion i diskussioner, fordi struktur og terminologi nu er fælles.
- Review‑møder kunne i højere grad fokusere på indhold og beslutninger frem for at lede efter information i dokumentet.
Eksempel 2 – Kortlægning af en dokumentationsproces fra idé til godkendt dokument
Kontekst
I en organisation med flere kvalitetskritiske dokumenter fandtes der ikke et fælles billede af,
- hvordan en ny dokumenttype initieres,
- hvem der skal reviewe og godkende,
- og hvordan ændringer skal håndteres over tid.
Det gav forsinkelser og uklarhed – især i grænsefladerne mellem udvikling, kvalitet og ledelse.
Min rolle
Connector og strukturperson: ingen myndighed over selve QMS‑systemet, men ansvar for at gøre flows og roller synlige.
Hvad jeg gjorde
- Førte korte, strukturerede samtaler med nøglepersoner (udvikling, QA/RA, ledelse) for at samle deres syn på processen.
- Udarbejdede et enkelt proceskort fra "behov for et dokument" til "godkendt, gemt og kommunikeret dokument".
- Klargjorde RACI‑lignende roller (hvem initierer, hvem udarbejder, hvem reviewer, hvem godkender, hvem informeres).
- Beskrev beslutningspunkter og eskalationsveje på en måde, der kan integreres i eksisterende kvalitetsdokumentation.
Resultat
- En fælles, visuel procesbeskrivelse til onboarding og intern dialog.
- Klarere forventninger til, hvem der skal involveres hvornår.
- Et praktisk udgangspunkt for senere QMS‑arbejde – uden at foregive, at hele systemet allerede er redesignet.
- Procesbeskrivelsen kunne bruges direkte i audit‑forberedelse uden at skulle genopfindes hver gang.
Eksempel 3 – Målrettet research‑overblik for et nyt MedTech‑emne
Kontekst
Et team skulle forstå de regulatoriske og strukturelle implikationer af et nyt emne (fx en ny softwareunderstøttet funktion), men havde begrænset kapacitet til indledende desk research.
Min rolle
Levere et struktureret første kort over feltet, ikke juridisk rådgivning eller endelig regulatorisk tolkning.
Hvad jeg gjorde
- Identificerede og samlede relevante standarder, vejledninger og positionspapirer.
- Udarbejdede et kort, refereret overblikspapir med:
- hovedbudskaber pr. kilde,
- en enkel sammenligningstabel,
- noter om, hvor kilderne lægger vægten (risiko, proces, dokumentation, roller).
- Pegede på, hvor informationen kan påvirke eksisterende interne processer (fx dokumentation, risikotænkning, overlevering mellem roller).
Resultat
- Et klart udgangspunkt for teamets dialog med egne RA/QA‑eksperter og eksterne rådgivere.
- Mindre tid brugt på "at finde de rigtige PDFs", mere tid på at beslutte, hvordan man skal handle.
- Et dokumenteret grundlag, der senere kan udbygges eller justeres i takt med, at det regulatoriske landskab udvikler sig.
- Efterfølgende arbejde med eksterne rådgivere kunne bygge på ét fælles, refereret overblik i stedet for løse noter.
Intern portfolio‑database
Bag dette offentlige overblik vedligeholder jeg en mere detaljeret intern portfolio‑database i Notion – med udkast, alternative strukturer og læringsnoter.
Til en første samtale er det mindre vigtigt, hvor mange projekter der findes, og mere vigtigt om den viste arbejdsform passer til jeres situation.
Ved behov kan jeg gennemgå anonymiserede eksempler mere detaljeret i et møde.