Sådan sporer du ændringer i en SOP

Sådan fungerer det

1. Registrér de fem felter på hver post

   Skriv den berørte SOP og trin ned, hvad der ændrede sig og hvorfor, ikrafttrædelsesdatoen, forfatteren og det præcise versionsnummer, denne post erstatter. En post uden den erstattede version efterlader et hul i loggen, ingen kan lukke bagefter.

2. Send sikkerhedskritiske ændringer ind på hastesporet

   Spørg, om ændringen rører et sikkerhedskritisk trin, før den går til review. Gør den det, skal I markere den til hastereview frem for at lade den stå i kø bag rutineændringer; gør den ikke, skal I sende den gennem den almindelige reviewcyklus.

3. Tjek for en verserende post, før I udarbejder

   Gennemsøg loggen for en post, der allerede er åben mod samme SOP, før I starter en ny. To åbne poster mod samme procedure giver to kandidatversionsnumre: koordinér med den anden forfatter, eller sekvensér ændringerne i stedet for at udarbejde parallelt.

4. Lås posten, når den er godkendt

   Registrér den godkendte post som endelig, opdater derefter SOP'ens versionsnummer og ikrafttrædelsesdato, og træk den version, den erstatter, tilbage. En post, der forbliver redigerbar efter godkendelse, er ikke en registrering, det er et udkast med en godkenders navn på.

5. Lad ændringsloggen stå for registreringen for en diagrambaseret SOP

   Er selve SOP'en et QueryChart-flowchart, kan I springe den manuelle log over for alt, der fanges på diagrammet: hver redigering er allerede sporet felt for felt. Åbn Versionshistorik, brug Sammenlign versioner til at se, hvad der ændrede sig mellem to gemte versioner, og gendan en tidligere med ét klik. Se /features/version-control.

Ofte stillede spørgsmål

Er »track changes« det samme som versionsstyring for en SOP?

Ikke helt. »Track changes« er dokumentredigeringssprog for indbyggede rettelsesmarkeringer og kommentarer inde i én fil. Versionsstyring for en SOP er praksissen med at give hver godkendt tilstand af proceduren sin egen identificerede version og holde en registrering af, hvad der ændrede sig mellem dem; en revisionshistorikpost er, hvordan den registrering bliver skrevet ned. Se /da/guides/versionsstyring-af-sop for det fyldigere skel.

Hvad skal en revisionshistorikpost registrere?

Fem ting, uanset hvem der skriver den: den berørte SOP og trin, en beskrivelse i klart sprog af ændringen og årsagen til den, ikrafttrædelsesdatoen, forfatteren og det præcise versionsnummer, posten erstatter. Den manglende erstattede version er det klart hyppigste hul i en revisionshistoriklog.

Går alle SOP-ændringer gennem samme review?

Nej. En ændring af et sikkerhedskritisk trin følger en hastereviewvej frem for at stå i kø bag rutineændringer, mens alt andet går gennem den almindelige cyklus. Begge veje mødes i samme dublettjek, før udarbejdelsen begynder: er der allerede en verserende post åben mod denne SOP?

Hvordan adskiller dette sig fra generelt at styre SOP-revisioner?

Denne side handler om mekanikken bag én post: de felter, den har brug for, reviewopdelingen, dublettjekket. Nummereringssystemet, reviewintervallet og hvem der ejer tidsplanen på tværs af hver SOP er styringslaget, gennemgået på /da/guides/saadan-styrer-du-sop-revisioner.

Erstatter QueryChart den manuelle log?

For en diagrambaseret SOP, ja, for alt der fanges på selve diagrammet: hver feltvise redigering registreres automatisk i Versionshistorik, med en Sammenlign versioner-visning og gendannelse med ét klik. Se /features/version-control. En manuel log er stadig værd at føre, hvor SOP'ens indhold lever uden for diagrammet, eller hvor en standard navngiver en revisionshistoriklog som sit eget artefakt, som det fyldigere livsforløb i den styrede SOP-skabelon.