Voorbeeld Diabetes Mellitus (samenhangende zorgvragen)

Dit materiaal is onderdeel van HL7v3-domein Primary Care V6.10_HL7v3-domeinspecificatie_Primary_Care. Compatible wijzigingen/nadere bewoordingen, tikfouten kunnen direct in de Wiki gewijzigd worden Open issues die discussie vergen s.v.p. in de commentaarsectie opnemen.

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.

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.

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.

In alle voorbeelden wordt ICPC met subcodes gebruikt. Bij het samenstellen van de voorbeelden is uitgegaan van versie ICPC-1-2000NL, deze versie ondersteunt het gebruik van subcodes. Indien deze versie in de berichten 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.