eprArena

(Case: Tjenestemodellering i Eldreomsorgen)

Redaktør: Hans A. Kielland Aanesen

Si din mening i tilhørende Blogg

Med eprArena ønsker vi først og fremst å fokusere på spesifikke teknologiske og IKT-messige verktøy og registere for hensiktsmessig bruk av omsorgsteknologi. Vi ønsker også å gi innspill når det gjelder bruk av aktuelle internasjonale og nasjonale standarder ved bruk av teknologi.

Det er i spesielt 3 viktige områder omsorgs-teknologi bør benyttes:

• Trivsels og rent sosiale forhold. ( Underholdning, musikk ,rask virtuell nærhet til venner og familie, spill, kalender med gjøremål etc )

• Generell tilstands/omgivelses-kontroll gjennom scenario-overvåkning av tjenestemottakers omgivelse gjennom avviks-rapportering. Status og avvik på fast monterte følere (bevegelse, gass/røyk, komfyrstatus, lys etc) samt status og avvik på kropps-sensorer ( blodtrykk, hjertefrekvens samt andre enkle nano-teknologiske blodanalyser). Se Fig 6

• Integrert tjenesteplanlegging og rapportering i tjenesteutøvelsen

Strukturen er bygget slik at den gir mulighet for en standardisert modellering av hovedtrekkene i anvendelsen med metadata og avanserte maler (Styrekort/templater) som sentrale elementer. ( Se Fig 4)

Fig 4: Modelldrevet Arkirektur i Sanntid

Sanntidsmodellering og prosessering av disse er et totalt nytt og tvingende nødvendig virkemiddel i interaktive systemløsninger gjennom en samhandlende OVERBYGNING.

Viktig å forstå er også at man skal slippe å skifte ut de eksisterende og underliggende fag- og ekspertsystemer. Disse skal kun eksponere logikk og informasjon til overbygnigen under et felles og "åpent" Web-services REGIME. Kun hvis underleverandørene ikke er med på dette skifter man det ut.

Utvikling og tilpassing av applikasjonene skjer i elektronisk verksteder som vi kaller eprArena. ( Se Fig 3)

Fig 3: Overbygningens fire Rollegrupper

Standardiserte komponenter som styrekort med tilknytning til underliggende forretningslogikk og informasjon eksponert fra fag- og ekspertsystemer (Web services , ebXML ) defineres gjennom verkstedet.

Disse standardiserte komponenter vil kunne gjenbrukes og er de viktigste byggestenene i de genererte Sanntidsmodeller. Modellene inneholder hjelpemidlene som trengs i de forskjellige arbeidssituasjoner og faser Rolleinnehaverene måtte havne havne i.

NB! Fasene følger Tjeneste-mottaker ( Se Fig 2)

Fig 2: Omsorgsbehov og Omsorgsnivåer

Modelleringen skjer i 2 step gjennom standardiserte verktøy og styrekort-tilgang fra registerene i eprArena: ( Se rollegrupperingen i Fig 3)

1. Statiske byggestener defineres i forkant av en arbeidssituasjonen:

   1. ( Rolle 1 og 2)

2. Sanntidsmodellen formes med komponenter og innhold i selve arbeidsutførelsen: ( Rolle 3 og 4)

Rutiner og innhold i denne modellering av elektroniske mapper i de forskjellige brukersituasjonener innhentes via Styrekortene og en tilhørende Rutinebank. En felles Rutinebank vedlikeholdes etter prinsippet om BESTE PRAKSIS. ( Se Service management standarden ITIL )

Tidligere arbeidserfaringer lagres og gjenbrukes gjennom denne felles Rutinebank.

Vi vet av erfaring at brukerne ikke kan forholde seg til en standard som bare består av ord og illustrasjoner. Forutsetning for at brukerne skal ha en begrunnet oppfatning om løsningens brukbarhet er at de kan se hvordan tjenestemappene vil se ut. Vi trenger altså tjenestemappe-modeller som brukerne kan fylle med innhold for både å danne seg en mening om utformingen og hvordan regelverket vil fungere. Disse tjenestemappene kaller vi demonstratorer (= Sanntidsmodeller). Demonstratorene representerer gjenbrukbare modeller som er kjørbare i Overbygningen.

EprArena vil organisere og tilpasse overbygninger som alle er bygd på de samme prinsippene. Fig 3 viser hvorledes Arbeidsledere sammen med Portal- & Systemutviklere danner grunnlaget for demonstratorene i eprArena som i praktisk tjesteutøving får innhold av Tjeneste-Utøvere og Tjeneste-mottakere. (Overbygningens Rollegrupper)

• Overbygningen utøver et regime (regelverk) for hvordan tilknyttede ekspert og fagsystemer eksponerer forretningslogikk og data. Overbygningen må være nøytral og ikke proprietær, mens de underliggende systemene kan være basert på hva som helst av plattformer.

• Det er sammenhengen mellom beskrivelsesreglene og oppbygging av overbygningen som gjør det mulig å generere anvendelser gjennom gjenbruk av et stort antall applikasjons komponenter administrert gjennom Tjenestemappe-Modellen (Arbeidsmappe+ Styrekort).

EprArena "verktøy" vil bli stilt til rådighet for sertifiserte organisasjoner til å definere/modellere strukturen på Arbeidsmappen med Styrekort for arbeidsprosesser og rutiner. Disse modellene gis innhold i arbeidssituasjonen ved prosessering av Styrekortene i den åpene overbygningen. Dette betyr at de standardene som blir anvendt i overbygningen også vil være åpne standarder med åpne kildekoder.

Arenaen anvendes for å sy sammen, tilpasse, kvalitetssikre og prøve ut nye anvendelser. Arenaen vil også bli en arena for læring samt utprøving av prinsipper for ledelse, delegering og ansvar under digitale forutsetninger.

Realisering av Roller og Infrastrukturen i Overbygningen

Infrastrukturen forutsetter at styrekortene i mappene er utviklet og fungerer i henhold til minimumskravene. Som nevnt innledningsvis mener vi at hjemmebasert helse og omsorg vil være en god pilot.

I neste omgang kan kommunale sykehjem og tilstøtende tjenester legges til.

Vi tror at når den første anvendelsen kan demonstreres vil andre piloter følge etter. Det mest nærliggende er anvendelser som dekker andre kommunale tjenester. Disse vil også være basert på tjenestemapper.

Rollestrukturen er vesentlig når man konstruerer Overbygningen.

De fire viktigste Rollegruppene er illustrert i Fig 3 :

1. Arbeidsledere: (Mappekonstruktører i eprArena)

2. Portal- & Systemutviklere:

3. Tjeneste-utøvere: ( Tjenesteutøvende medarbeidere)

4. Tjeneste-mottakere: ( Representerer Tjeneste-objectet)

Mer om eprArena og realisering av anvendelser

Utvikling og tilpassing av applikasjonene skal skje i et elektronisk verksted som vi kaller eprArena. (Workshop kan ikke brukes som begrep fordi ordet misforstås). Verktøyene i verkstedet vil nyttes til å generere strukturer og funksjoner som representerer regelverket i de elektroniske mappene. Verktøyene vil også bli benyttet til å integrere fagsystemer, kvalitetssystemer og tekniske moduler som skal inngå i de ferdige overbygningene.

Det kan også være behov for en forløper til eprArena som bare inneholder de standardiserte og dynamiske elementene. Denne har vi kalt eprMotor eller eprEngine.

EprArena vil organisere og administrere overbygninger som alle er bygd på de samme prinsippene.

• • Overbygningen utøver et regime (regelverk) for hvordan tilknyttede ekspert og fagsystemer eksponerer forretningslogikk og data. Overbygningen må være nøytral og ikke proprietær, mens de underliggende systemene kan være basert på hva som helst av plattformer.

  • Det er sammenhengen mellom beskrivelsesreglene og oppbygging av overbygningen som gjør det mulig å generere anvendelser gjennom gjenbruk av et stort antall applikasjons komponenter.

EprArena vil bli stilt til rådighet for sertifiserte organisasjoner som en åpen overbygning med åpne kildekoder. Dette betyr at de standardene som blir anvendt i overbygningen vil være åpne standarder og med åpne kildekoder.

Basisteknologien i e-Folder vil bli beskrevet gjennom en åpen standard og gjort tilgjengelig gjennom åpne kildekoder. Komponenter som er kritiske i for å sikre interoperabilitet skal bli stilt gratis til rådighet for sertifiserte organisasjoner.

Arenaen anvendes for å sy sammen, tilpasse, kvalitetssikre og prøve ut nye anvendelser. Arenaen vil også bli en arena for læring samt utprøving av prinsipper for ledelse, delegering og ansvar under digitale forutsetninger.

System for helhetlig risikostyring må utvikles som et verktøy i konseptet ”Fellesskap om kvalitet”. Dette må inngå i eprArena og integreres i den daglige driften. Risiko og sårbarhetsvurderinger vil være grunnlag for å avdekke risikoområder og iverksette tiltak for å fylle gapene.

Det er utviklet en templatprosessor som åpen kildekode og programvare. Denne vil bli anvendt for å prosessere styrekort.

Prosessering i anvendelsene vil foregå i to lag gjennom templater (styrekortene) og komponenter:

• Styrekortene beskriver strukturen i mappene. Styrekortene vil danne dynamiske templater. Templatene er regelbaserte og kjørbare gjennom templatprosessering. Templatene organiserer og orkestrerer koblinger til forretningslogikk og informasjon i underliggende systemer gjennom ”løst koblede applikasjoner”. Templatene vil også koble inn og ut komponenter som er spesifisert i styrekortene. Dynamiske innebærer at de vil bli endret etter behov.Når en konkret anvendelse blir etablert vil templatene bli gjort operative. De gis innhold og vil bli kjørbare i overbygningsportalen når tjenester, roller og arbeidsoppgaver er tildelt/konfigurert. Det vil bli mange templater, men disse må begrenses i antall og holdes på et nivå som sikrer at forutsetninger for interoperabilitet og trafikkregler blir fulgt.

• Komponenter kan være Funksjonene i mappene eller deler av fagsystemer, respektive ekspertsystemer som skal bli integrert og eksponert i mappene. Instrukser vil også bli behandlet som komponenter. Komponentene vil bli prosessert etter ”ordre” fra templatene.

Mappene opprettes og endres gjennom templater. Templatene henter inn og kobler ut komponenter etter behov. Mappene er dynamiske og de er tilpasset brukerens behov. ”Tilpasset” er viktig for at mappene skal kunne fungere når behovene varierer. I neste bolk er de viktigste tilpassingene beskrevet. For å samkjøre og gjenbruke informasjon i en felles og åpen infrastruktur kan man ikke ha samkjøringsregimer bestemt av en eller enkelte dominerende programvareleverandører.

EprArena vil derfor anvende ”trafikkregler” spesifisert gjennom åpne standarder av ISO, OASIS og UN/CEFACT (Det globale fellesskap)

Analogi:

Man kan ikke la en enkelt bilprodusent fastlegge sine egne trafikkregler og tildele seg selv forkjørsrett! (Det er selvfølgelig fellesskapets ansvar)

Det viktige i denne sammenheng er standarder som er nødvendige for at overbygningen skal fungere. Vi foreslår at overbygningen i stor grad baseres på standarder fra OASIS fordi standardene fra OASIS henger sammen, og fordi disse standardene representerer et ønsket mangfold. OASIS har forslagsrette til ISO.

Oppbygging av eprArena vil være basert på systemarkitekturen og dennes tre nivåer. Disse tre nivåene er for øvrig identisk med generelle anbefalinger i forbindelse med åpne standarder og åpne kildekoder.

eprArena vil ha 3 hoveddeler:

• 1. eFolder tool: Opprette templater med tilkobling av komponenter for en anvendelse

  2. eFolder registry: Register over templater og komponenter

  3. eFolder portal: Drift av overbygningen

Templater i ”eFolder tool” for en konkret anvendelse:

• • Et antall templater knyttet til mappen som overbygning

  • e-kontrakter mellom aktører (Collaboration Partner Agreement - CPA)

  • Faseinndeling

  • Roller og myndighet

  • Ett antall templater for hver fase og kategorier styrekort

    • Dokumentkort for de ulike kategorier informasjonsbærere

    • Rutinekort. Disse vil utgjøre hovedtyngden av tilkobling av fagsystemer og ekspertsystemer.

    • Arbeidskort med oppgavebeskrivelser, rapport, inspeksjon og meldesystem

  • Templater for kommunikasjon mellom dokumentkort, rutinekort og arbeidskort

Drift av overbygningen ”eFolder portal” vil være organisert i henhold til de hovedfunksjoner som anvendelsen er opprettet for. Funksjonene vil ofte bli dekket gjennom fagsystemer.

Fig 5: Tjenestemappe-modellering i Sanntid

Tjenestemappens viktigste Styrekort/templater:

Arbeidsmappe:

Inneholder alt en bruker/rolleinnehaver trenger i arbeidet. Alle Arbeidsmapper er inndelt i faser i forhold til fremdrift.

Inholdskort (Styrekort 1):

Styrer håndteringen av alle Dokumentene i mappen. Den har også sanntids-regneark av tilstandsdata og alarmstatus med responsoppgaver basert på verdier fra Omgivelseskontroll. Se avsnittet OMGIVELSESKONTROLL.

Arbeidsflytkort ( Styrekort 2):

Gir støtte til de administrative arbeids-oppgaver i de administrative rutinene.

(Ofte regelstyrt Flyt og Saksgang)

Oppgavekort/Tjenestekort ( Styrekort 3):

Definerer fysiske arbeidsoppgaver med arbeidsspesifikasjoner.

Innehar inspeksjon og rapportering.

Fig 6: Tilgangsstruktur

Si din mening i tilhørende Blogg