2.1 Opprettelse, forvaltning og Migrering

SFM er en separat applikasjon som har sin egen funksjonalitet, datamodell og sentral database. For at virksomheten som starter å bruke SFM skal få fullverdig konvertering av data fra gammel EPJ-løsning eller FM til SFM kreves det en effektiv løsning hvor datakvalitet blir bevart.

Migrering er beskrevet her: Migrering av data til SFM

ID

Kravbeskrivelse

Støttes i

Endringshistorikk

Kravet gjelder

Godkjennes av

Kommentar

2.1.1

EPJ skal kunne opprette en ny virksomhet i SFM.

Alle

Oppdatert kommentar til krav May 27, 2024

Alle

NHN

Virksomhet opprettes ved bruk av ressursen sfm-Organization.

Brukeren som er oppgitt i Helse-id token registreres som admin bruker i SFM og benyttes i videre prosess med å opprette andre brukere/migrere informasjon til SFM. 

https://e-resept.atlassian.net/wiki/spaces/SFMDOK/pages/2160493337

2.1.1.1

EPJ skal tilrettelegge funksjonalitet for opprettelse av ny virksomhet, slik at superbruker intuitivt forstår forskjellen på å opprette en ny virksomhet i ny SFM-instans vs det å opprette en ny virksomhet i en allerede etablert instans (der den nye virksomheten deler data med annen virksomhet). 

Alle

 

Nytt krav fra May 6, 2024

Alle

NHN

Før ny virksomhet opprettes skal det av sikkerhetsgrunner gjøres en GET på Organization:

Når hensikten er å opprette ny instans (nytt skjema) i SFM skal det sjekkes at token med "journal-id" og orgnr_parent/orgnr_child ikke returnerer http status 200 OK.

Når hensikten er å opprette ny virksomhet i eksisterende instans skal det sjekkes at åpent søk med eksistende "journal-id" gir http 200 OK 

Operasjon CreateOrganization benyttes videre i begge tilfelle. 

  1. Ny virksomhet opprettes i ny journalinstans dersom Journal-id er ukjent

  2. Ny virksomhet opprettes i eksisterende journalinstans dersom Journal-id finnes fra før (gitt token med org som allerede eksiserer i samme instans). 

2.1.1.2

EPJ skal vise fornuftig feilmelding når HelseID ikke kan utstede gyldig token.

TBD

Nytt krav fra May 6, 2024

Alle

NHN

Planlagt funksjonalitet, dato: TBD

HelseID sjekker at gyldig delegering foreligger og at nødvendige avtaler er på plass. 

HelseID vil returnere feilkoder dersom dette ikke er oppfylt: Se HelseID dokumentasjon for spesifikke feilkoder. 

Dette gjelder følgende: 

  • Delegering er ikke gyldig

  • Virksomhet er ikke Medlem i NHN

  • Virksomheten har ikke nødvendige godkjenninger på plass for å benytte SFM 

Driftsleverandøren er ansvarlig for å foreta tilsvarende manuelle sjekker av dette, før verifikasjon mot Medlemsregisteret er på plass. 

2.1.1.3

EPJ som benytter SFM skal presentere HelseID-token med identifikator til SFM instans.

Fra versjon 4

Nytt krav fra May 6, 2024

Alle

NHN

  • Multitenant klient: Journal-id (Fra SFM v4.0)

  • Single tenant klient: SFM-id

Begge disse tilsvarer SFM-id i sfm-organization profilen.

2.1.1.4

EPJ skal tilby sine virksomheter et valg ifht om driftsleverandør skal ha en superbruker i deres organisasjon eller ikke. 

Fra versjon 4

Nytt krav fra May 6, 2024

Alle

NHN

Det skal være støtte for at bruker i virksomheten kan logge inn og gjøre operasjonen for å opprette organisasjon på vegne av sin virksomhet, og at dette ikke MÅ gjøres av en ansatt hos driftsleverandør. 

2.1.1.5

EPJ skal ha funksjonalitet for å forvalte sine "tenants" og skal generere Journal-ID. 

Fra versjon 4

Nytt krav fra May 6, 2024

Multitenant

NHN

Eier av Multitenant HelseID-klienten (orgnr_supplier) er ansvarlig for å forvalte sine "tenants" og generere Journal-ID for aktuelle instanser i SFM. 

 Journal-ID skal alltid være en UUID. 

2.1.1.6

Eier av Multitenant HelseID-klienten må formidle korrekt Journal-id ved forespørsel om token for aktuell tenant. 

Fra versjon 4

Nytt krav fra May 6, 2024

Multitenant

NHN

Dokumentasjon hos HelseID:
sfm-id_for_multi_tenant-klienter_no_nb.md - NHN Utviklerportal

2.1.1.7

EPJ/driftsleverandør skal enkelt tilgjengeliggjøre informasjon om relasjon mellom virksomheter/kunder,  og SFM journalinstanser - som grunnlag for å yte god support/feilsøking. 

Fra versjon 4

Nytt krav fra May 6, 2024

Multitenant

NHN

Liste over kunder (inkl Navn, Organisasjonsnummer og Journal-id) skal kunne produseres fra EPJ/driftsleverandør.

Gjelder også historikk. 

 

2.1.1.8

System skal støtte manuell endring av Journal-id.

Historikk skal ivaretas. 

Fra versjon 4

Nytt krav fra May 6, 2024

Multitenant

NHN

a) System som støtter multi tenant HelseID skal støtte å ta i bruk "journal-id" for kunde som tidligere har single tenant klient, ved å gjenbruke eksisterende SFM-id.

b) System som støtter single tenant skal støtte å konfigurere single tenant klient med SFM-id lik "journal-id" fra multi tenant system.  

 

2.1.2

EPJ skal benytte SFM sitt oppgitte migreringsformat for overføring av relevante journalopplysninger

Alle

 

Alle med funksjon

EPJ

Det benyttes eget migreringstoken som alle leverandører må støtte. For leverandører som benytter FM så løses selve migreringen av FM, men migreringstoken må gjøres tilgjengelig av EPJ.

2.1.3

EPJ skal sikre at virksomheter som tar i bruk SFM overholder dokumentasjonskrav.

Alle

 

Alle

EPJ

Historikk må enten migreres til SFM eller være tilgjengelig i EPJ.

2.1.4

EPJ skal sikre at valgt migreringsmåte ivaretar behovene til de brukergrupper de leverer til.

Alle

Alle

EPJ

Når det finnes relevant data om kritiske legemiddelreaksjoner som er strukturert så skal det migreres.

For fastleger og avtalespesialister skal LIB migreres slik at brukerne kan finne igjen samme liste før og etter migrering.