Implementatiehandleiding HL7v3 basiscomponenten v2.2 Part3
HL7v3 Basiscomponenten deel 3
Contents
- 1 Inleiding
- 2 Datatypes
- 3 CMET's
- 3.1 Inleiding
- 3.2 Algemene beschrijving van CMET varianten
- 3.3 R_PatientNL (patiënt)
- 3.4 E_Person NL (persoon)
- 3.4.1 Functie
- 3.4.2 Informatiemodel E_PersonNL [universal]
- 3.4.3 Klasse Person (Persoon)
- 3.4.4 Klasse Employment (Beroep)
- 3.4.5 Klasse ContactParty (Contactpersoon/contactpersonen)
- 3.4.6 Klasse PatientOfOtherProvider (Relatie met huisarts/andere zorgverlener)
- 3.4.7 Klasse Birthplace (Geboorteplaats)
- 3.5 R_AssignedPerson (zorgmedewerker)
- 3.6 R_AssignedOrganization (zorginstelling)
- 3.7 R_AssignedDevice (apparaat)
- 3.8 R_AssignedEntity (verantwoordelijke)
- 3.9 E_Organization (organisatie)
- 3.10 E_Place (plaats)
- 3.11 R_LocationLocatedEntity (locatie)
Inleiding
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:
|
|
|
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:
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 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. |
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. |
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:
|
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:
| 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:
| 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:
|
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" |
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 |
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" |
| 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:
|
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:
|
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 |
| 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):
| 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).
| 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.
