Description på decision-ref

[mortsten]

Det bør være e mulighet for valgfri "description" i attributtet decision-ref

[runegri]

Siden informasjonselementet ikke kan valideres så mener NHN feltet må håndteres som fritekst. Siden det er en risiko for at et fritekstfelt kan inneholde pasientinformasjon så ønsker ikke NHN at HelseID skal ta i mot denne informasjonen.

Klarer vi å bli enige om et kodeverk her?

[eirikbroen]

Kan vi endre typen på dette feltet til å ta med seg code, system og assigner. Legge opp til at det er påkrevd å legge til en gyldig OID som identifiserer kodeverket og åpne for at det er lov med lokale kodeverk? Må da i så fall legge opp til en mekanisme for å kunne slå opp i nevnte kodeverk. I starten kan vi kanskje bli enige om et par kodeverk og gjøre disse tilgjengelige via kodeverkserver?

` decision-ref" : { "id": "8<.. id til lokal tilgangsbeslutning, unik for konsument og autogenerert i EPJ ..>8" , "code": "Legekonsultasjon", "system": "urn:<OID>", "assigner": "HelseSørØst", "user-selected": false, }

[steinarnoem]

Burde det ikke være opp til den behandlingsansvarlige å vurdere personvernskonsekvenser og å gjennomføre eventuelle risikovurderinger? Hjemmelsgrunnlaget ligger i pasientjournalforskriften §14 - altså er det konsument/kilde som har behandlingsansvar for opplysningene. At dokumentasjonen overføres til kilden og lagres der er en del av oppgavefordelingen mellom partene, hvor NHN har rollen som databehandler.

Av en eller annen grunn får jeg ikke til å assigne @richardhus til dette issuet 👯‍♂️ Så jeg setter den til @runegri i stedet :)

[mortsten]

Det overordnede behovet decision-ref dekker, er å kunne spore beslutningen på tvers av aktører. I utgangspunktet bør ID være dekkende for dette formålet. User-selected er viktig å ha med for å bedømme hvordan beslutningen oppstod. I stor grad bør de andre attributtene i datamodellen dekket behovet som beskriver beslutningen om tilgang. Kan gi en verdi å gjøre en ny vurdering fra spesialist om vi får dekket vårt behov gjennom de andre attributtene i datamodellen.

Videre er jeg enig med både @eirikbroen og @steinarnoem på generelt grunnlag rundt både risiko og det å akseptere lokale kodeverk og assigner på generelt grunnlag.

[runegri]

Hvis vi kan kutte ned til å bare inkludere en ID så er jo saken her veldig enkel. Da må vi bare definere en valideringsregel for hvilke tegn vi inkluderer og en maksimal lengde. Kan vi si at dette skal være en UUID?

[eirikbroen]

Vil tro at en enkel uuid kan fungere godt for mange systemer, men forstår det slik at for Dips er det et ønske om at denne referansen skal bære med seg noe mer innhold. Altså at det er en sammensatt verdi som sier noe om tidspunkt, type beslutning osv. Sammensatt referanse vil ikke være globalt unik, men unik innenfor en virksomhet/system.

Kanskje mulig med en en valideringsregel som tar høyde for en slik sammensatt referanse også? Har du et eksempel på en slik referanse @mortsten?

Ut over det så er jeg enig med @steinarnoem og tenker det er viktig å avklare hvilket ansvar HelseID har mht å validere innhold i disse attributtene.

[steinarnoem]

Dette burde jeg antagelig kunne svare på selv (ettersom jeg har hatt gleden av å jobbe med spesifikasjonen over tid), men for å være ærlig så husker jeg ikke... De ulike formålene med decision_ref og "purpose_of_use_details" kommer tydelig fram i spesifikasjonen, men kan noen beskrive den praktiske og prinsipielle forskjellen mellom en referanse til lokal beslutning i decision ref og "purpose_of_use_details", som er en oppsummering av tilgangsbeslutningen i helsepersonellets lokale journalsystem?

[eirikbroen]

En forskjell på decision_ref og purpose_of_use_details er at decision_ref skal på et eller annet nivå være unikt slik at det kan benyttes til f.eks å sammenstille logg fra flere dokumentkilder for samme oppslag slik at visning til innbygger kan være mer oversiktlig. Decision_ref peker på en og samme sesjon (kan være samme verdi for oppslag på dokumentliste og flere ulike dokument, men skal ikke være lik på tvers av pasient eller besøk). Purpose_of_use_details utvider beskrivelse av formål med f.eks navn på tilgangsbeslutning i sykehus EPJ eller kodet verdi på tildelt tjeneste i journalsystem for pleie og omsorgstjeneste i kommune. Her kan verdien i attributtet være lik på tvers av pasient og tid.

[mortsten]

Når det gjelder decision_ref descripion, så er den fra DIPS sammensatt av følgende: Begrunnelse for innsyn (e.g. "Inneliggende pasient på, avdeling, post, seksjon, lokalisering, inntid , uttid .")

@eirikbroen : Var det denne du etterspurte eller ID?

[eirikbroen]

Ser jeg var litt vel upresis over. Tenkte i utgangspunktet på _decisionref id, men for den verdien antar jeg at vi kan slippe unna med et enkelt regulært uttrykk for validering. _decisionref description er jo en litt hardere nøtt å knekke. Gitt det du skriver over @mortsten så blir det vanskelig å se for seg at enkel validering av syntaks kan fungere. Antar at det finnes endel varianter av den første biten ("Inneliggende pasient på") av begrunnelsen og kanskje litt ulike kombinasjoner av de andre elementene også. Gjør det jo litt vanskelig å se for seg at vi kan bruke et kodeverk all den tid data her vil endre seg med pasient, tid, behandling osv