CMET A CareStatement

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.

Documenthistorie

Versie	Datum	Omschrijving
6.10.0.0	12-10-2011	RFC37712: code in ObservationIntolerance niet gespecificeerd
6.10.0.0	12-10-2011	RFC36120: Mapping NHG tabel 45 eenheden op UCUM tbv metingen
6.10.0.0	12-10-2011	RFC40061: Verduidelijking term Medicatie in PS
6.10.0.0	12-10-2011	RFC42204: „<0,01‟nog open – Mapping tabel 45 eenheden op UCUM tbv metingen
6.10.0.0	12-10-2011	RFC42205/42687: Oplossing voor onmogelijkheid om verschil tussen beheer- en inhoudsverantwoordelijke te kunnen maken.
6.10.0.0	12-10-2011	RFC39650: Attribuut nillable="true" verwijderd, behalve in Class „REPC_MT000100UV01Observation„
6.10.0.0	12-10-2011	RFC43229: Beschrijving hoe een ontvanger van een waarneembericht om moet gaan met de volgende situaties: Ontvangen van een waarneembericht voor een onbekende patiënt. ONtvangen van een waarneembericht dat al eerder is ontvangen
6.10.0.0	12-10-2011	RFC35966: Tekst bij Reason in tabel EpisodeOfCondition aangepast.
6.10.0.0	12-10-2011	RFC35357: Tekst over kwalificatie van metingen
6.10.0.0	12-10-2011	RFC 35349: artikelnummer verplicht met translation naar PRK en/of GPK.
6.10.0.0	12-10-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).
6.10.0.0	12-10-2011	Geherstructureerde versie van v6.0.5.0.

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.

Common Message Element Types

Dit hoofdstuk bevat de beschrijving van de domein specifieke CMET‟s. Voor de basisinformatie over de functie en de varianten van CMET‟s wordt hier verwezen naar de [HL7v3 IH Basis]. Ook de CMET‟s R_AssignedPersonNL, R_AssignedPerson[identified], R_PatientNL, R_AssignedEntityNL_PO zijn daar beschreven.

CMET R_AssignedEntityNL_PO

De CMET R_AssignedEntityNL_PO wordt gebruikt om zorgverleners, medewerkers en derden (personen of organisaties) mee te geven. Om redundantie te vermijden, wordt de auteur, als de verantwoordelijke (vaste) arts, hier verplicht meegegeven in de contextControlCode, zodat die als standaardwaarde overal elders niet ingevuld hoeft te worden. In het geval van een professionele samenvatting die door een HAP wordt opgeleverd wordt de HAP (organisatie) als auteur van de PrimaryCareProvision act meegegeven, de behandelend arts wordt als auteur van de encounter meegegeven. We gebruiken de volgende attributen: id (AGB of UZI-nummer), addr (adres), telecom (voor telefoonnummer, faxnummer of e-mailadres) en name (van Person of name van Organization (voor de naam van de entiteit)). Indien de naam van een Persoon wordt meegegeven dan kan de organisatie namens welke een rol wordt vervuld meegegeven worden in de CMET E_Organization [universal]. Voor het overige wordt verwezen naar [HL7v3 IH Basis].

CMET R_patientNL

Attribuut	Beschrijving
id	Verplicht, interne identificaties van patiënt binnen zendend systeem.
addr	Indien thuisadres van patiënt aanwezig is in zendend systeem is dit verplicht (code HP). Er mogen verschillende adressen worden meegegeven, een bezoekadres gaat mee met code PHYS.
telecom	Telefoonnummers, fax en e-mail kunnen worden meegegeven. INdien er een of meerdere telefoonnummers aanwezig zijn in zendend systeem, is dit minimaal één keer verplicht. FOrmaat is + nn ccc cc cccc met nn is landelijke toegangscode en cc ccc cccc het 10-cijferige telefoonnummer zonder 0 (resteert dus 9 cijfers).
statusCode	'active' indien patiënt ingeschreven is, 'terminated' indien patiënt is uitgeschreven. De statusCode 'terminated' zal bij een PS en WB niet voorkomen.
effectiveTime	'In- en uitschrijfdatum van patiënt kunnen hierin meegegeven worden. Indien bekend moet de tijd ook worden meegegeven.

Relatie
Organisation (identified)
Person

De CMET Organisation (identified) behorend bij de Patient, gebruiken we optioneel, alleen om het Id attribuut (bijvoorbeeld de AGB-code) van de praktijk mee te geven.

CMET E Person

Van CMET E_Person gebruiken we de volgende attributen:

Attribuut	Beschrijving
name	Patiëntnaam volgens het datatypen PN. zie [HL7v3 IH Basis] voor een gedetailleerde beschrijving.
administrativeGender	Geslacht van patiënt
birthTime	Geboortedatum van patiënt
deceasedInd	Alleen gebruiken ('true') indien patiënt overleden is, waarbij overlijdensdatum onbekend is
deceasedTime	Overlijdensdatum
educationLevelCode	Opleiding van patiënt is optioneel (moet ontvanger dus wel toestaan)

De CMET E_Person heeft een aantal relaties: ContactParty, Birthplace, Employment, PatientOfOtherProvider en CoveredParty

Relatie	Beschrijving
ContactParty	een naam (in Person) en telefoonnummer (in telecom van ContactParty) van een betaler kan hier worden meegegeven. Code staat op „PAYOR‟
BirthPlace	geboorteplaats wordt meegegeven indien aanwezig in zendend systeem
Employment	in occupationCode mag een beroep uit WCIA tabel 11 worden meegegeven (optioneel, dus ontvanger moet het toestaan)
PatientOfOtherProvider	Indien de auteur niet de vaste huisarts is, kan hier de vaste huisarts worden meegegeven (is optioneel). Indien de vaste huisarts wordt meegegeven, dan is een id in HealthCareProvider (AGB of UZI) verplicht en een naam (in ProviderPerson) optioneel.
CoveredParty	Verzekeringsgegevens van de patiënt. Een verzekeringsnummer gaat mee in de „Id‟ van PolicyOrAccount, het type verzekering in de „code‟ van PolicyOrAccount en de identificatie van de verzekeraar wordt als AGB-code of als UZOVI nummer meegegeven in 'id' van CarrierRole, terwijl de naam van de verzekeraar meegaat in 'name' van CarrierOrganization.

CMET A JournalEntry

R-MIM:	COCT_RM120000NL
HL7v3artefacttype:	CMET
HL7v3 gestructureerde naam:	A_JournalEntry [universal]
Herkomst:	AORTA

Voor het statisch model van COCT_MT120000NL_JE wordt verwezen naar R-MIM Journaalregel.

De CMET A_JournalEntry wordt gebruikt om een vrije tekstregel mee te geven, die niet gecodeerd maar wel gestructureerd is volgens de SOEP-structuur. Indien bij een zendend systeem bekend is dat een vrije tekst regel een Plan bevat, dient de ontvanger dat mee te krijgen. Wanneer bij een zendend systeem bekend is dat een dossierregel hoort onder een van de andere CMET‟s in de choicebox, maar er geen gestandaardiseerde code aanwezig is (maar bijvoorbeeld een lokale code) dan wordt hiervoor deze JournalEntry niet gebruikt, maar in de betreffende andere CMET wordt in het code of value attribuut een lokale code meegegeven indien dit is toegestaan (CD CWE type). Indien lokale codes in het betreffende CMET niet zijn toegestaan en indien het niet mogelijk is om een vertaling naar een standaardcode te maken (eenmalig per gebruiker), dan dient de regel als JournalEntry mee te gaan, waarbij de SOEP code als volgt toegevoegd mag worden: Een diagnose wordt een E, een medicatievoorschrift en –aflevering wordt een P, een bepalingsaanvraag en –resultaat wordt een O, een verwijzing en een niet-medicamenteuze therapie wordt een P.

CMET A Diagnosis [universal] (COCT_MT120100NL) Diagnose

R-MIM:	COCT_RM120100NL
HL7v3artefacttype:	CMET
HL7v3 gestructureerde naam:	A_Diagnosis [universal]
Herkomst:	AORTA

Voor het statisch model van COCT_MT120100NL wordt verwezen naar R-MIM Diagnose.

De CMET A_Diagnosis wordt gebruikt om een diagnose mee te geven. De auteur van een diagnosecode zal meestal een arts zijn. Vooruitlopend op de situatie dat ook de patiënt de auteur van een diagnosecode kan zijn, wordt deze mogelijkheid ondersteund.

CMET A MedicationCombinedOrder [universal] (COCT_MT932000NL) Medicatievoorschrift

In deze CMET worden de gegevens van voorschriften opgenomen. Zie HL7v3-domeinspecificatie Pharmacy. In deze CMET moet voor de PS wel een voorschrijfdatum/tijd in author worden opgegeven. Er hoeft echter geen voorschrijvend arts zelf te worden opgegeven (omdat die default gelijk is aan de huisarts). De link naar R_AssignedPerson is nillable gemaakt om hierin te voorzien; R_AssignedPerson hoeft dus niet gevuld te worden. Ook subject hoeft niet te worden opgegeven omdat die gelijk is aan de patiënt. Bij voorschrijven op artikelnummer (KNMP-nummer in MedicationKind.code) moet de PRK en/of GPK verplicht in de translation worden opgenomen. Attribuut doseCheckQuantity wordt niet gebruikt.

CMET A_ContraIndication[universal] (COCT_MT120100NL_CI) ContraIndicatie

R-MIM:	COCT_RM120100NL_CI
HL7v3 Nederlandse naam	Contra-indicatie
HL7v3artefacttype:	CMET
HL7v3 gestructureerde naam:	A_ContraIndication [universal]
Herkomst:	AORTA

Voor het statisch model van COCT_MT120100NL_CI wordt verwezen naar R-MIM ContraIndicatie.

Contra-indicaties en ongewenste middelen worden zoveel mogelijk gemapt naar codelijsten uit de G-standaard, zodat medicatiebewaking door de waarnemer mogelijk is.

De CMET A_ContraIndication wordt gebruikt om contra-indicaties mee te geven die gebruikt worden voor de medicatiebewaking. Hoewel contra-indicaties kunnen worden vastgelegd in de vorm van een diagnosecode, behoren niet alle diagnosecodes tot de contra-indicaties. Gebruikelijk is om die zaken die een zorgverlener als contra-indicatie geregistreerd heeft via een code uit Thesaurus 040 van de [G-Standaard] op te nemen op het niveau van een PCP. Een dergelijke contra-indicatie kan vaak gemapt worden op een ICPC-code en andersom. Zowel in versie 3 als in versie 4 van de [NHG HIS-tabellen] hanteert het NHG een vertaaltabel (tabel 27A) waarin 22 ICPC-codes naar codes uit Thesaurus 040 worden omgezet. Zo kan een K74 uit de ICPC-lijst (Angina Pectoris) aanleiding zijn om, al dan niet via een bevestiging van een arts, de contra-indicatiecode 70 uit de TH040 toe te voegen aan het dossier. Om te zorgen dat de medicatiebewaking geen hinder ondervindt van deze wijzigingen, wordt de CMET ContraIndication gebruikt om het volgende mee te geven:

• Een contra-indicatie (thesaurus 040);
• Een contra-indicatie in de vorm van een diagnosecode (ICPC).

Beide zijn door de arts, verantwoordelijk voor de PrimaryCareProvision, als contra- indicatie benoemd in het dossier van de patiënt. Een zogenaamde „afgeleide contra- indicatie‟ is een contra-indicatiecode die op basis van prescripties (automatisch) gegenereerd is.

CMET A ObservationIntolerance

R-MIM:	COCT_RM120104NL
HL7v3 Nederlandse naam:	Intolerantie
HL7v3artefacttype:	CMET
HL7v3 gestructureerde naam:	A_ObservationIntolerance [universal]
Herkomst:	AORTA

Voor het statisch model van COCT_MT120104NL wordt verwezen naar R-MIM Intolerantie.

Uit de functionele beschrijving van de [G-Standaard] komt het volgende citaat: “De 'ongewenste groepen, ongewenste stoffen en ongewenste handelsproducten' (is 'ongewenste middelen') vormen samen met de 'contra-indicaties' de patiëntkenmerken. Bij ongewenste middelen gaat het niet uitsluitend om een allergie, er kunnen andere redenen zijn om een stof of groep van stoffen niet af te leveren aan een bepaalde patiënt, bijvoorbeeld een bijwerking. Ook kan de toedieningsweg van een stof hierbij een rol spelen. Het kan ook voorkomen dat het product van een bepaalde fabrikant niet gewenst is, bijvoorbeeld door een hulpstof. Met behulp van de door het softwarehuis geleverde optie 'ongewenste middelen' kan de gebruiker de betreffende ongewenste stof, de groep van stoffen, of het betreffende product zelf selecteren en koppelen aan de patient, met opgave van de reden van de koppeling. Als de patient een geneesmiddel krijgt voorgeschreven, moet het systeem controleren of dit middel al dan niet ongewenst is.”

De CMET A_ObservationIntolerance wordt gebruikt om het volgende mee te geven:

• Individuele bestanddelen, oftewel stoffen op basis van stofnaamcode (SNK).
• Individuele bestanddelen in combinatie met een toedieningsweg (SSK).
• Ongewenste groepen, oftewel groepen medicijnen met een ongewenste stof.
• Ongewenst handelsprodukt (bestand 030 (handelsprodukten)).

CMET A_CareStatement [care provision] (REPC_MT000100UV01) KLinische bewering

R-MIM:	REPC_RM000100NL
HL7v3artefacttype:	CMET
HL7v3 gestructureerde naam:	A_CareStatement [care provision]

Voor het statisch model van REPC_MT000100UV01 wordt verwezen naar [HL7v3 DS Care Provision].

A_CareStatement wordt gebruikt voor diagnostische bepalingen (uitslagen). De CMET A_CareStatement is beschreven in [HL7v3 DS Care Provision]. Van de daar beschreven klassen wordt door Hwg alleen gebruik gemaakt van de klassen Observation, Organizer, Act en enkele participaties. In deze paragraaf wordt de klasse Observation ingevuld, samen met ReferenceRange en ObservationRange, zoals deze gebruikt wordt bij uitslagen.

• Metingen moeten kunnen worden ontvangen vanaf AORTA v6.0.5.0
• Verzenden is verplicht als er gekwalificeerd wordt voor v6.0.5.0, maar is in productie niet toegestaan tot alle AORTA v5.x systemen uitgefaseerd zijn vanwege versie incompatibiliteit. Ingangsdatum is 1 december 2010.