Verksamhetsregler för nationellt e-receptformat human
Denna sida innehåller en beskrivning av de regelverk som gäller för att förskriva och makulera elektroniska recept till Receptdepå human via NEF-formatet.
1 Inledning
1.1 Syfte
Syftet med denna sida är att beskriva de regelverk som gäller för att förskriva och makulera elektroniska recept.
1.2 Målgrupp
Målgrupp för denna sida är vårdgivare med IT-system som nyttjar E-hälsomyndighetens tjänster samt systemleverantör som utvecklar eller förvaltar dessa IT-system.
1.3 Informationsnivå
Allmän information.
1.4 Bakgrund
Verksamhetsregler för XML-receptmeddelanden kan indelas i tre olika nivåer: syntaktisk och strukturell nivå samt regler avseende innehåll vilket benämns Automatisk format och författningskontroll (AFF).
1.5 Avgräsningar och förutsättningar
Att tillämpa nationellt e-receptformat innebär att vårdsystemet producerar ett meddelande som följer specifikationen och verksamhetsreglerna för nationellt e-receptformat och att kontroller sker under förskrivningsfasen i vårdsystemet som säkerställer detta. Det är viktigt att kontroller enligt specifikationen för nationellt e-receptformat sker så tidigt som möjligt i vårdsystemet.
Korrekt struktur och format, regelverk samt syntax för XML beskrivs mer detaljerat i NEF - Teknisk implementationsguide.
2. Regler för korrekt syntax enligt meddelandeformat XML
För att tillämpa verksamhetsregler på ett meddelande förutsätts att meddelandet är "well formed", det vill säga korrekt bildat enligt de syntaxregler som gäller för formatet. E-hälsomyndigheten har bestämt att meddelandet ska vara bildat enligt syntaxen för XML version 1.0
3. Regler för korrekt struktur på information och informationselement
Förutom att meddelandet ska följa XML-syntax ska meddelandet innehålla rätt information och informationselement. Med information avses här data som är knutet till ett visst informationselement.
Regelverk specificeras i XML-specifikationer av ett XML-schema.
Ett XML-meddelande (exempelvis ett e-receptmeddelande) valideras gentemot ett XML-schema. Validering kan vara att dokumentet överensstämmer med ett visst regelverk. En strukturell validering av ett XML- meddelande görs, det vill säga att det innehåller den information och de informationselement som är obligatoriska, i rätt ordning och frekvens samt att de datavärden som finns i meddelandet följer de restriktioner som finns angivna. Exempel på detta är teckenlängd, datatyp, format, giltiga kodvärden.
Regelverk anger vad som ska gälla för alla e-receptmeddelanden oavsett dess innehåll utifrån olika situationer ur ett verksamhetsperspektiv.
4. Regler för korrekt innehåll utifrån verksamhetsfall
Denna typ av validering kan göras maskinellt eller manuellt genom att exempelvis en farmaceut granskar innehållet i ett recept. Exempel på sådana regler är att vissa informationselement är obligatoriska om en förskrivning avser en förskrivning av läkemedel. Denna typ av regler refererar till externa fakta i en verksamhet som att en förskrivning med ett visst NplPack-Id innebär en förskrivning av läkemedel. Identifiering av dessa fall kan inte göras enbart genom att inspektera meddelandet utan måste definieras utifrån en extern källa (till exempel en databas som kan användas för att klassificera varor med olika NplPack-Id).
I denna kategori faller även de regler som inte kan fångas i ett XML-schema. Detta gäller villkorliga beroenden i ett meddelande, exempelvis att informationselement eller information måste vara obligatoriska eller ha ett visst värde, beroende på ett visst värde i ett fält.
5. Verksamhetsregler utöver de som definieras i XML-scheman
5.1 Transportinformation - Message Routing Address
5.1.1 Sender
Sender (MessageRoutingAddress/Sender) ska motsvara den avtalade identiteten för sändare av elektroniska meddelanden (e-recept och makuleringsmeddelande).
5.1.2 Subsender
Receptsamlingen respektive makuleringsmeddelandet ska innehålla en systemidentifikation för sändande system (MessageRoutingAddress/Subsender).
5.1.3 SystemName och Systemversion
Information i SystemName och SystemVersion ska motsvara namn och version av vårdsystemet där receptet skapats. I de fall modulversion finns ska det anges i fältet ModuleVersion.
5.2 Regler för receptinnehåll
5.2.1 Begäran om applikationskvittens
Kvittenshantering i flödet är en grundpelare i att åstadkomma ett tillförlitligt och kvalitetssäkrat flöde. Avsändande system ska alltid begära en kvittens och kunna hantera dessa i system och verksamhet. MessageReceiptAcknowledgementRequest ska alltid ha värdet AL (Always).
Det är nödvändigt att använda kvittens för att få information om eventuella fel. Det kan gälla valideringsfel enligt XML-schemat, validering av andra verksamhetsregler eller andra tekniska fel. I NEF - Riktlinjer kvittenshantering beskrivs detta mer detaljerat.
5.2.2 Använd alltid unika idn (UUID/GUID)
UUID/GUID ska användas för unik identifiering av meddelande. Detta gäller följande element i ett e-receptmeddelande: IdOfMessageBySender, PresciptionSetID och InterChangeRef. I
NEF - Rekommendation till hantering av GUID - UUID beskrivs detta mer detaljerat.
Att använda unika id har flera syften:
identifiering av receptmeddelande
identifiering av makuleringsmeddelande
hantering av tekniska dubbletter
loggning för support
referens till tjänster mot förskrivningsoriginal
5.2.3 Meddelandets sändare
Meddelandets sändare (MessageSender) ska alltid vara samma som förskrivare (Prescriber).
Fältlängden för förskrivarens namn är begränsat till 35 tecken. Namnet ska skrivas i form av ”Efternamn Förnamn”, enligt NEF - Specifikation för XML-meddelande E-recept human.
5.2.4 GLN-kod till mottagande Apotek
Vid förskrivning behöver förskrivare i vissa sammanhang kunna adressera ett e-recept till ett angivet apotek, till exempel då en patient inte har ett fullständigt och giltigt personnummer. Vid mottagning av e-receptet sker en validering mot E-hälsomyndighetens Expeditionsställeregister (EXPO) att apoteket (GLN-koden) som e-receptet adresseras till finns i EXPO, är godkänt och aktivt.
Apotekslistan innehåller även viktiga kontaktuppgifter till recepturen som förskrivaren behöver för att kunna komma i kontakt med farmaceut.
Apotekslista_js exporteras från EXPO och tillhandahålls till vårdsystem via en sftp-area.
För att få tillgång till apotekslista_js beställer vårdgivaren ett sftp-abonnemang via en blankett från E-hälsomyndigheten webbplats.
En ny apotekslista_js publiceras dagligen på sftp-arean.
Apotekslistan beskrivs detaljerat i bilaga Postbeskrivning apotekslista human.
5.2.5 Användande av Födelsedatum
Kan inte personnummer användas vid förskrivning av e-recept, finns en möjlighet att använda födelsedatum (FDA). Vid förskrivning på födelsedatum ska mottagande apotek identiferas med GLN-kod (DesignatedMessageReciever/HealthcareAgent/HealthcareAgentId).
Enligt receptföreskrifterna måste ålder och kön anges på patienten. Därför ska följande regler tillämpas vid förskrivning utan personnummer:
födelsedatumet måste vara fullständigt, det vill säga innehålla sekelsiffra, årtal, månad och dag för att vara sökbart på det mottagande apoteket och kunna knytas till en giltig identitetshandling (PatientId/Idscheme = FDA,PatientID/Value=ccyymmdd)
födelsedatumet måste vara rimligt och korrekt angivet för den aktuella patienten.
information om kön (SEX) ska anges eftersom kön ej framgår av födelsedatum.
5.2.6 Doseringsanvisning
Doseringsanvisning, UnstructuredDosageAdmin, ska inte innehålla några kontrolltecken (radbrytning, tab m.fl.). Texten ska vara i klartext utan förkortningar. De enda förkortningar som får förekomma är sådana som används för doseringsenheter till exempel mg, ml, IE, g och kg.
5.2.7 Språkkoder
Språkkoder beskrivs i ISO 639-1 och anges i LanguageOfLabel.
5.2.8 NPL-packid, NPL-id och varunummer
Nationellt e-receptformat kan hantera NPL-Packid, NPL-id och varunummer. Förskrivning kan ske antingen med en kombination av NPL-värden (IdType = NPLID) och NPL-PackId (IdType = NPLPACK), enbart NPL-PackId eller enbart varunummer (IdType = NVN).
Läkemedel i e-recept ska identifieras med NPL-id och NPL-packid.
Observera att artikeln ”licensläkemedel eförskrivning” (”gruppvarunummer” 670000, NPL-id: SB060301000001, NPL-packid:SB060301100001 ) enbart får användas vid förskrivning av licensläkemedel som ännu inte finns i VARA.
5.2.9 Arvode/patientavgift – Funktionaliteten har utgått
Funktionalitet för hantering av arvode har utgått. Fälten går fortfarande att skicka in, men informationen i dessa fält är inte synliga för apotek. Detta innebär att apoteken inte har någon möjlighet att administrera arvoden. Arvode/patientavgifter kan anges i PrescriptionSet/PaymentDetails och avser hela receptsamlingen.
Versionshistorik
| 1.0 |
2016-04-14 |
Ny sida i handbok för vårdaktörer, som bygger på information ur "NEF- e-recept". |
