Den gode XML booking BookingQuery BookingResult BookingConfirm BookingList Sundhedsfaglige anbefalinger og XML Facitliste for

Transkript

1 XTID01-04 Den gode XML booking BookingQuery BookingResult BookingConfirm BookingList Sundhedsfaglige anbefalinger og XML Facitliste for XML Booking-forespørgsel VersionCode: XT0133L TypeCode: XTID01 XML Booking-resultat VersionCode: XT0233L TypeCode: XTID02 XML Booking-bekræftelse VersionCode: XT0333L TypeCode: XTID03 XML Booking-repertoire VersionCode: XT0433L TypeCode: XTID04 1

2 Indholdsfortegnelse: Baggrund:...3 Afsnit A: Sundhedsfaglige anbefalinger...5 Booking mellem sundhedsvæsnets parter Formål Et typisk papirbrev Beskrivelse af sammenhæng mellem de fire standarder Den gode XML booking...14 Afsnit B: XML Facitliste...15 XML Facitliste booking-forespørgsel...15 XML Testeksempel booking-forespørgsel...23 XML Facitliste booking-resultat...28 XML Testeksempel booking-resultat...36 XML Facitliste booking-bekræftelse...42 XML Testeksempel booking-bekræftelse...48 XML Facitliste booking-repertoire...50 XML Testeksempel booking-repertoire...56 XML Kvalifikatorliste (fælles for de fire standarder)

3 Baggrund MedComs XML EPJ kommunikations projekt har til formål at tilpasse og genbruge MedComs kommunikationsstander for primærsektoren til kommunikation af de tilsvarende meddelelser internt på sygehuset og mellem sygehuse, det vil sige til kommunikation af henvisninger, epikriser, laboratorieresultater m.v. Standarderne der skal anvendes til sygehusområdet skal fremover være baseret på XML syntaksen, hvor de hidtidige standarder var baseret på UN EDIFACT syntaks og standard. Kommunikation mellem sygehusafdelinger er mere omfattende og kompleks end den der er mellem sygehuse og primærsektoren, hvorfor MedComs kommunikationsstandarder er blevet gennemgået og tilpasset sygehusmiljøet. Mens G-EPJ forudsætter udvikling og indførelse af en ny type EPJsystemer, bygger "XML-EPJ Kommunikationsprojektet" på eksisterende IT-systemer og tager udgangspunkt i kommunikation mellem de IT-systemer, der benyttes i sundhedssektoren i dag. Det er målsætningen, at XML-EPJ projektet inden udgangen af 2005 resulterer i storskala landsdækkende benyttelse af alle relevante MedCom meddelelser til kommunikation internt på sygehuse og mellem sygehuse. Som supplement hertil er der udviklet fire XML-standarder til anvendelse i forbindelse med booking mellem to systemer i det danske sundhedsvæsen. Standarden er forsøgt gjort så bred, at alle de eksisterende systemer vil kunne anvende standarden. Udviklingen er sket gennem en sundhedsfaglig gennemgang i et konkret projekt i Nordjyllands Amt, under hensyntagen til den aktuelle og fremtidige brug af meddelelserne, herunder tilpasning til de journaler der fremover vil blive baseret på G-EPJ modellen. Der er således indført en række nye elementer i alle XML dokumenterne så der kan vedhæftes G-EPJ elementer til eksisterende XML dokumenter og således sikre en gradvis overgang til G-EPJ baserede journalsystemer. Hvis der ønskes overførsel af billeder eller andre binære elementer, eller mulighed for at udnytte internet teknologien med henvisninger Links til URL Internet sider, kan dette gøres i en parallel fremsendt henvisning, frem for her i bookingen. 3

4 Den samlede dokumentation af de gode XML breve består af: Afsnit A Indeholder sundhedsfaglige anbefalinger og en kort gennemgang af formålet 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. Dernæst er der anbefalinger og krav til det informationsindhold, der skal sendes og vises for brugeren. anbefalinger og krav til præsentation af dette informationsindhold i journalsystemet Afsnit B Indeholder den tekniske dokumentation af de nærværende XML standarder og består af: Kvalifikatorliste Indeholder de i de fire aktuelle meddelelser anvendte kvalifikatorer og de tilhørende værdier. Det er ikke alle kvalifikatorer, der anvendes i de fire standarder. Eksempel Et fuldt XML eksempel på de i afsnit A viste papirbreve er vist her. Supplerende testeksempler kan altid findes på MedComs hjemmeside. Ved booking-forespørgsel og booking-result er der i eksemplerne anført dataene struktureret efter G-EPJ opbygning, mens dette ikke er gjort for de to andre standarder. Ved booking-result eksemplet er der angivet indhold i Local_Elements -segmentet, der viser hvorledes to systemer properitært kan aftale at udveksle informationer udover standardens rammer. Facitliste For at sikre overensstemmelse mellem de sundhedsfaglige anbefalinger og en entydig mapning i MedComs XML standarder er udarbejdet en Facitliste for benyttelsen af de nærværende fire XML standarder. 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. 4

5 Afsnit A Sundhedsfaglige anbefalinger for XML booking XTID

6 Booking mellem sundhedsvæsenets parter 1. Formål Ud over det formaliserede kontaktbehov mellem eksempelvis sygehuse, lægepraksis, apoteker og kommuner i form af udskrivningsbreve, røntgensvar, henvisninger og indlæggelses- og udskrivningsadvis eksisterer der et stort behov for via en sikker kommunikation at kunne booke ydelser af forskellig karakter, i forbindelse med udredning eller opfølgning vedrørende den enkelte patients behandling. Hver gang en part i sundhedsvæsenet ønsker at henvise en patient, eller bestille ydelser andetsteds i sundhedsvæsenet, er der behov for en booking. F.eks. indeholder henvisninger, der fremsendes til en sygehusafdeling, ikke tilstrækkelig beskrivelse omkring de ydelser der ønskes udført på patienten, til at visitator kan give et præcist bud på rette tidspunkt for indkaldelse til undersøgelse/behandling. Der vil naturligvis stadig fremover forekomme typer af henvisninger, hvor booking ikke kan udføres sideløbende. For at kunne foretage en sikker og hurtig booking, kræves der en udveksling af tre meddelelser, hvorfor det er hensigten at kommunikationen bør ske automatisk uden brugerinvolvering, hvor dette er muligt. Hvor det er muligt at etablere automatisk respons på en forespørgsel, vil den som foretager bookingen få bekræftelse med det samme, og derved kunne informere patienten uden at skulle kontakte denne efterfølgende. Tilsvarende undgår patienter at skulle henvende sig med spørgsmål og ændringsønsker til de tildelte tidspunkter. Bookingmeddelelserne er primært tænkt anvendt ved on-line bookingmulighed, men hvis der ikke er et tilstrækkelig automatiseret IT-system hos den som modtager booking-forespørgslen, må modtageren håndtere forespørgslen og returnere et tidspunkt manuelt. Såfremt forbindelsen er permanent tilstede, og ITsystemerne i begge ender understøtter automatiseret drift, må bookingen siges at være tæt på on-line. Hvis der ikke eksisterer mulighed for automatiseret behandling ved modtagelse af XML-meddelelse (f.eks. i form af en web-service), kan man anvende XML-meddelelserne asynkront i stedet. Dette kan gøres som vedhæftelse til via sundheds-datamettet, eller forsendelse via VANS. Bookingmeddelelsen har til formål at udnytte de eksisterende landsdækkende EDI / XML kommunikationsløsninger til sikker kommunikation af patienthenførbare, tekstbaserede forespørgsler og informationer mellem alle parter (sygehuse, lægepraksis, apoteker og kommuner) i sundhedssektoren. MedComs booking brevtype er et subset af standarden for Den gode XML epikrise, der er udvidet med bookingspecifikke oplysninger. Da meddelelsen indeholder patienthenførbare oplysninger, skal den normalt gemmes sammen med andre patientoplysninger i såvel afsenders som modtagers IT-systemer. Modtagere bør være opmærksomme på, at man ofte kan modtage bookinger omhandlende patienter, der ikke i forvejen er registreret i modtagers edb-system. 6

7 2. Et typisk papirbrev En typisk booking-forespørgsel kunne se sådan ud: (Overskrifter er vist med kursiv - og medsendes ikke i meddelelsen) AFSENDER: Hillerød Sygehus Ortopædkirurgisk amb. vestergade Hillerød MODTAGER: Roskilde Amts Sygehus Køge Billeddiagnostisk afd. Lykkebækvej Køge ** Rekvirering af ydelse ** Afsendt: kl FORTROLIGT KUN TIL SUNDHEDSFAGLIGT BRUG Knut Odvar Mosebryggersen Grusgraven 3, 3 tv 3400 Hillerød BREVTEKST: Ønskede ydelser (maximalt 10): Røntgen af højre hofte i 2 planer. Røntgen af venstre hofte i 2 planer. Vælg en af følgende prioriteter: V Elektiv Fremskyndet Akut Tidligste start: kl Senest slut: kl Patienten kan aldrig om: Formiddagen Fredage I weekenderne. Vælg en af følgende 2 typer: Manuel V Automatisk (tidspunkt må genereres uden hensyntagen til eventuelle bemærkninger) ID på den fremsendte forespørgsel er Bemærkning: Da patienten tidligere har været undersøgt af Dr. Olsen, vil det være rart om samme læge kan tilse patienten, om muligt. 7

8 Et typisk papirbrev Et typisk booking-resultat kunne se sådan ud: (Overskrifter er vist med kursiv - og medsendes ikke i meddelelsen) ** Foreslået tidspunkt for rekvireret ydelse ** Afsendt: kl AFSENDER: Roskilde Amts Sygehus Køge Billeddiagnostisk afd. Lykkebækvej Køge MODTAGER: Hillerød Sygehus Ortopædkirurgisk amb. vestergade Hillerød FORTROLIGT KUN TIL SUNDHEDSFAGLIGT BRUG Knut Odvar Mosebryggersen Grusgraven 3, 3 tv 3400 Hillerød BREVTEKST: Bookede ydelser: Røntgen af højre hofte i 2 planer. Røntgen af venstre hofte i 2 planer. Prioritet: Elektiv Mødetidspunkt: kl Forventet afslutning: kl Dette forslag til tidspunkt for de anmodede services skal bekræftes inden d kl Type: Tilbudt ID for den bookede tid er ID på den fremsendte forespørgsel er Bemærkning: Patienten skal henvende sig ved skranke 2 og behandles i rum 4. Patienten kan ikke blive tilset af Dr. Olsen, da han er gået på pension. 8

9 Et typisk papirbrev En typisk booking-bekræftelse kunne se sådan ud: (Overskrifter er vist med kursiv - og medsendes ikke i meddelelsen) ** Bekræftelse på tilbudt tidspunkt for rekvireret ydelse ** Afsendt: kl AFSENDER: Hillerød Sygehus Ortopædkirurgisk amb. vestergade Hillerød FORTROLIGT KUN TIL SUNDHEDSFAGLIGT BRUG MODTAGER: Roskilde Amts Sygehus Køge Billeddiagnostisk afd. Lykkebækvej Køge Vælg én af følgende 2 muligheder for den tilbudte tid med ID : V Det tilbudte tidspunkt er OK. Afvis den tidbudte tid. 9

10 Et typisk papirbrev Et typisk booking-repertoire kunne se sådan ud: (Overskrifter er vist med kursiv - og medsendes ikke i meddelelsen) ** Oversigt over ydelser der kan bestilles ** Afsendt: kl AFSENDER: Roskilde Amts Sygehus Køge Billeddiagnostisk afd. Lykkebækvej Køge MODTAGER: Hillerød Sygehus Ortopædkirurgisk amb. vestergade Hillerød BREVTEKST: Følgende ydelser kan bookes: R01 som er Røntgen. R10h som er Røntgen af højre arm. R10v som er Røntgen af venstre arm. R11h som er Røntgen af højre ben. R11v som er Røntgen af venstre ben. R12h som er Røntgen af højre fod. R12v som er Røntgen af venstre fod. R20h som er Røntgen af højre hofte. R20v som er Røntgen af venstre hofte. R20h2 som er Røntgen af højre hofte i 2 planer. R20v2 som er Røntgen af venstre hofte i 2 planer. R30 som er Røntgen af thorax. C01 som er CT-scanning. M01 som er MR-scanning P01 som er PET-scanning. 10

11 3. Sammenhæng mellem standarderne Hvad er de enkelte standarder til? Der er udviklet i alt fire standarder, for at kunne opfylde alle behov i forbindelse med udveksling af booking-informationer. Den første standard kaldes BookingQuery, og benyttes til at sende en forespørgsel om udførelse af en eller flere ydelser. Rekvirenten udvælger ydelser fra udbyderens repertoire. Den anden standard kaldes BookingResult, og benyttes til at sende et konkret forslag om tidspunkt retur til den som fremsendte BookingQuery. Den som udbyder ydelsen finder først ledige tid ud fra de anmodede kriterier, og det givne foreslåede tidspunkt reserveres i udbyderens system for en aftalt periode. Den tredje standard kaldes BookingConfirm, og benyttes til at bekræfte eller afvise det modtagne BookingResult. Hvis der sendes en afvisning, skal ny BookingQuery foretages helt fra grunden af. Hvis der sendes en accept, men denne ankommer for sent til udbyderen, skal udbyderen fremsende en ny BookingResult. Den fjerde standard kaldes BookingList, og benyttes til at distribuere hvilket repertoire af ydelser man som udbyder stiller til rådighed. Modtagelse af denne meddelelse, kan være en forudsætning for at kunne afsende en fornuftig BookingQuery. Der kan i BookingQuery anføres nogle kommentarer, som gør at automatisk generering af et BookingResult ikke er muligt, og behandlingen af forespørgslen dermed udføres manuelt. Til hver BookingQuery kan der opsættes nogle kriterier der ønskes opfyldt (evt. fra patientens side). Det kan være ikke før eller ikke efter et anført tidspunkt, ugedage der ikke er mulige, eller ikke mulighed for morgen/eftermiddag. Hvis en part i sundhedsvæsenet ønsker at informere andre parter om nye bookinger, kan BookingResult fremsendes enkeltstående, uden en forudgående BookingQuery f.eks. fra et hospital til egen læge, når patienten indkaldes til en undersøgelse/behandling. En enkeltstående BookingResult laves derfor ofte samtidigt med indkaldelsen sendes til patienten. Hver BookingResult kan have en af fire mulige typer: Positiv = Tidspunkt indenfor anmodede kriterier. Negativ = Ingen tid tildelt indenfor anmodede kriterier. Alternative = Tidspunkt er udenfor anmodede kriterier. Korrektion = Tidspunkt er ændret i forhold til tidligere sendt BookingResult (anvendes kun ved for sent modtagelse af accept). Ved afsendelse af BookingQuery navngives denne entydigt hos rekvirenten, og navnet returneres i BookingResult. Hver BookingResult navngives også entydigt, så det kan returneres i bekræftelsen/afvisningen. Hver part i sundhedsvæsenet som kan tilbyde udførelse af ydelser for andre, kan distribuere en liste med deres repertoire af ydelser, som består af en ID og en beskrivelse. Dette kan f.eks. være R10=Røntgen af bryst, R11=Røntgen af arm, R12=Røntgen af ben etc. 11

12 Der kan foretages en afbestilling af en allerede accepteret booking, ved at fremsende yderligere en bekræftelse, men denne gang lade bekræftelsen være negativ (en afvisning). Det er væsentligt, at der anvendes samme unikke booking-id i de to bekræftelsesmeddelelser. Ved forsinkelser og/eller ombookinger hos serviceudbyderen, kan det bilateralt aftales, om der ønskes genfremsendelse af korrigeret tidspunkt for bookingen til rekvirenten. BookingResult meddelelsen vil i en sådan sitation få en særskilt markering, så rekvirenten s ITsystem ikke returnerer BookingConfirm herpå. 12

13 13

14 4. Det gode XML booking Det anbefales afsendersystemet: at kunne afsende breve til modtagere der anvender såvel SKS sygehusafdelingsnumre, ydernummer eller lokationsnummer. at alle felter som findes i bookingen vises på skærmbillede(r) før afsendelse kan ske. at alle felter i en booking, der er under redigering, skal kunne rettes. at bookingen skal være endelig/godkendt, før afsendelse kan ske. at bookingen skal kunne genfremsendes uændret men at dette ikke må kunne ske ved en fejltagelse. at det fremgår af bookingen, hvis bookingen er en tilføjelse/korrektion af en tidligere fremsendt booking. Sker fremfinding/dannelse på baggrund af en G-EPJ baseret journal kan de oplysninger der stammer fra G-EPJ elementer også sendes i G-EPJ elementerne i XML-bookingen. Der må ikke findes data i de medsendte G-EPJ elementer som ikke er indeholdt i bookingen. Modtagersystemet skal organiseres således: at kunne modtage breve fra afsendere af enhver type med et afsenderid på formen an..17, herunder såvel SKS sygehusafdelingsnumre, ydernummer, kommunenummer, apoteksnummer eller lokationsnummer. at modtagne forespørgsler på booking, der kan behandles automatisk, bliver det. Der skal returneres en tilhørende meddelelse med forslag til konkret booking-tidspunkt. at foreslå den først ledige tid, hvor de ønskede ydelser er mulige, med hensyntagen til de i forespørgslen anførte betingelser. at modtagne forslag til konkrete booking-tidspunkter, der kan behandles automatisk, bliver det. Der skal returneres en tilhørende accept eller afvisning. alternativt at alle fremsendte informationer vises overskueligt (i en eller flere funktioner) i modtagersystemet gerne i samme form (overskrifter, datoformater o.l.) som det fremgår af det typiske papirbrev. at fremsendte informationer ved modtagelsen vises som de fremsendes og ikke som de måtte fremgå af et eksisterende register i modtagersystemet. at de modtagne informationer genanvendes i så høj grad som muligt i modtagersystemet. og det anbefales at medsendte binære elementer kan vises direkte ved kald fra den aktuelle booking, og at man returnerer til samme sted i bookingen, når man forlader det binære element. og det anbefales at medsendte URL referencer kan aktiveres direkte fra bookingen, og at man returnerer til samme sted i bookingen, når man forlader referencen. at man viser en evt. SUP angivelse på bookingens første side. At der ikke returneres accept/afvisning på et BookingResult, hvis denne er markeret værende udelukkende til information for modtageren (som typisk vil være en kopimodtager). 14

15 Afsnit B XML Facitliste XML Booking-forespøgsel XTID01 15

16 XML Facitliste Den gode XML booking-forespørgsel, XTID01, VersionCode XT0133L MedComs XML meddelelser er opdelt i tre dele: Del A indeholder logistikdata (Tekniske data, afsender, modtager, patient og pårørende). Del B indeholder MedCom meddelelsens kliniske data. Del C kan indeholde G-EPJ XML elementer. XML-Facitlisten består af følgende objekter: Del A: Emessage (Kuvert) o Envelope (KuvertData) Sent (Dato) o BookingQuery (Bookingforespørgsel) Letter (BrevData) Authorisation (Dato) Sender (Afsender) Receiver (Modtager) Patient (Patient) Del B: BookingService (Bestilling) ServicePart (Ydelse) max. x 10 Limitation (periode-afgrænsning) Del C: GEPJ_Elements Local_Elements 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. XML TAG, som viser XML element navnet. DataDefinition, der definerer indholdet af de enkelte data. Derudover beskrives relevante anvendelsesregler og andet, der er nødvendige for en korrekt implementering. 16

17 XML Facitliste XML Facitliste XTID01 FeltDef M XML TAG XML DataDefinition <?xml version="1.0" encoding="iso "?> Format M Skal medsendes som en kopi af den viste XML deklaration <!--MedCom_De_gode_XMLbreve_ !> Format Anbefales medsendt <Emessage> M <Emessage> <Envelope> M <Envelope> <Sent> M <Sent> <Date>Kuvertens_afsendelses_dato</Date> Date M <Date></Date> Date er dato for påbegyndelse af afsendelse af kuverten på formen YYYY- MM-DD. <Time>Kuvertens_afsendelses_tidspunkt</Time> Time M <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 <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 ing</acknowledgementcode> M <AcknowledgementCod e></acknowledgement Code> 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> <BookingQuery> M <BookingQuery> <Letter> M <Letter> <Identifier>Brevets_nummer</Identifier> an..14 M <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 <VersionCode></Versio ncode> <StatisticalCode>Brevets_statistiknummer</Statistica lcode> an..8 M <StatisticalCode></Stati sticalcode> 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. StatisticalCode udfyldes med TypeCode (f.eks. XDIS01, XRPT02). Statisticalcode er beregnet til statistik formål og må ikke bruges af modtager systemer. <Authorisation> M <Authorisation> <Date>Brevets_godkendelsesdato</Date> Date M <Date></Date> Date er dato hvor brevet blev lavet "færdigt" eller "godkendt" hos afsender. Date angives på formatet YYYY-MM-DD. 17

18 XML Facitliste XTID01 FeltDef M XML TAG XML DataDefinition <Time>Brevets_godkendelsesKlokkeslet</Time> Time M <Time></Time> Time er det tidspunkt hvor brevet blev lavet "færdigt" eller "godkendt" hos afsender. Time angives på formatet HH:MM sættes til "00:00" såfremt klokkeslæt ikke kan angives. </Authorisation> M </Authorisation> <TypeCode>Brevets_brevtype_i_kode</TypeCode> KVA M <TypeCode></TypeCod TypeCode er kvalifikator for brevets type. Se kvalifikatorliste. e> <StatusCode>Brevets_status</StatusCode> KVA M <StatusCode></Status Code> <EpisodeOfCareIdentifier>Brevets_sygdoms_forloeb snummer</episodeofcareidentifier> </Letter> M </Letter> <Sender> M <Sender> <EANIdentifier>Afsenders_lokationsnummer</EANId entifier> StatusCode er en kvalifikator der angiver om brevet er nyt, rettet eller slettet. Den aktuelle anvendelse kan ses i kvalifikatorlisten. Skal altid udfyldes validt. an..35 <EpisodeOfCareIdentifi EpisodeOfCareIdentifier er reserveret til SSTs kommende forløbsmodel og er></episodeofcareide benyttes til at knytte informationer til samme sygdomsforløb. ntifier> an..35 M <EANIdentifier></EANI dentifier> EANIdentifier er kuvertafsenders lokationsnummer det vil normalt sige afsendende organisation. Såvel positiv som negativ kvittering sendes tilbage til dette nummer. <Identifier>Afsenders_ID_nummer</Identifier> an..17 M <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 <OrganisationName>Afsenders_organisation</Organi an..35 sationname> M <IdentifierCode></Identi fiercode> M <OrganisationName></ OrganisationName> IdentifierCode er kvalifikator for det anvendte kode- el. klassifikationssystem - ofte "sygehusafdelingsnummer" hvis afsender er en sygehusafdeling, "ydernummer" hvis sygesikringsyder, "kommunenummer" hvis kommune. OrganisationName er navnet i tekst på afsendende 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". 18

19 XML Facitliste XTID01 FeltDef M XML TAG XML DataDefinition <DepartmentName>Afsenders_afdeling_el_socialomr aade</departmentname> an..35 <DepartmentName></D epartmentname> <UnitName>Afsenders_afdeling_el_socialdistrikt</Uni an..35 <UnitName></UnitNam tname> e> DepartmentName er navnet på sygehusafdelingen hvis afsender er et sygehus, navnet på hjemmepleje distriktet hvis afsender er en kommune, titlen "læge" hvis afsender er et lægehus o.l. Udfyldes ofte med "Gadenavn" ved fysioterapeutklinikker. UnitName er sygehusafsnit, hvis afdeling er et sygehus, navnet (For- og efternavn) hvis afsender er en person i et lægehus, hjemmeplejegruppe hvis kommune. <StreetName>Afsenders_adresse</StreetName> an..35 <StreetName></StreetN StreetName er afsenders vejnavn og vejnummer. ame> <SuburbName>Afsenders_bostednavn</SuburbNam an..35 <SuburbName></Subur SuburbName er et evt. stednavn på afsenders primære adresse for eks.: e> bname> Mullerup, 5772 Kværndrup. <DistrictName>Afsenders_by</DistrictName> an..35 <DistrictName></Distric DistrictName er afsenders bynavn på primære adresse. tname> <PostCodeIdentifier>Afsenders_postnummer</PostC n4 <PostCodeIdentifier></ PostCodeIdentifier er afsenders postnummer på primære adresse. odeidentifier> PostCodeIdentifier> <TelephoneSubscriberIdentifier>Afsenders_telefon</ TelephoneSubscriberIdentifier> an..25 <TelephoneSubscriberI dentifier></telephones ubscriberidentifier> TelephoneSubscriberIdentifier er afsenders telefonnummer. <MedicalSpecialityCode>Afsenders_medicinske_spe ciale</medicalspecialitycode> KVA <MedicalSpecialityCode MedicalSpecialityCode er en kvalifikator for afsenders lægelige speciale. ></MedicalSpecialityCo de> Skal udfyldes, men er medicinsk speciale ikke kendt /ikke relevant benyttes kvalifikatoren "ikkeklassificeret". Se kvalifikatorliste. </Sender> M </Sender> <Receiver> M <Receiver> <EANIdentifier>Modtagers_lokationsnummer</EANId an..35 M <EANIdentifier></EANI EANIdentifier er kuvertmodtagers lokationsnummer. entifier> dentifier> <Identifier>Modtagers_ID_nummer</Identifier> an..17 M <Identifier></Identifier> Identifier er slutmodtagers sygehusafdelingsnummer, ydernummer, kommunenummer eller lokationsnummer. Identifier skal anvendes som beskrevet ved SenderIdentifier ovenfor og skal altid udfyldes validt. <IdentifierCode>Modtagers_ID_nummer_type</Identi fiercode> KVA M <IdentifierCode></Identi fiercode> IdentifierCode er kvalifikator for det anvendte kode- el. klassifikationssystem - ofte "sygehusafdelingsnummer" hvis modtager er en sygehusafdeling, "ydernummer" hvis sygesikringsyder, "kommunenummer" hvis kommune. <OrganisationName>Modtagers_organisation</Organ an..35 <OrganisationName></ OrganisationName er navnet i tekst på modtagende sygehus, lægehus eller isationname> OrganisationName> kommune. Udfyldes som for SenderOrganisationName. <DepartmentName>Modtagers_afdeling</Departmen an..35 <DepartmentName></D DepartmentName er navnet på sygehusafdeling, hjemmeplejedistrikt eller tname> epartmentname> titlen "Læge" hvis modtager er en læge i et lægehus o.l. Se beskrivelse under SenderDepartmentName. 19

20 XML Facitliste XTID01 FeltDef M XML TAG XML DataDefinition <UnitName>Modtagers_afsnit</UnitName> an..35 <UnitName></UnitNam e> UnitName er modtagende sygehusafdeling eller for- og efternavn (hvis modtager er en person i et lægehus). Se beskrivelse under SenderUnitName. StreetName er modtagers primære adresse. <StreetName>Modtagers_adresse</StreetName> an..35 <StreetName></StreetN ame> <SuburbName>Modtagers_bostednavn</SuburbNam an..35 <SuburbName></Subur SuburbName er et evt. stednavn på modtagers primære adresse f.eks.: e> bname> Mullerup, 5772 Kværndrup. <DistrictName>Modtagers_bynavn</DistrictName> an..35 <DistrictName></Distric DistrictName er modtagers bynavn på primære adresse. tname> <PostCodeIdentifier>Modtagers_postnummer</PostC n4 <PostCodeIdentifier></ PostCodeIdentifier er modtagers postnummer på primære adresse. odeidentifier> PostCodeIdentifier> </Receiver> M </Receiver> <Patient> M <Patient> Vælg mellem ( Vælg mellem ( <CivilRegistrationNumber>Patientens_CPR_nummer </CivilRegistrationNumber> Eller eller <AlternativeIdentifier>Patientens_erstatnings_CPR_n ummer</alternativeidentifier> n10 <CivilRegistrationNumb er></civilregistrationn umber> an10 <AlternativeIdentifier></ AlternativeIdentifier> CivilRegistrationNumber er patientens valide CPR-nummer og dette eller et erstatningsnummer skal altid medsendes. CPR-nummer sendes uden bindestreg. Hvis et validt cpr-nummer ikke findes sendes et erstatningsnummer i AlternativeIdentifier på præcis 10 tegn. AlternativeIdentifier er et erstatnings CPR-nummer eller et usikkert CPRnummer på præcis 10 tegn. Udfyldes hvis der ikke er angivet et validt CPRnummer i CivilRegistrationNumber. ) ) <PersonSurnameName>Patientens_efternavn</Pers an..70 M <PersonSurnameName PersonSurnameName er patientens efternavn. onsurnamename> ></PersonSurnameNam e> <PersonGivenName>Patientens_fornavne</PersonGi an..70 <PersonGivenName></ PersonGivenName er patientens fornavn(e). Fornavn bør altid medsendes. venname> PersonGivenName> <StreetName>Patientens_adresse</StreetName> an..35 <StreetName></StreetN StreetName er patientens primære vejnavn og nummer. ame> <SuburbName>Patientens_bostednavn</SuburbNam an..35 <SuburbName></Subur SuburbName er et evt. stednavn på patientens primære adresse f.eks.: e> bname> Mullerup, 5772 Kværndrup. <DistrictName>Patientens_bynavn</DistrictName> an..35 <DistrictName></Distric DistrictName er bynavn på den primære adresse. tname> <PostCodeIdentifier>Patientens_postnummer</PostC n4 <PostCodeIdentifier></ PostCodeIdentifier er postnummeret på den primære adresse. odeidentifier> PostCodeIdentifier> 20

21 XML Facitliste XTID01 FeltDef M XML TAG XML DataDefinition <OccupancyText>Patientens_stillingsbetegnelse</Oc an..35 <OccupancyText></Occ OccupancyText er patientens stillingsbetegnelse. cupancytext> upancytext> <EpisodeOfCareStatusCode>Patientens_status</Epi KVA M <EpisodeOfCareStatus EpisodeOfCareStatusCode er en kvalifikator, der angiver patientstatus. Se sodeofcarestatuscode> Code></EpisodeOfCare kvalifikatorliste. StatusCode> </Patient> M </Patient> <BookingService> M <BookingService> Ydelse <BookingQueryIdentifier></BookingQueryIdentifie An..35 r> M <BookingQueryIdentifi Entydig ID på booking-forespørgslen fra rekvirentens side. Det er></bookingqueryide anbefales at lade rekvirentens lokationsnummer eller SKS-kode helt ntifier> eller delvist indgå i denne identifier, så denne ID bliver unik nationalt. <ServicePart> <ServicePart> <ServiceCode></ServiceCode> An..8 M <ServiceCode></Servic Ydelsens ID. ecode> <ServiceName></ServiceName> An..70 <ServiceName></Servi Ydelsens navn. cename> </ServicePart> </ServicePart> <Limitation> <Limitation> <NotBefore> <NotBefore> <Date></Date> Date M <Date></Date> Date er dato for tidligste tidspunkt hvor bookingen må forekomme, på formen YYYY-MM-DD. <Time></Time> Time <Time></Time> Time er klokkeslæt for tidligste klokkeslæt hvor bookingen må forekomme, på formen HH:MM. </NotBefore> </NotBefore> <NotAfter> <NotAfter> <Date></Date> Date M <Date></Date> Date er dato for seneste tidspunkt hvor bookingen må forekomme, på formen YYYY-MM-DD. <Time></Time> Time <Time></Time> Time er klokkeslæt for seneste klokkeslæt hvor bookingen må forekomme, på formen HH:MM. </NotAfter> </NotAfter> <NotDay>Ikke_Dag</Notday> An..8 <NotDay></Notday> Angiver hvilken dag patienten generelt ikke kan. Skal rumme en af følgende værdier: mandag, tirsdag, onsdag, torsdag, fredag, lørdag, søndag, weekend. <NotMorning></NotMorning> An..1 <NotMorning></NotMo Angiver at patienten generelt ikke kan om formiddagen. Feltet sættes rning> til 1 hvis sandt eller 0 hvis falsk. <NotAfternoon></NotAfternoon> An..3 <NotAfternoon></Not Afternoon> Angiver at patienten generelt ikke kan om eftermiddagen. Feltet sættes til 1 hvis sandt eller 0 hvis falsk. 21

22 XML Facitliste XTID01 FeltDef M XML TAG XML DataDefinition </Limitation> </Limitation> <RequestType>Komm_Form</RequestType> M <RequestType></Requ esttype> Type af forespørgsel. Kan rumme automatisk som betyder at der må genereres et booking-resultat automatisk ud fra booking-forespørgslen. Feltet kan også rumme manuel, hvis der f.eks. i kommenteringen fremgår information der har betydning for det bookede tidspunkt/ydelser. <Remark></Remark> An..350 <Remark></Remark> Her kan anføres eventuelle bemærkninger eller kommentarer vedrørende booking-forespørgslen. Må ikke indeholde væsentlige kliniske oplysninger, hvis Komm_Form er sat til automatisk. <Priority>BookingPrioritet</Priority> KVA <Priority></Priority> Her anføres prioritet. Default er elektiv. </BookingService> M </BookingService> </BookingQuery> M </BookingQuery> <GEPJ_Elements> <GEPJ_Elements> </GEPJ_Elements> </GEPJ_Elements> <Local_Elements> <Local_Elements> </Local_Elements> </Local_Elements> </Emessage> M </Emessage> 22

23 Testeksempel XML Booking: XTID01 <?xml version="1.0" encoding="iso "?> <Emessage xmlns=" <Envelope> <Sent> <Date> </Date> <Time>12:01</Time> </Sent> <Identifier>KuvertNr012238</Identifier> <AcknowledgementCode>minuspositivkvitt</AcknowledgementCode> </Envelope> <BookingQuery> <Letter> <Identifier>BrevNr00133</Identifier> <VersionCode>XT0133L</VersionCode> <StatisticalCode>XTID01</StatisticalCode> <Authorisation> <Date> </Date> <Time>11:02</Time> </Authorisation> <TypeCode>XTID01</TypeCode> <StatusCode>nytbrev</StatusCode> </Letter> <Sender> <EANIdentifier> </EANIdentifier> <Identifier> </Identifier> <IdentifierCode>sygehusafdelingsnummer</IdentifierCode> <OrganisationName>Frederiksborg Amt</OrganisationName> <DepartmentName>Hillerød Sygehus</DepartmentName> <UnitName>Kirurgisk afd. A</UnitName> <DistrictName>Hillerød</DistrictName> <PostCodeIdentifier>3400</PostCodeIdentifier> <MedicalSpecialityCode>kirurgi_sygehus</MedicalSpecialityCode> </Sender> <Receiver> 23

24 <EANIdentifier> </EANIdentifier> <Identifier>250210</Identifier> <IdentifierCode>sygehusafdelingsnummer</IdentifierCode> <OrganisationName>Roskilde Amts Sygehus Køge</OrganisationName> <DepartmentName>Ortopædkirurgisk amb.</departmentname> <StreetName>Lykkebækvej 1</StreetName> <DistrictName>Køge</DistrictName> <PostCodeIdentifier>4600</PostCodeIdentifier> </Receiver> <Patient> <CivilRegistrationNumber> </CivilRegistrationNumber> <PersonSurnameName>Mosebryggersen</PersonSurnameName> <PersonGivenName>Knut Odvar</PersonGivenName> <StreetName>Grusgraven 3, 3 tv</streetname> <DistrictName>Hillerød</DistrictName> <PostCodeIdentifier>3400</PostCodeIdentifier> <EpisodeOfCareStatusCode>inaktiv</EpisodeOfCareStatusCode> </Patient> <BookingService> <BookingQueryIdentifier> </BookingQueryIdentifier> <ServicePart> <ServiceCode>R20h2</ServiceCode> <ServiceName>Røntgen af højre hofte i 2 planer.</servicename> </ServicePart> <ServicePart> <ServiceCode>R20v2</ServiceCode> <ServiceName>Røntgen af venstre hofte i 2 planer.</servicename> </ServicePart> <Limitation> <NotBefore> <Date> </Date> <Time>14:00</Time> </NotBefore> <NotAfter> <Date> </Date> <Time>16:00</Time> </NotAfter> <NotDay>Fredag</NotDay> <NotDay>Weekend</NotDay> 24

25 <NotMorning>1</NotMorning> <NotAfternoon>0</NotAfternoon> </Limitation> <RequestType>automatisk</RequestType> <Remark>Da patienten tidligere har været undersøgt af Dr. Olsen, vil det være rart om samme læge kan tilse patienten, om muligt.</remark> <Priority>elektiv</Priority> </BookingService> </BookingQuery> <GEPJ_Elements> <GEpjInterface xmlns=" <afsender> <afsenderid> </afsenderid> <udtraekstidspunkt> t12:01:00+01:00</udtraekstidspunkt> </afsender> <Patient> <id> <prefix>cpr</prefix> <vaerdi> </vaerdi> </id> <identitet> <lokalstrid>knut Odvar Mosebryggersen</lokalStrId> <domaene> <lbnr>0</lbnr> </domaene> </identitet> </Patient> <forloeb> <id> <prefix>0</prefix> <vaerdi>991</vaerdi> </id> <patient_id> <prefix>cpr</prefix> <vaerdi> </vaerdi> </patient_id> </forloeb> <Intervention> <id> 25

26 <prefix>0</prefix> <vaerdi>1812</vaerdi> </id> <patient_id> <prefix>cpr</prefix> <vaerdi> </vaerdi> </patient_id> <Art> <primaerkode> <dato> </dato> <kode>r20h2</kode> </primaerkode> </Art> <Art> <primaerkode> <dato> </dato> <kode>r20v2</kode> </primaerkode> </Art> </Intervention> <InterventionStatus> <id> <prefix>0</prefix> <vaerdi>181201</vaerdi> </id> <besluttetaf> <tilknyttetenhed> <navn> <dato> </dato> <kode> </kode> </navn> </tilknyttetenhed> </besluttetaf> <dokumenteret> <datotid> t12:01:00+01:00</datotid> </dokumenteret> <besluttet> <datotid> t12:01:00+01:00</datotid> </besluttet> 26

27 <dokumenteretaf> <tilknyttetenhed> <navn> <dato> </dato> <kode> </kode> </navn> </tilknyttetenhed> </dokumenteretaf> <ejerart> <dato> </dato> <kode>intenderet</kode> </ejerart> <art> <dato> </dato> <kode>intenderet</kode> </art> <Aarsag> <dato> </dato> <kode>obs. for osteoporose i hofte.</kode> </Aarsag> <gepj_id> <prefix>0</prefix> <vaerdi> </vaerdi> </gepj_id> <prioritet> <dato> </dato> <kode>elektiv</kode> </prioritet> </InterventionStatus> </GEpjInterface> </GEPJ_Elements> <Local_Elements> </Local_Elements> </Emessage> 27

28 Afsnit B XML Facitliste XML Booking-resultat XTID02 28

29 XML Facitliste Den gode XML booking-resultat, XTID02, VersionCode XT0233L MedComs XML meddelelser er opdelt i tre dele: Del A indeholder logistikdata (Tekniske data, afsender, modtager, patient og pårørende). Del B indeholder MedCom meddelelsens kliniske data. Del C kan indeholde G-EPJ XML elementer. XML-Facitlisten består af følgende objekter: Del A: Emessage (Kuvert) o Envelope (KuvertData) Sent (Dato) o BookingResult (Bookingforslag) Letter (BrevData) Authorisation (Dato) Sender (Afsender) Receiver (Modtager) Patient (Patient) Del B: BookingServiceOffered (Foreslået tidspunkt for samlede booking) ServicePart (Ydelse) max. x 10 ScheduledMeetingStart (Start klk) ScheduledMeetingEnd (Slut klk) Expiration (Udløb) Del C: GEPJ_Elements Local_Elements 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. XML TAG, som viser XML element navnet. DataDefinition, der definerer indholdet af de enkelte data. Derudover beskrives relevante anvendelsesregler og andet, der er nødvendige for en korrekt implementering. 29

30 XML Facitliste XML Facitliste XTID02 FeltDef M XML TAG XML DataDefinition <?xml version="1.0" encoding="iso "?> Format M Skal medsendes som en kopi af den viste XML deklaration <!--MedCom_De_gode_XMLbreve_ !> Format Anbefales medsendt <Emessage> M <Emessage> <Envelope> M <Envelope> <Sent> M <Sent> <Date>Kuvertens_afsendelses_dato</Date> Date M <Date></Date> Date er dato for påbegyndelse af afsendelse af kuverten på formen YYYY- MM-DD. <Time>Kuvertens_afsendelses_tidspunkt</Time> Time M <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 <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 ing</acknowledgementcode> M <AcknowledgementCod AcknowledgementCode er en kvalifikator, der angiver om positiv kvittering e></acknowledgement ønskes retur. Negativ sendes under alle omstændigheder uafhængig af Code> værdien af AcknowledgementCode. </Envelope> M </Envelope> <BookingResult> M <BookingResult> <Letter> M <Letter> <Identifier>Brevets_nummer</Identifier> an..14 M <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 <VersionCode></Versio ncode> <StatisticalCode>Brevets_statistiknummer</Statistica lcode> an..8 M <StatisticalCode></Stati sticalcode> 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. StatisticalCode udfyldes med TypeCode (f.eks. XDIS01, XRPT02). Statisticalcode er beregnet til statistik formål og må ikke bruges af modtager systemer. <Authorisation> M <Authorisation> <Date>Brevets_godkendelsesdato</Date> Date M <Date></Date> Date er dato hvor brevet blev lavet "færdigt" eller "godkendt" hos afsender. Date angives på formatet YYYY-MM-DD. 30

31 XML Facitliste XTID02 FeltDef M XML TAG XML DataDefinition <Time>Brevets_godkendelsesKlokkeslet</Time> Time M <Time></Time> Time er det tidspunkt hvor brevet blev lavet "færdigt" eller "godkendt" hos afsender. Time angives på formatet HH:MM sættes til "00:00" såfremt klokkeslæt ikke kan angives. </Authorisation> M </Authorisation> <TypeCode>Brevets_brevtype_i_kode</TypeCode> KVA M <TypeCode></TypeCod TypeCode er kvalifikator for brevets type. Se kvalifikatorliste. e> <StatusCode>Brevets_status</StatusCode> KVA M <StatusCode></Status Code> StatusCode er en kvalifikator der angiver om brevet er nyt, rettet eller slettet. Den aktuelle anvendelse kan ses i kvalifikatorlisten. Skal altid udfyldes validt. <EpisodeOfCareIdentifier>Brevets_sygdoms_forloeb snummer</episodeofcareidentifier> </Letter> M </Letter> <Sender> M <Sender> <EANIdentifier>Afsenders_lokationsnummer</EANId entifier> an..35 <EpisodeOfCareIdentifi EpisodeOfCareIdentifier er reserveret til SSTs kommende forløbsmodel og er></episodeofcareide benyttes til at knytte informationer til samme sygdomsforløb. ntifier> an..35 M <EANIdentifier></EANI dentifier> EANIdentifier er kuvertafsenders lokationsnummer det vil normalt sige afsendende organisation. Såvel positiv som negativ kvittering sendes tilbage til dette nummer. <Identifier>Afsenders_ID_nummer</Identifier> an..17 M <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 <OrganisationName>Afsenders_organisation</Organi an..35 sationname> <DepartmentName>Afsenders_afdeling_el_socialomr aade</departmentname> M <IdentifierCode></Identi fiercode> M <OrganisationName></ OrganisationName> an..35 <DepartmentName></D epartmentname> IdentifierCode er kvalifikator for det anvendte kode- el. klassifikationssystem - ofte "sygehusafdelingsnummer" hvis afsender er en sygehusafdeling, "ydernummer" hvis sygesikringsyder, "kommunenummer" hvis kommune. OrganisationName er navnet i tekst på afsendende 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". DepartmentName er navnet på sygehusafdelingen hvis afsender er et sygehus, navnet på hjemmepleje distriktet hvis afsender er en kommune, titlen "læge" hvis afsender er et lægehus o.l. Udfyldes ofte med "Gadenavn" ved fysioterapeutklinikker. 31

32 XML Facitliste XTID02 FeltDef M XML TAG XML DataDefinition <UnitName>Afsenders_afdeling_el_socialdistrikt</Uni an..35 <UnitName></UnitNam tname> e> UnitName er sygehusafsnit, hvis afdeling er et sygehus, navnet (For- og efternavn) hvis afsender er en person i et lægehus, hjemmeplejegruppe hvis kommune. <StreetName>Afsenders_adresse</StreetName> an..35 <StreetName></StreetN StreetName er afsenders vejnavn og vejnummer. ame> <SuburbName>Afsenders_bostednavn</SuburbNam an..35 <SuburbName></Subur SuburbName er et evt. stednavn på afsenders primære adresse for eks.: e> bname> Mullerup, 5772 Kværndrup. <DistrictName>Afsenders_by</DistrictName> an..35 <DistrictName></Distric DistrictName er afsenders bynavn på primære adresse. tname> <PostCodeIdentifier>Afsenders_postnummer</PostC n4 <PostCodeIdentifier></ PostCodeIdentifier er afsenders postnummer på primære adresse. odeidentifier> PostCodeIdentifier> <TelephoneSubscriberIdentifier>Afsenders_telefon</ TelephoneSubscriberIdentifier> an..25 <TelephoneSubscriberI dentifier></telephones ubscriberidentifier> TelephoneSubscriberIdentifier er afsenders telefonnummer. <MedicalSpecialityCode>Afsenders_medicinske_spe ciale</medicalspecialitycode> KVA <MedicalSpecialityCode MedicalSpecialityCode er en kvalifikator for afsenders lægelige speciale. Skal ></MedicalSpecialityCo de> udfyldes, men er medicinsk speciale ikke kendt /ikke relevant benyttes kvalifikatoren "ikkeklassificeret". Se kvalifikatorliste. </Sender> M </Sender> <Receiver> M <Receiver> <EANIdentifier>Modtagers_lokationsnummer</EANId an..35 M <EANIdentifier></EANI EANIdentifier er kuvertmodtagers lokationsnummer. entifier> dentifier> <Identifier>Modtagers_ID_nummer</Identifier> an..17 M <Identifier></Identifier> Identifier er slutmodtagers sygehusafdelingsnummer, ydernummer, kommunenummer eller lokationsnummer. Identifier skal anvendes som beskrevet ved SenderIdentifier ovenfor og skal altid udfyldes validt. <IdentifierCode>Modtagers_ID_nummer_type</Identi fiercode> KVA M <IdentifierCode></Identi fiercode> IdentifierCode er kvalifikator for det anvendte kode- el. klassifikationssystem - ofte "sygehusafdelingsnummer" hvis modtager er en sygehusafdeling, "ydernummer" hvis sygesikringsyder, "kommunenummer" hvis kommune. <OrganisationName>Modtagers_organisation</Organ an..35 <OrganisationName></ OrganisationName er navnet i tekst på modtagende sygehus, lægehus eller isationname> OrganisationName> kommune. Udfyldes som for SenderOrganisationName. <DepartmentName>Modtagers_afdeling</Departmen an..35 <DepartmentName></D DepartmentName er navnet på sygehusafdeling, hjemmeplejedistrikt eller tname> epartmentname> titlen "Læge" hvis modtager er en læge i et lægehus o.l. Se beskrivelse under SenderDepartmentName. <UnitName>Modtagers_afsnit</UnitName> an..35 <UnitName></UnitNam e> UnitName er modtagende sygehusafdeling eller for- og efternavn (hvis modtager er en person i et lægehus). Se beskrivelse under SenderUnitName. <StreetName>Modtagers_adresse</StreetName> an..35 <StreetName></StreetN StreetName er modtagers primære adresse. ame> <SuburbName>Modtagers_bostednavn</SuburbNam e> an..35 <SuburbName></Subur bname> SuburbName er et evt. stednavn på modtagers primære adresse f.eks.: Mullerup, 5772 Kværndrup. 32

33 XML Facitliste XTID02 FeltDef M XML TAG XML DataDefinition <DistrictName>Modtagers_bynavn</DistrictName> an..35 <DistrictName></Distric DistrictName er modtagers bynavn på primære adresse. tname> <PostCodeIdentifier>Modtagers_postnummer</PostC n4 <PostCodeIdentifier></ PostCodeIdentifier er modtagers postnummer på primære adresse. odeidentifier> PostCodeIdentifier> </Receiver> M </Receiver> <Patient> M <Patient> Vælg mellem ( Vælg mellem ( <CivilRegistrationNumber>Patientens_CPR_nummer </CivilRegistrationNumber> Eller eller <AlternativeIdentifier>Patientens_erstatnings_CPR_n ummer</alternativeidentifier> n10 <CivilRegistrationNumb er></civilregistrationn umber> an10 <AlternativeIdentifier></ AlternativeIdentifier> CivilRegistrationNumber er patientens valide CPR-nummer og dette eller et erstatningsnummer skal altid medsendes. CPR-nummer sendes uden bindestreg. Hvis et validt cpr-nummer ikke findes sendes et erstatningsnummer i AlternativeIdentifier på præcis 10 tegn. AlternativeIdentifier er et erstatnings CPR-nummer eller et usikkert CPRnummer på præcis 10 tegn. Udfyldes hvis der ikke er angivet et validt CPRnummer i CivilRegistrationNumber. ) ) <PersonSurnameName>Patientens_efternavn</Pers an..70 M <PersonSurnameName PersonSurnameName er patientens efternavn. onsurnamename> ></PersonSurnameNam e> <PersonGivenName>Patientens_fornavne</PersonGi an..70 <PersonGivenName></ PersonGivenName er patientens fornavn(e). Fornavn bør altid medsendes. venname> PersonGivenName> <StreetName>Patientens_adresse</StreetName> an..35 <StreetName></StreetN StreetName er patientens primære vejnavn og nummer. ame> <SuburbName>Patientens_bostednavn</SuburbNam an..35 <SuburbName></Subur SuburbName er et evt. stednavn på patientens primære adresse f.eks.: e> bname> Mullerup, 5772 Kværndrup. <DistrictName>Patientens_bynavn</DistrictName> an..35 <DistrictName></Distric DistrictName er bynavn på den primære adresse. tname> <PostCodeIdentifier>Patientens_postnummer</PostC n4 <PostCodeIdentifier></ PostCodeIdentifier er postnummeret på den primære adresse. odeidentifier> PostCodeIdentifier> <OccupancyText>Patientens_stillingsbetegnelse</Oc an..35 <OccupancyText></Occ OccupancyText er patientens stillingsbetegnelse. cupancytext> upancytext> <EpisodeOfCareStatusCode>Patientens_status</Epi KVA M <EpisodeOfCareStatus EpisodeOfCareStatusCode er en kvalifikator, der angiver patientstatus. Se sodeofcarestatuscode> Code></EpisodeOfCare kvalifikatorliste. StatusCode> </Patient> M </Patient> <BookingServiceOffered> M <BookingServiceOffer Forslag til tidspunkt for anmodet ydelse ed> 33