Årsrapporter Norsk MS register og biobank. Nasjonalt register for kronisk obstruktiv lungesykdom. Norsk register for leppe-kjeve-ganespalte

Transkript

1 Årsrapporter 2011 Norsk MS register og biobank Nasjonalt register for kronisk obstruktiv lungesykdom Norsk register for leppe-kjeve-ganespalte

2 Rapportering nasjonale kvalitetsregistre KONTAKTINFORMASJON Registerets navn Norsk Multippel Sklerose Register og Biobank Registeransvarlig Kjell Morten Myhr Telefon / (exped) / E post kjmy@haukeland.no Helseforetak Helse Bergen Nevrologisk avdeling, Haukeland Universitetssykehus, N 5020 Postadresse Bergen Hjemmeside 2 REGISTERINFORMASJON Hovedformål bergen.no/omoss/avdelinger/ms/sider/norskms register og biobank.aspx Kvalitetssikring av diagnose og behandling av multippel sklerose og generere data og biologisk materiale til forskning Juridisk hjemmelsgrunnlag Samtykkebasert Dekningsgrad institusjon 100% (Nevrologiske avdelinger) Dekningsgrad individ Ca 65 % 3 INNTEKTER 2011 Tildelt beløp fra Helse Vest Overført beløp fra tidligere år «Tildelt» beløp fra eksterne kilder Totalsum inntekter 2011 Beskrivelse av eventuelle eksterne inntektskilder 4 KOSTNADER 2011 Lønnskostnader Andre driftskostnader Utstyr Totalsum kostnader 2011 Beskrivelse av kostnader (Helse Vest) (Helse Nord) = (Bruk av egne midler/resurser ved Nasjonalt kompetansesenter for MS «egeninnsats» ved egne midler) Nasjonalt kompetansesenter for MS med hoved andel som egeninnsats (overlege og statistiker som har arbeidet med registerløsning i MRS) register og biobank (fra «egne midler») Se budsjett/regnskap (vedlagt) Rapportering nasjonale kvalitetsregistre 2012 Side 1

3 5 OVERFØRING AV MIDLER Sum midler som er overført til 2012 Begrunnelse for hvorfor midlene ikke er brukt i 2011 Kort redegjørelse for bruk av evt. overførte midler i Utsettelser og forsinkelser i MRS Se budsjett/regnskap som i 2011 men i tillegg har vi arrangert et nasjonalt MS register symposium med internasjonal deltakelse. Arrangement april 2012 Solstrand med oppfølgende utgivelse av et eget Supplement til Acta Neurologica Scandinavica. 6 IKT Løsning for datafangst Løsning for rapportering Kommentarer til løsningene for datafangst og rapportering Papirskjema og manuell punching av data til ACCESS database frem til nylig. MRS har vært under utvikling med etter hvert planlagt ferdigstilling april 2012 men det er fortsatt mangler som gjør løsningen så lite funksjonell at en av strategiske grunner avventes nasjonal lansering. Via MRS men er usikker på om løsninger er på plass Utvikling av MRS løsning har vært særdeles tidkrevende og utfordrende. Planlegging av arbeidet startet 2009 og vi er ennå ikke i mål. Av hva jeg forstår har verken HEMIT eller lokal IT node erfaring med utarbeiding av denne type registerløsninger for longitudinell rapportering av data fra pasienter med kronisk sykdom. I tillegg har jeg forstått at ITplattform som har vært valgt i HEMIT (frem til nå) ikke har løsninger som støtter state of the art registerløsninger som må kunne forventes til dagen formål. Det innarbeides ny plattform nå i HEMIT men det er ukjent om MS registeret er prioritert i forhold til denne. Løsningen for utarbeiding av registerløsning har vært svært uheldig siden HEMIT/lokal node ikke har erfaring med denne type registerløsning. En utviklingsprosess som nå har gått over mer enn to år (forsiktig anslag) er en betydelig utfordring, både internt i registeret men særlig også eksternt i kommunikasjon til fagmiljøet som er blitt informert om at elektronisk løsning for MS registeret er under etablering. En er derfor i ferd med å miste troverdighet i arbeidet. 7 ANALYSE OG RAPPORTERING Det er etablert styringsgruppe for registeret som har utarbeidet Utleverte data retningslinjer for tildeling av registerdata og biologiske prøver. Rapportering nasjonale kvalitetsregistre 2012 Side 2

4 Søknad sendes register og styringsgruppen tildeler etter søknad. Nødvendige godkjenninger fra eksempelvis REK må foreligge før tildeling gjennomføres i avidentifisert format. Evt. koblinger til andre registre må godkjennes av REK (dersom utenfor samtykket) og må gjøres før utlevering av avidentifisert materiale Antall og geografisk fordeling av pasienter i immunmodulerende behandling med sammenligning mot andre regioner/helseforetak Antall og fordeling av forbruk av forskjellig immunmodulerende behandling med sammenligning mot andre regioner/helseforetak Antall pasienter som ikke mottar behandling og begrunnelse av dette med sammenligning mot andre regioner/helseforetak Viktigste analyser Antall pasienter i registeret sammenlignet med estimert antall pasienter i befolkningen med sammenligning mot andre regioner/helseforetak Sammenlikning av effekt og bivirkningsprofil av immunmodulerende behandling (krever store kohorter og lengre observasjonstid) Rapporter Rapportering på datakvalitet Det er planlagt kombinasjon av papir og elektroniske rapporter. Kvalitetsdelen av registeret vil ikke rapportere før funksjonell MRSløsning er tilgjengelig Frem til nå har det vært manuell kvalitetssjekk. Gjennom MRSløsning har vi ønske om elektronisk oppfølging med kvalitetskontroll og mulighet for elektronisk overføring av purringer. Det vil foreligge muligheter på geografi / gruppenivå for å vurdere kompletthet av registerdata med sammenlikning mot reseptregister og NPR. Rapportering til HF ledelse 8 RELASJON TIL FAGLIGE RETNINGSLINJER/VEILEDERE OG KVALITETSINDIKATORER* Oppfølging av anbefalinger fra nasjonale retningslinjer Målsetting for behandling Nasjonale kvalitetsindikatorer Nasjonale faglige retningslinjer for diagnostikk og behandling av MS er utarbeidet ( fagligeretningslinjer for diagnostikk attakk og sykdomsmodifiserendebehandling av multippel sklerose/sider/default.aspx ) og det kan gjøres analyser kontroll om pasienter mottar behandling etter retningslinjer Alle pasienter skal motta diagnostikk og behandling etter nasjonale faglige retningslinjer. Ikke definert ved multippel sklerose men en satser på å utvikle dette i samsvar med Nasjonale faglige retningslinjer Rapportering nasjonale kvalitetsregistre 2012 Side 3

5 Andel pasienter som mottar immunmodulerende behandling. Viktigste parameter (e) Pasientrapporterte utkommemål (PROMS) Kliniske parametere: Sykdomsattakker, totalt funksjonsskår (EDSS), kompositt funksjonsskår (gange, håndfunksjon og kognisjon). MRIsykdomsaktivitet, symptom sjekk med oppfølging, behandling med affekt og bivirkninger. Fatigue Severity Scale (FSS), EQ 5D, Multiple Sclerosis Impact Scale (MSIS 29) 9 IGANGSATTE FORBEDRINGSPROSJEKTER Kort beskrivelse av prosjekt som er startet Forbedringer / resultat oppnådd i pasientbehandlingen Ingen direkte MRS relaterte prosjekt er startet siden det ikke er i funksjon. MEN det er startet en rekk register assosierte prosjekter innen epidemiologi, klinikk og basale analyser i forhold til biobank materiale med blant annet flere artikler i velrenommerte tidsskift deriblant Nature Foreløpig ingen men systematisk vitamin D målinger og råd om røykeslutt er innført på bakgrunn av studier knyttet til registeret. Rett behandling til rett pasient og til rett tid. Dette kan promoteres gjennom analyser fra register i forhold til diagnostikk og behandling etter Nasjonale faglige retningslinjer Planlagte forbedringsprosjekter Diagnostikk til rett tid reduserte tid fra første symptom til diagnose og mulighet for behandling. Økt fokus og tilgang på diagnostikk og behandling av ledsagende symptomer ved MS som eksempelvis blæreforstyrrelse, seksuell dysfunksjon, smerter, spastisitet og infeksjoner og depresjon. 10 RELASJON TIL INTERNASJONALE MILJØER Kort beskrivelse Samarbeid med MS register i Sverige og Danmark samt medlem i arbeidsgruppe for etablering av felles Europeisk MS register: EUReMS eurems project&catid=83:eurems&itemid= DELTAKENDE ENHETER Kort beskrivelse Alle nevrologiske avdelinger i Norge: n= 23 (se MRS basisskjema) 12 PERSONELL Stillinger statistiker overlege sekretær som deles med Nasjonalt kompetansesenter for MS (se budsjett) Rapportering nasjonale kvalitetsregistre 2012 Side 4

6 13 FORSKNING Publikasjoner Registeret har ikke produsert rene registerartikler men har produsert en rekke artikler basert på delmaterialer /koblinger fra registeret. Vedlagt følger liste over slike artikler som er pubmed indeksert liste over artikler i trykkeprosess og artikler samt en liste over artikler i manus/submittert format. Vedlagt følger også liste over artikler som er mer perifert knyttet til register men som handler om MS problemstillinger med indirekte relevans for registeret. 14 RELEVANTE VEDLEGG NB: Registerprotokoll skal inkluderes som vedlegg. Både budsjett for 2011 og regnskap for 2011 skal også legges ved denne rapport. I tillegg må budsjett og planer for 2012, samt tentativt budsjett og planer for 2013 redegjøres for. Forklarende kommentarer til de ulike kostnadsområdene skal legges inn i punkt 4 i dette skjema, eventuelt inkluderes som et eget vedlegg. Rapportering nasjonale kvalitetsregistre 2012 Side 5

7 Etablering Etablert etter konsesjon fra Datatilsynet fra 1998 registrering fra 2001 av Nasjonalt kompetansesenter for MS med støtte fra Norsk Nevrologisk Forening Databehandlingsansvar/Lokalisering Helse Bergen er databehandlingsansvarlig Styringsgruppe Styringsgruppe består av utnevnte fagpersonerf r fra de Regionale samarbeidsorganene (mellom universitetene og helseforetakene) med tilleggg av Nasjonalt Folkehelseinstitutt og MS forbundet: Helse Sør Øst: Frode Vartdal Helse Vest: Nils Erik Gilhus Helse Midt Norge: Rune Midgard Helse Nord: Svein Ivar Mellgren Nasjonalt folkehelseinstitutt: Camilla Stoltenberg MS forbundet: Gurli Vagner Målgruppe for inklusjon Alle pasienter med multippel sklerose uavhengig av sykdomsforløp og behandling Formål med registeret NORSK MULTIPPEL SKLEROS SE REGISTER OG BIOBANK (NMSRB) Kvalitetssikring av diagnostikk og behandling av multippel sklerose o Registeret skal arbeide faglige kvalitetsindikatorer for MS behandlingg til deltagende sykehus og sentrale helsemyndigheter. Etablere datamateriale og biobank for biologisk materiale for forskning o Registeret skal gi grunnlag for årlig rapport tilbake Daglig leder: Overlege professor Kjell Morten Universitetssykehus, Bergen Myhr, Nasjonalt Kompetansesenter for multippel sklerose, Nevrologisk avdeling, Haukeland Registreringg Registrerende enheter: Alle nevrologisk avdelinger i Norge. Registrering basert på skriftlig informert samtykke, innrapportertt av behandlende nevrolog/ms spl. Papirbasert registrering Personidentifiserbaree data Online registrering planlagt fra 2012 via Helsenettet og portalen helseregisteh er.no Dataløsning: MRS (Medisinsk Registreringssystem), utviklet av HEMIT ikke klart per Datalagring: Helse Nord IKT Nasjonalt multippel sklerose register Nevrologisk avdeling Haukeland Universitetssykehus 5021 Bergen Telefon: Telefaks: E-post: ms-senter@helse-bergen.no

8 Variabler (Table 1) Table 1. Variables included in The Norwegian Multiple Sclerosis Registry and Biobank Person Identification/Demographics Name and identification number* Year of birth* Gender* Informed consent* Diagnosis Year of onset* Year of diagnosis* Disease course* Onset symptom* Number of relapses or progressive symptom at diagnosis* MRI at diagnosis* Evoked potentials at diagnosis* CSF analyses at diagnosis* Disease modifying treatment and follow up Ongoing treatment* Any previous medication and reason for changes Any reason for no treatment* Any side effects* Neutralizing antibody analysis during interferon beta and natalizumab treatment JC virus screening during natalizumab treatment Ophthalmologic examination during fingolimod treatment Disease activity and clinical scoring Number of relapses* MRI examination and recording of any new lesions Expanded Disability Status Scale (EDSS)*(11) Multiple Sclerosis Functional Composite (MSFC) (12) Symbol Digit Modalities Test (SDMT) (13) Symptom checklist the presence of any symptoms and any treatment of those Patients reported outcome measures Fatigue Severity Scale (FSS) (14) Multiple Sclerosis Impact Scale (MSIS 29) (15) Health related quality of life assessment by the EuroQol 5D (EQ 5D) (16) Other variables Co morbidity Concomitant medication Family members with MS Previous Epstein Barr virus infection Serum vitamin D levels Smoking habits Vital signs (weight, height, blood pressure, pulse) *Obligatory recording

9 Kvalitetssikring av data Manuell kvalitetskontroll i perioden for papirskjema Innebygde valideringsregler i planlagt versjon av versjonen av MR Datasikkerhet Konferer Helse Nord IKT og Helse Vest IKT Helse Bergen har skrevet databehandler avtale med alle rapporterende enheter, samt Nasjonalt Folkehelseinstitutt for biobank lagring Finansiering NMSRB er finansiert til nå av Nasjonalt Kompetansesenter for MS, gjennom Helse Bergen/Helse Vest Delvis finansiering gjennom registersatsning i Helse Vest Nettside: bergen.no/omoss/avdelinger/ms/sider/norsk ms register og biobank.aspx med informasjon om: Beskrivelse av MS Register og Biobank Informasjon om Registrering Retningslinjer for tildeling og bruk av data og biologisk materiale Skjema (informasjonsskriv, Samtykkeerklæring, registreringsskjema, skjema for oppstart av behandling og skjema for endring av behandling) Styringsgruppesammensetning Søknadsskjema om tilgang på data/biologisk materiale Brukerveiledning MRS (planlagt) Det er også linker til andre dokumenter/funksjoner som Kompetansesenter/register er ansvarlig for: Informasjon og lab skjema for analyser av nøytraliserende antistoffer mot interferon beta (Nasjonal servicefunksjon ved kompetansesenter/register: av nab mot ifnb ved ms.aspx Informasjon og lab skjema for analyser av nøytraliserende antistoffer mot natalizumab (Nasjonal servicefunksjon ved kompetansesenter/register: av nab mot natalizumab ved ms.aspx Nasjonale faglige retningslinjer for diagnostikk og behandling av MS. faglige retningslinjer for diagnostikk attakk og sykdomsmodifiserende behandling av multippel sklerose/publikasjoner/nfr diagnostikk attakkog sykdomsmodifiserende behandling av multippel sklerose.pdf

10 VITENSKAPELIGE ARTIKLER fordelt som følgende: PubMed n=17 + In presss n=16 + mauscript/submitted n= 11 + assosierte artikler n=8; totalt n = 52 PUBMED INDEKSERTE VITENSKAPELIGE ARTIKLER (n=17) 1. Løken Amsrud KI, Myhr KM, Bakke SJ, Beiske AG, Bjerve KS, Bjørnarå BT, Hovdal H, Lilleås F,, Midgard R, Pedersen T, Benth JS, Torkildsen O, Wergeland S, Holmøy T. Retinol levels are associated with w magnetic resonance imaging outcomes in multiple sclerosis. Mult Scler Aug 20. [Epubb ahead of print] PubMed PMID: P Grytten N, Aarseth JH, Espeset K, Johnsen GB, Wehus R, Lund C, Haugstad RC. Stoppers andd non starters of diseasemodifying treatment in multiple sclerosis. Acta Neurol Scand Aug 25. doi: /j x. [Epub ahead of print] PubMed PMID: Saltytė Benth J, Myhr KM, Løken Amsrud KI, Beiske AG, Bjerve KS, Hovdal H, Midgard M R, Holmøy T. Modelling and Prediction of 25 Hydroxyvitamin D Levels in Norwegian Relapsing Remitting Multiple M Sclerosis Patients. Neuroepidemiology Jul 17;39(2) : Løken Amsrud KI, Holmøy T, Bakke SJ, Beiske AG, Bjerve KS, Bjørnarå BT, Hovdal H, Lilleås F, Midgard R, Pedersen T, Benth JS, Sandvik L, Torkildsen O, Wergeland S, Myhr KM. Vitamin D and disease activity in multiple sclerosis before and during interferon β treatment. Neurology Jul 17;79(3): Torkildsen O, Wergeland S, Bakke S, Beiske AG, Bjerve KS, Hovdal H, Midgard R, R Lilleås F, Pedersen T, Bjørnarå B, Dalene F, Kleveland G, Schepel J, Olsen IC, Myhr KM. ω 3 Fatty Acid Treatment in Multiple Sclerosiss (OFAMS Study): A Randomized, Double Blind, Placebo Controlled Trial. Arch Neurol Aug;69(8): Mero IL, Smestad C, Lie BA, Lorentzen ÅR, Sandvik L, Landrø NI, Aarseth JH, Myhr KM, Celiuss EG, Harbo HF. Polymorphisms of the BDNF gene show neither association with multiple sclerosis susceptibility nor clinical course. J Neuroimmunol Mar;244(1 2): Gavasso S, Gjertsen B, Anderssen E, Myhr K, Vedeler C. Immunogenic effects of o recombinant interferon beta Mult Scler therapy disrupt the JAK/STAT pathway in primary immune cells from patients with multiple sclerosis. Aug;18(8): International Multiple Sclerosis Genetics Consortium; Wellcome Trust Case Control Consortium 2, Sawcer S et al. Genetic risk and a primary role for cell mediated immune mechanisms in multiple sclerosis. Nature Aug 10;476(7359): Søndergaard HB, Sellebjerg F, Hillert J, Olsson T, Kockum I, Lindénn M, Mero IL, Myhr KM, Celius EG, Harbo HF, Christensenn JR, Börnsen L, Sørensen PS, Oturai AB. Alterations in KLRB1 gene expression e and a Scandinavian multiple sclerosis association study of the KLRB1 SNP rs Eur J Hum Genet Oct;19(10): : Sørensen PS, Jensen PE, Haghikia A, Lundkvist M, Vedeler C, Sellebjerg F, Koch Henriksen N,, Fogdell Hahn A, Myhr KM, Hillert J, Gold R. Occurrence of antibodies against natalizumab in relapsing multiple sclerosis patients treated with natalizumab. Mult Scler Sep;17( 9): Riise T, Kirkeleit J, Aarseth JH, Farbu E,, Midgard R, Mygland Å, Eikeland R, Mørland TJ, Telstad W, Førland PT, Myhr KM. Risk of MS is not associated with exposure to crude oil, but increases with low level of education. Mult Scler Jul;17(7): Mero IL, Ban M, Lorentzen ÅR, Smestad C, Celius EG, Sæther H, Saeedi H, Viken MK, Skinningsrud B, Undlien DE, Aarseth J, Myhr KM, Granum S, Spurkland A, Sawcer S, Compston A, Lie BA, Harbo HF. Exploring thee CLEC16A gene reveals a MS County: a cross sectional population based study inn a landlockedd county of Eastern Norway. Acta Neurol Scand associated variant with correlation to the t relative expression of CLEC16A isoforms in thymus. Genes Immun Apr;12(3): Risberg G, Aarseth JH, Nyland H, Lauerr K, Myhr KM, Midgard R. Prevalence andd incidence off multiple sclerosis in Oppland Oct;124(4): Svendsen B, Myhr KM, Nyland H, Aarseth JH. The cost of multiple sclerosis in Norway. N Eur J Health Econ Nov Glad SB, Nyland H, Aarseth JH, Riise T, Myhr KM. How long can you keep working with benign multiple sclerosis? J Neurol Neurosurg Psychiatry Jan;82(1): Smedal T, Myhr KM, Aarseth JH, Gjelsvik B, Beiske AG, Glad SB, Strand LI. The influence i of warm versus cold c climate on the effect of physiotherapy in multiple sclerosis. Acta Neurol Scand Jul;124(1): Smedal T, Beiske AG, Glad SB, Myhr KM, Aarseth JH, Svensson E, Gjelsvik B, Strand LI. Fatigue in multiple sclerosis: associationss with health related quality of life and physical performance. Eur J Neurol Jan;18(1): Nasjonalt multippel sklerose register Nevrologisk avdeling Haukeland Universitetssykehus 5021 Bergen Telefon: Telefaks: E-post: ms-senter@helse-bergen.no

11 VITENSKAPELIGE ARTIKLER In press 2012 (n=16) 1. Ann C. Kroksvee, Jacob D. Jaffe, Harald Barsnes, Elise Aasebø, Yngvild Bjørlykke, Hasmik Keshishian, Rune J. Ulvik, Christian A. Vedeler, Kjell Morten Myhr, Steven A. Carr, Frode S. Berven. Quantitative proteomics of cerebrospinal fluid suggests increased levels of secretogranin 1 in early multiple sclerosis. Journal of Proteome Research 2012 IN PREESS 2. K.I. Løken Amsrud, T. Holmøy, S.J. Bakke, A.G. Beiske, K.S. Bjerve, B.T. Bjørnarå, H. Hovdal, F. Lilleås, R. Midgard, T. Pedersen, J. Šaltytė Benth, L. Sandvik, Ø. Torkildsen, S. Wergeland, K.M. Myhr. Vitamin E and disease activity in multiple sclerosis. PLOS One 2012, IN press 3. Hanne Marie Bøe Lunde, Bjørn Bjorvatn, Kjell Morten Myhr, Lars Bø. Clinical assessment and management of sleep disorders in multiple sclerosis. Acta Neurol Scand J 2012, In Press 4. Hanne Marie Bøe Lunde, Tommy F. Aae, William Indrevåg, Jan Aarseth, Bjørn Bjorvatn, Kjell Morten Myhr, Lars Bø. Poor sleep in patients with multiple sclerosis. PLOS One 2012, In press 5. Maria Ban, Stacy Caillier, Inger Lise Mero, Kjell Morten Myhr, Elisabeth G. Celius, Jan Aarseth, Øivind Torkildsen, Hanne F. Harbo, Jorge Oksenberg, Stephen L. Hauser, Stephen Sawcer, Alastair Compston. Mutant alleles of the CYP27B1 gene are not associated with multiple sclerosis. Ann Neurol 2012, In press 6. Øivind Torkildsen, Kristin Ingeleiv Løken Amsrud, Stig Wergeland, Kjell Morten Myhr, Trygve Holmøy. Fat soluble vitamins as disease modulators in multiple sclerosis. Acta Neurol Scand J 2012, In press 7. Øivind Torkildsen, Nina Grytten, Jan Aarseth, Kjell Morten Myhr, Margitta T Kampman. Month of birth as a risk factor for multiple sclerosis: an update. Acta Neurol Scand 2012 In press. 8. Trygve Holmøy, Øivind Torkildsen, Kjell Morten Myhr, Kristin Ingeleiv Løken. Vitamin D supplementation and monitoring in MS: who, when, and wherefore. Acta Neurol Scand 2012 In press 9. Stig Wergeland, Øivind Torkildsen, Lars Bø, Kjell Morten Myhr. Polyunsaturated fatty acids in multiple sclerosis therapy. Acta Neurol Scand 2012 In press 10. Sonia Gavasso, Nina K. Aarskog, Tove H. Marøy, Jan Aarseth, Elling Ulvestad, Kjell Morten Myhr, Christian A. Vedeler. Gene expression of IgG receptors in whole blood of multiple sclerosis patients is not influenced by interferon beta or glatiramer acetate treatment. Acta Neurol Scand 2012 In press 11. Pugliatti M, Casetta I, Drulovic J, Granieri E, Holmøy T, Kampman TM, Landtblom A M, Lauer K, 8 Myhr K M, Parpinel M, Pekmezovic T, Riise T, Zhu B, Wolfson C. A novel questionnaire for multinational case control studies on environmental factors in multiple sclerosis (EnvIMS Q). Acta Neurol Scand 2012 In press 12. Kroksveen AC, Guldbrandsen A, Vedeler C, Myhr KM, Opsahl JA, Berven FS. Cerebrospinal fluid proteome comparison between multiple sclerosis patients and controls. Acta Neurol Scand 2012 In press 13. KM Myhr, N Grytten, Ø Torkildsen, S Wergeland, L Bø, M Pugliatti, and JH Aarseth. A need for national registries and international collaborative research in multiple sclerosis. Acta Neurol Scand 2012 In press 14. M Pugliatti Maura, KM Myhr et al. et al. Assess, compare and enhance the status of People with MS in Europe: a European Register for Multiple Sclerosis (EUReMS). Acta Neurol Scand 2012 In press 15. KM Myhr, N Grytten, JH Aarseth. The Norwegian Multiple Sclerosis Registry and Biobank. Acta Neurol Scand 2012 In press 16. N Grytten, JH Aarseth, K Espeset, G Berg Johnsen R, Wehus, C. Lund, T Riise, R Haugstad. Health related quality of life and disease modifying treatment behaviour in relapsing remitting multiple sclerosis a multicentre cohort study. Acta Neurol Scand 2012 In press Manuscript/Submitted 2012 (n=11) 1. Faurizio A Leone, Nadia Barizzone, Federica Esposito, Ausiliatrice Lucenti, Hanne F Harbo, An Goris, Ingrid Kockum, Annette Bang Oturai, Elisabeth Gulowsen Celius, Inger Lise Mero, Benedicte Dubois, Tomas Olsson, Helle Bach Søndergaard, Daniele Cusi, Sara Lupoli, Franca Guerini, Daniela Galimberti, Marco Salvetti, Giuseppe Liberatore, Vittorio Martinelli, Paola Naldi, Kjell Morten Myhr, Roberto Bergamaschi, Giancarlo Comi, Filippo Martinelli Boneschi, Sandra D'Alfonso. Association of genetic markers with CSF oligoclonal bands in Italian MS patients. Mult Scler J 2012, Submitted 2. IL Mero, MW Gustavsen, H Sæther, S Flåm, HB Søndergaard, PEH Jensen, T Berge, A Bjølgerud, A Muggerud, JH Aarset, KM Myhr, EG Celius, F Sellebjerg, J Hillert, L Alfredsson, T Olsson, AB Oturai, I Kockum, BA Lie, B Kulle, HF Harbo. Genetic differences relating to oligoclonal band status in multiple sclerosis. Ann Neurol 2012, Submitted 3. Ralf Gold, Kjell Morten Myhr, Irina Ejovara, Ralf A. Linker, Chris Polman, Frauke Zipp, Finn Sellebjerg, Thomas Berger, Eva Havrdova, Xavier Montalban, Heinz Wiendl, Per Soelberg Sorensen. Guidelines on the use of modern antibody therapies for treatment of multiple sclerosis and neuroimmunological diseases. Eur J Neurol 2012, Submitted

12 4. Tomas Olsson, Anat Achiron, Lars Alfredsson, Thomas Berger, David Brassat, Andrew Chan, Giancarlo Comi, Mefkure Eraksoy, Harald Hegen, Jan Hillert, Poul Erik Hyldgaard Jensen, Lucia Moiola, Kjell Morten Myhr, Annette Oturai, Sven Schippling, Aksel Siva, Per Soelberg Sorensen, Anne Kathrin Trampe, Thomas Weber, James Potts, Tatiana Plavina, Dominic Paes, Meena Subramanyam. Anti JCV antibody prevalence in a multinational multiple sclerosis cohort. Mult Scler J 2012, Submitted 5. Gry Klevan, Cecilie Osman Jacobsen, Jan Harald Aarseth, Kjell Morten Myhr, Harald Nyland, Solveig Glad, Kirsten Lode, Nanna Figved, Elisabeth Farbu, Jan Petter Larsen. Health related quality of life in patients recently diagnosed with multiple sclerosis. Acta Neurol Scand 2012, Submitted 6. NG Torkildsen, Ø. Torkildsen, KM Myhr R Midgard, T Holmøy, OP Dahl, G Risberg, E farbu, EG Celius, M Kampamnn. Month of birth among patients with multiple sclerosis. Mult Scler J 2012, Submitted 7. Comi, Giancarlo; Martinelli, Vittorio; Rodegher, Mariaemma; Moiola, Lucia; Bajenaru, Ovidiu; Carra, Adriana; Elovaara, Irina; Fazekas, Franz; Hartung, Hans Peter; Hillert, Jan; King, John; Komoly, Samuel; Lubetzki, Catherine; Montalban, Xavier; Myhr, Kjell Morten; Preziosa, Paolo; Ravnborg, Mads; Rieckmann, Peter; Rocca, Maria; Wynn, Daniel; Young, Carolyn; Filippi, Massimo. Effects of early treatment with glatiramer acetate inpatients withclinically isolated syndrome. Mult Scler J Ann C. Kroksveen, Elise Aasebø, Heidrun Vethle, Vincent Van Pesch, Diego Franciotta, Charlotte Teunissen, Rune J. Ulvik, Christian Vedeler, Kjell Morten Myhr, Harald Barsnes, Frode S. Berven. Discovery and verification of multiple sclerosis candidate biomarkers using itraq and SID SRM. Manuscript in preparation 9. M Kampamnn, NG Torkildsen, KM Myhr R Midgard, T Holmøy, OP Dahl, G Risberg, E farbu, EG Celius, Ø. Torkildsen,. Gender differences in multiple sclerosis. Manuscript in preparation 10. Sonia Gavasso, Tove Marøy, Ellen Mosleth, Katarina Jørgensen, Hanne Linda Nakkestad, Bjørn Tore Gjertsen, Kjell Morten Myhr, Christian Vedeler In vivo single cell phospho specific flow cytometry in interferon beta treated multiple sclerosis patients; pstat1 predicts neutralizing antibody titers. Manuscript in preparation 11. Henning K Olberg, RJ Cox, Jane K Nøstbakken, Jan H Aarseth, Christian A Vedeler, Kjell Morten KM Myhr. The influence of immunomodulatory therapy on vaccination response among patients with multiple sclerosis. Manuscript in preparation Andre assosierte artikler (n=8) 1. Wergeland S, Torkildsen O, Myhr KM, Mørk SJ, Bø L. The cuprizone model: regional heterogeneity of pathology. APMIS Aug;120(8): doi: /j x. Epub 2012 Feb 24. PubMed PMID: Grimaldi L, Barkhof F, Beelke M, Burton J, Holmoy T, Hupperts R, Killestein J, Rieckmann P, Schluep M, Smolders J; SOLAR Study Group. A randomized trial of high dose vitamin D2 in relapsing remitting multiple sclerosis. Neurology Mar 13;78(11):841. PubMed PMID: Wergeland S, Torkildsen Ø, Myhr KM, Aksnes L, Mørk SJ, Bø L. Dietary vitamin D3 supplements reduce demyelination in the cuprizone model. PLoS One. 2011;6(10):e Epub 2011 Oct 20. PubMed PMID: ; PubMed Central PMCID: PMC Hartung HP, Freedman MS, Polman CH, et al.; BENEFIT Study Group. Interferon β 1b neutralizing antibodies 5 years after clinically isolated syndrome. Neurology Aug 30;77(9): Epub 2011 Aug 17. Erratum in: Neurology Sep 27;77(13):1317. PubMed PMID: Sorensen PS, Lycke J, Erälinna JP, et al.; SIMCOMBIN study investigators. Simvastatin as add on therapy to interferon β 1a for relapsing remitting multiple sclerosis (SIMCOMBIN study): a placebo controlled randomised phase 4 trial. Lancet Neurol Aug;10(8): PubMed PMID: Teunissen CE, Tumani H, Bennett JL, Berven FS, et al. Consensus Guidelines for CSF and Blood Biobanking for CNS Biomarker Studies. Mult Scler Int. 2011;2011: Epub 2011 Jul 18. PubMed PMID: ; PubMed Central PMCID: PMC Berle M, Kroksveen AC, Haaland OA, et al. Protein profiling reveals inter individual protein homogeneity of arachnoid cyst fluid and high qualitative similarity to cerebrospinal fluid. Fluids Barriers CNS May 20;8: Kroksveen AC, Opsahl JA, Aye TT, Ulvik RJ, Berven FS. Proteomics of human cerebrospinal fluid: discovery and verification of biomarker candidates in neurodegenerative diseases using quantitative proteomics. J Proteomics Apr 1;74(4):

13 Norsk MS Registerr og Biobank regnskap Finansieringskilde Budsjett Forbruk Nasjonalt MS kompetanse senter Norsk MS register og biobank Totalt Inntektt * Utgifter Overlege (20 %) Statistiker (100 %) Drift for Register & Biobank Lagringskostnader Biobank IT ingeniør (50 %) for overføring av dataa Sekretær (25 %) for plotting Sekretær (20 %) Oppstartsmøte og reise i Norge for oppstart av MRS Sum forbruk Avvik ** Sum *Bevilgning fra Helse Nord Helse Vest = 775,000 ** overført grunnet forsinkelser i innføring/ferdigstillingg av MRS løsning Nasjonalt multippel sklerose register Nevrologisk avdeling Haukeland Universitetssykehus 5021 Bergen Telefon: Telefaks: E-post: ms-senter@helse-bergen.no

14 Norsk MS Register og Biobank regnskap Finansieringskilde Budsjett Forbruk Nasjonalt MS kompetansesenter Norsk MS register og biobank Totalt Inntekt * Utgifter Overlege (25 %) Statistiker (100 %) Drift for Biobank Lagringskostnader Biobank IT ingeniør (50 %) for overføring av data Sekretær (50 %)* for plotting Sekretær (20 %) Oppstartsmøter og reise i Norge for oppstart av MRS* og MS symposium Sum forbruk Avvik 0** Sum *Bevilgning fra Helse Nord Helse Vest (overført fra 2011 pga forsinkelser i MRS) og tillegg i bevilgning fra Helse Vest for 2012** Beregninger gjort primo oktober viser at en vil sannsynligvis følge budsjett dersom vi får overført data og plottet uregistrerte skjema. MEN dette fordrer ferdigstilling av en funksjonell MRS løsning. Dersom ikke dette ikke foreligger, vil det søkes om å overføre midler allokert til dette formålet

15 Norsk MS Register og Biobank regnskap Budsjett Forbruk Finansieringskilde Nasjonalt MS kompetansesenter Norsk MS register og biobank Totalt Inntekt * Utgifter Overlege (25 %) Statistiker (80 %) Drift for Register & Biobank Lagringskostnader Biobank IT ingeniør (50 %) for overføring av data Sekretær (75 %)* for plotting Opplæring /reise i Norge Utstyr/Infrastruktur Sum forbruk Avvik Sum *I budsjettet er ikke lagt inn overføring av midler fra 2012 siden vi håper at alle data er overført og skjemaer er plott høsten Dersom MRS ikke er klar for dette må det skje overføring av midler fra 2012 med tilsvarende økning av budsjett for Det søkes om NOK for Norsk MS Register og Biobank for 2013

16 Rapportering nasjonale kvalitetsregistre KONTAKTINFORMASJON Registerets navn Nasjonalt register for kronisk obstruktiv lungesykdom Registeransvarlig Per Bakke, Sverre Lehmann (daglig faglig leder) Telefon SL: / E post sverre.lehmann@helse bergen.no Helseforetak Helse Bergen HF Postadresse Lungeavdelingen, Haukeland Universitetssjukehus, 5020 Bergen Hjemmeside 2 REGISTERINFORMASJON Hovedformål Juridisk hjemmelsgrunnlag Dekningsgrad institusjon Dekningsgrad individ Epidemiologisk overvåking og registering av tidstrender i forekomst av alvorlig kols. Kvalitetskontroll av medisinske og samfunnsøkonomiske forhold ved kols, dvs å kunne kartlegge sykdoms og behandlingsforløpet og sammenlikne helseeffekt og ressursinnsats ved alternative opplegg. Forskning knyttet til kols. Samtykkebasert 10% (pr. september 2012 tre sykehus som har tatt i bruk registeret: Haukeland, Haugesund, Ålesund. Introduseres til fem nye sykehus ila. høst 2012: St. Olav, Stavanger, Kristiansand, Arendal, Tromsø) 5% (datagrunnlag 40% av aktuelle pasienter inkludert på deltakende sykehus og 10% av aktuelle norske sykehus, de som pt. deltar i registeret) 3 INNTEKTER 2011 Tildelt beløp fra Helse Vest Overført beløp fra tidligere år Tildelt beløp fra eksterne kilder Totalsum inntekter 2011 Beskrivelse av eventuelle eksterne inntektskilder KOSTNADER 2011 Lønnskostnader inkl. sosiale kostnader. Rapportering nasjonale kvalitetsregistre 2012 Side 1

17 Andre driftskostnader Utstyr Totalsum kostnader 2011 Beskrivelse av kostnader Lønnskostnader, reisekostnader, bilgodtgjørelse, telefon, medisinske forbruksvarer 5 OVERFØRING AV MIDLER Sum midler som er overført til 2012 Begrunnelse for hvorfor midlene ikke er brukt i 2011 Kort redegjørelse for bruk av evt. overførte midler i IKT Løsning for datafangst Løsning for rapportering Kommentarer til løsningene for datafangst og rapportering MRS Medisinsk registreringssystem utviklet av Helse Midt Norge IT. Webapplikasjon som er tilgjengelig via portalen helseregister.no Benytter samme som for datafangst for enkle/online rapporter MRS (er under utvikling). For mer avansert statistikk er det mulig å ta ut hele datagrunnlaget som en datadump. Selve rapporteringsskjemaet er utviklet og vedlikeholdt av Helse Vest IKT Rapportering nasjonale kvalitetsregistre 2012 Side 2

18 7 ANALYSE OG RAPPORTERING Utlevering av komplett anonymisert datafil (kun løpenummer) i excelformat, kodebeskyttet, hver 6 mnd. Kode leveres med sms til lokalt registeransvarlig. Formål kvalitetssikring og forbedring. Utleverte data Datautlevering til forskningsformål etter samme prosedyre som over vil gjøres etter søknad og påfølgende vurdering av registerets styre. Viktigste analyser Rapporter Inklusjonsrate ifht. total antall pasienter innlagt med H og B diagnose kols på enheten (sistnevnte hentes fra driftstall lokal sykehus). Død under oppholdet. Demografiske data krysset mot lungefunksjon og antropometriske variabler samt livskvalitetsmåling. Ventilasjonsstøttepraksis krysset mot innkomst ph og lungefunksjon. Antibiotikapraksis krysset mot innkomst Lpk, crp og lungefunksjon. Medisinering ved utreise krysset mot lungefunksjon og a. blodgassanalyser ved utreise. Informasjonsrutiner (vaksinasjon, rehab, røykeavvenning) etterlevelsesfraksjon samt krysskobling mot demografiske variable og lungefunksjon. Reinnleggelsefrekvens, endring i sykdomsaktivitet, komorbiditet og livskvalitet hos pasienter med hyppige innleggelser. Årlig elektroniske rapport sendes til Fagsenter for medisinske registre ved Helse vest med kopi til Avdelingsdirektør ved Lungeavdelingen, Helse Bergen. Enkle/online rapporter MRS er under utvikling høst 2012 og vil kunne tas ut til enhver tid til bruk på de lokale enheter, men da kun med tilgang til egne data. Det er presentert data i form av poster fra registeret på den nasjonale kvalitetskonferansen i Rapportering på datakvalitet Rapportering til HF ledelse Datakvalitetsrapportering vil inngå i online rapportene som er under utvikling, tilgjengelig for hver enhets eget materiale inkl. angivelse av manglende data i registreringer. Årlig rapport sendes til Avdelingsdirektør ved Lungeavdelingen, Helse Bergen for registeret i sin helhet, som rapporterer videre til HF ledelse, og årlig til klinikk/ avdelingsledere ved de respektive lokale sykehus, fra lokale registeransvarlige. 8 RELASJON TIL FAGLIGE RETNINGSLINJER/VEILEDERE OG KVALITETSINDIKATORER* Oppfølging av anbefalinger fra nasjonale retningslinjer Rapportering nasjonale kvalitetsregistre 2012 Side 3 Registeret er godt egnet til å kunne evaluere om sykehusbehandling av kols blir utført i overenstemmelse med internasjonale retningslinjer (GOLD), samt de kommende norske retningslinjer som pt. er til vurdering for godkjenning i

19 Målsetting for behandling Nasjonale kvalitetsindikatorer Viktigste parameter (e) Pasientrapporterte utkommemål (PROMS) Helsedirektoratet. Minst 70% av alle kolspasienter med ph < 7.35 bør behandles med bipap eller respirator under oppholdet. Minst 80% av alle med alvorlig kols bør behandles med langtidsvirkende antikolinergt medikament og / eller kombinasjonspreparat (LABA/inhalasjonssteroid) ved utreise. Minst 80% av alle dagligrøykere skal ha mottatt informasjon om røykeslutt. Minst 80% skal ha mottatt informasjon om rehabilitering og influensavaksine. Minst 80% skal få målt høyde og vekt under oppholdet. Minst 80% skal fylle ut spørreskjema om livskvalitet (CAT) og gjøre spirometri og a. blodgass før utreise. Reinnleggelser innen 30 dager skal forekomme hos < 10% av pasientene. Registeret kan monitorere graden av reinnleggelse av eldre innen 30 dager blant de som samtykker til deltakelse. Dette er en nasjonal kvalitetsindikator. Evaluering av behandling og pasientinformasjon/ opplæring, i overenstemmelse med evidensbaserte retningslinjer? Reinnleggelsefrekvens, endring i sykdomsaktivitet og livskvalitet hos «svingdørspasienter». Helserelatert livskvalitet (COPD assessment test / CAT) 9 IGANGSATTE FORBEDRINGSPROSJEKTER Kort beskrivelse av prosjekt som er startet Forbedringer / resultat oppnådd i pasientbehandlingen Planlagte forbedringsprosjekter Evaluering av ventilasjonsstøttepraksis, informasjon til pasienter, måling av KMI, og medisinering ved utreise første år i Web presentert ved poster på Kvalitetskonferansen for helseregistre i Bergen Resultater fra første år vil sammenholdes med tilsvarende analyser fra 2. år (pr. april 2013), etter fokus på forbedring av svake områder. Se over Rapportering nasjonale kvalitetsregistre 2012 Side 4

20 10 RELASJON TIL INTERNASJONALE MILJØER Variablene som er valgt ut er beskrevet som sentrale variabler i de internasjonale retningslinjene for kols (GOLD guidelines; for å kunne karakterisere sykdommens alvorlighetsgrad (spirometri, blodgasser, livskvalitet, komorbiditet), samt for å kunne vurdere om aktuelle evidensbaserte behandlingstiltak er iverksatt under oppholdet (ventilasjonsstøtte, Kort beskrivelse medisinering, pasientopplæring og informasjon). Kols registre finnes i andre land, feks. Danmark / USA; The Danish National Registry of Patients / The COPD Research Registry. Det danske er et sentralt register uten detaljregistrering av diagnostikk og behandling under opphold på sykehus, det amerikanske et poliklinisk basert register. Intet samarbeid etablert pt. 11 DELTAKENDE ENHETER Kort beskrivelse Web versjonen var tilgjengelig fra mars 2011 og pilotperioden ferdig 1/7 11. Sykehus i alle landet HF vil fortløpende inviteres til deltakelse. Pr. 1.oktober 2012 er registeret introdusert til 3 andre sykehus, Haugesund, Ålesund og St.Olav, og tatt aktivt i bruke ved de to førstnevnte. St.Olav har intensjon om å komme i gang ila. høsten Det er planlagt informasjonsreiser til sykehusene Kristiansand/Arendal, Stavanger og Tromsø ila. høsten Ila vil resterende del av landets sykehus bli tilbudt opplæring og oppstart. 12 PERSONELL Stillinger Pt. 2 stk 50% koordinator stillinger for opplæring / introduksjon av andre sentra til registeret, kvalitetssikring av registrerte data, rapportering og kommunikasjon mot IT relatert personell i Helse Vest RHF og HEMIT. 20% fagleder (overlege). 13 FORSKNING Publikasjoner Ingen internasjonale publikasjoner hittil. Poster fra 1. driftsår i web presentert ved Kvalitetskonferansen for helseregistre i Bergen Ingen forskningsstillinger/ stipendiater pt. 14 RELEVANTE VEDLEGG NB: Registerprotokoll skal inkluderes som vedlegg. Både budsjett for 2011 og regnskap for 2011 skal også legges ved denne rapport. I tillegg må budsjett og planer for 2012, samt tentativt budsjett og planer for 2013 redegjøres for. Forklarende kommentarer til de ulike kostnadsområdene skal legges Rapportering nasjonale kvalitetsregistre 2012 Side 5

21 inn i punkt 4 i dette skjema, eventuelt inkluderes som et eget vedlegg. VEDLEGG: 1) Registerprotokoll med pas. info/samtykke formular og konsesjon Budsjett og planer for 2012: Tildelt budsjettramme for 2012: kr Lønn: 2 x 50 % koordinatorstillinger inkl. sos. utgifter: kr (en av koordinatorene ulønnet perm for masteroppgave i en mnd., derfor noe lavere lønnskostnad enn tidligere stipulert). 20% faglig leder (overlege) inkl. sos. utgifter: kr Reisekostnader, bilgodtgjørelse, telefon, medisinske forbruksvarer: kr Kostnader total sum 2012: kr Reisevirksomhet 2012: Fagleder og koordinator reise til St. Olav, Stavanger, Tromsø, Kristiansand/ Arendal. Introduksjonsmøter. Budsjett og planer for 2013: Registeret er planlagt gradvis ekspanderende i form av flere deltakende sykehus og mer aktivitet i styre, nasjonal referansegruppe og ressurspersoner, noe som krever økte budsjettrammer: Tentativt budsjett: Tildelt budsjettramme kr Lønn: 2 x 50 % koordinatorstillinger inkl. sos. kostnader: kr % Faglig leder inkl. sos. kostnader: kr % Merkantil støtte: kr Reisekostnader, bilgodtgjørelse, telefon, medisinske forbruksvarer, samling x 2 for nasjonal referansegruppe og ressurspersoner på deltakende sykehus, deltakelse nasjonal registerkonferanse: kr Kostnader total sum 2013: Reisevirksomhet 2013: Fagleder og koordinator reise til 7 8 nye sykehus. Rapportering nasjonale kvalitetsregistre 2012 Side 6

22 VEDLEGG 1 REGISTERPROTOKOLL Bergen 30/9 12 Nasjonalt register for kronisk obstruktiv lungesykdom Introduksjon Kronisk obstruktiv lungesykdom (KOLS) forekommer hos ca 10 % av den voksne befolkning i Norge og sykdommer øker kraftig med høyere alder. Insidensen dvs. nye tilfeller per år, er i vår del av landet anslått til ca 1 % (Johannessen 2002). Med utgangspunkt i registreringer fra Sverige medfører KOLS årlige kostnader på 4. 4 milliarder NOK og for Vestlandet (Helse Vest) ca en milliard NOK i indirekte og direkte kostnader (Jansson 2002). Verdens Helseorganisasjon og European Lung White Book (Loddenkemper 2003) beregner at ingen annen sykdom vil gi en større økning i dødelighet og tap av livskvalitet i den industrialiserte verden fram til Alvorlige og livstruende forverringer av KOLS er med ca 900 sykehusinnleggelser per år ved Haukeland universitetssykehus en av de hyppigste årsakene til innleggelser ved dette sykehuset liksom ved de øvrige samarbeidende sykehus i Helse Vest (Eagan 1999, Skaug 2001). Alvorsgraden ved disse sykdommene synliggjøres ved at nærmere 25 % av pasientene som blir innlagt ved Haukeland universitetssykehus dør i løpet av de to neste år (Fjellanger 2003). Medlemmene i Vest norsk lungeforum har påpekt at eldre mennesker med KOLS, som ofte har samtidig andre kroniske sykdommer, må få leve bedre mens de lever. Et positivt tiltak vil være å gi helsearbeidere større viten om hva de gjør og gi dem bedre kompetanse i hva de bør gjøre. Det er i dag store kunnskapshull om KOLS hva angår behov for helsetjenester, effekten av de behandlingstilbud som gies og kostnadene ved de ulike tiltak/behandlinger. En arbeidsgruppe for forskning i Helse Vest anbefalte i 2003 at Helse Vest i framtiden bør satse på de store folkesykdommene inkludert KOLS og gi økonomisk støtte til store og gode kliniske forskningsmiljøer (Regional arbeidsgruppe 2003). Nasjonalt råd for prioriteringer i helsevesenet (Sosial- og helsedirektoratets hjemmeside) bemerket i sin drøfting av helsetjenesten for syke gamle at kunnskapsgrunnlaget er bedre når det gjelder livreddende og livsforlengende behandling enn for helsehjelp til å bedre livskvaliteten. Rådet uttaler også at det er store kunnskapshull når det gjelder gamle menneskers behov for helsetjenester, effekten av ulike behandlingstilbud, og kostnadene forbundet med tiltakene. Hovedmålsetningene med KOLS kvalitetsregisteret: 1. Epidemiologisk overvåking og registering av tidstrender i forekomst av alvorlig kols. 2. Kvalitetskontroll av medisinske og samfunnsøkonomiske forhold ved kols, dvs å kunne kartlegge sykdoms- og behandlingsforløpet og sammenlikne helseeffekt og ressursinnsats ved alternative opplegg. 3. Forskning knyttet til kols.

23 Målene er videre å gi pasientdata som er riktige (kvalitetssikret), dokumenterte (kodet), standardiserte (entydig kodeplattform), leverbare (elektronisk) og tilgjengelige (for forskere og helseforvaltning). Registeret skal ikke krenke pasientenes personvern, all deltakelse er frivillig og basert på samtykke. Registeret må kunne utvides til alle sykehus i Norge og må kunne sammenkobles med andre helseregistre (Dødsårsaksregisteret, medisinsk fødselsregister, norsk pasientregister, kreftregisteret, reseptregisteret, registre under SSB, registre under NAV). Registeret er for pasienter med KOLS og har i første omgang til hensikt å kunne sammenligne helseeffekter ved ulike behandlingsopplegg med utgangspunkt i pasienter innlagt på sykehus. Registeret ble etablert som et lokalt papirbasert register i 2004 og ble utvidet til Nasjonalt register fra 2006 gjennom godkjenning fra Helse- og omsorgsdepartementet. Elektronisk datainnsamling ved bruk av MRS-plattformen ble godkjent av datatilsynet i 2010 og pilotfasen startet i februar 2011 ved Haukeland Universitetssjukehus, Lungeavdelingen. De første 12 måneder etter pilotfasen (1.juli juni 2012) med web-basert løsning er det registrert 458 opphold som utgjør 40,4 % av alle opphold med hoved- eller bidiagnose kols ved Lungeavdelingen i samme periode (N = 1133). Pr. 1.oktober 2012 er registeret introdusert til 3 andre sykehus, Haugesund, Ålesund og St.Olav, og tatt aktivt i bruke ved de to førstnevnte. St.Olav har intensjon om å komme i gang ila. høsten Det er planlagt informasjonsreiser til sykehusene Kristiansand/Arendal, Stavanger og Tromsø ila. høsten Helse Vest RHF er databehandlingsansvarlig for opplysninger i registeret. Inklusjonskriterier for Nasjonalt register for kronisk obstruktiv lungesykdom Alle pasienter innlagt ved norske sykehus som får / vil få hoved- eller bidiagnose kols (J41.0- J44.9) i epikrisen fra oppholdet. Pasientene vil avgi en samtykkeerklæring for å bli registrert første gang, og ved senere opphold uten nytt samtykke. Alle deltakere har til en hver tid anledning til tilbaketrekking av samtykke og alle registrerte opphold i registeret vil da slettes. Pasienter uten samtykkekompetanse vil ikke kunne inkluderes i registeret. Arkiverte data i registeret. Vi ønsker en enkel datainnsamling for å opprettholde motivasjonen blant informantene til å gi data over tid. Følgende data vil bli registrert: 1. Dato for aktuell innleggelse, informant 2. Demografi dvs. personnummer, kjønn, høyde, vekt. 3. Røykevaner 4. Infeksjonsstatus (C-reaktivt protein (CRP), leucocyttall (LPK), ph basert på arteriell blodgass) ved innleggelse 5. Eventuell antibiotika behandling og ventilasjonsstøtte under aktuelle sykehusopphold. 6. Ko-morbide sykdommer

24 7. Spirometri, helserelatert livskvalitet- COPD assessment test (CAT), arteriell blodgass og medikamenter ved utskrivelse. Registrering av utreisedestinasjon (hjem, institusjon). Evt. død under oppholdet. 8. Informasjon gitt ved utskrivelse vedrørende influensavaksine, kols-rehabilitering og røykeavvenning ml serum tatt ved utskrivelsen til lagring i biobank (ikke tatt i bruk pr. 1/10-12) Eier av registeret. Helse-Vest representert ved ledelsen i Lungeavdelingen, Haukeland Universitetssykehus og Seksjon for lungemedisin, Institutt for indremedisin. Styret av registeret 1. Avdelingsleder ved Lungeavdelingen, Haukeland Universitetssykehus. Vedkommende er ansvarlig for rutinemessig og systematisk innsamling av data og er leder for styret. 2. Professorene/ førsteamanuensene i lungemedisin (heltid og deltid ved Universitetet i Bergen). Vedkommende er ansvarlig for årlige analyser, forskningsveiledning og internasjonal publisering av data fra registeret. 3. Datakvalitetsleder for pasienter og behandling ved Haukeland Universitetssykehus. Vedkommende skal gi råd om lovene (Helseregisterloven, Biobankloven og Bioteknologiloven) og registerdrift inkludert tiltak for personvern og kobling til andre registre som folkeregisteret, dødelighetsregisteret, kreftregisteret, fødselsregisteret og m.fl. 4. En spesialist i lungesykdommer fra hver helseregion skal ila. høst 2012 inngå i en nasjonal rådgivningsgruppe, rekruttert fra de deltagende sykehus. Vedkommende skal ha et ansvar for at problemstillinger av allmenn interesse blir stilt registeret og at eksterne brukere blir rekruttert for å anvende registeret. Medlemmet utpekes av styret av registeret, konf. Pkt. 1 og 2. Sekretariat Sekretariatet er lokalisert i Lungeavdelingen, Haukeland Universitetssykehus og bemannes med 1/1 stilling for kvalitetssikring av data og internkontroll av registeret. Utbytte av registeret Opprettelse av et nasjonalt pasientregister for kolspasienter vil gi: 1. innsikt i behandling og forløp (overlevelse) til en stor gruppe pasienter som vil øke i antall i Norge, 2. et verktøy for å måle forbedringer og en mer effektiv forebyggelse, diagnostikk og behandling av en stor gruppe pasienter, 3. innsikt i direkte og indirekte helsekostnader hos en stor pasientgruppe, 4. et verktøy for internasjonalt forskningssamarbeid hvor norsk, klinisk forskning har et fortrinn, 5. et verktøy som kan gjøre det mulig å utføre ekstern finansiert oppdragsforskning av høy kvalitet.

25 Registerforskning har foreløpig vært prioritert for pasientgrupper som kreft, hjertekarsykdommer, gravide og fødselsskader men det er intet etisk eller helseøkonomisk grunnlag som tilsier at ikke andre pasientgrupper skulle få de samme muligheter for å erverve seg lignende kunnskaper. Et pasientregister er naturligvis ikke noe substitusjon for randomiserte kliniske forsøk. Den gir imidlertid en bedre forståelse av hvordan diagnostiske tiltak, legemidler, opplæring og kontroller virker i en vid pasientpopulasjon. Kontrollerte kliniske forsøk anvendes i meget selektive pasientpopulasjoner og kan ikke gi informasjon om hvordan medikamenter og andre tiltak fungerer i virkeligheten med pasienters og helsearbeideres reelle handlingsmønstre. Informasjon fra pasientregistret bør derfor være et grunnlag for politisk og administrative beslutninger om tiltak og finansielle prioriteringer med relasjon til helsen for kols- pasienter. Vedlegg o Konsesjon fra Datatilsynet o Informasjonsbrev til deltakerne / Samtykkeerklæring

26 Forespørsel om registrering i Nasjonalt Kolsregister (Register for pasienter med kronisk obstruktiv lungesykdom). Bakgrunn Dette er et spørsmål til deg om å la deg registrere i Nasjonalt kolsregister. Hensikten er å sikre dokumentasjon av behandlingsresultat. For å gi best mulig behandling og oppfølging er det behov for bedre kunnskap, ikke bare om tilstanden hos hver enkelt kolspasient, men om hele pasientgruppen. Nasjonalt kolsregister vil danne et viktig grunnlag for forskning om kols. For at behandlingstilbudet til pasientene skal bli best mulig, er både kvalitetssikring og forskning viktig og nødvendig. Å bli registrert i kolsregisteret er frivillig og krever informert samtykke, det betyr at du må undertegne en samtykkeerklæring før vi kan registrere deg i registeret. Registeret vil inneholde følgende opplysninger om deg: De opplysninger som inngår i registeret er navn og fødselsnummer og opplysninger om diagnoser og behandling som blir gitt. Andre opplysninger som registreres er innleggelse- og utskrivings-dato, høyde, vekt, røykevaner, blodprøvesvar, lungefunksjontester, livskvalitetsscore, medikamentbruk ved utreise, samt informasjon om influensavaksine/ rehablitering/ røykeavvenning kurs gitt ved utreise. Opplysningene innsamles ved at relevante opplysninger fra pasientjournalen din overføres til kolsregisteret. Helse Bergen HF er databehandlingsansvarlig og eier av registeret. Registrering av opplysninger skjer ved hjelp av datateknologi og er sikret mot innsyn fra uvedkommende. Opplysningene lagres permanent i elektronisk form. Behandlingen av opplysningene er godkjent av Datatilsynet etter Personopplysningslovens 33. Alle innsamlede opplysninger behandles konfidensielt, og alle som arbeider med opplysninger fra registeret har taushetsplikt om forhold de får kjennskap til. Fagpersonene som behandler pasientgruppen kan få opplysninger fra registeret om de pasientene de selv har behandlet. Biobank Blodprøven (5 ml blod) som blir tatt og informasjonen utledet av dette materialet vil bli lagret i en forskningsbiobank ved Haukeland Universitetssykehus. Hvis du sier ja til å delta i studien, gir du også samtykke til at det biologiske materialet og analyseresultater inngår i biobanken. Professor Per Bakke er ansvarshavende for forskningsbiobanken. Biobanken planlegges å vare til Etter dette vil materiale og opplysninger bli destruert og slettet etter interne retningslinjer. Innsynsrett, endring og sletting av opplysninger Du har full rett til innsyn i hva som er registrert om deg, og til å få korrigert eventuelle feil. I tillegg kan du når som helst kreve at innsamlede prøver og opplysninger om deg blir slettet fra registeret, uten at du må oppi noen grunn. Sletting av data vil ikke innebære sletting fra anonymiserte forskningsfiler som allerede er benyttet i forskning. Det vil ikke ha noen betydning for ditt behandlingsopplegg dersom du velger å ikke la deg registrere, eller dersom du senere ønsker å trekke deg. Besøksadresse: Haukeland Universitetssykehus, Jonas Liesvei 65, Postadresse: Helse Bergen HF, Postboks 1, 5021 Bergen Telefon Innvalg Telefaks, E-post: postmottak@helse-bergen.no Foretaksnr. NO mva. Internett:

27 Utlevering av opplysninger fra registeret vil bare skje til forskere i form av avidentifiserte oversikter. Det vil si at alle opplysningene vil bli behandlet uten navn og fødselsnummer eller andre direkte gjenkjennende opplysninger. En kode knytter deg til dine opplysninger og prøver gjennom en navneliste. Det er kun autorisert personell knyttet til registeret som har adgang til navnelisten og som kan finne tilbake til deg. For forskningsprosjekter kan det være aktuelt å i tillegg sammenstille informasjon fra registeret med andre opplysninger fra sykejournal og fra andre offentlige registre, som medisinsk fødselsregister, norsk pasientregister, kreftregisteret, reseptregisteret, registre under Statistisk Sentralbyrå, registre under Norsk arbeids og velferdsforvaltning (NAV), og dødsårsaksregisteret. Alle forskningsprosjekter må imidlertid forhåndsgodkjennes av Den regionale komité for medisinsk forskningsetikk og andre offentlige instanser som loven krever. Registeransvarlig: Professor Per Bakke Haukeland Universitetssykehus, Lungeavdelingen. Postboks 1, 5021 Bergen Tlf: ERKLÆRING OM SAMTYKKE Jeg har lest informasjonsskrivet forespørsel om registrering i Nasjonalt kolsregister, og er gjort kjent med registerets formål, hvilke personopplysninger som skal registreres, hvor opplysningene skal hentes fra, hvordan utlevering av opplysninger skal foregå og hvilke rettigheter jeg har med hensyn til innsyn, endring og sletting av opplysninger i registeret. Jeg er kjent med at opplysninger hentes fra min journal, og at det kan bli tatt blodprøver til oppbevaring i en forskningsbiobank, som vil være en del av registeret. Innsamlede prøver og opplysninger vil bare bli brukt i kvalitetssikring av pasientbehandling og i forskning om kols. Jeg samtykker herved i at innsamlede prøver og opplysninger om meg som beskrevet i informasjonsskrivet inngår i Nasjonalt kolsregister. NAVN: ( Bruk blokkbokstaver) Fødselsnummer: ( 11 siffer ) Dato: Underskrift. Besøksadresse: Haukeland Universitetssykehus, Jonas Liesvei 65, Postadresse: Helse Bergen HF, Postboks 1, 5021 Bergen Telefon Innvalg Telefaks, E-post: postmottak@helse-bergen.no Foretaksnr. NO mva. Internett:

28 Besøksadresse: Haukeland Universitetssykehus, Jonas Liesvei 65, Postadresse: Helse Bergen HF, Postboks 1, 5021 Bergen Telefon Innvalg Telefaks, E-post: Foretaksnr. NO mva. Internett:

29

30

31

32

33

34

35

36 Rapportering nasjonale kvalitetsregistre KONTAKTINFORMASJON Registerets navn Norsk kvalitetsregister for leppe- kjeve- ganespalte Registeransvarlig Klinikkdirektør August Bakke, Kirurgisk klinikk, Helse Bergen HF Telefon Til registeradm: august.bakke@helse-bergen.no E-post lkg-register@helse-bergen.no Helseforetak Postadresse Hjemmeside Helse Bergen HF Norsk kvalitetsregister for leppe- kjeve- ganespalte Haukeland universitetssjukehus, 5021 Bergen 2 REGISTERINFORMASJON Hovedformål Juridisk hjemmelsgrunnlag Dekningsgrad institusjon 1. Sikre pasientene best mulig behandling og oppfølging 2. Sikre entydig registrering og datainnsamling av LKG-spalte behandlingen 3. Registrere om pasientgruppen og foresatte føler seg ivaretatt 4. Legge forhold til rette for å kunne sammenligne behandling og resultat med andre behandlingsteam 5. Tilrettelegge for forskning 6. Utarbeide årsrapporter Oppdragsdokument fra Helse og omsorgsdepartementet til Helse Sør-Øst RHF og Helse Vest RHF: Helse Sør-Øst RHF og Helse Vest RHF har samarbeidet om å opprette et nasjonalt medisinsk kvalitetsregister for leppe-kjeve ganespalte for å styrke behandlingstilbudet til barn med leppe-kjeve-ganespalte. Registeret skal sikre dokumentasjon av behandlingsresultater for denne pasientgruppen. Konsesjon fra Datatilsynet for opprettelse av det sentrale registeret foreligger fra 20.oktober 2010 (ref 09/146-2/CGN) med utdyping Krav er skriftlig samtykke fra foresatte og fornyet samtykke fra pasienten ved 16 år. Samtykket kan innhentes av en av medlemmene i behandlingsteamet på vegne av alle faggruppene. Datatilsynet tillater ikke at informasjon formidles mellom faggruppene via registeret. To behandlingsteam for leppe- kjeve- ganespalte i Norge behandler alle pasienter med LKG; Oslo-teamet: Oslo Universitetssykehus, Statped Bredtvet kompetansesenter Bergens-teamet: Haukeland universitetssjukehus, Statped Vest, Fylkestannlegen i Hordaland/Universitetet i Bergen Rapportering nasjonale kvalitetsregistre 2012 Side 1

37 Dekningsgrad 100%, dvs alle nyfødte som blir henvist til kirurgisk behandling av LKG-spalte i Norge inviteres til deltagelse i registeret. Dekningsgrad individ Registeret startet inklusjon av pasienter fra 1.januar Alle nyfødte etter 1. januar 2011 med spalte som henvises til de to behandlingsteamene, inviteres til deltagelse. Fra samme dato har kjeveortoped inkludert pasienter som innkalles til rutinekontroll 6 år og logoped og psykolog pasienter til rutinekontroll 10 år. 3 INNTEKTER 2011 Tildelt beløp fra Helse Vest Overført beløp fra tidligere år Tildelt beløp fra eksterne kilder Totalsum inntekter 2011 Beskrivelse av eventuelle eksterne inntektskilder mil mil 0 4 KOSTNADER 2011 Lønnskostnader Andre driftskostnader Utstyr Totalsum kostnader 2011 Beskrivelse av kostnader Nedsatt aktivitet i registeret pga sykdom. Utarbeiding av rapporter derfor utsatt. Samme med ferdigstilling av web-side og informasjonsbrosjyrer. Rapportering nasjonale kvalitetsregistre 2012 Side 2

38 5 OVERFØRING AV MIDLER Sum midler som er overført til 2012 Begrunnelse for hvorfor midlene ikke er brukt i 2011 Kort redegjørelse for bruk av evt. overførte midler i Nedsatt aktivitet pga langtids sykefravær, ikke hatt vikar Se vedlagt budsjett 6 IKT Løsning for datafangst Løsning for rapportering Kommentarer til løsningene for datafangst og rapportering Hver institusjon har en spesifikk tilgang med fem roller i MRS systemet: Behandler, Leser, Pasientansvarlig, Registeransvarlig, Brukeradministrator. I tillegg har daglig leder / koordinator tilgangen Brukeradministrator for alle institusjonene. Systemansvarlig ved Helse Vest IKT har rollen som Systemadministrator (ref. Driftsmanual MRS). Opplysningene lagres elektronisk i avidentifisert form (separat fra navn og fødselsnummer) Virksomhetene/institusjonene har ikke ha tilgang til hverandres data. Administrerende direktør i Helse Bergen HF, er databehandlingsansvarlig for registeret Den sentrale database i Helse Nord leverer data ved etterspørsel fra registeradministrasjonen. Et standardisert oppsett for årlig rapportering er i planleggingsfasen. Videreutvikling av de elektroniske skjemaene i en versjon 1.1. er i spesifisert i samarbeid med fagsenteret for kvalitetsregistre Helse Bergen i løpet av høsten Versjon 1.1 vil trolig komme i drift V Ved årskiftet 2012/13 har registeret inkludert ca 200 pasienter født etter 1. januar Det vil også være inkludert ca 200 pasienter født før 1. januar 2011 med diagnosekoder som delvis er konverterbar til LKG-registerets kodesystem. Høsten 2012 arbeider vi med forberedelser til en rapport med deskriptive data til fagmiljøene, foretaksledelse og pasientforening som skal være tilgjengelig i løpet av første halvdel av 2013 og presenteres på styremøtet V ANALYSE OG RAPPORTERING Styret har ansvar for retningslinjene som regulerer tilgang og bruk av data og avgjør hvem som får tilgang. I kompliserte spørsmål kan Utleverte data uavhengige eksperter konsulteres. Avgjørelsen kan påklages etter forvaltningslovens regler. Styret skal påse at beslutninger følger Rapportering nasjonale kvalitetsregistre 2012 Side 3

39 Viktigste analyser Helse Bergens til enhver tid gjeldende styrende dokumenter og er i samsvar med konsesjonsbetingelser, registervedtekter, samtykker og gjeldende lovverk. Tilgang til data til forskningsprosjekter tilstås i henhold til prosjektsøknad som er i tråd med Helseforskingsloven og er godkjent av Regional komité for medisinsk og helsefaglig forskningsetikk (REK). Den vitenskapelige problemstillingen må ligge innenfor registerets formål. Forøvrig skal man ved tildeling av data legge vekt på følgende forhold: Faglig kvalitet og originalitet Nytteverdi for folkehelsen, forebyggende og/eller kurativt helsearbeid Faglige, administrative, praktiske og økonomiske bidrag til planlegging og/eller innsamling av data som inngår i registeret Det faglige miljø rundt søkeren Om delprosjektet kan øke kvaliteten på registerets database, for eksempel prosjekter som validerer registerdata Dersom flere søknader omfatter samme problemstilling, vil forskerne bli oppfordret til å samarbeide, enten ved samarbeide om analyser og publisering, eller ved en finere inndeling av problemstillingen. Hvis dette ikke går, vil styret prioritere søknadene etter faglig kvalitet. Ved bruk av data fra registeret skal kilde alltid oppgis. Det skal inngås skriftlig avtale med prosjektleder for bruk av materialet. Det skal loggføres tidspunkt og til hvem data er utlevert, samt hvilke opplysninger som er utlevert. Rapporter Rapportering på datakvalitet Rapportering til HF-ledelse Et oppsett for årlig rapportering av institusjonenes egne data, og en samlet årsrapport til behandlerne i det nasjonale datasettet er under arbeid. Oppsett for årlig rapport til pasientorganisasjon og sykehusadministrasjon utarbeides også. De første fire årene vil rapportene være rent deskriptive, hovedsakelig opptelling og beskrivelse av inkluderte pasienter. Etter ytterligere noen år drift vil statistiske analyser av data bli lagt til. Kompletthet - inklusjon av pasienter og utfylling av skjema må overvåkes. Registeradministrasjonen har ansvar for dette overvåkes og skal rapportere til styret hvert halvår. Via registeransvarlig August Bakke, direktør ved Kirurgisk klinikk, HUS 8 RELASJON TIL FAGLIGE RETNINGSLINJER/VEILEDERE OG KVALITETSINDIKATORER* Oppfølging av anbefalinger Oppdragsdokument fra Helse og omsorgsdepartementet fra nasjonale retningslinjer til Helse Sør-Øst RHF og Helse Vest RHF Rapportering nasjonale kvalitetsregistre 2012 Side 4

40 Målsetting for behandling Nasjonale kvalitetsindikatorer Svarbrev fra Helse Vest til Helse og omsorgsdepartementet På oppdrag fra Helsedirektoratet 1 har Helse Sør-Øst RHF og Helse Vest RHF samarbeidet om å opprette et nasjonalt medisinsk kvalitetsregister for leppe- kjeve ganespalte for å styrke behandlingstilbudet til barn med leppe- kjeveganespalte. Systematisk behandlingsplan for pasienter med LKG som viser standardisert oppfølging fra alle faggruppene i behandlingsteamene, Registeret skal med bakgrunn i denne planen sikre dokumentasjon av behandlingsresultater for denne pasientgruppen. Alle faggrupper registrerer funksjon relatert til kirurgisk behandling. Komplikasjoner kort tid etter operasjon: Plastikkirurg: blødning, infeksjon Viktigste parameter (e) Langtidsresultat etter kirurgi: Logoped: tale Kjeveortoped: bitt og tyggeforhold Psykolog: livskvalitet ØNH: hørsel, luftpassasje nese Plastikkirurg: funksjon og utseende «Maksimalt resultat med minimalt av tiltak» Pasientrapporterte utkommemål (PROMS) Foreldretilfredshet i forhold til postoperativ smertebehandling, ernæring og informasjon. Rapportering nasjonale kvalitetsregistre 2012 Side 5

41 9 IGANGSATTE FORBEDRINGSPROSJEKTER Kort beskrivelse av prosjekt som er startet Forbedringer / resultat oppnådd i pasientbehandlingen Planlagte forbedringsprosjekter Retrospektiv detaljert diagnosekoding av pasienter født , dvs- 450 pasienter i Bergensteamet og 1100 pasienter i Osloteamet. Dette gjør at kan vi inkludere pasientene i registeret og registrere hendelser og undersøkelser etter 1.januar Opprettelsen av registeret har vært inspirerende for fagmiljøet. Det har styrket samarbeidet mellom faggruppene og mellom de to behandlingsteamene. 10 RELASJON TIL INTERNASJONALE MILJØER Vi hadde besøk fra det svenske kvalitetsregisteret for LKG-behandlingen i oppstartfasen. Planlagt studietur til dette registeret og til det danske miljøet i Kort beskrivelse Seminardag 4.oktober 2013 med Professor Murthy fra Sri Ramachandra Medical College & Research Institute, Chennai, India. LKG registeret er et av temaene. 11 DELTAKENDE ENHETER Kort beskrivelse To behandlingsteam for leppe- kjeve- ganespalte i Norge behandler alle pasienter: Oslo-teamet: Oslo Universitetssykehus, Statped Bredtvet kompetansesenter Bergens-teamet: Haukeland universitetssjukehus, Statped Vest, Fylkestannlegen i Hordaland/Universitetet i Bergen Sykepleier, Logoped, Kjeveortoped, Psykolog, Plastikkirurg og ØNH-lege i begge team bidrar med registreringer. 12 PERSONELL Stillinger Faglig leder 20% Koordinator 100% Statistiker / It-konsulent 20% kortere engasjement av annen kompetanse Alle lønnes via registeret 13 FORSKNING Publikasjoner Forskningsprosjekt: «Å leve med leppe- ganespalte», REK-Vest 1098/2010. Forskningsstudien skal bruke data fra noen av de nasjonale registrene i Norge (Medisinsk Fødselsregister, registre Rapportering nasjonale kvalitetsregistre 2012 Side 6

42 under Forløpsdatabasen trygd, Utdanningsdirektoratet og Skattedirektoratet) og vil beskrive forhold for hele befolkningen, som er født i Norge fra generelt og for barn født med leppe-ganespalte spesielt. Vi vil følge alle barn, som ble født i Norge i tidsrommet (1,5 millioner barn), frem til Alle deltagere er derfor 18 år eller eldre i Vi vil sammenligne barn som er født med og uten leppe-ganespalte med tanke på skolegang (grunnskole, videregående-, høyskole), mottak av trygdetjenester og sosialhjelp, samt data om dødsfall, opplysninger om yrkeskarriere og etablering av egen familie. Vi vil studere variabler som er brukt i et kvalitetsregister i Bergens teamet Variablene er faggruppenes vurdering av behandlingsresultat ved 15 år, kodet i en karakterskala som er utarbeidet av hver av faggruppene i teamet. Vi vil evaluere disse variablene mtp bruk i det nasjonale LKG registeret. «Prenatal diagnostikk av LKG-spalte», søknad REK under utarbeidelse. 20% legestilling planlagt til prosjektet første del av Prosjekt er et samarbeid mellom Oslo og Bergensteamet og Senter for fostermedisin UiB og planlegger kobling av data med Medisinsk Fødselsregister. Publikasjoner Medlemsbladet for pasientforeningen «Dialog» 2011 Poster ved europeisk LKG-kongress Salzburg 2012 Artikkel i Journal of Craniofacial and Cleft lip and palate er under arbeid. Verdenskongress mai-2013, Orlando. Fire abstrakt med data fra LKG -registeret er akseptert. 14 RELEVANTE VEDLEGG NB: Registerprotokoll skal inkluderes som vedlegg. Både budsjett for 2011 og regnskap for 2011 skal også legges ved denne rapport. I tillegg må budsjett og planer for 2012, samt tentativt budsjett og planer for 2013 redegjøres for. Forklarende kommentarer til de ulike kostnadsområdene skal legges inn i punkt 4 i dette skjema, eventuelt inkluderes som et eget vedlegg. Vedlegg o Vedtekter o Sammensetning styre, brev fra Registereier o o o Konsesjon fra Datatilsynet Databehandleravtale underskrevet eksemplarer er lagret i ephorte Brev fra Helse og omsorgsdepartementet til Helse Sør-Øst RHF og Helse Vest RHF Rapportering nasjonale kvalitetsregistre 2012 Side 7

43 o Brev fra Helse Vest til Helse og omsorgsdepartementet o Budsjett 2013 o Forventede utgifter 2012 o o o o Risikovurdering Informasjonsbrosjyre link på hjemmeside Informasjon og Samtykkeskriv - link på hjemmeside Brukerveiledning- link på hjemmeside o budsjett for 2011 og regnskap for 2011 o budsjett og planer for 2012 o tentativt budsjett og planer for 2013 Rapportering nasjonale kvalitetsregistre 2012 Side 8

44 REGISTERPROTOKOLL Norsk kvalitetsregister for Leppe- kjeve-ganespalte Norwegian registry of Cleft Lip and Palate Registerets organisering Registerets mandat Helse og omsorgsdepartementet (HOD) påla i 2008 Helse Sør-Øst RHF og Helse Vest RHF å etablere et kvalitetsregister for leppe- kjeve-ganespalte (LKG) behandlingen, og helseforetakene ble enige om at ansvaret for etableringen og driften av dette registeret skulle legges til Helse Vest RHF og Helse Bergen HF. Administrerende direktør har delegert ansvaret til Klinikkdirektør i Kirurgisk Klinikk, Haukeland universitetssykehus, som dermed har hovedansvaret for databehandling og drift. Ansvaret for finansieringen ligger i det regionale foretaket. Se vedlegg: Brev fra Helse og omsorgsdepartementet til Helse Sør-Øst RHF og Helse Vest RHF Brev fra Helse Vest til Helse og omsorgsdepartementet Sammensetning styre (konf brev registereier ) Styringsgruppen skal bestå av 7 medlemmer som skal representere registeret geografiske utbredelse, aktuelle fagmiljøer, ha fagpolitisk forankring, ha forskningskompetanse og øvrig kompetanse knyttet mot gjeldende retningslinjer, lovverk og krav til medisinske registre samt ha ett medlem fra aktuelle pasientgrupper. To representanter fra LKG-miljøet i Oslo To representanter fra LKG-miljøet i Bergen En representant fra styret i Norsk plastikkirurgisk forening En representant med forskning- og lederkompetanse utenfor de aktuelle miljøer En representant for den aktuelle pasientgruppen Kirurgi er den sentrale delen av behandlingen, og det forutsettes at en kirurg fra henholdsvis Oslo og Bergen er i styringsgruppen. De øvrige fra Oslo og Bergen bør fortrinnsvis være fra andre fagområder.sammensetningen må tilstrebes å inneha god akademisk kompetanse med minimumskrav til en representant med akademisk kompetanse på norsk doktorgradsnivå eller tilsvarende. Referansegruppen kan oppnevnes av styringsgruppen. Den bør være bredt sammensatt og skal brukes som rådgivende organ. Referansegruppe skal sikre rådgivning fra pasient- og brukerorganisasjoner, andre fagmiljøer enn de som sitter i styringsgruppen, representanter for universiteter / høyskoler og forvaltning. Referansegruppen skal oppnevnes for samme tidsperiode som styringsgruppen. Introduksjon Ansvarlig for registeret. Administrende direktør for Helse Bergen, Stener Kvindsland er databehandlingsansvarlig for registeret og Direktør ved Kirurgisk Klinikk Helse Bergen, August Bakke er registeransvarlig. Deltagende institusjoner Oslo-teamet: Oslo Universitetssykehus, Statped Bredtvet kompetansesenter Bergens-teamet: Haukeland Universitetssjukehus, Statped Vest, Fylkestannlegen i Hordaland/Universitetet i Bergen Alle samarbeidspartnere til registeret

45 It-arbeid Bernt Olav Økland, Helse Vest Ikt It-sikkerhet Eline Monstad, It-sikkerhetsleder Helse Vest Juridisk veiledning Eline Monstad, It-sikkerhetsleder Helse Vest Helsefortakenes veiledningstjeneste for kvalitetsregistre Registerenheten ved Helse Nord Anne Høye, leder Fagsenter for medisinske registre Helse Vest Ane Johannessen, leder Bakgrunn På oppdrag fra har Helse Vest RHF i samarbeid med Helse Sør-Øst RHF opprettet Norsk kvalitetsregister for leppe- kjeve- ganespalte. Hensikten er å sikre dokumentasjon av behandlingsresultat. For å gi best mulig behandling og oppfølging er det behov for bedre kunnskap, ikke bare om tilstanden hos hver enkelt pasient som er født med leppe- kjeveganespalte, men om hele pasientgruppen. Nasjonalt kvalitetsregister for leppe- kjeve- ganespalte vil være et viktig grunnlag for forskning. For at behandlingstilbudet til pasientene skal bli best mulig, er både kvalitetssikring og forskning viktig og nødvendig. Målsetninger Sikre entydig registrering og datainnsamling av LKG-spalte behandlingen Sikre pasientene best mulig behandling og oppfølging Registrere om pasientgruppen og foresatte føler seg ivaretatt Legge forhold til rette for å kunne sammenligne behandling og resultat med andre behandlingsteam Tilrettelegge for forskning Utarbeide årsrapporter Materiale og metode Inklusjonskriterier: Barn og voksne med leppe- kjeve- ganespalte som henvises til de to behandlingsteamene i Norge. Pasienter uten spalte, som henvises teamene med diagnosen rhinolalia aperta (hypernasalering) er en aktuell gruppe pasienter å inkludere i registeret, fordi noen følger samme behandlingsopplegg som pasienter med leppe- kjeve-ganespalte. Pasientgruppen med rhinolalia aperta uten LKG-spalte er svært heterogen mtp andre funksjonshemninger. Styringsgruppen finner det nødvendig å etablere registeret med en veldefinert og mest mulig homogen pasientgruppe. Registeret etableres derfor bare med pasienter som får diagnostisert en leppe- kjeve- ganespalte. Når registeret er veletablert og har vært i drift i fem-ti år vil styret vurdere om inklusjonskriteriene skal utvides. Eksklusjonskriterier Foresatte som ikke samtykker eller som etter skriftlig samtykke trekker tilbake sitt samtykke. Pasienter over 16 år som skriftlig trekker tilbake samtykket. MRS, Medisinske Registrerings System

46 Registreringsskjema skriv inn % på pasientsøk o Variabelspesifikasjon Versjon 1.1. spesifikasjon, konf. Bernt Olav Økland ved Fagsenteret for kvalitetsregistre Helse Bergen o Systemspesifikasjon og risikovurdering Konf Helse Vest Ikt eller o Kvalitetssikring Rutiner for kvalitetssikring av data kopletthet De første årene trenger vi en oversikt over antallet som ikke leverer inn samtykke. Fordi hvis for mange utgår, må rutiner for innhenting av samtykke revurderes i klinikkene og styret vurdere søknad til Datatilsynet om endringer i konsesjonen. En person som samler alle samtykkene for behandlingsteamet. Vedkommende har også et "lokalt behandlingsregister" (det er lovlig uten konsesjon), dvs en komplett liste over alle pasientene som har vært til dagskurs og/eller vært operert ved sykehuset. Det vil si at dette "lokale registeret" også har med de som ikke har samtykket. Ved å sammenligne disse to" listene", kan man finne hvor mange som ikke har samtykket. Koordinator skal innhente disse opplysningene en gang i halvåret og rapportere til styret. o Databehandleravtale V / personvernombudet Helse Bergen og Direktør Kirurgisk Klinikk Helse Bergen o Tilgangsstyring Hver institusjon har en spesifikk tilgang med fem roller i MRS systemet: Behandler, Leser, Pasientansvarlig, Registeransvarlig, Brukeradministrator. I tillegg har daglig leder / koordinator tilgangen Brukeradministrator for alle institusjonene. Systemansvarlig ved Helse Vest IKT har rollen som Systemadministrator (ref. Driftsmanual MRS). Opplysningene lagres elektronisk i avidentifisert form (separat fra navn og fødselsnummer) Virksomhetene/institusjonene har ikke ha tilgang til hverandres data. o Logging, Rutiner for backup-lagring, Rutine for vedlikehold, Drifting, Endring Konf Driftsansvarlig Helse Vest Ikt. Tidsplan Registeret startet inklusjon av pasienter 1.januar Alle nyfødte etter 1. januar 2011 med spalte som henvises til de plastikkirurgiske avdelingene inviteres til deltagelse. Fra samme dato inkluderte kjeveortoped og ØNH-lege pasienter som ble innkalt til rutinekontroll 6 år og logoped og psykolog pasienter til rutinekontroll 10 år. Elektronisk registrering var tilgjengelig fra 23.september Ingen planlagt sluttdato for registeret Konsesjon fra Datatilsynet

47 Konsesjon fra Datatilsynet for opprettelse av det sentrale registeret foreligger fra 20.oktober 2010 (ref 09/146-2/CGN) med utdyping Krav er bl.a. skriftlig samtykke fra foresatte, fornyet samtykke fra pasienten ved 16 år og at informasjon ikke kan formidles mellom faggruppene via registeret. Samtykket kan innhentes av en av medlemmene i behandlingsteamet på vegne av alle. Forutsetninger for konsesjonen er sikkerhetsdokumentasjonen knyttet til Medisinsk Registrering Systemet (MRS) og at tilgang sikres ved sterk autentisering. Vedlegg o Vedtekter o Sammensetning styre, brev fra Registereier o Konsesjon fra Datatilsynet o Databehandleravtale underskrevet i ephorte o Brev fra Helse og omsorgsdepartementet til Helse Sør-Øst RHF og Helse Vest RHF o Brev fra Helse Vest til Helse og omsorgsdepartementet o Budsjett 2013 o Forventede utgifter 2012 o Risikovurdering o Informasjonsbrosjyre link på hjemmeside o Informasjon og Samtykkeskriv - link på hjemmeside o Brukerveiledning- link på hjemmeside

48 Vedtekter for Norsk kvalitetsregister for Leppe- kjeve- ganespalte 1 Registerets navn Norsk kvalitetsregister for leppe- kjeve- ganespalte Kortversjon: LKG-registeret Engelsk navn: Norwegian Registry of Cleft Lip and Palate 2 Registerets formål 1. Sikre pasientene best mulig behandling og oppfølging 2. Sikre entydig registrering og datainnsamling av LKG-spalte behandlingen 3. Registrere om pasientgruppen og foresatte føler seg ivaretatt 4. Legge forhold til rette for å kunne sammenligne behandling og resultat med andre behandlingsteam 5. Tilrettelegge for forskning 6. Utarbeide årsrapporter 3 Innhold i registeret Registeret er samtykkebasert og består av personopplysninger som er samlet inn for å ivareta registerets funksjon. Konsesjon fra Datatilsynet Konsesjon fra Datatilsynet for opprettelse av det sentrale registeret foreligger fra 20.oktober 2010 (ref 09/146-2/CGN) med utdyping Krav er bl.a. skriftlig samtykke fra foresatte, fornyet samtykke fra pasienten ved 16 år og at informasjon ikke kan formidles mellom faggruppene via registeret. Samtykket kan innhentes av en av medlemmene i behandlingsteamet på vegne av alle. Forutsetninger for konsesjonen er sikkerhetsdokumentasjonen knyttet til Medisinsk Registrering Systemet (MRS) og at tilgang sikres ved sterk autentisering. Inklusjonskriterier: Barn og voksne med leppe- kjeve- ganespalte som henvises til de to behandlingsteamene i Norge. Pasienter uten spalte, som henvises teamene med diagnosen rhinolalia aperta (hypernasalering) er en aktuell gruppe pasienter å inkludere i registeret, fordi noen følger samme behandlingsopplegg som pasienter med leppe- kjeve-ganespalte. Pasientgruppen med rhinolalia aperta uten LKG-spalte er svært heterogen mtp andre funksjonshemninger. Styringsgruppen finner det nødvendig å etablere registeret med en veldefinert og mest mulig homogen pasientgruppe. Registeret etableres derfor bare med pasienter som får diagnostisert en leppe- kjeve- ganespalte. Når registeret er veletablert og har vært i drift i fem-ti år vil styret vurdere om inklusjonskriteriene skal utvides. Eksklusjonskriterier Foresatte som ikke samtykker eller som etter skriftlig samtykke trekker tilbake sitt samtykke. Pasienter over 16 år som skriftlig trekker tilbake samtykket. Formatert: Høyre: 0,63 cm 1

49 4 Ansvar for registeret På oppdrag fra Helsedirektoratet 1 har Helse Sør-Øst RHF og Helse Vest RHF samarbeidet om å opprette et nasjonalt medisinsk kvalitetsregister for leppe-kjeve ganespalte for å styrke behandlingstilbudet til barn med leppe-kjeve-ganespalte. Registeret skal sikre dokumentasjon av behandlingsresultater for denne pasientgruppen. Helse Vest RHF og Helse Sør-Øst RHF har i samråd lagt drift og det økonomiske ansvaret for registeret til Helse Bergen HF. Administrerende direktør i Helse Bergen HF, er databehandlingsansvarlig for registeret, og Klinikkdirektør for Kirurgisk klinikk i Helse Bergen HF er registeransvarlig. 5 Organisering av registeret Styringsgruppe De to behandlingsteamene for leppe- kjeve- ganespalte i Norge har det faglige ansvaret for registeret. Styringsgruppen i etableringsfasen består av fagpersoner fra de to behandlingsteamene og fra Medisinsk Fødselsregister. Etter forslag fra fagmiljøene har registeransvarlig godkjent følgende styringsgruppe: Michael Matzen, Overlege, Plastikkirurgisk avdeling, Universitetssykehuset Oslo Gunvor Semb, Kjeveortoped, Bredtvet kompetansesenter og Universitetssykehuset Oslo Inger Beate Tørdal, Logoped, Bredtvet kompetansesenter Hallvard Vindenes, Overlege, plastikkirurgisk avdeling, Haukeland Universitetssykehus Åse Sivertsen, Overlege, Plastikkirurgisk avdeling, Haukeland Universitetssykehus Rolv Terje Lie, Professor medisinsk statistikk, Universitetet i Bergen og Medisinsk Fødselsregister Vararepresentanter Hvert behandlingsteam har en vararepresentant til styringsgruppen i etableringsfasen. Osloteamet: Kristin Billaud Feragen, psykolog, v/ Statped Bredtvet kompetansesenter. Bergensteamet: Paul Sæle, kjeveortoped, v/ Universitetet i Bergen og Fylkestannlegen i Hordaland Leder av styringsgruppen Styringsgruppen har valgt sin leder: Rolv Terje Lie, Professor medisinsk statistikk v/universitetet i Bergen og Medisinsk Fødselsregister Styringsgruppen er oppnevnt fra januar Fasen med utarbeidelse og utprøving av registeret regner man vil vare i to år. Styringsgruppen besluttet at de seks medlemmene fortsetter som medlemmer av styret det første året med etablert drift. 1 Oppdragsdokument fra Helse og omsorgsdepartementet til Helse Sør-Øst RHF og Helse Vest RHF Svarbrev fra Helse Vest til Helse og omsorgsdepartementet Formatert: Høyre: 0,63 cm 2

50 - Halvparten av medlemmene i styret bør bli sittende ved nytt styrevalg. - Man kan sitte i styret i inntil 6 år. - Valg av styret legges til NorCleft møtene, samarbeidsmøtene mellom de to behandlingsteamene som arrangeres med ett og et halvt års intervall. - Deltagerne på NorCleft møtet fra spalteteamene i Oslo og Bergen har stemmerett til styrevalg. - Det første styrevalget blir vinter/vår Nytt styre velges ved hvert tredje NorCleft møte, dvs med 4,5 års intervall. - Styret skal til valget legge fram et forslag til ny styresammensetning. - Styrets sammensetning i driftsfasen: 2 medlemmer fra Bergensteamet 2 medlemmer fra Osloteamet 1 medlem fra Registermiljøet 1 medlem fra Pasientorganisasjonen Minst ett av styrets medlemmer må være ansatt i Helse Bergen HF. Styringsgruppen konstituerer seg selv og velger selv sin leder. Beslutningsrett De seks medlemmene av styringsgruppen / styret har beslutningsrett. For beslutningsdyktighet kreves 4/6 tilstedeværelse. Vedtak fattes med alminnelig stemmeflertall. Ved stemmelikhet har styreleder dobbeltstemme. Tale og møterett Styremedlemmene har møterett til styremøtene. Styreleder har uttalerett. Daglig leder deltar i møtene med talerett, men uten stemmerett. Styringsgruppen møtes annen hver gang i Oslo og Bergen. Dato for møtene settes opp på styremøtet nært desember hvert år. Referansegruppe Bjørn Andersen, Leder Leppe-ganespalteforeningen Edda Olofsdottir, Overlege, Barneklinikken Haukeland Universitetssykehus Stein Emil Vollset, Leder Medisinsk Fødselsregister Kristin Feragen, Psykolog, Bredtvet kompetansesenter Nina Lindberg, Sykepleier, plastikkirurgisk avdeling, Universitetssykehuset Oslo Jens Christian Haug-Ericsson, Overlege, øre nese hals avdelingen, Haukeland Universitetssykehus Samarbeidspartnere til registeret IT-arbeid Helse Midt-Norge IT Helse Nord IT Helse Vest IKT AS IT-sikkerhet og juridisk veiledning Personvernombud Helse Bergen personvernombudet@helse-bergen.no Formatert: Høyre: 0,63 cm 3

51 Helseforetakenes veiledningstjeneste for kvalitetsregistre Registerenheten ved Helse Nord Fagsenter for medisinske registre Helse Vest Daglig drift Registeret vil bli drevet av et sekretariat med daglig leder, som skal være medisinsk utdannet og ha relevant erfaring med leppe- kjeve- ganespalte behandling. Vedkommende skal være ansatt i Kirurgisk klinikk, Helse Bergen. Daglig leder ansettes på åremål etter råd fra styret. Daglig leder rapporterer til styret. Daglig leder o Medisinsk utdannet o Faglig ansvarlig o Informasjonsansvarlig o Utarbeide årsrapporter og andre rapporter o Videreutvikle det elektroniske skjemaet o Kontaktledd til styret o Kontaktledd mellom Helse Vest IKT AS og behandlingsteamene Koordinator o Kontaktperson for behandlingsteamene, faggruppene. Tilrettelegge registreringen o Kontaktperson for pasientgruppen. o Kontakt Helse Vest IKT AS Opprette nye brukere Kontaktledd mellom Helse Vest IKT AS og behandlingsteamene o Vedlikehold av Web-sidene Informasjon til pasientgruppen Informasjon til behandlingsteamene o Organisere samhandlingsmøte mellom behandlingsteamene (70 personer) o Utarbeide informasjonsbrosjyre Statistiker o Utarbeiding av årsrapporter og andre repporter o Videreutvikle det elektroniske skjemaet. 6 Styrets oppgaver Styrets oppgaver omfatter: Videreutvikle registeret i henhold til intensjonene Utarbeide forslag til budsjett og søke om budsjettmidler Bearbeide retningslinjer for tilgang og bruk av data i registeret Fortløpende vurdere alle henvendelser om bruk av data. Beslutninger om bruk og utlevering til forskningsprosjekt gjøres i henhold til godkjenning gitt av REK.. Gi råd til daglig leder og gi retningslinjer for daglig drift Ansvarlig for årsmelding og regnskap som utarbeides av daglig leder Registeransvaret ligger til administrerende direktør Helse Bergen. Denne har delegert dette til klinikkdirektør Kirurgisk klinikk. Styret skal rapportere til denne. Formatert: Høyre: 0,63 cm 4

52 7 Retningslinjer for tilgang, bruk og lagring av data i registeret Styret har ansvar for retningslinjene som regulerer tilgang og bruk av data og avgjør hvem som får tilgang. I kompliserte spørsmål kan uavhengige eksperter konsulteres. Avgjørelsen kan påklages etter forvaltningslovens regler. Styret skal påse at beslutninger følger Helse Bergens til enhver tid gjeldende styrende dokumenter og er i samsvar med konsesjonsbetingelser, registervedtekter, samtykker og gjeldende lovverk. Tilgang for daglig bruk gis til personell med tjenestelig behov, og bare til data for egen virksomhet. Detaljert beskrivelse av spaltetype med figur og femsifret kode registreres av plastikkirurgen etter første operasjon utleveres mellom virksomhetene, men bare innenfor eget behandlingsteam. Denne opplysningen er grunnleggende for videre behandling og registrering av data i alle faggrupper. Annen relevant informasjon vil bli utlevert på forespørsel mellom faggruppene ved tjenestelig behov. Tilgang i forbindelse med forskning tilstås i henhold til prosjektsøknad som er i tråd med Helseforskingsloven og er godkjent av Regional komité for medisinsk og helsefaglig forskningsetikk (REK). Prosjektet vil bli betraktet som et delprosjekt av Norsk kvalitetsregister for Leppe- kjeve - ganespalte. Avtale om tilgang gir bruksrett i henhold til en eller flere spesifiserte problemstillinger i en begrenset periode. Utleveringen av data tilpasses den konkrete forespørsel. Den vitenskapelige problemstillingen må ligge innenfor registerets formål. Forøvrig skal man ved tildeling legge vekt på følgende forhold: Faglig kvalitet og originalitet Nytteverdi for folkehelsen, forebyggende og/eller kurativt helsearbeid Faglige, administrative, praktiske og økonomiske bidrag til planlegging og/eller innsamling av data som inngår i registeret Det faglige miljø rundt søkeren Om delprosjektet kan øke kvaliteten på registerets database, for eksempel prosjekter som validerer registerdata Dersom flere søknader omfatter samme problemstilling, vil forskerne bli oppfordret til å samarbeide, enten ved samarbeide om analyser og publisering, eller ved en finere inndeling av problemstillingen. Hvis dette ikke går, vil styret prioritere søknadene etter faglig kvalitet. Ved bruk av data fra registeret skal kilde alltid oppgis. Det skal inngås skriftlig avtale med prosjektleder for bruk av materialet. Det skal loggføres tidspunkt og til hvem data er utlevert, samt hvilke opplysninger som er utlevert. Hver institusjon har en spesifikk tilgang med fem roller i MRS systemet: Behandler, Leser, Pasientansvarlig, Registeransvarlig, Brukeradministrator. I tillegg har daglig leder og/eller koordinator tilgangen Brukeradministrator for alle institusjonene. Systemansvarlig ved Helse Vest IKT har rollen som Systemadministrator (ref. Driftsmanual MRS). Formatert: Høyre: 0,63 cm 5

53 Lagring av data Opplysningene lagres elektronisk i avidentifisert form (separat fra navn og fødselsnummer) Virksomhetene som registrerer data har ikke ha tilgang på hverandres data. Start- og sluttdato Registeret startet inklusjon av pasienter fra 1.januar Alle nyfødte etter 1. januar 2011 med spalte som henvises til de plastikkirurgiske avdelingene inviteres til deltagelse. Fra samme dato inkluderer kjeveortoped og ØNH-lege alle pasienter som innkalles til rutinekontroll 6 år. Logoped og psykolog inkluderer pasienter til rutinekontroll 10 år. Elektronisk registrering var tilgjengelig fra 23.september Registeret planlegges uten tidsbegrensning. Det er ikke planlagt å slette data etter endt registreringsperiode ut over for personer som trekker seg. 8 Endring av vedtektene Forslag til endring fremlegges av styret for råd og driftsansvarlig institusjon (Helse Bergen HF). Endringer må alltid forelegges helseforetaket, slik at databehandlingsansvaret og behovet for endringsmelding i forhold til konsesjonen kan sikres. Helse Bergen HF skal påse at forslag til endringer er i samsvar med gjeldende lovverk, og har ansvar for å gjennomføre evt. endringsmeldinger i henhold til konsesjoner og lignende. Styret kan fatte vedtak om endringer av vedtektene med ¾ flertall. Bergen, revidert Åse Sivertsen, Prosjektleder for styringsgruppen Formatert: Høyre: 0,63 cm 6

54 Kirurgisk Klinikk Utlevering av data fra Norsk kvalitetsregister for leppe- kjeve- ganespalte Retningslinjer for tilgang til data fra Norsk kvalitetsregister for Leppe- kjeveganespalte (LKG-registeret) til kvalitetssikrings- og/eller forskningsformål. Dokumentets formål Formålet er å redegjøre for LKG-registerets retningslinjer for å sikre høy tilgjengelighet av data fra LKG-registeret til kvalitetssikrings- og/eller forskningsformål, samt å sikre høy vitenskapelig kvalitet på arbeider fra registeret. Retningslinjene har også som formål å sikre at utlevering av data skjer i tråd med gjeldende regler for behandling av personopplysninger. Den delmengde av data som en faggruppe ved ett av de to behandlingsteamene selv har levert til LKG-registeret skal være fritt tilgjengelige for ansatte fra den aktuelle faggruppen. Utlevering av slike del-datasett er således unntatt fra det regelverket som omhandler aggregerte data fra flere faggrupper og aggregerte data fra begge behandlingsteam. Adgang til data Tilgang til data gis etter søknad og inngått avtale med LKG-registerets styre. En slik avtale gir rettigheter til å undersøke og publisere på en bestemt problemstilling. Det må framgå av avtalen hvilken periode en eventuell tidsavgrensning skal gjelde for. Data som utleveres vil være avidentifiserte i. Samarbeid mellom faggruppene i behandlingsteamet Faggruppene plikter å informere de andre faggruppene i behandlingsteamet om problemstillingen under planlegging av søknad om data. De andre faggruppene i behandlingsteamet skal inviteres til deltagelse i prosjekt og søknad tidlig i prosessen. Samarbeid mellom behandlingsteamene Behandlingsteamene plikter å informere hverandre om problemstillingen og søknaden om data. Det andre behandlingsteamet skal inviteres til deltagelse i prosjekt og søknad tidlig i prosessen. Besøksadresse: Haukeland Universitetssykehus, Jonas Liesvei 65, Postadresse: Helse Bergen HF, Postboks 1, 5021 Bergen Telefon Innvalg Telefaks , E-post: postmottak@helse-bergen.no Foretaksnr. NO mva.

55 2 Krav til søknad Søknaden om tilgang til data bør inneholde en fullstendig prosjektbeskrivelse og publikasjonsplan. Det må klart fremgå av søknaden hvem som er prosjektleder og har det faglige ansvaret for prosjektet. Søknaden skal inneholde en beskrivelse av: Problemstillingen Beskrivelse av utvalget som ønskes, samt hvilke variabler som skal benyttes i analysen. Publikasjonsplan Artikler, internett, målgrupper for publisering For hvert prosjekt må det vurderes om det omfattes av allerede eksisterende godkjenninger/konsesjon, eller om det er nødvendig med ny tilråding i Regional komité for medisinsk og helsefaglig forskningsetikk forskningsetikk (REK) og/eller registrering hos Datatilsynet/personvernombudet. De nødvendige godkjenninger må foreligge før data kan utleveres. Dokumentasjon fra faggruppene i hvert av behandlingsteamene at de informert om og invitert til deltagelse i prosjektet og søknaden. Dokumentasjon fra begge behandlingsteam at de informert om og invitert til deltagelse i prosjektet og søknaden. Behandling av søknad Søknader om tildeling av data med tilhørende problemstillinger stiles til styringsgruppen for LKG-registeret, eventuelt det organ styringsgruppen utnevner til dette formål. Følgende kriterier vektlegges ved behandling av søknad: Faglig relevans Prosjektet må være faglig velbegrunnet og av en slik natur at det best lar seg undersøke innenfor rammene av et register. Prosjekter som er i overensstemmelse med LKG-registerets primære formål vil bli prioritert. Faglig kapasitet Prosjektleder må sannsynliggjøre at prosjektmedarbeiderne har kompetanse og kapasitet til å analysere og publisere data på en faglig tilfredsstillende måte og innen rimelig tid. Hensyn til pågående prosjekter Søknadens prosjektbeskrivelse og publikasjonsplan skal ikke være konflikt i med andre godkjente publikasjonsplaner. Dersom to prosjekter ligger faglig nær hverandre vil styringsgruppen oppmuntre til faglig samarbeid mellom prosjektene. Tidsbegrensning Før utlevering av data bør det inngås en avtale med styringsgruppen om en tidsbegrensning for tilgang til data. For doktorgradsprosjekter er det vanlig å skjerme problemstillingen i 5 år. For andre forskere i 3 år. For kvalitetsikringsformål (kontinuerlig monitorering) kan det være aktuelt å stille data til disposisjon uten å stille krav til sluttdato. Prosjektet bør da beskrive meldingsrutiner til registeret ved vesentlige endringer og/eller mangelfull framdrift.

56 3 Datautlevering Data utleveres som tekstfil, og kan derfra konverteres til aktuell programvare av søker. Persondata som utleveres til forskningsformål vil normal være avidentifiserte eller anonymiserte ii. Et løpenummer (en tilfeldig serie) vil erstatte person identifikasjon, slik at enkelt personer kan følges i datamaterialet. Regler for publisering Ved publisering, her forstått som all offentliggjøring av forskningsresultater eller annen sammenstilling av data der det benyttes data fra LKG-registeret skal det fremgå at dataene er fra LKG-registeret. Forfatterskap Ved publisering må Vancouver-reglene ligge til grunn for medforfatterskap. Dette betyr at for å kunne kreve medforfatterskap må vedkommende ha bidratt substansielt til konsept og ide, eller innsamling av data, eller analyse og fortolkning av data. Medforfattere skal før publisering ha godkjent den versjonen som sendes inn for publisering. Reaksjoner ved avtalebrudd Ved avtalebrudd vil styringsgruppen for LKG-registeret ta kontakt med prosjektansvarlig for en avklaring av de faktiske forhold i saken. Dersom det ikke oppnås enighet mellom partene vil det kunne bli aktuelt og sende en skriftlig redegjørelse til de ansvarlige ved den prosjektansvarliges institusjon om at denne har overtrådt avtalen om bruk av data. Hvis dette ikke fører frem til en enighet mellom partene vil det kunne være aktuelt for styringsgruppen å inndra rettighetene til dataene. Klager og omgjøring av vedtak Styringsgruppen er ansvarlig for forvaltning av dataene i registeret. Klager på beslutninger som styringsgruppen for det enkelte register har fattet vedrørende utlevering og bruk av data, rettes til styringsgruppen for LKG-registeret. i Data der navn, fødselsnummer og andre personentydige kjennetegn er fjernet, slik at opplysningene ikke lenger kan knyttes til en enkeltperson, og hvor identitet bare kan tilbakeføres ved sammenstilling med de samme opplysninger som tidligere ble fjernet, jfr. Helseregisterloven 2. ii Opplysninger der navn, fødselsnummer og andre personentydige kjennetegn er fjernet, slik at opplysningene ikke lenger kan knyttes til en enkeltperson, jfr. Helseregisterloven 2 Bergen, For styringsgruppen, Åse Sivertsen, prosjektleder

57 404 Rutine for oppfyllelse av prosjektdeltakernes rettigheter i forskningsprosjekter Internkontrollsystem for medisinsk og helsefaglig forskningsvirksomhet Dokumenteier: Forskningsansvarlig Dokumentansvarlig: Gyldig fra: Gjelder for: Prosjektleder Versjon: 0.9 Vedr. rutiner for sletting av helse-og personopplysninger i LKG-registeret. (saksopplysning av fra Åse Sivertsen, prosjektleder) Rutinen er nylig oppdatert i forhold til ny helseforskningslov, og har derfor ikke blitt godkjent ennå. Denne nye rutinen vil gjelde også for kvalitetsregisteret generelt. Se i dokumentet under. Formål Deltakelse i forskningsprosjekter er som hovedregel basert på frivillighet. Enhver som har blitt informert og/eller samtykket til slik deltakelse kan kreve innsyn, retting av uriktig registrerte opplysninger, trekke seg fra videre deltakelse eller tilbakekalle avgitt samtykke, herunder sletting/reservasjon. Henvendelser om innsyn må alltid skje skriftlig, være datert og undertegnet av forskningsdeltaker eller dennes verge. Det er ikke nødvendig å oppgi noen årsak. Tidspunkt Ved henvendelse om innsyn i og/eller retting og sletting av data fra forskningsdeltaker i forskningsprosjekter Hvis forskningsdeltaker ønsker å trekke seg fra deltakelse i forskningsprosjekter. Aktiviteter Prosjektleder saksbehandler innkomne henvendelser fortløpende. Krav om innsyn skal besvares uten ugrunnet opphold, og senest innen 30 dager etter at organisasjonen mottok henvendelsen. Ved innsyn må det vurderes hvorvidt innsyn skal begrenses eller avslås med en medisinsk eller annen begrunnelse. Ved avslag på krav om sletting, kan avgjørelsen klages inn for Regional komité for medisinsk og helsefaglig forskningsetikk (REK). Maler Svar på henvendelse om innsyn (vil bli utarbeidet) Svar på henvendelse om sletting/reservasjon (vil bli utarbeidet) Dokumentasjon Henvendelse og svar på henvendelse arkiveres i ansvarlig organisasjon sitt saksarkiv. Lovmessig grunnlag Helseforskningsloven 36, 40, 42 og 43 Personopplysningsloven 24 Forvaltningsloven 11a

58

59

60 Kirurgisk Klinikk Data som registreres i Norsk kvalitetsregister for Leppe- kjeve- ganespalte. Til oppstarten av registeret har vi utarbeidet variabler til registrering i barneårene (0-10 år), vedlagt i listene nedenfor. Seks faggrupper skal levere data til registeret: Plastikkirurger, logopeder, øre-nese-hals leger, sykepleiere, psykologer og kjeveortopeder. Registeret skal følge behandlingen av barnet fra nyfødt til ung voksen alder. Ved oppstart av registeret inngår datainnsamling i veletablerte behandlings- og kontrollopplegg ved begge behandlingsteam. Oppstart av registrering er planlagt til 1. januar 2010, og vi ønsker å inkludere pasienter som henvises første gang til behandlingsteamene f.o.m. 1.januar Vi har også lagt opp til en retrospektiv registrering slik at logopedene, kjeveortopedene og psykologene skal samle data til registrering av barn som i 2010 er henholdsvis 4 år, 6 år og 10 år. Denne retrospektive registreringen innebærer skriftlig informasjon til foresatte og innhenting av samtykke, på samme måte som til nyfødte. Uten en slik retrospektiv registrering av diagnose og gjennomgått behandling vil det gå 4-10 år før logopedene, kjeveortopedene og psykologene kan legge inn data og svært lenge før man kan ta ut nytten av registeret. Datainnsamling til registeret er lagt til faste kontroller (alderstrinn) som er godt etablert i behandlingsoppleggene ved behandlingsteamene. Alderstrinn for registreringer etter fylte 6 år vil være avhengig av spaltetypen barnet har. Det vil ved alle spaltetyper bli gjort registreringer i forbindelse med all kirurgisk behandling. Ved de mest vanlige spaltetypene vil vi samle data til registeret ved oppfølgingskontroll 15 år, 18 år og 22 år. Inkludering i registeret vil ikke innebære innkalling til kontroller utenom dagens etablerte behandlingsopplegg, og barna må ikke gjennomføre annen behandling eller undersøkelser enn barn som ikke er inkludert i registeret. Besøksadresse: Haukeland Universitetssykehus, Jonas Liesvei 65, Postadresse: Helse Bergen HF, Postboks 1, 5021 Bergen Telefon Innvalg Telefaks , E-post: postmottak@helse-bergen.no Foretaksnr. NO mva.

61 2 Plastikkirurgi Alle operasjoner 6 år Klassifisering ved første operasjon Overskrift Navn datasetttype/ parameter Gyldige verdier Kommentar Tidspunkt for registrering Personalia Personnummer Xxxxxx xxxxx Første operasjon Dato for undersøkelsen Alder ved undersøkelsen Etternavn Fornavn Undersøkelsesdato Barnets alder Xx xx xxxx Regnes ut av maskinen fra fødselsdato og undersøkelsedato Spaltemorfologi Y-klassifisering Avkryssing i figur (eget vedlegg ) Obligatorisk Qiang L in Cleft palatecraniofacial journal Sept 2007, vol 44 no.5 Femsifret spaltekode XXXXX Kommer automatisk fra utkryssing i figuren over. Qiang L in Cleft palatecraniofacial journal Sept 2007, vol 44 no.5 ICD 10 diagnose Q35-37 Kommer automatisk fra utkryssing i figuren over

62 3 Alle operasjoner - også ved alle polikliniske og dagkirurgiske operasjoner Operasjonsprosedyre Operasjonsprosedyre Leppelukking Andre prosedyrer under samme narkose Ganelukking Sulcusplastik Bein til kjevespalte Svelgplastik Fistellukking Leppekorreksjon Nesekorreksjon Ortognatisk kirurgi Reoperasjon innen 1 uke Annet Paracentese Innleggelse av ventilasjonsdren Tann ekstraksjon Blottlegging tann Krokfeste tann Hjernestamme audiometri Ingen andre Obligatorisk Avkryssing Flere mulige Obligatorisk Avkryssing Flere mulige Dato for operasjonen Operasjonsdato xx.xx.xx Obligatorisk Alder ved operasjonen Dato fra Orbit Alder År + mndr Regnes av maskinen Ventetid Frist start behandling xx.xx.xx Dato fra Orbit Ventetid mndr Regnes av maskinen fra operasjonsdato og frist start behandling Behandlingsnivå Behandlingsnivå Poliklinisk operasjon Rullegardin Alle operasjoner - også poliklinisk, dagkirurgi

63 4 Leppelukking Ganelukking Bein til kjevespalte Svelglapp Leppelukking Operasjonsmetode Leppelukking Tilleggsprosedyre Ganelukking Operasjonsmetode Ganelukking Tilleggsprosedyre Bein til kjevespalte Tilleggsprosedyre Svelglapp Operasjonsmetode Svelglapp Tilleggsprosedyre Dagkirurgi Innleggelse Millard Annen McCoomb Vomer-lapp Sommerlad Langenbeck Sideincisjoner Lukking av restspalte Lukking av fistel Hyne s Pharyngeal lapp Fettcelle injeksjon Sideincisjoner Ett alternativ mulig Aktiveres ved operasjonsprosedyren leppelukking Rullegardin Ett alternativ mulig Ja/nei Begge prosedyrer er mulig Aktiveres ved operasjonsprosedyren ganelukking Rullegardin Ett alternativ mulig Ja/nei Aktiveres ved operasjonsprosedyren bein til kjevespalte Avkryssing Flere mulige Aktiveres ved operasjonsprosedyren svelglapp Rullegardin Ett alternativ mulig Ja/nei Fistellukking Fistellukking Mucoperiost lapp alene Aktiveres ved operasjonsprosedyren Leppelukking Ganelukking Bein til kjevespalte Svelgplastikk fistellukking

64 5 Operasjonsmetode Beintransplantasjon Tungelapp Nesekorreksjon Nesekorreksjon Septumplastik Tilleggsprosedyre Osteotomi Ortognatisk kirurgi Ortognatisk kirurgi LeFort I Operasjonsmetode LeFort II LeFort III Mandibel retraksjon Akutt reoperasjon Reoperasjon Blødning Infeksjon Annet fistellukking Rullegardin Ett alternativ mulig Aktiveres ved operasjonsprosedyren nesekorreksjon Avkryssing Flere mulige Aktiveres ved operasjonsprosedyren ortognatisk kirurgi Avkryssing Flere mulige Aktiveres ved operasjonsprosedyren Reoperasjon innen 1 uke Avkryssing Flere mulige Nesekorreksjon Ortognatisk kirurgi Reoperasjon innen 1 uke Ved sykehusinnleggelse for leppelukking, ganelukking og ved oppfølgingskontroll 6 år Komorbiditet Andre misdannelser, sykdommer Ja Nei Obligatorisk Hvis ja, neste spørsmål Leppelukking Ganelukking Fellesundersøkel ser 4, 6 og 16 år Muskel-skjelett Avkryssing Hjerte Flere mulige Annen ansiktsmisdannelse Øye Øre

65 6 Dysmorfe trekk Aldersadekvat psykomotorisk utvikling Medisinsk genetisk utredning Klinisk syndromdiagnose / genetisk diagnose Annet i sentral nervesystemet Andre Ja Nei Usikkert Ja Nei Usikkert Ikke indikasjon Har vært undersøkt Henvises i dag Navn skrives Obligatorisk Rullegardin Ett alternativ mulig Obligatorisk Rullegardin Ett alternativ mulig Obligatorisk Rullegardin Ett alternativ mulig Informasjon fra tidligere registreringer må komme opp ICD 10 Oppfølgingskontroll 6 år Fistel Oronasal fistel Ja Rullegardin 4, 6 og 16 år Nei Ett alternativ mulig - spalte i kjeve eller gane som har vært forsøkt lukket Usikkert Hvis ja, to neste spørsmål Lokalisasjon Uvula Avkryssing Bakre bløte gane Flere mulige Overgang harde- bløte gane Harde Prealvolært

66 7 Størrelse Alveola Foramen incisivum området Sonderbar inn i nesen ja-nei Væske passerer ja-nei Mat passerer ja- nei Avkryssing Flere mulige

67 8 Kjeveortopedi 6 år Overskrift Tidspunkt for registrering Navn datasetttype/ parameter Variabelnavn Variabel nummer Måleenhet Gyldige verdier Validering (min/max, annet) Personalia Personnummer 1 Xxxxxx xxxxx Etternavn 2 Fornavn 3 Spalteklassifisering Kirurg ved første operasjon Spaltekode 4 Xxxxx +figur 0-4, 0-4, 0-4, 0-4, 0-4 Data overføres fra plastikkirurgens registrering (første operasjon) Spalte hovedgruppe 5 CLO CLP CPO Data overføres fra plastikkirurgens registrering (første operasjon) Spørsmål relevant for spaltetype kommer opp i skjemaet for registrering- For eksempel ved CPO utgår spørsmål om beintransplantasjon Dato for undersøkelsen 6 år Undersøkelsedato 6 Xx xx xxxx Alder ved undersøkelsen Barnets alder 7 Regnes ut av maskinen fra fødselsdato og undersøkelsedato Antall tenner i spalteområdet 6 år Agenesi 8 Nei Ja Usikkert Betegnelse aktuelle agenesi 9 xx Xx Xx Xx Dersom ja eller usikkert kommer neste spørsmål To siffer skrives inn for hver tann Evnt flere

68 9 Overtallige tenner 10 Nei Ja Usikkert Tannbuerelasjoner 6 år Horisontalt 11 Overbitt Kantbitt Underbitt Vertikalt 12 Åpent Kantbitt Normalt Dypt Rullegardin Ett alternativ mulig Rullegardin Ett alternativ mulig Rullegardin Ett alternativ mulig Transversalt (kryssbitt) Transversalt (kryssbitt) beskrivelse Nei Ja Usikkert 13 Enkeltsidig Dobbeltsidig Partielt Dersom ja eller usikkert kommer neste spørsmål Rullegardin Ett alternativ mulig Yardstick Rullegardin Ett alternativ mulig Profilrøntgen SNA 15 grader xx Tosifret tall skrives inn SNB 16 xx Tosifret tall skrives inn ANB 17 xx Tosifret tall skrives inn Beintransplantasjon 6 år Beintransplantasjonsbehov 18 Nei Ja Usikkert Rullegardin Ett alternativ mulig Denne variabelen aktiveres ikke ved CPO Kjeveortopedisk behandling 6 år Behov for tidlig tannregulering 19 Nei Ja Usikkert Rullegardin Ett alternativ mulig Fistel 6 år Oronasal fistel 20 Nei Rullegardin

69 10 -spalte i kjeve eller gane som har vært forsøkt lukket Ja Usikkert Ett alternativ mulig Karies 6 år Karieserfaring 21 Nei Ja Rullegardin Ett alternativ mulig

70 11 Logopedi 4 år Overskrift Navn datasetttype/ parameter Gyldige verdier Personalia Personnummer Xxxxxx xxxxx Etternavn Fornavn Spalteklassifisering Spaltekode 0-4, 0-4, 0-4, 0-4, figur Kommentar Data overføres fra plastikkirurgens registrering (første operasjon) Spalte hovedgruppe CLO CLP CPO Data overføres fra plastikkirurgens registrering (første operasjon) Dato for undersøkelsen Undersøkelsedato Xx xx xxxx Nasalitet Hypernasalitet Normal Ubetydelig /innslag av lett Lett og konsekvent/innslag av moderat Moderat og konsekvent/innslag av sterk Sterk og konsekvent Hyponasalitet Normal Ubetydelig /innslag av lett Lett og konsekvent/innslag av moderat Moderat og konsekvent/innslag av sterk Sterk og konsekvent Valg i rullegardin Valg i rullegardin

71 12 Artikulasjon Talens forståelighet (Perseptuell vurdering i henhold til SVANTE) Velopharynxfunksjon (Perseptuell vurdering i henhold til SVANTE) Trykkredusert artikulasjon Nasal luftlekkasje Antall korrekt artikulerte orale konsonanter Antall artikulasjonsavvik foran velofarynx Antall artikulasjonsavvik bak velofarynx Talens forståelighet Velopharynxfunksjon Normal Valg i rullegardin Ubetydelig /innslag av lett Lett og konsekvent/innslag av moderat Moderat og konsekvent/innslag av sterk Sterk og konsekvent Normal Valg i rullegardin Ubetydelig /innslag av lett Lett og konsekvent/innslag av moderat Moderat og konsekvent/innslag av sterk Sterk og konsekvent Andel av totalen % Andel av totalen % Andel av totalen % God Valg i rullegardin Lett nedsatt Sterkt nedsatt Ikke vurdert Tilstrekkelig Valg i rullegardin Marginal utilstrekkelig Utilstrekkelig (inkompetent) Ikke vurdert

72 13 Sykepleie Første sykehusinnleggelse Alle utskrivelser Overskrift Navn datasetttype/ parameter Gyldige verdier Kommentar Tidspunkt for registrering Personalia Personnummer Xxxxxx xxxxx Første sykehusinnleggelse Etternavn Fornavn Fødselsår xxxx Fra personnummer Kjønn jente Fra personnummer gutt Sosialt Mors bosted før barnets fødsel Postnummer sted Mor født i Norge Ja Nei Far født i Norge Ja Nei Barnet født i Norge Ja Nei Barnet adoptert Ja Nei Tidligere operasjoner LKG operasjoner utført i annet land Ja Nei Feltet aktiveres dersom barnet ikke er født i Norge

73 14 Prosedyrer gjort i annet land Leppelukking Ganelukking Kommer opp dersom ja Flere mulige Familie Nære slektninger med LKG Ja Nei Ikke opplysninger Mor Kommer opp dersom ja Far Avkryssing Tvilling Flere mulige Helsøsken Halvsøsken Besteforeldre Fosterdiagnostikk Diagnose ved ultralyd i svangerskapet Ja Nei Ikke opplysninger Aktiveres ikke dersom barnet ikke er født i Norge Alle utskrivelser Årsak til sykehus innleggelsen Årsak til innleggelsen Planlagt operasjon Komplikasjon, nylig LKG operert Utredning Rullegardin Ett alternativ Alle utskrivelser fra sykehuset Etter dagkirurgi eller poliklinisk operasjon Antall innleggelse døgn etter operasjonen Sykehusavdeling 1-20 døgn Pasienthotell 1-20 døgn

74 15 Psykologi 10 år Overskrift: Psykologisk fungering og tilpasning Alder Navn datasetttype/ parameter Måle-enhet Gyldige verdier Validering (min/max, annet) Strength and Difficulties Questionnaire (barnet/ungdom og foreldre) Child Experience Questionnaire (barnet/ungdom) Satisfaction with Appearance scales (barnet/ungdom) Satisfaction with service and treatment (foreldre) Vurdering av hvorvidt barnets selvfølelse er preget av spalten (foreldre) Henvist til psykolog i spalteteamet utenom rutineundersøkelsen 10 år Sumskåre av 20 ledd store vansker Emosjonelle vansker Gjennomsnittsverdi for 5 ledd 0-10 Atferdsvansker Gjennomsnittsverdi for 5 ledd 0-10 Hyperaktivitet/uoppmerksomhet Gjennomsnittsverdi for 5 ledd 0-10 Sosiale vansker Gjennomsnittsverdi for 5 ledd 0-10 Prososial atferd Gjennomsnittsverdi for 5 ledd 0-10 sumskåre av alle 20 ledd 0-80 Erting Ett ledd fra CEQ 0-4 Andre stirrer Ett ledd fra CEQ år Ja Gjennomsnittsverdi av sumskåre basert på 2 ledd (evt.14 ledd) stor tilfredshet med utseende Ett ledd stor tilfredshet Ett ledd ingen innvirkning 10 positiv innvirkning 0 negativ innvirkning Nei Ikke opplysninger

75 16 Henvist fra Oppfølging psykolog i teamet Oppfølging psykolog lokalt Foreldre Plastikkirurg Kjeveortoped Logoped Sykepleier Andre Ja Nei En oppfølgingssamtale Behandling/terapi Viderehenvisning Ingen tilgjengelig psykolog Annet Ja Nei BUP Barnevern PPT Privat Kompetansesenter Annet Ved ja - avkryssing Ved ja - avkryssing Ved ja - avkryssing Bergen, Åse Sivertsen

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131 DET KONGELIGE HELSE- OG OMSORGSDEPARTEMENT HELSE E3ERGEN HF J~flL~ Sa~nr.:~b7- Dok.rir.: f Arkivrir.:3 Q, ~ Helse Sør-øst RI-IF i,! Helse Vest RHF ~ t f ~ Deres ref Vår ref Dato SHAl/ME I3ehandlingsfflbudet til pasienter med leppe-kjeve-ganespa1te~herunder pasienter med velocardiofacialt syndrom Bakgruim Det vises til at Helse Sør-øst RHF og Helse Vest RHF i dag har et flerregionalt ansvar for behandling av pasienter med leppe-kjeve-ganespalte, jf rundskriv 1-19/2003. Det vises også til oppdragsdokumentet for 2007 om landsfunksjoner, nasjonale medisinske kompetansesentra og kompetansesentra for personer med sjeldne og lite kjente diagnoser og funksjonshernninger samt møte 27. august 2007 med Helse Sør-øst RHF og Helse Vest RI-IF. Brevet inneholder en utdypning av ansvar og oppgaver i henhold til dette. Vi viser videre til oppdrag gitt til Sosial- og helsedirektoratet av om å forestå en faglig og organisatorisk gjennomgang av behandlingstilbudet til barn med leppe-kjeveganespalte. Rapporten Tilbudet til pasienter med leppe-kjeve-ganespalte, herunder velocardiofacialt syndrom. Faglig gjennomgang ble avgitt av Sosial- og helsedirektoratet 22. august En faglig gjennomgang av det norske behandlingstilbudet av en internasjonal faglig sammensatt arbeidsgruppe på oppdrag fra tidligere Helse Sør RHF samt innspill fra ulike aktører inngår i grunnlaget for Sosial- og helsedirektoratets rapport.. Vi viser videre til brev av til Helse Vest RHF, der (let bes om en særskilt vurdering av organiseringen av behandlingstilbudet til pasienter med leppe-kjeveganespalte i forbindelse med oppdrag om å utarbeide et forslag til en fremtidig heihetlig plan for organisering av lands- og flerregionale funksjoner og rapporten Fremtidig organisering av høyspesialiserte tjenester som ble avgitt i september Postadresse Kontoradresse Telefon* Saksbehandfer Org. nr.. Telefaks

132 Vurdering av behandlingslilbudet til barn med leppe-kjeve-ganespalte Rapporten fra Sosial- og helsedirektoratet fremhever at dagens organisering med tvert-faglige spalteteam og bruk av behandlingsprotokofler som tilfredsstiller internasjonale krav gir grunnlag for en individualjsert, heihetlig og tvert-faglig livsløpsoppfølging for pasienter med leppe-kjeve-ganespalte. Samtidig understrekes det at sarnhandling mellom tjenestenivåene er viktig for behandling av denne pasientgruppen. Rapporten peker også på at det er behov for ytterligere vitenskapelige studier og dokurnentasjon Urn resultater av behandlingen av pasienter med leppe-kjeveganespalte, særskilt når det gjelder taleutvikling, språk og horsel, både nasjonalt og internasjonalt. Departementet legger på bakgrunn av foreliggende dokumentasjon til grunn at det i dag finnes et behandlingstilbud av tilfredsstillende kvalitet i Norge for behandling av pasienter med leppe-kjeve-ganespalte. Vi vurderer det i tråd med dette som hensiktsmessig med en videreforing av dagens sentraliserte tvert-faglige organisering av behandlingstilbudet til barn med leppe-kjeve-ganespalte i henholdsvis Helse Sør-øst RHF og Helse Vest RHF. Rapporten fra Sosial- og helsedirektoratet peker samtidig på enkelte tiltak som kan bidra til å videreutvikle og bedre behandlingstilbudet til pasienter med leppe-kjeveganespalte i Norge. Det foreslås i tillegg.særskilte tiltak for å bedre behandlingstilbudet til barn med velocardiofacialt syndrom. Departementet viser til rapporten, som er tilgjengelig på: ~ av pasienter med leppe kjeve 0 g ganespalte Vurdering av behandlingstilbudet til barn med velocardiofacialt syndrom To kompetansesentre for sjeldne og lite kjente diagnoser og ftmnksjonshemninger lokalisert i Helse Sør-øst RHF, henholdsvis Frambu kompetansesenter for sjeldne funksjonshemninger og Tako-senteret, er i dag tillagt ansvar for å følge opp pasienter med ulike syndromer der leppe-kjeve-ganespalte forekommer, herunder barn med velocardjofacjalt syndrorn. I tillegg følges barn med velocardiofacialt syndrom og leppe og/kjeve-ganespalte opp av de tvert-faglige spalteteamene i hhv Helse Sør-øst RHF og Helse Vest RHF. Når det gjelder behandling av pasienter med velocardiofacialt syndrorn, vises det i rapporten til at denne pasientgruppen bla. på grunn av vanskelig diagnostikk ofte diagnostiseres sent. Det gjelder særskilt barn med skjult ganespalte. I tillegg vises det til at det er særskilte utfordringer innen tale, kommunikasjon og et-næring for barn med velocardiofacialt syncirorn. Side 2

133 Vellocardiofacialt syndrom har et heterogent symptombilcie og rapporten peker derfor på at det er behov for å etablere et særskilt og individuelt tilpasset behandlingstilbud til denne pasientgruppen. Rapporten anbefaler at det utarbeides faglig veiledningsmateriell som kan gi pasienter, pårørende og fagpersonell grunnleggende kunnskap om en tilstand, og at Frambu kompetansesenter koordinerer arbeidet i samarbeid med øvrig fagmiljø og det multidisiplinære teamet. Rapporten peker også på behov for økt kompetanse samt klare ansvarsforhold, slik at prirnærhelsetjenesten både kan gjenkjenne og henvise pasienter med skult ganespalte videre for undersøkelse og følge opp pasienter etter behandling i spesialisthelsetjenesten på en god måte. Rapporten anbefaler derfor at det etableres et spesialisert, rnultidisiplinært team for å styrke kunnskap om diagnose, undersøkelse og behandling av barn ved velocardiofacialt syndrom, og at Barneklinikken ved Rikshospitalet-Radiumhospitalet HF gis en koordinerende Mnksjon. Rapporten anbefaler at dét tilrettelegges for utstyr og kompetanse innen videofluoroskopisk røntgenundersøkelse av denne pasientgruppen, samt at det er behov for okt praksis og avklaring av kunnskapsgrunnlaget for bruk av nasendoskopi i Norge. Siste pekes det på at feltet ernæring/spising for barn for denne pasientgruppen bør styrkes enten ved etablerte pediatriske miljø, eventuelt gjennom økt samarbeid mellom craniofacialt team og kompetansesenteret for barn med spise- og ernæringsvansker ved Rikshospitalet. Departementet vurderer på bakgrunn av foreliggende dokumentasjon, at det er behov for en styrking av det heihetlige behandlingstilbudet til denne pasientgruppen. Oppdrag Departementet forutsetter at Helse Sør-øst RHF og Helse Vest RHF, som er tillagt et flerregionalt ansvar for behandling av pasienter med leppe-kjeve-ganespalte, legger til grunn anbefalingene i rapporten og sikre at disse følges opp på en hensiktsmessig måte. Departementet vil særskilt be om at følgende tiltak iverksettes for å styrke kvaliteten på behandlingstilbudet til barn med leppe-kjeve-ganespalte: Det skal opprettes et informasjons- og kontaktsenter for pasienter med leppekjeve-ganespalte, pårørende og helsepersonell i Helse Sør-øst RI-IF. Formålet er å sikre veiledning og rådgivning, saint bidra til å tilgjengeliggj øre informasjon. Det skal i samarbeid mellom Helse Sør-øst RHF og Helse Vest RHF etableres et nasjonalt medisinsk kvalitetsregister for leppe-kjeve-ganespalte. Formålet er å sikre dokumentasjon av behandlingsresultater for denne pasientgruppen. De to regionale helseforetakene må avklare hvilket RHF som tillegges et overordnet nasjonalt ansvar for drift av det nasjonale kvalitetsregisteret. Det bes om særskilt tilbakemelding på. dette innen 1. desember I tillegg bes det om at det iverksettes følgende tiltak for å styrke behandlingstilbudet til barn med velocardiofacialt syndrom: Side 3

134 Det skal opprettes et multidisiplinært team for barn med velocardiofacialt syndrom i Helse Sør-øst RHR Det multidisiplinære teamet skal sikre kompetanseoppbygging, rådgivning og tilgjengehiggjoring av informasjon om dliagnostikk og behandling av barn med velocardiofacialt syndrom. Oppgaver og ansvar for det multidisiplinære teamet må klargjøres og avgrenses i forhold til de oppgaver og ansvar som er tillagt de etablerte tvert-faglige spalteteamene og øvrige nasjonale kompetansesentre Som har oppgaver tilknyttet denne pasientgruppen. Helse Sør-øst RHF og Helse Vest RHF skal bidra i arbeidet med å utarbeide faglig veiledningsmateriell for diagnostikk og behandling av pasienter med velocardiofacialt syn drom. Veiledningsmateriellet skal informere om særskilte forhold som bør ha spesiell oppnierksomhet i oppføligingen av barn med velocartliofacialt s3~ndrom,saint bidra til å siki~hensiktsmessig samhandling - mellom tjenestenivåene og kunne danne grunnlag for utarbeidelse av individuell plan for disse pasientene. Arbeidet skal gjennomføres i regi av Sosial- og helsedirektoratet, som er tillagt et nasjonalt ansvar for utarbeidelse av nasjonale veiledere. Helse Sør-øst RI-IF og Helse Vest RHF skal vurdere behov for utstyr, kompetanseoppbygging og kunnskapsgrunnlag for bruk av videofluoroskopisk rontgenundersøkelse og nasendoskopi i Norge saint vurdere behov for en styrking av feltet ernæring/spising for barn med velocardiofacialt syndrom, jf rapportens anbefalinger. Departementet legger til grunn at ovennevnte tiltak gjennomføres innenfor tilgjengelige økonomiske rammer. Det bes om at Helse Sør-øst RHF og Helse Vest RHF rapporterer på ovennevnte i årlig melding, samt i årlig rapportering på lands- og flerregionale funksjoner til Sosial- og helsedirektoratet. Det er i dag to fagmiljoer i Norge med kompetanse på denne sykdornmen. Den lovfestede retten til fornyet vurdering, eller second opinion, gjelder kun behandlingstilbud i Norge. Et regionalt helseforetak kan imidlertid etter en konkret faglig vurdering, velge å akseptere at en pasient blir henvist til vurdering i utlandet for foretakets regning. Departementet legger til grunn at de regionale helseforetakene, på bakgrunn av foreliggende dokumentasjon, sikrer nødvendig dialog og samordning slik at pasienter med leppe-kjeve-ganespalte, herunder pasienter med velocardiofacialt syndrom, nasjonalt gis et likeverdig diagnostikk- og behandlingstilbud. Særskilt om logopeditjenesten Rapporten fra Sosial- og helsedirektoratet viser til at det er behov for å legge bedre til rette for lokal oppfølging av hørselsproblematikk og spesialpedagogisk bistand med logoped. Rapporten anbefaler videre at logopedifaget bør styrkes i sin helsefaglige profil og tilknytning, men at den spesialpedagogiske kompetansen fortsatt bør ligge til grunn. Logopeditjenesten er organisert som spesialpedagogisk tilbud under utdanningsdirektoratet. Helse- og omsorgsdepartementet vil be Side 4

135 Kunnskapsdepartementet vurdere rapportens anbefalinger, herunder kapasiteten og det helsefaglige innholdet i logopedifaget. Departementet viser i denne sammenheng også til at Sosial- og helsedirektoratet er gitt i oppdrag å foreta en prinsipiell og overordnet vurdering av helsepersoneilovens autorisasjonsordning. Hovedfonnålet med en slik vurdering skal være å gi departementet beslutningsgrunnlag i forhold til om lovens autorisasjonsording er egnet også for fremtiden eller om ordningen bør endres, justeres eller suppleres på noe punkt. Direktoratets vurdering om ovennevnte skal foreligge senest 21. januar Med hilsen (7 L ~ / Syi~øveRoald e.f. avdelingsdirektør YCL~kLLL Maiken Engeistad underdirektor Q~x~ Kopi: Helse Midt-Norge RI-IF Helse Nord RRF Kunnskapsdepartementet Sosial- og helsedirektoratet Haukelland universitetssykehus HF Eikelund Statped Vest Rikshospitalet-Radiumhospitalet HF Bredtvedt kompetansesenter Foreningen DiGiorge Syndrom Leppe-ganespalteforeningen Side5

136 DET KONGELIGE HELSE- OG OMSORGSDEPARTEMENT Kunnskapsdepartementet Postboks 8119 Dep 0032 OSLO Deres ref V~rei Dato S}{A/me Behandlingstilbudet til barn med leppe-kjeve-ganespalte og velofaciocardialt syndrom Helse- og omsorgsdepartenientet er opptatt av å sikre barn med leppe-kjeve-ganespalte et godt behandlingstilbud. Det behandles i dag ca 120 barn pr år med ulike typer leppekjeve- og/eller ganespalte i Norge. Det finnes mange ulike typer spalter, ofte kombinert med ulike syndromer. Behandlingen kjennetegnes ved at den er tverrfaglig og på.går over mange år der endelig resultat av behandlingen ikke kan måles før barna er voksne. Behandlingstilbudet til barn med leppe-kjeve-ganespalte er sentralisert til to steder i Norge, henholdsvis Rikshospitalet-Radiumho.spitalet HF/Bredtvedt kompetansesenter og Haukeland Universitetssykehus HF/Eikelund Statped Vest. Både i Oslo og i Bergen er det organisert spalteteam med ulik faglig kompetanse (plastikk-kirurgi, odontologi, øre-nese-hals, logopedi og psykologi) for å ivareta behandlingstilbudet. Med bakgrunn i at et fåtall familier liar søkt behandling i utlandet gnmnet misnøye med behandlingstilbudet i Norge. ga departementet Sosial- og helsedirektoratet i oppdrag i brev av 1.. juni 2006 å forestå en faglig og organisatorisk gjerinomgang av behandlingstilbudet til barn med leppe-kjeve-ganespalte. Rapporten Tilbudet til pasienter med ieppe-kjeve-ganespaite, herunder velocardiofacialt syndrom. Faglig gjennomgang ble avgitt av Sosial- og helsedirektoratet 22. august vedlegg til rapporten er (let en arbeiclsgrupperapport fra en internasjonalt sammensatt faggruppe som har gjennomgått det norske behandlingstilbu det (Elanderrapporten). Rapporten med vedlegg er tilgjengelig på: avj~sienterj~edleppe kjeve o Postadresse Kontoradresse Telefon* Saksbehandler Org. nr. - Telefaks

137 g_ganespalte Departementet viser videre til brev til hhv Helse Sør-øst RHF og Helse Vest RHF av 2. oktober 2007 om oppføliging av rapportens anbefalinger. Særskilt om logopeditjenesten Alvorlige språk- og talevansker gjør at pasienter med leppe-kjeve-ganespalte kan trenge bistand og behandling fra logoped gjennom barndom, oppvekst og i voksen alder. Personer med leppe-kjeve-ganespalite og vellopharyngeal insuffisiens har langvarige behov for logopedtjenester lokalt, som ledd i et individuelt planlagt tilbud i samarbeid med øvrig helsetjeneste. En eventuell rett til logopedihjelp for undersøkelse og behandling for språk- og taledefekter utledes av opplæringslovens alminnelige regler om spesialundervisning og spesiallpedágogisk hjelp i lovens kapittel 5. Dersom logöpedihjelp må anses sorñ et adekvat og nødvendig tiltak for at en elev skal få tilfredsstillende utbytte av oppilæringen i forhold til evner og forutsetninger vil dette kunne kreves fra kommunen eller fylkeskommunen. Tilsvarende vil gjelde for spesialpedagogisk hjelp i barnehagen, når dette er nødvendig for at barnet skal få en tilfredsstillende utvikling når det begynner i skolen. Rapporten fra Sosial- og helsedirektoratet peker på behov for bedre tilrettelegging og tilgang til lokal oppfølging av hørselsproblematikk og spesialpedagogisk bistand med logoped for denne pasientgruppen. Rapporten anbefaler videre at logopedifaget bør -~ styrkes i sin helsefaglige profil og tilknytning enten i grunnutdanningen eller som tilleggs- /videreutdanning, men at den spesialpedagogiske kompetansen fortsatt bør ligge til grunn. Sist peker rapporten på at det er behov for å sikre vitenskapelig dokumentasjon av behandlingsresultater innenfor logopedien. Det anbefales bl.a. at taleutvikling fra foreliggende materiale ved Bredtvet kompetansesenter evalueres. Eikelund Statped Vest og Bredtvet kompetansesenter inngår i statlig spesialpedagogisk støttesystem (statped) underlagt utdanningsdirektoratet. I tråd med dette, bervi Kunnskapsdepartementet om å foreta en vurdering av rapporten og behov for oppfølging av denne. Vi legger til grunn at Helse- og omsorgsdepartementet og helsetjenesten vil bli trukket inn i dette arbeidet. I tillegg ber vi om at Kunnskapsdepartementet vurderer om det er behov for en styrking av utdanningskapasiteten innenfor logopedifaget, jf ovennevnte påpekninger. Vi vil for øvrig vise til at Sosial- og helsedirektoratet er gitt i oppdrag å foreta en prinsipiell og overordnet vurdering av helsepersonellovens autorisasjonsordning. Hovedformålet med en slik vurdering skal være å gi departementet besllutningsgrunnlag i forhold til om lovens autorisasjonsording er egnet også for fremtiden eller om ordningen bør endres, justeres eller suppleres på noe punkt. Direktoratets vurdering skal foreligge senest 21. januar Side2

138 Departementet ber om en tilbakemelding fra Kunnskapsdepartementet på hvordan ovennevnte vil bli fulgt opp. Med hilsen cl ~ ~k Syn~nøveRoald e.f. avclelingsdirektør Kopi: Sosial- og helseairektoratet ~LLCL~ Maiken Engeistac underdirektor De regionale helseforetakene Bredtvedt kompetanse senter Eikelund Statped Vest Haukeland universitetssykehus HF Rikshospitalet-Radiurnhospitalet HF Leppe-ganespailteforeningen Foreningen DiGiorge syndrom Side 3

139

140 LKG registeret Budsjett 2013 Rapportering Konsulent It-arbeid 20 % stilling Forskning Å leve med leppe- ganespalte Samarbeidsmøter bergen Oslo Forberedelser presentasjon i Orlando Prenatal diagnostikk Prosjektstilling lege fra % stilling. Kobling MFR Informasjonsskriv pasientgruppen Samarbeidsmøter Oslo Bergen, evnt Trh Møter og kongresser Cleft 2013 Orlando Reise, opphold, avgift ÅR & ÅS Seminar Geilo november 2013 Velkomst 3000 Frukt 2 pauser 3000 Foredragsholder 8000 Reise og opphold 2 pers Oppfølging Osloteamet Opphold & reise 1-2 pers x Middag 10 pers x Studietur LKG register Sverige og Danmark 4 pers Websiden og informasjonsbrosjyren It-konsulent 5 mndr 20 % stilling ÅS

141 LKG registeret Forventede kostnader okt, nov, des -12 Lønn ÅS, ved feil ikke utbetalt etter juni-12 20% stilling Rapportering Diagnosekoding pasienter Bergen 500 pasienter (Rolf Tindlund+ sekretær) Oslo 1000 pasienter (Stein Groth) Konsulent It-arbeid Truc Ngyen fra % stilling Forskning Å leve med leppe- ganespalte Kobling v/ssb Porto infoskriv Prosjekt PC Diverse kontorarbeid 40 t Noe reiser/møter mellom teamene Seminar Dagspakke sykehotellet deltagere ca Middag kveld 4.10., ca 12 pers ca Evnt reiseutgifter Joyshna ca.. Evnt boutgifter Joyshna Fordrag Joyshna Foredrag A Fordrag Jugessur Oppfølging Osloteamet, november Opphold & reise ÅR ca Middag 10 pers ca Informasjonsbrosyren Oversettelse til engelsk ca Trykk ca Web-siden It-konsulent fra % stilling ÅS

142 Risikovurdering Fortrolig Risikovurdering av Medisinsk Registreringssystem HEMIT juni 2009 Risikovurderingen er gjennomført i samarbeid med Risikovurdering MRS _LKG registeret.doc side 1 av 15

143 Risikovurdering Fortrolig Innhold 1 BAKGRUNN FOR RISIKOVURDERINGEN OMFANG KONKLUSJON OG SAMMENDRAG KONKLUSJON SAMMENDRAG GJENNOMFØRING AV RISIKOVURDERINGEN AKTIVITETER OG TIDSPLAN METODIKK DELTAGERE NIVÅ FOR AKSEPTABEL RISIKO RISIKOMATRISE MRS SCENARIOLISTE...13 Dokumentinformasjon: Utskriftsdato: 12. november 2009 Skrevet av: Jan Henriksen, INFOSEC Norge AS Tittel: Risikovurdering av Medisinsk Registreringssystem Datamedia: Hele rapporten er tilgjengelig i MS-Word Dok-id: Risikovurdering MRS _LKG registeret.doc Risikovurdering MRS _LKG registeret.doc side 2 av 15

144 Risikovurdering Fortrolig 1 BAKGRUNN FOR RISIKOVURDERINGEN Helseregion Midt-Norge har tatt i bruk ny versjon av Medisinsk Registreringssystem (MRS). MRS benyttes av alle HF i regionen, men skal på sikt etableres som en nasjonal løsning for kvalitetsregistre. Risikovurderingen er gjennomført for å påse at løsningen er innefor krav til informasjonssikkerhet fastsatt i Norm for informasjonssikkerhet i helsesektoren og Informasjonssikkerhet overordnet strategi og målsettinger, Helse Midt-Norge, OMFANG Risikovurderingen dekker - Applikasjonen MRS og enkelte forhold vedrørende teknisk løsning (denne er per dato ikke etablert for nasjonale registre) Se scenarioliste i kapittel 7 som viser hvilke scenarioer som er vurdert. Scenarioer merket med prioritet 2 er ikke vurdert fordi MRS har funksjonalitet og løsninger som ivaretar kravene til informasjonssikkerhet og personvern. 3 KONKLUSJON OG SAMMENDRAG 3.1 Konklusjon Risikovurderingen har identifisert en rekke tiltak som må gjennomføres for å bringe risikoen ned på et akseptabelt nivå. Se pkt 3.2 for forslag til tiltak. Det anbefales at det gjennomføres en egen risikovurdering av teknisk løsning for nasjonal løsning for kvalitetsregistre. 3.2 Sammendrag Risikovurderingen har identifisert følgende forslag til tiltak (aktiviteter): Nr Tiltak som foreslås gjennomført (referanse til kapittel 6 Risikomatrise) Risiko 1. Etablere loggføring av forsøk på uautorisert tilgang (1.1) 8 2. Følge opp arbeidet med drift med å begrense antall brukere i HEMIT som har adminrettigheter og tilgang til MRS (1.3) 4 3. Dokumentere eksisterende logger i MRS (1.4) 8 4. Etablere et sett med rapporter i MRS som dekker analyse av logger (1.4) 8 5. Etablere krav til passord ved bruk av brukernavn og passord i MRS (minimum 8 tegn, kombinasjon av alfanummerisk og spesialtegn, 4 bytte hver 90 dag, ikke mulig med passordrotasjon) (1.5) 6. Etablere selvstendig autentisering til hver enkelt rolle. Gjøres ved at 8 Ansvar Risikovurdering MRS _LKG registeret.doc side 3 av 15

145 Risikovurdering Fortrolig Nr Tiltak som foreslås gjennomført (referanse til kapittel 6 Risikomatrise) Risiko bruker må registrere brukernavn og passord på nytt (1.6, 1.7) 7. Etablere ulik autentisering til ansettelsesforhold i forskjellige HF (1.7) 8 8. Bruke folkeregisteret i Norsk Helsenett som kilde for pasientopplysninger (kun demografiske data) i MRS (1.8) 6 9. Endre eksisterende felt for fødselsnr til kun fødselsdato for bruker (1.9) Etablere funksjonell løsning som krever at passord for adminbruker byttes ved første gangs bruk av adminbruker (1.10) Sjekke hva som loggføres for adminbruker (1.11) Etablere nødvendig loggføring av adminbruker (1.11) Automatisere installasjon av MRS slik at driftspersonell ikke trenger å konfigurere systemet (1.12) Fjerne kryptering av database i MRS (1.13) 8 Ansvar Nr Tiltak som gjennomføres i den videre utvikling av MRS Ansvar 15. Etablere loggføring av utskrifter når utskrifter som identifiserer enkeltpersoner må loggføring gjøres tilgjengelig i MRS 16. Etablere funksjonell løsning slik at hele eller deler av informasjonen i MRS kan sperres for enkeltpersoner 17. Etablere løsning for faktisk makulering (fjerning) av registrert pasient i MRS. Dette kan også løses ved beskrivelse av hvordan dette skal gjøres med bistand fra personell i HEMIT (databehandler) som har nødvendige rettigheter til databasen. 18. Etablere løsning for avidentifisering som oppfyller kravet slik at opplysningene ikke lenger kan knyttes til en enkeltperson, og hvor identitet bare kan tilbakeføres ved sammenstilling med de samme opplysninger som tidligere ble fjernet. Jf helseregisterloven 2. Det er for eksempel mulig å identifisere enkeltpersoner med unik diagnose i små kommuner. 19. Etablere løsning for pseudonymisering som oppfyller kravet helseopplysninger der identitet er kryptert eller skjult på annet vis, men likevel individualisert slik at det lar seg gjøre å følge hver person gjennom helsesystemet uten at identiteten røpes. Jf helseregisterloven Etablere sterk autentisering av eksterne brukere (i realiteten alle brukere) av MRS. Med sterk autentisering menes en kombinasjon av noe brukeren vet (passord) og noe brukeren har fysisk (passordkalkulator, Smartkort, etc). Nr Tiltak som vurderes ved bredding av MRS Ansvar 21. Etablere databehandleravtale mellom RHF som databehandlingsansvarlig og det enkelte HF som blir databehandler for RHF når HF ikke har egen bruk av MRS. Forholdet oppstår når HF kun plukker ut data for overføring til nasjonalt register. 22. Etablere sikker løsning for overføring av data fra lokal til nasjonal MRS. Ved forsendelse av lagringsmedia skal rekommandert post benyttes. Ved bruk av e-post eller registrering over Internett skal PKI benyttes for å identifisere rett avsender og mottaker. Risikovurdering MRS _LKG registeret.doc side 4 av 15

146 Risikovurdering Fortrolig 4 GJENNOMFØRING AV RISIKOVURDERINGEN 4.1 Aktiviteter og tidsplan Risikovurderingen er gjennomført med følgende aktiviteter og tidsplan 1. Utarbeide scenarioliste 26. og 27. juni Møte risikovurdering 1. juli Utarbeide utkast til rapport 2. og 3. juni Sendt utkast for kommentarer 3. juni Innarbeidet kommentarer Ingen kommentarer mottatt. 6. Utarbeidet endelig rapport 11. juni Metodikk Risikovurderingen er gjennomført iht metodikken som benyttes i helseregionen og som er anbefalt i Norm for informasjonssikkerhet i helsesektoren (ref Faktaark 7 Risikovurderinger). Tabellene i kapittel 6 Risikomatrise inneholder alle forhold som er vurdert. Kolonnen merket med Scenario og mulige årsaker inneholder hypotetiske situasjoner og eksisterende svakheter. Sannsynligheten for at en observasjonen eller svakheten inntreffer er fastsatt etter at eksisterende tiltak er hensyntatt. Likeledes er konsekvensen av et scenario, beskrevet i kolonnen Mulige konsekvenser, fastsatt etter at eksisterende tiltak er hensyntatt. Et scenario kan således få lav sannsynlighet (verdi 1) og lav konsekvens (verdi 1) fordi eksisterende tiltak reduserer både sannsynligheten for at hendelsen inntreffer og konsekvensen om den inntreffer. 4.3 Deltagere Følgende personer har deltatt i arbeidsgruppen: Navn Funksjon Virksomhet Øivind Hepsø Utvikler HEMIT Rudi Bech Utvikler HEMIT Randi Skogseth-Stephani Bruker St Olav avd hjerneslag Hild Fjærtoft Registeransvarlig/prosjektleder St Olav avd hjerneslag Margareth Von Ibenfeldt Spesialfunksjoner St Olav avd hjerneslag Eva Svarva Prosjektleder HEMIT Jan Henriksen Konsulent INFOSEC Risikovurdering MRS _LKG registeret.doc side 5 av 15

147 Risikovurdering Fortrolig 5 NIVÅ FOR AKSEPTABEL RISIKO Mål og strategi for informasjonssikkerhet og nivå for akseptabel risiko er hentet fra dokumentet: Informasjonssikkerhet overordnet strategi og målsettinger, Helse Midt-Norge, Med kritiske systemer menes: Systemer som anvendes i diagnostikk, behandling eller pleie og hvor tapt tilgang gir økt risiko for at tjenesten enten ikke ytes eller må ytes med redusert kvalitet, førende til økt risiko for feilbehandling. Tilgjengelighet Indikator Antall tilgjengelighetsbrudd på systemer hvor det behandles kritiske personopplysninger. Tilgjengelighetsbrudd omfatter også responstid ut over angitt krav. Nedetid på systemer hvor det behandles kritiske personopplysninger. Det skilles mellom planlagt og ikke-planlagt nedetid Antall tilfeller hvor det har oppstått personskader eller fare for personskade grunnet tilgjengelighetsbrudd Akseptkriterier Ikke-planlagte avbrudd Antall ikke-planlagte avbrudd i kritiske systemer skal ikke overstige 1 pr. måned og ikke mer enn tre ganger pr. år i det enkelte system. Avbruddets varighet skal ikke overstige 15 minutter i tidsrommet mandag fredag og 1 time i tidsrommet hverdager og i helger (målt hos bruker). Planlagte avbrudd Antall planlagte avbrudd i kritiske systemer skal gjennomføres i avtalt servicevindu og ikke overstige 1 pr. måned. Avbruddets varighet skal ikke overstige 4 timer og gjøres i tidsrommet (målt hos bruker). Planlagte avbrudd i de enkelte kritiske systemer ut over 4 timer pr. måned (målt hos bruker) skal ikke overstige 2 pr år. Utover dette skal det avtales i hvert enkelt tilfelle. Varsling til bruker ved planlagt avbrudd i kritiske systemer skal skje minimum 14 dager på forhånd. Responstid Responstid skal ikke overstige definerte krav for kritiske system. Krav til responstid skal nedfelles i avtaleverket for hver enkelt applikasjon. Responstid som overskrider definerte krav, defineres som uplanlagt nedetid Feilbehandling Feilbehandling eller fare for feilbehandling av pasienter som følge av utilgjengelige helseopplysninger skal ikke forekomme - null-toleranse Risikovurdering MRS _LKG registeret.doc side 6 av 15

148 Risikovurdering Fortrolig 6 RISIKOMATRISE Forklaring til koder Sannsynlighet: (Angitt som antall per år) 1 Usannsynlig Hendelsen inntreffer 1 gang per 5. år eller sjeldnere 2 Mindre sannsynlig Hendelsen inntreffer årlig 3 Mulig Hendelsen inntreffer månedlig 4 Sannsynlig Hendelsen inntreffer en gang i uken eller oftere Konsekvens: (Angitt for Tilgjengelighet, Konfidensialitet, Integritet/kvalitet) Konsekvens: (Angitt for Tilgjengelighet, Konfidensialitet, Integritet/kvalitet) Hentet fra TrinnVis ( 1 Ubetydelig / Ingen Stans i <system> i en time Ingen uautorisert innsyn i personopplysninger MRS er komplett Ikke fare for pasienters helse Intet brudd på personvernet Ubetydelig økonomisk tap Intet tap av renommé eller rykte 2 Moderat Stans i <system> inntil 1 dag Uautorisert innsyn i enkelte personopplysninger og lovbrudd Noen mangler eller feil i MRS Ikke fare for pasienters helse Brudd på personvernet for et lite antall pasienter Gjenopprettelig økonomisk tap Moderat tap av renommé eller rykte 3 Alvorlig Stans i <system> inntil 3 dager Uautorisert innsyn i enkelte personopplysninger, mulighet for endring og brudd på lov Viktige mangler eller feil i MRS Fare for pasienters helse og liv ved feilbehandling eller mangelfull behandling Brudd på personvernet for et stort antall pasienter Alvorlig økonomisk tap Alvorlig tap av renommé eller rykte 4 Kritisk Stans i <system> inntil 7 dager Fullt uautorisert innsyn i eller mulighet for endring av alle personopplysninger og brudd på lov Kritiske mangler eller feil i MRS Tap av liv på grunn av feilbehandling eller mangelfull behandling Brudd på personvernet for et stort antall (alle) pasienter Uopprettelig økonomisk tap Brudd på krav til: K = Konfidensialitet I/Kv = Integritet T = Tilgjengelighet Risiko = S x Ko Risiko >= 4 krever vurdering av tiltak. For hendelser som kan medføre fare for pasientene liv og helse skal det uavhengig av risiko iverksettes tiltak. Konsekvens og Risiko som kan medføre fare for pasientene liv og helse er tydeliggjort i kolonnen merket Mulige konsekvenser i tabellen under. Forkortelser og forklaringer SP = Sensitive personopplysninger (helse og pasientopplysninger) POL = Personopplysningsloven POF = Personopplysningsforskriften (spesielt forskrift til 13 Informasjonssikkerhet) HRL = Helseregisterloven DT = Datatilsynet Risikovurdering MRS _LKG registeret.doc Side 7 av 15

149 Risikovurdering Fortrolig Sannsynligheten for at en observasjonen eller svakheten inntreffer er fastsatt etter at eksisterende tiltak er hensyntatt. Likeledes er konsekvensen av en observasjon eller svakhet, beskrevet i kolonnen Mulige konsekvenser, fastsatt etter at eksisterende tiltak er hensyntatt. En observasjon eller svakhet kan således få lav sannsynlighet (verdi 1) og lav konsekvens (verdi 1) fordi eksisterende tiltak reduserer både sannsynligheten for at hendelsen inntreffer og konsekvensen om den inntreffer. Risikovurdering MRS _LKG registeret.doc Side 8 av 15

150 Risikovurdering Fortrolig 6.1 MRS Nr K,I T,Kv 1.1 K,I 1.2 K 1.3 K, I 1.4 K, I Scenario og mulige årsaker S Ko Forsøk på uautorisert tilgang (funksjoner bruker ikke har tilgang til) blir ikke loggført Utskrifter blir ikke loggført Gjelder både visning på skjerm og utskrift på skriver. Logger er ikke beskyttet for tilgang fra uautoriserte Svak eller manglende analyse av logger R (SxKo) Mulige konsekvenser Eksisterende og forslag til nye tiltak Brudd på krav i Normen Eksisterende tiltak: - Ingen Foreslåtte tiltak: - Etablere loggføring av forsøk på uautorisert tilgang Ingen Eksisterende tiltak: - Loggføring av innlogging i valgt rolle - Ingen rapporter identifiserer enkeltpersoner, men er kun på aggregert nivå med statistikk og fordelinger Foreslåtte tiltak: - Etablere loggføring av utskrifter når utskrifter som identifiserer enkeltpersoner må loggføring gjøres tilgjengelig i MRS (tiltak type 3) Uustorisert innsyn i MRS Uautorisert endring, sletting Eksisterende tiltak: - Alle som har administrator domenerettigheter har tilgang til MRS db - HEMIT har igangsatt arbeid med å begrense hvem som har tilgang til MRS Foreslåtte tiltak: - Følge opp arbeidet med drift med å begrense antall brukere i HEMIT som har adminrettigheter og tilgang til MRS Brudd på krav i Normen Eksisterende tiltak: - Ingen Foreslåtte tiltak: - Dokumentere eksisterende logger i MRS - Etablere et sett med rapporter i MRS som dekker analyse av logger Risikovurdering MRS _LKG registeret.doc Side 9 av 15

151 Risikovurdering Fortrolig 6.1 MRS Nr K,I T,Kv 1.5 K, I 1.6 K, I 1.7 K, I Scenario og mulige årsaker S Ko R (SxKo) Svak passordkvalitet ift minimums lengde, krav om bruk av alfanumeriske tegn, krav til passordbytte, ikke mulig med passordrotasjon Autentisering skjer ikke selvstendig for hver enkelt rolle Ulike ansettelsesforhold (samme person kan ha ulike roller innenfor samme virksomhet) identifiseres ikke og det er ikke ulike autentiseringskriteria Mulige konsekvenser Uautorisert tilgang (innsyn, endring, sletting) Brudd på krav i Normen Eksisterende og forslag til nye tiltak Eksisterende tiltak: - God passordkvalitet ved pålogging via AD (i motsetning til ved bruk av brukernavn og passord i MRS hvor det ikke er krav til passord i det hele tatt) Foreslåtte tiltak: - Etablere krav til passord ved bruk av brukernavn og passord i MRS (minimum 8 tegn, kombinasjon av alfanummerisk og spesialtegn, bytte hver 90 dag, ikke mulig med passordrotasjon) Brudd på krav i Normen Eksisterende tiltak: - Autentisering av brukeren (brukernavn og passord eller via AD). Denne initielle autentiseringen gir tilgang til alle rollene brukeren er tildelt - Loggføring gjøres ift den aktive rollen Foreslåtte tiltak: - Etablere selvstendig autentisering til hver enkelt rolle. Gjøres ved at bruker må registrere brukernavn og passord på nytt Brudd på krav i Normen Eksisterende tiltak: - Bruker autentiseres for ett HF - Bruker må bytte profil for å få tilgang til annet HF, men må ikke autentiseres på nytt Foreslåtte tiltak: - Etablere selvstendig autentisering til hvert ansettelsesforhold i samme HF. Gjøres ved at bruker må registrere brukernavn og passord på nytt - Etablere ulik autentisering til ansettelsesforhold i forskjellige HF Risikovurdering MRS _LKG registeret.doc Side 10 av 15

152 Risikovurdering Fortrolig 6.1 MRS Nr K,I T,Kv 1.8 I 1.9 K 1.10 K, I, T 1.11 K, I 1.12 K, I, T Scenario og mulige årsaker S Ko Bruker feilregistrerer pasientopplysninger (kun demografiske data) i MRS egne intern db Bruker registreres med 11- siffret fødselsnr Adminbruker endrer ikke standard brukernavn og passord (Admin/Admin) Bruk av adminbruker loggføres ikke MRS feilkonfigureres R (SxKo) Mulige konsekvenser Feil i statistikk Feil i pasientopplysninger Feil i systemer MRS skal avgi data til Unødvendig bruk av fødselsnr iht POL 12 Eksisterende og forslag til nye tiltak Eksisterende tiltak: - Ikke mulig med feilregistrering ved bruk av HIS 90 PasProvider Foreslåtte tiltak: - Bruke folkeregisteret i Norsk Helsenett som kilde for pasientopplysninger (kun demografiske data) i MRS Eksisterende tiltak: - Ingen Foreslåtte tiltak: - Endre eksisterende felt for fødselsnr til kun fødselsdato for bruker Uautorisert tilgang Eksisterende tiltak: - Diftsdokumentasjon for MRS anbefaler at passord endres Foreslåtte tiltak: - Etablere funksjonell løsning som krever at passord for adminbruker byttes ved første gangs bruk av adminbruker Brudd på krav i Normen Eksisterende tiltak: - Usikkert om det er loggføring av MRS adminbruker Foreslåtte tiltak: - Sjekke hva som loggføres for adminbruker - Etablere nødvendig loggføring av adminbruker Sikkerhetsmekanismer blir deaktivert Uautorisert tilgang Plunder og heft Stans i MRS Ikke tilgang til MRS Eksisterende tiltak: - Driftsdokumentasjon med installasjonsveiledning - Verktøy for installasjon av MRS Foreslåtte tiltak: - Automatisere installasjon av MRS slik at driftspersonell ikke trenger å konfigurere systemet Risikovurdering MRS _LKG registeret.doc Side 11 av 15

153 Risikovurdering Fortrolig 6.1 MRS Nr K,I T,Kv 1.13 T Scenario og mulige årsaker S Ko Det er uklart om det er behov for å kryptere db i MRS R (SxKo) Mulige konsekvenser Fare for at driftspersonell ikke tar vare på krypteringsnøkkelen som benyttes ved installasjon av MRS Ikke mulig med flytting eller restore av database Tap av data Eksisterende og forslag til nye tiltak Eksisterende tiltak: - Beslutning om kryptering av database er ikke kjent for personellet som har ansvaret for utvikling av MRS - MRS driftes i sikker sone i helseregionen som skal være tilstrekkelig sikring - Bruker er kun autorisert for sine data ift HF, avdeling, osv - Brukers rettigheter styres ift gitte roller Foreslåtte tiltak: - Fjerne kryptering av database i MRS Risikovurdering MRS _LKG registeret.doc Side 12 av 15

154 Risikovurdering Fortrolig 7 SCENARIOLISTE Prioritet: 1 = Må vurderes 2 = Ikke nødvendig å vurdere pga status på eksisterende tiltak eller scenario har liten betydning Scenarioliste Prioritet: 1 = Må vurderes 2 = Ikke nødvendig å vurdere pga status på eksisterende tiltak eller scenario har liten betydning 3 = Funksjonalitet må utvikles 4 = Tiltak tas opp ved bredding av MRS Nr MRS - scenario applikasjon Prioritet Vurdert 1. Stans i MRS inntil 3 minutter (mange ulike årsaker, server, 2 kommunikasjon, trådløst nettverk, osv) 2. Ikke planlagt stans i MRS inntil 10 minutter 2 3. Stans i MRS inntil 1 time 2 4. Autorisert innlogging blir ikke loggført 2 5. Autorisert innsyn/oppslag blir ikke loggført 2 6. Autorisert registrering/endring blir ikke loggført 2 7. Autorisert retting blir ikke loggført 2 8. Autorisert sletting blir ikke loggført 2 9. Utskrifter blir ikke loggført 1 X 10. Forsøk på uautorisert tilgang (funksjoner bruker ikke har tilgang 1 X til) blir ikke loggført 11. Opplysninger kan endres uten at det registreres hvem som har 2 endret og hva som er endret (før- og etterverdier) 12. Opplysninger føres ikke i henhold til standard kodeverk LoggProvider er ikke aktivert Logger har ikke korrekt tidsstempel Logger oppbevares ikke minimum 3 måneder Logger er ikke beskyttet for tilgang fra uautoriserte 1 X 17. Svak eller manglende analyse av logger 1 X 18. Svak eller manglende autorisasjon av brukere i ulike roller Systemet støtter ikke muligheten for å ivareta innsynsretten, 3 sletting og sperring av hele/deler av journalen / informasjonen 20. Ikke mulig og faktisk fjerne informasjon om en pasient 3 (makulering i db) 21. Passordfil er ikke kryptert Tildelt autorisasjon kan ikke tidsavgrenses Svak passordkvalitet ift minimums lengde, krav om bruk av 1 X alfanumeriske tegn, krav til passordbytte, ikke mulig med passordrotasjon 24. Autentisering skjer ikke selvstendig for hver enkelt rolle 1 X Risikovurdering MRS _LKG registeret.doc Side 13 av 15

155 Risikovurdering Fortrolig Nr MRS - scenario applikasjon Prioritet Vurdert 25. Autentisering av bruker sikrer ikke identifisering i korrekt rolle i Se 24 hvert enkelt tilfelle 26. Ulike ansettelsesforhold (samme person kan ha ulike roller 1 X innenfor samme virksomhet) identifiseres ikke og det er ikke ulike autentiseringskriteria 27. Bruker av nasjonalt register (MRS) har tilgang til identifiserbare 2 opplysninger fra flere HF (i samme MRS-db) 28. Det er ikke mulig å kontrollere tildelte autorisasjoner Avidentifisering er ikke tilstrekkelig ift kravet slik at 3 opplysningene ikke lenger kan knyttes til en enkeltperson, og hvor identitet bare kan tilbakeføres ved sammenstilling med de samme opplysninger som tidligere ble fjernet. Jf helseregisterloven 2 (kommune er bl.a. i bruk i systemet) 30. Pseudonymisering er ikke tilstrekkelig ift kravet 3 helseopplysninger der identitet er kryptert eller skjult på annet vis, men likevel individualisert slik at det lar seg gjøre å følge hver person gjennom helsesystemet uten at identiteten røpes. Jf helseregisterloven Stans i PasLink WebServices Feil i PasLink WebServices Intern pasientdatabase er ikke kryptert med tilstrekkelig 2 krypteringsstyrke 34. Bruker feilregistrerer pasientopplysninger i MRS egne intern db 1 X 35. Parametre for konfigurasjon settes feil. For eksempel: 2 - RedigerbareParametere - TillatRedigering - TillatSletting - SlettPasient 36. Valideringsregler blir ikke satt til å kjøre Ved bruk av forms autentisering er det ikke pålogget bruker som 2 autentiseres (men systembrukeren) 38. Vurdere scenario over ift loggføring av innsyn/oppslag, 2 registrering, endring, sletting 39. Bruker registreres med 11-siffret fødselsnr 1 X 40. Tildelte autorisasjoner oppbevares ikke i minimum 5 år Lenker fra MRS gir tilgang til eksterne nett (usikre nett). Ikke 2 relevant for MRS, men har med konfigurasjon av teknisk løsning/nettverk 42. Adminbruker endrer ikke standard brukernavn og passord 1 X (Admin/Admin) 43. Bruk av adminbruker loggføres ikke 1 X 44. Utskrift er ikke kryptert 2 Nr MRS - scenario databehandlingsansvarlig Prioritet Vurdert 45. Det er ikke opprettet databehandleravtale mellom RHF og HF. HF 4 bruk av MRS er ikke i egen interesse, men kun som verktøy for å avgi data til nasjonalt register. 46. MRS er ikke underlagt konfigurasjonsstyring (oppsett, endringer, oppdateringer) 2 Risikovurdering MRS _LKG registeret.doc Side 14 av 15

156 Risikovurdering Fortrolig Nr MRS - scenario databehandlingsansvarlig Prioritet Vurdert 47. Forsendelse av data fra lokal MRS til nasjonalt register er ikke 4 sikret (rekommandert post, PKI ved e-post og Internettbruk for sikker identifikasjon av mottaker og avsender) 48. Behandling av identifiserbare data i nasjonalt register er ikke skilt per HF 2 Nr MRS - scenario teknisk løsning Prioritet Vurdert 49. Ekstern kommunikasjon for MRS er ikke kryptert 2 (Webapplikasjon) 50. Trafikk mellom web-, app- (tjeneste) og datalag er ikke kryptert 2 (avhenger av hvordan løsningen er installert og tilgjengeliggjort for eksterne brukere) 51. Webapplikasjon har direkte tilgang til db Webtjenestekall er ikke kryptert med SSL Nøkkel for kryptering av database blir ikke tatt vare på 1 X Det er uklart om det er behov for å kryptere db i MRS? 54. I produksjonsoppsett av MRS er security_enabled = fasle AuthorizationProvider er i produksjonsoppsett satt til simple, slipp 2 gjennom alt 56. Ikke sterk autentisering av ekstern bruker MRS feilkonfigureres 1 X Risikovurdering MRS _LKG registeret.doc Side 15 av 15

157 Versjon: 1.0 Systemdok MRS 2.0 Systemdokumentasjon for Medisinske Registreringssystem (MRS) Helse Midt-Norge

158 Revisjonshistorie Dato Versjon Beskrivelse Forfatter Initiell Mats Pettersen Revisjon ifm HIS90PasientProviderTrustedSubSyste m Rudi Bech -2-

159 Innhold 1. INNLEDNING FORMÅL RELATERTE DOKUMENTER OPPSUMMERING OVERORDNET BESKRIVELSE AV MRS VIRKEMÅTE OG TEKNOLOGI ARKITEKTUR Driftsaarkitektur Programvarearkitektur PROVIDERE OG INTEGRASJONSPUNKTER Loggeprovider Autorisasjonsprovider Rolleprovider Brukerprovider Organisasjonsprovider Pasientprovider Prosesslaget som provider TILGANGSKONTROLL Bruker, identitet og tilgangsprofil Roller i systemet AVIDENTIFISERING/ANONYMISERING AV DATA DATAINNSAMLING OG SIKRING AV DATAKVALITET Validering av data Ferdigstilling/lukking av skjema Kontrollscript DATABASE OG OBJEKTMODELL SKILLE MELLOM PRESENTASJON, DEFINISJON OG DATALAGRING SKJEMA OG UTFORMING Underskjema og relaterte skjema Databseelementer: Skjema og utforming DEFINISJON AV DATASETTTYPE CopyParent og CopyRelated Databseelementer: Definisjon av DataSettType LAGRING AV DATA OG KOBLING MOT PASIENT Datasett Kobling av datasett mot pasient Databseelementer: Lagring av data og kobling mot pasient LOGGING Databaseelementer: Logging OPPSETT AV MRS INSTANS Databaseelementer: Oppsett av MRS Instans RAMMEVERK FOR UTVIKLING KRAV TIL UTVIKLINGSMILJØ AUTOMATISK BYGGING SOURCESAFE TESTSERVERE MRS-BuildServer MRS-DCTest MRS-DCAlfa MRS-DCBeta

160 5.4.5 MRS-FAT Web Server MRS-FAT App Server MRS-FAT Database Server MRS-Test Klient 1, 2 og Utvidelse av testoppsettet RETNINGSLINJER FOR UTVIKLING KILDEKODESTANDARD Ordliste Navngiving Kommentarer FEILHÅNDTERING ENHETSTESTING Eksempel Sammenligning Tilstand Unntak RETNINGSLINJER FOR BRUK AV SOURCESAFE VERSJONERING TILLEGG A: MICROSOFT ENTERPRISE LIBRARY A.1 CACHING APPLICATION BLOCK A.2 CONFIGURATION APPLICATION BLOCK A.3 DATA ACCESS APPLICATION BLOCK A.4 CRYPTOGRAPHY APPLICATION BLOCK A.5 EXCEPTION HANDLING APPLICATION BLOCK A.6 LOGGING AND INSTRUMENTATION APPLICATION BLOCK A.7 SECURITY APPLICATION BLOCK

161 1. Innledning 1.1 Formål Dette dokumentet skal gi en overordnet beskrivelse av MRS og gi en forståelse av hvordan systemet fungerer. Dokumentet er ment for systemadministratorer, arkitekter, testere og utviklere av MRS. Dokumentet er levende, og skal reflektere det faktiske systemet. 1.2 Relaterte dokumenter HEMIT IT-strategi HEMIT Arkitekturstrategi 1.3 Oppsummering Vi har i dette dokumentet gitt en overordnet beskrivelse av MRS og hvilket miljø systemet forekommer i. Vi har beskrevet virkemåte og teknologi via arkitekturbeskrivelse, beskrivelse av integrasjon og grensesnitt mot andre systemer, tilgangskontroll og til slutt en beskrivelse av systemets database. -5-

162 2. Overordnet beskrivelse av MRS MRS - Medisinsk Registreringssystem er et egenutviklet webbasert system for registrering og rapportering av ulike medisinske parametre og klinsk data på individnivå. Systemet er i utgangspunktet utviklet for å tilfredstille kravene til et medisinsk kvalitetsregister hvor innhenting og analysering av strukturerte kliniske data står sterkt i fokus. Dette innbærer f.eks. innhenting og bearbeiding av opplysninger på individnivå om diagnoser, behandlingstiltak og behandlingsresultat. Det kan være resultater i forhold til en bestemt behandlingsmetode, et bestemt behandlingsopplegg, behandling av en bestemt sykdom eller gruppe av sykdommer og der opplysningene er basert på valgte indikatorer eller andre opplysninger som forteller noe om kvaliteten. Systemet skal med dette i første rekke sikre og utvikle kvaliteten på den kliniske behandlingen innen de enkelte fagområder på tvers av sykehus og forvaltningsnivåer. Det skal med andre ord bidra til å dokumentere effekten av behandlingsmetoder og behandlingsprosedyrer, slik at alle pasienter innen det fagområde eller sykdomsgruppe registeret gjelder for skal få en behandling som er effektiv og i samsvar med god praksis. Figur 1-6-

163 Figuren over viser et eksempel på sammenhengen MRS kan inngå i som en del av både behandlings- og forskningsprosessen. Som vi ser inngår MRS (register) som en del av flere systemer en registrerer i i løpet av behandlingsprosessen, og ofte er det allerede gjort flere registreringer i andre systemer før en registrerer i registeret. Fra det lokale registeret kan det så gjøres uttrekk (og avidentifisering/pseudonymisering) av registerdata til et eventuelt nasjonalt register. Herfra kan en sammenstille data for analyse, generere rapporter, skrive ut sammendrag og oversikter til pasienten eller for eksempel eksportere data for statistikk, anvendt klinisk forskning o.l. Selve forskningsprosessen er vist nederst i figuren, og her inngår de fire hovedaktivitetene planlegging, datasamling, analyse og publikasjon. Naturlig nok vil det være i analysefasen at informasjon fra kvalitetsregisteret er mest aktuelt, men det kan også være aktuelt at en i forkant (planleggingsfasen) må gjøre endringer i registeret og f.eks. definere nye parametre en ønsker å registrere/forske på. Dette fører til at systemet (registeret) vil være under mer eller mindre konstant endring i forhold til hva en registrerer. Det har derfor vært viktig å kunne utvikle et system som takler dette på en enkel måte, uten at ny utvikling må gjøres for hver gang det skjer en endring i f.eks. et skjema eller en rapport. -7-

164 3. Virkemåte og teknologi MRS er et generisk system som er utviklet etter Helse Midt-Norges arkitektur- og integrasjonsstrategi. Systemet består av en webapplikasjon, med tilhørende webtjenster og MSSQL 2005 database i bunnen. Systemet er utviklet for å kunne bli installert i flere instanser (f.eks. MRS Norsk Hjerteinfarktregister og MRS Norsk Hjerneslagregister) med lik funksjonalitet men med ulik konfigurasjon for hver instans. Det eneste som må lages nytt pr. instans er ny logo og evt. andre grafiske elementer. Resten er konfigurasjon, og parametre, skjema, validering, kontrollskript o.l. defineres kun opp via XML. Rapporter utvikles i Reporting Services, og nye rapporter kan legges til eller fjernes etter behov. Innenfor en instans av applikasjonen kan en tildele brukere ulik tilgang ved å gi dem ulike roller i systemet, og data kan filtreres ut fra hvor brukeren er ansatt. 3.1 Arkitektur MRS er som nevnt over utviklet med støtte for å fungere i en tjenestebasert virksomhetsarkitektur (Serviece Oriented Architecture SOA ). Dvs at alle funkjoner MRS bruker også er implementert via et tjenestelag. Systemet er også designet for å kunne ta i bruk andre utenforliggende tjenester som tilbys via arkitekturen. Figuren nedenfor viser hvordan MRS er realisert i henhold til en slik modell. MRS UI Felles informasjonsmodell Sikkerhet, logg, kommunikasjon WS MRS Prosess PAS Service Bus WS WS UserInfo Basis WSE SOAP HTTP TCP/IP Figur 2-8-

165 Figuren skisserer en typisk virksomhetsarkitektur, og hvordan koblingene mot tjenester er realisert ved hjelp av en såkalt web service bus. Dette konseptet er et anerkjent bilde på en teknisk arkitektur basert på web services. Web Service Bus er ikke et produkt, men mer en infrastruktur som inneholder kommunikasjonsprotokoller. Over denne bus en tilgjengeliggjør MRS sine tjenester, slik at andre applikasjoner kan konsumere denne, og samtidig tar MRS i bruk andre forretningstjenester; for eksempel uthenting av pasientinformsjon fra PAS (Pasientadministrativt system) Driftsaarkitektur Med driftsarkitektur mener vi det fysiske driftsmiljøet MRS 2.0 kan kjøres i. Dette er enten en fysisk lagdelt arkitektur fordelt over tre lag; web-, app- (tjeneste) og datalag, eller en todelt lagstruktur med en web- og en databaseserver. I figuren under vises hvordan MRS er delt opp på de ulike lagene. WebServer MRS Webapplikasjon AppServer Webtjeneste DBServer MRS DB Database Om MRS skal kjøre i en to- eller trelags arkitektur velger man som et konfigurasjonsvalg i webapplikasjonen. Fordelen med å kjøre i en trelags fysisk arkitektur er lastbalanse, mulighet for vanntett skott mellom webserver og database, og tilgjengeliggjøring av webtjeneste for andre applikasjoner / presentasjonsgrenesnitt. Fordelen med tolags arkitektur er ytelse (mindre overhead, da en slipper webtjenestekall), billigere (slipper to servere), enklere vedlikehold. Det er for øvrig ingenting i veien for å kjøre webtjeneste og presentasjonslag på samme fysiske server, for da å kunne tilgjengeliggjøre webtjenesten derfra. -9-

166 3.1.2 Programvarearkitektur For å kunne realisere ovennevnte driftsarkitektur på best mulig måte har vi i MRS 2.0 etablert en tredelt lagstruktur innad i applikasjonen. Vi har her valgt en arkitektur basert på Microsoft anbefalte referansearkitektur for slike typer.net applikasjoner. Arkitekturen er hovedsaklig delt inn i 3 hovedlag. Dette er Presentation Layer, Business Layer og Data Layer. Presentation Layer Inneholder komponenter som sørger for interaksjonen mellom brukerne og applikasjonen. Business Layer Inneholder komponenter som er selve kjernen applikasjonen, som tilbyr forretningsfunskjonalitet. Applikasjonslaget utfører da forretningsprosesser som inneholder en eller flere oppgaver eller tjenester. Data Layer Inneholder komponenter som gjør det mulig å lagre og hente ut nødvendig data. Dette kan enten være fra database, webtjenester eller andre datakilder. Disse 3 hovedlagene består av flere komponenter eller sublag. Figuren nedenfor viser disse. Common Components Business Workflows UI Components UI Process Components Service Interface Data Access Logic Components Business Components Business Entities Service Agents Presentation Layer Business Layer Data Layer Data Sources Services DB Generelt er det slik at komponenter innenfor hvert lag snakker med hverandre, mens kun de laveste komponentene snakker med laget under og de øverste komponentene snakker med laget over. For eksempel er det slik at kommunikasjon mellom presentasjon- og forretningslag skjer via kommunikasjon mellom UI Process Components i presentasjonslaget og Service Interface komponenter (Webtjenester) i forretningslaget. Mellom forretningslaget og datalaget skjer kommunikasjonen mellom Business Components og Data Access Logic Components (DAL) eller Service Agents (SA). DAL komponenter er her akksess mot lokale ressurser slik som interne databaser, mens SA -10-

167 komponenter håndterer kommunikasjon mot eksterne tjenester (slik som f.eks. webtjenester). 3.2 Providere og integrasjonspunkter For å sikre størst mulig fleksibilitet i systemet er MRS 2.0 modularisert opp ved hjelp av såkalte providere. En provider er som navnet sier en tilbyder av en eller annen tjeneste eller funksjon i systemet. Ved hjelp av klart definerte grensesnitt (Provider Interfaces) kan da en provider enkelt byttes ut med en annen (som støtter det samme grenesnittet). I MRS 2.0 er det utviklet ulike providerene for: - Logging - Autorisasjon - Rollehåndtering - Brukerhåndtering - Organisasjonsstruktur - Pasienthåndtering I tillegg håndteres også prosesslaget mellom presentasjon- og applikasjonslaget også som en provider (processprovider og configprocesprovider). Denne bestemmer om prosesslaget skal gå mot webtjenestene eller om en skal gå direkte mot applikasjonslaget. (Det er da dette som bestemmer om en skal kjøre i en to- eller trelags arkitektur, se Driftsaarkitektur.) Vi skal nå gå gjennom de ulike providerene listet ovenfor Loggeprovider Loggeprovideren står som navnet sier for logging i systemet. Dette er ikke datalogging, men logging av feil, advarsler, generell informasjon og evt debug av systemet. I MRS 2.0 finnes en standard loggeprovider basert på nlog 1.0. nlog er et loggebibliotek som kan konfigureres opp til å logge mot en rekke ulike kilder. Eksempler på slike kilder kan være database, konsoll, eventlog, fil, mail, msmq, osv. Syntaks og hva en skal logge til defineres i en egen konfigfil for nlog (web.nlog). Standard i MRS 2.0 er logging til fil. Dokumentasjon og veiledning til hvordan logge til andre kilder finnes på Grensesnitt ILog ILog Interface Methods LogException(object obj, Exception ex) : void LogException(object obj, Exception ex, string additionalinfo, LogLevel loglevel) : void LogMessage(string message, LogLevel loglevel, object obj) : void -11-

168 LogLevel Enum Info Warn Error Fatal Debug ProviderConfig, default logprovider <component id="logprovider" service="hemit.mrs.businesslayer.providerinterfaces.ilog, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.businesslayer.defaultproviders.nlogprovider, Hemit.MRS.DefaultProviders" lifestyle="singleton" /> Autorisasjonsprovider Autorisasjonsprovideren tilbyr en måte å sjekke om en bruker har rettigheter til å utføre ulike operasjoner i systemet. Dette er da tett knytett opp mot den rollen brukeren er logget inn som. Default i MRS 2.0 gjøres denne sjekket mot et predefienrt sett av opgaver definert i databasen, og hvor også koblingen mellom hvilke roller som har lov til å utføre hvilke oppgaver ligger. Grensesnitt IAuthorizer IAuthorizer Interface Methods CheckAccessToOperation(IdentitetBE user, string application, string operation) : bool CheckAccessToOperation(int rolleid, string application, string operation) : bool ProviderConfig, default authorizationprovider <component id="authorizationprovider" service="hemit.mrs.businesslayer.providerinterfaces.iauthorizer, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.uiprocesscomponents.kvalitetsregisteruipc.usercontextprocess, Hemit.MRS.KvalitetsregisterUIPC" lifestyle="transient" /> Rolleprovider Rolleprovideren er en enkel provider som kun har som oppgave å tilby en liste over de ulike rollene som er tilgjengelig i systemet. -12-

169 Disse rollene kan enten være definert i databasen (slik det er default i MRS 2.0) eller en kan hente de fra en annen kilde, slik som XML eller AzMan. Rolle- og autorisasjonsprovideren er tett knyttet sammen, så en utskifting av den ene vil i de fleste tilfeller også bety en utskifting av den andre. Grensesnitt IRoleManagement IRoleManagement Interface Methods HentAlleRoller() : List< RolleBE> ProviderConfig, default rolemanagementprovider <component id="rolemanagemnetprovider" service="hemit.mrs.businesslayer.providerinterfaces.irolemanagement, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.uiprocesscomponents.kvalitetsregisteruipc.usercontextprocess, Hemit.MRS.KvalitetsregisterUIPC" lifestyle="transient" /> Brukerprovider Brukerprovideren inneholder det som har med selve brukeren å gjøre. I MRS 2.0 er det en egen brukerdatabase hvor alle brukerne av systemet ligger. En bruker får da en BrukerProfil som består av selve brukeren selv (personen), hvilke identiteter han har inn mot systemet (domenebruker og/eller brukernavn/passord), samt hvilke tilganger han har i systemet. En bruker kan ha flere tilganger i systemet. Disse er da definert via ulike tilgangsprofiler, bestående av en rolle, et tidsrom, samt hvilken organisatorisk enhet (sykehus + avdeling) tilgangen hører til. Se for øvrig Bruker, identitet og tilgangsprofil. Om MRS skal installeres på et sykehus som skal bruke et eget idm-system, kan en da utvikle en provider som støtter følgende grensesnitt: Grensesnitt IUserManagement IUserManagement Interface Methods BrukerSok(string fodselsnummer, string brukernavn, string fornavn, string etternavn, string fdato) : BrukerProfilBE[] HentBruker(int brukerid) : BrukerProfilBE IsBrukernavnTilgjengelig(int brukerid, string brukernavn, AuthenticationType brukertype) : bool LagreBruker(BrukerProfilBE brukerprofil) : BrukerProfilBE -13-

170 ProviderConfig, default usermanagementprovider <component id="usermanagementprovider" service="hemit.mrs.businesslayer.providerinterfaces.iusermanagement, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.uiprocesscomponents.kvalitetsregisteruipc.usercontextprocess, Hemit.MRS.KvalitetsregisterUIPC" lifestyle="transient" /> Organisasjonsprovider Oranisasjonsprovideren har som oppgave å tilby gjeldende organisasjonsstruktur for systemet. I MRS 2.0 er denne organisasjonsstrukturen definert i databasen, og default organisasjonsprovider går mot denne. Om en har regionale systemer som inneholder organsiasjonsstruktur, eller en ønsker å ta i bruk nasjonale registre, slik som for eksempel RESH, kan man da utvikle en provider for dette. Grensesnitt IOrganisasjonsstruktur IOrganisasjonsstruktur Interface Methods HentOrganisasjonsstruktur() : RegionBE[] ProviderConfig, default organisasjonsstrukturprovider <component id="organisasjonsstrukturprovider" service="hemit.mrs.businesslayer.providerinterfaces.iorganisasjonsstruktur, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.uiprocesscomponents.kvalitetsregisteruipc.usercontextprocess, Hemit.MRS.KvalitetsregisterUIPC" lifestyle="transient" /> Pasientprovider Pasientprovideren håndterer alt som har med selve pasienten å gjøre. Dette gjør at en kan trekke all pasientinformasjon ut av selve systemet, og få en fullstendig avidentifisert database. Det eneste som ligger igjen i databasen til MRS er en kobling mellem den interne pasientid en i MRS og pasient iden i det eksterne pasientsystemet. Av sikkerhetsmessige, konsistensmessige og praktiske grunner anbefales det å bruke sykehusenes egne kjernesystem for administrering av pasienter. I Helse Midt-Norge benyttes PAS (Pasient Administrativt System), levert av TietoEnator, som pasientsystem. Integrasjonen mot dette systemet går via et sett webtjenester; PasLink WebServices for HIS

171 Men pga at MRS skal kunne fungere frittstående, er det også utviklet en egen intern pasientdatabase i systemet. Denne er kryptert, og håndteres av systemet ellers som om den skulle vært en ekstern database. Forskjellen er at du i denne kan opprette og endre på pasientopplysninger, noe du ikke kan i for eksempel provideren for HIS90 i Helse Midt-Norge. Pga at en vil kunne ha mange ulike providere av pasientinformasjon, og noen skal være mulig å endre/opprette pasienter i, mens andre ikke, er det i selve grensesnittet defienert en del parametre som sier hva provideren er i stand til. For eksempel om det skal gå an å editere pasienter, hvilke parametre om pasienten provideren tilbyr osv. Parametre og metoder ExternalIdType - Brukes internt i MRS til å identifisere hvilken provider som har opprettet pasienten. HarTilgangsprofilExtentionGUI - Om provideren har egen GUI for tilgangsprofilen. PasientType - Hvilken type pasienter denne provideren håndterer. (Fullt pasientobjekt, enkelt pasientobjekt, enkel mannn, enkel kvinne) RedigerbareParametere - Hvilke parametere du kan redigere ved hjelp av denne provideren. TilgjengeligeParametere - Hvilke parametere på pasientobjektet som er tilgjengelige fra denne provideren. TillatRedigering - Om provideren støtter redigering/lagring av pasienter. F.eks så vil PAS ikke støtte redigering av pasienter. TillatSletting - Om provideren støtter sletting av pasienter. F.eks vil provider for intern pasientdatabase tillate dette. Videre tilbyr provideren en rekke metoder: HentPasient - Metode for å hente ut data om en pasient. En kan hente (søke etter) pasienten ved å bruke enten intern pasientid eller pasientens offiselle id - personnummer. HentTilgjengeligeExtentionVerdier - Metode for å hente ut tilgjengelige verdier, som skal listes i en eventuell tilgangextention i administrasjonsgui for tildelig av tilganger til brukere av systemet. LagrePasient - Lagrer en pasient. Skal kun kalles på providere hvor "TillatRedigering" er true. LastTilgangsprofilExtention - Metode som laster en composite control av typen TilgangsprofilExtention for denne provideren. Brukes kun hvis HarTilgangsprofilExtentionGUI er satt til true. -15-

172 ListPasienter - Metode for å søke opp en liste av pasienter ut fra gitte kriterier. SlettPasient - Sletter en pasient innefor providere hvor "tillatredigering" er true. Grensesnitt IPasientProvider IPasientProvider Interface Properties ExternalIdType { get; } : string HarTilgangsprofilExtentionGUI { get; } : bool PasientType { get; } : PasientType RedigerbareParametere { get; } : PasientParameter TilgjengeligeParametere { get; } : PasientParameter TillatRedigering { get; } : bool TillatSletting { get; } : bool Methods HentPasient(string providerpasientid, string offisiellid, string offisiellidtype, IdentitetBE user) : Pasient HentTilgjengeligeExtentionVerdier(BrukerProfilBE brukerprofil, TilgangsprofilBE thistilgangsprofil) : string LagrePasient(Pasient pasient, IdentitetBE user) : Pasient LastTilgangsprofilExtention() : TilgangsprofilExtention ListPasienter(string offisiellid, string offisiellidtype, string fornavn, string etternavn, string fdato, IdentitetBE user) : List<EnkelPasie SlettPasient(string providerpasientid, IdentitetBE user) : bool ProviderConfig, PasientProvider HIS90 <component id="pasientprovider" service="hemit.mrs.businesslayer.providerinterfaces.ipasientprovider, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.his90pasientprovider.pasientprovider, Hemit.MRS.HIS90PasientProvider" lifestyle="transient" /> Obs! Denne provideren støtter kun PasLinkWS v. 2.1 (leveranse 2). ProviderConfig, PasientProvider HIS90 <component id="pasientprovider" service="hemit.mrs.businesslayer.providerinterfaces.ipasientprovider, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.his90pasientprovider.pasientprovider, Hemit.MRS.HIS90PasientProviderTrustedSubSystem" lifestyle="transient" /> Obs! Denne provideren støtter PasLinkWS v (m/rettinger) eller nyere. Begge HIS90-providerne bruker PatientWS (GetPatient, ListPatientsById, GetPatientRelatives, ListPatients) og AuthenticationWS (GetUserLogin). -16-

173 ProviderConfig, PasientProvider Intern pasientdatabase <component id="pasientprovider" service="hemit.mrs.businesslayer.providerinterfaces.ipasientprovider, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.internpasientdatabaseprovider.fullpasientprovider, Hemit.MRS.InternPasientdatabaseProvider" lifestyle="transient" /> Prosesslaget som provider For at presentasjonslaget i systemet skal kunne fungere uavhengig av om det underforliggende businesslaget skal aksesseres via webtjeneste eller direkte har vi i MRS 2.0 implementert hele prosesslaget som en egen provider. Eller, det vil si to providere. En for standardmetoder i MRS (IProcess) og en for konfig/administrasjon (IConfigProcess). Det er da disse providerne som bestemmer om en skal gå mot webtjeneste eller ikke. ProviderConfig, lokalt oppsett: <component id="processprovider" service="hemit.mrs.businesslayer.providerinterfaces.iprocess, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.presentationlayer.serviceagents.localserviceagent, Hemit.MRS.PresentationLayer.ServiceAgents" lifestyle="transient" /> <component id="configprocessprovider" service="hemit.mrs.businesslayer.providerinterfaces.iconfigprocess, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.presentationlayer.serviceagents.localconfigserviceagent, Hemit.MRS.PresentationLayer.ServiceAgents" lifestyle="transient" /> ProviderConfig, oppsett med webtjeneste: <component id="processprovider" service="hemit.mrs.businesslayer.providerinterfaces.iprocess, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.presentationlayer.serviceagents.mrswsserviceagent, Hemit.MRS.PresentationLayer.ServiceAgents" lifestyle="transient" /> <component id="configprocessprovider" service="hemit.mrs.businesslayer.providerinterfaces.iconfigprocess, Hemit.MRS.ProviderInterfaces" type="hemit.mrs.presentationlayer.serviceagents.mrsconfigwsserviceagent, Hemit.MRS.PresentationLayer.ServiceAgents" lifestyle="transient" /> Prosessproviderne på sin side gjør da et kall mot applikasjonslaget, henholdsvis direkte eller via webtjenester. Webtjenesten(e) på sin side implementerer grensesnittet(ene) som prosesslaget da kaller (IMrsWS og IConfigMrsWS). -17-

174 Det er da nøyaktig samme kode som kjøres, inkludert autorisasjonssjekk i businesslaget, uansett om man kjører webtjeneste eller ikke. Eneste forskjellen er at webtjenestene går over http/soap, med den overheaden det gir. I tillegg til selve soap konverteringen er det her også et issue i forhold til sikkerhet over webtjenesten. I MRS 2.0 legges det på alle kall en ekstra header som sier hvem som kaller webtjenesten. Ved bruk av integrert sikkerhet på webapplikasjonen, er det da den påloggede brukeren (på tråden) som blir satt som kaller. Denne brukeren må da være satt opp til å ha tilgang til å kjøre webtjenesten for at dette skal gå. Om applikasjonen er satt opp med forms autentisering, må en da bruke en systembruker for å kalle webtjenesten. Brukeren som er pålogget applikasjonen blir da satt som bruker i headeren, mens det er selve systembrukeren selve kallet kjøres som. Webtjenestekallet bør i tillegg krypteres via SSL. Dette må da settes opp på IIS-serveren hvor webtjenesten kjører. -18-

175 Grensesnitt IProcess IProcess Interface Methods Authenticate(string username) : IdentitetBE BrukerSok(string fodselsnummer, string brukernavn, string fornavn, string etternavn, string fdato) : BrukerProfilBE[] CheckAccessToOperation(int roleid, string operasjonnavn) : bool DeleteDataSett(int datasettid) : DeleteState DeleteKontakt(KontaktBE kbe) : DeleteState EndreValgtProfil(int profilid) : IdentitetBE GetAlleKontakter(int pasientid, string registerkode) : KontaktBE[] GetCustomDataSettList(string listtype, string externalidtype, string registerkode, DateTime fra, DateTime til) : DSInfoBE[] GetCustomDataSettListSetup(string listtype) : CustomDataSettListSetup GetDataSettType(string datasetttypekey) : DataSet GetDefaultSkjema(string registerkode) : SkjemaInfoBE GetIdentity(string username) : IdentitetBE GetKontakt(int kontaktid, string registerkode) : KontaktBE GetKontrollskript(int skjemaid, int sidenr) : SkriptBE[] GetMrsInstans(string mrsinstansid) : DataSet GetOrganisasjonsstruktur() : RegionBE[] GetSkjema(string skjemaid, string datasettid, string parentdatasettid, string relateddatasettid) : DataSet GetUferdigeRegistreringer(string externalidtype, string registerkode, DateTime fra, DateTime til) : DSInfoBE[] HentAlleRoller() : RolleBE[] HentAntallSisteUferdigePasienter(string externalidtype, string registerkode) : int HentBruker(int brukerid) : BrukerProfilBE HentMeny(string menuname) : XmlDocument HentPasient(int pasientid, string externalid, string externalidtype, string psientpseudonym, string registerkode) : MrsPasient HentPasientProviderInfo() : PasientProviderInfo HentProsedyreParametre(string prosedyrenavn) : RapportParameterBE[] HentRapport(int rapportid) : RapportBE HentRapportDataSett(RapportDataSetRequestBE req) : DataSet HentRapportProsedyrer() : string[] HentRapportServer(int serverid) : RapportServerBE HentSisteLestePasienter(string brukernavn, string externalidtype, string registerkode, int maxnum) : MrsPasient[] HentSistePasienter(string brukernavn, string externalidtype, string registerkode, int maxnum) : MrsPasient[] HentSisteUferdigePasienter(string externalidtype, string registerkode, int fromindex, int toindex) : MrsPasient[] IsBrukernavnTilgjengelig(int brukerid, string brukernavn, AuthenticationType brukertype) : bool LagreBruker(BrukerProfilBE brukerprofil) : BrukerProfilBE LagrePasient(MrsPasient pasient, string registerkode) : MrsPasient LagreRapport(RapportBE rapport) : RapportBE LagreRapportServer(RapportServerBE server) : RapportServerBE ListPasienter(string ID, string IDType, string fornavn, string etternavn, string fdato, string registerkode) : MrsEnkelPasient[] ListRapporter() : RapportBE[] ListRapportServere() : RapportServerBE[] Login(string useraccount) : IdentitetBE Logout() : void PasientProviderHentTilgjengeligeExtentionVerdier(BrukerProfilBE bruker, TilgangsprofilBE tilgang) : string SaveKontakt(KontaktBE kbe) : int SlettPasient(MrsPasient pasient, string registerkode) : void SlettRapport(RapportBE rapport) : void SlettRapportServer(RapportServerBE server) : void UpdateDataSett(XmlDocument xmldoc) : DataSetResult UpdateStatus(int datasettid, DSStatus status, bool ignorevalidationquestion) : void UpdateTheme(string newtheme) : void ValidateSkjema(XmlDocument xmldoc) : DataSet -19-

176 Grensesnitt IConfigProcess IConfigProcess Interface IMrsConfigWS IMrsConfigWS Interface Methods GenererDataSettTypeXml(string datasetttypekey) : XmlNode GenererDataSettValideringXml(string datasetttypekey) : XmlNode GenererSkjemaKontrollskriptXml(string skjematypekey) : XmlNode GenererSkjemaXml(string skjematypekey) : XmlNode HentDefaultSkjema(int skjemaid) : DefaultSkjemaBE HentDefaultSkjemaFraRegisterkode(string registerkode) : DefaultSkjemaBE HentInstans(int instansid) : InstansBE HentKvalitetsregister(string registerkode) : KvalitetsregisterBE HentSkjemaID(string skjematypekey) : int InsertDataSettTypeDefinition(XmlNode xmldocument, bool genererrapportgrunnlag) : int InsertSkjemaDefinition(XmlNode xmldocument) : int LagreDefaultSkjema(DefaultSkjemaBE skjema) : void LagreEnhet(EnhetBE enhet, EnhetType type) : int LagreInstans(InstansBE mrsinstans) : InstansBE LagreKvalitetsregister(KvalitetsregisterBE kvalitetsregister) : KvalitetsregisterBE LagreOrganisasjonstre(RegionBE[] regioner) : void ListInstanser() : InstansBE[] ListKvalitetsregistre() : KvalitetsregisterBE[] ListSkjema() : SkjemaMetaBE[] SettAktivStatus(int skjemaid, bool aktiv) : void SettInnKontrollskript(XmlNode xmldocument) : void SettInnValideringsregler(XmlNode xmldocument) : bool SlettEnhet(EnhetBE enhet, EnhetType type) : void SlettKvalitetsregister(string registerkode) : void SlettMrsInstans(int instansid) : void IProcess kaller webtjenesten via grensesnittet IMrsWS: -20-

177 Grensesnitt IMrsWS IMrsWS Interface Methods Authenticate(string brukernavn) : IdentitetBE BrukerSok(string fodselsnummer, string brukernavn, string fornavn, string etternavn, string fdato) : BrukerProfilBE[] CheckAccessToOperation(int rolleid, string operasjonnavn) : bool DeleteDataSett(int datasettid) : DeleteState DeleteKontakt(KontaktBE kbe) : DeleteState EndreValgtProfil(int profilid) : IdentitetBE GetAlleKontakter(int pasientid, string registerkode) : KontaktBE[] GetCustomDataSettList(string listtype, string externalidtype, string registerkode, DateTime fra, DateTime til) : DSInfoBE[] GetCustomDataSettListSetup(string listtype) : CustomDataSettListSetup GetDataSett(int datasettid) : XmlNode GetDataSettType(string datasetttypekey) : XmlNode GetDefaultSkjema(string registerkode) : SkjemaInfoBE GetIdentitet(string brukernavn) : IdentitetBE GetKontakt(int kontaktid, string registerkode) : KontaktBE GetKontrollskript(int skjemaid, int sidenr) : SkriptBE[] GetMrsInstans(string mrsinstansid) : XmlNode GetOrganisasjonsstruktur() : RegionBE[] GetSkjemaDefinition(int skjemaid, int parentdatasettid, int relateddatasettid) : XmlNode GetSkjemaDefinitionAndData(int datasettid) : XmlNode GetUferdigeRegistreringer(string externalidtype, string registerkode, DateTime fra, DateTime til) : DSInfoBE[] HentAlleRoller() : RolleBE[] HentAntallSisteUferdigePasienter(string externalidtype, string registerkode) : int HentBruker(int brukerid) : BrukerProfilBE HentMeny(string menuname) : XmlNode HentPasient(int pasientid, string externalid, string externalidtype, string pasientpseudonym, string registerkode) : MrsPasient HentPasientProviderInfo() : PasientProviderInfo HentProsedyreParametre(string prosedyrenavn) : RapportParameterBE[] HentRapport(int rapportid) : RapportBE HentRapportDataSett(RapportDataSetRequestBE req) : DataSet HentRapportProsedyrer() : string[] HentRapportServer(int serverid) : RapportServerBE HentSisteLestePasienter(string brukernavn, string externalidtype, string registerkode, int maxnum) : MrsPasient[] HentSistePasienter(string brukernavn, string externalidtype, string registerkode, int maxnum) : MrsPasient[] HentSisteUferdigePasienter(string externalidtype, string registerkode, int fromindex, int toindex) : MrsPasient[] IsBrukernavnTilgjengelig(int brukerid, string brukernavn, AuthenticationType brukertype) : bool LagreBruker(BrukerProfilBE brukerprofil) : BrukerProfilBE LagrePasient(MrsPasient pasient, string registerkode) : MrsPasient LagreRapport(RapportBE rapport) : RapportBE LagreRapportServer(RapportServerBE server) : RapportServerBE ListPasienter(string ID, string IDType, string fornavn, string etternavn, string fdato, string registerkode) : MrsEnkelPasient[] ListRapporter() : RapportBE[] ListRapportServere() : RapportServerBE[] Login(string useraccount) : IdentitetBE Logout() : void PasientProviderHentTilgjengeligeExtentionVerdier(BrukerProfilBE bruker, TilgangsprofilBE tilgang) : string SaveKontakt(KontaktBE kbe) : int SlettPasient(MrsPasient pasient, string registerkode) : void SlettRapport(RapportBE rapport) : void SlettRapportServer(RapportServerBE server) : void UpdateDataSett(XmlNode xmldatasett) : DataSetResult UpdateStatus(int datasettid, DSStatus status, bool ignorevalidationquestions) : DataSetResult UpdateTheme(string newtheme) : void Valideringsresultat(XmlNode skjema) : XmlNode -21-

178 3.3 Tilgangskontroll Tilgangen til og visning av opplysninger i MRS styres av hvilken rolle brukeren har i systemet og hvilken data brukeren skal ha tilgang til. Det vil si at personer fra ulike organisatoriske enheter og sykehus skal ha ulik tilgang i systemet (datatilgang) og personer med ulike funksjoner på sykehuset skal ha ulik tilgang til ulike funksjoner i systemet Bruker, identitet og tilgangsprofil For å beskrive tilgangskontrollen i MRS 2.0 er det viktig å forstå hvordan selve brukerprofilen til brukerne er oppbygd. Det er dette som bestemmer hvordan brukeren skal komme seg inn i systemet, og hva han skal ha tilgang til. Skissen under viser hvordan dette henger sammen: Som vi ser kan en bruker både ha flere identiteter inn mot systemet, og flere tilgangsprofiler knyttet mot seg. Vi skal nå gå litt nermere inn på de ulike elementene. Bruker En bruker av MRS er en fysisk person med tilgang til systemet. Brukeren er identifisert ved personnummer, og opptrer bare en gang pr register. -22-

179 BrukerBE Class Fields Properties BrukerID Epost Etternavn Fodselsnummer Fornavn Telefonnummer Theme TilgjengeligeProfiler Tittel ValgtProfil Methods ToString Feltene Fornavn og Etternavn brukes for visning av hvem som er logget på registeret, mens feltene Epost, Tittel og Telefonnummer kun brukes for å kunne kontakte en bruker hvis det skulle være behov for det. (I denne versjonen av MRS er det ingen GUIelemeter som tar i bruk disse feltene). Theme bestemmer hvilket fargetema brukeren har valgt. I tillegg ser vi at brukeren har et sett med TilgjengeligeProfiler og en ValgtProfil. Dette er tilgangsprofiler, som vi kommer tilbake til i de neste avsnittene. Identitet For å logge på systemet har brukeren en eller flere identiteter. En identitet kan enten være brukernavn/passord (for formsautentisering) eller det kan være en domenebruker (for SSO (Windowsautentisering)). Om en bruker har flere domebrukere han/henne ønsker å logge inn via, kan en da legge til begge desse koblet mot selve brukeren. På denne måten har en en mer fleksibel løsning i forhold til domener og domenestruktur. -23-

180 BrukerBE Class Fields Properties BrukerID Epost Etternavn Fodselsnummer Fornavn Telefonnummer Theme TilgjengeligeProfiler Tittel ValgtProfil Methods ToString IIdentity IdentitetBE Class BrukerBE Fields Properties AuthenticationType Brukernavn BrukerType IdentitetID IsAuthenticated Name Passord AuthenticationType Enum Windows Forms Tilgangsprofil Videre må brukren få tilgang til selve dataen i systemet. Dette settes opp ved at brukeren får tildelt en eller flere tilgangsprofiler. Mens identiteten sier hvem brukeren er, sier tilgangsprofilen hva han har tilgang til. En tilgang består av en rolle, en organisatorisk enhet og et tidsrom tilgangen gjelder for. En bruker kan dermed ha flere ulike roller i systemet, og ulik tilgang ut fra organisatorisk tilhørighet. TilgangsprofilBE Class Fields Properties GyldigFra GyldigTil ID Organisasjon Rolle TilgangsprofilExtension Methods TilgangsprofilBE TilgangsprofilExtentionBE Class Fields Properties Providernavn Verdi Methods ToString -24-

181 Om en bruker får tildelt flere tilgangsprofiler, må han velge vilken tilgang han skal akkessere systemet med. I brukergrensesnittet gjør han dette ved å trykke knappen for bytt profil, og velger hvilken tilgang han vil ha aktiv. Tilgangsprofiler spesifiserer tilgangen på avdelingsnivå. Det vil si en avdeling under et sykehus, under et helseforetak, under en region. Når et skjema så registreres i systemet blir det da tagget med denne avdelingen. Skjemaet vil da kun være tilgjengelig for andre som er logget på akkurat denne spesifike avdelingen. Dette betyr også at om en bruker skal ha tilgang til flere ulike avdelinger på et sykehus, må det opprettes flere tilgangsprofiler brukeren må velge mellom. Det kan også tenkes at en bruker skal ha flere ulike roller innenfor en avdeling, men dette vil ikke påvirke hva han har tilgang til, bare hva han får lov til å gjøre i systemet. Dermed vil dette være et mer søkt tilfelle. TilgangsprofilExtention Pga at systemet skal kunne integreres mot ulike systemer, for eksempel Pasientadministrative system (PAS), er det i tillegg mulighet til å legge til egne tilgangstillegg for disse. For eksempel vil en med integrasjon mot PAS ønske å koble en pas-bruker mot den tilgangen brukeren har. På denne måten kan en sørge for single sign-on funskjonalitet også mot de integrerte systemene. For PAS HIS90 som brukes i Helse Midt-Norge er det derfor i pasientprovideren utviklet en egen tilgangsextention som viser ut en liste over tilgjengelige PAS-brukere for den aktuelle MRS-brukeren. Tillegget tar da utgangspunkt i personnummeret til MRS-brukeren og leter opp alle tilgjengelige PAS-tilganger denne personen har innenfor det valgte sykehuset (som er valgt på selve tilgangen). Når brukeren logger på, og da velger denne tilgangen, er det da pasientprovideren som sørger for at brukeren blir pålogget også mot pasientsystemet. Ved bruk av intern pasientdatabase er dette ikke nødvendig, og for denne pasientprovideren trengs derfor ingen ekstra tillegg Roller i systemet I tillegg til filtrering på selve dataen en bruker skal få tilgang til trengs der filtrering på hvilke funkjsoner og operasjoner de ulike brukerene av MRS skal ha tilgang til. Dette gjøres ved å sette opp ulike roller i systemet. Rollen er igjen, som nevnt over, koblet mot tilgangsprofilen. Det er seks roller i systemet; Behandler, Leser, Pasientansvarlig, Registeransvarlig, Brukeradministrator og Systemadministrator. En Behandler har som hovedformål å registrere i registeret. Han/hun har da rettighterer til å søke opp pasienter (basert på personlig tilgang), opprette nye sykdomstilfeller og registrere i, endre og slette skjemaer. En behandler har ikke mulighet til å ferdigstille eller gjenåpne et skjema, og har ikke mulighet til å slette skjema som er ferdigstillet/lukket. En bruker med rollen behandler vil typisk være en sykepleier eller en sekretær med begrensede rettigheter. -25-

182 En Leser har som navnet sier kun lesetilgang i registeret. Han/hun kan ikke registrere skjema, men har mulighet til å søke opp pasienter og se på registrerte skjema innenfor den gitte avdelingen. Leseren vil typisk også bli tildelt mulighet for å få opp ulike avidentifiserte rapporter fra registeret. Leseren er gjerne en administrativ person på avdelingen, eller en forsker. En Pasientansvarlig har samme rettigheter som en benhandler, men har i tillegg rettigheter til å ferdigstille/lukke og gjenåpne skjemaer. En pasientansvarlig har også mulighet til å slette et lukket skjema. (Dette skjemaet vil da ikke bli fysisk slettet fra databasen, bare deaktivert og gjemt i bakgrunnen. Dette for at det skal gå an å finne tilbake til skjemaet hvis det var en feilsletting.) Personer som skal ha rollen Pasientansvarlig vil typisk være leger og evt. sekretærer med utvidede rettigheter. Hver instans av systemet vil ha en eller flere Registeransvarlig. En registeransvarlig har alle rettigheter som en pasientansvarlig, pluss muligheten for å kunne hente ut egne rapporter. En registeransvarlig er typisk en person som har fått i oppgave å sørge for kvaliteten på de data som blir registrert, veilede andre brukere og være brukerens nærmeste kontaktpunkt ved feil, mangler, spørsmål og oppfølging. En Brukeradministrator er en person som har mulighet til å opprette brukere og sette tilgang i systemet. Brukeradministratoren settes da opp som administrator for en eller flere spesifikke avdelinger han kan gi tilgang til. På denne måten kan for eksempel avdelingsledere selv få administrere hvem som skal få tilgang til systemet og hvilken rolle disse skal ha. Den siste rollen er Systemadministrator som i tillegg til å ha de samme rettighetene som registeransvarlig og brukeradministrator har mulighet til å legge inn nye datasetttyper, skjema, valideringsregler og kontrollskript. Personer med rollen administrator it vil typisk være en systemansvarlig ved it-avdelingen for den gjeldende instansen av systemet. 3.4 Avidentifisering/anonymisering av data Helseregisterloven skiller mellom fire kategorier opplysninger: Helseopplysninger som entydig kan knyttes til en identifiserbar person. Disse blir i det etterfølgende kalt personidentifiserbare helseopplysninger. Pseudonyme helseopplysninger. Dette er helseopplysninger hvor personens identitet er erstattet med et pseudonym. Dette hindrer at personen kan identifiseres, men opplysningene er likevel entydig knyttet til en person på en slik måte at når detkommer til nye opplysninger om personen, så kan disse knyttes til samme pseudonym. Alle opplysninger som rapporteres til registret kan dermed sammenstilles for hver enkelt person, uavhengig av når opplysningene blir rapportert eller hvem som er kilden. Pseudonyme helseopplysninger er personentydige men ikke personidentifiserbare. Avidentifiserte helseopplysninger. Dette er helseopplysninger der navn, fødselsnummer og andre personentydige kjennetegn er fjernet eller erstattet med et saksnummer e.l. Dersom det benyttes saksnummer må det tildeles nye saksnummer for hver enkelt rapportering til registret. Denne metoden gir ikke mulighet til å knytte opplysninger rapportert fra forskjellige kilder eller til forskjellig tid, til samme person. Personens identitet kan bare kan tilbakeføres ved sammenstilling med de samme opplysninger som tidligere ble fjernet. -26-

183 Anonyme opplysninger. Dette er opplysninger der navn, fødselsnummer og andre personentydige kjennetegn er fjernet, slik at opplysningene ikke lenger finnes noen mulighet til å knytte opplysningene til en enkeltperson. Ettersom det kun er de to første kategoriene opplysninger som gjør det mulig å følge personer over tid, er dette i praksis de eneste typene opplysninger som er aktuelle for bruk i kvalitetsregistre. (Kilde: KITH rapport nr. 38/03: Koordinerte løsninger for kvalitetsregistre) MRS baserer seg, som beskrevet over, på bruk av en egen pasientprovider for uthenting av pasientopplysninger. Dette gjør at en ved bruk av et eksternt pasientsystem ikke vil lagre personidentifiserbare opplysninger i databasen. En kan dermed ikke si at MRSbaserte kvalitetsregistre med integrasjon fra ekstrene PAS er personidentifiserbare. Ved bruk av intern pasientdatabase som provider for paientinformasjon vil en derimot kunne si at MRS er personidentifiserbar. Det vil si pasientopplysningene blir lagret i databasen, men ligger der kryptert. Det vil igjen si at du må ha tilgang til selve systemet for at dataen kan hentes ut på leselig form. Koblingen mellom pasientprovideren og pasienten internt i MRS legger videre til rette for å gjøre MRS til et pseudonymisert register. Grunnen til at vi her sier lagt til rette for er at vi i dag ikke kan si vi har en fullstendig pseudonymisert løsning. I den forstand at en og samme person alltid vil få et og samme pseudonym (og dermed være pesonentydig nasjonalt sett). Pseudonymiseringen (beholdningen av personentydigheten) i MRS skjer ved at en pasient ved et helseforetak (juridisk enhet) får et pseudonym som kun er gjennomgående for registreringer ved dette hf et. En kan da følge en pasients sykdomsforløp innenfor hf et, men ikke på tvers av hf. Dette pseudonymet kobles da i databasen mot det eksterne pasientsystemet (PAS) ved hjelp av en ekstern nøkkel (PAS ID). For nermere beskrivelse av denne koblingen se Lagring av data og kobling mot pasient. 3.5 Datainnsamling og sikring av datakvalitet Data i MRS blir registret lokalt over web ved de ulike kliniske avdelingene på sykehuset/ene som er koblet mot systemet. Når en bruker da legger inn data, blir de først validert mot en del predefinerte valideringsregler, før de lagres i den sentrale databasen. Når en da begynner å registrere får datasettet/skjemaet tilstanden kladd. Denne tilstanden vil datasettet da ha helt til en autorisert person går inn og ferdigstiller/lukker skjemaet Validering av data Når et datasett skal lagres i databasen må det altså først valideres mot et sett valideringsregler. Disse regelene er definert av fagmiljøet selv, og er med på å sikre at all data som lagres er konsistent og gyldig i forhold til det spesifikke registeret. En valideringsregel kan settes opp til å kjøres kun ved lagring, kun ved ferdigstilling eller evt. begge deler. Grunnen til dette er at en gjerne ønsker strengere valideringsregler ved ferdigstilling enn ved selve delregistreringen. -27-

184 Eksempel på en valideringsregel kan være at et visst parameter ikke kan ha verdi utenfor en viss range, at utreisedato ikke kan være før innleggelse, eller f.eks. at enkelte parameter må fylles ut før en får lagre Ferdigstilling/lukking av skjema Det er kun pasientansvarlige (som oftest en lege) som har mulighet til å ferdigstille et skjema. Det er derfor denne personens ansvar å sørge for at alle data er gyldige og i henhold til valideringsreglene før han/hun ferdigstiller Kontrollscript I tillegg til selve valideringsreglene (som kun kjøres ved lagring/ferdigstilling) har en muligheten til å lage kontrollskript som styrer funksjonaliteten under selve skjemautfyllingen. Dette kan være at hvis en f.eks. krysser av for en spesifikk verdi så blir andre felter grået ut / disablet for registrering. Dette er også en funkjsonalitet som skal være med å sikre kvaliteten på selve registreringen. -28-

185 4. Database og objektmodell Databasen i MRS er utformet som en generisk metadatabase hvor definisjon av hvilke data som kan lagres og den faktiske lagringen av dataen er separert. Dette gir en meget fleksibel løsning i forhold til opprettelse og endring av nye registre. 4.1 Skille mellom presentasjon, definisjon og datalagring En viktig del av måten MRS er bygd opp på er skillet vi gjør mellom presentasjon, definisjon og lagring av data. Dette gjør at vi basert på en definisjon kan ha mange ulike presentasjoner (i praksis skjemautforminger), samtidig som vi har muligheten til å endre/legge til parametre i denne definisjonen uten at gamle skjema nødvendigvis må endres. Et skjema (presentasjon) som er lagret i MRS defineres i databasen som et DataSett (datalagring) bestående av et vilkårlig antall parametre med verdi. Hvilke parametre som er tilgjengelig er igjen defienert via DataSettType (definisjonen). Dette forklares best ved et eksempel: En definerer opp en DataSettType (DST) med parametrene a, b, c og d. Dette er da de mulige parametrene en kan ha med i et skjema. Vi kan da for eksempel definere opp to skjema ut fra dette. Skjema1 med parameterene {a, b og c) og Skjema2 med parametrene {a og d}. Ved utfylling og lagring av disse skjemaene vil en da få et DataSett med {va, vb, vc} og et annet DataSett med verdiene {va og vd}. Begge basert på DataSettTypen DST. Ønsker en å utvide Skjema2 med et nytt parameter, e, kan en da legge til dette parameteret i DataSettTypen og legge inn en ny definisjon av Skjema2 til å inneholde parametrene {a, d og e}. Nye DataSett lagret basert på Skjema2 vil da inneholde verdiene {va, vd og ve). Dette gjør det relativt enkelt å utvide og endre på skjemadefinisjoner, også etter at systemet er installert og tatt i bruk. Selv om det er forskningsmessig meget hensiktsmessig å ha et så stabilt datagrunnlag som mulig har det vist seg at slik funksjonalitet som beskrevet over har vært høyt verdsatt fra kundens ståsted. Figuren under viser hvordan sammenhengen mellom presentasjon, datadefinisjon og datalagring er realisert i databasen. -29-

186 -30- Skjema SkjemaID SkjemaTypeKey Navn DataSettTypeID DataSettTypeKey ParentID RelatedID DefaultSkjema VisFra VisTil VisNavn Tooltip Listposition KunEnInstans Aktiv Side SideID Sidenr SkjemaID Navn Tooltip Gruppe GruppeID Navn Synlig Retning AntallKolonner SideID Colspan VisNavn Kontroll KontrollID Navn Felttype Lengde AntallRader Synlig Hjelpetekst IkkeBlank ReadOnly GruppeID AntallKolonner ParameterID PrevParameterID FraTidspunkt TilTidspunkt Standardverdi CaptionWidth ControlWidth Indent TabIndex FlowIndex DataSettType DataSettTypeID RegisterKode DataSettTypeKey Navn Beskrivelse RegionSpesifikk RegionKode HFSpesifikk HelseforetakKode SykehusSpesifikk SykehusKode Aktiv Parameter DataSettTypeID ParameterID ParameterKey Navn RapportNavn Datatype Standardverdi IkkeBlank CopyParent CopyRelated Kommentar GyldigFraOgMed GyldigTilOgMed Alternativ ParameterID AlternativID AlternativKey Tekst Verdi AlternativNummer GyldigFraOgMed GyldigTilOgMed Filter DataSett DataSettID RegisterKode DataSettTypeID DataSettTypeKey SkjemaID SkjemaTypeKey KontaktID StatusID ParentID RelatedID Pasientnummer RegistreringsRegion RegistreringsHF RegistreringsSykehus RegistreringsAvdeling OpprettetDato Aktiv Verdi VerdiID Verdi DataSettID ParameterID SistOppdatert Brukerkonto

187 4.2 Skjema og utforming Et skjema er bygd opp hierarkisk med et vilkårlig antall sider som igjen inneholder et sett med grupper av et vilkårlig antall kontroller. En kontroll er her en typisk textbox, dropdown, checkbox eller radiobutton. Til hver kontroll kan en sette label, samt hvor bred labelen og selve kontrollen skal være. En kontroll kan ha en standardverdi, og en kan definere opp hjelpetekst som kommer opp når brukeren holder musen over kontrollen. Hvis en kontroll er en datokontroll (spesialkontroll for dato og tid) har en også muligheten for å sette at denne kontrollen angir fratidspunkt eller sluttidspunkt for skjemaet (og da også datasettet). Dette både for visning i GUI, samt for bruk av sortering/filtrering av datasett på tid i rapporter. Pga dette anbefales det alltid å ha en kontroll i skjemaet som angir starttidspunkt. En kontroll er alltid koblet mot et parameter definert i DataSettTypen. Det er via kontrollen (parameteren) at det blir lagret en verdi koblet til datasettet i databasen. Datasettet vil da bestå av like mange (ingen mindre, ingen flere) verdier som det er kontroller i skjemaet. Her er det en direkte mapping. Alle kontroller i et skjema må plasseres i grupper. I gruppen angir en hvor mange kolonner med kontrollere en ønsker å ha med. For eksempel kan en sette at en ønsker to kolonner med kontrollere i en gruppe. Avhengig av rekkefølge i databasen vil da de ulike kontrollene automatisk legge seg inn etter hverandre i de to kolonnene. Ser en at det f.eks. ble for store åpenrom kan en da ved å sette AntallKolonner i gruppetabellen få opp tre kolonner istedenfor. Dette kun ved å endre en parameter. En har også mulighet for at kontrollere kan spanne over flere kolonner. F.eks. hvis en har to kolonner men vil at den øverste kontrollen skal dekke over begge kolonnene. Dette settes da i AntallKolonner i Kontroltabellen. Skjemaet er igjen delt opp i sider bestående av disse gruppene. En side har i seg selv seks kolonner. En gruppe kan da være 1/6, 1/3, 1/2, 2/3, 5/6 eller hele bredden bredden av skjemaet (definert i ColSpan i gruppetabellen). Med dette forståes også at det kan være en til seks grupper ved siden av hverandre. Hver gruppe får et navn som da blir overskrift på gruppen. En kan også velge at en gruppe skal være usynlig, for eksempel hvis en ønsker å ha med en del verdier (defienert som standardverdier eller via spesialkontroller) som ikke trengs å vises for brukeren. Dette som sagt fordi hver verdi som skal lagres i databasen må være koblet mot en parameter via en kontroll i skjemaet Underskjema og relaterte skjema Ofte er det slik at ulike skjemaer hører til hvarandre i en eller annen sammenheng. For eksempel kan en i enkelte situasjoner ønske å registrere noe ekstra i forhold til det som er registrert i hovedskjemaet. Det en da kan gjøre er å opprette et nytt skjema og definere at dette er et underskjema av et annet. Dette gjøres da ved å sette ParentID i skejmatabellen, som da angir hvilket skjema som er foreldren til dette skjemaet. For at et underskjema skal være tilgjengelig må da et (helt eller delvis) utfylt hovedskjema finne sted. Dette kommer da opp som et eget valg i GUI. Når en da ferdigstiller hovedskjemaet vil også alle underskjema valideres og ferdigstilles i samme prosess. På samme måte som for underskjema kan en også definere opp relaterte skjema. Dette er skjema som har egen ferdigstilling (og valideringsregler) men som samtidig er i sammenheng med et hovedskjema. Hovedskjema defineres da via RelatedID, og det relaterte skjemaet vil kun komme opp hvis hovedskjemaet er påbegynt registrering på. -31-

188 Relaterte skjema vil typisk være oppfølgingsskjema som utfylles en periode etter selve hovedregistreringen. En kan også bestemme om under- og relterte skjema kan ha flere instanser under hovedskjemaet. F.eks. om en skal kunne registrere et eller flere oppfølginger under et hovedskjema. Dette defineres i feltet KunEnInstans i skjematabellen Databseelementer: Skjema og utforming Skjema Attributt Beskrivelse Eksempel SkjemaID Løpenummer i databasen 1 n SkjemaTypeKey Unik kode som identifiserer skjemaet. Navn Navn på skjema / tittel Hovedinfarkt DataSettTypeID DataSettTypeKey ParentID RelatedID DafaultSkjema ID som identifiserer hvilken DataSettType skjemaet er av. Nøkkel som identifiserer hvilken DataSettType skjemaet er av. Om skjemaet har et parent skjema settes ID til dette her. Om skjemaet har et relatert skjema settes ID til dette her. Om dette skjemaet er et defaultskjema. Dvs hovdeskjema for et register. HJERTE_DST_01_HOVED_01 1 n HJERTE_DST_01 1 n 1 n True/false VisFra Om fradato skal vises i GUI True/false VisTil Om tildato skal vises i GUI True/false VisNavn Tooltip Listposition KunEnInstans Aktiv Om navnet/tittelen på skjemaet skal vises i GUI Hjelpetekst som beskriver skjemaet. Hvilken posisjon skjemaet skal ha i listen over tilgjengelige skjema (sortering). Om det kun skal kunne opprettes en instans av skjemaet. Om datasettet er aktivt. Dvs kommer opp som mulig skjema å fylle ut for brukeren. True/false Tekstreng 1 n True/false True/false Side Attributt Beskrivelse Eksempel SideID Løpenummer i databasen 1 n Sidenr Sidenummer i skjemaet 1 n SkjemaID Hvilket skjema siden hører til. 1 n Navn Navn på skjemasiden. Tesktstreng Tooltip Hjelpetekst for sidenavigering Tekstsreng Gruppe Attributt Beskrivelse Eksempel GruppeID Løpenummer i databasen 1 n -32-

189 Attributt Beskrivelse Eksempel SideID Hvilken side i skjemaet gruppen hører til 1 n Navn Navn/tittel på gruppen. Tesktstreng Synlig AntallKolonner Colspan VisNavn Om gruppen skal være synlig i GUI Hvor mange kolonner gruppen skal ha inni gruppen. Altså hvor mange kontroller det skal være plass til på siden av hverandre inne i gruppen. Hvor mange sidekolonner gruppen skal spanne over. En side er delt inn i 3 kolonner. Om navnet/tittelen på gruppen skal vises io GUI True/false 1 n 1, 2 eller 3 True/false Kontroll Attributt Beskrivelse Eksempel KontrollID Løpenummer i databasen 1 n GruppeID Hvilken gruppe kontrollen hører til 1 n ParameterID PrevParameterID Hvilken parameter kontrollen er koblet mot ParameterID til kontrollen før i tabrekkefølgen. Brukes til å sette riktig tab-flyt i registreringen. 1 n 1 n Navn Navn/caption/labell for kontrollen. Tesktstreng -33-

190 Attributt Beskrivelse Eksempel Felttype Hvilken type kontrollen er av. TextBox DropDown DateTime Date Time CheckBox Float Int FødselsårTextBox (fra pasienten) AlderTextBox (fra pasienten) DodTextBox (fra pasienten) PostnummerTextBox (fra pasienten) KjonnValg (fra pasienten) SivilstatusTextBox (fra pasienten) YrkeTextBox (fra pasienten) KommuneTextBox (fra pasienten) AvdelingTextBox (fra brukerobjekt) SykehusTextBox (fra brukerobjekt) HelseforetakTextBox (fra brukerobjekt) RegionTextBox (fra brukerobjekt) PasientnummerTextBox (fra pasienten) DateEndOfDay RadioButton RadioButtonList RadioButtonList_H RadioButtonList_V TextArea PostStedTextBox DodDate NasjonalitetTextBox (fra pasienten) FodselsdatoTextBox (fra pasienten) HiddenFodselsDato (fra pasienten) Registreringstidspunkt NasjonalitetKodeTextBox (fra pasienten) BMITextBox (fra pasienten) Label LabelNoCaption Button Url Spacer (tom kontroll) Lengde AntallRader Synlig Hjelpetekst IkkeBlank ReadOnly AntallKolonner FraTidspunkt TilTidspunkt Brukes ikke Om en kontroll skal gå over flere rader. Om kontrollen skal være synlig eller ikke Hjelpetekst/tooltip for beskrivelse av hva som skal registreres i kontrollen. Om kontrollen kan være blank/uutfylt Om kontrollen skal kun være lesbar, ikke skrivbar Antall kolonner i gruppen kontrollen skal spanne over Om denne kontrollen representerer fratidspunkt for skjemaet/datasettet. Må være av typen Date eller DateTime Om denne kontrollen representerer tiltidspunkt for skjemaet/datasettet. Må være av typen Date eller DateTime 1 n True/false Teskstreng True/false True/false 1 n True/false True/false Standardverdi Standard verdi Tekstreng -34-

191 Attributt Beskrivelse Eksempel CaptionWidth Bredde på labelen 70px 100% 80% 220 ControlWidth Bredde på selve kontrollen 100px Indent TabIndex FlowIndex Om det skal legges en indent (innrykking) på kontrollen. Brukes for å visualisere sammenheng mellom kontroller Tabrekkefølge. Hvis blankt følges default tabbing. Rekkefølge på kontroll for sortering. Brukes foreløpig ikke. 70px 70 True/false 1 n 1 n 4.3 Definisjon av DataSettType En DataSettType (DST) består av et sett med parametre som igjen kan ha ulike alternativer. Det er settet av parametre som danner grunnlaget for hva som kan registreres i systemet, og hva som igjen vil være tilgjengelig for rapportering. Det er mulig å ha flere DST er i et register, men som regel vil det bare være en. Dette bla fordi rapporter ikke kan gå på tvers av DST er. En DST består altså at et vilkårlig sett med parametre. En parameter har i tillegg til et løpenummer Navn, Datatype, Standardverdi, CopyRelated*, CopyParent*, samt Kommentar. I tillegg kan en sette opp ulike alternativer for et parameter. Disse har da Verdi, Navn, AlternativNummer (sortering), samt gyldighet fra-til CopyParent og CopyRelated De to mest fornulige attributtene i parametertabellen er nok CopyRelated og CopyParent. Dette er en mekanisme som gjør det mulig å kopiere verdier på tvers av relaterte datasett, og er i nær tilknytning til parent- og related skjema som beskrevet under Skjema og utforming. Det man sier ved å sette true på CopyRelated og/eller CopyParent er at verdien som er fylt inn i hovedskjemaet (som det relaterte skjemaet linkes til) vil bli kopiert over i underskjemaet (eller det relaterte skjemaet/datasettet). Dette gjør at en slipper å fylle inn verdier flere ganger, og en får konsistente data datasettene imellom. For eksempel hvis man har et relatert skjema hvor en ønsker å ha med symptomtidspunkt registrert i hovedskjemaet. Da kan ved å sette true på CopyRelated på symptomtidspunktparameteret autamtisk få kopiert over symtomtidspunkt fra hovedskjemaet når en oppretter oppfølgingsskjemaet. Dette er en mekanisme som også brukes under rapportering. En kan da få opp en relatert verdi på en rapport uavhengig om den er fylt ut i selve skjemaet. Dette er en funksjonalitet som har blitt etterspurt av kunden, og som det derfor har blitt utviklet en slik spesialløsning på. -35-

192 4.3.2 Databseelementer: Definisjon av DataSettType DataSettType Attributt Beskrivelse Eksempel DataSettTypeID Løpenummer i databasen 1 n DataSettTypeKey RegisterKode Unik kode som identifiserer hvilken datasetttype det er. Hvilket register datasettypen hører til. HJERTE_DST_01 SLAG_DST_01 HJERTE_01 Navn Navn på datasettypen Hjerteinfarkt Beskrivelse Beskrivelse av datasetttypen. Tekststreng RegionSpesifikk Om datasettypen skal være regionspesifikk altså bare gjelde for en spesifikk region. RegionKode Hvis refgionspesifikk regionkode HMN HFSpesifikk Om datasettypen skal være spesifikk for et helseforetak altså bare gjelde for et spesifikkt helseforetak. True/false True/false HelseforetakKode Hvis hfspesifikk hfkode STOH SykehusSpesifikk Om datasettypen skal være sykehysspesifikk altså bare gjelde for et spesifikkt sykehus. SykehusKode Hvis sykehusspesifikk sykehuskode True/false HMN Aktiv Om datasettypen er aktiv True/false Parameter Attributt Beskrivelse Eksempel ParameterID Løpenummer i databasen 1 n ParameterKey Nøkkel som unikt identifiserer parameteren. Tekststreng Navn Unikt navn på parameter Tekststreng RapportNavn DatasettTypeID Datatype Navn som kommer opp på rapporter (dumprapport). Typsik en kortere variant enn fullt navn. ID på datasettet parameteren hører under. Hvilken datatype parameteren skal være av Tekststreng 1 n String DateTime Bool Numeric Standardverdi Standardverdi for parameteren Tekststreng IkkeBlank Om parameteren kan være blank True/false CopyParent CopyRelated GyldigFraOgMed GyldigTilOgMed Om paremateren skal kopieres fra et parent datasett. Om parameteren skal kopieres fra et relatert datasett. Dato for når parameteren er gyldig fra Dato for når parameteren er gyldig til Int True/false True/false Kommentar Kommentar til parameteren Tekstreng -36-

193 Alternativ Attributt Beskrivelse Eksempel AlternativID Løpenummer i databasen 1 n ParameterID AlternativKey Verdi Tekst AlterativNummer GyldigFraOgMed GyldigTilOgMed Filter ID på parameter alternativet hører til Nøkkel som unikt identifiserer alternativet. Verdi for alternativet (det som blir lagret) Tekst for alternativet (det som vises i GUI) Brukes til sortering av alternativene Dato for når alternativet er gyldig fra Dato for når alternativet er gyldig til Hvis alternativet er avhengig av at en annen verdi er satt brukes dette feltet for å sette denne verdien. Brukes i forbindelse med Ajax. 1 n Tekststreng Tekststreng Tekststreng 1 n Tekststreng 4.4 Lagring av data og kobling mot pasient Som nevnt i kapittel Avidentifisering/anonymisering av data, samt i Feil! Fant ikke referansekilden. - Feil! Fant ikke referansekilden. lagres ikke pasientopplysninger i MRS-databasen. Vi skal nå gå litt nærmere inn på hvordan koblingen mellom data og pasienter gjøres i databasen. Som vi ser av figuren er det lagt opp til en hierarkisk oppbygging, med kvalitetsregister på topp og helt ned til verdi på bunn. Et kvalitetsregister består av mange pasienter, hver pasient kan ha flere kontakter (sykdomstilfeller) hvor det på hver kan lagres flere ulike datasett bestående av et vilkålig antall verdier. -37-

194 Kvalitetsregister PasientIKvalitetsregister Kontakt DataSett Verdi ID ID ID DataSettID VerdiID RegisterKode RegionKode RegionKode RegisterKode Verdi Navn HelseforetakKode HelseforetakKode DataSettTypeID DataSettID Beskrivelse SykehusKode SykehusKode DataSettTypeKey ParameterID GyldigFra RegisterKode AvdelingsKode SkjemaID SistOppdatert GyldigTil ExternalID Navn SkjemaTypeKey Brukerkonto Opprettet ExternalIDType ExternalKontaktID KontaktID IsDefault PasientPseudonym ExternalKontaktType StatusID Kommentar PasientIKvalitetsregisterID ParentID FraDato RelatedID TilDato Pasientnummer VisNavn RegistreringsRegion VisFra RegistreringsHF VisTil RegistreringsSykehus StatusID RegistreringsAvdeling Kommentar OpprettetDato Aktiv Aktiv Datasett Som vi ser er det kun data via datasettet som inneholder de faktiske pasientopplysningene. Et datasett er en ren mapping fra alle parametrene som er med i et skjema. Dvs alle kontrollene koblet mot et parameter som er med i skjemaet. Hver verdi i et datasett vil da være koblet mot en spesiell parameter definert i DataSettTypen datasettet er av. Datasettet blir igjen koblet mot region, hf og sykehus slik at en har kontroll på hvor dhvert datasett hører hjemme. Avhengig om datsettet (skjemaet) er ferdigstilt (lukket) eller i kladd vil datasettet ha ulik status. Dette er satt i feltet StatusID. Videre registreres hvilket skjema datasettet er registrert med samt eventuelle relaterte eller parent datasett. Se Underskjema og relaterte skjema for mer om relaterte skjema. Relaterte skjema vil da resultere i relaterte datasett Kobling av datasett mot pasient Som vi ser av Feil! Fant ikke referansekilden. er datasett koblet mot pasienter via den kontakten det er registrert under, som videre er koblet mot en pasient i tabellen PasientIKvalitetsregister. Når en pasient blir opprettet i PasientIKvalitetsregister lagres løpenummer, samt hvilken region, hf og sykehus det er snakk om. Dette medfører at selv om det er en og samme fysiske person som blir registrert via to forskjellige sykehus vil det bli to ulike innslag i tabellen. Pasienten vil da få to ulike løpenummer, som igjen er det som da vises til brukeren og som eventuelt taes med på rapporter. Grunnen til at en ønsker å vise et løpenummer for en pasient er at en trenger dette bla for å kunne telle opp antall unike pasienter i systemet for eksempel med en spesifikk diagnose. Dette vil bli riktig hvis en teller opp lokalt pr. sykehus, men kan være en feilkilde når en teller opp regionalt eller nasjonalt. Systemet er implementert på denne måten pga de sikkerhetsmessige aspektene vedrørende at en ikke skal kunne gjennkjenne pasienter på tvers av de juridiske enhetene. -38-

195 Den eneste indikasjon/kobling mot hvliken pasient det er snakk om er via ExternalID og ExternalIDType. Dette er en id som brukes som integrasjonsnøkkel mot det eksterne pasientsystemet. ExternalID er da en id som i utgangspunktet kun er kjent for det eksterne systemet, og med mindre det eksterne systemet bruker personnummer som id vil ikke denne kunne identifisere pasienten. I Helse Midt-Norge er det eksterne pasientsystemet PAS, levert av TietoEnator. ID en dette systemet bruker er ikke personidentifiserbar, men en har mulighet til å søke opp hvilken pasient det er snakk om hvis en har tilgang til den spesifikke pasienten via PAS. Dette kan være brukere som ikke er brukere av selve registeret. På bakgrunn av dette vises aldri den eksterne ID en til brukeren, og det er kun løpenummer som brukes på rapporter og i systemet generelt Databseelementer: Lagring av data og kobling mot pasient Kvalitetsregister Attributt Beskrivelse Eksempel ID Løpenummer i databasen 1 n RegisterKode Unik kode som identifiserer hvilket kvalitetsregiseter det er. HJERTE_01 SLAG_01 Navn Navn på register Hjerteinfarktregister Beskrivelse Beskrivelse av registeret. Tekststreng GyldigFra GyldigTil Opprettet IsDefault Dato kvalitetsregisteret er gyldig fra. Dato kvalitetsregisteret er gyldig til. Dato for når registeret ble opprettet. Om dette er det gjeldende kvalitetsregisteret /1 PasientIKvalitetsregister Attributt Beskrivelse Eksempel ID Løpenummer i databasen 1 n RegionKode HelseforetakKode SykehusKode RegisterKode Unik kode som identifiserer regionen. Unik kode som identifiserer helseforetaket. Unik kode som identifiserer sykehuset. Kode som kobler pasienten mot et spesifikt kvalitetsregister. HMN HNT STOH STOH HJERTE_01 SLAG_01 ExternalID ID i eksternt pasientsystem Kan være både tall og bosktaver. Maks lengde 255. Avhengig av hva som brukes i eksternt system. ExternalIDType PasientPseudonym Kommentar Hvilket type eksternt pasientsystem som brukes. Pseudonym som følger pasienten innenfor et HF. Mulighet for å legge kommentar om pasienten. Tekststreng STOLAV: Tekststreng -39-

196 Kontakt Attributt Beskrivelse Eksempel ID Løpenummer i databasen 1 n RegionKode HelseforetakKode SykehusKode AvdelingKode Unik kode som identifiserer regionen. Unik kode som identifiserer helseforetaket. Unik kode som identifiserer sykehuset. Unik kode som identifiserer avdelingen kontrakten hører under. Navn Navn/tittel på kontakten / sykdomstilfellet. ExternalKontaktID ExternalKontaktType PasientIKvalitetsregisterID ID i kontakt i eksternt pasientsystem. For eksempel om kontakten skal kobles til et spesifikt opphold. (Brukes ikke i dag). Hvilket type eksternt pasientsystem som brukes. ID til pasienten i PasientIKvalitetsregistertabellen. HMN HNT STOH STOH KIR Hjerteinfarkt Kan være både tall og bosktaver. Maks lengde 255. Avhengig av hva som brukes i eksternt system. PAS 1 n FraDato Dato kontakten gjelder fra TilDato Dato kontakten gjelder til VisNavn VisFra VisTil StatusID Om en skal vise navnet/tittelen på kontakten i GUI Om en skal vise fradato på kontakten i GUI Om en skal vise tildato på kontakten i GUI Hvilken status kontakten har. Brukes ikke. True/false True/false True/false Kommentar Kommentar for kontrakten. Tekststreng Aktiv Om kantakten er aktiv eller ikke. Brukes istedenfor å slette kontakter. True/false DataSett Attributt Beskrivelse Eksempel DataSettID Løpenummer i databasen 1 n RegisterKode DataSettTypeID DataSettTypeKey SkjemaID SkjemaTypeKey KontaktID Kobling mot hvilket register datasettet fører inn under. ID som identifiserer hvilken DataSettType datasettet er av. Nøkkel som identifiserer hvilken DataSettType datasettet er av. Kobling mot hvilket skjema datasettet ble registrert med. Kobling mot hvilket skjema datasettet ble registrert med. ID til kontakten datasettet hører inn under. HJERTE_01 1 n HJERTE_DST_01 1 n HJERTE_DST_01_HOVED_01 StatusID Hvilken status datasettet har. 1 = Kladd 2 = Lukket (Ferdigstilt) ParentID Om datasettet har et parent datasett settes ID til dette her. 1 n 1 n -40-

197 Attributt Beskrivelse Eksempel RelatedD Pasientnummer RegistreringsRegion RegistreringsHF RegistreringsSykehus RegistreringsAvdeling Om datasettet har et relatert datasett settes ID til dette her. Sammenstilt løpenummer for pasienten. Sammensatt løpenummer for pasienten. Består av regionnr, hfnr, sykehusnr samt pasientløpenummer i databasen. Unik kode som identifiserer hvilken region datasettet er registrert under. Unik kode som identifiserer hvilket HF datasettet er registrert under. Unik kode som identifiserer hvilket sykehus datasettet er registrert under. Unik kode som identifiserer hvilket avdeling datasettet er registrert under. Navn Navn/tittel på kontakten / sykdomstilfellet. OpprettetDato Aktiv Dato for når datasettet ble opprettet. Om datsettet er aktiv eller ikke. Brukes istedenfor å slette datasettet. 1 n HMN HNT STOH STOH KIR Hjerteinfarkttilfelle True/false Verdi Attributt Beskrivelse Eksempel VerdiID Løpenummer i databasen 1 n Verdi Selve verdien parameteret har xxxxxxxxx DataSettID ParameterID SistOppdatert Brukerkonto Kobling mot hvilket datasett verdien hører under. ID som identifiserer hvilken parameter verdien hører til. Dato for når verdien ble oppdatert. Brukerkonto for personen som sist oppdaterte verdien 1 n 1 n STOLAV\mape 4.5 Logging I og med at de registrene som er opprettet til nå betegnes som behandlingsrettede / forskningsregister lokalt (innen for helseforetaket), kreves det logging og historikk. MRS har derfor en omfattende intern logg for lesing, opprettelse, endring, ferdigstilling, gjenåpning og sletting av skjema. Videre logges det opprettelse, endring og sletting av pasienter og kontakter (sykdomstilfeller). Logging skjer i tabellene LoggHendelse og LoggLesing. I tillegg logges hver innlogging i systemet. -41-

198 4.5.1 Databaseelementer: Logging LoggHendelse Attributt Beskrivelse Eksempel ID Løpenummer i databasen 1 n EndringstypeID Hvilken type endreing det er. - Opprettelse DataSettID KontaktID PasientID Brukerkonto ID til datasett (skjema), hvis det er gjort en endring på datasettet. ID til kontakten (sykdoomstilfellet), hvis det er gjort endring på kontakten. ID til pasienten det har blitt gjort en endring under/på. AD brukerkonto til personen som har gjort endringen. - Endring - DataSett satt inaktivt - Fullstendig sletting - Gjenåpning 1 n 1-n 1 n Brukernavn AD brukernavnet uten prefiks. Funk Brukerprofil Hvilken tilgangprofil brukeren brukten når hendelsen inntraff STOLAV\Funk Funk Tidspunkt Tidspunkt endringen er gjort LoggLesing Attributt Beskrivelse Eksempel ID Løpenummer i databasen 1 n DataSettID PasientID KontaktID Brukerkonto ID til datasett (skjema) brukeren har lest. ID til pasienten det har blitt lest på. ID til kontakten (sykdomstilfellet) det har blitt lest på. AD brukerkonto til personen som har lest. 1 n 1 n 1 n Brukernavn AD brukernavnet uten prefiks. Funk Brukerprofil Hvilken tilgangprofil brukeren brukten når hendelsen inntraff STOLAV\Funk Funk Tidspunkt Tidspunkt for lesingen Logins Attributt Beskrivelse Eksempel ID Løpenummer i databasen 1 n Brukerkonto AD brukerkonto til personen som har logget inn. Brukernavn AD brukernavnet uten prefiks. Funk STOLAV\Funk Navn Fullt navn til brukeren. Unkel, Frank Fornavn Fornavn til brukeren. Frank Etternavn Etternavn til brukeren. Unkel Tittel Tittel Konsulent Region Hvilken region brukeren er ansatt under. Helse Midt-Norge -42-

199 Attributt Beskrivelse Eksempel RegionNummer RegionKode Helseforetak HelseforetakNummer HelseforetakKode Sykehus SykehusNummer SykehusKode Avdeling AvdelingNummer AvdelingsKode PasCslSection Regionnummer for regionen brukeren er ansatt under. Regionkode for regionen brukeren er ansatt under. Helseforetak brukeren er ansatt under. Helseforetaknummer til helseforetaket brukeren er ansatt under. Helseforetakkode til helseforetaket brukeren er ansatt under. Hvilet sykehus brukeren er ansatt på. Sykehusnummer på sykehuset brukeren er ansatt på. Sykehuskode på sykehuset brukeren er ansatt på. Hovedavdeling brukeren er ansatt under. Avdelingsnummer på avdelingen brukeren hovedsakelig er ansatt under. Avdelingskode på avdelingen brukeren hovedsakelig er ansatt under. Hvilken PAS seksjon brukeren hører til. (Helse Midt-Norge spesifikt) 1 HMN St. Olavs Hospital HF (STOH) 1 STOH St. Olavs Hospital 1 STOH Hjertemed 1 HJMED TR_PAS Innlogget Tidspunkt for innloggingen :01:10 Utlogget Evt. tidspunkt for utlogging :03: Oppsett av MRS Instans Hver installasjon av MRS krever at en setter opp en MRS instans i databasen. Denne inneholder en del spesifikke parametre som kun er gjeldene for denne installasjonen av systemet. Bla velger man hvilke css er som skal brukes som igjen styrer layout, logoer og lignende på selve web siden. I tillegg definerer en opp om en skal bruke en intern eller en ekstern pasientdatabase Databaseelementer: Oppsett av MRS Instans MrsInstans Attributt Beskrivelse Eksempel ID Løpenummer i databasen 1 n InstansNavn Internt navn på instansen Hjerteinfarkt DisplayName RegisterKode Navn som vises på skjerm, bla i tittelen på webapplikasjonen. ID til kvalitetsregistert instansen hører til. MRS Hjerteinfarkt HJERTE_01 ApplicationName Navn i kobling mot AzMan MRS-Hjerteinfarktregister AppCssPath Lenke til applikasjonsspesifikk css fil som gir instansen rett logo og lignende. css/apps/hjerteinfarkt_hmn/ app.css -43-

200 Attributt Beskrivelse Eksempel ThemeCssPath Lenke til default css som definerer fargeoppsett på instansen. css/themes/blue/ MrsBlue.css Velkomsttekst Velkomsttekst på forsiden, topp <H1>Velkommen</H1><P>Velkommen til Hjerteinfarktregisteret, et medisinsk kvalitetsregister for Midtfelttekst Generell tekst på forsiden, midten <P><I>Medisinske kvalitetsregistre</i> inneholder opplysninger på individnivå om diagnoser, Nyhetstekst Nyheter på forsiden, bunn <h3>info</h3> <p>- Dette er en pilot av hjerteinfarktregisteret<br> PathBrukermanual Lenker Lenke til eventuell brukermanual spesifikk for instansen. Spesifikke lenker som er aktuelle for instansen Session_timeout Tid før en session går ut 120 ShowThemePicker StdFeilmelding TlfKundesenter IsDefault Om det skal være mulig å endre farge/utseende for brukeren Standard feilmelding som hektes på feilmeldinger i registeret. Telefonnummer til lokalt kundesenter. Brukes til å hekte på feilmeldinger. Om denne MRSInstansen er gjeldende MRSInstans - Registreringer er reelle<br> - Ved første gangs bruk css/apps/hjerteinfarkt_hmn/brukermanual.pdf - <a href= >Medinfo</a> <br>- <a href= > Medinfo2</a> True/false Hvis problemet er vedvarende, vennligst ta kontakt med ditt lokale kundesenter, tlf (0) (0) True/false -44-

201 5. Rammeverk for utvikling Dette dokumentet beskriver den felles kodebasen som skal brukes i MRS. 5.1 Krav til utviklingsmiljø Utvikleren må sitte i et Microsoft-miljø, med enten Windows 2003 Server, Microsoft XP, eller Windows Vista som operativsystem. Utvikling foregår i Visual Studio 2005 eller 2008 og krever.net 2.0 innstallert på maskinen. Utvikleren kan selv velge om han ønsker å bruke lokal database, eller en database på en server satt opp til utviklingsformål. Databaseserveren må være MS SQL 2005, standard eller høyere. Utviklingsmaskinen må være koblet til intranett, og ha tilgang til SourceSafe serveren, som pr i dag ligger på trmnhappsvr02 ( ). 5.2 Automatisk bygging Automatisk bygging settes opp i eget testmiljø av virtuelle maskiner for MRS (TRMNHVSUTV01). Selve byggingen skjer da på den virtuelle serveren BUILDSERVER installert her. Prosjekter som er satt opp er da tilgjengelig på For å få tilgang må buildserver være tilgjengelig via nettverket, samt legges til i unntak under proxy-innstillinger i Internet Explorer slik at den blir håndtert som innenfor intranettet. Byggingen skjer automatisk når det har kommet endringer i SourceSafe, og alle tester kjøres. Testrapport publiseres, og det er mulig for prosjektdeltagere å få mail dersom noen av testene feiler. Disse verktøyene brukes på byggeserveren Komponent Link Beskrivelse CruiceControl.NET Applikasjon som overvåker kildekode og bygger på nytt når endringer er oppdaget. NAnt System for å utføre oppgaver basert på en XML-beskrivelse. Nunit Rammeverk for enhetstesting i.net 5.3 SourceSafe MRS 2.0 bruker SourceSafe 2005 for håndtering av kildekodekontroll. For å bruke denne må du få opprettet en egen bruker med tilgang til kildekoden. Denne opprettes via SourceSafe s administrasjonsgui. Selve MRS koden ligger videre under rotkatalogen $/Hemit/Mrs/Mrs 2.0. Oppsettet av de ulike registrene kan samtidig også finnes under en egen solution i Source Safe under $/Hemit/Mrs/Mrs-Config. Dette er filene som inneholder beskrivelser av DataSettType, validreinger, kontrollskript og skjema til de ulke kvalitetsregistrene. -45-

202 For å koble opp mot sourcesafe er det beste å mappe opp disken hvor selve kildekodekontrollen ligger \\trmnhappsvr02\sourcesafe2005 og koble mot srcsafe.src filen derfra. Se for øvrig Retningslinjer for bruk av SourceSafe. 5.4 Testservere Som nevnt over er det satt opp et eget testmiljø for MRS. Dette inneholder en rekke virtuelle servere, og skal simulere det miljø MRS kan bli installert under. Selve hosten for det virteuelle miljøet heter TRMNHVSUTV01, og oppsettet av de virtuelle serverne kan finnes på adressen: Vi skal her kort gå gjennom de ulike serverne i testmiljøet MRS-BuildServer Denne har vi gått gjennom ovenfor, og er den som holder orden på automatisk bygging av MRS. Her bygges også setupfiler som alltid vil være oppdatert i forhold til siste innsjekking som går gjennom. Byggeserveren står i hemit-domenet og er tilgjengelig fra intranettet MRS-DCTest Dette er en domeneserver som simulerer topp-ad i et AD-tre. Eneste som kjører på denne serveren er Active Directory, og serveren må kjøre for at testmiljøet skal være oppe å gå (forutenom byggeserveren som er uavhengig av dette domenet) MRS-DCAlfa Dette er på samme måte som MRS-DCTest en domeneserver, i et domenetre (forest). MRS-ACAlfa ligger under MRS-DCTest i den strukturen, og er det domenet applikasjon og databaseserverne meldes inn i. I helse midt-norge simulerer dette domenet hemitdomenet. MRS-DCAlfa kan ikke taes ned om testmiljøet skal være oppe å gå MRS-DCBeta Dette er også en domeneserver, som ligger på samme nivå som MRS-DCAlfa, under MRS-DCTest. Dette er domenet selve klientene blir meldt inn i. I helse midt-norge simulerer dette domenet hf-domenene, for eksempel stolav-domenet. MRS-DCBeta kan ikke taes ned om testmiljøet skal være oppe å gå. -46-

203 5.4.5 MRS-FAT Web Server Dette er selve webserveren i testoppsettet, og simulerer en webserver i et produksjonsmiljø. Webserveren er det øverste laget i en trelags fysisk arkitektur, og er den klientene skal koble seg mot og ha tilgang til. På webserveren installeres selve MRS web-applikasjonen, som igjen gjør sine kall enten mot webtjenesten som installeres på applikasjonsserveren, eller direkte mot databasen som ligger på databaseserveren. Dette er som vi har vært inne på tidligere et konfigurasjonsoppsett. MRS-FAT Web Server kan ikke taes ned om MRS-applikasjonen skal være tilgjengelig i testmiljøet. MRS-FAT Web Server er meldt inn i Alfa-domenet, som kjører på MRS-DCAlfa MRS-FAT App Server Dette er applikasjonserveren i testoppsettet, og simulerer en applikasjonserver i et produksjonsmiljø. Appserveren er det mellomste laget i en trelags fusisk arkitektur, og det er her webtjenestene skal installeres. Om en velger å ikke bruke 3-lags arkitektur, trengs ikke webtjensten installeres, og dermed trengs heller ikke denne serveren å kjøre ved et slikt oppsett. MRS-FAT App Server er meldt inn i Alfa-domenet, som kjører på MRS-DCAlfa MRS-FAT Database Server Dette er databaseserveren i testoppsettet, og simulerer en databaseserver i et produksjonsmiljø. Serveren har installert MS SQL 2005 og det er her MRS databasen legges. I tillegg er også Reporting Services lagt inn på denne serveren, noe som også betyr at serveren kjører IIS for å hoste disse. I et reelt produksjonsmiljø må en kunne forvente at rapportserveren i enkelte miljøer vil være en annen server enn selve databaseserveren. Så skal en simulere dette, bør en opprette en ny virtuell server kun for håndtering av rapporter. MRS-FAT Database Server er meldt inn i Alfa-domenet, som kjører på MRS-DCAlfa MRS-Test Klient 1, 2 og 3 Dette er tre testklienter som er satt opp med Windows XP, for å kjøre test mot registeret. Klientene skal simulere de aktuelle klientene ute på sykehuset, og bør være satt på samme måte som disse. Hvis en skal teste mot et spesifikt xp-image for eksempel, kan det være lurt å opprette en ny slik klient for akkurat dette imaget. Også hvis det er spesifikke oppsett enkelte sykehus har på sine klienter bør disse settes opp som egne klienter. Videre bør en gjøre et valg ut i fra om klienten skal være i samme domene som applikasjonsserverene (alfa), eller om de skal være i et eget (beta), slik det for eksempel er i helse midt-norge. For en helse midt-norge test bør da altså klientene ligge i betadomenet. -47-

204 5.4.9 Utvidelse av testoppsettet Som vi har vært inne på bør det opprettes nye klienter for hvert ulike klientoppsett som skal testes mot MRS systemet. Dette er for å simulere de ulike oppsettene en kan ha på klientsiden. Men også for serversiden bør en gjøre dette. Hvis for eksempel MRS skal installeres i et miljø som er veldig ulikt det som er i Helse Midt-Norge (som er utgangspunktet for testoppsettet), bør en lage en ny rig som simulerer dette. I enkelte tilfeller vil det kanskje bare være webserveren som er forskjellig fra Helse Midt-Norge sitt oppsett, i andere tilfeller større forskjeller. Uansett bør systemet testes i alle mulige oppsett systemet skal bli installert under, og denne testserveren (TRMNHVSUTV01) er et bra sted å gjøre dette på. For å sørge for god nok ytelse bør en generelt ta ned de serverene en da ikke bruker under den gjeldende testen. Dette gjelder også klientmaskiner som står ubrukt. Det er kun når disse brukes til testing at disse bør være påslått. Hvis en bare skal ta ned en server for en liten stund, uten at omgivelsene rundt blir endret, kan det være en fordel å bare slå av maskien ved bruk av save state. Men hvis en planlegger endringer i for eksempel domene eller lignende kan det være en fordel å slå disse helt av, slik at det ikke blir problemer når en skal gjenoppstå fra en tilstand (state). -48-

205 6. Retningslinjer for utvikling Dette dokumentet inneholder de regler og valg som er gjort for ifht. den koden som skal skrives i systemet. 6.1 Kildekodestandard Dette kapttelet beskriver standard for programmering og navnekonvensjoner i MRS Ordliste Camel casing Pascal casing Første bokstav i navnet er liten, stor bokstav brukes for hvert nytt ord minvariabel, minklasse Stor bokstav brukes for hvert nytt ord MinVariable, MinKlasse, MinFunksjon Navngiving Denne lista er noe modifisert, men hovedtrekkene er tatt fra Type Standard Example Solution File Project File Source File Namespaces Assemblies Classes and Structs Pascal Case. Always match Solution Name & Root Namespace. Pascal Case. Always match Assembly Name & Root Namespace. Pascal Case Always match Class name and file name Pascal Case, no underscores. Use Hemit.TechnologyName as root. If the assembly contains a single name space, or has an entire self-contained root namespace, name the assembly the same name as the namespace. Pascal Case, no underscores or leading C or cls. Classes may Hemit.Mrs.sln namespace Hemit.Mrs MrsWS.csproj Hemit.Mrs.ServiceInterfaces.MrsWS.dll -> namespace Hemit.Mrs.ServiceInterfaces.MrsWS MyClass.cs public class MyClass Hemit.Mrs.BusinessRules Hemit.SingleSignOn.MyClass Hemit.Idm.MyClass AppliedIS.TimeCard.BusinessRules.dll IrritatedVowel.Controllers.dll Widget InstanceManager XmlDocument -49-

206 Collection Classes Delegate Classes Exception Classes Attribute Classes Interfaces Enumerations Functions and Subs Properties and Public * Member Variables begin with an I only if the letter following the I is not capitalized; otherwise it looks like an Interface. Classes should not have the same name as the namespace in which they reside. Any acronyms of three or more letters should be Pascal case, not all caps. Try to avoid abbreviations, and try to always use nouns. Follow class naming conventions, but add Collection to the end of the name Follow class naming conventions, but add Delegate to the end of the name Follow class naming conventions, but add Exception to the end of the name Follow class naming conventions, but add Attribute to the end of the name Follow class naming conventions, but start the name with I and capitalize the letter following the I Follow class naming conventions. Do not add Enum to the end of the enumeration name. If the enumeration represents a set of bitwise flags, end the name with a plural. Pascal Case, no underscores except in the event handlers. Try to avoid abbreviations. Many programmers have a nasty habit of overly abbreviating everything. This should be discouraged. Functions and subs must differ by more than case to be usable from case-insensitive languages like Visual Basic.NET Pascal Case, no underscores. Try to avoid abbreviations. Members must differ by more than case to be usable from case-insensitive languages like Visual Basic.NET. MainForm DocumentForm HeaderControl CustomerListDataSet (typed dataset) WidgetCollection WidgetCallbackDelegate InvalidTransactionException WebServiceAttribute IWidget SearchOptions (bitwise flags) AcceptRejectRule (normal enum) VB: Public Sub DoSomething(...) C#: public void DoSomething(...) VB: Public Property RecordID As Integer C#: public int RecordID -50-

207 Parameters -51- Procedure- Level Variables Class-Level Private and Protected Variables Controls on Forms Camel Case. Try to avoid abbreviations. Parameters must differ by more than case to be usable from case-insensitive languages like Visual Basic.NET. Camel Case Camel Case with Leading Underscore, do not use m_. Modified Hungarian Using.NET Class Names VB: ByRef recordid As Integer C#: ref int recorded VB: Dim recordid As Integer C#: int recordid ; VB: Private _recordid As Integer C#: private int _recordid ; txtuserid, lblheader, lstchoices, btnsubmit Kommentarer 1. Alle kommentarer skal skrives på norsk 2. Bruk // for å kommentere enkelt linje, eller /* */ for å kommentere en blokk som går over flere linjer. 3. Bruk prefiksing av kommentarer slik at disse kan vises i oppgavelisten a. // TODO b. // UNDONE c. // HACK Alle klasser, public metoder og parametre må beskrives. 6.2 Feilhåndtering Alle feil som oppstår i kode skal generere unntak. Det er opp til unntaksbehandleren 1 å eventuelt logge feilsituasjonen. Det er tre hovedmåter å behandle unntak på. Tatt fra 1. Let the exception propagate automatically With this approach, you do nothing and deliberately ignore the exception. This causes the control to move immediately from the current code block up the call stack until a catch block with a filter that matches the exception type is found. 2. Catch and rethrow the exception With this approach, you catch and react to the exception, and clean up or perform any other required processing within the scope of the current method. If you cannot recover from the exception, you rethrow the same exception to your caller. 3. Catch, wrap, and throw the wrapped exception As an exception propagates up the call stack, the exception type becomes less relevant. When an exception is wrapped, a more relevant exception can be returned to the caller. This is illustrated in Figure 4. With this approach, you catch 1 Unntaksbehandler i Microsoft Exception Application Block

208 the exception, which allows you to react to it, clean up, or perform any other required processing within the scope of the current method. If you cannot recover, wrap the exception in a new exception, and throw the new exception back to the caller. The InnerException property of the Exception class explicitly allows you to preserve a previously caught exception. This allows the original exception to be wrapped as an inner exception inside a new and more relevant outer exception. The InnerException property is set in the constructor of an exception class. Denne figuren viser hvordan et unntak blir fanget av B(), ekstra informasjon blir lagt til og unntaket sendes videre til A(). Feil! Ukjent bryterargument. 6.3 Enhetstesting Det skal utarbeides tester for alle klasser når disse implementeres. Det skal lages tester som tester et sett med gyldige verdier, og et sett med ugyldige verdier. Disse skal da returnere et unntak. Følgende eksempler er tatt fra Eksempel Oppsett Det lages en egen testklasse. Denne kan se slik ut: namespace NUnit.Tests { using System; using NUnit.Framework; } [TestFixture] public class SuccessTests { //... } Sammenligning Assert.AreEqual( int expected, int actual ); Assert.AreEqual( decimal expected, decimal actual ); Assert.AreEqual( float expected, float actual, float tolerance ); Assert.AreEqual( double expected, double actual, double tolerance ); Assert.AreEqual( object expected, object actual ); -52-

209 Assert.AreSame( object expected, object actual ); Tilstand Assert.IsTrue( bool condition ); Assert.IsTrue( bool condition, string message ); Assert.IsTrue( bool condition, string message, object[] parms ); Assert.IsFalse( bool condition); Assert.IsFalse( bool condition, string message ); Assert.IsFalse( bool condition, string message, object[] parms ); Assert.IsNull( object anobject ); Assert.IsNull( object anobject, string message ); Assert.IsNull( object anobject, string message, object[] parms ); Assert.IsNotNull( object anobject ); Assert.IsNotNull( object anobject, string message ); Assert.IsNotNull( object anobject, string message, object[] parms ); Unntak namespace NUnit.Tests { using System; using NUnit.Framework; [TestFixture] public class SuccessTests { [Test] [ExpectedException(typeof(InvalidOperationException))] public void ExpectAnException() { /*... */ } } } -53-

210 6.4 Retningslinjer for bruk av SourceSafe Under følger en del leveregler ved bruk av sourcesafe. Disse gjelder spesielt for prosjekter hvor en er flere utviklere som jobber mot samme koden. Sjekk ikke ut kode du v sel ikke skal jobbe på. Skriv kommentarer på /endret ny kode når du sjekker inn. Kjør alltid Get Latest før u sjekker d inn kode, slik at du vet at koden du sjekker inn kompilerer med det som ligger i kildekodekontrollen. Aldri sjekk ut solution prosjektfiler og over lengre tid. Hvis du for eksempel må legge til en klasse til et prosjekt; sjekk ut prosjektet og legg til den tomme filen, sjekk inn prosjektet og den tomme filen begynn så å jobbe med kun den filen du skal jobbe med utsjekket. Ikke la det gå for lang tidmellom hver gang du sjekker inn kode. Helst hver dag før du går fra jobb. Du vet aldri når du detter på sykkelen og blir borte noen dager. Alltid sjekk inn all kode før planlagt fravær. Om det er flere som skal jobbe mot samme klasse; lag en partial class slik at hver får sin fil de kan sjekke ut å jobbe mot. Her er videre dialog viktig, slik at man ikke ødelegger for hverandre. Ikke sjekk ut web- og.config ap filer for å gjøre lokale tilpasninger (for eksempel for å kjøre mot lokal database). Kun sjekk ut disse ved endringer i selve konfigfilene. Triks for å gjøre lokale tilpassninger: browse deg frem til hvor filen ligger på harddisken og fjern read only på filen. Du kan nå fritt endre på filen uten at du må sjekke den ut fra sourcesafe. 6.5 Versjonering Versjonering etableres på tre nivåer. Under utvikling vil det bli begrenset bruk for dette, hovedvekten av versjonering vil foregå i test- og produksjonssfase. Fullstendig installasjonsbeskrivelse og installasjonsskript gjøres tilgjengelig på releaseserver. Hovedsakelig deles versjoneringen inn i tre nivåer som følger: a) Hovedversjon b) Mellomversjon c) Feilretting Hovedversjon endres kun ved store endringer i systemet. Mellomversjonen endres når funksjonalitet legges til eller endres. Nivå 3 brukes kun ved veldig små endringer og retting av feil. Alle egenutviklede DLLer og EXEer som er en del av en release får samme versjonsnummer. -54-

211 Tillegg A: Microsoft Enterprise Library Enterprise Library er en samling av de applikasjonsblokker 2 som Microsoft mener er mest velegnet for enterprise utvikling. Til sammen består biblioteket av syv blokker. Hver av disse blokkene dekker separate problemdomener, men alle er bygget på de samme prinsippene. Dette gjør det enklere for utviklere å sette seg inn i bruken av de forskjellige blokkene. Blokkene inkluderer: Caching Application Block Configuration Application Block Data Access Application Block Crypthography Application Block Exception Handling Application Block Logging and Instrumentation Application Block Security Application Block Enterprise Library inkluderer også et grafisk verktøy, Enterprise Library Configuration, som gjør det enkelt å konfigurere applikasjoner for bruk av de forskjellige applikasjonsblokkene. Mange av blokkene benytter andre blokker. Disse avhengighetene innebærer at det i de fleste tilfeller vil være en fordel å installere hele Enterprise Library. A.1 Caching Application Block Denne blokka tilbyr en enkel måte å cache informasjon på. Den er ment å kunne brukes i de fleste typer applikasjoner (web/windows forms/com+ osv), og tilbyr konfigurerbar backingstore (f.eks SQL Server) for persistens. Blokka er trådsikker, ett applikasjonsdomene kan inneholde flere cacher, og alle parametre som styrer cachen (bl.a levetid og backingstore) er konfigurerbare. Minimalt kodeeksempel: productcache.add(product.productid, product, 2, null, new SlidingTime(TimeSpan.FromMinutes(5))); Product product = (Product) productcache.getdata(selectitemform.productid); A.2 Configuration Application Block Denne applikasjonsblokka tilbyr skriving og lesing av konfigurasjonsdata. Selve lagringa av dataene tilbys av storage providers, og kan konfigureres. Det er mulighet for å utvikle egne storage providers. Den største fordelen med denne blokka er at den gir mulighet for at konfigurasjonsdata kan behandles konsistent på tvers av applikasjoner, uten å måtte vurdere hvordan dette skal gjør for hvert enkelt prosjekt

212 Minimalt kodeeksempel: string constring = (string)configurationmanager.getconfiguration("connectionstring "); ConfigurationManager.WriteConfiguration("ConnectionString", constring) A.3 Data Access Application Block Data Access blokka forenkler de mest vanlige måter å aksessere datakilder på. Den har støtte for både Stored Procedures og in-line SQL. Den gjør altså bruken av ADO.NET både enklere, og mindre disponert for feil. I tillegg blir bruken av storageprovider abstraherert vekk, slik at koden enklere kan brukes for andre databasesystemer 3. Minimalt eksempel: Database db = DatabaseFactory.CreateDatabase(); using (IDataReader datareader { } = db.executereader(commandtype.text, "Select Name, Address, City From Customers" )) customergrid.datasource = datareader; customergrid.databind(); A.4 Cryptography Application Block Enterprise Cryptography Application Block forenkler de mest vanlige måter å anvende krytografi på i applikasjoner. Dette inkluderer kryptering og dekryptering av informasjon, hashing av data og lignende. I tilllegg til å gjøre bruken av krypto-metoder enklere og mer konsistent., er blokka konfigurerbar slik at forskjellige cryptography providers kan anvendes. Minimalt eksempel: byte[] valuetoencrypt = Encoding.Unicode.GetBytes("password"); byte[] encryptedcontents = Cryptographer.EncryptSymmetric("symmProvider", valuetoencrypt); stringtodecrypt = (new UnicodeEncoding()).GetString(encryptedContents); byte[] decryptedcontents = Cryptographer.DecryptSymmetric("symmProvider",stringToDecrypt); string plaintext = (new UnicodeEncoding()).GetString(decryptedContents); A.5 Exception Handling Application Block Denne blokka tilbyr en strukturert og konfigurerbar håndtering av unntak (exceptions) på tvers av applikasjoner. Dette innebærer følgende: Håndtering av unntak i catch{} klausuler implementeres i egne Exception Handlers. Disse handlerene implementers på tvers av applikasjoner, og vil derfor være konsistente. 3 Utstrakt bruk av stored procedures, som er tilfelle hos HEMIT, gjør dette til en mindre fordel. -56-

213 Handlerene assosieres med Exception Policies ved hjelp av en policy. Disse sier hvordan forskjellige unntakstyper skal håndteres av handlerne. Det kan finnes flere policies for en applikasjon. Det er inkludert tre Exception Handlere i blokka: Wrap Handler. Denne legger et unntak inn i et annet unntak. Replace Handler. Denne bytter ut et unntak med et annet.. Logging Handler. Denne formaterer informasjon fra unntaket, og sender resultatet videre til Logging and Instrumentation blokka. Se under for mer info om denne. Årsaken til at man har flere policies for den samme applikasjonen, er at man ofte vil at den samme type unntak skal håndteres forskjellig i forskellige lag av applikasjonen. For eksempel kan datalaget ønske å legge generelle unntak inn i en unntakstype laget for datalagen, mens man i grensesnittsslaget ønsker å bytte ut unntak med andre, mer brukervennlige, unntak. Minimalt eksempel: // Logger exceptionen catch(exception ex) { bool rethrow = ExceptionPolicy.HandleException(ex, "Logging Policy"); } if (rethrow) throw; A.6 Logging and Instrumentation Application Block The Logging and Instrumentation Block gir utviklerene en konsistent og enkel måte å logge og instrumentere koden på. Hendelser kan logges til forskjellige, konfigurerebare, mål. Disse inkluderer fil, database, event-logg, message queue og mer. I SOA Framework er det inkludert en hjelpeklasse for logging som benytter seg av log4net 4. Minimalt eksempel: LogEntry log = new LogEntry(); log.eventid = this.eventform.eventid; log.message = this.eventform.message; log.category = this.eventform.category; log.priority = this.eventform.priority; Logger.Write(log); A.7 Security Application Block Security Application Block tilbyr standariserte metoder for å håndtere autentisering, autorisasjon, håndtering av roller og profiler samt caching av sikkerhetsrelatert informasjon

214 Som for de andre applikasjonsblokkene er de fysiske sikkertstilbyderne (security providers) abstrahert vekk, og konfigureres ved kjøretid. Det følger blant annet med en tilbyder for AzMan. Minimalt eksempel: IRolesProvider rolesprovider = RolesFactory.GetRolesProvider("Roles Provider"); IPrincipal principal = this.rolesprovider.getroles(new GenericIdentity("Username")); if (principal!= null) { } bool isinrole = principal.isinrole("manager"); -58-

215 Norsk kvalitetsregister for LEPPE - KJEVE - GANESPALTE Informasjon til foreldre og foresatte

216 Norsk kvalitetsregister for leppe- kjeve- ganespalte Postadresse Norsk kvalitetsregister for leppe- kjeve- ganespalte Kirurgisk klinikk Haukeland Universitetssykehus 5021 Bergen E-post Internett Kontakttelefon: Kjære foreldre Vi ønsker å invitere deres barn til å delta i Norsk kvalitetsregister for leppe- kjeve- ganespalte (LKGregisteret). Et kvalitetsregister er et dataregister der fagpersoner kan dokumentere resultater for en pasientgruppe, med utgangspunkt i den enkelte pasient sitt behandlingsforløp. For at dere skal kunne ta stilling til om vi kan samle data om deres barn i registeret, vil vi forklare hvorfor registeret er opprettet og hva deltakelse vil innebære for dere. Å registrere seg i Norsk kvalitetsregister for leppe- kjeve- ganespalte er frivillig og krever skriftlig samtykke. Dette betyr at du må undertegne en samtykkeerklæring før barnet ditt kan registreres. Denne samtykkeerklæringen må fornyes av barnet selv ved fylte 16 år. Vi anbefaler dere derfor å lese nøye igjennom informasjonen i denne brosjyren. Spør oss gjerne hvis det er noe som er uklart eller hvis dere vil ha mer informasjon. Statped Vest Statlig spesialpedagogisk støttesystem Registerets formål Registerets formål er å sikre barn født med leppe- kjeve- ganespalte et best mulig behandlingstilbud. Registeret skal samle data fra behandlingsteamene i Oslo og Bergen, for å sørge for at fagfolk, ved bruk av data, kan vurdere om behandlingen er god nok.

217 Bakgrunn I Norge fødes årlig omtrent 130 barn med ulike spaltetyper. Leppe- kjeve- ganespalte er den alminneligste medfødte mis-dannelsen i hode- og halsregionen og opptrer hos ca. 2 av 1000 levende fødte. Årsaken til leppe- kjeve- ganespalte er flere, avhengig av gener og miljøfaktorer. Forekomsten i Norge har vært uendret de siste førti årene. Resultatet av behandlingen ses først når personen er utvokst, oftest i voksen alder. Dette gjelder både utseende (arr og vekst av ansiktets strukturer), tale (ganefunksjon og romforhold i svelget), hørsel (gjentatte problem i mellomørene kan medføre nedsatt hørsel i voksen alder), bitt / tannstatus og sosial tilpasning. Da antall barn født med leppe- kjeve- ganespalte i Norge pr. år er forholdsvis få, er det en fordel om datainnsamlingen blir stabil over mange år. Dette for å kunne ha et tilstrekkelig antall pasienter fagfolkene kan sammenligne mellom. Først da er det mulig å si noe om resultatene. Derfor håper vi at dere vil være med i registeret. På møtet kan dere gi skriftlig samtykke. Er dere usikre, kan dere vente med å ta stilling til dette til barnet blir innlagt på sykehuset for første operasjon.samtykkeerklæringen inneholder informasjon til dere om hvilken type data som blir registrert og hva disse skal brukes til. Innsynsrett, endring og sletting av opplysninger Du har full rett til innsyn i hva som er registrert om barnet ditt. I tillegg kan du når som helst kreve at opplysningene blir slettet fra registeret uten at du må oppgi noen grunn. Om du ikke ønsker å la ditt barn bli registrert får det ingen innflytelse på forholdet til behandlingsteamet. Heller ikke om du ønsker å trekke samtykket. Behandlingen av opplysningene er godkjent av Datatilsynet og foregår elektronisk. Opplysningene behandles konfidensielt, og alle som arbeider med data fra registeret har taushetsplikt om forhold de får kjennskap til. Registreringsskjema og samtykkeerklæring Registeret er godkjent av Datatilsynet som har stilt krav til innhenting, lagring og bruk av data. Dette for å sikre personvernet til den enkelte pasient. Registeret er basert på samtykke fra foreldre/foresatte ved første sykehuskontroll, som oftest når barnet er nyfødt. Når pasienten blir 16 år, må nytt samtykke innhentes i forbindelse med rutinekontroll i behandlingsteamene (ref. personopplysningsloven 9 a). Som foreldre/foresatte til nyfødte eller adopterte barn med leppe- kjeveganespalte, blir dere innkalt til informasjonsmøte som arrangeres av faggruppene i behandlingsteamet som dere er henvist til. Her får dere muntlig informasjon om registeret og mulighet til å stille spørsmål.

218 Sentraliserte behandlingsteam Vi har to behandlingsteam i Norge: Oslo-teamet Oslo universitetssykehus ved Rikshospitalet og Statped, Bredtvet kompetansesenter Bergens-teamet Haukeland universitetssjukehus Fylkestannlegen i Hordaland, Senter for Leppe- kjeve- ganespalte Statped Vest Teamene samarbeider om behandlingen og består av: Plastikkirurger, logopeder, øre-nese-hals leger, sykepleiere, kjeveortopeder og psykologer. Mål Sikre pasientene best mulig behandling og oppfølging Sikre entydig registrering og datainnsamling av LKG-spalte behandlingen Registrere om pasientgruppen og foresatte føler seg ivaretatt Legge forhold til rette for å kunne sammenligne behandling og resultat med andre behandlingsteam Tilrettelegge for forskning Utarbeide årsrapporter Organisering og drift av registeret Helse Vest RHF og Helse Sør-Øst RHF har lagt drift og det økonomiske ansvaret for registeret til Helse Bergen HF. Helse Bergen HF er databehandlingsansvarlig for registeret Helse-Vest IKT er ansvarlig for teknisk drift Kirurgisk klinikk ved Helse Bergen HF, har det administrative ansvaret for registeret. Sekretariatfunksjon og daglig ledelse av registeret er lokalisert til Helse Bergen. De to behandlingsteamene for leppe- kjeve- ganespalte i Norge, ved de to plastikkirurgiske avdelingene ved Oslo Universitessykehus og Haukeland Universitetssykehus, har det faglige ansvaret for registeret For nærmere informasjon: Utlevering av opplysninger Det er etablert en styringsgruppe som har utarbeidet egne retningslinjer for tilgang til data fra Norsk Kvalitetsregister for Leppe- kjeveganespalte, til kvalitetssikrings- og/eller forskningsformål. Data fra registeret som forskere får tilgang til, vil bli anonymisert. Identiteten er skjult, navn og andre kjennetegn oppbevares kun ved Norsk kvalitetsregister for leppe- kjeve-ganespalte. I enkelte forskningsprosjekter kan det bli nødvendig også å bruke tilleggsopplysninger fra andre nasjonale registre som Medisinsk fødselsregister, Kreftregisteret, Dødsårsakregisteret og Norsk pasientregister med flere. Noe som er poengtert i samtykkeerklæringen.

219 Nr Helse Bergen Foto: Norsk kvalitetsregister for LEPPE - KJEVE - GANESPALTE

220 Norsk kvalitetsregister for LEPPE - KJEVE - GANESPALTE Informasjonsskriv og erklæring om samtykke for foresatte til barn 0-16 år Bakgrunn På oppdrag fra Helse og omsorgsdepartementet har Helse Vest RHF i samarbeid med Helse Sør- Øst RHF opprettet Norsk kvalitetsregister for leppe- kjeve- ganespalte. Hensikten er å sikre dokumentasjon av behandlingsresultat. For å gi best mulig behandling og oppfølging er det behov for bedre kunnskap, ikke bare om tilstanden hos hver enkelt pasient som er født med leppe- kjeveganespalte, men om hele pasientgruppen. Nasjonalt kvalitetsregister for leppe- kjeve- ganespalte vil være et viktig grunnlag for forskning. For at behandlingstilbudet til pasientene skal bli best mulig, er både kvalitetssikring og forskning viktig og nødvendig. Det er frivillig å la barnet bli registrert, og det krever informert samtykke. Det betyr at du må undertegne en samtykkeerklæring før vi kan registrere opplysninger om barnet ditt i registeret. Hva skal registreres og hvor skal opplysningene i registeret hentes fra? Opplysninger som inngår i registeret er navn og fødselsnummer og opplysninger om diagnose og behandling. Det registreres begrensede opplysninger om andre sykdommer, arveforhold, funksjon og tilpasning. Dataene er en systematisering av opplysninger som vanligvis inngår i barnets journal under behandling og oppfølging. Dersom vi ser at vi mangler opplysninger til registeret fra innleggelse/ konsultasjon, vil vi kontakte dere. Lagring og utlevering av opplysninger Registrering av opplysninger skjer ved hjelp av datateknologi og er sikret mot innsyn fra uvedkommende. Opplysningene lagres permanent i elektronisk form. Behandlingen av opplysningene er godkjent av Datatilsynet etter Personopplysningslovens 33 og Helseregisterloven 5. Helse Bergen HF er databehandlingsansvarlig. Alle innsamlede opplysninger behandles konfidensielt, og alle som arbeider med registeret har taushetsplikt om forhold de får kjennskap til. Fagpersonene som behandler pasientgruppen kan få opplysninger fra registeret om de pasientene de selv har behandlet. Opplysninger om andre pasienter enn de som behandleren selv har behandlet, kan frigis ved søknad til styret og må godkjennes av lovbestemte instanser (personvernombud, regional komité for medisinsk og helsefaglig forskningsetikk). Relevant informasjon vil bli utlevert mellom faggruppene ved tjenestelig behov. Anonymiserte masseopplysninger fra registeret vil bli presentert i standardiserte årsrapporter til fagmiljøene, pasientgruppen og helsemyndighetene. Innsynsrett, endring og sletting av opplysninger Du har full rett til innsyn i hva som er registrert om barnet ditt og til å få korrigert eventuelle feil. I tillegg kan du når som helst kreve at opplysninger om barnet ditt blir slettet fra registeret, uten at du må oppi noen grunn. Internett E-post: lkg-registeret@helse-bergen.no Telefon Postadresse: Norsk kvalitetsregister for leppe-kjeve-ganespalte. Haukeland universitetssjukehus Bergen. Helse-Bergen, telefon sentralbord

221 Sletting av data vil ikke innebære sletting fra anonymiserte forskningsfiler som allerede er benyttet i forskning. Det vil ikke ha noen betydning for ditt barns behandlingsopplegg dersom du velger å ikke la barnet bli registrert, eller dersom du senere ønsker å trekke tilbake samtykket. Når barnet er blitt 16 år, må det selv ta stilling til om han/hun ønsker å inngå i registeret. Om ønskelig kan han/hun få slettet registrerte opplysninger. Forskning Utlevering av opplysninger til forskning på leppe-kjeve-ganespalte vil bare være i form av avidentifiserte oversikter. Det vil si at opplysningene vil bli behandlet uten navn og fødselsnummer eller andre direkte gjenkjennende opplysninger. En kode knytter barnet til sine opplysninger gjennom en navneliste, og det er kun autorisert personell knyttet til registeret som har adgang til navnelisten og som kan finne tilbake til barnet. For forskningsprosjekter kan det være aktuelt å sammenstille informasjon fra registeret med andre opplysninger i barnets sykejournal og med offentlige registre og befolkningsundersøkelser, som: Medisinsk fødselsregister, Norsk pasientregister, Norsk nyfødtmedisinsk kvalitetsregister, Kreftregisteret, Reseptregisteret, registre under Statistisk Sentralbyrå, registre under Norsk arbeids og velferdsforvaltning (NAV), Dødsårsaksregisteret, Norsk kvalitetsregister for sped- og småbarns psykiske helse og Nasjonale skoleprøver. Alle forskningsprosjekter må imidlertid forhåndsgodkjennes av regional komité for medisinsk og helsefaglig forskningsetikk og andre offentlige instanser som loven krever. FØDSELSNUMMER FULLT NAVN Fornavn Mellomnavn Etternavn BEHANDLINGSTEAM (kryss av) OSLO BERGEN STED DATO FORESATTE 1 TELEFON/MOBIL FORESATTE 2 Pasientdata Signering av erklæring Jeg har lest informasjonen ovenfor og samtykker i at: De nevnte opplysningene registreres i pasientdatabasen. Opplysningene kan brukes til forskningsformål som nevnt ovenfor. For mer informasjon: E-post: lkg-registeret@helse-bergen.no TELEFON/MOBIL Det er tilstrekkelig med samtykke fra en foresatt Statped Vest Statlig spesialpedagogisk støttesystem HELSE BERGEN Haukeland universitetssjukehus

222 Norsk kvalitetsregister for LEPPE - KJEVE - GANESPALTE Informasjonsskriv og erklæring om samtykke for ungdom over 16 år Bakgrunn På oppdrag fra Helse og omsorgsdepartementet har Helse Vest RHF i samarbeid med Helse Sør-Øst RHF opprettet Norsk kvalitetsregister for leppe- kjeve- ganespalte. Hensikten er å sikre dokumentasjon av behandlingsresultat. For å gi best mulig behandling og oppfølging er det behov for bedre kunnskap, ikke bare om tilstanden hos hver enkelt pasient som er født med leppe- kjeveganespalte, men om hele pasientgruppen. Nasjonalt kvalitetsregister for leppe- kjeve- ganespalte vil være et viktig grunnlag for forskning. For at behandlingstilbudet til pasientene skal bli best mulig, er både kvalitetssikring og forskning viktig og nødvendig. Det er frivillig å være registrert. Da du var liten valgte dine foresatte at opplysninger fra din behandling skulle inngå i registeret. Den gang undertegnet de en samtykkeerklæring som ga oss denne tillatelsen. Hva registres og hvor hentes opplysningene fra? Opplysninger som inngår i registeret er navn og fødselsnummer og opplysninger om diagnose og behandling. Det registreres begrensede opplysninger om andre sykdommer, arveforhold, funksjon og tilpasning. Dataene er en systematisering av opplysninger som vanligvis inngår i journalen under behandling og oppfølging. Dersom vi ser at vi mangler opplysninger til registeret fra innleggelse/konsultasjon, vil vi kontakte dere. Lagring og utlevering av opplysninger Registrering av opplysninger skjer ved hjelp av datateknologi og er sikret mot innsyn fra uvedkommende. Opplysningene lagres permanent i elektronisk form. Behandlingen av opplysningene er godkjent av Datatilsynet etter Personopplysningslovens 33 og Helseregisterloven 5. Helse Bergen HF er databehandlingsansvarlig. Alle innsamlede opplysninger behandles konfidensielt, og alle som arbeider med registeret har taushetsplikt om forhold de får kjennskap til. Fagpersonene som behandler pasientgruppen kan få opplysninger fra registeret om de pasientene de selv har behandlet. Opplysninger om andre pasienter enn de som behandleren selv har behandlet, kan frigis ved søknad til styret og må godkjennes av lovbestemte instanser (personvernombud, regional komité for medisinsk og helsefaglig forskningsetikk). Relevant informasjon vil bli utlevert mellom faggruppene ved tjenestelig behov. Anonymiserte masseopplysninger fra registeret blir presentert i standardiserte årsrapporter til fagmiljøene, pasientgruppen og helsemyndighetene. Internett E-post: lkg-registeret@helse-bergen.no Telefon Postadresse: Norsk kvalitetsregister for leppe-kjeve-ganespalte. Haukeland universitetssjukehus Bergen. Helse-Bergen Haukeland universitetssjukehus, telefon sentralbord

223 Innsynsrett, endring og sletting av opplysninger Du har full rett til innsyn i hva som er registrert om deg og til å få korrigert eventuelle feil. I tillegg kan du når som helst kreve at opplysninger om deg blir slettet fra registeret, uten at du må oppi noen grunn. Sletting av data vil ikke innebære sletting fra anonymiserte forskningsfiler som allerede er benyttet i forskning. Det vil ikke ha betydning for ditt videre behandlingsopplegg dersom du velger å ikke være registrert. Forskning Utlevering av opplysninger til forskning på leppe-kjeve-ganespalte vil bare være i form av avidentifiserte oversikter. Det vil si at opplysningene blir behandlet uten navn og fødselsnummer eller andre direkte gjenkjennende opplysninger. En kode knytter personen til sine opplysninger gjennom en navneliste, og det er kun autorisert personell knyttet til registeret som har adgang til navnelisten og som kan finne tilbake til personen. For forskningsprosjekter kan det være aktuelt å sammenstille informasjon fra registeret med andre opplysninger i sykejournalene og med offentlige registre og befolkningsundersøkelser, som: Medisinsk fødselsregister, Norsk pasientregister, Norsk nyfødtmedisinsk kvalitetsregister, Kreftregisteret, Reseptregisteret, registre under Statistisk Sentralbyrå, registre under Norsk arbeids og velferdsforvaltning (NAV), Dødsårsaksregisteret, Norsk kvalitetsregister for sped- og småbarns psykiske helse og Nasjonale skoleprøver. Alle forskningsprosjekter må imidlertid forhåndsgodkjennes av regional komité for medisinsk og helsefaglig forskningsetikk og andre offentlige instanser som loven krever. FØDSELSNUMMER FULLT NAVN Fornavn Mellomnavn Etternavn BEHANDLINGSTEAM (kryss av) OSLO BERGEN STED DATO UNDERSKRIFT TELEFON/MOBIL Pasientdata Signering av erklæring Jeg har lest informasjonen ovenfor og samtykker i at: De nevnte opplysningene registreres i pasientdatabasen. Opplysningene kan brukes til forskningsformål som nevnt ovenfor. For mer informasjon: E-post: lkg-registeret@helse-bergen.no Statped Vest Statlig spesialpedagogisk støttesystem HELSE BERGEN Haukeland universitetssjukehus

224 Handlingsplan Skal legges fram for styret ved neste styremøte nov/des-12 Bakgrunn: Registeret startet inklusjon av pasienter 1.januar Alle nyfødte etter 1. januar 2011 med spalte som henvises til de plastikkirurgiske avdelingene inviteres til deltagelse. Fra samme dato inkluderte kjeveortoped og ØNH-lege pasienter som ble innkalt til rutinekontroll 6 år og logoped og psykolog pasienter til rutinekontroll 10 år. Elektronisk registrering var tilgjengelig fra 23.september Oppgave Tiltak Ansvarlig 1 Tilrettelegge og koordinere drift Institusjonene oppfordres til å legge til rette for ressurspersoner å følge opp LKG-registeret, ved at det blir avsatt tid for dette arbeidet. Oppdatere /revidere informasjon til pasientgruppen, pasientorganisasjon, behandlingsteam og faggrupper Registeradministrasjonen skal være kontaktledd mellom HelseVest IKT, og behandlingsteamene Opprettholde kontaktperson for faggruppene Teamledere Koordinator Prosjektleder og koordinator Teamledere