Signering av e-resept meldinger
- Sven Erik Johansson
Innhold:
Bakgrunn
Det lovhjemlet krav om signatur på resept. Både Rekvirerings- og utleveringsforskriften, og Reseptformidlerforskriften kravstiller dette.
"Signatur" har to hensikter i denne sammenhengen: Integritetsbeskyttelse, dvs at dokumentet er beskyttet mot uoppdagede endringer og entydig og sikker identifikasjon av rekvirent/avsender. Reseptformidleren validerer både integriteten og avsenderens autorisasjon som helsepersonell og rekvireringsrett. Denne valideringen dokumenteres på resepten. Reseptformidleren signerer for dette.
Følgende signaturformer tilgjengelig:
Tradisjonell XMLDSIG påført med personlig sertifikat fra godkjent sertifikatutsteder og nøkkelbruk "Ikke-avvisning". Dette sertifikatet er vanligvis utstedt som et Smartkort beskyttet med PIN kode.
Signatur basert på systemsertifikat med HelseID-token som bekreftelse på rekvirentens identitet og aktive signatur-handling. Systemsertifikatet benyttet for slik signatur skal være kjent av Reseptformidleren og knyttet til godkjent "Trusted party".
Definisjoner
|
|
|---|---|
Elektronisk signatur | Begreper knyttet til elektronisk signatur er komplisert. Dels er det overlappende begrepsbruk for tiltenkt nøkkelbruk i sertifikatene, dels er det forskjellige nivåer av signatur. Begreper som "avansert elektronisk signatur" og "kvalifisert sertifikat" er ment å presisere dette. De to løsningene som benyttes i e-resept har forskjellig tilnærming, men løser begge kravet til entydig og sikker identifikasjon av rekvirent, og beskyttelse mot endring av resept og PLL etter innsending (integritetsbeskyttelse) |
Personlig sertifikat | Sertifikat som er utstedt til en person av en Certificate Authority som er godkjent for bruk i e-resept, med policy som identifisererer det som personlig sertifikat: |
Virksomhetssertifikat /eSegl | Sertifikat som er utstedt til en virksomhet, hovedenhet eller organisasjonsledd av en Certificate Authority som er godkjent for bruk i e-resept, med policy som identifiserer det som et virksomhetssertifikat eller elektronisk segl. Nøkkelbruk (Key usage) for signatur skal være Ikke-avvisning = Non-repudiation = Content comitment (0x40). Sertifikatet skal minst støtte signatur-algoritme sha256WithRSAEncryption |
Elektronisk resept | Begrenses her til å omfatte meldingen M1 i gyldige versjoner som spesifisert av Direktoratet for e-helse. (Strengt tatt er resept sendt med telefaks omfattet av begrepet "elektronisk kommunikasjon" i personvernsammenheng, men det er ikke relevant her). |
HelseID | Tjeneste og format for sikker identifikasjon av systemer og personer i helsetjenesten. Integrert med nasjonale identitetstilbydere. For å kunne benyttes som grunnlag for signatur på elektronisk resept og PLL skal brukeren være logget inn på høyt nivå. Detaljer knyttet til bruk av Helse-ID finnes på:https://www.nhn.no/helseid/ |
Hodemeldingen | Struktur i XML for koding av meldinger i helsesektoren. Utgjør i denne sammenheng meldingen "M1 - Resept" med fagmelding "Resept", seksjon for avsender, mottaker og pasient og signatur. Hodemeldingen spesifiserer eget element for signatur med referanse til W3C spesifikasjon "XML Signature Syntax and Processing": XML Signature Syntax and Processing Version 1.1 (w3.org) Se egen definisjon av hodemeldingen for detaljer. |
Krav til signatur på resept og PLL
All bruk av e-resept forutsetter etterlevelse av Normen, og godkjenning for bruk mot Reseptformidleren.
Signatur skal alltid være en bevisst handling fra brukeren, og det skal være mulig for brukeren å forstå hva som signeres.
Sertifikater som benyttes ved signeringen skal være i henhold til krav i e-resept.
Resept kan signeres elektronisk på to måter:
Signatur basert på personlig sertifikat
Signatur basert på HelseID med person-id og virksomhetssertifikat/eSegl
Begge disse kan benyttes, men signatur basert på HelseID er betinget av spesiell godkjenning av systemet og driften av systemet som påfører signaturen.
Figur som viser alternative signeringsmetoder for resept. SKO signaturen finnes bare på resepter som utleveres til apotek og bandasjist (og videre til Helfo)
Signatur basert på HelseID med person-id og virksomhetssertifikat/eSegl
Signatur basert på HelseID påføres ved at systemet som signerer resepten vedlegger JWT token som bekrefter rekvirentens identitet som en konsekvens av handlingen "signer og send".
JWT token fra HelseID skal ha følgende claims for identitetsbekreftelse:
helseid://claims/identity/pid: <nasjonal identitet>
helseid://claims/identity/security_level: 4
helseid://claims/identity/assurence_level: high
(det er andre krav til format og innhold i token som ikke er dekket her)
JWT token identitetsbevis legges til M1 som vedlegg. Vedlegg er en standard mekanisme for Hodemeldingen. Vedlegg til meldinger er beskrevet i eget dokument: Vedlegg til meldinger - ehelse
JWT token vedlegges i <RefDoc> struktur på følgende måte:
<RefDoc> <IssueDate V="2018-10-12T09:30:12"/>
<MsgType V="A" DN="Vedlegg"/>
<MimeType>application/jwt</MimeType>
<Description>HelseID</Description>JWT token skal BASE64 kodes og legges ved i:
<Content> <Base64Container ...> (JWT token) </Base64Container>Signatur med virksomhetssertifikat påføres meldingen (M1/M25.1) i eget felt spesifisert for dette i Hodemeldingen (Signature):
"Elektronisk signatur. En XML-realisering av meldingen skal benytte XML Digital Signature i henhold til XML-Signature Syntax and Processing W3C Recommendation 12 February 2002, http://www.w3.org/TR/xmldsig-core/ " (NB: spesifikasjonen er revidert i 2013)
Signaturen skal være påført med virksomhetssertifikat på spesifisert nivå av driftsleverandøren som sender inn resepten. Signaturen har etter denne metoden to formål:
Driftsleverandøren digitale signatur på resept
Integritetsbeskyttelse av innholdet i en resept/PLL inklusive HelseID token med rekvirentens identitet.
Signatur etter denne metoden inkluderer rekvirentens nasjonale id (personnummer/d-nummer) samt HPR nummer (i hodemeldingen) og rekvirentens identitet er således entydig og sikkert bekreftet. Identiteten benyttes for oppslag i helesepersonellregisteret for kontroll av autorisasjon og rekvireringsrett.
Signatur basert på personlig sertifikat
For signering av resept etter denne metoden påføres meldingen (M1/M25.1) et signaturelement i eget felt spesifisert for dette i Hodemeldingen (Signature):
"Elektronisk signatur. En XML-realisering av meldingen skal benytte XML Digital Signature i henhold til XML-Signature Syntax and Processing W3C Recommendation 12 February 2002, http://www.w3.org/TR/xmldsig-core/ " (NB: spesifikasjonen er revidert i 2013)
Signaturen skal være påført med et Personlig sertifikat på spesifisert nivå av rekvirenten som sender inn resepten. Signaturen har etter denne metoden to formål:
Rekvirentens signatur på resept. Signeringssertifikatet knytter rekvirenten til signaturen.
Integritetsbeskyttelse av innholdet i en resept/PLL.
Signatur etter denne formen inkluderer rekvirentens offentlige sertifikat. Dette benyttes videre for entydig og sikker identifikasjon av rekvirent via oppslag hos sertifikat-utsteder. Identiteten benyttes for oppslag i helesepersonellregisteret for kontroll av autorisasjon og rekvireringsrett.
Reseptformidlerens kontroll og videre behandling
Reseptformidleren gjør omfattende kontroller av autorisasjon og rekvireringsrett ved mottak av resept. I tillegg valideres signaturer og gyldighet av alle benyttede sertifikater. Deretter genereres en kopi av resepten med et signaturkontollobjekt (SKO) som bekrefter valideringene og kontrollene som er gjort på mottakstidspunktet. SKO objektet fungerer som dokumentasjon av foretatt kontroll, samt at tilleggsinformasjon om rekvireringsrett og autorisasjon inkluderes. SKO signeres med Reseptformidlerens sertifikat. Resept med SKO benyttes på utleverersiden og danner grunnlag for refusjonskrav fra utleverer. Resepter uten benyttes i rekvirentdelen av e-reseptkjeden.
For signatur basert på HelseID er det en forutsetning av driftsleverandøren som påfører signatur med virksomhetssertifikat er opprettet som "Trusted party" i Reseptformidleren før signaturen blir godkjent for bruk.
Avvik
Ved alvorlige avvik fra Normen eller andre krav i e-resept, generelle grove sikkerhetsavvik eller bevisst misbruk av signeringsordningen kan dataansvarlig for Reseptformidleren utestenge helseperson, virksomhet, systemleverandør eller driftsleverandør til avviket er håndter avklart og håndtert.