Pasientens prøvesvar

Avtale om integrasjon av EPJ-system til nasjonal tjeneste

Saksnr Helsedirektoratet: 24/19648 Avtale ID NHN: 24/00727

Bilag 1

Kundens beskrivelse av oppdraget

Innhold

1 Innledning 3

2 Overordnet om Oppdraget 4

3 Krav til Funksjonalitet 5

4 Brukerhistorier for tilgangsbegrensninger til prøvesvar 26

5 Brukerhistorier for tilgang til prøvesvar 28

6 Brukerhistorie overføring fra EPJ til Pasientens prøvesvar 35

7 Krav til gjennomføring av oppdraget 36

0 Xxxxxxxxxx xxxx 00

1 Innledning

Dette bilaget (PDF-dokument) oppstiller Kundens krav til ytelsen. Kravene gjøres gjeldende for alle leveranser under avtalen.

Ytelsen defineres som leveranse av komplett sett av integrasjoner i henhold til Kundens beskrivelse av oppdraget, inkludert de tekniske og funksjonelle spesifikasjoner som er vedlagt Bilag 1.

Krav beskrevet i punkt 1A, 1B, 2,3 og 5, kan være løst med bruk av 3. parts leverandører for rekvirering (IHR), med egen rekvisisjonsløsning, eller en kombinasjon av disse.

Leverandører som KUN benytter 3. part rekvisisjonsløsning (IHR), og tilhørende IHR ivaretar både innhold og formidling av rekvisisjonen/henvisningen, samt løsning for eventuelle tilgangsbegrensninger i rekvisisjonsøyeblikket, beskriver dette for punktene 1A, 1B, 2,3 og 5. Det er egne krav definert for rekvisisjonsløsninger fra 3. part (IHR), utenfor denne avtalen.

1.1 Krav og kravtyper

1.1.1 Kundens krav

Nr.: Kravpunktets unike løpenummer

Beskrivelse: Tekst som beskriver kravet

Type krav: Se tabell nedenfor

Absolutte krav (A)

Kravet er viktig og MÅ tilfredsstilles. Kravet er å anse som et minimumskrav.

Ønskede krav (B)

Kravet BØR tilfredsstilles, men det er ikke et absolutt krav. Svar vil likevel ha

betydning for evaluering av tilbudet.

Info (I)

Ikke et direkte krav til leveransen, men leverandøren skal i sin

løsningsbeskrivelse gi utfyllende informasjon. Svar vil ha betydning for evaluering av tilbudet.

1.1.2 Leverandørens besvarelse

Leverandørens besvarelse av kravene i Bilag 1 legges inn i "SSA-O Bilag 2 - Leverandørens spesifikasjon av oppdraget" (Word dokument). Av hensyn til lesbarhet gjengis kravene fra Bilag 1 også i bilag 2. Videre besvarer Leverandøren med sitt innhold i bilagene 3,4 og 5 til SSA-O. I Bilag 2 bekrefter Leverandøren at disse bilagene er utfylt etter anvisning i bilagene (kun Ja/Nei).

Tilbys: I hvilken grad leverandøren kan tilfredsstille kravet (Ja, Nei, Delvis). For krav som besvares med Delvis, må det i løsningsbeskrivelsen særskilt utdypes hva som ikke kan tilfredsstilles. Blå skrift.

Løsningsbeskrivelse: Utfyllende informasjon om hvordan kravet tilfredsstilles. Blå skrift.

Der Leverandøren av plasshensyn ikke finner det hensiktsmessig å legge løsningsbeskrivelsen (Bilag 2) inn i kravtabellen, kan denne beskrives i blå skrift merket "Leverandørens svar:" under de utdypende kravbeskrivelsene i kapitel 3 i Bilag 2. I så fall skal det i kravtabellen gis referanse til hvor løsningsbeskrivelsen ligger, og det skal i løsningsbeskrivelsen klart fremkomme hvilket krav som utdypes.

Leverandøren er selv ansvarlig for å beskrive alle nødvendige løsningselementer for å få en komplett løsning, selv om ikke alle disse er kravsatt.

2 Overordnet om Oppdraget

2.1 Oppdraget

Pasientens prøvesvar er en ny nasjonal e-helseløsning og i dette oppdraget ønskes det å anskaffe integrasjon fra fastlegers EPJ til ny nasjonal tjeneste, Pasientens prøvesvar. EPJ vil ved integrasjon kunne ivareta å formidle formål og reservasjon, samt tilgangsbegrensninger i rekvisisjonsøyeblikket, samt få tilgang til alle prøvesvar på en pasient i Pasientens prøvesvar, både de en selv har rekvirert og fra andre rekvirenter (tjenstlig behov ligger til grunn).

Helse- og omsorgsdepartementet har vedtatt endringer i kjernejournalforskriften § 4, slik at forskriften åpner for lagring av laboratorie- og radiologisvar (prøvesvar). Forskriftendringene er blant annet en oppfølging av endringene i pasientjournalloven fra 2. juni 2023, jf. Prop.91 L (2022–2023) Endringer i pasientjournalloven m.m. (Pasientens prøvesvar i nasjonal kjernejournal) og Innst.406 L (2022–2023). Lovvedtaket endret forskriftshjemmelen knyttet til nasjonal kjernejournal i pasientjournalloven § 13. Endringen klargjorde at flere opplysningstyper kan inkluderes i nasjonal kjernejournal, bl.a. prøvesvar.

2.2 Om tjenesten Pasientens prøvesvar

Pasientens prøvesvar (PPS) skal gi helsepersonell trygg og sikker tilgang til alle typer laboratorie- og radiologisvar, uavhengig av hvem som har bestilt undersøkelsen og hvor undersøkelsen er utført. Pasienter og innbyggere får tilgang til den samme informasjonen via Helsenorge.

Helsepersonell og innbygger skal kunne sette eller endre tilgangsbegrensninger for prøvesvar ett sted for hele sektoren/alle system. Dette innebærer at helsepersonellet setter tilgangsbegrensninger i egne- eller tilknyttede fagsystemer (rekvisisjonsløsninger, EPJ, LIMS, kjernejournal portal etc.), mens innbygger setter sine tilgangsbegrensninger i Helsenorge.

Tillitsrammeverket er felles spilleregler for deling av helseopplysninger mellom nivåer og virksomheter. Dette skal appliseres fortløpende for tjenester i nasjonal kjernejournal i løpet 2024, deriblant Pasientens prøvesvar, pasienten journaldokumenter, kritisk info etc., samt pasientens måledata som ikke nødvendigvis vil havne under kjernejournalforskriften. Dette betyr for leverandørene at man ved å etablere tilgang til prøvesvar-API, har man en rimelig generisk løsning for tilgang til andre informasjonselementer i nasjonal kjernejournal, enten via KJ portal eller integrert med hvert enkelt API.

Kjernejournalforskriften beskriver at formålet med opplysningene skal være til helsehjelp, som betyr at

rekvirenten må kunne angi hvilket formål en rekvisisjon/henvisning har. I tillegg skal innbygger selv kunne reservere seg mot at prøvesvarene fra akkurat denne rekvisisjonen blir lagret i pasientens prøvesvar (dette i tillegg til reservasjonsmulighet angitt i Helsenorge, for å ha en nasjonal kjernejournal, eller hele prøvesvar tjenesten).

For begge disse tilfellene skal både formål og reservasjon kunne angis i rekvisisjonsmeldingen, samt i nytt API (Helsehjelp-API), for å sikre at kun relevante prøvesvar sendes og/eller lagres i Pasientens prøvesvar.

For å kunne sette tilgangsbegrensninger i forkant av at pasient tar en prøve som analyseres ved laboratoriet, eller henvises til en radiologisk virksomhet, er det behov for at rekvisisjonsløsninger er integrert med Personvern og tilgangsstyring (PTS-API).

Leverandører vil med en slik integrasjon ha forutsetninger for å kunne bidra til en bedre og mer sikker deling av helseopplysninger mellom helseaktører, samtidig som man ivaretar innbyggers innsynsrettigheter i tilgangen på egne opplysninger i Helsenorge. Pasientens prøvesvar er første bruker av PTS-API, og målet er å ta i bruk dette for andre nasjonale ehelse-løsninger.

3 Krav til Funksjonalitet

Beskrivelse av behovene er her avgrenset til fastlege-EPJ og egne/interne rekvisisjonsløsninger, samt relasjoner mellom fastlege-EPJ og eksterne IHR/rekvisisjonsløsninger.

3.1 Krav

Det er behov for at EPJ-leverandører realiserer støtte for å sikre fastleger og avtalespesialister tilgang til prøvesvar fra Pasientens prøvesvar i eget fagsystem (EPJ) og at de kan se, sette og endre tilgangsbegrensninger for prøvesvarene, for både helsepersonell og innbygger.

Kundens krav
Nr	Beskrivelse av krav	Dokumentasjons-krav	Type krav
Info1	Leverandøren bes avklare hvilke(t) EPJ-system som omfattes av oppdraget	Oppgi navn og aktuell versjon av EPJ	I
Info2	Leverandøren bes avklare forholdet mellom omfattet EPJ-system og rekvisisjonsløsning	Oppgi navn og aktuell versjon av rekvisisjonsløsning	I

Kundens krav
Nr	Beskrivelse av krav	Dokumentasjons-krav	Type krav
1A	Kunne angi/formidle om formålet med rekvisisjonen/henvisningen er til helsehjelp eller ikke (i både rekvisisjonsmeldingen og nytt Helsehjelp-API) Se utfyllende beskrivelse av kravet nedenfor (3.1.1) Se gjerne brukerhistorie i kap. 4 for utfyllende forklaring.	Leverandør må her beskrive hvordan de løser å formidle formål, herunder besvare hvordan kravene beskrevet i 3.1.1 blir løst.	B
1B	Alle rekvisisjonsmeldinger skal identifiseres med en globalt unik id (XxxxXxx.Xx) som en UUID (Universally/Globally Unique Identifier)	Leverandører må her bekrefte at rekvisisjonsID er en UUID, herunder besvare hvordan kravet i 3.1.1. og 3.1.2 blir løst	B
2	Kunne bistå innbygger med å reservere seg mot lagring av prøvesvar fra denne rekvisisjonen, i rekvisisjonsøyeblikket. Se utfyllende beskrivelse av kravet nedenfor (3.1.2) Se gjerne brukerhistorie i kap. 4 for utfyllende forklaring.	Leverandør må her beskrive hvordan de løser å formidle reservasjon, herunder besvare hvordan kravene beskrevet i 3.1.2 blir løst.	B

Kundens krav
Nr	Beskrivelse av krav	Dokumentasjons-krav	Type krav
3	Kunne angi/formidle NHN PPS som kopimottaker, i rekvisisjonsprosessen. Se utfyllende beskrivelse av kravet nedenfor (3.1.3) Se gjerne brukerhistorie i kap. 4 for utfyllende forklaring.	Leverandør må her beskrive hvordan de løser å formidle NHN PPS som kopimottaker, herunder besvare hvordan kravene beskrevet i 3.1.3 blir løst.	B
4	Kunne se, sette eller endre tilgangsbegrensninger med bruk av Personvern og tilgangsstyring (PTS- API) i eget EPJ. Se utfyllende beskrivelse av kravet nedenfor (3.1.4) Se brukerhistorie i kap. 4 for utfyllende forklaring.	Leverandør må her beskrive hvordan de løser å sette tilgangsbegrensninger i EPJ med bruk av PTS-api, herunder besvare hvordan kravene beskrevet i 3.1.4 blir løst.	A
53.1. 5	Kunne sette tilgangsbegrensninger med bruk av Personvern og tilgangsstyring (PTS-API) Se utfyllende beskrivelse av kravet nedenfor (3.1.5) Se brukerhistorie i kap. 4 for utfyllende forklaring.	Leverandør må her beskrive hvordan de løser å sette tilgangsbegrensninger rekvisisjonsprosessen med bruk av PTS-api, herunder besvare hvordan kravene beskrevet i 3.1.5 blir løst.	B
6	Kunne vise prøvesvar fra PPS i eget EPJ med bruk av prøvesvar-API. Se utfyllende beskrivelse av kravet nedenfor (3.1.6) Se brukerhistorie i kap. 5 for utfyllende forklaring.	Leverandør må her beskrive hvordan de løser å vise prøvesvar fra PPS i egen brukerflate i EPJ , herunder besvare hvordan kravene beskrevet i 3.1.6 blir løst.	A

Kundens krav
Nr	Beskrivelse av krav	Dokumentasjons-krav	Type krav
7	Ta i bruk HelseID og nasjonalt tillitsrammeverk ved integrasjon med PTS-API, Helsehjelp-API og Prøvesvar-API Se utfyllende beskrivelse av kravet nedenfor (3.1.7)	Leverandør må her beskrive hvordan de løser å ta i bruk HelseID og nasjonalt tillitsrammeverk ved integrasjon til de tre api'ene, herunder besvare hvordan kravene beskrevet i 3.1.7 blir løst.	A
8	Vise nylig prøvesvar tidlig i rekvisisjonsprosessen, i eget EPJ Se utfyllende beskrivelse av kravet nedenfor (3.1.8) Se brukerhistorie i kap. 6 for utfyllende forklaring.	Leverandør må her beskrive hvordan de løser å vise tidligere prøvesvar fra PPS ved rekvirering av ny undersøkelse/analyse, herunder besvare hvordan kravene beskrevet i 3.1.8 blir løst.	A
9	Overføre pasientnære prøvesvar fra fastlegens EPJ til Pasientens prøvesvar, som svarrapporter. Se utfyllende beskrivelse av kravet nedenfor (3.1.9) Se brukerhistorie i kap. 6 for utfyllende forklaring.	Leverandør må her beskrive hvordan de løser å overføre pasientnære prøvesvar til PPS som en svarrapport, herunder besvare hvordan kravene beskrevet i 3.1.9 blir løst.	B
10	Motta lenke til laboratoriets labhåndbok i mottatte svarrapporter, og kunne åpne lenke fra eget EPJ. Se utfyllende beskrivelse av kravet nedenfor (3.1.10) Se brukerhistorie i kap. 5 for utfyllende forklaring.	Leverandør bes her beskrive hvordan de tenker å løse å motta lenke til labhåndbok i en svarrapport, herunder besvare hvordan kravene beskrevet i 3.1.10 kan løses.	B

Kundens krav

Beskrivelse av krav

Dokumentasjons-krav

Type krav

Kunne vise vedlegg til svarrapporten fra Pasientens prøvesvar

Se utfyllende beskrivelse av kravet nedenfor (3.1.11)

Se brukerhistorie i kap. 5 for utfyllende forklaring.

Leverandør bes her beskrive hvordan de tenker å løse å ta imot vedlegg som følger med i en svarrapport, herunder besvare hvordan kravet beskrevet i 3.1.11 kan løses.

NHN viser til beskrivelse av api'ene og implementasjonsveileder på utviklerportal, herunder beskrivelse av tilgang til testmiljø og bruk av testdata.

• Se teknisk beskrivelse og informasjonsmodell av prøvesvar-api på: xxxxx://xxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxx/xxxxxxxxxx-xxxxxxxxxx/

• Se teknisk beskrivelse og informasjonsmodell av pts-api på: xxxxx://xxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxx/xxx/

• Se teknisk beskrivelse av HelseId på: xxxxx://xxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxx/xxxxxxx/

• Teknisk beskrivelse for helsehjelp-api vil snarlig bli tilgjengelig.

3.1.1 Utdyping krav nr. 1 behov for å angi FORMÅL med rekvisisjonen/henvisningen

Det er ikke hjemmel i kjernejournalforskriften for å lagre prøvesvar som er tatt til andre formål enn helsehjelp, for eksempel prøvesvar tatt til kontroll- og sanksjonsformål, i Pasientens prøvesvar. Eksempelvis skal heller ikke prøver relatert til rene livsstils-formål, omfattes av Pasientens prøvesvar.

Det er KUN prøvesvar som har angitt formål helsehjelp som lagres i Pasientens prøvesvar, og ansvaret for å avgjøre om formålet er til helsehjelp eller ikke, ligger hos rekvirenten. Rekvirenten må derfor ha løsninger tilgjengelig for å kunne angi dette så tidlig som mulig i bestillingsprosessen.

Det er behov for at

• EPJ-leverandører etablerer støtte for å kunne angi/formidle formål med bestillingen, i rekvisisjonsprosessen, og oppdaterer slik informasjon som kodet verdi i rekvisisjonsmeldingen.

• EPJ-leverandører må integreres med nytt NHN Helsehjelp-API, for å kunne angi formål helsehjelp, når dette er tilfelle, i rekvisisjonsprosessen.

Dette betyr at rekvirenten må kunne angi formålet med bestillingen, og ta et aktivt valg hvor formålet ikke er helsehjelp. Der hvor formålet ikke er til helsehjelp, skal tilhørende svarrapporter IKKE sendes fra LAB/RAD til Pasientens prøvesvar, og eventuelle feil innsendte svarrapport skal slettes i NHN sentral

løsning før de lagres.

Ved rekvisisjon med flere formål, anbefales det å opprette egne rekvisisjoner med og uten formål helsehjelp

Helsedirektoratet er i ferd med å beskrive hva som er å betrakte som formål helsehjelp, og har opprettet ett kodeverk 8312 med tilhørende formålskoder med beskrivelse av hver formålskode.

Det er planlagt 2 forskjellige løsninger for å kunne angi formål med rekvisisjonen, hvor begge løsninger skal innfris;

1. Formålskode skal inkluderes i Rekvisisjonsmeldingen og videreføres i svarrapporten

2. Formålskode skal overføres til nytt HELSEHJELP-API for denne rekvisisjonen/bestillingen

3.1.1.1 Oppdatere rekvisisjonsmelding med FORMÅL som en del av begrunnelsen

Helsedirektoratet har opprettet kodeverk OID=8312 med tilhørende formålskoder, som skal benyttes som en KODET VERDI under Aktuell problemstilling “PROB” i rekvisisjonsmeldingen. Dette er beskrevet i oppdatert HIS 80821:2014 – Rekvirering av medisinske tjenester v1.6, kap 5.1.31.

KRAV til formålskode i rekvisisjonsmeldinger

Rekvisisjonsløsninger må gi rekvirenten mulighet til å angi formålskoder fra OID=8312 under aktuell problemstilling i rekvisisjonsmeldingen, beskrevet i HIS 80821:2014. Alle rekvisisjonsmeldinger skal inneholde en kodeverdi som angir formålet med rekvisisjonsmeldingen/henvisningen.

• Rekvirenten skal enkelt kunne se og velge formålskoder med tilhørende beskrivelse fra OID=8312, for rekvirenten, i rekvisisjonsløsningen.

• Oppdatering av liste fra OID=8312 skal være dynamisk

• En formålskode fra OID=8312 skal alltid inkluderes i Rekvisisjonsmeldingen (og videreføres i svarrapporten av LAB/RAD)

• RekvisisjonsID (XxxxXxx.Xx) SKAL være en UUID og være tilgjengelig for rekvirenten ved eventuelle henvendelser.

• Rekvirent skal kunne endre formålskode for en allerede sendt rekvisisjonsmelding, og sende denne oppdateringen som en endring i rekvisisjons-meldingen (skal tas inn hos LAB/RAD hvis analysen/undersøkelsen ikke er påstartet), for samme Rekvisisjons-ID.

3.1.1.2 Angi FORMÅL med rekvisisjon/bestillingen til nytt HELSEHJELP-API

Selv om formålskoder skal angis i rekvisisjonsmeldingen, vil det ta lang tid før alle LIMS/RIS har implementert støtte for å videreføre formålskoden i svarrapporten(e), samt etablert rutiner for å kunne hindre innsending av “ikke formål helsehjelp” til Pasientens prøvesvar.

▪

xxxxx://xxx.xxxxxxx.xxxxxx.xx/xxxxxxxxx/xxxxxxxxxx/xxx/xxxxxx/xxxxxxxxxxxx/xxxxxxxxxxx/XXX%0000000

_2014%20Rekvirering%20av%20medisinske%20tjenester%20v1.6%20-oppdatert.pdf

Det er derfor etablert et nytt HELSEHJELP-API for å kunne angi direkte når formålet med rekvisisjonen/bestillingen er helsehjelp. HELSEHJELP-API krever ikke HelseID brukerpålogging, men HelseID maskin-til-maskin-pålogging, og vil kun inneholde informasjon om RekvisisjonsID (UUID, presisert i HIS 80821:2014 – Rekvirering av medisinske tjenester v1.6), eventuell Lab-ID (ServProvId) og tilhørende formålskode HHJ (helsehjelp). I tillegg informasjon om hvem som har sendt inn informasjonen og når. Beskrivelse av HELSEHJELP-API vil gjøres tilgjengelig på NHN Utviklerportal i løpet av april 2024.

Med HELSEHJELP-API, vil NHN kunne lagre innsendte svarrapporter knyttet til rekvisisjonens formål, kun hvor formålet er satt til helsehjelp. Tilsvarende vil regionale IKT-selskap selv kunne etablere egen message- broker med integrasjon med HELSEHJELP-API, og dermed selv kunne tillate innsending til Pasientens prøvesvar, kun hvor formål helsehjelp er angitt.

KRAV til formålskode i HELSEHJELP-API

Helsehjelp-API skal tas i bruk i rekvisisjonsprosessen, for å angi formålskode når rekvirent har angitt at formålet er helsehjelp.

• Etablert i hht beskrivelse av Helsehjelp-API på NHN Utviklerportal

• Rekvirenten skal enkelt kunne se og velge formålskoder med tilhørende beskrivelse fra OID=8312, for rekvirenten, i rekvisisjonsløsningen.

• Oppdatering av liste fra OID=8312 skal være dynamisk

• Formålskode fra OID=8312 skal alltid inkluderes i Helsehjelp-API for rekvisisjonen/henvisningen

• Gi rekvirenten mulighet til å endre formålskode for en allerede sendt rekvisisjons-melding, og sende denne oppdateringen som en ny formålskode til Helsehjelp-API, basert på samme RekvisisjonsID (XxxxXxx.Xx).

• RekvisisjonsID (XxxxXxx.Xx) SKAL være en UUID

• Det skal kun formidles informasjon om pasienter med fødselsnummer (FNR) eller D-nummer (DNR) i Helsehjelp-API

3.1.2 Utdypning krav 2 behov hos innbygger for å kunne reservere seg mot lagring

Det er behov for at

• EPJ-leverandører etablerer støtte for å kunne angi om pasienten reservere seg mot lagring, i rekvisisjonsprosessen, og oppdaterer slik informasjon i rekvisisjonsmeldingen.

• Kode for Reservasjon skal overføres til nytt HELSEHJELP-API for denne rekvisisjonen/bestillingen

Innbyggere har i dag mulighet til å reservere seg mot lagring i Helsenorge, hvor man kan reservere seg mot å ha en kjernejournal, eller reservere seg mot at kun alle prøvesvar lagres i kjernejournal.

Men innbygger har også rett til å kunne reservere2 seg mot at prøvesvarene fra denne rekvisisjonen/bestillingen lagres i Pasientens prøvesvar, og rekvirenten skal ha mulighet til å angi reservasjon som en del av rekvisisjonsmeldingen, og i Helsehjelp-API.

3.1.2.1 Oppdatere rekvisisjonsmelding med kode for Reservasjon mot lagring

KRAV til angivelse av reservasjon mot lagring i rekvisisjonsmelding

Bruk av Reservasjon (OID=3108) er allerede beskrevet i meldingsstandard for rekvirering og svarrapportering, og skal tas i bruk i interne rekvisisjonsløsninger, også for å angi om en bestilling ikke skal lagres i Pasientens prøvesvar.

• Rekvirenten skal enkelt kunne se og velge kodeverdi for reservasjon med tilhørende beskrivelser, i rekvisisjonsløsningen.

• Oppdatering av liste skal være dynamisk

• Innstillinger skal kunne være konfigurerbare med standardverdier f.eks. pr bruker og/eller organisasjon.

• RekvisisjonsID (XxxxXxx.Xx) er identifikatoren som knytter rekvisisjonen og svarrapporten sammen, og denne SKAL være UUID, og være tilgjengelig for rekvirenten ved eventuelle henvendelser.

• Kode for Reservasjon (OID=3108) skal alltid inkluderes i Rekvisisjonsmeldingen (og videreføres i svarrapporten av LAB/RAD)

• Rekvirent skal kunne endre kode for reservasjon for en allerede sendt rekvisisjonsmelding, og sende denne oppdateringen som en endring i rekvisisjons-meldingen (skal tas inn hos LAB/RAD hvis analysen/undersøkelsen ikke er påstartet), for samme Rekvisisjons-ID.

3.1.2.2 Angi kode for Reservasjon mot lagring i nytt HELSEHJELP-API

KRAV til angivelse av reservasjon mot lagring i Helsehjelp-API

• Rekvirenten skal enkelt kunne se og velge kodeverdi for reservasjon med tilhørende beskrivelser, i rekvisisjonsløsningen.

• Oppdatering av liste skal være dynamisk

• Innstillinger skal kunne være konfigurerbare med standardverdier f.eks. pr bruker og/eller organisasjon.

• RekvisisjonsID (XxxxXxx.Xx) er identifikatoren som knytter rekvisisjonen og svarrapporten sammen, og denne SKAL være UUID, og være tilgjengelig for rekvirenten ved eventuelle henvendelser.

• Kode fra OID=3108 skal alltid overføres til nytt HELSEHJELP-API for denne rekvisisjonen/bestillingen.

• Det skal kun formidles informasjon om pasienter med fødselsnummer (FNR) eller D-nummer (DNR) i Helsehjelp-API

▪

2 Se krav 2 og forbeholdet når det gjelder reservasjon. Det forventes snarlig avklaring som vil formidles leverandørene.

•

• Gi rekvirenten mulighet til å endre kode for reservasjon i en allerede sendt rekvisisjons-melding, og sende denne oppdateringen som en ny reservasjonskode til Helsehjelp-API, basert på samme RekvisisjonsID (XxxxXxx.Xx).

3.1.3 Utdypning krav 3 behov for å angi NHN PPS som kopimottaker i rekvisisjonen

I og med at det vil være mange systemer som er inkludert i prosessen for å sikre at kun prøvesvar med formål helsehjelp, og som ikke er reservert av pasienten selv, blir sendt til Pasientens prøvesvar, er det behov for flere løsninger for å oppnå det samme formålet. Og det vil være stor forskjell i tid når forskjellige aktører kan implementer støtte for hvert enkelt tiltak, f.eks LIMS/RIS-systemer.

Det er derfor beskrevet som et behov at NHN Pasientens prøvesvar legges inn som Copydest i rekvisisjonsmeldingen, alltid, men kun når formål er satt til helsehjelp (kodeverdi) HHJ ref (kap 3.1.1), og det IKKE finnes reservasjon mot lagring (kap 3.1.2).

"KRAV" til angivelse av NHN PPS som kopimottaker, i rekvisisjonsmelding

Dette er ikke et endelig krav, men en anbefaling om å benytte eksisterende funksjonalitet i rekvisisjonsmeldingen, som beskriver for LAB/RAD at kopimottaker skal motta en kopi av tilhørende svarrapporter.

• Hvis formål er HHJ og det ikke er satt Reservasjon, angi NHN-PPS som kopimottaker

• Det skal ikke sendes kopi av rekvisisjonen (som tidligere)

• Adresseinformasjon for NHN-PPS hentes fra NHN Adresseregister3

3.1.4 Utdypning krav 4 behov integrasjon med personvern og tilgangsstyring (PTS)

EPJ må kunne se/sette/endre innstillinger for personvern og tilgangsstyring (PTS) for prøvesvar (nekte, skjerme, sperre og utsatt innsyn) jf. Begrepsdefinisjoner fra Direktoratet for e-helse4, herunder klargjøre for bruk av HelseID5, NHN Selvbetjening6, tillitsrammeverket (attest) og DPOP7.

Det er behov for at

• EPJ-leverandørene må integrere med PTS-API8 for å ivareta tilgangsbegrensninger som fastlegen ønsker å se, sette, eller endre etter mottatt svarrapport, i eget EPJ.

▪

3 xxxxx://xxx.xxx.xx/xxxxxxxxx/xxxxxxxxxxxxxxxxx

xxxxx://xxx.xxxxxx.xx/xxxxxxxxxxxxxxx/xxxxxxxxxx/Xxxxxxxxxxxxxxxxxxx%00xxx%00xxxxxxxxxxxxxxxxxxx

%20mv.%20i%20behandlingsrettede%20helseregistre

5 xxxxx://xxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxx/xxxxxxx/

6 xxxxx://xxxxxxxxxxxxx.xxxx.xxxxxxx.xx/

7 xxxxx://xxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxx/xxxxxxx/xxxxxxxxxxxxx-xx-xxxxxxxxxxxx/xxxx- av-helseid/docs/dpop/dpop_no_nbmd/

8 xxxxx://xxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxx/xxx/

• Integrasjon med PTS-API fra intern rekvisisjonsløsning i eget fagsystem, for å kunne sette/endre innstillinger allerede i rekvireringsøyeblikket

• EPJ-leverandørene benytter kodeverk definert for formålet, etablert av Helsedirektoratet (pr nå OID=9603 og OID=7608), men her kan det komme endringer.

3.1.4.1 Integrasjon med PTS-API fra EPJ for nekting og utsatt innsyn

Helsepersonells behov for å kunne utsette eller nekte innbygger innsyn i prøvesvar av pasientsikkerhetshensyn etableres gjennom grensesnitt i helsepersonellets eget fagsystem, der integrasjon med PTS muliggjør at innbygger ikke får innsyn i prøvesvar via Xxxxxxxxxx.xx.

Enkelte prøvesvar vil ha en generell utsettelse før de gjøres tilgjengelig for innbygger i Helsenorge, mens andre vil gjøres tilgjengelig uten utsettelse, men først når prøvesvaret har status endelig. Retningslinjer for utsatt innsyn er i ferd med å bli vedtatt av Helsedirektoratet og gir føringer for hvilke prøvesvar (svarrapporter) som skal utsettes med 14/90 kalenderdager før de vises for innbyggere i Helsenorge, og hvilke som skal gjøres tilgjengelig uten utsettelse etc. "Retningslinjer for utsatt innsyn for innbyggere" vil gjøres tilgjengelig så snart dette vedtatt. Dokumentet vil være dynamisk og endres over tid, både når det gjelder inndeling av fagområder, og antall dagers utsettelse.

Ved integrasjon med PTS-API fra EPJ, vil helsepersonell kunne se, sette og endre tilgangsbegrensninger for et allerede mottatt prøvesvar, med en usikkerhet rundt hvorvidt innbygger allerede har rukket å se det samme prøvesvaret i Helsenorge. Men i og med at helsepersonell mottar prøvesvar med alle statuser, også foreløpige, vil helsepersonell kunne sette tilgangsbegrensninger før de er tilgjengelig for innbygger i Helsenorge.

Helsepersonell vil også kunne sperre eller skjerme for deling med annet helsepersonell, ved integrasjon mellom eget fagsystem og PTS-API. Informasjon om sperringen eller blokkeringen gjelder for alle prøvesvar, eller for en angitt tidsperiode, hvor sperring gjelder for alt helsepersonell og kan oppheves ved samtykke eller i en akuttsituasjon, mens blokkering gjelder alltid og kun for navngitt helsepersonell.

Både sperring og blokkering oppdateres som en del av innbyggers personvernsinnstilling i Helsenorge, hvor innbygger selv kan endre på disse innstillingene ved behov.

KRAV til integrasjon med PTS-API fra EPJ for allerede mottatte prøvesvar (svarrapporter)

• Integrasjon ihht beskrivelse på NHN Utviklerportal for PTS og HelseID

• Hvis det ikke er angitt noen tilgangsbegrensning i rekvisisjonsøyeblikket, vil innbygger kunne se egne prøvesvar i Helsenorge basert på eventuelle antall dager utsatt innsyn beskrevet i "Retningslinjer for utsatt innsyn for innbygger."

• Helsepersonell skal enkelt kunne se allerede satte tilgangsbegrensninger for innbygger, for hver svarrapport

• Helsepersonell skal enkelt kunne se og velge kodeverdi for nekting/utsatt innsyn med tilhørende beskrivelser (OID=9603), i eget EPJ.

• Helsepersonell skal enkelt kunne se og velge kodeverdi for sperring for helsepersonell med tilhørende beskrivelser (OID=7608), i eget EPJ.

• Oppdatering av begge lister skal være dynamisk

3.1.5 Utdypning krav 5 behov for integrasjon med PTS-API for tilgangsbegrensninger i

rekvisisjonsprosessen

Helsepersonellets primære behov er å sende alle prøvesvar alltid, og at det kun i enkelt-tilfeller at tilgangsbegrensninger skal angis i rekvisisjonsløsningen. Helsepersonells behov for å kunne sette tilgangsbegrensninger allerede i rekvisisjonsøyeblikket, skal løses ved å ta i bruk PTS-API i egen rekvisisjonsløsning, eller ved at tilknyttet IHR er integrert med PTS-API. Alle prøvesvar som blir tilknyttet samme rekvisisjonsmelding for samme pasient, vil da beholde samme tilgangsbegrensning ved utlevering av prøvesvar til innbygger i Helsenorge.

Med en integrasjon mellom egen rekvisisjonsløsning og PTS-API, kan grensesnitt med fordel utformes slik at helsepersonell kun endrer på standard tilgangsbegrensninger for hele rekvisisjonen, slik at personvern og pasientsikkerhet ivaretas (utsatt innsyn, nekting, sperring, skjerming etc).

Det er derfor ingen informasjon om tilgangsbegrensninger i verken rekvisisjonsmeldingen eller i svarrapporten, kun mellom rekvisisjonsløsning og PTS-API. Pasientens prøvesvar behandler relasjoner mellom rekvisisjonen og tilhørende svarrapporter, slik at de samme tilgangsbegrensninger vil gjelde for alle relaterte prøvesvar for innbygger, i Xxxxxxxxxx.xx.

Kodeverk som pr i dag benyttes er OID=9603 og OID=7608, og innholdet vil kunne endres over tid, til å inkludere andre kodeverdier definert av Helsedirektoratet.

I og med at Pasientens prøvesvar er en nasjonal løsning, og dermed må forholde seg til mange forskjellige rekvisisjonsløsninger nasjonalt, er ikke anbefaling om bruk av UUID tilstrekkelig for å sikre personvernet og pasientsikkerheten. For å sikre at informasjon om tilgangsbegrensninger alltid følger riktig rekvisisjonsmelding, stilles det krav til bruk av UUID som RekvisisjonsID, <ServReq><Id>, både for interne rekvisisjonsløsninger og hvis det er EPJ som angir RekvisisjonsID for IHR-løsninger, Fürst Forum, Dips Interactor, HP link etc. Dette er også presisert i Meldingsstandard for rekvisisjonsmelding HIS 80821:20149

3.1.5.1 Integrasjon med PTS-API for nekting og utsatt innsyn i rekvisisjonsprosessen

Pasientens prøvesvar vil automatisk utlevere prøvesvar til innbyggere basert på "Retningslinjer for utsatt innsyn for innbygger" når antall dager passeres. Antall dager og tilhørende fagområder antas å endres av Helsedirektoratet over tid, tilsvarende det våre naboland som Sverige og Danmark erfarte rundt nedjustering av tid før innbyggere fikk tilgang til egne prøvesvar.

Rekvirenten kan i tillegg endre på antall dager før innbygger får innsyn i Helsenorge, samt kunne nekte innsyn for innbygger totalt, basert på behov beskrevet i pasient- og brukerrettighetsloven (f.eks. fare for

▪

9 xxxxx://xxx.xxxxxx.xx/xxxxxxxxxxxxxxx/xxxxxxxxxx/xxxxxxxxxxxxxxxxxx-x0.0-xxxxxxxxxxx

liv og helse etc.).

KRAV til integrasjon med PTS-API for nekting og utsatt innsyn i rekvisisjonsprosessen

• Integrasjon ihht beskrivelse på NHN Utviklerportal for PTS og HelseID

• Hvis det ikke angis noen tilgangsbegrensning i rekvisisjonsøyeblikket, vil innbygger kunne se egne prøvesvar i Helsenorge basert på antall dager beskrevet i "Retningslinjer for utsatt innsyn for innbygger"

• Rekvirenten skal enkelt kunne se og velge kodeverdi for nekting/utsatt pasientinnsyn med tilhørende beskrivelser (OID=9603), i rekvisisjonsløsningen.

• Rekvirenten skal i rekvisisjonsøyeblikket kunne sette kodeverdi for å gi innsyn for innbygger uten utsettelse, kodeverdi for å utsette pasientinnsynet ytterligere, eller kodeverdi for å nekte innsyn totalt - inntil ny kode som ikke er nekting er satt.

• Oppdatering av listen skal være dynamisk

• Innstillinger skal kunne være konfigurerbare med standardverdier f.eks. pr bruker og/eller organisasjon.

• RekvisisjonsID (XxxxXxx.Xx) er identifikatoren som knytter rekvisisjonen og svarrapporten sammen, og denne SKAL være UUID, og være tilgjengelig for rekvirenten ved eventuelle henvendelser.

• Gi rekvirenten mulighet til å endre kode for tilgangsbegrensning i en allerede sendt rekvisisjons- melding, og sende denne oppdateringen som en ny kode for tilgangsbegrensning til PTS-API, basert på samme RekvisisjonsID (XxxxXxx.Xx).

• Det skal kun formidles informasjon om pasienter med fødselsnummer (FNR) eller D-nummer (DNR) i PTS-API

3.1.5.2 Integrasjon med PTS-API for sperring og skjerming, i rekvisisjonsprosessen

Rekvirenten skal kunne bistå innbygger med å sperre for deling med annet helsepersonell, ved å angi kode for dette i rekvisisjonsøyeblikket fra OID=7608. Informasjon om sperringen eller blokkeringen gjelder for alle prøvesvar, eller for en angitt tidsperiode, hvor sperring gjelder for alt helsepersonell og kan oppheves ved samtykke eller i en akuttsituasjon, mens blokkering gjelder alltid og kun for navngitt helsepersonell. Både sperring og blokkering vil oppdateres som en del av innbyggers personvernsinnstilling i Helsenorge, hvor innbygger selv kan endre på disse innstillingene ved behov.

KRAV til integrasjon med PTS-API for sperring og skjerming, i rekvisisjonsprosessen

• Integrasjon ihht beskrivelse på NHN Utviklerportal for PTS og HelseID

• Innbygger skal selv sette tilgangsbegrensninger i Helsenorge, og hvis det ikke angis noen tilgangsbegrensning i rekvisisjonsøyeblikket, vil prøvesvarene gjøres tilgjengelig for behandlende helsepersonell baset på innbyggers egne innstillinger.

• Rekvirenten skal i rekvisisjonsøyeblikket kunne bistå innbygger, ved å sette kodeverdi for sperring eller blokkering fra OID=7608, i PTS-API, som innbygger selv kan endre på i Helsenorge ved behov10 .

▪

10 xxxxx://xxx.xxx.xx/xxxxxxxxx/xxxxxxxxxx-xxxxxxxxx/xxxxx-xxxxxxxxxx-xx-

• En sperring og blokkering gjelder ikke kun for denne rekvisisjonen, men for alle svarrapporter eller svarrapporter for en angitt tidsperiode.

• En blokkering skal også inneholde HPR-nummer på blokkert helsepersonell11

o Hvis HPR-nummer er ukjent, oppgi navn på helsepersonell til Veiledning for Helsenorge på telefon 00 00 00 00 for bistand

• RekvisisjonsID (XxxxXxx.Xx) er identifikatoren som knytter rekvisisjonen og svarrapporten sammen, og denne SKAL være UUID, og være tilgjengelig for rekvirenten ved eventuelle henvendelser.

• Gi rekvirenten mulighet til å endre kode for sperring i en allerede sendt rekvisisjons-melding, som en oppdatering av personvernsinnstilling til PTS-API, basert på samme RekvisisjonsID (XxxxXxx.Xx) og pasient.

• Det skal kun formidles informasjon om pasienter med fødselsnummer (FNR) eller D-nummer (DNR) i PTS-API

3.1.6 Utdyping krav 6 behov for EPJ-integrasjon med prøvesvar API

EPJ må gi fastlegen tilgang til alle prøvesvar i Pasientens prøvesvar for en pasient, også de en selv ikke har rekvirert, samt sammenstilling i egen arbeidsflate, herunder klargjøre for bruk av HelseID, tillitsrammeverket (attest) og DPOP12.

Det er behov for at

• EPJ-leverandører integrerer med prøvesvar-API for å kunne vise alle prøvesvar tilhørende pasienten som er i behandling, i eget EPJ

• EPJ-leverandør skal kunne vise informasjon om pasienten har tilgang til prøvesvaret i Helsenorge, samt sette nye tilgangsbegrensninger, endre eller oppheve allerede satte innstillinger, forutsatt integrasjon med PTS-API (se 3.1.4).

• EPJ-leverandøren skal vise alle prøvesvar for sin pasient sammenstilt i egen arbeidsflate, eks i et Labark, for både egne rekvirerte og de man selv ikke har rekvirert

Merknad:

Det er pr i dag ikke støtte for bulk-nedlasting av svarrapporter fra Pasientens prøvesvar til EPJ, eks for alle i en fastlegeliste. Dette omfattes IKKE av denne anskaffelsen.

▪

informasjonssikkerhet/Personvernsinnstillinger_innbygger

11 xxxxx://xxx.xxx.xx/xxxxxxxxx/xxxxxxxxxx-xxxxxxxxx/xxxxx-xxxxxxxxxx-xx- informasjonssikkerhet/innsynsrett-for-innbygger

12 xxxxx://xxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxx/xxxxxxx/xxxxxxxxxxxxx-xx- eksempelkode/bruksmoenstre/dpop/

KRAV til integrasjon med PPS-API fra eget EPJ

• Integrasjon ihht beskrivelse på NHN Utviklerportal for Prøvesvar-API og HelseID

• For en og samme pasient skal EPJ kunne vise alle tilhørende svarrapporter, både egne rekvirerte og de en selv ikke har rekvirert, samt kunne sammenstille disse i egen arbeidsflate, eks Labark.

• Like analysekoder fra forskjellige laboratorium skal kunne trendes over tid for både internrekvirerte og eksternrekvirerte, med tydelig visning av eventuelle forskjeller i referanseområder, analysemetoder etc.

• Det skal være godt synlig for helsepersonell hvilke prøvesvar som er internrekvirert og hvilke som er eksternt rekvirert

Se beskrivelse av prøvesvar-api her: xxxxx://xxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxx/xxxxxxxxxx- proevesvar/ og NHN selvbetjeningsløsning for bruk i test, se xxxxx://xxxxxxxxxxxxx.xxxx.xxxxxxx.xx/

3.1.7 Utdyping krav 7 behov for å ta i bruk tillitsrammeverk, HelseID og DPOP

Det er behov for at

• EPJ-leverandører implementerer støtte for å ta i bruk tillitsrammeverket som en generisk løsning for "alle" nye API som tilgjengeliggjøres fra NHN, beskrevet på github

o NHN har beskrevet hvilke informasjonselementer som kravstilles pr API, og hvilke som kan sendes inn uten at informasjon benyttes til logging, autentisering og/eller autorisasjon, på NHN Utviklerportal

o For alle informasjonselementer tilknyttet Kjernejournal-forskriften (prøvesvar, kritisk info etc.), kreves samtykkegrunnlag fra pasienten, eventuelt med implisitt samtykke for fastlege etc. Se beskrivelse av " access-basis" under "Autorization" for Prøvesvar-API på NHN Utviklerportal.

• EPJ-leverandører etablerer HelseID-pålogging i eget EPJ – for å kunne tilby SSO ved konsum av helsedata fra Prøvesvar-API, alternativt ny Helse-ID pålogging ved konsum av helse-data fra Pasientens prøvesvar eller personvern og tilgangsstyring.

• EPJ-leverandør etablerer støtte for DPOP, med en gradvis innføring av krav til DPOP pr tjeneste. For PPS og PTS-API, vil ikke dette være et krav i tidlig 2024, men det vil komme som et krav, kanskje i løpet av 2024/2025. I en overgangsperiode vil samme endepunkt (API) støtte både med og uten DPOP.

Målet med tillitsrammeverket er at utviklingen og delingen av helseopplysninger skal gå raskere, riktigere, enhetlig med høy informasjonssikkerhet, godt personvern og fokus på pasientsikkerhet.

Tillitsrammeverket - Attest

Et av målene for 2024 er å applisere tillitsrammeverket for alle tjenestene i satsningen Digital samhandling. Det er oppnådd enighet i hvordan dette skal løses i sektoren, som nå prøves ut i Pasientens journaldokumenter som første tjeneste ut.

Erfaringene fra denne utprøvingen skal danne grunnlag for å dele helseopplysninger og for å dokumentere

og logge det tjenstlige behovet.

Målet er at man som leverandør gjør en jobb med å etablere, og så kan dette gjenbrukes på alle tjenester som deler helseopplysninger fremover. Implementeringen av dette bør ta høyde for at hver tjeneste har litt ulike egenskaper og reguleringer som bør kunne håndteres ved at man bygger en logikk for å parmeterstyre hvilke attributter som skal gjelde for Attesten knyttet til hver tjeneste. Det må tas høyde for årlige revisjoner i tillitsrammeverket.

KRAV til bruk av HelseID for å ta API i bruk

• Leverandører skal implementere bruk av HelseID brukerpålogging som beskrevet på NHN Utviklerportal, for Prøvesvar-API, og legge til rette for samme implementering for PTS-API, men foreløpig er det ikke krav til HelseID brukerpålogging for PTS-API

• Leverandører skal implementere bruk av HelseID maskin-til-maskin (M2M) som beskrevet på NHN Utviklerportal, for personvern- og tilgangsstyring (PTS-API) og Helsehjelp-API.

3.1.8 Utdypning krav 8 behov for å se tidligere prøvesvar i oppstart av rekvisisjonsprosessen

Det er behov for at leverandøren prioriterer;

• Integrasjon med prøvesvar-API fra eget EPJ som henter opp nylige prøvesvar for pasienten, i starten av bestillingsprosessen.

• Integrasjon med PTS-API fra eget EPJ som viser status på tilgangsbegrensninger for disse prøvesvarene.

• Integrasjon med PTS-API for egen rekvisisjonsløsning for å kunne sette/oppheve innstillinger allerede i rekvireringsøyeblikket.

• Samhandling mellom EPJ og tilknyttet rekvisisjonsløsning (IHR) for eventuelt å kunne overføre informasjon mellom EPJ og IHR, beskrevet som brukerhistorie i kapittel 5.2, men er ikke kravstilt i denne leveransen.

Helsepersonells behov for å kunne utsette eller nekte innbygger innsyn i prøvesvar allerede i rekvisisjonsøyeblikket, etableres gjennom grensesnitt i helsepersonellets eget rekvisisjonsløsning, eller tilknyttet løsning for IHR, integrert med PTS-API. Dette vil muliggjøre at helsepersonell kan begrense pasientinnsynet allerede FØR prøvesvaret foreligger for innbygger i Xxxxxxxxxx.xx

For dette behovet er det viktig å vite om det nylig er gjennomført relevante analyser/undersøkelser, som kan bidra til en bedre oppfølging av allerede gjennomførte analyser, eller kunne begrense nye analyser/undersøkelser.

KRAV til integrasjon med PPS-API og PTS-API fra eget EPJ, tidlig i rekvireringsprosessen

• Integrasjon ihht beskrivelse på NHN Utviklerportal for Prøvesvar-API og PTS-API

o Vise nylige prøvesvar fra prøvesvar-API sammen med interne prøvesvar, når rekvisisjonsprosessen starter

o Vise eventuelle tilgangsbegrensninger satt allerede er satt for nylige prøvesvar (svarrapporter)

3.1.9 Utdypning krav 9 behov for å overføre pasientnære målinger fra EPJ

3.1.9.1 Overføring av analyseresultater fra EPJ til Pasientens prøvesvar med bruk av svarrapport

Det er behov for at

• EPJ-leverandører utvikler støtte for å kunne sende inn pasientnære analyser til Pasientens prøvesvar, f.eks. HbA1c, som en standardisert Svarrapport v1.4, alternativt ta i bruk hyllevare utviklet av andre for å sende inn prøvesvar fra legekontorets lab, til Pasientens prøvesvar.

Målet er å kunne berike flere informasjonselementer med viktig informasjon som finnes lagret kun hos EPJ. Dette vil medføre at informasjon gjøres tilgjengelig for helsepersonell i en behandlingssituasjon, uten at behandlende helsepersonell trenger å etterlyse informasjon, og fastleger slipper å ettersende informasjon på fax, epost eller edi.

KRAV til innsending av svarrapporter fra lokal lab ved legekontoret

• Svarrapporter som sendes inn til Pasientens prøvesvar skal ha formål helsehjelp, og være i henhold til standard for svarrapportering, v1.4.

• Innbygger har ikke reservert13 seg mot lagring av prøvesvarene fra denne rekvisisjonen, i Pasientens prøvesvar

3.1.9.2 Overføring av måleresultater fra EPJ til Pasientens prøvesvar med bruk av FHIR- REST-API (kun til informasjon om fremtidig behov)

NHN planlegger å tilgjengeliggjøre REST-API for innsending av pasientnære målinger via REST-API, men dette er ikke en leveranse i denne anskaffelsen, og beskrivelse under er kun til informasjon.

Det er behov for at

• EPJ-leverandører må forberede for hvordan informasjon relatert til pasientnære prøver i EPJ, eks HbA1c, kan overføres fra strukturelt til Pasientens prøvesvar, basert på FHIR-REST-API.

• SOM helsepersonell ønsker jeg ikke å logge på med HelseID for hver overføring til Pasientens prøvesvar, påloggingsinformasjon må komme fra EPJ-innlogging med HelseID, og videreføres til PPS-REST-API-INN.

▪

13 Se krav 2 og forbeholdet når det gjelder reservasjon. Det forventes snarlig avklaring som vil formidles leverandørene.

3.1.10 Utdypning krav 10 behov for å motta lenke til labhåndbøker i EPJ

Det er behov for at

• EPJ-leverandør må kunne ta imot lenke til laboratoriets labhåndbok for alle analyser i en svarrapport som mottas i eget EPJ (uavhengig av Prøvesvar-API)

• EPJ-leverandør kan velge å vise ekstern lenke fra laboratorium

• EPJ-leverandører integrerer med prøvesvar-API for å kunne vise alle prøvesvar tilhørende pasienten som er i behandling. Leveransen handler om å kunne forberede for å kunne ta imot lenke til labhåndbok, som en del av integrasjon med Prøvesvar-API.

Det vises til Meldingsstandard for svarrapportering her: xxxxx://xxx.xxxxxx.xx/xxxxxxxxxxxxxxx/xxxxxxxxxx/xxxxxxxxxxxxxxxx-xx-xxxxxxxxxx-xxxxxxxxx- v1.4

Innbygger har behov for utdypende informasjon om ikke-kliniske opplysninger til mottatte prøvesvar i Helsenorge, i tillegg til forklaringstekster fra SML (store medisinske leksikon) som Helsenorge tilbyr. Rekvirenten kan også lese laboratoriets egen omtaler av selve analysen, metode og referanseområder etc., noe som kan bidra til en mere riktig tolkning av prøveresultater, bedre pasientbehandling og redusert tidsbruk for å finne relevant informasjon

Laboratorium gis muligheten til å legge inn lenke til egne brukerhåndbok-tekster ved sending av svarrapporter. Dette forutsetter at hvert laboratorium må ha separate (og stabile) URL’er for hver enkelt analyse som det ønskes å inkludere lenke til.

Helsedirektoratet mener dette vil kunne se slik ut i svarrapport v1.4, og det vil være frivillig hvordan denne opplysningen blir brukt i eget EPJ-system:

• Bruke feltet "Ytterligere spesifikasjon" (Spec) i klassen Undersøkelse (Investigation)

• 8213 etableres som kodeverk som sier at dette er et kodeverk med lenke til informasjon om analysen/undersøkelsen. Beskrivelse fra Hdir fra desember 2023 inneholder feil. Denne er korrekt;<Spec V="URL" S="2.16.578.1.12.4.1.1.8213" DN="xxxxx://xxx.xxxxxxxxxxxxxxx.xx/?xxxxxxxxxxxxxxxx&xxxxxxxxxxxx0xx00xxx0x0 76d"/>

• I og med at slike lenker vil følge selve XML også til fastlege som rekvirent, må EPJ- leverandører uavhengig av integrasjon med prøvesvar-API, klargjør for at helsepersonell får tilgang til denne url’en når den ligger med i svarrapporten.

I Pasientens prøvesvar inkluderes eventuelle lenker som en del av svarrapporten via prøvesvar- api, og gjøres synlig i f.eks. KJ portal. EPJ må kunne ta imot tilsvarende informasjon.

KRAV til mottak av lenke til labhåndbok

• EPJ må kunne ta imot eventuell lenke til labhåndbok fra prøvesvar-API

MERKNAD

I og med at Kunden ikke har endelig spesifikasjon for hvordan url til labhåndbok skal etableres, vil krav 10 være en opsjon for Oppdraget under denne avtalen. Beskrivelse under er kun til informasjon om mulig kommende behov for videreutvikling av Pasientens prøvesvar.

Kunden kan bestille løsning av vedlegg som et tilleggsoppdrag basert på oppgitte timepriser og bestemmelse i SSA-O Bilag 5 Pris og prisbestemmelser kapittel 2.2.

3.1.11 Utdyping krav 11 behov vise vedlegg i svarrapporten

I Pasientens prøvesvar vil det på sikt bli visning av vedlegg i alle fagområder, og Helsedirektoratet har varslet endring av meldingsstandard for svarrapportering at det bli obligatorisk å kunne ta imot vedlegg. Følgelig må EPJ ha støtte for å kunne lese inn vedlegg uavhengig av fagområde.

Vedlegg kan f.eks. en skisse av en tumor. Lenke vil følge med som et FHIR objekt (tillatte format jf., standard for svarrapportering) og kan håndteres ved mottak av svarrapporter i EPJ, herunder visning av vedlegget i EPJ.

MERKNAD

I og med at Kunden ikke har endelig spesifikasjon for hvordan vedlegg i svarrapporten skal etableres som en dokumentdatabase, og hvordan dette skal tilgangsstyres, vil krav 11 være en opsjon for Oppdraget under denne avtalen. Beskrivelse under er kun til informasjon om mulig kommende behov for videreutvikling av Pasientens prøvesvar.

Kunden kan bestille løsning av vedlegg som et tilleggsoppdrag basert på oppgitte timepriser og bestemmelse i SSA-O Bilag 5 Pris og prisbestemmelser kapittel 2.2.

3.2 Beskrivelse av Personvern og tilgangsstyring (PTS)

Beskrivelse av personvern og tilgangsstyring

I beskrivelsen av behov og løsninger nedenfor benyttes begreper innenfor personvern og tilgangsstyring definert av Helsedirektoratet (tidligere Direktoratet for e-helse):

Her er følgende begreper definert:

• Tilgangsbegrensning

• Nekting

• Skjerming

• Sperring

• Utsatt innsyn for innbygger

• Reservasjon

• Personverninnstillinger

Pasientens prøvesvar må ivareta lovpålagte krav innen personvern og pasientsikkerhet, jmf. pasient- og brukerrettighetsloven og personopplysningsloven.

a) Utsatt innsyn for pasienten i Helsenorge

Informasjon skal gis pasienten på en hensynsfull måte, og helsepersonell skal så langt som mulig sikre seg at mottakeren har forstått innholdet og betydningen av informasjonen. Det kan videre utledes av kravet i helsepersonelloven § 4 om at helsepersonell skal utføre sitt arbeid i samsvar med krav til faglig forsvarlighet og omsorgsfull hjelp, at helseopplysninger skal kommuniseres til pasienten på en hensynsfull måte.

Med utsatt innsyn menes en maskinell mekanisme som sørger for at prøvesvar for enkelte fagområder gjøres tilgjengelig for innbygger en viss tid (f.eks. 10 dager) etter at de er gjort tilgjengelig for helsepersonell. Hensikten er å kunne tilrettelegge for at behandler kan ta kontakt og gi veiledning i tråd med forsvarlig og omsorgsfull helsehjelp, før innbygger selv leser prøvesvarene. Andre prøvesvar fra andre fagområder kan tilgjengeliggjøres uten utsettelse. Det er Helsedirektoratet som driver prosessen med å anbefale hvilke fagområder som skal ha utsatt frist for innsyn eller ikke.

b) Nekting

Det vises til pasient- og brukerrettighetsloven § 5-1 andre ledd. Det gjøres oppmerksom på at Pasientens prøvesvar gir helsepersonell anledning til å se/sette/oppheve nekting og utsatt innsyn via kjernejournal portal, men da etter at et prøvesvar foreligger. For at en slik innstilling skal settes i forkant av en prøvetaking er en avhengig av at fastlegens rekvisisjons/henvisnings-løsning (EPJ/IHR) er integrert med Personvern og tilgangsstyring (PTS-API).

c) Skjerming

PTS vil på sikt kunne samle tilgangsbegrensninger der helsepersonell har skjermet tilgang for annet helsepersonell, dersom det er grunn til å tro at pasienten ønsker dette. Skjerming vil formidles til PTS gjennom API fra helsepersonellets EPJ/IHR eller KJ portal, på samme måte som nekting og utsatt innsyn.

Rekvisisjon/henvisning

Svarrapport

REK

EPJ KJ

Portal

HELSEHJELP-API

LAB/RAD

HELSEHJELP

PTS

PVK

KOPI

HN PVK

Pasientens prøvesvar

Helsenorge .no

PRØVESVAR - API

PTS - API

• FORMÅL

• RESERVASJON

• NEKTING

• UTSATT INNSYN

• SKJERMING

• SPERRING

• BLOKKERING

Helsepersonell

SAMMENSTILT LØSNINGSVALG FOR TILGANGSBEGRENSNINGER FOR PASIENTENS PRØVESVAR

• RESERVASJON

• SPERRING

• BLOKKERING

Innbygger

Figur 1 Enkel systemskisse

d) Bakgrunn for etablering av PTS

En innbygger skal kunne motsette seg deling av sine helseopplysninger ved å be om at deler av eller hele journalen sperres for utvalgt helsepersonell, en gruppe av helsepersonell eller virksomheter. Dagens praksis er at innbyggere selv må ta fysisk kontakt med hver av virksomhetene som deler for å motsette seg deling. Ingen av disse virksomhetene tilbyr selvbetjent funksjonalitet.

Ved innføring av nye nasjonale e-helseløsninger som deler helseopplysninger med formål om å yte, administrere eller kvalitetssikre helsehjelp, må innbyggers rett til å motsette seg slik deling sikres. Innbyggers rettigheter gjenspeiles blant annet i pasientjournalloven, kjernejournalforskriften, reseptformidlerforskriften og pasient- og brukerrettighetsloven.

I Akson SSD14 ble det pekt på at dette behovet må løses mest mulig likt på tvers av de nasjonale e- helseløsninger og at innstillingene burde håndteres i en fellestjeneste. På grunn av at hver nasjonal e- helseløsning er regulert spesifikt, kan det være en utfordring å lage felles sperreinnstillinger.

Det eksisterer i dag en nasjonal personverntjeneste for helse- og omsorgssektoren, hvor innbyggere, gjennom xxxxxxxxxx.xx, kan administrere helsepersonells tilgang til opplysninger i kjernejournal, reseptformidleren og enkelte nasjonale registre. Det overordnede behovet er å videreutvikle den eksisterende nasjonale personverntjenesten på Helsenorge (Personvernkomponenten – PVK), med funksjonalitet hvor innbyggere skal kunne få tilgang til en selvbetjent løsning for å administrere tilgangsbegrensninger (personverninnstillinger) på ett sted for alle de nasjonale e-helseløsningene og for deling av helseopplysninger mellom virksomhetene i helse- og omsorgsektoren.

▪

14 Sentralt styringsdokument Akson: Helhetlig samhandling og felles kommunal journalløsning - ehelse

Videreutviklingen skal i første omgang dekke behovene for tilgangsbegrensninger, herunder personverninnstillinger, i Pasientens prøvesvar. Helsepersonell eller innbygger skal kunne sette, endre og lese tilgangsbegrensninger ett sted, der helsepersonell setter tilgangsbegrensninger i eget relevant fagsystem, mens innbygger setter sine tilgangsbegrensninger på Xxxxxxxxxx.xx. Løsningsmønster for innsamling og tilgjengeliggjøring av tilgangsbegrensninger mellom NHN og virksomhetene i helse- og omsorgssektoren skal kunne gjenbrukes i andre nasjonale e-helseløsninger, som f.eks. pasientens journaldokumenter og pasientens måledata. «Ikke-digitale» innbyggere skal kunne få hjelp til å motsette seg deling uten å måtte benytte seg av Xxxxxxxxxx.xx.

Den nasjonale personverntjenesten er forankret og bestilt gjennom program for digital samhandling (PDS) (behov #16) og skal realiseres stegvis. Dette innebærer at den nasjonale personverntjenesten i første omgang kun skal etablere funksjonalitet som svarer til behovene for tilgangsbegrensninger i Pasientens prøvesvar.

Innbyggers behov for tilgangsbegrensninger vil ta utgangspunkt i etablert funksjonalitet og grensesnitt (PVK) for å sperre eller blokkere alt eller utvalgt helsepersonells tilgang til helseopplysninger, med prøvesvar som kategorien av helseopplysninger man i Pasientens prøvesvar knytter tilgangsbegrensningene til. Innbyggers tilgangsbegrensninger skal kunne tilgjengeliggjøres for virksomheter som har integrasjon med PTS.

Dette innebærer at PTS etableres som en tjeneste som ivaretar de funksjonelle behovene for ivaretagelse av pasientsikkerhet og innbyggers rett til å motsette seg deling, og formidler behovene som tilgangsbegrensninger mellom virksomhetene i helse- og omsorgssektoren, nasjonale e-helseløsninger og Xxxxxxxxxx.xx.

Videreutviklingen av en nasjonal personverntjeneste eller tilgangsstyringstjeneste, vil i første omgang innebære en etablering av PTS for en samling og tilgjengeliggjøring av tilgangsbegrensninger knyttet til Pasientens prøvesvar som en nasjonal e-helseløsning.

3.3 Bakgrunn for etablering av Pasientens prøvesvar (PPS)

Pasientens prøvesvar med tilgangsbegrensninger er en av flere byggeklosser som bygger opp under "Én innbygger – én journal", hvor behovet er å gjøre relevante helsedata tilgjengelig for helsepersonell som behandler pasienten, uavhengig av hvor behandlingen skjer, og hvor helsedataene kommer fra, og samtidig bidra til at innbyggere kan ta et større eierskap til egne helsedata.

Med Pasientens prøvesvar vil helsepersonell få tilgang til alle prøvesvar som er relevante for pasientbehandlingen, og slipper å etterlyse informasjon som er nødvendig, noe som kan bidra til raskere diagnostisering, bedre beslutningsgrunnlag, mere riktig behandlingsnivå og dermed bedre kvalitet i helsetjenestene. Prøvesvarene gjøres tilgjengelig for helsepersonell i kjernejournal, enten i kjernejournal portal, eller integrert som en del av verdikjeden i helsepersonellets eget EPJ.

Det er behov for at EPJ-leverandørene integrerer mot prøvesvar-api. På den måten vil fastlege få tilgang til å se alle svarrapporter i Pasientens prøvesvar i egen arbeidsflate, også de en selv ikke har rekvirert, samt kunne sammenstille disse i egen arbeidsflate, eks Labark. Det er viktig at helsepersonell lett kan

identifisere hvilke prøvesvar som er eksternt rekvirerte.

I og med at svarrapporter i Pasientens prøvesvar kommer fra mange forskjellige laboratorier med f.eks. egne analysemetoder og referanseområder, og disse tilgjengeliggjøres som FHIR-ressurser, er det viktig at eventuell sammenstilling og trending av like analysekoder over tid, tydelig viser variasjoner i referanseområde, analysemetode etc.

Andre behov er å sikre at det er helsepersonell ved angitt virksomhet som faktisk ber om tilgang til prøvesvar, og at slik informasjon er sikret med HelseID, beskrevet i NHN Utviklerportal. I og med at Pasientens prøvesvar er hjemlet under Kjernejournalforskriften, skal helsepersonell kunne åpne prøvesvar som er sperret av innbygger, ved å innhente samtykke fra pasienten selv, eller overstyre tilgangen i en akuttsituasjon. Beskrivelse av slike informasjonselementer fra tillitsrammeverket, finnes på NHN Utviklerportal.

4 Brukerhistorier for tilgangsbegrensninger til prøvesvar

Nedenfor redegjøres for brukerhistorier for både innbygger og helsepersonell. Se også beskrivelse av funksjonelt Beskrivelse av personvern og tilgangsstyring

4.1 Tilgangsbegrensninger satt av innbygger i Helsenorge

Som innbygger har jeg behov for å kunne motsette meg deling av helseopplysninger eller gjøre begrensninger i behandlingen av personopplysninger (personverninnstillinger) – personverninnstillinger satt av innbygger må kunne etterleves i helsepersonellets fagsystemer

a) Som innbygger har jeg behov for å kunne sette eller oppheve sperringer, herunder blokkeringer, mot at alle eller utvalgte helseopplysninger blir utlevert til alle eller utvalgt helsepersonell, slik at jeg kan ivareta mine rettigheter

i. Som innbygger har jeg behov for å få eller kunne innhente informasjon om hvilke konsekvenser sperringene jeg vurderer å sette eventuelt kan ha for helsehjelpen, slik at jeg kan ta en informert beslutning

ii. Som innbygger har jeg behov for å kunne sperre alle eller utvalgte helseopplysninger mot deling, slik at jeg kan ivareta mine rettigheter

iii. Som innbygger har jeg behov for å kunne sperre eller blokkere helsepersonells tilgang til helseopplysninger i en nasjonal e-helseløsning for en gitt tidsperiode, slik at jeg kan ivareta mine rettigheter.

iv. Som innbygger har jeg behov for å kunne sette eller oppheve blokkeringer mot at helseopplysninger i en nasjonal e-helseløsning gjøres tilgjengelig for utvalgt helsepersonell, slik at jeg kan ivareta mine rettigheter

b) Som innbygger har jeg rett til å reservere meg mot lagring av eller deling av enkelte eller alle helseopplysninger i nasjonale e-helseløsninger

4.2 Tilgangsbegrensninger satt av helsepersonell i eget EPJ

Som helsepersonell har jeg behov for å kunne se, sette, endre og oppheve tilgangsbegrensninger på prøvesvar slik at jeg kan ivareta liv og helse og gi hensynsfull helsehjelp

a) Som helsepersonell har jeg behov for å kunne bistå innbygger med å sperre eller blokkere tilgang til helseopplysninger for annet helsepersonell, og se hvilke tilgangsbegrensninger som er gjort

b) Som helsepersonell har jeg behov for å kunne skjerme helseopplysninger for deling mot annet helsepersonell, på vegne av pasienten, slik at jeg får ivaretatt pasientens rettigheter

c) Som helsepersonell har jeg behov for å kunne nekte innbygger innsyn når det er påtrengende nødvendig for å hindre fare for liv eller alvorlig helseskade for pasienten eller brukeren selv, eller innsyn er klart utilrådelig av hensyn til personer som står vedkommende nær

d) Som helsepersonell har jeg behov for å kunne utsette innbyggers innsyn i sine helseopplysninger, for å sørge for at informasjon om sykdom, behandling og oppfølging individuelt gis av helsepersonell

e) Som helsepersonell har jeg behov for å kunne endre eller oppheve allerede satte tilgangsbegrensninger for prøvesvar satt for en innbygger, slik at hen raskt kan få tilgang til egne prøvesvar i Helsenorge.

f) SOM helsepersonell ønsker jeg ikke å logge på med HelseID for hver innstilling som skal settes, påloggingsinformasjon må komme fra EPJ-innlogging med HelseID, og videreføres til PTS-API.

4.3 Tilgangsbegrensninger satt av helsepersonell i rekvisisjonsøyeblikket

Som helsepersonell har jeg behov for å kunne sette eller oppheve tilgangsbegrensninger allerede i rekvisisjonsøyeblikket, slik at jeg kan ivareta liv og helse og gi hensynsfull helsehjelp, i forkant av at prøveresultatene foreligger for innbygger i Helsenorge.

Alle prøvesvar med formål helsehjelp skal sendes til Pasientens prøvesvar, og det er kun i unntakstilfeller jeg skal måtte forholde meg til endring av standardverdier.

a) Som helsepersonell har jeg behov for å kunne bistå innbygger med å sperre eller blokkere tilgang til helseopplysninger for annet helsepersonell, allerede i rekvisisjonsøyeblikket, slik at jeg får ivaretatt pasientens rettigheter

b) Som helsepersonell har jeg behov for å kunne skjerme helseopplysninger for deling mot annet helsepersonell, allerede i rekvisisjonsøyeblikket, slik at jeg får ivaretatt pasientens rettigheter

c) Som helsepersonell har jeg behov for å kunne nekte innbygger innsyn allerede i rekvisisjonsøyeblikket, når jeg vet at det er påtrengende nødvendig for å hindre fare for liv eller alvorlig helseskade for pasienten eller brukeren selv, eller innsyn er klart utilrådelig av hensyn til personer som står vedkommende nær

d) Som helsepersonell har jeg behov for å kunne utsette innbyggers innsyn i sine helseopplysninger allerede i rekvisisjonsøyeblikket, for å sørge for at informasjon om sykdom, behandling og

oppfølging individuelt gis av helsepersonell før prøvesvaret er tilgjengelig for innbygger i Helsenorge.

e) Som helsepersonell har jeg behov for å kunne endre eller oppheve allerede satte tilgangsbegrensninger for prøvesvar med en systemgenerert utsettelse for innbygger, allerede i rekvisisjonsøyeblikket, slik at innbygger raskt kan få tilgang til egne prøvesvar i Helsenorge.

f) Som helsepersonell har jeg behov for å kunne imøtekomme innbygger som har gode argumenter for å motsette seg behandling av kommende prøvesvar i behandlingsrettet helseregister, ved å angi Reservasjon i rekvisisjonsmeldingen, slik at kommende svarrapporter ikke lagres i Pasientens prøvesvar.

g) Som helsepersonell har jeg behov for å kunne angi formålet med bestillingen, (helsehjelp, kontroll- og sanksjonsformål etc.). Dette for å sikre at LAB/RAD ikke sender inn svarrapporter som ikke har formål helsehjelp.

h) Som helsepersonell har jeg behov for å være tygg på at innstillinger satt i rekvisisjonsøyeblikket for akkurat denne unike rekvisisjonsmeldingen, medfører at innsendte svarrapport(er) fra LAB/RAD til pasientens prøvesvar, knyttes til akkurat denne rekvisisjonen, slik at personvern og pasientsikkerhet kan ivaretas.

i) Som helsepersonell ønsker jeg ikke å logge på med HelseID for hver innstilling som skal settes i rekvisisjonsløsning, påloggingsinformasjon må komme fra EPJ-innlogging med HelseID, og videreføres til rekvisisjons- henvisnings- eller bestillingsløsningene.

Xxxxxxxx

• Xxxxxxx pasient- og brukerrettighetslovens §5 og §3.4

• Ivareta KJ forskriftens krav om å kun lagre prøvesvar med formål helsehjelp, hvor Helsedirektoratet er i ferd med å etablere et nasjonalt kodeverk med tilhørende formålskoder, som rekvisisjonsløsningen må ha et forhold til.

• Tilgangsbegrensning satt i rekvisisjonsøyeblikket er basert på nasjonal unik RekvisisjonsID, UUID (og/eller tjenesteyters id) for rekvisisjonsmelding, og arves av alle svarrapporter med samme Rekvisisjons-ID.

• Tilgangsbegrensning for mottatt prøvesvar gjelder for svarrapportens ID og alle tilhørende analyser/undersøkelser, og eventuelle endringer/kanselleringer av svarrapport.

• Rekvirering av medisinske tjenester beskriver <Reservation DN="Tillatelse" (eller "Reservasjon") S="2.16.578.1.12.4.1.1.3108" V="T" (eller "R") />

5 Brukerhistorier for tilgang til prøvesvar

5.1 Tilgang til- og vise prøvesvar i eget EPJ

Se også beskrivelse av funksjonelt Utdyping krav 6 behov for EPJ-integrasjon med prøvesvar API

Som helsepersonell har jeg behov for at labarket tydelig viser endrede- og nye prøvesvar slik at jeg raskt får oversikt og blir oppdatert på hva som er endret/nytt på mine pasienter

• Når jeg som behandler går inn i labarket (eller annen prøvesvars-visning) på et senere tidspunkt trenger jeg å lett kunne se hvilke prøvesvar som er nye og hvilke tidligere (nedlastede) prøvesvar som er endret siden siste oppslag.

• Visningen er fra før meget informasjonstett og jeg har derfor behov for at dette ikke løses ved å introdusere mer tekst, men synliggjøre gjennom grep i visningen. Det er spesielt viktig at dette IKKE løses ved å sende varsler til innbokser eller gjennom pop-up funksjonalitet.

• SOM helsepersonell ønsker jeg ikke å logge på med HelseID for hvert kall som gjøres til pasientens prøvesvar, påloggingsinformasjon må komme fra EPJ-innlogging med HelseID, og videreføres til PPS-API (og eventuelt PTS-API).

5.2 Se nylige prøvesvar i rekvireringsprosessen

Som helsepersonell har jeg behov for å se pasientens tidligere prøvesvar når jeg starter rekvireringsprosessen, enten det er lokal rekvireringsløsning, eller tilknyttet IHR.

For å rekvirere benytter jeg vanligvis en IHR modul som Dips Interactor eller Fürst Forum etc. Jeg har da stor nytte av å se pasientens tidligere prøvesvar tidlig i rekvireringsprosessen. Jeg har også nytte av å kunne se historikk en viss tid bakover i tid.

I det jeg åpner rekvireringsmodulen fra pasientens journal i eget EPJ, ønsker jeg en presentasjon av alle prøver som nylig er tatt på pasienten. Det bør minimum være en visning av de siste prøvesvar og dato for disse, alternativt vise hele eller deler av pasientens historikk fra Pasientens prøvesvar i det man starter rekvireringsprosessen?

Jeg vil ønske å markere aktuelle prøver for ny rekvisisjon.

Hvis jeg søker opp og rekvirer en prøvepakke eller enkeltprøver ønsker jeg en prioriter visning av svarhistorikken på disse prøvene.

SOM helsepersonell ønsker jeg ikke å logge på med HelseID for hver hendelse til Pasientens prøvesvar eller personvern- og tilgangsstyring, påloggingsinformasjon må komme fra EPJ-innlogging med HelseID, og videreføres til PPS-API og PTS-API.

Ut fra dette kan jeg bedre vurdere nytten av å bestille en gitt prøve eller komplementerende prøver.

Tilleggsfunksjonalitet som vil være ønskelig i IHR løsningen, eller hvis historikken vises tilknyttet eget EPJ : Historikken kan brukes til å gi meg råd om adekvat prøvebestilling, ressursbesparende tips mtp hyppighet eller kostbarhet.

Dette vil kunne gi en stor økonomisk samfunnsgevinst.

(Generelt bør vi vurdere å fokusere utvikling av nødvendig funksjonalitet rundt rekvireringsprosessen i IHR

løsningen for å redusere ressursbruk og øke bredding av ny funksjonalitet?)

5.3 Tilgang til referanseverdier for alle analyser

Som helsepersonell har jeg behov for å se referanseverdier når jeg ser på et prøvesvar

Behovet for kontinuitet i rekken av svar på samme prøve er svært viktig. Jeg har mindre behov for å se

små variasjoner i referanseverdier basert på forskjell i det enkelte laboratorium sitt analyseutstyr.

Tanker om løsningsvalg

• Analyser som har samme nasjonale kodeverdi må presenteres på samme linje selv om det er ulike laboratorier og evt referanseverdier

• Referanseverdier i trendvisningen kan markeres grafisk i visningen

• Referanseverdier i tabellvisning bør bestå av en kolonne som viser referanseverdi basert på fortrukket laboratorium. Referanseverdien på den enkelte prøve kan også fremkomme ved tooltip på det enkelte svar i tabellen.

• Man kan så velge tilgjengeliggjøre hvert enkelt laboratorium sine referanseverdier, analysemetoder og lenke til labhåndbok som tooltip.

5.4 Tilgang til- og visning av vedlegg til prøvesvar

MERKNAD: Dette behovet prioriteres ikke i Pasientens prøvesvar nå, og beskrivelsen under er kun til informasjon om eventuelle kommende behov, men omfattes IKKE av denne anskaffelsen.

Se også beskrivelse av funksjonelt Utdyping krav 11 behov vise vedlegg

Som helsepersonell har jeg enkelte ganger behov for å kunne åpne vedlegg når jeg ser på prøvesvar

Dette er det sjelden behov for og det er derfor ikke ønskelig at informasjon om at det finnes et vedlegg tar stor plass i visningen av prøvesvar.

Innspill til løsningsvalg

• Vedlegg bør signaliseres gjennom et symbol eller annet visningsteknisk grep.

Tilleggskommentar:

Vi ønsker spesifikt at det ikke skal være et krav om å åpne vedlegget for å se prøvesvaret. Helsedirektoratet har varslet endring standarden slik at alle fagområder kan ha vedlegg, og EPJ må kunne motta disse.

5.5 Lenke til lab/rad sin labhåndbok

Se også beskrivelse av funksjonelt Utdypning krav 10 behov for å motta lenke til labhåndbøker – som også omhandler laboratoriets mulighet til å inkludere lenke til sin labhåndbok i eksisterende svarrapport, i løpet av 2024.

Som helsepersonell kan jeg ha behov for å slå opp i labhåndboken til det laboratoriet som blodprøven er analysert ved, eller radiologi-virksomheten undersøkelsen er gjennomført hos, når jeg ser på et prøvesvar.

En visning av lenke til laboratoriehåndboken kan ikke ta plass i visningen av prøvesvar. Det er allerede en svært informasjonstett informasjonsflate som ikke må fylles med unødvendig tekst eller symbolikk.

Tanker om løsningsvalg

• Man kan tilgjengeliggjøre lenke til labhåndbok som tooltip/høyreklikk, symbol eller annet visningsteknisk grep.

Generelt om tooltip funksjoner man kan ønske:

• Labhåndbok

• Referanseverdier for spesifikke lab

• Kommentar til prøven

• Se rekvirentinformasjon

5.6 Tilgjengeliggjøre alle prøvesvar for min fastlegeliste – primærbruk

Som helsepersonell har jeg behov for å ha alle prøvesvar på fastlegelistens pasienter tilgjengelig også utenfor den direkte konsultasjonen med pasienten. Som fastlege har jeg utredning og behandlingsansvar for en tilmeldt gruppe av pasienter og har behov for å kunne utføre søk for å finne risikopasienter og ta ut rapporter på pasienter som trenger ekstra/fokusert oppfølging eller tjenester som vaksinering.

Dersom det oppstår negative effekter av et behandlingstiltak (legemiddel) må fastlegen kunne utføre kombinasjonssøk på legemidler og prøvesvar som er relevante for å finne pasienter som må følges opp. Disse to datatypene er essensielle for denne typen søk. Spesielt dersom man ønsker å finne marginale pasienter er prøvesvar en essensiell parameter for å finne disse.

a) Som helsepersonell har jeg behov for å ha alle prøvesvar på fastlegelistens pasienter tilgjengelig også utenfor den direkte konsultasjonen med pasienten.

Som fastlege har jeg utredning og behandlingsansvar for en tilmeldt gruppe av pasienter og har behov

for å kunne utføre søk for å finne risikopasienter og ta ut rapporter på pasienter som trenger ekstra/fokusert oppfølging eller tjenester som vaksinering.

MERKNAD Det er ikke prioritert å levere løsning for nattlig batch-overføring fra Pasientens prøvesvar til fastlegens EPJ for sine listepasienter i 2024. All eventuell overføring av prøvesvar til eget EPJ skjer ved autentisering fra innlogget bruker. NHN vil vurdere behovet videre, men en eventuell batch-overføring vil ikke omfattes av denne anskaffelsen.

b) Som helsepersonell har jeg behov for at EPJ på en tydelig måte viser at et prøvesvar er eksternt rekvirert.

Det må sikres at dette også er tydelig for tilsynsmyndighet gjennom logg eller løpende journal som kan oversendes ved eventuelt begjæring om utlevering av journal.

Merknader:

Det må reflekteres i løpende journal og/eller logg som følger med ved utskrift av journal

Det må være et grunnleggende prinsipp at rekvirent fremdeles skal være ansvarlig for oppfølging av patologiske prøver. Helsepersonell som lagrer informasjon i EPJ, er selv dataansvarlig for lagret informasjon.

c) Som helsepersonell har jeg behov for å ha prøvesvar tilgjengelig for å kunne gjøre uttrekk av risikogrupper i min pasientpopulasjon.

De 3 viktigste er dataelementene vi har for å gjøre uttrekk er diagnose, legemidler og prøvesvar.

Diagnosesystemet er svært upresist. Legemidler og prøvesvar er essensielle dataelementer for å kunne spisse uttrekkene til en noenlunde god kvalitet.

Eks:

• Risikogruppe for pandemi/sesongvaksinering.

• Risikogruppe basert på bruk av et legemiddel.

• Risikogruppe basert på sammenstilte parameter (legemiddel, blodprøve og diagnose)

Eksempel:

Nyresvikt grad 3 eller dårligere defineres kun av GFR

Løsning:

• Kunne gjøre et søk på gitte kriterier

MERKNAD Det er ikke prioritert å levere løsning for nattlig batch-overføring fra Pasientens prøvesvar til

fastlegens EPJ for sine listepasienter i 2024. All eventuell overføring av prøvesvar til eget EPJ skjer ved autentisering fra innlogget bruker. NHN vil vurdere behovet videre, men en eventuell batch-overføring vil ikke omfattes av denne anskaffelsen.

5.7 Tilgjengeliggjøre alle prøvesvar – sekundærbruk

Som helsepersonell er det behov for å lage praksisprofiler for å forbedre kvaliteten på legekontoret. Analysedata er også viktig for forskning.

1.Som helsepersonell har jeg behov for å lage praksisprofiler for å for bedre kvaliteten på legekontoret.

Overordnet Brukerhistorie Sekundærbruk:

• Analysedata er også viktig for forskning.

Brukerhistorie Praksisprofiler

EPJ og/eller 0.xxxxx leverandører har løsninger for å trekke ut data til bruk i fremstilling av praksisprofiler for å utføre kvalitetsarbeid. Alle data må være tilgjengelig for løsningen.

Nyttescenarioer:

EPJ og/eller 0.xxxxx leverandører har løsninger for å produsere uttrekk av arbeidslister. Dette kan være en gruppe pasienter som trenger spesiell oppføling eller risikopopulasjoner definert ut fra ulike forhold. For eksempel forskrivningspraksis – søvnmangel, antibiotika, A- og B-preparat forskrivning, sykemeldingspraksis, behandlingspraksis kronisk sykdom mm.

Pasientens prøvesvar relevante eksempler:

Risikoprofiler utarbeides på bakgrunn av blant annet diagnose, prøvesvar og legemiddelbruk – dersom man mangler prøvesvar mangler man en vesentlig kilde for risikoanalysen.

Merknader:

Rapportering til bruk i kvalitetsoppfølging av egen praksis blir vel strengt tatt primærbruk av data? Det er kun behandler som har tilgang til data og bruker dem for å analysere egen praksis for å justere behandling av egne pasienter.

Data vil ikke være anonymisert for behandler.

MERKNAD: Det er ikke prioritert å levere løsning for nattlig batch-overføring fra Pasientens prøvesvar til fastlegens EPJ for sine listepasienter i 2024. All eventuell overføring av prøvesvar til eget EPJ skjer ved autentisering fra innlogget bruker. NHN vil vurdere behovet videre, men en eventuell batch-overføring vil ikke omfattes av denne anskaffelsen.

1. Som helsepersonell har jeg i økende grad behov for kontekstavhengig visning av prøvesvar slik at jeg får god beslutningsstøtte

Dette krever oppdaterte strukturerte data som EPJ leverandør kan presentere i andre kontekster enn labarket.

Brukereksempler

• Nyeste blodprøve (ofte GFR) verdi er tilgjengelig ved fornyelse av resepter – kan brukes til å utløse varsler

• Nyeste blodprøve (GFR) er tilgjengelig og vil da kunne fylles automatisk inn ved rekvirering av MR bilder

• Nyeste blodprøve (GFR) er tilgjengelig ved forskrivning av legemidler og interaksjonsvurdering og vil da kunne gi varsler og råd.

Merknader

Tilgjengelighet av blodprøver i vekslingen mellom ulike behandlere gir mer effektiv oppfølging og bedre pasientsikkerhet

Dette kan gi oss mulighet for å utvikle systematikk for varsler basert på trendutvikling og om anbefalt/unødvendig rekvirering.

Nedlasting av oppdaterte data kan selvfølgelig sikkert løses ved å hente dem i bakgrunnen ved oppslag i journal uten at man aktivt slår opp labarket.

2. Som helsepersonell trenger jeg at EPJ holder oversikt over informasjon som inneholder genetiske opplysninger da dette er informasjon som skal behandles særskilt ved utlevering av informasjon til f.eks. forsikringsselskap.

Jeg trenger et system for å merke denne typen data og lett gjenfinne den og skille den ut fra annen journalinformasjon ved behov. Et eksempel på gjenbruk er at genetiske prøver ikke skal utgis til forsikring.

MERKNAD

Helsedirektoratet har informert om at Ny meldingsprofil med meldingstype MGEN trolig blir publisert i september 2024 – ref. høring fra 14.12.2023

3. Som helsepersonell har jeg behov for at labarket har funksjoner for å håndtere visningen i situasjoner der det er tatt mange prøvesett over korte perioder som for eksempel under en sykehusinnleggelse eller en eller et fåtall prøver er tatt gjentatte ganger med stor hyppighet som for eksempel INR.

Visningen av disse er i mange situasjoner uhensiktsmessig og tar for mye plass i visningsfeltet.

I denne situasjonen må jeg kunne velge å skjule/kollabere prøvesett for en tidsperiode eller skjule / kollabere en gitt analyse (INR)

4. Som helsepersonell ønsker jeg at data i EPJ skal være tilgjengelig for forskning uten at det oppleves som en belastning og uten merarbeid ved registering og deling av data.

Brukerhistorie Forskning

Som lege ønsker jeg at data i EPJ skal være tilgjengelig for forskning uten at det oppleves som en belastning og uten merarbeid ved registering og deling av data. Deling av data skal følge lovverket. Både legekontor, behandler og pasient skal være anonymisert.

Dette krever strukturerte data. Dersom dette skal være mulig å hente fra våre EPJ må Pasientens prøvesvar være tilgjengelig når disse søkene utføres (med dagens regelverk? Vi inngår avtale om uttrekk av data fra EPJ).

Deling av data skal følge lovverket. Både legekontor, behandler og pasient skal være anonymisert.

Dagens situasjon:

Praksisnett: (UIB) Nasjonal satsing finansiert av Norsk Forskningsråd.

Gruppedata kan hentes/oppdateres når rapporter skal kjøres. Tidsfaktor ikke kritisk. Skjer gjerne utenfor arbeidstid.

Anonymisert pasient, lege og legekontor

Data fra 90 legekontor. 500 leger. 500 000 pasienter.

Henter i dag data fra EPJ. Hente noen data fra sentrale verktøy/registre eks SFM?

Praksisnett henter i dag data automatisk fra EPJ via «snowboks», lege bruker ikke tid på dette.

Snow Health Appliance Box er en liten datamaskin som installeres lokalt på fastlegens kontor og som automatisk trekker ut data fra pasientjournalen. Snow-boksen kobles til fastlegepraksisens server og henter data i henhold til en avtalt variabel-liste hver natt. Alle data som blir lagret på boksen lokalt er pseudonymisert, både pasient- og legeinformasjon. Aggregerte data blir overført til PraksisNett og inngår i en database som vil beskrive praksis- og pasientgrunnlaget i nettverket og danne grunnlag for planlegging av studier.

6 Brukerhistorie overføring fra EPJ til Pasientens prøvesvar

6.1 Overføre prøvesvar fra EPJ til Pasientens prøvesvar (PPS) som svarrapport

Som fastlege gjennomføres mange analyser hvor analyseresultat kun lagres i eget EPJ, og som helsepersonell har jeg behov for å bidra med verdifull informasjon til Pasientens prøvesvar, som også gradvis vil tilfredsstille kommende krav til meldeplikt også for pasientnære analyser.

• Prøveresultater fra vårt eget laboratorium ved fastlegekontoret, for eksempel HbA1c langtidsblodsukker, registreres i dag kun lokalt i eget EPJ, og vi ønsker at slike pasientnære prøvesvar sendes til Pasientens prøvesvar

• Alle analyseresultater som kategoriseres som prøvesvar til formål helsehjelp, skal kunne sendes til Pasientens prøvesvar som en standardisert svarrapport v1.4, tilsvarende som andre legekontor som er med i utprøving av Pasientens prøvesvar som produsent, hvor lokal LIMS rekvirerer til seg selv og svarrapport sendes tilbake til eget EPJ, hvor pasienten prøvesvar er satt som kopimottaker.

6.2 Overføre prøvesvar fra EPJ til Pasientens prøvesvar (PPS) via REST-API (til informasjon)

MERKNAD: NHN planlegger å tilgjengeliggjøre REST-API for innsending av pasientnære målinger via REST- API, men dette er ikke en prioritert leveranse i denne anskaffelsen, og beskrivelse under er kun til informasjon.

• Alternativt skal samme analyseresultat kunne pushes fortløpende til Pasientens prøvesvar med dedikert prøvesvar-rest-API

• Som helsepersonell ønsker jeg ikke å logge på med HelseID for hver overføring til Pasientens prøvesvar, påloggingsinformasjon må komme fra EPJ-innlogging med HelseID, og videreføres til PPS-REST-API-INN.

• Som fastlege gjennomføres mange analyser hvor analyseresultater kun lagres i eget EPJ, og som både legevakt og spesialisthelsetjenesten har behov for å vite om, eks målinger fra EKG, blodtrykk etc., i sin vurdering av henvist/mottatt pasient. Slike opplysninger må komme annet helsepersonell til gode, via strukturert overføring til pasientens måledata FHIR-api.

• Målinger ved fastlegekontoret registreres i dag kun lokalt i eget EPJ, og vi ønsker at slike måleresultater overføres som strukturerte måleverdier til pasientens måledata

• Som helsepersonell ønsker jeg å kategorisere hvilke måledata som skal overføres strukturert til Pasientens prøvesvar, og hvor ofte slike data skal overføres.

• På samme metode som måledata i dag overføres fra Digital hjemme-oppfølging (DHO) til pasientens måledata, skal utvalgte måledata pushes fortløpende til pasientens måledata fra eget EPJ med bruk av tilsvarende FHIR-API.

7 Krav til gjennomføring av oppdraget

7.1 Krav

Kundens krav

Nr.

Beskrivelse

Krav til dokumentasjon

Type krav

7.1.1

Leverandøren bekreftet å ha utfylt SSA-O

Bilag 3 Prosjekt- og fremdriftsplan (blå skrift)

SSA-O Bilag 3

8 Merkantile krav

8.1 Krav

Kundens krav
Nr	Beskrivelse	Krav til dokumentasjon	Type krav
8.1.1	Leverandøren bekrefter å ha utfylt bilag 4 Administrative bestemmelser (blå skrift) inkludert CV'er for nøkkelpersonell (som vedlegg)	SSA-O Bilag 4	A
8.1.2	Leverandøren bekrefter å ha utfylt bilag 5 Samlet Pris og prisbestemmelser (blå skrift)	SSA-O Bilag 5	A

Document Metadata

Table of Contents

Pasientens prøvesvar

Document Metadata