Kompetensforum för nationell arkitektur

En presentation över ämnet: "Kompetensforum för nationell arkitektur"— Presentationens avskrift:

1

2 Kompetensforum för nationell arkitektur
Presentationsmaterial 26 maj 2015

3 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

4 Testkrav för tjänsteproducenter till JoL-kontrakten
Se pdf “TestkravFörTjänsteproducenter.pdf” 26 maj 2014 Rikard Edgren

5 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

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

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

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

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

10 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

11 Ärendehantering i GitHub

12 Ärendehantering i Bitbucket

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

14 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

15 Ny version av Engagemangsindex-TKB
förtydligande om grundladdning m.m 26 maj 2015 Johan Eltes

16 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

17 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

18 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”

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

20 Nya/uppdaterade RIV-TA-anvisningar
Redovisades muntligt 26 maj 2015 Johan Eltes

21 Krav på uppgradering till nya huvudversioner av tjänstekontrakt för NTjP-anslutna parter
26 maj 2015 Johan Eltes

22 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

23 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?

24 Ä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

25 Förslag till användning av datatyper och referensmodell från HL7 FHIR
26 maj 2015 Helen Broberg

26 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)

27 HL7 FHIR (uttalas ”Fire”)
Fast Healthcare Interoperabilitet resources HL7 senaste standard ramverk Under utveckling DSTU 2 (Draft Standard for Trial Use) halvårsskiftet Beräknar bli standard 2017 RESTful (focus idag) Extensions

28 FHIR resurser

29 FHIR Observation resource

30 FHIR profile Specialisering av en FHIR resource

31 CIMI och FHIR Clinical Information Modeling Initiative
Kliniska modeller (arketyper)

32 Användning av FHIR idag
Öppna API som bygger på FHIR 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.

33 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

34 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?