AMQP Tjenesteoversikt

Tjenesteoversikt kan benyttes for å sende en helsekontakt til innbygger. Meldingstypen ble opprinnelig kalt tjenesteoversikt fordi den gir en oversikt over hvilke helsetjenester innbygger mottar og som gir digitale innbyggertjenester.

Forutsetninger for å bruke denne prosessen er:

Avsender må kunne markere enkelte tjenester som digitale innbyggertjenester
Avsender må være i stand til å ha en elektronisk meldingsutveksling med Helsenorge.no

API-navn	DIALOG_INNBYGGER_TJENESTEOVERSIKT
Funksjonelt område	Helsekontakter
API-versjon og dato publisert	v1.0 Feb 3, 2017
Status	status:I Drift
API-dokumentasjon sist endret	Feb 11, 2021
Teknologi	status:AMQP

Prosesser og flyt

Her er info om prosesser og flyt

Følgende prosess skal aktiveres i adresseregisteret for å støtte funksjonaliteten.

Prosess	Funksjonalitet	Versjon
Dialog_Innbygger_Tjenesteoversikt	Avsender kan sende en helsekontakt til innbygger på Helsenorge. Alle Helsekontakter for avsender (kommunikasjonspart) skal sendes og Helsenorge vil opprette, oppdatere og inaktivere basert på dette.	1.0

Tabellen under viser hvilke roller som inngår i prosessen, hvilke funksjoner de ulike rollene kan gjøre og hvilke meldinger som benyttes for de ulike versjonene.

Versjon	Rolle	Funksjon	Meldingsinnhold
1.0	Innbygger	Apprec	Applikasjonskvittering
1.0	Helsepersonell	Oversikt	Tjenesteoversikt

Sekvensdiagram for prosessen tjenesteoversikt er vist i figuren under.

Se ytterligere detaljer i innholdsstandarder for innhold i meldinger

Hodemelding

Hodemelding vil inneholde informasjon om avsender, mottaker og pasient. Hodemelding vil også inneholde teknisk informasjon som unik id og tidspunkt for generering. Nedenfor beskrives de viktigste delene av standarden som slik den skal brukes for orientering om tjenestetilbud

Den unike id (MsgId) i Hodemeldingen skal være en UUID (Universally Unique Identifier).

XML eksempel:

<MsgId>33160f22-3483-11e2-81c1-0800200c9a66</MsgId>

Elementet «MsgHead/MsgInfo/Type» skal angi at meldingen er Tjenesteoversikt. Innholdet skal angis med følgende kodeverdi fra kodeverk 8279 Meldingens funksjon:

Kodeverdi

Kodetekst

DIALOG_INNBYGGER_TJENESTEOVERSIKT

Dialog med innbygger – tjenesteoversikt

Informasjon om avsender og mottaker skal være i henhold til beskrivelsen i standarden for tjenestebasert adressering tilgjengelig her: https://www.ehelse.no/standarder/om-standardisering-i-e-helse/tjenestebasert-adressering

Avsender: MsgHead/MsgInfo/Sender

I avsender av en melding skal informasjon på to organisasjonsnivå oppgis, virksomhet og kommunikasjonspart. Her-id på begge nivåer skal brukes som identifikator.

XML eksempel med Oslo kommune som avsender:

<Sender>
	<Organisation>
		<OrganisationName>OSLO KOMMUNE HELSEETATEN</OrganisationName>
		<Ident>
			<Id>93638</Id>
			<TypeId DN="HER-id" V="HER" S="2.16.578.1.12.4.1.1.9051"/>
		</Ident>
		<Organisation>
			<OrganisationName>Sykepleietjeneste, pleie- og omsorg </OrganisationName>
			<Ident>
				<Id>93971</Id>
				<TypeId DN="HER-id" V="HER" S="2.16.578.1.12.4.1.1.9051"/>
			</Ident>
		</Organisation>
	</Organisation> 
</Sender>

Mottaker: MsgHead/MsgInfo/Receiver

I mottager av en melding skal informasjon på to organisasjonsnivå oppgis, virksomhet og kommunikasjonspart. Her-id på begge nivåer skal brukes som identifikator, et XML eksempel er vist under.

<Receiver>
<Organisation>
		<OrganisationName>Direktoratet for e-helse</OrganisationName>
		<Ident>
			<Id>93580</Id>
			<TypeId DN="HER-id" V="HER" S="2.16.578.1.12.4.1.1.9051"/>
		</Ident>
		<Organisation>
			<OrganisationName>Digitale innbyggertjenester</OrganisationName>
			<Ident>
				<Id>93239</Id>
				<TypeId DN="HER-id" V="HER" S="2.16.578.1.12.4.1.1.9051"/>
			</Ident>
		</Organisation>
	</Organisation> 
</Receiver>

Elementet <MsgHead/MsgInfo/Ack> skal benyttes til å angi at det skal svares med applikasjonskvittering. Tjenesteoversikt skal alltid ha en applikasjonskvittering.

XML eksempel:

<Ack DN="Ja" V="J"/>

For identifikasjon av en pasient benyttes kodeverket «ID-type for personer» 8116, se http://www.volven.no . Skjemaet støtter flere identifikatorer, men for digital dialog benyttes bare en identifikator og det er bare støtte for fødselsnummer eller D-nummer

Følgende informasjon er obligatorisk å oppgi for pasient.

fornavn
etternavn
fødselsnummer eller d-nummer

XML eksempel for pasient med fødselsnummer:

<Patient>
	<FamilyName>Danser</FamilyName> 
	<GivenName>Line</GivenName> 
	<Ident>
		<Id>13116900216</Id> 
		<TypeId V="FNR" DN="Fødselsnummer" S="2.16.578.1.12.4.1.1.8116" /> 
	</Ident>
</Patient>

Hodemeldingen har struktur for å ha null til mange forekomster av MsgHead/Document. Under «Document» vil faginnholdet i en melding være plassert, og faginnholdet er definert i egne xml skjema. Innholdet under Document vil være xml skjemaet TjenesteOversikt.

Tjenesteoversikt

For overføring av helsekontakter er det utarbeidet et eget skjema spesifikt for dette formålet- tjenesteoversikt.

Tabellen under oppsummerer attributtene i Tjeneste.

Elementer	K	Type	Beskrivelse
Tjenesteid (TjenesteId)	1	string	Id for tjeneste i avsenders system. Dette er en lokal ID, det fins ikke nasjonal standard for Id og type CV benyttes derfor heller ikke. Maks lengde på tjenesteId er satt til 30 tegn
Tjenestenavn (TjenesteNavn)	1	string	Den betegnelse som benyttes for tjenestetypen, f.eks. "Praktisk Bistand". Navn slik det vises til innbygger på helsekontakt i Helsenorge. Vil vises som: Navn på helsekontakt Mottager av meldinger som sendes Hvem timeavtale er med
TjenesteOmrade (TjenesteOmrade)	1	String	ID til tjenestetype, for gruppering av ulike typer tjenester. Gyldige verdier: 1= Kommunal helse og omsorg
Tjenesten levert av (TjenesteLevertAv)	0..1	string	Opplysninger om hvem som leverer tjenesten. For eksempel: Nordre Aker hjemmetjeneste
Tjeneste telefon (TjenesteTlf)	0..1	Telecom	Telefonnummer til leverandør av tjeneste
Tjeneste URL (TjenesteURL)	0..1	Telecom	URL til leverandør av tjeneste
Startdato (Startdato)	1	date	Angir startdato for tjenesten. Helsekontakt blir aktiv for innbygger etter denne datoen.
Sluttdato (Sluttdato)	0..1	date	Angir sluttdato for tjenesten (dersom dette er kjent). Helsekontakt blir inaktiv dersom denne datoen er passert.
Kommunikasjonspart HER id (HerId)	1	Ident	HER id som skal benyttes for å kontakte tjenesten, for eksempel ved dialog fra innbygger til kommune for en spesifikk tjeneste. Flere tjenester kan ha samme tjenesteadresse (HER ID) og denne kan være ulik nivå 2 adressen til avsender av meldingen med TjenesteOversikt (denne meldingen). Derfor kreves HER Id spesifikt oppgitt per enkelttjeneste slik at avsender kan styre hvor meldinger adresseres. Eksempel: 93971 (Sykepleietjeneste, pleie og omsorg)

Et eksempel på XML med Oslo kommune, og to aktive tjenester er vist under. Den første tjenesten har en primærkontakt og telefonnummer og URL til tjenesten.

<TjenesteOversikt xmlns:fk1="http://www.kith.no/xmlstds/felleskomponent1" p2:schemaLocation="http://ehelse.no/xmlstds/tjenesteoversikt TjenesteOversiktv1.0.xsd" xmlns:p2="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://ehelse.no/xmlstds/tjenesteoversikt">
<Tjeneste>
	<TjenesteId>3</TjenesteId>
	<TjenesteNavn>Hjemmesykepleie</TjenesteNavn>
	<TjenesteOmrade>1</TjenesteOmrade>
	<TjenesteTlf>
		<fk1:TeleAddress V="tel:21802180"/>
	</TjenesteTlf>
	<TjenesteURL>
		<fk1:TeleAddress V="url:https://www.oslo.kommune.no/helse-og-omsorg/"/>
	</TjenesteURL>
	<TjenesteLevertAv>Bydel Gamle Oslo</TjenesteLevertAv>
	<FraDato>2020-03-17</FraDato>
	<HERId>
		<fk1:Id>93971</fk1:Id>
		<fk1:TypeId V="HER" S="2.16.578.1.12.4.1.1.9051" DN="HER-id"/>
	</HERId>
	<RelaterteRoller>
		<RoleToPatient V="9" S="2.16.578.1.12.4.1.1.9034" DN="Primærkontakt"/>
		<HealthcareProfessional>
		<fk1:TypeHealthcareProfessional DN="Sykepleier" V="SP"/>
		<fk1:FamilyName>Lin</fk1:FamilyName>
		<fk1:GivenName>Rita</fk1:GivenName>
		<fk1:Ident>
			<fk1:Id>9144900</fk1:Id>
		<fk1:TypeId V="HPR" DN="HPR-nummer" S="2.16.578.1.12.4.1.1.8116"/>
		</fk1:Ident>
		</HealthcareProfessional>
	</RelaterteRoller>
</Tjeneste>
<Tjeneste>
	<TjenesteId>12</TjenesteId>
	<TjenesteNavn>Praktisk bistand</TjenesteNavn>
	<TjenesteOmrade>1</TjenesteOmrade>
	<TjenesteLevertAv>Leverandør A</TjenesteLevertAv>
	<FraDato>2017-01-12</FraDato>
	<HERId>
	<fk1:Id>93971</fk1:Id>
	<fk1:TypeId V="HER" S="2.16.578.1.12.4.1.1.9051" DN="HER-id"/>
	</HERId>
</Tjeneste>
</TjenesteOversikt>

RelaterteRoller benyttes for å kunne overføre helsepersonell knyttet til tjenesten og som skal være tilgjengelig for innbygger på Helsenorge. Tabellen under oppsummerer attributtene i RelaterteRoller. Skjemaet tillater også sending av enheter og personer, dette er ikke støttet funksjonelt.

RelaterteRoller inneholder samme informasjon som RollerRelatertNotat i dialogmeldingen og burde vært navngitt konsistent med dialogmelding. En endring krever oppdatert skjema og versjon av kommunikasjonsprosess, og anses ikke hensiktsmessig.

Elementer	K	Type	Beskrivelse
RoleToPatient	0..1	CS	Helsepersonellets rolle i forhold til en pasient. Kodeverk: 9034 Helsepersons roller i forhold til pasient Foreløpig benyttes kun Primærkontakt fra kodeverket.
TypeHealthcareProfessional)	0..1	CS	Kode som angir kategori helsepersonell i henhold til helsepersonellregisterets inndeling. Kodeverk: 9060 Kategori helsepersonell
FamilyName	1	string	Angir personens etternavn. Påkrevd dersom relaterteRoller sendes.
GivenName	1	string	Angir personens fornavn. Påkrevd dersom relaterteRoller sendes.
Ident	1	Identifikator	Id og Idtype. TypeId hentes fra kodeverk 8116. Følgende verdier er i bruk HPR og "XXX" annet

Et eksempel på XML med en primærkontakt er vist under:

<RelaterteRoller>
	<RoleToPatient V="9" S="2.16.578.1.12.4.1.1.9034" DN="Primærkontakt"/>
	<HealthcareProfessional>
		<fk1:TypeHealthcareProfessional DN="Sykepleier" V="SP"/>
		<fk1:FamilyName>Lin</fk1:FamilyName>
		<fk1:GivenName>Rita</fk1:GivenName>
		<fk1:Ident>
			<fk1:Id>9144900</fk1:Id>
			<fk1:TypeId V="HPR" DN="HPR-nummer" S="2.16.578.1.12.4.1.1.8116"/>
		</fk1:Ident>
	</HealthcareProfessional>
</RelaterteRoller>

Avsender vil alltid sende en komplett liste med gjeldende tjenester, og mottager vil alltid synkronisere denne komplett ved å:

Opprette alle nye tjenester
Oppdatere alle eksisterende tjenester
Sette sluttdato for tjenester som er aktive hos mottager, men ikke inneholdt i melding

Nøkkelfelt for å identifisere en tjeneste unikt er:

TjenesteId i Tjeneste. Lokal Id i avsenders system
Id fra Patient (Fødselsnummer eller d-nummer)
Kommunikasjonspart HER Id

Avsender har logikk for håndtering av sending av tjenesteoversikt slik at korrekt informasjon for en tjeneste kan vises i Helsenorge.no. Et tenkt tilfelle er vist i tabellen under, der en tjeneste går fra Aktiv-> Inaktiv -> Aktiv:

Periode	Status
2.5-6.6	Aktiv
07.jun	Inaktiv
8.6 ->	Aktiv

I dette tilfellet skal EPJ sende følgende informasjon for at informasjon i Helsenorge skal bli riktig:

Tjeneste med sluttdato 6.6 sendes til og med 6.6. Dette sikrer at tjenesten vises som aktiv til og med 6.6 og vises som inaktiv fra og med 7.6
Den 08.06 sendes tjeneste med startdato 08.6 og med åpen sluttdato

Dersom tjeneste med startdato 8.6 sendes før 8.6 vil tjenesten ikke vises riktig som aktiv eller historisk.

Helsenorge lagrer ikke historikk for meldingen, så de fleste feilsituasjoner kan løses ved å sende ny korrekt melding. Tabellen under gir foreslått håndtering av kjente tilfeller.

Type	Håndtering
Retting etter manglende mottatt melding eller feil innhold i melding	Avsender sender ny melding med korrekt innhold, mottager synkroniserer innhold.
Tjeneste feilaktig sendt til mottager	EPJ sender en tom liste med Tjenesteoversikt, Helsenorge setter da sluttdato for alle aktive tjenester for valgt person og virksomhet.
Endring av fødselsnummer	Her er det flere mulige tilfeller Fødselsnummer er endret i Helsenorge , men ikke i EPJ. Helsenorge vil sende negativ AppRec på meldingen og indikere at person ikke er digitalt aktiv inntil personnummer er endret i EPJ Fødselsnummer er endret i EPJ, men ikke Helsenorge . Helsenorge vil sende negativ AppRec på meldingen og indikere at person ikke er digitalt aktiv inntil personnummer er endret i Helsenorge
Endring av HER-id for virksomhet	Denne er for eksempel relevant ved kommunesammenslåinger, der HER-id kan endres. Her er Helsenorge avhengig av å få slettet tjenester for tidligere HER-Id og opprettet tjenester for ny HER-id. Løsning for å sikre konsistente data er at EPJ sender Tom tjenesteoversikt for gammel HER-id. Avslutter dermed alle helsekontakter for gammel HER-id Korrekt tjenesteoversikt for ny HER-id. Oppretter alle helsekontakter for ny HER-id Endring av HER-id på Virksomhet anses som et unntakstilfelle, og prosessen for dette kan være delvis manuell. Eksempel der dette er relevant er kommunesammenslåinger.

Applikasjonskvittering

Applikasjonskvittering skal benyttes for å bekrefte at melding er mottatt og kan behandles av systemet. Applikasjonskvittering v1.1 skal benyttes, slik beskrevet i https://ehelse.no/his80415-2012.

Applikasjonskvittering skal benyttes slik det er beskrevet i standarden for Applikasjonskvittering v1.1. Det er beskrevet at følgende hovedprinsipp gjelder for når det skal sendes positiv eller negativ kvittering.

Type kvittering	Tolkning
Positiv applikasjonskvittering	Fagmeldingen er mottatt og at den kan tolkes korrekt. Fageldingen vil da være klar for videre behandling i det aktuelle fagsystem og ansvarlig personell kan lese innholdet i mottatt fagmelding (dokument).
Negativ applikasjonskvittering	Mottakende applikasjon ikke kan tolke opplysningene i mottatt fagmelding. Ingen videre oppfølging kan ventes av mottaker ved negativ applikasjonskvittering.

En negativ applikasjonskvittering betyr i hovedsak at det var noe feil med mottatt melding slik at denne ikke kunne behandles av mottaker. Når det sendes en negativ kvittering forventes det at mottaker følger opp denne i henhold til feilkoder og sender en ny (og feilfri) melding.

Kodeverk 8221 «Feilmeldinger for applikasjonskvittering» skal brukes ved negativ applikasjonskvittering for å angi type feilmelding. Ved mottak av en melding gjøres det i hovedsak to ulike valideringer

Validering på transportnivå. Beskrevet i AMQP profil https://ehelse.no/hits1216-2018
Validering av fagmelding. Ved feil benyttes negative applikasjonskvitteringer.

Tabellen under viser negative applikasjonskvitteringer som kan forventes mottatt.

Kode	Bruk
T01 – Ikke XML / ikke 'well formed' / uleselig	Mottatt XML kan ikke tolkes.
T02 – XML validerer ikke	XSD-validering
E10 Ugyldig meldingsidentifikator	Ikke samsvar AMQP Avsender HER-Id <-> fagmelding Avsender HER-Id eller Ikke samsvar AMQP mottager HER-Id <-> fagmelding mottager HER-Id
E35 Pasienten finnes ikke i mottakersystemet	Innbygger er ikke digitalt aktiv og melding kan ikke behandles. Avsender skal markere innbygger som ikke aktiv og melding skal ikke resendes.

I noen tilfeller er melding korrekt og sendt til riktig innbygger, men meldingen kan likevel ikke behandles. Dette skjer dersom en aktør sender melding til en person som ikke har en innbyggerprofil på helsenorge.no og samtykke til digital helsetjeneste. Helsenorge.no har i dette tilfellet ikke lov til å lagre eller behandle meldingen.

I dette tilfellet sendes negativ kvittering med feilkoden «E35 - Pasienten finnes ikke i mottakersystemet». Mottager av kvittering skal markere innbygger som ikke aktiv og melding skal ikke resendes.

Generell info om meldingsutveksling med Helsenorge

For overordnet informasjon om meldingsutveksling med Helsenorge se her: Meldingsutveksling med Helsenorge