Sidjämförelse

...

Expandera

title	Hur administreras informationen i TAK ?

Det är naturligtvis av yttersta vikt att information i Tjänsteadresseringskatalogen är korrekt,
samt att det finns en spårbarhet på vem som tillhandahållit vilken information.
Inom förvaltningen för den gemensamma Tjänsteplattformen använder man för närvarande ett system med
fyra olika Word-blanketter (A, B, C och D) för att inhämta informationen.
Dessa ligger till grund för uppdateringar av databasen, och arkiveras.
Det finns planer på att ta fram ett administrativt gränssnitt för att delegera ut administrationen av TAK närmare
verksamheterna.

Expandera

title	Vad används de fyra blanketterna till ?

A - Information om tjänster (tjänstekontrakt), version osv.
B - Information om konsumentsystem
C - Information om producentsystem och logiska adresser
D - Information om anropsbehörighet

Expandera

title	Kan TPs seriekopplas ?

Den nationella arkitekturen som den är beskriven i T-boken och detaljerad i RIV TA utgår ifrån att flera
tjänsteplattformar kan seriekopplas. Typfallet är att en region/landsting har en regional instans (en sk RTjP) som används för regional trafik, men också utgör gateway för alla integrationer till tjänster utanför regionen. Praktiskt kan man i normalfallet tänka sig en kedja på upp till tre plattformar, RTjP-NTjP-RTjP, för kommunikation ut ur en region,
via den gemensamma plattformen (NTjP) och in till en tjänst i en annan region. Teoretisk skall dock kedjan kunna vara längre

...

Expandera

title	Hur kopplas praktisk tre plattformar in i serie ?

Låt oss anta att en tjänstekonsument kopplas samman med en tjänsteproducent (som representerar en verksamhet) via tre plattformar;

K1 - RTjP1 - NTjP - RTjP2 - P1 - V1.

Ett exempel på en sådan integration skulle kunna gälla NPÖ2 som tjänstekonsument och tjänsten !GetCareDocumentation.
En tjänstekonsument på VGR, K1, är ansluten till VGRs regionala plattform,
RTjP1.
När en journal skall hämtas från Hjärtkliniken på Karolinska sjukhuset inom SLL kommer anropet att routas via den gemensamma plattformen (NTjP),
och sedan vidare till SLLs regionala plattform (RTjP2).
Därefter går det till den producent, Take Care (P1), som representerar Hjärtkliniken. Den slutgiltiga adressaten, logiska adressen, är alltså Hjärtkliniken (V1).

Beteckning	Exempel
K1	Regional applikation inom VGR
RTjP1	Regional tjänsteplattform inom VGR
NTjP	Gemensam tjänsteplattform
RTjP2	Regional tjänsteplattform inom SLL
P1	Take care - journalsystem inom SLL
V1	Hjärtkliniken på Karolinska sjukhuset, SLL

RTjP1-TAK
För att detta exempel skall fungera så måste RTjP1-TAK (dvs den TAK som används av RTjP1) innehålla förljande information:

Fält	Data \|
Tjänst	GetCareDocumentation
Tjänstekonsument	K1
Tjänsteproducent	NTjP
Logisk adress	V1
Adresseringsinformation	att anrop adresserade till adressen (verksamheten) V1, för tjänsten !GetCareDocumentation, skall skickas till tjänsteproducenten NTjP
Behörighetinformation	att tjänstekonsumenten K1 har behörighet att adressera verksamheten V1 för tjänsten !GetCareDocumentation

Det är i den första tjänsteplattformen i kedjan som det sker en behörighetskontroll av att den ursprungliga tjänstekonsumenten har behörighet att anropa verksamheten i fråga. RTjP1 har ingen information om RTjP2 och P1.

NTjP-TAK

NTjP-TAK kommer att ha information om:

Fält	Data
Tjänst	GetCareDocumentation
Tjänstekonsument	RTjP1
Tjänsteproducent	RTjP2
Logisk adress	V1
Adresseringsinformation	att anrop adresserade till adressen (verksamheten) V1, för tjänsten !GetCareDocumentation, skall skickas till tjänsteproducenten RTjP2
Behörighetinformation	att tjänstekonsumenten RTjP1 har behörighet att adressera verksamheten V1 för tjänsten !GetCareDocumentation

Behörighetskontrollen begränsas här till att verifiera att den regionala tjänsteplattformen RTjP1 har rättighet att andressera V1 för !GetCareDocumentation.
NTjP känner inte till K1 eller P1.

RTjP2-TAK

RTjP2-TAK innehåller:

Fält	Data
Tjänst	GetCareDocumentation
Tjänstekonsument	NTjP
Tjänsteproducent	P1
Logisk adress	V1
Adresseringsinformation	att anrop adresserade till adressen (verksamheten) V1, för tjänsten !GetCareDocumentation, skall skickas till tjänsteproducenten P1
Behörighetinformation	att tjänstekonsumenten NTjP har behörighet att adressera verksamheten V1 för tjänsten !GetCareDocumentation

Behörighetskontrollen begränsas här till att verifiera att den gemensamma tjänsteplattformen NTjP har rättighet att andressera V1 för !GetCareDocumentation.
RTjP2 känner inte till K1 eller RTjP1.

Expandera

title	När kan ett tjänstekontrakt installeras i SIT- eller QA-miljön?

För installation i SIT- eller QA-miljön ska domänen vara tekniskt granskad och godkänd, dvs. det finns ett tekniskt granskningsprotokoll publicerat på RIVTA.

Domäner som ägs av eHälsomyndigheten är undantag och kvalitetssäkras inte enligt våra rutiner.

Expandera

title	När kan ett tjänstekontrakt installeras i produktionsmiljön?

För installation i produktionsmiljön ska domänen vara granskad och godkänd utifrån perspektiven informatik, säkerhet och teknik.

Domänversionen måste vara en released version som inte kommer att ändras. Ingen released candidate (RC) är tillåten i produktionsmiljön.

Domäner som ägs av eHälsomyndigheten är undantag och kvalitetssäkras inte enligt våra rutiner.

Jämförda versioner

Gammal version 7

Ny version Aktuell

Nyckel