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.
|
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:
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 |
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: |
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.
|