SFM Instanser, Organisasjoner, SFM-id og HelseID

UNDER ARBEID

Fra SFM versjon 3.0 er datamodell og tilgangskontroll i BasisAPI og Fullversjon samordnet. Ikke identisk, men hovedtrekkene er det samme.

SFM reflekterer den store diversiteten i helsesektoren, fra små enkeltmanssforetak til store kommuner eller Helseforetak.

Sentralt i SFM er at det skilles mellom opplysninger som tilhører forskjellige journalsystemer. SFM har begrepet “instans” som samsvarer med et journalsystem. Eksempler er alt fra journalsystem for en eller flere fastleger til større kommunale samarbeid eller Helseplattformen i Midtnorge.

Oversikt

Når du som leverandør skal i gang med din kunde må du ha følgende på plass:

• HelseID:

  • Etablert ditt system som Klientsystem i HelseID selvbetjening, med SFM som API

  • klient for din kunde, med eller uten støtte for underenheter

  • Om du leverer multi-tenant løsning/sky vil det komme støtte for dette gjennom HelseID

• Adresseregister:

  • Oppføring for kunden, med en eller flere HER-id som skal benyttes (toppnivå eller tjenester etter nærmere regler

• Registrert kunden som “aktør” i Reseptformidler

Avhengig av hvor komplekse kundene er, vil deler eller hele denne siden være relevant.

Den forenklede versjonen er at EPJ må ha støtte for å registrere følgende i SFM

• Organisasjon(er)

• Superbruker

• Helsepersoner

• Pasienter

Organisasjonen registreres i SFM relevante identifikaktorer: Organisasjonsnummer, HER-id, samt SFM-id som identifiserer kundens journal og samsvarer med oppsett i HelseID.

SFM vil dermed gjenkjenne helseID token med organisasjonsnummer og SFM-id, og kunne etablere en sesjon eller kontekst for bruker og pasient.

Etablere SFM instans

SFM er en “bootstrap” løsning, som betyr at så snart man har en helseID-klient beregnet for SFM (aud=sfm) og ønsker å ta løsningen i bruk i en virksomhet, eller gruppe virksomheter, så kan man opprette den første virksomheten. Det er to tillatte operasjoner som kan gjøres mot SFM av ukjent aktør (SFM-id i token er ikke kjent tidligere):

• Hente “capabilityStatement” fra FHIR api

• Opprette (create) organisasjon i FHIR api

Når virksomhet opprettes er dette basert på informasjon i sfm-Organization objektet som sendes, samt informasjon i helseID access token. Det er krav til at det er innlogget bruker representert i token. Organisasjonen som opprettes har typisk active=false.

Følgende skjer i SFM når dette gjøres:

Nytt databaseskjema opprettes i database, og tilgangskontroll for denne opprettes og knyttes til SFM-id i token. Toppnivå organisasjonsoversikt oppdateres.

• Organisasjonen opprettes i databasen basert på informasjon i sfm-Organization. Identifier (ENH) skal korrespondere med informasjon i token.

• Superbruker (Person) opprettes basert på personnummer i token, tomme felt for navn osv.

• Forøvrig er installasjonen nå tom

HelseID token med samme SFM-id gir nå tilgang til denne installasjonen etter gjeldende tilgangskontroll, foreløpig bare for den opprettede superbrukeren.

MERK at det nå kan opprettes nye organisasjoner i SFM instansen. Det kan være underenheter til opprettet hovedenhet, hovedenhet til opprettet underenhet, samarbeidende hovedenhet med egen helseID klient (og tilhørende SFM-id, osv.)

Import av data

For en typisk legekontorinstallasjon setter superbruker nå i gang en eksport fra gammelt system og påfølgende import av data til SFM. Det er eget “scope” i helseID til bruk for dette på grunn da det er en tidkrevende operasjon, og det er spesialbehandling i SFM for prosessering utover levetid av token.
Importen kan inneholde, organisasjonsinformasjon, helsepersonell, pasienter og pasientopplysninger (legemiddeldata). Se eget kapittel: Migrering av data til SFM - SFM Informasjon - Confluence (atlassian.net)

Organisasjoner

I sin enkleste form inneholder en SFM instans en enkelt organisasjon, en superbruker (Person), en eller flere helsepersoner og pasienter.

I dette tilfellet er det kun nødvendig med ett organisasjonselement, som nå allerede er opprettet. Organisasjonen må ha navn, adresse, telefon, Identifier for organisasjonsnummer og Identifier for HER-id fra Adresseregister.

I tillegg er det krav til systemopplysninger som benyttes videre mot e-resept. (For detajler se sfm-Organizaton i simplifier: R4 Medication | sfm-Organization - SIMPLIFIER.NET)

I mange tilfeller vil organisasjonen være predefinert i Kjernejournal, mens innmelding til Reseptformidleren må bestilles gjennom NHN kundeservice om det ikke allerede er etablert.

Når organisasjon med HER-id settes aktiv meldes det inn til Reseptformider at denne benytter SFM.

Enkel organisasjon, f.eks. fastlegekontor

FHIR representasjon av en enkelt organisasjon

En mer kompleks enhet, for eksempel en kommune vil være rigget med mange underenheter, kanskje også flere nivå, ved at tjenestene fra Adressregister ligger som organisasjonselementer. Dette kan gjøres på flere måter:

Skisse som inkluderer journalsamarbeid mellom to kommuner, en stor og en liten.

Skisse som viser en kommune som benytter to systemer mot SFM. Merk at det under gitte forutsetninger kan settes opp deling av data mellom disse.

Juridisk enhet / Juridiske enheter og underliggende virksomheter

Norsk Helsenett SF har ikke hjemmel til å lagre eller behandle pasientopplysninger i SFM. Det er SFM sine “brukere” som eier data, og tegner nødvendig databehandleravtale med Norsk Helsenett SF.

SFM forholder seg til informasjon som kommer i HelseID access token. Det er to sentrale elementer/claims her:

Fra Test, Østmarka legekontor:

I dette tilfellet er det virksomheten 999944582 som skal benytte SFM til å yte helsehjelp, og hovedenhet er 100100126 - disse representer en organisasjon registrert i enhetsregisteret.

Den sentrale organisasjonen for videre kommunikasjon mot Reseptformidler og Kjernejournal er her orgnr_child. Denne må være registrert i SFM som en FHIR Organization (sfm-Organization).

SFM er fleksibel i organisering. Flere hovedenheter/juridiske enheter kan dele en instans i SFM. Samtidig er det viktig å forstå at en juridisk enhet kan ha flere journalsystmer som IKKE deler data og derfor skal ha separate instanser av SFM. Det er altså mange-til-mange relasjon.
SFM-id er sentral i dette, og kommuniseres i token. SFM-Id representerer på mange måter en konkret journal. Mer presist kan de være flere SFM-id (les HelseID klientkonfigurasjoner) som peker inn i samme journal ( *..1 relasjon)

Dette åpner både for samarbeid mellom flere juridiske enheter, og for bruk av flere journalsystemer mot samme legemiddeljournal.

De facto prinsipper for fastlegene

Fastlegeordningen er basert på at det som hovedregel er den enkelte fastlege som yter helsehjelp via sitt enkeltpersonsforetak.

Flere fastleger samarbeider typisk om felles journal via det som juridisk heter §9 samarbeid, med referanse til pasientjournalloven.

En vanlig forekomst er at en liten gruppe (fast-)leger, med hver sitt ENK (Enkeltpersonforetak) har journalsamarbeid for å ivareta journalplikten i sine respektive virksomheter. Det disse ENK selskapene som formelt representer dataansvar.

I tillegg har disse legene, eller noen av dem, og kanskje i tillegg et Ansvarlig selskap (ANS) eller (DA) med næringskode Allmenn legetjeneneste. Dette er gjerne registrert i Adresseregisteret (AR) med nødvendige opplysninger for meldingsutveksling og kommunikasjon med e-resept. I adresseregisteret er det også typisk registrert fastleger under kontoret som “kommunikasjonsparter”. Det er gjerne denne registreringen som i praksis oppfattes som det “juridisk” ansvarlige selskapet, og dermed i tillegg figurerer i Reseptformidler, Kjernejournal og kontaktpunkt for pasientene.

I noen tilfeller har også legene et Aksjeselskap (AS) som ivaretar felles forpliktelser, eiendom, fellesfunksjoner og ansettelser gjennom en tradisjonell virksomhet (underenhet)

Det har også vist seg at noen legekontor (samarbeidende enkeltpersonforetak) er registrert i enhetsregisteret som Kontorfellesskap. Dette er ikke juridisk enhet, og kan ikke opprettes som enhet i HelseID. Løsningen er å endre selskapsform (anbefalt), eller representere ett eller flere av enkeltpersonforetakene i SFM, med tilhørende HelseID klient.

De facto prinsipper for kommuner

Kommuner er vanligvis satt opp med en organisasjonsstruktur i Enhetsregisteret med en helseetat som organisasjonsledd. Noen kommuner har i tillegg bydeler (Oslo). Kommunen har pålagte tjenester som utføres i virksomheter utenfor kommunen, som fengselshelsetjeneste og skolehelsetjeneste.

Når virksomhetene er plassert under Helseetaten er det ofte denne som opptrer som juridisk enhet/avtalepart, for eksempel i virksomhetssertifikater eller HelseID og i avtaler med Norsk Helsenett om databehandleravtaler. For helseID spesielt vil disse kunne opptre i Selvbetjening og i Token som øverste nivå.

Adresseregister

Adresseregisteret i Norsk Helsenett inneholder oppføringer av helsevirksomheter, med underlagte kommunikasjonsparter. For kommuner vil ofte Helseetaten (og ev bydeler) opptre her som kommunen, og med kommunens pålagte oppgaver som tjenester med hver sin HER-id. De mest relevante tjenestene for SFM er:

• Legetjeneste ved sykehjem mm

• Helsestasjons- og skolehelsetjeneste

• Legevakt

• Forskrivning

• Fengselshelsetjeneste

For kommunale fastlegekotntor er det praksis at disse er opprettet som egne oppføringer i Adresseregisteret. Dette skyldes antakelig at Adresseregisteret ikke har funksjonalitet for å representere organisasjonsstruktur.

Merk at standard for tjenestebasert adressering ikke er gjeldende for registrering i e-resept, men at det vanligvis de definerte tjenestetypene med fordel kan benyttes også her.

Fastlegekontor - enkelt og vanskelig

Som nevnt over er det juridiske relativt komplekst, men det er etablert praksis for at det er “legekontoret” som opptrer som behandlingssted og dermed som “eier” av pasientjournal. Mange fastlegekontor er stabile over tid og har fastleger for alle fastlegelister som er knyttet til kontoret. Det finnes også en god del lister hvor det ikke er en fast lege, men hvor fastlegene på kontoret deler på en eller flere “ledige” lister. Det er også eksempler på leger som betjener flere fastlegekontor, med lister på begge steder.

Det sentrale her er at felles journal ofte følger det diffuse begrepet “legesenter” fordi nettopp pasientgruppen er stabil over tid.

SFM er laget for å tåle “alle” tilfeller av endringer hvor pasienten opplever å “tilhøre” et legesenter:

• Fastlege slutter, pasienten får ny fastlege på samme legesenter

• Fastlege sluttter og etterlater seg liste uten fast lege

• To fastlegekontor slås sammen til ett

• Eierskap til legesenter endrer seg (og kanskje også juridisk enhet)

• Legekontor endrer navn

• Legekontor bytter journalsystem

• Eksremversjonen: Alt dette skjer samtidig: To leger som utgjør et fastlegekontor slutter og “selger” sine praksiser til to nye, som bytter journalsysten, døper om legekontoret og oppretter nytt selskap.

I alle disse tilfellene er SFM i stand til å videreføre legemiddelopplysningene via SFM-id, som alltid vil peke inn i SFM på rett “journalsystem”. Om ting gjøres i riktig rekkefølge vil dette fungere out-of-the-box. Uansett vil vi gjennom kundeservice kunne bistå i få det på plass.

Kommune eksempel

En kommune som skal ta i bruk et EPJ system med SFM fullversjon for flere av sine virksomheter vil typisk rigge for en enkelt instans - som korresponderer med et enkelt journalsystem for alle virksomhetene.

Typisk vil organisasjonsleddet “Helseetaten” opprette HelseID-klient i HelseID Selvbetjening.

Skal kommunen / helseetaten ta i bruk flere journalsystemer vil det benyttes en HelseID klient for hver av disse. Det samme gjelder dersom det er ønskelig å opprette flere isolerte journalsystem som ikke deler data på tvers av virksomheter, f.eks samme EPJ-systemtype på Legevakt og Helsestasjon, men ikke delte data.

En kommune som skal benytte et pasientjournalsystem med SFM må gå gjennom organisasjonsstruktur, både kommunens eget organisasjonskart, oppføringer i adresseregisteret (AR) og Enhetsregisteret (brreg.no / Enhetsregisteret). En praktisk tilnærming dersom det er ønskelig med gruppering er spørsmålet? “Hva skal fremstå som avsender på resept?”. Det er i alle fall ikke Kommunen eller helseetaten.
Med utgangspunkt i tjenestene definert i AR kan det vurderes å gruppere for eksempel sykehjem med fellestjeneste under “Legetjeneste ved sykehjem” og definere denne som en “aktør” i e-resept for en logisk gruppe virksomheter.

Dette kan gjøres på to måter i SFM:

1: Virksomhetene opprettes uten HER-id og ev felles opplysninger, og plasseres i hierarki under tjenesten som opptrer som organisasjonselement

2: Virksomhetene opprettes med all nødvendig informasjon i SFM, inklusive navn, adresse, telefon, virksomhetsnummer og HER-id (for e-resept)

Merk at toppnivået vanligvis ikke vil ha noen relevans i SFM. Her vil typisk orgnr_parent i HelseID peke til Helseetaten, mens orgnr_child vil velge hvilken virksomhet som opptrer mot Reseptformidler og Kjernejournal.
Dette løses normalt med en felles helseID klient for alle kommunens virksomheter i samme installasjon. Denne vil ha en SFM-id som benyttes for tilgang til korrekt instans av SFM.

Privat sykehus med mange virksomheter

Tilsvarende vil privat sykehus med mange avdelinger være organisert med ett toppnivå og flere virksomheter, vanligvis med geografisk tilhørighet. Foretrukket løsning er at disse registreres i adresseregister med tjenesten “Forskrivning” for hver enkel virksomhet, men dersom det er felles tjeneste for alle henvendelser og forespørsler på resept kan det gjøres mer samlet.

Det anbefales også her felles HelseID klient for å minimere risiko for feilkonfigurasjon. Dersom det er valgt en HelseID klient for hver virksomhet kan det også fungere, men for å få delt journal i SFM må det konfigureres i rett rekkefølge. (Token med kjent SFM-id må benyttes for opprettelse av virksomhet registrert med ny SFM-id)