Vedlegg til kravspesifikasjon Integrasjonskrav til nytt
Innhold Kravspesifikasjon - integrasjonskrav til nytt 1 INNLEDNING... 3 1.1 INTEGRASJONSKRAV... 3 1.2 FORMÅL... 3 1.3 SYSTEMSKISSE INTEGRASJONER... 3 2 OVERORDNEDE RAMMER OG FØRINGER FOR INTEGRASJONSARKITEKTUREN... 4 2.1 HELSE VEST INTEGRASJONSSTRATEGI... 4 3 BRUKSTILFELLER... 5 3.1 HENTE PASIENTDEMOGRAFI FRA PASIENTREGISTER... 5 3.1.1 ARBEIDSFLYT... 6 3.1.2 TEKNISK KRAV... 7 3.2 HENTE PASIENTDEMOGRAFI FRA PASIENTREGISTER OG FOLKEREGISTERET... 7 3.2.1 ARBEIDSFLYT... 8 3.2.2 TEKNISK KRAV... 9 3.3 STARTE LØSNINGEN MED OPPSTARTSPARAMETRE... 10 3.3.1 ARBEIDSFLYT... 11 3.3.2 TEKNISK KRAV... 12 3.4 OPPDATERING AV PASIENT ID... 12 3.4.1 TEKNISK KRAV... 12 3.5 OPPDATERING AV PASIENTDEMOGRAFI... 13 3.5.1 TEKNISK KRAV... 13 3.6 HENTE SOSIODEMOGRAFISKE DATA FRA EPJ... 15 3.7 KLINISKE DATA FRA EPJ TIL NY LØSNING... 15 3.7.1 PASIENTFORLØP/PASIENTHISTORIE... 15 3.7.2 PSYKIATRI OG RUS... 15 3.7.3 LABORATORIESVAR... 15 3.7.4 MEDISINER... 16 3.8 KLINISKE DATA TIL EPJ FRA NY LØSNING... 16 3.9 UTTREKK TIL FORSKNINGS- OG KVALITETSREGISTRE... 16 3.10 UTTREKK TIL STATISTIKKPROGRAM... 16 4 SIKKERHET I WEB SERVICES... 16 Side 2 av 16
1 Innledning Kravspesifikasjon - integrasjonskrav til nytt 1.1 Integrasjonskrav Dette dokumentet inneholder en detaljert beskrivelse av integrasjonskrav tilknyttet nytt psykometriske instrumenter og brukererfaringsundersøkelser, heretter kalt «Løsningen», som skal anskaffes i Helse Bergen. Det er ønskelig at Løsningen skal kunne integreres mot sentrale tjenester som tilbys og benyttes i Helse Vest, dvs. tjenester, registre og funksjonalitet som ligger utenfor løsningen. 1.2 Formål Formålet med de tekniske beskrivelsene som er satt opp i dette dokumentet er: - Å sikre at de funksjonelle kravene blir understøttet av relevante tekniske integrasjon beskrivelser/krav - Å sikre at løsningen blir sett i sammenheng med den eksisterende infrastrukturen i helseregionen - Å få et mest mulig helhetlig bilde av det integrasjonsmessige aspektet av en leveranse 1.3 Systemskisse integrasjoner Side 3 av 16
Kravspesifikasjon - integrasjonskrav til nytt 2 Overordnede rammer og føringer for integrasjonsarkitekturen 2.1 Helse Vest Integrasjonsstrategi Helse Vest har en regional integrasjonsstrategi som skal følges ved innføring i de enkelte foretakene. Strategien er kvalitetssikret mot Nasjonal IKT Fagforum Arkitektur, og prinsipper, krav og anbefalinger er i tråd med Nasjonal IKTs Tjenesteorientert arkitektur i spesialisthelsetjenesten. Noen sentrale elementer fra integrasjonsstrategien gjengis her kort: For meldingsbaserte tjenester (asynkrone), skal kommunikasjonen foregå via Helse Vests mellomvare, Microsoft BizTalk Server. I tråd med Nasjonal IKTs arkitektur, skal meldingene følge standardene til KITH og HL7. For synkron kommunikasjon skal det benyttes et sett webtjenester. I tråd med Nasjonal IKTs arkitektur, følger disse tjenestene ISO-standarden HL7 v3. Replikering av data skal bare forekomme dersom virksomhetsmessige behov tilsier at dette er den beste løsningen. Ellers skal oppslag mot kilde/andre systemer benyttes når Systemet ikke selv eier dataelementene. Løsningen skal implementeres i henhold til Helse Vests integrasjonsstrategi og prinsipper. Eventuelle avvik fra integrasjonsstrategien skal dokumenteres særskilt i løsningsbeskrivelsen. Side 4 av 16
3 Brukstilfeller I seksjonene under er det for noen brukstilfeller lagt inn beskrivende prosessdiagrammer for å illustrere hvordan Løsningen skal samhandle med sentrale tjenester. Det er benyttet en delmengde av standard BPMN notasjon i diagrammene. 3.1 Hente pasientdemografi fra pasientregister En pasient/person hentes fra pasientregister (DIPS PAS) når et fødselsnr, D-nummer eller hjelpenummer tastes inn i skjermbilde for henting av pasient eller når en bruker velger en pasient fra listen i dette skjermbildet.
3.1.1 Arbeidsflyt Søker frem pasient Start registrering Sjekker om pasient ligger i internt register Ja Klargjør til registrering Nei Søker etter pasient i sentrale tjenester Opprett pasient i internt register PatientRegistry. GetDemographics Figur 1 Hente pasientdemografi
3.1.2 Teknisk krav For å hente navn og adresse fra pasientregister basert på F-, D- eller H-nummer, skal web-tjenesten PatientRegistry.GetDemographics benyttes. Pasientdemografi på HL7 v3 format returneres til kallende system. Request: Response: PRPA_IN201307NO PRPA_IN201308NO Krav til sikkerhet: Web tjenesten skal tilfredsstille sikkerhetskrav som spesifisert i 4. 3.2 Hente pasientdemografi fra pasientregister og Folkeregisteret En pasient/person hentes fra pasientregister (DIPS PAS) eller Folkeregistret når et fødselsnr, D-nummer eller hjelpenummer tastes inn i skjermbilde for henting av pasient eller når en bruker velger en pasient fra listen i dette skjermbildet.
3.2.1 Arbeidsflyt Sentrale tjenester Stamcelle system Bruker Søker frem pasient Sjekker om pasient ligger i internt register NB! Oppretter pasient i pasientregister dersom den ikke finnes. Nei Søker etter pasient i sentrale tjenester HL7 AddGetDemographics Ja Opprett pasient i internt register Start registrering Klargjør til registrering Figur 2 Hente pasientdemografi og opprette pasient
3.2.2 Teknisk krav For å hente navn og adresse fra pasientregister eller Folkeregister basert på F- eller D-nummer, skal webtjenesten AddGetDemographics benyttes: Denne tjenesten er en aggregert BizTalk-tjeneste, utviklet av Helse Vest IKT som benytter HL7- standardtjenester mot pasientregister og Folkeregister. For oppslag av pasient/persondemografi vil Løsningen ikke trenge å forholde seg til de underliggende HL7-tjenestene. AddGetDemographics har identisk kallgrensesnitt (request og response) som HL7 v3-tjenesten PatientRegistry.GetDemographics. Ved kall til tjenesten AddGetDemographics vil denne forsøke å hente pasientdemografi for gitt pasient fra DIPS PAS ved hjelp av tjenesten PatientRegistry.GetDemographics. Dersom pasienten ikke eksisterer, vil persondemografi bli hentet fra Folkeregisteret ved hjelp av tjenesten PersonRegistry.GetDemographics. Personen som returneres vil så bli lagt til i pasientregister (DIPS PAS) ved hjelp av tjenesten PatientRegistry.Add og pasientdemografi på HL7 v.3-standard returneres til kallende system. Request- og responsinteraksjonene er identiske med interaksjonene PRPA_IN201307UV og PRPA_IN201308UV02 som benyttes av HL7-tjenesten PatientRegistry.GetDemographics, bare navnene er forskjellige. Request: Response: PRPA_IN201307UV02_HV PRPA_IN201308UV02_HV
Kravspesifikasjon - integrasjonskrav til nytt Krav til sikkerhet: Web tjenesten skal tilfredsstille sikkerhetskrav som spesifisert i 4. 3.3 Starte Løsningen med oppstartsparametre Valgt pasient skal kunne overføres automatisk fra pasientregister (DIPS PAS) til Løsningen ved at Løsningen startes med (blant annet) pasient Id som oppstartsparameter. Skjermbilde for valgt pasient skal vises i Løsningen. Side 10 av 16
3.3.1 Arbeidsflyt Sentrale tjenester Stamcelle system Bruker Figur 3 Motta pasient id og opprette pasient
3.3.2 Teknisk krav Løsningen skal kunne startes vha DIPS Verktøyintegrasjon. Det er to måter å aktivere/starte en annen applikasjon fra DIPS EPJ/PAS: 1. Starte applikasjon ved å spesifisere kommandolinje (CMD) m/parametere 2. Registrere COM komponent som lastes og kalles hver gang bruker velger et spesifisert menyvalg. a. Kall til COM-komponent som implementerer grensesnittet IDIPSToolsIntegration b. IDIPSToolsIntegration har én metode: Execute (IStrings) c. 3.part kan integrere uten å være avhengig av endringer i DIPS-klienten d. Kan overføre en rekke parametere, f.eks. pasientid og/eller navn. Merknad: Det er ikke mulig å sende over passord som parameter. Brukernavn er derimot mulig å sende inn, f.eks. aktiv bruker i DIPS. Ved mottak av pasient id skal Løsningen søke frem pasienten i internt register. Hvis pasienten ikke finnes skal denne hentes i sentralt pasientregister ved å benytte HL7-tjenesten PatientRegistry.GetDemographics, før den opprettes i internt register. Request: PRPA_IN201307NO Response: PRPA_IN201308NO ContextManager fra DIPS DIPS ContextManager gir konstekststyring mellom DIPS og andre applikasjoner. Beskriv eventuelt løsningens muligheter i tilknytning til dette eller annen kontekststyring. 3.4 Oppdatering av pasient ID Løsningen skal slå sammen pasient id er dersom disse peker til samme pasient. Et eksempel på dette kan være en pasient med H-nummer som allerede er registrert med sitt offisielle F-nummer fra tidligere. Funksjonaliteten vil være avhengig av om hvilken informasjon som allerede er registret på pasienten i Løsningen: Både gammel og ny id er kjent pasientinformasjon kobles sammen. Bare gammel id er kjent id oppdateres. Bare ny id er kjent ingen oppdatering. Verken gammel eller ny id er kjent ingen oppdatering. 3.4.1 Teknisk krav Løsningen skal kunne motta meldingen PatientRegistry.DuplicatesResolved og slå sammen pasientinformasjon eller oppdatere pasient id en. Løsningen må oppdatere pasientdemografi i lokal database dersom pasienten finnes. For ukjente pasienter skal meldingen avvises. I begge tilfeller skal Løsningen kunne sende en kvittering (ack) på at meldingen er mottatt. Det skal dog være konfigurerbart om Løsningen skal sende slike kvitteringer. Meldingsformat: PRPA_IN201304NO
Kvittering: MCCI_IN000002UV01 Kravspesifikasjon - integrasjonskrav til nytt 3.5 Oppdatering av pasientdemografi Løsningen skal oppdatere pasienter som har fått oppdatert pasientdemografien i DIPS. Dette er særlig relevant i de tilfellene der pasienten er oppdatert til død i DIPS, men er også relevant for andre endringer på pasientdemografien. 3.5.1 Teknisk krav Løsningen skal kunne motta meldingen PatientRegistry.RecordRevised. Denne meldingen inneholder oppdatert pasientdemografi. Løsningen må oppdatere pasientdemografi i lokal database dersom pasienten finnes. For ukjente pasienter skal meldingen avvises. I begge tilfeller skal Løsningen kunne sende en kvittering (ack) på at meldingen er mottatt. Det skal dog være konfigurerbart om Løsningen skal sende slike kvitteringer. Meldingsformat: PRPA_IN201302NO Kvittering (Ack): MCCI_IN000002UV01 Side 13 av 16
Kravspesifikasjon - integrasjonskrav til nytt DIPS MessageBroker DIPS BizTalk PatientRegistry.RecordRevised PRPA_IN201302NO Receipt ack MCCI_IN000002UV01 Oppdatert pasient KITH XML AppRec KITH XML Ny løsning Side 14 av 16
Kravspesifikasjon - integrasjonskrav til nytt 3.6 Hente sosiodemografiske data fra EPJ Beskriv løsningens muligheter for å hente sosiodemografiske data fra DIPS. 3.7 Kliniske data fra EPJ til ny løsning 3.7.1 Pasientforløp/pasienthistorie Systemet skal kunne hente opp en pasients kontakthistorikk ved hjelp av sentral tjeneste. Tekniske krav For å hente pasienthistorikk for en pasient fra DIPS skal web tjenesten CareRecordManager.GetCareRecordProfile benyttes: Request: Response: QUPC_IN043100NO QUPC_IN043200NO Tjenesten returnerer de 20 siste oppholdene i sykehuset. Beskrivelse av Web tjenesten, samt wsdl, skjema og eksempelmeldinger er tilgjengelig på http://hl7.ihelse.net. 3.7.2 Psykiatri og rus Beskriv løsningens muligheter for uthenting av følgende informasjonselementer fra DIPS Vedtaksoversikt Uferdige Vedtak Registrerte GAF-verdier Tvangsmidler MADR-verdier Rusrelaterte data 3.7.3 Laboratoriesvar Beskriv løsningens muligheter for uthenting av laboratoriesvar fra andre fagsystem eventuelt fra DIPS. Side 15 av 16
3.7.4 Medisiner Kravspesifikasjon - integrasjonskrav til nytt Beskriv løsningens muligheter for uthenting av eventuelle registrerte medikamenter på pasienten fra andre systemer. 3.8 Kliniske data til EPJ fra ny løsning Beskriv løsningens mulighet for å oppdatere DIPS med aktuelle data fra løsningen. 3.9 Uttrekk til forsknings- og kvalitetsregistre Beskriv funksjonaliten i løsningens for uttrekk av data til forsknings- og kvalitetsregistre 3.10 Uttrekk til statistikkprogram Beskriv funksjonaliten i løsningens for uttrekk av data til statistikkprogram som SPSS o.l.. 4 Sikkerhet i Web services For å konsumere Web services må en brukerkode og tilhørende passord inkluderes i SOAP header til Web services spørringen. SOAP header vil se slik ut (forenklet eksempel): <soapenv:header> <wsse:security xmlns:wsse="(..)" soapenv:mustunderstand="1">.. <wsse:usernametoken somenamespace:id= uuid-060c77ce-... > <wsse:username>wsconsumer</wsse:username> <wsse:password wsse:type=... >SecretPassword</wsse:Password> </wsse:usernametoken> </wsse:security> </soapenv:header> Figur 2: Eksempel på forenklet SOAP Header for sikkerhet i Web services All trafikk over Web services skal være kryptert. Side 16 av 16