Sist oppdatert med nye krav
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 | Kommentar |
3.1.1 |
Opprettelse av ny database for virksomhet som tar ibruk SFM Basis API skal gjøres gjennom SFM API
3.1.2
Operasjonen Post skal benyttes på sfm-Organization ressursen som er gjort tilgjengelig.
Organisasjon som opprettes skal ha unik HER-id som ikke er i bruk i SFM. Organisasjonsnummer som registreres skal være gjengitt i Access token.
3.1.3
Access token sikkerhetsnivå høy skal benyttes ved opprettelse av ny database. Det stilles krav til at token inneholder unik SFM-id som ikke tidligere er brukt for andre databaser i SFM.
EPJ skal kunne opprette en ny virksomhet og oppdatere virksomheten i SFM. | Alle | 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.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 | 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.2 | EPJ skal vise fornuftig feilmelding når HelseID ikke kan utstede gyldig token. | Alle | 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 |
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 | 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 | 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 | |
3.1.1.7 | EPJ/driftsleverandør skal enkelt tilgjengeliggjøre informasjon om relasjon mellom virksomheter/kunder, og SFM journalinstanser | Multitenant | 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 | 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. |