NEF - Specifikation för XML-meddelande applikationskvittens e-recept human
Denna sida beskriver det fastställda formatet för att skicka och ta emot applikationskvittens för e-receptmeddelande human.
Syfte
Syftet med denna sida är att beskriva den struktur och det format informationen ska hålla för att mottagaren ska kunna tolka informationen i ett XML-meddelande på ett korrekt sät
Målgrupp
Målgrupp för denna sida är vårdgivare med IT-system som nyttjar eHälsomyndighetens tjänster samt systemleverantör som utvecklar eller förvaltar dessa IT-system.
Informationsnivå
Teknisk information.
Bakgrund
Detta dokument har tagits fram i ett nationellt samarbete med representanter från landstingen, Sveriges Apoteksförening, Distriktsveterinärerna och Apotekens Service. Förvaltningen av dokumentet ligger hos eHälsomyndigheten.
Övergripande struktur
Förklaringar
I denna specifikation förekommer ett antal förkortningar och koder för att beskriva förekomst och datatyper för element och attribut i XML-meddelandet.
Förkortningar
Förekomst = antal ggr ett element eller attribut skall/får förekomma enligt nedan:
[1] = Måste förekomma 1 gång (Obligatoriskt element eller attribut)
[0..1] = Förekommer ingen eller högst 1 gång (Frivilligt element eller attribut)
[0..*] = Förekommer ingen eller många gånger (Frivilligt element eller attribut)
[1..*] = Repeteras valfritt antal gånger. Måste dock förekomma minst 1 gång (Obligatoriskt element eller attribut)
{a,b,..} = Uppräkning av giltiga värden i ett datafält av uppräkningsbar typ.
Typ = typ av element eller attribut
A anger att det är ett attribut som avses och inte ett element.
Class motsvaras i ett XML-schema av en complexType.
Nedanstående typer motsvarar i ett XML-schema av simpleType.
S = String = Alfanumerisk teckensträng (bokstäver och siffror tillåtna)
V = Code Value = Kodat värde (numerisk), där betydelsen av varje kod skall framgå av tabell. (Exempel: 1 = Förskrivning)
I = Integer = Heltal
E = Enumerated = Uppräkningsbar typ (alfanumerisk), där tabell skall ange tillåtna värden med förklaringar. (Exempel: VEN)
Generella regler för meddelandestruktur
Om ett komplext element inte innehåller några obligatoriska element skall det komplexa elementet inte vara obligatorisk.
Denna regel tillämpas i specifikationen.
Om ett element inte är obligatorisk och inte innehåller data skall det inte finnas med i meddelandet.
Denna regel är nödvändig att följa för att det skall vara möjligt att kontrollera innehållet i ett meddelande. För att kunna göra detta måste det vara möjligt att avgöra om information är avsedd att finnas i ett visst elementfält.
Obligatoriska element får inte lämnas tomma. Detta kontrolleras vid mottagning.
Tillåtna tecken i element- och attributfält
XML-meddelanden skall följa XML 1.0 . Endast kodning enligt UTF-8 tillåts. Detta skall anges i en XML-deklaration. Detta gäller enbart meddelandet vilket kan konverteras till UTF-8 i t.ex. en receptserver ifall aktuellt vårdsystem inte stödjer UTF-8.
Tillåtna tecken i attribut och elementfält är en delmängd av UTF-8 och specificeras i Tillåtna tecken i element och attributdata.
XML-reserverade tecken
XML-reserverade tecken skall ersättas enligt "Extensible Markup Language (XML) 1.0 (Fourth Edition) 2.4 Character Data and Markup"(Se www.w3c.org). XML-reserverade tecken finns listade i [[Tillåtna tecken i element och attributdata]].
CDATA sektioner tillåts inte.
Ändringslogg
Äldre relevanta kommentarer i ändringsloggen är utgråade.
Ändringstyper
Formaliserad struktur. Innebär en ändring som syftar till att rätta struktur och fält och göra formatregler och kontroller enhetliga och mer formellt definierade.
Regelverk. Innebär en ändring som syftar till att korrigera meddelandet så att det överensstämmer med praxis, verksamhetsregler, föreskrifter och legala krav.
Utökad funktionalitet. Innebär en ändring som syftar till att utöka funktionalitet i meddelandet.
XML-Schema definitioner
XML-specifikationer och koppling till respektive XML-schema finns specificerade i NEF - Implementationsguide. XML-specifikationer kan uppdateras separat utan att ett nytt XML-schema tas fram.
1 Interchange - Rootelement
-Interchange |
Rootelement |
Class |
1 |
|
|
--MessageRoutingAddress |
Generellt meddelandehuvud tillämpas på e-recept |
Class |
1 |
|
2013-09-24: Beskrivs detaljerat i Specifikation för XML-Message Routing Address.
Tillämpningar beskrivs under 1.1 MessageRoutingAdress. |
-- ApplicationAcknowledgeMessage |
Aperakmeddelande |
Class |
1 |
|
Se 1.2 |
1.1 MessageRoutingAddress (tillämpningar)
Generellt meddelandehuvud tillämpas och beskrivs i detalj i Specifikation för XML-Message Routing Adress. Specifik tillämpning gäller för nedanstående:
- MessageRoutingAddress |
Meddelandehuvud, transportinformation |
Class |
1 |
|
Används som meddelandehuvud för e-recept och applikationskvittenser för e-recept. |
|
-- RecipientQualifier |
Kodkvalificerare för mottagare |
E |
1 |
Char(4)
{14, 30, ZZZ } |
Kvalificerare för mottagare.
14 = EAN / GLN
30 = Organisationsnummer
ZZZ = Avtalad struktur mellan parterna. |
2013-09-24: lagt till GLN |
-- MessageType |
Meddelandetyp
e-recept = meddelande av typen e-recept. Avser det meddelande som följer detta huvud. |
E |
1 |
Char(14)
{e-recept} |
Anger att innehållet i meddelandet följer strukturen för ett e-recept. Fler meddelandetyper kan tillkomma då användning utvidgas för detta meddelandehuvud. |
|
--- receipt |
Kvittenskvalificerare
application = applikationskvittens |
A, E |
1 |
Char(14)
{application} |
För detta meddelande används application, dvs det är en kvittens.
Exempel:
<MessageType receipt="application">e-recept</MessageType> |
|
1.2 ApplicationAcknowledgeMessage
ApplicationAcknowledgeMessage |
Aperakmeddelande |
Class |
1 |
|
|
|
--- ReferedObjectInfo |
Information om refererat meddelandeobjekt i kvittensen. |
Class |
1 |
|
Här kan inkluderas information som det är relevant att eka tillbaka från det ursprungliga meddelandet (innanför kuvertet MessageRoutingAddress) |
|
---- PrescriptionSetId |
Receptid på refererad objekt angivet av ursprunglig sändare av meddelandet. |
S |
1 |
Char(41) |
Idtyp anges i attributet idtype. |
|
----- idtype |
Typ av id. |
A,E |
0..1 |
Char(14) {UUID, GUID} |
Exempel: <PrescriptionSetId idtype="GUID"> 0af25f00-387d-11d3-9d31-00a0cc39621a</PrescriptionSetId> |
Nytt attribut för att kunna representera idtyp.
Ändringstyp: Utökad funktionalitet.
2014-09-18: Exemplet har uppdaterats. |
---- PrescriptionSetIssueTime |
Tidpunkt för utfärdade av refererat objekt, angivet av ursprunglig sändare av meddelandet. |
T |
1 |
Char(20) |
ccyy-mm-ddTtt:mm. Datum är ett legalt krav. |
|
--- MessageStatus |
Övergripande status på meddelandet.
0 = Accepterat utan upptäckta fel
1 = Accepterat med varningar
2 = Ej Accepterat, kan ej hanteras av mottagaren. |
V |
1 |
Char(1)
{0,1,2} |
1 = Accepterat med varningar innebär att det kan expedieras med justeringar på apotek. |
|
--- StatusInformation |
StatusInformation |
Class |
1..* |
|
Möjligt med flera statusinformationsrader. Även obligatoriskt vid MessageStatus = 0. |
|
---- StatusCode |
Informationskod
Prefix på statuskoden.
01 nnn - XML validering,
02 nnn - validering av verksamhetsregler för human
Där nnn börjar på 001. |
V |
1 |
Char(5) |
Används för att identifiera Statusinformation för behandling, mm. för t.ex. support, drift. För att ange vilken typ av validering som fallerat läggs ett prefix på statuskoden. |
|
---- Description |
Beskrivnings av kodens innebörd. |
S |
1 |
Char(254) |
|
|
Versionshistorik
2010-02-25 |
2.1.3 |
Viveka Ek |
Fastställd av NEF-förvaltningsgrupp efter granskning via projektplatsen. |
2010-05-12 |
2.1.4 |
Viveka Ek |
Granskad av styrgruppen den 12 maj, godkänd med några små ändringar. Ändringarna införda och dokumentet är således godkänt av styrgrupp för publicering. Ändringarna som infördes efter granskning av styrgrupp var:
Fastställande och ändringsdatum felaktigt. 1.2 Message status Apotek ändras till apotek. |
2013-09-24 |
3.0 |
Monica Rosén |
Specifikationen inlagd i ny mall och har lyfts upp till version 3.0 för att anpassas till nytt dokumenthanteringssystem. Översyn av layout och små textuella justeringar är gjorda.
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.
Koppling mellan XML-scheman och XSD-filer finns från och med nu i dokumentet NEF- Implementationsguide.
Äldre ändringar i ändringsloggen gråmarkeras och nya ändringar dateras från och med nu.
1.1, ny tabell för att förtydliga tillämpningar av Specifikation XML- Message Routing Adress, GLN tillagt. |
2014-09-18 |
4.0 |
Monica Rosén |
Specifikationen har bytt namn till "NEF - Specifikation Aperak E-recept XML".
Tagit bort versionshistorik som är äldre än 5 år.
Apotekens Service har bytts ut mot eHälsomyndigheten i text och logga.
1.2, Idtype, Exemplet har uppdaterats. |
