Overordnet arkitekturbeskrivelse. DIFA Forprosjekt

Transkript

1 Overordnet arkitekturbeskrivelse DIFA Forprosjekt

2 Leveransens innhold DIFA forprosjekt har sammenstilt en beskrivelse av foreløpige arkitekturprinsipper og overordnede arkitekturkrav til den nye bransjeløsningen. Hensikten har vært å utforme et utgangspunkt for anskaffelsen, samt å danne et overordnet felles bilde av den nye bransjeløsningens omfang. Oversikt over forprosjektets arkitekturleveranse Delleveranse #1: Arkitekturprinsipper for ny bransjeløsning Delleveranse #2: Overordnede arkitekturkrav Delleveranse #3: Overordnet arkitekturbeskrivelse Vedlegg Side 2

3 Oversikt over forprosjektets arkitekturleveranse Side 3

4 Forprosjektets overordnede arkitekturbeskrivelse henger tett sammen med DIFAs øvrige leveranser Føringer Strategiske føringer for DIFA Forventede effekter Styrende prinsipper for ny bransjeløsning Ønsket funksjonalitet Arkitektur Detaljering DIFA Ny bransjeløsning Side 4

5 De tre delleveransenes innhold 1. Arkitekturprinsipper - Arkitekturprinsipper for ny bransjeløsning må ses i sammenheng med de styrende prinsippene for den nye bransjeløsningen. Arkitekturprinsipper er å oppfatte som retningslinjer for implementering og bruk av IT, og skal fungere som et sett med felles retningslinjer for alt arbeid med IT-løsninger. De skal bidra til at IT-arkitekturen er i tråd med DIFAs forventede effekter, apotekenes egne løsninger og den fremtidige utviklingen i bransjen. Sammen med de styrende prinsippene skal de dermed bidra til å legge til rette for en og god og helhetlig bransjeløsning. 2. Overordnede arkitekturkrav - Overordnede arkitekturkrav er spesifisert innenfor fem sentrale arkitekturområder. Overordnede arkitekturkrav er listet for å identifisere aspekter ved arkitekturen som vil være førende for utforming av den nye bransjeløsningen. Hensikten med de overordnede arkitekturkravene er ikke å gi et fullstendig bilde av hvilke tekniske krav en nye bransjeløsningen må forholde seg til, men å avdekke områder som er av høy kompleksitet, er kostnadsdrivende eller gir føringer på videre arbeid i DIFA. 3. Overordnet arkitekturbeskrivelse - Forprosjektets overordnede arkitekturbeskrivelse består av skisser for utvalgte deler av den nye bransjeløsningen og en kompleksitetsvurdering av samtlige komponenter arkitektgruppen identifisert som en potensiell del av den nye bransjeløsningen. Side 5

6 Delleveranse #1: Arkitekturprinsipper for ny bransjeløsning Side 6

7 Arkitekturprinsipper for ny bransjeløsning Fleksibilitet. Bransjeløsningen skal utformes slik at den ikke fremstår som begrensende for endringer i apotekenes arbeidsprosesser, innhold, organisering, eierskap og infrastruktur. Nye komponenter skal kunne legges til uten større modifikasjoner. Bransjeløsningens utforming skal fremme modularitet, gjenbruk og delte komponenter. Funksjoner og informasjon som eies av bransjeløsningen skal være tilgjengelige som integrasjonstjenester for apotek. Tjenesteorientering. Bransjeløsningen skal være tjenesteorientert og sammensatt av løst koblede komponenter med åpne, standardiserte grensesnitt. Funksjonalitet og ytelsesnivå skal være hovedhensyn ved utvikling av bransjeløsningen. Samhandling. Bransjeløsningen skal samhandle effektivt med apotekenes egne, myndigheters og andre relevante virksomheters IT-løsninger. Kvalitet. Teknisk og faglig kvalitet skal bygges inn i bransjeløsningens prosesser og funksjonalitet. Bransjeløsningen skal bygges på en måte som sikrer at data som eies av bransjeløsningen, data som registreres i bransjeløsningen, og data som brukes i bransjeløsningen valideres tidlig og er av høy kvalitet. Sikkerhet. Bransjeløsningen skal bygges for å kunne håndtere sensitive opplysninger. Bransjeløsningen i seg selv og informasjonen som behandles i denne skal med utgangspunkt i formelle krav beskyttes mot brudd på konfidensialitet, integritet og tilgjengelighet. Brukervennlighet og effektivitet. Bransjeløsningen skal være intuitiv og lede de ansatte gjennom prosessene på en effektiv måte. Brukervennlighet innebærer at bransjeløsningen skal oppleves som enkel å bruke, gjøre apotekansatte i stand til å utnytte sin kompetanse optimalt, og ikke oppleves som en hindring i arbeidet. Kompleksitet. Bransjeløsningen skal utformes på en måte som gjør at bransjen unngår at ekstra eller unødvendig kompleksitet introduseres. Side 7

8 Delleveranse #2: Overordnede arkitekturkrav for ny bransjeløsning Side 8

9 Overordnede arkitekturkrav bakgrunn og hensikt Overordnede arkitekturkrav er spesifisert for følgende områder: - Informasjonsarkitektur - Applikasjonsarkitektur Sikkerhetsarkitektur Integrasjonsarkitektur - Drift og infrastruktur Overordnede arkitekturkrav er listet for å identifisere viktige aspekter ved arkitekturen som vil være førende for design, prioriteringer og valg relatert til den nye bransjeløsningen. Hensikten med de overordnede arkitekturkravene er å tidlig avdekke områder som er av høy kompleksitet, er kostnadsdrivende og som gir sterke føringer på videre arbeid med funksjonalitet og arkitektur i neste fase av DIFA. Side 9

10 Informasjonsarkitektur overordnede krav Informasjonsarkitektur Kunden skal kunne få innsyn i informasjon som er lagret om kunden Informasjonsarkitekturen skal understøtte samhandling på tvers av aktører i helse-norge - Så langt som mulig benytte standardiserte informasjonsmodeller og kodeverk (e-resept, FEST, mfl.) - Etablere felles informasjonsmodell og kodeverk for bransjen der det ikke finnes nasjonale standarder Tydelig eierskap til informasjon og masterdata (fullstendige og korrekte data for enhver informasjonsentitet skal eksistere ett sted. Blant annet for å hindre uoverensstemmelse mellom registre) Data skal registreres og valideres så nær kilden som mulig Data skal kun registreres én gang Endringer i data må kunne logges, slik at man kan spore hvem som endret hva og når enderingen har skjedd Side 10

11 Applikasjonsarkitektur overordnede krav Applikasjonsarkitektur Bransjeløsningen skal kunne integreres med andre systemer som gir brukerne en effektiv og brukervennlig arbeidsprosess Bransjeløsningen skal ha et eget brukergrensesnitt som er felles for bransjen, og skal i tillegg eksponere tjenester og informasjon til gjenbruk i apotek Front-end skal integreres med back-end via et API, og dette APIet skal kunne støtte flere applikasjoner Deler av bransjeløsningens funksjonalitet skal kunne byttes ut og videreutvikles uten at det påvirker helheten Ny funksjonalitet og nye tjenester skal kunne piloteres hos et utvalg av bransjeløsningens brukere Bransjeløsningen må være responsiv Det skal ikke være sterke avhengigheter mellom funksjoner Side 11

12 Sikkerhetsarkitektur overordnede krav Sikkerhetsarkitektur Bransjeløsningen skal etterfølge Norm for informasjonssikkerhet i helse- og omsorgstjenesten (Normen) Bransjeløsningen må følge de sikkerhetsstandarder som brukes av myndigheter og tjenester som bransjeløsningen integreres med Bransjeløsningen skal eie og forvalte en felles sikkerhetspolicy for tilgangskontroll Bransjeløsningen må støtte brukersesjoner som er pålogget med «Single Sign On» (SSO) fra apotekenes egne system Bransjeløsningen skal ikke ha en egen påloggingsløsning (pålogging må håndteres av apotekene) Brukere og deres roller skal innhentes fra apotekenes systemer. Bransjeløsningen skal vedlikeholde tilgangskontroll, rollebeskrivelser med restriksjoner, sporbarhet og kontroll Apotekene må vedlikeholde en oversikt over sine ansatte, deres roller og apotektilknytning, og gjøre denne tilgjengelig for bransjeløsningen Det skal være tydelig hvem som eier data og hvem som har rett til å bruke data i bransjeløsningen Det er kun applikasjonen som skal ha direkte tilgang til data, brukeren skal få tilgang til data via tjenester Bransjeløsningen skal også kunne nås via en tredjeparts innloggingsløsning (f.eks. ID-Porten) Data i bransjeløsningen må klassifiseres med beskyttelsesbehov i forhold til konfidensialitet, integritet og tilgjengelighet Side 12

13 Integrasjonsarkitektur overordnede krav Integrasjonsarkitektur Bransjeløsningen må kunne tilpasses myndighetenes teknologiske løsninger og tjenester, ettersom hovedprosessen for refusjon og legemiddelhåndtering er styrt av myndighetene. Bransjeløsningen må tilby informasjon og tjenester til apotekenes egne IT-løsninger. Bransjeløsningen skal ha felles, åpne og veletablerte standarder for APIer. Videreutvikling og endringer av bransjeløsningens tjenester skal ikke bryte med eksisterende grensesnitt, med mindre det er forretningsmessig hensiktsmessig eller nødvendig. Integrasjonsplattformen skal støtte flere typer av patterns (mønster). Det gjelder f.eks. støtte for å abonnere på hendelser og direkte dataoppslag Kun tjenester for informasjon og prosesser som eies av bransjeløsningen skal kunne gjenbrukes av eksterne systemer. - Dette betyr for eksempel at andre IT-systemer må integrere direkte med Reseptformidleren for å hente resepter. Side 13

14 Drift og infrastruktur overordnede krav Drift og infrastruktur Bransjeløsningen skal bygges basert på en sentralisert arkitektur Bransjeløsningen skal kunne driftes og forvaltes sentralt Bransjeløsningen må støtte overvåking - Applikasjonens tilstand (tilgjengelighet, ytelse) - Funksjonell overvåking Bransjeløsningen skal tilknyttes Norsk Helsenett og internett slik at den kan benytte og tilby tjenester Bransjeløsningens skal tilrettelegge for at apotekene kun skal kunne drifte tynne klienter og periferiutstyr Apotekene sine WAN må være høytilgjengelige for at bransjeløsningen skal være høytilgjengelig Side 14

15 Delleveranse #3: Overordnet arkitekturbeskrivelse for ny bransjeløsning Arkitekturskisser Kompleksitetsvurderinger Side 15

16 Overordnet arkitekturbeskrivelse for ny bransjeløsning Forprosjektets overordnede arkitekturbeskrivelse består av overordnede skisser for utvalgte deler av den nye bransjeløsningen og kompleksitetsvurderinger av foreslåtte komponenter og integrasjoner. Følgende skisser er inkludert i leveransen: - Integrasjonsoversikt - Moduloversikt - Sikkerhet (overordnet ansvarsfordeling) - Applikasjonsbilde Side 16

17 Ny bransjeløsning: Oversikt over integrasjoner med kompleksitetsvurdering S/M/L/XL angir integrasjonens antatte kompleksitet Anbefalingen vil revurderes i neste prosjektfase

18 Kommentarer til integrasjonsoversikten Oversikten på forrige side illustrerer de integrasjoner som den nye bransjeløsningen må håndtere for å levere ønsket funksjonalitet Endelig antall integrasjoner og integrasjonenes kompleksitet vil være avhengig av bransjeløsningens informasjonsarkitektur og fremtidige behov for å hente inn og avlevere data til eksterne aktører og løsninger. Behov for nye integrasjoner kan derfor tilkomme, samtidig som antatte integrasjoner utgår. For flere av integrasjonen vil det være et potensiale for å forenkle og/eller modernisere integrasjonens implementasjon. Forenklingspotensialet må vurderes i dialog med den andre integrasjonsparten i neste fase av prosjektet. Side 18

19 Ny bransjeløsning: Foreløpig anbefaling til logisk funksjonell inndeling (moduloversikt) Anbefalingen vil revurderes i neste prosjektfase

20 Ny bransjeløsning: Ansvarsfordeling for identifikasjon, brukerkontroll og tilgangsstyring (sikkerhet) Sikkerhetsarkitektur Det stilles høye krav til bransjeløsningens sikkerhet, både internt og eksternt Sikkerhetsarkitekturen vil være et stort og komplekst tema i neste fase av prosjektet, og må prioriteres For å klare høyt stilte krav til fleksibilitet, effektivitet og brukervennlighet anbefaler arkitekturgruppen at apotekene skal ha ansvar for brukerhåndtering og innlogging til den nye bransjeløsningen Anbefalt ansvarsoppdeling innebærer at eier av bransjeløsningen etablerer krav og standarder for tilgangsstyring som apotekene må etterleve, men at identifisering og vedlikehold av brukere finner sted i apotekenes egne systemer Arkitektgruppens anbefaling er illustrert i bildet til høyre

21 Ny bransjeløsning: Foreløpig anbefaling for fremtidig applikasjonslandskap Anbefalingen vil revurderes i neste prosjektfase

22 Kommentarer til applikasjonsoversikten Applikasjonsoversikten på forrige side er en illustrasjon av forprosjektets foreløpige anbefaling og kan derfor endres når ny informasjon blir tilgjengelig i neste fase av prosjektet. Det er på nåværende tidspunkt stor usikkerhet knyttet til applikasjonen «Systemstøtte for farmasøytiske tjenester» og hvilken funksjonalitet denne skal støtte. Farmasøytiske tjenester som i dag tilbys i apotek er enkle og trenger ingen eller begrenset med systemstøtte. Fremtidige tjenester kan skape behov for mer avansert systemstøtte. Hvordan dette skal håndteres fra et arkitekturperspektiv avklares i det tjenestebegrepet etableres i bransjen og nye tjenester introduseres. Området farmasøytiske tjenester er nærmere beskrevet i forprosjektets funksjonalitetsbeskrivelse. Applikasjoner som ivaretar funksjonalitet som er antatt isolert eller der det er høy sannsynlighet for at offentlige myndigheter i fremtiden vil etablere nasjonale løsninger, er skilt ut for å gjøre den nye bransjeløsningen mest mulig endringsdyktig og fleksibel. Det kan i neste prosjektfase bli aktuelt å skille ut komponenter som i dag er antatt å være en del av f.eks. Reseptur-applikasjonen, i egne applikasjoner. Dette skal gjøres i de tilfeller en slik oppdeling understøtter de styrende prinsippene for ny bransjeløsningen. Side 22

23 Kompleksitetsvurdering Arkitektgruppen har vurdert kompleksiteten for de foreslåtte applikasjonene/komponentene, samt for bransjeløsningens eksterne integrasjoner. Kompleksitetsvurderingen gir grunnlag for anbefalinger rundt anskaffelsen, teknologibruk, overordnede kostnadsestimater osv. Kompleksitetsvurderingen av de foreslåtte applikasjonene er basert på følgende dimensjoner: - Vurdering av dagens FarmaPro 5-funksjonalitet - Brukergrensesnitt - Forretningslogikk - Datamodell Kompleksitetsvurderingen av bransjeløsningens eksterne integrasjoner er basert på integrasjonens størrelse, bruksomfang og antatt datamengde. For flere av integrasjonen finnes det et potensiale for at via dialog med integrasjonsparten forenkle og/eller modernisere integrasjonens implementasjon. Forenklingspotensialet må vurderes sammen med integrasjonspart i neste fase. Side 23

24 Kompleksitetsvurdering applikasjon: Farmasøytiske tjenester Beskrivelse Funksjonalitet som gir standardisert systemstøtte for farmasøytiske tjenester. Systemstøtte som skal tilbys har følgende fellestrekk: (1) dokumentasjon av utført tjeneste, (2) mulighet for refusjon, (3) bransjefelles varenummer og pris. Det er behov for stor fleksibilitet i arkitekturen på dette området for at løsningen skal kunne håndtere mange forskjellige typer av tjenester. Implementasjon arkitektgruppens foreløpige vurdering Utvidelse med nye tjenester må evt. håndteres som et miniprosjekt dersom kompleksitet og/eller behov for tilpasninger tilsier det. Totalvurdering av kompleksitet: Middels Brukergrensesnitt Lav (Kun aktuelt for dokumentasjon av tjeneste) Forretningslogikk N/A (Ingen forretningslogikk som standard) Datamodell Lav (Utvidbart kodeverk, standardisert format for dokumentasjon fritekst) Side 24

25 Kompleksitetsvurdering applikasjon: Reseptur Beskrivelse Funksjonalitet og tjenester for alle prosesser som er direkte koblet til resepthåndtering. Inkluderer f.eks. kundeinformasjon, reseptekspedisjon og legemiddelinformasjon. Applikasjonen krever optimalisert og god prosessflyt. Implementasjon arkitektgruppens foreløpige vurdering Eksponerte tjenester og eget brukergrensesnitt Totalvurdering av kompleksitet: Svært høy Dekker mellom 25-50% av kompleksiteten i dagens FarmaPro 5 Brukergrensesnitt Høy (Skjermbilder - S, presentasjonsregler - XL, informasjon - M) Forretningslogikk - Høy (Reseptekspedering - L, fagkontroller L (XL hvis vesentlig flere enn i dag, konfigurerbare og fleksible), Tekniske kontroller M (Inkl. batch-kontroll) Datamodell Svært høy Integrasjoner Svært høy (mange og komplekse integrasjoner) Side 25

26 Kompleksitetsvurdering applikasjon: Refusjonskrav Beskrivelse Funksjonalitet og tjenester for å motta refusjonskrav, sende krav til mottaker elektronisk eller på papir, samt oppfølging av utestående og avslåtte krav. Implementasjon arkitektgruppens foreløpige vurdering Skal ha eksponerte tjenester og brukergrensesnitt Totalvurdering av kompleksitet: Middels Brukergrensesnitt Lav (Få skjermbilder, få brukere) Forretningslogikk Middels (Motta refusjonskrav, sende til mottaker elektronisk eller papir, oppfølging av utestående og avslåtte krav) Datamodell Middels Side 26

27 Kompleksitetsvurdering applikasjon: Vedtaksregister Beskrivelse Felles register for vedtak koblet til kunden, tilgengelig på tvers av apotek. Implementasjon arkitektgruppens foreløpige vurdering Eksponerte tjenester og eget (separat) brukergrensesnitt for opplastning og vedlikehold av vedtak utenfor resepthåndteringsprosessen. Separat vedtaksapplikasjon gir gode muligheter for å raskt ta i bruk eventuelle nye registre som utvikles av myndighetene. Totalvurdering av kompleksitet: Lav Brukergrensesnitt Lav (Få skjermbilder - S, Støtte for å laste opp dokumenter - S) Forretningslogikk N/A (Forutsetter «strøm på papir», forretningslogikk ligger i reseptur) Datamodell Lav (Noe metadata, kodeverk, lagre scannede dokumenter) Side 27

28 Kompleksitetsvurdering applikasjon: Fullmaktsregister Beskrivelse Felles register for fullmakter for utlevering av kundes legemidler til tredjepart. Skal være tilgengelig på tvers av apotek. Implementasjon arkitektgruppens foreløpige vurdering Eksponerte tjenester og eget (separat) brukergrensesnitt for opplastning og vedlikehold av vedtak utenfor resepthåndteringsprosessen. Separat fullmaktapplikasjon gir gode muligheter til å raskt ta i bruk eventuelle nye registre som utvikles av myndighetene. Totalvurdering av kompleksitet: Lav Brukergrensesnitt Lav (Få skjermbilder - S, Støtte for å laste opp dokumenter - S) Forretningslogikk N/A (Forutsetter «strøm på papir», forretningslogikk ligger i reseptur) Datamodell Lav (Noe metadata, kodeverk, lagre scannede dokumenter) Side 28

29 Kompleksitetsvurdering applikasjon: Egenandelsberegning Beskrivelse Funksjonalitet for beregning av kundens egenandel, basert på aktuelle regelverk. Implementasjon arkitektgruppens foreløpige vurdering Eksponerte tjenester, men trenger ikke eget brukergrensesnitt. Bør ikke implementeres med regelmotor. Kompleksitet, omfang av bruk og endringstakt tilsier at en regelmotor vil føre til høye kostnader og økt behov for ressurskrevende drift og vedlikehold. Totalvurdering av kompleksitet: Høy Brukergrensesnitt N/A (Har ikke eget brukergrensesnitt) Forretningslogikk Høy (Komplekse regler, medium stabilitet, store økonomiske konsekvenser) Datamodell Lav (Tilstandsløs) Side 29

30 Kompleksitetsvurdering: Integrasjoner Hver integrasjon er dokumentert med arkitektgruppens vurdering av integrasjonens kompleksitet i integrasjonsoversikten på side 21. Ved implementering av samtlige integrasjoner gjelder styrende prinsipper for ny bransjeløsning, arkitekturprinsippene og de overordnede kravene som er definert for integrasjonsarkitekturen. Oppsummering av arkitektgruppens kompleksitetsvurdering: - Den nye bransjeløsningen vil ha mellom eksterne integrasjoner. Nøyaktig antall avhenger av det antall rapporter som skal sendes fra bransjeløsningen, evt. nye integrasjonsmuligheter med aktører i norsk helsevesen samt evt. behov for nye informasjonskilder for å støtte apotekansatte med bedre informasjon og beslutningsstøtte. - 6 av integrasjonene er vurdert til å være av LAV kompleksitet - 8 av integrasjonene er vurdert til å være av MIDDELS kompleksitet - 5 av integrasjonene er vurdert til å være av HØY kompleksitet - 1 av integrasjonene er vurdert til å være av SVÆRT HØY kompleksitet - Det er behov for et antall nye integrasjoner mellom den nye bransjeløsningen og apotekenes egne systemer. Flere av disse integrasjonene vil ha en høy kompleksitet. Side 30

31 Vedlegg Rapporteringsoversikt Bransjeløsningen er en del av et miljø med sterke avhengigheter og mange aktører Side 31

32 Rapporteringsoversikt Side 32

33 Oversikt over rapporter som sendes fra FarmaPro 5 i dag, der mottaker av rapporten er en ekstern aktør Rapport Reservasjon FHI rapport Reseptregisisteret FHI Antidatabase Bransjestatistikk NAF Ekspedisjonsliste helsetilsynet Datauttrekk til sykehus Regnskapsuttrekk Mottaker Folkehelseinstituttet (FHI) Folkehelseinstituttet og SSB Ikke lenger i bruk Apotekforeningen Helsetilsynet Sykehusapotekene HF Apotekets regnskapsfører Side 33 Oversikten er basert på opplysninger fra Espire. Den fulle oversikten over dagens rapportering fra FarmaPro 5 er tilgjengelig i AS-IS-dokumentasjonen fra DIFA forprosjekt.

34 Bransjeløsningen er en del av et miljø med sterke avhengigheter og mange aktører Side 34

35 Bransjeløsningen vil ha en sentral rolle i et miljø med sterke avhengigheter og mange integrasjoner Helsenorge.no Nasjonal journalløsning Reseptregisteret (FHI) VetReg + øvrige registre Elektronisk pasientjournal Reseptformidler Bransjeløsningen HELFO Rekvirentsystemer Apotekene Apotekene