Digital dialog - generelle funksjonelle krav

Tilleggskrav for alle integrasjoner med digital dialog

NB! de tekniske kravene gjelder selv om det ikke er spesifisert i de funksjonelle kravene. Dersom det er mangler eller motsigelser ber vi om å få beskjed om dette.
ID’ene er av historiske grunner ikke løpende, og det betyr ikke at noe er falt ut.

ID	Område	Krav til integrasjonsparten	Prioritet	MELDINGSTYPE /retning	AKSJONSKODER	Akseptansekriterie	Kommentar / Lenker kun for NHN
DD basis- 24 UTGÅTT	Status om innbygger er aktiv digital bruker	https://helsenorge.atlassian.net/wiki/spaces/HELSENORGE/pages/1810268162 HN vil sende en melding til EPJ når innbygger trekker samtykke til digital helsetjeneste. Merk: Hvis pasient samtykker før legekontor blir digitalt, vil legekontoret ikke motta noen digitalt aktiv status (før pas evt. initsierer en kontakt). Tilsvarende ved fastlegebytte, vil det ikke sendes melding fra HN til ny EPJ. Innbygger kan også bli digitalt inaktiv på grunn av manglende bruk, dette vil ikke medføre melding fra HN	MÅ HA	DIALOG_INNBYGGER_DIGITALBRUKER /Fra HN	SDAB Status digital aktiv bruker	EPJ skal endre pasientens status i henhold til dette https://helsenorge.atlassian.net/wiki/spaces/HELSENORGE/pages/1810399233
DD basis- 24a UTGÅTT	Sjekk om innbyggere er aktiv digital brukere	https://helsenorge.atlassian.net/wiki/spaces/HELSENORGE/pages/1810268162 EPJ skal jevnlig sjekke om nye innbygger er digitalt aktiv, slik at legekontoret har oppdatert digital status før melding blir skrevet og sendt. Med tjenesten «Sjekk om innbygger(e) er digitalt aktive bruker(e)» menes det at EPJ-systemet sender en liste med pasienter til HN og spør om hvem av pasientene som er digitale aktive brukere på HN . Svaret tilbake fra HN er kode 28 med en liste over de pasientene som er digitale aktive brukere, alternativt, kode 29 som angir ingen digitalt aktive brukere.	MÅ HA	DIALOG_INNBYGGER_DIGITALBRUKER /Fra EPJ & HN	SIDAB sjekk om innbygger(e) er digitalt aktiv(e) bruker(e) 28 Digital aktiv(e) bruker(e) 29 Ingen digital(e) bruker(e)	EPJ skal sette pasientens status i henhold til dette Det skal jevnlig sjekkes for digitalt status på "Ikke digitale" pasienter. Periode skal være konfigurerbar, én gang i døgnet kan være et utgangspunkt.
DD basis- 24b UTGÅTT	Sjekk om innbygger er aktiv digital bruker	EPJ-systemet skal ikke tillate at legekontoret sender henvendelser til en bruker som ikke er en digitalt aktiv på HN . HN vil sende en negativ applikasjonskvittering E35 i retur dersom innbyggers status er ikke aktiv. EPJ skal da oppdatere status.	MÅ HA	DIALOG_INNBYGGER_DIGITALBRUKER /Fra EPJ & HN	SIDAB sjekk om innbygger(e) er digitalt aktiv(e) bruker(e) 28 Digital aktiv(e) bruker(e) 29 Ingen digital(e) bruker(e)	Det skal tydelig fremgå i EPJ at pasienten ikke er digital aktiv slik at man ikke kan starte dialog
DD basis- 27	Andre funksjonelle krav	For kommunikasjon som ikke foregår i sanntid skal EPJ-systemet sende en applikasjonskvittering til HN når en melding er korrekt mottatt (dekrykptert og validert) av EPJ-systemet.	MÅ HA	Fra EPJ		EPJ skal sende apprec på alle async meldinger som kommer inn. EPJ bør synligjøre manglende mottat apprec fra HN Negativ apprec må synliggjøres
DD basis- 28	Andre funksjonelle krav	EPJ-systemet må tillate at en mottatt henvendelse kan endres til en annen kategori. F.eks. må en eKontakt kunne endres til en eKonsultasjon dersom innholdet er spørsmål om helsehjelp som må besvares av lege. Følgende henvendelser skal kunne endres: • Reseptfornyelse til eKontakt eller eKonsultasjon • eKonsultasjon til eKontakt eller reseptfornyelse • eKontakt til reseptfornyelse eller eKonsultasjon	MÅ HA	Fra EPJ		Følgende henvendelser skal kunne endres: • Reseptfornyelse til eKontakt eller eKonsultasjon • eKonsultasjon til eKontakt eller reseptfornyelse • eKontakt til reseptfornyelse eller eKonsultasjon
DD basis-29	Andre funksjonelle krav	EPJ-systemet må kunne vise tråder av meldinger slik at det er tydelig hvilke svar som hører til hvilke spørsmål. Dette gjelder også når det er flere spørsmål og svar i en dialog.	MÅ HA	Fra HN		Det skal være klart synlig i EPJ at det finnes flere meldinger i en dialog mellom behandler og innbygger, og i hvilken rekkefølge meldingene er sendt
DD basis-30	Andre funksjonelle krav	EPJ-systemet må kunne ta i mot og vise meldinger med emnefelt slik at det blir enkelt for fastlegekontoret å se hva meldingen gjelder. Emnefelt skal ikke kunne endres.	MÅ HA	Fra HN		Emne og dato feltene skal vises tydelig. Disse to feltene skal ikke kunne endres i EPJ.
DD basis-31	Andre funksjonelle krav	EPJ-systemet skal kunne ta i mot meldinger med vedlegg. Vedlegget må vises sammen med meldingen slik at behandler ser sammenhengen mellom vedlegget og meldingen.	MÅ HA	..._EKONSULTASJON ..._EKONTAKT /fra HN		EPJ skal tydelig vise alle vedlegg og alle vedleggene må kunne skaleres slik at det passer til et vindu og man kan lese hele
DD basis-32	Andre funksjonelle krav	Behandler skal kunne sende en melding/svar med vedlegg.	MÅ HA	..._EKONSULTASJON ..._EKONTAKT /fra HN		EPJ kan sende melding med vedlegg til innbygger Maks 12 20 MB totalt Maks 3 vedlegg kan legges til i EPJ Maks 4MB per vedlegg	Oppdatert 22/3-23: Fra april-23 økes max MB lov å sende til 20Mb totalt.
DD basis-33	Andre funksjonelle krav	Kun vedlegg av filtypene pdf/a, jpeg og png skal kunne sendes og mottas.	MÅ HA	..._EKONSULTASJON ..._EKONTAKT /fra EPJ & HN		EPJ må begrense på type vedlegg som kan legges til og kan bare ta imot disse typene: PDF/A, JPEG og PNG
DD basis-35	Andre funksjonelle krav	EPJ-systemet skal kunne ta i mot rik tekst (XHTML) i en melding og vise tilsvarende formattering for behandler.	MÅ HA	Fra EPJ		EPJ skal kunne ta imot rik tekst (XHTML) i en melding, se vedlagt link til hvordan formatering av XHTML skal være. https://ehelse.no/standarder-kodeverk-og-referansekatalog/standarder-og-referansekatalog/bruk-av-xhtml-formatering-hisd-11552008
DD basis-37	Andre funksjonelle krav	EPJ- systemet må kunne oppdatere tjenesteoversikten i registerplattform hos Norsk Helsenett med informasjon om legekontoret og om hvilke digital dialog tjenester som støttes. Følgende informasjon skal kunne registreres: Kontaktinformasjon, inkludert adresse Generell informasjon om virksomhet (som f.eks. åpningstider) Notis/beskjeder fra fastlegekontoret til alle pasienter per tjenestetype (Dette kan gjøres i BRREG eller i “Helsetilbud“) Informasjonen vil også kunne oppdateres via NHNs nettside for vedlikehold av registerinformasjon - AR og BRREG.	MÅ HA	Fra EPJ			Se også krav 39 & 47
DD basis-38	Andre funksjonelle krav	Det bør etableres en enkel funksjon som gjør det mulig for EPJ bruker å verifisere at kommunikasjonen er åpen.	BØR HA	DIALOG_INNBYGGER_TEST /Fra EPJ	KT Kommunikasjonstest RKT Respons Kommunikasjonstest	EPJ kan ta i bruk funksjonen for å verifisere at kommunikasjonskanalen er åpen og sertifikater er OK
DD basis-39	Andre funksjonelle krav	For å forenkle og støtte oppunder prosessen «Opprette CPP med tilhørende kommunikasjonsprosesser for kommunikasjonpart». Det finnes metoder: ICPPAService grensesnittet tilhørende Adresseregister-plattformen.	MÅ HA		Beskrivelse: Gruppering av CPP oppsett for ulike løsninger	AR skal være master for CPP oppsett, slik at ved åpning av CPP funksjonen i EPJ skal settings fra AR hentes inn, før bruker for lov å gjøre endringer. Det skal ikke kunne gjøres CPP endringer i EPJ, som ikke blir oppdatert i AR.	19.11.2021: AC lagt inn. Se også krav 37 & 47
DD basis-42	Andre funksjonelle krav	Serverklokke skal synkroniseres mot tidstjener, som beskrevet i AMQP spesifikasjon	MÅ HA
DD basis-43	Andre funksjonelle krav	Kommunikasjonsprosesser på versjon 1.2 skal tas i bruk. Dette støtter representasjon for foreldre for barn under 12 år & ved fullmakt fra person over 16 år Gjelder alle tjenestetyper	MÅ HA			03.08.2021: EPJ skal vise på alle meldingstyper, hvem som har skrevet på vegne av pasienten. Minimum med navn, og helst også med representasjonsrollen.	Se også krav 50
DD basis-44	Andre funksjonelle krav	Ved mottak av negativ apprec E35 fra HN skal innbygger settes digitalt ikke aktiv i EPJ.	MÅ HA			Dette gjelder for alle meldinger som gir applikasjonskvittering
DD basis-47	Andre funksjonelle krav	Registrere CPP i Adresseregisteret for hver kommunikasjonspart som man skal kommunisere med HN	MÅ HA		Beskrivelse: Gruppering av CPP oppsett for ulike løsninger	Vedlikehold av CPP på den enkelt fastlege/tjeneste må ikke legges på NHN Kunde- & Driftsenter. EPJ'ene må lage nøyaktig beskrivelser av hvordan dette skal settes opp. (se lenke i aksjonskoder kolonnen) Evt lage integrasjon. ref krav 39.	19.11.2021: AC lagt inn. Se også krav 37 & 39
DD basis-48	Andre funksjonelle krav	Adressere meldinger til riktig tjenesteadresse	MÅ HA
DD basis-50	Andre funksjonelle krav	Åpne for fastlege og kommunale tjenester på vegne av barn 12-16: Når en bruker av EPJ setter opp en time til en person 12-16 skal det komme opp et varsel med påminnelse om at timen vil vises for foresatte på helsenorge, slik at de blir påminnet om å spørre pasienten om det er ønskelig. Dette varselet skal dukke opp når brukeren er i kontekst av å sette opp en time - mao. før timen lagres! Det skal være mulig å velge en timetype som ikke sendes til helsenorge, slik at denne ikke vises til foresatte. Timetypen skal være navngitt slik at det er lett forståelig at den ikke vises på helsenorge. Foreldre med foreldreansvar kan: Sende meldinger til fastlege og kommune på vegne av barn mellom 12-16 lese meldinger som er sendt til barnet bestille og behandle timer/avtaler hos fastlege og kommune på vegne av barnet	MÅ HA	DIALOG_INNBYGGER_TIMERESERVASJON DIALOG_INNBYGGER_TIMEUTSENDELSE / i EPJ	05 Timereservasjon bekreftet 07 Endring av time bekreftet	Løsningsmessige godkjenningskriterier Varselet skal komme kun hvis pasienten er digitalt aktiv og mellom 12-16. Det må være en sperre på at timen ikke opprettes før det svares eksplisitt på riktig timetype. Det skal være mulig for EPJ-bruker å velge en timetype som ikke sendes til HN.	Nytt Basiskrav fra 2019. HN L.19.2 Spesifikt AC er slettet etter avtale med TA: KVL. 27/10-21 Se også krav 43
DD basis-51	Andre funksjonelle krav	Validering mot CPA ved ny melding i EPJ.	MÅ HA	DIALOG_INNBYGGER.. …_TIMERESERVASJON …_TIMEONSKE …_RESEPTFORNYELSE ..._EKONSULTASJON ..._EKONTAKT /Fra EPJ		Det skal bare være mulig for helsepersonell å sende en melding som ligger i samhandlingsavtale (CPA) mellom lege og HN . Prosesser som ikke ligger i avtale skal ikke tillates sendt, HN vil ikke godta disse.	Nytt Basiskrav fra mars 2019.
DD basis	Andre funksjonelle krav	Svartelisting - hindre visse pasienter (som misbruker tjenestene) tilgang ”Svartelistet”	BØR HA	DIALOG_INNBYGGER.. …_TIMERESERVASJON …_TIMEONSKE …_RESEPTFORNYELSE ..._EKONSULTASJON ..._EKONTAKT /Fra EPJ	30 Tjeneste Ikke tilgjengelig	Det skal være mulig for helsepersonell å sperre en eller flere tjenester for visse pasienter. Ved sykront kall fra HN vil “Tjenesten ikke tilgjengelig …kontakt legekontoret på annen måte“ vises i stedet for timeboken. Ved asykron melding (eKonsultasjon, eKontakt eller Reseptfornyelse) vil dette, vi denne sendes fra HN og pasienten vil få en svarmelding med kode 30 som viser teksten “Tjenesten ikke tilgjengelig …kontakt legekontoret på annen måte“ for pasienten.	04.12.2022 Dette er beskrevet i teknisk dokumentasjon fra DDFLs begynnelse, men integrasjonskravet ble borte i en oppdatering. Legges derfor inn her.