L XPRE01 Den gode XML recept Prescription 01.06.2006 Revideret 01.09.2009 Sundhedsfaglige anbefalinger og XML Facitliste for XML recept VersionCode: XLMS016 TypeCode: XPRE01 1
2
Indholdsfortegnelse: Forord... 3 Rettelser... 3 Baggrund... 5 Afsnit A: Sundhedsfaglige anbefalinger... 7 1. Anvendelse... 8 2. Krav og anbefalinger... 9 Afsnit B: XML Facitliste... 17 XML Facitliste... 18 XML Kvalifikatorliste... 28 XML Testeksempel... 36 Bilag 1 Printtabel for receptblanket... 37 Bilag 2 Databeskrivelse for LMS-takst pr. 1. april 2005... 43 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. Rettelser 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. 1. juni 2006: Rettelser udført i schemaet: Streetname elementet under Sender, PatientOrRelative og PriorityOfDelivery, er blevet rettet til at kunne indeholde strenge med op til og med 70 tegn frem for 35 tidligere. Rettelser til dokumentation: Streetname elementet under Sender, PatientOrRelative og PriorityOfDelivery, kan indeholde strenge med op til og med 70 tegn. IdentifierCode elementet under Sender er obligatorisk. TelefoneSubscriber elementet under Sender er obligatorisk. OrganisationName elementet under Sender kan indeholde strenge med op til og med 70 tegn. 4
Baggrund EDI-transmission af recepter har allerede en lang tradition i Danmark, hvor den nationalt udviklede RECEPT-meddelelse er benyttet siden 1990. I 1998 blev Sundhedsstyrelsen, Danmarks Apotekerforening og Praktiserende Lægers Organisation enige om, via Sundhedsstyrelsen, at implementere en ny receptmeddelelse baseret på MEDPRE. I forbindelse med denne proces har en arbejdsgruppe formuleret krav til implementering af MEDPRE, mens en anden arbejdsgruppe har beskæftiget sig med koordinering af de eksisterende medicindatabaser og evt. justeringer af receptbekendtgørelsen. Seneste rettelser til recepten er fra oktober 2005 omhandlende autorisationsid. Disse er nu implementeret i stort set alle lægesystemer. Implementeringen kan ses på www.medcom.dk under Hvem kan hvad nu. XML-recepten er udarbejdet i forbindelse med MedComs XML EPJ kommunikations projekt Udarbejdelsen af XML recepten er baseret på det indhold der i dag findes i recepten, og det er ved udarbejdelsen af XML versionen sikret at der fremover automatisk kan konverteres til en recept der er baseret på gældende EDIFACT standard og version. Denne konvertering kan testes på MedComs hjemmeside: http://web.health-telematics.dk/xmledi I efteråret 1999 er der foretaget en opfølgning af implementeringen af MEDPRE på baggrund af opsamling af en del fejlbehæftede/mangelfulde recepter, både i Lægemiddelstyrelsen, Sundhedsstyrelsen, Apotekerforeningen og MedCom. Sundhedsstyrelsens MEDPRE opsamlingsgruppe bestod af: Jesper Theilgaard, almen praksis, konsulent, Kolding Lars Harild, Lægemiddelstyrelsen Susann Duedal Pedersen, Sundhedsstyrelsen Karin Demkjær, MedCom I maj 2002 overtog Lægemiddelstyrelsen ansvaret for den elektroniske recept. 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 vist et eksempel på et typisk papirbrev af den pågældende type. Hensigten med disse to beskrivelser er at give udenforstående (f.eks. programmører) en overordnet forståelse af hvad kommunikationen indebærer i praksis. Bilag Printvejledning Databeskrivelse LMS-takst Afsnit B Indeholder den tekniske dokumentation af nærværende XML standard 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 XML standard. 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. Eksempel Et fuldt XML eksempel på de i afsnit A viste papirrecepter er vist her. Supplerende testeksempler kan altid findes på MedComs hjemmeside 6
Afsnit A Sundhedsfaglige anbefalinger for XML recepten XPRE01 7
1. Anvendelse XLMS016 anvendes til følgende funktioner: Der kan ikke via XML-recept gives anvisning om markering af pakning med advarselssymbol Forsendelse af recept Indeholdende en eller flere ordinationer af varer med varenummer optaget i Lægemiddelstyrelsens elektroniske medicintakst eller frihandelsvarer med varenummer Fra én læge (praktiserende læge/speciallæge med ydernummer eller sygehusansat læge) eller én tandlæge (med ydernummer) Til ét apotek Udstedt til én patient (menneske) eller eget brug (læger, tandlæger) eller brug i praksis Med evt. oplysninger om levering på anden måde end afhentning på apoteket. Der er en række funktioner, som hermed er undtaget: Medicinrekvisitioner fra f.eks. jordemødre, sygeplejersker og redere. Recepter fra udstedere, der ikke har ydernummer, autorisationsnummer eller er ansat på hospitalsafdeling med sygehusklassifikation. Ordination af lægemidler, mærkevarer eller andre produkter, der ikke har varenummer i det fælles datagrundlag. Dette gælder bl.a. magistrelle ordinationer. Dyrlægeordinationer, som ikke længere er tilladt (pr. 1/3 2000). Andre begrænsninger, som skyldes bestemmelser i receptbekendtgørelsen: Der kan ikke via XML-recept angives, at den ordinerede mængde ikke må fraviges Der kan ikke via XML-recept angives understregning af indikation Meddelelsesstruktur og indhold: Meddelelsen består af følgende hoveddele: Information om involverede partnere i sundhedsvæsenet Information om selve recepten Information om patienten (menneske) Information om ordinationer Information om genudlevering Information om brugsanvisning Information om levering Det fælles datagrundlag: En forudsætning for korrekt brug er at implementere et datagrundlag med automatisk opdatering hver 14. dag. Datagrundlaget kan hentes på Lægemiddelstyrelsens FTP-server (ftp.dkma.dk). Der er henvisning til de aktuelle felter i datadefinitionen i afsnit B. Databeskrivelse af LMS-takst er indsat sidst i dokumentationen som bilag. Datagrundlaget kan også hentes hos Lægeforeningens Forlag som ascii-fil med tilhørende feltdefinition. Ved at benytte LMStaksten har man nøjagtig samme datagrundlag, som det apotekerne benytter. Det er vigtigt, at afsendersystem medsender kodet dosering og indikation, hvor dette er muligt i forhold til den pågældende ordination. Disse anvendes videre direkte på doseringsetiket til patient og overførsel af data til Medicinprofilen, hvor de bl.a. indgår i funktionen med compliancekontrol. 8
2. Krav og anbefalinger De krav og anbefalinger, der findes til de elektroniske recepter, har til formål at sikre en smidig og korrekt kommunikation mellem receptudsteder og apotek, således at lægens intentioner ved receptudstedelsen når fuldstændigt og uændret frem til apotekets ekspedition. Derfor beskrives specifikationer vedr. datagrundlag for og funktioner til udførelse, afgivelse og lagring af ordinationer i lægelige edb-systemer, som skal være eller bør være opfyldt, for at systemet kan betegnes som fagligt, juridisk og sikkerhedsmæssigt fyldestgørende. Kravene er altså specielt opstillet mhp. at opnå ensartet og fejlfri funktion af xml-recepter. Opdateringsterminer og -metode Lægesystemernes medicindatabaser skal opdateres ved hjælp af ny version af datagrundlaget hver anden mandag, når de nye priser træder i kraft. Datagrundlaget vil være klar fra Lægemiddelstyrelsen fredag kl. 18. Systemhusene skal formidle en løsning, så opdatering kan foregå mellem fredag kl. 18 og mandag kl. 8, så vidt muligt automatisk. Ved opdateringen overføres den ikrafttrædelsesdato, som datagrundlaget er udstyret med. Apotekerne modtager også denne identifikation ved opdatering af deres database, og de er derfor i stand til på et sikkert grundlag at foretage automatisk verifikation af varenummer vs. præparat/pakning og koder for brugsanvisning vs. tekster, når datoerne er ens. Udover egentlige krav og anbefalinger er der anført en del oplysninger om baggrund, som kan være en støtte for systemerne. Autenticitet Indholdet i alle essentielle felter i datagrundlaget skal overføres i uændret form til applikationens database. Dog må, - og typografiske hjælpetegn fjernes og felter concateneres, hvis funktionaliteten ikke forringes. Tegnsættet i databasen skal understøtte samtlige tegn i datagrundlaget. I praksis betyder dette, at der skal benyttes ISO 8859-1. Følgende tegn giver erfaringsmæssigt problemer og må derfor ikke anvendes: Tegn Code Page 865 (decimalt) $ 36 @ 64 [ 91 \ 92 ] 93 { 123 } 125 124 156 ½ 171 ¼ 172 175 Tegn, der normalt ikke findes på tastaturer: Semigrafik (CP 865 decimalt 169, 170, 176-223, 244, 245, 251, 254, 255) og styretegn (CP 865 decimalt 1-31) må heller ikke anvendes. Systemhus eller bruger må ikke oprette præparater eller pakninger, der ikke findes i datagrundlaget. Systemhuset må fjerne eller fjerne adgangen til præparater/pakninger, der ikke er relevante i praksis, eksempelvis SAD-præparater, præparater med begrænset udlevering (BEGR), infusionsvæsker o.l. 9
Ordinationsprocessen Valg af præparat Et nyt præparat bør kunne vælges ved indtastning af præparatnavn eller en del af præparatnavn. Ved manglende entydighed bør de præparater/grupper vises, der opfylder indtastningskriteriet, så det ønskede kan vælges. Et præparat bør kunne genordineres ved udpegning eller markering med tastetryk/nummer i en medicinoversigt. Ved genordinering skal alle oplysninger vedr. ordinationen kunne inspiceres, og de brugertilgængelige oplysninger skal kunne modificeres før accept, hvis det ønskes. Hvis den genordinerede pakning er udgået, skal det aktuelle udvalg af pakninger vises, så der kan vælges et alternativt lægemiddel. Udgåede pakninger må ikke kunne ordineres, heller ikke ved genordination, hvor det skal checkes, at pakningen stadig er gyldig. Valg af alternativt præparat/omvendt substitution Hvis en bestemt pakning er udvalgt, skal applikationen understøtte valg af synonympræparater eller synonympakninger. Der findes i datagrundlaget en markering på hver pakning: A billigst, B ikke billigst, men skal ikke substitueres eller C der skal substitueres. Denne markering skal kunne vises på iøjnefaldende måde (men ikke nødvendigvis med A, B eller C), og de relevante substitutioner skal kunne vises. Der skal kunne vises en angivelse af relative prisforhold, så det billigste eller et andet kan vælges. Sorteringsrækkefølgen ved visningen skal - ved samme relative pris - være randomiseret. Der må ikke være fremhævning af præparater fra enkeltfirmaer og ingen positiv/negativ særbehandling af parallelimportører henholdsvis originalfirmaer. Der skal være mulighed for at fravælgelse af substitution, så der bliver angivet Ej S på recepten. Adgang til prisoplysninger og udleveringsbestemmelser Det bør være muligt for en given pakning at se relevante priser. Det gælder såvel pakningspris som enhedspris eller pris per DDD. Det skal være muligt for en given dispenseringsform eller pakning at se udleveringsbestemmelser, tilskud og evt. tilskudsklausuler. Dosisdispensering Ifølge bekendtgørelse nr. 80 af 5. februar 2003 om dosisdispensering af lægemidler er det muligt for lægen at ordinere lægemidler til dosisdispensering. Derfor anbefales det, at lægen har mulighed for at se, hvilke præparater, der er omfattet af denne ordning. Den oplysning fremgår af Datagrundlaget, LMS 01, felt 23, Egnet til dosisdispensering, position 164, 2 muligheder D eller blank. Uddrag af receptbekendtgørelsen: 7. En recept på et lægemiddel, hvortil der er udstedt markedsføringstilladelse, skal indeholde lægemidlets navn, lægemiddelform, styrke (hvis lægemidlet findes i flere styrker) og mængde. Styrke og mængde skal anføres entydigt og på en sådan måde, at ændringer ikke kan foretages. Receptudstederen kan ved at understrege mængden tilkendegive, at denne ikke må fraviges, jf. 30. Stk. 2 En recept på et lægemiddel, som skal dosisdispenseres, skal indeholde de i 7, stk. 1, 1. pkt. nævnte oplysninger og påtegningen dosisdispensering. Mængden kan angives som en tidsperiode på højest 2 år, hvori der løbende skal dosisdispenseres. Har receptudstederen anført kopi ønskes, skal apoteket fremsende kopi af doseringskort til receptudstederen. 10
Stk. 3. Hvis udlevering af et lægemiddel, der dosisdispenseres, skal bringes til ophør, skal recepten indeholde de i stk. 2 nævnte oplysninger samt påtegningen seponeres. Med mindre andet er anført på recepten, effektueres seponeringen med virkning fra førstkommende udlevering. I afsendersystem vælges som hidtil et givet varenummer (pakningsstørrelse). Denne mængde overrules af en start- og slutdato, hvis dosisdispensering er valgt. Ved seponering medsendes kun slutdato. I praksis kan denne seponering først træde i kraft ved næste pakning til patient. Det er ikke relevant med start-/slutdato samtidig med iteration, da mængden kan gives op til en periode på 2 år (En recept er kun gyldig i 2 år). Egen læge kan angive, at det ønskes, at apoteket skal sende en kopi af det totale doseringskort på patienten. Dette kan indeholde ordinationer fra andre læger end egen læge. På nuværende tidspunkt vil dette være på papir. (Der er udarbejdet en XMLstandard på doseringskortmeddelelsen i forbindelse med dosisdispenseringsprojektet, men der er p.t. ikke aftalt pilotforsøg med denne meddelelse til lægepraksis). Doseringstekst/indikation Datagrundlaget indeholder for hver DrugID af et præparat koder med tilhørende kodebetydning for doseringstekst og indikation. Doseringstekster og indikationer er i overensstemmelse med de godkendte doseringer og indikationer for dispenseringsformen. Formålet med disse tekster med tilhørende koder er dels at gøre det lettere for brugerne at oprette ordinationer, idet man blot kan vælge en af de allerede eksisterende tekster i stedet for selv at skrive den, dels at kunne automatisere receptkontrollen på apoteket. Koderne overføres af apoteket til Medicinprofilen. Systemet skal understøtte muligheden for at vælge mellem forslagene til doseringstekst og forslagene til indikation. Systemhuset eller brugerne må selv indlægge andre tekstforslag for en given dispenseringsform, men evt. anvendt kode skal detekteres som lokalt oprettet og fjernes før forsendelse. Hvis der ikke er et forslag, der passer til den konkrete ordination, skal brugeren kunne indtaste en fri tekst for dosering og indikation. Systemet skal checke og advare, hvis ikke-tilladte tegn er anvendt (se ovenfor). Kodeteksterne skal overføres direkte til etiketten, som apoteket sætter på lægemidlet. Brugerne skal altså være klar over, at frie tekster også bliver overført direkte til etiketten. Doseringstekster findes i datagrundlaget i en lang form og i en kort form. Når kodede tekster sendes i xml-recepter, skal der altid sendes både kode og kodebetydning i lang form. Apoteket skal altid udskrive den lange form. Frie tekster må ikke sendes i forkortet form, selv om det er muligt at finde en sådan ved opslag i den pågældende tabel Tilføjelse af hjælpeoplysninger (iteration, tilskudsklausulering, bemærkning m.v.) Iteration: Der skal være adgang til at indtaste iteration, men kun hvor udleveringsbestemmelserne giver mulighed herfor. Det indtastede skal på entydig måde kunne omsættes til 3 komponenter: Antal udleveringer, antal intervaller mellem udlevering og enhedsinterval (dage, uger, måneder). Tilskudsklausulering: Der skal være adgang til at indtaste koder for disse oplysninger for præparater, hvor dette er relevant, men ikke for andre. 11
Bemærkning: Der skal ved afslutning af en eller flere ordinationer være adgang til at indtaste en bemærkning gældende for samtlige udførte ordinationer. Ved udskrift af recepter eller forsendelse af xml-recepter skal ordinationer med forskellig bemærkning udskrives på hver sin recept (bemærkning anføres én gang pr. recept) og indeholdes i hver sin meddelelse. XML-formatet tillader desuden, at der er en bemærkning til den enkelte ordination (beregnet til fx batchnummer for vaccine). Der bør være adgang til indtastning af en sådan oplysning. Forsendelse: Der skal ved afslutning af en eller flere ordinationer være adgang til at indtaste en kode for forsendelse til patientens adresse gældende for samtlige ordinationer. Ved udskrift af recepter eller forsendelse af XML-recepter skal ordinationer med denne kode/ingen kode udskrives på hver sin recept (tekst vedr. forsendelse anføres én gang pr. recept) og indeholdes i hver sin meddelelse. Lagring og præsentation Lagring af ordination Lagring af ordination omfatter alle oplysninger, der er nødvendige for entydigt at identificere det ordinerede. Det gælder følgende: Patientidentifikation, ordinationsdato/tid, varenummer, kode for doseringstekst og indikation, antal pakninger, iterationer, antal intervaller og kode for enhedsinterval, samt klar tekst for dispenseringsform, præparatnavn, pakningsindhold, doseringstekst og indikation. Udover dette er følgende hensigtsmæssigt, specielt ved genordination: Kode for særlige tilskud, kode for Ej S, kode for specifik leverandør, kode for fast medicin og beregnet dato for opbrugt ordination (slutdato). Datagrundlaget indeholder data, der muliggør beregning af, hvornår en ordination vil være opbrugt. Disse data er knyttet til standarddoseringsteksterne. Det er muligt ved hjælp af en relativt enkel algoritme at analysere frie doseringstekster mhp. beregning af slutdato. Præsentation i oversigt Der skal være let adgang til en oversigt over patientens ordinationer i et eller flere formater (efter status, ATC-nummer, alfabetisk, dato). Der skal kunne vises en oversigt med sidste ordination af hvert præparat i en bestemt dispenseringsform. For det enkelte præparat i denne oversigt skal kunne vises samtlige tidligere ordinationer med dato, udleveret mængde, doseringstekst og indikation. Den enkelte ordination skal indeholde følgende i oversigten: Ordinationsdato/slutdato, dispenseringsform (kort form), præparatnavn, styrke, udleveret mængde, doseringstekst, indikation. Det er hensigtsmæssigt, at det med et tegn markeres, at det pågældende præparat er ordineret dags dato, og at der gives advarsel, hvis præparatet genordineres samme dag. Det er ofte nødvendigt at afkorte eller omforme (kode) et eller flere elementer i oversigten. Der skal være let adgang til at se fulde data, hvor der er sket afkortning/kodning. Der bør være mulighed for beregning og præsentation af data vedr. forbrug mhp. identifikation af overforbrug/manglende compliance. Sletning af ordination må ikke kunne ske, hvis ordinationen er afgivet som XML-recept. 12
Oprettelse/ændring af ordination uden udlevering Der bør være adgang til at oprette en ordination og ændre en ordination (fx doseringstekst eller pakningsstørrelse mhp. næste udlevering) uden udlevering, fx efter udskrivelse fra sygehus, hvor nye præparater er ordineret, eller ved telefonkonsultation, hvor den fortsatte dosering ændres. Slutdatoen bør genberegnes ud fra en ændret doseringstekst. Det bør ved særlig markering vises, at der er tale om en ikke-udleveret ordination. Udskrift af recept Feltindhold og positioner/feltstørrelser på receptblanketten fremgår af Printtabel til recepter. Der må højst være 3 ordinationer på en receptblanket. Ved lægemidler i udleveringsgruppe AP4/NBSAP4 må der kun være én ordination pr. recept. XML-recepter Godkendelse Ordinationer beregnet til XML-afsendelse, som er udført af ikkelæge, skal godkendes af en læge før afsendelsen. Ved godkendelse skal samtlige oplysninger vedr. ordinationen være til rådighed. Det er den læge, der godkender ordinationen, der er den ansvarlige læge (og dermed den læge, der overføres til XML-recepten). En XML-recept til godkendelse skal kunne afvises og slettes fra databasen. Antal ordinationer Ved lægemidler i udleveringsgruppe AP4/NBSAP4 må der kun være én ordination pr. meddelelse. For alle andre ordinationer begrænses antallet kun af MIG en (99 ordinationer). Tidsstempling af XML-ordinationer og XML-recepter Formålet med korrekt og entydig tidsstempling er at kunne kvalitetskontrollere XML-recepter mht. tidsforbrug fra ordination til ekspedition på apoteket. Den første forudsætning er, at afsendersystemets ur er indstillet korrekt. Det skal vise lokal tid +/- 1 minut. Ordinationer beregnet til XML-forsendelse skal tidsstemples ved oprettelsen. Når XML-forsendelsen dannes, allokeres en eller flere ordinationer til hver meddelelse. Tidsstemplingen af ordinationerne vil aldrig være ens, der vil altid være en forskel på et eller flere sekunder, af og til minutter. Tidsstemplingen af meddelelsen (XMLrecepten) skal være tidsstemplingen på én af ordinationerne, fx den yngste. Tidsstemplingen på forsendelsen skal være det tidspunkt, hvor dannelsen af XML-meddelelsen sker. Kontrolfunktioner Afsendelse af positiv kvitteringsmeddelelse fra apoteket, når der er modtaget en syntaktisk korrekt xml-recept, er obligatorisk. Modtagelse og behandling af kvitteringsmeddelelsen i afsendersystemet er ligeledes obligatorisk. Både negativ og positiv. Der bør kunne vises oversigter over samtlige afsendte XMLrecepters status for aktuelle dag og foregående 2 hverdage. Oversigten skal rumme patientidentifikation (CPR-nummer og navn), apotek, recept-id (evt. i forkortet form), status, initialer for den person, der har oprettet ordinationen, og for evt. godkendende læge, tidspunkt for dannelse, tidspunkt for afsendelse og tidspunkt for modtaget kvittering. Oversigten skal kunne sorteres efter tidspunkt for dannelse og efter CPR-nummer. Oversigten skal kunne udskrives i en log. 13
Der skal være mulighed for at undersøge, hvornår sidste gennemførte opkald til netoperatøren har fundet sted. Det vil være hensigtsmæssigt også at kunne se årsag til evt. driftsstop (ingen kontakt med modem, manglende klartone, optaget, manglende connect, forkert baudrate, fejl i transmission), men dette er ikke muligt i alle systemer. Som alternativ skal brugerne have mulighed for at få vejledning af systemet om simpel fejlsøgning: Sluk/tænd modem, check af stik, egen telefonlinies tilstand, opkald til netoperatørens telefonnummer, prøveopkald med overvågning af fejlmeddelelser. En typisk recept (svarer til testeksempler i afsnit B) Eksempel 1 (Recept med 2 præparater bestilt til dosisdispensering. Læge ønsker kopi af doseringskort fra apotek. Ordinationer er gældende i 2 år uanset valgt pakningsstørrelse) Eksempel 2 14
(Recept med afhængighedsskabende præparat og kun en ordination pr. recept. Medicin sendes til patient pr. post. Recept med 3 præparater. Et med Ej S, importørnavn og genudlevering. To med tilskud. Eksempel 3 15
16
Afsnit B XML Facitliste XML Recept XPRE01 17
XML Facitliste Den gode XML recept, XLMS016 VersionCode XPRE01 XML-Facitlisten består af følgende objekter: Emessage (Kuvert) o Envelope (KuvertData) Sent (Dato) o Prescription (Recept) Letter (BrevData) Authorisation (Dato) Sender (Afsender) Issuer (Receptudsteder) Receiver (Modtager) (PatientOrRelative (Patient eller pårørende) eller ForGPClinicUse (Til brug i praksis)) 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. 18
XML Facitliste XML Facitliste XLMS016 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. Der skal altid anmodes om positiv kvittering på Prescription. </Envelope> M </Envelope> <Prescription> 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. 19
XML Facitliste XLMS016 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 med XPRE01 i LMS016. <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> </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. <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 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>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. 20