Denne side er under udarbejdelse af Sundhedsdatastyrelsen i samarbejde med Medcom - den forventes færdig i Q1 2026 |
Indholdsfortegnelse
Formålet med denne side er at beskrive, hvordan vi tester dokumentdeling gennem NSPs dokumentdelingsservice.
| Forkortelse | Beskrivelse |
|---|---|
| SUT | System Under Test |
| Kildesystem | System der leverer dokumenter til dokumentdelingsinfrastrukturen gennem DROS |
| Modtagersystem | System der søger og ehnter dokumenter i dokumentdelingsinfrastrukturen gennem DDS - DokumentDelingsServicen |
| Anvendersystem | En fælles betegnelse for kilde- og modtagersystemer. |
| SIT | SystemIntegrationsTest - se yderlige beskrivelse under |
| Nummer | Test type | Beskrivelse | Ansvarlig |
|---|---|---|---|
| 1 | Systemintegrationstest også kaldet Egen-Test | Her verificeres at der er en teknisk sammenhængende løsning mellem en anvender og NSP Dokumentregistrerings og Opdateringsservice (DROS). 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. Medcom indsæt link til jeres beskrivelse | Medcom |
| 3 | E2E test | Her verificeres, at løsningen forretningsmæssigt fungerer efter hensigten på tværs af kildesystem(er) og modtagersystem(er). 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. Aftales med Medcom hvornår vi laver E2E test. SDS oplæg er at det er hver gang en ny dokumenttype implementeres og først når både kilde- og modtagersystem er implementeret. Det skal drøftes i hvor høj grad vi vil lave E2E på nye kilder og nye modtagersystemer, - det er et ressourcespørgsmål. | 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 EgenTesten. Forretningsreglerne løbes igennem på et møde mellem SDS/Arosii, Medcom og projektledelse, hvor det afgøres i hvilke testtyper forretningsreglerne behandles. Testcases for 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 Spørgeskemaer: Link mangler Hjemmemålinger: Link mangler Graviditetsmappe: Link mangler Indsæt link til både forretningsregler og test cases. Medcom: Er det forretningsregler for hjemmemålinger og spørgeskemaer? | Projekt |
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.
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.
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 |
| 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 |
| 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 |
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.