Reell SOA struktur

Si din mening i tilhørende Blogg

Knapt noe forvaltningsområde er så komplekst og arbeidsintensivt som Pleie- og omsorgstjenestene. Fordi disse tjenestene er så komplekse må infrastrukturen være enkel og bestå av noen enkle og utprøvde grunnmodeller. Det har vært – og er – et mål for oss at prinsippene er enklest mulig og at grunnmodellene som infrastrukturen er bygd opp av gjentas og gjentas og gjentas.

Brukeropplevd kontroll og kvalitet står sentralt. En slik tilnærming er også i overensstemmelse med klare føringer i den sittende regjeringens tiltredelseserklæring (Soria Moria erklæringen). Vårt forslag til en felles og åpen TJENESTE-ORIENTERT-ARKITEKTUR møter behovene på en enkel måte. Forslaget til infrastruktur har ikke et teknisk utgangspunkt, men peker på hvordan datastøtten blir en reell hjelper til mennesker i arbeid og samarbeid.

Datastøtten skal være organisert for å gi best mulig støtte til mennesker i omsorgsarbeid. Dette er en klar forutsetning for hva som er helsetjenestens hovedformål:

" Best mulig tjenester for sluttbruker / pasienter "

I dataverdenen kalles dette for SOA( Service Oriented Architecture).

Vi (EPR-Forum og OASIS BCM/EPR) har i lengre tid brukt hjemmebasert pleie og omsorg som prioritert område. Området er valgt fordi gevinstmulighetene er formidable og behovet er stort. Anvendelsen er relativt oversiktelig, den kan begynne med det enkle og utvides etter hvert som man vinner erfaring.

Den grunnleggende teknologien som er omtalt i forbindelse med EprArena (Realisering av anvendelser) er utviklet og er basert på åpne standarder fra flere standardiseringsorganisasjoner. ITIL og reelle SOA OASIS standarder er de viktigste. Litt av hensikten med prosjektet er at det ikke vil være nødvendig å finne opp hjulet på nytt, men å basere utvikling av overbygningen og tjenestemappen på eksisterende løsninger og "åpne" standarder.

Dagens abstraksjonsprinsipper med XML-teknologi har åpnet opp for helt nye måter å samkjøre datasystemer på uten å måtte låse seg til en enkelt leverandørs teknologi eller plattform-regime.

SOA Prinsippene omkring Service Management med felles Rutinebanker vedlikeholdes etter prinsippet om BESTE PRAKSIS.

The IT Service Management (ITSM) standard er beskrevet i ITIL-standarden

( ITIL = IT Infrastructure Library : ISO 20000 / BS 15000 )

I dag domineres SOA av IT-selskapenes egne regimer, noe som ikke var ideen bak SOA.

Vi kaller derfor denne form for SOA : Teknologi(plattform) Orientert Arkitektur forkortet til TOA.

I den videre beskrivelse benytter vi SOA, men mener da "åpen" og "reell" SOA som er platform og teknologi-uavhengig.( Se Fig 4)

NB Ved å klikke på illustrasjonene blir de forstørret !

Fig 4: Modelldrevet Arkirektur i Sanntid

(HYBRID IT-struktur med Integrasjon av TOA og SOA)

( ServiceOrientedArchitecture + TechnologyOrientedArchitecture )

Vår SOA har tatt denne problemstilling på alvor og tatt utgangspunkt i en OVERBYGNING som samkjører Fag- og Ekspert-systemer (Fig 4), men som også tar for seg OMGIVELSESKONTROLL som samkjører og kan gjøre alle elektroniske produkter om til nettverks-enheter (Se Fig 6) uavhengig av teknologiplattformer.

Fig 6: Tilgangsstruktur

For å håndtere disse 2 nivåer av abstraksjonsteknikker fra en tjeneste og brukerrelatert side er ROLLEGRUPPERING med prioritert tilgangskontroll (OASIS ID-trust) helt avgjørende med tanke på informasjonsdeling. Se Rollegruppering i avsnittet "Realisering av Anvendelser" og Fig 3.

Fig 3: Overbygningens fire Rollegrupper

1: Arbeidsledere: (Mappekonstruktører i eprArena)

I denne rollen konstruerer og definerer man alle de nye typer Arbeidsmapper og Roller med tilhørende Rutiner(Beste Praksis Rutiner) som man måtte trenge i sin organisasjon. Dette organiseres gjennom modelleringen av mappene med sine definerte Styrekort/Templater. Gjennom eprArena defineres derfor et nødvendig samhandlingsregime for å kunne eksponere data og annet innhold fra underliggende systemer ( Fag-/Ekspert-systemer).

Ved hjelp av Metodeverktøy i eprArena Spesifiserer Arbeidsledere(uten programmeringskunnskap) kravspesifikasjon til evt nye Web-tjenester som må lages av Portal- og Systemutviklere i de underliggende systemer. Programmering av programvarekomponenter som Semantic Web services og ebXML får dermed påtvunget et Overbygningsregime som er tvingende nødvendig for en uniform samhandling av data og informasjon.

2: Portal- & Systemutviklere:

De representerer system og programmeringskunnskapen i de underliggende Fag- og Ekspertsystemer. De er disse personer som programmerer Softwarekomponenter som eksponerer data og innhold til Overbygningen.

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

Disse medarbeidere har sine Arbeidsmapper med Informasjon og hjelpeverktøy de trenger i sin arbeidssituasjon. Gjennom sine Arbeidsmapper håndteres Arbeidsinstrukser, Rapportering og Melding om evt ønskede nye Behov. Tjenesteutøverene legger med andre ord Innhold til mappene.

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

Dette representerer borgerene som har krav på lovpålagte tjenester eller ønsker egne ikke lovpålagte tjenester. Borgerene har derfor sin egen Mappe (MIN SIDE) hvor status og faser i tjenestene er synlige.

Prinsippene og modelleringsteknikken som benyttes organiseres derfor i 2 viktige områder:

I disse to sidene utdypes modelleringsteknikken nærmere da dette er vitalt for OVERBYGNINGEN.

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.

Si din mening i tilhørende Blogg

Page updated

Google Sites

Report abuse