...
Tjänsteplattform
Tekniska krav
ARK_0034
Version 1.3
| Innehållsförteckning |
|---|
...
Versionshistorik
...
Version
...
Författare
...
Kommentar
...
PA1
...
Mattias Nordvall
...
Första utkast
...
PA2
...
Mattias Nordvall
...
Uppdaterat efter intern remiss
...
PA3
...
Lars Erik Röjerås
...
Justeringar efter genomläsning
...
1.0
...
Mattias Nordvall
...
Dokumentets underrubrik är nu ”Tekniska krav” istället för ”Regler för interoperabilitet”.
Lagt till kapitel med definition av termer.
Tagit bort texter om reverse proxy (betraktas som implementationsdetalj).
Lagt till felkoder för virtualiseringsplattform.
Tagit bort regel om loggning av förändringar av TAK-information (inte ett tekniskt krav).
Tagit bort skrivning om godkännande av tjänstekontrakt i 3.1.1 (inte ett tekniskt krav).
Ändrat regel om uppbyggnad av URL:er till att enbart beskriva slutet på adresserna (det enda som är reglerat i RIV TA).
Förtydligat att anropsbehörighet i TAK avser närmast anropande tjänstekonsument.
Kapitlet om TAK använde begreppet ”logisk adress” om två olika saker.
Lagt till översiktligt kapitel om Tjänsteväxel.
Korrigerat ordval och stavfel.
Uppdaterade illustrationer.
...
1.0.1
...
Mattias Nordvall
...
Korrigerat vissa formuleringar och illustrationer.
Nytt stycke om förhållandet mellan nationella och regionala tjänsteplattformar.
...
1.1
...
Mattias Nordvall
...
Kapitlet om anpassningsplattform och tjänsteväxel omskrivet och felaktigheter korrigerade.
Regel ”Exponering av URL:er” i kapitel 4 korrigerad för att överensstämma med underliggande regelverk.
Exempel från den senaste versionen av RIV-TA Basic Profile, t.ex. SOAP Headers, är ändrade till mer generella begrepp
...
1.2
...
Mattias Nordvall
...
Lagt till regler i kapitel 4 från RIV TA Basic Profile 2.0. Dessa regler behöver följas av tjänsteplattformar.
Lagt till Regel #6 under kapitlet Aggregeringsplattform.
...
1.3
...
Mattias Nordvall
...
Tjänsteplattform Tekniska krav ARK_0034 Version 1.4 |
| Innehållsförteckning |
|---|
Versionshistorik | |||
Version | Revision Datum | Författare | Kommentar |
PA1 | Mattias Nordvall | Första utkast | |
PA2 | Mattias Nordvall | Uppdaterat efter intern remiss | |
PA3 | Lars Erik Röjerås | Justeringar efter genomläsning | |
1.0 | Mattias Nordvall | Dokumentets underrubrik är nu ”Tekniska krav” istället för ”Regler för interoperabilitet”. Lagt till kapitel med definition av termer. Tagit bort texter om reverse proxy (betraktas som implementationsdetalj). Lagt till felkoder för virtualiseringsplattform. Tagit bort regel om loggning av förändringar av TAK-information (inte ett tekniskt krav). Tagit bort skrivning om godkännande av tjänstekontrakt i 3.1.1 (inte ett tekniskt krav). Ändrat regel om uppbyggnad av URL:er till att enbart beskriva slutet på adresserna (det enda som är reglerat i RIV TA). Förtydligat att anropsbehörighet i TAK avser närmast anropande tjänstekonsument. Kapitlet om TAK använde begreppet ”logisk adress” om två olika saker. Lagt till översiktligt kapitel om Tjänsteväxel. Korrigerat ordval och stavfel. Uppdaterade illustrationer. | |
1.0.1 | Mattias Nordvall | Korrigerat vissa formuleringar och illustrationer. Nytt stycke om förhållandet mellan nationella och regionala tjänsteplattformar. | |
1.1 | Mattias Nordvall | Kapitlet om anpassningsplattform och tjänsteväxel omskrivet och felaktigheter korrigerade. Regel ”Exponering av URL:er” i kapitel 4 korrigerad för att överensstämma med underliggande regelverk. Exempel från den senaste versionen av RIV-TA Basic Profile, t.ex. SOAP Headers, är ändrade till mer generella begrepp | |
1.2 | Mattias Nordvall | Lagt till regler i kapitel 4 från RIV TA Basic Profile 2.0. Dessa regler behöver följas av tjänsteplattformar. Lagt till Regel #6 under kapitlet Aggregeringsplattform. | |
1.3 | Mattias Nordvall | Uppdaterat Regel #6 under kapitlet Aggregeringsplattform. | |
| 1.4 | 2017-12-07 | Björn Hedman | Lagt till information om adressering baserat på TAK och organisationsdata "HSA klättring" Under rubrik 4.2.6 har görs hänvisning till Basic Profile istället för att beskriva och exemplifiera i detta dokument Rättat numrering av regler under kapitel 5.1 (Virtualiseringsplattform) felet uppstod mellan version 1.0 och 1.1 (några regler utgick i 1.1) Tagit bort hänvisning till fallstudie för "Regional tjänsteplattform, Landstinget Dalarna" eftersom länken var bruten. |
Inledning
Hälso- och sjukvårdssektorn i Sverige har på uppdrag av Sveriges Kommuner och Landsting och under ledning av CeHis, nuvarande Inera, gemensamt tagit fram en nationell teknisk arkitektur i syfte att stödja samarbete över organisationsgränserna.
...
Namn | Adress | Beskrivning | |||
SKL TP | Officiell referens-implementation. Bygger på Mule ESB. | Landstinget Dalarnas implementation av SKL TP/skltp.se/ | Officiell referens-implementation. Bygger på Mule ESB. |
1.5 Referenser
Ref | Dokument | Beskrivning | ||
[R1] | T-boken | Referensarkitektur för vård och omsorg | ||
[R2] | RIV Tekniska Anvisningar – Översikt | |||
[R3] | RIV Tekniska Anvisningar – Basic Profile | RIV-TA:s tillägg till WS-I Basic Profile | ||
[R4] | RIV Tekniska Anvisningar – Basic Profile – Valfria Tillägg 2.1 | |||
[R5] | RIV Tekniska Anvisningar – Tjänsteschema | Beskrivning av schema-filer för tjänstekontrakt. | ||
[R6] | Tjänstekontrakts-beskrivning Engagemangsindex | Beskrivning av tjänstekontrakt i domänen itintegration:engegementindex. | ||
[R7] | WS-I Basic Profile 1.1 | En specifikation på protokollanvändning i syfte att kunna implementera interoperabla webbtjänster. | ||
[R8] | Tjänstekontrakts-beskrivning Tjänsteadressering | Beskrivning av tjänstekontrakt i domänen infrastructure:itintegration:registry. http://rivta.se/domains/infrastructure_itintegration_registry.html | ||
| [R9] | Användarhandledning adressering med HSA information | Beskrivning av hur organisationsdata (från HSA) kan användas för logisk adressering | domainsinfrastructure_itintegration_registry.html |
2. Terminologi
Följande termer förekommer i dokumentet.
...
RIV Tekniska Anvisningar är den tekniska realiseringen av de koncept som beskrivs i T-boken. Här definieras t.ex. RIV TA Basic Profile (förkortat RIV TA BP), som anger hur den tekniska kommunikationen mellan tjänstekomponenter ska gå till. RIV TA BP baseras på WS-I Basic Profile, som i sin tur bygger på SOAP. Se [R7].
3.2 Nationella och regionala och tjänsteplattformar
Tjänsteplattformar förekommer dels i en nationell instans, men även hos regionala aktörer inom hälso- och sjukvårdssektorn. Oavsett vilket, skall tjänsteplattformarna tillämpa de regler som beskrivs i detta dokument.
Tjänstekomponenter ansluts till någon av dessa tjänsteplattformar. Därefter styr tjänsteplattformarnas vägvalsinformation och anropsbehörigheter åtkomsten mellan tjänstekomponenterna.
Tjänstekonsumenter skickar alltid sina meddelanden till den tjänsteplattform tjänstekonsumenten är ansluten till. Meddelandena är adresserade med mottagarens logiska adress.
Såvida den adresserade tjänsteproducenten förekommer i den anropade tjänsteplattformens tjänsteadresseringskatalog, vidarebefordrar tjänsteplattformen meddelandet, antingen direkt till tjänsteproducenten, eller till den tjänsteplattform som tjänsteproducenten är ansluten till.
Observera att anrop direkt mellan regionala tjänsteplattformar inte får förekomma. Anrop mellan tjänstekomponenter anslutna till olika tjänsteplattformar skall alltid ske via den nationella tjänsteplattformen.
4. RIV Tekniska Anvisningar
RIV Tekniska Anvisningar (RIV TA) är en samling specifikationer på hur elektronisk information ska utbytas för att kunna tolkas av tjänstekomponenter byggda på olika mjukvaruplattformar.
Syftet med detta kapitel är att ge en sammanfattning av de regler från RIV TA som berör tjänsteplattformar, samt att hänvisa till de dokument där reglerna har sina gällande formuleringar. En tjänsteplattform behöver i dagsläget stödja RIV TA Basic Profile version 2.0 och 2.1.
Då RIVTA Basic Profile 2.0 är en äldre version finns dess dokumentation inte publicerad på rivta.se. Kontakta arkitektur@inera.se vid behov av denna dokumentation.
4.1 Information
4.1.1 Användning av tjänstekontrakt
Allt meddelandeutbyte ska baseras på tjänstekontrakt, som utformats enligt gällande versioner av RIV TA.
4.2 Kommunikation
Följande regler gäller för all kommunikation mellan tjänstekomponenter, inklusive tjänsteplattformars delkomponenter, om inte annat nämns.
4.2.1 Transportprotokoll
Tjänstekomponenter skall skicka och ta emot anrop över HTTPS, om inte annat anges i regelverk för specifika tjänstekomponenter.
Källa: RIVTA Basic Profile 2.0 och 2.1 [R3] Regel #6
4.2.2 Autentisering
HTTPS-sessioner skall autentiseras med hjälp av HTTPS Mutual Authentication. Det innebär att båda parter autentiserar varandra med hjälp av certifikat.
Tjänstekonsumentens identitet fastställs utifrån attributet SerialNumber i dess certifikat. Certifikat utgivna av SITHS är utformade på detta sättsin tur bygger på SOAP. Se [R7].
3.2 Nationella och regionala och tjänsteplattformar
Tjänsteplattformar förekommer dels i en nationell instans, men även hos regionala aktörer inom hälso- och sjukvårdssektorn. Oavsett vilket, skall tjänsteplattformarna tillämpa de regler som beskrivs i detta dokument.
Tjänstekomponenter ansluts till någon av dessa tjänsteplattformar. Därefter styr tjänsteplattformarnas vägvalsinformation och anropsbehörigheter åtkomsten mellan tjänstekomponenterna.
Tjänstekonsumenter skickar alltid sina meddelanden till den tjänsteplattform tjänstekonsumenten är ansluten till. Meddelandena är adresserade med mottagarens logiska adress.
Såvida den adresserade tjänsteproducenten förekommer i den anropade tjänsteplattformens tjänsteadresseringskatalog, vidarebefordrar tjänsteplattformen meddelandet, antingen direkt till tjänsteproducenten, eller till den tjänsteplattform som tjänsteproducenten är ansluten till.
Observera att anrop direkt mellan regionala tjänsteplattformar inte får förekomma. Anrop mellan tjänstekomponenter anslutna till olika tjänsteplattformar skall alltid ske via den nationella tjänsteplattformen.
4. RIV Tekniska Anvisningar
RIV Tekniska Anvisningar (RIV TA) är en samling specifikationer på hur elektronisk information ska utbytas för att kunna tolkas av tjänstekomponenter byggda på olika mjukvaruplattformar.
Syftet med detta kapitel är att ge en sammanfattning av de regler från RIV TA som berör tjänsteplattformar, samt att hänvisa till de dokument där reglerna har sina gällande formuleringar. En tjänsteplattform behöver i dagsläget stödja RIV TA Basic Profile version 2.0 och 2.1.
Då RIVTA Basic Profile 2.0 är en äldre version finns dess dokumentation inte publicerad på rivta.se. Kontakta arkitektur@inera.se vid behov av denna dokumentation.
4.1 Information
4.1.1 Användning av tjänstekontrakt
Allt meddelandeutbyte ska baseras på tjänstekontrakt, som utformats enligt gällande versioner av RIV TA.
4.2 Kommunikation
Följande regler gäller för all kommunikation mellan tjänstekomponenter, inklusive tjänsteplattformars delkomponenter, om inte annat nämns.
4.2.1 Transportprotokoll
Tjänstekomponenter skall skicka och ta emot anrop över HTTPS, om inte annat anges i regelverk för specifika tjänstekomponenter.
Källa: RIVTA Basic Profile 2.0 och 2.1 [R3] Regel #6
4.2.2 Autentisering
HTTPS-sessioner skall autentiseras med hjälp av HTTPS Mutual Authentication. Det innebär att båda parter autentiserar varandra med hjälp av certifikat.
Tjänstekonsumentens identitet fastställs utifrån attributet SerialNumber i dess certifikat. Certifikat utgivna av SITHS är utformade på detta sätt.
Källa: RIVTA Basic Profile 2.0 och 2.1 [R3] Regel #6
4.2.3 Bevara ursprunglig avsändares identitet i http header
Efter att autentisering skett enligt ovan, och aktuell förfrågan INTE innehåller http header x-rivta-original-serviceconsumer-hsaid, skall tjänsteplattformen infoga denna http header i utgående anrop och sätta värdet till anropande tjänstekonsuments identitet.
Detta görs för att nästa komponent i kedjan inte kommer att kunna läsa ursprungsavsändarens certifikat.
Källa: RIVTA Basic Profile 2.1 Valfria tillägg [R4] Regel #2
Detta regleras inte i RIVTA Basic Profile 2.0.
4.2.4 Vidarebefordran av http header
Om ett inkommande anrop kommer från en tjänsteplattform och innehåller http header x-rivta-original-serviceconsumer-hsaid så ska denna http header skickas vidare oförändrad, förutsatt att anropet kommer från en tjänsteplattform som betraktas som känd. Detta kan fastställas t.ex. genom att hålla en lista på betrodda tjänsteplattformars ip-adresser eller funktionscertifikat.
Källa: RIVTA Basic Profile 2.0 och 2.1 Valfria tillägg [R3R4] Regel #6
4.2.3 Bevara ursprunglig avsändares identitet i http header
Efter att autentisering skett enligt ovan, och aktuell förfrågan INTE innehåller http header x-rivta-original-serviceconsumer-hsaid, skall tjänsteplattformen infoga denna http header i utgående anrop och sätta värdet till anropande tjänstekonsuments identitet.
Detta görs för att nästa komponent i kedjan inte kommer att kunna läsa ursprungsavsändarens certifikat.
Källa: RIVTA Basic Profile 2.1 Valfria tillägg [R4] Regel #2
Detta regleras inte i RIVTA Basic Profile 2.0.
4.2.4 Vidarebefordran av http header
Om ett inkommande anrop kommer från en tjänsteplattform och innehåller http header x-rivta-original-serviceconsumer-hsaid så ska denna http header skickas vidare oförändrad, förutsatt att anropet kommer från en tjänsteplattform som betraktas som känd. Detta kan fastställas t.ex. genom att hålla en lista på betrodda tjänsteplattformars ip-adresser eller funktionscertifikat.
Källa: RIVTA Basic Profile 2.1 Valfria tillägg [R4] Regel #4
Detta regleras inte i RIVTA Basic Profile 2.0.
4.2.5 Logisk adressering
Alla tjänstekomponenter skall förutsätta att inkommande meddelanden har en specificerad mottagare i form av en logisk adress. Den logiska adressen återfinns i en SOAP Header med följande namn:
- RIVTA Basic Profile 2.0: {http://www.w3.org/2005/08/addressing}:To
- RIVTA Basic Profile 2.1: {urn:riv:itintegration:registry:1}:LogicalAddress
Källa: RIVTA Basic Profile 2.0 och 2.1 [R3] Regel #8
4.2.6 Exponering av URL:er
Tjänsteproducenter och tjänsteplattformar bör exponera URL:er som innehåller följande beståndsdelar:
- Huvudversion av aktuellt tjänstekontrakt
- Kortnamn på den version av RIV-TA Basic Profile som används
Exempel: https://tidbok.landsting.sjunet.org/crm/scheduling/MakeBooking/1/rivtabp21
Källa: RIVTA Basic Profile 2.1 [R3] Regel #19.
Detta regleras inte i RIVTA Basic Profile 2.0.
4.2.7 Tekniska fel
I de fall där en tjänstekomponent behöver generera ett felmeddelande som beskriver ett tekniskt fel, skall detta göras med hjälp av SOAP Faults. Detta till skillnad från logiska fel, som ska kommuniceras med vanliga svarsmeddelanden och definieras i respektive tjänstekontraktsbeskrivning.
Källa: RIVTA Tjänsteschema 2.1 [R5] Regel #11
Detta regleras inte i RIVTA Tjänsteschema 2.0.
5. Virtualiseringsplattform
Virtualiseringsplattformen agerar som en ställföreträdare för alla tjänsteproducenter som implementerat ett tjänstekontrakt och anslutit till aktuell tjänsteplattform. Den uppträder som om det enbart fanns en tjänsteproducent, men dirigerar frågemeddelanden vidare till de faktiska tjänsteproducenterna och förmedlar svarsmeddelandet i retur.
En virtualiseringsplattform behöver kunna stödja flera olika RIV TA-profiler. Dessa profiler kan ha olika regler för hur t.ex. meddelandens logiska adress förmedlas (se kap. 4 för information om den senaste versionen).
Virtualiseringsplattformen har tillkommit för att uppfylla T-bokens arkitekturella princip om lös koppling mellan tjänstekonsumenter och -producenter.
5.1 Regler
Regel #1: Datakommunikation
Virtualiseringsplattformen skall följa alla kommunikationsregler i aktuella RIV TA-profiler.
Regel #2: Åtkomstkontroll
Virtualiseringsplattformen skall ha möjlighet att vid inkommande anrop kontrollera åtkomstbehörigheten för kombinationen av följande:
- Anslutande tjänstekonsument (kan vara en annan tjänsteplattform)
- meddelandets logiska mottagaradress
- anropat tjänstekontrakt
Åtkomstbesluten skall baseras på information som lagras i tjänsteadresseringskatalogen. Om åtkomst inte tillåts skall den inkommande förfrågan inte vidarebefordras. Istället skall ett felmeddelande returneras, enligt aktuell RIV TA-profil.
Källa: [R2] Kapitel 8.5
Regel #4: Vägval för anrop
För att kunna vidarebefordra inkommande meddelanden till rätt tjänsteproducent, behöver virtualiseringsplattformen kunna slå upp den tekniska adress som meddelandet ska vidarebefordras till. Denna information tas fram ur den information som är registrerad i tjänsteadresseringskatalogen utifrån följande kriterier:
- meddelandets logiska mottagaradress
- anropat tjänstekontrakt, inkl. tjänstedomän och kontraktets huvudversion
- anropad RIVTA-profilversion
#4
Detta regleras inte i RIVTA Basic Profile 2.0.
4.2.5 Logisk adressering
Alla tjänstekomponenter skall förutsätta att inkommande meddelanden har en specificerad mottagare i form av en logisk adress. Den logiska adressen återfinns i en SOAP Header med följande namn:
- RIVTA Basic Profile 2.0: {http://www.w3.org/2005/08/addressing}:To
- RIVTA Basic Profile 2.1: {urn:riv:itintegration:registry:1}:LogicalAddress
Källa: RIVTA Basic Profile 2.0 och 2.1 [R3] Regel #8
4.2.6 Exponering av URL:er
Tjänsteproducenter och tjänsteplattformar skall exponera URL:er enligt reglerna i RIVTA Basic Profile 2.1 [R3] Regel #19.
Detta regleras inte i RIVTA Basic Profile 2.0.
4.2.7 Tekniska fel
I de fall där en tjänstekomponent behöver generera ett felmeddelande som beskriver ett tekniskt fel, skall detta göras med hjälp av SOAP Faults. Detta till skillnad från logiska fel, som ska kommuniceras med vanliga svarsmeddelanden och definieras i respektive tjänstekontraktsbeskrivning.
Källa: RIVTA Tjänsteschema 2.1 [R5] Regel #11
Detta regleras inte i RIVTA Tjänsteschema 2.0.
5. Virtualiseringsplattform
Virtualiseringsplattformen agerar som en ställföreträdare för alla tjänsteproducenter som implementerat ett tjänstekontrakt och anslutit till aktuell tjänsteplattform. Den uppträder som om det enbart fanns en tjänsteproducent, men dirigerar frågemeddelanden vidare till de faktiska tjänsteproducenterna och förmedlar svarsmeddelandet i retur.
En virtualiseringsplattform behöver kunna stödja flera olika RIV TA-profiler. Dessa profiler kan ha olika regler för hur t.ex. meddelandens logiska adress förmedlas (se kap. 4 för information om den senaste versionen).
Virtualiseringsplattformen har tillkommit för att uppfylla T-bokens arkitekturella princip om lös koppling mellan tjänstekonsumenter och -producenter.
5.1 Regler
Regel #1: Datakommunikation
Virtualiseringsplattformen skall följa alla kommunikationsregler i aktuella RIV TA-profiler.
Regel #2: Åtkomstkontroll
Virtualiseringsplattformen skall ha möjlighet att vid inkommande anrop kontrollera åtkomstbehörigheten för kombinationen av följande:
- Anslutande tjänstekonsument (kan vara en annan tjänsteplattform)
- meddelandets logiska mottagaradress
- anropat tjänstekontrakt
Åtkomstbesluten skall baseras på information som lagras i tjänsteadresseringskatalogen. Om åtkomst inte tillåts skall den inkommande förfrågan inte vidarebefordras. Istället skall ett felmeddelande returneras, enligt aktuell RIV TA-profil.
Källa: [R2] Kapitel 8.5
Regel #3: Utgått
Regel #4: Vägval för anrop
För att kunna vidarebefordra inkommande meddelanden till rätt tjänsteproducent, behöver virtualiseringsplattformen kunna slå upp den tekniska adress som meddelandet ska vidarebefordras till. Denna information tas fram ur den information som är registrerad i tjänsteadresseringskatalogen utifrån följande kriterier:
- meddelandets logiska mottagaradress
- anropat tjänstekontrakt, inkl. tjänstedomän och kontraktets huvudversion
- anropad RIVTA-profilversion
Virtualiseringsplattform kan utöka adresseringsmodellen med att använda en kombination av information i tjänsteadresseringskatalogen och organisationsdata för att på så sätt administrera teknisk adressering enligt en hierarkisk modell där alla underliggande enheter adresseras med samma tekniska adress som den som registrerats i tjänsteadresseringskatalogen (se mer information i separat dokumentation kring modellen [R9])
Regel #5: Vidarebefordran av anrop
...
Virtualiseringsplattformen skall kunna översätta inkommande anrop från en version av RIV-TA till en annan. Skillnader mellan RIV TA-versioner kan t.ex. gälla utformning av SOAP-meddelanden eller säkerhetsmekanismer och kan utläsas i dokumentationen för respektive version.
Regel #7 Utgått
Regel #8: Felkoder
Virtualiseringsplattformen skall returnera felmeddelanden enligt respektive RIV TA-profil, med följande felkoder och i följande felsituationer:
...
Den primära konsumenten av informationen i tjänsteadresseringskatalogen är Virtualiseringsplattformen (VP). Kommunikationen mellan VP och TAK regleras inte av några nationella tjänstekontrakt.
Tjänsteadresseringskatalogen kan kombineras med organisationsdata se också "Regel #4: Vägval för anrop"
6.1 Regler
Regel #1: Lagring av vägvalsinformation
...