Lyckas med dokumentationen inom Medtech

Inom Medical Device råder hårda krav på dokumentation och att allt arbete som görs måste vara spårbart. Jag vet mycket väl hur enerverande det kan vara att behöva dokumentera för mycket men inom Medical Device finns det inget som heter överdokumentation och därför är utmaningen att dokumentera ”Just Enough”.

I denna artikel kommer jag inte gå in på vad som ska dokumenteras inom Medical Device, det finns en bra checklista här som jag har använt flertal gånger. Jag kommer istället fokusera på hur dokumentationen kan struktureras med praktiska tips på hur ni kan fördela dokumentationsbördan, undvika tung dokumentation sent i projektet och ge er inspiration till att hitta rätt nivå av dokumentation.

Alla ansvarar för dokumentationen

I ett utvecklingsprojekt bör alla ansvara för dokumentationen, inte enbart en person. Om alla dokumenterar vad de själva ska göra, vad de har gjort och hur de har genomfört arbetet (utan undantag) så kommer dokumentationen vara komplett. Då blir dokumentationsbördan inte lika stor och ni undviker att panikartat skapa dokumentationen i slutet av ett projekt eller inför en release.

En förutsättning för att det ska funka bra är dock att motivera alla att vilja dokumentera, att de förstår strukturen och vad som gäller allmänt för Medical Device och för just er produkt. Jag förutsätter att ni har ett team med olika kompetenser som alla förstår sitt arbete väl och är måna om att leverera hög kvalitet till personen som tar vid efter dem. Ovan nämnt upplägg faller dock om en enstaka teammedlem glömmer eller låter bli att göra sin del av dokumentationen.

Använd ett digitalt ärendehanteringssystem

Snälla, sluta dokumentera era krav och tester i Word och Excel. Det finns mängder med digitala verktyg för ändamålet som ger stora fördelar för samarbete, arbetsfördelning, uppföljning, rapportering samt framför allt spårbarhet.

Välj gärna ett onlineverktyg som lagrar allt i molnet och har en hög tillförlitlighet, det kommer bli er bästa vän i vardagen. Har ni budgeten så rekommenderar jag Azure DevOps, där ni har väl fungerande och heltäckande lösning för planering, krav och testarbete, kodhantering och mycket mer. Atlassians Jira och Confluence fungerar lika bra, de stora drakarna har blivit stora av en anledning. För mindre och även billigare lösningar kan jag rekommendera att ni läser min kollega Olofs blogg om testverktyg. Den är lika relevant idag som när den skrevs.

Smart formulering på era krav tillåter mer flexibilitet

Ett stort problem som många medtech-bolag bygger in tidigt är att CE-märka sin produkt på en alldeles för hög detaljnivå av sina krav och att de är formulerade med ett språkbruk som tvingar lösningsförslag att matcha vad som gällde när kraven skrevs istället för att tillåta flexibilitet och möjlighet att svara mot användarnas behov över tid.

En bra regel gällande språket när ni skriver krav är att de ska vara så enkelt formulerade och lättlästa att en helt utomstående person ska kunna förstå vad det är för produkt och vad den kan göra. Att hitta rätt språkbruk för krav kan vara klurigt, men fullt möjligt och framför allt blir det lättare om flera personer med olika erfarenheter delar bördan.

Jag rekommenderar också att skriva era krav i vad-termer istället för hur-termer. Det är väldigt vanligt att vi skriver krav som exempelvis ”Systemet ska kunna lagra personuppgifter som namn och adress i en databas”. En bättre formulering på samma krav kan istället vara ”Systemet ska lagra patientinformation” vilket ger en öppen beskrivning och tillåter anpassningar för bästa möjliga lösning senare i utvecklingsprocessen.

Ett annat verkligt misstag jag har sett är vid krav på systemanpassningar där de har formulerats som exempelvis ”Användaren ska kunna byta språk till franska”. Här kan vi med fördel ha ett ett samlingskrav som ”Användaren ska kunna anpassa systemet” istället och därefter koppla djupare nivåer av krav som förklarar anpassningen i högre detalj och omfatta fler anpassningsmöjligheter än bara språk, eller just ett specifikt språk.

Anledningen att skapa kravhierarkier är att det blir enklare att göra sena förändringar i utvecklingsprocessen allt eftersom ni som team lär er mer om kravet, behovet och lösningen. I bilden nedan ser ni de redan inbyggda hierarkierna i Azure DevOps och i Atlassian Jira. Mitt råd är att hålla språket öppet i användarkraven (User Requirement) och systemkraven (System Requirement), det vill säga Epic eller Portfolio Epic-nivå. Det är även denna nivå som ni CE-märker mot tillsammans med ert Intended Use, och pekar då mot ert ärendehanteringssystem för djupare nivåer av detaljer, där ni också över tid kan göra förändringar och marknadsanpassningar när behovet ändras. Ni gör alltså fortfarande en nedbrytning av krav för att ha en fullständig spårbarhet och fungerande planering. Det är grundläggande agila principer jag pratar om här och det behöver inte vara annorlunda för Medical Device.

Illustration av nivåerna. Till vänster är nivåbegreppen från Azure DevsOps och till höger från Atlassian Jira.

Här är ett verkligt exempel:

1. Intended Use – Ett Journalsystem för öppenvård. Hanteras i CE-märkning
2. Epic/ Portfolio Epic – Användaren ska kunna anpassa systemet. Hanteras i CE-märkning
3. Feature/Epic – Användaren ska kunna ändra språk. Tillåter anpassning
4. User Story - Funktionsdetaljer och utseende, antal språk, djupare detaljer av vad som händer när användaren klickar på något. Tillåter ännu mer anpassning
5. Task - Vem som ska göra vad, hur ni ska testa, verifiera och validera. Fullständig flexibilitet

Ert underlag för en CE-märkning blir då en länksamling mot ärendehanteringsverktyget med total spårbarhet och alla ansvarar för dokumentationen.

Sammanfattning

Strukturen på era krav är avgörande för hur flexibla ni kan vara i produktutvecklingsprocessen. Om ni CE-märker mot för hög detaljnivå blir det svårt att göra anpassningar, så välj rätt i kravhierarki, formulering och nivå för CE-märkning. Använd ett riktigt bra verktyg som hjälper er med detta, de kan vara dyra men väl värda investeringen om det möjliggör för er att utveckla en ännu bättre produkt över tid. Om ni även får alla i teamet att ansvara för dokumentation och se till att dokumentera sitt eget ansvarsområde och, viktigt att poängtera, följer det så har ni en riktigt bra grund för att skala upp er produkt och anpassa er för den nya behovsbilden som ni möter med tiden.