3.1 Opprettelse, forvaltning og migrering i SFM basis API
Sist oppdatert med nye krav Feb 14, 2025
SFM Basis API er en separat applikasjon som har sin egen funksjonalitet, datamodell og sentral database. SFM Basis API krever at virksomhet opprettes i datatbasen og at det knyttes systembruker til virksomhet slik at videre oppdateringer av virksomhets og brukerinformasjon kan gjøres gjennom API og Virksomhetsportal.
ID | Kravbeskrivelse | Kravet gjelder | Godkjennes av | Kommentar |
3.1.1 | EPJ skal kunne opprette en ny virksomhet og oppdatere virksomheten i SFM. | 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. |
3.1.1.1a. | 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 | 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.
|
3.1.1.1b. | EPJ må være i stand til å opprette underorganisasjon i SFM. | Alle med aktuell kundegruppe | NHN | Merk at dette innebærer å kunne Hensikten med kravet er at EPJ bør være i stand til å sette opp en virksomhet (underorganisasjon) som skal ha separat journal. |
3.1.1.2 | EPJ skal vise fornuftig feilmelding når HelseID ikke kan utstede gyldig token. | Alle | NHN | HelseID sjekker at gyldig delegering foreligger. HelseID vil returnere feilkoder dersom dette ikke er oppfylt. Se HelseID dokumentasjon for spesifikke feilkoder som må håndteres. |
3.1.1.3 | EPJ som benytter SFM skal presentere HelseID-token med identifikator til SFM instans. | Alle | EPJ |
Begge disse tilsvarer SFM-id i sfm-organization profilen. |
3.1.1.4 | EPJ skal kunne tilby sine virksomheter et valg ifht om driftsleverandør skal ha en superbruker i deres organisasjon eller ikke. | Alle | EPJ | 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 nødvendigvis MÅ gjøres av en ansatt hos driftsleverandør. |
3.1.1.5 | EPJ skal ha funksjonalitet for å forvalte sine "tenants" og skal generere Journal-ID. | 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. |
3.1.1.6 | Eier av Multitenant HelseID-klienten må formidle korrekt Journal-id ved forespørsel om token for aktuell tenant. | Multitenant | EPJ |
|
3.1.1.7 | EPJ/driftsleverandør skal enkelt tilgjengeliggjøre informasjon om relasjon mellom virksomheter/kunder, og SFM journalinstanser | Multitenant | EPJ | Liste over kunder (inkl Navn, Organisasjonsnummer og Journal-id) skal kunne produseres fra EPJ/driftsleverandør. Hensikten med kravet er at EPJ skal ha denne oversikten/koblingen hos seg, og skal kunne være i stand til å fremskaffe denne informasjonen ved forespørsel fra NHN, f. eks til bruk ifbm. support/feilsøking. Gjelder også historikk. |
3.1.1.8 | System skal støtte manuell endring av Journal-id. Historikk skal ivaretas. | Multitenant | EPJ | 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. |