CMETs22:R Patient

From Hl7book

Jump to: navigation, search

 

Contents

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)

File:COCT RM050000NL.png

De CMET R_Patient [universal] bevat de volgende gegevensklassen:

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


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

Patient Patiëntgegevens

De klasse Patient heeft de volgende kenmerken:

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


De klasse Patient heeft de volgende associaties:

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


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

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


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

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


Image: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.
Image: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.

Image: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.


Image: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.

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

Image: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.

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

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

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


XML-voorbeeld

Een actieve patiëntregistratie.

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


Vooralsnog niet gebruiken in de Nederlandse situatie.

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


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

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


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

XML-voorbeeld

De toegang tot de patiëntgegevens is beperkt.

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


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

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


XML-voorbeeld

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

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

 

Informatiemodel R_PatientNL [identified] (COCT_RM050001NL)

File:COCT RM050001NL.png

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

De CMET R_Patient [identified] bevat de volgende gegevensklassen:

Patient Patiëntidentificatie

De klasse Patient heeft de volgende kenmerken:

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


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


Zie Patient.id bij R_Patient [universal].

Personal tools