HL7v3-domeinspecificatie Primary Care

Transcriptie

1 HL7v3-domeinspecificatie Primary Care 1 Datum: 23 december 2014 Versie: Referentie: [HL7v3 DS Primary Care]

2 2 Nictiz is het landelijke expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. Met en voor de zorgsector voorziet Nictiz in mogelijkheden en randvoorwaarden voor elektronische informatie-uitwisseling voor en rondom de patiënt. Wij doen dit ter bevordering van de kwaliteit en doelmatigheid in de gezondheidszorg. Nictiz Postbus CC Den Haag Oude Middenweg AC Den Haag 3 T info@nictiz.nl

3 Inhoudsopgave 1 Inleiding Doel en scope Doelgroep voor dit document Relatie met logische domeinen Documenthistorie Legenda Domain Message Information Models D_MIM REPC_DM000001NL Eerste lijns zorgdomein model PrimaryCareProvision (PCP) CMET s aan PCP EpisodeOfCondition ActReference AnnotationObsEvent Encounter CMET s in Activities (choicebox) Additionele informatie over registratietypes Refined Message Information Models R-MIM QUPC_RM Opvraagbericht R-MIM REPC_RM004001NL_PS Professionele Samenvatting R-MIM REPC_RM004001NL_WR Waarneembericht R-MIM COCT_RM120000NL_JE Journaalregel R-MIM COCT_RM120100NL Diagnose R-MIM COCT_RM932000NL Medicatievoorschrift R-MIM COCT_RM120100NL_CI ContraIndicatie R-MIM COCT_RM120104NL Intolerantie Berichten Message Type QUPC_MT Opvragen Professionele Samenvatting querybyparameter patientid Message Type REPC_MT004001NL_PS Professionele Samenvatting PrimaryCareProvision subject author performer custodian component pertinentinformation component component choicebox component

4 component Message Type REPC_MT004001NL_WR Waarneembericht PrimaryCareProvision subject component pertinentinformation component choicebox Common Message Element Types CMET R_AssignedEntityNL_PO CMET R_PatientNL CMET E_Person CMET A_JournalEntry [universal] (COCT_MT120000NL_JE) Journaalregel JournalEntry author performer dataenterer CMET A_Diagnosis [universal] (COCT_MT120100NL) Diagnose ObservationDx author performer dataenterer CMET A_MedicationCombinedOrder [universal] (COCT_MT932000NL) Medicatievoorschrift CMET A_ContraIndication[universal] (COCT_MT120100NL_CI) ContraIndicatie ContraIndication author dataenterer CMET A_ObservationIntolerance[universal] (COCT_MT120104NL) Intolerantie ObservationIntolerance author CMET A_CareStatement [care provision] (REPC_MT000100UV01) Klinische bewering observation referencerange observationrange Aanmelden gegevens Aanmelden (MFMT_IN002101) Heraanmelden en afmelden Bijlage A Referenties...65 Bijlage B Overzicht domeinberichten...66 Bijlage C Overzicht gebruikte vocabulaire...67 C.1 AdministrativeGender ( ) C.2 NoteCategory ( ) HL7v3-domeinspecificatie Primary Care, v

5 C.3 MaritalStatus ( ) C.4 Soort Journaalregel ( ) C.5 Soort contact ( ) C.5.1 NHG tabel 14 versie C.5.2 NHG tabel 14 versie C.6 Code verrichtingen ( ) C.7 ActPriority ( ) C.8 ActStatus ( ) C.9 Confidentiality ( ) C.10 ObservationInterpretation ( ) Bijlage D Overzicht gebruikte OID s...74 Bijlage E Mapping eenheden NHG tabel 45 - UCUM...75 Bijlage F Voorbeeldberichten...76 HL7v3-domeinspecificatie Primary Care, v

6 105 6 HL7v3-domeinspecificatie Primary Care, v

7 Inleiding 1.1 Doel en scope Dit document beschrijft het domein Primary Care, het HL7-domeinmodel voor de eerstelijnszorg. Dit model is de basis voor de HL7 versie 3 interacties ten behoeve van communicatie in de eerste lijn. Deze interacties zijn voor de zorgtoepassing Huisartswaarneemgegevens (Hwg) beschreven in [HL7v3 IH Hwg]. Dit document beschrijft de D-MIM s, R-MIM s, message types en andere domeinspecifieke onderdelen. 1.2 Doelgroep voor dit document De doelgroep bestaat uit productmanagers en softwareontwikkelaars van informatiesystemen die de gegevensuitwisseling in de eerste lijn via AORTA willen implementeren. 1.3 Relatie met logische domeinen Dit document heeft een relatie met document [Def huisartsendomein]. In dat document is het logische domein voor huisartsen beschreven. 1.4 Documenthistorie Versie Datum Omschrijving dec-2014 Bestandsnaam document aangepast naar bestandstitel door bestandsnaam te wijzigen van AORTA_7PriCa_Def_PrimaryCaredomein_HL7 naar HL7v3- domeinspecificatie_primary_care. Referenties (Bijlage A) voor HWG documentatie aangepast naar Tekstuele aanpassing in Bijlage F. Versienummer opgehoogd naar v n.a.v. bovenstaande aanpassingen okt-2011 RFC37712: code in ObservationIntolerance niet gespecificeerd okt-2011 RFC36120: Mapping NHG tabel 45 eenheden op UCUM tbv metingen okt-2011 RFC40061: Verduidelijking term Medicatie in PS okt-2011 RFC42204: <0,01 nog open Mapping tabel 45 eenheden op UCUM tbv metingen okt-2011 RFC42205/42687: Oplossing voor onmogelijkheid om verschil tussen beheeren inhoudsverantwoordelijke te kunnen maken okt-2011 RFC39650: Attribuut nillable="true" verwijderd, behalve in Class REPC_MT000100UV01Observation okt-2011 RFC43229: Beschrijving hoe een ontvanger van een waarneembericht om moet gaan met de volgende situaties: 1. Ontvangen van een waarneembericht voor een onbekende patiënt. 2. Ontvangen van een waarneembericht dat al eerder is ontvangen okt-2011 RFC35966: Tekst bij Reason in tabel EpisodeOfCondition aangepast okt-2011 RFC35357: Tekst over kwalificatie van metingen okt-2011 RFC 35349: artikelnummer verplicht met translation naar PRK en/of GPK okt-2011 RFC 46138: Vanwege optionaliteit of niet meer van toepassing zijn geen beschrijving van FamilyHistory, Marker, Procedure en Referral, predecessor, Documents, MedicationDispenseEvent ObservationRequest en ObservationEvent. Deze mogen niet gebruikt worden (conformance X) okt-2011 Geherstructureerde versie van v HL7v3-domeinspecificatie Primary Care, v

8 Legenda Er worden in de implementatiespecificaties bij de berichtspecificaties regelmatig de volgende symbolen gebruikt: Let op! Dit is een aandachtpunt. Een opmerking die de aandacht vestigt op een bepaald opvallend aspect. Dit is een open issue of known issue. Een kwestie die nog open ligt voor discussie, maar onderkend is. Dit is een frequently asked question (FAQ) met antwoord De specificatie van een bericht wordt aan de hand van de XML-structuur van het bericht beschreven. In de volgende tabel worden alle onderdelen van het bericht beschreven in de volgorde van hun voorkomen in het bericht. Element: IdentifiedPerson Pad: CS 1..1 M Bevat de elementklasse. CONF Bevat de vaste waarde ASSIGNED id II 1..* M BSN Bevat één of meer identificaties van de persoon. CONF Er moet een element id zijn met het burgerservicenummer in het en met de OID in het addr AD 0..* C Adres Bevat het adres van de persoon. CONF Het adrestype moet, indien bekend, worden gecommuniceerd in het Element een XML-element van een interactie, een contextnode zoals die in de XMLstructuur van de interactie voorkomt. Element komt in het model (D-MIM / R-MIM) overeen met een klasse (Role, RoleLink, Entity, Act, ActRelationship, Participation) Pad XPath-expressie. Hiërarchisch pad tot en met het element boven het eigenlijke element, de zogenaamde parent node. Er worden geen volledige en geen absolute paden gegeven, omwille van bondigheid en omdat elementen ook op allerlei plaatsen hergebruikt kunnen worden. Als het element het root element betreft dan is het pad leeg. Als het element een onderdeel van de Transmission Wrapper betreft, begint het pad met <interactionid>/. Als het element een onderdeel van de Control Act Wrapper betreft, dan begint het pad met ControlActProcess/. Als het element een deel van het Message Type (Payload) of een Common Message Element Type (CMET) betreft dan begint het pad met het eerste element van dat Message Type/die CMET met. Als het element een deel is van een query begint het pad met QueryByParamaterPayload/... Subelement onderdeel van het element dat in deze tabel beschreven wordt. Een onderdeel kan in XML een attribuut of een element zijn. Onderdelen die beginnen met zijn een XML-attribuut; de overige onderdelen zijn een XML-element. 8 HL7v3-domeinspecificatie Primary Care, v

9 DT definieert het datatype van het onderdeel. Zie [HL7v3 IH Basis] voor meer informatie over datatypen. Kard - definieert de kardinaliteit van het onderdeel. Dit bepaalt het aantal keer dat het onderdeel mag/moet voorkomen. Zie [HL7v3 IH Basis] voor meer informatie over kardinaliteit. C - definieert de conformiteit van het attribuut. M - mandatory (vereist) R - required (verplicht ondersteunen) O - optioneel C - conditioneel verplicht F - fixed (vaste waarde ongeacht of deze voorkomt. Alleen te gebruiken voor structuurattributen etc.)). X - het onderdeel mag voorkomen, maar wordt niet meegenomen in de verwerking van de interactie NP - niet toegestaan (not permitted) betekent dat het onderdeel niet mag voorkomen (en ook niet aanwezig is in het onderliggend schema). LBA - logisch berichtattribuut. Logische berichten en hun attributen zijn in [Ontw Hwg] beschreven. Wanneer het LBA niet ingevuld is betekent dit dat er geen overeenkomstig attribuut in het ontwerp beschreven is. Definitie definitie van de functie van het onderdeel CONF Iedere subelementrij wordt gevolgd door een rij met nul of meer conformanceregels. HL7v3-domeinspecificatie Primary Care, v

10 Domain Message Information Models 2.1 D_MIM REPC_DM000001NL Eerste lijns zorgdomein model Dit hoofdstuk omvat een algemene beschrijving van het D-MIM (core structure) voor het Primary Care domein. De herkomst van het D-MIM wordt hier vermeld. De voor Aorta relevante delen van het D-MIM worden weergegeven in een afbeelding m.b.v. een statisch model. HL7v3 artefacttype D-MIM HL7v3 gestructureerde naam Primary Care Domain Model NL Herkomst AORTA, gebaseerd op [MEDEUR] Het domeinmodel REPC_DM000001NL is de uitwerking van het huisartsendomein zoals beschreven in [Def huisartsendomein]. Het model beschrijft een groot deel van de gegevens in het huisartsdossier. 10 HL7v3-domeinspecificatie Primary Care, v

11 2 3 Figuur 1 REPC_DM000001NL HL7v3-domeinspecificatie Primary Care, v

12 Het Primary Care model (PRICA) kent als ingang een PrimaryCareProvision (PCP) in de Event mood omdat het in de eerstelijnscommunicatie van (deel)dossiers vrijwel altijd om een registratie van medische handelingen gaat. Deels gaat het om statische informatie, gegevens die in de loop van de tijd redelijk stabiel blijven en rechtstreeks te koppelen zijn aan de patiënt (overgevoeligheden), deels gaat het om dynamische informatie, de registratie van het beloop in de tijd (registratie van anamnese en lichamelijk onderzoek, voorschriften, correspondentie, uitslagen; dit alles al dan niet verder gestructureerd in de vorm van SOEP, journaal en/of episodes). Een PCP bevat op hoofdlijnen: episodedefinities (weer te geven als een samenstel van episodes-of-condition en diagnoses, afhankelijk van de definitie die zender of ontvanger hanteert ten aanzien van episode of probleem), consulten (encounters) met dossierregels (activities), eventueel consultloze dossierregels (activities), contra-indicaties en allergieën (waaronder alle ongewenste groepen). Contacten kunnen vervolgens weer vrije tekst-regels bevatten, voorschriften (medication-combined-order), diagnoses, metingen (observaties) en verwijzingen (referral) met ontslaginformatie. De verschillende onderdelen van het model worden hierna kort beschreven PrimaryCareProvision (PCP) Het startpunt (Entrypoint) van het D-MIM PRICA is aan PCP gekoppeld. Het centrale object in het model is het PCP. Alle gegevens benodigd voor de berichten zijn aan dit object gekoppeld. Dit is in feite de container van een eerstelijnsdossier CMET s aan PCP Sommige data-elementen kunnen op verschillende plaatsen een rol spelen en worden dan als herbruikbaar blokje (CMET) in het D-MIM opgenomen. Zo kan een diagnosecode worden gebruikt in een diagnoseregel binnen het contact, maar ook in de definitie van een probleem- of episodeontwikkeling of in een conditie. De volgende CMET s zijn in het model aan PCP opgenomen: A_Diagnosis: diagnose A_ContraIndication en A_ObservationIntolerance: worden gebruikt voor het vastleggen van condities (allergie en overgevoeligheid). R_AssignedPerson/R_AssignedPersonNL: beschrijving van een persoon in zijn rol als zorgmedewerker. Als author de verantwoordelijke persoon, als dataenterer de registrerende persoon, als performer de uitvoerende persoon. R_AssignedEntityNL_PO: wordt gebruikt om zorgverleners, medewerkers en derden (personen of organisaties) te beschrijven. Als author is dit de vaste huisarts die verantwoordelijk is voor het beheer van het dossier. R_PatientNL: wordt gebruikt voor het vastleggen van administratieve patiëntgegevens; speelt de rol van de patiënt Patiëntkoppeling Veel CMET s bevatten een verwijzing naar de patiënt waarop het gegeven betrekking heeft (bijv. de persoon waarvan een familieanamnese is bepaald). Deze patiënt is bij het gebruik van deze CMET s binnen het huisartsdossier echter niet gevuld, omdat deze wordt bepaald door de patiënt die aan de focal class (PrimaryCareProvision) hangt. Impliciet wordt ervan uitgegaan dat alle CMET s betrekking hebben op deze zelfde patiënt. 12 HL7v3-domeinspecificatie Primary Care, v

13 Persoon- en organisatiekoppeling Wat betreft de rollen van personen en organisaties, heeft het PRICA-model (D-MIM inclusief de bijbehorende CMET s) alleen de author, custodian, dataenterer en performer nodig. De author is degene die (inhouds)verantwoordelijkheid draagt voor de betreffende medische gebeurtenis. De dataenterer is degene die de medische gebeurtenis heeft geregistreerd. De performer (uitvoerende) van een medische gebeurtenis in een eerstelijnsdossier is bijna altijd de auteur. Omdat de verwijzingen vanuit PCP en de CMET A_CareStatement ook naar organisaties of instrumenten kunnen gaan, wordt hier de Assigned_Entity gebruikt. In alle andere gevallen wordt Assigned_Person gebruikt om de geldende restricties zoveel mogelijk modelmatig vast te leggen. In de AssignedPerson kan desgewenst worden meegegeven namens welke organisatie de persoon handelt. Om onderscheid te kunnen maken tussen inhoudsverantwoordelijkheid en beheerverantwoordelijkheid is de participatie custodian in het model opgenomen. Een custodian kan aan een PrimaryCareProvision en aan een Encounter worden gekoppeld. Voor het proces van de waarneming is de custodian koppeling aan Encounter van belang. Als een waarneemcontact in het dossier van de vaste huisarts wordt opgenomen dan blijft de waarnemer de author van dat contact. De vaste huisarts kan dan als custodian aan de Encounter worden toegevoegd om expliciet te maken dat de vaste huisarts de beheerverantwoordelijkheid overneemt. De custodian participatie op PrimaryCareProvision niveau kan worden gebruikt om, indien dit van toepassing is, onderscheid te maken tussen inhoudsverantwoordelijkheid en beheerverantwoordelijkheid. Dit komt met name voor bij groepspraktijken waar de organisatie als beheerverantwoordelijke optreedt. Dit betekent niet dat in elk bericht altijd alle personen en organisaties worden verstuurd. Als algemene regel geldt dat alleen die personen en/of organisatie worden meegestuurd die van belang zijn voor de meegestuurde medische inhoud en als zodanig in het bronsysteem zijn vastgelegd. Wat betreft de identificatie van personen en organisaties: in de medische gegevens (de payload van de berichten) mag naast de UZI ook de AGB-code gebruikt worden. De identificatie van zorgverleners en gemandateerde medewerkers in de wrappers van de berichten vereist echter UZI-nummers. Deze UZI-nummers zijn noodzakelijk voor authenticatie en autorisatie op het Landelijk Schakelpunt. Verder is van belang dat degene die verantwoordelijk is voor de zorgrelatie met de patiënt (meestal de vaste huisarts ) degene is die als zender optreedt. Dit is nodig voor de authenticatie en autorisatie op basis van de gegevens op de envelop (de wrapper waar de zender en ontvanger in horen). Als vaste huisarts wordt deze persoon meegegeven in de CMET E_Person. Dit is nodig om de consistentie te waarborgen met andere berichten (bv. het voorschrijfbericht) waar de auteur een voorschrijver is en dat hoeft niet de vaste huisarts te zijn. Als deze arts de verantwoordelijke is voor de meeste consulten, komt die ook als auteur van de PCP mee. Dat is handig omdat die dan doorgegeven (overerfd; in HL7 middels contextcontrolcode) kan worden bij elke contactgebonden activiteit. Een dergelijke overerving houdt in dat standaard als auteur bij alle acts, de auteur van de PCP ingevuld wordt, tenzij de act zelf een andere auteur aangeeft EpisodeOfCondition Groeperingstructuur om zaken die medisch gezien onder één noemer vallen te koppelen en te voorzien van diagnosecodes. De EpisodeOfCondition wordt gebruikt om een episode mee te benoemen. De periodes van voorkomen worden in EpisodOfCare vastgelegd. HL7v3-domeinspecificatie Primary Care, v

14 EpisodOfCare bevat de begindatum van het eerste contact. EpisodOfCare gaat in een volgende versie uit het model verdwijnen; in een volgende versie wordt ActReferences direct aan een EpisodeOfCondition gekoppeld ActReference Referentie vanuit EpisodeOfCondition naar Activities uit de Choicebox met Clinical Statements. Dit kan zowel een consultloze als consultgebonden Clinical Statement zijn. Door het gebruik van deze referentie is het niet nodig zowel bij de encounter als bij de EpisodeOfCondition de volledige activities op te nemen AnnotationObsEvent AnnotationObsEvent kan worden gebruikt om overdrachtgegevens (informatie in de vorm van een vrije tekst beschrijving van een specifieke aard) die bij een PCP horen mee te geven. Te denken valt aan een SOS notitie, een waarneemnotitie, sociale gegevens of attentieregels Encounter Encounter wordt gebruikt om een consult of contact mee te geven. Een PrimaryCareProvision hoeft geen consulten te hebben, maar een consult heeft altijd minimaal 1 Activity (dossieritem of dossierregel). Een Deelcontact bestaat uit die Activities die met hetzelfde sequencenumber verbonden zijn aan de Encouter. Vanuit een EpisodeOfCondition kan ook verwezen worden naar deze Activities. Indien alle Activities van een Encounter onder dezelfde episode vallen, kan op deze wijze een episodekoppeling met een consult worden gerealiseerd. Indien ook het sequencenumber meegenomen wordt, kan zelfs ieder deelcontact aan een episode gehangen worden (via de ActReferences) CMET s in Activities (choicebox) De volgende CMET s komen in de choicebox voor: A_Diagnosis: diagnose A_MedicationCombinedOrder: voorschrift A_JournalEntry: vrije tekst (journaal)regel A_CareStatement: uitslagen en correspondentie Welke gegevens en welke filter op de gegevens moeten worden meegenomen is beschreven in [Ontw Hwg]. Vanwege optionaliteit of niet meer van toepassing zijn wordt er geen beschrijving van FamilyHistory, Marker, Procedure en Referral, predecessor, Documents, MedicationDispenseEvent ObservationRequest en ObservationEvent gegeven. Het wordt afgeraden deze elementen te gebruiken Additionele informatie over registratietypes Om het PRICA-model op hoofdlijnen nader toe te lichten is er voor gekozen om de verschillende registratietypes te doorlopen. Hierbij gaat het om de verschillende manieren waarop de dynamische informatie kan worden vastgelegd en verder gestructureerd. Dit betekent onder andere dat het PRICA-model verschillende registratietypes moet dekken. Het berichtenverkeer rondom een patiënt in de eerstelijns zorg omvat een aantal soorten registraties die veelvuldig voorkomen, te weten: Registratie van Consultloze en niet-episodegebonden informatie (zie ) Registratie van Consultloze maar wel-episodegebonden informatie (zie ) Registratie van Consultgebonden, niet-episodegebonden informatie (zie ) Registratie van Consult- en Episodegebonden informatie (zie ) 14 HL7v3-domeinspecificatie Primary Care, v

15 De bovenstaande registratietypes zijn af te leiden uit het PRICA-model. Aan de hand van deze registraties kan men het PRICA-model (Figuur 1 REPC_DM000001NL) stap voor stap doorlopen. Deze registraties zullen hieronder aan de hand van een aantal voorbeelden (zie , , ) toegelicht worden. Voordat bovenstaande registratietypes besproken worden, is het van belang eerst de definitie van een aantal concepten te bespreken. Het gaat dan vooral om de concepten Episode (al dan niet als Probleem; zie ), Contact en Deelcontact (al dan niet als Consult; zie ) Episode concepten De diverse definities van Episode zijn op verschillende wijze reeds in vele systemen geïmplementeerd. Ook heeft de jarenlange discussie door zorgverleners niet tot algemeen geaccepteerde definities geleid. Voor de modellering van dergelijke concepten hoeft dit geen probleem te zijn, mits men de te onderscheiden structuren maar eenduidig benoemt en aangeeft hoe men vanuit de concepten van een zendend en ontvangend systeem een vertaling naar deze structuren dient te maken. Het NHG definieert de episode als de chronologische verzameling van medische gegevens (episode-items) van één patiënt die de toestandsverandering in de tijd weergeeft betreffende één gezondheidsprobleem. De episode-items dienen verplicht aan een episode gekoppeld te zijn en bestaan uit: deelcontactverslag voorschrift uitslag van een bepaling brief (dwz. tekstsamenvatting, niet het volledige origineel) Niet-episodegebonden informatie betreft: aanvraag voor diagnostische bepaling familieanamnese behandeling/operatie/profylaxe allergie / intoleranties sociale gegevens In dit document wordt geen poging ondernomen om één definitie vast te leggen, maar zijn de volgende structuren onderscheiden: I. Voortschrijdend inzicht Een arts kan in eerste instantie denken aan een diagnose, maar later blijkt dat de diagnose toch bijgesteld moet worden en uiteindelijk blijkt alles door een dieper liggende oorzaak gekarakteriseerd te kunnen worden. Diverse werkhypothesen en/of diagnosen die zijn voorzien van een tijdstempel moeten dus aan elkaar gerelateerd kunnen worden wanneer ze een voortschrijdend inzicht weergeven betreffende één bepaalde zorgvraag. Meestal wordt hier verondersteld dat de laatste diagnose het best omschrijft wat er aan de hand is. Typisch voorbeeld hiervan is iemand die komt voor een benauwd gevoel, die de diagnose kortademig krijgt, die later een longprobleem blijkt te hebben, en dat blijkt later veroorzaakt door een hartprobleem. Omdat in het geval van voortschrijdend inzicht niet alleen de diagnose wordt aangepast, maar ook de episodetitel wordt gewijzigd, wordt dit in het model geïmplementeerd als een recursieve relatie op de episode HL7v3-domeinspecificatie Primary Care, v

16 (episodeofcondition). Het type relatie is sequelto, er wordt op die manier aangegeven dat de nieuwe episode een oudere vervangt. II. Hoofdzaken en bijkomende zaken III. Een patiënt kan last hebben van veel klachten die apart diagnosticeerbaar en behandelbaar zijn, maar toch vallen onder één overkoepelend ziektebeeld. Het is in feite een hiërarchische relatie: een parent met diverse children. Hoewel deze structuur in de praktijk nog nauwelijks wordt gebruikt voor de registratie van ziektebeelden, dient deze wel onderscheiden te worden van de andere structuren. Typisch voorbeeld hiervan is Diabetes mellitus waarbinnen verschillende zaken aan de orde kunnen zijn zoals een oogprobleem, voetproblemen, hoge bloeddruk, etc. Opnieuw optreden van eerder gediagnosticeerde ziekte Bij een patiënt is al een keer eerder een diagnose vastgesteld, maar de verschijnselen zijn een tijd over geweest en komen nu weer terug. Het gaat in principe om één en dezelfde diagnose, die in een latere periode terugkeert. Een bepaalde conditie (ziekte) kan dus verschillende zorgperiodes hebben. Typische voorbeelden hiervan zijn het jaarlijks voorkomen van klachten van hooikoorts, periodes met lage rugpijn of periodiek terugkomen van klachten van depressiviteit. De periodes van voorkomen worden in EpisodOfCare vastgelegd. EpisodOfCare gaat in een volgende versie uit het model verdwijnen omdat er geen use case voor is. Wanneer deze structuren in HL7 worden gemodelleerd worden de specifieke HL7v3- termen gebruikt. Structuur III is de meest eenvoudige van de drie. De zorgperiodes worden daarbij niet als aparte entiteit vastgelegd, maar uitsluitend in de vorm van contacten in het dossier opgenomen. Structuur I (voortschrijdend inzicht) kan voorkomen bij de concepten van structuur II en III en zou dus in die modellen moeten passen. Structuur II (hoofd- en bijzaken) kan gemodelleerd worden als een verwijzing vanuit het hele model naar een andere versie van het hele model via een component-of relatie. Om ingewikkelde nesting te voorkomen, kan overwogen worden dat deze relatie maar één niveau diep mag zijn: het is immers alleen bedoeld om bijvoorbeeld diverse SOEPcombinaties of diagnose-behandel-combinaties onder één overkoepelende diagnose te kunnen plaatsen. Het feit dat partij A structuur I Episode noemt, partij B juist structuur III en partij C structuur I juist een typisch voorbeeld vindt dat als Probleem zou moeten worden getypeerd, doet hier niet ter zake. De structuur is consistent met de HL7 modellen en is in staat om de drie te onderscheiden structuren op te nemen. Het is aan de zender en ontvanger om het zodanig te vullen/verwerken dat het zo veel mogelijk aansluit bij de wijze waarop de concepten zijn geïmplementeerd door de ICT-leveranciers in hun informatiesystemen HL7v3-domeinspecificatie Primary Care, v

17 In het vervolg van dit document gebruiken we het woord Episode voor structuur II (omdat HL7v3 het concept Episode zo hanteert): het is een ordenings- of groeperingsmechanisme. De structuren I en III passen echter ook op het model Contact/Deelcontact concepten Vaak wordt de term episode ook gehanteerd om onderscheid te maken tussen zaken die binnen één patiëntcontact ter sprake kunnen komen. Een zogenaamd deelcontact betreft dan die zaken die binnen een contact tot één episode behoren. Ook in de concepten contact en deelcontact spelen de diverse opvattingen over episodes een rol. Voor het modelleren is van belang dat er systemen zijn die episodeloze deelcontacten hebben. Ook al is dit niet ideaal en wordt dit door de beroepsgroep ontraden, de registratie van veel oude consulten is en blijft vaak episodeloos. Dat wil zeggen, een deelcontact kan worden onderscheiden als een aparte entiteit, zonder daarvoor een episode in welke zin dan ook nodig te hebben. Een arts heeft hierbij de mogelijkheid om bijvoorbeeld tijdens een consult een nieuw deelcontact te openen en daar van alles in te voeren, zonder een diagnose of episode aan te maken. Er is een groeperingsmechanisme waarmee contactregels aan elkaar gekoppeld kunnen worden wanneer ze onder één encounter vallen is. In het D-MIM is dit het sequencenumber in de relatie encounter-act. In het HIS Referentiemodel van het NHG [HIS_NHG_model] wordt een contact breed gedefinieerd als een zorginhoudelijke interactie tussen de zorgverlener en de patiënt en/of diens medisch dossier. Dus ook een bewerking door een praktijkmedewerker in het medisch dossier wordt gezien als een contact. Een consult kan in het NHG-model zowel op de praktijk (consult), bij de patiënt thuis (visite), per telefoon of via plaatsvinden. Wanneer we in het vervolg spreken over consultloze en consultgebonden zaken, hanteren we deze NHG-terminologie. Omdat het deelcontact in het NHG-model diverse activities/clinical statements kan bevatten is een groeperingmechanisme in de vorm van een sequence number afdoende voor de communicatie hiervan Registratie van Consultloze en niet Episodegebonden informatie Voorbeelden: Pad in het D-MIM PRICA Toelichting: Conditie (1) PCP A_ObservationIntolerance (CMET) of A_ContraIndication Wanneer er geen daadwerkelijke consulten zijn geweest waarin algemene zaken ten aanzien van patiëntconditie zijn vastgelegd, kan men condities zonder (nep)consulten opnemen Registratie Consultloze maar wel Episodegebonden informatie Voorbeeld: Labbepaling voor specifieke episode Pad in het D-MIM PRICA (1) PCP (2) EpisodeOfCondition (3) EpisodOfCare - (4) ActReference: Observation (A_CareStatement) in choicebox (Activities) Toelichting: Het is mogelijk om registraties te hebben waarbij er geen consult bestaat, maar wel een episode. In het PRICA-model is er daarom een directe relatie tussen PCP en Episode. Middels de ActReference aan de episode wordt er een verwijzing gemaakt naar een clinical statement (A_CareStatement) uit de choicebox (Activities); bijvoorbeeld een elektronisch ingelezen laboratoriumuitslag HL7v3-domeinspecificatie Primary Care, v

18 die niet onder een daadwerkelijk patiëntconsult is vastgelegd maar onder een episode Registratie Consultgebonden informatie, niet Episodegebonden Voorbeeld: Pad in het D-MIM PRICA Toelichting: Vage klachten (1) PCP (2) Encounter (3) A_JournalEntry in choicebox (Activities) In dit geval wordt EpisodeOfCondition niet aangedaan, maar worden de vage klachten via Encounter in journaalregels vastgelegd Registratie Consult- en Episodegebonden informatie Voorbeeld: Deelcontact Pad in het D-MIM PRICA (1) PCP (2) EpisodeOfCondition - (3) EpisodOfCare (4) ActReference en (1) PCP (2) Encounter (3) Choicebox (Activities) Toelichting: Dit is een situatie waarbij er een registratie wordt gedaan van Encounters gekoppeld aan een Episode. Om een expansie aan XML code te vermijden, is gekozen voor de verwijzing met Act-references. De episodestructuur wordt daarmee apart onder een PCP gehangen, terwijl de consulten met deelcontact-items ook apart onder de PCP hangen. De episodekoppeling van deelcontact-items wordt gerealiseerd via Act-references vanuit EpisodeOfCondition naar de Activities die onder een Encounter hangen. Zoals al eerder naar voren gebracht, is er geen Act Deelcontact opgenomen. De Deelcontacten kunnen desgewenst worden bijeengehouden door gebruik van hetzelfde sequencenumber in de relatie Encounter-choicebox (Activities) Om deze abstracte modellen en structuren enigszins voorstelbaar te maken, geven we enkele voorbeelden van episodeconstructies die in de eerstelijn gebruikelijk zijn Voorbeeld Vage klachten (minimale constructie) Een patiënt komt bij de arts met vage klachten. De huisarts codeert dit niet, stelt de patiënt wel gerust, maar verwijst twee weken later toch door naar de internist omdat de klachten na twee weken zijn verergerd. In een bericht gebaseerd op D-MIM PRICA ziet de registratie er als volgt uit: De twee contacten komen als onderdeel van het dossier (de PrimaryCareProvision) mee. In die contacten wordt o.a. de verantwoordelijke arts, de contactdatum en desgewenst ook de registrant en registratiedatum vastgelegd. In de koppeling naar de dossierregels van de betreffende contacten kan een deelcontactidentificatie worden meegegeven. In het eerste contact kunnen twee vrije tekst-regels (journaalregels) worden meegegeven, één met de tekst vage klachten (eventuele SOEP-codering S) en één met gerustgesteld (eventuele SOEP-codering P). 18 HL7v3-domeinspecificatie Primary Care, v

19 Er kan een episoderelatie worden meegegeven. De EpisodeOfCondition is dan vage klachten (in het attribuut text), er is geen diagnosecode. Vanuit de EpisodeOfCondition is er via EpisodOfCare een koppeling (via de actreferences) naar de vrije-tekst-regel gerustgesteld (en ook naar vage klachten indien deze naast episodenaam ook als dossierregel meegaat) en naar de verwijzing internist Voorbeeld Darmkanker (voortschrijdend inzicht) Patiënt komt bij huisarts met buikklachten. Ook is er vermoeidheid en een veranderd ontlastingpatroon. Huisarts verwijst naar MDL-arts en die doet nader onderzoek. Op de echo is niets zichtbaar. De MDL-arts rapporteert terug dat er geen aanwijzingen zijn voor aandoeningen op zijn terrein. De huisarts verandert de werkhypothese in vermoeidheid. Na twee maanden komt de patiënt weer bij huisarts en die constateert nu een zwelling in de buik. De huisarts verwijst opnieuw door naar internist. Uit de tweede ontslagbrief neemt huisarts de diagnose non-hodgkin lymfoom over. In een bericht gebaseerd op D-MIM PRICA ziet de registratie van dit voortschrijdend inzicht er in eerste instantie als volgt uit: De contacten komen als onderdeel van het dossier (de PrimaryCareProvision) mee. In die contacten wordt o.a. de verantwoordelijke arts, de contactdatum en desgewenst ook de registrerend persoon en registratiedatum vastgelegd. In het eerste contact kunnen vrije tekst-regels worden meegegeven met een beschrijving van de klachten. De beschrijving van de buikklachten kan resulteren in de aanmaak van een episode, die wordt meegegeven in EpisodeOfCondition. Nadat de MDL-arts een terugrapportage heeft gedaan wordt hiervan een verslag opgenomen zonder registratie van een consult (Clinical statement zit rechtstreeks aan PrimaryCareProvision en gaat niet via Encounter of EpisodeOfCondition). Op basis van de ontslagbrief wordt de episode-definitie bijgesteld: vermoeidheid in plaats van buikklachten. Er komt hierdoor een nieuwe Episode bij, waarbij een sequelto relatie wordt gelegd naar de bestaande EpisodeOfCondition. Indien buikklachten als een ICPC code D06.00 was geregistreerd, krijgt de nieuwe episode of condition nu als diagnosecode een A04.00 mee. De statuscode van de oude episode wordt obsolete, de high value van de effectivetime wordt gezet, de nieuwe episode krijgt de statuscode active, de effectivetime bevat alleen een low value en daarmee wordt het voortschrijdend inzicht in de loop van de tijd vastgelegd. De actreferences van een episode verwijzen naar alle clinical statements die behoren bij deze episode, ongeacht of ze bij een consult horen of niet. Na twee weken: Op dezelfde wijze (sequelto-relatie naar episode vermoeidheid) kan na twee weken een D24.00 (zwelling in buik) en daarna een epsiode met de diagnose B72.02 (non hodgkin lymfomen) worden toegevoegd. Als alternatief kunnen deze diagnosecodes ook uitsluitend worden meegegeven als diagnoseregels, met ActRefence en zonder sequelto-relatie, maar dan is de registratie niet als voortschrijdend inzicht door de ontvanger te herkennen. Wanneer de diagnoseregels wel allemaal aan één episode hangen, zou de ontvanger het kunnen afleiden, maar dergelijke impliciete semantiek dient zo veel mogelijk vermeden te worden. Wanneer een zender voortschrijdend inzicht wil sturen, gaat dat dus middels sequelto. Voortschrijdend inzicht moet dan uiteraard wel door de arts met sequentiële en gekoppelde episodes zijn geregistreerd. In alle voorbeelden wordt ICPC met subcodes gebruikt. Bij het samenstellen van de voorbeelden is uitgegaan van versie ICPC NL, deze versie ondersteunt het gebruik van subcodes. Indien deze versie in de berichten HL7v3-domeinspecificatie Primary Care, v

20 wordt gebruikt, zijn subcodes verplicht. N.B. het bovenstaande is niet van toepassing voor de Professionele samenvatting aangezien hier alleen de active episodes zijn opgenomen. Bovenstaande beschrijving geldt indien er sprake is van dossier overdracht d.m.v. HL7v3-berichten Voorbeeld Diabetes Mellitus (samenhangende zorgvragen) Een patiënt komt bij de huisarts met klachten over dorst en vermoeiheid. Uit de nuchtere bloedsuikerbepaling blijkt diabetes. Verwijzing naar oogarts levert retinopathie op. Zowel de diabetes mellitus als de retinopathie worden geregistreerd. Omdat de retinopathie in het kader van de diabetes behandeling geconstateerd is, wordt deze hieronder gerangschikt. In berichten gebaseerd op het D-MIM PRICA zal Diabetes als een Episode of Condition worden meegegeven (met een diagnosecode T90.00 en een Episode of Care), terwijl de retinopathie (met een diagnosecode F83.00 en een eigen Episode of Care) als Component van de diabetes-episode meegaat. Indien een informatiesysteem deze beschreven structuren ondersteunt en een gebruiker deze ook adequaat invult, kunnen ook alle combinaties van bovenbeschreven zaken voorkomen. Zo kan een patiënt met pijn op de borst een angina pectoris blijken te hebben die resulteert in een hartinfarct. Bij blijvende pijn op de borst zal de angina pectoris geregistreerd blijven met het infarct eronder. Wanneer de pijn niet meer terugkomt zal het hartinfarct de uiteindelijke diagnose zijn. 20 HL7v3-domeinspecificatie Primary Care, v

21 Refined Message Information Models In dit hoofdstuk worden de R-MIM s beschreven. R-MIM s zijn afgeleiden van een D-MIM. De berichtinhoud (de payload ) wordt bepaald door van R-MIM s afgeleide message types. Het R-MIM wordt afgebeeld in een statisch model. In dit hoofdstuk zijn ook de statische modellen van de domein specifieke CMET s opgenomen. 3.1 R-MIM QUPC_RM Opvraagbericht D-MIM: REPC_DM000001NL HL7v3 artefacttype: R-MIM HL7v3 gestructureerde naam: Primary Care EHR Extract Query Herkomst: AORTA Figuur 2 R-MIM R-MIM QUPC_RM Beschrijving van R-MIM QUPC_RM Het model van het opvraagbericht is zeer eenvoudig, de query kent slechts één parameter namelijk het BSN van de patiënt, dit is opgenomen in het value attribuut van de patientid klasse. Overzicht message types afgeleid van R-MIM QUPC_RM Message Types HL7v3 gestructureerde naam HL7v3 naam Primary Care EHR Extract Query QUPC_MT R-MIM REPC_RM004001NL_PS Professionele Samenvatting D-MIM: REPC_DM000001NL HL7v3 artefacttype: R-MIM HL7v3 gestructureerde naam: PCP Extract NL Herkomst: AORTA HL7v3-domeinspecificatie Primary Care, v

22 65 66 Figuur 3 R-MIM REPC_RM004001NL_PS 22 HL7v3-domeinspecificatie Primary Care, v

23 Beschrijving van R-MIM REPC_RM004001NL_PS De ingang voor dit model is de klasse PrimaryCareProvision, dit is als het ware de container voor de samenvatting. Aan PrimaryCareProvision zijn participaties (patiënt, auteur etc.) gekoppeld die betrekking hebben op de gehele samenvatting, daarnaast zijn er ook component relaties naar activiteiten die algemene patiëntkenmerken bevatten. Aan PrimaryCareProvision zijn ook de episodes (episodeofcondition) en contacten (encounter) gekoppeld. Contacten bevatten verschillende activiteiten (activities) en participaties. Episodes kunnen referenties (ActReference) naar activiteiten bevatten en gekoppelde diagnoses. Overzicht Message Types afgeleid van R-MIM REPC_RM004001NL_PS HL7v3 gestructureerde naam HL7v3 naam Primary Care Extract Query Response REPC_MT004001NL_PS 3.3 R-MIM REPC_RM004001NL_WR Waarneembericht D-MIM: REPC_DM000001NL HL7v3 artefacttype: R-MIM HL7v3 gestructureerde naam: PCP Locum Report NL Herkomst: AORTA HL7v3-domeinspecificatie Primary Care, v

24 Figuur 4 R-MIM REPC_RM004001NL_WR 24 HL7v3-domeinspecificatie Primary Care, v

25 Beschrijving van R-MIM REPC_RM004001NL_WR De ingang voor dit model is de klasse PrimaryCareProvision, dit is de container voor het waarneemcontact. Aan de PrimaryCareProvision zijn de patiënt, het waarneemcontact (encounter), een eventueel episodevoorstel (EpisodeOfCondition) en eventueel overdrachtgegevens (AnnotationObsEvent) gekoppeld. Het contact bevat koppelingen naar de activiteiten (activities). Vanuit het episodevoorstel kunnen referenties (ActReference) naar de activiteiten gelegd worden. Overzicht message types afgeleid van R-MIM REPC_RM004001NL_WR Message Types HL7v3 gestructureerde naam HL7v3 naam Primary Care Locum Report REPC_MT004001NL_WR 3.4 R-MIM COCT_RM120000NL_JE Journaalregel D-MIM: POOB_DM000000UV HL7v3 artefacttype: R-MIM HL7v3 gestructureerde naam: A_JournalEntry universal Herkomst: Afgeleid van COCT_RM120100UV A_ObservationDx [Universal] uit [HL7v3_Ballot8_Aug2004] Figuur 5 R-MIM COCT_RM120000NL_JE Beschrijving van R-MIM COCT_RM120000NL_JE HL7v3-domeinspecificatie Primary Care, v

26 JournalEntry is een specialisatie van Observation, alleen de attributen die noodzakelijk zijn voor het registreren van journaalregels zijn hier opgenomen. De optionele participaties worden gebruikt indien de participanten afwijken van de context (contact, gehele PS) waar deze klasse gebruikt wordt. Overzicht CMET s afgeleid van R-MIM COCT_RM120000NL_JE HL7v3 gestructureerde naam HL7v3 naam A_JournalEntry COCT_MT120000NL_JE 3.5 R-MIM COCT_RM120100NL Diagnose D-MIM: POOB_DM000000UV HL7v3 artefacttype: R-MIM HL7v3 gestructureerde naam: A_Diagnosis [universal] Herkomst: Afgeleid van COCT_RM120100UV A_ObservationDx [Universal] uit [HL7v3_Ballot8_Aug2004] Figuur 6 R-MIM COCT_RM120100NL Beschrijving van R-MIM COCT_RM120100NL ObservationDx is een specialisatie van Observation en wordt gebruikt om diagnoses gestructureerd vast te leggen. De optionele participaties worden gebruikt indien de participanten afwijken van de context (contact, gehele PS) waar deze klasse gebruikt wordt. 26 HL7v3-domeinspecificatie Primary Care, v

27 Overzicht CMET s afgeleid van R-MIM R-MIM COCT_RM120100NL CMET s HL7v3 gestructureerde naam HL7v3 naam A_Diagnosis [universal] COCT_MT120100NL 3.6 R-MIM COCT_RM932000NL Medicatievoorschrift Voor een beschrijving van de CMET A_MedicationCombinedOrder (medicatievoorschrift) zie [HL7v3 DS Pharmacy]. 3.7 R-MIM COCT_RM120100NL_CI ContraIndicatie D-MIM: POOB_DM000000UV Nederlandse naam: Contra-indicatie HL7 v3 artefacttype: R-MIM HL7 V3 gestructureerde naam: A_ContraIndication universal Herkomst: Afgeleid van COCT_RM120100UV A_ObservationDx [Universal] uit [HL7v3_Ballot8_Aug2004] Figuur 7 COCT_RM120100NL_CI Beschrijving van R-MIM COCT_RM120100NL_CI ContraIndication wordt gebruikt voor het gestructureerd vastleggen van diagnoses die een contra-indicatie kunnen vormen voor geneesmiddelen. De optionele participaties HL7v3-domeinspecificatie Primary Care, v

28 worden gebruik indien de participanten afwijken van de context (contact, gehele PS) waar deze klasse gebruikt wordt. Overzicht CMET s afgeleid van R-MIM COCT_RM120100NL_CI CMET s HL7 V3 gestructureerde naam HL7 V3 naam A_ContraIndication [universal] COCT_MT120100NL_CI 3.8 R-MIM COCT_RM120104NL Intolerantie D-MIM: POOB_DM000000UV Nederlandse naam: Intolerantie HL7 v3 artefacttype: R-MIM HL7 V3 gestructureerde naam: A_ObservationIntolerance universal Herkomst: Afgeleid van COCT_RM120100UV A_ObservationDx [Universal] uit [HL7v3_Ballot8_Aug2004] Figuur 8 COCT_RM120104NL Beschrijving van R-MIM COCT_RM120104NL ObservationIntolerance wordt gebruikt om overgevoeligheden en allergiëen vast te leggen. Severity kan gebruikt worden om de ernst van de reactie vast te leggen. De optionele participaties worden gebruikt indien de participanten afwijken van de context (contact, gehele PS) waar deze klasse gebruikt wordt. Overzicht CMET s afgeleid van R-MIM COCT_RM120104NL 28 HL7v3-domeinspecificatie Primary Care, v

29 672 CMET s HL7 V3 gestructureerde naam A_ObservationIntolerance [universal] HL7 V3 naam COCT_MT120104NL HL7v3-domeinspecificatie Primary Care, v

30 Berichten In dit hoofdstuk worden de domeinspecifieke message types beschreven. De berichtinhoud (de payload ) wordt bepaald door het message type. Message types zijn afgeleiden van een R-MIM. 4.1 Message Type QUPC_MT Opvragen Professionele Samenvatting R-MIM: HL7v3 artefacttype: HL7v3 gestructureerde naam: Herkomst: querybyparameter QUPC_RM Message Type Primary Care EHR Extract Query AORTA Element: querybyparameter Pad: ControlActProcess Subelement DT # C LBA Omschrijving Voor alle hier niet beschreven subelementen van QueryByParameterPayload zie [HL7v3 IH Wrp]. patientid 1..1 M De (gedeeltelijke) naam van de gezochte organisatie/het gezochte organisatiedeel. Zie patientid Element: patientid Pad: QueryByParameterPayload/ value II 1..1 M BSN Bevat één of meer identificaties van de persoon. CONF Er moet een element value zijn met het burgerservicenummer in het en met de OID in het 4.2 Message Type REPC_MT004001NL_PS Professionele Samenvatting R-MIM: HL7v3 artefacttype: HL7v3 gestructureerde naam: Herkomst: REPC_RM004001NL_PS Message Type Primary Care Extract Query Response AORTA Restricties voor het message type van de PS ten opzichte van het volledige dossier van de huisarts zijn beschreven in [Ontw Hwg]. In onderstaande tabel worden de items gekoppeld aan de HL7 termen. Groep / item Episode Contact Journaalregel Voorschrift Condities HL7 term EpisodeOfCondition, mostrecentencounter Encounter CMET A_JournalEntry CMET A_MedicationCombinedOrder CMET A_ObservationIntolerance CMET A_ContraIndication 30 HL7v3-domeinspecificatie Primary Care, v

31 Uitslag Overdrachtinformatie CMET A_CareStatement (Observation) AnnotationObsEvent In de op te leveren PS worden ook alle nog niet in het systeem verwerkte maar daar wel ontvangen waarneemberichten verwerkt PrimaryCareProvision Element: PrimaryCareProvision CS 0..1 F Dit attribuut heeft als vaste waarde PCPR heeft vaste waarde CS 0..1 F Dit attribuut heeft als vaste waarde EVN heeft vaste waarde EVN. id II 1..1 M Identificatie binnen oorspronkelijke systeem. CONF Verplicht aanwezig en mag hebben. CONF De waarde van id moet overeenkomen met de id van het object. CONF Voor id moeten zowel een waarde hebben, te bepalen door het oorspronkelijke systeem. text ED 0..1 O Beschrijving van de volledige PrimaryCareProvision in vrije tekst. statuscode CS CNE 1..1 M Mogelijke waarden zijn active of completed. CONF statuscode heeft de waarde active als de PS afkomstig is van de vaste huisarts, en de waarde completed als deze (in het geval dat het waarneemverslag niet verstuurd kon worden) afkomstig is van een waarnemer. Merk op dat a.d.h.v. de statuscode van de PrimaryCareProvision act kan worden vastgesteld of de PS afkomstig is van de huisarts (status= active ) of van een waarnemer (status= completed ). effectivetime IVL_TS 0..1 R Inschrijfdatum Inschrijfdatum van de patiënt wordt gevuld in Indien bekend moet de tijd ook worden meegegeven. Indien PS afkomstig van waarnemer zie waarde effectivetime in CONF Indien de inschrijfdatum van de patiënt bekend is moet deze worden gevuld in CONF Er mogen geen andere elementen of attributen worden gebruikt dan low/@value. confidentialitycode SET_CE CWE 0..* X Vertrouwelijkheidcode waarmee patiënt kan aangeven wie gegevens mag inzien. Gebruik: N (normal: geautoriseerde zorgverleners) of R (restricted: expliciete toestemming van patiënt vereist.) subject 1..1 M Geeft de participatie aan tussen PCP en de patiënt. Zie CONF Verplicht aanwezig en mag hebben. author 1..1 R Geeft de participatie aan tussen PCP en de verantwoordelijke arts. Zie CONF Wanneer de author onbekend is geldt de UNK. performer 0..* R Geeft de participatie aan tussen PCP en de uitvoerder(s). Wordt alleen gevuld als dit een andere is dan de author. Zie custodian 0..1 R Geeft de participatie aan tussen PCP en de beheerder. Zie component7 0..* R Geeft de relatie aan tussen PCP en episodeofcondition. Zie pertinentinformation 0..* R Geeft de relatie aan tussen PCP en HL7v3-domeinspecificatie Primary Care, v