Interaktivt køsystem. Kravspesifikasjon

Transkript

1 Avdeling for medisinsk biokjemi Interaktivt køsystem Prosjektkode: itide Kravspesifikasjon Fil: Dato/tid: Status: Forfattet/revidert av: kravspesifikasjonv06jgg.doc Endelig <Jens G. Gleditsch/ KVV/ EG> 1 Innledning Terminologi og definisjoner verordnet beskrivelse av systemet Funksjonelle krav Kjernefunksjoner for køsystem Integrasjon LIMS Integrasjon klinikksystem Pasientfunksjoner Rapport og ledelsesfunksjoner Tekniske krav verordnede tekniske krav Krav til infrastruktur Sikkerhetskrav Integrasjonskrav Visningsflater/ brukergrensesnitt... 11

2 1 Innledning Dette dokumentet er en overordnet spesifikasjon for et fleksibelt og dynamisk køsystem, primært utformet for en pasientrettet prøvetaking i sykehus. Hensikten med systemet er å bedre kvaliteten i den pasientrettede prøvetakningsvirksomheten ved å optimalisere tids- og ressursbruk, både for pasient og for tjenesteyter, og være et dynamisk verktøy for kontinuerlig effektivisering og kvalitetsarbeid. Systemet skal gi mulighet for tildeling av kønummer og aktivitetsregistrering ved prøvetaking. Systemet skal i tillegg støtte en rekke statistiske funksjoner for overvåkning og rapportering av ventetider. Systemet skal også ha dynamiske grensesnitt mot kliniske pasientadministrative systemer, laboratorieinformasjonssystemer (LIMS) og pasientportaler. Systemet skal være basert på åpne teknologistandarder både mht. arkitektur, verktøy og grensesnitt, og være fleksibelt utformet for å kunne tilpasses forskjellige behov og organisatoriske forhold. Merk at systemet ikke er tenkt som noe booking-system, selv om det ikke skal utelukkes mulig funksjonalitet som understøtter dette. Det kan som kjent oppstå et forventningsproblem i grenselandet mellom bookingsystemer og køsystemer mht. til ventider før tjenester utføres, og som må vurderes nøye ved presentasjon av løsninger og tjenester. 2 Terminologi og definisjoner Kø (pasient) Booking Prøvetaking LIMS (eng.) Portal (IKT) Kø-portalen Ventetid I denne sammenhengen en organisering av pasienter med behov for tjenester (prøvetaking) ved tildeling av sekvensnummer (kølapper). I denne sammenheng en forhåndsreservasjon og tidfesting av en tjeneste. En kvalifisert tjeneste i tilknytning til medisinske laboratorier for fremskaffelse av biologisk materiale fra pasienten, som regel av blod gjennom venepunksjon, men andre undersøkelsesprosedyrer kan også forekomme. Laboratory Information Management System, IKT-systemer i medisinske laboratoriet som understøtter all arbeidsflyt og rapportering. Et rammeverk av IKT-systemer som gir en enhetlig og brukervennlig tilgang til informasjon og ressurser innen en organisatorisk kontekst (inter/intranett, klinikk, pasient etc..). I denne sammenhengen et sett med IKT-tjenester knyttet til kø-systemet som kan benyttes direkte eller indirekte i andre web-baserte systemer og portaler. Den tid det tar fra pasient melder seg, eller stiller seg til rådighet for prøvetaking, frem til prøvetakerressurs stilles til rådighet for pasienten og prøvetaking. Merk at det i motsetning til alminnelig oppfatning faktisk er fysiologisk korrekt med noe ventetid. I henhold til prosedyrene for korrekt prøvetaking, skal pasienter som regel roe seg ned før prøvetaking for å standardisere de biologiske forhold som undersøkes.

3 3 verordnet beskrivelse av systemet Systemet skal tjene som et integrasjons- og logistikksystem for pasientprøvetaking og primært understøtte følgende kjernefunksjoner. Funksjonene er tildelt en antatt kategorisk modulangivelse som benyttes i alle scenarioer for å angi hvilke funksjoner eller moduler som antas påkrevet for å understøtte ønsket funksjonalitet: Funksjon Modul Registrering og tildeling av kølapp fra kølappautomat utenfor laboratoriet. Ev informasjon om henvendelse i skranken Skrankebasert tildeling (eget personale) av kategoriserte kønummer (fysiske kølapper eller virtuelle kønummer?) Administrere prøvetakningskøer og nummer (inkrementere, vise, understøtte opprop) Varsle når antall og ventetider beveger seg utenfor definerte grenseverdier Logge alle hendelser og tidsbruk til database (ventetid for pasient) Integrasjon med LIMS for å kvittere arbeidsflyt og prosesser til fagsystemet og knytte dette til elementer i LIMS (Rekvisisjon etc.) Informasjon om faktiske og prognostiske køer og ventetider til kliniske- og pasientsystemer (flere alternative visninger innen både dag og uke), samt anbefalte tidspunkt for prøvetaking i spesielle prosedyrer (belastninger etc.) Logiske funksjoner som muliggjør pasientvarsling før prøvetaking etter tildeling av kønummer. Levere oversikter og statistikk (styringsverktøy og kvalitetsindikatorer) Varsle personer (grupper) via e-post, SMS, calling etc. Integrasjon med elektronisk rekvirering i klinikksystem som kan på grunnlag av pasientkategori, rekvirentkode el. inkludere informasjon om prøvetaking, kontaktsted eller andre instrukser til pasienten. Enkle bookingfunksjoner som på grunnlag av manuelle regler eller empirisk tidsbruk kan estimere optimale tidsperioder for prøvetaking i spesielle prosedyrer (belastninger etc.) Dynamisk beregne og justere forventede ventetider basert på oppgaver (pasienter og bookede prosedyrer) og ressurser (prøvetakere) Integrasjon med LIMS for å hente ut fra fagsystemet forventede prøvetakinger basert forhåndsrekvisjoner i systemet. (regelbasert på grunnlag av rekvirentkoder etc.) Pasientorientert tildeling (ved hjelp av egnet infrastruktur og hardware) av kategoriserte kønummer (fysiske kølapper eller virtuelle kønummer) A 0 A B C D E F G H I J K L M N

4 For å beskrive og eksemplifisere dette kan man se for seg følgende typiske hendelsesforløp (scenarioer). Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 Scenario 6 En pasient henvises fra lege på en poliklinikk, ev en innlagt pasient blir sendt til prøvetakingsenheten for blodprøvetaking. Pasienten registrerer seg på kølappautomaten som står utenfor ekspedisjonen. Dersom det er bestilt blodprøver blir pasienten tildelt kølapp med nummer i riktig kø utfra ønsket prioritet (øhjelp eller rutine). Uten forhåndsbestilte blodprøver vil skjermen gi en informasjon til pasienten om å henvende seg i skranken. Pasienten melder seg i skranken og tildeleles en kølapp med nummer, og venter på tur i ventearealet. Når ledig prøvetakere skal betjene aktuelt kønummer, registreres dette elektronisk og ventetiden beregnes. Nummeret vises på en lystavle og pasienten kalles inn til prøvetaking. Prøvetaker utfører sin blodprøvetaking og kvitterer for dette i aktuelt IKT-system. Alle nøkkeltall omkring ventetider og prøvetaking sendes LIMS og registreres for sporbarhet. Det er henvist så mange pasienter til prøvetaking at prøvetakere ikke klarer å ta unna pasientene. Ventetider for pasienter øker (eller forventes å øke) ut over en definert grense for øhjelp eller rutine. Dette utløser et elektronisk varsel til e-post(ledelse), calling SMS, EP tavle el. Varslingen kan gå til utpekte ansatte som da skal bistå i blodprøvetakingen slik at pasientventetider holdes på akseptabelt nivå. En inneliggende pasient skal i løpet av dagen ta en blodprøve og kan sendes til prøvetaking. Sengepostens personell sjekker raskt køtjenestene i et aktuelt portalsystem, og finner et tidspunkt på dagen som prognostisk sett ikke gir lang ventetid for pasienten og informerer pasienten om dette. En inneliggende pasient skal ta en blodprøve så fort som mulig og skal sendes til prøvetaking. Sengepostens personell sjekker raskt køtjenestene i den kliniske portalen, og finner det prøvetakingsstedet som i øyeblikket har kortest ventetid, og sender pasient dit. En pasient er henvist til prøvetaking i en svært hektisk periode med mange ventende. Pasienten ber om SMS-varsling når det estimeres at minutter gjenstår før prøvetaking, og kan derfor velge å vente på varsling i et annet område på sykehuset. I en klagesak mot sykehuset hevdes at pasienten måtte vente i timevis på prøvetaking. Ledelsen sjekker logger i LIMS. Basert på informasjon tilknyttet den aktuelle rekvisisjon kan de dokumentere når prøvetaking var utført og prøven kvittert inn til LIMS, samt påbegynt og avsluttet ventetid for aktuell prøvetaking. A 0 A B D E A C I F F A G I A D E Scenario 7 En poliklinisk pasient blir sendt til blodprøvetakning på A 0

5 Scenario 8 Prøvetakningsenheten. Pasienten har dårlig immunforsvar og må beskyttes fra kontakt med andre pasienter. Blodprøven er allerede bestilt elektronisk. Pasienten registrerer seg på kølappautomaten i gangen Den elektroniske rekvireringen er linket opp mot køsystemet slik at pasienten får informasjon på kølappen om hvilken inngang han/hun skal til for å ta blodprøvene. En pasient er henvist til glukosebelastning. Dette er en tidkrevende prosedyre og må forhåndsbestilles. Mulige tider legges ut fra køsystemet og ledige timer kommer opp for reservasjon. Venesectio er også en tidkrevende prosedyre og ut fra statistisk materiale i køsystemet kan de sette opp mulige tider hvor det vil være mest gunstig å sende pasienter ned til prøvetakningen for venesectio. A J F K Scenario 9 Poliklinikk eller sengepost skal sende pasient til flere undersøkelser og sjekker ventetiden for blodprøvetaking med tanke på at pasientlogistikken skal være mest mulig effektiv. Scenario 10 Poliklinisk pasient skal ta en prøve neste uke, men er uavhengig av en spesiell dag. Legen kan sjekke ikke bare hvilket tidspunkt, men også hvilken dag som normalt er mest gunstig, med tanke på ventetid, ut fra statistikk i køsystemet. Scenario 11 En pasient får beskjed om stipulert ventetid ved ankomst, men så skjer det noe uforutsett og ventetiden øker/minsker. Det bør være mulig at pasienten får beskjed om ny stipulert ventetid, enten ved henvendelse til skranken eller (helst) på infotavle el lign. (Smsvarsling) Scenario 12 Man vet at det er bestilt flere tidkrevende prøvetakinger f. eks. Glukosebelastning eller venesectio. Slik bestilling bør kunne legges inn med estimert tidsforbruk slik at estimert ventetid blir korrigert for dette. Pasienten får informasjon på etikettene om hvilken kølapp som skal trekkes og hvor lang tid belastningen tar. Scenario 13 På samme måte hadde det vært lurt å ha mulighet for å legge inn antall prøvetakere som er tilgjengelig til et gitt tidspunkt eller dag. Det vil kunne gi et bedre inntrykk av hvor lang estimert ventetid vil være. For eksempel hvis det er faglig allmøte og mange prøvetakere er borte samtidig eller mange er syke slik at ventetiden blir lengre denne dagen, enn den normalt ville ha vært, (eller andre årsaker). Scenario 14 Så lenge vi har papirrekvisisjoner og forhåndsrekvirerer bør det være en mulighet for å legge inn dette, slik at vi kan si noe om ventetiden i den perioden pasientene er forventet å komme for prøvetaking. Eks. antall nyretransplanterte pasienter som kommer til kontroll kan variere fra 20 til 40, og det kan gi store utslag på ventetiden for andre pasienter som ikke er i prioritert kø. Scenario 15 Kl aktiveres kølappautomaten i gangen utenfor venteværelset. Prøvetakingsenheten åpner for blodprøvetaking kl Pasienter som er tidlig ute og som oftest har behov for en prioritert blodprøvetaking, kan da trekke kølapp fra EN kø mellom kl og F F A B G I A K B L F M A 0 A N

6 kl Dette er en prioritert kø. Ansatte på laboratoriet kan starte med blodprøvetaking fra denne køen kl og således spares tid til registrering og/ eller skrankefunksjon som forsinker prosessen. Kl skrus kølappautomaten over på ordinær funksjon med registrering av pasient og tildeling av kølapp uti fra ønsket prioritet. De aktuelle scenarioer er ikke uttømmende for alle mulige hendelsesforløp, men kan anses som typiske for et velfungerende køsystem.

7 4 Funksjonelle krav 4.1 Kjernefunksjoner for køsystem Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kunne konfigureres dynamisk og hierarkisk for multiple uavhengige kø-kategorier: Lokalisasjon (geografisk område hvor prøvetaking utføres) Pasientkategori (rekvirentkode/prosedyre/ behandling etc) Prioritet (akutt el.) Løsningen skal registrere alle hendelser omkring venting og ressursuttak (prøvetaking) og forutsetter elektronisk rekvirering: Påbegynt venting ankomstregistrering og tildeling av kønummer til pasient (kønummer, muligens pasient-id) Kategoriinformasjon (lokalisasjon, kategori, prioritet etc.) Avsluttet venting innkalling til prosedyre (prøvetaking) peratørinformasjon (prøvetaker) Avsluttet prosedyre (prøvetaking) Prosedyreinformasjon (prøvenummer) Løsningen skal understøtte arbeidsflyt for alle brukere av køsystemet: Tildeling av kønummer i ønsket kategori (virtuelt eller ved utskrift av lapp/etikett) Viser dynamiske og konfigurerbare nummeroversikter på en eller flere tavler (storskjermer) og/eller skjermbilder på PC. M Gjelder bare første kulepunkt Allokering av ressurs til kønummer og prosedyre (prøvetaking) Avslutning av prosedyre og fristilling av ressurs.

8 4.2 Integrasjon LIMS Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kommunisere meldingsbasert med LIMS: Benytte standard protokoller der dette er relevant (antatt HL7- basert og KITH-XML) Konfigureres for alternative LIMS-systemer og konnektivitetsløsninger basert på lokalisasjon og kategori. Utføre sanntidsspørring etter forhåndsrekvirert rekvisisjon på rekvisisjons-id Melde hendelsesinformasjon til LIMS etter prøvetaking Benytte direkte eller indirekte konnektivitetløsninger (Nettverk/IP, filbasert el. avhengig av LIMS) 4.3 Integrasjon klinikksystem Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kunne tilby tjenester til andre web-baserte portalsystemer i nettverk. Vise aktuelle ventetider i forskjellige køer (lokalisasjoner og kategorier) Vise forventet ventid (prognostisk) for andre tidspunkt i forskjellige køer (lokalisasjoner og kategorier) Mulig tildeling av kønummer i ønsket (predefinert) kategori (virtuelt eller ved utsrift av lapp/etikett) Vise prosedyrebasert informasjon for å forberede pasienter for prøvetaking.

9 4.4 Pasientfunksjoner Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kunne tilby tjenester til mulige pasientorienterte web-baserte portalsystemer i nettverk. Løsning skal kunne vise prosedyrebasert informasjon for å forberede pasienter for prøvetaking. Vise aktuelle ventetider i forskjellige køer (lokalisasjoner og kategorier) Vise forventet ventid (prognostisk) for andre tidspunkt i forskjellige køer (lokalisasjoner og kategorier) Ved tildeling av kønummer kan pasienten ønske seg elektronisk varsling før prøvetaking (antagelig SMS-basert) 4.5 Rapport og ledelsesfunksjoner Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kunne levere en rekke faste og ad hoc rapporter over virksomheten. Faste konfigurerbare oversikter over køer, kategorier, antall prøvetakinger og tidsbruk per tidsenhet (timer, dager, uker etc.) Akkumulerte oversikter over totaler Fritt definerbare søk og uttrekk basert på standardiserte rapportverktøy Løsningen skal kunne konfigureres for å varsle i sanntid når forhåndsdefinerte kritiske indikatorer overskrides. Aktuelle pasientventetider i en/flere køer Forventet pasientventetider i en/flere køer (basert på erfaringsbasert tidsbruk og antall ventende) Varsling via flere (mulige samtidige) alternative elektroniske kanaler til en eller flere definerte mottakere. Varsling til elektroniske tavler eller portalsystemer.

10 5 Tekniske krav 5.1 verordnede tekniske krav Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kunne konfigureres og kjøres på en Linux basert server med Apache. Løsning skal kunne konfigueres og kjøres på en virtuell server. Løsning skal kunne leveres med en PostgreSQL database eller racle. Løsning skal kunne håndtere forespørsler til og fra en Linux basert server i racle PL/SQL og InterSystems Cache. Løsning skal kunne vises på PC, nettbrett, telefoner og andre utstyr med nettleser. Løsning skal kunne konfigureres og leveres med norsk som hovedspråk med engelsk som alternativ. Løsning skal kunne konfigureres og leveres med andre språk. Løsning skal kunne håndtere flere siter samtidig. Løsning skal kunne lett vedlikeholdes og administreres. Løsning skal kunne tåle feil internt og fra andre systemer, dvs, ha høy motstandsdyktighet og pålitelighet. Algoritmisk håndtering av eks ulike køer, antall prøvetakere, siter, etc ved avvikende hendelser 5.2 Krav til infrastruktur Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kunne samkjøres og brukes mht sykehusets nåværende infrastruktur og datasystemer. Løsning skal kunne bruke en Public-Key-Infrastructure, PKI for sikker kommunikasjon og verifisere brukeren ved digital signatur.

11 5.3 Sikkerhetskrav Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kunne samkjøre med sykehusets bruker logon og autentisering for å hente bruker profil. Løsning skal kunne håndtere sykehusets single-sign-on Lightweight Directory Access Protocol på samme måte som LIMS og DIPS. Løsning skal kunne håndtere søk i LIMS for å hente ikkesensitiv pasient informasjon ved bruk av Public-Key- Infrastructure, PKI for sikker kommunikasjon. Løsning skal kunne opprettholde dataintegritert og tilgjengelighet. 5.4 Integrasjonskrav Nr Krav Kravets viktighet (/H/M/L) Tilbyder oppfyller krav (ja/ nei) Løsning skal kunne integreres med LIMS. Løsning skal kunne integreres ved flere siter. Systemet må testes ved første implementering Løsning skal kunne integreres med DIPS

12 5.5 Visningsflater/brukergrensesnitt Kjernefunksjon tildele kønummer Kjernefunksjon tildele kønummer fra skranken

13 Kjernefunksjon informasjon til pasienter, skjerm med oversikt over status på ulike køer i venterom Kjernefunksjon status for de ulike køer, tilgjengelig i skranke og i prøvetakingsrom

14 Kjernefunksjon administrere kønummer (opprop) Kjernefunksjon oversikt med kun EN kø i bruk

15 Innovasjonselementer (poli) klinikksystemer, integrasjon mot DIPS

16 Innovasjonselementer pasientfunksjoner, informasjon på SMS Innovasjonselementer informasjon på web om aktuell og prognostisk ventetid Innovasjonselement ledelsesfunksjon, adminstrasjon av køen(e) (1)

17 Innovasjonselement ledelsesfunksjon, adminstrasjon av køen(e) (2), registrering av prøvetakere Innovasjonselement ledelsesfunksjon, adminstrasjon av køen(e) (3), informasjon til pasientene på kølappskriver

18 Innovasjonselement ledelsesfunksjon, adminstrasjon av køen(e) (4), administrere kriterier for assistanse

19 Kontaktflater fra start til slutt Administrasjons -grensesnitt C:\Documents and Settings\uxonrn\Lokale innstillinger\temporary Internet Files\Content.utlook\35JZBUE9\Kravspesifikasjon-final.doc, side 19 av 20

20 Revisjonslogg Versjon Dato Skrevet/redigert Endring av 01 <?> <?> Dokumentmal Jens G. Gleditsch 2. utkast Kham Viravong 3. utkast Eva grønn C:\Documents and Settings\uxonrn\Lokale innstillinger\temporary Internet Files\Content.utlook\35JZBUE9\Kravspesifikasjon-final.doc, side 20 av 20