Implementatiehandleiding HL7v3 basiscomponenten v2.2 Part3

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)

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:

Confidentiality [2.16.840.1.113883.5.25]
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.

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:

PatientImportance [2.16.840.1.113883.5.1075]
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.

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)

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]

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.

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)

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:

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

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:

MaritalStatus [2.16.840.1.113883.5.2]
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

File:Info.png

Belangrijke opmerkingen: 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. 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:

NHG tabel 6: Code burgerlijke staat NIET GEBRUIKEN IN HL7-BERICHTEN
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"

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:

EducationLevel [2.16.840.1.113883.5.1077]
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

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

NHG tabel 20: Code opleiding [2.16.840.1.113883.2.4.4.30.20]
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"

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

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)

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.

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:

NHG tabel 11: Code sociale laag [2.16.840.1.113883.2.4.4.30.11]
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

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)

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

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

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

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)

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

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

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)

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.

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.

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.

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.

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.

XML-voorbeeld

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

 

R_AssignedOrganization [universal]

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.

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.

 

E_Organization (organisatie)

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

 

E_Organization [identified]

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.

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]

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.

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

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.

  Naar boven

CMET's

Naar hoofdstuk CMET