HL7v3-domeinspecificatie conditie

Inleiding

Doel en scope

Dit document beschrijft het Conditiedomein, het HL7-domeinmodel voor potentiele contraindicaties. Dit model is de basis voor de HL7 versie 3 interacties ten behoeve van communicatie. Deze interacties zijn voor de zorgtoepassing Medicatieproces (Mp) beschreven in [Ontw Mp].

Op basis van de toepassingen die zijn beschreven in het ontwerp medicatieproces is een beperkt aantal interacties gekozen die in de implementatiehandleiding Medicatieproces ([HL7v3 IH Mp]) worden beschreven: Opvragen potentiële contra-indicaties (Patient Medical Conditions Query) en Opleveren potentiële contra-indicaties (Patient Medical Conditions Query Response).

In deze domeingids worden het statisch model (D-MIMs, R-MIMs, message types) behorend bij deze interacties en andere domeinspecifieke onderdelen uitgewerkt.

Doelgroep voor dit document

De doelgroep bestaat primair uit de systeemontwerpers en softwareontwikkelaars bij de leveranciers van zorg informatiesystemen (ook wel bekend als de ‘XIS leveranciers’) die medicatiebewaking willen ondersteunen. Daarnaast biedt het document echter achtergrondinformatie voor iedereen die de HL7 versie 3 specificaties inhoudelijk wil bekijken.

Relatie met logische domeinen

Dit document heeft een relatie met document [Def conditiedomein]. In dat document is het logische domein voor condities beschreven.

Documenthistorie

Versie	Datum	Omschrijving
6.10.0.0	12-okt-2011	RFC 46390: Verwijderen overgevoeligheidsquery en response
		RFC 46391: Niet toestaan van queryparameters: availabilityTimeInterval en ActId
		RFC 46392: Gebruik CMET als payload
		RFC 46393: Nieuwe functionele naamgeving generieke query en respons
		RFC 43032: Toestaan SHB contra-indicatiecodes als secundaire code
		RFC 44599: Verwisseling van OID’s SNK, SSK
		RFC 44599: Verwisseling van OID’s SNK, SSK
		RFC 44932: Voorbeeld informant op pag. 43 onjuist en onduidelijk (voorbeelden zijn in v6.10.0.0 niet opgenomen)
		RFC 45641: Afleiden of een conditie een “afgeleide conditie” is.
		RFC 24859: Inconsistentie Medicatiebewaking subject/R_Patient [Universal], en subject/R_Patient [Identified/Confirmable]
		RFC 29185: Onbekend codesysteem voor ernst van intolerantie in IH medicatiebewaking
6.12.0.0	3-mei-2013	Tussenrelease
6.12.1.0	1-juli-2013	Query-parameters actID en availabilityTimeInterval verwijderd.
		Query-parameters effectiveTimeInterval en authorOrPerformerRole optioneel.
		Tekst dat op zorgverlenerrol op ZIM gefilterd wordt verwijderd.
		Attribuut @negationInd: vaste waarde “false”.
		Element <code>: ingeperkte subset waarden (m.n. geen afgeleide contra-indicaties meer).
		Element <effectiveTime>: optioneel geworden.
		Element <confidentialityCode>: niet gebruiken.
		Element <uncertaintyCode>: vaste waarde “N”.
		Element <value>: nullFlavor “OTH” i.p.v. “NA” en @displayName verplicht bij gebruik <translation> (SHB-codes).
		Element <subjectOf1> (ernst): niet gebruiken.
		Element <condition><author> - toelichting hoe te gebruiken wanneer er geen auteur bekend is bij een historische conditie.

Legenda

Let op! Dit is een aandachtpunt. Een opmerking die de aandacht vestigt op een bepaald opvallend aspect

Dit is een 'open issue' of 'known issue'. Een kwestie die nog open ligt voor discussie, maar onderkend is.

Dit is een frequently asked question (FAQ) met antwoord.

C - definieert de conformiteit van het attribuut.

• M - mandatory (vereist)
• R - required (verplicht ondersteunen)
• O - optioneel
• C - conditioneel verplicht
• F – fixed (vaste waarde ongeacht of deze in het bericht voorkomt. Alleen te gebruiken voor structuurattributen (@classCode, etc.))
• X - het onderdeel mag voorkomen, maar wordt niet meegenomen in de verwerking van de interactie
• NP - niet toegestaan (not permitted) betekent dat het onderdeel niet mag voorkomen (en ook niet aanwezig is in *het onderliggend schema).

Refined Message Information Models

In dit hoofdstuk worden de R-MIM’s beschreven. 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 QUMT RM020099NL Generieke Act Query

D-MIM:	geen
HL7v3 artefacttype:	R-MIM
HL7v3 gestructureerde naam:	Generic Act Query
Herkomst:	Aorta

Figuur 1 R-MIM QUMT_RM020099NL

Beschrijving van R-MIM QUMT_RM020099NL

Deze query wordt aangeduid met de naam Generic Act Query, want de query kan in deze vorm gebruikt worden voor het opvragen van willekeurige Acts (activiteiten in HL7-termen). De volgende parameters worden in het model gebruikt:

• patientId: BSN;
• effectiveTimeInterval: Geldigheidstermijn;
• authorOrPerformerRole: Rol van de verantwoordelijk zorgverlener.

R-MIM REPC RM000003NL Medische Conditie

D-MIM:	geen
HL7v3 artefacttype:	R-MIM
HL7v3 gestructureerde naam:	Medical Condition

Figuur 2 R-MIM REPC_RM000003NL

Beschrijving van R-MIM REPC_RM000003NL

Dit model bevat enkel de CMET A_MedicalCondition waarin specifiek kenmerken van de toestand van de patiënt zijn opgenomen waaruit potentiële contraindicaties kunnen worden afgeleid. Voor een beschrijving zie "Medische Conditie".

R-MIM COCT RM000003NL Medische Conditie

D-MIM:	geen
HL7v3 artefacttype:	R-MIM
HL7v3 gestructureerde naam:	A_Medical Condition

Figuur 3 R-MIM COCT_RM000003NL

Beschrijving van R-MIM COCT_RM000003NL

Het kernbegrip in dit model is de klasse Condition, die staat voor een specifiek kenmerk van de toestand van de patiënt. De beschrijving van de specifieke interacties (zie [HL7v3 IH Mp]) licht toe hoe de aard van de conditie wordt doorgegeven in het bericht (dit ligt voor overgevoeligheden iets anders dan voor condities in het algemeen).

De Condition is dus het beginpunt (entry point) van elk bericht omtrent condities. Het is de zogenaamde focal class van deze berichten, oftewel de gegevensklasse waar het om draait. De klasse Condition geeft een aspect van de (lichamelijke of geestelijke) toestand van de patiënt aan dat relevant is binnen het patiënt dossier, ook al ligt vooralsnog de nadruk op medicatiebewaking.

Intolerantie of allergie is een vorm van een conditie (een aspect van de toestand van een patiënt). Elke intolerantie/allergie heeft betrekking op precies één veroorzakende stof. Deze veroorzaker (causativeAgent) kan betrekking hebben op een medicatie (handelsproduct) of een losse stof of groep stoffen (zgn. ongewenste groep).

Het huidige informatiemodel voor condities is puur gebaseerd op condities die relevant zijn voor medicatiebewaking. Dat wil zeggen dat bij het bepalen van het model en de gebruikte coderingen geen rekening wordt gehouden met bijvoorbeeld pollenallergie, patienteigenschappen en de meeste voedselintoleranties, die niet van belang zijn voor medicatie.

Net als bij alle andere observaties binnen HL7 worden de attributen code en value op een specifieke manier gebruikt om condities te classificeren. Het attribuut code duidt het type conditie aan en niet specifieke ziektebeelden of andere patiëntkenmerken. Het gaat bij het attribuut code alleen om een brede typering van het soort condities dat voorkomt. Op dit moment wordt dit attribuut vooral gebruikt om allergieën en andere overgevoeligheden als categorie te onderscheiden, maar in de toekomst zou dat verder kunnen worden uitgebreid (bijvoorbeeld om handicaps, chronische en acute aandoe¬ningen, complicaties etcetera te onderscheiden). Het attribuut value geeft daarentegen een classificatie van specifieke aspecten van de toestand van de pa¬tiënt aan en wordt bijvoorbeeld gebaseerd op een codering van diagnoses of allergieën.

Gekoppeld aan de Condition zijn een aantal belangrijke geassocieerde klassen:

• Het subject duidt de patiënt aan waarop de conditie betrekking heeft. Dit gebeurt door een CMET waarmee alle patiëntkenmerken kunnen worden meegegeven. Deze associatie is verplicht benoemd, aangezien de conditie anders contextloos is.
• De author heeft betrekking op de persoon die verantwoordelijk is voor het feit dat deze condition is vastgelegd (als onderdeel van het EPD van de patiënt). Dit is vrijwel altijd een zorgverlener, maar kan ook de patiënt zelf zijn als sprake is van bijvoorbeeld een online ingevuld vragenformulier over bestaande patiëntaandoeningen. Ook deze wordt verplicht benoemd bij elke conditie om het gegeven te borgen.
• De informant is de persoon (of personen) die de bron was voor de informatie over de conditie. Naast de patiënt zelf of de zorgverlener (die een diagnose stelt), kan het ook voorkomen dat een andere betrokken persoon als bron fungeert. Dit is bijvoorbeeld het geval bij een ouder/verzorger die informatie over een kind overdraagt.
• De causativeAgent (in de afbeelding hierboven aangeduid als participant) is alleen van toepassing op overgevoeligheden (inclusief allergieën). Dit betreft de relatie tussen de overgevoeligheid en de stof of het specifieke medicijn waarop die overgevoeligheid betrekking heeft (die dus de bron of veroorzaker ervan is).
• De predecessor legt een verband tussen de huidige conditie en een conditie die eraan voorafging. Als een zorgverlener bijvoorbeeld een bestaande conditie, geconstateerd door een andere zorgverlener, opnieuw bekijkt en tot een andere of aanvullende conclusie komt, dan kan hiermee de relatie bewaard worden. Merk op dat de aard van de relatie standaard “SUCC” (succeeds) is. Deze zegt alleen dat de huidige volgt op de conditie die wordt geïdentificeerd in ConditionReference. Dit maakt de huidige conditie dus nog geen vervanger van de conditie waaraan gerefereerd wordt.

Naast deze gegevensklassen komen er in de berichten nog een aantal klassen voor, waarmee bijvoorbeeld de ernst van de conditie en de opmerkingen van diverse zorgverleners over de conditie worden doorgegeven, alsook de mutaties die op de conditie zijn uitgevoerd. De details van alle relevante gegevenselementen wordt in de beschrijving van de Message Types ("Berichten") verder toegelicht.

Berichten

Alle berichten zijn te vinden in art-decor.

Common Message Element Types

CMET A_MedicalCondition (COCT_MT000003NL) Medische Conditie

R-MIM:	REPC_RM000003NL
HL7v3 artefacttype:	CMET
HL7v3 gestructureerde naam:	A_MedicalCondition

code

Het conditietype in de vorm van een brede indeling in categorieën. In eerste instantie is het daarbij vooral van belang om overgevoeligheden te kunnen onderscheiden van overige condities. Aangezien het vooralsnog alleen om overgevoeligheden voor medicatie gaat, kunnen daarvoor de codes DINT, DALG en DNAINT gebruikt worden. Alle overige conditietypes worden aangeduid met de algemene code DX (diagnose). Al deze codes zijn afkomstig uit het HL7 codesysteem ActCode, met als OID 2.16.840.1.113883.5.4. De huidige subset aan gebruikte codes wordt als volgt gedefinieerd:

Lvl	Concept Code head Code-defined Value Set	Code	Weergavenaam	Omschrijving
2	S: ObservationDiagnosisTypes (DX)	DX	ObservationDiagnosisTypes	An observation about the presence (or absence) of a particular disease state in a subject
3	S: ObservationDrugIntoleranceType (DINT)	DINT	Drug Intolerance	Hypersensitivity resulting in an adverse reaction upon exposure to a drug
4	L: (DALG)	DALG	Drug Allergy	An allergy to pharmaceutical product
4	L: (DNAINT)	DNAINT	Drug Non-Allergy Intolerance	Hypersensitivity to an agent caused by a mechanism other than an immunologic response to an initial exposure

Merk op dat in het HL7 code system het uitgangspunt is dat Intolerance een generiek concept is boven Allergy, in plaats van een zusterconcept náást Allergy. Dit is een veelvoorkomende misinterpretatie van het begrip Intolerance. Hierdoor ontstaat er een mismatch tussen de concepten en de daarbij gehanteerde codes, maar dat doet niets af aan de juiste betekenis: DINT: medicatieovergevoeligheid (niet nader gespecificeerd) DALG: medicatieallergie (overgevoeligheid o.b.v. immuunsysteem) DNAINT: medicatieintolerantie (niet-allergische overgevoeligheid)

Mogen ook afgeleide contra-indicaties worden doorgegeven? NEE, er is besloten dat afgeleide contra-indicaties geen plek hebben bij de uitgewisselde condities. Een afgeleide contra-indicatie is een conditie waarvan het bestaan (meestal o.b.v. geautomatiseerde regels) wordt afgeleid uit het bekend zijn van bepaalde medicatie bij een patiënt. Bijvoorbeeld: de patiënt gebruikt insuline, dus diabetes wordt bepaald als afgeleide contra-indicatie. Deze categorie wordt nadrukkelijk onderscheiden van expliciet vastgestelde condities, zelfs als deze vastgesteld worden door de apotheker (bijvoorbeeld doordat de patiënt zelf aan de apotheker vertelt dat hij diabetes heeft). Deze categorie wordt nadrukkelijk onderscheiden van expliciet vastgestelde condities, zelfs als deze vastgesteld worden door de apotheker (bijvoorbeeld doordat de patiënt zelf aan de apotheker vertelt dat hij diabetes heeft).

statusCode

Conditie status

Geeft aan welke status de conditie heeft. De mogelijke waarden daarbij zijn:

• active (default): de conditie is op dit moment aanwezig, dat wil zeggen het is een actueel aspect van de toestand van de patiënt.
• completed: de conditie is inmiddels ‘achter de rug’, dat wil zeggen de aandoening, allergie, zwangerschap, et cetera is ‘over gegaan’.
• obsolete: Een conditie die achterhaald is doordat dezelfde zorgverlener (als de auteur van de conditie) op basis van voortschrijdend inzicht een nieuwe conditie heeft geregistreerd.
• nullified: Een ONTERECHT geregistreerde conditie die ongedaan is gemaakt. Het gaat hier dus nadrukkelijk om een foutieve registratie die niet het standpunt van de auteur weergaf.

value

De primaire tabel die gebruikt wordt om dergelijke contra-indicaties mee te coderen is subtabel 40 van de thesaurus van de G-Standaard. In het kader van het ICA project van Nictiz heeft een uitbreiding van deze tabel plaatsgevonden, zodat hierin ook veel contra-indicaties verwerkt zijn uit de tabellen van de Stichting Healthbase (SHB) en het model EVS van het Nederlands Huisartsen Genootschap (NHG). De intentie was dat subtabel 40 daarmee afdoende zou zijn om alle marktpartijen de benodigde detaillering te bieden. Voor gebruikers van de SHB-tabel is dat punt echter nog niet bereikt, waar¬door er behoefte is om naast subtabel 40-codes ook SHB-codes te kunnen uitwisselen.

Zowel binnen de G-Standaard als in de tabellen van SHB wordt ook de relatie vastgelegd tussen (potentiële) contra-indicaties en de stoffen, stofgroepen en/of handelsproducten waarmee ze conflicteren, d.w.z. waarvoor ze een contra-indicatie zijn. Op die manier is de registratie van condities een belangrijke input voor de medicatiebewaking die veel leveranciers hebben geïntegreerd in hun software. Overigens is deze medicatiebewaking nog niet volledig uitgewerkt voor alle codes die recent in subtabel 40 zijn toegevoegd.

Hoe worden andere codes dan die uit subtabel 40 doorgegeven? Het is mogelijk om meer dan één conditieclassificatie door te geven, door het gebruik van <translation>-elementen in de XML-berichten. Indien mogelijk moet altijd een primaire code uit subtabel 40 worden doorgegeven. Systemen die andere interne codes gebruiken (m.n. die van de Stichting Healthbase) zullen dus intern een mapping naar de bijbehorende code uit subtabel 40 moeten ondersteunen, maar kunnen daarnaast de SHB-code doorgeven als <translation>. Alleen als er geen mapping beschikbaar is bij een SHB-code, mag nullFlavor=“OTH” worden gebruikt om aan te geven dat geen subtabel 40-code beschikbaar is. In dat geval is het overigens verplicht om de betreffende SHB-code door te geven als <translation> en om daarbij @displayName mee te geven met een tekstuele omschrijving. Ontvangende systemen die geen SHB-codes ondersteunen, mogen deze negeren. Eventueel kunnen ze wel @displayName van de SHB-code tonen, als geen subtabel 40-code en bijbehorende omschrijving aanwezig zijn.

Hoe worden allergieën en andere overgevoeligheden doorgegeven? Strikt genomen zou er een systeem van conditiecodes kunnen bestaan waar alle relevante overgevoeligheden in staan (in feite als diagnosecodes). Dergelijke codes (in de trant van ‘allergie voor ...’) bestonden tot voor kort wel in de G-Standaard, maar daar is nu gekozen voor een andere aanpak. Binnen subtabel 40 van de thesaurus komen dus alleen condities (meer specifiek: potentiële contra-indicaties) voor die los staan van een overgevoeligheid voor een specifieke stof, stofgroep of handelsproduct. De oplossing is dat in plaats van het attribuut Condition.value gebruik wordt gemaakt van een associatie met een specifieke stof, stofgroep of handels-product, zodat allergieën en andere overgevoeligheden op willekeurig niveau kunnen worden aangeduid. Dit is veel flexibeler dan het werken met specifieke conditiecodes voor elke denkbare overgevoeligheid, zeker als overgevoeligheden voor specifieke handelsproducten vastgelegd moeten worden (dit zou een redundante codering parallel aan de HPK’s opleveren). Men kan zeggen dat de stof- en productcoderingen zelf kunnen fungeren als conditiecode, maar dit is semantisch gezien niet juist. Iemand lijdt niet aan de conditie ‘penicilline’, maar aan ‘allergie voor penicilline’ en het is niet zuiver om de stofcode te ‘misbruiken’ in de betekenis van een conditie. Allergieën en andere overgevoeligheden worden aangeduid door een associatie met de betreffende stof/medicatie (zie causativeAgent).

Merk op dat dus in hetzelfde attribuut een veelheid aan coderingssystemen gebruikt kan worden. Duidelijk is dat hier behoefte is aan een vorm van terminologiestandaardisatie. Tot het moment dat die plaats vindt, wordt er aangesloten op bestaande coderingen. Voor de medicatiebewaking is dat zoals gezegd primair het volgende coderingssysteem:

Subtabel 40 van de thesaurus van de G-Standaard (contra-indicaties) Deze tabel geeft een beperkt aantal conditiecodes die zuiver zijn geclassificeerd vanuit hun rol als (potentiële) contra-indicatie bij bepaalde soorten medicatie. Dat wil zeggen dat sommige aandoeningen zeer ruim gecategoriseerd zijn (bijvoorbeeld hypertensie, dat vaak meer een symptoom dan een op zichzelf staande aandoening is), terwijl andere zeer specifiek zijn aangeduid (bijvoorbeeld GLUCOSE-6-FOSFAAT-DEHYDROGENASE-DEFICIENTIE, dat bij een specifieke groep medicijnen problemen oplevert). Ook zijn in deze lijst condities opgenomen die geen ziekte zijn, maar wel relevant kunnen zijn bij medicatiebewaking. Een voorbeeld hiervan is de vaak genoemde code voor ‘zwangerschap/kinderwens’. Er komen geen codes voor die specifiek bedoeld zijn om overgevoeligheden aan te duiden.

causativeAgent

Bij het doorgeven van de stof of stofgroep waarvoor een patiënt een allergie of intolerantie heeft, wordt gebruik gemaakt van de methodiek die hiervoor binnen de G-Standaard is ontwikkeld. Deze is gebaseerd op drie verschillende aanduidingniveaus:

• Individuele bestanddelen, oftewel stoffen op basis van stofnaamcode (SNK).

De OID voor deze G-Standaard tabel is 2.16.840.1.113883.2.4.4.1.750.

• Individuele bestanddelen in combinatie met een toedieningsweg (SSK).

De OID voor deze G-Standaard tabel is 2.16.840.1.113883.2.4.4.1.725.

• Ongewenste groepen, oftewel groepen medicijnen met een ongewenste stof.

De OID voor deze G-Standaard tabel is 2.16.840.1.113883.2.4.4.1.902.122.

Als de veroorzaker van de allergie of intolerantie op basis van een handelsproduct (HPK) wordt aangeduid, dan dient dit te gebeuren op basis van de CMET E_MedicationKind. In alle andere gevallen dient de klasse materialKind gebruikt te worden om de betreffende stof of stofgroep gecodeerd door te geven. De samenhang van deze codes is als volgt:

Ieder artikel met een aanwezig generiek niveau (GPK) heeft altijd één of meer werkzame stoffen. Bekijken we dit technisch gedetailleerder, dan gelden de volgende uitspraken: - Bij iedere GPK behoort precies één SPK. - Bij iedere SPK kunnen meerdere GPK’s behoren. - Eén of meerdere SPK’s kunnen bij één of meerdere SSK’s behoren. - Bij iedere SSK behoort precies één SNK. - Bij iedere SNK kunnen meerdere SPK’s behoren.

Met behulp van het volgende schema kan de software vanuit een bekende GPK de bijbehorende SPK, SSK’s en SNK’s traceren:

Art.nr.	:14668157	PARACETAMOL/CODEINEFOSFAAT	GF TABLET 500/50MG (30 ST)
HPK	:1474707	PARACETAMOL/CODEINEFOSFAAT	GF TABLET 500/50MG
PRK	41726	PARACETAMOL/CODEINE	TABLET 500/50MG
GPK	81140	PARACETAMOL/CODEINE	TABLET 500/50MG
SPK	31402
SSK-1	639	ORAAL en SNK:906	Paracetamol
SSK-2	22195	ORAAL en SNK:38938	CODEINE

Hulpstof 1	GNGNK:18732	MAGNESIUMSTEARAAT
Hulpstof 2	GNGNK:19488	SLICIUMDIOXIDE
Hulpstof 3	GNGNK:43702	CELLULOSE, MICROKRISTALLIJN
Hulpstof 4	GNGNK:46639	HYPROLOSE
Hulpstof 5	GNGNK:60607	CARBOXYMETHYLZETMEEL NATRIUM
Werkz. stof 1	GNGNK:906	PARACETAMOL
Werkz. stof 2	GNGNK:43702	CODEINE DIWATERSTOFFOSFAAT-0.5-WATER

Art.nr.	:15041220	MARVELON TABLET	(63 ST)
HPK	416681	MARVELON TABLET
PRK	16292	ETHINYLESTRADIOL/DESOGESTREL	TABLET 30/150UG
GPK	39578	ETHINYLESTRADIOL/DESOGESTREL	TABLET 30/150UG
SPK	25194
SSK-1	6939	ORAAL EN SNK:9342	ETHINYLESTRADIOL
SSK-2	18953	ORAAL EN SNK:30333	DESOGESTREL

Hulpstof 1	GNGNK:10553	LACTOSE 1-WATER
Hulpstof 2	GNGNK:13986	POVIDON
Hulpstof 3	GNGNK:16683	TOCOFEROL, DL-ALFA-
Hulpstof 4	GNGNK:16829	STEARINEZUUR
Hulpstof 5	GNGNK:19488	SILICIUMDIOXIDE
Hulpstof 6	GNGNK:34932	AARDAPPELZETMEEL
Werkz. stof 1	GNGNK:9342
Werkz. stof 2	GNGNK:30333

Art.nr.	14065525	MORFINE HCL CF INJVLST 10MG/ML AMPUL 1ML	(10 ST)
HPK	1043110	MORFINE HCL CF INJVLST 10MG/ML AMPUL 1ML
PRK	21652	MORFINE INJVLST 10MG/ML AMP 1ML
GPK	28746	MORFINE INJVLST 10MG/ML
SPK	18791
SSK	25941	PARENTERAAL en SNK:44598 MORFINE

Hulpstof 1	GNGNK:8729	NATRIUMCHLORIDE
Hulpstof 2	GNGNK:12564	ZOUTZUUR
Hulpstof 3	GNGNK:49735	WATER VOOR INJECTIES
Werkz. stof 1	GNGNK:620	MORFINE HYDROCHLORIDE-3-WATER

author

Alleen wanneer bij historische condities de auteur niet bekend is, mag de auteur leeg gelaten worden. Dit gebeurt door de assignedPerson/id én de assignedPerson/assignee/assigneePerson/name van een nullFlavor 'UNK' te voorzien.

XML voorbeeld:

<author>
    <time value="201302"/>         <!--  Deze alleen gebruiken als er een time stamp bekend is. -->
    <assignedPerson>
        <id nullFlavor="UNK"/>
        <assignee>
            <assigneePerson>
                <name nullFlavor="UNK"/>
            </assigneePerson>
        </assignee>
    </assignedPerson>
</author>

informant

Wanneer de patiënt de melder van de conditie is, wordt dat hier aangegeven. Gegevens van de patiënt staan elders in het bericht.

XML voorbeeld:

<!-- De melder is de patient -->
<informant>
    <patient classCode="PAT"/>
</informant>

Bewaking op allergiën

Inleiding

Patiënten kunnen allergisch zijn voor bepaalde stoffen of groepen van middelen (bijvoorbeeld sulfa’s, perubalsem, goudverbindingen). Maar er zijn ook andere redenen om bepaalde stoffen niet meer te willen voorschrijven of afleveren aan een patiënt. Denk hierbij bijvoorbeeld aan bijwerkingen. Daarnaast komt het voor dat een product van een bepaalde fabrikant niet gewenst is. Systemen kunnen een module bevatten waarmee zorgverleners ervoor waken dat een patiënt een middel krijgt voorgeschreven of afgeleverd waarvoor hij/zij allergisch is of dat hij/zij niet wenst.

Werking van het systeem

In het lokale elektronisch patiëntendossier dient te zijn opgenomen voor welk middel de patiënt allergisch is of welk middel hij/zij niet wenst. Op basis van dit dossier dient de zorgverlener door zijn computersysteem te worden ondersteund bij het voorkomen van het gebruik van middelen waarvoor de patiënt allergisch is of waarvan gebruik om andere redenen niet gewenst is.

Beheer van het elektronisch patiëntendossier In het lokale elektronisch patiëntendossier (EPD) wordt opgenomen voor welke stoffen of (groepen van) producten de patiënt allergisch is of welke om andere redenen ongewenst zijn. Degene die dit dossier beheert dient de mogelijkheid te hebben om een selectie te maken uit alle voorkomende bestanddelen van geneesmiddelen voor opname in het dossier. Dit kunnen zowel werkzame bestanddelen als hulpstoffen zijn . Zo nodig dient deze selectie verfijnd te kunnen worden tot een bepaalde toedieningsweg . Denk hierbij bijvoorbeeld aan tetracyclinecapsules die darmproblemen kunnen geven en tetracyclineoogzalf die wel gebruikt kan worden. Indien een bestanddeel geselecteerd is, dient de zorgverlener de vraag gesteld te worden of uitsluitend de stof of mogelijk een hele groep van producten “ongewenst” zijn . Denk hierbij bijvoorbeeld aan bestanddeel amoxiciline ten opzichte van de hele penicillinegroep. Bij het opgeven van een “ongewenste” groep zal de zorgverlener de vraag gesteld moeten worden of er wellicht sprake is van kruisovergevoeligheid met een andere groep zodat ook deze groep in het EPD opgenomen kan worden. Maar ook dient er de mogelijkheid te zijn om een selectie te maken uit een lijst met individuele producten voor opname in het dossier. Denk hierbij bijvoorbeeld aan generieke handelsproducten zoals Carbamazepine tablet 200mg (als per se Tegretol moet worden afgeleverd) .

Om bij een patiënt de bewaking op allergieën of ongewenste middelen te kunnen uitvoeren, dient het derhalve mogelijk te zijn om in het EPD de volgende items op te nemen:

• individuele bestanddelen;
• individuele bestanddelen in combinatie met een toedieningsweg;
• ongewenste groepen;
• individuele producten.

Allergie voor een hulpstof

Op het moment dat een voorschrijver medicatie voorschrijft, zal dit veelal op stofnaam zijn (voorschrijfproduct). Hierdoor geeft de voorschrijver niet exact aan welk product er afgeleverd zal worden. Per leverancier kunnen de hulpstoffen verschillen waarvoor de patiënt allergisch is. Bewaking vindt dan plaats bij aflevering in de apotheek. Maar zo kan een voorschrijver er ook voor kiezen om juist wel een specifiek product van een bepaalde leverancier voor te schrijven .

Controle In de G-Standaard zijn per product zowel de werkzame stoffen als de hulpstoffen opgenomen . In dit bestand is tevens de toedieningsweg per product opgenomen. Indien een specifiek product is voorgeschreven kan eenvoudig gecontroleerd worden op ‘ongewenst zijn’. Uitgangspunt hiervoor is de samenstelling van het specifieke product en de groepen waarin het product is ingedeeld , die in relatie worden gebracht met het EPD van de patiënt. Indien op stofnaam is voorgeschreven (voorschrijfproduct) zullen alle producten onder het voorschrijfproduct gecontroleerd moeten worden op allergie of ongewenstheid bij de patiënt (zie EPD). Zodra alle producten onder het voorschrijfproduct aangeven dat deze ongewenst zijn, dient de zorgverlener het advies te krijgen dat er beter een alternatief voorgeschreven of afgeleverd kan worden. Indien niet alle producten onder het voorschrijfproduct dit aangeven, dient getoond te worden welke producten gewenst en welke ongewenst zijn, waardoor gekozen kan worden voor een alternatief dat niet ongewenst is.

predecessor

Deze relatie kan gebruikt worden in diverse situaties waarbij het relevant is om aan te geven dat er een bepaald verband bestaat tussen twee conditie(registratie)’s. De meest voorkomende situatie waarin dit gebruikt zal worden, is als een arts de reeds bekende condities opvraagt en (mede) op basis daarvan zelf een registratie doet over hetzelfde patiëntkenmerk of een kenmerk dat daar direct mee samenhangt. Dit betreft dus bijvoorbeeld het volgende scenario:

• Arts X registreert dat patiënt A lijdt aan een lichte nierfunctiestoornis.
• Arts Y krijgt dezelfde patiënt A onder behandeling vanwege verhevigde klachten.
• Arts Y vraagt de bekende condities op (al dan niet via het LSP) en verkrijgt daarbij o.a. informatie omtrent de eerder door arts X vastgelegde conditie.
• Arts Y constateert dat de nierfunctiestoornis inmiddels ernstig van aard is. Daarnaast wil zij enige notities maken over het verloop van de klachten.
• Omdat arts Y geen mutaties kan uitvoeren op de conditieregistratie van arts X (die immers in een ander informatiesysteem heeft plaatsgevonden), doet arts Y een nieuwe registratie binnen het lokale EPD (voor dezelfde diagnose). Daarbij legt arts Y ook de ernst van de conditie en de bijbehorende notities vast.
• Om duidelijk te maken dat de twee conditieregistraties aan elkaar gerelateerd zijn, legt het systeem van arts Y een predecessor-relatie gelegd naar de registratie van arts X.
• Wanneer nu een derde arts een (samengevoegd) conditieoverzicht opvraagt, zullen daarin beide conditieregistraties opgenomen zijn, waarbij de registratie van arts Y toont dat deze gerelateerd is aan de registratie van arts X.

Het voordeel van bovenstaande werkwijze is dat beide artsen hun eigen informatiesystemen blijven gebruiken (er is geen gemeenschappelijke registratie), terwijl toch een verband kan worden gelegd tussen hun gegevens. Dankzij dit verband kan een opvragend systeem een betere (overzichtelijker) presentatie van de gegevens aan de gebruiker bieden.

Merk op dat het voor een juist gebruik van de referentie naar de voorgaande conditie essentieel is dat de volledige identificatie van deze conditie(registratie) wordt uitgewisseld en niet meer muteert in het bronsysteem. Deze randvoorwaarde geldt overigens in breder verband bij het leggen van relaties met externe gegevens in een virtueel EPD.

Aanmelden gegevens

Net als voor andere gegevenssoorten zullen ook de objecten die relevant zijn voor medicatiebewaking moeten worden aangemeld bij de verwijsindex van de ZIM, zodat deze daarna kan dienen voor het opvragen van deze gegevens bij de bronsystemen.

In [Ontw VWI] worden interacties met de verwijsindex op de AORTA beschreven met de mogelijkheid om categoraal of atomair aan te melden. In [Def conditiedomein] is de keuze voor categoraal aanmelden bij de verwijsindex vastgelegd. De relevante gegevenssoorten voor dit domein zijn in onderstaande tabel vermeld.

Tabel 1 Gegevenssoort (ActRegistryCode: x_DataDomainNl)

Level	Type, Domain name and/or Mnemonic code	OID	Code	Omschrijving	Register
X	L: (288432)	2.16.840.1.113883.2.4.15.4	288432	Conditie	VWI
X+1	L: (800310)	2.16.840.1.113883.2.4.15.4	800310	Overgevoeligheid	VWI

Condities (code gegevenssoort: “288432”)

Dit is een generieke gegevenssoort voor relevante ‘aspecten van de toestand van de patiënt’.

Overgevoeligheden (code gegevenssoort: “800310”)

Een specialisatie van condities wordt gevormd door overgevoeligheden voor specifieke stoffen of andere invloeden van buitenaf die een patiënt kan hebben.

Er worden niet alleen condities aangemeld die relevant zijn voor medicatiebewaking. Niet alle ‘condities’ van de patiënt (die onder andere alle bekende aandoeningen, handicaps etc. omvatten) zijn relevant voor medicatiebewaking, zelfs niet als gefilterd wordt op alleen ‘actieve’ condities. Dat is ook de reden waarom in de meeste huisartsinformatiesystemen een specifieke categorie ‘contra-indicaties’ wordt bijgehouden, oftewel condities waarvan bekend is dat ze mogelijk relevant zijn bij de medicatiebewaking.

Op dit moment is een standaardquery Opvragen potentiële contra-indicaties beschreven, die alle condities oplevert die matchen met Tabel 40 uit [G-Standaard] en medicatieovergevoeligheden. Het vragende systeem kan de opgeleverde gegevens zo nodig verder te filteren op relevantie voor medicatiebewaking.

De interacties, message types en R-MIM’s met betrekking tot aanmelden, heraanmelden en afmelden van gegevens zijn beschreven in [HL7v3 IH VWI] en [HL7v3 DS Shared Messages]. Voor enkele elementen geldt een specifieke of nadere invulling van de implementatierichtlijn. Deze worden hieronder beschreven.

Bijlage A Referenties

Tabel 2 Referenties

Referentie	Document	Versie
[Def conditiedomein]	Definitie conditiedomein	6.12.0.0
[G-Standaard]	G-Standaard	Huidige
[HL7v3_Ballot8_Aug2004]	HL7v3 Ballot8 augustus 2004	Ballot 8
[HL7v3 DS Shared Messages]	HL7v3-domeinspecificatie Shared Messages	6.11.0.0
HL7v3 DS Pharmacy	HL7v3-domeinspecificatie Pharmacy	6.12.0.0
[HL7v3 DS Care Provision]	HL7v3-domeinspecificatie Care Provision	6.11.0.0
[HL7v3 IH Basis]	Implementatiehandleiding HL7v3 basiscomponenten	2.2
[HL7v3 IH Mp]	HL7v3-implementatiehandleiding medicatieproces	6.12.0.0
[HL7v3 IH VWI]	HL7v3-implementatiehandleiding verwijsindex	6.11.0.0
[HL7v3 IH Wrp]	HL7v3-implementatiehandleiding berichtwrappers	6.11.0.0
[Ontw VWI]	Ontwerp verwijsindex	6.11.0.0
Ontwerp Mp	Ontwerp medicatieproces	6.12.7.0

Bijlage B Overzicht domeinberichten

Tabel 3 Overzicht domeinberichten

#	Logische bericht naam	Toepassing	HL7v3 interactienaam	Gestructureerde naam	HL7V3 Message Type
1	Opvragen potentiële contra-indicaties	Mp	REPC_IN000023NL	Patient Medical Conditions Query	QUMT_MT020099NL
2	Opleveren potentiële contra-indicaties	Mp	REPC_IN000024NL	Patient Medical Conditions Query Response	REPC_MT000003NL

Bijlage C.1 G-standaard thesaurus

code	Volledige omschrijving
0	ER IS GEEN CONTRA INDICATIE
18	HYPERTENSIE
24	ASTMA EN CHRONISCH OBSTRUCTIEVE LONGZIEKTEN
38	DEPRESSIESIE
42	EPILEPSIE
64	GLAUCOOM, NAUWE KAMERHOEK
66	GLAUCOOM, OPEN KAMERHOEK, ONBEHANDELD
67	GLAUCOOM NAUWE-KAMERHOEK & PRIMAIR OPEN-KAMERHOEK
70	ANGINA PECTORIS
72	HARTFALEN
78	GLUCOSE-6-FOSFAAT-DEHYDROGENASE-DEFICIENTIE
98	JICHT
118	LEVERFUNCTIESTOORNIS
136	MYASTHENIA GRAVIS
137	VERMINDERDE NIERFUNCTIE
158	ULCUS PEPTICUM
162	PARKINSON, ZIEKTE VAN
178	PSORIASIS
183	SCHILDKLIERAANDOENING
190	DIABETES MELLITUS
207	RISICOGROEP VOOR INFULENZAVACCINATIE
209	PORFYRIE
210	SPORTBEOEFENING
211	BENIGNE PROSTAATHYPERPLASIE
212	COELIAKIE
213	FENYLKETONURIE
214	REFLUXZIEKTE
215	SLAAPAPNEU
216	VENEUZE TROMBOSE
217	ARTERIELE TROMBOSE
218	LANG QT-INTERVAL SYNDROOM
219	VERKEERSDEELNAME
500 t/m 544	diverse genetische kenmerken
1300	KINDERWENS (MAN)
1310	KINDERWENS (VROUW)
1320	ZWANGERSCHAP
1330	BORSTVOEDING

Code ‘000’ (‘ER IS GEEN CONTRA-INDICATIE’) mag NIET gebruikt worden, omdat in de opzet van de HL7v3-berichten deze codes staan voor condities. Het valt nooit uit te sluiten dat later een conditie bekend wordt die toch als contra-indicatie fungeert. Hetzelfde effect wordt bereikt door gewoon geen condities terug te geven als antwoord op de Conditiequery (een specifieke conditie kan worden uitgesloten door deze door te geven met negationInd = ’true’). Let op: het doorgeven van een Condition met een nullFlavor als value is geen alternatief voor deze code, omdat dit betekent: ‘er is sprake van een conditie, maar ik weet niet welke (of ik heb er geen code voor)’.

De codes ‘207’ (‘RISICOGROEP VOOR INFLUENZAVACCINATIE’), ‘210’ (‘SPORTBEOEFENING’) en ‘219’ (‘VERKEERSDEELNAME’) zijn geen condities in de normale betekenis van het woord, maar duiden erop dat de patiënt behoort tot één van de risicogroepen voor influenzavaccinatie of dat hij/zij als (top)sporter onderhevig zal zijn aan dopingcontroles of dat hij/zij regelmatig bestuurder is van een verkeersvoertuig hetgeen ook een reden kan zijn voor niet voorschrijven van bepaalde soorten medicatie. Deze codes worden (ter ondersteuning van medicatiebewaking) toegestaan zolang ze voorkomen in subtabel 40. Het maakt wel duidelijk dat een conditie soms het karakter van een ‘vlag’ heeft.

Bijlage D Overzicht gebruikte OID's

Tabel 4 Overzicht OID'S

OID	Beheerder	Nederlandse omschrijving
2.16.840.1.113883.2.4.6.3	Ministerie VWS	Burgerservicenummer
2.16.840.1.113883.2.4.15.111	CIBG	UZI-register rolcode
2.16.840.1.113883.2.4.15.4	Nictiz	Act registrycodes in de AORTA Verwijsindex
2.16.840.1.113883.5.1	HL7 Internationaal	Geslacht code
2.16.840.1.113883.5.2	HL7 Internationaal	Burgerlijke staat
2.16.840.1.113883.5.4	HL7 Internationaal	ActCode
2.16.840.1.113883.5.14	HL7 Internationaal	ActStatus OID wordt niet zelf gebruikt, omdat attribuut statusCode altijd datatype CS heeft
2.16.840.1.113883.5.1053	HL7 Internationaal	ActUncertainty
2.16.840.1.113883.5.25	HL7 Internationaal	Vertrouwelijkheidcodes
2.16.840.1.113883.2.4.4.1.902.40	Z-Index	G-standaard thesaurus 040, TH040
2.16.840.1.113883.2.4.4.1.750	Z-Index	G-Standaard tabel: Individuele bestanddelen, oftewel stoffen op basis van stofnaamcode (SNK).
2.16.840.1.113883.2.4.4.1.725	Z-Index	G-Standaard tabel: Individuele bestanddelen in combinatie met een toedieningsweg (SSK)
2.16.840.1.113883.2.4.4.1.902.122	Z-Index	G-Standaard tabel: Ongewenste groepen, oftewel groepen medicijnen met een ongewenste stof.
2.16.840.1.113883.2.4.4.7	Z-Index	G-Standaard tabel: Ongewenst handelsprodukt (bestand 030(handelsprodukten))

Bijlage F implementatierichtlijnen:"Allergieën en ongewenste middelen