Page History
| Info | ||
|---|---|---|
| ||
Denne side er under udarbejdelse af Sundhedsdatastyrelsen i samarbejde med Medcom - den forventes færdig i Q1 2026 |
Indholdsfortegnelse
| Table of Contents |
|---|
Intro
Formålet med denne side er at beskrive, hvordan vi tester dokumentdeling gennem NSPs dokumentdelingsservice.
Forkortelser
| Forkortelse | Beskrivelse |
|---|---|
| SUT | System Under Test |
| Kildesystem | System der leverer dokumenter til dokumentdelingsinfrastrukturen gennem DROS |
| Modtagersystem | System der søger og |
| henter dokumenter i dokumentdelingsinfrastrukturen gennem DDS - DokumentDelingsServicen | |
| Anvendersystem | En fælles betegnelse for kilde- og modtagersystemer. |
| SIT | SystemIntegrationsTest - se yderlige beskrivelse under |
Test typer
| Nummer | Test type | Beskrivelse | Ansvarlig |
|---|---|---|---|
| 1 | Dokumentdeling Systemintegrationstestogså kaldet Egen-Test forkortet (DDSIT) | Her verificeres at der er en teknisk sammenhængende løsning mellem en anvender og NSP Dokumentdelingsinfrastrukturen: Dokumentregistrerings og Opdateringsservice (DROS) og Dokumentdelingsservicen (DDS). Der er en standard testprotokol for systemintegrationstest som altid skal køres. Den er forskellig for Kildesystem og Modtagersystem. | Projekt og Leverandør |
| 2 | Certificering | Der er en egentest og en livetest af at standarden overholdes indholdsmæssigt og at metadata udfyldes korrekt ved alle kald. Se yderligere veskrivelse her: Test og certificering - MedCom Forudsætning er, at DDSIT er gennemført. | MedcomMedcom |
| 3 | E2E test | Her verificeres, at løsningen forretningsmæssigt fungerer efter hensigten på tværs af kildesystem(er) og modtagersystem(er). Testen bør involvere klinikere til at validere at indhold angivet korrekt og uforvansket i mellem kilde- og anvendersystem. Der er retningslinier for, hvad E2E testen bør indeholde, men testcases vil typisk være defineret specifikt til projektet. E2E testen tester flowet i dokumentdelingen, samtykke- og frabedelser, behandlingsrelationsnotifikationer, rettigheder samt minlog registreringer. Forudsætning er, at Certificering er gennemført. | Planlægges af projekt SDS-NSP TM deltager |
| 4 | Forretningsregel test | Det skal aftales som en del af projektet, hvornår og hvem der udfører forretningsregeltesten. Den kan foretages som en del af E2E, og dele af den kan løbes igennem i EgenTestenDDSIT. Forretningsreglerne løbes igennem på et møde mellem SDS/Arosii, Medcom og projektledelse, hvor det afgøres i hvilke testtyper forretningsreglerne behandles. Testcases beskrives i denne template (Mikkel indsæt link) Eksempler på forretningsreglerne er dokumenteret her: Et Samlet Patient Overblik ESPO (aftaler, diagnoser, forløbsplaner, stamkort): Test af Et Samlet Patientoverblik Høremappe: Test af Høremappe | Projekt |
Test arkitektur
Dette viser ikke den fulde dokumentdelingsinfrastruktur, da mange systemer er involveret.
Dette er blot et udsnit for at illustrere test scope for henholdvist systemintegrationstest og E2E test.
| Gliffy Diagram | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Hvornår skal test gennemføres?
Nedenstående tabel viser retningslinier for hvilke testtyper, der kræves.
| Situation | Hvilke tests skal gennemføres? | ||||
|---|---|---|---|---|---|
| Leverandørtest | SIT kilde | SIT modtager | Certificering | E2E | |
Ny anvender på eksisterende IT system begynder at levere eksisterende dokumenttype. Der er ikke væsentlig forskel på konfigurationen af den pågældende implementering i forhold til tidligere certificererede implementeringer. Eksempel: en kommune implementerer et eksisterende EOJ system, som allerede er certificeret. Konfiguration der vedrører dokumentdelingsdata er identisk med tidligere konfigurationer i andre kommuner | X | (X) | (X) | ||
Ny anvender på eksisterende IT system tager eksisterende dokumenttype i brug. Der er væsentlig forskel på konfigurationen af den pågældende implementering i forhold til tidligere certificererede implementeringer. Eksempel: en kommune implementerer et eksisterende EOJ system, som allerede er certificeret. Konfiguration der vedrører dokumentdelingsdata er identisk med tidligere konfigurationer i andre kommuner | X | X | X |
| |
Nyt IT system begynder at levere eksisterende dokumenttype, som allerede er E2E testet Eksempel: Et nyt bookingsystem begynder at levere aftaler | X | X | X | (X) | |
Nyt IT system begynder at hente og vise eksisterende dokumenttype, som allerede er E2E testet Eksempelvis: En ny App viser forløbsplaner | X | X | X | ||
Ny dokumenttype og/eller format introduceres både i kildesystemer og anvendersystemer Eksempelvis: EHMI beskeder skal fremover deles gennem dokumentdelingsinfrastrukturen | X | X | X | X | X |
Nye valideringsregler for dokumentregistrering introduceres Eksempelvis: Der opsættes regler for metadata ved upload af aftaler | X | X | |||
Når E2E test er påkrævet, kan denne først foretages, når mindst et kilde- og et anvendersystem er færdigimplementeret. Det betyder, at denne test tidsmæssigt kan ligge et stykke efter certificeringen af den første part.
(X) i E2E kolonnen betyder, at formel E2E med alle parter IKKE er påkrævet, men det anbefales på det kraftigste, at projektet selv validerer kildesystemets uploadede dokumenter i et relevant modtagersystem fx Sundhed.dk eller Sundhedsjournalen.
Ansvar
Ansvarsfordeling mellem MEDCOM, SDS/Arosii, projekter og leverandører
R= Responsible (udførende på opgaven), A=Accountable (ansvarlig for at opgaven udføres), C=Consulted (konsulteret), I=Informed (Informeret)
| Aktivitet | SDS PO |
|---|
| SDS TM | Medcom | Projekt |
|---|
| Projektets leverandører | |||||
|---|---|---|---|---|---|
| Systemintegrationstest | |||||
| Vedligeholdelse af checkliste til testprotokol | A | R | I | C | I |
| Systemintegrationstest / Egentest | I | C | A | R | |
| Certificering | |||||
| Planlægning af certificering |
| I | I | A | R | C | |
| Testcase udarbejdelse til egentest og certificering | I | I | A/R | C | |
| Egentest (forberedelse til certificering) | A | R | R | ||
| Medcom Certificering Metadata | I | I | A/R | R | R |
| Medcom Certificering indhold | I | I | A/R | C |
| R | |||||
| E2E test | |||||
| Vedligeholdelse af checkliste til testprotokol | A | R | C | C | |
| Planlægning af E2E | C | C | R | A | C |
| Test case udarbejdelse |
| A | R? | C | I | I | |
| Test case eksekvering | A | C? | C | R | R |
| Test rapportering og dokumentation | I | R? | I | A | C |
| Tilbagemelding på test | I | R? | R? | A | I |
...
Forudsætninger
| Testtype | Forudsætning | Ansvarlig |
|---|---|---|
| SIT | DROS dokumentdelingsinfrastruktur til dokumenttype under test skal være til stede | Projekt bestiller SDS etablerer |
| SIT | DROS skal være konfigureret til dokumenttype | Projekt bestiller SDS etablerer |
| SIT | Udvikling skal være færdig hos leverandør og systemtestet | Leverandør |
| SIT | Adgang til sundhedsdatanettet samt whitelisting skal være etableret | Projekt bestiller Operatør etablerer |
| E2E | Test borgere der kan anvendes til alle systemer der indgår i testen er oprettet inkl MitID hvis nødvendigt | Projektet |
| E2E | Data til generering af dokumenter i kildesystem skal være etableret (eller kunne etableres let under selve E2E test udførslen) | Projektet |
| E2E | Alle systemer, der indgår i testen skal være færdige, testede og deployede på et miljø, der er sammenhængende med NSP Test2 | Projektet SDS fsva NSP komponenter |
Proces for planlægning af test
| Aktivitet | Hvornår | Deltagere |
|---|---|---|
| Planlægning af testforløb, cirka tidsplan, bookning af E2E møder og certificering | 3 mdr før ønsket E2E | Projektleder tager intitiativ Deltagere: Medcom, SDS, |
SDS TM, relevante projektdeltagere |
| Gennemgang af projekt og afklaring af hvor i testprocessen de forskellige forretningsregler verificeres | 2 mdr før ønsket E2E | Projektleder tager intitiativ Deltagere: Medcom, SDS, SDS TM, relevante projektdeltagere |
Tilpasning af SIT/Egentest + E2E testprotokoller/checklister til konkret projekt Afklaring af forudsætninger for testgennemførsel samt hvem der er ansvarlig for at sikre det | 1 mdr før ønsket E2E | Projekt |
| indkalder SDS PO og SDS TM | ||
| Statusmøde vedr testklargøring, verificering af, at alle E2E forudsætninger er til stede | 1 uge før ønsket E2E | Projekt indkalder SDS PO og SDS TM |
Test protokoller
De testprotokoller, som skal gennemføres til Egentest / SIT test, ses herunder. Der tages en kopi af protokollen og den tilpasses i forhold til de retningslinier, som er beskrevet.
For E2E tests skal en ny protokol skrives hver gang. Der er en checkliste med punkter, som man som minimum skal i gennem i en E2E test, men da dokumenttyper og forretningsregler er forskellige, kan der ikke laves en generisk test protokol for E2E tests. Det er dog helt tilladt at finde inspiration i tidligere testprotokoller og derfor er der uploadet og linket til et antal eksempler.
| Page Tree | ||
|---|---|---|
|