Hva er SFM-id og hvorfor har vi bruk for det?
SFM har sitt utspring i e-resept og erfaringer gjennom mange år med endringer i sektor. Endringene spenner fra eierforhold på fastlegekontor til sammenslåing og splitting av kommuner.
I e-resept er avsender av resept en kommunikasjonspart. Det er et begrep som benyttes i tjenestebasert adressering, men ikke begrenset til dette. Helt spesifikt er de fleste fastlegekontorene i Norge representer ved sin “toppnivå” HER-id i Adresseregisteret. Fastlegene har også gjerne sin egen oppføring, men den benyttes ikke i e-resept. Det er ikke krav til en tjeneste i adresseregisteret for registrering i e-resept.
En resept, eller mer generelt en legemiddelbehandling, kommer fra en virksomhet som har journalplikt i henhold til pasientjournalloven, pasientjournalforskriften og helsepersonelloven. Juridisk er ansvaret plassert, men det er dynamikken som krever en mer generell tilnærming:
Når et fastlegekontor får endring i eierstrukturen er det likevel behov for kontinuitet i pasientens journalsystemer. I sin ytterste konsekvens kan et fastlegekontor over en periode bytte ut alle leger, eiere, oppføring i Enhetsregisteret, endre navn, flytte - men allikevel ha de pasientene, som ser sine (nye) fastleger. Det er her SFM-id kommer inn som en fast (persistent) identifikator på journalsystemet.
SFM-id er for (single-tentant) HelseID klienter registrert i konfigurasjonen, og kan endres. Det er en viktig egenskap, men må benyttes forsiktig.
Dersom et legekontor bytter juridisk eier, kan ny HelseID klient opprettes og SFM-id kan settes manuelt tilsvarende som for gammel organisasjon. Det er også andre grep som er nødvendig i en slik overgang, f.eks at det er registrert ny superbruker for ny organisasjon i SFM dersom nødvendig og at ny organisasjon er skrevet til SFM. Det siste er også noe som Norsk helsenett kundeservice kan bistå med å få på plass.
SFM-id er “identifikator” til en journal-instans
SFM peker altså til korrekt instans av SFM før det gjøres tilgangskontroll basert på annen informasjon i HelseID tilgangsbillett.
Merk:
Flere HelseID klienter kan peke med hver sin SFM-id inn til samme journalinstans
En organisasjon/virksomhet kan ha flere HelseID klienter med forskjellige SFM-id dersom det er behov for separate journaler.
Relasjon til HelseID
I tidlig fase av HelseID var konseptet at en helseID klient representerer en installasjon av et system i en organisasjon. Altså:
To forskjellige journalsystemer: hver sin HelseID klientTo organisasjoner med hver sin journal benytter samme leverandør: hver sin HelseID klient.
Innledningsvis ble det diskutert om HelseID sin KlientID kunne representere en slik “journalID”, men siden HelseID ikke ønsket å garantere at den ikke kunne endre seg over tid besluttet SFM prosjektet i samarbeid med HelseID å introdusere en “journal-id”. Fra SFM prosjektets side ble det argumentert for å etabler en generisk ID og ikke knytte den mot SFM, men det er historie.
Dette skjer ved at HelseID selvbetjening genererer (et forslag til) SFM-id når det opprettes ny HelseID klient for et klientsystem (EPJ) som benytter SFM. SFM-id utleveres automatisk med token når EPJ systemet utfører en token-request / innlogging.
Helseplattformen benytter en alternativ HelseID struktur: Multi tenant klient. Denne kan representere mange toppnivå organisasjoner basert på delegering i Altinn. Dette passet hånd i hanske med SFM, fordi Helseplattformen kun har en instans av SFM for alle sine medlemmer.
Når samme klientform (multi tenant) nå tilbys til EPJ leverandører, blir det ikke lenger mulig å benytte SFM-id på “toppnivå” for å nå de forskjellige instansene til leverandørens kunder. Det er rett og slett nødvendig å etablere en “journal-id” som EPJ leverandør benytter mot SFM for å nå korrekt instans. Dersom det ikke var dynamikk i sektoren, og dersom det ikke var behov for at en organisasjon benyttet systemer fra flere leverandører, ville SFM kunne benyttet organisasjonsnummer/legal entity for å gi tilgang til korrekt instans, men slik fungerer ikke sektoren.
Multi tenancy løsning
Når nyheten om at HelseID skulle tilby EPJ leverandørene en multi tenancy “single client” løsning, ble det satt ned en arbeidsgruppe for å foreslå en løsning. SFM prosjektet fikk føringer fra HelseID om bruk av “Extended context” i HelseID for dette, men det er en løsning som ikke er satt i produksjon.
Forslaget omfatter at SFM skal gjenkjenne et Multi-tenant HelseID token og se etter SFM-id i et SFM spesifikt context claim. Det vil altså være to nivåer av SFM-id i slikt token, men det er uproblematisk for SFM å skille disse varientene.
Det er mulig å oppnå denne konteksten på annen måte, men det vil i så fall minske verdien av informasjonen i token, og innføre parametre (usignert) i REST kall som i dag er parameterløse. Med andre ord: en stor fordel om HelseID token fremover kan være bærer av journal-id.
Veien videre
SFM prosjektet har nå ballen, som omfatter å beskrive hva SFM-id er og hvorfor vi trenger den.
Videre er vi utfordret på å se på sammenhengen mellom SFM datamodell for organisasjoner og tillitsrammeverket.
Vi jobber med saken.