Generell informasjon
Ting å ta stilling til
Dette er eksempler på ting som kommunen og velferdsteknologileverandøren må ta stilling til i fellesskap:
Brukerens identifikator – hva skal brukes?
Velferdsteknologisystemets tjenstlige behov
Representasjon av brukeren i velferdsteknologisystemet
Hvilken informasjon trengs om brukeren?
Hvordan er brukerne organisert i velferdsteknologisystemet – er de knyttet mot f.eks. tjenester eller avdelinger?
Hva skal skje når en bruker:
Blir opprettet eller får oppdatert pasientinformasjon (enten i velferdsteknologisystemet eller i EPJ)
Flytter til en annen kommune
Slutter å motta tjenestene som velferdsteknologisystemet har tjenstlig behov for
Avgår med døden
Varierende innhold
Det er to elementer som skaper potensiell variasjon i hva som returneres:
Ulike EPJ-er har både ulikt innhold og ulike muligheter for å hente innholdet ut
Ulike kommuner har fylt ut informasjonen i sin EPJ ulikt
Hvis en leverandør av et velferdsteknologisystem ønsker seg uthentingsfunksjonalitet fra kommuner med ulike EPJ-er, er det dermed en del hensyn som må tas for å kunne oppnå en felles løsning.
Tjenstlig behov
VKP returnerer kun informasjon som det er tjenstlig behov for å spørre om. Dette løses ved at velferdsteknologisystemet må oppgi en eller flere tjenestekoder i denne lista ved forespørsel om pasientinformasjon. Kommunen har satt opp hvilke tjenestekoder som tilsvarer hva i deres EPJ, samt hvilke velferdsteknologisystemer som skal ha mulighet til å bruke hvilke tjenestekoder (begge disse oppsettene kan de se på Min side).
Det er altså kommunen som sitter på styringen av hvilke pasienter de ulike velferdsteknologisystemene kan hente ut fra kommunens EPJ. Les mer her.
Identifikator
Det er i all hovedsak to typer identifikatorer tilknyttet pasientene i EPJ-systemet:
Fødselsnummer, D-nummer eller felles hjelpenummer
EPJ-ID (individuelt løpenummer i EPJ-systemet, unik for hver installasjon/kommune)
Begge disse typene identifikatorer kan brukes for å hente ut enkeltpasienter. Les mer om hvordan her. Ved å gjøre et kall uten å oppgi identifikator, vil man få returnert alle relevante pasienter (altså pasienter med tjenstlig behov).
Nasjonalitet
Nasjonalitet blir returnert hvis pasientens nasjonalitet er lagret i henhold til ISO3166. Grunnen til dette er det ikke er noe standardisert måte å lagre pasientens nasjonalitet i EPJ-en.
Språk
Språk blir returnert hvis pasientens språk er lagret i henhold til ISO639. Grunnen til dette er det ikke er noe standardisert måte å lagre pasientens språki EPJ-en.
EPJ-spesifikk informasjon
Gerica
Les mer om Gericas API-er her.
Pasientrelasjoner
VKP har foreløpig ikke mulighet til å returnere pasientrelasjoner fra Gerica.
Tjenstlig behov
For å definere det tjenstlige behovet til velferdsteknologisystemet, bruker VKP i Gerica sitt tilfelle det som blir returnert i feltet PlannedAction fra CareServices-kallet. Det er mulig å også få returnert pasienter som har tjenesten et stykke frem i tid.
Avdelingstilhørighet
Feltet geographicalLevel i Gerica gjengis gjennom patient.managingOrganization. Det er da pasientens tilhørighet som blir gjengitt, ikke tjenestens tilhørighet. Merk at Gerica per nå kun returnerer avdelings-ID-en for å definere geographicalLevel, altså at navnet på nivået ikke sendes med.
VKP ikke mulighet til å returnere managingOrganization når man søker etter enkeltpasienter.
Innsynsbegrenset informasjon
Enkelte pasienter har behov for å ha ulik form for tilgangsbegrensning på informasjonen som er om dem i EPJ-systemet. Det er viktig at velferdsteknologisystemet ivaretar sikkerheten til pasientene som har lagt inn sperringer i sitt journalsystem, for eksempel ved å ikke gi mulighet til å legge inn den hemmelige/sperrede informasjonen slik at velferdsteknologisystemet blir en snarvei til informasjon som ikke skal konsumeres.
Gerica har ulik funksjonalitet for hemmelig informasjon og sperringer:
CosDoc
?
CarePlan.activity.detail.description
Med utgangspunkt i dette kan vi bruke en alternativ filtreringsmetode:
I partnerprofil setter kommunen opp hvilke avdelinger (GruppeId'er) som er relevante for Besøksplan.
For hver av disse kan det angis hvilken tekst som skal vises for hver aktivitet.
Hvis det jeg har beskrevet om avdelinger over stemmer for Bamble, vil partnerprofil / kommunekonfigurasjon da se ut som følger:
Tiltaksplanene i CosDoc er i utgangspunktet strukturert oppbygd, men spørsmålet er hvordan den enkelte kommune bruker tiltaksplanen ift. tjenesten lokalisering. Vi ser for oss at dette må "standardiseres" på et vis når informasjon skal hentes ut til knutepunktet.
Etter møte med 110 Telemark og NetNordic 3. oktober, kom det frem at 110 Telemark ikke ønsker at vi returnerer kodene fra vårt kodeverk, men heller fullt navn fra EPJ (eksempelvis TejensteTypeBeskrivelse fra CosDoc).
For forespørsel om mange: Pårørende blir ikke hentet ut pga lasten som påføres CosDoc. De blir returnert ved én.
Vi henter nærmest pårørende kun når man henter en pasient.
Organisasjon | EpisodeOfCare | Det er denne informasjonen vi tenker å formidle i form av en streng – eksempel "Oslo|Gamle Oslo|Øst|Kampen". I CosDoc knyttes ansvarlig tjenestested til bruker via tjeneste, AvdelingId. |
|
Visma Profil
Tjenstlig behov
Det må være huket av for “ResponssenterFlagg” på pasientenes tjeneste i Visma Profil for at VKP skal få returnert informasjon om pasienten fra Vismas API-er.
Visma Profil bruker IPLOS-kodene som utgangspunkt for tjenestebeskrivelsene sine. VKP mapper disse om til eget kodeverk for tjenstlig behov som velferdsteknologileverandørene forholder seg til.
Avdelingstilhørighet
Visma Profil strukturerer pasientens tilhørighet i distrikt, sone og delsone (hieratisk under hverandre i en trestruktur). Dette er pasientens tilhørighet, og ikke tjenestens tilhørighet. Det er opp til kommunen hvordan de bruker denne strukturen, og det er ikke alle som bruker alle tre nivåene.