R-MIM COCT_RM120104NL Intolerantie

{{#customtitle:HL7v3-domeinspecificatie Primary Care|HL7v3-domeinspecificatie Primary Care}}

Inleiding

Doel en scope

Deze pagina 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 informatiestandasard Huisartswaarneemgegevens (HWG) beschreven in [HL7v3 IH Hwg]. Dit document beschrijft de D-MIM's en R-MIM's, de message types en common message element types zijn terug te vinden in ART-DECOR.

Doelgroep voor deze pagina

De doelgroep bestaat uit productmanagers en softwareontwikkelaars van informatiesystemen die de gegevensuitwisseling in de eerste lijn willen implementeren.

Relatie met logische domeinen

Deze pagina heeft een relatie met het Ontwerp Huisartswaarneemgegevens. In dit ontwerp staat beschreven hoe de informatiestandaard Huisartswaarneemgegevens (HWG) is ontworpen, en hoe deze standaard het (zorg)proces ondersteunt.

Legenda

Er wordt in de implementatiespecificatie enkele malen het volgende symbool gebruikt:

Domain Message Information Models

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 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 het Ontwerp Huisartswaarneemgegevens. Het model beschrijft een groot deel van de gegevens in het huisartsdossier.

Figuur 1 REPC_DM000001NL

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.

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.

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.

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 het Ontwerp Huisartswaarneemgegevens. 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
• Registratie van Consultloze maar wel-Episodegebonden informatie
• Registratie van Consultgebonden, niet-Episodegebonden informatie
• Registratie van Consult- en Episodegebonden informatie

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 op deze pagina aan de hand van een aantal voorbeelden (vage klachten, darmkanker en diabetes mellitus) 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), Contact en Deelcontact (al dan niet als Consult).

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 (episodeOfCondition). Het type relatie is „sequelTo‟, er wordt op die manier aangegeven dat de nieuwe episode een oudere vervangt.

II. Hoofdzaken en bijkomende zaken

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.

III. 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 „SOEP-combinaties‟ of „diagnose-behandel-combinaties‟ onder één overkoepelende diagnose te kunnen plaatsen.

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 e-mail 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:	Conditie
Pad in het D-MIM PRICA	(1) PCP - A_ObservationIntolerance (CMET) of A_ContraIndication
Toelichting:	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

Voorbeelden:	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 die niet onder een daadwerkelijk patiëntconsult is vastgelegd maar onder een episode.

Registratie Consultgebonden informatie, niet Episodegebonden

Voorbeelden:	Vage klachten
Pad in het D-MIM PRICA	(1) PCP – (2) Encounter – (3) A_JournalEntry in choicebox (Activities)
Toelichting:	In dit geval wordt EpisodeOfCondition niet aangedaan, maar worden de vage klachten via Encounter in journaalregels vastgelegd.

Registratie Consult- en Episodegebonden informatie

Voorbeelden:	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).
• 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 act-references) 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.

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.

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.

R-MIM QUPC_RM990001 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_RM990001

Beschrijving van R-MIM QUPC_RM990001

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.

R-MIM REPC_RM004001NL_PS Professionele Samenvatting

D-MIM:	REPC_DM000001NL
HL7v3 artefacttype:	R-MIM
HL7v3 gestructureerde naam:	PCP Extract NL
Herkomst:	AORTA

Figuur 3 R-MIM REPC_RM004001NL_PS

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.

R-MIM REPC_RM004001NL_WR Waarneembericht

D-MIM:	REPC_DM000001NL
HL7v3 artefacttype:	R-MIM
HL7v3 gestructureerde naam:	PCP Locum Report NL
Herkomst:	AORTA

Figuur 4 R-MIM REPC_RM004001NL_WR

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.

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

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.

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.

R-MIM COCT_RM932000NL Medicatievoorschrift

Voor een beschrijving van de CMET A_MedicationCombinedOrder (medicatievoorschrift) zie [HL7v3 DS Pharmacy].

R-MIM COCT_RM120100NL_CI ContraIndicatie

D-MIM:	POOB_DM000000UV
Nederlandse naam:	Contra-indicatie
HL7v3 artefacttype:	R-MIM
HL7v3 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 worden gebruik indien de participanten afwijken van de context (contact, gehele PS) waar deze klasse gebruikt wordt.

R-MIM COCT_RM120104NL Intolerantie

D-MIM:	POOB_DM000000UV
Nederlandse naam:	Intolerantie
HL7v3 artefacttype:	R-MIM
HL7v3 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.