Systemtransparens Dokumentasjon, systemutvikling og regelverksutvikling Forelesning i Finf4001, 20. oktober 2009 transparen't a2 (også utt -an>g; gj fr fra mlat, av transparere 'være synlig gjennom', av trans- og lat. parere 'være synlig') gjennomsiktig, gjennomskinnelig Hva er systemtransparens? I grove trekk innebærer det at det transformerte, rettslige innholdet skal være tilgjengelig, forståelig og forsvarbart Egenskaper Hvorfor systemtransparens? Et (av mange) midler for å realisere viktige hensyn som rettssikkerhet, demokrati og personvern Mål/idealer Hvordan oppnå systemtransparens? Styring, organisering/medvirkning, dokumentasjon, opplæring osv. Virkemidler/metoder Forståelighet Forvaltningens generelle veiledningsplikt, fvl. 11 å gi parter og andre interesserte adgang til å vareta sitt tarv i bestemte saker på best mulig måte Pol 22, innsyn ved helautomatiske beslutninger Hvis en avgjørelse har rettslig eller annen vesentlig betydning for den registrerte og fullt ut er basert på automatisk behandling av personopplysninger, kan den registrerte som avgjørelsen retter seg mot, kreve at den behandlingsansvarlige gjør rede for regelinnholdet i datamaskinprogrammene som ligger til grunn for avgjørelsen Forsvarbarhet Generell begrunnelsesplikt, fvl. 24 og 25 Klagerett, fvl. 28 Alle avgjørelser kan normalt påklages i én instans, som kan prøve alle sider ved saken Reservasjonsretten for helautomatiske avgjørelser, pol 25 Den som en fullt automatisert avgjørelse som nevnt i 22 retter seg mot eller som saken ellers direkte gjelder, kan kreve at avgjørelsen overprøves av en fysisk person. Tilgjengelighet Hvordan kan rettslige systemavgjørelser bli offentlige? 1. Programkoden kan gjøres offentlig tilgjengelig 2. De rettslige systemavgjørelsene kan formuleres som pseudokode 3. De rettslige systemavgjørelsene kan dokumenteres i form av et utvalg av avgjørelser i vanlig språk som a) avklarer tolkningstvil av betydning og b) inneholder supplerende regler i forhold til rettsgrunnlaget 4. De rettslige systemavgjørelsene kan dokumenteres ved at de blir uttrykt som og integrert i det vanlige regelverket (lov, forskrift mv) 5. De rettslige systemavgjørelsene kan dokumenteres ved at selve beslutningssystemet blir offentlig tilgjengelig Dokumentasjon som virkemiddel for systemtransparens Systemdokumentasjon som Kinder-egg, løser tre ting på en gang Dokumentasjonen er et håndfast produkt, som er egnet for tilgjengeliggjøring Dokumentasjonen beskriver systemets innhold i naturlig språk, som er mer forståelig Dokumentasjonen kan (forhåpentligvis) beskrive samsvaret mellom rettskilder og transformering, som gjør IT-systemets transformerte regelverk forsvarbart 1
Forslaget i Schartum 1993 og 1994: Dokumentasjon gir transparente systemer Begrepet rettslig dokumentasjon: Konkrete koblinger mellom rettskildene og datamaskinprogrammet Vise fram/tydeliggjøre tolkningsvalg og beslutningene under transformering Rettslig dokumentasjon på to nivåer: Programnær, teknisk orientert dokumentasjon (for legalitetskontroll) Rettskildenær, mindre formalisert (for veiledning) Mer om de to nivåene av dokumentasjon To nivåer av dokumentasjon: Bør være så like hverandre at det ikke feiltolkes mellom dem Problemer som ikke drøftes: Er dette mulig? Er det effektivt/hensiktsmessig? Dokumentasjonen leses begge veier : Bedre mulighet for å bruke systemutviklingen som verktøy for å forenkle og forbedre regelverket bakenfor Handler også om tilgjengeliggjøring Selve systemene bør også publiseres Problem som ikke drøftes: Opphavsrett, eierskap Problem som bare så vidt berøres: Borgernes forkunnskaper Rettslig dokumentasjon i Schartum 2005 kap. 7: Krav til rettslig systemdokumentasjon Definert slik: Funksjoner/egenskaper ved systemet som er basert på rettskilder eller som det er påkrevd å bruk juridisk metode for å vurdere kvaliteten av Fire ulike former: Bekreftede systemspesifikasjoner Brukerveiledninger Interne regelverk I form av endringer i rettskildene (Generell legalitetskontroll) (Individuell legalitetskontroll) (Veiledning, presedenser etc.) (Tilbakeføring) Hvordan kan vi godtgjøre/ verifisere at programkoden er i samsvar med gjeldende rett? Rettslig systemutvikling Samle og fortolke alle relevante rettskilder Beslutte hva som er riktige tolkningresultater uttrykt i naturlig språk Formalisere tolkningsresultatet Beslutte hva som er en riktig representasjon av rettskildene dokumentasjon Dokumentere samsvar 001 01 Plikter til å dokumentere På de fleste områder i forvaltningen: Svakt regulert Anbefalinger Godkjenningsordninger basert på egenerklæringer som forutsetter dokumentasjon Pålegg om dokumentasjon oftest generelle; lite konkret om hva dokumentasjonens innhold skal være Et område der påleggene er klarerer; statlig økonomistyring Sammenheng mellom systemdokumentasjonskrav og krav til å sporing mellom saksbehandling og utbetaling Faglige normer om og holdninger til dokumentasjon Dokumentasjonsnormer ofte integrert i metoden Tradisjonelle systemutviklingsmetoder: Dokumentasjonsdrevet Hva med moderne utviklingsmetoder? Mer direkte basert på empirisk forskning; hvilke metoder gir egentlig gode IT-systemer som resultat? Overser ofte dokumentasjon Outrerte varianter argumenterer mot dokumentasjon (verre enn bortkastet tid, kan føre til at man låser seg ) Løsning (min påstand): Behov for å rive normer om dokumentasjon løs fra systemutviklingsmetode 2
E-forvaltning i Norden, kap. 16: Dokumentasjonsproblem I, hvor i IT-systemet har de ulike rettskildene blitt av Hva skal dokumentasjonen inneholde, og hvordan utforme den? Dokumentasjonens formål Legalitetskontroll, veiledning, vedlikehold (samme perspektiver som i Dags artikkel) Dokumentasjonens målgrupper Oftest problematisert. Trenger interne og eksterne ulik dokumentasjon? Bidrar ulike typer dokumentasjon til å sementere forskjellige kunnskaper om transformeringen? Dokumentasjonens systematikk Håndverket, pragmatikk og nytteverdi Positive definisjoner Restriksjoner Oppdatering av data Algoritmer Programkodemoduler skjermbilder, inntasting og visning av data Databasedefinisjoner tabeller attributter projeksjoner integritetsregler domenerestriksjoner triggere og lagrede prosedyrer lagrede prosedyrer kode som angir kriterier for kontroll av inntastete verdier kode som setter betingelser for oppdatering kode som inneholder algoritmer for å beregne nye verdier Lagrete, formaliserte data dataverdier data som angir kriterier for kontroll av innlastete verdier data som setter betingelser for oppdatering data som inneholder algoritmer for å beregne nye verdier Transformeringsrommet Dokumentasjonsproblem II, i praksis er svært mange IT-systemer underdokumenterte Feil profesjoner som skriver dokumentasjon? Lavt prioritert i utviklingsprosjekter? Bi-produkt av utviklingsprosessen, vedlikeholdes derfor dårlig etter at systemet er tatt i bruk? Gir lite status å skrive dokumentasjon? En liten dreining i tema: Noen kategorier av offentlige informasjonsressurser Grunndata Nøkkelinformasjon som benyttes av flere virksomheter (primært) for entydig identifikasjon av personer, virksomheter, eiendommer etc. Bør i størst t mulig grad være faste (over tid) og fortolkningsfrie, ikke oppfattes forskjellig avhengig av situasjonen de brukes i Vil i sin natur være strukturerte data Egentlig er det få rene grunndataelementer i samfunnet. Men de er særdeles viktige, og relativt ressurskrevende å forvalte Noen kategorier av informasjonsressurser (II) Etatsdata (eller fagdata ) Disse betegnelsene er ikke offisielle (vedtatt av noen), men de har vært brukt i utredninger om samordning og felles bruk av offentlig informasjon Etatsdata betegner informasjonsressurser som ikke er grunndata, men som det likevel kan være behov for (eller ønske om) å dele mellom flere etater Dette er også i hovedsak strukturerte data Men ikke like faste og fortolkningsfrie som grunndata? Eks: Inntekt, arbeidsgiver, forsørgningsplikt, botid, behandlingstiltak osv. Noen kategorier av informasjonsressurser (III) Å utnytte fagdata (med samordningspotensial ) mellom etater reiser noen problemer: Hjemler for vs. rettslige hindringer mot utveksling/gjenbruk Hvordan vite at meningsinnholdet er (tilstrekkelig) sammenlignbart? Egnet teknologi og organisasjon (informasjonsressursbehandlingen, teknisk og organisatorisk interoperabilitet ) Er metadata svaret? Cliffhanger, kommer tilbake til spørsmålet om noen foiler 3
informasjonsinfrastrukturene (I) Bruk av informasjonen ofte kryssende hensyn: Hjemler for bruk av informasjon Til dels generelle reguleringer (offentlighetsprinsippet utenfor taushetspliktens område, samtykke innenfor taushetspliktens område etc.) Til dels konkret k hjemmel til å innhente opplysning x fra etat t y Regler som begrenser bruken av informasjon Taushetsplikt som skranke for å utlevere opplysninger Personopplysningsvernet, bl.a. ikke formål som er uforenlig med det opprinnelige formålet informasjonsinfrastrukturene (II) Innhenting av opplysninger Personopplysninger; grunnkravene i pol Ulike løsninger ; lovhjemmel, nødvendighetskriterier, konsesjon Opplysninger fra næringslivet; plikter til å melde noe til det offentlige har oftest lovhjemmel informasjonsinfrastrukturene (III) Lovbestemte krav til forvaltningsorganers produksjon av informasjonsressurser Generelle krav, som omfatter alle eller de fleste organer arkivlova, journalføringsplikt Spesifikke krav, visse forvaltningsorganer er tildelt oppgaver med å forvalte felles informasjonsressurser Brønnøysundregistrene, Skattedirektoratet/sentralkontoret for folkeregistrering, SSB, NAV Formkrav og teknologikrav Bestemte skjemaer Tekniske standarder Noen (rest-)kategorier av informasjonsressurser Publikasjonsserier Knytter en type informasjoner til en utgiver og et noenlunde avgrenset formål, for eksempel Norges Lover, NOU-er, anbudsutlysninger mv. Hovedsakelig ustrukturerte data, men med noe strukturert katalogiseringsinformasjon g Arkiver Løpende dokumentasjon av saksbehandlingen Selve dokumentene normalt ustrukturerte data, mens journalene i vesentlig grad er strukturerte Katalogtjenester Internettadresser, telefonnummere, postnummere, trafikkruter Informasjonselementer som er nødvendige forutsetninger for (eller bi-produkter av) andre konkrete samfunnsinfrastrukturer I sin natur strukturerte data, har en del til felles med grunndata Utviklingstrekk i den rettslige reguleringen av informasjonsinfrastrukturer Informasjonsinfrastrukturene i samfunnet er ofte gamle, dvs. har røtter fra før informasjonen ble digitalisert Men: Har digitalisering g ført til økende rettsliggjøring av informasjonsinfrastrukturene? Regulere bruk (både muliggjøre og hindre) Regulere aktører og deres plikter Sikre kvalitet og brukbarhet I noen grad reguleres også markedsmessige forhold Grunndata og fagdata som dokumetasjonsproblem metadata Definisjon i Oxford English Dictionary: metadata n., a set of data that describes and gives information about other data Man legger vanligvis også inn en forutsetning om at metadata skal være strukturerte, og maskinlesbare Ofte hierarkiske: begrep/underbegrep/under-underbeg Gjennomarbeidete og godt strukturerte metadata antas å være hensiktsmessig for å sammenligne (kilde)dataelementers meningsinnhold Brønnøysundreg. forvalter bl.a. Oppgaveregisteret, som er en lovfestet offentlig metadataressurs 4
Hva ligger i Data om data? Dataelementets definisjon og lovlige verdier Forfatternavn (tekst, 40 tegn) Fødselsdato (dato mellom 1.1.1800-31.12.2099) Begrepsbeskrivelser Begrepsklasser, strukturer Autoritative kilder innen et område Rapporteringsplikter (intervaller, kontekst, hjemmel) Betingelser for bruk av dataelementet (hvem, når, ) Kataloginformasjon om arkivinnførsel eller verk Hamsun, Knut Født 04.08.1859 To metadataperspektiver Fremkalling deskriptivt perspektiv Begrepene i verden (og i rettskildene) er som de er, metadataene er noe man må finne under begrepene Metadataene kan være gode, men ikke perfekte, måter å beskrive begrepene på Fint om vi finner begrepslikhet, men metadata er minst like viktig for å avdekke forskjeller Konstruksjon normativt perspektiv Både de egentlige begrepene i verden og metadataene er noe vi konstruerer selv Hvis vi vil at to informasjonselementer skal bety det samme kan vi bli enige og vedta det Metadata vs. transformering og rettslig dokumentasjon Dokumentasjon av metadata: Fare for å bli for innholdsorientert? Er kunnskap om begrepenes meningsinnhold i seg selv nok for forsvarlig samhandling eller må man ta med dib betraktningen hva man gjør med ddataene? Rettslig dokumentasjon (av transformeringen) Er dette mest funksjonsorientert (prosess, treffe vedtak), eller ivaretas både innhold og prosess? Det vi tidligere har lært om transformering: Ligger det nærmest perspektivet fremkalling eller konstruksjon fra forrige lysark? 5