HL7v3-domeinspecificatie conditie

Uit informatiestandaarden
Ga naar: navigatie, zoeken

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

Em.png

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

Issue icon.png

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

Question icon.png

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.png
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.png
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.png
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).


Issue icon.png

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.


Em.png

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

Issue icon.png

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)

Issue icon.png

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).


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.

Issue icon.png

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.

Issue icon.png

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.


author

Em.png

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>


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:

Benadering van het Generieke niveau (GPK) vanuit de stofnaam (SNK)

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:

Voorbeelden vanuit de G-Standaard

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


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.


EPDallergie.png

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.


Voorschrift.png

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.


Issue icon.png

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.0.0


Bijlage B Overzicht domeinberichten

Tabel 3 Overzicht domeinberichten
# Logische bericht naam Toepassing HL6v3 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


Issue icon.png

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)’.


Issue icon.png

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

Bijlagef1.png

Bijlagef2.png

Bijlagef3.png

Bijlagef4.png

Bijlagef5.png

Bijlagef6.png

Bijlagef7.png

Bijlagef8.png