This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Implementatiehandleiding HL7v3 basiscomponenten v2.2 Part3

From HL7Wiki
Revision as of 06:45, 24 December 2009 by Alexander.henket@enovation.nl (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Implementatiehandleiding
HL7v3 Basiscomponenten deel 3

Inleiding

Naar inleidende hoofdstukken


Datatypes

Naar hoofdstuk datatypes


CMET's

 

Inleiding

Common Message Element Types (CMET's) zijn herbruikbare informatiemodellen (en daaruit afgeleide berichtsegmenten), die binnen HL7 versie 3 worden gebruikt om tussen berichten onderling een (interne) vorm van standaardisatie te bereiken. Door immers in alle berichten dezelfde specificaties te gebruiken voor bepaalde terugkerende onderdelen, zoals de patiënt, de zorgverlener en de zorginstelling, ontstaan de volgende voordelen:

  • Er wordt geen tijd verspild aan het praten over steeds dezelfde zaken (efficiency).
  • Ontwikkeling van CMET's kan aan deskundigen worden overgelaten (specialisatie).
  • Software die HL7-berichten genereert of verwerkt kan hiervoor steeds dezelfde basisfunctie gebruiken, ongeacht de berichtcontext waarin de CMET voorkomt.

CMET's zijn in feite R-MIMs, net zoals die voor volledige HL7-berichten gebruikt worden, maar fungeren als bouwstenen voor de berichtmodellen waarin ze gebruikt worden. In die zin lijken ze meer op de datatypes die elders in dit document beschreven worden, omdat ze herbruikbare, afgebakende gegevensstructuren beschrijven. Elke CMET heeft z'n eigen XML-schema, waaraan wordt gerefereerd vanuit de schema's voor berichten.

 

Algemene beschrijving van CMET varianten

De meeste CMET's komen in meerdere varianten voor. Deze zogenaamde 'flavors' (smaken) worden toegepast afhankelijk van de informatiebehoefte in een bepaalde context. De voornaamste verschillen zitten in de 'rijkheid' aan gegevens in de CMET.

In het algemeen komen vier verschillende varianten van de meeste CMET's voor:

[Universal]

Deze variant wordt gebruikt tussen zogenaamde 'loosely coupled systems', d.w.z. systemen die geen toegang hebben tot een gemeenschappelijk of gesynchroniseerd stambestand (bijv. van patiënten of zorgverleners). In deze versie van de CMET kunnen alle relevante gegevens van het betreffende object worden benoemd. Alle andere CMET varianten zijn dan ook restricties (deelverzamelingen) op dit universele informatiemodel.

[Identified]

Deze variant wordt gebruikt tussen zogenaamde 'tightly coupled systems', die volledig blind kunnen varen op het uitwisselen van een gemeenschappelijke identificatie voor het betreffende object (de 'instance identifier'). Binnen één zorginstelling is dit sowieso vaak voldoende, maar bij gebruik van landelijke identificatiesystemen, zoals AGB-Z of UZI voor zorgverleners en BSN voor patiënten, geldt dit in principe ook op landelijke schaal.

[Identified-Confirmable]

Deze variant is een tussenvorm van Universal en Identified, waarbij naast de identifier ook precies voldoende gegevens beschikbaar zijn om de identifier te kunnen verifiëren. Op deze manier kan de ontvanger de gegevens controleren met die in de eigen database. Wat er gebeurt als er verschillen zijn, hangt sterk af van de context van het bericht.

[Contact]

Deze variant wordt gebruikt in situaties waarbij het vooral belangrijk is om contact met de betreffende persoon of instantie te kunnen opnemen. Dat wil zeggen dat de nadruk ligt op adres- en telecommunicatiegegevens, incl. die van eventuele contactpersonen.

In Nederland zullen niet alle varianten gebruikt worden. Binnen elk bericht zal worden bekeken welke informatiebehoefte in de betreffende context moet worden vervuld.

 

R_PatientNL (patiënt)

 

Functie

De CMET R_Patient vormt een standaardberichtelement voor het uitwisselen van administratieve patiëntgegevens. Deze worden vaak aangeduid als N.A.W. (Naam Adres Woonplaats) gegevens, hoewel die term niet de hele lading dekt. Ook geboortedatum, geslacht, telefoonnummers etc. maken bijvoorbeeld deel uit van R_Patient.

De CMET R_Patient komt (in één van de mogelijke varianten) voor in de meeste HL7 versie 3 berichten, doordat het de universele manier is om de patiënt (die tenslotte meestal centraal staat) te identificeren en/of te beschrijven binnen alle domeinen.

Het is belangrijk om op te merken dat een patiënt in de context van HL7 versie 3 altijd betrekking heeft op een persoon (of ander levend wezen) als ontvanger van zorg. In principe is dit een 'rol' die gespeeld wordt in de context van een bepaalde zorginstelling. Op die manier wordt er onderscheid gemaakt tussen de persoon (met vaste persoonsgegevens) en diens rol als patiënt, met patiëntgegevens die in principe kunnen wisselen per zorginstelling. In de praktijk worden deze gegevens meestal gezamenlijk verzonden.

De verschillende 'smaken' van de CMET worden als volgt gebruikt:

  • R_Patient [universal] || doorgeven van algemene patiëntgegevens
  • R_Patient [identified] || identificatie van de patiënt o.b.v. nummer
  • R_Patient [identified-confirmable] || patiëntidentificatie met controlegegevens


In de volgende secties wordt een beschrijving gegeven van R_Patient [universal], waarna van de andere varianten de verschillen met de [universal] variant worden beschreven.

 

Informatiemodel R_PatientNL [universal] (COCT_RM050000NL)

COCT RM050000NL.png

De CMET R_Patient [universal] bevat de volgende gegevensklassen:

Patient Patiëntgegevens (in de context van een zorginstelling)
CMET E_PersonNL [universal] Persoonsgegevens (onafhankelijk van de zorginstelling)
(in het NL model worden dieren als patiënt nog uitgesloten)
CMET E_Organization [identified] Zorginstelling waarbij de persoon als patiënt bekend is
(in het NL model wordt alleen het instellingsnummer gebruikt)


Belangrijk kenmerk is dus dat een patiënt altijd een persoon is (dieren worden nog buiten beschouwing gelaten) en in de context van een bepaalde organisatie (potentieel) zorg ontvangt. Die organisatie zal meestal een zorginstelling zijn, waarbij de unieke identifier (id) van de patiënt zowel een lokaal als een landelijk nummer (BSN) kan zijn.

Patient Patiëntgegevens

De klasse Patient heeft de volgende kenmerken:

classCode PAT (Patient)
Een persoon in de rol van patiënt
(in de context van een zorginstelling)
id Patiëntidentificatie(s)
addr Woon/verblijfadres(sen)
telecom Communicatieaanduiding(en)
statusCode Status van de patiëntregistratie
effectiveTime Geldigheidsinterval
confidentialityCode Vertrouwelijkheidaanduiding
veryImportantPersonCode VIP aanduiding


De klasse Patient heeft de volgende associaties:

1..1 patientPerson Persoonsgegevens (onafhankelijk van de zorginstelling)
0..1 providerOrganization Zorginstelling waarbij de persoon als patiënt bekend is


Voor een toelichting op deze associaties wordt verwezen naar de betreffende CMET's.

Patient.id   Patiëntidentificatie(s)
SET<II> [1..*]


Het element <Patient><id> is verplicht gevuld binnen R_Patient en bevat één of meer patiëntnummers, d.w.z. instance identifiers die de patiënt onderscheiden van andere (potentiële) zorgontvangers. Deze identificatie kan een nummer zijn dat lokaal binnen een zorginstelling is gegenereerd, maar het mag ook een regionaal of landelijk nummer zijn (vanaf 1/6/2008 is het BSN als landelijk nummer beschikbaar). De gehanteerde identificaties hangen af van de context waarin de CMET wordt toegepast.

De identificatie van een patiënt moet zodanig worden doorgegeven dat deze ondubbelzinnig is voor de ontvangende applicatie. Het datatype II (Instance Identifier) garandeert dit door naast de extension van de identifier (het feitelijke nummer) ook de root door te geven, die het betreffende identificatiesysteem (en dus de combinatie) uniek aanduidt.

In principe zullen meestal twee soorten patiëntidentificaties gebruikt worden:

  • lokale nummers van de zorginstelling, meestal gegenereerd door het primaire informatiesysteem (het 'XIS') van de betreffende zorginstelling;
  • het landelijke Burgerservicenummer, zoals deze elektronisch opvraagbaar is bij de Sectorale Berichten Voorziening voor de Zorg (SBV-Z) of via het LSP.

Hier onder wordt voor beide situaties beschreven hoe het element id gevuld zal worden.

File:Info.png Het zal binnen Nederland binnenkort waarschijnlijk zo zijn (zodra het BSN is ingeburgerd) dat in ieder geval het BSN wordt doorgegeven als patiëntidentificatie, met daarnaast eventueel het eigen (lokale) patiëntnummer.


Lokaal patiëntnummer

Dit is dus bijv. het nummer dat door het ZIS van een ziekenhuis, het HIS van een huisarts of het AIS van een apotheek is uitgegeven. Om mogelijk te maken dat elke id van een patiënt universeel uniek is, wordt in het datatype II gebruik gemaakt van een OID (object identifier) o.b.v. de zorginstelling waarbinnen het nummer is uitgegeven:

root = OID o.b.v. de betreffende zorginstelling (zie de voorbeelden hieronder)
extension = lokaal referentienummer van patiënt (uniek binnen deze zorginstelling)

De root wordt dan samengesteld door de zorginstelling te identificeren en op basis hiervan het patiëntidentificatiesysteem daarbinnen te benoemen. Zorginstellingen (en zorgverleners) worden in Nederland meestal aangeduid d.m.v. het AGB-Z nummer, hetgeen leidt tot de volgende opbouw van de root (afhankelijk van het instellingstype):

Binnen een ziekenhuis:

OID-segment betekenis
2.16.840.1.113883.2.4 HL7 Nederland
.6.1 AGB-Z
.6010756 AGB-Z nummer van het ziekenhuis waarbinnen het nummer is uitgedeeld (zonder de voorloopnul !)
.1 Het ZIS binnen het betreffende ziekenhuis
.1 Patiëntnrs. als identificatiesysteem binnen het ZIS


Binnen een huisartsenpraktijk:

OID-segment betekenis
2.16.840.1.113883.2.4 HL7 Nederland
.6.1 AGB-Z
.1042461 AGB-Z nr. van de huisartsenpraktijk waarbinnen het nummer is uitgedeeld (zonder de voorloopnul !)
.1 Het HIS binnen de betreffende huisartsenpraktijk
.1 Patiëntnrs. als identificatiesysteem binnen het HIS


Binnen een openbare apotheek:

OID-segment betekenis
2.16.840.1.113883.2.4 HL7 Nederland
.6.1 AGB-Z
.2004321 AGB-Z nr. van de openbare apotheek waarbinnen het nummer is uitgedeeld (zonder de voorloopnul !)
.1 Het AIS binnen de betreffende openbare apotheek
.1 Patiëntnrs. als identificatiesysteem binnen het AIS


File:Info.png Als bijv. een ziekenhuis koppelingen onderhoudt met lokale openbare apotheken, waarbij het lokale patiëntnummer, zoals gebruikt in deze apotheken, wordt bijgehouden in een kruistabel (dus gekoppeld aan het lokale patiëntnummer van het ziekenhuis zelf, of aan het BSN), dan moet het ziekenhuis de volledige instance identifier van het patiëntnummer van de apotheek gebruiken wanneer het met de apotheek communiceert. Desondanks blijft het ziekenhuis de 'scoper' van de gebruikte patiëntrol.
File:Info.png Nu binnenkort de UZI-passen en bijbehorende nummers in gebruik genomen worden in Nederland, ontstaat daarmee ook een nieuw systeem voor het identificeren van zorgverleners én zorginstellingen. Zorginstellingen kunnen dan nl. geïdentificeerd worden op basis van het UZI abonneeregister, waarin alle instanties die UZI passen hebben aangevraagd worden bijgehouden.

Het bovenstaande principe voor de root OID van lokale patiëntnummers (en andere lokale identificatiesystemen) blijft echter volledig intact, alleen neemt het UZI abonneenummer de functie van het AGB-Z nummer over.

De OID voor UZI abonneenummers is 2.16.528.1.1007.3.3 (dus niet onder de HL7 Nederland tak) en UZI abonneenummers zelf zijn 8-cijferig. De OID voor lokale patiëntnummers binnen een ziekenhuis kan dan bijv. worden: 2.16.528.1.1007.3.3.1234567.1.1 voor een ziekenhuis met als UZI-abonneenummer 01234567 (ook hier worden voorloopnullen verwijderd).


In feite bestaan er geen regels voor de opbouw van root OID's (de segmenten zijn betekenisloos), zolang maar de garantie bestaat dat de extension er een unieke context mee verkrijgt. Bovenstaande methode wordt echter sterk geadviseerd bij het doorgeven van lokale patiëntnummers, om te zorgen voor uniforme toepassing binnen Nederland.

Burger Service Nummer

In alle berichten die worden uitgewisseld via de landelijke infrastructuur (AORTA), zal in Nederland gebruik moeten worden gemaakt van het Burger Service Nummer als primaire patiëntidentificatie. Voor het systeem van Burger Service Nummers is een vaste OID (object identifier) vastgelegd, zodat patiëntnummers altijd als BSN herkenbaar zijn.

De OID voor Burger Service Nummers is: 2.16.840.1.113883.2.4.6.3'. Aan deze root van de instance identifier is een patiëntnummer dus altijd herkenbaar als BSN.

File:Info.png Aangezien het id element herhalend mag voorkomen binnen de R_Patient CMET, is het zonder meer toegestaan om naast het BSN van de patiënt óók een lokaal gegenereerd patiëntnummer door te geven. Dit gaat niet op als het patiëntnummer bijv. als parameter voor een query naar het LSP fungeert, maar wel in alle gevallen waarin de R_Patient CMET wordt gebruikt.


File:Info.png Burgerservicenummers zijn altijd 9-cijferig (evt. incl. voorloopnullen) en hebben op de laatste positie een controlecijfer op basis van een modulo-11 proef. Vanzelfsprekend moet ook dit controlecijfer worden doorgegeven.


XML-voorbeeld 1

Een patiënt is binnen het ziekenhuis met AGB-Z nummer 06010756 bekend onder het intern gegenereerde nummer 120267BA501. De Patient.id wordt als volgt doorgegeven:

<id extension="120267BA501" root="2.16.840.1.113883.2.4.6.1.6010756.1.1"/>

Noot 1: Merk op dat de extension niet per se numeriek hoeft te zijn, maar ook letters mag bevatten. De extension moet worden weergegeven exact zoals in het bronsysteem.

Noot 2: Merk op dat de AGB-Z nummerreeks voor ziekenhuizen altijd begint met '06'. De voorloopnul vervalt altijd binnen de OID van de root (algemene regel bij OID-gebruik).

XML-voorbeeld 2

Een patiënt is binnen de huisartsenpraktijk met AGB-Z nummer 01042461 bekend onder het intern gegenereerde nummer 018793. De Patient.id wordt als volgt doorgegeven:

<id extension="018793" root="2.16.840.1.113883.2.4.6.1.1042461.1.1"/>

Noot 1: Merk op dat eventuele voorloopnullen in de extension mogen, en zelfs moeten, blijven staan, indien deze binnen het bronsysteem ook als zodanig gebruikt worden.

XML-voorbeeld 3

Een patiënt heeft Burger Service Nummer 012345672.

<id extension="012345672" root="2.16.840.1.113883.2.4.6.3"/>

XML-voorbeeld 4

Een patiënt heeft Burger Service Nummer 012345672, maar wordt binnen een ziekenhuis ook nog aangeduid met het intern (binnen het ZIS) gegenereerde nummer 0006756420.

<id extension="012345672" root="2.16.840.1.113883.2.4.6.3"/>
<id extension="0006756420" root="2.16.840.1.113883.2.4.6.1.6010756.1.1"/>

Noot 1: Merk op dat de twee herhalingen van het id element gewoon achter elkaar worden weergegeven. Het BSN is voor de ontvanger herkenbaar o.b.v. de root OID.

Patient.addr   Woon/verblijfadres(sen)
BAG<AD> [0..*]

Het element <Patient><addr> is aanwezig indien bekend in R_Patient en bevat één of meer actuele adressen van de persoon in diens rol als patiënt. Dit gaat vrijwel altijd om een (t)huisadres, maar kan ook een vakantiewoning of ander tijdelijk adres betreffen.

Het element is required, hetgeen betekent dat alle applicaties die de CMET gebruiken dit element moeten ondersteunen. Er moet dus een waarde gestuurd kunnen worden als deze bekend is. Een ontvangend systeem moet in staat zijn de waarden op te slaan.

File:Info.png Men kan zich natuurlijk afvragen waarom een adres een patiëntgegeven is en geen vast persoonsgegeven. De redenatie is dat het adres afhankelijk is van de rol van de persoon als patiënt, omdat bijv. een arts een ander adres zal hanteren in zijn rol van patiënt dan in zijn rol van zorgverlener. Ook kan een patiëntadres bijv. van tijdelijke aard zijn i.v.m. medische behandeling.


Het gaat dus om de woon/verblijfadressen van de patiënt, zoals door de zorginstelling gehanteerd binnen de eigen administratie. Zie verder de beschrijving bij het datatype 'AD'. Als er slechts één (woon)adres van de patiënt bekend is, hetgeen in vrijwel alle informatiesystemen zo is, dan wordt dit meestal aangeduid met 'HP' (Home Primary).

XML-voorbeeld

Een patiënt staat geregistreerd met (woon)adres Dorpsstraat 54, 1024 BB te Purmerend.

<addr use="HP"> 
   <streetName>Dorpsstraat</streetName>
   <houseNumber>54</houseNumber>
   <postalCode>1024 BB</postalCode>
   <city>Purmerend</city>
</addr>
Patient.telecom   Communicatieaanduiding(en)
BAG<TEL> [0..*]


Het element <Patient><telecom> is aanwezig indien bekend in R_Patient en bevat één of meer actuele telefoonnummers of andere communicatieaanduidingen die gebruikt kunnen worden om de patiënt te bereiken. Hieronder valt bijv. telefoonnummer thuis, telefoonnummer op het werk, mobiel nummer of fax, maar ook een e-mailadres!

Het element is required, hetgeen betekent dat alle applicaties die de CMET gebruiken dit element moeten ondersteunen. Er moet dus een waarde gestuurd kunnen worden als deze bekend is. Een ontvangend systeem moet in staat zijn de waarden op te slaan, waarbij het echter mogelijk is dat niet alle communicatieaanduidingen ondersteund worden (zo zal niet in elk systeem specifiek ruimte zijn om een e-mailadres op te slaan).

File:Info.png

Binnen het datatype 'TEL' zijn allerlei communicatieaanduidingen mogelijk. Het advies is om binnen R_Patient alleen de volgende typen toe te passen:

  • tel: voor telefoonnummers (inclusief semafoons)
  • fax: voor faxapparaten
  • mailto: voor e-mailadressen

Voor de inhoud van de nummers cq. adressen zelf kunnen mogelijk nog nadere conventies worden afgesproken (bijv. m.b.t. landcodes en streepjes in telefoonnummers), maar momenteel is gewoon elke tekst hier geldig.


Het gaat dus om de communicatieaanduidingen van de patiënt, zoals die door de zorginstelling worden gehanteerd binnen de eigen administratie. Zie verder de beschrijving bij het datatype 'TEL'. De meest voorkomende telefoonnummertypen zijn 'HP' (telefoonnummer thuis), 'MC' (mobiel nummer) en 'WP' (telefoonnummer werk).

XML-voorbeeld

Van een patiënt worden diens telefoonnummer thuis, een mobiel nummer en een e-mailadres doorgegeven. Dit levert drie herhalingen op van het element <Patient><telecom>:

<telecom use="HP" value="tel:0299-955555" />
<telecom use="MC" value="tel:06-98686555" />
<telecom value="mailto:j.jansen@speednet.nl" />
Patient.statusCode   Status van de patiëntregistratie
CS [1..1] <= RoleStatus


Het element <Patient><statusCode> is verplicht gevuld, maar dit is feitelijk alleen het geval omdat het in de internationale specificaties ook aanwezig moet zijn. Normaal gesproken zal het altijd de waarde active hebben, ten teken dat het een patiëntregistratie betreft die actief is binnen de administratie. Als de patiëntregistratie 'vervallen' is (d.w.z. niet meer gebruikt mag worden) dan wordt als statusCode terminated meegegeven.

File:Info.png

Als binnen de patiëntregistratie van een zorginstelling blijkt dat dezelfde persoon meerdere keren als patiënt is ingeschreven, dan is het gebruikelijk dat deze nummers aan elkaar 'gekoppeld' (of 'gelijkgesteld') worden. Daarbij wordt één van de nummers prevalent en de andere nummers vervallen.

Let op: vervallen nummers kunnen niet in dezelfde Patient-klasse worden meegegeven als het prevalente nummer, omdat het element <statusCode> betrekking heeft op de gehele klasse en niet op afzonderlijke id elementen.

De juiste manier om vervallen patiëntregistraties door te geven is d.m.v. de klasse OtherIDs binnen de E_Person CMET (zie elders in dit document). Deze klasse wordt echter vooralsnog niet toegepast in de Nederlandse situatie.


XML-voorbeeld

Een actieve patiëntregistratie.

<statusCode code="active" />
Patient.effectiveTime   Geldigheidsinterval
IVL<TS> [0..1]


Vooralsnog niet gebruiken in de Nederlandse situatie.

Patient.confidentialityCode   Vertrouwelijkheidaanduiding
(CE CNE [0..1] <= Confidentiality


Dit optionele element heeft betrekking op het vertrouwelijkheidniveau van de betreffende patiëntgegevens. Vooralsnog wordt daarbij slechts gebruik gemaakt van drie codes uit het code system Confidentiality (2.16.840.1.113883.5.25). Zie onderstaande tabel:

Code Naam Definitie
N normal Normale vertrouwelijkheidregels (in de context van de gezondheidszorg) zijn van toepassing. Dat wil zeggen dat alleen geautoriseerde personen met een legitieme medische of administratieve reden toegang mogen hebben.
R restricted Beperkte toegang, bijv. alleen voor zorgverleners (of daardoor gemandateerde medewerkers) met een actuele behandelrelatie met de patiënt.
V very restricted Zeer beperkte toegang, zoals bepaald door de patiënt zelf of diens wettelijke vertegenwoordiger.
Confidentiality [2.16.840.1.113883.5.25]


De standaardwaarde is 'N', dus als het element niet wordt meegegeven is de toegang 'normaal'.

XML-voorbeeld

De toegang tot de patiëntgegevens is beperkt.

<confidentialityCode codeSystem="2.16.840.1.113883.5.25" code="R" />
Patient.veryImportantPersonCode   VIP aanduiding
(CE CNE [0..1] <= PatientImportance


Dit optionele element heeft betrekking op de aard van de speciale status die de patiënt voor de zorginstelling heeft. Daarbij wordt gebruik gemaakt van het binnen HL7 gedefinieerde codesysteem PatientImportance (2.16.840.1.113883.5.1075). Zie tabel:

Conceptcode Naam Definitie
BM Board Member Lid van de raad van bestuur van de zorginstelling.
DFM Physician Family Member Familielied van een lid van de medische staf.
DR Staff Physician Lid van de medische staf.
FD Financial Donor Financiële donor van de zorginstelling.
FOR Foreign Dignitary Buitenlandse hoogwaardigheidsbekleder.
GOVT Government Dignitary Hoogwaardigheidsbekleder.
SFM Staff Family Member Familielied van een medewerker.
STF Staff Member Medewerker van de zorginstelling.
VIP Very Important Person Andere VIP.
PatientImportance [2.16.840.1.113883.5.1075]


XML-voorbeeld

De patiënt is een lid van de medische staf.

<veryImportantPersonCode codeSystem="2.16.840.1.113883.5.1075" code="DR" />

 

Informatiemodel R_PatientNL [identified] (COCT_RM050001NL)

COCT RM050001NL.png

De [identified] variant van de CMET R_Patient is een restrictie op de [universal] variant, waarin alleen de unieke patiëntidentificatie(s) zijn opgenomen in het informatiemodel. Dit wordt alleen gebruik om een bij de ontvanger reeds bekende patiënt te identificeren, maar niet om wijzigingen door te geven. Vandaar ook het ontbreken van de statusCode.

De CMET R_Patient [identified] bevat de volgende gegevensklassen:

Patient Patiëntidentificatie

De klasse Patient heeft de volgende kenmerken:

classCode PAT (Patient)
Een persoon in de rol van patiënt
(in de context van een zorginstelling)
id Patiëntidentificatie(s)


Patient.id   Patiëntidentificatie(s)
SET<II> [1..*]


Zie Patient.id bij R_Patient [universal].

 

E_Person NL (persoon)

 

Functie

De CMET E_Person vormt een standaardberichtelement voor het uitwisselen van vaste persoonsgegevens, zoals naam, geboortedatum en geslacht. Deze CMET wordt vooral gebruikt in combinatie met R_Patient en R_AssignedPerson, waarbinnen E_Person een genest onderdeel is voor de vaste persoonsgegevens van de patiënt resp. zorgverlener.

File:Info.png Let op dat in het HL7 versie 3 RIM (Reference Information Model), en dus ook in alle daarop gebaseerde informatiemodellen, het adres en bijv. de telefoonnummers worden beschouwd als kenmerken van de rol die een persoon vervult, bijv. de rol van patiënt of zorgverlener. Deze kenmerken komen dan ook niet voor in het model van de E_Person CMET.


De CMET E_Person, althans in de [universal] variant (zie hieronder), bevat de meest essentiële vaste persoonsgegevens, aangevuld met de mogelijkheid om diverse andere persoonsgebonden gegevens door te geven (zoals de huisarts en zorgverzekeringen).

File:Info.png Merk op dat het doorgeven van persoonsgegevens (d.m.v. E_Person) binnen een bepaald bericht (bijv. een Voorschriftbericht voor medicatie) geen surrogaat mag zijn voor een een online patiëntkoppeling (zoals vaak met ADT berichten binnen ziekenhuizen wordt gebruikt). De meegestuurde gegevens zijn alleen geldig in de context van het bericht waarin ze meekomen. Als er later wijzigingen in de persoonsgegevens van het bronsysteem zijn, worden deze immers niet automatisch bijgewerkt in gekoppelde systemen en ze zijn ook niet apart opvraagbaar.


De essentiële gegevens, te weten naam, geboortedatum en geslacht, hangen natuurlijk nauw samen met het landelijke BSN register, waarin deze gegevens ook (o.b.v. de Gemeentelijke Basis Administratie) beschikbaar zijn. De CMET dwingt echter niet af dat de meegestuurde gegevens per se consistent zijn met de GBA gegevens bij het BSN.

File:Info.png Merk op dat de Sectorale Berichten Voorziening voor de Zorg (SBV-Z) geen mogelijkheid biedt om het BSN register te raadplegen o.b.v. alleen het BSN nummer. Het is dus ook niet voldoende om alleen een BSN nummer mee te sturen en te verwachten dat het ontvangende systeem daarmee de essentiële persoonsgegevens zelf kan opvragen bij de SBV-Z.


In de Nederlandse HL7 versie 3 berichten wordt tot nu toe gebruik gemaakt van de E_Person [universal] variant, die de mogelijkheid biedt om diverse persoonsgegevens door te geven.

 

Informatiemodel E_PersonNL [universal]

COCT RM030200NL.png

De CMET E_Person [universal] bevat de volgende gegevensklassen:

Person Persoon
Employment Beroep(en)
ContactParty Contactpersoon/contactpersonen
PatientOfOtherProvider Relatie met de huisarts
Birthplace Geboorteplaats
R_CoveredParty (CMET) Zorgverzekering(en) (zie opmerkingen voor R_CoveredParty later in dit document)


De meeste van de gegevens in het bovenstaande model zijn optioneel, aangezien de CMET ook gebruikt moet kunnen worden om simpelweg de naam, de geboortedatum en eventueel het geslacht door te geven. In de uitgebreide vorm omvat de CMET dus ook de huisarts, verzekeringen, contactpersonen en zelfs beroepsaanduidingen van de persoon.

Kort samengevat kent het berichtelement de volgende kenmerken:

  • Een persoon heeft een optionele ID (BSN als persoonsnummer).
  • De onderdelen naam, geslacht en geboortedatum zijn optioneel, maar wel required. Dat wil zeggen dat elk (verzendend en ontvangend) systeem ze moet ondersteunen.
  • Verder zijn er optionele modelonderdelen m.b.t. de geboorteplaats, evt. overlijden, meerlingen, burgerlijke staat en zelfs opleiding (deze laatste t.b.v. huisartsdossiers).
  • Een persoon heeft optioneel één of meer verzekeringspolissen.
  • Een persoon heeft optioneel een zorgrelatie met één (vaste) huisarts.
  • Een persoon heeft optioneel één of meer contactpersonen.
  • Een persoon heeft optioneel één of meer beroepsmatige rollen.

De laatste twee gegevenscategorieën zijn weer vooral toegevoegd t.b.v. huisartsdossiers, omdat het informatie betreft die bij waarneming en overdracht uitgewisseld kan worden.

Hl7logofordocumentation.png

Er zijn in dit uitzonderlijke geval diverse aanpassingen en uitbreidingen gemaakt op het internationale model, aangezien dit op bepaalde punten tekort schoot voor de Nederlandse situatie. Er is een proces in gang gezet om deze Nederlandse wensen in het internationale model terug te laten komen, aangezien uitgangspunt is dat altijd harmonisatie plaatsvindt.

De aanpassingen zijn:

  • De klasse PatientOfOtherProvider is toegevoegd om de huisarts van de persoon door te geven (via een nogal ingewikkelde constructie). Dit loopt vooruit op een internationale aanpassing en is in de toekomst ook geschikt om bijv. tandarts en (vaste)apotheek door te geven.
  • De associatie met R_CoveredParty is herhalend (0..*) gemaakt, omdat ook meervoudige zorgverzekeringen doorgegeven moeten kunnen worden (bijv. basisverzekering plus aanvullende verzekering). Zie ook opmerkingen R_CoveredParty later in dit document.
  • Het element Employment.occupationCode is toegevoegd, omdat dit beter aansloot bij de gehanteerde beroepscodes bij huisartsen.
  • Het element Person.id is verwijderd bij de ContactParty (terwijl het daar internationaal verplicht is), omdat contactpersonen niet geïdentificeerd hoeven te worden (maar alleen bereikbaar moeten zijn).
  • Het element Birthplace.addr is toegevoegd, omdat anders niet het geboorteland en/of de geboorteplaats kunnen worden weergegeven.

 

Klasse Person (Persoon)

COCT RM030200NL PersonPart.png

De klasse Person heeft de volgende kenmerken:

classCode PSN (Persoon)
Een persoon (mens)
determinerCode INSTANCE
Een specifiek persoon (individu)
id Persoonsnummer
name Naam
administrativeGenderCode Geslacht
birthTime Geboortedatum (en evt. –tijd)
deceasedInd Overlijdensindicatie
deceasedTime Overlijdensdatum (en evt. –tijd)
multipleBirthInd Meerlingindicatie
multipleBirthOrderNumber Meerlingvolgnummer
maritalStatusCode Burgerlijke staat
educationLevelCode Opleidingsniveau


De klasse Person heeft de volgende associaties:

0..1 Employment Beroep
0..* ContactParty Contactpers(o)n(en)
0..1 PatientOfOtherProvider Relatie met de huisarts
0..1 Birthplace Geboorteplaats
0..* CoveredParty Zorgverzekering(en)


Deze associaties worden verderop in de zogenaamde 'walkthrough' nader toegelicht.

Person.id   Persoonsnummer
SET<II> [0..*]


Het element id is binnen de CMET E_Person [universal] optioneel en herhalend.

Het kan gebruikt worden om het Burger Service Nummer (BSN), dat in de Nederlandse zorg gaat fungeren als persoonsidentificatie, uit te wisselen tussen systemen. Meestal zal het BSN dan echter ook als patiëntidentificatie gehanteerd worden (zie CMET R_Patient) en is het hier dus redundant. Het element is herhalend beschikbaar omdat eventueel ook andere persoonsidentificaties, zoals het paspoort- of rijbewijsnummer, gehanteerd zouden kunnen worden, hoewel dat in de Nederlandse zorgsector zeer ongebruikelijk is.

File:Info.png Het BSN is in principe een persoonsidentificatie (dat zelfs breder dan alleen de zorgsector wordt toegepast), maar zal in de meeste gevallen ook fungeren als patiëntidentificatie binnen zorginstellingen, die het waarschijnlijk als primaire identificatie binnen het eigen informatiesysteem gaan gebruiken.


De OID voor Burger Service Nummers is: 2.16.840.1.113883.2.4.6.3. Aan deze root van de instance identifier is een persoonsnummer dus altijd herkenbaar als zijnde een BSN.

XML-voorbeeld

Een patiënt heeft Burger Service Nummer 123456782.

<id extension="123456789" root="2.16.840.1.113883.2.4.6.3"/>
Person.name   Naam
PN [0..2]


Het element name is binnen de CMET E_Person [universal<nowiki>]</nowiki> een optioneel gegeven, dat echter wel de conformance-indicatie required heeft. Dit wil zeggen dat zowel verzendende als ontvangende systemen die de CMET gebruiken in staat moeten zijn om het gegeven te verzenden (als dat gewenst is) resp. op te slaan (als het verzonden wordt).

Het datatype is PN (Person Name), hetgeen in HL7 versie 3 een vrij complexe structuur heeft. Het is een zogenaamd 'mixed content' datatype, dat in principe bestaat uit vrije tekst, maar waarin structuurkenmerken aanwezig zijn om specifieke onderdelen van de tekst te benoemen. Het datatype PN wordt uitgebreid beschreven bij de Nederlandse implementatierichtlijnen voor HL7v3 datatypes, waar ook voorbeelden te vinden zijn.

Op welke manier de naam wordt meegegeven binnen de CMET hangt sterk af van de context van het betreffende bericht en de mogelijkheden binnen het bronsysteem. Het zou kunnen dat het systeem slechts in staat is om één enkele string als naam door te geven, maar het is ook mogelijk dat de naam volledig opgesplitst in onderdelen beschikbaar is (inclusief eventuele adellijke of academische titels en mogelijk ook een aanhef).

File:Info.png

Let op dat het bij het gebruik van een partnernaam niet alleen relevant is dat iemand getrouwd is, maar vooral of de betreffende persoon al dan niet met de naam van de partner wil worden aangesproken of aangeschreven.

Het toepassen van de partnernaam in de persoonsnaam staat los van het eventueel vastleggen van de partner als contactpersoon.

In de huidige Nederlandse wetgeving kan na een huwelijk elke combinatie van eigennaam en/of partnernaam gevoerd worden door beide partners. Vanzelfsprekend is het geslacht van de partners daarbij niet relevant.

Het BSN-register, zoals dit raadpleegbaar is via de SBV-Z, bevat per definitie alleen eigennamen en kent geen partnernamen.


File:Info.png Het is ook mogelijk om twee namen voor dezelfde persoon door te geven. Daarbij geldt voor Nederland de beperking dat dit alleen gebruikt mag worden om de combinatie van een reguliere naam en een officiële naam uit de Gemeentelijke Basis Administratie aan te duiden, hetgeen van belang kan zijn indien deze niet gelijk zijn. Eén specifieke toepassing hiervan is het doorgeven van de geboortenaam van iemand die na een huwelijk niet meer de geboortenaam als deel van de achternaam voert (deze geboortenaam blijft nl. wel deel uitmaken van de naam in de GBA).


XML-voorbeeld

Voor reguliere voorbeelden, zie de beschrijving bij het datatype PN (Person Name). Indien iemand als geboortenaam Jansen heeft, maar sinds een huwelijk alleen de naam van diens partner voert (Pietersen), ontstaat er een verschil tussen de naam in de GBA en de reguliere naam waarmee de patiënt wordt aangesproken (of aangeschreven):

<name use="L"> 
   <family qualifier="SP">Pietersen</family>
</name>
<name use="OR">
   <family qualifier="BR">Jansen</family>
</name>

In bovenstaand voorbeeld zijn eventuele andere naamdelen niet opgenomen.

Person.administrativeGenderCode   Geslacht
(CE CNE [0..1] <= AdministrativeGender


Het element administrativeGenderCode is binnen de CMET E_Person [universal] een optioneel gegeven, dat echter wel de conformance-indicatie required heeft. Dit wil zeggen dat zowel verzendende als ontvangende systemen die de CMET gebruiken in staat moeten zijn om het gegeven te verzenden resp. op te slaan (indien aanwezig).

Voor dit gegeven moeten de waarden worden gebruikt uit de volgende HL7-tabel:

Code Weergavenaam Nederlandse omschrijving
F Female Vrouwelijk
M Male Mannelijk
UN Undifferentiated Onbepaald
AdministrativeGender [2.16.840.1.113883.5.1]


File:Info.png De waarde "UN" moet niet gebruikt worden om aan te geven dat (nog) geen waarde voor het geslacht van een persoon bekend is. Als dat zo is, dan blijft het gegeven leeg en krijgt een zogenaamde nullFlavor (zie bij het datatype ANY). De waarde "UN" wordt alleen gebruikt als het geslacht wel bekend is, maar noch zuiver mannelijk noch zuiver vrouwelijk is.

Merk overigens op dat het hier gaat om het "administratief geslacht", zoals door de patiënt gemeld, en niet om klinische geslachtbepaling.


XML-voorbeeld

Een vrouw.

<code code="F" codeSystem="2.16.840.1.113883.5.1" displayName="Vrouwelijk" />

Noot: het attribuut displayName is optioneel en mag niet door de ontvanger gebruikt worden bij verwerking.

Person.birthTime   Geboortedatum (en evt. –tijd)
TS [0..1]


Het element birthTime is binnen de CMET E_Person [universal] een optioneel gegeven, dat echter wel de conformance-indicatie required heeft. Dit wil zeggen dat zowel verzendende als ontvangende systemen die de CMET gebruiken in staat moeten zijn om het gegeven te verzenden (als dat gewenst is) resp. op te slaan (als het verzonden wordt).

Het datatype TS staat toe om tijdstippen met verschillende nauwkeurigheidsgraden uit te wisselen, afhankelijk van de mate van precisie waarmee deze bekend is in een systeem. Normaal gesproken zal het bij het element Person.birthTime een geboortedatum (d.w.z. jaar+maand+dag) betreffen, maar er mag ook een geboortetijd toegevoegd worden.

File:Info.png Het komt regelmatig voor dat van patiënten wel het geboortejaar maar geen exacte geboortedatum bekend is. Deze worden vaak geregistreerd onder de datum 1 januari, maar binnen HL7v3 zou dus een datum met een lagere precisie kunnen worden gebruikt om alleen het geboortejaar door te geven (en duidelijk te maken dat de exacte datum niet bekend is).


Een persoon is geboren op 30 maart 1967.

<birthTime value="19670330"/>

Een persoon is geboren op 30 maart 1967 om 06:30.

<birthTime value="196703300630"/>

Een persoon is geboren in 1967, maar de exacte datum is onbekend.

<birthTime value="1967"/>
Person.deceasedInd   Overlijdensindicatie
BL [0..1]


Het element deceasedInd is binnen de CMET E_Person [universal] optioneel aanwezig. Het wordt gebruikt om aan te geven dat de betreffende persoon inmiddels overleden is. Het heeft een standaardwaarde "false", hetgeen inhoudt dat het afwezig zijn van het element wordt geïnterpreteerd als aanduiding dat de betreffende persoon 'in leven' is.

File:Info.png Als het aanverwante element deceasedTime een waarde heeft, dan moet de deceasedInd expliciet als true worden doorgegeven. Als dit niet het geval is, dan heeft de meegegeven overlijdensdatum geen betekenis.


Zie voor XML-voorbeelden bij deceasedDate.

Person.deceasedDate   Overlijdensdatum (en evt. –tijd)
TS [0..1]


Het element deceasedTime is binnen de CMET E_Person [universal] optioneel aanwezig. Het wordt gebruikt om aan te geven waneer de betreffende persoon overleden is, hetgeen zowel specifiek (incl. tijd) als ruwweg (bijv. alleen jaar) mag worden weergegeven.

File:Info.png Het element deceasedTime heeft alleen betekenis als het aanverwante element deceasedInd de waarde true heeft (d.w.z. als de persoon expliciet als overleden is aangeduid) en moet anders genegeerd worden.

De reden dat beide elementen bestaan, is dat vaak wel het feit van het overlijden bekend is, maar niet de overlijdensdatum (in dat geval blijft deceasedDate dus leeg of wordt expliciet een nullFlavor meegegeven)


XML-voorbeelden

Een persoon is overleden, maar het is niet relevant wanneer (het verzendende systeem kent het concept niet of verstuurt het nooit).

<deceasedInd value="true" />

Een persoon is overleden, maar het is niet bekend wanneer (het verzendende systeem kent het concept "overlijdensdatum" wel).

<deceasedInd value="true" />
<deceasedDate nullFlavor="UNK" />

Een persoon is overleden op 12 januari 2005.

<deceasedInd value="true" />
<deceasedDate value="20050112" />
Person.multipleBirthInd   Meerlingindicatie
BL [0..1]


Het element multipleBirthInd is binnen de CMET E_Person [universal] optioneel. Het wordt gebruikt om aan te geven dat de betreffende persoon er één van een meerling is. Het heeft een standaardwaarde "false", hetgeen inhoudt dat het afwezig zijn van het element wordt geïnterpreteerd als: 'de persoon is geen onderdeel van een meerling'.

De meerwaarde van de meerlingindicatie ligt in het feit dat meerlingen een veel hogere kans hebben om als personen verwisseld te worden (door de gelijke geboortedatum, eigennaam en, zeker bij kinderen, ook het adres). De meerlingindicatie werkt dan als signalering dat extra aandacht (of zelfs meer zoekcriteria) moeten worden toegepast.

File:Info.png Dit gegeven moet niet gebruikt worden om aan te geven dat sprake is van een meerling tijdens de zwangerschap (dus niet als kenmerk van de moeder, maar ook niet als kenmerk van de foetus!). Het heeft pas betekenis als kenmerk van een pasgeborene als sprake is geweest van meervoudige geboortes bij een bevalling (na 16 weken zwangerschap).


File:Info.png Als het aanverwante element multipleBirthOrderNumber een waarde heeft, dan moet multipleBirthInd als true worden doorgegeven. Als dit niet het geval is, dan heeft "volgnummer binnen de meerling" geen betekenis.


Zie voor XML-voorbeelden bij multipleBirthOrderNumber.

Person.multipleBirthOrderNumber   Meerlingvolgnummer
INT [0..1]


Het element multipleBirthOrderNumber is binnen de CMET E_Person [universal] optioneel aanwezig. Het wordt gebruikt om aan te geven als hoeveelste van de meerling de betreffende persoon geboren werd. De waarde is dus een geheel getal >= 1.

File:Info.png Het element multipleBirthOrderNumber heeft alleen betekenis als het aanverwante element multipleBirthInd de waarde true heeft (d.w.z. als de persoon expliciet als meerling is aangeduid).

De reden dat beide elementen bestaan, is dat meestal wel bekend is dat de persoon een meerling is, maar niet in welke volgorde de geboortes plaatsvonden (in dat geval blijft multipleBirthOrderNumber dus leeg of wordt expliciet een nullFlavor meegegeven).


Het element multipleBirthOrderNumber is zeker niet bedoeld als medisch gegeven, maar kan evt. worden gebruikt als extra methode om meerlingen van elkaar te onderscheiden.

File:Info.png Er zijn geen harde regels voor de toegepaste volgnummers, zolang ze maar dienst doen als uniekmaker voor de personen die meerling van elkaar zijn. De gebruikte waarden mogen dus ook bijv. 100 en 200 zijn.


XML-voorbeelden

Een persoon is (deel van een) tweeling, maar de geboortevolgorde is niet relevant (het verzendende systeem kent het concept niet of verstuurt het nooit).

<multipleBirthInd value="true" />

Een persoon is (deel van een) drieling, maar de geboortevolgorde is niet bekend (het verzendende systeem kent het concept "meerlingvolgnummer" wel).

<multipleBirthInd value="true" />
<multipleBirthOrderNumber nullFlavor="UNK" />

Een persoon is (deel van een) tweeling en is als 2e van het stel geboren.

<multipleBirthInd value="true" />
<multipleBirthOrderNumber value="2" />
Person.maritalStatusCode   Burgerlijke staat
(CE CNE [0..1] <= MaritalStatus


Het element maritalStatusCode is binnen de CMET E_Person [universal<nowiki>]</nowiki> optioneel.

De burgerlijke staat van een persoon wordt in de meeste zorginstellingen niet vastgelegd (en dus ook niet uitgewisseld), maar is een gegeven dat binnen het huisartsdossier en ook in de geestelijke gezondheidszorg wel relevant is.

Voor dit gegeven moeten de waarden worden gebruikt uit de volgende HL7-tabel:

Code Weergavenaam Nederlandse omschrijving
D Divorced Gescheiden (huwelijk ontbonden)
M Married Gehuwd
S Never Married Nooit gehuwd geweest
T Domestic partner Geregistreerd partnerschap
W Widowed Weduwe/weduwnaar
MaritalStatus [2.16.840.1.113883.5.2]


File:Info.png Belangrijke opmerkingen:
  1. Het gaat bij bovenstaande codes om de meest recente toestand (bij 'hertrouwd' gaat 'getrouwd' boven 'gescheiden' of 'weduwe'). De patiënt bepaalt altijd zelf welke code van toepassing is.
  2. Er is internationaal geen specifieke code voor 'geregistreerd partnerschap' (Domestic partner heeft de ruimere betekenis van 'samenwonen'). Voor Nederland is de definitie ingeperkt, omdat het feit dat iemand samenwoont los staat van de burgerlijke staat.


De tabel die momenteel meestal gebruikt wordt in de huisartssector is NHG tabel 6:

Code Omschrijving Toelichting HL7-code
01 Gehuwd M
02 Gescheiden D
03 Ongehuwd S
04 Samenwonend bij geregistreerd partnerschap in andere gevallen T
S (of D of W)
06 Weduwstaat W
07 LAT-relatie bij geregistreerd partnerschap
bij huwelijk
in andere gevallen
T
M
S (of D of W)
08 Hertrouwd zelfde als gehuwd M
90 Onbekend nullFlavor = "UNK"
99 Overig geen van bovenstaande categorieën nullFlavor = "OTH"
NHG tabel 6: Code burgerlijke staat
NIET GEBRUIKEN IN HL7-BERICHTEN


Het streven is om deze tabel niet meer te gebruiken binnen HL7-berichten. De codes voor samenwonend en LAT-relatie hebben geen betrekking op de burgerlijke staat, maar op het woonverband. Het onderscheid tussen hertrouwd en gehuwd is niet relevant.

File:Info.png Een systeem dat intern gebruik maakt van de NHG (of andere) codes (en dat zullen de meeste zijn), moet in staat zijn om een mapping te maken naar de HL7 MaritalStatus tabel om uitwisselbaarheid te garanderen.


XML-voorbeelden

Een persoon heeft zichzelf aangeduid als alleenstaand (d.w.z. niet gehuwd).

<maritalStatusCode code="S" codeSystem="2.16.840.1.113883.5.2" displayName="Ongehuwd" />

Een persoon heeft binnen een huisartssysteem de NHG tabel 6 code '08' (hertrouwd).

<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2" displayName="Gehuwd" />

Een persoon heeft binnen een huisartssysteem de NHG tabel 6 code '99' (overig).

<maritalStatusCode nullFlavor="OTH" />
Person.educationLevelCode   Opleidingsniveau
(CE CNE [0..1] <= EducationLevel + NHG_tabel_20


Het element educationLevelCode is binnen de CMET E_Person [universal] optioneel.

Het opleidingsniveau van een persoon wordt in de meeste zorginstellingen niet vastgelegd (en dus ook niet uitgewisseld), maar is een gegeven dat binnen het huisartsdossier en ook in de jeugd gezondheidszorg of geestelijke gezondheidszorg wel relevant is.

Voor dit gegeven kunnen twee mogelijke tabellen gebruikt worden. HL7 kent als codes:

Code Weergavenaam Nederlandse omschrijving
ASSOC Associate's or technical degree complete
BD College or baccalaureate degree complete HBO voltooid
ELEM Elementary School basisschool (lagere school)
GD Graduate or professional Degree complete universiteit voltooid
(is dit incl. hogeschool?)
HS High School or secondary school degree complete middelbare school voltooid
PB Some post-baccalaureate education universiteit niet voltooid
(aansluitend op HBO)
POSTG Doctoral or post graduate education post-doctoraal
SCOL Some College education HBO niet voltooid
SEC Some secondary or high school education middelbare school niet voltooid
EducationLevel [2.16.840.1.113883.5.1077]


Binnen Nederland is echter tabel 20 van de NHG tabellenklapper in gebruik en wordt binnen alle sectoren gebruikt.

Code Weergavenaam Nederlandse omschrijving HL7-code
01 geen opleiding
02 lager algemeen onderwijs basisschool (lagere school) ELEM
03 lager beroepsonderwijs LBO HS
04 middelbaar algemeen onderwijs MAVO, VMBO HS
05 middelbaar beroepsonderwijs MBO, incl. MEAO en MTS
08 hoger algemeen onderwijs HAVO, VWO (?) HS
09 hoger beroepsonderwijs HBO, incl. HEAO en HTS BD
10 wetenschappelijk onderwijs universiteit/hogeschool GD (hogeschool?)
90 onbekend nullFlavor = "UNK"
99 overig onderwijs geen van bovenstaande categorieën nullFlavor = "OTH"
NHG tabel 20: Code opleiding [2.16.840.1.113883.2.4.4.30.20]


File:Info.png Merk op dat de codes 90 en 99 in HL7 als nullFlavor zouden worden aangeduid. Aangezien het echter niet mogelijk is om een nullFlavor naast een code uit een ander codesysteem door te geven, kunnen deze nullFlavors alleen gebruikt worden wanneer geen NHG code aanwezig is.


Het is duidelijk dat de (internationale) HL7-tabel sterk op de Verenigde Staten is ingesteld, terwijl de Nederlandse tabel veel meer aansluit bij het systeem met verschillende niveaus van algemeen en beroepsonderwijs (MAVO, HAVO, VWO, etc.).

Hl7logofordocumentation.png Er zal in internationaal verband nog het volgende worden nagegaan:
  • Waarom er geen code is voor 'geen enkele (voltooide) opleiding'.
  • Hoe MBO onderwijs het beste in de tabel benoemd kan worden.
  • Wat de beste synoniemen zijn voor de codes ASSOC, GD en PB.


Elke combinatie van bovenstaande tabellen mag worden gebruikt bij het doorgeven van het opleidingsniveau. Hoewel de NHG tabel waarschijnlijk de voorkeur zal krijgen i.v.m. bestaande implementaties, is het aan te bevelen om waar mogelijk daarnaast de bijbehorende HL7-code door te geven om zo uniform mogelijk gegevens uit te wisselen.

XML-voorbeelden

Een persoon heeft als hoogste opleidingsniveau de MAVO gedaan.

<educationLevelCode code="04" codeSystem="2.16.840.1.113883.2.4.4.30.20" displayName="middelbaar algemeen onderwijs">
   <translation code="HS" codeSystem="2.16.840.1.113883.5.1077" displayName="High School or secondary school degree complete"/>
</educationLevelCode>

Noot: het attribuut displayName is optioneel en mag niet gebruikt worden bij verwerking.

Een persoon heeft een opleiding gedaan die niet in de gebruikte codelijst(en) voorkomt.

<educationLevelCode nullFlavor="OTH">
   <originalText>Huishoudschool</originalText>
</educationLevelCode>

 

Klasse Employment (Beroep)

COCT RM030200NL EmploymentPart.png

De associatie Employment is optioneel aanwezig in de CMET E_Person.

In het kader van de uitwisseling van huisartsdossiers komt het ook voor dat gegevens omtrent het beroep (eigenlijk de 'sociale laag') van de patiënt (oftewel de persoon) worden vastgelegd en uitgewisseld. De beroepen worden daarbij gecodeerd aangeduid.

Hl7logofordocumentation.png Er zijn een aantal zaken die internationaal nog zullen worden aangepast met betrekking tot de klasse Employment binnen de CMET E_Person:
  • De naam zou eigenlijk Employee moeten zijn, want dat is de rol die de persoon speelt. Daarmee zou de associatie ook asEmployee heten.
  • Het element occupationCode komt niet voor in het internationale model. Er is wel een element jobCode, maar dit is bedoeld voor de interne functieaanduiding van een werknemer en niet van het beroep.


XML-voorbeeld

<person>
   ...	
   <asEmployment>
      ...
   </asEmployment>
   ...
</person>

De klasse Employment heeft de volgende kenmerken:

classCode EMP (Employee)
De persoon als werknemer (beroepsbeoefenaar).
occupationCode Beroepscode

classCode

Employment.occupationCode   Beroepscode
(CE CNE [0..1] <= NHG_tabel_11


Het element occupationCode is verplicht gevuld in elk voorkomen van de klasse Employment. Het geeft een gecodeerde aanduiding voor het beroep van de persoon. Omdat de voornaamste toepassing ligt in de huisartsensector, wordt daarbij gebruik gemaakt van de daar gebruikelijke NHG tabel 11, die de volgende codes bevat:

Code Omschrijving
01 ongeschoolde arbeid
02 geschoolde arbeid
03 lager employée
04 kleine zelfstandige
05 middelbaar employée
06 hogere beroepen
07 zonder beroep
09 huishoudelijk werk (gezin)
90 onbekend
99 Overig
NHG tabel 11: Code sociale laag [2.16.840.1.113883.2.4.4.30.11]


File:Info.png NHG tabel 11 geeft feitelijk geen aanduiding voor het beroep, maar eerder van het 'niveau' waarop de persoon professioneel actief is. Het element jobCode benadert echter het meest de toepassing in de huisartsensector.


XML-voorbeeld

Een persoon heeft een functie als directeur van een middelgrote onderneming. Dit wordt door de huisarts gekwalificeerd als een 'hoger beroep', met de code '06' in NHG tabel 11.

<occupationCode code="06" codeSystem="2.16.840.1.113883.2.4.4.30.11" displayName="hogere beroepen" />

Noot: het attribuut displayName is optioneel en mag niet gebruikt worden bij verwerking.

 

Klasse ContactParty (Contactpersoon/contactpersonen)

COCT RM030200NL ContactPartyPart.png

De associatie ContactParty is optioneel en herhalend aanwezig in de CMET E_Person.

Het kan voorkomen dat bij een persoon (meestal in diens rol als patiënt) één of meer contactpersonen moeten worden doorgegeven. In sommige gevallen fungeren dergelijke contactpersonen als primair aanspreekpunt voor de patiënt (bijv. bij een kind of mentaal gehandicapte die niet in staat zijn om zelf met de zorgverleners te communiceren). In andere gevallen betreft het personen die in geval van nood gealarmeerd kunnen worden.

XML-voorbeeld

<person>
   ...	
   <contactParty>
      ...
      <person>
         ...
      </person>
   </contactParty>
   ...
</person>

De klasse ContactParty heeft de volgende kenmerken:

classCode CON (Contact)
Een persoon in diens rol als contactpersoon voor een ander.
code Contactpersoontype
telecom Telecommunicatieaanduiding(en)


De klasse Person heeft de volgende kenmerken:

classCode PSN (Person)
Een persoon.
determinerCode INSTANCE
Een individu.
name Naame


ContactParty.code   Contactpersoontype
(CE CNE [0..1] <= ContactRoleType


Het element code is optioneel aanwezig in de klasse ContactParty. Het geeft een gecodeerde aanduiding voor het type contactpersoon (internationaal kan het ook een contactorganisatie zijn, maar deze mogelijkheid wordt in Nederland nog uitgesloten).

Hierbij wordt gebruik gemaakt van de HL7 value set ContactRoleType (uit het domein RoleCode):

Code HL7-weergavenenaam Nederlandse omschrijving
ECON emergency contact Een contactpersoon voor noodsituaties
NOK next of kin Familielid (of andere naaste)
RoleCode (value set ContactRoleType) [2.16.840.1.113883.5.111]


Aangezien slechts één ContactParty.code kan worden meegegeven, moet de ContactParty rol herhaald worden als een persoon meerdere contactpersoontypes vervult.

Hl7logofordocumentation.png Er ontbreekt in feite nog een code voor een contactpersoon die als 'aanspreekpunt' fungeert voor een 'niet-communicatiebekwaam' persoon, zoals een kind of een mentaal gehandicapte. Nu wordt er meestal automatisch van uitgegaan dat dit een naast familielid is, maar dit is zeker niet per definitie zo. Advies is om in situaties waarbij geen van bovenstaande codes relevant is, het element simpelweg niet mee te geven.


XML-voorbeeld

Een dochter fungeert als contactpersoon voor noodsituaties bij haar opgenomen moeder.

<code code="ECON" codeSystem="2.16.840.1.113883.5.111" displayName="emergency contact" />

Noot: het attribuut displayName is optioneel en mag niet gebruikt worden bij verwerking.

 

Klasse PatientOfOtherProvider (Relatie met huisarts/andere zorgverlener)

COCT RM030200NL PatientOfOtherProviderPart.png

De relatie tussen een persoon (meestal in de rol van patiënt) en diens huisarts wordt binnen HL7 versie 3 aangeduid op een manier die misschien op het eerste gezicht nogal omslachtig lijkt. De achterliggende gedachte is dat de relatie tussen een persoon en diens huisarts niet principieel anders is dan die tussen een persoon en diens chirurg, afgezien van het feit dat er sprake is van een langdurigere relatie. Het feit dat iemand in Nederland a) verplicht is om een huisarts te hebben en b) maximaal één huisarts tegelijk mag hebben, is internationaal redelijk bijzonder. Zo ontstaat bovenstaand model.

De klasse PatientOfOtherProvider heeft de volgende kenmerken:

classCode PAT (Patient)
Patiënt (van een zorgverlener).


De klasse subjectOf heeft de volgende kenmerken:

typeCode SBJ (Subject)
De patiënt is het onderwerp van de zorgrelatie met de zorgverlener.


De klasse PatientCareProvision heeft de volgende kenmerken:

classCode PCPR (Patient Care Provision)
Een zorgrelatie tussen een patiënt en een zorgverlener.
moodCode EVN (Event)
Een feitelijke zorgrelatie. (ook wel een 'verantwoordelijkheidsperiode').
code GENRL (General)
Ook andere codes zijn toegestaan, zie opmerking later in dit document.


De klasse responsibleParty heeft de volgende kenmerken:

typeCode PROV (Provider)
De zorgverlener is de verantwoordelijke voor de zorgrelatie met de patiënt.


De klasse HealthCareProvider heeft de volgende kenmerken:

classCode PROV (Provider)
Zorgverlener (persoon of organisatie die gemachtigd is om zorg te verlenen).
id EVN (Event)
Huisartsnummer (of id van andere zorgverleners, zie opmerking beneden).


De klasse ProviderPerson heeft de volgende kenmerken:

classCode PSN (Person)
De zorgverlener is een persoon.
determinerCode INSTANCE (Instantiation)
Het betreft een specifieke zorgverlener (individu).
name Huisartsnaam (of naam van andere zorgverleners, zie opmerking beneden).


XML-voorbeeld

Een persoon heeft als huisarts de heer R. Jansen, met als AGB-Z code '01043251'.

<person>
   ...
   <asPatientOfOtherProvider>
      <subjectOf>
         <patientCareProvision>
            <code code="GENRL" codeSystem="2.16.840.1.113883.5.4" />
            <responsibleParty>
               <healthCareProvider>
                  <id extension="01043251" root="2.16.840.1.113883.2.4.6.1"/>
                  <providerPerson>
                     <name>
                        <prefix qualifier="TITLE">De Heer </prefix>
                        <given qualifier="IN">R. </given>
                        <family>Jansen</family>
                     </name>
                  </providerPerson>
               </healthCareProvider>
            </responsibleParty>
         </patientCareProvision>
      </subjectOf>
   </asPatientOfOtherProvider>
   ...
</person>
PatientCareProvision.code   Typering zorgrelatie
CE [1..1] <= ActMedicalServiceCode


Het element PatientCareProvision.code is een typering van de aard van de zorgrelatie tussen patiënt en zorgverlener. Binnen de HL7 value set ActMedicalServiceCode (onderdeel van het domein ActCode) bestaat de waarde 'GENRL', die van toepassing is op de aard van de huisarts in Nederland (en bijvoorbeeld de general practioner in Engeland).

Code HL7-weergavenenaam Internationale omschrijving
GENRL General General care performed by a general practitioner or family doctor as a responsible provider for a patient.
ActCode (value set ActMedicalServiceCode) [2.16.840.1.113883.5.4]


File:Info.png Er kan misschien de vraag gesteld worden waarom de waarde "GENRL" (inclusief de bijbehorende OID) moet worden doorgegeven als deze toch vastligt. De reden is dat in de toekomst waarschijnlijk de tandarts en eventueel ook de (vaste) apotheek van een persoon op dezelfde manier zullen worden doorgegeven. De waarde van PatientCareProvision.code is dan nodig om het onderscheid te kunnen maken tussen deze zorgrelaties.


XML-voorbeeld

<code code="GENRL" codeSystem="2.16.840.1.113883.5.4" />
HealthCareProvider.id   Nummer van de zorgverlener (bijv. huisartsnummer)
II [1..1]


Het element HealthCareProvider.id bevat de identificatie van de betreffende huisarts.

Voor Nederland wordt binnen HL7 versie 3 berichten op dit moment vooral gebruik gemaakt van de zogenaamde AGB-Z nummers voor zorgverleners, beheerd door VEKTIS. Voor communicatie op de landelijke infrastructuur (AORTA) moet straks echter de Unieke Zorgverleners Identificatie (UZI) gebruikt worden, die elke huisarts zal ontvangen.

De OID voor de AGB zorgverlenernummers is 2.16.840.1.113883.2.4.6.1.
De OID voor UZI nummers van natuurlijke personen is 2.16.528.1.1007.3.1.

XML-voorbeeld

Een huisarts wordt geïdentificeerd d.m.v. diens AGB-Z nummer 01043251.

<id extension="01043251" root="2.16.840.1.113883.2.4.6.1" />

Een huisarts wordt geïdentificeerd d.m.v. haar UZI nummer 1234567.

<id extension="001234567" root="2.16.528.1.1007.3.1" />
ProviderPerson.name   Naam van de zorgverlener (bijv. Huisartsnaam)
PN [1..1]


Het element ProviderPerson.name bevat de naam van de betreffende huisarts. De klasse ProviderPerson is op zich optioneel aanwezig, maar als deze klasse gebruikt wordt, dan is het element name verplicht gevuld (omdat anders de klasse geen functie heeft).

Zie verder de algemene beschrijving bij datatype PN (Person Name) elders in deze gids.

 

Klasse Birthplace (Geboorteplaats)

COCT RM030200NL BirthPlacePart.png

De klasse Birthplace is optioneel aanwezig in de CMET E_Person [universal] en geeft de geboorteplaats (meestal in de vorm van een land of een stad) van de persoon weer.

De klasse Birthplace heeft de volgende kenmerken:

classCode BIRTHPL (Birth Place)
Geboorteplaats (van een persoon).
addr EVN (Event)
Adresaanduiding


XML-voorbeeld

<person>
   ...
   <birthplace>
      ... 
   </birthplace>
   ...
</person>
Birthplace.addr   Adresaanduiding
AD [1..1]


Het element Birthplace.addr is verplicht gevuld als de klasse Birthplace aanwezig is en geeft een adresaanduiding van de geboorteplaats van de betreffende persoon. Zie hiervoor de gedetailleerde beschrijving van datatype AD (Address) elders in dit document.

File:Info.png Merk op dat bij het vastleggen en doorgeven van geboorteplaats meestal alleen het geboorteland (bij buitenlandse personen) of de geboortestad binnen Nederland. Meer gedetailleerde adresaanduidingen zijn ook mogelijk, maar meestal niet relevant als gegeven bij de persoon.


XML-voorbeeld

Een persoon is geboren in Marokko.

<addr>
   <country>Marokko</country>
</addr>

Dezelfde aanduiding, maar nu met landcode.

<addr>
   <country codeSystem="1.0.3166.1.2.2" code="MA">Marokko</country>
</addr>

Een persoon is geboren in Markelo.

<addr>
   <city>Markelo</city>
</addr>

 

R_AssignedPerson (zorgmedewerker)

 

Functie

De CMET R_AssignedPerson is bedoeld voor het beschrijven van een persoon in zijn rol als zorgmedewerker, in de breedste zin van het woord. De term 'assigned' slaat op het feit dat een zorgverlener of andere medewerker in de zorg altijd gesanctioneerd is door een zorginstelling waar hij of zij voor werkt. De term uit de HL7v3 standaard komt wat gezocht over, maar komt dus neer op een persoon met een toegewezen verantwoordelijkheid. In de praktijk wordt de CMET gebruikt voor directe zorgverleners (artsen, verpleegkundigen) en eventueel voor andere medewerkers met toegang tot zorginformatie (dat komt overeen met iedereen met een persoonsgebonden UZI-pas).

Van de CMET R_AssignedPerson bestaat een aantal varianten:

  • R_AssignedPerson [identified] (COCT_RM0910101)

Niets anders dan een unieke identificatie van de zorgmedewerker.

  • R_AssignedPerson [identified-confirmable] (COCT_RM090102)

Een unieke identificatie van de zorgmedewerker, aangevuld met de meest essentiële gegevens ter controle (naam/adres/zorgverlenerrol).

  • R_AssignedPersonNL [universal] (COCT_RM090100NL)

Volledige zorgmedewerkergegevens, geschikt om stamtabellen te synchroniseren.

 

R_AssignedPerson [identified]

Dit is de meest eenvoudige variant om personen, die betrokken zijn bij het zorgproces, te identificeren. Van deze CMET wordt in Nederland alleen het id element gebruikt.

COCT RM090101.gif

XML-voorbeeld

<AssignedPerson>
   <id extension="03004256" root="2.16.840.1.113883.2.4.6.1"/>
</AssignedPerson>

 

R_AssignedPerson [identified-confirmable]

Indien een id alleen niet voldoende is wordt de Identified-Confirmable variant gebruikt. Naam, adres en organisatie kunnen met deze CMET worden doorgegeven.

COCT RM090102.gif

XML-voorbeeld

<AssignedPerson>
   <id extension="03004256" root="2.16.840.1.113883.2.4.6.1"/>
   <code codeSystem="2.16.840.1.113883.2.4.15.111" code="01.014" displayName="Chirurg"/>
   <addr use="WP">
      <streetName>Valkendael</streetName>
      <houseNumber>45</houseNumber>
      <postalCode>6245 HK</postalCode>
      <city>Maastricht</city>
   </addr>
   <assignee>
      <assigneePerson>
         <name>
            <prefix qualifier="AC">Dr. </prefix>
            <given>Peter</given>
            <prefix qualifier="VV">van </prefix>
            <family qualifier="BR">Pulver</family>
         </name>
      </assigneePerson>
   </assignee>
</AssignedPerson>

 

R_AssignedPersonNL [universal]

Van de universele variant is een Nederlandse restrictie gemaakt. Het verschil met de Identified-Confirmable variant is dat de universele CMET het mogelijk maakt om gegevens over telecommunicatie, certificaten en duur van de rol vast te leggen.

COCT RM090100NL.png

File:Info.png Het telecom element bevat de bereikbaarheidsgegevens van de persoon, zoals telefoonnummers en e-mailadressen. Naast telefoon- en faxnummers, kan dit element voor zorgverleners tevens de Applicatie Identificatie bevatten van de applicatie die de zorgverlener gebruikt.


XML-voorbeeld

<AssignedPerson>
   <id extension="03004256" root="2.16.840.1.113883.2.4.6.1"/>
   <code codeSystem="2.16.840.1.113883.2.4.15.111" code="01.014" displayName="Chirurg"/>
   <addr use="WP">
      <streetName>Valkendael</streetName>
      <houseNumber>45</houseNumber>
      <postalCode>6245 HK</postalCode>
      <city>Maastricht</city>
   </addr>
   <assignee>
      <assigneePerson>
         <name>
            <prefix qualifier="AC">Dr. </prefix>
            <given>Peter</given>
            <prefix qualifier="VV">van </prefix>
            <family qualifier="BR">Pulver</family>
         </name>
      </assigneePerson>
   </assignee>
</AssignedPerson>

 

R_AssignedOrganization (zorginstelling)

R_AssignedOrganization [identified]

Voor het identificeren van een organisatie middels één of meerdere id's volstaat deze CMET. Het code element wordt in Nederland niet gebruikt.

COCT RM090201.gif

XML-voorbeeld

<AssignedOrganization>
   <id extension="1" root="2.16.840.1.113883.2.4.6.5"/>
</AssignedOrganization>

 

R_AssignedOrganization [identified-confirmable]

Van deze CMET worden in Nederland de volgende onderdelen gebruikt:

id identificatie van de organisatie
addr adres van de organisatie
name naam van de organisatie (in Organization)


Er dient minimaal één id plus adres of naam te worden vastgelegd.

COCT RM090202.gif

XML-voorbeeld

<AssignedOrganization>
   <id extension="1" root="2.16.840.1.113883.2.4.6.5"/>
</AssignedOrganization>

 

R_AssignedOrganization [universal]

COCT RM090200.gif

XML-voorbeeld

<AssignedOrganization>
   <id root="2.16.840.1.113883.2.4.6.1" extension="06003652"/>
   <addr use="WP">
      <streetName>Valkendael</streetName>
      <houseNumber>45</houseNumber>
      <postalCode>6245 HK</postalCode>
      <city>Maastricht</city>
   </addr>
   <telecom use="WP" value="tel:+31434073576"/>
   <assignedPrincipalChoiceList>
      <assignedOrganization>
         <name>Gezondheidscentrum Aesculaap</name>
      </assignedOrganization>
   </assignedPrincipalChoiceList>
</AssignedOrganization>

 

R_AssignedDevice (apparaat)

Deze CMET wordt gebruikt om gegevens rond apparatuur vast te leggen.

COCT RM090300.gif

XML-voorbeeld

<AssignedDevice>
  <id root="2.16.528.1.1007.3.3.12345.1" extension="006456"/>
  <telecom value="http://www.Aesculaap.nl"/>
  <assignedPrincipalChoiceList>
    <assignedDevice>
       <softwareName>Apache web server</softwareName>
    </assignedDevice>
  </assignedPrincipalChoiceList>
  <Organization>
      <id root="2.16.528.1.1007.3.3" extension="00012345"/>
      <name>Gezondheidscentrum Aesculaap</name>
  </Organization>
</AssignedDevice>

 

R_AssignedEntity (verantwoordelijke)

De CMET R_AssignedEntity bestaat uit een algemene rol die de "verantwoordelijke" aangeeft. De verantwoordelijke wordt gespeeld door of een Person, een Organization, of een Device klasse. In feite is deze CMET een algemene versie van of de CMET R_AssignedOrganization, de CMET R_AssignedDevice en de CMET R_AssignedPerson. Zie de beschrijving van die CMET's voor details rondom gebruik van de Rol-klasse en de entiteit die de rol speelt.

COCT RM090002UV.png

 

E_Organization (organisatie)

Deze CMET wordt zelden los gebruikt, maar meestal als onderdeel van andere CMET's.

 

E_Organization [identified]

COCT RM150001.gif

XML-voorbeeld

<Organization>
  <id extension="1" root="2.16.840.1.113883.2.4.6.5"/>
</Organization>

 

E_Organization [identified-confirmable]

Naast id's kan deze CMET ook adresgegevens en de naam van de organisatie bevatten. Het code element wordt wederom niet gebruikt. Deze CMET zal vooral gebruikt worden om de naam van een organisatie door te geven.

COCT RM150002.gif

XML-voorbeeld

<Organization>
   <id root="2.16.840.1.113883.2.4.6.1" extension="06004213"/>
   <name>Gezondheidscentrum Aesculaap</name>
   <addr>
      <streetName>Valkendael</streetName>
      <houseNumber>45</houseNumber>
      <postalCode>6245 HK</postalCode>
      <city>Maastricht</city>
   </addr>
</Organization>

 

E_Organization [universal]

COCT RM150000.gif

XML-voorbeeld

<Organization>
   <id root="2.16.840.1.113883.2.4.6.1" extension="06004213"/>
   <name>Gezondheidscentrum Aesculaap</name>
   <telecom use="WP" value="tel:+31434073576"/>
   <addr use="WP">
      <streetName>Valkendael</streetName>
      <houseNumber>45</houseNumber>
      <postalCode>6245 HK</postalCode>
      <city>Maastricht</city>
   </addr>
</Organization>

 

E_Place (plaats)

Deze CMET wordt gebruikt om gegevens over een plaats vast te leggen. In Nederland zal slechts een aantal van de onderdelen gebruikt worden:

id identificatie van de plaats
name naam van de plaats
desc omschrijving van de plaats


De relaties worden in Nederland nog niet gebruikt.

COCT RM710000.gif

XML-voorbeeld

<Place>
   <name>Naam van een plaats, afdeling, kast of anders</name>
   <desc>Omschrijving van de plaats, dit is een ED type kan ook een foto bevatten.</desc>
   <directionsText>Beschrijving van hoe de plaats te bereiken.
   ED type, kan dus ook een routekaart zijn.</directionsText>
</Place>

 

R_LocationLocatedEntity (locatie)

Deze CMET wordt gebruikt om een bepaalde locatie aan te duiden, bijvoorbeeld een bed of een afdeling in een ziekenhuis, een verdieping of een gebouw in een zorginstelling. Dit wordt meestal gezien in een associatie met andere klassen en kan ook hiërarchisch worden gebruikt, om een locatie binnen en locatie aan te geven.

 

R_LocationLocatedEntity [identified]

Als een id van een locatie bekend is kan de identifed variant van de CMET gebruikt worden.

id Verplichte identificatie van de locatie


COCT RM070001.gif

XML-voorbeeld

<LocatedEntity>
   <id extension="012" root="2.16.528.1.1007.3.3.12345.23.1"/>
</LocatedEntity>

 

R_LocationLocatedEntity [universal]

Van deze CMET worden in Nederland de volgende onderdelen gebruikt:

id identificatie van de locatie
addr adres van de locatie
telecom bijhorende telecommunicatiecontacten
statusCode status van de locatie
effectiveTime geldigheidstermijn van de locatie


Van deze CMET wordt in Nederland de volgende relatie gebruikt:

Location Naam enz. van de locatie (in E_Place)


Er dient minimaal één id, adres, telecom of de associatie location te worden vastgelegd.

COCT RM070000.gif