Addera Stöd för PULL i EI Vägval och rekommendation Projekt SLL Tjänstearkitektur Johan Eltes 2012-04-15 Uppdaterad 2012-04-26 med beslut inom SLL HSf

Bakgrund NPÖs nya anslutningsmodell har bara stöd för PUSH För system som har förutsättningarna är PUSH bästa lösningen Cosmic, Take Care Det finns många äldre system med en arkitektur som inte med rimliga insatser klarar PUSH-modellen Ex: Screeningsystemet SafirLIS (Jönköping, Halland, Västmanland) Kan lösas med mellanlager som klarar PUSH, men vårdgivare (t.ex. SLL) vill inte ha mellanlager och det är i sig en stor investering (nytt förvaltningsobjekt) Drabbar Mina vårdkonatkter i närtid och NPÖ-anslutningar på sikt

Krav på PULL-lösning Även PULL ska ske genom nationellt RIVTA-tjänstekontrakt Annars kan inte PULL-integrationer för ett system återanvändas mellan vårdgivare som har samma system Det ska INTE lösas per anvädningsfall och system (t.ex. Inte som speciallösning inom NPÖ svarstjänst, annan lösning för tidsbokningshändelser från samma system etc) PULL ska vara ett “försteg” till befintlig PUSH Dvs en komponent “pollar” vårdsystemet genom ett nytt PULL-kontrakt för EI. Engagemangen som kommer in via PULL till komponenten, går in i befintlig PUSH

Tjänstekontrakt i EI-domänen FindContent sök i ett EI GetUpdates (ej obligatoriskt för ett EI) JS uppdaterar genom PULL ProcessNotification Levererar händelser till prenumerant Update JS uppdaterar genom PUSH

FindContent

GetUpdates

ProcessNotification

Update

Engagemangsindex med PUSH

Utgångsläge Det finns två EI-implementationer En kommerciell från Tieto som är inbäddad i den nationella NPÖ-plattformen En open-source från SLL som finns på Google Code http://code.google.com/p/sll-engagemangsindex/ Tjänstekontrakt för PULL togs fram här om veckan, baserat på behov som uppmärksammats inom Mina vårdkonatkters anslutningsprojekt för Tidbok Det är frivilligt för ett EI att stödja PULL-kontraktet Bef. EI-implementationer saknar detta stöd idag Tilläggsbeställning från CeHis behövs för att tillföra PULL till nationellt EI Innebär uppskattningvis att vi kan få PULL om 6 månader Regionalt EI finns bara i drift hos SLL Medel finns reserverade för att införa PULL Kan vara på plats inom 4 veckor (skulle möta landstingens integrationsplan för SafirLIS)

Handlingsalternativ – kort sikt A. Införa PULL-funktion i SLL Regionalt EI Använda SLL:s regionala index som nationellt EI för PULL under en övergångsperiod Nationellt EI kan fortfarande vara nationellt för PUSH. Det som “pollas” av SLL R-EI notifieras till nationellt EI Påverkar inte vårdsystemen elller brandväggar hos vårdgivarna. PULL-anropen till landstingen (förutom SLL) kommer fortfarande via nationella tjänsteplattformen Regionerna kan (bör) installera R-EI lokalt, så att “PULL” sker internt B. Införa PULL-funktionen som en fristående komponent i istf i R-EI/Nationellt EI Ger samma funktion om att ha det i R-EI, men kan användas regionalt utan att krav på regionalt R-EI Dvs införande av regionalt PULL-stöd kan ske fristående från beslut om att införa ett R-EI. Detta alternativ blir slutprodukt från början. Ingen migrering från regionalt till nationellt Minskar administration för SLL som då inte behöver hantera andra regioners integrationer.

Alternativ B - översiktsbild

Alternativ B – I ett sammanhang) (tjänsteadresseringskatalog och TP/RTP utelämnade i bilden)

Rekommendation SLL tar fram en fristående komponent för PULL istället för att bygga in funktionen i R-EI Läggs i samma Google-code-projekt som R-EI Den installeras hos SLL i bef. RTP-infrastruktur när PULL-behov finns Den installeras i nationella plattformen för att användas mot SafirLIS-landstingen Även systemleverantörer kan integrera komponenten i sin egen arkitektur och därmed utåt sett erbjuda PUSH

Beslut SLL HSf Ehälsa (inom Tjänstearkitektur SLL) finansierar utveckling enligt rekommendation Resultatet blir öppen källkod på Google Code enl nat riktlinjer Kan driftsättas i NTjP (mot nat. EI) och i RTP-installationer av motsvarande plattform (mot reg. EI) Utveckling klar 2012-06