Overvåking av meldingsutveksling - ved hjelp av MTM Bente Bredholt, Helse Midt-Norge IT 31. august 2012 Integrasjonsdagene hos Communicate
Men først litt om meg Bente Bredholt Fysiokjemiker/bioingeniør (1983->) Systemutvikler/programmerer (1987->) Prosjektleder (1992 - >) Selvstendig / eget konsulentselskap (2002 -> 2005/2006) (prosjektledelse/endringsledelse) Ansatt i Hemit fra november 2005 (først som prosjektleder, senere i alt mulig innenfor Meldingsløftet )
- og oss i Helse Midt-Norge Helse Midt-Norge - RHF (Regionalt HelseForetak): (Helse Midt-Norge ble etablert etter den store sykehusreformen i 2001 og 2002) - ansvar for sykehus og spesialisthelsetjenesten i de tre midt-norske fylkene. Namsos og Levanger Ålesund, Volda, Molde og Kristiansund. Trondheim + Orkdal og Røros: Vestmo Behandlingssenter i Ålesund, Veksthuset i Molde, Trondheimsklinikken i Trondheim Helseregionen har ca. 15.000 ansatte. Omfatter: de offentlige sykehusene, institusjonene i psykiatrien (barn og voksne), ambulansetjenesten, nødmeldingstjenesten, sykehusapotek, laboratorier og institusjoner i rusomsorgen. Ålesund, Molde, Kristiansund, Trondheim, Namsos og Levanger I tillegg håndteres Ambulanse Midt-Norge, Helsebygg og Hemit.
Meldingsløftet + Helse Midt s behov for MTM (eller tilsvarende) verktøy
Sykehus og elektronisk kommunikasjon - Sykehusene har i mange år sendt meldinger - Det var imidlertid vanskeligere for sykehusene å motta meldinger - M:M kommunikasjon krever MER enn 1:M, det er vanskelig å tilpasse seg alt! - KITH (Kompetansesenteret for IT i helse- og sosialsektoren) - nå EISI (avdeling standardisering i divisjon e-helse og IT innunder Helsedirektoratet) - beskrev en del nye standarder for kommunikasjon M:M som få benyttet. - NASJONALT MELDINGSLØFT BLE ETABLERT!
Nasjonalt Meldingsløft - Helsedirektoratet Startet 31. mars 2008 Fokus på elektroniske basismeldinger mellom sykehus og allmennleger.
Meldingsløftet - overtatt av NHN fra 1.1.2012. Nå mer fokus på utbredelse av meldinger i kommunene
MTM - overvåking av applikasjonskvitteringer Fra et tidlig prosjektoppdrag for Rutineutvikling for å håndtere papirløse e-meldinger (juni 2007)
Meldingsløftets meldinger - Basismeldinger: Basismeldinger: Henvisninger og epikriser Rekvisisjoner (lab/røntgen) og svarrapporter (labsvar/røntgensvar) I tillegg skal alle meldinger skal besvares med en applikasjonskvittering Forutsetning: Bruk av sikker meldingsutveksling via NHN (Norsk HelseNett). o ebxml-rammeverk med PKI o kryptering/dekryptering o Signering/autentisering (mottar også ebms-kvittering) Skissen er stjålet fra Sykehuset i Vestfold Status hos Helse-Midt i dag: Henvisninger (mottas) og epikriser (sendes) Rekvisisjoner til røntgen (mottas) Svarrapport /røntgensvar (sendes) Svarrapport / labsvar fra med.biokjemi, farmakologi, immunologi etc (sendes) Vi benytter ebxml-rammeverket i kommunikasjonen med noen partnere, men ikke alle. (DES benyttes også.) Helse-Midt benytter ikke (av diverse årsaker, ikke kun tekniske) : Svarrapport for patologi - sendes ikke. Rekvisisjoner til lab (utenom røntgen) - mottas ikke. De fra HFsiden benytter MTM når de følger opp sine utsendte meldinger!
Meldingsløftets meldinger PLO-meldinger: Opprinnelig et ELIN-K prosjekt som startet hos Norsk Sykepleierforbund for å dekke kommunens behov for kommunikasjon mellom fastleger og sykehus. https://www.sykepleierforbundet.no/vis-artikkel/643628/elin-k PLO-meldingene ble viktig for sykehusene i fbm samhandlingsreformen PLO-meldingene som sendes mellom sykehus og kommune: Pasientlogistikk-meldinger som sendes fra sykehus til kommune Fagmeldinger som sendes fra sykehus til kommune: Fagmeldinger som sendes fra kommune til sykehus Dialogmeldinger Forespørsel (sendes og mottas) Svar på forespørsel (sendes og mottas) Avviksmelding (sendes og mottas, skal være relatert til en opprinnelig fagmelding.) De fra HFsiden benytter MTM til feilsøking. (Følger primært opp utsendte meldinger i fagsystemet, ikke MTM )
Hvilke behov dekker MTM hos oss?
Interessenter - i MTM Overvåking / sjekking: De som sender/mottar meldingene i HelseForetakene (HF) Forskjellige miljø: lab, røntgen, Doculive/EPJ, samhandling pleie-og-omsorg Integrasjonsdrift i Hemit (Helse Midt IT) Utvikling og test: De som utvikler løsninger og orkestreringer på BizTalk (Hemit) De som tester integrasjonsløsningene som er levert på BizTalk (Hemit + HF) Statusrapportering, økonomi / planlegging De som rapporterer status i pågående prosjekt som har meldingsutbredelser De som budsjetterer Interessentkonflikt: - kriteriet for at meldingene settes til Success/Error Avhenger av HVEM som skal se på meldingen HF: Error hvis avsender/mottaker ikke får opprinnelig melding dvs der negativ appkvitt sendes eller mottas skal opprinnelig melding ha status Error. Hemit/drift: Error hvis noe feiler, dvs opprinnelig melding som besvares med negativ appkvitt - og utsendelsen går bra - skal ha status Success
Hvordan dekker MTM behovene for overvåking/sjekking?
Overvåking/sjekk av meldingene De som sender meldinger på HelseForetaket (HF) Ser kun sine utsendte meldinger Følger opp meldinger med Error (mottak av negativ applikasjonskvittering) Mer på de følgende foil De som mottar meldingene på HelseForetakene (HF) Ser bare de meldingene som skal til seg, men benytter MTM kun som et feilsøkingsverktøy Dvs når noen etterlyser hva som har skjedd med innsendt melding fordi avsenderen ikke har fått applikasjonskvittering f.eks Integrasjonsdrift i Hemit (Helse Midt IT) Ser alle, men benytter MTM bare i fbm feilsøking. ALT som gjøres i fbm oppslag etc logges!
Feil ved utsendte meldinger Overvåking/sjekk av meldingene De som sender meldinger på HelseForetaket (HF) Oppfølging av meldinger med negativ appkvitt HFet har ansvar for overvåking av sine utsendte meldinger. Meldingsløftsmiljøet splittet opp i: Lab, røntgen og Doculive/EPJ Sjekker/følger opp negative applikasjonskvitteringer og også de som mangler applikasjonskvittering (hvis kommunikasjonen BARE går elektronisk.) 2 1 Visningsfil
Visningsfil Overvåking/sjekk av meldingene De som sender meldinger på HelseForetaket (HF) Oppfølging av meldinger med negativ appkvitt Visningsfil gjør det enklere å lese innholdet i XML-filene for å kunne finne ut av hvorfor noe feilet. (Ekspempelet: Nyfødt, pasienten var ikke blitt tildelt fødselsnummer på det tidspunktet meldingen var sendt. Sykehuset benyttet internt hjelpenummer. Ikke kjent pasient hos legekontoret. )
Behandle avvik/feil Overvåking/sjekk av meldingene De som sender meldinger på HelseForetaket (HF) Oppfølging av meldinger med negativ appkvitt De som overvåker: - legger også på en kommentar på meldingen som har feilet, - samt skifter status fra Error til Behandlet.
Overvåking/sjekk av meldingene De som sender meldinger på HelseForetaket (HF) De som mottar meldingene på Helseforetaket Integrasjonsdrift i Hemit (Helse Midt IT) Tilgang / pålogget bruker ser bare det han skal ha rettigheter til å se! - og kan bare endre status hvis han har adminrettighet (endret i MTM 5.0) NB: PLO-meldingene følges IKKE opp i MTM, men i journalsystemet. MTM benyttes her bare til feilsøking av både sendte og mottatte meldinger
Eksempel en adminbruker som ser mye mer. Flere meldingstyper og flere partnere internt i Helse Midt-Norge Overvåking/sjekk av meldingene Integrasjonsdrift i Hemit (Helse Midt IT) Feilsøking også i fbm utvikling og test av løsninger og orkestreringer på BizTalk (Hemit + HF)
Loggen for hver melding, viser hva som skjer.. Overvåking/sjekk av meldingene De som sender meldinger på HelseForetaket (HF) De som mottar meldingene på Helseforetaket Integrasjonsdrift i Hemit (Helse Midt IT) Brukeren kan lese i loggen for hver enkelt melding hvordan den er behandlet på BizTalk. I dette tilfellet her, har brukeren leserett også til innholdet i den sendte meldingen, men dette kan fjernes.
Feilsøking via loggen : Overvåking/sjekk av meldingene Integrasjonsdrift i Hemit (Helse Midt IT) Feilsøking også i fbm utvikling og test av løsninger og orkestreringer på BizTalk (Hemit + HF)
Logging / Henvisning I Overvåking/sjekk av meldingene Integrasjonsdrift i Hemit (Helse Midt IT) Feilsøking også i fbm utvikling og test av løsninger og orkestreringer på BizTalk (Hemit + HF) Man kan lese mye i loggen : Utvidet logging gir også en avansert sluttbruker mer mulighet til å følge opp hva som konkret har skjedd med meldingen og hvor den har havnet internt. IKKE FEIL, men korrekt STYRT håndtering i orkestreringen på BizTalk fordi den avdelingen/tjenesten som skulle motta henvisningen på Helseforetaket ikke har startet med elektronisk vurdering av henvisningene. Manuelt mottak sharepoint DES-kryptering
Logging / Henvisning II Overvåking/sjekk av meldingene Integrasjonsdrift i Hemit (Helse Midt IT) Feilsøking også i fbm utvikling og test av løsninger og orkestreringer på BizTalk (Hemit + HF) Den avanserte sluttbrukeren ser her at henvisningen har blitt sendt rett inn i Doculive (journalsystemet). Der gjøres det også en del automatiske opphentinger av informasjonen i henvisningen til et vurderingsnotat som blir delvis utfylt. Henvisningen havner så i forhåndsdefinerte postkasser/arbeidslister avhengig av hvilken avdeling eller tjeneste meldingen er sendt til. Automatisk mottak helt inn til en arbeidsliste i journalen. Meldingen er sendt med hjelp av ebxml og kryptert med PKI.
Søking / gjenfinning Overvåking/sjekk av meldingene De som sender meldinger på HelseForetaket (HF) De som mottar meldingene på Helseforetaket Integrasjonsdrift i Hemit (Helse Midt IT) Finne en spesifikk melding, men vet ikke eksakt hvilken MTMID den har. Søker da på Sender/Receiver (som logges fra meldingen) eller andre brukerdefinerte felt som er spesifikke for hver melding. (XPATH-uttrykk)
Overvåking/sjekk av meldingene Utfordring / interessekonflikt: Error eller Success? I og med at det er HF-brukeren som først og fremst benytter MTM for oppfølging (Hemit har feillogger utenom), så BØR det være HFets ønske som styrer valg av status.
Hvordan vi har løst rettigheter / tilgang
Storebror ser deg Vi har satt på logging, og kan ved behov - gå gjennom hvilke personer som har hatt tilgang til innhold / sensitive data på en pasient. Fellesbrukere skal IKKE ha tilgang til å se innholdet i de loggede filer. Vi ønsker derfor at alle brukere skal ha sin unike påloggingsnavn. (AD.brukeren er forsøkt, men rettighetene ved endringer ble ikke oppdatert. Mulig dette er bedre ivaretatt i MTM versjon 5 eller 6.)
Brukere og grupper En bruker tilhører en eller flere grupper. Gruppen bestemmer a) hvilke HFs data han/hun skal ha tilgang til, b) meldingstype og c) om han/hun skal kunne lese innholdet i de loggede filene eller ikke..
Grupper Sykehus / HF Meldingstyper og rettigheter Pr 15. august 2012 har vi 46 navngitte grupper 41 meldingstyper og 1890 partnere!
Meldingstype, sender og mottaker Tilgang gis via bruker eller gruppe på type melding, samt på (av)sender og mottaker. Intern (styrer tilgang) Fjernet everyone Ekstern( everyone ) De eksterne partnere er felles, kan sees av alle!
ØNSKE 1: Forenkle rettigheter/tilgang. AD-bruker: Fordel: Enkelt å opprette, men Ulempe: rettighetene i MTM ble værende (endres ikke hvis endret i AD) Det er pr i dag tungvint å administrere tilgang for M:M via Grupper Brukere Meldingstyper Sender (av meldingen) Mottaker (av meldingen) Vi har forenkler tilgangsstyringen litt ved å gi Everyone -tilgang på eksterne partnere, og styre tilgangen til meldinger kun på interne partnere. Ønske 1: Forenkle administrasjon av tilgang ved at en gruppe kan ligge i en gruppe Tilgangsstyring er noe krevende, og det finnes fallgruver: Det KAN skje feilsituasjoner - hvor man pga logging av feil utilsiktet også gir for mye rettigheter - ELLER for få (ved at man i andre sammenheng glemmer å gi - eller fjerner everyone på eksterne partnere).
ØNSKE 2: Organisatorisk hierarki Ønsker å ha hierarki på avsendere/ mottakere: I meldingsløftet-sammenheng er adressene på to nivå. 1. nivå er kommune/helseforetak eller organisasjon. 2. nivå er lege i en organisasjon, tjeneste eller enhet. Nå må vi velge om vi logger nivå 1 eller nivå 2, og tilgangsstyringen må skje via dette Ønske 2: Ønsker et hierarki der man kan definere / si at tjeneste X tilhører helseforetak Y eller sykehus Z og gi tilgang basert på dette. Logger man meldingene på nivå 2, vil man få mye administrasjon mht tilgangsstyring. Løsningen blir da å logge på nivå 1 eller via en avledet enhet som f.eks sykehus eller edi-adresse..
ØNSKE 3: Skille ut de papirløse! (viktig for HFet) Pr i dag så har man ikke kapasitet til å overvåke alle meldinger man mangler applikasjonskvittering på. HFene fokuserer derfor mest på oppfølgingen av de partnere som har blitt papirløse. Fordi man ikke har muligheter til å sette dette pr partner i MTM, - så har man mange ekstra systemer. Planlegger å legge inn nye statuser for å skille ut papirløse. Ønske 3: Ønsker en enklere måte å kunne ivareta overvåking av en gruppe med partnere som f.eks alle meldingene til de som er blitt papirløse.
ØNSKE 4: Knytning mot NHN-adresseregisteret Pr i dag legges det inn beskrivende tekst på koden/navnet man logger som sender/mottaker av meldingen. Ønske 4: HFene ønsker at navnet som blir gitt stemmer overens med det som til enhver tid står i NHN-adresseregisteret. (For enklere søking på partner)