Page History
...
Skrivning af aftaler til aftaleoversigt
| Test ID# | Test Scenarie | Forudsætninger | Forventet resultat | Resultat | Afvigelse | Kommentar |
| 1 | Forretningsregel 1 Aflevering af understøttede aftaletyper Forretningsregel 8 indgår i denne test | Det er tilknyttet en testpatient på NSP. Der skal oprettes og publiceres en aftale for hver understøttet aftaletype jvf Tabel 2 under forretningsregler Bemærk: Det er kun gældende for den/de specifikke aftaletyper som fagsystemet understøtter | For hver understøttet aftaletype, kan |
| denne hentes via delingsinfrastrukturturen. | Der testes ikke om alle felter fra CDA standarden er udfyldt korrekt, dette forudsættes gjort under MedCom's certificeringstest Ligeledes forudsættes det at XDS metadata er sat korrekt, dette kontrolleres ligeledes under MedCom's certificeringstest | |||||
| 2 | Forretningsregel 2 Løbende og tidstro aflevering | Det er tilknyttet en testpatient på NSP. Der skal oprettes og publiceres en aftale for hver understøttet aftaletype jvf Tabel 2 under forretningsregler Denne kan testes i sammenhæng med Test ID #1 | Fra aftalen med testpatienten er gemt i fagsystemet, må der ikke gå mere end 15 minutter inden aftalen kan hentes via delingsinfrastrukturen | |||
| 3 | Forretningsregel 3 Repeterende aftaler | Det er tilknyttet en testpatient på NSP. En aftale repeterende med jævne mellemrum oprettes og publiceres 6 måneder frem Bemærk: Understøttes repeterende aftaler ikke, udgår denne test. | Aftaler 6 måneder fra kan hentese via delingsinfrastrukturen | 6 måneder er besluttet ud fra hvad en borger kan forvente. | ||
| 4 | Forretningsregel 4 og 5 Aftaler ugyldiggøres (annulleres) | Det er tilknyttet en testpatient på NSP. En aftale oprettes først og deles med infrastrukturen. Samme aftales annulleres derefter | Først kontrolleres at kan hentes via delingsinfrastrukturturen. Efterfølgende kontrolleres at aftale kan hentes med StatusType: Deprecated, selve aftaledokumentet skal stadig have status active | Der ændres ikke på selve aftaledokumentet, det er udelukkende XDS-metadata der viser om en aftale er ugyldiggjort | ||
| 5 | Forretningsregel 7 Aftaler uden patientdelatagelse | Der må ikke deles aftaler uden patientdelatagelse | Fagsystemet skal godtgøre at der ikke deles aftaler uden patientdelatagelse | Det kan f.eks være en aftale mellem sundhedsfaglige, som omhandler patienten, men hvor patienten ikke selv skal deltage. | ||
| 6 | Forretningsregel 10 Spærring for deling af aftaler | Det er tilknyttet en testpatient på NSP. Der testes for 2 typer spærring: 1. Der spærres for deling af data fra dataproducerende organisation ud fra SOR-ID. 2. Der spærres for deling af data ud fra et angivet tidsrum, som indbefatter oprettelsestidspunktet af data. | XDS metadata for aftalen skal være opmærket, således det muliggør at der kan spærres for deling af aftalen | Der testes ikke for spærring af data for den specifikke sundhedsperson (ud fra autorisationsnummer) der forsøger at fremsøge data. Da denne test er forbehold brugergrænseflader. | ||
| 7 | Teknisk regel 1 Afkoblingskomponent. | Publicering af aftaler via Dokument registrerings- og opslagsservicen (DROS) skal foregå gennem afkoblingskomponenten "DCC'en". | Kontrolleres via log-opslag at afkoblingskomponenten er anvendt. | |||
| 8 | Teknisk regel 2 Sikkerhedsbillet. | Publicering af aftaler skal være baseret på en whitelistet Den Gode Webservice (DGWS) adgang, og indeholde en gyldig sikkerhedsbillet (SOSI-ID kort) på niveau 3 . | Kontrolleres via log-opslag at korrekt sikkerhedsbillet er anvendt. |
Læsning af aftaleoversigt
...