Import / export - filformat til brug for flytning af patientdata.

(1)

30.10.2009 – til høring Side 1 af 69

Import / export - filformat

til brug for flytning af patientdata.

PLO-format version 3.0 – OIO-XML

PLO-format Styregruppen, Trondhjemsgade 9, DK 2100 København Ø

(2)

Formål

Version 2.50 af det gammelkendte PLO import/export-filformat tilpassede udvekslingsformatet til en mere ”moderne” udgave, hvor der kan gøres brug af en række standardværktøjer ifm den praktiske implementeringsopgave i et givet system. Version 3.0 er en opgradering af dette format til understøttelse af OIO-XML for dermed at opnå at formatet placeres som en del af de

fællesoffentlige XML-udvekslingsstandarder.

En vigtig gevinst ved omlægningen til OIO-XML, er understøttelsen af NDR 3.2 (Navngivnings- og designregler version 3.2), der giver et sæt af spilleregler for opbygningen af skemaer. Under NDR 3.2. er der faste regler for navngivning og struktur, der øger læseligheden af det overførte XML væsentligt.

I forhold til version 2.50 er det tilstræbt at lave så få ændringer som muligt i forhold til semantik og valideringsregler. Dette skyldes ønsket om at inducerer så få ændringer i de implementerende systemer som muligt. Der er visse steder sket en opstramning af strukturen i retning af en mere ensartet opbygning inspireret af OIO-XML. Denne opstramning på struktur og indhold giver - sammen med nogle få regler for indlæsning, udlæsning, opbevaring og videreforsendelse af PLO- filer i et givet system - mulighed for at kunne opfylde det overordnede mål: ”intet må gå tabt i forbindelse med flytning af elektroniske patientjournaler”.

Formatet understøtter ligesom tidligere udgaver export/import én enkelt patients data og hele patientdatabaser. Der er dog nu også i forbindelse med flytning af en patient tilføjet mulighed for at kunne eksportere flere udgaver af den samme patient. Da man ved en sådan flytning skal

videresende alle tidligere versioner af patientens data, anbefales det, at man i modtagersystemerne skal kunne foretage selektiv import af patientdata på basis af en række parametre. Endelig er der åbnet mulighed for at kunne flytte dele af én enkelt patients journal.

Af hensyn til overskueligheden indeholder indeværende dokument beskrivelse af PLO 3.0 formatets strukturer til håndtering af headere, stamdata og kliniske data, mens de simple typer er

dokumenteret i et separat bilag, hvor også den detaljerede mapningen mellem PLO format 2.50 og PLO format 3.0 er beskrevet i et særskilt afsnit.

(3)

Dokumenthistorik

Release Dato Ansvarlig Beskrivelse

3.0 release 1 5.11.2009 Ove Frost Sørensen,

Silverbullet

Første udkast til OIO- XML-version

Silverbullet

Kode-referencer omlagt til generisk struktur.

Silverbullet

Tilføjet strukturer til anvendelse for tandlæger 3.0 release 4 29.06.2010 Ove Frost Sørensen,

Silverbullet

Tilføjet BehandlerStruktur, UdenlandskAdresseStruktur samt nestede

AnatomiKodeStrukturer

Silverbullet

Revideret efter kursus for lægesystemleverandører

(4)

Indholdsfortegnelse

Indhold

Formål ... 2

Dokumenthistorik... 3

Indholdsfortegnelse ... 4

PLO 3.0 Principper og regler ... 6

Ændringer i release 2 ... 10

Ændringer i release 4 ... 12

Header strukturer ... 13

PLOFormatStruktur... 13

PLOUdtraekStruktur ... 14

PLOHeaderStruktur ... 15

PatientUdtraekStruktur: ... 18

Stamdata ... 20

StamdataStruktur:... 20

PaaroerendeStruktur: ... 24

Kliniske data ... 26

BehandlerSamling ... 26

BehandlerStruktur ... 28

CaveSamling ... 29

CaveStruktur ... 30

VaccinationSamling ... 32

VaccinationStruktur ... 33

NoteSamling ... 35

NoteStruktur ... 36

DiagnoseSamling ... 38

DiagnoseStruktur ... 39

LabSkemaSamling ... 42

LabSkemaStruktur ... 43

BoerneSkemaSamling ... 46

BoerneSkemaStruktur ... 47

BoerneSkemaAnalyseStruktur ... 48

MedicinOrdinationSamling ... 50

(5)

MedicinOrdinationStruktur ... 51

MedicinEnkeltOrdinationStruktur ... 53

PraeparatStruktur ... 56

ReferenceSamling ... 58

ReferenceStruktur ... 58

BinaerSamling ... 60

BinaerStruktur ... 61

InterventionSamling ... 64

InterventionStruktur ... 65

ObservationSamling ... 67

ObservationStruktur ... 68

(6)

PLO 3.0 Principper og regler

Filstruktur

Filformatet er opbygget som XML-format, der i sig selv betyder overholdelse af en række regler vedr. syntaks. Men da denne standard i sig selv er ret åben, er der lagt en række begrænsninger ind, som gør, at det er overkommeligt f.eks. ikke at skulle kunne håndtere ethvert valg af tegnsæt.

Følgende grundregler gælder for formatet:

1) UTF8 skal altid bruges som tegnsæt - i nuværende såvel som fremtidige versioner.

(<?xml version="1.0" encoding="utf-8" ?>)

2) Både den nuværende og fremtidige versioner af xml PLO_PatientData har hver sine skemaer for validering af dataopbygning og indhold - f.eks.:

<xs:schema xmlns=”http://rep.oio.dk/...”

xmlns:main=”http://rep.oio.dk/...”

xmlns:com=”http://rep.oio.dk/………”

xmlns:plo="urn:oio:medcom:plo:2009.12.31"

targetNamespace="urn:oio:medcom:plo:2009.12.31"

xsi:schemaLocation="http://rep.oio.dk/…./../PLOUdtrae kStruktur.xsd">

<xs:element name="PLOUdtraekStruktur"> .... osv

3) En xml-PLO-fil kan nu kun indeholde data for nul eller 1 patient - et totaludtræk fra en klinik vil altså indeholde mange enkelte xml-filer. En samlet PLO-forsendelse af én patient kan indeholde flere forskellige filer med hver sin version af PLO-formatet og dermed flere forskellige skemaer for validering. Enhver version af xml-PLO filen har sit eget xml-skema.

Således er det altid muligt at validere en given version op mod versionens originale skema.

4) Tidligere ikke XML-udgavers oplysninger vedr. versions-nummer, afsender, afsenderID … udtræksdato mm. bliver således nu en uadskillelig del af hver sin PLO-fil for det pågældende dataudtræk for en patient.

5) Der findes xml filer med nul eller én patient, - og med komplet eller delvise patientdata. Typisk vil disse eksempler af PLO dataudtræk finde generel anvendelse:

Dataudtræk PLOformat type

1) Totaludtræk af én patient ”total”

2) Deludtræk af én patient ”delvis”

Som en speciel ting er det muligt at generere en xml-fil med nul patienter. Dette benyttes ved ekstern forespørgsel (p-epj).

N.B.: Totaludtræk af hele patientdatabaser anbefales altid at håndteres af afsender- og modtagersystemhuset og ikke som ”normal” forsendelse.

N.B.: Dataudtræk af typen ”delvis” er at sammenligne med almindelige meddelelser på linie med f.eks. epikriser (se bemærkningerne under punkt 12).

(7)

30.10.2009 – til høring Side 7 af 69 6) Det er ikke længere tilladt at benytte selvopfundne datanavne eller selvopfundne sektioner –

med andre ord skal en PLO-fil (i en given version) altid kunne valideres med det til versionen hørende skema.

7) Evt. nyt binært filindhold skal som konsekvens af pkt. 6) godkendes og dokumenteres.

8) Datoformatet er fast og indgår som en datatype i formatet (yyyy-mm-dd hh:mm:ss). I visse tilfælde er der behov for at angive tal i strenge, og i disse situationer angives tal uden tusinde separator og med komma som decimal separator.

9) Ligeledes indgår nu en "KompleksTekstType" type i stedet for det gamle ftx-segment, hvilket gør det muligt, at man i videst mulig omfang kan benytte copy/paste funktionaliteten fra andre windowsprogrammer, mindst indeholdende mulighed for ”hårdt” linieskift, fed, kursiv, understreg, fast pitch / proportionalskrift. KompleksTekstType er et veldefineret subset af OO- XML og er således konformant til OIO-XML.

10) ”atr” - datataget udgår som en logisk følge heraf.

11) Der er indført en objektreference - endnu en type "referencetekst" - som indgår i 2 sektioner ud over stamdatasektionen. Der skal være reference til ethvert objekt i binærsektionen og stamdatasektionen er ”default”-stedet for resten af de referencer, der ikke er nævnt i note- og labsektio- nen. Reference-id’et skal være éntydigt inden for samme xml-PLO fil. Bemærk at der kan være flere xml-PLO filer af samme patient, hvorfor det modtagende system herefter sikrer sin egen integritet for hele patientdatabasen i forhold til navngivning af entydig referencehenvisninger til evt. vedhæftede objekter i binærsektionen fra alle denne patients binærsektioner.

12) Regler vedr. modtagelse, udpakning, indlæsning, opbevaring og videreforsendelse af PLO-filer:

a) Modtagne ”PLOformat” filer af typen ”total” skal altid gemmes ”under” eller i tilknytning til patienten efter ingen, hel eller delvis indlæsning.

b) Modtages flere ”PLOformat” filer af samme cpr-nummer, skal alle af typen ”total”

gemmes ”under” eller i tilknytning til patienten efter ingen, hel eller delvis indlæsning.

c) Modtagne ”PLOformat” filer af typen ”delvis” kan efter fuld indlæsning slettes. De indlæste data anses herefter - på linie med indlæste epikriser - som en del af lægens selvproducerede journal og sendes derfor videre når lægen evt. geneksporterer patienten til ny læge.

d) Afsendes en patients elektroniske journal til et nyt lægehus, gøres det ved at medsende alle gemte, ”gamle” PLO-filer på patienten plus patientens aktuelle aktive journal fra det pågældende lægehus.

e) Det anbefales, at systemerne udvikler brugervenlige import /eksport funktioner af PLO-filerne, således at dette princip gøres let anvendeligt og frem for alt overholdes mht. princippet om, at ”intet må gå tabt undervejs”. Specielt ved afsendelse af ”total”- forsendelser skal det afsendende system sikre, evt. selektivitetsfunktionalitet i forbindelse ”delvis-filer” ikke bryder denne regel.

(8)

30.10.2009 – til høring Side 8 af 69 f) En totalforsendelse af enkelt patient vil indeholde én eller et antal xml-PLO filer af

samme patient. Disse filer er entydigt mærket således, at de alle har en unik

identifikation (PakkeIdentifikator), sekvensnummer (SekvensNummerIdentifikator) og totaludtræksnummer (UdtraekAntal) (for denne forsendelse), der skal forstås således at sekvensnummer 1 er det afsendende systems aktuelle totale eksportfil, og resten af filerne fra sekvensnummer 2 og opefter er ”bilag” (tidligere - af afsendersystemet - modtagne versioner af xml-PLO filer af denne patient).

g) PLO-filer af typen ”delvis” er hovedsagelig tænkt som:

1) en mulig struktureret ”super-meddelelse”, der gør det let at flytte alle data struktureret fra afløserlægen til egen læge ifm ferier/udannelser m.m. Dette som et alternativ til en simpel epikrise.

2) udtræk til brug ifm forsikringsforespørgsler, indberetninger, statistik, kvalitetssikring eller anden selektiv udlæsning.

13) Medicinordinationer, på hvilke der er registreret negativt samtykke, medtages ikke i overførslen via PLO-Formatet. Medicinordinationerne vil være tilgængelige i FMK såfremt patienten giver samtykke til adgangen.

14) Tidligere indeholdt PLO-formatet en type med de mulige værdier for praksislægesystem. Da formatet på længere sigt er tiltænkt en bredere anvendelse, for eksempel til kommunikation mellem tandlæger og fysioterapeuter, er denne type fjernet og erstattet af et ustruktureret streng.

15) Der er konsekvent indført en (optionel) mulighed for at angive behandler (klinisk ansvarlig) på kliniske registreringer for at håndtere de tilfælde, hvor flere klinikere er involveret i

behandlingen af patienten (relevant for tandlæger). Behandlerne overføres i en indledende samling af BehandlerStrukturer, og der refereres til behandlere gennem BehandlerIdenfikator elementer. Såfremt der ikke angives Behandler på en klinisk registrering antages

registreringerne foretaget af den yder, der er angivet i oplysningerne i KlinikStruktur i Stamdata.

(9)

30.10.2009 – til høring Side 9 af 69 Filransport

Traditionel forsendelse:

Filen eller filerne kan enten "transporteres" på magnetisk eller elektronisk medie - dvs diskette, CD- ROM, RAM-stick eller evt. flytbar harddisk. Forudsætningen er dog, at der i modtager- og afsendersystemernes applikationer findes "brugervenlige" rutiner, der kan adressere disse mediers læse- og skriveenheder.

Det anbefales altid at benytte elektronisk forsendelse ved udtræk af enkelt patientdata.

Elektronisk forsendelse:

Elektronisk forsendelse vil normal ske ved xml-forsendelse via VANS. Eller evt. ved direkte Webservice ”forsendelse” til modtager eller fra afsender eller deres respektive databrokere/VANS.

Uanset elektronisk forsendelsesmetode anbefales det, at der sikres en kvitteringsfunktionalitet, som kan håndteres / kontrolleres på brugerniveau.

Forsendelseskuvert:

Forsendelse af en PLO-fil kan ske vha. en MEDBIN edifact eller XML-konvolut. Ved xml-forsendelse, anbefales det, at der anvendes samme konvolut, uanset om der benyttes flytning via VANS eller flytning via Webservice. Eksempel:

Skemaeksempel for forsendelseskuvert:

Der er i MedCom regi igangsat et XML-kuvert projekt, som forventes pilottestet inden udgangen af 2007. Denne kuvert vil muligvis også finde anvendelse for al anden VANS-baseret forsendelse i XML-kuverter, idet den også vil kunne bære alle EDIFACT-forsendelser.

Nedenstående eksempel er IKKE en del af PLO-format standarden, men blot et foreløbigt

”førsteforslag”, som har været udgangspunktet i MedCom-kuvert projektet.

(En MedCom-projektgruppe arbejder pt. på den endelig definition)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="MEDCOMENVLOPE"

elementFormDefault="qualified">

<xs:element name="XMLEnvelope">

<xs:complexType>

<xs:element name="MedComEnvelopeHeader">

<xs:element name="SenderEAN" type="xs:string"/>

<xs:element name="ReceiverEAN" type="xs:string"/>

<xs:element name="EnvelopeIdentifier" type="xs:string"/>

<xs:element name="EnvelopeTimestamp" type="xs:string"/>

<xs:element name="ReceiptRequest">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="0"/>

<xs:enumeration value="1"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="ContentType">

(10)

30.10.2009 – til høring Side 10 af 69 <xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="XML"/>

<xs:enumeration value="EDIFACT"/>

<xs:enumeration value="HL7"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="MessageIdentifier" type="xs:string"/>

<xs:element name="MessageDokumentType" type="xs:string"/>

<xs:element name="MessageDokumentTypeVersion" type="xs:string"/>

</xs:element>

<xs:element name="MedComEnvelopeContent">

<xs:element name="Dokument" type="xs:base64Binary"/>

</xs:element>

</xs:complexType>

</xs:element>

</xs:schema>

N.B.: Den ”rå” XML PLO-fil vil blive placeret i base64-elementet.

Alternativt kan en MEDBIN forsendelse med samme ”rå” indhold anvendes – som i dag.

Ændringer i release 2

Under kravsafdækningen i forhold til anvendelse af PLO-XML formatet til udveksling af journaler mellem tandlægesystemer stod det klart at der var et behov for at udvide standarden med mulighed for håndtering af et par nye klassifikationer (ICD-DA, FDI, Haderup). Release 1 af PLO-XML formatet fulgte det princip, at der er en konkret XML-type for hvert kodesystem (ICD10kode, ICD10Struktur, ICPCKode, ICPCStruktur, …). Såfremt dette princip fastholdes skulle vi altså tilføje typer som ICDDAKode, ICDAStruktur, etc…

Ulempen ved denne strategi er, at kernestandarden skal opdateres hver gang, der er behov for at understøtte en ny klassifikation. Derfor blev det besluttet at ændre denne strategi, således at der laves et sæt af generiske typer til at håndtere koder. Jeg har indarbejdet denne ændring i vedhæftede forslag.

Ændringen har følgende konsekvenser:

- ICD10Kode, ICD10KodeStruktur, ICPCKode, ICPCKodeStruktur, ICPCEKode og ICPCEKodeStruktur, ICPCTekstIndikator, OrganKapitelStruktur,

OrganKapitelIdentifikator udgår.

- Der indføres nye typer: Kode, KodeStruktur, KlassifikationsIdentifikator, AekvivalentKodeStruktur.

- KodeStruktur indeholder: KlassifikationsIdentifikator, Kode, KodeTekst, NoteTekst, samt en liste af ækvivalente koder (AekvivalentKodeStruktur).

- AekvivalentKodeStruktur indeholde KlassifikationsIdentifikator, Kode og KodeTekst. Der er derfor kun muligt at lave ækvivalens imellem koder i eet niveau.

- ICPCE håndteres ved at sende ICPC-koden med en ækvivalent ICD10-kode.

(11)

30.10.2009 – til høring Side 11 af 69 - Betydningen af ICPCTekstIndikator i ICPCE implementeres ved at KodeTekst på

hovedkoden er optionel. Såfremt den er angivet, er det ICPC-kodeteksten. Hvis den ikke er angivet, skal den ækvivalente ICD10-kodetekst anvendes.

- Felterne StartDato, SlutDato og ForløbsIdentifikator (Fra ICPCEStruktur) flyttes til DiagnoseArtStruktur. Disse felter er logisk set ikke en del af kodeangivelsen, men mere registreringer i forhold til den kliniske fastslåelse af diagnosen. At flytte dem til DiagnoseArtStruktur betyder, at disse felter (optionelt) også kan anvendes for andre klassifikationer end ICPCE.

Der anvendes følgende klassifikationsIdentifikatorer:

KlassifikationsIdentifikator Klassifikationssystem

ICD10 International Statistical Classification of

Diseases and Related Health Problems 10th Revision

ICPC International Classification of Primary Care

ICPCE (ICPC-2) International Classification og

Primary Care – 2^nd Edition.

ORGANKAPITEL Organkapitelbetegnelse (A, B, D, F, H, K, L, N,

P, R, S, T, U, W, X, Y, Z) fra ICPC. Benyttes til en overordnet kodning af diagnose.

ICD-DA International Classification of diseases to

Dentistry and Stomatology (for tandlæger)

ATC Anatomical Therapeutical Chemical

classification system. Anvendes til angivelse af medicinallergier.

FDI Federation Dentaire International (tandlæger)

FNUX-BK FNUX Behandlingskompletteringen (tandlæger)

FNUX-PA FNUX Paradontosekoder (tandlæger)

FNUX-DK FNUX Diagnosekompletteringen (tandlæger)

(12)

Ændringer i release 4

I forbindelse med implementering af formatet til overførsel af tandlægejournaler har der vist sig et behov for at registrere hvilke (ud af mange) behandlere, der har udført interventioner, stillet diagnoser eller foretaget observationer. Dette er gennemført konsekvent på den måde, at det er muligt at angive en liste (BehandlerSamling) af behandlere, der har været involveret i patientens behandling, herunder deres individuelle ydernumre og autorisationsnumre. Fra de enkelte registreringer er det muligt at referere til disse behandlere. Angivelse af behandlere er optionel på alle registreringer.

Der har været et ønske om at kunne angive CVR-numre og adresse på klinik. Dette har ført til indførsel af KlinikStruktur, hvor Yderidentifikator og SORIdentifikator er flyttet til.

CaveStruktur er udvidet med mulighed for at angive kode for anden ikke-medicin relateret allergi, eksempelvis guldallergi. Dette er implementeret ved at ændre den hidtidige AtcKode til den mere generiske AllergiKodeStruktur. Medicinske allergier angives ved at anvende klassifikationskoden

”ATC”.

AnatomiKodeStruktur er udvidet med muligheden af at angive nestede AnatomiKodeStrukturer.

Dette anvendes eksempelvis til angivelse af tandflader, hvor den ”yderste” AnatomiKodeStruktur angiver tanden, mens de ”indre” angiver de berørte tandflader.

angivelse

Der er tilføjet mulighed for at angive udenlandske adresser i UdenlandskAdresseStruktur.

Ændringer i release 5

PLO-formatet anvender OIO-skemaer til repræsentation af personnavne og adresser. Set i lyset af at basiskilden til disse informationer er det danske sygesikringskort, som har en enklere model for personnavne og adresser, er det valgt at anvende OIO-skemaet på en måde, der svarer til sygesikringskortets strukture. Derfor overføres mellemnavn i samme felt som fornavn, mens adresselinien (StreetName) også indeholde husnummer, Floor og Suite. Bemærk, at på gund af at XKom_AddressPostal skemaet har StreetBuildingIdentifier som et mandatory element, har det været nødvendigt at kopiere skemaet ind i plo:DanskAdresseStruktur skemaet. Dette betyder, at PLO-formatet anvender OIO-XML’s navngivning for adresse elementerne, men ikke skemaet.

I forbindelse med diskussioner omkring migration frem mod det nye format stod det klart, at ikke alle systemer er i stand til at skelne entydigt mellem forskellige behandlere. For visse systemer registreres kun initialer på behandleren. Ved genbrug af initialer er det derfor muligt at der findes registreringer med samme initial, som ikke nødvendigvis refererer til samme behandler. For at tilgodese disse systemer, er der generelt indført muligheden af at vælge mellem (Choice)

BehandlerIdentifikator og BehandlerInitial i kliniske registreringer. Det forventes, at anvendelsen af BehandlerInitial på denne måde vil mindskes over tid.

FMK’s model for angivelse af behandlere (DoctorStructure) har været reviewet og fundet at være et subset af BehandlerStructure.

FMK’s model af medicinordinering er blevet indarbejdet på den måde, at der er tilføjet en

(13)

30.10.2009 – til høring Side 13 af 69 ordinationsversion til PraeparatStruktur, Doseringsmønsteret er udbygget med valgfri angivelse af mere detaljerede doseringsmønstre. Desuden er administrationsvejen tilføjet.

For alle angivelser af tidsstempler for klinisk information er der indført mulighed for at vælge (choice) mellem at angive Dato eller Dato/Tid.

Header strukturer

PLOFormatStruktur

”PakkeIdentifikator”, ”SekvensNummerIdentifikator” og ”UdtraekAntal” er data til brug for håndtering af evt. dobbelt-forsendelser og forsendelser af totaludtræk med én eller flere bilag.

PLOUdtraekStruktur består af et antal enkelt udtræk som hver især består af en header (PLOHeaderStruktur) og et indhold (PatientUdtraekStruktur).

Element Type Beskrivelse

PakkeIdentifikator String Unik identifikation af en PLO-fil.

SekvensNummer- Identifikator

int Sekvensnummeret for det enkelte udtræk, på den måde at værdien 1 er det afsendende systems aktuelle totale udtræksfil, mens værdierne 2,3,... er bilag svarende de PLO-filer, det afsendende system har modtaget fra andre systemer.

UdtraekAntal int Det samlede antal af PLO udtræk i en PLO-fil.

PLOUdtraek- Struktur

PLOUdtraekStruktur- Type

Indeholder data svarende til et enkelt udtræk af data for en enkelt patient fra et lægepraksissystem.

PLOFormatStruktur.xsd

<?xml version="1.0" encoding="UTF-8"?>

Kommenterede [N1]: Hvorfor kan der være flere

PLOFormatStrukturer? (1 til mange er angivet). Ifølge regel 3 må der kun være op til én patientudtræk for hver XML fil, så derfor kan der ikke forekomme flere PLOFormatStuktur’er i samme XML fil.

Kommenterede [N2]: Fælles format ønskes. Jeg foreslår en GUID/UUID som eksemplet anvender.

Kommenterede [N3]: Som jeg har forstået denne regel så må startes der forfra med sekvensnummer 1 for hver ny patient?

Kommenterede [N4]: Igen. Er det for hver patient?

(14)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:plo="urn:oio:medcom:plo:2009.12.31" targetNamespace="urn:oio:medcom:plo:2009.12.31"

elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0" xml:lang="DA">

<xs:include schemaLocation="PLOUdtraekStruktur.xsd"/>

<xs:include schemaLocation="PakkeIdentifikator.xsd"/>

<xs:include schemaLocation="SekvensNummerIdentifikator.xsd"/>

<xs:include schemaLocation="UdtraekAntal.xsd"/>

<xs:element name="PLOFormatStruktur" type="plo:PLOFormatStrukturType"/>

<xs:complexType name="PLOFormatStrukturType">

<xs:sequence maxOccurs="unbounded">

<xs:element ref="plo:PakkeIdentifikator"/>

<xs:element ref="plo:SekvensNummerIdentifikator"/>

<xs:element ref="plo:UdtraekAntal"/>

<xs:element ref="plo:PLOUdtraekStruktur"/>

</xs:sequence>

</xs:complexType>

PLOFormatStruktur.xsd.meta.xml

<Metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://rep.oio.dk/infostructurebase/schemas/2004/09/13/">

<Title>PLOFormatStruktur</Title>

<DescriptionDanish>Indeholder et udtræk af patient data fra et praksislægesystem.

</DescriptionDanish>

</DescriptionStructure>

</Metadata>

PLOUdtraekStruktur

Element Type Beskrivelse

PLOHeaderStruktur PLOHeader- StrukturType

Indeholder metadata om PLO udtræksfilens indhold, eksempelvis ydernummer og afsendersystem.

PatientUdtraek- Struktur

PatientUdtraek- StrukturType

Struktur indeholdende udtrækkets data vedrørende en enkelt patient

PLOUdtraekStruktur.xsd

<xs:include schemaLocation="PLOHeaderStruktur.xsd"/>

<xs:include schemaLocation="PatientUdtraekStruktur.xsd"/>

<xs:element name="PLOUdtraekStruktur" type="plo:PLOUdtraekStrukturType"/>

<xs:complexType name="PLOUdtraekStrukturType">

<xs:sequence>

<xs:element ref="plo:PLOHeaderStruktur"/>

(15)

30.10.2009 – til høring Side 15 af 69 <xs:element ref="plo:PatientUdtraekStruktur" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

PLOUdtraekStruktur.xsd.meta.xml

<Title>PLOUdtraekStruktur</Title>

<DescriptionDanish>Indeholder data svarende til et enkelt udtræk af data for en enkelt patient fra et lægepraksissystem.</DescriptionDanish>

</Metadata>

PLOHeaderStruktur

(16)

Element Type Beskrivelse

UdtraeksIdentifi- kator

xs:string Mandatory, unikt id på udtrækket.

UdtraeksVersion- Identifikator

xs:string Mandatory, angivelse af PLO-format versionsnummer DelvistUdtraek-

Indikator

xs:boolean Mandatory, angiver om der er tale om et delvist udtræk.

SystemIdentifikator xs:string Mandatory, angiver hvilket system der har genereret (men ikke nødvendigvis afsendt) filen.

AfsenderNavn xs:string Mandatory, angiver et navn på afsendersystemet.

Mellem 1 og 70 tegn.

KlinikStruktur KlinikStrukturType Optionel, angiver oplysninger vedrørende afsendende klinik.

UdtraekPatientAntal xs:int Mandatory, angiver hvor mange patienter der er indeholdt i filen, 0 eller 1.

StartDatoTid xs:dateTime Mandatory, angiver fra dato og tid for den periode patientdata i filen tilhører.

SlutDatoTid xs:dateTime Mandatory, angiver til dato og tid for den periode patientdata i filen tilhører.

DatoTid xs:dateTime Mandatory, angiver den dato og tid hvor filen er genereret.

PLOHeaderStruktur.xsd

<xs:include schemaLocation="UdtraeksIdentifikator.xsd"/>

<xs:include schemaLocation="UdtraeksVersionIdentifikator.xsd"/>

<xs:include schemaLocation="SystemIdentifikator.xsd"/>

<xs:include schemaLocation="AfsenderNavn.xsd"/>

<xs:include schemaLocation="KlinikStruktur.xsd"/>

<xs:include schemaLocation="UdtraekPatientAntal.xsd"/>

<xs:include schemaLocation="StartDatoTid.xsd"/>

<xs:include schemaLocation="SlutDatoTid.xsd"/>

<xs:include schemaLocation="DatoTid.xsd"/>

<xs:element name="PLOHeaderStruktur" type="plo:PLOHeaderStrukturType"/>

<xs:complexType name="PLOHeaderStrukturType">

<xs:sequence>

<xs:element ref="plo:UdtraeksIdentifikator"/>

<xs:element ref="plo:UdtraeksVersionIdentifikator"/>

<xs:element ref="plo:SystemIdentifikator"/>

<xs:element ref="plo:AfsenderNavn"/>

<xs:element ref="plo:KlinikStruktur" minOccurs="0"/>

<xs:element ref="plo:UdtraekPatientAntal"/>

<xs:element ref="plo:StartDatoTid"/>

<xs:element ref="plo:SlutDatoTid"/>

Kommenterede [N5]: Fælles format ønskes. Jeg foreslår en GUID/UUID som eksemplet anvender.

Kommenterede [N6]: Igen format ønskes F.eks 300, 3.00, 3,00

Kommenterede [N7]: Er det en kvalifikator (nvx) eller er det fri tekst? Evt. med systemets versionsnummer? (NOVAX 16.x.x.x)

Kommenterede [N8]: Hvorfor er denne tid vigtig (mandatory)?

Kommenterede [N9]: Hvorfor er denne tid vigtig?

(17)

30.10.2009 – til høring Side 17 af 69 <xs:element ref="plo:DatoTid"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

PLOHeaderStruktur.xsd.meta.xml

<Title>PLOHeaderStruktur</Title>

<DescriptionDanish>Indeholder metadata om PLO udtræksfilens indhold, eksempelvis ydernummer og afsendersystem.

</Metadata>

(18)

PatientUdtraekStruktur:

Som det fremgår, har PLO-formatet i version 3.0 indført OIO-begrebet ”Samling” på overniveau for hvert af typerne af kliniske data i udtrækket. Årsagen til dette er dels et ønske om konformans til OIO-XML men også et ønske om ensartet semantisk opdeling mellem repeterende elementer, hvilket vil lette parsingen af formatet.

PatientUdtraekStruktur.xsd

Kommenterede [N10]: Egne sektioner er ikke tilladt mere. Det er ok, men hvordan sender man så aftalte data mellem systemerne?

SEI koder vedr. indberetning, SNOMED moder.

Overvejelser til andre samlinger vi kunne få brug for:

- Refraktion - Audio

-Undersøgelse (måske) - Behandling (SEI ligger her)

Klart nok er de fleste til speciallæger og spørgsmålet er om de nogen sinde vil udveksle journaler via PLO formatet.

Vi oplever at øjenlæger bruger PLO til at sende til hinanden.

(19)

30.10.2009 – til høring Side 19 af 69 xmlns:plo="urn:oio:medcom:plo:2009.12.31" targetNamespace="urn:oio:medcom:plo:2009.12.31"

<xs:include schemaLocation="StamdataStruktur.xsd"/>

<xs:include schemaLocation="BehandlerSamling.xsd"/>

<xs:include schemaLocation="NoteSamling.xsd"/>

<xs:include schemaLocation="CaveSamling.xsd"/>

<xs:include schemaLocation="DiagnoseSamling.xsd"/>

<xs:include schemaLocation="LabSkemaSamling.xsd"/>

<xs:include schemaLocation="BoerneSkemaSamling.xsd"/>

<xs:include schemaLocation="MedicinOrdinationSamling.xsd"/>

<xs:include schemaLocation="ReferenceSamling.xsd"/>

<xs:include schemaLocation="BinaerSamling.xsd"/>

<xs:include schemaLocation="VaccinationSamling.xsd"/>

<xs:include schemaLocation="InterventionSamling.xsd"/>

<xs:include schemaLocation="ObservationSamling.xsd"/>

<xs:element name="PatientUdtraekStruktur" type="plo:PatientUdtraekStrukturType"/>

<xs:complexType name="PatientUdtraekStrukturType">

<xs:sequence>

<xs:element ref="plo:StamdataStruktur"/>

<xs:element ref="plo:BehandlerSamling" minOccurs="0"/>

<xs:element ref="plo:CaveSamling" minOccurs="0"/>

<xs:element ref="plo:VaccinationSamling" minOccurs="0"/>

<xs:element ref="plo:NoteSamling" minOccurs="0"/>

<xs:element ref="plo:DiagnoseSamling" minOccurs="0"/>

<xs:element ref="plo:LabSkemaSamling" minOccurs="0"/>

<xs:element ref="plo:BoerneSkemaSamling" minOccurs="0"/>

<xs:element ref="plo:MedicinOrdinationSamling" minOccurs="0"/>

<xs:element ref="plo:ReferenceSamling" minOccurs="0"/>

<xs:element ref="plo:BinaerSamling" minOccurs="0"/>

<xs:element ref="plo:InterventionSamling" minOccurs="0"/>

<xs:element ref="plo:ObservationSamling" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

PatientUdtraekStruktur.xsd.meta.xml

<Title>PatientUdtraekStruktur</Title>

<DescriptionDanish>Struktur indeholdende udtrækkets data vedrørende en enkelt patient.</DescriptionDanish>

</Metadata>

(20)

Stamdata

StamdataStruktur:

Element Type Beskrivelse

CPRnummerIdentifi- (OIO-XML) Mandatory, patientens cprnummer

(21)

30.10.2009 – til høring Side 21 af 69 kator CPR_PersonCivilRegistrationIdentifi

er

uden bindestreg AlternativPerson

Identifikator

xs:string Person identifikation, der ikke er et

Validt CPR-nummer, eksempelvis erstatnings CPR-numre eller grænsegængernumre.

FoedselsDato xs:date Mandatory, Patientens fødselsdato

NationalitetKode NationalitetKodeType Optional, patientens nationalitet angivet med en 3 bogstavkode.

Datagrundlag: ”MedCom Landekoder – recept”.

PersonKoenKode PersonKoenKodeType Mandatory, Patientens køn, værdier: ”kvinde” eller ”mand”.

(Foedselsdato og koen er nødvendige pga. cprnumre hvor sidste ciffer har en anden betydning).

StillingsbetegnelseNav n

xs:string Optionel, patientens evt.

stillingsbetegnelse. Mellem 1 og 35 tegn.

PersonNavnStruktur (OIO-XML)

PersonNameStructureType

Mandatory, Patientens navn

PersonKaldeNavn xs:string Optionel, Patientens eventuelle

kaldenavn. Op til 35 tegn DanskAdresseStruktur (OIO-XML)

AddressPostalType

Optionel, Patientens adresse UdenlandskAdresse-

Struktur

(OIO-XML)

SecondaryPostalLabelType

Optionel, Patientens udenlandske adresse.

KommuneKode (OIO-XML)

Cpr:AuthorityCodeType

Optionel, Kode for patientens hjemkommune. Streng indeholdende op til 4 cifre.

RegionsKode (OIO-XML)

Cpr:AuthorityCodeType

Optionel, Kode for patientens hjemregion. Streng indeholdende op til 4 cifre.

Sygesikringsgruppe- Identifikator

SygesikringsgruppeIdentifikatorType Mandatory, Patientens sygesikringsgruppe, værdi 1-9.

TelefonNummer- Struktur

TelefonNummerStrukturType Optionel, Patientens evt.

telefonnumre, op til 10 forskellige telefonnumre.

EmailAdresseStruktur EmailAdresseStruktur Optionel, Patientens evt.

emailadresser, op til 5 forskellige emailadresser.

BehandlerIdentifikator BehandlerIdentifikatorType Mandatory, angiver patientens behandler vha. autorisationsid. 5 tegn fra mængden:

[0-

9BCDFGHJKLMNPRSTVXYZ]

Kommenterede [N11]: Jeg mener at kommunekode kun er3 cifre.

Kommenterede [N12]: Mindre detalje men jeg tror regionskode kun kan være 3 cifre 080, 081 osv.

Kommenterede [N13]: Er ked af at det stadig er aktuelt at blande information om patientens sygesikringsgruppe og -status.

Kommenterede [N14]: Var der ikke bedre med en reference til en behandler i BehandlerSamling? Evt. identificeret med autorisationskoden eller initialer.

Åbner muligheder for at have en behander der måske ikke har autorisationsid? Vil det forekomme (privathospitaler, sundhedscentre mv.).

Jeg har fået bekræftet at ikke alle behandlere har autorisationsid hos vores kunder.

(22)

30.10.2009 – til høring Side 22 af 69 PensionistIndikator xs:Boolean Optionel, angiver hvorvidt

patienten er pensionist.

GenerelCaveTekst GenerelCaveTekstType Optionel, Patientens evt. cave.

Anvendes til en evt. generel cave information på patienten. Cave defineres bredt, eks.: ”Taler dårligt dansk”. Mellem 1 og 70 tegn.

PaaroerendeStruktur PaaroerendeStrukturType Optionel, patientens evt.

familerelationer. Angives ved en sekvens på op til 99

PaaroerendeStruktur instanser.

ObjectReference ObjectReferenceType Optionel, angiver eventuelle referencer på patienten.

StamdataStruktur.xsd

<xs:include schemaLocation="CPRnummerIdentifikator.xsd"/>

<xs:include schemaLocation="AlternativPersonIdentifikator.xsd"/>

<xs:include schemaLocation="FoedselsDato.xsd"/>

<xs:include schemaLocation="NationalitetKode.xsd"/>

<xs:include schemaLocation="PersonKoenKode.xsd"/>

<xs:include schemaLocation="PersonNavnStruktur.xsd"/>

<xs:include schemaLocation="DanskAdresseStruktur.xsd"/>

<xs:include schemaLocation="UdenlandskAdresseStruktur.xsd"/>

<xs:include schemaLocation="StillingsbetegnelseNavn.xsd"/>

<xs:include schemaLocation="SygesikringsgruppeIdentifikator.xsd"/>

<xs:include schemaLocation="TelefonNummerStruktur.xsd"/>

<xs:include schemaLocation="EmailAdresseStruktur.xsd"/>

<xs:include schemaLocation="BehandlerIdentifikator.xsd"/>

<xs:include schemaLocation="PensionistIndikator.xsd"/>

<xs:include schemaLocation="GenerelCaveTekst.xsd"/>

<xs:include schemaLocation="PaaroerendeStruktur.xsd"/>

<xs:include schemaLocation="ObjectReference.xsd"/>

<xs:include schemaLocation="KommuneKode.xsd"/>

<xs:include schemaLocation="RegionsKode.xsd"/>

<xs:include schemaLocation="SkoleKode.xsd"/>

<xs:include schemaLocation="SkoleKlasse.xsd"/>

<xs:include schemaLocation="PersonKaldeNavn.xsd"/>

<xs:element name="StamdataStruktur" type="plo:StamdataStrukturType"/>

<xs:complexType name="StamdataStrukturType">

<xs:sequence>

<xs:choice>

<xs:element ref="plo:CPRnummerIdentifikator"/>

<xs:element ref="plo:AlternativPersonIdentifikator"/>

</xs:choice>

<xs:element ref="plo:FoedselsDato"/>

Kommenterede [N15]: Vi har en general cavetekst der er 1.000 karakterer langt. Som notattype.

(23)

30.10.2009 – til høring Side 23 af 69 <xs:element ref="plo:NationalitetKode" minOccurs="0"/>

<xs:element ref="plo:PersonKoenKode"/>

<xs:element ref="plo:PersonNavnStruktur"/>

<xs:element ref="plo:PersonKaldeNavn" minOccurs="0"/>

<xs:element ref="plo:DanskAdresseStruktur" minOccurs="0"/>

<xs:element ref="plo:UdenlandskAdresseStruktur" minOccurs="0"/>

<xs:element ref="plo:RegionsKode" minOccurs="0"/>

<xs:element ref="plo:KommuneKode" minOccurs="0"/>

<xs:element ref="plo:SkoleKode" minOccurs="0"/>

<xs:element ref="plo:SkoleKlasse" minOccurs="0"/>

<xs:element ref="plo:StillingsbetegnelseNavn" minOccurs="0"/>

<xs:element ref="plo:SygesikringsgruppeIdentifikator"/>

<xs:element ref="plo:TelefonNummerStruktur" minOccurs="0" maxOccurs="10"/>

<xs:element ref="plo:EmailAdresseStruktur" minOccurs="0" maxOccurs="5"/>

<xs:element ref="plo:BehandlerIdentifikator"/>

<xs:element ref="plo:PensionistIndikator" minOccurs="0"/>

<xs:element ref="plo:GenerelCaveTekst" minOccurs="0"/>

<xs:element ref="plo:PaaroerendeStruktur" minOccurs="0" maxOccurs="99"/>

<xs:element ref="plo:ObjectReference" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

StamdataStruktur.xsd.meta.xml

<Title>StamdataStruktur</Title>

<DescriptionDanish>Indeholder stamdataoplysninger vedrørende patienten i et PLO udtræk.

</Metadata>

(24)

PaaroerendeStruktur:

Element Type Beskrivelse

PaaroerendeRelation- Kode

PaaroerendeRelationKodeType Optionel, relationens type, angivet som en af følgende værdier:

”vaerge”, ”mor”, ”far”, ”bror”,

”soen”, “datter”, “partner”,

“mand”, ”hustru”, ”aegtefaelle”,

”andet”

CPRnummerIdentifi- kator

(OIO-XML)

CPR_PersonCivilRegistrationIdentifier

De pårørendes cprnummer uden bindestreg

AlternativPerson Identifikator

xs:string Person identifikation, der ikke er

et Validt CPR-nummer, eksempelvis erstatnings CPR- numre eller grænsegænger- numre.

PersonNavnStruktur (OIO-XML)

PersonNameStructureType

(Optionel) Den paarørendes navne.

PaaroerendeStruktur.xsd

<xs:include schemaLocation="DanskAdresseStruktur.xsd"/>

<xs:include schemaLocation="CPRnummerIdentifikator.xsd"/>

<xs:include schemaLocation="AlternativPersonIdentifikator.xsd"/>

<xs:include schemaLocation="PaaroerendeRelationKode.xsd"/>

<xs:element name="PaaroerendeStruktur" type="plo:PaaroerendeStrukturType"/>

Kommenterede [N16]: Bemærk at strukturen kræver både fornavn og efternavn. Vi har kun et samlet navnefelt, men måske kan man angive f.eks. fornavn som blank og hele navnet i efternavn?

Bare forekomsten er tilstedet af hensyn til strukturen?.

(25)

<xs:complexType name="PaaroerendeStrukturType">

<xs:sequence>

<xs:element minOccurs="0" ref="plo:PaaroerendeRelationKode"/>

<xs:choice>

<xs:element ref="plo:CPRnummerIdentifikator"/>

<xs:element ref="plo:AlternativPersonIdentifikator"/>

</xs:choice>

<xs:element minOccurs="0" ref="plo:PersonNavnStruktur"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

PaaroerendeStruktur.xsd.meta.xml

<Title>PaaroerendeStruktur</Title>

<DescriptionDanish>Information vedrørende pårørende til en patient.</DescriptionDanish>

</Metadata>

(26)

Kliniske data

BehandlerSamling

BehandlerSamling.xsd

<xs:include schemaLocation="BehandlerStruktur.xsd"/>

<xs:element name="BehandlerSamling" type="plo:BehandlerSamlingType"/>

<xs:complexType name="BehandlerSamlingType">

<xs:element ref="plo:BehandlerStruktur"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

BehandlerSamling.xsd.meta.xml

<Title>BehandlerSamling</Title>

<DescriptionDanish>En samling af behandlere.</DescriptionDanish>

(27)

</Metadata>

(28)

BehandlerStruktur

Element Type Beskrivelse

BehandlerIdentifikator BehandlerIdentifikatorType Mandatory, identification af behandleren inden for dette udtræk..

YderIdentifikator xs:string Optionel, behandlerens

eventuelle ydernummer. Max 6 tegn.

PersonNavnStruktur PersonNavnStrukturType Optionel, Angiver behandlerens navn.

StartDato xs:dato Optionel. Angiver startdatoen

for behandleren

SlutDato xs.dato Optionel. Angiver slutdatoen for

behandleren

BehandlerInitial xs:string Optionel. Max 5 tegn.

Behandlernes initialer.

AutorisationsIdentifikator xs:string Optionel, behandlerens autorisationsID i det offentlige autorisationsregister.

StillingsbetegnelseNavn xs:String Optionel. behandelerens evt.

stillingsbetegnelse.

BehandlerStruktur.xsd

<xs:include schemaLocation="YderIdentifikator.xsd"/>

<xs:include schemaLocation="BehandlerInitial.xsd"/>

<xs:include schemaLocation="AutorisationsIdentifikator.xsd"/>

<xs:include schemaLocation="StartDato.xsd"/>

<xs:include schemaLocation="SlutDato.xsd"/>

<xs:element name="BehandlerStruktur" type="plo:BehandlerStrukturType"/>

<xs:complexType name="BehandlerStrukturType">

<xs:sequence>

<xs:element minOccurs="0" ref="plo:YderIdentifikator"/>

<xs:element minOccurs="0" ref="plo:PersonNavnStruktur"/>

<xs:element minOccurs="0" ref="plo:StartDato"/>

<xs:element minOccurs="0" ref="plo:SlutDato"/>

<xs:element minOccurs="0" ref="plo:BehandlerInitial"/>

<xs:element minOccurs="0" ref="plo:AutorisationsIdentifikator"/>

<xs:element minOccurs="0" ref="plo:StillingsbetegnelseNavn"/>

Kommenterede [N17]: Format? Tror det kan lade sig gore at bruge init som vi gør.

Kommenterede [N18]: Evt. maks. længde?

(29)

</xs:sequence>

</xs:complexType>

</xs:schema>

BehandlerStruktur.xsd.meta.xml

<Title>BehandlerStruktur</Title>

<DescriptionDanish>Information om en behandler.</DescriptionDanish>

</Metadata>

CaveSamling

CaveSamling.xsd

(30)

30.10.2009 – til høring Side 30 af 69 elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0" xml:lang="DA">

<xs:include schemaLocation="CaveStruktur.xsd"/>

<xs:element name="CaveSamling" type="plo:CaveSamlingType">

</xs:element>

<xs:complexType name="CaveSamlingType">

<xs:element ref="plo:CaveStruktur"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

CaveSamling.xsd.meta.xml

<Title>CaveSamling</Title>

<DescriptionDanish>En samling af Cave oplysninger.</DescriptionDanish>

</Metadata>

CaveStruktur

Element Type Beskrivelse

StartDato xs:date Optionel, evt. startdato.

StartDatoTid xs:datetime Optionel, evt. starttidspunkt.

Kun StartDato eller StartDatoTid kan angives.

SlutDato xs:date Optionel, evt. slutdato.

SlutDatoTid xs:datetime Optionel, evt. slutidspunkt. Kun

SlutDato eller SlutDatoTid kan angives.

AllergiKodeStruktur KodeStrukturType Optionel, Angiver typen af allergi. For medicinallergi anvendes klassifikationskoden

”ATC” med koden lig med atckoden for det område, caven omfatter.

OverskriftTekst OverskriftTekstType Mandatory, Overskrift, der kort beskriver Caven. Mellem 1 og 70 tegn.

CaveVirkningTekst CaveVirkningTekstType Optionel, Tekst der beskriver Cavens virkning. Maksimalt 5 linier a højst 70 tegn.

KommentarLinieSamling KommentarLinieSamlingType Optionel. Samling af kommentarer til Caven.

BehandlerIdentifikator BehandlerIdentifikatorType Optionel. Identifikation af

Kommenterede [N19]: Bør nok også angive max 5 linie a højst 70 tegn, da schemaet siger det er samme plo:LinieTekst type med denne begrænsning.

(31)

30.10.2009 – til høring Side 31 af 69 behandleren, der har

identificeret allergien.

BehandlerInitial xs:string Optionel. Anvendes for

systemer, der kun angiver behandlerens intialer. Der kan angives BehandlerIdentifikator eller BehandlerInitial, ikke begge.

CaveStruktur.xsd.meta.xml

<xs:include schemaLocation="AllergiKodeStruktur.xsd"/>

<xs:include schemaLocation="StartDato.xsd"/>

<xs:include schemaLocation="SlutDato.xsd"/>

<xs:include schemaLocation="StartDatoTid.xsd"/>

<xs:include schemaLocation="SlutDatoTid.xsd"/>

<xs:include schemaLocation="OverskriftTekst.xsd"/>

<xs:include schemaLocation="CaveVirkningTekst.xsd"/>

<xs:include schemaLocation="KommentarLinieSamling.xsd"/>

<xs:element name="CaveStruktur" type="plo:CaveStrukturType"/>

<xs:complexType name="CaveStrukturType">

<xs:sequence>

<xs:choice minOccurs=”0”>

<xs:element ref="plo:StartDato"/>

<xs:element ref="plo:StartDatoTid"/>

</xs:choice>

<xs:element ref="plo:SlutDato"/>

<xs:element ref="plo:SlutDatoTid"/>

</xs:choice>

<xs:element ref="plo:AllergiKodeStruktur" minOccurs="0"/>

<xs:element ref="plo:OverskriftTekst"/>

<xs:element ref="plo:CaveVirkningTekst" minOccurs="0"/>

<xs:element ref="plo:KommentarLinieSamling" minOccurs="0"/>

<xs:element ref="plo:BehandlerIdentifikator" />

<xs:element ref="plo:BehandlerInitial"/>

</xs:choice>

</xs:sequence>

</xs:complexType>

</xs:schema>

CaveStruktur.xsd.meta.xml

(32)

30.10.2009 – til høring Side 32 af 69 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

<Title>CaveStruktur</Title>

<DescriptionDanish>Angivelse af en cave oplysning, eksempelvis en allergi, på ATC-niveau.

</Metadata>

VaccinationSamling

VaccinationSamling.xsd

<xs:include schemaLocation="VaccinationStruktur.xsd"/>

<xs:element name="VaccinationSamling" type="plo:VaccinationSamlingType"/>

<xs:complexType name="VaccinationSamlingType">

<xs:element ref="plo:VaccinationStruktur"/>

</xs:sequence>

</xs:complexType>

(33)

</xs:schema>

VaccinationSamling.xsd.meta.xml

<Title>VaccinationSamling</Title>

<DescriptionDanish>En samling ef enkeltvaccinationer.</DescriptionDanish>

</Metadata>

VaccinationStruktur

Element Type Beskrivelse

DatoTid xs:datetime Dato og tid for vaccinationen.

Dato xs:date Dato for vaccination. Eet af

elementerne Dato og DatoTid skal angives.

BoerneVaccinationIndikator xs:boolean Mandatory, angiver (true) om der er tale om en

børnevaccination.

VaccinationNavn xs:string Optionel, Et beskrivende

navn på vaccinationen.

Mellem 1 og 70 tegn..

PraeparatStruktur PraeparatStrukturType Optional. Oplysninger om det præparat, der er anvendt ved vaccinationen.

BatchIdentifikator BatchIdentifikatorType Optionel, vaccinens evt.

batchnr. Mellem 1 og 70 tegn,.

LinieTekst CaveVirkningTekstType Optionel, evt. kommentar til

vaccinationen.

BehandlerIdentifikator String Optionel. Identifikation af

behandleren, der har udført vaccinationen.

BehandlerInitial xs:string Optionel. Anvendes for

systemer, der kun angiver behandlerens intialer. Der kan angives BehandlerIdentifi- kator eller BehandlerInitial, ikke begge.

VaccinationStruktur.xsd

(34)

30.10.2009 – til høring Side 34 af 69 xmlns:plo="urn:oio:medcom:plo:2009.12.31" targetNamespace="urn:oio:medcom:plo:2009.12.31"

<xs:include schemaLocation="LinieTekst.xsd"/>

<xs:include schemaLocation="DatoTid.xsd"/>

<xs:include schemaLocation="Dato.xsd"/>

<xs:include schemaLocation="BoerneVaccinationIndikator.xsd"/>

<xs:include schemaLocation="VaccinationNavn.xsd"/>

<xs:include schemaLocation="PraeparatStruktur.xsd"/>

<xs:include schemaLocation="BatchIdentifikator.xsd"/>

<xs:element name="VaccinationStruktur" type="plo:VaccinationStrukturType"/>

<xs:complexType name="VaccinationStrukturType">

<xs:sequence>

<xs:choice>

<xs:element ref="plo:DatoTid"/>

<xs:element ref="plo:Dato"/>

</xs:choice>

<xs:element ref="plo:BoerneVaccinationIndikator"/>

<xs:element ref="plo:VaccinationNavn" minOccurs="0"/>

<xs:element ref="plo:PraeparatStruktur" minOccurs="0"/>

<xs:element ref="plo:BatchIdentifikator" minOccurs="0"/>

<xs:element ref="plo:LinieTekst" minOccurs="0"/>

<xs:element ref="plo:BehandlerInitial" />

</xs:choice>

</xs:sequence>

</xs:complexType>

</xs:schema>

VaccinationStruktur.xsd.meta.xml

<Title>VaccinationStruktur</Title>

<DescriptionDanish>Oplysninger vedrørende en given vaccination.</DescriptionDanish>

</Metadata>

(35)

NoteSamling

NoteSamling.xsd

<xs:include schemaLocation="NoteStruktur.xsd"/>

<xs:element name="NoteSamling" type="plo:NoteSamlingType">

</xs:element>

<xs:complexType name="NoteSamlingType">

<xs:element ref="plo:NoteStruktur"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

NoteSamling.xsd.meta.xml

(36)

30.10.2009 – til høring Side 36 af 69 xmlns="http://rep.oio.dk/infostructurebase/schemas/2004/09/13/">

<Title>NoteSamling</Title>

<DescriptionDanish>En samling af enkelt notater.</DescriptionDanish>

</Metadata>

NoteStruktur

De kliniske noter kategoriseres på overordnet niveau efter om det er egne noter (noter skrevet af den pratkiserende læge selv), indgående noter (noter sendt fra andre sundhedspersoner) eller udgående noter (noter sendt til andre sundhedspersoner). Dette udtrykkes i PLO-formatet gennem choice- konstruktionen med valget mellem EgneNoterKode, IndgaaendeNoterKode eller

UdgaaendeNoterKode.

Element Type Beskrivelse

EgneNoterKode EgneNoterKodeType Optionel. Angiver, at notatet er skrevet af den praktiserende læge selv.

Mulige værdier: ”kontinuation”,

”resume”, ”andet”.

IndgaaendeNoterKode IndgaaendeNoterKodeType Optionel. Angiver, at notatet er sendt til den praktiserende læge fra en anden sundhedsperson/

organisation. Mulige værdier:

”henvisning","rekvisition”,

"epikrise","korrespondance",

"email","blanket",”andet”.

UdgaaendeNoterKode UdgaaendeNoterKodeType Optionel. Angiver, at notatet er sendt fra den praktiserende læge til en anden sundhedsperson/

organisation. Mulige værdier:

”henvisning","rekvisition”,

"epikrise","korrespondance",

"email","blanket",”andet”.

MedcomKode MedcomKodeType Optionel, her kan den medcom

brevtype der ligger til grund for noten evt. angives.

Det gør det f.eks. muligt at angive om en epikrise er en vagtepikrise, sygehusepikrise, etc.

Mellem 1 og 35 tegn.

SystemKode SystemKodeType Optionel, evt. systemspecifik

notettype, 1 - 5 tegn,

DatoTid xs:datetime Dato og tid for noten.

Dato xs:date Dato for noten. Eet af elementerne

DatoTid og Dato skal angives.

OverskriftTekst OverskriftTekstType Optionel, en beskrivende