Versjonssammenligning

Nøkkel

  • Denne linjen ble lagt til.
  • Denne linjen ble fjernet.
  • Formateringen ble endret.

Generell informasjon

Panel
panelIconIdatlassian-light_bulb_on
panelIcon:light_bulb_on:
panelIconText:light_bulb_on:
bgColor#FFFAE6

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:

  1. Ulike EPJ-er har både ulikt innhold og ulike muligheter for å hente innholdet ut

  2. 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.

Info

Nasjonalitet og språk

Nasjonalitet blir kun returnert hvis pasientens nasjonalitet er lagret i henhold til ISO3166 og ISO639. Grunnen til dette er det ikke er noe standardisert måte å lagre pasientens nasjonalitet eller språk i EPJ-ene.

Ta stilling til

Panel
panelIconIdatlassian-light_bulb_on
panelIcon:light_bulb_on:
panelIconText:light_bulb_on:
bgColor#FFFAE6

Tjenstlig behov

Utvid
titleLes mer om 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.

Panel
panelIconIdatlassian-light_bulb_on
panelIcon:light_bulb_on:
panelIconText:light_bulb_on:
bgColor#FFFAE6

Brukerens identifikator

Utvid
title
Eksempeltegning av tjenstlig behovImage Removed

Identifikator

Les mer om identifikator

Det er i all hovedsak to typer identifikatorer tilknyttet pasientene i EPJ-systemet:

  1. Fødselsnummer, D-nummer eller felles hjelpenummer

  2. 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

som oppfyller det 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.

Panel
panelIconIdatlassian-light_bulb_on
panelIcon:light_bulb_on:
panelIconText:light_bulb_on:
bgColor#FFFAE6

Representasjon av brukeren

Utvid
titleLes mer om representasjon

Hvordan skal brukeren representeres? Hvilken informasjon trengs, og hva kan EPJ-en tilby? Hvordan er brukerne organisert i velferdsteknologisystemet per i dag? Er brukerne organsiert på ligende måte i EPJ-en?9

Panel
panelIconIdatlassian-light_bulb_on
panelIcon:light_bulb_on:
panelIconText:light_bulb_on:
bgColor#FFFAE6

Hendelser

Utvid
titleLes mer om ulike hendelser

Hva skal skje når en bruker

… blir opprettet eller får oppdatert pasientinformasjon i velferdsteknologisystemet

… blir opprettet eller får oppdatert pasientinformasjon i EPJ

… har tjenester som er knyttet til ulike avdelinger/grupper i velferdsteknologisystemet

… får tilordnet en ny tjeneste som velferdsteknologisystemet har ansvar for

… slutter å motta tjenestene som velferdsteknologisystemet har tjenstlig behov for

… får en ny avdeling som har ansvar for brukerens tjeneste

… ikke lengre mottar tjenester som velferdsteknologisystemet håndterer

… får en innsynsbegrensning i journalen sin

… flytter til hemmelig adresse

… flytter til en annen kommune eller avgår med døden

Panel
panelIconIdatlassian-light_bulb_on
panelIcon:light_bulb_on:
panelIconText:light_bulb_on:
bgColor#FFFAE6

Oppsett og struktur

Utvid
titleLes mer om oppsett og struktur

Hvordan passer:

  • Dagens prosess i velferdsteknologisystemet ved opprettelse av ny tjeneste for bruker? Hvordan skal det fungere etter oppsatt opp mot ønsket funksjonalitet for integrasjonen?

  • Tjenesteoppsettet i EPJ med tjenesteoppsettet i VFT-systemet

  • Avdelingsstrukturen i EPJ med avdelingsstrukturen i VFT-systemet


EPJ-spesifikk informasjon

Gerica

Les mer om Gericas API-er her.


Pasientrelasjoner

VKP har foreløpig ikke mulighet til å returnere pasientrelasjoner fra GericaGerica returnerer ikke pasientrelasjoner per nå.

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 hvis det er ønskelig.

Avdelingstilhørighet

Pasient

Feltet geographicalLevel Patient.GeographicalLevel i Gerica gjengis gjennom patient.managingOrganization i VKP sin FHIR-profil. 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 enkeltpasienterreturnerer ikke pasientens avdelingstilhørighet ved spørringer på enkeltpasienter.

Tjeneste/tiltak

Feltet PatientCareServices.GeographicalLevel i Gerica gjengis episodeOfCare.managingOrganization i VKP sin FHIR-profil. Det er da tilhørigheten til pasientens tjenester som blir gjengitt, ikke pasientens tilhørighet.

Utvid
titleNærmere informasjon om GeographicalLevel

Nivået settes manuelt i kommunens EPJ-instans, og er knyttet til egne rutiner i hver kommune. Det er ingen automatisk relasjon til aktive tjenestermellom pasient og tjenester, disse tilknyttes avdelinger uavhengig av hverandre. En pasient i Gerica vil i tillegg kunne ha tilknytning til ulike tjenester/tjenesteleverandører som hjemmesykepleie rødt team, praktisk bistand øst, lokaliseringstjeneste leverandør X osv. Dette vil ikke fremkomme av dette feltet.

Utvid
titleNærmere informasjon om ManagingOrganization

Avdelingen pasient er knyttet til på sitt brukerkort (geographicalLevel) knyttes til managingOrganization ved hjelp av en identifier.

  • System settes til http://gerica.tietoevry.no/geographicallevel

  • Value settes til avdelings-ID-en/geografisk nivå. For tjeneste/tiltak er det det nederste nivået som gjengis

  • Display settes til avdelingsnivåstien, separert med |

Eksempel:

Kodeblokk
"managingOrganization": { 
    "identifier": { 
        "system": "http://gerica.tietoevry.no/geographicallevel", 
        "value": "1.12.5" 
    }, 
    "display": "Christiania|Vest|Blommenholm" 
}

Tiltak/tjeneste

Gerica har delt opp tjeneste/tiltak i en trestruktur som kommunen selv setter opp. Les mer om avdelingstilhørigheten til tjenester og tiltak i avsnittet over.

Utvid
titleEksempel
Kodeblokk
"type": [
    { 
    "coding": [
          { 
          "code": "2.2.3", 
          "display": "Medisinering i hjemmet" 
          }
      ]
    }
]

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:

Utvid
titleHemmelig adresse og/eller kontaktinformasjon

I informasjonen VKP får fra Gerica, finnes det felt som heter IsSecretAddress og IsSecretCommunication. Hvis disse feltene er satt til true, vil VKP ikke videreformidle henholdsvis adresseinformasjon eller kontaktinformasjon (f.eks. telefonnummer). Isteden vil henholdsvis address.text og/eller telecom.value settes til “not available”.

VKP anbefaler at velferdsteknologisystemet behandler hemmelig adresse/kontaktinformasjon annerledes enn hvis det ikke er oppgitt mangler adresse/kontaktinformasjon. I de tilfellene vil informasjonen mangle i VKP sin respons, i kontrast til eksplisitt oppgitt som “not available”.

Utvid
titleSperret for personell

Gerica har ulike former for sperringer som kan settes opp for å forhindre innsyn i en pasients journal. Dette formidles til VKP gjennom et informasjonsfelt som heter AccessRestriction. Hvis VKP får noe oppgitt i dette feltet, uavhengig av hva slags sperring det er, så vil ikke pasienten returneres. Isteden vil det returneres en 403-melding med en operation outcome (code 1.2) som gjør det mulig for velferdsteknologisystemet å forstå at det dreier seg om et tilfelle med sperret personell (les mer her).

Ulike velferdsteknologisystemer løser tilfeller som dette på ulikt vis, og den enkelte leverandør bør diskutere egen funksjonalitet med de aktuelle Gerica-kommunene. Her er eksempler på ulike varianter:

  • Informasjonsmelding til sluttbruker som forsøker å hente en pasient med sperring.

    • Eksempel: “Det er lagt til sperringer for journalen. Snakk med nærmeste leder før du registrerer manuelt“ eller “Det kan ikke
      hentes informasjon fra ekstern journal“

  • Trigging av mail til virksomhetsadministratoren i velferdsteknologisystemet, for å sikre videre oppfølging av tilfellet. I mailen bør det oppgis hvilken ansatt-id som trigget forespørselen, samt tidspunkt. For å komplementere dette må det tilgjengeliggjøres en loggløsning der det er mulig å slå opp for å finne hvilket f.nr. det ble søkt etter.

    • Eksempel: “Ansatt id: 224 har forsøkt å hente inn informasjon fra EPJ for en person som har sperret for enkelte brukere i journalen. Du må sikre at disse sperringene ivaretas for pasienten i [velferdsteknologiløsning]. Sjekk revisjonsloggen for flere detaljer”

  • Eventuelt ingen melding til sluttbruker, kun trigging av mail (se over) og blanke felter.

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
.managingOrganization
.display

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.

VKP leverer planlagte og utførte besøk for dagens dato, i form av en vkp_carePlan-ressurs av type Arbeidsplan

Visma Profil

Besøksplan

I Gerica er det foreløpig kun mulighet til å hente ut pågående og planlagte besøk, dvs. at man ikke får hentet gjennomførte besøk.

Les mer om Gericas API-er her.

Visma Profil


Pasientrelasjoner

VKP har tidligere ikke returnert pasientrelasjoner fra Visma, men vil utvide med dette i 2022.

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

Det er kun mulig å hente ut pasienter som er i aktiv tjeneste, ikke pasienter som har tjenesten frem i tid.

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.

Utvid
titleNærmere informasjon om ManagingOrganization

Pasientens tilhørighet knyttes til managingOrganization ved hjelp av en identifier.

  • System settes til http://profil.visma.no/district

  • Value settes til [Distrikt-id].[Sone-id].[Delsone-id]. Eksempel: 1.12.5

  • Display settes til [Distrikt] | [Sone] | [Delsone] . Eksempel: (separert med |)

Eksempel:

Kodeblokk
"managingOrganization": { 
    "identifier": { 
        "system": "http://profil.visma.no/district", 
        "value": "1.12.5" 
    }, 
    "display": "Christiania|Vest|Blommenholm" 
}

Hvis kommunen ikke bruker alle tre nivåene, vil dette gjengis med tomrom, mens skilletegnet (. eller |) beholdes. Eksempler:

  • Manglende distrikt:

    • Value: .12.5

    • Display: |Vest|Blommenholm

  • Manglende delsone:

    • Value: 1.12.

    • Display: Christiania|Vest|

  • Manglende sone og delsone:

    • Value: 1..

    • Display: Christiania||

Besøksplan

Visma Profil har funksjonalitet for å sette en grense for hvor mange timer frem og tilbake eksterne har lov til å hente besøk fra. Hvis dette er aktivert i kommunens EPJ, vil dette overstyre eventuelle parametere som er sendt inn til VKP.

CosDoc


Pasientrelasjoner

Vi henter nærmeste pårørende kun når man henter én pasient pga lasten som påføres CosDoc.

Tjenstlig behov

Det er kun mulig å hente ut pasienter som er i aktiv tjeneste, ikke pasienter som har tjenesten frem i tid.

Avdelingstilhørighet

I CosDoc knyttes ansvarlig tjenestested til bruker via tjeneste (AvdelingId).

Utvid
titleNærmere informasjon om ManagingOrganization

Avdelingsknyttes til managingOrganization ved hjelp av en identifier.

Eksempel:

Kodeblokk
"managingOrganization": { 
    "identifier": { 
        "system": "http://cosdoc.dips.no/avdelingstre", 
        "value": "1.10.100" 
    }, 
    "display": "Christiania|Vest|Blommenholm" 
}