NEF - Teknisk implementationsguide
Informationen har tagits fram i ett nationellt samarbete med representanter från regionerna, Sveriges Apoteksförening, Distriktsveterinärerna och Apotekens Service (nuvarande E-hälsomyndigheten). Förvaltningen av informationen ligger nu hos E-hälsomyndigheten.
1 Inledning
1.1 Syfte
Syftet med sidan är att beskriva regler för syntax, informationsstruktur och regler för innehåll för ett XML-meddelande som utväxlas mellan sjukvårdens parter och E-hälsomyndigheten.
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å
Teknisk information.
1.4 Avgränsningar och förutsättningar
I detta dokument beskrivs regler för syntax, informationsstruktur och regler för innehåll för ett e-receptmeddelande som utväxlas mellan sjukvårdens parter och E-hälsomyndigheten som bygger på formatet XML och den internationella förstandarden ENV 13607.
Den nivå som beskrivs i detta dokument är den tillämpningsnivå som gäller mellan parterna för verksamheten att förskriva, kommunicera och expediera ett elektroniskt recept.
Figur 1 Tillämpningsnivåer av e-receptmeddelande i XML
Ett XML-meddelande innehåller format, struktur, värdemängder enligt XML-scheman och verksamhetsregler. I detta dokument beskrivs de XML-specifikationer, XML-scheman och de verksamhetsregler som gäller för att ett XML-meddelande ska anses ha giltig innehållsstruktur [1].
2 Meddelanden
De olika meddelanden som definieras i detta dokument är:
Meddelandehuvud/MessageRoutingAddress
- E-receptmeddelande
- Makuleringsbegäran
- Applikationskvittens (Aperaker för e-receptmeddelande samt makuleringsbegäran)
Alla meddelanden har följande struktur:
Utväxling /Interchange
Huvud /MessageRoutingAddress
Meddelande (till exempel NewPrescriptionMessage, eller ApplicationAcknowledgeMessage)
Varje meddelande beskrivs i en XML-specifikation och definieras i ett antal XML-scheman:
- Header.xsd (MessageRoutingAddress)
- Prescription.xsd / PrescriptionAnimal.xsd (e-receptmeddelande)
- PrescriptionCancellation.xsd / PrescriptionCancellationAnimal.xsd (makuleringsmeddelande)
- Aperak.xsd / AperakAnimal.xsd (Applikationskvittens e-receptmeddelande)
- AperakCancellation.xsd / AperakCancellationAnimal.xsd (Applikationskvittens makuleringsmeddelande).
Dessa XML-scheman inkluderar alla Types.xsd eller Common.xsd som definierar enkla typer med restriktioner på format och giltiga värden.
Ett antal specifikationer definierar och förklarar innehållet i olika meddelanden i e-receptflödet:
2.1 XML-schema struktur
2.1.1 Prescription.xsd
Prescription.xsd innehåller ett meddelandehuvud, MessageRoutingAddress, som definieras i Header.xsd.
Därefter följer själva e-receptmeddelandet, NewPrescriptionMessage.
Alla generellt definierade typer finns i Types.xsd där datatyper definieras samt restriktioner som till exempel teckenlängd, tillåtna värden och giltiga mönster på data beskrivs. Denna typ av restriktioner kan även i vissa fall finnas i Prescription.xsd då de i vissa fall avviker från de generella enkla typernas restriktioner. För en översiktsbild av meddelandet se nedan.
Figur 2 Översiktsbild för Prescription.xsd
2.1.2 Aperak.xsd
Aperak.xsd innehåller definition av applikationskvittens för e-recept. Den inkluderar Header.xsd och Types.xsd.
Figur 3 Översiktsbild Aperak.xsd
I specifikationen för aperaken finns förklaringar och tillämpning av MessageRoutingAddress för ett e-recepts aperak.
2.1.3 PrescriptionCancellation
Nedanstående figur illustrerar hur XML-strukturen för makuleringsbegäran ser ut.
Figur 4 Översiktsbild PrescriptionCancellation.xsd
2.1.4 Aperak Cancellation
Nedanstående figur illustrerar hur XML-strukturen för hur makuleringskvittensen ser ut.
Figur 5 Översiktsbild AperakCancellation.xsd
2.1.5 Header.xsd
Header.xsd innehåller en generell definition av format på MessageRoutingAddress. Den inkluderar Types.xsd. Header.xsd inkluderas i Prescription.xsd och Aperak.xsd.
Figur 6 Översiktsbild Header.xsd
2.1.6 Types.xsd och Common.xsd
Types.xsd och Common.xsd innehåller definition av enkla typer som används i de olika meddelanden som finns i e-receptflödet (XML).
Då antalet typer är för många för att få plats på en bild kan de inte visas på denna sida.
3 Verksamhetsregler - e-receptmeddelande human
Verksamhetsregler för e-receptmeddelandet kan indelas i tre olika nivåer: syntaktisk och strukturell nivå samt regler avseende innehåll i förhållande till olika situationer i en viss verksamhet, det vill säga från förskrivning till expediering av ett elektroniskt recept.
Att implementera 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.
Verksamhetsregler för e-recept djur beskrivs i dokumentet "Handbok för vårdaktörer - DJUR", bilaga Förskrivning DJUR.
3.1 Korrekt syntax enligt meddelandeformatet XML
För att tillämpa verksamhetsregler på ett meddelande förutsätts att meddelandet är korrekt bildat enligt de syntaxregler som gäller för formatet. I E-hälsomyndighetens fall att meddelandet är enligt syntaxen för XML version 1.0.
3.2 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.
I. Korrekt struktur på meddelandet och korrekt format på datavärden som följer regler för definierade datatyper.
a) Att meddelandet innehåller den information och de informationselement som är obligatoriska, i rätt ordning och frekvens.
b) Att de datavärden som finns i meddelandet följer de restriktioner som finns angivna, exempelvis teckenlängd, datatyp, format, giltiga kodvärden.
Detta regelverk specificeras i specifikationer (Specifikation av MessageRoutingAddress, applikationskvittens och XML-recept) och av ett antal XML-scheman, se kapitel 2 - Meddelanden. Ett XML-dokument (till exempel ett e-receptmeddelande) valideras att dokumentet överensstämmer strukturellt med ett visst regelverk gentemot ett XML-schema.
Detta regelverk anger vad som ska gälla för alla e-receptmeddelanden oavsett dess innehåll utifrån olika situationer ur ett verksamhetsperspektiv. Detta är en intern statisk [2] validering med avseende på ett visst schema.
3.3 Korrekt innehåll utifrån verksamhetsfall
II. Regler som upprätthåller meddelandets interna konsistens (att vara ett giltigt recept i olika situationer) med avseende på olika fall som uppstår i en verksamhet.
Detta är en extern dynamisk validering med avseende på en extern verksamhet. Denna typ av validering kan göras maskinellt eller manuellt genom att till exempel 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 av 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 (exempelvis 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. Till exempel att informationselement eller information måste vara obligatoriska eller ha ett visst värde, beroende på ett visst värde i ett fält.
Ett giltigt meddelande ska uppfylla de villkor som ställs i I och II.
4 Verksamhetsregler utöver de som definieras i XML-scheman (human)
XML-schemat definierar alla obligatoriska informationselement som gäller för förskrivningar av läkemedel, teknisk sprit, livsmedel samt hjälpmedel.
I XML-schemat finns denna information samt en mängd andra restriktioner av innehållet (stränglängder, format, kodvärden).
Verksamhetsregler för e-recept djur beskrivs i "Handbok för vårdaktörer - DJUR", bilaga Förskrivning DJUR.
4.1 Transportinformation - Message Routing Address
4.1.1 Sender
(MessageRoutingAddress/Sender) Samma Sender som används i receptsamlingen ska användas i makuleringsbegäran.
Exempel på struktur:
Exempel 1
<Sender>GLNkod för sändande system</Sender>
<SenderQualifier>14</SenderQualifier>
<SubSender>Vårdcentral ID</SubSender>
Exempel 2
<Sender>Organisationsnummer för sändande system</Sender>
<SenderQualifier>30</SenderQualifier>
<SubSender>Vårdcentral ID</SubSender>
Exempel 3
<Sender>Avtalad struktur för sändande system</Sender>
<SenderQualifier>ZZZ</SenderQualifier>
<SubSender>Vårdcentral ID</SubSender>
4.1.2 Subsender
Receptsamlingen respektive makuleringsmeddelandet ska innehålla en systemidentifikation för sändande system (MessageRoutingAddress/Subsender).
4.2 Regler för receptinnehåll klartext (human)
I detta avsnitt följer en beskrivning av vissa regler för att exemplifiera hur receptets struktur och innehåll implementeras utöver de som definieras av XML-schemat och specifikationen. Text i fet stil anger om ett namn refererar till ett informationselement i specifikationen och i XML-schemat.
Vägledande för de beskrivna verksamhetsreglerna är Läkemedelsverkets föreskrifter (HSLF-FS 2021:75) om förordnande och utlämnande av läkemedel och teknisk sprit.
4.2.1 Avvisning och kontroll
Generellt gäller att vårdsystem ska kontrollera att receptmeddelande följer nedanstående regler utöver de regler som specificeras i XML-schema och specifikation.
E-hälsomyndigheten kontrollerar samtliga meddelanden, med schemavalidering och med AFF- kontroller. I dokumentet NEF - Riktlinjer kvittenshantering beskrivs detta mer ingående.
4.2.2 Läkemedelsförmån
a) och b)
För att ett läkemedel ska kunna expedieras med förmån måste läkemedlet vara berättigat till förmån och förmånstyps värde ska vara 'R' (CareCoverageType = R) samt att en giltig arbetsplatskod (HealthCareAgentId/Value av typen VENValue, IdScheme = VEN) är angiven.
c)
Ett läkemedel kan expedieras utan förmån om förmånstyps värde är 'U' (CareCoverageType = U ).
4.2.2.1 Övergångslösning för läkemedelsförmån efter lagändring (2 juni 2020-1 december 2025)
Fältet Förmånstyp ska endast avse huruvida patienten har rätt till läkemedelsförmån (=R) eller ej (=U), oavsett om läkemedlet som förskrivs är inom eller utom läkemedelsförmånen. Det måste därför vara möjligt att ange R eller U oavsett om valt läkemedel ingår i läkemedelsförmånen eller inte.
För varor som har förmånsbegränsning är det obligatoriskt att ange om förutsättningar för läkemedelsförmån är uppfyllda eller inte. Detta anges under övergångsperioden av förskrivaren i doseringstexten. Förslagsvis med texten "Villkor förmån är uppfylld" alternativt "Villkor förmån ej uppfylld". För läkemedel som inte har förmånsbegränsning ska denna uppgift inte anges.
Förutsättningar för att ett läkemedel ska kunna expedieras med läkemedelsförmån efter lagändring:
- En giltig arbetsplatskod (HealthCareAgentId/Value av typen VENValue, IdScheme = VEN) är angiven. Detta innebär ingen förändring.
- Patienten är en förmånsberättigad person vilket anges med värdet 'R' i förmånstyp (CareCoverageType = R).
- Då läkemedlet har förmånsbegränsning ska förutsättningarna för förmån vara uppfyllda.
4.2.3 Instruktioner för användning
Förskrivs ett läkemedel eller teknisk sprit är informationselementet och informationen i Instruktioner för användning (InstructionsForUse) obligatoriskt.
4.2.4 Särskilda läkemedel
a) Förskrivs särskilda läkemedel till en person (TypeOfSubjectOfCare = 1) får inte startförpackning förskrivas. Om typ av utbyte är lika med 'PRO'(SubstitutionType = PRO) är receptet felaktigt.
b) Förskrivs särskilda läkemedel till en person (TypeOfSubjectOfCare = 1) ska personens personnummer eller födelsedata (PatientId/IdScheme= PNR/FDA) anges.
Källa: Läkemedelsverkets föreskrift HSLF-FS 2019:32
4.2.5 Teknisk sprit
Förskrivs teknisk sprit får antal uttag inte överskrida 1 (DispensingRepeatNumber = 1).
4.2.6 Instruktioner vid upprepad expediering
Det är ett krav att man ska kunna ange ett så kallat absolut expeditionsintervall för alla förskrivningar. Anges tid mellan uttag (TimeInterval) i recept ska tidsenhet (TimeUnit) och Tidsvärde (TimeValue) anges.
4.2.7 Kön
Det är ett krav att ange kön vid receptförskrivning via NEF. Kön anges i fältet Sex.
Denna information kommer inte automatiskt med om förskrivning görs på födelsedatum, kön visas inte på recept.
4.2.8 Användande av Födelsedatum (FDA)
Kan inte personnummer användas vid förskrivning av e-recept, finns en möjlighet att använda födelsedatum (FDA). Det är då ett krav att e-receptet samtidigt adresseras till ett lokalt apotek. (DesignatedMessageReciever/HealthcareAgent/HealthcareAgentId/Idscheme = EAN, Value av typen EANValue)
Endast e-recept med personnummer kan hanteras i Nationella läkemedelslistan.
Patientens ålder och kön ska anges för en mer patientsäker hantering på apoteket. Därför är det viktigt att följande tillämpas vid förskrivning utan personnummer:
- då kön inte kan avläsas ur ett födelsedatum ska e-receptet innehålla information om kön (SEX).
- födelsedatum ska vara fullständigt, det vill säga innehålla sekelsiffra, årtal, månad och dag för att vara sökbart på ett lokalt apotek och kunna knytas till en giltig legitimation (PatientId/Idscheme = FDA,PatientID/Value=ccyymmdd).
- födelsedatum måste vara rimligt och korrekt angivet för den aktuella patienten.
4.2.9 GLN-kod till mottagande Apotek
GLN-kod för att ange ett mottagande apotek hämtas från apotekslistan. Denna beställs från E-hälsomyndigheten alternativt kontaktas aktuell region som kan ha ett abonnemang av apotekslistan.
Vid förskrivning på personnummer ska E-hälsomyndighetens GLN-kod till Receptbrevlådan anges som default. En aktuell version av apotekslistan ska alltid finnas tillgänglig i vårdsystemet för att ge förskrivaren tillgång till kontaktuppgifter till ett apotek som förskrivaren kan behöva för att komma i kontakt med farmaceut eller ringa in recept. Möjligheten att kunna direktadressera en förskrivning på personnummer till ett specifikt apotek kommer inte längre vara möjligt när vård- eller apotekssystem ansluter mot versionspaket 21. Det är fortsatt möjligt att direktadressera en förskrivning med personnummer med versionspaket 17.1 för vården, men apotek som anslutit till versionspaket 21 kommer inte längre få signal om att direktadresserat recept finns.
Förskrivning och expediering av direktadresserade förskrivningar på födelsedatum påverkas inte av förändringen utan är ett fortsatt krav oavsett vilket versionspaket ett vårdsystem eller apotekssystem ansluter mot.
Apotekslistan beskrivs detaljerat i Postbeskrivning apotekslista human.
4.2.10 Applikationskvittens
(MessageReceiptAcknowledgementRequest = AL) ska alltid ha värdet AL i transportinformationen i receptsamlingen.
4.2.11 Leveransinformation
Om meddelandets mottagare (DesignatedMessageReciever/HealthcareAgent/HealthcareAgentId/Idscheme = EAN, Value av typen EANValue) är ett lokalt apotek, till exempel en apoteksaktörs e-handel, är leveransinformation (PrescriptionSet/DeliveryLocation) innehållande namn och ort UnstructuredAddress) obligatorisk.
Leveransinformation ska inte automatiskt följa med vid förnyelse av recept.
Vårdsystemet ska ha en spärr som förhindrar att ett e-recept, som avses att skickas till ett lokalt apotek kan skickas iväg med ett tomt leveransinformationsfält.
4.2.12 Meddelandets sändare
Meddelandets sändare (MessageSender) ska alltid vara samma person som är 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-recept.
4.2.13 NPL-packId, NPL-id och varunummer
Nationellt e-receptformat kan hantera NPL-id, NPL-PackId och varunummer. Förskrivning kan ske antingen med:
- enbart NPL-PackId (IdType = NPLPACK)
- kombination av NPL-värden; NPL-id (IdType = NPLID) och NPL-PackId (IdType = NPLPACK)
- enbart varunummer (IdType = NVN)
All förskrivning av läkemedelsartiklar ska ske med enbart NPL-PackId, eller en kombination av NPL-PackId och NPL-id. Även APL-produkter, extempore och licenser räknas som läkemedel.
Generella artiklar (så kallade ”gruppvnr”) som ”Licensläkemedel e-förskrivning” (vnr 670000) och ”Extempore e-förskrivning” (vnr 660000) har NPL-identiteter som ska användas vid e-förskrivning. Artikeln ”Teknisk sprit e-förskrivning” (vnr 640000) är däremot en handelsvara och identifieras därmed med hjälp av varunummer vid e-förskrivning.
Se även VARA - Nationellt produkt- och artikelregister.
4.2.14 Startförpackning
Vid förskrivning som inte avser särskilda läkemedel eller teknisk sprit ska startförpackning kunna anges. (Substitution Type=PRO).
Startförpackning ska inte automatiskt följa med vid förnyelse av recept.
4.2.15 Utbyte av läkemedel
Vid förskrivning ska man kunna ange att utbyte inte får ske (SubstitutionType = EBY).
4.2.16 Fler förpackningar av samma läkemedel
Flerval innebär förskrivning av ett läkemedel från en leverantör, med samma beredningsform, dosering och styrka, enda skillnaden är förpackningsstorlek (PrescriptionItemId).
Kontakt ska tas med E-hälsomyndigheten innan flerval implementeras i nya vårdsystem.
4.2.17 Sista datum för första uttag/begränsad giltighetstid
I Läkemedelsverkets föreskrifter (HSLF-FS 2021:75) om förordnande och utlämnande av läkemedel och teknisk sprit, anges att "Ett recept gäller under ett år från den dag det utfärdas om inte förskrivaren anger kortare giltighetstid. För övriga utlämnanden är giltighetstiden ett år."
För att ange en förkortad giltighetstid för första uttaget ska fältet LatestRequestedTimeForDispensing användas. Om en receptsamling med flera recept förskrivs ska olika giltighetsdatum kunna anges för varje enskilt recept.
Det rekommenderas att detta fält används för exempelvis antibiotikaförskrivning för att undvika att ett recept ligger kvar i Receptdepån för uttag trots att behovet av antibiotika rimligtvis upphört efter en tid.
PrescriptionItemAuthTime ska inte användas för e-recept.
4.2.18 Begäran om applikationskvittens
Det är ett krav att alltid ange att man efterfrågar kvittenser och att dessa hanteras i system och verksamhet. Enligt XML-specifikationen i nationellt e-receptformat är det obligatoriskt med en kvittens. 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. Kvittenshantering i flödet är en grundpelare i att åstadkomma ett tillförlitligt och kvalitetssäkrat flöde.
MessageReceiptAcknowledgementRequest ska sättas till AL (Always).
4.2.19 Ange alltid SystemName och Systemversion
För att bedriva kvalitets- och säkerhetsarbete, både för sändande och mottagande part, är det nödvändigt med information om vilket system som skapat receptmeddelandet. Därför är det ett krav att alltid ange åtminstone SystemName och SystemVersion på vårdsystemet där receptet skapats.
I de fall modulversion finns ska det anges i fältet ModuleVersion.
4.2.20 Använd alltid unika id:n (UUID/GUID)
Att använda unika id har olika syften:
- identifiering av receptmeddelande
- identifiering av makuleringsmeddelande
- hantering av tekniska dubbletter
- loggning för support
- referens till tjänster mot förskrivningsoriginal
Därför är det ett krav att alltid använda unika identiteter vid implementation av nationellt e-receptformat.
En unik identifiering av meddelandet kan användas genom att använda UUID/GUID. Detta gäller följande element i ett e-receptmeddelande:IdOfMessageBySender, PresciptionSetID och InterChangeRef. I dokumentet " NEF- Rekommendationer till hantering av UUID/GUID" beskrivs detta mer detaljerat.
4.2.21 Doseringsanvisning
Doseringsanvisning, UnstructuredDosageAdmin, ska inte innehålla några kontrolltecken (radbrytning, tab m.fl.).
Texten ska vara i klartext. Förkortningar ska inte förekomma förutom sådana som används för doseringsenheter som exempelvis: mg, ml, E, IE, g och kg.
4.2.22 Särskilda upplysningar
Förskrivaren har möjlighet att lämna särskilda upplysningar till apoteken. Vissa av dessa upplysningar har strukturerats upp för att minska feltolkning:
4.2.22.1 Språk
Språkkoder, LanguageOfLabel, ingår i NEF-formatet. Genom att använda språkkoder underlättas det för förskrivaren att kunna ange vilket språk patienten förstår och kan användas av apoteken för kommunikation med patienten. Enligt NEF-formatet ska fältet språk användas för att förskrivare ska kunna indikera att patienten inte förstår svenska. Fältet är synligt för apoteken. Expedierande farmaceut kan därefter hantera informationen på lämpligt sätt.
Farmaceuten ska vid utlämnandet ge patienten en individuellt anpassad information angående hur läkemedlet ska administreras, förvaras mm.
I de fall ett e-recept skrivs ut på papper skrivs språket ut i klartext på receptblanketten under Övriga upplysningar
Språkkoder beskrivs i ISO 639-1 och anges i LanguageOfLabel.
4.2.22.2 Förskrivarens kommentar
Det ska vara möjligt för förskrivaren att lämna annan kortfattad upplysning till apoteket, som kan vara relevant vid expediering genom att använda fältet PrescribersComment.
Förskrivarens kommentar ska inte automatiskt följa med vid förnyelse av recept.
4.2.22.3 Leveransinformation
Om leverans ska ske via ombud är det obligatoriskt att ange leveransinformation, detta anges i fältet DeliveryLocation.
4.2.23 Förskrivarkod
Giltig förskrivarkod ska alltid anges i MessageSender och Prescriber.
4.2.24 Arbetsplatskod
XML-formatet tillåter upp till 17 tecken i fältet HealtcareAgentInContextId/HealtcareAgentId/Value. Trots att det ryms 17 tecken i detta fält så används max 13 tecken enligt standard ISO/IEC 15416. En giltig arbetsplatskod ska bestå av max 13 siffror och inleds med en två-siffrig landstingskod. Utifrån arbetsplatskoden genereras en streckkod för de e-recept som skrivs ut på apotek. Arbetsplatskoden används även av apoteken för att rapportera försäljning till respektive region.
Om arbetsplatskod saknas i arbetsplatskodsregistret kan elektroniska recept inte tas emot.
Om arbetsplatskod finns i arbetsplatskodsregistret men är ogiltig vid förskrivningstillfället, kan inte receptet expedieras inom förmån.
4.2.25 Testindikator
I meddelandehuvudet MessageRoutingAddress ska alltid giltig testindikator anges i fältet TestIndicator.
När man skickar ett e-recept används fältet för att ange om receptet är avsett för Produktion (TestIndicator=1), Test (TestIndicator=2) eller Utbildning (TestIndicator=3).
För att testa respektive utbilda i vårdsystem kan man i begränsad omfattning ange TestIndicator=1 eller TestIndicator=3. Testindicator=2 accepteras inte i produktion.
Test- och utbildningsrecept ska användas ytterst sparsamt i produktionsmiljö. Skarpa patientidentiteter ska under inga omständigheter användas! För test- och utbildningsrecept tillhandahålls testpersonidentiteter i de testpaket som ska användas vid tester. Tester utförs mot E-hälsomyndighetens testmiljö.
Det ska tydligt framgå för användaren vilken miljö som man är inloggad i (test, utbildning eller produktion).
Före mer omfattande användning, till exempel i utbildningssyfte, ska E-hälsomyndigheten informeras.
4.2.26 Produkt- och artikelinformation - Sil (Varulista)
För att förskrivaren ska få ett bra stöd vid förskrivning är det viktigt att vårdsystemet tillhandahåller en aktuell produkt- och artikelinformation. Det innebär bland annat att artiklar som tillhör samma produkt ska presenteras för förskrivaren så att denne kan skilja mellan dem och därmed välja rätt artikel trots att produktnamnet är detsamma, för mer information om detta hänvisas till bilaga VARA.
Rekommendationen är att produkt- och artikelinformationen uppdateras minst en gång i veckan.
Enligt beslut mellan Socialdepartementet och Sveriges Kommuner och Regioner (SKR, tidigare SKL) så ska vårdsystemen vara integrerade mot Sil så att alla använder sig av samma aktuella information. Sil uppdateras två gånger per vecka i dagsläget, rekommendationen är att även vårdsystemen uppdaterar produkt- och artikelinformationen med samma frekvens. Rekommendationen är att det sker via automatisk uppdatering.
Vid förnyelse av recept ska en förnyad kontroll mot Sil genomföras.
4.2.27 Iterering av narkotika
Recept med förskrivning som ska itereras avseende narkotika i förteckning II och III i Läkemedelsverkets föreskrifter (LVFS 2011:10) om förteckningar över narkotika får inte lämnas ut till patient.
Källa: Läkemedelsverkets föreskrifter (HSLF-FS 2021:75)
Narkotika på licens kan alltid itereras enligt receptföreskrifterna, utan att det behöver anges i doseringsanvisningen att det ska förvaras på specifikt apotek.
4.2.28 Förmån vid förnyelse av recept
Då ett recept förnyas ska vårdsystemet ha en kontroll mot en uppdaterad varulista i Sil, som kontrollerar om artikeln är förmånsberättigad eller inte. Rekommendationen är att förmån inte automatiskt följer med vid förnyelse.
4.2.29 Hårdkodning rekommenderas inte
Hårdkodning och egen inbyggd logik är alltid förknippat med risker, och ska därför undvikas i förskrivningssystemet.
5 Referenser
Postbeskrivning apotekslista human
NEF - E-recept djur
[NEF - E-recept human
NEF - PIRR Anrop av webbtjänster
NEF - Riktlinjer kvittenshantering
NEF - Rekommendation till hantering av GUID/UUID
Tillåtna tecken i element och attributdata
VARA - Nationellt produkt- och artikelregister
ENV 13607:2000 - Health informatics - Messages for the exchange of information on medicine prescriptions.
Svensk implementation av ENV 13607 i XML gällande: - Recept/rekvisition - Återkallande av recept/rekvisition - Information om expedierade läkemedel - Återkallande av information om expedierade läkemedel, http://www.sis.se/
ISO 639-1 - Standard för språkkoder
Läkemedelsverkets föreskrifter (HSLF-FS 2021:75) om förordnande och utlämnande av läkemedel och teknisk sprit
För information om förmåner, se: Tand- och Läkemedelsförmånsverket, www.tlv.se.
För Sil:s tjänstegränssnittsspecifikation, kontakta SIL på Inera http://www.inera.se/.
Versionshistorik
Utgåva |
Datum |
Kommentar |
2013-01-28 |
5.0 |
Samverkansgruppen NEF med representanter från landstingen, Sveriges Apoteksförening, Distriktsveterinärerna och Apotekens Service har upphört. Apotekens Service uppdaterar och fastställer dokumentet.
Uppdaterat hänvisningar till dokument.
Makulering för djur är infört, uppdatering i kapitel: 2, 5.1 och 5.2.
4.1.12 (human), Förtydligande
4.1.17 (human) uppdatering pga ny utgåva av Receptföreskrift - tolkningar och kommentarer,
4.1.29 (human), förtydligande vårdsystem ska använda SIL.
4.1.30 (human), förtydligande FDA
5 (human och djur), uppdatering av referenser |
2013-09-30 |
6.0 |
4.1.13, Rekommendation att läkemedelsartiklar förskrivs på en kombination av NPL-Packid och NPL-id.
5.2, Uppdaterat hänvisning till SIL. Lagt till referens till bilaga VARA. |
2014-09-26 |
7.0 |
Dokumentet inlagt i ny mall.
Versionshistorik äldre än 2 år har tagits bort.
Apotekens Service har ersatts av eHälsomyndigheten.
Sekretess enligt OSL 18:8 har gulmarkerats i hela dokumentet.
2 (human och djur), tabellen har uppdaterats med nya namn på specifikationer och hänvisning till plats där dokumentation tillhandahålls har uppdaterats.
4.1 (human), Nytt kapitel.
4.2 (human), Hänvisning till referens har uppdaterats.
4.2.2 (human), Hänvisning har lagts till.
4.2.9 (human), Förtydligande angående Apotekslistan samt hänvisning har lagts till.
4.2.10 (human), Subsender har flyttats till 4.1.2.
4.2.12 (human), Hänvisning har uppdaterats.
4.2.13 (human), Lagt till att eHäslomyndigheten har beslutat att förskrivning av läkemedel ska ske med NPLId och NPLPackId.
4.2.14 (human), Rekommendation avseende startförpackning har lagts till.
4.2.17 (human), Hänvisning till referens har uppdaterats.
4.2.23 (human), Funktionaliteten för arvode har utgått.
4.2.27 (human), Förtydligande avseende arbetsplatskod har lagts till.
4.2.29 (human), Förtydligat att förskrivaren behöver få stöd att välja rätt artikel samt en hänvisning till bilaga VARA. Rekommendation avseende SIL har lagts till.
4.2.30 (human) Lagt till iterering av narkotika på licens.
4.2.31 (human), Rekommendation avseende förmån har lagts till.
5 (human och djur), Referenser och hänvisning till plats där dokumentation tillhandahålls har uppdaterats. |
| 2016-04-15 |
8.0 |
4.2.4 och 4.2.30 (human), uppdatering med anledning av att receptföreskrifterna har uppdaterats.
4.2.11 och 4.2.24 (human), rekommendationer tillagda.
4.2.13 (human), förtydligande angående förskrivning av läkemedel med NPL-identiteter. Lagt till hänvisning till bilaga VARA.
4.2.22, (human) förtydligande av fältet LanguageOfLabel
4.2.27 (human), förtydligat att arbetsplatskoden måste vara giltig
4.2.28 (human), förtydligande angående testpersondeniteter
4.2.32 (human), nytt kapitel |
| 2017-12-27 |
9.0 |
4.2; 4.2.4; 4.2.17; 4.2.27 och 5 Uppdatering av hänvisning till föreskrift
4.2.8 och 4.2.9 Uppdatering från receptbrevlådan till Receptdepån |
| 2019-12-30 |
10.0+11.0 |
Redaktionella ändringar - exempelvis ny stavning E-hälsomyndigheten
Information om lagförändring gällande läkemedelsförmån
4.2.2.1 Nytt stycke kring förändringar från 2020-06-02 för läkemedelsförmåner
4.2.8 Uppdatering av information kring fda
4.2.22.2 Gråmarkerat information omborttagen funkrionalitet, arvode |
| 2020-05-25 |
12.0 |
4.2.2.1 Uppdaterat datum övergångslösning pga förskjutning NLL
4.2, 4.2.4, 4.2.17, 4.2.27, 5 Uppdaterat föreskrift
|
2022-04-08
| 13.0
| 4.2.9 Uppdaterat information om att direktadresserade recept för personnummer inte längre kan tas emot av apotek som anslutit till versionspaket 21
|
2023-11-10
| 14.0
| 4.2.26 Uppdaterat information om frekvens uppdatering av Sil
4.2.9 Uppdaterat information om direktadresserade förskrivningar på personnummer
|
[1] Giltig innehållsstruktur avser ej XML-format utan t.ex. obligatoriska element och innehåll i element beroende på lagstiftning och verksamhetsregler, t.ex. krav på innehåll i ett e-receptmeddelande vid förskrivning av särskilda läkemedel.
[2] Statisk i den meningen att den inte tar hänsyn till en tolkning i varje enskilt fall av olika data. Dynamisk validering kan sägas äga rum då den görs utifrån en tolkning av varje enskilt fall.
