Utbildningsdag 2013-11-28 2013-11-28 Leriks och Leo Slussen

Agenda 10:00 – 10:10 Introduktion (Helena) 10:10 – 10:45 Processer (Ewa) 10:45 – 10:50 Rast 10:50 – 11:30 T-boken och RIVTA anvisningar (Lennart) 11:30 – 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 – 16:00 Diskussion, frågor och Avslutning

Introduktion

Processer Processer Aktiviteter VIFO karta Vägledning för innovativ applikationsutveckling Kvalitetssäkring Kommer snart 

Processer inom Arkitektur och regelverk (dvs hur vi arbetar) Arkitekturstöd CeHis Röda processer ännu inte beskrivna Nästa projekt etapp Förslag Ide Stöd för-studie Stöd Innovativ tjänste- utveckling Stöd beställning Cehis- beställnig Beställning utveckling Förv. objekt Verksam- hetsplan Stöd förvaltnings- plan Förvaltnings- plan Övrigt stöd Röda delprocesser inte helt klara. Stöd för innovativ applikations- och tjänsteutveckling för detaljer se aktivitetskarta nästa bild. Dokument för ”kommentarer” Frågor om regelverk Övriga frågor Andra fråge-ställningar Stöd till frågeställare

Aktiviteter Beställning av utv. projekt/(förändring i förvaltnings-objekt) Startmöte 1 Avstämning 2 6 Kontakt med projekt 5 Ta emot dokument i ”slutversion”. 3 Läsa och kommentera 4 Stöd innovativ applikations- och tjänsteut-veckling Möte med projekt Inga röda Kommentarer 1 el flera röda 7 Klart för publicering på RIV-TA site Självförklarande. Nästa etapp Förvaltning

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.

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/.

Kvalitetssäkring Kategorier av kontrakt som är beställda av Cehis Gemensamma (fd nationella): Godkänd inom alla perspektiv A&R. Kan installeras på den gemensamma tjänste-plattformen.Följer uppsatta regelverk Delvis gemensamma:Några (men inte alla) tjänstekontrakten inom domänen är godkända av alla grupper (VITS). Kan installeras på gemensamma tjänsteplattformen. Projektspecifika:Följer RIVTA. Kan installeras på den gemensamma tjänsteplattformen under vissa förutsättningar. - Arkitekturellt beslut - Tidsbegränsat/omfattningsbegränsat - Begränsad anslutning Perspektiv: Verksamhet, informationsstruktur, informationssäkerhet och teknik

Kvalitetssäkring, övrigt SAD:ar för ”egna” utvecklingsprojekt granskas ur tekniskt och informationssäkerhetsperspektiv. Övriga tjänster/applikationer behöver ”certifieras” (här pågår ett arbete)

Snart kommer Vägledning för informationssäkerhetsarbete, i och kring de nationella gemensamma tjänsterna (ersätter den gamla ”S-boken”) Syftet med dokumentet är att dra upp riktlinjer för ansvarsfördelningen mellan olika aktörer vid leverans och användning av nationella tjänster. Omfattar: Informationssäkerhets krav för gemensamma tjänster som är framtagna och beslutade av vårdgivarna gemensamt via CeHis. Det finns som bilaga en mall där leverantörerna av e-hälsotjänster årligen ska deklarera området informationssäkerhet för varje tjänst de levererar. Vi får då en transparens inom området och vårdgivarna kan välja att ”skruva upp” eller skruva ner” nivån. Som ansvarig för informationen är det nödvändigt att ha en god uppfattning om hur biträdet hanterar informationen. Informationsägaren /personuppgiftsansvarig måste kunna säkerställa att: leverantören hanterar informationen på ett sätt som stämmer med gällande lagar. leverantören hanterar informationen på ett sätt som är förenligt med kundens/ vårdgivarens informationssäkerhetspolicy och ledningssystem för informationssäkerhet. leverantören inte tar större risker för informationssäkerheten än Informationsägaren/ personuppgiftsansvarig är medveten om, och finner acceptabelt

Till sist… arkitektur@cehis.se

T-boken och RIVTA anvisningar Bakgrund Strategi 2013-2018 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

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.

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. 2018-09-17 15

Innehållsförteckning T-boken http://rivta.se/documents/ARK_0019

Innehållsförteckning T-boken i kortform http://rivta.se/documents/ARK_0020

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 2018-09-17

RIV Tekniska anvisningar - innehåll Åtta anvisningar Öppen förvaltning styrd av principer Creative Commons CC-BY-SA (http://creativecommons.org/licenses/by-sa/2.5/se/ ) 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.

http://rivta.se/documents/ 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).

http://rivta.se/documents/ARK_0007 RIV TA Basic Profile RIV TA 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.

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

http://rivta.se/documents/ARK_0008 RIV TA Basic Profile RIV TA 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

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

http://rivta.se/documents/ARK_0009 RIV TA Basic Profile RIV TA 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.

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

http://rivta.se/documents/ARK_0003 RIV TA RIV TA 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.

RIV Tekniska anvisningar RIV TA Basic Profile RIV TA Domän- schema RIV TA Tjänste- schema RIV TA Översikt Bläddra snabbt

RIV TA RIV TA Tjänste- schema RIV TA Domän- schema RIV TA Översikt RIV TA Tjänste- schema RIV TA Domän- schema RIV TA Basic Profile Bläddra snabbt

http://rivta.se/documents/ARK_0001 RIV TA RIV TA Tjänste- schema Översikt RIV TA Tjänste- schema RIV TA Domän- schema RIV TA Basic Profile Bläddra snabbt http://rivta.se/documents/ARK_0005 http://rivta.se/documents/ARK_0006 http://rivta.se/documents/ARK_0002

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. RIVTA bygger på ett antal mycket väletablerade industristandarder. Baseras på TP* Förutsätter följsamhet mot

RIV Tekniska anvisningar bygger på T-boken - SOA The OASIS Web Services Interoperability (WS-I). http://www.ws-i.org/Profiles/BasicProfile-1.1.html SOAP 1.1 specification http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ WSDL 1.1 specification http://www.w3.org/TR/wsdl 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.

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 som beskrivs i referensarkitekturen Fråga-svar Uppdrag-resultat Informationsspridning 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.

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.

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. 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?)

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, konsumenter, 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?)

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) … Producenterna 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.

VAD bygger upp ett tjänstekontrakt Tjänstekontraktsbeskrivning (eg. Tjänstedomänsbeskrivning) 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

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

Tillkommande anvisningar Iterativ, behovsbaserad, utveckling av RIV TA Även i form av FAQ Under utveckling: Realisering av regional plattform HTTP header för ursprunglig konsument Statusrapportering för aggregerade tjänster Intygspropagering Utökad beskrivning av mönster uppdrag-resultat Diskuteras: REST Systemadressering 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.

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 http://rivta.se/documents/ARK_0015/ Exempel http://rivta.se/documents/ARK_0016 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.

Dokumentation http://rivta.se/ - beständig förstasida Google code http://rivta.se/wiki http://rivta.se/servicedomaintable http://rivta.se/source http://rivta.se/issues http://rivta.se/downloads http://rivta.se/documents http://skltp.se/ - Plattformen, beständig http://cehis.se/ - Slås samman med inera.se? http://www.inera.se/ - Slås samman med cehis.se ? RIVTA.SE är den beständiga startsidan.

Arkitekturella dokument generellt ARK-nummer http://rivta.se/documents http://rivta.se/documents/ARK_0019 Uppstädning av dokument Anvisningar bestående, dokumenten ”städas” Lagt in ARK-nummer, för länkning TjänsteKontraktsBeskrivning, SAD samt Arkitekturella beslut. http://rivta.se/documents/ARK_0013 http://rivta.se/documents/ARK_0015 http://rivta.se/documents/ARK_0023 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

Konfigurationsstyrning HUR-et Praktisk handledning - http://rivta.se/documents/ARK_0007 Är inte Projektmodell, projektinfrastruktur Kravhantering Ändringshantering Tjänstedomäner Praktisk hantering på siten -hur TD skall lagras, versionshanteras och releasas Vi publicerade v2 för två veckor sedan, det är den som beskrivs. Demo

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.

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. TD egen 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.

Använder Google code (idag) Källkodsrepository Versionshantering via subversion Wiki Tracker Nedladdningsarea Behörighetshantering https://code.google.com/p/support/wiki/GettingStarted Var tidigare på OSOR.

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

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 Namnsättning: En domän svarar mot ett funktionsområde inom vården. Mappas mot VIFO-kartan. Det kanske redan finns en befintlig domän som täcker in det behov ett projekt identifieras. Kontakta arkitektur@cehis.se för att få ett namn alternativt komma i kontakt med befintlig domän. Skaffa konto: 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. Många företag använder Google Apps med eget domännamn, vilket också fungerar. Det ser man tydligt om man tittar i listan över people. Står ingen domän är det ”@gmail.com” 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 sidan både utloggad och sedan påloggad på konto som är committer – instruktionen förändras. Visa utcheckning read-only i Windows – men cancelera efter några sekunder. Gå till förutcheckad och navigera runt i trädet. Poängtera: - Verktyg - Var tjänstedomänerna ligger Gå igenom strukturen för en av domänerna: …\rivta-read-only\ServiceInteractions\riv\crm\scheduling Obs – gamlas namnsättnignsstrukturen Skapa mappstruktur: Gör en skarp checkout genom att först titta på Google code hur kommandot ska se ut. Kopiera exempelmappen som ligger under tools. Använd verkligen svn vid utvecklingen. Viktigt med öppen utveckling! Skapa TKB: http://rivta.se/documents/ARK_0015 Skall ligga i docs-mappen. Titta gärna på hur andra gjort. Skapa tekniska filer: Dvs det egentliga utvecklingsarbetet av de tekniska kontrakten. 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 kommer att ta ö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. 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. Namnsättningsregler står i wiki: http://code.google.com/p/rivta/wiki/FAQ#Namnsättning_och_versionshantering Skapa TAG enligt namnsättningsreglerna. Använd svn copy-kommandot. I praktiken en kopia av trunc in under tags. Meddela sedan arkitektur@cehis.se Vi kommer att granska och godkänna för installation i TP. Informationen publiceras i ”tabellen”. Vi kommer även i närtid att börja hantera att skapa zip samt ladda upp. 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.

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 http://rivtatools.callistaenterprise.se/ Verifieringsscript på gång (automation) Använd de verktyg som finns. Vi ”kräver” att generatorn nyttjas.

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

Projekt- och Produktionsansvar Anders Pettersson Tänsteplattformen Projekt- och Produktionsansvar Anders Pettersson

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

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

Vision without execution is a hallucination. Thomas A. Edison

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

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)

Antalet anrop/dygn

Antal anslutna verksamheter till domäner

Antalet ärenden i kundtjänst…

Antalet Kontrakt

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

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

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 (2013 04 12) Bygger på att ”keep alive används”

Tillgänglighet

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.

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

Process för anslutning B C D

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

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

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

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

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

VP

Aggregering

EI

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

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

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

Bra länkar www.skltp.se www.rivta.se Vilka tjänster/kontrakt finns i vilken miljö https://skl-tp.atlassian.net/wiki/pages/viewpage.action?pageId=14090468 Anslutnings-FAQ (teknisk) https://skl-tp.atlassian.net/wiki/display/NTJP/FAQ+Teknik http://www.inera.se/TJANSTER--PROJEKT/Tjansteplattform/