Utbildningsdag T-bok och RIV TA

En presentation över ämnet: "Utbildningsdag T-bok och RIV TA"— Presentationens avskrift:

1 Utbildningsdag T-bok och RIV TA 2014-03-05
Lennart Eriksson Lars Erik Röjerås

2 Agenda 10:00 – 10:05 Introduktion (Lennart)
10:05 – 10:30 Informatik m.m. (Lennart) 10:30 – 11:00 T-boken (Lennart) 11:00 – 11:15 Rast 11:15 – 11:35 RIVTA anvisningar (Leo) 11:35 – 11:45 Tjänstekontraktsbeskrivningen (Lennart) 11:45 – 12:30 Lunch 12:30 – 13:25 Konfigurationsstyrningen (Leo) 13:25 – 13:30 Rast 13:30 – 15:00 Tjänsteplattformen, SKLTP inkl. processer (Anders) 15:00 – 15:15 Fika med bulle 15:15 – 15:45 Säkerhetstjänster (Björn) 15:45 – 16:00 Frågor och Avslutning

3 Introduktion

4 Processer Arkitektur och regelverk Informatik VIFO karta
Sonja Kantonen VIFO karta Vägledning för innovativ applikationsutveckling Kvalitetssäkring

5 VIFO-karta (Vårdens informations och
funktionskarta) I arbetet med en effektiv tjänsteutveckling ingår det att se till att tjänsterna får en - logisk och förvaltningsbar struktur. Till det har den sk VIFO-kartan (Vård och omsorgs informations och funktionskarta) använts. Här visas kartan i en version som används för att kunna namnsätta förvaltningsbara domäner.  Namnsättningen av en tjänstedomän (som ska anslutas till gemensamma tjänsteplattformen) görs i tre nivåer och med ströd av strategin för Nationell E-hälsa på översta nivån (Detta ör en administrativ indelning och har enbart svenskt namn, individ, medarbetare, beslutsfattare, infrastruktur) För Nivå 2 och 3 används VIFO-kartans struktur och namn ges på både svenska och engelska, det engelska ingår sedan i det tekniska namnet. Projektets placering i VIFO-kartan brukar göras tidigt inom ett projekt och vid namnsättning används resultatet av den aktiviteten. Som exempel Område Medarbetare, svenskt domännamn Vård och omsorgsprocess på engelska clinical process (nivå 2) Hantera aktiviteter, remiss (nivå 3) på engelska acitivity, reguest och det tekniska namnet blir clinical process:activilty:request (dvs nivå 2 och 3).Godkänt namn används sedan i dokumenytatione enligt RIV-TA. Många domäner har tagits fram innen den här modellen började användas, det sker en succesiv överföring från de ”gamla” domännamnen till namn enligt ny struktur.

6 Vägledning för innovativ applikations- och tjänsteutveckling
Vägledningen beskriver vilka olika mallar utvecklingsprojekt ska använda sig av för att uppnå hög kvalitet i de tjänster som utvecklas. I dokumentationen som levereras ska framgå hur tjänsten är tänkt att användas, hur informationen hanteras lagligt och verksamhetsmässigt, För den tekniska utveklingen i projektet används RIV-TA. Informationsspecifikationen: här ingår flödesbeskrivning, informationsklassning och informationsmodell. Icke funktionella krav: ”kvalitetskrav på informationshanteringe, bör användas som ett verktyg för kommunikation och för att skapa samsyn. Bör användas redan från projektstart och detaljeras efterhand. I mallar förTKB och SAD har båda krav att icke funktionella krav ska anges. AB: Används för att beskriva vilka avsteg från regelverket som är gjorda inom akutell utveckling. Det är ett underlag för den kommande förvalntingen av projektresultatet där beslut ska tas om hand och åtgärdas. Tjänstekontraktsbeskrivning: kompletterar den maskinläsbara anvisningen och ör en teknisk anvisning som är baserad å¨resultat från tidigare faser i projektarbetet. Dokumentet ska kunna läsas fristående. SAD: Är en beskrivning som kompletterar den producerade källkoden och ska kuna läsas fristående. Den beskriver de arkitektuella huvuddragen i en tänkt eller genomförd teknisk implementation/lösning. Kvalitetssäkring: TKB läses och om ”alla är överens” klassas dokumenten som ww.cehis.se/arkitektur_och_regelverk/regelverk/.

7 T-boken och RIVTA anvisningar
Bakgrund Strategi Strategi för tänkt teknisk arkitektur T-boken Genomgång av T-bokens kapitel och dess innehåll grovt sett Domänbegreppet RIVTA anvisningar

8 Strategi för den tekniska verktygslådan
Tjänsteplattformar lokal/regional gemensam Gemensamma standarder RIVTA SAMBI Gemensamma kontrakt/funktioner Domäner för information (VIFO) Tjänstekontraktsbeskrivningar Gemensamma applikationer NPÖ Pascal Lokal tjänsteutveckling Med tydlig kommunikation När lådan är fylld kan vi ta med krav på att den användes i våra Upphandlingar! För att vi skall kunna få upp farten måste alla tillsammans följa gemensamma standarder och riktlinjer. Om vi dessutom dokumenterar och förvaltar enligt uppsatta mål kan alla återanvända det som skapa både centralt men även lokalt. Tjänsteplattformar kommer effektivt kunna knyta ihop det som finns att tillgå lokalt/regionalt och gemensamt. Om kommunikation om domänernas innehåll och funktion samt förvaltning blir tydlig kan vi lättare hitta var/vad som finns att återanvända/utveckla. Genom att använda de framtagna komponenterna kan vi komma till ett läge där vi i upphandlingssituationer kan kravställa att det som finns användes. Det gäller då Gemensam drift Gemensamma plattformar Gemensam och regionala säkerhetstjänster Gemensamma och regionala tjänster som inte behöver ingå i alla upphandla lösningar Gemensamma funktioner kan användas där de fyller en bra funktion Sammantaget kan vi få en öppnare och tydligare marknad där även små leverantörer kan verka.

9 Tekniska perspektivet (T-boken)
T-boken, teknisk referensarkitektur för samverkan RIV tekniska anvisningar, utbyte av information, WS-I Konceptuell beskrivning av samband Säkerhetstjänster, NPÖ, SITHS och HSA Utredning kring tjänsteväxel, brygga mot externa parter Anslutningsarkitektur, för vårdgivare Strategi för samverkan, inklusive identitetshantering Övergripande beskriva vad som skall finnas och hur T-boken skall ses i sitt sammanhang. 9

10 Innehållsförteckning T-boken

11 Innehållsförteckning T-boken i kortform

12 Konceptuell bild av T-bokens omgivning
Ingångar för Invånare, företagare och utförare Kommunikation med andra landsting, kommuner och utförare Kundvård och gemensamma vyer över kundengagemang, ärenden, diarium, kunder, … Verksamhetssystem per förvaltning eller bolag Gemensamma register Gemensamma stödsystem Integration och standardiserade meddelanden Kommunikation med statliga myndigheter T-boken och arkitekturens plats i ”universum” Det finns många intressenter och det ställs stora krav på ingångar omfattning m.m. Ingång för medarbetare Referensarkitekturen beskriver förutsättningar för anslutning till den gemensamma samordnade arkitekturen

13 RIV Tekniska anvisningar
Åtta anvisningar Öppen förvaltning styrd av principer Creative Commons CC-BY-SA ( ) Tjänstekontraktens ”VAD” Kontrakt Domänbegreppet Framtid Vilka anvisningar håller vi på att ta fram (Tjänstekontraktens ”HUR” Krav för hantering på rivta siten – hur (konfigurationsstyrning) Kommer i ett senare pass) Principerna är beskrivna i översikten. Får använda och modifiera, även kommersiellt. Dock enbart under motsvarande licens, och alltid ange ursprunget.

14 http://rivta.se/documents/ RIV TA RIV TA RIV TA RIV TA RIV TA RIV TA
Basic Profile RIV TA Basic Profile Intygsprp RIV TA Domän- schema RIV TA Konfig- styrning RIV TA Release Notes RIV TA Tjänste- schema RIV TA Översikt RIV TA Öppen källkod Visa var de ligger på rivta.se. RIVTA är ett begrepp vi använder på flera olika företeelser. Låt oss titta på de specifika anvisningarna (dokumenten).

15 http://rivta.se/documents/ARK_0007 RIV TA RIV TA RIV TA RIV TA RIV TA
Basic Profile RIV TA Basic Profile Intygsprp RIV TA Domän- schema RIV TA Konfig- styrning RIV TA Release Notes RIV TA Tjänste- schema RIV TA Översikt RIV TA Öppen källkod Gås igenom i ett kommande pass.

16 RIV Tekniska anvisningar
RIV TA Basic Profile RIV TA Basic Profile Intygsprp RIV TA Domän- schema RIV TA Release Notes RIV TA Tjänste- schema RIV TA Översikt RIV TA Öppen källkod

17 http://rivta.se/documents/ARK_0008 RIV TA RIV TA RIV TA RIV TA RIV TA
Basic Profile RIV TA Basic Profile Intygsprp RIV TA Domän- schema RIV TA Release Notes RIV TA Tjänste- schema RIV TA Översikt RIV TA Öppen källkod Skall tillämpas av nationellt beställda och finansierade projekt. Klassificering i sex nivåer baserat på öppenhet av; licens, källkod, kommunikation, deltagande och beslutsforum Licensform för leverabler Upphovsrätt och ägarskap till källkod och andra leverabler Best practice i form av direktiv baserat på klassificering Google code rekommenderas – kan omprövas Rekommendationer kring licentyper

18 RIV Tekniska anvisningar
RIV TA Basic Profile RIV TA Basic Profile Intygsprp RIV TA Domän- schema RIV TA Release Notes RIV TA Tjänste- schema RIV TA Översikt

19 http://rivta.se/documents/ARK_0009 RIV TA RIV TA RIV TA RIV TA RIV TA
Basic Profile RIV TA Basic Profile Intygsprp RIV TA Domän- schema RIV TA Release Notes RIV TA Tjänste- schema RIV TA Översikt Enbart release notes från v1 till v2 av RIV TA.

20 RIV Tekniska anvisningar
RIV TA Basic Profile RIV TA Basic Profile Intygsprp RIV TA Domän- schema RIV TA Tjänste- schema RIV TA Översikt

21 http://rivta.se/documents/ARK_0003 RIV TA RIV TA RIV TA RIV TA RIV TA
Basic Profile RIV TA Basic Profile Intygsprp RIV TA Domän- schema RIV TA Tjänste- schema RIV TA Översikt Intygspropagering: ”Elementet Assertion från SAML 2.0 Core skall användas för att i soap-header specificera intyg för den medarbetare eller invånare vars identitet skall intygas.” Används ej idag.

22 RIV Tekniska anvisningar
RIV TA Basic Profile RIV TA Domän- schema RIV TA Tjänste- schema RIV TA Översikt

23 RIV TA RIV TA RIV TA RIV TA Tjänste- Domän- Basic Profile schema
Översikt RIV TA Tjänste- schema RIV TA Domän- schema RIV TA Basic Profile

24 http://rivta.se/documents/ARK_0001 RIV TA RIV TA RIV TA RIV TA
Översikt RIV TA Tjänste- schema RIV TA Domän- schema RIV TA Basic Profile

25 Det handlar om tjänstekontrakt
Vägled- ning Hänvisar till RIV TA Översikt Hänvisar till SITHS f-cert T-boken Principer Adressering ställer krav på W3C, OASIS mfl internationella standarder inom XML och WS RIV TA Tjänste- schema RIV TA Domän- schema RIV TA Basic Profile Nått fram till kärnan. Vägledningen återkommer senare. Sammanhållande anvisning som bl a pekar ut RIVTA. Man kan se RIVTA som en detaljering av T-boken. Nödvändig detaljnivå för att kunna realisera. TP (och SKLTP) förutsätter att de WS som integreras följer RIVTA. Trafiken är krypterad och SITHS-certifikat används för att identifiera parter. Baseras på TP* Förutsätter följsamhet mot

26 RIV Tekniska anvisningar bygger på
T-boken - SOA The OASIS Web Services Interoperability (WS-I). SOAP 1.1 specification WSDL 1.1 specification I grunden är vår referensarkitektur som den är beskriven I T-boken en Service Oriented Architecture – SOA. WS-I BP 1.1 This document defines the WS-I Basic Profile 1.1, consisting of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

27 Fokusområden (tillägg till industristandarderna)
Interoperabilitet Design för framåt/bakåtkompatibilitet Stöd för referensarkitekturens adresseringsmodell Standards för namngivning Stöd för de interaktionstyper (mönster) som beskrivs i referensarkitekturen Fråga-svar Uppdrag-resultat Informationsspridning (Marknadsplats) Man kan se RIVTA som en mycket tunt lager ovanpå dessa standarder. RIVTA handlar om interoperabilitet, åtkomst till web services. Kompatibiliteten mycket viktig vid många anslutna. Logisk adressering, verksamhetsadressering, HSA-id. Detaljerad namnsättning baserad på profiler och dess version, tjänstedomäner och kontrakt, samt versioner. Enbart Fråga-svar används i dagsläget. Uppdrag-resultat på gång inom Intygsprojektet.

28 Gemensamma tjänstekontrakt
Virtuella IT-tjänster i tjänsteplattformen Get EHR-extract Get Patient Schedule Make Bookin g Get Listing … Scheduling (tidbokning) Carelisting (vårdval) Ehrexchange (journal) … Vi utvecklar tjänstekontrakt ”Virtuell nationell tjänst” – som inte finns. Jfr ”nationell listningstjänst”. … Uttrycker ett idealiserat integrationsgränssnitt mot EN nationell tjänst som oftast inte finns. Är ALDRIG definierat utgående från ett system.

29 Gemensamma tjänstekontrakt
Virtuella IT-tjänster i tjänsteplattformen Get EHR-extract Get Patient Schedule Make Bookin g Get Listing … Scheduling (tidbokning) Carelisting (vårdval) Ehrexchange (journal) … Varje kontrakt enbart en operation, se som metoder i en klass. Paketeras i domäner. … Uttrycker ett idealiserat integrationsgränssnitt mot EN nationell tjänst som oftast inte finns. Är ALDRIG definierat utgående från ett system. Ordnas i ”tjänstedomäner” (= förvaltningsobjekt?)

30 Gemensamma tjänstekontrakt
Nationella e-tjänster för medborgare och medarbetare Distansvård på webben Tidbokning på webben Min journal NPÖ Virtuella IT-tjänster i tjänsteplattformen Get EHR-extract Get Patient Schedule Make Bookin g Get Listing … Scheduling (tidbokning) Carelisting (vårdval) Ehrexchange (journal) … Användare, tjänstekonsumenter, av nationella, virtuella, tjänster. Konsumenterna ansluter till TP. … Uttrycker ett idealiserat integrationsgränssnitt mot EN nationell tjänst som oftast inte finns. Är ALDRIG definierat utgående från ett system. Ordnas i ”tjänstedomäner” (= förvaltningsobjekt?)

31 Gemensamma tjänstekontrakt
Nationella e-tjänster för medborgare och medarbetare Distansvård på webben Tidbokning på webben Min journal NPÖ Vårdgivarnas verksamheter med anslutna verksamhetssystem Virtuella IT-tjänster i tjänsteplattformen Get EHR-extract Get Patient Schedule Make Bookin g Get Listing … Scheduling (tidbokning) Carelisting (vårdval) Ehrexchange (journal) … Tjänsteproducenterna måste realisera kontrakten och anslutas till TP. … Uttrycker ett idealiserat integrationsgränssnitt mot EN nationell tjänst som oftast inte finns. Är ALDRIG definierat utgående från ett system. Ordnas i ”tjänstedomäner” (= förvaltningsobjekt?) System och bef. tjänster behöver anpassas (”anslutas”) enligt nationella tjänstekontrakt. De kan både vara producent och konsument av tjänst.

32 VAD bygger upp ett tjänstekontrakt
Dokumentation Tjänstekontraktsbeskrivning (eg. Tjänstedomänsbeskrivning) Arkitekturella beslut (Informationsmodell) Teknisk definition per kontrakt WSDL-fil (metadata för kuvertering, kommunikationsprotokoll och säkerhet) XML Scheman (metadata för fråge- och svarsmeddelanden) Exempel-meddelanden Skript-filer för att generera Java- och .Net-stubbar för konsument och producent Teststöd

33 RIV Tekniska anvisningar
Transport Meddelande Idag fokuserade på SOAP-baserade web services över https: Interop Säkerhet Anvisning -profil 2.1 - Basic Profile Kuvert / Envelope Huvud / Header Innehåll / Body De olika anvisningarna fokuserar på olika delar Anvisning Tjänste-schema 2.1 Avser tekniska aspekter på innehåll: Interop Versionering Anvisning Domän-schema 2.1

34 Tillkommande anvisningar
Iterativ, behovsbaserad, utveckling av RIV TA Även i form av FAQ Under utveckling: Systemadressering och aggregering Realisering av regional plattform Intygspropagering Utökad beskrivning av ytterligare anropsmönster uppdrag-resultat Diskuteras: REST Signering/kryptering Vidareutvecklingen är hela tiden behovsstyrd, och sker tillsammans med projekten, tillsammans med er. Vi använder FAQ för att få ut nya råd anvisningar snabbare. Viktigt att ni hör av er om ni har frågor och förslag kring anvisningarnas förvaltning och vidareutveckling.

35 Tjänstekontraktsbeskrivningen
Vad är Tjänstekontraktsbeskrivningen Skall finnas för en informationsdomän Ingår i kravdokumentationen för aktuell domän och dess kontrakt Är det som alla implementationer av aktuella kontrakt måste uppfylla. Hur denna uppfyllnad sker kan med fördel beskrivas i en SAD (Software Architecture Document) Vad finns i mallen? Var finns dokumentet? DEMO Vi går igenom innehållet i mall och exempel. Mall Exempel För att beskriva en funktionell domän och dess informationsinnehåll finns detta dokument. Dokumentet skall ge en kort beskrivning av vad som skall tillföras i funktionell form. Samtidigt skall alla i området ingående kontrakt finnas noggrant kravställda/specificerade. Det är genom att läsa in detta dokument som olika lösningsarkitekter kan ta fram hur de skulle kunna realisera aktuella kontrakt.

36 Dokumentation http://rivta.se/ - beständig förstasida Google code
- Plattformen, beständig - Slås samman med inera.se? - Slås samman med cehis.se ? RIVTA.SE är den beständiga startsidan.

37 Arkitekturella dokument generellt
ARK-nummer Uppstädning av dokument Anvisningar bestående, dokumenten ”städas” Lagt in ARK-nummer, för länkning TjänsteKontraktsBeskrivning, SAD samt Arkitekturella beslut. För att få länkar som består och alltid pekar på senaste version av aktuellt informationsområde (obs inte diarienummer som pekar på specifikt dokument) har vi genom för en ny samling med URL:er som pekar på ”rätt sak” Detta blir möjligt genom att vi numera äger domänen ”rivta.se” Vi har vid denna genomgång även försökt fixa till länkar m.m. Detta behöver dock fixas till ytterligare en gång. Detta arbete pågår

38 Konfigurationsstyrning
HUR-et Praktisk handledning - Är inte Projektmodell, projektinfrastruktur Kravhantering Ändringshantering Tjänstedomäner Praktisk hantering på siten - hur Tjänstedomäner skall lagras, versionshanteras och releasas Demo

39 Viktiga termer Beskrivning
Version Tjänstekontrakt kan ha olika utgåvor. Varje utgåva benämns version och ska ha en versionsbeteckning. Release När en ny version av den slutgiltiga tjänstedomänen paketerats och är fastställd benämns den Release. Release Candidate (RC) När en version av en tjänstedomän har paketerats och är klar att testas/verifieras benämns den Release Candidate Varje kontrakt har en version på formen X.Y.Z Varje paketering av kontrakt i en domän kallas release – och har ett versionsnummer. Skulle kunnat kalla det en ”distribution”. RC för för-releaser.

40 Konfigurationsstyrning
Tjänstekontraktsutveckling är en egen aktivitet Tjänstedomänen är ett eget förvaltningsobjekt Egen versionshantering, release etc Versionshanteringsfrågor är viktiga Öppen utveckling Återanvändning En egen aktivitet som behöver följa våra anvisningar och granskningsprocesser. Tjänstedomän (TD) är ett eget förvaltningsobjekt – MYCKET viktigt. Skär ju ofta tvärs över befintliga projekt och förvaltningsobjekt. Öppen utveckling, allt ligger (ska ligga) synligt på webbplatsen.

41 Använder Google code (idag)
Källkodsrepository Versionshantering via subversion Wiki Tracker Nedladdningsarea Behörighetshantering Var tidigare på OSOR.

42 Det här behöver vi installera
Klient till Subversion Java Microsoft .Net SDK (Visual Studio) Programspråket Groovy Programspråket Python Windows, MAC och Linux används.

43 Processen för ny tjänstedomän
Namnsättning (namnrymden) beslutad Skaffa konto Anslut till Subversion Skapa mappstruktur enligt namnrymden Skapa Tjänstekontraktsbeskrivning Skapa tekniska filer (WSDL, XSD) Skapa TAG för release candidate (RC) och beställ paketering Skapa TAG release och beställ paketering En domän svarar mot ett funktionsområde inom vården. Mappas mot VIFO-kartan. Namnsättning: Det kanske redan finns en befintlig domän som täcker in det behov ett projekt identifieras. Kontakta för att få ett namn alternativt komma i kontakt med befintlig domän. Så länge vi använder Google code så måste man ha ett Google-konto med behörighet ”committer” för att kunna uppdatera information på siten. Skaffa konto: Många företag använder Google Apps med eget domännamn. Det går även att ansluta ett befintligt konto till ett Google-id, vilket också fungerar. Det ser man tydligt om man tittar i listan över people. Står ingen domän är det konton. Viktigt att fylla i vem man är – vi kommer att bli tuffare på det. Även rensa bort gamla konton. Anslut till Subversion: Navigera runt i kort i källkodsträdet på webben - browse. Instruktion under Source-checkout på Google code Visa utcheckning read-only i Windows – men cancelera efter några sekunder. Visa sidan både utloggad och sedan påloggad på konto som är committer – instruktionen förändras. Gå till förutcheckad och navigera runt i trädet. Poängtera: - Verktyg - Var tjänstedomänerna ligger …\rivta-read-only\ServiceInteractions\riv\crm\scheduling Gå igenom strukturen för en av domänerna: Obs – gamlas namnsättnignsstrukturen Skapa mappstruktur: Kopiera exempelmappen som ligger under tools. Gör en skarp checkout genom att först titta på Google code hur kommandot ska se ut. Använd verkligen svn vid utvecklingen. Viktigt med öppen utveckling! Skapa TKB: Skall ligga i docs-mappen. Titta gärna på hur andra gjort. Även AB skall finnas. Dvs det egentliga utvecklingsarbetet av de tekniska kontrakten. Skapa tekniska filer: WSDL och XSD. Enligt RIVTA som vi talade om tidigare. Verktygsstöd; WSDL-generator, referensapplikationer, testsvit, verifieringsscript Även se wiki. RC beställ paketering: Hittills har det varit att beställa granskning. Vi har tagit över skapandet av zip-fil och uppladdning till arkivet. TAG är här ett begrepp från SVN. Egentligen en kopia av aktuell utvecklingsversion. Ger spårbarhet. Namnsättningsregler står i wiki: Tidigare har vi arbetat med ”beta” och svn-revisionsnummer. Lämnar nu detta till förmån för RC-taggning. Eftersom en tag skapas i SVN behöver vi inte använda revisionsnummer längre. Skapa TAG enligt namnsättningsreglerna. Använd svn copy-kommandot. I praktiken en kopia av trunk in under tags. Meddela sedan Vi granskar och godkänner för installation i TP. Informationen publiceras i ”tabellen”. Release beställ paketering: När alla tester är klara och den första skarpa transaktionen genomförts görs föregående steg om med den slutgiltiga releasen. Innehållet skall vara identiskt med den sista RC.

44 Verktygsstöd Referensapplikation .Net och Java
Kan kopieras för att verifiera egna kontrakt Visar hur klient-kod och serverkod blir Standard JAX WS 2 och .Net WCF 3.5+ Visar hur certifikat kan hanteras för https/tls För varje publicerat tjänstekontrakt: WSDL-first-skript för .Net WCF och JAX-WS Generator finns i form av Groovy-skript Exempel: Tidbokningskontrakten Tjänstekontraktsgenerator Verifieringsscript Använd de verktyg som finns. Vi ”kräver” att generatorn nyttjas.

45 Tjänsteplattformen, SKLTP inkl. processer
Målet med TP Förklaring vad som finns i drift Vad finns Miljöer Vilka tjänster finns idag Vilka tjänster är installerade Process för anslutningar Krav att få vara med på TP SKLTP genomgång av innehåll m.m. Regional plattformskrav Utbildningsmaterial, SKLTP-Box

46 Tänsteplattformen Projekt- och Produktionsansvar Anders Pettersson

47 Agenda Vad/vilka är vi. Hur ser det ut idag, vad körs
Prestanda och tillgänglighet Anslutning Infrastruktur SKLTP Tjänster Framtid

48 Bild om innovationkraft och genomförande
1 eller 2 på innovation och påhittighet 13 plats på genomförande

49 Vision without execution is a hallucination.
Thomas A. Edison

50 Organisation Tjänsteansvarig (Anders Bergman)
Driftsleverantör (Cybercom) Applikationsförvaltning (Callista) Domänutveckling 50% (Anders Ohlsson) Produktionsansvar 50% (Anders Pettersson) Arkitekturansvar 40% (Magnus Larsson+Björn Skeppner) Testkoordinator 50% Krister Eriksson Projektansvar 50% (Anders Pettersson) Organisation

51 Förvaltningsstruktur
Infrastruktur; Hårdvara, nätverk, os… Applikation; Mule, Tomcat… Nationell Tjänsteplattform; Anpassningar, övervakning… Anslutningar, övervakning Förvaltning av tjänstedomäner och tjänstekontrakt Utveckling av tjänstekontrakt Utveckling av invånar- eller vårdtjänst RIV-TA VITS, RIV-specifikation Förvaltning av invånar- eller vårdtjänst CeHis/Arkitektur och Regelverk Projekt/tjänst Tjänstedomän (Ingår i tjänsten from 2013) ICC Nationell tjänsteplattform (tom 2012)

52 Antalet anrop/dygn

53 Antal anslutna verksamheter till domäner

54 Antalet ärenden i kundtjänst…

55 Antalet Kontrakt

56 Antal anrop i genomsnitt per dygn för respektive tjänst

57 Mest använda kontrakt Elektroniskt sjukintyg - från IFV
urn:riv:insuranceprocess:healthreporting:FindAllQuestions:1:rivtabp20 18 121387 urn:riv:insuranceprocess:healthreporting:FindAllAnswers:1:rivtabp20 121300 Infektionsverktyget urn:riv:processdevelopment:infections:ProcessCondition:1:rivtabp20 93 59105 urn:riv:processdevelopment:infections:ProcessCareEncounter:1:rivtabp20 186 57464 Dos-paketerade läkemedel urn:riv:druglogistics:dosedispensing:HamtaOrginalforpackning:1:rivtabp20 225 49564 urn:riv:druglogistics:dosedispensing:HamtaMeddelanden:1:rivtabp20 47089 Erbjuden etjänst urn:riv:eservicesupply:eoffering:GetAvailableEServices:1:rivtabp21 209 42079 urn:riv:druglogistics:dosedispensing:HamtaVardtagareinformation:1:rivtabp20 30220 urn:riv:processdevelopment:infections:ProcessActivity:1:rivtabp20 158 14947 Apotekens Service läkemedelstjänster - AXS urn:riv:inera:se.apotekensservice:axs:HamtaPatientInfo:1:rivtabp20 370 12833 Nationell Listning urn:riv:crm:carelisting:GetListing:1:rivtabp20 571 10724 urn:riv:druglogistics:dosedispensing:SokVardandeEnhet:1:rivtabp20 10426 urn:riv:crm:carelisting:GetPersonQueueStatus:1:rivtabp20 418 9759 Engagemangsindex urn:riv:itintegration:engagementindex:FindContent:1:rivtabp21 47 6848 Tjänstedomän Tjänstekontrakt Svarstid medel Antal anrop / dygn Elektroniskt sjukintyg - från IFV urn:riv:insuranceprocess:healthreporting:FindAllQuestions:1:rivtabp20 22 102144 urn:riv:insuranceprocess:healthreporting:FindAllAnswers:1:rivtabp20 21 102057 Dos-paketerade läkemedel urn:riv:druglogistics:dosedispensing:HamtaOrginalforpackning:1:rivtabp20 319 49602 urn:riv:druglogistics:dosedispensing:HamtaMeddelanden:1:rivtabp20 442 47107 Infektionsverktyget urn:riv:processdevelopment:infections:ProcessCondition:1:rivtabp20 90 46058 Erbjuden etjänst urn:riv:eservicesupply:eoffering:GetAvailableEServices:1:rivtabp21 201 36548 urn:riv:druglogistics:dosedispensing:HamtaVardtagareinformation:1:rivtabp20 263 30218 urn:riv:processdevelopment:infections:ProcessActivity:1:rivtabp20 117 26794 Apotekens Service läkemedelstjänster - AXS urn:riv:inera:se.apotekensservice:axs:HamtaPatientInfo:1:rivtabp20 480 12259 urn:riv:processdevelopment:infections:ProcessCareEncounter:1:rivtabp20 269 11102 Nationell Listning urn:riv:crm:carelisting:GetListing:1:rivtabp20 1015 11006 urn:riv:druglogistics:dosedispensing:SokVardandeEnhet:1:rivtabp20 184 10481 urn:riv:crm:carelisting:GetPersonQueueStatus:1:rivtabp20 372 9841 Engagemangsindex urn:riv:itintegration:engagementindex:FindContent:1:rivtabp21 64 7009

58 Prestanda Vilka krav finns? Vilka påslag görs i TP?
SLA och Kravställningen håller på att formaliseras i ny process – behöver förbättras. Vilka påslag görs i TP? Säkerhetsprojektet uppmätte en OH på ca 100ms ( ) Bygger på att ”keep alive används”

59 Tillgänglighet

60 Struktur - Tjänstedomänansvar
Tjänstedomänansvar i verksamheten: Utveckla och förvalta tjänstedomänen. Tillämpa regelverk och processer vid utveckling och förvaltning av tjänstedomän. Tillhandahålla information och dokumentation om tjänstedomänen. Stödja landsting/regioner/andra vid breddinförande. Samordna krav och koordinera ändringsarbetet för tjänstedomänen. Ansvar för att sprida information om ändringar i tjänstedomänen. Ha kontroll över vilka som nyttjar tjänsten. Finansiera kostnaderna för installation av tjänstekontrakt och anslutningar. Tjänstedomänen planerar utrullningsprojekt och koordinerar och planerar anslutningar tillsammans med tjänsteplattformsförvaltningen. Tjänstedomänen beställer anslutningar och stödjer de som ansluter till domänen.

61 Realisera nytta – från idé till avveckling
Behovsanalys Förstudie Utveckla Förvalta Avveckla Budget. Prioritera. Budget. Prioritera. Budget. Prioritera. Budget. Prioritera. Budget. Prioritera. Välja och styra Objektägare Utse SG och förstudieledare. Utarbeta förstudiedirektiv. Utse TDA och PL. Utarbeta projektdirektiv. Utse förvaltningsledare V & IT. Löpande uppföljning. Löpande ledning och uppföljning. Utse avvecklingsledare. Godkänna avveckling. Leda Förvaltningsledning B1 B2 B3 B4 B5 B6 B7 Q1 Q2 Q5 Q6 Q7 Q4 Använda Överlämna Q3 Objektspecialister Utföra Definiera behov Förstudie Acceptera Underhålla Avveckla Över Utveckla Acc Utv Fs Ba Vad Hur Skapa lösning Skapa värde Upphöra NA Ta emot A-blankett Ansluta prod/kons i SIT-miljö Godkänn införandeplan Ta emot B-,C- och D-blankett x2 Ansluta prod/kons i SIT-miljö Ansluta prod/kons i AV-miljö Ansluta prod/kons till ny TjD Överlämna ny TjD till förvaltning Skapa nytt kontrakt i befintlig TjD Införa nytt kontrakt i befintlig TjD Avveckla kontrakt i befintlig TjD Ansluta ny prod/kons till befintlig TjD Avveckla prod/kons från befintlig TjD Ersätta bef prod med ny prod i befintlig TjD Ansluta prod/kons i SIT-miljö Ansluta prod/kons i AV-miljö Följa upp nyckeltal Ersätta bef TjD med uppgraderad TjD Avveckla kontrakt i TjD Avveckla TjD Avveckla prod/kons från TjD Skapa slutrapport

62 Process för anslutning
B C D

63 Beställning A Godkända kontrakt av A&R
Ska finnas Tjänstedomänansvarig (TDA) TDA skickar in beställning på blankett Kontrakten testas i QA TDA godkänner test Kontrakten installeras i prod Anslut parter

64 Beställning B och C Funktionscertifikat för alla miljöer (QA och Prod)
TDA beställer anslutning av konsument eller producent TP förberes med brandväggsöppningar samt konfig TAK (Tjänsteadresseringskatalog). Part testar i QA. Efter godkännande av TDA flytt från QA till Prod

65 Miljöer Utv SKLTP-BOX Paketerad i en virtuell maskin för utbildning, utvärdering och lokala tester Test Finns ej Integrationstest Håller på att Byggas upp QA Produktion

66 SKLTP 2.2.1 Tjänsteplattformen Vad är vad?
Är implementationen av T-boken, funktionalitet. Är ”plattformsoberoende” Bygger på RIV-TA och fastställda specifikationer Är en release Mjukvara (b.la Mule) Stödfunktionalitet Infrastruktur Process och anslutning

67 Vad är Mule ESB? Den ledande Open Source ESB’n… Två paketeringar
Mule ESB Community Edition Mule ESB Enterprise Edition Utvecklingsverktyg Mule Studio Mule ESB EE tillägg Mule ESB Support Data Mapper Mule Management Console CloudHub Anypoint Enterprise Security Anypoint Enterprise Registry Mule ESB High Availability

68

69 VP

70 Aggregering

71 EI

72 Processer och rutiner Skalbarhet i teknik och organisaton
Etablering ICC Ny modell för hantering av domänutveckling/förvaltning

73 Regionala plattformar
I strategin finns en decentraliserad struktur Inte bygga en administrativkoloss längst upp Tjänsteifiering

74 Framåt Plattformsutveckling Regionala plattformar
Meddelande Notifiering Axel RIV/SHS brygga RIV/SSEK brygga kommer att byggas EI – utbyggnad Regionala plattformar Skalbarhet i teknik och organisaton Driftsmigrering – byte av leverantör Ny målarkitektur 2.0 Etablering ICC Ny modell för hantering av domänutveckling/förvaltning

75 Bra länkar www.skltp.se www.rivta.se
Vilka tjänster/kontrakt finns i vilken miljö Anslutnings-FAQ (teknisk)