7prica:V6.10 PriCa D MIM Additionele informatie over registratietypes Episode concepten

Uit informatiestandaarden
Versie door Schmohl (overleg | bijdragen) op 15 aug 2013 om 12:03 (Episode concepten)
Ga naar: navigatie, zoeken

{{#customtitle: Episode concepten|Episode concepten}}

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

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.