Meldingsutveksling med Kreftregisteret over Norsk Helsenett

Transkript

1 Meldingsutveksling med Kreftregisteret over Norsk Helsenett Versjonshistorikk Versjon Dato Kommentar Forfatter Første utkast Sølve Monteiro Legge til oppsummering Sølve Monteiro Endre noe tekst og Steinar Auensen layout Tekstlig innhold Jan Nygård Innledning Dette dokumentet beskriver delvis hvordan Kreftregisteret idag mottar meldinger, litt om prosseseringen og litt om hvordan vi ønsker at nye partnere kan utveksle meldinger med oss. Det er mange tekniske områder som ikke vil bli gjennomgått her (Norsk Helsenett, meldingstjeneren, KITH sine XML er, ebxml, HTML-skjema), da det finnes tilstrekkelig dokumentasjon for disse systemene andre steder. Per idag (05/10/2011) er det kun én aktør på Norsk Helsenett som innsender kliniske kreftmeldinger til Kreftregisteret, Sykehuset Østfold, så dette vil bli brukt som eksempel. Denne instruksen er ment for teknisk personell med litt kunnskap mo XML og generell IT. Meldingstyper Det brukes to forskjellige meldingstyper, begge definert av KITH: Hodemelding og Applikasjonskvittering. Hodemelding ( aspx ) Denne XMLfilen er en generisk type som kan brukes til alt. Siden de fleste andre meldingene er for spesifikke og det er for mye arbeid å endre på disse, brukes hodemeldingen sitt åpne felt for å sende data på formatet vi ønsker selv. I all hovedsak ser hodemeldingen slik ut: <?xml version="1.0" encoding="utf-8"?> <MsgHead xmlns=" <MsgInfo> <Type V="{{meldingstype}}" /> <MIGVersion>{{versjonsnummer}}</MIGVersion> <GenDate V="{{generert tidspunkt}}"/> <MsgId>{{unik meldingsid}}</msgid> <Sender> <Id>{{avsender NHN ID}}</Id> <TypeID V="ENH"/> </Sender> <Receiver> <Id>{{Mottakers NHN ID}}</Id>

2 <TypeID V="ENH"/> </Receiver> </MsgInfo> <Document> {{ Fritt innhold}} </Document> </MsgHead> Her har feltene som er aktuell for å sette inn data blitt farget i rødt for utheving. Her følger en beskrivelse for disse. Meldingstype og versjonsnummer Disse to attributtene identifiserer hvilken type melding som blir sendt med hodemeldingen. Det er ikke noen teknisk restriksjon på hva meldingen skal hete, men Kreftregisteret sorterer meldingene etter denne verdien. Derfor er det viktig at denne verdien settes etter avtale med Kreftregisteret. Det samme gjelder for versjonsnummer. I prosseseringen er det noen elementer som har blitt lagt til eller fjernet avhengig av versjonen, derfor er denne også ganske rigid. Generert tidspunkt Dette er typisk satt av applikasjonen, og bør være i formatet ÅÅÅÅ-MM-DDTtt:mm:ssZ (ISO 8601). Eksempel på en gyldig verdi for dette feltet er T10:33:27Z MeldingsID Dette er en unik ID for hver melding. Det anbefales å bruke UUID eller lignende hvis mulig. Et alternativ er å bruke for eksempel millisekundtelleren for UNIX TIME ( ). Denne må være unik for at systemet med applikasjonskvitteringer skal fungere. Avsender NHN ID Dette er Norsk Helsenett ID til avsender. Denne må være korrekt for at applikasjonskvitteringene skal komme fram. Dette nummeret er typisk organisasjonsnummeret. Eksempler på noen ID er: Kreftregisteret: Sykehuset Østfold: Rikshospitalet: Mottakers NHN ID Dette er Norsk HelseNett ID til mottaker. Dersom meldingen skal sendes til Kreftregisteret, må ID være Innhold

3 Dette vil være selve kroppen, eller innholdet i meldingen. Her kan hva som helst inkluderes, så lenge innholdet er gyldig XML. Eksempel Under følger et eksempel (litt forenklet) på en melding mottatt fra Sykehuset Østfold. Meldingen ble generert av webapplikasjonen for å fylle ut kreftmeldinger. <?xml version="1.0" encoding="utf-8"?> <MsgHead xmlns=" <MsgInfo> <Type V="HTML_KLIN_MAMMA"/> <MIGVersion>1.3</MIGVersion> <GenDate V=" T10:33:27Z"/> <MsgId> </MsgId> <Sender> <Id> </Id> <TypeID V="ENH"/> </Sender> <Receiver> <Id> </Id> <TypeID V="ENH"/> </Receiver> </MsgInfo> <Document> <!-- Her kommer alt innholdet i meldingen... --> </Document> </MsgHead> Denne hodemeldingen er av type HTML_KLIN_MAMMA versjon 1.3. Dette har blitt satt opp slik at Kreftregisteret vet hvordan å prossessere akkurat denne typen melding av denne versjonen. Den unike ID en her ( ) ble generert av webapplikasjonen som lagde XML-filen, og er Unixtime (millisekunder siden ). Avsenderen er Sykehuset Østfold, og de har NHN ID (og organisasjonsnummer) Siden mottaker er Kreftregisteret, er mottaker ID satt til I noden MsgHead/Document er selve innholdet i meldingen, som et annet XML-element med mange underelementer. Siden dette innholdet er irrelevant for denne forklaringen (såfremt innholdet er gyldig XML), vil ikke dette bli diskutert nærmere.

4 Applikasjonskvittering ( aspx ) Dette er også en generisk melding, men har mindre frihet i seg. Det aller viktigste i denne meldingen er at den refererer til en tidligere mottatt melding. Meldingstjenere vil på grunnlag av denne referansen kunne automatisk returnere applikasjonskvitteringen til korrekt avsender. Under vises et eksempel på en applikasjonskvittering: <?xml version="1.0" encoding="utf-8"?> <AppRec xmlns=" xmlns:xsd=" xmlns:xsi=" xsi:schemalocation=" AppRec-v xsd"> <MsgType V="APPREC"/> <MIGversion> </MIGversion> <GenDate> T01:01:01</GenDate> <Id>a055409e-32b b386-a937d074ca18</Id> <Sender> <Role V="SENDER"/> <HCP> <Inst> <Name>Kreftregisteret</Name> <Id> </Id> <TypeId V="ENH"/> </Inst> </HCP> </Sender> <Receiver> <Role V="RECEIVER"/> <HCP> <Inst> <Name>Sykehuset Østfold</Name> <Id> </Id> <TypeId V="ENH"/> </Inst> </HCP> </Receiver> <Status V="3" DN="Feil i innhold"/> <Error V="1" DN="Ugyldig fødselsnummer, vennligst dobbeltsjekk og send inn ny versjon."/> <OriginalMsgId> <MsgType V="HTML_KLIN_MAMMA" DN="Meldeskjema brystkreft"/> <IssueDate> T10:33:27Z</IssueDate> <Id> </Id> </OriginalMsgId> </AppRec> Denne applikasjonskvitteringen referer til hodemeldingen vist som eksempel i forrige avsnitt: elementet Apprec/OriginalMsgId/Id er det samme som hodemeldingens MsgHead/MsgInfo/MsgId. Dette er det absolutt viktigste feltet i meldingen. Dersom denne er korrekt, vil den til og med overstyre verdien angitt i Reciever (ihvertfall for DIPS Communicator). Denne meldingen inneholder ikke frie felt, så det er strengt tatt ikke mulig å gi tilbakemelding utenom en

5 forhåndsdefinert status (definert av KITH): OK, Avvist og feil i delmelding, med verdier hhv 1, 2 og 3. Siden det behov for å gi mer tilbakemelding enn dette, er det heldigvis en måte å komme rundt dette. Elementet <Error> kan legges ved selv om meldingen er OK. I attributten DN kan man legge inn fritekst, for en mer tekstlig tilbakemelding. Dette har blitt brukt av KRG for eksempel for å bekrefte en melding med status OK, samtidig som forslag til endringer, forbedringer eller generelle tilbakemeldinger har blitt gitt. Meldingsflyt Meldingsflyten med Kreftregisteret over Norsk HelseNett (NHN) er enkel. Avsender sender innholdet sitt pakket inn i en KITH hodemelding, Kreftregisteret prosseserer den, og sender tilbake en applikasjonskvittering. Selve innholdet i meldingen til Kreftregisteret vil være et element i Figur 1: Meldingsflyten fra helseforetak til Kreftregisteret og tilbake igjen hodemeldingen, mens resten av hodemeldingen blir å betrakte som metadata. Denne metadataen brukes av Kreftregisteret for å sortere, behandle og gi korrekt tilbakemelding på den innsendte meldingen. Følgende figur viser meldingsflyten mellom innsender og Kreftregisteret. Beskrivelse: - Helseforetaket fyller ut en melding i en innregistreringsløsning (HTMLSkjema, MRS,...) - Innregistreringsløsningen legger meldingen i en gitt mappe som overvåkes av meldingstjeneren. Meldingen er av type KITH MsgHead med en gitt verdi for type og versjon. - Meldingstjeneren plukker opp hodemeldingen og sender den til riktig partner angitt av adressen i hodemeldingen. - Kreftregisterets meldingstjener (DIPS Communicator) mottar meldingen og dumper den ut i en mappe for videre behandling - Gitt at den mottatte meldingen er av typen KITH hodemelding sendes den videre inn i systemet og sorteres på type og versjon. Det er flere trinn med prossesering og validering

6 her, både en automatisk (sjekk av validitet, kompletthet, osv) og manuell (medisinsk innhold er fornuftig, korrekt pasient,...). - Kreftregisteret genererer en applikasjonskvittering. Per idag aktiveres dette manuelt, etter den medisinske vurderingen av meldingen. Siden meldingen ligger på vent helt til den blir behandlet av en av Kreftregisterets medarbeidere, kan det ta lang tid før applikasjonskvitteringen sendes. Denne delen av prossessen vil endres i framtiden ved at kvittering vil gis raskere. - Meldingstjeneren plukker opp applikasjonskvitteringen. Siden applikasjonskvitteringen referer til en melding med ID som har blitt mottatt tidligere, blir den automatisk returnert til korrekt adresse. - Helseforetaket mottar applikasjonskvittering. Avhengig av deres system, kan denne routes tilbake til innregistreringsløsningen for å gi en bekreftelse/tilbakemelding på den utfylte meldingen. Oppsummering Meldingsutveksling med Kreftregisteret er per idag enkelt, men det må gjøres noen trinn på forhånd. 1. Avtale kommunikasjon med Kreftregisteret slik at partner kan bli satt opp i meldingstjener. Dette kan involvere utveksling av sertifikater. 2. Avtale type hodemelding, versjon og innhold med Kreftregisteret. 3. Installer og konfigurer innregistreringsløsning, og pass på at meldinger blir lagret/eksportert som KITH hodemeldinger etter avtale 4. Konfigurer meldingstjener til å automatisk plukke opp hodemeldingene og sende de til Kreftregisteret. 5. Kreftregisteret vil returnere en applikasjonskvittering (AppRec). Det er aktuelt at HF behandler disse for å gi tilbakemelding til innregistrere.