Syftet med denna si​da är att beskriva regler för syntax, informationsstruktur och regler för innehåll i ett XML-meddelande som utväxlas mellan djursjukvårdens parter och E-hälsomyndigheten.​

1. Avgränsningar och förutsättningar

Alla specifikationer och krav gällande NEF berör enbart e-recept djur. Verksamhetsregler för e-receptmeddelande för djur beskrivs i NEF - Verksamhetsregler för nationellt e-receptformat djur.

I detta dokument beskrivs regler för syntax, informationsstruktur och regler för innehåll i ett e-receptmeddelande som utväxlas mellan djursjukvå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 expediering av 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. På denna sida beskrivs de XML-specifikationer, XML-scheman och de verksamhetsregler som gäller för att ett XML-meddelande ska anses ha giltig innehållsstruktur.

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)
• PrescriptionAnimal.xsd (e-receptmeddelande)
• PrescriptionCancellationAnimal.xsd (makuleringsmeddelande)
• AperakAnimal.xsd (Applikationskvittens e-receptmeddelande)
• 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. PrescriptionAnimal.xsd  

PrescriptionAnimal.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 PrescriptionAnimal.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 PrescriptionAnimal.xsd.

2.1.2. AperakAnimal.xsd

AperakAnimal.xsd innehåller definition av applikationskvittens för e-recept. D​en inkluderar Header.xsd och Types.xsd.

 
Figur 3. Översiktsbild AperakAnimal.xsd.

I specifikationen för aperaken finns förklaringar och tillämpning av MessageRoutingAddress för ett e-recepts aperak.

2.1.3. PrescriptionCancellationAnimal.xsd

Nedanstående figur illustrerar hur XML-strukturen för makuleringsbegäran ser ut. 
 

Figur 4. Översiktsbild PrescriptionCancellationAnimal.xsd.

2.1.4. AperakCancellationAnimal.xsd

Nedanstående figur illustrerar hur XML-strukturen för makuleringskvittensen ser ut. 

 
Figur 5. Översiktsbild AperakCancellationAnimal.xsd. 

.

2.1.5. Header.xsd

Header.xsd innehåller en generell definition av format på MessageRoutingAddress. Den inkluderar Types.xsd och Header.xsd och inkluderas i PrescriptionAnimal.xsd och AperakAnimal.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 

Verksamhetsregler för e-receptmeddelandet kan delas in 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:

• djurvårdsystemet producerar ett meddelande som följer specifikationen och verksamhetsreglerna för nationellt e-receptformat
• kontroller sker under förskrivningsfasen i djurvå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 djurvårdsystemet.

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 innebär det att meddelandet ska vara enligt syntaxen för XML version 1.0. Ett giltigt meddelande ska uppfylla de villkor som ställs i 3.2 och 3.3 nedan.

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.

Korrekt struktur på meddelandet och korrekt format på datavärden som följer regler för definierade datatyper:

• Att meddelandet innehåller den information och de informationselement som är obligatoriska, i rätt ordning och frekvens.
• 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 genom 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  validering med avseende på ett visst schema.

3.3. Korrekt innehåll utifrån verksamhetsfall

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.

4. Verksamhetsregler utöver de som definieras i XML-scheman 

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

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

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 "Vägledning till Läkemedelsverkets föreskrifter (HSLF-FS 2019:32) 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 AFF- kontroller. I dokumentet Riktlinjer kvittenshantering beskrivs detta mer ingående.

4.2.2. 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.3. Särskilda läkemedel

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.4. Teknisk sprit

Förskrivs teknisk sprit får antal uttag inte överskrida 1 (DispensingRepeatNumber = 1).

4.2.5. Instruktioner vid upprepad expediering

Det är ett krav att man ska kunna ange ett så kallat expedieringsintervall för alla förskrivningar. Anges tid mellan uttag (TimeInterval) i recept ska tidsenhet (TimeUnit) och Tidsvärde (TimeValue) anges.

4.2.6. 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.7. Användande av Födelsedatum (FDA)

Endast e-recept med personnummer kan hanteras i Receptdepå djur. 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) 

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 djurägaren.

4.2.8. 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 dock alltid finnas tillgänglig i vårdsystemet för att ge förskrivaren möjlighet att kunna direktadressera till ett specifikt apotek. Exempelvis kan avtal finnas mellan vårdenhet och ett lokalt apotek. Apotekslistan innehåller även viktiga kontaktuppgifter till apoteket som förskrivaren behöver för att kunna komma i kontakt med farmaceut eller kunna ringa in recept.

Apotekslistan beskrivs detaljerat i Postbeskrivning apotekslista djur.

4.2.9. Applikationskvittens 

(MessageReceiptAcknowledgementRequest = AL) ska alltid ha värdet AL i transportinformationen i receptsamlingen.

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

KRAV 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.11. 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"

4.2.12. 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.13. Sista datum för första uttag/begränsad giltighetstid

I Läkemedelsverkets föreskrifter (HSLF-FS 2019:32) om förordnande och utlämnande av läkemedel och teknisk sprit, 26 § 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.

PrescriptionItemAuthTime kan användas för att ange en kortare giltighetstid för den aktuella receptraden. För antimikrobiella läkemedel ska dock giltighetstiden alltid vara 5 dagar.

Om en receptsamling med flera recept förskrivs ska olika giltighetsdatum kunna anges.

4.2.14. Begäran om applikationskvittens

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 eller 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. Det är därför ett krav att alltid ange att man efterfrågar kvittenser och att dessa hanteras i system och verksamhet.  

MessageReceiptAcknowledgementRequest ska sättas till AL (Always).

4.2.15. Ange alltid SystemName och SystemVersion

För att bedriva ett kvalitetsarbete 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.16. Använd alltid unika idn (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 Rekommendation till hantering av GUID-UUID beskrivs detta mer detaljerat.

4.2.17. Doseringsanvisning  

Doseringsanvisning, UnstructuredDosageAdmin, ska inte innehålla några kontrolltecken (radbrytning, tab m.fl.).

Texten ska vara i klartext, förkortningar får inte förekomma. De enda förkortningar som får förekomma är sådana som används för doseringsenheter som exempelvis: mg, ml, E, g och kg.

4.2.18. 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.18.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 och för expedierande farmaceut som därefter kan hantera informationen på lämpligt sätt.

I de fall ett e-recept skrivs ut på papper skrivs språket ut i klartext på pappersreceptet under Övriga upplysningar

Språkkoder beskrivs i ISO 639-1 och anges i LanguageOfLabel.

4.2.18.2. Arvode - 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. Fälten är alltså fortfarande en del av NEF, men ska inte användas.

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

KRAV Förskrivarens kommentar ska inte automatiskt följa med vid förnyelse av recept.

4.2.18.4. Leveransinformation

KRAV Om leverans ska ske via ombud är det obligatoriskt att ange leveransinformation, detta anges i fältet DeliveryLocation.

4.2.19. Förskrivarkod

KRAV Giltig förskrivarkod ska alltid anges i MessageSender och Prescriber.

4.2.20. 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ör mer omfattande användning, till exempel i utbildningssyfte ska E-hälsomyndigheten informeras.

4.2.21. Produkt- och artikelinformation

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.

4.2.22. 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 djurägare.
Källa: Läkemedelsverkets föreskrifter (HSLF-FS 2019:32).

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.23. Hårdkodning rekommenderas ej

Hårdkodning och egen inbyggd logik utöver den ovan beskrivna NEF-hanteringen är alltid förknippat med risker, och ska därför undvikas i vårdsystemet.

5. Referenser

E-recept djur

PIRR Anrop av webbtjänster

Riktlinjer kvittenshantering

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

Versionshistorik