norskhelsenett / tillitsrammeverk

Repo for spesifikasjoner og annet relevant arbeid med Tillitsrammeverket

Tillitsrammeverk

Pasientens journaldokumenter (PJD) med relevante spesifikasjoner er nå i utprøving. Spesifikasjonene for PJD understøtter krav i tillitsrammeverket for PJD og er klare til å prøves ut.

NHN vil i samarbeid med helsevirksomhetene og EPJ leverandørene som deltar i utprøvingen forbedre og oppdatere spesifikasjonene underveis i utprøvingsperioden basert på erfaringer.

Samarbeid om spesifikasjoner

Vi har valgt å bruke versjonskontrollverktøyet Github til å skrive dokumentasjon og spesifikasjoner av flere årsaker:

• Det lar oss håndtere versjoner på en god måte
• Det gir oss god kontroll over endringer og historikk
• Det gjør samarbeid på tvers enklere

Spesifikasjoner

• Informasjonsmodell og datamodell for attestering av helsepersonells grunnlag for tilgang til helseopplysninger.
• Krav og forretningsregler for bruk av informasjonsmodell for attestering av helsepersonellets grunnlag for tilgang til helseopplysninger

Prosess

Utviklingen av spesifikasjonene vil foregå over flere iterasjoner, hvor hver iterasjon fører til en ny versjon av spesifikasjonen. NHN skal sørge for framdrift og vil fungere som reviewer av pull-requests, sørger for framdrift i viktige diskusjoner og vil håndtere eventuelle tilbakemeldinger via issues.

Hvis det ikke oppstår nye diskusjoner eller issues som peker på feil, eller dersom endringene kun består av språklige endringer skal det gjennomføres en avstemning om hvorvidt spesifikasjonen skal publiseres som versjon 1.0.

"Feature team" for utvikling av spesifikasjoner

Alle som har interesse oppfordres til å gi innspill og bidrag til spesifikasjonene som utvikles i forbindelse med etablering av tillitsrammeverket. For å sørge for framdrift i utviklingen av spesifikasjoner opprettes det en arbeidsgruppe som består av fageksperter fra sektoren, NHN og direktoratet.
Arbeidsgruppa sin oppgave er å sørge for framdrift i utviklingen av spesifikasjoner knyttet til tilgangsstyring og sporbarhet som skal benyttes av tjenesteleverandører og programvareleverandører ved deling av helseopplysninger mellom helsepersonell på tvers av virksomheter i sektoren.

Arbeidsgruppa treffes regelmessig, og har det redaksjonelle ansvaret for spesifikasjonene. Arbeidsgruppa må også sørge for å få nødvendige tilbakemeldinger fra involverte parter, slik at spesifikasjonene reflekterer det reelle behovet.

Diskusjoner

Spesifikasjonene vil bli basert på diskusjoner og innspill gjort i Github. Diskusjoner og innspill i andre kanaler vil ikke bli behandlet. Derfor er det viktig at diskusjoner som foregår utenfor dette repositoriet blir dokumentert skriftlig, enten som diskusjon, eller som issues eller pull-requests.

Issues

Når du oppdager feil eller mangler i spesifikasjonen må du opprette en issue i Github. Dersom det er behov for å diskutere eller på annen måte behandle en registrert issue skal dette gjøres skriftlig ved å legge inn kommentarer. Dersom en issue fører til en endring i spesifikasjonen skal denne endringen gjøres via en pull-request, eller som en merge mot den branchen man jobber mot.

Pull-request

Dersom du ønsker å gjøre endringer direkte i spesifikasjonen skal du benytte pull-requests i Github. Hvis en pull-request er knyttet til en issue ønsker vi at du lenker pull-requesten til issuet.

Norsk Helsenett vil fungere som reviewer av pull-requests, og vil gjøre en kvalitetskontroll og håndtere eventuelle diskusjoner knyttet til innsjekkingen.

Behov for møter og avklaringer

Vi anser det som sannsynlig at det vil bli behov for å gjennomføre møter, men legger ikke opp til en fast møteserie med mindre det viser seg å bli et behov. Dersom det viser seg at bidragsyterne til spesifikasjonene har behov for å gjennomføre møter vil disse møtene fasiliteres av NHN og avtales fortløpende.

Versjonering

Spesifikasjonen vil versjoneres etter hver iterasjon, hvor versjonen indikeres av et suffix, f.eks. "-1", "-2", osv.

Når spesifikasjonen ansees som ferdig skal den publiseres som versjon 1.0.

Innføring til bruk av Github

Hvordan bruke Github

Github har god dokumentasjon som beskriver arbeidsflyten. Les brukerveiledningen på Github for å få en forståelse for de grunnleggende prinsippene.

Skriv dokumenter i Markdown (.md filer)

Markdown er et språk som kan brukes for å generere html. Det er enkelt i bruk, og krever ingen spesiell programvare.

Innføring til markdown på Github

Verktøy for Markdown (.md filer)

Vi anbefaler to verktøy for å skrive .md filer:

• Github: Github har innebygget teksteditor for Markdown. Dette er den enkleste måten å gjøre endringer, og krever ingen installert programvare på din maskin.
• Visual Studio Code: Er et utviklingsverktøy for å skrive programmeringskode. Ved å bruke extensions kan blant annet få forhåndsvisning av dokumentet du skriver.

Det finnes mange andre teksteditorer som man også tilbyr forhåndsvisning av HTML koden som blir generert. Ta en titt på nettet for å se om du finner noen som passer for deg.

Diskuter med andre som bidrar

Vi har valgt å bruke diskusjoner på Github for dialog mellom de som bidrar. På den måten er alle diskusjoner synlige for de som deltar, samtidig som vi ivaretar historikken på en god måte.

Diagram i markdown

Github har støtte for å lage diagram i markdown dokumenter ved bruk av Mermaid. Se her for en introduksjon.

tillitsrammeverk's Issues

Informasjon om autorisasjoner og lisenser tas ut av spesifikasjonen

• Gruppa er enig om at HPR-nr bør være med hvis det finnes (HelseID bør berike hvis tilgjengelig)
• Enkelte helsepersonell har ikke autorisasjon

Autorisasjoner og Lisenser fra HPR er tilgjengelige i både HPR og i HelseID sitt userinfo endepunkt i dag - ved behov kan datakilden/dokumentkilden gjøre oppslag mot disse tjenestene. Informasjonen trenger ikke å være med i access token..

Angi formålet med attributtet

I spesifikasjonen i dag kommer det ikke klart fram hva attributtet skal benyttes til.

Jeg foreslår at vi legger til en kolonne i tabellen som viser oversikten over attributtene, hvor vi indikerer:

• tilgangsstyring
• loggkontroll og sporbarhet
• pasientens rettigheter

Beskriv hvordan vi bruker branching for publisering og versjonering av spesifikasjonene

Det står ikke beskrevet hvordan vi har tenkt å versjonere spesifikasjonene.
Vi bør legge til litt tekst i README om hvordan dette er tenkt gjort.. Sikkert lurt å skrive noe om dette i discussions også.

3.2.5.2 Helsepersonellets strukturelle rolle

Synes det mangler en klar referanse til entitetene i informasjonsmodell. Gjelder egentlig flere av avsnittene 3.2.5.x.

Bør "purpose_of_use_details" være et offisielt norsk kodeverk

Hei,
tar meg den frihet å melde inn et par ting om https://github.com/NorskHelsenett/Tillitsrammeverk/blob/main/specs/informasjons_og_datamodell.md.

1: feilstavingen practictioner bør byttes ut, i eksempler og dataformater

2: under healthcare_service nevnes kodeverk som er utgått.
8627 Tjenestetyper innen spesialisthelsetjenesten - erstattet med 8655
Linkene til kodeverkene er feil.
(Generelt bør disse kodeverkene samsvare med dem som brukes av RESH, HPR og andre registre hos https://register-web.test.nhn.no/docs/api/ - RESH lister 8653, 8654, 8655 (og iblant 8652, 8663))

3: Bør ikke kodeverket for "purpose_of_use_details" være et offisielt norsk kodeverk og dermed ligge i Volven og ikke være DIPS-proprietært? Også logisk at kodeverket 9151 for kommunene ligger under healthcare service?

Bør care_relation:healthcare_service i informasjonsmodellen reflekteres på samme måte i SAML-sikkerhetsbeviset knyttet til IHE XDS?

I informasjonsmodellen er attributter som ikke egentlig er spesifikke for verken helsepersonellet eller pasienten når disse sees uavhengig av hverandre lagt under care_relation. I SAML-sikkerhetbeviset vi i dag mottar fra nasjonal XCA ligger dette attributtet under subject, som altså tilsier at helsehjelpstjenesten er koblet mot helsepersonellet og egentlig uavhengig av hvilken pasient det er snakk om. Det kan godt være riktig i mange tilfeller, men strengt tatt burde vel healthcareservice heller ligge utenfor subject ettersom det vi er på jakt etter her er hvilken helsehjelpstjeneste som ytes av helsepersonellet for den aktuelle pasienten som sikkerhetsbeviset og forespørselen gjelder. Et og samme helsepersonell kan godt primært yte en spesifikk helsehjelpstjeneste i de fleste tilfeller, men når de inngår i en behandling av pasienter er det behandlingen pasienten mottar fra virksomheten som er relevant for å kunne forstå hvorfor dette helsepersonellet har et tjenstlig behov for tilgang de aktuelle helseopplysningene når det gjelder denne spesifikke pasienten i akkurat dette tilfellet. Mitt forslag er derfor at healtchares_service legges utenfor subject direkte på rot-nivå i SAML-sikkerhetsebeviset.

Beskriv prosess og funksjonen for featureteamet i README dokumentet

Forslag til revidert personvernkapittel

4.2 Personvern

Datamodellen legger til rette for en utlevering av personopplysninger, herunder helseopplysninger, som en behandling av en særlig kategori av personopplysninger, gjennom å sammenstille opplysninger om helsepersonellet, pasientens identifikasjonsnummer, opplysninger om virksomheten der helsehjelpen utføres, formålet med tilgangen til helseopplysninger og relasjonen mellom helsepersonellet og pasienten, for å autentisere tilgang til gitte helseopplysninger.

4.2.1 Tap av personopplysninger

Ved å utnytte svakheter og sårbarheter i programvare kan kan en angriper observere personopplysninger som utleveres mellom tekniske tjenester som benyttes av virksomheter ved deling av helseopplysninger.
Tap av personopplysninger kan oppstå mellom flere parter i verdikjeden:

• mellom konsument og autorisasjonsserver/IdP
• mellom konsument og informasjonstjeneste
• mellom informasjonstjeneste og datagrensesnitt
  For å sikre mot potensielt tap av personopplysninger bør det vurderes å etablere tiltak for å ivareta konfidensialiteten.

4.2.2 Overvåkning av ansatte i andre virksomheter

Datamodellen innebærer en utlevering av opplysninger om helsepersonellets arbeidsforhold. Disse opplysningene utleveres til andre virksomheter enn den virksomheten helsepersonellet er ansatt hos eller yter helsehjelp på vegne av. Det legges derfor til rette for at opplysninger kan benyttes til å monitorere helsepersonell i andre virksomheter. Dataansvarlige må følgelig være bevisste begrensningene i formålet med behandlingen av personopplysninger og eventuelt vurdere risiko knyttet til behandling av personopplysninger utover dette formålet.

4.2.4 Vurdering av personvernkonsevenser

For å ivareta rettighetene og frihetene til pasienten og helsepersonellet som registrerte, bør dataansvarlig virksomhet vurdere hvorvidt behandlingen av personopplysninger medfører høy risiko for at de registrertes rettigheter og friheter ikke ivaretas.

4.2.3 Forutsetninger for behandling av personopplysninger med utgangspunkt i datamodellen

Med utgangspunkt i at datamodellen legger til rette for en utlevering av personopplysninger, herunder helseopplysninger, som en behandling av en særlig kategori av personopplysninger, vil det forutsettes at behandlingen skjer i tråd med prinsipper for behandling av personopplysninger. Personvernkonsekvensene ved tap av personopplysninger eller utilsiktet tilgang vil være store, og behandlingen vil følgelig måtte innebære et særlig fokus på misbruk gjennom behandling av opplysningene til andre formål og helsepersonellets dokumenterte tjenstlige behov for tilgang til gitte helseopplysninger

Utgåtte kodeverk

ref: @ArneHD

2: under healthcare_service nevnes kodeverk som er utgått.
8627 Tjenestetyper innen spesialisthelsetjenesten - erstattet med 8655
Linkene til kodeverkene er feil.
(Generelt bør disse kodeverkene samsvare med dem som brukes av RESH, HPR og andre registre hos https://register-web.test.nhn.no/docs/api/ - RESH lister 8653, 8654, 8655 (og iblant 8652, 8663))

Legg til noen konkrete anbefalinger til markdown editorer..

Redigere direkte i Gihub
Visual studio code - med extensions
Ghostwriter

Angående "Sikkerhetsutfordringer med logging: Log4J som eksempel"

Hei @steinarnoem!

Forbehold om at jeg forstår dette riktig. Dette er jo innsynslogging (auditlogging), mens Log4J brukes jo til systemlogging, altså en annen type logging.

Det jobbes med en nasjonal implementasjonsguide for FHIR AuditEvent som viser hvordan token-attributtene (claims) skal mappes fra token til AuditEvent, se https://github.com/HL7Norway/AuditEvent.

Denne bør selvsagt tilpasses nasjonal informasjonsmodell for tillitsrammeverket

Hilsen
Trond :-)

Angivelse av "authorization"

Er det konsumenten, via sin EPJ, som angir hvilken "authorization" konsumenten har i det øyeblikket forespørselen sendes? Eller skal konsumenten bare angi fødselsnummer, hvorpå HelseID vil berike token med både HPR nummer og autorisasjoner fra HPR registeret? Dersom det er det siste (HelseID beriker), hva vil da skje dersom konsumenten har flere autorisasjoner i HPR? Vil alle autorisasjonene inkluderes i aksess token?

Knytte informasjonsmodellen til konseptet attestering og attest av helsepersonellets grunnlag for tilgang

Konseptet rundt attestering og attest bør tydeliggjøres i spesifikasjonen. Jeg tror at formålet med informasjonsmodellen blir lettere å forstå når vi rammer det inn på en litt annen måte enn vi har gjort tidligere..

@richardhus , @eirikbroen og andre - noen innspill? Skal jeg forsøke meg på noen formuleringer?

Krav om at "User-Agent" i http header settes til en verdi som gir mening for native klienter ved kall til HelseID

Tilhørighet til behandlingssted og detaljert organisasjonstilhørighet for pasienten

Hvilke informasjonselementer beskriver pasientens organisasjonstilhørighet: Legal entity, point-of-care, department ... eller bare point-of-care og department. -- fordi spesifikasjon er inconsistent. I tillegg hvorfor?

"purpose_of_use"

I møtet 10.03.2023 ble vi enige om å beholde "purpose_of_use", men indikere at informasjonskilden både kan være KJ og konsument.

ref: https://github.com/NorskHelsenett/Tillitsrammeverk/blob/main/meeting_minutes/2023-03-10%20temam%C3%B8te.md

Legg til bidragsytere i spesifikasjonen

Kjerneteamet:
Richard Husevåg (HSØ)
Sverre Martin Jensen (Oslo Kommune)
Erik Vegler Broen (Oslo Kommune - Origo)

Andre bidragsytere:
Trond Elde (DIPS), Asefeh Johnsen, Eva Tone Fosse, Helge Bjertnæs

Legg til flere etterhvert som de kommer til

Beskrivelse av at (og hvordan) datamodellen kan serialiseres til forskjellige format

Datamodellen kan f.eks. representeres ved bruk av JSON, CBOR eller XML. Dette bør komme fram av spesifikasjonen.
Det bør presiseres at vi har brukt JSON i eksemplene i spesifikasjonen fordi JSON formatet er mer lesbart enn f.eks. XML.

Norm for informasjonssikkerhet

Bør ikke Norm for informasjonssikkerhet også refereres i tillegg lovverket?

Norm for informasjonssikkerhet er jo styrende for de som kobler seg til Norsk Helsenett.

Legg til tekst og oid for facility_type i JSON eksempel

Det mangler tekst og oid på flere eksempler i dag. Det bør legges til, slik at eksemplene reflekterer virkeligheten litt bedre.

Definer omfanget til versjon 1.0 av implementors-draft

Informasjon som er ønsket i SAML token men ikke er en del av helsepersonellets attest

Dere har nevnte 2 informasjonselementer som ikke er en del av attest fordi informasjon ikke er inkludert i grunnlaget for hvorfor helsepersonellet fikk tilgang til pasientens informasjon i sitt lokal EPJ:
1 - Helsepersonellets level of assurance som kommer via helsepersonellets brukerpålogging ved bruk av HelseID (ikke EPJ), og
2 - Teknisk tracing referanse som blir generert av EPJ men ikke en del av attest.

Vi må avklare hvilke spesifikasjon skal sikre disse info-elementer kommer frem til SAML-token.

Datamodell - Spørsmål om attributter

Har et par spørsmål til attributter i utkast til datamodell

structural_role Antar at de fleste EPJ systemer ikke har en mapping fra brukerrolle til de tre foreslåtte verdiene. Denne attributten er satt opp som obligatorisk. Er tanken her at denne verdien angir hvilken rolle personell har i i en gitt behandlingsrelasjon og som ikke kan utledes fra HPR informasjon eller mangel på denne?

functional_role Foreslått kodeverk her er satt til å være STYRK-08 og at informasjonskilde er EPJ/HR system. Antar at mange virksomheter har EPJ uten direkte integrasjon med HR system og dermed enten må lage en slik integrasjon eller gjøre en form for dobbeltføring. Burde vi foreslå en mulig mapping fra funksjonelle roller i EPJ. Typ - EPJ Rolle "Lege" i et system i primærhelsetjenesten = STYRK-08 2211 - Allmennpraktiserende Leger?

locality Bør ta en diskusjon på hva som er forventining knyttet til verdi på dette attributtet. Kan se for meg flere situasjoner hvor det for eksempel ikke er fornuftig å spesifisere avdeling - Eks. Overgrepsmottak. Hva er formålet med denne attributten? Er det hovedsaklig å gjøre det enklere for pasient å forstå innsynslogg?

purpose_of_use Dette attributtet diskuterte vi endel i pilot Oslo Kommune/HSØ, kom der frem til at det i legevaktsammenheng var lite verdifullt å avgi noen annen verdi enn "Behandling". Ser EHDSI spesifikasjon lister ganske få mulige verdier. Naturlig nivå å legge seg på? Dette er nok også en verdi som ikke finnes direkte i EPJ og som vi bør tilby eksempel på mapping av hvis den skal være obligatorisk.

Clinical speciality tas ut av spesifikasjonen

Ref: https://github.com/NorskHelsenett/Tillitsrammeverk/blob/main/meeting_minutes/2023-03-10%20temam%C3%B8te.md

Attributt for autentiseringsstyrke?

Ved gjennomgang og sammenstilling av attributter fra HelseID informasjonsmodell med SAML fra kjernejournal og Helse Sør-Øst sikkerhetsbevis virker det som om HelseID-informasjonsmodellen mangler attributtet som angir autentiseringsstyrken på sluttbrukerens autentisering. Innholdet reflekterer typisk EIDAS lav, betydelig eller høy, eventuelt hvilket av nivåene 1-4 i henhold til den særnorske kategoriseringen som er benyttet. I SAML fra kjernejournal finnes SecurityLevel for dette, som vi mapper til hso:subject:assurance-level i Helse Sør-Øst sikkerhetsbeviset. Denne finnes helt sikkert også i HelseID vil jeg tro, men den mangler i informasjonsmodellen/spesifikasjonen så vidt jeg kan se.

Spesifikasjonen bør reflektere at både HelseID og konsumenten kan være informasjonskilde for dataansvarlig og behandlingssted

Kilde for legal entity:

• for multi-tenancy og §9 samarbeid: EPJ (HelseID kontrollerer at det foreligger en delegering i Altinn)
• for on-premise (single-tenant): HelseID er kilde (utledes av metadata basert på klientid+klienthemmelighet)

Korriger behandlingssted og dataansvarlig

Feature-teamet har konkludert med at id og navn i attributtstruktur skal være: "legal_entity" og "point_of_care".

Behandlingssted ("point_of_care") skal være obligatorisk:

• attributtet skal være obligatorisk både i teknisk kontrakt og i vilkår
• dersom juridisk enhet og behandlingssted er likt skal juridisk enhet gjentas i feltet for behandlingssted

Tilgangskontroll gjelder også retten til å motsette seg tilgjengeliggjøring (sperring/reservasjon)

Mener det bør fram at tilgangskontroll ikke kun er knyttet til tjenstlig behov, men også kontroll av pasientens reservasjoner knyttet til utlevering av pasientopplysninger (sperring) som en del av å "støtte opp under innbyggers rettigheter".

Fjern attributtet som beskriver helsepersonellets strukturelle rolle fra spesifikasjonen

Ref beslutning i arbeidsmøte 02.03.2023 - https://github.com/NorskHelsenett/Tillitsrammeverk/blob/main/meeting_minutes/2023-03-02%20informasjonsmodell.md

Strukturell rolle fjernes fra spesifikasjonen.

Discussed in #9

^{Originally posted by eirikbroen February 16, 2023}
Antar at de fleste EPJ systemer ikke har en mapping fra brukerrolle til de tre foreslåtte verdiene. I og med at dette attributtet er satt opp som obligatorisk bør vi forsøke å gjøre innføring så enkel som mulig. Er tanken her at denne verdien angir hvilken rolle personell har i i en gitt behandlingsrelasjon og at verdi ikke kan utledes fra HPR informasjon eller mangel på denne?

Forbedre lesbarhet

Spesifikasjonen er strukturert på en litt rotete måte nå - se om det er mulig å forbedre strukturen..

Tydeliggjøre gyldige verdier for attributtet Purpose of Use

Gjøre det helt tydelig i dokumentasjonen at aktuelt verdisett er kun 3 verdier (fra det mer omfattende kodeverket https://terminology.hl7.org/ValueSet-v3-PurposeOfUse.htmlhttps://terminology.hl7.org/ValueSet-v3-PurposeOfUse.html): TREAT/treatment, ETREAT/Emergency Treatment og COC/coordination of care.

Helsepersonellets fødselsnummer og navn

Helsepersonellets fødselsnummer og navn må overføres til datakilden.
Fødselsenummer er pr i dag den eneste identifikator som unikt identifiserer helsepersonellet ettersom ikke alt helsepersonell har HPR-nummer.
Navn som gjaldt på tidspunktet hvor HP fikk innsyn må også med, ettersom det kan endres i etterkant.

Feilstaving av "practitioner"

ref: @ArneHD arnedh

1: feilstavingen practictioner bør byttes ut, i eksempler og dataformater

Ta "care_type" inn i spesifikasjonen

"care_type": er ikke påkrevd (f.eks. legevakt-case)
Peker på kodeverk fra IPLOS, men har overlapp med HSØ sin "purpose_local"

Retningslinjer for bruk av attributtet Purpose of Use

Lage tydelige retningslinjer for i hvilke scenarioer hver av disse er aktuelle å bruke, gjerne med et par-tre eksempler fra ulike helsetjenester.

HPR-nummer i spesifikasjonen

• Gruppa er enig om at HPR-nr bør være med hvis det finnes (HelseID bør berike hvis tilgjengelig)
• Enkelte helsepersonell har ikke autorisasjon

Dette bør beskrives i spesifikasjonen, og i vilkårstekst.

"facility_type" tas ut av spesifikasjonen

ref: https://github.com/NorskHelsenett/Tillitsrammeverk/blob/main/meeting_minutes/2023-03-10%20temam%C3%B8te.md

OID for norske organisasjonsnummer

OID for organisasjonsnummer er 2.16.578.1.12.4.1.4.101 - ref: https://www.ehelse.no/teknisk-dokumentasjon/oid-identifikatorserier-i-helse-og-omsorgstjenesten

Flytte noe av dagens innhold ned i dokumentet som vedlegg

Kapittel om EHDSi og HL7 standard kan inngå som vedlegg i bunn av dokumentet. Dette vil øke lesbarheten.

Behov for å kunne filtrere mellom systemutledet tilgang og egenerklærte tilgangsbehov som grunnlag for tilgang

Helseforetakene i Helse Sør-Øst har nå fått litt erfaring med å gjøre logganalyse basert på informasjon fra konsumenter som formidles til dem som kilder etter spesifikasjonen som Helse Sør-Øst startet med under utprøvingen. Blant de attributtene de så langt har funnet nyttige finner vi et boolsk flagg som indikerer om en tilgang er systemutledet basert på informasjon om helsepersonellet og pasienten som er registeret i PAS/EPJ (eventuelt i annet fagsystem) eller om tilgangen er basert på en egenerklæring av at helsepersonellet trenger tilgang til pasienten. Ønsker derfor å foreslå at denne typen informasjon innlemmes også i tillitsrammeverket.

Gi konkret beskrivelse av avvik fra EHDSI i spesifikasjon for informasjons- og datamodell

Bør navn formidles strukturert som fornavn og etternavn?

I Helse Sør-Øst ser vi at for fagsystemer som skal opprette brukere/personer basert på innhold mottatt i sikkerhetsbevis, så har vi behov for at navn formidles strukturert, altså at fornavn og etternavn formidles i hvert sitt informasjonselement, fremfor å være sammenslått til et informasjonselement slik både HelseID og SAML-sikkerhetsbevisene for helsenorge.no og kjernejournal har det i dag. I tillegg ser jeg når jeg sammenlikner med HL7 FHIR at man for personnavn i stor grad legger opp til å bruke datatypen HumanName (http://hl7.org/fhir/datatypes.html#HumanName), der det er støtte for elementene given (fornavn), family (etternavn) og text (fullt navn) pluss et par andre metadatainformasjonselementer som enn så lenge neppe er aktuelle. For logging til FHIR AuditEvent vil det også være en fordel om vi har en mest mulig kompatibel struktur på navn når dette formidles i sikkerhetsbevis.

Bruk standard struktur for attributter

Vi må bruke samme struktur for å beskrive forskjellige attributter.

Feature-teamet har landet på følgende strukturer:

"person (juridisk/fysisk)": {
	"id": "xxxxxxxx",
	"name": "navn på juridisk eller fysisk person",
	"system": "x.x.x.x.x.x", //oid for F-nr/D-nr/Org.nr
    "authority": "www.brreg.no" //eller www.skatteetaten.no
}

"verdi_fra_kodeverk":{    
	"code": "en_kode",
	"text": "en_beskrivende_tekst",
	"system": "oid kode for system", 
	"assigner": "den_ansvarlige_for_kodeverket"
}

"fritekst": {
    "type": "NUMERIC|ALPHANUMERIC|DECIMAL",
    "value": "en verdi" 
}

"hendelse_referanse":{
    "id": "xxxxxxxx",
	"verdi_fra_kodeverk": {
        "code": "XX",
        "text": "en_beskrivende_tekst",
        "system": "x.x.x.x.x.x",
        "assigner": "den_ansvarlige_for_kodeverket"
    },
	"person (juridisk/fysisk)": {
        "id": "xxxxxxxx",
        "name": "navn på juridisk eller fysisk person",
        "system": "x.x.x.x.x.x", //oid for F-nr/D-nr/Org.nr
        "authority": "www.brreg.no" //eller www.skatteetaten.no
    },
    "fritekst":{
        "type": "NUMERIC|ALPHANUMERIC|DECIMAL",
        "value": "en verdi" 
    }
}

Eks 1: Tilgangsbeslutning/hjemmelsgrunnlag
"hendelse_referanse":{
    "id": "xxxxxxxx",
	"verdi_fra_kodeverk": {
        "code": "XX",
        "text": "en_beskrivende_tekst",
        "system": "x.x.x.x.x.x",
        "assigner": "den_ansvarlige_for_kodeverket"
    },
   "fritekst":{
        "type": "NUMERIC|ALPHANUMERIC|DECIMAL",
        "value": "en verdi" 
    }
}

Eks 2: Tilgangsbeslutning/hjemmelsgrunnlag (ikke unntak)
"hendelse_referanse":{
    "id": "xxxxxxxx",
	"person (juridisk/fysisk)": {
        "id": "xxxxxxxx",
        "name": "navn på juridisk eller fysisk person",
        "system": "x.x.x.x.x.x", //oid for F-nr/D-nr/Org.nr
        "authority": "www.brreg.no" //eller www.skatteetaten.no
    },
    "fritekst":{
        "type": "NUMERIC|ALPHANUMERIC|DECIMAL",
        "value": "en verdi" 
    }
}

Informasjonsmodellen bør indikere hvilke attributter som er "landet" og hvilke som er "under behandling"

Dette bør indikeres i informasjonsmodell og i datamodell, slik at man kan se hva som er en del av den endelige spesifikasjonen.

Nytt kapittel med egen ordliste med begrepsdefinisjoner?

F.eks. beskrive hva som menes med begrepet sikkerhetsbillett. Ta med alternative navn f.eks. sikkerhetsbevis., og eksempler kan være SAML eller JWT. Referere til autoritative kilder f.eks. RFCer etc med offisielle definisjoner.

Strukturen i foreslått informasjonsmodell

Informasjonsmodellens care_relation-gruppering inneholder etter det jeg kan se nå enkelte attributter som egentlig er knyttet til helsepersonellet eller pasienten uavhengig av hverandre. Med det mener jeg for eksempel at legal_entity, point_of_care og department kan og bør legges både på helsepersonellet og på pasienten fremfor å ligge i care_relation som beskriver relasjonen mellom dem. Dette fordi helsepersonellet fint kan tilhøre et annet arbeidssted/behandlingssted enn pasienten i sin behandling av pasienten. Da er det ryddig og også mest intuitivt for leverandører å hente frem helsepersonellets tilhørighet og legge det i disse elementene under subject, mens de kan hente frem pasientens tilhørighet separat og legge det under patient. Har man det kun under care_relation, så får man ikke uttrykt både helsepersonellets og pasientens tilhørighet, man må velge en av disse og hvilken er det da riktigst å velge?

Anonymisering av helsepersonellets identitet i innsynslogg for innbygger

Enkelte helsepersonellkategorier påberoper seg anonymisering ved oppslag i en pasients opplysninger. Dette kan f.eks. gjelde AMK--operatører. Skal dette kobles opp mot tillitsrammeverket på en eller annen måte? Kan man f.eks. se for seg at dersom koden "ETREAT" benyttes for purpose_of_use, så skal helsepersonellets identitet anonymiseres i innsynsloggen til innbygger?

Behov for mer forklaring rundt purpose of use BTG.

Forbedring av kapitlene "Innledning" og "Bakgrunn for spesifikasjonen"

Jeg synes at kapitlene innledning og bakgrunn for spesifikasjonene for info- og datamodellen bør forbedres.

Teksten kan spisses litt mer - slik den står nå bærer den preg av å være lite gjennomarbeidet.

Forbedring av eksempler for department i detaljeringen av informasjonsmodellen

Eksempelet i informasjonsmodellen inneholder verdier som "resh:xxxxxx" i value-feltet og "resh:x.x.x.x.x" i system-feltet, mens det her er unødvendig og forvirrende å ha med prefixet "resh:" ettersom det skal være lov med andre typer enn bare RESH (og RESH har en egen OID som skal brukes i system, så der er det direkte feil med resh: som prefix). @steinarnoem: Kan du oppdatere eksempelet?