Page History
Formål
Formålet med denne test er at vise, at SUT (System Under Test) er koblet korrekt til dokumentdelingsservice på test miljøet og kan søge og hente dokumenter korrekt.
Dette foretages som en egen test af test typen Systemintegrationstest, hvor vi ser, at forbindelsen mellem Høremappemodul og NSP-Dokumentdelingsinfrastruktur er som forventet.
Scope
I denne test er SUT = Høremappemodulet.
...
Eventuelle fejl, der skal rettes før gennemførelse af E2E, noteres i test protokollen. Resultatet meddeles til projektlederen og Sundhedsdatastyrelsens PO for dokumentdeling.
Tools
| Navn | URL | Kommentar |
|---|---|---|
| XDS Portal | https://xdsportal.medcom.dk/xdsportal-test1/ | XDS Portal er en web-applikation, der kan fremsøge dokumenter i SDS Patientindekset og hente dokumenterne on-demand eller fra et XDS-repository. |
| DTG | Dynamisk Testdata Generator er en web-klient hvor en anvender kan logge ind og oprette testpersoner samt tilknytte autorisationer og ydere hertil. | |
| DRG | Dynamisk Request Generator (DRG) - Leverancebeskrivelse | Dynamisk Request Generator (DRG) kan bruges til at opbygge og eksekvere requests dynamisk mod NSP- komponenter. F.eks. kan DRG ved en test anvendes til at oprette spærring af dokumenter, uploade dokumenter eller hente dokumenter. |
Test cases
Disse bør afvikles mod NSP Test miljøet. Projektet kan aftale om det skal foregå mod Test1 eller Test2.
...
For høremappe dokumenter er det denne URL: "/decoupling/nspservices/hm" - eksempelvis: "https://test1-cnsp.ekstern-test.nspop.dk:8443/decoupling/nspservices/hm"
| Nr | Krav | Beskrivelse | Forventet resultat | Afviklings-tidspunkt | Aktuelt resultat |
|---|---|---|---|---|---|
| 1 | Hul igennem SUT medarbejder med autorisation kan |
søge et dokument gennem dokumentdelingsinfrastrukturen Følgende Domæneregler er overholdt: • |
DR6: |
"Leverandøren af et anvendersystem skal sikre, at systemet kun viser metadata og henter de dokumenttyper som forretningsstyregruppen har godkendt." DR13: "Et anvendersystem skal kunne anvende XDS metadata til at sikre, at der kun fremsøges og hentes dokumenter, som er relevante for patientens pleje og det aktuelle behandlingsforløb anvendersystemet anvendes i forbindelse med." Følgende Forretningsregler er overholdt: |
1: Data som gemmes i Høremappen skal overholde Noah datastandarden for den pågældende audiologiske oplysning og opmærkes med metadata som overholder den danske metadata-profil. Der må ikke gemmes indholdstomme dokumenter.
5: Brugeradgang til Høremappen forudsætter at den audiologiske fagperson har en behandlingsrelation til borgeren/patienten og alle adgange til Høremappen bliver logget til borgerens MinLog. I de lokale audiologiske fagsystemer skal der været etableret mekanismer, der minimerer risikoen for at brugerne kan foretage uberettigede opslag i Høremappen. Man kan fra SUT modtagersystem kun søge på typekode, derfor er test cases med formatkode irrelevante og fjernet | Som medarbejder med autorisation: Der laves et ITI- |
18 kald fra SUT på stien gennem NSP afkoblingskomponent |
Dokumentet kan afleveres uden fejl
Dokumentet kan fremsøges via DDS,
fx ved brug af XDS Portal eller DRG
Status skal være Approved
Dokumentets metadata skal overholde metadataprofilen og værdier være korrekte
Dokumentet må ikke være tomt
2025-10-10
på en borger som har et eller flere høremappedokumenter, heraf nogle stykker deprecated
|
RegistryStoredQuery" | 1) På SUT brugerfladen verificeres: Der modtages en liste af høremappedokumenter, der indeholder alle aktive dokumenter på borgeren. Borgerens deprecatede dokumenter vises ikke 2) Det konkrete API kald inspiceres og følgende verificeres: ITI-18 Søgningen er foretaget med den specifikke typekode 3) Der laves et opslag i MinLog gennem DRG (eller Sundhed.dk hvis dette foretrækkes) og følgende verificeres: Søgningen er logget med korrekt: tekst, bruger og organisation. | 2025-11-19 | ||
| 1b | Samme som 1a men med medarbejde1uden autorisation, der i stedet har national rolle nspAudiologiMedarbR4 | Samme som 1a
| 1) Samme som 1a 2) Samme som 1a 3) Samme som 1a | 2025-11-21 |
| OK |
Indsæt desuden:
A skærmbillede af metadataeller
eller
B xml fil med metadata
som bilag. Angiv "Egentest kildesystem testcase 1" som reference
2 Udelades | Såfremt Borger opslag er muligt i løsningen, så gentages test case 1 Borgeropslag er ikke mulige, så test case udelades | Som borger: Der laves et ITI-18 kald fra SUT på stien gennem NSP afkoblingskomponent på en borger som har et eller flere høremappedokumenter (der bør ligge et dokument for hvert af de formatkoder som SUT understøtter at vise) | Der modtages en liste af høremappedokumenter Søgningen er foretaget med den specifikke typekode og eventuelt også den specifikke formatkode. Søgningen er foretages af borgeren selv Der laves et opslag i MinLog gennem DRG (eller Sundhed.dk hvis dette foretrækkes) for at checke at søgningen er logget med korrekt: tekst, bruger og organisation. Teksten skal være "Opslag i høremappen af borger" | ||
3 Udelades | Såfremt opslag af forældermyndighedsindehaver og/eller fuldmagtshaver er muligt i løsningen, så gentages test case 2 for hver af disse Borgeropslag er ikke mulige, så test case udelades | Som forældermyndighedsindehaver/fuldmagtshaver: Der laves et ITI-18 kald fra SUT på stien gennem NSP afkoblingskomponent på en borger som har et eller flere høremappedokumenter (der bør ligge et dokument for hvert af de formatkoder som SUT understøtter at vise) | Der modtages en liste af høremappedokumenter Søgningen er foretaget med den specifikke typekode og eventuelt også den specifikke formatkode. Søgningen er foretages af forældermyndighedsindehaver/ værge/fuldmagtshaver Der laves et opslag i MinLog gennem DRG (eller Sundhed.dk hvis dette foretrækkes) for at checke at søgningen er logget med korrekt: tekst, bruger og organisation. Teksten skal være "Opslag i høremappen af forældermyndighedsindehaver/fuldmagtshaver" | ||
| 4a | SUT kan hente og vise dokumenter der ligger i dokumentdelingsinfrastrukturen for medarbejder med autorisation Fyldestgørende dokument | Som medarbejder med autorisation: Der laves et ITI-43 |
En sundhedsperson, der anvender SUT, skal kunne udpege og ugyldigøre et dokument som tidligere er oprettet i et XDS repository.
Kravet er kun gældende for ”stable” dokumenter.
Følgende Domæneregler er overholdt:
•DR09: "Dokumentet skal kunne opdateres så det fremstår som ugyldiggjort"Følgende Forretningsregler er overholdt:
3: Parterne skal kunne slette/opdatere data som de selv har oprettet i Høremappen, eksempelvis for at slette/opdatere fejlagtige data. og
4: Når data slettes lokalt jf. gældende lokale slettefrister skal data også slettes i Høremappen.
Der laves et ITI-57kald fra SUT på stien gennem NSP afkoblingskomponent |
på et fyldestgørende høremappedokument |
|
2007: |
RetrieveDocumentSet" | Dokumentet |
Dokumentet kan fremsøges via DDS,
fx ved brug af XDS Portal eller DRG
Status skal være Deprecated
vises som det skal i SUT Der laves et opslag i MinLog gennem DRG (eller Sundhed.dk hvis dette foretrækkes) for at checke at søgningen er logget med korrekt: tekst, bruger og organisation. Teksten skal være "Visning af oplysninger" | 2025-11-19 | OK Request: Egentest-OUH-modtagersystem-testcase-4a-request.xml Screenshots: MinLog ved Sundhed.dk:
|
| 4b | SUT kan hente og vise dokumenter der ligger i dokumentdelingsinfrastrukturen for medarbejder med national rolle nspAudiologiMedarbR4 Fyldestgørende dokument
| Som medarbejder med national rolle nspAudiologiMedarbR4: Der laves et ITI-43 |
2025-10-10
kl 14:27:06
OK/Fejl (beskriv fejlen)
Indsæt desuden:
A skærmbillede af metadataeller
eller
B xml fil med metadata
som bilag. Angiv "Egentest kildesystem testcase 2" som reference
Et dokument kan erstattes af et andet dokument
Følgende Forretningsregler er overholdt:
3: "Parterne skal kunne slette/opdatere data som de selv har oprettet i Høremappen, eksempelvis for at slette/opdatere fejlagtige data."
kald fra SUT på stien gennem NSP afkoblingskomponent |
på et fyldestgørende høremappedokument |
"soap-action": "urn:ihe:iti:2007: |
RetrieveDocumentSet" | Dokumentet |
Det nye dokument kan hentes og har status Approved
Det gamle dokument kan hentes og har status Deprecated
vises som det skal i SUT Der laves et opslag i MinLog gennem DRG (eller Sundhed.dk hvis dette foretrækkes) for at checke at søgningen er logget med korrekt: tekst, bruger og organisation. Teksten skal være "Visning af oplysninger" | 2025-11-21 | ||||
5 | SUT tager højde for spærring og frabedelser i visning af dokumenter Følgende Domæneregler er overholdt: DR 10: "Et anvendersystem skal flage hvis der, ved en søgning i SDS patientindekset, returneres information om, at borgeren har registreret spærring." Følgende Forretningsregler er overholdt: 8: Parternes fagsystemer skal kunne håndtere at borgeren har spærret for adgang til Høremappen. Et fagsystem skal således flage hvis der, ved en søgning i Høremappen, returneres information om, at borgeren har registreret spærring. Et fagsystem skal give brugeren mulighed for at anvende værdisprings-reglen for at tilsidesætte spærring og hente dokumenter, som borgeren har spærret for. Værdispring og meddelelse om spærringer/frabedelser understøttes ikke i projektet men det testes, at spærrede dokumenter ikke vises (dataspærring på klinikniveau) | Der laves en frabedelse af deling af dokumenter fra høreklinikken på en borger som HAR dokumenter fra den pågældende frabedte klinik SAMT minimum en anden klinik, hvor der ikke er frabedelser Som medarbejder laves et ITI-18 kald på den pågældende borger "soap-action": "urn:ihe:iti:2007:RegistryStoredQuery" | I SUT : Der vises ingen dokumenter fra klinikken med frabedelse men øvrige dokumener vises Der laves et opslag i MinLog gennem DRG (eller Sundhed.dk hvis dette foretrækkes) for at checke at søgningen er logget med korrekt: tekst, bruger og organisation. Teksten skal være "Opslag i høremappen af sundhedsfaglig" | 2025-11-21 | OK Screenshot:
MinLog:
|
6 Udelades | SUT kan lave værdispring Følgende Domæneregler er overholdt: DR 11: "Et anvendersystem skal give brugeren mulighed for at hente dokumenter, som borgeren har spærret adgangen til. |
2025-10-10
kl 14:27:06
OK/Fejl (beskriv fejlen)
Indsæt desuden:
A skærmbillede af metadataeller
eller
B xml fil med metadata
som bilag. Angiv "Egentest kildesystem testcase 3" som reference
Test case 1 gentages et antal gange ud fra følgende parametre:
- Kombination af alle typekoder og/eller formatkoder som er relevante for det pågældende projekt og SUT.
- Hvis der er andre specifikke forretningsregler, såsom hvilke eventcodes der hører til hvilke formatcodes, så skal der være et scenarie for hver mulig kombination
- Hvis dokumenttypen kan indeholde større eller mindre mængder af data så medtages
- et minimumssenarie, hvor kun obligatoriske felter er udfyldt og med så få data som muligt
- et maksimum scenarie hvor alle elementer er udfyldt og fritekster og tal skrives med så mange tegn/cifre som muligt
Eksempler:
- 4a: SUT kan publicere et audiologi dokument med typekode 28615-3 og formatkode nauf-v500. Eventcode skal være 1. Minimumsudfyldelse
- 4b: SUT kan publicere et audiologi dokument med typekode 28615-3 og formatkode nauf-v502. Eventcode skal være 1. Maksimumsudfyldelse
Det er op til SUT leverandør at vurdere hvor mange forskellige kombinationer, det er relevant at medtage.
Følgende Domæneregler er overholdt:
DR2: "Dokumenter skal have et format, der fremgår af listen dk-ihe-formatcode-cs (urn:oid:1.2.208.184.100.10)." Følgende Forretningsregler er overholdt: |
1: Data som gemmes i Høremappen skal overholde Noah datastandarden for den pågældende audiologiske oplysning og opmærkes med metadata som overholder den danske metadata-profil. Der må ikke gemmes indholdstomme dokumenter.
Samme som testcase 1, hvor dokument og metadataangivelse passer til den enkelte testcase a,b,c
Denne række duplikeres for hvert sæt af dokumenttype/formatkode, der skal testes. Hver linie angives med et nyt bogstav, eksempelvis 4a, 4b, 4c osv.
Det er leverandøren af SUTs ansvar at medtage alle relevante kombinationer.
Denne testcase kan helt udelades såfremt der kun findes en dokumenttype/formatkode kombination i det pågældende SUT, og der ikke er øvrige særlige regler for andre metadata såsom eventcodes - i så fald kan dette scenarie være dækket alene af testcase 1.
Samme som testcase 1
Her verificeres yderligere at formatkode, dokumenttype, øvrige relevante metadata felter som fx eventcode og indhold af dokument er korrekt. Det er vigtigt at sikre at alt tekst og elementer er til stede i dokumentet fra infrastrukturen.
2025-10-10
kl 14:27:06
OK/Fejl (beskriv fejlen)
Indsæt desuden:
A skærmbillede af metadataeller
eller
B xml fil med metadata
som bilag. Angiv "Egentest kildesystem testcase 4a/b/c..." som reference
SUT skal dokumentere at SUT selv indeholder journalføringen.
8: Parternes fagsystemer skal kunne håndtere at borgeren har spærret for adgang til Høremappen. Et fagsystem skal således flage hvis der, ved en søgning i Høremappen, returneres information om, at borgeren har registreret spærring. Et fagsystem skal give brugeren mulighed for at anvende værdisprings-reglen for at tilsidesætte spærring og hente dokumenter, som borgeren har spærret for. Værdispring og meddelelse om spærringer/frabedelser understøttes ikke i projektet men det testes, at spærrede dokumenter ikke vises (dataspærring på klinikniveau) | På samme medarbejder og borger laves der nu værdispring i SUT efter at beskeden om, at ikke alle dokumenter vises Denne test case kan udføres umiddelbart efter test case 5 | I SUT: Dokumenterne vises nu. Der laves et opslag i MinLog gennem DRG (eller Sundhed.dk hvis dette foretrækkes) for at checke at søgningen er logget med korrekt: tekst, bruger og organisation. Teksten skal være "Opslag i høremappen af sundhedsfaglig hvor frabedelser tilsidesættes" | ||
| 7 | Følgende Domæneregler er overholdt: DR 7: "Leverandøren af et anvendersystem skal sikre, at systemet ikke kan persistere metadata som søges i SDS patientindekset eller de dokumenter, som hentes via SDS patientindekset" Følgende Forretningsregler er overholdt: 7: Som udgangspunkt må data hentet fra Høremappen ikke persisteres/gemmes i eget fagsystem - medmindre de hentede data indgår som grundlag i den videre behandling af borgeren. Eksempelvis må audiogram-data hentet fra Høremappen som benyttes til at tilpasse/justere høreapparater godt gemmes lokalt |
5: Parterne skal lokalt opretholde en patientjournal jf. gældende journal lovgivning. Høremappen er ikke journalbærende, men er udelukkende en delingsplatform
. | Denne test foretages ved at beskrive/dokumentere hvordan SUT overholder forretningskravet | SUT kan dokumentere kravsopfyldelsen |
OK/Fejl (beskriv fejlen)
Indsæt desuden:
A skærmbillede af metadataeller
eller
B xml fil med metadata
som bilag. Angiv "Egentest kildesystem testcase 4a/b/c..." som reference
OK | |
| 8 |
Værdisæt i SUT opdateres løbende. Følgende Domæneregler er overholdt: • DR14: "Et kildesystem og/eller anvendersystem skal indeholde en funktion, som gør det muligt at opdatere systemet med den aktuelt gældende version af valuesets. Opdateringen skal udføres med et interval på maksimum 90 dage." | Denne test foretages ved at beskrive/dokumentere hvordan SUT overholder forretningskravet | SUT kan dokumentere kravsopfyldelsen | OK |
Indsæt desuden:
A skærmbillede af metadataeller
eller
B xml fil med metadata
Integration til Høremappen foregår via afkoblede komponenter (Høremappe modulet + proxyservice) som kan opdatere uafhængigt af det audiologiske fagsystem (her Auditbase). Høremappe modul + proxy kan opdateres med nye valuesets indenfor den angivne frist skulle det blive aktuelt. |