Behov for avklaringer rundt overføring av "patient_id"

[oekvennaas]

I https://github.com/NorskHelsenett/Tillitsrammeverk/blob/main/specs/informasjons_og_datamodell.md kap 4.2.4 angis det at "patient_id" er et påkrevd felt som skal avleveres av konsumentens EPJ. Dette forstås som at "patient_id" er endel av attesten som skal overføres. Spesifikasjonen er imidlertid utydelig på hvordan "patient_id" skal overføres, og det kan forstås som at "patient_id" skal overføres på samme måte som andre informasjonselementer under patient kategorien, hvilket er feil. Jeg foreslår derfor følgende:

1. Det må tydeliggjøres at tabell i kap 4.2.4 spesifiserer attesten og ikke hva som skal overføres til HelseID.
2. Man kan vurdere å inkludere en ekstra kolonne i tabellen som angir hvordan informasjonselementet skal overføres. For "patient_id" må det da spesifiseres at informasjonselementet skal avleveres av konsumentens EPJ som en parameter i body til HTTP request mot API ressursen. De andre elementene skal da overføres via et RO (Request Object) mot authorize endepunktet til HelseID.

I kap 4.5.1 er det angitt et eksempel på et "patient_id" attributt i json format. Eksempelet indikerer at attributtet legges inn i authorization_details og sendes i RO til HelseID. Det blir feil. Det samme gjelder JSON profilen for datamodellen i kap 7. Jeg foreslår at kap 4.5.1 slettes, samt at "patient_id" fjernes fra datamodellen i kap 7.

[steinarnoem]

Jeg mener at hvordan de enkelte attributtene overføres hører til løsningsbeskrivelse, og ikke i informasjonsmodell for attestering. For PJD er det SAML tokenet som utgjør den endelige attesten som mottas av dokumentkilden. Jeg tror det er klokt å skille løsningsbeskrivelse fra informasjonsmodell for attestering. Dette vil bidra til at konseptet er gjenbrukbart i andre sammenhenger enn Kjernejournal Portal. Slik jeg forstår det er foreslått løsning at identifikator for pasienten ikke overføres via HelseID, men til KJ. Og at det er KJ som sammenstiller attest for dokumentkildene i PJD. Dokumentkildene vil dermed ikke oppleve noen forskjell. Det er bare journalsystemene som implementerer attesteringen og NHN som vil måtte forholde seg til dette.

Vi har tidligere skissert en løsning hvor alle attributtene i en attestering av helsepersonellet hos konsumenten sendes samlet til HelseID hos NHN, for å dra nytte av eksisterende tillitsforhold og mekanismer som signerte forespørsler. Jeg mener at denne tilnærmingen konseptuelt sett både er enkel å forstå og å implementere. En alternativ løsning kunne ha vært at hele attesten blir signert av konsumenten, og overført direkte til API uten å gå via NHN. For PJD hadde dette vært KJ.

Jeg tror det er fornuftig å finne en felles tilnærming til hvordan en attest overføres fra konsument til tillitsanker, slik at det er gjenbrukbart og likt for alle konsumenter som skal implementere dette i sine system, også for andre tjenester hos NHN og direkte mellom virksomhetene i sektoren. Jeg tror at en oppsplitting av attributter i en attest forringer kvaliteten på løsningen, og vanner ut konseptet.

[mortsten]

4.2.4 Bør stå som den står, da den oppsummerer den helhetlige informasjonsmodellen. Løsning beskrives i eget avsnitt.

Slik jeg oppfatter er det 2 hovedrisikoområder som gjør at vi ikke lander dette. Dersom det er andre årsaker, bør sektoren gjøres kjent med det.

• AccessToken på avveie med helseopplysninger -> Helseopplysninger på avveie. Foreslått tiltak er å fjerne pasientidentifikator
• Misbruk av AccessToken utstedt for en pasient bruker for tilgang til andre pasienter. -> Tiltaket har vært å inkludere pasientidentifikator i accesstoken slik at pasientid i forespørsel kan valideres mot pasientID i access token.

Mener det er viktig å avklare hvordan løsningsmønsteret tidlig, for å forberede aktørene på å måtte håndtere ulike løsningsmønstre. Som @steinarnoem skriver er det et ønske i sektorene at tillitankeret også skal dekke både nasjonale og regionale tjenester. Felles tilnærming er nødvendig, slik at vi slipper nye runder med endringer hos aktørene på dette området.

[richardhus]

Støtter @steinarnoem og @mortsten, og skulle gjerne sett at vi fikk tatt en systematisk og skriftlig gjennomgang av alternativene med fordeler, ulemper, risikoer/trusler og muligheter (SWOT-analyse), ettersom det bør tas beslutning basert på en helhetlig vurdering her. Min magefølelse er at ulempene med å basere seg på at pasientidentifikatoren ikke kan bæres av et access token er betydelige for helsesektoren og sektorens leverandører, og det er ikke nødvendigvis i tråd med EU som vel baserer mye på XUA og SAML med pasientidentifikator. Jeg kan heller ikke helt forstå at vi ikke kan gjøre tilstrekkelige tekniske tiltak for å sikre at sensitive personopplysninger kan bæres av et access token all den tid de uansett skal inngå i forespørsler der summen av access token (i http header) og payload (i http body) likevel vil avdekke de samme like sensitive personopplysningene? Det er jo det som skal formidles hele veien fra API-konsumenter til API-tilbydere, mens access tokenet kun er frittstående mellom API-konsumenten og token-utsteder i et bittelite vindu når man henter det ut for å legge det ved forespørselen, samt selvsagt internt i token-utstedelseskomponenten. Fordelene sett opp mot ulempene, risiko/trusler og muligheter vil hjelpe oss å komme til en felles konklusjon eller i alle fall en konklusjon som vi kan forstå bedre, så jeg mener det er verdt investeringen å gjøre dette skriftlig og systematisk.

[steinarnoem]

Vi har rendyrket konseptet attest i spesifikasjonen, slik at løsningene som skal implementere står friere til å implementere dette i sine løsninger. Løsningsmønster vil dokumenteres i de enkelte tjenestene.

[steinarnoem]

Konklusjon etter møte i feature-team.

Attributtet beholdes i informasjonsmodellen. Det vil være opp til løsningsdesign hvordan det overføres. Feature teamet ønsker at det skal være en generisk løsning.