Den gode XML receptfornyelse PrescriptionRequest. 01.10.2006 Revideret 01.03.2012. Sundhedsfaglige anbefalinger og XML Facitliste for

L XPRE60 Den gode XML receptfornyelse PrescriptionRequest 01.10.2006 Revideret 01.03.2012 Sundhedsfaglige anbefalinger og XML Facitliste for XML receptfornyelse VersionCode: XR6031W TypeCode: XPRE60 1

2

Indholdsfortegnelse: Forord:... 4 Rettelser:... 4 Baggrund:... 5 Afsnit A: Sundhedsfaglige anbefalinger... 7 1. Receptfornyelse hos praktiserende læge eller speciallæge... 8 1.1 Formål... 8 1.2 En receptfornyelse fra system til system... 9 1.3 Den gode system til system receptfornyelse... 11 1.4 Forslag til standardsvar på anmodning om receptfornyelse... 12 Afsnit B: XML Facitliste... 13 XML Facitliste... 14 XML Kvalifikatorliste... 25 XML Testeksempel... 31 Bilag 1 Databeskrivelse for LMS-takst pr. 1. april 2005... 32 3

Forord Der har længe været et generelt ønske fra mange udviklere/leverandører og andre, at rettelser/præciseringer og lign. til standarderne blev skrevet ind i MedComs standarddokumentation, så alt blev samlet i et dokument. Vi forsøger derfor fremover at indskrive de rettelser/præciseringer der må komme i standarddokumentationen med tydelig markering af, hvornår den sidste rettelse er indført. Udover dette vil man stadig kunne se på tværs af alle standarderne hvilke rettelser der er kommet over tid i Rettelsesbladet som ligger på MedComs hjemmeside. Rettelser 1. marts 2012: PeriodUnitType og InvervalUnitType dag rettet til dag Fejl kvalifikatorlisten rettet, PeriodUnitType og InvervalUnitType dag var sat som om det var måned(er). 29. oktober 2010: PreferredPharmacy er nu krævet. For at være kompatibelt med Edifact udgaven, er PreferredPharmacy gjort mandatory i xml udgaven. 23. juni 2009: Fjernelse af G-EPJ elementer. G-EPJ elementer er ikke længere en del af xml-schemaet, hvis de medsendes sker dette ved at bruge elementet Local_Elements under Envelope. 1. juli 2007: SOR - Sundhedsvæsenets organisationsregister. I forbindelse med overgang til SOR (Sundhedsvæsnets Organisations Register) vil det fremover være muligt at anvende denne kode til identifikation af sundhedsvæsnets parter. Dette betyder at IdentifierCodeType i alle meddelelser også kan antage værdien sorkode. 2. november 2006: PostCodeIdentifier ændrer feltlængde fra n4 til an..9. Da der er flere udenlandspatienter som frekventerer danske læger bliver vi nødt til at udvide feltet, så det kan indeholde udenlandske postnumre. Feltet udvides fremover til an..9 i stedet for n4 som det er nu og dette gælder for alle XML meddelelser. 4

Baggrund I forbindelse med Fyrtårns-projektet i Nordjylland blev der udviklet en EDIFACT-standard til udveksling af data mellem Kommunens EOJ (Elektronisk Omsorgs Journalsystem) og 4 udvalgte lægesystemer. Denne standard byggede på den daværende receptstandard SST012. Standarden gav mulighed for at lave en anmodning om receptfornyelse direkte fra patientens medicinkort i EOJ-systemet, som kunne overføres direkte til lægens medicinkort. Herefter kunne den praktiserende læge nemt udpege den ønskede medicin i sit medicinmodul og generere en elektronisk recept til det ønskede apotek. Dette for at lette arbejdsgangen med receptfornyelser både hos hjemmeplejen og hos den praktiserende læge. Evalueringen af projektet var positiv og Ålborg Kommune og de involverede læger anvender standarden i dag og er samtidig udbredt til flere kommuner med samme omsorgssystem og læger med de 4 lægesystemer. Senere har også et femte lægesystem udviklet, så de kan modtage receptfornyelsesanmodningen også. Samtidig benyttes lejligheden til at lave en versionsændring af EDIFACT-versionen, så den bygger på gældende receptstandard (LMS016), som samtidig giver mulighed for at angive, om den fornyede medicinordination skal dosisdispenseres. XML-receptfornyelsen er udarbejdet i samarbejde mellem Lægemiddelstyrelsen og MedCom. Udarbejdelsen af XML-receptfornyelsen er baseret på det indhold, der i dag findes i recepten, og det er ved udarbejdelsen af XMLversionen sikret, at der fremover automatisk kan konverteres til en receptfornyelse, der er baseret på gældende EDIFACT-standard og -version. Denne konvertering kan testes på MedComs hjemmeside: http://web.health-telematics.dk/xmledi I forbindelse med indførelse af en fælles receptserver, hvor alle elektroniske recepter fremover skal sendes til og hjemmeplejens adgang til medicinprofilen, bliver der mulighed for, at EOJsystemerne kan implementere web-services med data fra medicinprofilen. Her vil det også være muligt at generere en anmodning om receptfornyelse. I den forbindelse er der behov for, at receptfornyelsesstandarden også er tilgængelig i XML-format. 5

Den samlede dokumentation af de gode XML-breve består af: Afsnit A Indeholder sundhedsfaglige anbefalinger og en gennemgang af anvendelsen med krav og anbefalinger med den pågældende kommunikation samt visning af et eksempel på et typisk papirbrev af den pågældende type. Hensigten med disse to beskrivelser er at give udenforstående (fx programmører) en overordnet forståelse af, hvad kommunikationen indebærer i praksis. Eksempel Et fuldt XML-eksempel på de i afsnit A viste papirrecepter er vist her. Supplerende testeksempler kan altid findes på MedComs hjemmeside. Bilag Databeskrivelse LMS-takst Afsnit B Indeholder den tekniske dokumentation af nærværende XMLstandard og består af: Facitliste For at sikre overensstemmelse mellem de sundhedsfaglige anbefalinger og en entydig mapning i MedComs XML-standarder er udarbejdet en Facitliste for benyttelsen af nærværende XMLstandard. Facitlisten skal sikre en ensartet benyttelse af standarden, således at alle afsendersystemer vil kunne anvende standarden nøjagtig ens. Definitionerne for de enkelte dataelementer er ligeledes opført i facitlisten. Kvalifikatorliste Indeholder de i den aktuelle meddelelse anvendte kvalifikatorer og de tilhørende værdier. 6

Afsnit A Sundhedsfaglige anbefalinger for XML receptfornyelsen XPRE60 7

1. Receptfornyelse hos praktiserende læge eller speciallæge 1.1 Formål Formålet med receptfornyelsesstandarden er, at plejepersonale hos kommunerne på vegne af en patient kan bestille receptpligtig medicin hos læge eller speciallæge. I de tilfælde, hvor der er tale om patienter, der er på fast medicin, kan disse genbestillingsekspeditioner med fordel foregå fra system til system. Det betyder nemlig, at plejepersonalet kan foretage bestillingen på et hvilket som helst belejligt tidspunkt på døgnet. Web-serviceintegration Hjemmepleje Omsorgssystem Denne meddelelse indeholder angivelse af ønsket præparat(er) med angivelse af form, styrke, pakningsstørrelse, dosering og indikation. Derudover kan der evt. være anført ønsker vedr. levering og ønsket apotek og måske en supplerende kommentar fra patientens side. Hvis receptfornyelsen direkte fra system til system skal besvares, sendes denne i en korrespondancemeddelelse til det svarlokationsnummer, der er angivet i receptfornyelsesstandarden. Nedenfor er skitseret flowet omkring receptfornyelsesanmodningen. De stiplede pile angiver flowet af receptfornyelsen, som det anvendes i dag direkte fra omsorgssystem til lægesystem. Receptfornyelse XML/EDIFACT Receptserver/ Medicinprofil Control XML/EDIFACT Lægesystem Receptfornyelse og Control (XML/EDIFACT) Korrespondance XML/EDIFACT Lægepraksis De beskrevne sundhedsfaglige anbefalinger i Den gode receptfornyelse er generelle anbefalinger. Behovet for yderligere information i forbindelse med receptfornyelse er minimal, da der er tale om kendte patienter for lægen. De relevante kliniske oplysninger, der ligger til grund for lægens vurdering i forbindelse med udstedelsen af den egentlige recept, ligger tilgængelige i lægens 8

eget system. Den gode receptfornyelse kræver derfor ikke supplerende vejledninger, hvor specielle lokale forhold præciseres og uddybes, men kan stå alene i den generelle form, den har. Eksempel 1: Benyttelse af EDI-kommunikation til receptfornyelse system til systemløsning via VANS har i modsætning til de hidtidige ad hoc løsninger den store fordel, at de fremsendte oplysninger kan genbruges i modtagersystemerne. 1.2 En receptfornyelse fra system til system (skærmdump fra stylesheet på MedComs konverter) svarende til de 3 EDIFACT-eksempler i afsnit B 9

Eksempel 2: Eksempel 3: 10

1.3 Den gode system til system receptfornyelse Det anbefales afsendersystemet (receptserver, omsorgssystem m.m.): At alle felter, som findes på receptfornyelse fra system til systemsiden, vises på et skærmbillede, før afsendelse kan ske. At receptfornyelsen registreres i systemet, således at gentagelse/genfremsendelse ikke finder sted på grund af manglende registrering eller overblik. At de viste receptfornyelsesinformationer skal kunne udskrives samlet, hvis bestilleren ønsker det. At der ved indtastningscheck eller automatisk overførsel af data o.l. sikres: CPR-nummervaliditet At der kun kan sendes meddelelser, der indeholder de nødvendige oplysninger medicinen kan afhentes samt evt. yderligere kommentarer. Forslag til standardsvar findes i afsnit 1.4. Modtagersystemet skal endvidere kunne kvittere system til system medicinbestillinger med almindelig positiv CONTRL på anmodning og negativ CONTRL generelt, jf. MedComs syntaks- og kommunikationsregler. Ved afsendelse fra receptserver er det hertil CONTRL sendes, medens korrespondance sendes direkte til svarlokationsnummer i receptfornyelsen. Det anbefales modtagersystemet (medicin- og journalmodulet hos modtager): At alle fremsendte informationer vises overskueligt i en eller flere funktioner. At fremsendte informationer ved modtagelsen vises, som de fremsendes sammen med opslag i egen database på identiteten af det modtagne CPR-nummer. At de modtagne informationer vises i sammenhæng med modtagersystemets medicinmodul for den pågældende patient. At modtagersystemet viser, hvorfra den pågældende meddelelse stammer. Hvis den kommer via VANS, skal rekvirentens data præsenteres sammen med de øvrige oplysninger i meddelelsen. Modtagersystemet skal kunne kvittere alle systemreceptfornyelser via korrespondancemeddelelse til plejehjemmet/hjemmeplejedistriktet, indeholdende oplysninger vedr. receptfornyelsen og apotek, hvor 11

1.4 Forslag til standardsvar på anmodning om receptfornyelse Forslag til standardsvar fra lægesystem til rekvirent (alle svar skal kunne redigeres). A) Patientens CPR-nummer findes ikke i lægesystemer Patienten ser desværre ikke ud til at være kendt i vort edb-system, så vi er ikke i stand til at imødekomme din medicinbestilling. Men du er velkommen til at ringe til os på telefon xxxxxxxx. B) Kvittering for modtagelse Vi har modtaget din anmodning om receptfornyelse. Du vil modtage vores svar på din anmodning indenfor X arbejdsdage. C) Imødekommelse af receptfornyelse. Din anmodning om receptfornyelse er nu færdigbehandlet. Medicinen kan hentes på XXXXXXXX Apotek. D) Negativ tilbagemelding på receptfornyelse. Recepten kan desværre ikke fornyes. Kontakt os venligst på telefon xxxxxxxx. 12

Afsnit B XML Facitliste XML Receptfornyelse XPRE60 13

XML Facitliste Den gode XML receptfornyelse, XR6031W VersionCode XPRE60 XML-Facitlisten består af følgende objekter: Emessage (Kuvert) o Envelope (KuvertData) Sent (Dato) o PrescriptionRequest (Receptfornyelse) Letter (BrevData) Authorisation (Dato) Sender (Afsender) PersonInOrganisation AnswerTo Receiver (Modtager) Issuer (Receptudsteder) PrefferredPharmacy (PatientOrRelative (Patient eller pårørende) PrescriptionInformation (Receptinformation) DoseDispenseInformation (Information om dosisdispensering) Delivery (Leveringsoplysninger) Drug (Lægemiddel) max. x 99 Importer (Importør) Dosage (Dosering) Indication (Indikation) Iteration (Genudlevering) DoseDispensing (Start og slutdato for dosisdispensering ) Objekterne er kun vist en gang, men nogle af dem kan gentages flere gange. De er markeret på følgende måde, f.eks.: max. x 10 Facitlisten består af følgende kolonner: XML Facitliste, der angiver navnet på data og kvalifikatorer som benyttes i Facitlisten. Feltdef, som angiver antallet af karakterer som er tilladt samt om det er en kvalifikator (KVA). M = Mandatory (obligatorisk), der angiver hvilke data der altid skal være medsendt af afsender. M kan forstås på 2 måder. a) I Facitlisten kan der stå et M ud for elementnavnet både i dets starttag og dets sluttag. Dette betyder at hele elementet inkl. nestede elementer skal sendes. For de nestede elementer gælder det dog kun hvis disse også er angivet som Mandatory. b) Hvis der ikke står et M ud for elementnavnet skal hele elementet ikke medsendes, men hvis man alligevel sender noget skal de nestede elementer med et M ud for altid sendes. EDIFACT TAG, som viser det tidligere EDIFACT datanavn. XML TAG, som viser XML element navnet. XML DataDefinition, der definerer indholdet af de enkelte data. Derudover beskrives relevante anvendelsesregler og andet, der er nødvendige for en korrekt implementering. 14

XML Facitliste XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <?xml version="1.0" encoding="iso-8859-1"?> Format M Skal medsendes som en kopi af den viste XML deklaration <!--MedCom_De_gode_EDIbreve_Udkast_1--> Format Anbefales medsendt <Emessage> <Emessage> <Envelope> M <Envelope> <Sent> M <Sent> <Date>Kuvertens_afsendelses_dato</Date> Date M KuvSendtDato <Date></Date> Date er dato for påbegyndelse af afsendelse af kuverten på formen YYYY-MM-DD. <Time>Kuvertens_afsendelses_tidspunkt</Time> Time M KuvSendtKl <Time></Time> Time er klokkeslæt for påbegyndelse af afsendelse på formen HH:MM. Hvis dette ikke kan genereres, anvendes "00:00" </Sent> M </Sent> <Identifier>Kuvertens_nummer</Identifier> an..14 M KuvertNr <Identifier></Identifier> Identifier er et afsender genereret løbenummer unikt for denne kuvert afsendt af den pågældende afsender. Afsendersystemer bør sikre at samme nummer aldrig kan benyttes to gange. <AcknowledgementCode>Kuvert_kvitterings_anmodn KVA M KUVKVIT <AcknowledgementCo ing</acknowledgementcode> de></acknowledgeme ntcode> AcknowledgementCode er en kvalifikator, der angiver om positiv kvittering ønskes retur. Negativ sendes under alle omstændigheder uafhængig af værdien af AcknowledgementCode. </Envelope> M </Envelope> <PrescriptionRequest> M <Prescription> <Letter> M <Letter> <Identifier>Brevets_nummer</Identifier> an..14 M BrevNr <Identifier></Identifier> Identifier er et afsender genereret løbenummer, unikt for hvert brev fra denne afsender. Afsendersystemer bør sikre at der aldrig kan sendes samme Identifier fra samme afsender. <VersionCode>Brevets_version</VersionCode> KVA M VERSION <VersionCode></Versi oncode> VersionCode SKAL angives med den versionsbetegnelse, der fremgår af kvalifikatorlisten. Det er vigtigt at VersionCode er korrekt, da modtagersystemer benytter VersionCode til at afgøre hvilken brevtype, modtager kan modtage. VersionCode er unik for den enkelte brevtype. Her anvendes XR6031W 15

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <StatisticalCode>Brevets_statistiknummer</Statistica lcode> an..8 M BrvStat <StatisticalCode></Sta tisticalcode> StatisticalCode udfyldes med TypeCode (f.eks. XDIS01, XRPT02). Statisticalcode er beregnet til statistik formål og må ikke bruges af modtager systemer. BrvStat udfyldes her med XPRE60 <Authorisation> M <Authorisation> <Date>Brevets_godkendelsesdato</Date> Date M BrevDannetTid <Date></Date> Date er dato hvor brevet blev lavet "færdigt" eller "godkendt" hos afsender. Date angives på formatet YYYY-MM-DD. <TimeWithSec>Brevets_godkendelsesKlokkeslet</Ti mewithsec> Time M BrevDannetTid <TimeWithSec></Time WithSec> TimeWithSec er det tidspunkt hvor brevet blev lavet "færdigt" eller "godkendt" hos afsender. TimeWithSec angives på formatet HH:MM:SS sættes til "00:00:00" såfremt klokkeslæt ikke kan angives. </Authorisation> M </Authorisation> <TypeCode>Brevets_brevtype_i_kode</TypeCode> KVA M BRVTYPE <TypeCode></TypeCo TypeCode er kvalifikator for brevets type. Se kvalifikatorliste. de> Her XPRE60 </Letter> M </Letter> <Sender> M <Sender> <EANIdentifier>Afsenders_lokationsnummer</EANId entifier> an..35 M AfsLok <EANIdentifier></EANI EANIdentifier er kuvertafsenders lokationsnummer det vil dentifier> normalt sige afsendende organisation. Såvel positiv som negativ kvittering sendes tilbage til dette nummer. Ved afsendelse fra receptserver er det receptserverens lokationsnummer der anvendes. <Identifier>Afsenders_ID_nummer</Identifier> an..17 M AfsID <Identifier></Identifier> Identifier er den egentlige afsenders ID-nummer. Alle an..17 formater skal kunne håndteres. Identifier skal altid udfyldes validt. F.eks. sygehusafdelingsklassifikationsnummer hvis afsender er et sygehus (stamafdelingen) og ydernummer hvis afsender er en lægepraksis, en speciallæge, en fysioterapeut eller en kiropraktor. Kommunenummer hvis afsender er en kommune. Hvis afsender ikke har afdelingseller ydernummer anvendes ofte et lokationsnummer. Alle modtagere skal kunne modtage alle typer på formen an..17, da der fremover vil blive sendt breve mellem alle typer afsendere og modtagere. Alle modtagere skal kunne modtage og behandle "ukendte" numre og f.eks. kunne håndtere hvis numrene ændres. <IdentifierCode>Afsenders_ID_nummers_type</Ident ifiercode> KVA M KODE <IdentifierCode></Iden tifiercode> IdentifierCode er kvalifikator for det anvendte kode- el. klassifikationssystem - ofte "sygehusafdelingsnummer" hvis afsender er en sygehusafdeling, "ydernummer" hvis sygesikringsyder, "kommunenummer" hvis kommune. 16

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <OrganisationName>Afsenders_organisation</Organi an..70 M Afsenderafd <OrganisationName>< OrganisationName er navnet i tekst på afsendende sationname> /OrganisationName> sygehus, lægehus, kommune o.l. Det anbefales at Sygehusnavn, Lægehusnavn, Fysioterapiklinikken o.l. altid udfyldes i OrganisationName - gerne kort, f.eks. "OUH" i stedet for "Odense Universitets Hospital". Hvis amtet ønskes angivet, skal dette indsættes i OrganisationName, f.eks. "Fyns Amt, OUH". <StreetName>Afsenders_adresse</StreetName> an..70 AfsAdr <StreetName></Street StreetName er afsenders vejnavn og vejnummer. Name> <PostCodeIdentifier>Afsenders_postnummer</PostC an..9 AfsPost <PostCodeIdentifier></ PostCodeIdentifier er afsenders postnummer på primære odeidentifier> PostCodeIdentifier> adresse. <TelephoneSubscriberIdentifier>Afsenders_telefon</ TelephoneSubscriberIdentifier> <PersonInOrganisation> <TitleAndName>Anmoders_titel_og_navn</TitleAndN ame> </PersonInOrganisation> <AnswerTo> <EANIdentifier>Svar_lokationsnummer</EANIdentifie an..35 r> an..25 M AfsTlf <TelephoneSubscriber Identifier></Telephone SubscriberIdentifier> M TelephoneSubscriberIdentifier er afsenders telefonnummer. I forbindelse med afsendelse fra receptserver, er det vigtigt at medsendt telefonnummer er aktuelt telefonnummer fra den organisation, som ønsker receptfornyelsen. an..70 M AfsenderNavn <TitleAndName></Title TitelAndName er stilling og navn på sygeplejerske, AndName> plejehjemsassistent eller anden relevant person, der anmoder om receptfornyelsen. M M SvarLokationsn ummer </AnswerTo> </Sender> M </Sender> <Receiver> M <Receiver> <EANIdentifier>Modtagers_lokationsnummer</EANId entifier> <EANIdentifier></EANI EANIdentifier er den afsendende organisations dentifier> lokationsnummer, hvortil der vil kunne svares direkte med Den gode korrespondance. an..35 M ModtLok <EANIdentifier></EANI EANIdentifier er kuvertmodtagers lokationsnummer. dentifier> 17

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <Identifier>Modtagers_ID_nummer</Identifier> an..17 M ModtagerID <Identifier></Identifier> Identifier er modtagers ID-nummer. Alle an..17 formater skal kunne håndteres. Identifier skal altid udfyldes validt. F.eks. sygehusafdelingsklassifikationsnummer hvis afsender er et sygehus (stamafdelingen) og ydernummer hvis afsender er en lægepraksis, en speciallæge, en fysioterapeut eller en kiropraktor. Kommunenummer hvis afsender er en kommune. Hvis afsender ikke har afdelings- eller ydernummer anvendes ofte et lokationsnummer. Alle modtagere skal kunne modtage alle typer på formen an..17, da der fremover vil blive sendt breve mellem alle typer afsendere og modtagere. Alle modtagere skal kunne modtage og behandle "ukendte" numre og f.eks. kunne håndtere hvis numrene ændres. <IdentifierCode>Modtagers_ID_nummers_type</Iden tifiercode> <OrganisationName>Modtagers_praksisnavn</Organ an..70 isationname> <Issuer> <AuthorisationIdentifier>Udsteders_AutorisationsID</ an..8 AuthorisationIdentifier > <TitleAndName>Udsteders_titel_og_navn</TitleAndN ame> <SpecialityCode>Udstederkode_for_speciallaege_i_b estemt_speciale</specialitycode> KVA M KODE <IdentifierCode></Iden tifiercode> IdentifierCode er kvalifikator for det anvendte kode- el. klassifikationssystem - ofte "sygehusafdelingsnummer" hvis afsender er en sygehusafdeling, "ydernummer" hvis sygesikringsyder, "kommunenummer" hvis kommune. PraksisNavnElle <OrganisationName>< OrganisationName er navnet i tekst på modtagende rsygehusafd /OrganisationName> lægepraksis. Udfyldes som for SenderOrganisationName. <Issuer> UdstederAutorisationsID an..70 UdstederNavn <TitleAndName></Title AndName> an..3 Specialekode <SpecialityCode></Sp ecialitycode> <AuthorisationIdentifier Issuer. AuthorisationIdentifier er receptudsteders ></AuthorisationIdentifi autorisationsid. Er udsendt fra Sundhedsstyrelsen januar er > 2005. AutorisationsID er på 5 karakterer og indeholder både tal og bogstaver. Vil nok sjældent blive anvendt, da anmodningen er til lægepraksis og ikke til den enkelte læge. TitelAndName er stilling og navn på læge eller tandlæge, der forventes at udstede recepten. Vil nok sjældent blive anvendt, da anmodningen er til lægepraksis og ikke til den enkelte læge. SpecialityCode: Specialekode for det relevante speciale ved anvendelse af ekstern kodeliste. Visse lægemidler må kun ordineres af bestemte speciallæger eller læger ansat på en bestemt specialafdeling. I dette segment angives udstederens autorisation som speciallæge ved at angive specialet. Udfyldes kun hvis receptfornyelsen indeholder præparat med udleveringsbestemmelse NBS og AP4NB i LMS02 felt 10. Udleveringsspeciale er angivet i LMS02 felt11. Reference til LMS19. Anvendes ikke pt. i receptfornyelsen. 18

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <Occupation>Udsteders_profession</Occupation> KVA UDSTEDERPR OF <Occupation></Occup ation> Occupation er receptudsteders profession. Læge (laege) eller tandlæge (tandlaege) </Issuer> </Issuer> </Receiver> M </Receiver> <PreferredPharmacy> M <EANIdentifier>Onsket_Apotek_lokationsnummer</E an..35 M OnsketModtLok <EANIdentifier></EANI EANIdentifier er lokationsnummer på det apotek, hvortil ANIdentifier> dentifier> medicinen ønskes bestilt. <OrganisationName>Onsket_Apoteksnavn</Organis an..70 ApoteksNavn <OrganisationName>< OrganisationName er navnet i tekst på det apotek, hvortil ationname> /OrganisationName> medicinen ønskes bestilt. Kan også være receptserver. </PreferredPharmacy> <PatientOrRelative> M <PatientOrRelative> <Type>Patient_eller_patienttilknyttet_person</Type> KVA PART <Type></Type> Type bruges til at identificere hvem receptfornyelsen er til. Patient er den person, som ordinationerne er bestemt for. Patienttilknyttet_person er patientens(et barns) pårørende med sygesikringsbevis, hvis barnet ikke har kendt cprnummer. (bruges sjældent i dag, da alle børn får CPRnummer ved fødslen). <CivilRegistrationNumber>Patientens_CPR_nummer </CivilRegistrationNumber> <PersonSurnameName>Patientens_efternavn</Pers onsurnamename> n10 PatCPR <CivilRegistrationNum ber></civilregistration Number> an..70 M PatEnavn <PersonSurnameNam e></personsurnamen ame> an..70 M PatFnavn <PersonGivenName>< /PersonGivenName> CivilRegistrationNumber er patientens valide CPR-nummer. CPR-nummer sendes uden bindestreg. Hvis et validt cprnummer ikke findes sendes fødselsdato i <PatientDateOfBirth> og køn i <PatientSex> PersonSurnameName er patientens efternavn. <PersonGivenName>Patientens_fornavne</PersonGi venname> PersonGivenName er patientens fornavn(e). Fornavn bør altid medsendes. <StreetName>Patientens_adresse</StreetName> an..70 PatAdr <StreetName></Street StreetName er patientens primære vejnavn og nummer. Name> <DistrictName>Patientens_bynavn</DistrictName> an..35 PatBy <DistrictName></Distri DistrictName er bynavn på den primære adresse. ctname> <PostCodeIdentifier>Patientens_postnummer</PostC an..9 PatPost <PostCodeIdentifier></ PostCodeIdentifier er postnummeret på den primære odeidentifier> PostCodeIdentifier> adresse. <CountryCode>Patientens_landekode</CountryCode an..3 Landekode <CountryCode></Coun CountryCode : ISO3166 3-bogstav kode. Krævet ved > trycode> adresse uden for Danmark. Liste findes på www.medcom.dk under koder/tabeller/ydere. <CountyCode>Patientens_amtsnummer</CountyCod an..9 Amtskode <CountyCode></Count CountyCode 3 cifre f.eks. FYN = 042. Liste findes på e> ycode> www.medcom.dk under koder/tabeller/ydere. Pr. 1. januar 2007 sendes i stedet regionskode. 19

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <PatientDateOfBirth>Patientens_foedselsdag</Patien Date Foedselsdato <PatientDateOfBirth>< PatientDateOfBirth er patientens fødselsdato. Skal tdateofbirth> /PatientDateOfBirth> medsendes, hvis der ikke er medsendt validt CivilRegistrationNumber. <PatientSex>Patientens_koen</PatientSex> KVA PARTKOEN <PatientSex></Patient Sex> PatientSex er patientens køn. Skal medsendes, hvis der ikke er medsendt validt CivilRegistrationNumber. <EmailStatus>Status_paa_email</EmailStatus> KVA EMAILTYPE <EmailStatus></Email Status> EmailStatus angiver om om e-mailadresse er permanent eller midlertidig for denne bestilling. Skal være med, hvis EmailIdentifier sendes efterfølgende <EmailIdentifier></EmailIdentifier> an..35 PartEmail <EmailIdentifier></Em ailidentifier> </PatientOrRelative> </PatientOrRelative> <PrescriptionInformation> M <PrescriptionInformatio n> <SenderComputerSystem>Afsenders_edbsystem</S endercomputersystem> <MessageStatusCode>original_eller_kopi</Message StatusCode> <DrugDatabaseVersion>VersionsID_af_datagrundlag </DrugDatabaseVersion> <DoseDispenseInformation> an..35 M AfsSystem <SenderComputerSyst em></sendercompute rsystem> KVA M MEDDELSESF UNKTION an..35 M VersionsID <DrugDatabaseVersio n></drugdatabasever sion> EmailIdentifier er den e-mailadresse, hvortil e-mail-kvittering ønskes tilsendt. Anvendes ved bestilling via web. Ved receptfornyelse fra receptserver til lægesystem kvitteres til receptserver med Den gode Control og evt andet tekstsvar sendes som Den gode korrespondance til EANIdentifier under <AnswerTo>. SenderComputerSystem er navnet på afsenders edbsystem. Enten navnet på det afsendende omsorgssystem eller receptserver. <MessageStatusCode MessageStatusCode angiver status på meddelelse. Kan ></MessageStatusCod være original eller kopi e> <DoseDispenseInform ation> DrugDatabaseVersion er versionsid for det anvendte datagrundlag. Findes i systemfil felt 09. Format YYYYWW (Årstal og ugenummer for takstens ikrafttrædelsesdato). 20

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <Status>dosisdispensering_eller_seponering</Status > <CopyRequired>Laege_oensker_kopi_af_doseringsk ort</copyrequired> KVA M STATUS <Status></Status> Status angiver at alle præparater på recepten skal dosisdispenseres eller seponeres fra dosisdispenseringen. Der gøres opmærksom på, at præparater, som har været ordineret til almindelig udlevering også skal kunne seponeres. Status dækker hele meddelelsen, hvorfor der ikke både kan ordineres og seponeres i samme meddelelse, ligesom der ikke kan sendes en receptfornyelse med præparater til både dosisdispensering og udlevering af hele pakninger. Præparater, som kan vælges til dosisdispensering, er markeret med D i LMS01 felt 23. BOOLEA N DOSERINGSK ORTKOPI <CopyRequired></Cop yrequired> </DoseDispenseInformation> </DoseDispenseInform ation> vælg mellem max. x 3 ( vælg mellem max. x 3 <OrderInstruction>Ordreinstruktion</OrderInstruction > an..70 eller <DeliveryInformation>Leveringsinformation</DeliveryI an..70 nformation> BemaerkningHe lerecept BemaerkningHe lerecept ) ) <Delivery> <Delivery> <PriorityOfDelivery>Forsendelses_oplysning</Priority OfDelivery> CopyRequired medsendes hvis læge ønsker kopi af doseringskort tilsendt fra apoteket. Anvendes ikke ved receptfornyelsen pt. <OrderInstruction></Or OrderInstruction er fri tekst vedrørende hele recepten. derinstruction> (Svarer til FTX-segment med kvalifikator ORI i edifactreceptfornyelsen). Ved receptfornyelsesstandardens implementering i receptserver er det aftalt, at anmodning om ændringer af pakningsstørrelse anføres i dette fritekstfelt og ikke under DrugTypes PackageSize. Det anbefales derfor under implementeringen af denne standard at tage højde for dette i applikationen, så teksten viser ved udpegning af præparater til genbestilling i læges medicinkort. eller KVA M LEVERING <PriorityOfDelivery></ PriorityOfDelivery> <DeliveryInformation> DeliveryInformation er fri tekst vedrørende hele recepten. </DeliveryInformation> (Svarer til FTX-segment med kvalifikator DEL i edifactrecepten) omhandlende information omkring levering af medicinen. PriorityOfDelivery angiver forsendelsesmåde. "Samme_dag" betyder første ordinære levering, efter omstændighederne med apotekets egen transport eller fx med rutebil. Det betyder IKKE omgående levering, der findes ingen kode for herfor, dette må angives i <OrderInstruction> eller aftales på anden måde. 21

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition vælg mellem ( M vælg mellem ( <StreetName>Leverings_adresse</StreetName> an..70 LeveringsAdres se <StreetName></Street Name> StreetName er her leveringsadresse. Udfyldes kun hvis medicinen skal sendes til anden adresse end angivet under patienten. Ved afsendelse fra receptserver anvendes altid dette felt og ikke PseudoAddress. eller Eller <PseudoAddress>Navn_paa_leverings_adresse</Ps an..70 LeveringsAdres <PseudoAddress></Ps PseudoAddress anvendes ved andet end gadenavn eudoaddress> se eudoaddress> f.eks.plejehjem, håndkøbdsudsalg. (Svarer til FORMATADR = US i edifactrecept) ) ) <PostCodeIdentifier>Postnummer_paa_leveringsadre an..9 LeveringsPostnr <PostCodeIdentifier></ PostCodeIdentifier er postnummer på leveringsadresse. sse</postcodeidentifier> PostCodeIdentifier> <ContactName>Navn_paa_leveringsadresse</Conta an..70 NavnPaaLeveri <ContactName></Cont ContactName er navn på stedfortræder på leveringsadresse ctname> ngsadresse actname> eller navn på leveringsadressen. </Delivery> </Delivery> </PrescriptionInformation> M </PrescriptionInformati on> <Drug> M <Drug> <PackageIdentifier>Varenummer</PackageIdentifier> n..6 M VareNummer <PackageIdentifier></ PackageIdentifier> <NameOfDrug>Praeparatnavn</NameOfDrug> an..35 M PraeparatNavn Dispenseringsfo rm <DosageForm>Laegemiddelform</DosageForm> an..35 M PraeparatNavn Dispenseringsfo rm <NameOfDrug></Nam eofdrug> <DosageForm></Dosa geform> PackageIdentifier. En ordination identificeres unikt vha. en paknings varenummer. (Nordisk varenummer, VNR). En pakning, der ikke har et VNR, kan ikke ordineres via XML. Varenummer findes i LMS02 felt 02. Foranstillede nuller i varenummeret skal altid medsendes. Ved afsendelse af receptfornyelsen via receptserver er det varenummeret fra tidligere ordineret præparat, der medsendes, uanset hvilket varenummer der er udleveret fra apotek. NameOfDrug er præparatnavn. Findes i LMS01 felt 06. Ved lægemidler i udleveringsgruppe AP4 (LMS02 felt 10 ) må der kun være én ordination pr. recept DosageForm er lægemiddelform f.eks tabletter. Findes i LMS01 felt 07 <PackageSize>Paknings_stoerrelse</PackageSize> an..70 M StyrkeEllerPakni <PackageSize></Pack PackageSize angiver pakningsstørrelse på valgt præparat. ngsstoerrelse agesize> Findes i LMS02 felt 06. <DrugStrength>Styrke_paa_praeparat</DrugStrength an..70 StyrkeEllerPakni <DrugStrength></Drug DrugStrength angiver styrken på præparat. Findes i LMS01 > ngsstoerrelse Strength> felt 10. <Importer> <Importer> vælg mellem ( vælg mellem ( 22

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <ShortName>Forkortelse_for_importoer</ShortName an..70 ImportoerNavn <ShortName></ShortN ShortName er forkortelse for parallelimportør. Findes i > ame> LMS09 felt 04 med reference til LMS01 felt 14. ShortName anvendes kun hvis <SubstitutionCode> er medsendt. Hvis ikke parallelimportør kan der sendes "dir imp" i stedet for importørnavn. eller eller <LongName>Importoernavn_hele_navn</LongName > an..70 ImportoerNavn <LongName></LongN ame> ) ) </Importer> </Importer> <NumberOfPackings>Antal_pakninger</NumberOfPa n..15 M AntalPakninger <NumberOfPackings> ckings> </NumberOfPackings> <ReimbursementClause>Tilskud_til_medicin</Reimb ursementclause> <SubstitutionCode>ikke_substitution</SubstitutionCo de> KVA KVA TILSKUDSKOD E <ReimbursementClaus e></reimbursementcl ause> <Dosage> M <Dosage> <DosageCode>Kode_for_doseringstekst</DosageCo an..8 de> <DosageText>Kodebetydning_eller_fri_tekst</Dosag etext> LongName er importørs fulde navn. Findes i LMS09 felt 03 med reference til LMS01 felt 14. LongName anvendes kun hvis <SubstitutionCode> er medsendt. Hvis ikke parallelimportør kan der sendes "direkte forhandlet" i stedet for importørnavn. NumberOfPackings er antallet af pakninger af det valgte varenummer. ReimbursementClause angiver at patienten opfylder forudsætning for tilskud af den valgte slags. Findes i LMS02 felt 13. Reference til LMS17 SUBSTITUTION <SubstitutionCode></S SubstitutionCode angiver at det pågældende præparat ikke ubstitutioncode> må substitueres (Ej S). Kun "ikke_substitution" anvendes pt. Oplysning om hvilke præparater der kan substitueres findes i LMS01 felt 18 med anvigelse af "G". Doseringskode <DosageCode></Dosa gecode> <Period>Behandlingsvarighed_antal_dage_eller_uger </Period> <PeriodUnit>Enhed_for_behandlingsvarighed</Perio KVA dunit> </Dosage> M </Dosage> <Indication> M <Indication> DosageCode er kode for den medsendte dosering. Data findes i LMS27 og LMS28 med reference til DrugID i LMS01. Det er et krav at kode medsendes, når der er valgt en af de anbefalede doseringer. Disse bør altid præsenteres i afsendersystem, så udsteder kan vælge fra liste. an..70 M KodebetydningE <DosageText></Dosag DosageText er kodebetydning af DosageCode. Findes i llerfritext etext> LMS28 felt 3. Eller fri doseringstekst. Fri doseringstekst bør ikke indeholde forkortelser, da teksten overføres til doseringsetiket på pakning til patienten. an..35 Tidsenheder <Period></Period> Period angiver behandlingsvarighed i antal dage eller uger. ENHEDSFORM <PeriodUnit></PeriodU PeriodUnit er enhed for <Period>. Kan være "dag" eller AT nit> "uger" 23

XML Facitliste XR6031W FeltDef M EDIFACT TAG XML TAG XML DataDefinition <Code>Kode_for_indikation</Code> an..17 Indikationskode <Code></Code> Code er kode for den medsendte indikation. Data findes i LMS25 og LMS26 med reference til ATC i LMS01. Det er et krav at kode medsendes, når der er valgt en af de anbefalede indikationer. Disse bør altid præsenteres i afsendersystem, så udsteder kan vælge fra liste. <Text>Kodebetydning_eller_fri_tekst</Text> an.70 M KodebetydningE <Text></Text> llerfritext Text er kodebetydning af Indication.<Code>. Findes i LMS26 felt 2. Eller fri indikationstekst. Fri indikationstekst bør ikke indeholde forkortelser, da teksten overføres til doseringsetiket på pakning til patienten. </Indication> M </Indication> <Iteration> <Iteration> <Number>Antal_genudleveringer</Number> n..15 M AntalGenudl <Number></Number> Number er antal genudleveringer (heltal > 0). Hvis præparatet ikke skal udleveres flere gange skal <Iteration> udelades. <Interval>Antal_tidsenheder_mellem_genudlevering< an..35 M Tidsenheder <Interval></Interval> Interval er antal tidsenheder (heltal > 0) mellem hver /Interval> udlevering fra apotek. <IntervalUnit>Enhed_paa_Antal_tidsenheder</Interva KVA lunit> </Iteration> <SupplementaryInformation>Supplerende_oplysning_ an..70 om_praeparat</supplementaryinformation> <DoseDispensing> <StartDate>Startdato_paa_dosisdispensering</Start Date> <EndDate>Slutdato_paa_dosisdispensering</EndDat e> Date Date M ENHEDSFORM AT <IntervalUnit></Interva IntervalUnit er enhed for <Interval>. Kan være "dag", "uge" lunit> eller "maaned". </Iteration> SupplementaryInformation er fri tekst vedrørende præparat. ation></supplementary F ex. Batchnummer. Information> <DoseDispensing> SupplerendeInfo <SupplementaryInform Praep M DATOSTARTSL <StartDate></StartDat UT e> M DATOSTARTSL <EndDate></EndDate UT > </DoseDispensing> </DoseDispensing> </Drug> M </Drug> </PrescriptionRequest> M </Prescription> </Emessage> M </Emessage> StartDate er første dato, der skal pakkes dosisdispenseret medicin til. Kan kun sendes, hvis <DoseDispenseInformation>.<Status> er medsendt. Ved dosisdispensering medsendes <Iteration> ikke. EndDate er sidste dato, der skal pakkes dosisdispenseret medicin til. Kan kun sendes, hvis <DoseDispenseInformation>.<Status> er medsendt. Ved dosisdispensering medsendes <Iteration> ikke. Slutdato er gældende uanset valgt pakningsstørrelse. 24

XML Kvalifikatorliste Den gode XML recept, XPRE01 VersionCode XLMS016 I Kvalifikatorlisten er angivet XML KvalifikatorNavn/Type her er angivet koden for kvalifikatortypen og de er sorteret alfabetisk. Gyldige XML vaerdier, kvalifikatorværdier angivet med sigende navn. EDIFACT KvalifikatorNavn, således som dette fremgår af Facitlisten i EDIFACT. Gyldige EDIFACT kvalifikatorvaerdier for hver enkelt kvalifikator i henhold standarden. Kun de viste kvalifikatorværdier må benyttes. Modtages en ugyldig kvalifikator, skal denne dog kunne modtages og skal behandles som om der var tale om default kvalifikator. XML KvalifikatorDefinition der angiver betydningen af hver enkelt kvalifikatorværdi i XML. 25

XML Kvalifikatorliste XML KvalifikatorNavn/Type Gyldige XMLvaerdier Default EDIFACT Gyldige XML KvalifikatorDefinition KvalifikatorNavn EDIFACT vaerdier AcknowledgementCodeType minuspositivkvitt Default KUVKVIT 0 Angiver at der ikke ønskes POSITIV XCONTRL kvittering på kuverten. Negativ XCONTRL sendes altid ved "mislykket modtagelse" AcknowledgementCodeType pluspositivkvitt KUVKVIT 1 Angiver at der ønskes POSITIV XCONTRL kvittering ("brevet er modtaget") på applikationsniveau på kuverten. VANS må aldrig sende POSITIV XCONTRL. IdentifierCodeType sygehusafdelingsnummer Default KODE SKS Sygehusafdelingsnummer i officiel SKS-kode. IdentifierCodeType sorkode KODE SOR Sundhedsvæsenetsorganisationsregister IdentifierCodeType ydernummer KODE YNR Ydernummer for praktiserende ydere. IdentifierCodeType lokationsnummer KODE EAN EAN-lokationsnummer IdentifierCodeType kommunenummer KODE KOM Kommunenummer. InvervalUnitType dag ENHEDSFORMAT 802 Dag(e) InvervalUnitType uge ENHEDSFORMAT 803 Uge(r ) InvervalUnitType maaned ENHEDSFORMAT 804 Måned(er) MessageStatusCodeType original Default MEDDELSESFUNKTI 9 Original receptfornyelse: Ny meddelelse ON MessageStatusCodeType kopi MEDDELSESFUNKTI 7 Kopi af tidligere fremsendt receptfornyelse ON OccupationType laege Default UDSTEDERPROF PHY Læge OccupationType tandlaege UDSTEDERPROF DEN Tandlæge PatientSexType hankoen PARTKOEN 1 Hankøn PatientSexType hunkoen PARTKOEN 2 Hunkøn PeriodUnitType dag ENHEDSFORMAT 802 Dag(e) PeriodUnitType uge ENHEDSFORMAT 803 Uge(r ) PriorityOfDelivery send_til_anden_adresse_samme_dag LEVERING OAD Send til anden adresse samme dag/snarest PriorityOfDelivery send_til_anden_adresse_pr_post LEVERING OAM Send til anden adresse pr. post PriorityOfDelivery send_til_patientadresse_pr_post LEVERING PAD Send til patientadresse samme dag/snarest PriorityOfDelivery send_til_patientadresse_samme_dag LEVERING PAM Send til patientadresse pr. post 26

XML KvalifikatorNavn/Type Gyldige XMLvaerdier Default EDIFACT Gyldige XML KvalifikatorDefinition KvalifikatorNavn EDIFACT vaerdier ReimbursementClauseType klausulbetingelse_opfyldt TILSKUDSKODE CLA Klausulbetingelse opfyldt. Svarende til værdierne i LMS17: CARD, EPIL, OSREU, PARK, PERN, SPAST og SPERI. ReimbursementClauseType bevilling_fra_laegemiddelstyrelsen TILSKUDSKODE SPG Bevilling fra Lægemiddelstyrelsen StatusType dosisispensering STATUS DOS Dosisdispensering StatusType seponeres STATUS SEP Seponering SubstitutionCodeType ikke_substitution Default SUBSTITUTION NS Ikke substitution TypeCodeType XPRE60 Default BRVTYPE PRE60 XML receptfornyelse TypeType patient Default PART PAT Patient TypeType patienttilknyttet_person PART PAS Patienttilknyttet person VersionCodeType XR6031W VERSION R6031W XR6031W er versionsnummer for "den gode" XML receptfornyelse. Værdier angivet med kursiv er forklaringer til anvendelsen ved konvertering mellem EDIFACT/XML Anvendes hvis der er medsendt dato under Dosedispensing Anvendes hvis der er medsendt dato under Dosedispensing Default DATOSTARTSLUT 90 Starttidspunkt for dosisdispensering DATOSTARTSLUT 91 Sluttidspunkt for dosisdispensering Default MEDPRE MEDPRE MEDPRE angiver at EDI-meddelelsen er et subset af den europæiske pre-standard "MEDPRE". Default UNOC UNOC UNOC betyder at brevet sendes i tegnsættet ISO 8859-1. Dette tegnsæt SKAL altid benyttes. FORSIKRINGSTYPE DK Sygeforsikring Danmark FORSIKRINGSTYPE MK Medicinkort Default DAEKNINGSTYPE NA Dækningstype ikke relevant INSTRUKTION AUP Til eget brug Default INSTRUKTION UIS Til brug i praksis TEKSTEMNE DEL Leveringsinformation 27

XML KvalifikatorNavn/Type Gyldige XMLvaerdier Default EDIFACT Gyldige XML KvalifikatorDefinition KvalifikatorNavn EDIFACT vaerdier Default TEKSTEMNE ORI Ordreinstruktion Default IDENTITETSNR CPR CPR-nummer Default FORMATNAVN SCC Efternavn fulgt af fornavne, adskilt af komma FORMATNAVN US Ustruktureret navn DOSERINGSKORTK COP Kopi af doseringskort ønskes OPI FORMATLEVERAND AB Forkortet navn OER FORMATLEVERAND US Ustruktureret navn OER TEXTTYPE 5 Doseringsanvisning TEXTTYPE 9 Doseringsanvisning, understreget FORMATADR 1 Gade-/vejnavn efterfulgt af nummer, etage etc. FORMATADR US Ustruktureret adresse Default CPRNR CPR Medsendes hvis UdstederCpr er udfyldt. Er mandatory, hvis ordineret præparat er kopieringspligtigt VAREKODE DDP Dispenseringsform VAREKODE DNM Præparatnavn MAALEDIMENSION CT Pakningsstørrelse MAALEDIMENSION S Styrke MAALEKVALIFIKATO AAU Pakning R MAALEKVALIFIKATO DEN Densitet (styrke) R 28

XML KvalifikatorNavn/Type Gyldige XMLvaerdier Default EDIFACT Gyldige XML KvalifikatorDefinition KvalifikatorNavn EDIFACT vaerdier Blank, bruges ikke ved XML KODE "KODE" udfyldes af og til ikke hvis "KODEORG" er "9" for lokationsnummer. Bruges hvis kode er blank KODEORG 9 9 angiver EAN (lokationsnummer), f.eks. anden part, der anvender lokationsnummer. Bruges hvis kode er KOM KODEORG IM Indenrigsministeriet, hvis KODE er kommunenummer. Bruges hvis kode er SKS Default KODEORG SST SST angiver at kodeansvarlige er Sundhedsstyrelsen. Bruges hvis kode er USP KODEORG "KODEORG" udfyldes ikke hvis "KODE" er "USP" for uspecificeret, lokal kode. Bruges hvis kode er YNR KODEORG SFU SFU angiver at kodeansvarlige er Sygesikringens Forhandlingsudvalg. Bruges hvis kode er LDD KODEORG LMS Lægemiddelstyrelsen Bruges ikke KODEORG NCD Anden kodeansvarlig organisation. Er en del af xml-strukturen og ikke længere en kvalifikator Er en del af xml-strukturen og ikke længere en kvalifikator Er en del af xml-strukturen og ikke længere en kvalifikator Er en del af xml-strukturen og ikke længere en kvalifikator Er en del af xml-strukturen og ikke længere en kvalifikator Er en del af xml-strukturen og ikke længere en kvalifikator Er en del af xml-strukturen og ikke længere en kvalifikator Er en del af xml-strukturen og ikke længere en kvalifikator Er en del af xml-strukturen og ikke længere en kvalifikator <FixedFont> Default FORMAT F00 Ikke-proportional skrift. Svarer til eneste mulige formatering i modtagersystemer i dag. Teksten bør vises af modtager i ikke-proportional skrift (f.eks. Courier) med en liniebredde på 70 tegn, da teksten kan indeholde tabeller eller indrykninger og disse vil blive "vredet" ved anvendelse af proportional skrift. Al tekst vil som udgangspunkt blive vist "venstrestillet". <FixedFont><Right> FORMAT F0H Ikke-proportional skrift. Højrestillet. <FixedFont><Center> FORMAT F0M Ikke-proportional skrift. Midtstillet. <FixedFont><Bold> FORMAT FF0 Ikke-proportional skrift. Fed. <FixedFont><Underline> FORMAT FU0 Ikke-proportional skrift. Understreget. <FixedFont><Italic> FORMAT FK0 Ikke-proportional skrift. Kursiv. <Font> FORMAT P00 Proportional skrift. Afsendersystemer bør benytte denne type (under forudsætning af at teksten ikke indeholder tabeller eller indrykninger). <Right> FORMAT P0H Proportional skrift. Højrestillet. <Center> FORMAT P0M Proportional skrift. Midtstillet. 29

XML KvalifikatorNavn/Type Gyldige XMLvaerdier Default EDIFACT Gyldige XML KvalifikatorDefinition KvalifikatorNavn EDIFACT vaerdier Er en del af xml-strukturen og ikke <Bold> FORMAT PF0 Proportional skrift. Fed. længere en kvalifikator Er en del af xml-strukturen og ikke <Underline> FORMAT PU0 Proportional skrift. Understreget. længere en kvalifikator Er en del af xml-strukturen og ikke <Italic> FORMAT PK0 Proportional skrift. Kursiv. længere en kvalifikator Hænger sammen med FORMAT Default TEXTNR NC NC anvendes normalt altid i dag. 30

Testeksempel Alle opdaterede testeksempler findes på MedComs hjemmeside: http://www.medcom.dk/ under fanen Standarder under de respektive meddelelsesstandarder. 31

Bilag 1 Databeskrivelse for LMS-takst pr. 1.april 2005 Nyeste version kan findes på Lægemiddelstyrelsens FTP-server. Adgang hertil fås ved henvendelse til Lægemiddelstyrelsen. DATABESKRIVELSE FOR LMS-TAKST LMS / 20050401 Tab.navn Indhold Type Antal Fra - til Bemærkninger Felt nr. Kar. LMS01 Grunddata, Lægemiddel 01 Drugid N 11 1-11 02 Varetype AN 2 12-13 Udfyldt med SP (Specialiteter) 03 Varedeltype AN 2 14-15 Udfyldt med LM (lægemiddel, reg.) 04 Alfabet. Sekvensplads AN 9 16-24 05 Spec. Nummer N 5 25-29 D.sp.nr. (decentrale) - Alm. nr (centrale) 06 Navn AN 30 30-59 Evt. forkortet 07 Lægemiddelform, tekst AN 20 60-79 Evt. forkortet 08 Form-kode AN 7 80-86 Ref. t. LMS22, felt 01 09 Kode for yderligere form-oplysn. AN 7 87-93 Feltet er tomt pt. 10 Styrke (klar tekst) AN 20 94-113 11 Styrke, numerisk N 10 114-123 12 Styrke, enhed AN 3 124-126 Ref. t. LMS15, enhedstype 3 13 MT-indehaver N 6 127-132 Ref. t. LMS09 14 Repræsentant (distributør) N 6 133-138 Ref. t. LMS09 15 ATC AN 8 139-146 Ref. t. LMS12 16 Administrationsvej AN 8 147-154 4 x 2 kar. (Ref. t. LMS11) 17 Trafikadvarsel AN 1 155 2 muligh.: J eller blank 18 Substitution AN 1 156 2 muligh.: G eller blank 19 Blank AN 1 157 20 Blank AN 1 158 32

21 Blank AN 1 159 22 Lægemidlets substitutionsgruppe AN 4 160-163 Substitutionsgruppenr. på Drugid-niveau 23 Egnet til dosisdispensering AN 1 164 2 muligh.: D eller blank 24 Dato for afregistr. af lægemiddel AN 8 165-172 Format: ååååmmdd Total record-længde: 172 LMS02 Grunddata, Pakning 01 Drugid N 11 1-11 Ref. t. LMS01, felt 01 02 Varenummer N 6 12-17 03 Alfabet. sekvensnr. N 3 18-20 04 Varenummer for delpakning N 6 21-26 Udfyldes for multipakningen 05 Antal delpakninger N 3 27-29 Antal delpakn. i stor/multipakning 06 Pakningsstørrelse, klartekst AN 30 30-59 07 Pakningsstørrelse, numerisk N 8 60-67 Brutto 08 Pakningsstørrelse, enhed AN 2 68-69 Ref. t. LMS15, enhedstype 4 09 Emballagetype AN 4 70-73 Ref. t. LMS14 10 Udleveringsbestemmelse AN 5 74-78 Ref. t. LMS18 11 Udlevering, speciale AN 5 79-83 Ref. t. LMS19 12 Sygesikringskode AN 2 84-85 Ref. t. LMS16 13 Klausul for sygesikringstilskud AN 5 86-90 Ref. t. LMS17 14 Antal DDD pr. pakning N 9 91-99 15 Opbevaringstid, numerisk N 2 100-101 Hos distributør 16 Opbevaringstid, enhed AN 1 102 Ref. t. LMS15, enhedstype 1 17 Opbevaringsbetingelser AN 1 103 Ref. t. LMS20 18 Oprettelsesdato N 8 104-111 Format: ååååmmdd 19 Dato for seneste prisændring N 8 112-119 Format: ååååmmdd 20 Udgået dato N 8 120-127 Format: ååååmmdd 21 Beregningskode AIP -> reg.pris AN 1 128 Ref. t. LMS13 22 Pakning optaget i tilskudsgruppe AN 1 129 2 muligh.: F eller blank 23 Færdigfremstillingsgebyr AN 1 130 2 muligh.: B eller blank 24 Blank AN 1 131 25 Pakningsdistributør N 6 132-137 Ref. t. LMS09 Total record-længde 137 LMS03 Grunddata, Priser Alle priser er i øre med foranstillede nuller 01 Varenummer N 6 1-6 Ref. t. LMS02, felt 02 33

02 AIP N 9 7-15 Apotekets indkøbspris 03 Registerpris N 9 16-24 Beregning i prisbekendtg., 2, stk. 1, 9 og 10 04 Ekspeditionens saml. pris (ESP) N 9 25-33 Reg.pris + evt. receptur- og færdigtilb.gebyr 05 Tom N 9 34-42 Udfyldt med 000000000 06 Tom N 9 43-51 Udfyldt med 000000000 07 Tilskudspris (TSP) N 9 52-60 Tilskudspris (human) eller 000000000 (veterinær) 08 Leverancepris til hospitaler N 9 61-69 Blodprod. o.l. (Udfyldt med 000000000) 09 Leverancepris (dyrlæger) N 9 70-78 Beregning i prisbekendtgørelsen, 2, stk. 6 10 Ikke-tilskudsberettiget del N 9 79-87 Fx utensilie eller del af kombinationspakn. 11 Tom N 9 88-96 Udfyldt med 000000000 Total record-længde 96 LMS04 Substitution 01 Substitutionsgruppenummer N 4 1-4 Substitutionsgruppe for pakningen 02 Receptens varenummer N 6 5-10 Varenr. hvis substitutionsmuligheder skal findes 03 Numerisk pakningsstørrelse N 8 11-18 Felt 07 i LMS02 04 Prod. alfabetiske sekvensplads AN 9 19-27 Felt 04 i LMS01 05 Blank 7 28-34 06 Substitutionskode for pakning AN 1 35 Værdier=A-B-C (for varenr. i felt 02) 07 Billigste varenummer N 6 36-41 Henvisning til billigste pakning 08 Blank 6 42-47 Total record-længde 47 LMS05 Substitution af lægemidler uden fast pris 01 Substitutionsgruppenummer N 4 1-4 Substitutionsgruppe for pakningen 02 Varenummer N 6 5-10 Total record-længde 10 LMS07 Tilskudsprisgrupper (pakningsniveau) 01 Tilskudspris-gruppe N 4 1-4 02 Varenummer N 6 5-10 Ref. t. LMS02 03 Blank 1 11 Total record-længde 11 LMS09 Firmaliste 34

01 Firmanummer N 6 1-6 Ref. t. LMS01, felt 13-14 02 Firmamærke (kort) AN 20 7-26 P.t. tomt 03 Firmamærke, langt navn AN 32 27-58 04 Parallelimportør-kode AN 2 59-60 Total record-længde 60 LMS10 Udgåede navne 01 Drugid N 11 1-11 Ref. t. LMS01 02 Dato for ændringen N 8 12-19 03 Tidligere navn AN 50 20-69 Total record-længde 69 LMS11 Administrationsvej 01 Kode AN 2 1-2 Ref. t. LMS01, felt 16 02 Kort tekst AN 10 3-12 03 Tekst AN 50 13-62 04 Blank 1 63 Total record-længde 63 LMS12 ATC-koder og tekst 01 ATC-niveau 1 AN 2 1-2 Felt 01-05 ref. t. LMS01, felt 15 02 ATC-niveau 2 AN 2 3-4 03 ATC-niveau 3 AN 1 5 04 ATC-niveau 4 AN 1 6 05 ATC-niveau 5 AN 2 7-8 06 Tekst AN 72 9-80 07 Blank AN 72 81-152 Total record-længde 152 LMS13 Beregningsregler 01 Kode AN 1 1 Ref. t. LMS02, felt 21 02 Tekst AN 50 2-51 03 Blank 1 52 Total record-længde 52 LMS14 Emballagetype-koder 35