Page Comparison

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

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.

Sekvensdiagram for prosessen tjenesteoversikt er vist i figuren under.

Se ytterligere detaljer i innholdsstandarder for innhold i meldinger

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:

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.

Tabellen under oppsummerer attributtene i Tjeneste.

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 dialogmeldingingdialogmelding. En endring krever oppdatert skjema og versjon av kommunikasjonsprosess, og anses ikke hensiktsmessig.

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 å:

1. Opprette alle nye tjenester

2. Oppdatere alle eksisterende tjenester

3. Sette sluttdato for tjenester som er aktive hos mottager, men ikke inneholdt i melding

Nøkkelfelt for å identifisere en tjeneste unikt er:

1. TjenesteId i Tjeneste. Lokal Id i avsenders system

2. Id fra Patient (Fødselsnummer eller d-nummer)

3. 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:

I dette tilfellet skal EPJ sende følgende informasjon for at informasjon i helsenorge.no 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 .no 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.

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.

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

1. Validering på transportnivå. Beskrevet i AMQP profil https://ehelse.no/hits1216-2018 

2. Validering av fagmelding. Ved feil benyttes negative applikasjonskvitteringer.

Tabellen under viser negative applikasjonskvitteringer som kan forventes mottatt.

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.