Kompetensforum för nationell arkitektur Presentationsmaterial 26 maj 2015

Agenda Testkrav för tjänsteproducenter till JoL-kontrakten Migrering av regelverksförvaltning från Google Code (som stängs) Ny version av Engagemangsindex-TKB (patch-version) - förtydligande om grundladdning m.m Process för utveckling av nästa T-bok initierad. Plan och status. Krav på uppgradering till nya huvudversioner av tjänstekontrakt för NTjP-anslutna parter Nya/uppdaterade RIV-TA-anvisningar Förslag till användning av datatyper och referensmodell från HL7 FHIR

Testkrav för tjänsteproducenter till JoL-kontrakten Se pdf “TestkravFörTjänsteproducenter.pdf” 26 maj 2014 Rikard Edgren rikard.edgren@nordicmedtest.se

Migrering av regelverksförvaltning från Google Code (som stängs) Uppdaterad version efter hantering i A&R dagen efter mötet. 27 maj 2015 Mattias Nordvall Mattias.nordvall@inera.se

Utvärderade alternativ CodePlex, SourceForge och GitLab har också övervägts.

Resultat av utvärdering Båda alternativ uppfyller våra funktionella krav Båda alternativ kan användas utan kostnad Båda alternativ innebär byte från Subversion till Git Bitbucket återkommande exempel på mer avancerad funktionalitet (se rapport)

Tidigare logisk indelning Alla tjänstedomäner tillsammans i ett filträd

Ny logisk indelning Varje tjänstedomän får ett eget repository – detta beror i grunden på hur tags och branches fungerar i Git

Konsekvenser av ny logisk indelning Behörigheter kan sättas per tjänstedomän Varje tjänstedomän får en separat ärendehantering Varje tjänstedomän får en separat wiki (om man vill) Utvecklingsarbete kan starta lokalt och sedan övergå till RIVTA

Ärendehantering i GitHub

Ärendehantering i Bitbucket

Migrering av innehåll All befintlig källkod, inkl varje commit, tag och branch kan migreras till Git via verktyget svn2git. Google tillhandahåller script och instruktioner för migrering av ärenden och wiki-sidor (men vi måste manuellt dela upp dem per tjänstedomän).

Förslag till fortsatt arbete Innan midsommar: Inera skapar repositories och tilldelar behörigheter i Bitbucket Inera uppdaterar dokument och anvisningar. Inera migrerar innehåll efter samråd med tjänstedomänansvariga (behöver inte ske samtidigt). Inera kommunicerar förändringarna till berörda utvecklare Efter semestrarna: Tjänstedomänutvecklingen pågår i Bitbucket

Ny version av Engagemangsindex-TKB förtydligande om grundladdning m.m 26 maj 2015 Johan Eltes Johan.eltes@inera.se

Detaljering av kraven för uppdatering av Engagemangsindex Generellt 1000 poster per meddelande 1000 är default. Antalet ska vara konfigurerbart (kunna ändras utan ny release eller ny leverans från leverantör). Grundladdning Uppdatering var 5:e sekund (önskemål för att kunna köras under löpande drift). Konfigurerbart tidsintervall. Inga dubbletter med avseende på posternas identitet under HELA grundladdningen Löpande uppdatering Uppdatering var 5:e minut Alla händelser som skett senaste 5 minuterna Inga dubbletter med avseende på posternas identitet

Detaljering av kraven för uppdatering av Engagemangsindex…forts.. Regler vid otillgänglig tjänsteproducent (EI) Hänvisning till ny regel i ny version av RIVTA Basic Profile 2.1 (.2) – lanseras inom kort Regel #22: Omförsök vid tillfälligt otillgänglig tjänsteproducent Begränsning av notifiering (önskemål från jurister) Regionalt EI får inte prenumerera på nationellt EI Poster som tas emot av notifieringsmottagare måste hanteras och kastas ”med vändande post” Lättnader i krav på fältet DataController (PU-ansvarig organisation) Fältet bör innehålla HSA-id/orgnummer för PuA, men kan innehålla källsystem-id Eftergift för att möjliggöra migrering av fler bef. NPÖ-svarstjänster Anpassning till ny mall Detaljerade sekvensdiagram för olika användningsfall PULL-metoden utgår GetUpdates-kontraktet utgår

Detaljering av kraven för uppdatering av Engagemangsindex…forts.. Nya krav på ett Engagemangsindex Krav på att kunna ha prenumerationsmask för Categorization och ServiceDomain Redan implementerat av SKLTP-EI Krav på att validera enligt domänspecifika regelverk Exempel frånJoL-domänerna: “LogicalAdress och SourceSystem ska ha samma värde” “mostRecentContent är obligatoriskt”

Process för utveckling av nästa T-bok initierad. Plan och status Redovisades muntligt 26 maj 2015 Johan Eltes johan.eltes@inera.se

Nya/uppdaterade RIV-TA-anvisningar Redovisades muntligt 26 maj 2015 Johan Eltes Johan.eltes@inera.se

Krav på uppgradering till nya huvudversioner av tjänstekontrakt för NTjP-anslutna parter 26 maj 2015 Johan Eltes Johan.eltes@inera.se

Policy för följsamhet till TK-versioner Rör tjänstekonsumenter och tjänsteproducenter Rör enbart nya huvudversioner (1.x -> 2.0, 2.x -> 3.0 etc) Bygger på balans mellan innovationstakt och stabilitet/ekonomi i integrationslandskapet Är tänkt som en mall för överenskommelser som kan refereras eller specialiseras av tjänstedomäner Journalleverantörernas inspel: Förutsägbart (högsta) antal uppgraderingar per år för att kunna passa in i förvaltningsavtal

Policy för följsamhet till TK-versioner Frågeställningar att beakta I vilka forum förhandlas beslut om ny huvud-version? Fungerar ehälsoutvecklingen om vi beslutar om max en ny huvudversion per 12 månader? Vad är rätt siffra? Kan landsting och kommunleverantörer hantera krav på att vara på senaste huvudversionen alternativt en huvudversion som inte är äldre än 24 månader?

Är detta ett bra förslag? TK-utveckling: Minimum 12 månader mellan två huvudversioner Syfte: möta leverantörers krav på förutsägbarhet Anslutande parter: Äldre version än 24 månader får inte användas om det finns nyare version som är minst 12 månader gammal Syfte: möjliggöra utveckling av ehälsolandskapet Anslutande parter: Nya-anslutning (tjänsteproducent) får ske till nuvarande eller föregående huvudversion Undvika att ha fler än 3 versioner i luften

Förslag till användning av datatyper och referensmodell från HL7 FHIR 26 maj 2015 Helen Broberg helen.broberg@inera.se

Användning av FHIR vid utveckling och förvaltning av nationella tjänster Underlag för inriktningsbeslut Inriktningsbeslut att gå vidare och genomföra utredning/analys – validera och verifiera Beslutsunderlag med rekommendation och handlingsplan Mål: Beslut om användning (När, var, hur)

HL7 FHIR (uttalas ”Fire”) Fast Healthcare Interoperabilitet resources HL7 senaste standard ramverk Under utveckling DSTU 2 (Draft Standard for Trial Use) halvårsskiftet http://hl7.org/fhir/2015May/index.html Beräknar bli standard 2017 RESTful (focus idag) 80-20 - Extensions

FHIR resurser

FHIR Observation resource

FHIR profile Specialisering av en FHIR resource

CIMI och FHIR Clinical Information Modeling Initiative Kliniska modeller (arketyper) http://www.clinicalelement.com/cimi-browser/#/

Användning av FHIR idag Öppna API som bygger på FHIR Smart on FHIR http://smartplatforms.org/smart-on-fhir/ Flera stora världsledande sjukvårds aktörer och leverantörer ingår i ett gemensamt projekt – The Argonaut project, med syfte att öka användningen av FHIR. t.ex. Intermountain Healthcare, Mayo Clinic, Cerner and Epic. http://www.hl7.org/documentcenter/public_temp_36E77A6A-1C23-BA17-0C107523B7DF0844/pressreleases/HL7_PRESS_20141204.pdf

Olika sätt av tillämpning Innehållet ”Kopiera” och inspireras av innehållet i aktuell/a FHIR-resurser Datatyper Använda FHIR datatyper XSD som ”payload” Använda XSD-objekt från FHIR Med ”teknisk bindning” (exkluderad i nuvarande fas) Använda FHIR´s ”teknik” FHIR profile Använda som Interaktionsöverenskommelser

Många frågetecken ???? (Exempel) Koppling till begreppsdefinitioner? Kodverk? NI2015:* ? Använda som referens modell? Extensions? (Datatyper och i resourcer) Attribut istället för element i FHIR? Skall defacto-datatyperna som finns ersättas med FHIR datatyper ? Hur skapas och hanteras FHIR Profile? Verktyg? När börja använda? Skall/bör? Vem?