Infrastruktur for elektronisk handel

Størrelse: px
Begynne med side:

Download "Infrastruktur for elektronisk handel"

Transkript

1 Prosjekt i regi av Norsk EDIPRO Kravspesifikasjon for etablering og drift av Registry og Repository Versjon november 2001 Norsk EDIPRO Tel Postboks 2526 Solli Fax Oslo Internett:

2 Copyright Norsk EDIPRO, All Rights Reserved. Dette dokumentet er utarbeidet som en del av dokumentasjonen fra prosjektet Infrastruktur for elektronisk handel i regi av Norsk EDIPRO. Dette dokumentet, og oversettelser av det, kan fritt kopieres og distribueres. Dokumentet kan fritt brukes som grunnlag for arbeid som forklarer og/eller kommenterer på innholdet i dokumentet eller på annen måte bidrar til at spesifikasjonen blir tatt i bruk. Slikt avledet arbeid kan fritt utarbeides, kopieres, publiseres og distribueres forutsatt at det gis behørig referanse til dette dokumentet og at det ikke legges begrensninger arbeidet utover det som er definert i denne teksten. Dette dokumentet i seg selv kan imidlertid ikke endres på noen måte med unntak av det som måtte være nødvendig i forbindelse med oversettelse. Dette dokumentet reflekterer de synspunkter og konklusjoner som har fremkommet gjennom arbeid i prosjektet og ikke nødvendigvis synspunktene til de enkelte deltakerne eller deres arbeidsgivere. 2

3 Forord Prosjektet Infrastruktur for elektronisk handel ble initiert av Norsk EDIPRO i samarbeid med leverandører og brukere våren I kartleggingsfasen, som ble gjennomført våren/sommeren 2000, ble det blant annet gjennomført en serie intervjuer for å kartlegge brukerbehov og avklare problemstillinger knyttet til en åpen felles infrastruktur for elektronisk handel. Spesifikasjonsfasen av prosjektet bygger videre på resultatene fra kartleggingsfasen og tar sikte på å utarbeide spesifikasjoner som skal legge til rette for etablering av et sett av samvirkende informasjonsbanker (Repository) og tilhørende indeks (Registry) som er åpent tilgjengelig og inneholder informasjon om de konkrete e-handelsløsninger som benyttes i markedet. Åpen tilgang til et sett av samvirkende Registry og Repositories blir av stadig flere, også internasjonalt, sett på som selve hjertet i en åpen infrastruktur for elektronisk handel. Ved at detaljerte beskrivelser av en virksomhets forretningsprosesser og tilhørende datainnhold gjøres åpent tilgjengelig sammen med en beskrivelse av de tekniske e-handelsløsninger, legges grunnlaget for en åpen infrastruktur av samhandlende applikasjoner, hvor også små og mellomstore virksomheter skal kunne delta. Visjonen om en åpen infrastruktur innebærer at det sannsynligvis vil finnes flere operatører av Registry- og Repository-tjenester. Hva innebærer dette for de aktørene som skal etablere og drifte slike tjenester? Hvilke krav bør brukerne stille til slike løsninger? Dette er i hovedsak de problemstillingene som tas opp i dette dokumentet. I dette dokumentet stilles det krav til hva aktørene skal kunne gjøre/tilby, hva de bør gjøre/tilby og hva de eventuelt for egen interesse kan gjøre/tilby. Prosjektet Infrastruktur for elektronisk handel, eller Norsk EDIPRO, har verken til hensikt å etablere et Registry eller et Repository, ei heller har man til hensikt å etablere en tilsynsordning som skal påse at de kravene som stilles i dette dokumentet faktisk blir overholdt. En åpen infrastruktur for elektronisk handel må etter prosjektets oppfatning tuftes på brukernes og aktørenes egen vilje og interesse for løsningene. Det er vårt håp at markedet finner de kravene vi har stilt både fornuftige og realistiske og anser samsvar med disse kravene som et kvalitetsstempel. Denne første versjonen av dokumentet er ment som et utkast for å skissere den funksjonalitet og prinsipper en leverandør av Registry og Repository tjenester skal tilby. Prosjektet ønsker kommentarer og innspill fra brukere og leverandører for å videreutvikle dokumentet slik at det kan få en funksjon som et retningsgivende dokument. Prosjektet Infrastruktur for elektronisk handel inneholder flere leveranser hvorav ett må sees i sammenheng med denne dokumentasjonen. Innhold og beskrivelsesteknikker til Registry og Repository utarbeides parallelt med denne dokumentasjonen og blir henvist til i flere punkter. Dokumentet er utarbeidet av en arbeidsgruppe under ledelse av Mariann Sundvor, Norsk EDIPRO. Arbeidsgruppen har hatt følgende sammensetning: Hans-Petter Christiansen, Norsk Jan Mærøe, Tybring Gjedde Hydro Arild Nybakk, Skandinavisk Jostein Frømyr, EdiSys AS Transport System as Gerd Moan, Silverstream Geirr Prestholdt, Cap Gemini Roar Moe, Maris Per-Gunnar Swahn, Silverstrea Dokumentet er ført i pennen av John Krogstie, SINTEF. 3 Oslo, november 2001 Jostein Frømyr, Prosjektleder

4 Innholdsfortegnelse 4

5 1 Innledning 5

6 1 Innledning Dette dokumentet inneholder overordnet kravspesifikasjon til aksess og drift av Registry og Repository løsninger innen elektronisk handel. 1.1 Interessenter Interessenter til denne kravspesifikasjonen er de parter som har interesse av produktet/tjenesten som skal spesifiseres, enten som brukere, utviklere eller tilbydere av tjenesten. Følgende generelle interessentgrupper er identifisert: Tilbydere av elektroniske tjenester: Ønsker å kunne bruke Registry og Repository til å kommunisere til eventuelle kunder hvilke tjenester de kan tilby. Brukere av elektroniske tjenester: Ønsker å kunne bruke Registry og Repository til finne beskrivelser av tjenester de ønsker å benytte. For både brukere og tilbydere er det viktig å ta høyde for behovene og forutsetningene til både små og store virksomheter Organisasjoner som forvalter standarder innen elektronisk handel: Ønsker å kunne legge inn beskrivelse av standardprosesser/standardformater i Registry og Repository slik at de er enkelt tilgjengelige for dem som ønsker å basere sine implementasjoner på disse standardene. Leverandører av teknisk infrastruktur og tekniske løsninger: Ønsker at systemet kan inneholde beskrivelse av bruk av deres teknologi og de formater/standarder etc som de støtter. Ønsker potensielt at deres løsninger blir valgt som basisteknologi for en implementasjon av Registry og /eller /eller Repository Myndigheter: Ønsker at en løsning skal understøtte politiske mål om omfang (både i volum og i antall bedrifter) for utbredelse av elektronisk handel i Norge. Ønsker at dette skal foregå innen de lovmessige rammer som eksisterer for handel. Leverandører av Registry og Repository teknologi. Operatører: Ønsker å drifte en Registry og/eller Repository-løsning på det norske marked. Kan være en leverandør av Registry og/eller Repository-teknologi 1.2 Leserveiledning I neste seksjon oppsummeres overordnede forutsetninger for prosjektet, mens en overordnet beskrivelse og diskusjon av de viktigste aspektene ved en Registry og Repository løsning diskuteres i seksjon 3. Seksjon 4 inneholder funksjonelle krav til et slik system, i form av usecases med tilliggende beskrivelse. Seksjon 5 inneholder øvrige (ikke-funksjonelle) krav. Tekniske rammebetingelser diskuteres i seksjon 6. I tillegg finnes det en ordliste og en referanseliste i slutten av dokumentet, samt en kort oversikt over øvrige momenter som har vært diskutert som en del av arbeidet, uten at det har blitt tatt med som krav til løsningen. 6

7 2 Overordnede Forutsetninger Prosjektets overordnede målsetning er i prosjektdirektivet for spesifikasjonfasen formulert til å være: Å gjøre elektronisk handel i utvidet betydning lettere tilgjengelig, spesielt for små og mellomstore bedrifter, uten at det skal være nødvendig for den enkelte bedrift å tilpasse seg teknologien som benyttes i "andre enden, ved å legge til rette for etablering av et sett av informasjonsbanker og tilhørende indeks (Repository og Registry) som er åpent tilgjengelige og inneholder informasjon om de konkrete løsninger som benyttes i markedet Følgende operative mål relevant for overordnede krav til Registry og /Repository er definert for spesifikasjonsfasen: Legge til rette for etablering av et eller flere Repositories og tilhørende felles Registry i det norske markedet ved å etablere en beskrivelsesteknikk som kan benyttes for å beskrive innholdet i Registry og Repository Legge til rette for samtrafikk og samarbeid mellom tjenesteyterne i infrastrukturen ved å definere tjenester fra en tjenesteyter og informasjon om hvordan samtrafikk med tjenesteyteren skal gjennomføres som en del av innholdet i et Registry Forankre bruken av åpne Repository og Registry blant norske bruker- og leverandørmiljøer gjennom aktiv markedsføring og påvirkning. Selv om kartleggingsfasen konkluderte med at en åpen infrastruktur for elektronisk handel må tilrettelegge for et mangfold i tekniske løsninger, har vi i videreføringen av prosjektet valgt å legge til grunn en forutsetning om at infrastrukturen vil bygge på Internett-relatert teknologi og at eventuelt andre teknologier vil komme som et supplement. 7

8 3 Overordnet beskrivelse Følgende figur 1 beskriver overordnet bruksmønster av en Registry og Repository løsning (og hva som normalt gjøres uavhengig av disse). Figur 1: Overordnet bruksscenario for bruk av Registry og Repository 1. En fremtidig tilbyder av en tjeneste (Bedrift A) aksesserer (eventuelt) Registry for å finne ut hvilke standardiserte meldingsstrukturer og forretningsprosesser etc. som er tilgjengelige og støttet gjennom infrastrukturen. Antar under at også disse standardprosessene er beskrevet i henhold til standard beskrivelsesteknikk og er lagret i et Repository som tilbyder eventuelt kan laste denne ned fra. 2. Basert på disse meldingsstrukturene/forretningsprosessene lages/tilpasses lokale systemer hos bedrift A. 3. Hva de lokale systemene hos bedrift A tilbyr, og på hvilken måte, registreres/representeres i Registry og Repository ved bruk av standard beskrivelsesteknikk. Bedrift A, eller den organisasjon som har lagt informasjonen inn i Registry og Repository er informasjonseier og derfor ansvarlig for kvaliteten av denne. 4. Et annet bedrift (bedrift B) aksesserer Registry for å lete etter mulige samarbeidspartnere. Ved identifisering av en eller flere interessante kandidater laster 1 Figuren er tatt fra en ebxml-presentasjon uten at dette gir noen føringer om i hvor stor grad eksisterende ebxmlspesifikasjoner skal benyttes. 8

9 bedrift B (informasjonsbruker) ned representasjonene av en eller flere løsninger fra Repository. 5. Bedrift A og B inngår en avtale basert på (en eventuelt videreutvikling og forfining av) forretningsprosessbeskrivelsen og tilpasser sine systemer/løsninger gjensidig for å kunne utføre sine forretningstransaksjoner. 6. Bedrift A og B gjennomfører forretningstransaksjoner basert på den inngåtte avtalen. FMS Repository Repository Markeds plass Registry Markeds plass Repository FMS Figur 2: Prinsippskisse arkitektur Figur 2 over viser en prinsippskisse av en løsning med en Registry og en rekke Repositories. Vi vil ha dette som utgangspunkt i dokumentet. Man kan ha mange Registries i parallell, drevet av ulike operatører. Ulike Repositories kan også drives av ulike operatører, og ikke nødvendigvis av de samme som driver Registries. Alle operatører av Registries og Repositories som ønsker å følge de krav som er fremlagt i dette dokumentet må tilkjennegi at de følger de angitte krav vedrørende drift av Registry og Repositories. En operatør kan velge om han vil drifte Registry og/eller Repository. En operatør som velger å bare drifte et Registry må gjøre dette slik at det kan fungere sammen med et eller flere Repositories laget i henhold til prosjektets spesifikasjon. Tilsvarende må en operatør som bare skal drifte et Repository ta hensyn til at det skal fungere sammen med en Registry tjeneste som driftes av en annen part. Det skal være mulig å lagre all relevant informasjon om de løsninger som er tilgjengelige i markedet. Dette inkluderer Beskrivelse og informasjon av forretningsmodeller for de områdene som omfatter både forretningsprosessene og de data som benyttes ved en elektronisk samhandling. Modeller og beskrivelser av de meldinger som utveksles, eller elektroniske skjema som benyttes. Modeller og beskrivelser av de tekniske løsninger som benyttes for å realisere forretningsprosessene. 9

10 Semantiske definisjoner av de data som er definert i forretningsmodellene. Rapporten Innhold og beskrivelsesteknikker til Registry og Repository definerer i større detalj hva som skal lagres i Registry og Repository. Handelskataloger og varedata ligger ikke i et Repository. Transaksjonsdata (dvs. informasjon om enkelthandler se steg 6 i figur 1) lagres heller ikke i Repository. 10

11 4 FUNKSJONELLE KRAV Under er det illustrert de viktigste kravene i form av use-casediagrammer. Nummereringene i billedteksten vil bli benyttet som referanser videre i dokumentet. I slutten av avsnittet er det beskrevet et scenario for hvordan Registry og Repository kan bli brukt sammen i en helhetlig løsning. 4.1 Innlegging i Registry Registry 0.1 Logg inn på registry Informasjonseier (submitter) 1.1 Legg inn registry-beskrivelse av tjeneste 1.2 Oppdater registry-beskrivelse av tjeneste 1.3 Fjern registry-beskrivelse av tjeneste Operatør Figur2: Innlegging i Registry Roller (aktører i UML-terminologi) 11

12 Informasjonseier (submitter): Organisatorisk enhet som legger informasjon inn i et Registry med peker til en mer omfattende beskrivelse i Repository. Registreringen kan enten referere til en standardprosess/standardformat, der innlegger typisk vil være et standardiseringsorgan, eller en konkret forretningsprosess som tilbys. Innlegger kan i det siste tilfelle enten være selve forretningspartneren (den som tilbyr tjenesten), eller noen som handler på vegne av denne tilbyderen. Innlegger vil fungere som informasjonseier og er den som er ansvarlig for kvaliteten av innholdet i Registry samt det som blir refereres til fra Registry. Med kvalitet menes her at de prosessene som beskrives faktisk tilbys, og at beskrevet funksjonalitet er tilstede. I tillegg omfatter kvalitet her at de definerte språk for å beskrive tjenester er brukt på riktig måte. Operatør: Organisatorisk enhet som drifter og administrerer Registry (tilbyder av Registry tjenester). Use Cases: UC 0.1. Logg inn i systemet: Informasjonseier og operatør som skal endre de tjenester som tilbys gjennom Registry, skal først tvinges til å identifisere seg. UC 1.1. Legg inn Registry-beskrivelse av tjeneste: En innlegger av en tjeneste kan legge inn dokumentasjon inkludert peker til denne. Det skal tilbys to varianter av denne funksjonen: En tjeneste er allerede lagt inn i et Repository, og man ønsker å oppdatere Registry til å referere til denne. En ny tjeneste skal legges inn i Repository (se UC 1.5), samt at Registry oppdateres til å peke til denne. Grensesnittet for innlegging bør her utformes slik at dette oppfattes som en integrert prosess. Systemet skal validere at beskrivelsen i Registry er i henhold til formatet for denne (riktig syntaks jmfr. regler som beskrives i dokument Innhold og beskrivelsesteknikker til Registry og Repository. Det bør være mulig å registrere ufullstendig definerte tjenester, og disse skal markeres som ufullstendige. Det bør kunne indikeres når tjenesten skal spesifiseres komplett. Et eksempel på en ufullstendig tjenestebeskrivelse kan være en prosess der man har definert at det skal være fire meldingsutvekslinger, men bare tre av dem er ferdig definert. UC 1.2. Oppdater Registry-beskrivelse av tjeneste: Det skal være mulig å oppdatere en Registry beskrivelse for informasjonseieren av tjenestebeskrivelsen. UC 1.3. Fjern Registry-beskrivelse av tjeneste: Det skal være mulig å slette en eksisterende tjenestebeskrivelse av dem som har lagt den inn. Operatøren bør ha mulighet til å fjerne en tjenestebeskrivelse i Registry (f.eks. hvis informasjonseier ikke lenger eksisterer). Hvis operatøren fjerner en tjeneste, skal informasjonseier bli informert. 4.2 Innlegging i Repository Følgende use cases beskriver funksjonaliteten for innlegging i et Repository. 12

13 Repository 0.2 Logg inn på repository Informasjonseier 1.5 Legg inn repository-beskrivelse av tjeneste 1.6 Oppdater repository-beskrivelse av tjeneste Operatør 1.7 Fjern repository-beskrivelse av tjeneste Figur 4 : Innlegging i Repository Roller (aktører i UML-terminologi) Informasjonseier (submitter): Organisatorisk enhet som legger informasjon inn et Repository. Registreringen kan enten referere til en standardprosess/standardformat, der innlegger typisk vil være et standardiseringsorgan, eller en konkret forretningsprosess som tilbys. Innlegger kan i det siste tilfelle enten være selve forretningspartneren (den som tilbyr tjenesten), eller noen som handler på vegne av denne. Innlegger vil fungere som informasjonseier og er den som er ansvarlig for kvaliteten av innholdet i Repository. Operatør: Organisatorisk enhet som drifter og administrerer Repository. Use Cases: UC 0.2. Logg inn i systemet: Informasjonseier og operatør som skal legge inn eller endre de tjenester som er representert i Repository, skal først tvinges til å identifisere seg. 13

14 UC 1.5. Legg inn Repository-beskrivelse av tjeneste: En informasjonseier kan legge inn dokumentasjon på tjenesten i Repository. Det bør være mulig å ha en sømløs integrasjon mellom funksjonaliteten for å legge inn en tjenestebeskrivelse i Repository, og å legge inn peker til denne fra Registry. Systemet bør validere at beskrivelsen i Repository er i henhold til formatet for denne (riktig syntaks i henhold til beskrivelse gitt i dokument Innhold og beskrivelsesteknikker til Registry og Repository. Det skal her også avklares om det er enkelte formater som et Repository skal sjekke i forhold til syntaks). Det bør være mulig å registrere ufullstendig definerte tjenester, og disse skal markeres som ufullstendige. Det bør kunne indikeres når tjenesten skal spesifiseres komplett. Det kan tilbys mulighet for å definere at bare deler av Repository innholdet er fritt tilgjengelig for alle, mens andre deler er skjult dersom en avtale om samhandling først må tre i kraft. UC 1.6. Oppdater Repository beskrivelse av tjeneste: Det skal være mulig å oppdatere en Repository beskrivelse for informasjonseier av tjenesten UC 1.7. Fjern Repository beskrivelse av tjeneste: Det skal være mulig å slette en eksisterende tjenestebeskrivelse fra Repository av de som har lagt den inn. Operatøren bør ha mulighet til å fjerne en tjenestebeskrivelse i Repository (f.eks. hvis et firma som har definert tjenesten, ikke lenger eksisterer). Hvis operatøren fjerner en tjeneste, skal informasjonseier bli informert. Når en tjeneste fjernes fra Repository skal også registreringen i Registry som peker til denne fjernes. 4.3 Finn tjeneste gjennom Registry Use case viser basisinformasjon i forhold til bruk av et Registry. Bruk av Registry for å hente ut informasjon skal ikke kreve brukeridentifikasjon Registry 2.1 Let etter tjeneste Bruker 2.2 Søk etter tjeneste Figur 5. Finn tjeneste gjennom Registry 14

15 Roller (aktører i UML-terminologi) Bruker: En som har behov for å finne en tjenestebeskrivelse gjennom Registry. Dette kan være søk etter en standardbeskrivelse for å implementere en tjeneste og som deretter kan gjøres tilgjengelig gjennom Registry og Repository. Alternativt er det søk etter beskrivelse av en forretningsfunksjon som tilbys av en mulig forretningspartner. Bruker kan være en person eller en dataapplikasjon Use Cases UC 2.1. Let etter tjeneste: Det skal tilbys et navigeringsgrensesnitt som muliggjør å lete seg frem til (browse) en type tjeneste i Registry. Detaljerte krav til dette vil avhenge av de avtalte beskrivelsesteknikkene. UC 2.2. Søk etter tjeneste: Det bør eksistere søkemotor funksjonalitet som gjør det mulig å søke etter tjenester i Registry etter gitte kriterier. Hvilke kriterier dette skal gjelde, bestemmes nærmere når dokument Innhold og beskrivelsesteknikker til Registry og Repository er ferdig. Søkemotoren skal kunne aksesseres via et menneske-maskin grensesnitt. Det skal også finnes et grensesnitt for å søke som kan benyttes direkte av en data applikasjon. 4.4 Finn og last ned Repository innhold Use case viser basisinformasjon i forhold til bruk av et Repository. Bruk av Repository for å hente ut informasjon skal ikke kreve brukeridentifikasjon. Repository 2.5 Slå opp i kjent tjeneste Bruker 2.6 Last ned tjenestebeskrivelse Figu 6. Finn tjeneste gjennom Registry Roller (aktører i UML-terminologi) Bruker: En som har behov for å finne en tjenestebeskrivelse i Repository. Dette kan være søk etter en standardbeskrivelse for å implementere en tjeneste som så eventuelt skal publiseres gjennom Registry/Repository. Alternativt er det søk etter beskrivelse av en forretningsfunksjon som tilbys av en mulig forretningspartner. Bruker kan være en person eller en data applikasjon 15

16 Use cases: UC 2.5. Slå opp i kjent tjeneste: Alle tjenestene skal ha en entydig definisjon, slik at man enkelt kan finne en tjeneste eller beskrivelse man allerede kjenner til direkte i Repository. UC 2.6. Last ned tjenestebeskrivelse: Det skal være mulig å laste ned den komplette beskrivelsen av tjenesten fra et felles Repository. Der en komplett beskrivelse ikke er lagt inn enda, skal bruker få melding om dette. En bruker kan laste ned ubegrenset antall tjenestebeskrivelser. Nedlastning skal kunne startes både fra et menneske-maskin grensesnitt og fra en applikasjon. Hovedscenario for bruk Følgende scenario illustrere normal prosessflyt i bruk av Registry og Repository, se figur 1. En bransjeorganisasjon legger inn sine standardformater og prosesser i Registry (UC 1.1) og Repository (UC 1.5) Bedrift A skal implementere nye løsninger og slår opp i Registry for eventuelle bransje prosesser. (UC 2.1) Bedrift A finner bransje beskrivelsen av de relevante prosessene og laster ned disse.(uc 2.6) Det er mulig å laste ned hele eller deler av beskrivelsene. Når Repository adressen er kjent, kan Repository aksesseres direkte uten å gå veien via Registry. (UC 2.5/UC 2.6) Ved ferdig implementasjon av egne løsninger, dokumenteres dette med bruk av standard beskrivelsesteknikk i eget Repostory, og peker til dette legges inn i Registry (UC 1.1) Bedrift Y vurderer å gå inn på e-handel og trenger i sammenheng med dette blant annet å oppdatere transportløsningene sine. Bedrift Y søker i Registry (UC 2.2). Bedrift Y identifiserer relevante tjenester gitt av Bedrift B, og går inn i Repository for å finne definisjonene av tjenestene. Tjenestebeskrivelsene finnes i Repository og lastes ned derfra (UC 2.6). Bedrift Y kontakter Bedrift B, og gjør avtale med bedrift B etter en nærmere avklaring (i eller utenfor systemet). Etter en eventuell tilpasning av egne systemer, kan Bedrift Y og Bedrift B samhandle elektronisk. 4.5 Overordnede krav til representasjonsform Beskrivelsesformen skal være lett å bruke både for informasjonseiere(submitter) og brukerne. Samtidig skal sentrale deler av beskrivelsesspråket ha en formell syntaks og en operasjonell semantikk slik at modellene er tolkbare av en datamaskin, der dette er ønskelig. Et programmeringsspråk har operasjonell semantikk, siden det er kjent hvordan en datamaskin skal eksekvere et slikt program.. En representasjonsform som use cases har en formell syntaks. Et datasystem kan ikke gjennomføre eksekvering basert på en use case modell. Det er mulig å lage en automatisk kontroll av at modellen er i henhold til syntaksreglene til dette språket. 16

17 5 Øvrige krav Vi lister her øvrige (ikke-funksjonelle) krav til Registry og Repository. Der det er samme krav til både Registry og Repository, har vi ikke skilt beskrivelsen i to slik vi har gjort under funksjonelle krav. 5.1 Ytelse Trafikken på et Registry og felles Repository antas å bli begrenset. Følgende generelle retningslinjer bør være førende for responstid på de implementerte løsningene som skal aksesseres av en person direkte: Innskriving, bevegelse av mus, valg fra lister: millisekunder Enkle gjøremål som gjøres ofte: Mindre enn et sekund. Eksempel: bevegelse mellom side i Registry, innlogging i Registry Vanlig gjøremål: 2-4 sekunder. Eksempel: Motta resultat av et søk i Registry Komplekse gjøremål som gjøres sjeldent: Mindre enn 10 sekunder. Eksempel: Innlegging i Repository, nedlastning fra Repository. Hvis gjøremål tar lang tid, skal bruker gis en indikasjon om dette, samt om fremdriften i operasjoner. 5.2 Tilgjengelighet Systemene (Registry og Repository) skal være tilgjengelig 24 timer i døgnet alle dager. Reparasjonstid (Større reparasjoner av systemene som fører til at systemet må tas ned over lengre tid) skal gjøre i tidsrommet 20-7 på arbeidsdager eller i helger. Ved slike reparasjoner skal det klart fremgå ved forsøk på aksess av systemet, at det for øyeblikket er utilgjengelig, samt når det skal bli tilgjengelig igjen 5.3 Sikkerhet I denne sammenheng må det understrekes at operatøren bare administrerer den tekniske infrastrukturen. Adgangskontroll i henhold til autorisasjon Det er så langt definert 3 overordnede roller: Operatør (tilbyder av Registry og Repository) Informasjonseier (innlegger) Bruker For aktører som inngår i de to første rollene er det adgangskontroll som styrer tillatte operasjoner. Generelle brukere skal kunne søke i Registry og laste ned innhold fra åpne deler av Repository uten å måtte identifisere seg. Integritet Det skal sikres at det som ligger i Registry og Repository ikke blir oppdatert av andre enn informasjonseier, og at det ikke endres som del av overføring til bruker. 17

18 Autentisering av tilbyder. All innlegging og oppdatering av tjenestebeskrivelser skal være autentisert. Det bør være mekanismer for å oppdatere autentitets informasjon ved oppkjøp og sammenslåinger av bedrifter. Kryptering Arbeidsgruppen, som har utarbeidet denne dokumentasjon, ser så langt ikke behov for bruk av kryptering. Eventuell kryptering skal imidlertid støtte standardteknikker for dette, slik at man unngår å gjøre systemet vanskelig å bruke for enkelte brukergrupper. En mulig bruk av kryptering er ved overførsel av bruker/passord før innlegging i Registry/Repository, samt nedlastning av innhold med begrenset tilgjengelighet fra Repository. 5.4 Robusthet og feilhåndtering Systemet skal generere forståelige feilmeldinger ved feil fra brukeren. Systemet skal ikke feile selv om det er feil i input-data. Det skal være sikkerhetskopierings funksjonalitet og mulighet for å spore endringer slik at registrerte data ikke skal gå tapt ved en teknisk feil. Sikkerhetskopiering av data i felles Repository/Registry skal gjennomføres på daglig basis. 5.5 Brukervennlighet Systemet bør dekke støtte for flere språk. Som et minimum bør man støtte norsk og engelsk i aksessgrensesnittet for personer. Bruker skal oppfatte Registry og Repository som et system, med utstrakt brukergrensesnittintegrasjon. En konkret brukergrensesnittstandard skal avklares før implementasjon av Registry og Repository igangsettes. 5.6 Lovmessige krav Eiendomsrett til informasjon som legges i Repository må avklares, enten ved å støtte seg til eksisterende lovverk, eller ved å opprette egne avtaler som dekker de aspektene ved bruk av Registry og/eller Repository som ikke er dekket i lovverket. 5.7 Forretningsmessig og markedsmessige krav Ideelt sett er det ønskelig å oppfylle følgende til dels motstridende krav (sett fra et rent kommersielt perspektiv): Systemet bør representere informasjon om løsninger og standarder i utbredt bruk. Operatør bør bidra til at en kritisk mengde virksomheter benytter systemet. Operatør bør bidra til at datakvaliteten er tilstrekkelig høy for å tiltrekke samt holde på kundene. Kostnaden ved å bruke systemet skal ikke være for stor. Systemet bør ideelt opereres på en non-profitbasis (dvs. slik at kostnader dekkes.) 18

19 Operatøren må ha tillit og tyngde i markedet. Operatøren må ha langsiktig soliditet og garantert tilstedeværelse. Operatør skal være registrert som næringsdrivende i Norge. Det skal være mulig å etablere flere enn ett Registry og flere enn et Repository. Aktører som skal være operatører for Registry og/eller Repository kan være kommersielle, statlige eller organisert som en stiftelse. 5.8 Krav til rutiner hos operatør Brukerstøtte skal etableres i vanlig kontortid. Mottaksapparat for driftsfeil og funksjonelle feil skal etableres. Rutiner for arkivering av data skal etableres. Rutiner for sikkerhetskopiering og tilbakelegging av data skal etableres. 19

20 6 Tekniske rammebetingelser Man skal basere arbeidet på åpne standarder. Relasjon til internasjonale standarder og initiativ innen dette område så som ebxml, UDDI, UML, og UMM må avklares i det videre arbeidet. 6.1 Krav til teknisk plattform Man skal kunne bruke Registry og Repository via standard Internett-teknologi ved bruk av de til enhver tid mest utbredte browsere (I dag betyr det de mest utbredte variantene av Internet Explorer og Netscape. I fremtiden kan det være andre systemer som får stor utbredelse, og det er et krav til operatør av Registry og/eller Repository at systemet skal kunne aksesseres også av disse). 6.2 Eksterne grensesnitt Både Registry og Repository skal kunne aksesseres via eksterne applikasjoner som indikert under funksjonelle krav. 20

21 7 Vedlegg Ordliste med forkortelser og viktige begreper Alle viktige forkortelser og akronymer listes her sammen med betydningen. FMS: Formidlingssentraler Registry: En indeks over den informasjon som er tilgjengelig i en eller flere informasjonsbanker (Repository) om løsninger og tjenester for elektronisk handel med pekere til hvor i informasjonsbanken(e) (Repositoriene) opplysningene er tilgjengelige. Repository: En informasjonsbank med opplysninger om de elementene som inngår i en infrastruktur for elektronisk handel og hvordan de skal brukes sammen. 7.1 Referanser Bindende dokumenter Dette er dokumenter som stiller krav til systemet. 1. Prosjektdirektiv for spesifikasjonsfasen 2. Relevante lovtekster 3. Innhold og beskrivelsesteknikker for Registry og Repository Referansedokument: Referansedokument er dokument som kan gi nyttig tilleggsinformasjon. 1. Standarder (ebxml, UDDI). Se Innhold og beskrivelsesteknikker til Registry og Repository, for pekere til spesielt relevante deler. 2. Beskrivelse av UML (http://www.omg.org) 3. Forslag til kriterier for utvelgelse av prosjekter og forretningsprosesser 4. Forslag til krav til beskrivelsesteknikker for innhold i Repository Avledede dokument: Avledede dokumenter er dokument som planlegges skrevet basert på dette dokumentet. 21

Infrastruktur for elektronisk handel

Infrastruktur for elektronisk handel Prosjekt i regi av Norsk EDIPRO Bruk av Registry og Repository i en åpen infrastruktur for elektronisk samhandling Versjon 1.0 31 oktober 2002 Norsk EDIPRO Tel. 22 12 83 90 Postboks 2526 Solli Fax. 22

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Internett

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Internett PRODUKTBESKRIVELSE INFRASTRUKTUR NRDB Internett Versjon 3.0 11/10/04 Nasjonal referansedatabase AS 15/10/04 Page 1 of 10 Innholdsfortegnelse 1 INNLEDNING...3 1.1 NUMMERPORTABILITET...3 1.2 VIDERESALG TELEFONI...3

Detaljer

Infrastruktur for elektronisk handel. Et prosjekt i regi av Norsk EDIPRO. Møte om oppstart av hovedprosjekt 16 mai 2001. EdiSys. www.edisys.

Infrastruktur for elektronisk handel. Et prosjekt i regi av Norsk EDIPRO. Møte om oppstart av hovedprosjekt 16 mai 2001. EdiSys. www.edisys. Et prosjekt i regi av Norsk EDIPRO Møte om oppstart av hovedprosjekt 16 mai 2001 Dagsorden 1. Innledning og mål med prosjektet 2. Internasjonale aktiviteter med relevans for prosjektet 3. Nasjonale aktiviteter

Detaljer

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Lokal Node (VPN)

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Lokal Node (VPN) PRODUKTBESKRIVELSE INFRASTRUKTUR Lokal Node (VPN) Versjon 3.0 11/10/04 Nasjonal referansedatabase AS 14/10/04 Page 1 of 11 Innholdsfortegnelse 1 INNLEDNING...3 1.1 NUMMERPORTABILITET...3 1.2 VIDERESALG

Detaljer

Navngivning av XML elementer

Navngivning av XML elementer Navngivning av XML elementer Versjon 1.0 En anbefaling fra Norsk EDIPRO August 2002 Norsk EDIPRO Tel. 22 12 83 90 Postboks 2526 Soll Fax. 22 12 83 97 0202 Oslo Internet: www.edipro.no Forord Språket XML,

Detaljer

Technical Integration Architecture Teknisk integrasjonsarkitektur

Technical Integration Architecture Teknisk integrasjonsarkitektur Kap. 6 Technical Integration Architecture Studentpresentasjon av Cato Haukeland Oversikt Introduksjon -spesifikasjon Krav Beskrivelse Servicenivå Sikkerhet Plan Best practices Introduksjon Masterdokument

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit

Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit Prosjektansvarlig Nasjonal IKT for arkitektur Innhold Hvorfor jobbe

Detaljer

PRODUKTBESKRIVELSE TJENESTE. NRDB Nummerportabilitet

PRODUKTBESKRIVELSE TJENESTE. NRDB Nummerportabilitet PRODUKTBESKRIVELSE TJENESTE NRDB Nummerportabilitet Versjon 2.0 11/10/04 Nasjonal referansedatabase AS 15/10/04 Page 1 of 8 Innholdsfortegnelse 1 INNLEDNING...3 1.1 NUMMERPORTABILITET...3 1.2 VIDERESALG

Detaljer

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Sentralisert Node

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Sentralisert Node PRODUKTBESKRIVELSE INFRASTRUKTUR NRDB Sentralisert Node Versjon 3.0 11/10/04 Nasjonal referansedatabase AS 14/10/04 Page 1 of 10 Innholdsfortegnelse 1 INNLEDNING...3 1.1 NUMMERPORTABILITET...3 1.2 VIDERESALG

Detaljer

PRODUKTBESKRIVELSE TJENESTE. NRDB Videresalg Telefoni

PRODUKTBESKRIVELSE TJENESTE. NRDB Videresalg Telefoni PRODUKTBESKRIVELSE TJENESTE NRDB Videresalg Telefoni Versjon 2.0 11/10/04 Nasjonal referansedatabase AS 15/10/04 Page 1 of 8 Innholdsfortegnelse 1 INNLEDNING...3 1.1 NUMMERPORTABILITET...3 1.2 VIDERESALG

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

AP226 Use Case Diagram - SBL

AP226 Use Case Diagram - SBL AP226 Use Case Diagram - SBL Use Case Diagram Figuren under (Figur 1) viser en oversikt over alle use case for Sluttbrukerløsningen i Altinn 2 versjon 1. Den innerste firkanten inneholder alle use case

Detaljer

Anbefalinger om videreutvikling av Oppgaveregistret

Anbefalinger om videreutvikling av Oppgaveregistret E L M E R ENKLERE OG MER EFFEKTIV RAPPORTERING Middelthuns gate 27, Postboks 5250 Majorstua, N-0303 Oslo Anbefalinger om videreutvikling av Oppgaveregistret Rapport fra ELMER-prosjektet 24. juli 2001 Et

Detaljer

Grunnleggende om Evaluering av It-systemer

Grunnleggende om Evaluering av It-systemer Grunnleggende om Evaluering av It-systemer Hva er å evaluere? Foreta en vurdering av systemet og avklare nytten det har for brukerne. En systematisk innsamling av data som gir informasjon om nytteverdien

Detaljer

Innholdsstandard (meldinger) ebxml-rammeverk (innpakking, adressering, transportkvittering, kryptering, autentisering, virksomhetssignatur)

Innholdsstandard (meldinger) ebxml-rammeverk (innpakking, adressering, transportkvittering, kryptering, autentisering, virksomhetssignatur) NOTAT Fra KITH v/bjarte Aksnes m.fl. Dato 29.03.06 Samhandlingsarkitektur for helsesektoren En viktig forutsetning for at aktører i helsesektoren skal kunne samhandle elektronisk på en god måte er at alle

Detaljer

AP221 Use Case TUL Utarbeid designdokumenter

AP221 Use Case TUL Utarbeid designdokumenter AP221 Use Case TUL Utarbeid designdokumenter Utarbeid design Tjenesten designes. Dette er en samling av tre use case: Endre designdokument, Lag nytt designdokument, Last opp designdokument. Designet kan

Detaljer

GS1 Validering Brukerdokumentasjon 24.06.2008

GS1 Validering Brukerdokumentasjon 24.06.2008 GS1 Validering Brukerdokumentasjon 24.06.2008 24.06.2008 All contents copyright GS1 2008 Side 1 av 9 Innholdsfortegnelse 1. Introduksjon... 3 1.1. Bakgrunn... 3 1.2. Formål... 3 1.3. Bruksområde... 3 1.4.

Detaljer

FINT Forretningsmodell for Intermodal Transport. Et forsknings- og utviklingsprosjekt finansiert av Forskningsrådet MAROFF-programmet

FINT Forretningsmodell for Intermodal Transport. Et forsknings- og utviklingsprosjekt finansiert av Forskningsrådet MAROFF-programmet FINT Forretningsmodell for Intermodal Transport Et forsknings- og utviklingsprosjekt finansiert av Forskningsrådet MAROFF-programmet Deltagende parter NorStella prosjektledelse Stein Erik Grønland, Sitma,

Detaljer

Kartlegging av innovasjonstyper

Kartlegging av innovasjonstyper Kartlegging av innovasjonstyper Referanse til kapittel 12 Analysen er utviklet på basis av Keeleys beskrivelse av 10 typer innovasjoner (Keeley, L. 2013. Ten Types of Innovation. New Jersey: John Wiley

Detaljer

Hvordan få tilgang til journalopplysning fra andre virksomheter

Hvordan få tilgang til journalopplysning fra andre virksomheter Hvordan få tilgang til journalopplysning fra andre virksomheter Avdelingssjef, KITH Tema Løsninger for utlevering og tilgang til helseopplysninger Utlevering ved hjelp av web-publisering Samhandlingsarkitektur

Detaljer

Ny forvaltningsløsning for primærdata. - Strategi, planer og organisering

Ny forvaltningsløsning for primærdata. - Strategi, planer og organisering Ny forvaltningsløsning for primærdata. - Strategi, planer og organisering Anne Guro Nøkleby, Kartverket Dagens modell for FKBforvaltning FKB-data oppdateres primært i lokale kommunale originaler (dels

Detaljer

Hva jeg skal snakke om

Hva jeg skal snakke om Noark 5 Del 2 Hva jeg skal snakke om Litt om programvare Proprietær og åpenkildekode Tjeneste orientert arkitekturer Moderne utviklingsmetodikk dots Noark 5 kjerne Viktig men ikke noe som er tatt opp i

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

PRODUKTBESKRIVELSE NRDB. NRDB E-post-portering

PRODUKTBESKRIVELSE NRDB. NRDB E-post-portering PRODUKTBESKRIVELSE NRDB NRDB E-post-portering Versjon 2.0 11/10/04 Nasjonal referansedatabase AS 15/10/04 Page 1 of 8 Innholdsfortegnelse 1 INNLEDNING...3 1.1 NUMMERPORTABILITET...3 1.2 VIDERESALG TELEFONI...3

Detaljer

1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2. 1. 1 Status... 2. 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV...

1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2. 1. 1 Status... 2. 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV... Dossier Kompetanse Innholdsfortegnelse 1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2 1. 1 Status... 2 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV... 3 1.2.1 Personalia... 3 1.2.2

Detaljer

Utviklingsprosjekt: Eiendomsstrategi i Helgelandssykehuset HF. Nasjonalt topplederprogram

Utviklingsprosjekt: Eiendomsstrategi i Helgelandssykehuset HF. Nasjonalt topplederprogram Utviklingsprosjekt: Eiendomsstrategi i Helgelandssykehuset HF Nasjonalt topplederprogram Bjørn Bech-Hanssen Helgeland 2014 Bakgrunn og organisatorisk forankring for prosjektet Administrerende direktør

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA Sist oppdatert 18.02.2010 INNHOLD INNHOLD... 1 HVA ER CABINWEB... 2 HVA KAN DU BRUKE CABINWEB TIL?... 3 HVA ER NYTT I CABINWEB VERSJON 2.0...

Detaljer

Kravspesifikasjon for

Kravspesifikasjon for for ANSKAFFELSE AV Utarbeide WEB løsning samt maler for dokumenter og publikasjoner Luftambulansetjenesten ANS 21. juni 2012 INNHOLDSFORTEGNELSE: 1. FORORD... 3 2. KRAVSPESIFIKASJONENS OMFANG... 3 2.1

Detaljer

KRAVSPESIFIKASJON FOR SOSIORAMA

KRAVSPESIFIKASJON FOR SOSIORAMA KRAVSPESIFIKASJON FOR SOSIORAMA Innhold 1. Forord... 2 2. Definisjoner... 3 3. Innledning... 4 3.1 Bakgrunn og formål... 4 3.2 Målsetting og avgrensninger... 4 4. Detaljert beskrivelse... 8 4.1 Funksjonelle

Detaljer

NorStella. Avtalen omfatter følgende distributører.

NorStella. Avtalen omfatter følgende distributører. NorStella Det er i dag inngått følgende avtale mellom Distributører av ehandelsmeldinger og NorStella om felles samtrafikkavtale (se vedlegg) Avtalen forvaltes av NorStella gjennom forumet b2bconnect.no

Detaljer

TechnoPort 2005 Edgar Glück, Trondheim 21.10.2005

TechnoPort 2005 Edgar Glück, Trondheim 21.10.2005 Deling av RIS-informasjon mellom helseforetak Spesiallege Edgar Glück KITH Teleradiologiprosjektet i Helse Vest Skal tilby sømløs samhandling Mellom helseforetak Mellom system fra ulike leverandører Finne

Detaljer

1. Intro om SharePoint 2013

1. Intro om SharePoint 2013 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Intro om SharePoint 2013 Stein Meisingseth 09.08.2013 Lærestoffet er utviklet for faget LO205D Microsoft SharePoint 1. Intro om SharePoint

Detaljer

Sertifisering. Avdelingssjef Bjarte Aksnes

Sertifisering. Avdelingssjef Bjarte Aksnes Sertifisering Avdelingssjef Bjarte Aksnes www.kith.no Test- og godkjenningsordningen Formål for T&G: Å gi brukerne trygghet for at informasjonen overføres korrekt Å senke terskelen for å ta i bruk elektronisk

Detaljer

Fornyings og Administrasjonsdepartementet. Vår ref.: NSK/SHE/MAE Oslo, 30. september 2008

Fornyings og Administrasjonsdepartementet. Vår ref.: NSK/SHE/MAE Oslo, 30. september 2008 Fornyings og Administrasjonsdepartementet Bankenes BetalingsSentral AS Haavard Martinsens vei 54 Postadresse: 0045 Oslo Telefon: 22 89 89 89 Telefaks: 22 81 64 54 Foretaksregisteret: NO990 224 978 www.bbs.no

Detaljer

Veileder 3.2 Arbeidsdeling ved anskaffelsesprosesser over nasjonal terskelverdi

Veileder 3.2 Arbeidsdeling ved anskaffelsesprosesser over nasjonal terskelverdi Veileder 3.2 Arbeidsdeling ved anskaffelsesprosesser over nasjonal terskelverdi Dato: 10.07.2015 Ansvarlig enhet: Avdeling for økonomi Id: Sist endret av: Merethe Berger Håkonsen Dato: 10.07.2015 Erstatter:

Detaljer

SAKSFRAMLEGG. Forum: Skate Møtedato: 11.02.2015

SAKSFRAMLEGG. Forum: Skate Møtedato: 11.02.2015 SAKSFRAMLEGG Forum: Skate Møtedato: 11.02.2015 Sak under løpende rapportering og oppfølging Sak 02-2014. Veikart for nasjonale felleskomponenter. I dette møtet: Beslutningssak. Historikk/bakgrunn Skate

Detaljer

Strategi 2015-2018 Strategisk retning for Helsetjenestens driftsorganisasjon for nødnett HF for perioden 2015-2018

Strategi 2015-2018 Strategisk retning for Helsetjenestens driftsorganisasjon for nødnett HF for perioden 2015-2018 Strategi 2015-2018 Strategisk retning for Helsetjenestens driftsorganisasjon for nødnett HF for perioden 2015-2018 Innhold Hovedmål 1 Vellykket teknisk innføring av nødnett-brukerutstyr... 6 Hovedmål 2:

Detaljer

Styret Helse Sør-Øst RHF 23. oktober 2014 SAK NR 065-2014 VEDLIKEHOLDSAVTALE MELLOM DIPS ASA OG HELSE SØR-ØST RHF

Styret Helse Sør-Øst RHF 23. oktober 2014 SAK NR 065-2014 VEDLIKEHOLDSAVTALE MELLOM DIPS ASA OG HELSE SØR-ØST RHF Saksframlegg Saksgang: Styre Møtedato Styret Helse Sør-Øst RHF 23. oktober 2014 SAK NR 065-2014 VEDLIKEHOLDSAVTALE MELLOM DIPS ASA OG HELSE SØR-ØST RHF Forslag til vedtak: Styret godkjenner fremforhandlet

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

Akseptansetest av sending og mottak Applikasjonskvittering

Akseptansetest av sending og mottak Applikasjonskvittering Akseptansetest av sending og mottak Applikasjonskvittering Meldingsversjon: 1.0 Akseptansetest av sending og mottak Applikasjonskvittering 2 Innholdsfortegnelse 1. Revisjonshistorikk 3 2. Akseptansetest

Detaljer

1. Sammendrag. 2. Målsetting. Hovedmålsetting. Delmålsettinger

1. Sammendrag. 2. Målsetting. Hovedmålsetting. Delmålsettinger 1. Sammendrag Suksessen fra i fjor skal følges opp - men på en ny måte. Fokus flyttes fra merkevarebygging av sjøtransport til å øke av antall forespørsler. Varestrømmer, marked, kunder og behov skal kartlegges

Detaljer

1 Samhandlingsavtalen og de samhandlende partene

1 Samhandlingsavtalen og de samhandlende partene Side: 1 (Samhandlingsavtalen) er et avtalevedlegg til den kommersielle avtalen mellom kjøper og leverandør, som ønsker å drive handel over Ehandel.no. Samhandlingsavtalen regulerer hvordan den elektroniske

Detaljer

Utkast Kravspesifikasjon sensurregistrering

Utkast Kravspesifikasjon sensurregistrering Utkast Kravspesifikasjon sensurregistrering versjon 2.9.15 Richard Edvin Borge, Adelheid Mortensen Huuse 1 1 Introduksjon Som et ledd i digitaliseringen av eksamensprosessen er det ønskelig å få en løsning

Detaljer

Nasjonalt IKTs Klinisk IKT Fagforum

Nasjonalt IKTs Klinisk IKT Fagforum Nasjonalt IKTs Klinisk IKT Fagforum Mandat Dokumentkontroll Forfatter Gjennomgang Godkjent av Programkontoret Nasjonal IKT Klinisk IKT Fagforum Styringsgruppen Nasjonal IKT Endringslogg Versjon Dato Endring

Detaljer

Plan for SOSI-arbeid 2012, Morten presenterte planen for arbeidet med SOSI i 2012, basert på innmelding i miljøet.

Plan for SOSI-arbeid 2012, Morten presenterte planen for arbeidet med SOSI i 2012, basert på innmelding i miljøet. Referat SOSI-arbeidsgruppe 1 Teknikker og modeller Dato: 29. mars 2012 Tid: 0930-1500 Sted: Statens kartverk Oslo, møterom 2 STATENS KARTVERK Deltakere: Joan Peel Hansen, Kartverket Inger Hokstad, BA-nettverket

Detaljer

OPPLÆRING E04 01.03.96 FOR IMPLEMENTERING HBO ASO ETA E03 02.02.96 FOR IMPLEMENTERING HBO ASO ETA A02 24.01.96 INTERN UTGAVE HBO ASO

OPPLÆRING E04 01.03.96 FOR IMPLEMENTERING HBO ASO ETA E03 02.02.96 FOR IMPLEMENTERING HBO ASO ETA A02 24.01.96 INTERN UTGAVE HBO ASO Side: 1 av 10 DOKUMENT TITTEL: OPPLÆRING LEVERANDØR OSLO HOVEDFLYPLASS AS E04 01.03.96 FOR IMPLEMENTERING HBO ASO ETA E03 02.02.96 FOR IMPLEMENTERING HBO ASO ETA A02 24.01.96 INTERN UTGAVE HBO ASO A01

Detaljer

Samordning av IKT i spesialisthelsetjenesten Status ny felles IKT-strategi. v/administrerende direktør i Nasjonal IKT HF, Gisle Fauskanger

Samordning av IKT i spesialisthelsetjenesten Status ny felles IKT-strategi. v/administrerende direktør i Nasjonal IKT HF, Gisle Fauskanger Samordning av IKT i spesialisthelsetjenesten Status ny felles IKT-strategi v/administrerende direktør i Nasjonal IKT HF, Gisle Fauskanger Kort om Nasjonal IKT HF etablert 2014 STRATEGISK ENHET Nasjonal

Detaljer

PRODUKTBESKRIVELSE. NRDB Sentralisert Node

PRODUKTBESKRIVELSE. NRDB Sentralisert Node PRODUKTBESKRIVELSE NRDB Sentralisert Node Versjon 3.1, juni 2007 Nasjonal referansedatabase AS, c/o Infostrada AS, St Olavs plass 3, N- 0165 OSLO Side 1 av 5 1. INNLEDNING... 3 2. NRDB SENTRALISERT NODE...

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

Detaljer

Digitalt førstevalg og felleskomponenter

Digitalt førstevalg og felleskomponenter Digitalt førstevalg og felleskomponenter Ark2011 Cat Holten Brønnøysundregistrene Agenda Altinns arkitektur i fugleperspektiv Nye utfordringer ved økt modenhet Problemstillinger til diskusjon Ark 2011

Detaljer

Helhetlig integrasjonsplattform. Per Olav Nymo

Helhetlig integrasjonsplattform. Per Olav Nymo Helhetlig integrasjonsplattform Per Olav Nymo Affecto i korte trekk Bergen I Norge siden 1997 Spesialisert på Enterprise Information Management 130 ansatte i Oslo og Bergen 1.000 ansatte i Norden og Baltikum

Detaljer

Derfor trenger du BankID på nettstedet ditt

Derfor trenger du BankID på nettstedet ditt Derfor trenger du BankID på nettstedet ditt 2 400 000 Over 2,4 millioner nordmenn bruker allerede BankID daglig i nettbanken nordmenn kan bruke BankID på ditt nettsted BankID installert på ditt nettsted

Detaljer

Integrasjon Altinn. 31. august 2009 Morten Græsby

Integrasjon Altinn. 31. august 2009 Morten Græsby Integrasjon Altinn 31. august 2009 Morten Græsby 1 Formål Gi en grunnleggende oversikt over muligheter for integrasjon mot den nye Altinn-løsningen Fokus på integrasjon mot Altinn tjenester: Sluttbrukersystem

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Visma Anbud og Kontrakt Releasedokumentasjon

Visma Anbud og Kontrakt Releasedokumentasjon Visma Anbud og Kontrakt Releasedokumentasjon Versjon 6.6.1 25. januar 2011 1. VISMA ANBUD OG KONTRAKT (KGV) - RELEASEDOKUMENTASJON V6.6.1...3 Kritiske momenter som er viktig for eksisterende brukere før

Detaljer

Endringer i versjon 14.1

Endringer i versjon 14.1 Endringer i versjon 14.1 Endringsnummer Endring Brukskvalitet 14165 Liste over aktører man representerer. Brukere som representerer mange aktører ønsker å kunne skrive ut denne listen til excel for å få

Detaljer

Endringer i versjon 14.1

Endringer i versjon 14.1 Endringer i versjon 14.1 Endringsnummer Endring Brukskvalitet 14165 Liste over aktører man representerer. Brukere som representerer mange aktører ønsker å kunne skrive ut denne listen til excel for å få

Detaljer

Testdokumentasjon. Testdokumentasjon Side 1

Testdokumentasjon. Testdokumentasjon Side 1 Testdokumentasjon Testdokumentasjon Side 1 1. Innledning Dette er en testrapport som er laget for å teste applikasjonene for ios og Android plattformer. Den vil være delt opp i 4 deler. Den første delen

Detaljer

Nasjonal DNA sekvensdata IT plattform for helsevesenet- genap. Store data møter medisinen 1. september 2015

Nasjonal DNA sekvensdata IT plattform for helsevesenet- genap. Store data møter medisinen 1. september 2015 Nasjonal DNA sekvensdata IT plattform for helsevesenet- genap Store data møter medisinen 1. september 2015 1 Målsetning med prosjektet Prosjektets målsetning er å utvikle en IKT infrastruktur for sentral,

Detaljer

Notat om Norge digitalt og Norvegiana

Notat om Norge digitalt og Norvegiana mai 2015 Notat om Norge digitalt og Norvegiana Rammer og forutsetninger Dette notatet tar for seg problemstillinger som er aktuelle for samhandling mellom Norvegiana og Norge digitalt i et fremtidig digitalt

Detaljer

Jara NetBusiness og Jara B2B Volum

Jara NetBusiness og Jara B2B Volum Vilkårs - og funksjonsbeskrivelse for Jara NetBusiness og Jara B2B Volum 01.01.2010 Versjon 7.0 Innholdsfortegnelse VILKÅRS - OG FUNKSJONSBESKRIVELSE... 1 1 INNLEDNING... 4 1.1 HENSIKT... 4 1.2 DEFINISJONER...

Detaljer

360 emeetings. -Papirløse møter på ipad eller iphone

360 emeetings. -Papirløse møter på ipad eller iphone 360 emeetings -Papirløse møter på ipad eller iphone 360 emeetings for Apple ios 360 emeetings - en løsning med multitouch og et levende brukergrensesnitt. 360 emeetings hjelper deg og din virksomhet med

Detaljer

Installasjonsbeskrivelse for CAB Service Plattform med CABInstall

Installasjonsbeskrivelse for CAB Service Plattform med CABInstall Installasjonsbeskrivelse for CAB Service Plattform med CABInstall INNLEDNING... 2 INSTALLASJON... 3 AVANSERT INSTALLASJON... 10 YTTERLIGERE INFORMASJON... 11 Proxy... 11 Side 1 av 11 Innledning Denne beskrivelsen

Detaljer

Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet

Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet Bakgrunn Utredningen av standarder for informasjonssikkerhet har kommet i gang med utgangspunkt i forprosjektet

Detaljer

NORSK EDIEL BRUKERVEILEDNING. bruk av SMTP. for. Versjon: 1.0 Revisjon: E Dato: 3. Mars 2008

NORSK EDIEL BRUKERVEILEDNING. bruk av SMTP. for. Versjon: 1.0 Revisjon: E Dato: 3. Mars 2008 NORSK EDIEL BRUKERVEILEDNING for bruk av SMTP Versjon: 1.0 Revisjon: E Dato: 3. Mars 2008 Systemstøtte for Ediel / Norsk Ediel Ekspertgruppe Side: 1 INNHOLDSFORTEGNELSE 1 Bakgrunn... 3 2 Referanser...

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

EasyPublish Kravspesifikasjon. Versjon 1.0

EasyPublish Kravspesifikasjon. Versjon 1.0 EasyPublish Kravspesifikasjon Versjon 1.0 Endringshistorie Dato Versjon Kommentarar Person 12.04.2005 1.0 Første utkast Jesro Christoffer Cena Innhald 1 Innleiing...4 1.1 lsetjing... 4 1.2 Omfang... 4

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

Detaljer

Lansering av ny versjon av KF Lokal tjenestekatalog

Lansering av ny versjon av KF Lokal tjenestekatalog Lansering av ny versjon av KF Lokal tjenestekatalog Kommuneforlaget lanserer nå en ny versjon(4.4.) av KF Lokal tjenestekatalog, heretter kalt lokal tjenestekatalog. Mange av endringene kommer som resultat

Detaljer

STATKRAFT MOBILE WORK PLACE

STATKRAFT MOBILE WORK PLACE STATKRAFT MOBILE WORK PLACE Ronny Olaisen Ronny Olaisen Statkraft Energi AS Senior Vedlikeholds Ingeniør Sentral Teknisk Stab Forvaltning og administrasjon av SAP PM prosess - Support, SAP, MWP og BW -

Detaljer

Mandat. Ma lbilder og strategier for fellesløsninger i offentlig sektor

Mandat. Ma lbilder og strategier for fellesløsninger i offentlig sektor Mandat Ma lbilder og strategier for fellesløsninger i offentlig sektor Innhold Bakgrunn... 2 Formålet med felles målbilder og strategier... 2 Mål for arbeidet... 3 Leveranser 2015... 4 Del 1: Visjon og

Detaljer

BIRD - Administrasjon av forskningsdata (Ref #2219b941)

BIRD - Administrasjon av forskningsdata (Ref #2219b941) BIRD - Administrasjon av forskningsdata (Ref #2219b941) Søknadssum: 1 000 000 Varighet: Toårig Kategori: Innsatsområder Samarbeid og partnerskap Opplysninger om søker Organisasjonsnavn / nr Handelshøyskolen

Detaljer

Rollemodell. for. det norske kraftmarkedet

Rollemodell. for. det norske kraftmarkedet Rollemodell for det norske kraftmarkedet Versjon: 1.1.A Dato: 27. mai 2010 INNHOLD 1. INNLEDNING... 3 1.1 OM ROLLEMODELLEN... 3 1.2 EDIEL/EBIX... 3 1.3 NOEN UAVKLARTE PROBLEMSTILLINGER... 4 1.3.1 Nettområder

Detaljer

Bidrar tjenestebeskrivelser og elektroniske skjema til bedre kvalitet, bedre styring og bedre service i kommunen?

Bidrar tjenestebeskrivelser og elektroniske skjema til bedre kvalitet, bedre styring og bedre service i kommunen? Bidrar tjenestebeskrivelser og elektroniske skjema til bedre kvalitet, bedre styring og bedre service i kommunen? Karine Engebretsen Halden kommune Utfordringer Kommunen hadde; enkle publiseringsløsninger

Detaljer

AP221 Use Case SBL Finn aktive, mottatte og arkiverte elementer

AP221 Use Case SBL Finn aktive, mottatte og arkiverte elementer AP221 Use Case SBL arkiverte elementer arkiverte elementer Dette use case beskriver hvordan bruker kan finne aktive, mottatte og arkiverte elementer. Med aktive elementer menes innsendingstjenester som

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Akseptansetest av mottak Rekvirering av medisinske tjenester Medisinsk biokjemi

Akseptansetest av mottak Rekvirering av medisinske tjenester Medisinsk biokjemi Akseptansetest av mottak Rekvirering av medisinske tjenester Meldingsversjon: versjon 1.4, datert 20.05.2005 2 Akseptansetest av mottak Rekvirering av medisinske tjenester Innholdsfortegnelse 1. Revisjonshistorikk...

Detaljer

SERES - status Ressursnettverk for eforvaltning og Norstella Elektronisk Samhandling i Offentlig Sektor 27.august 2009

SERES - status Ressursnettverk for eforvaltning og Norstella Elektronisk Samhandling i Offentlig Sektor 27.august 2009 SERES - status Ressursnettverk for eforvaltning og Norstella Elektronisk Samhandling i Offentlig Sektor 27.august 2009 David Norheim, Computas 1 1 Agenda Litt kontekst SERES

Detaljer

Bransjens konklusjon og anbefaling rundt AMS-kanalen og lokale grensesnitt på målernoden

Bransjens konklusjon og anbefaling rundt AMS-kanalen og lokale grensesnitt på målernoden Bransjens konklusjon og anbefaling rundt AMS-kanalen og lokale grensesnitt på målernoden Dato: 21. november 2012 Dette notatet beskriver endelige konklusjoner fra Energi Norge og Energi Norges AMS-prosjekt

Detaljer

Høringsuttalelse forskrift om offentlige anskaffelser, klassisk sektor

Høringsuttalelse forskrift om offentlige anskaffelser, klassisk sektor Notat Til: MOD KPA Fra: Ehandelssekretariatet v/andré Hoddevik Kopi: MOD ITP Dato 6. juli 2005 Høringsuttalelse forskrift om offentlige anskaffelser, klassisk sektor Bakgrunn Det vises til Departementets

Detaljer

Avtale med Norsk Helsenett. Værnes 20/9 2012 Esben Andre Henriksen Hemit

Avtale med Norsk Helsenett. Værnes 20/9 2012 Esben Andre Henriksen Hemit Avtale med Norsk Helsenett Værnes 20/9 2012 Esben Andre Henriksen Hemit Bakgrunn Jan 2009 Oppdragsdok.H else Midt Norge Nov 2010 Programdirektiv for teknisk gruppe April 2011 Oppstartsmøte Des 2011 Sak

Detaljer

Elektronisk Samhandling i privat og offentlig virksomhet Teknologi og anvendelser 18.10.2006

Elektronisk Samhandling i privat og offentlig virksomhet Teknologi og anvendelser 18.10.2006 Elektronisk Samhandling i privat og offentlig virksomhet Teknologi og anvendelser 18.10.2006 Mariann Sundvor NorStella Agenda NorStella transportxml etablert standard innen transportbransjen shortseaxml

Detaljer

Utprøving av NHN-adresseregister

Utprøving av NHN-adresseregister Utprøving av NHN-adresseregister Prosjektleder: Sissel Skarsgaard Norsk Sykepleierforbund Prosjektansvarlig: Merete Lyngstad Norsk Sykepleierforbund Godkjent av: Side 2 av 5 1. Innholdsfortegnelse 2. Sammendrag

Detaljer

Plan som obligatorisk datasett i Norge digitalt. Kåre Kyrkjeeide

Plan som obligatorisk datasett i Norge digitalt. Kåre Kyrkjeeide Plan som obligatorisk datasett i Norge digitalt Kåre Kyrkjeeide Arealplan og planregister Hovedmålsettinger for Statens kartverk bidra til å gjøre kommunene i stand til å ivareta oppgavene knyttet til

Detaljer

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Metadata for samordning og samhandling

Metadata for samordning og samhandling Metadata for samordning og samhandling DNV/ Industry Geir Jevne, principal 16 October 2008 Problemløsning i en teknologisk hverdag Slide 2 Trærne i samordnings-, samarbeids- og samhandlingsskogen 1. Status

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Foto: Åsa Maria Mikkelsen STRATEGI 2015-2017

Foto: Åsa Maria Mikkelsen STRATEGI 2015-2017 Foto: Åsa Maria Mikkelsen STRATEGI 2015-2017 1. LOOPs visjon Vi skaper gode vaner Med vi menes ansatte i LOOP og de vi samarbeider med. Med skaper menes at LOOP tilrettelegger tjenester og verktøy av høy

Detaljer

PRODUKTBESKRIVELSE. NRDB Lokal Node

PRODUKTBESKRIVELSE. NRDB Lokal Node PRODUKTBESKRIVELSE NRDB Lokal Node Versjon 3.2, mars 2012 NRDB Lokal Node Versjon 3.2, mars 2012 Side 1 av 5 1. Innledning... 3 2. Beskrivelse av tjenesten... 3 2.1 Stored Procedure grensesnitt for direkte

Detaljer

Innføring av domeneregistreringer med elektroniske egenerklæringer

Innføring av domeneregistreringer med elektroniske egenerklæringer 1 (11) Innføring av domeneregistreringer med elektroniske egenerklæringer Dette dokumentet beskriver en løsning for registrering av domenenavn med elektroniske egenerklæringer. 2 (11) Historikk Dato Revisjon

Detaljer

Dokumenter som skal inngå i en melding kan opprettes og signeres uavhengig av hverandre.

Dokumenter som skal inngå i en melding kan opprettes og signeres uavhengig av hverandre. Systembeskrivelse for eksterne aktører Med milepæl 3 gir Kartverket neste innblikk i den kommende løsningen for elektronisk tinglysing. Milepæl 3 gir eksterne aktører mulighet til å få innsikt i grensesnitt

Detaljer

Jobbkø. Innhold. Versjon 1.0 Copyright Aditro Side 1 av 18

Jobbkø. Innhold. Versjon 1.0 Copyright Aditro Side 1 av 18 Innhold Jobbkø / Varsling... 2 Jobbkø... 2 Generelt om jobbkø... 2 Hovedfunksjoner... 2 Jobbkø Bestilling og Status... 2 Bestilling... 3 Faste jobber... 5 Status... 6 Jobb... 7 Administrasjon... 8 Konsern...

Detaljer

Elektronisk helsekort for gravide reell mulighet eller fjern drøm

Elektronisk helsekort for gravide reell mulighet eller fjern drøm Elektronisk helsekort for gravide reell mulighet eller fjern drøm Astrid Brevik Svarlien Annebeth Askevold www.kith.no Forprosjekt Elektronisk Helsekort for Gravide EHG Oppdrag fra Helsedirektoratet i

Detaljer