ID | Type krav | Gjelder for type integrasjon (Portal / API) | API | Krav | Må-/bør-krav | Kommentar | Akseptansetest |
|---|
F.1 | Funksjonelt | Portal, API | | KJ-ikon (helseindikatorikon) presenteres synlig for brukeren i det kliniske fagsystemet. | Må | Ikoner lastes ned fra vedlegg i integrasjonsguide: Integration Guide Kjernejournal Portal Ved API-integrasjon: Kravet kan endres til et bør krav ved API-integrasjon. Variabler som påvirker dette: Variablene nevnt ovenfor påvirker om Leverandør vurderer dette sammen med NHN. | Demomøte (Akseptansetest del 1) |
F.2
| Funksjonelt | Portal | | KJ-ikon har en tooltip som gir bruker informasjon om personens KJ status. | Må |
| Demomøte (Akseptansetest del 1) |
F.3 | Funksjonelt | Portal | | Det kliniske fagsystemet skal tilby helsepersonell tilgang til KJ enten som en ny fane i det kliniske fagsystemet eller som et separat vindu som åpnes etter trykk på ”KJ-ikonet”. *minimumsstørrelse 960x640 | Må |
| Demomøte (Akseptansetest del 1) |
F.4 | Funksjonelt | Portal | | Brukeren skal enkelt kunne klippe og lime fra KJ til det kliniske fagsystemet ved hjelp av KJs kopier til utklipp-funksjonalitet. | Må |
| Demomøte (Akseptansetest del 1) |
F.5 | Funksjonelt | Portal | | PDF generert i KJ-portal må kunne lastes ned til lokal klient og bruker må ha tilgang til PDF-leser og ha mulighet for utskrift av PDF-filer. | Må |
| Demomøte (Akseptansetest del 1) |
F.6 | Funksjonelt | Portal | | For å ivareta pasientsikkerheten skal KJ portalen være tett knyttet til den åpne pasienten i EPJ-systemet, slik at det ikke oppstår forvirring om hvilken pasient som er åpen i KJ. | Må | For web-baserte kliniske fagsystemer vil ikke dette være fullstendig kontrollerbart, men ved å bruke windows.open og parameteret windowName kan det sørges for at den samme fanen benyttes hver gang man trykker på KJ-ikonet, gitt normale innstillinger i Chrome. Et alternativ kan være å benytte det returnerte objektet til å lukke eksisterende fane og så benytte windows.open på nytt.
Dette vil ikke garantere at det kliniske fagsystemet har full kontroll på faner med KJ, ettersom brukeren kan styre en del innstillinger i nettleser, eller klone flere faner manuelt. Det er likevel bedre enn at det åpnes nye faner fortløpende. | Akseptansetest del 2a: Integrasjonstest |
F.7 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet må utvikle dialog med funksjonalitet for å angi samtykke for: | Må | Helsepersonell må alltid angi samtykke for nedlasting av informasjon fra kjernejournal via KJ.
| Demomøte API (Akseptansetest del 1) |
F.8 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet må utvikle dialog med funksjonalitet for å angi samtykke for: | Må | Dersom responsen fra KJ opplyser om at det finnes sperret fane (eksempelvis legemiddelfane eller kritisk informasjonsfane) må sluttbruker kunne angi samtykke for åpning av fane og sende ny forespørsel til KJ med samtykke for åpning av sperret fane. I respons fra KJ vil informasjon i den sperrede fane fremkomme. Tekst som skal vises sluttbruker: Ved pasientens samtykke:
"Informasjonen hentes fra KJ og lagres i pasientjournalen med pasientens samtykke. Pasienten har gitt sitt samtykke til at jeg kan få tilgang til informasjonen." Ved akuttsituasjon:
"Det er en akuttsituasjon der pasienten ikke er i stand til å samtykke, og det er fare for liv og alvorlig helseskade. Jeg får tilgang til sperret informasjon, denne hentes fra KJ og lagres i pasientjournalen" | Demomøte API (Akseptansetest del 1) |
F.9 | Funksjonelt | API | Legemiddel API | Det kliniske fagsystemet må utvikle dialog med funksjonalitet for å angi samtykke for: | Må | Dersom responsen fra KJ opplyser om at det finnes låste resepter må sluttbruker kunne angi samtykke for å låse opp låste resepter. I nytt kall mot KJ sendes det da samtykke for å åpne låste resepter. I responsen fra KJ vil låste resepter inkluderes. | Demomøte API (Akseptansetest del 1) |
F.10
| Funksjonelt
| API
| Legemiddel API, FHIR Kritisk info API
| Det kliniske fagsystemet må vise resultatet av spørring etter informasjon i KJ på en brukervennlig måte.
| Må
|
| Demomøte (Akseptansetest del 1)
|
F.11 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet må vise resultatet av spørring etter informasjon fra KJ komplett til sluttbruker. | Må | Komplett i denne sammenheng betyr at det kliniske innholdet fra responsen presenteres sluttbruker. Metadata som ikke endrer betydningen av klinisk innhold kan håndteres i bakgrunnen og må ikke vises til bruker. | Demomøte (Akseptansetest del 1) |
F.12 | Funksjonelt | API | Legemiddel API, FHIR Kritisk info API | Når det gjøres oppslag mot KJ, og informasjon fra KJ hentes inn i det kliniske fagsystemet, skal det komme tydelig frem at KJ er kilde til informasjon. | Må | Dersom informasjon fra KJ presenteres sammen med lokale felter skal det være tydelig for bruker hvilke felter som kun er lokale og hvilke som synkroniseres mot KJ. | Demomøte (Akseptansetest del 1) |
F.13 | Funksjonelt | API | FHIR Kritisk info API | Ved opplasting av informasjon til KJ skal det i dialog til sluttbruker tydelig fremkomme deresom: | Må | Ved manglende informasjon ved opplasting bør det presenteres en dialog til sluttbruker hvor manglende informasjon kan registreres. | Demomøte (Akseptansetest del 1) |
F.14 | Funksjonelt | API | FHIR Kritisk info API | Dersom opplasting til KJ ved endring eller nyregistrering feiler, skal bruker varsles. Det må være funksjonalitet for å manuelt forsøke på nytt, eller lokal lagring av registreringen. Dersom registreringen kun lagres lokalt skal dette tydelig markeres som ikke lastet opp til KJ. | Må | Når det ligger lokale registreringer som ikke er blitt lastet opp til KJ bør neste bruker som åpner samme informasjon få anledning til å forsøke en ny opplasting. Dette bør da være en manuelt styrt opplasting i tilfelle denne brukeren må rådføre seg eller kontrollere opplysningene før de lastes opp. | Demomøte (Akseptansetest del 1) |
F.15
| Funksjonelt
| API
| FHIR Kritisk info API
| Når bruker gjør endringer eller nyregistreringer i felter som synkroniseres med KJ bør oppdatering sendes til KJ automatisk.
| Bør
| Opplasting til KJ bør skje automatisk og ikke være avhengig av en aktiv handling fra bruker. (For å hindre at endringer kun lagres lokalt og ikke opplastes til KJ)
| Demomøte (Akseptansetest del 1)
|
F16
| Funksjonelt
| API
| FHIR Kritisk info API
| Ved blokkering av enkelte helsepersonell i KJ skal det vises en feilmelding. Feilmeldingen bør henvise til at informasjon er tilgjengelig i KJ Portal.
| | | |
F.17 | Funksjonelt | API | FHIR Kritisk info API | Dersom kontakten mellom det kliniske fagsystemet og KJ er brutt (og kritisk informasjon synkroniseres) ved bruk av API, må dette kommuniseres ved hjelp av feilmelding til sluttbruker. | Må | Å vise status ved symbol/ikon for ingen kontakt med API-el. feil i synkronisering skal sikre at brukeren er oppdatert om status mot KJ. Samtidig bør det ikke hindre at informasjon kan fortsatt oppdateres lokalt i EPJ, dersom det er ønskelig. Leverandør må beskrive i løsningsbeskrivelse hvordan dette håndteres. | Demomøte (Akseptansetest del 1) |
F.18 | Funksjonelt | API | FHIR Kritisk info API | Det kliniske fagsystemet bør vise hjelpetekst (i tooltip) for kodeverket for kritisk informasjon. | Bør | Her menes kodeverket for kritisk informasjon kategoriene “Smitte” og “Kritisk medisinsk tilstand”. Sendes med i FHIR-respons, under code.coding. For flere detaljer: /wiki/spaces/KJERNEJOUR/pages/547062040 og /wiki/spaces/KJERNEJOUR/pages/546668853 | Demomøte (Akseptansetest del 1) |
F.19 | Funksjonelt | API | FHIR Kritisk info API | Det kliniske fagsystemet må indikere for sluttbruker hvilke av de obligatoriske feltene (S-dataelementene/feltene i FHIR-profil) som ikke er samstemt med KJ. | Må | Skal vise konflikter mellom det kliniske fagsystemet og KJ. Dette bidrar til effektivisering av synkjobben mellom det kliniske fagsystemet og KJ. | Demomøte (Akseptansetest del 1) |
F.20 | Funksjonelt | API | FHIR Kritisk info API | Lokal kritisk info som er samstemt med KJ skal ikke kunne oppdateres i det kliniske fagsystemet uten at det synkront oppdateres med KJ. | Må | Det bidrar til å sikre en god datakvalitet i begge systemer, hvis det kliniske fagsystemet opererer med flere felter som dekker eldre data og nye informasjonen som er samstemt med KJ. | Demomøte (Akseptansetest del 1) |
T.1 | Teknisk | Portal | | Når bruker klikker på KJ-ikonet skal det åpnes en intern nettleser som åpner URL-adressen til hentpasient med ticket:
https://kjernejournal.no/hpp-webapp/ hentpasient.html?ticket=<URL-enkodet ticket> | Må |
| Demomøte (Akseptansetest del 1) |
T.2 | Teknisk | Portal, API | | I kommunikasjonen med KJ skal det kliniske fagsystemet inkludere en "X-EPJ-System"-header som indikerer hvilket klinisk fagsystem, og hvilken versjon, det er som utfører kallet. | Må | As web based EHR systems isn’t able to add HTTP headers to the portal requests, they MAY send the X-EPJ-System parameter in the URL instead
| Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
T.3 | Teknisk | Portal, API | | Pasienten skal være registrert i det lokale kliniske fagsystemets pasientregister med fødsels- eller D-nummer for å kunne åpne pasientens KJ (portal) eller lese/skrive informasjon fra/til pasientens KJ (API). | Må |
| Demomøte (Akseptansetest del 1) |
T.4 | Teknisk | Portal | | Det kliniske fagsystemet må benytte tjenesten hold sesjon som tilbys fra KJ. | Må |
| Akseptansetest del 2a: Integrasjonstest portalintegrasjon Akseptansetest del 2b: Avbruddstest portalintegrasjon |
T.5 | Teknisk | Portal | | Det kliniske fagsystemet må benytte tjenesten ”Logg av” som tilbys fra KJ når bruker logger av det kliniske fagsystemet. | Må |
| Akseptansetest del 2b: Avbruddstest portalintegrasjon |
T.6 | Teknisk | Portal | | Det kliniske fagsystemet må støtte at det lastes ned krypterte PDF-er fra KJ-nettleseren i det kliniske fagsystemet. PDF-en skal lagres i minnet og ikke til disk (alternativt slette PDF fra temp-mapper ved lukking/utlogging fra kliniske fagsystem) for å forhindre at informasjon blir tilgjengelig for andre brukere The EHR must support downloads of PDF's from the the KJ browser. The EHR must ensure that the PDF files are not stored longer than necessary since the files contains sensitive data. | Må |
| Demomøte (Akseptansetest del 1) |
T.7 | Teknisk | Portal, API | | Det kliniske fagsystemet skal ha en sentral konfigurerbar verdi som (de)aktiverer KJ-integrasjon i det kliniske fagsystemet. | Må |
| Demomøte (Akseptansetest del 1) KJEKSTERN-148 - Demomøte (Akseptansetest del 1) |
T.8 | Teknisk | Portal, API | | I det kliniske fagsystemet bør det være mulig, gjennom et brukergrensesnitt, å konfigurere hvilken brukergruppe eller enkeltpersoner som skal ha tilgang til KJ. | Bør | Da det er tilfeller hvor det er helsepersonellroller ved virksomheter som ikke har tjenstlig behov for KJ bør disse heller ikke få tilgang på KJ portal eller API.
| Demomøte (Akseptansetest del 1) |
T.9 | Teknisk | Portal, API | | Kall til helseindikatortjenesten må implementeres slik at det kliniske fagsystemet ikke blir hengende dersom det ikke oppnås kontakt med KJ. | Må | Som et kall i egen tråd. | Akseptansetest del 2b: Avbruddstest portalintegrasjon |
T.10 | Teknisk | Portal | | Innebygd nettleser må skjule adressefelt | Må |
| Demomøte (Akseptansetest del 1) |
T.11 | Teknisk | Portal | | Innebygd nettleser må skjule knapperad | Må |
| Demomøte (Akseptansetest del 1) |
T.12 | Teknisk | Portal | | Innebygd nettleser må ha skrudd av mulighet for høyreklikk-funksjonalitet | Må |
| Demomøte (Akseptansetest del 1) |
T.13 | Teknisk | Portal | | Innebygd nettleser må støtte Ctrl + A, Ctrl + C og Ctrl + V | Må |
| Demomøte (Akseptansetest del 1) |
T.14 | Teknisk | Portal | | Når en pasientjournal lukkes i det kliniske fagsystemet må den tilhørende åpne KJ-portalen også lukkes. | Må | Se kommentar tilhørende F.6 for web-basert EPJ.
| Demomøte (Akseptansetest del 1) |
T.15 | Teknisk | Portal | | Det må benyttes en nettleser som støttes av KJ. | Må | KJ støtter kun inntil to år gamle versjoner av Chrome og Edge. | Demomøte (Akseptansetest del 1) |
T.16 | Teknisk | Portal | | En oppgradering av nettleseren benyttet til KJ-portal bør ikke være avhengig av oppgradering av det kliniske fagsystemet. | Bør | Nettleseren som benyttes til KJ bør ikke være avhengig av oppgradering av selve det kliniske fagsystemet. Dersom oppdatering av nettleser krever en oppgradering av det kliniske fagsystemet forventes det hyppige oppdateringer slik at det tilstrebes at nettleser til enhver tid ikke er eldre enn 2 år. | Demomøte (Akseptansetest del 1) |
T.17 | Teknisk | Portal | | Integrert nettleser i EPJ skal ikke dele state (cookies, cache o.l.) med frittstående nettleser. Innlogging i KJ i EPJ skal ikke medføre at man blir logget inn i noen frittstående nettleser.
| Må | | Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
T.18 | Teknisk | Portal, API | | Det kliniske fagsystemet må kunne benytte HelseID sitt API for å hente et access-token som brukes på KJs REST-API for henting av pasientens helseindikator. | Må | Se integrasjonsguide for detaljer om scope, audience og security_level | Akseptansetest del 2a: Integrasjonstest |
T.19 | Teknisk | Portal, API | | Det kliniske fagsystemet må kunne kalle KJs REST-API med access-token fra HelseID for henting av pasientens helseindikator. | Må |
| Akseptansetest del 2a: Integrasjonstest |
T.20 | Teknisk | Portal | | Det kliniske fagsystemet må kunne tolke alle 5 indikatorverdiene i JSON-respons og vise korrekt KJ-ikon i det kliniske fagsystemet. | Må | Se også F.1 | Demomøte (Akseptansetest del 1) |
T.21 | Teknisk | Portal | | Det kliniske fagsystemet må kunne hente ticket fra JSON-respons og bruke dette som URL-parameter ved åpning av KJ. | Må |
| Akseptansetest del 2a: Integrasjonstest |
T.22 | Teknisk | Portal, API | | Dersom det kliniske fagsystemet både har portal- og API-integrasjon skal det kliniske fagsystemet støtte at ticketen med samtykket fra API-oppslaget gjenbrukes ved senere portaloppslag på samme pasient. | Må | | Akseptansetest del 2a: Integrasjonstest |
T.23 | Teknisk | Portal, API | | Det kliniske fagsystemet må kunne tolke feilmeldinger fra KJs APIer. Brukermeldingen skal presenteres for brukeren, og feilkoden skal logges. | Må | | Demomøte (Akseptansetest del 1) Akseptansetest del 2a: Integrasjonstest |
T.24 | Teknisk | Portal, API | | Det kliniske fagsystemet kan teste tilkobling mot KJ ved å kalle KJs ping-tjeneste med access-token fra HelseID. | Bør | For å teste at kommunikasjon fungerer, uten å faktisk hente helseinformasjon | - |
T.25 | Teknisk | Portal, API | | Det kliniske fagsystemet må bruke helsepersonellets aktuelle arbeidssted når det henter access-token fra HelseID, slik at oppslaget i KJ blir knyttet opp mot korrekt virksomhet. | Må | KJ knytter oppslaget opp mot virksomheten i tokenet fra HelseID. Dette er viktig for KJ som logger hvilken virksomhet skjer oppslaget fra. | Akseptansetest del 2a: Integrasjonstest |
T.26 | Teknisk | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet skal teknisk legge til rette for nedlasting av informasjon fra KJ via API automatisk | Må | Avhenger av sluttbrukers ønske om bruk av API, må-kravet kan derfor falle bort.
| Demomøte (Akseptansetest del 1) |
T.27 | Teknisk | API | Legemiddel API, FHIR Kritisk info API | Det kliniske fagsystemet skal teknisk legge til rette for nedlasting av informasjon fra KJ via API ved manuell handling | Må | Sluttbruker skal i det kliniske fagsystemet manuelt kunne velge å laste ned informasjon fra KJ | Demomøte (Akseptansetest del 1) |
T.28 | Teknisk | API | FHIR Kritisk info API | API-integrasjonen må utvikles i tråd med den tekniske dokumentasjon/dokumentasjon for FHIR-API | Må | Integrasjonen skal være i tråd med FHIR-profiler beskrevet på Simplifier - https://simplifier.net/kjernejournalr4 | Demomøte (Akseptansetest del 1) |
T.29
| Teknisk
| API
| FHIR Kritisk info API
| KJ fungerer som et nasjonalt sentralt arkiv for kritisk informasjon og det kliniske fagsystemet opprettholder en lokal kopi av denne informasjonen.
Kritisk informasjon i det kliniske fagsystemet kan være utdatert på grunn av at pasient har vært på andre steder og har fått oppdatert kritisk informasjonen sin.
For det kliniske fagsystemet er det nødvendig å lese fersk informasjon fra KJ ved hjelp av API før pasientbesøk.
| Bør
| Integrasjonen skal være i tråd med FHIR-profiler beskrevet på Simplifier - https://simplifier.net/kjernejournalr4
Les /wiki/spaces/KJERNEJOUR/pages/547061989 for Kritisk info-profiler.
| Demomøte (Akseptansetest del 1)
|
T.30 | Teknisk | API | FHIR Kritisk info API | For hver opprett/oppdater/slett-operasjon skal det kliniske fagsystemet hente oppdatert data før det utfører skriveoperasjonen. | Må | Det er viktig å jobbe med oppdatert data for å unngå duplisering og for å forbedre kvaliteten på kritisk informasjon. Integrasjonen skal være i tråd med FHIR-profiler beskrevet på Simplifier - https://simplifier.net/kjernejournalr4 Les /wiki/spaces/KJERNEJOUR/pages/547061989 for Kritisk info-profiler. | Demomøte (Akseptansetest del 1) |
T.31 | Teknisk | API | FHIR Kritisk info API | Det kliniske fagsystemet må kunne benytte timestampene i helseindikator-responsen for å avgjøre om de skal lese kritisk informasjon i KJ eller ikke. | Må | Hver gang helsepersonell åpner kritisk informasjon til en pasient skal det gå et kall til KJ for å sjekke om det er kritisk informasjon i KJ på pasienten.
Det kliniske fagsystemet må kunne benytte timestampene i helseindikator-responsen for å avgjøre om de skal lese kritisk informasjon i KJ eller ikke. Dette skal sikre at man ikke kaller APIet mer enn det er nødvendig. | Demomøte (Akseptansetest del 1) |
T.32 | Teknisk | API | FHIR Kritisk info API | Tidspunktet for synkronisering av kritisk informasjon bør være synlig for sluttbruker i det kliniske fagsystemet. | Bør | Dette er for å tydeliggjøre at kliniker jobber med en eldre versjon av kritisk Informasjon som kan skape utfordringer ved synkronisering med KJ på et senere tidspunkt. Ved et forsøk på synkronisering av utdaterte data vil det feile. Alle obligatoriske felt per profil står her: https://simplifier.net/kjernejournalr4/~resources?category=Profile&sortBy=RankScore_desc Les /wiki/spaces/KJERNEJOUR/pages/547061989 for Kritisk info-profiler. | Demomøte (Akseptansetest del 1) |
T.33
| Teknisk
| API
| Legemiddel API, FHIR Kritisk info API
| Hvis en helsepersonell bytter virksomhet i det kliniske fagsystemet, må det gjøres virksomhetautentisering på nytt.
| Må
| Dekkes av T.25.
| Akseptansetest del 2a: Integrasjonstest
|
T.34 | Teknisk | API | FHIR Kritisk info API | Dersom man benytter et annet kodeverk i det kliniske fagsystemet enn det som er gyldig på kritisk info-elementet, må man sikre 1-1 mapping mellom to kodeverk. | Må | Dette kravet skal sikre at man har en mapping mellom to kodeverk og skal begrense mulighet for å få feil fra Kritisk info-API. Kodeverk som er i bruk per felt per profil finnes under følgende linken : https://simplifier.net/kjernejournalr4/~resources?category=Profile&sortBy=RankScore_desc | Demomøte (Akseptansetest del 1) |
T.35 | Teknisk | API | FHIR Kritisk info API | Dersom det kliniske fagsystemet benytter et køsystem, må det benyttes en personlig bruker, ikke en systembruker, når data synkroniseres med KJ. | Må | Kravet gjelder både ved systembrudd og vanlige oppdateringer mot KJ da det ved opplasting til KJ skal tas stilling til data. Ved bruk av køsystem må konsument benytte personlig pålogging i alle tilfeller. Konsumenter må bygge en mekanisme som sikrer dette. | |
S.1 | Sikkerhet | Portal, API | | Det kliniske fagsystemet må benytte TLSv1.2 eller høyere. | Må |
| Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
S.2 | Sikkerhet | Portal, API | | Det kliniske fagsystemet skal validere at sertifikatene i TLS-koblingene mot KJ er gyldige til formålet (godkjent utsteder, gyldig for korrekt hostnavn og gyldig dato). | Må | Dette håndteres normalt sett av underliggende biblioteker, men det må ikke deaktiveres av fagsystemet. | Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
S.3 | Sikkerhet | Portal, API | | Det kliniske fagsystemet bør ikke godta revokerte sertifikater (verken TLS eller virksomhetsertifikater). | Bør | Dette for å beskytte det kliniske fagsystemet i en eventuell feilsituasjon der sertifikatene til KJ mot formodning skulle bli kompromittert. | Akseptansetest del 2a: Integrasjonstest portalintegrasjon |
S.4 | Sikkerhet | Portal, API | | Nøkkel som benyttes i forbindelse med S.5 må oppbevares sikkert og med samme sikkerhetstiltak som ved oppbevaring av virksomhetssertifikater i virksomheten. | Må | Dette er i praksis et HelseID-krav, men KJ velger å peke på dette da det påvirker KJ-integrasjon. | - |
S.5 | Sikkerhet | Portal, API | | Det bør være enkelt å importere RSA-nøkler fra HelseID inn i det kliniske fagsystemet. | Bør | Dette er i praksis et HelseID-krav, men KJ velger å peke på dette da det påvirker KJ-integrasjon. | - |
S.6 | Sikkerhet | Portal, API | | Det bør være enkelt å oppdatere RSA-nøkler fra HelseID i det kliniske fagsystemet. | Bør | Dette er i praksis et HelseID-krav, men KJ velger å peke på dette da det påvirker KJ-integrasjon. | - |
S.7 | Sikkerhet | Portal, API | | Ved SSO for portalintegrasjon, og ved API-integrasjon, må det kliniske fagsystemet sørge for at sluttbruker autentiserer seg med høyeste sikkerhetsnivå herunder: Buypass, Commfides eller BankID. | Må |
| Demomøte (Akseptansetest del 1) |
