Sundhedsfaglige anbefalinger og XML Facitliste for

(1)

XTID01-04

”Den gode XML booking”

BookingQuery BookingResult BookingConfirm

BookingList 01.06.2004

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

(2)

Indholdsfortegnelse:

Baggrund: ...3

Afsnit A: Sundhedsfaglige anbefalinger ...5

Booking mellem sundhedsvæsnets parter ...6

1. Formål ...6

2. Et typisk papirbrev ...7

3. Beskrivelse af sammenhæng mellem de fire standarder...11

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

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

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.

Mens G-EPJ forudsætter udvikling og indførelse af en ny type EPJ- systemer, 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.

(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:

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.

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.

(5)

Afsnit A

Sundhedsfaglige anbefalinger

for XML booking

XTID01-04

(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 IT- systemerne 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 e-mail 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.

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

** Rekvirering af ydelse **

Afsendt: 15.01.2004 kl. 12.01 AFSENDER:

Hillerød Sygehus Ortopædkirurgisk amb.

vestergade 9 3400 Hillerød

FORTROLIGT

KUN TIL SUNDHEDSFAGLIGT BRUG

MODTAGER:

Roskilde Amts Sygehus Køge Billeddiagnostisk afd.

Lykkebækvej 1 4600 Køge

150282-4933

Knut Odvar Mosebryggersen Grusgraven 3, 3 tv

3400 Hillerød

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 47110001

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:

15.01.2004 kl. 14.00 Senest slut:

20.01.2004 kl. 16.00

Patienten kan aldrig om:

Formiddagen Fredage I weekenderne.

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.

(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 **

FORTROLIGT

MODTAGER:

150282-4933

Knut Odvar Mosebryggersen Grusgraven 3, 3 tv

3400 Hillerød

Type: Tilbudt

ID for den bookede tid er 47114712

ID på den fremsendte forespørgsel er 47110001

BREVTEKST:

Bookede ydelser:

Røntgen af højre hofte i 2 planer.

Røntgen af venstre hofte i 2 planer.

Prioritet:

Elektiv

Mødetidspunkt:

19.01.2004 kl. 08.55 Forventet afslutning:

19.01.2004 kl. 11.00

Dette forslag til tidspunkt for de anmodede services skal bekræftes inden d. 16.01.2004 kl. 00.00

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.

(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 **

FORTROLIGT

MODTAGER:

Vælg én af følgende 2 muligheder for den tilbudte tid med ID 47114712:

V Det tilbudte tidspunkt er OK.

Afvis den tidbudte tid.

(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 **

MODTAGER:

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.

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

(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æftelses-

meddelelser.

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 IT-

system ikke returnerer BookingConfirm herpå.

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

(15)

Afsnit B

XML Facitliste

XML Booking-forespøgsel XTID01

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

(17)

XML Facitliste

XML Facitliste XTID01 FeltDef M 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_XMLbreve_01062004--!> 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 ing</AcknowledgementCode>

KVA 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>

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>Brevets_statistiknummer</Statistica lCode>

an..8 M <StatisticalCode></Stati sticalCode>

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.

(18)

<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 e>

TypeCode er kvalifikator for brevets type. Se kvalifikatorliste.

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

an..35 <EpisodeOfCareIdentifi er></EpisodeOfCareIde ntifier>

EpisodeOfCareIdentifier er reserveret til SSTs kommende forløbsmodel og benyttes til at knytte informationer til samme sygdomsforløb.

</Letter> M </Letter>

<Sender> M <Sender>

<EANIdentifier>Afsenders_lokationsnummer</EANId entifier>

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 M <IdentifierCode></Identi fierCode>

IdentifierCode er kvalifikator for det anvendte kode- el. klassifikationssystem - ofte "sygehusafdelingsnummer" hvis afsender er en sygehusafdeling,

"ydernummer" hvis sygesikringsyder, "kommunenummer" hvis kommune.

<OrganisationName>Afsenders_organisation</Organi sationName>

an..35 M <OrganisationName></

OrganisationName>

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

(19)

<DepartmentName>Afsenders_afdeling_el_socialomr aade</DepartmentName>

an..35 <DepartmentName></D epartmentName>

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>Afsenders_afdeling_el_socialdistrikt</Uni tName>

an..35 <UnitName></UnitNam 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 ame>

StreetName er afsenders vejnavn og vejnummer.

<SuburbName>Afsenders_bostednavn</SuburbNam e>

an..35 <SuburbName></Subur bName>

SuburbName er et evt. stednavn på afsenders primære adresse for eks.:

Mullerup, 5772 Kværndrup.

<DistrictName>Afsenders_by</DistrictName> an..35 <DistrictName></Distric tName>

DistrictName er afsenders bynavn på primære adresse.

<PostCodeIdentifier>Afsenders_postnummer</PostC odeIdentifier>

n4 <PostCodeIdentifier></

PostCodeIdentifier>

PostCodeIdentifier er afsenders postnummer på primære adresse.

<TelephoneSubscriberIdentifier>Afsenders_telefon</

TelephoneSubscriberIdentifier>

an..25 <TelephoneSubscriberI dentifier></TelephoneS ubscriberIdentifier>

TelephoneSubscriberIdentifier er afsenders telefonnummer.

<MedicalSpecialityCode>Afsenders_medicinske_spe ciale</MedicalSpecialityCode>

KVA <MedicalSpecialityCode

></MedicalSpecialityCo de>

MedicalSpecialityCode er en kvalifikator for afsenders lægelige speciale.

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 entifier>

EANIdentifier er kuvertmodtagers lokationsnummer.

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

IdentifierCode er kvalifikator for det anvendte kode- el. klassifikationssystem - ofte "sygehusafdelingsnummer" hvis modtager er en sygehusafdeling,

<OrganisationName>Modtagers_organisation</Organ isationName>

an..35 <OrganisationName></

OrganisationName>

OrganisationName er navnet i tekst på modtagende sygehus, lægehus eller kommune. Udfyldes som for SenderOrganisationName.

<DepartmentName>Modtagers_afdeling</Departmen tName>

DepartmentName er navnet på sygehusafdeling, hjemmeplejedistrikt eller titlen "Læge" hvis modtager er en læge i et lægehus o.l. Se beskrivelse under SenderDepartmentName.

(20)

<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 ame>

StreetName er modtagers primære adresse.

<SuburbName>Modtagers_bostednavn</SuburbNam e>

SuburbName er et evt. stednavn på modtagers primære adresse f.eks.:

<DistrictName>Modtagers_bynavn</DistrictName> an..35 <DistrictName></Distric tName>

DistrictName er modtagers bynavn på primære adresse.

<PostCodeIdentifier>Modtagers_postnummer</PostC odeIdentifier>

PostCodeIdentifier>

PostCodeIdentifier er modtagers postnummer på primære adresse.

</Receiver> M </Receiver>

<Patient> M <Patient>

Vælg mellem ( Vælg mellem (

<CivilRegistrationNumber>Patientens_CPR_nummer

</CivilRegistrationNumber>

n10 <CivilRegistrationNumb er></CivilRegistrationN umber>

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.

Eller eller

<AlternativeIdentifier>Patientens_erstatnings_CPR_n ummer</AlternativeIdentifier>

an10 <AlternativeIdentifier></

AlternativeIdentifier>

AlternativeIdentifier er et erstatnings CPR-nummer eller et usikkert CPR- nummer på præcis 10 tegn. Udfyldes hvis der ikke er angivet et validt CPR- nummer i CivilRegistrationNumber.

) )

<PersonSurnameName>Patientens_efternavn</Pers onSurnameName>

an..70 M <PersonSurnameName

></PersonSurnameNam e>

PersonSurnameName er patientens efternavn.

<PersonGivenName>Patientens_fornavne</PersonGi venName>

an..70 <PersonGivenName></

PersonGivenName>

PersonGivenName er patientens fornavn(e). Fornavn bør altid medsendes.

<StreetName>Patientens_adresse</StreetName> an..35 <StreetName></StreetN ame>

StreetName er patientens primære vejnavn og nummer.

<SuburbName>Patientens_bostednavn</SuburbNam e>

SuburbName er et evt. stednavn på patientens primære adresse f.eks.:

<DistrictName>Patientens_bynavn</DistrictName> an..35 <DistrictName></Distric tName>

DistrictName er bynavn på den primære adresse.

<PostCodeIdentifier>Patientens_postnummer</PostC odeIdentifier>

PostCodeIdentifier>

PostCodeIdentifier er postnummeret på den primære adresse.

(21)

<OccupancyText>Patientens_stillingsbetegnelse</Oc cupancyText>

an..35 <OccupancyText></Occ upancyText>

OccupancyText er patientens stillingsbetegnelse.

<EpisodeOfCareStatusCode>Patientens_status</Epi sodeOfCareStatusCode>

KVA M <EpisodeOfCareStatus Code></EpisodeOfCare StatusCode>

EpisodeOfCareStatusCode er en kvalifikator, der angiver patientstatus. Se kvalifikatorliste.

</Patient> M </Patient>

<BookingService> M <BookingService> Ydelse

<BookingQueryIdentifier></BookingQueryIdentifie r>

An..35 M <BookingQueryIdentifi er></BookingQueryIde ntifier>

Entydig ID på booking-forespørgslen fra rekvirentens side. Det anbefales at lade rekvirentens lokationsnummer eller SKS-kode helt eller delvist indgå i denne identifier, så denne ID bliver unik nationalt.

Ydelsens ID.

Ydelsens navn.

</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 rning>

Angiver at patienten generelt ikke kan om formiddagen. Feltet sættes 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.

(22)

</Limitation> </Limitation>

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>

(23)

Testeksempel

XML Booking: XTID01

<?xml version="1.0" encoding="ISO-8859-1"?>

<Sent>

</Sent>

<Identifier>KuvertNr012238</Identifier>

<AcknowledgementCode>minuspositivkvitt</AcknowledgementCode>

</Envelope>

<Identifier>BrevNr00133</Identifier>

</Authorisation>

<StatusCode>nytbrev</StatusCode>

</Letter>

<IdentifierCode>sygehusafdelingsnummer</IdentifierCode>

<OrganisationName>Frederiksborg Amt</OrganisationName>

<DepartmentName>Hillerød Sygehus</DepartmentName>

<UnitName>Kirurgisk afd. A</UnitName>

<DistrictName>Hillerød</DistrictName>

<MedicalSpecialityCode>kirurgi_sygehus</MedicalSpecialityCode>

</Sender>

(24)

<IdentifierCode>sygehusafdelingsnummer</IdentifierCode>

<OrganisationName>Roskilde Amts Sygehus Køge</OrganisationName>

<DepartmentName>Ortopædkirurgisk amb.</DepartmentName>

<StreetName>Lykkebækvej 1</StreetName>

</Receiver>

<PersonSurnameName>Mosebryggersen</PersonSurnameName>

<PersonGivenName>Knut Odvar</PersonGivenName>

<StreetName>Grusgraven 3, 3 tv</StreetName>

<DistrictName>Hillerød</DistrictName>

<EpisodeOfCareStatusCode>inaktiv</EpisodeOfCareStatusCode>

</Patient>

<ServiceName>Røntgen af højre hofte i 2 planer.</ServiceName>

</ServicePart>

<ServiceName>Røntgen af venstre hofte i 2 planer.</ServiceName>

</ServicePart>

</NotBefore>

</NotAfter>

<NotDay>Fredag</NotDay>

(25)

</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>

</afsender>

<id>

</id>

<lokalStrId>Knut Odvar Mosebryggersen</lokalStrId>

</domaene>

</identitet>

</Patient>

<id>

</id>

<patient_id>

</patient_id>

</forloeb>

<id>

(26)

</id>

<patient_id>

</patient_id>

<Art>

</primaerkode>

</Art>

<Art>

</primaerkode>

</Art>

</Intervention>

<id>

</id>

<navn>

</navn>

</tilknyttetEnhed>

</besluttetAf>

</dokumenteret>

(27)

<navn>

</navn>

</tilknyttetEnhed>

</dokumenteretAf>

<kode>Intenderet</kode>

</ejerArt>

<art>

<kode>Intenderet</kode>

</art>

<kode>Obs. for osteoporose i hofte.</kode>

</Aarsag>

<gepj_id>

</gepj_id>

<kode>elektiv</kode>

</prioritet>

</InterventionStatus>

</GEpjInterface>

</GEPJ_Elements>

<Local_Elements>

</Local_Elements>

</Emessage>

(28)

Afsnit B

XML Facitliste

XML Booking-resultat XTID02

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

(30)

XML Facitliste

<?xml version="1.0" encoding="ISO-8859-1"?> Format M Skal medsendes som en kopi af den viste XML deklaration

<!--MedCom_De_gode_XMLbreve_01062004--!> 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 ing</AcknowledgementCode>

KVA 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>

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

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>Brevets_statistiknummer</Statistica lCode>

an..8 M <StatisticalCode></Stati sticalCode>

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.

(31)