7phcy:V6.12.3 HL7v3-domeinspecificatie Pharmacy

Inleiding

Doel en scope

Het doel van dit document is het bieden van een praktische implementatiehandleiding voor de HL7 versie 3 specificaties t.b.v. het uitwisselen van medicatiegegevens.

In de HL7v3 specificaties voor de toepassing Medicatieproces is de nadruk gelegd op de procesmatige aspecten van gegevensuitwisseling rond het elektronisch medicatiedossier. Het gaat daarbij om het WAAROM, het WANNEER en het TUSSEN WIE van de interacties tussen systemen. Deze kennis wordt weergegeven in de vorm van storyboards, trigger events, applicatierollen en uiteindelijk een verzameling HL7 versie 3 interacties.

Het belangrijkste kenmerk van een HL7v3 interactie is het zogenaamde Message Type, waarmee de payload (de relevante medisch-inhoudelijke gegevens) uitgewisseld wordt. Dit document geeft een beschrijving van de verschillende vormen van deze payloads, voor zover afkomstig uit het domein Medicatiegegevens, inclusief de onderdelen (Common Message Element Type oftewel CMET) waaruit deze weer zijn opgebouwd.

Het gaat daarbij dus om het WAT van de uitgewisselde gegevens, oftewel de structuur, de inhoud en de implementatierichtlijnen voor de interacties die ze ondersteunen.

De volgende message types (payloads en CMET´s) worden uitgewerkt:

• Medicatievoorschrift (Medication Combined Order)

Deze wordt gebruikt bij het uitschrijven van een nieuw medicatievoorschrift door een voorschrijvend arts. Dit kan een ambulant recept (of vooraankondiging) of een klinische medicatieopdracht betreffen. Deze CMET wordt ook gebruikt binnen de zorgtoepassing huisartswaarneming (als dossieronderdeel) en als het resultaat bij het opvragen van een lijst met voorschriften uit bronsystemen (via het LSP).

• Medicatieverstrekking (Medication Dispense Event)

Deze wordt gebruikt bij het verstrekken van medicatie (al dan niet o.b.v. een voorschrift) door een verstrekker (meestal een apotheek). In het geval van een klinisch voorschrift wordt niet het leveren van de medicatie, maar het bevestigen van de medicatieopdracht door de ziekenhuisapotheek als uitgangspunt genomen. Deze CMET vormt ook het resultaat bij opvragen van een lijst met verstrekkingen.

• Toedieningsverzoek (Medication Administration Request)

Deze CMET wordt gebruikt als onderdeel van het Medicatievoorschrift en de Medicatieverstrekking, en wel om uit te drukken welke instructies er zijn voor de toediening van de medicatie (doseerschema, doseerhoeveelheid en andere gebruiksinstructies). Het enige verschil tussen het gebruik bij een voorschrift en een verstrekking, is dat bij de verstrekking de apotheker de instructies ook geaccordeerd heeft (dit geldt zowel bij ambulante als bij klinische medicatie).

• Medicatiesoort (Medication Kind)

Deze CMET wordt gebruikt als onderdeel van het Medicatievoorschrift en de Medicatieverstrekking, en wel om uit te drukken op welke soort medicatie deze betrekking hebben. Het enige verschil tussen het gebruik bij een voorschrift en een verstrekking, is dat bij verstrekking meestal een specifiekere medicatiesoort (artikel) benoemd kan worden, terwijl voorschrijven meestal generiek gebeurt.

• Voorschriftquery (Medication Combined Order Query)

Dit is de query waarbij aan een Zorg Informatie Makelaar of een voorschrijvend bronsysteem wordt gevraagd om een selectie van alle bij het systeem bekende voorschriften (voor een bepaalde patiënt) op te zoeken en terug te sturen.

• Verstrekkingsquery (Medication Dispense Event Query)

Dit is de query waarbij aan een Zorg Informatie Makelaar of een verstrekkend bronsysteem wordt gevraagd om een selectie van alle bij het systeem bekende verstrekkingen (voor een bepaalde patiënt) op te zoeken en terug te sturen.

• Medicatievoorschriftenlijst (Medication Combined Order List)

Dit is een lijst met alle gevonden resultaten bij het opvragen van voorschriften. Elk van de voorschriften heeft dezelfde structuur als een Medicatievoorschrift, alleen wordt de betreffende patiënt voor de hele lijst maar één keer doorgegeven.

• Medicatieverstrekkingenlijst (Medication Dispense Event List)

Dit is een lijst met alle gevonden resultaten bij het opvragen van verstrekkingen. Elk van de verstrekkingen heeft dezelfde structuur als een Medicatieverstrekking, alleen wordt de betreffende patiënt voor de hele lijst maar één keer doorgegeven.

Doelgroep voor dit document

De doelgroep bestaat primair uit de systeemontwerpers en software-ontwikkelaars bij de leveranciers van zorg informatie systemen (ook wel bekend als de ‘XIS leveranciers’) die medicatiegegevens 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 is bewust zoveel mogelijk opgezet als een zelfstandige bron van informatie. De HL7 versie 3 standaard is nuttig als achtergrondinformatie, maar niet per se noodzakelijk om de voor medicatiegegevens beschreven gegevensstructuren te implementeren. Deze implementatiehandleiding is een praktische invulling van de domeindefinitie Medicatiegegevens, maar kan ook los daarvan gelezen worden.

De details van het implementeren van de data types (elementaire bouwstenen) en de meest basale CMET’s (herbruikbare berichtelementen) zijn uitgewerkt in de implementatiehandleiding HL7v3 Basiscomponenten ([HL7v3 IH Basis]), waarin ook meer algemene achtergrondinformatie over de implementatie van HL7 versie 3 te vinden is.

Er wordt in dit document nadrukkelijk niets vermeld over de samenhang met de wrappers van de berichten. Deze implementatiehandleiding beschrijft hoe de zogenaamde payload van de specifieke interacties voor medicatiegegevens gebruikt dienen te worden, maar verwijst verder naar de implementatiehandleiding HL7v3 Wrappers.

Documenthistorie

Versie	Datum	Omschrijving
6.10.0.0	12-10-2011	Basisversie t.b.v. AORTA 2011
6.12.0.0	04-06-2013	Publicatie losse zorgtoepassing en als onderdeel van AORTA 2012
6.12.1.0	09-10-2013	Herintroductie logistieke verbruiksperiode in expectedUseTime. Verbetering van een aantal foutjes in de specificatie.

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.

HL7 bespreekpunt. Een aspect dat nog besproken moet worden binnen de (inter)nationale HL7 versie 3 werkgroepen.

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

Domain Message Information Model - Pharmacy

Het Domain Message Information Model (D-MIM) voor het medicatiedossier is de basis voor de specificatie van alle HL7 versie 3 interacties binnen dit domein. Elk berichttype (Message Type) wordt in een apart Refined Message Information Model (R-MIM) uitgewerkt (met een grafische weergave). Het D-MIM is niet meer of minder dan het overkoepelende informatiemodel waaruit alle R-MIM’s worden afgeleid door middel van verfijning en restrictie, waarbij alleen de onderdelen worden overgelaten die relevant zijn voor dat R-MIM, en waarbij cardinaliteit en conformance zo strak mogelijk worden gezet.

Hieronder treft u een globale schets van de meest essentiële gegevensklassen binnen het D-MIM. Deze zullen terugkomen in de eruit afgeleide message types. De essentie is dat alle specificaties met betrekking tot medicatiegegevens met elkaar in overeenstemming blijven door te garanderen dat ze allen worden afgeleid uit het overkoepelende Pharmacy D-MIM. Daarnaast biedt het Nederlandse Pharmacy D-MIM een goed uitgangspunt voor de harmonisatie met het internationale domeinmodel, nu en in de toekomst. Het D-MIM is niet normatief en beschrijft geen feitelijke interacties, maar is wel het fundament.

Figuur 1 D-MIM Pharmacy – Statisch Model

De essentie van het D-MIM is dat het bestaat uit vier hoofdklassen:

• De Prescription, oftewel het medicatievoorschrift als geheel. Belangrijk is dat de klasse Prescription fungeert als aanknopingspunt voor de patiënt en de voorschrijvende arts, die als zogenaamde CMET’s (Common Message Element Types) zijn opgenomen in het model. Voor Nederland is besloten dat elk medicatievoorschrift slechts betrekking heeft op één enkele medicatiesoort (anders gezegd: er is precies één ‘receptregel’ per medicatievoorschrift).

• De CMET E_MedicationKindNL, die alle gegevens over de voorgeschreven of verstrekte medicatiesoort bevat, incl. eventuele specificatie van ingrediënten en/of magistrale receptuur. Of het gaat om voorgeschreven of verstrekte medicatie hangt af van het message type waarin de CMET gebruikt wordt.

• Deze contactafhankelijkheid is er ook bij de klasse MedicationDispenseProcess. In een medicatievoorschrift is sprake van een optioneel MedicationDispenseRequest per voorgeschreven medicatie, terwijl in een medicatieverstrekking de MedicationDispenseEvent (dezelfde klasse in een andere fase van z’n ‘business cycle’) juist het centrale gegeven is. Het gaat daarbij dus om het verzoek tot verstrekking respectievelijk de feitelijk uitgevoerde verstrekking. In beide gevallen is er een associatie met de verstrekkende apotheker (beoogd dan wel feitelijk).

• Tenslotte is er per voorgeschreven of verstrekte medicatie sprake van één of meer zogenaamde toedieningsverzoeken (MedicationAdministrationRequest), die de medicatieafspraak tussen de patiënt en de arts en/of apotheker weergeven. In medische zin is hier de meest essentiële informatie te vinden (in samenhang met de betreffende medicatie), zoals het doseerschema (<effectiveTime>) en de doseerhoeveelheid (<doseQuantity>). De reden dat er meerdere toedieningsverzoeken per medicatie kunnen zijn, ligt in het feit dat per herhaling maar één doseerschema en doseerhoeveelheid kunnen worden opgenomen.

Er wordt geen algemene ‘walkthrough’ van het D-MIM gegeven, maar er worden specifieke implementatierichtlijnen beschreven bij de verschillende message types.

De R-MIM’s voor de queries worden niet afgeleid uit het algemene Pharmacy D-MIM. De reden hiervoor is dat de vraagstelling in de query een algemene structuur met een lijstje parameters is, dus zonder samenhang met de rest van de gegevens in het D-MIM. Anders ligt het met het antwoord op de query, dat wel volledig gebaseerd is op het informatiemodel uit het D-MIM. Sterker nog, het antwoord op bijv. de Voorschriftlijstquery bevat informatie die grotendeels gelijkvormig is aan aan het reguliere Medicatievoorschrift.

Message Types (payloads en CMET's)

Medicatievoorschrift (PORX/COCT_MT932000NL02)

D-MIM:	Pharmacy
HL7v3 gestructureerde naam:	Medication Combined Order

Diagram

Figuur 2 PORX_RM932000NL02 - R-MIM diagram

Figuur 3 COCT_RM932000NL02 - R-MIM diagram

Beschrijving

De bovenstaande R-MIM´s zijn bedoeld om alle relevante gegevens rond een medicatievoorschrift weer te geven. Het payload model PORX_MT932000NL02 wordt gebruikt bij het versturen van een nieuw voorschrift, maar bestaat op zichzelf uit niets anders dan de CMET COCT_MT932000NL02. Een CMET mag echter niet direct als payload fungeren, dus vandaar dat een dummymodel nodig is. De CMET fungeert daarnaast als onderdeel van:

• De Medicatievoorschriftenlijst, als component van een opgeleverde lijst.
• De Professionele Samenvatting en het Waarneembericht voor huisartsen.

De laatstgenoemde message types worden binnen HL7-domein Primary Care uitgewerkt.

De belangrijkste kenmerken van het model zijn:

• Elk voorschrift heeft betrekking op één enkele patiënt.
• Elk voorschrift kent één enkele voorschrijver als auteur.
• Elk voorschrift omvat één of meer toedieningsverzoeken.
• Een voorschrift omvat optioneel een verstrekkingsverzoek.
• Elk voorschrift heeft betrekking op één enkel soort medicatie.

De zogenaamde focal class van het R-MIM is dus de klasse Prescription, die betrekking heeft op één enkel medicatievoorschrift. Deze klasse fungeert als entry point (startpunt) voor de payload van interacties op basis van het message type PORX_MT932000NL02) en als onderdeel van andere message types die CMET COCT_MT932000NL02 gebruiken.

Bij elk medicatievoorschrift hoort logisch gezien één patiënt, maar die wordt niet altijd expliciet doorgegeven, omdat deze in veel gevallen wordt bepaald door de context.

Binnen het R-MIM wordt gebruik gemaakt van een aantal domeinspecifieke CMET’s (Common Message Element Types) die hergebruikt worden in verschillende R-MIM’s:

• E_MedicationKindNL voor de voorgeschreven medicatiesoort;
• A_MedicationAdministrationRequestNL voor de ‘toedieningsverzoeken’.

De implementatierichtlijnen voor deze CMET’s worden elders in dit document uitgewerkt.

Hierarchical Message Description

<Prescription>	Medicatievoorschrift
<subject><Patient>	Patiënt
<author><AssignedPerson>	Voorschrijvende arts
<directTarget><prescribedMedication> <MedicationKind>	Voorgeschr. medicatie
[{ <activeIngredient> [ <activeIngredientMaterialKind> ] }]	Werkzame stof
[{ <otherIngredient><ingredientMaterialKind> }]	Andere ingrediënt
[ <productOf><medicationDispenseRequest>	Verstrekkingsverzoek
[ <performer><assignedPerson> <representedOrganization> ]	Beoogde verstrekker
]
{ <therapeuticAgentOf><medicationAdministrationRequest>	Toedieningsverzoek
[{ <support2><medicationAdministrationInstruction> }]	Gebruiksinstructie
}]
[{ <precondition><observationEventCriterion> }]	Randvoorwaarde
}
[ <reason><diagnosisEvent> ]	Voorschrijfreden

prescription

Formaat:

<Prescription>
  <id …/>
  <statusCode …/>
  [  <subject …/> ]
     <author …/>
     <directTarget …/>
  [   <reason …/> ]
</Prescription>

Definitie: afhankelijk van toepassing in ambulante respectievelijk klinische situatie:

• Ambulant recept, uitgeschreven door een huisarts of specialist tijdens diens spreekuur of op de spoedeisende hulp, waarvoor de medicatie door de patiënt zelf (of door een vertegenwoordiger) wordt opgehaald bij een openbare apotheek.
• Klinische medicatieopdracht, uitgeschreven door een specialist ten behoeve van een opgenomen patiënt, en doorgegeven aan de ziekenhuisapotheek, die de medicatieopdracht bevestigt en garandeert dat de medicatie beschikbaar is.

Een medicatievoorschrift is een groeperingsmechanisme voor twee soorten verzoeken:

• Toedieningsverzoeken van de voorschrijver aan de toediener (de patiënt zelf of het verplegend personeel). Alle toedieningsverzoeken bij één medicatie samen heten de medicatieafspraak, die met of ten behoeve van de patiënt is gemaakt.
• Verstrekkingsverzoek van de voorschrijver aan de verstrekker (apotheek of apotheekhoudende huisarts). Dit is het (al dan niet expliciete) logistieke verzoek voor het leveren van medicatie om de toedieningsverzoeken te kunnen uitvoeren.

De toedieningsverzoeken zijn meestal primair, in de zin dat de benodigde verstrekking wel impliciet kan worden afgeleid uit de gewenste toediening, maar niet andersom.

Door de manier waarop het Medicatievoorschrift (Medication Combined Order) is opgezet, zal elk voorschrift betrekking hebben op één enkel soort medicatie. Een andere manier om dit te zeggen is dat er precies één ‘receptregel’ per voorschrift is. Daarbinnen kunnen op basis van voorgeschreven medicatie één of meer toedieningsverzoeken en optioneel een verstrekkingsverzoek zijn aangeduid.

Voor extra en achtergrondinformatie zie ook Medicatievoorschrift

prescription.id

Formaat:

 <id root="…" extension="…"/>

Definitie: De identificatie van het medicatievoorschrift. Deze wordt gegenereerd door het voorschrijvende systeem (bijvoorbeeld van de huisarts of medisch specialist) en moet wereldwijd en eeuwig uniek zijn. Zie de [HL7v3 IH Basis] voor een toelichting op het gebruik van datatype II om een dergelijke identifier aan te duiden.

Het voorschrijvend systeem moet er voor zorgen dat elk medicatievoorschrift een eigen <id> krijgt. Een ontvangend systeem (bijvoorbeeld van de apotheek) dat medicatie verstrekt op basis van binnenkomende voorschriften, moet door vergelijking met reeds verwerkte identifiers zorgen dat nooit een voorschrift dubbel wordt verwerkt.

XML voorbeeld:

Een huisarts informatiesysteem (HIS) registreert medicatievoorschriften en verzendt deze naar een openbaar apotheeksysteem (via een Zorg Informatie Makelaar). Het HIS genereert daarbij een uniek referentienummer voor het voorschrift (hier van 10 cijfers).

<id  extension="0008112345"
     root="2.16.528.1.1007.3.3.1025463.1.9"
     assigningAuthorityName="HIS Dr. Jansen" />

In bovenstaand voorbeeld heeft de huisarts blijkbaar URA-nummer ‘01025463’ (er mogen geen voorloopnullen in een OID-node voorkomen), is ‘1’ de aanduiding voor het HIS dat hij gebruikt en is ‘9’ de aanduiding voor de voorschriftnummers binnen dat HIS. Deze opbouw is géén eis (zolang de OID maar uniek is), maar slechts een suggestie.

prescription.statusCode

Formaat:

<statusCode code=”active|completed”/>

of

<statusCode nullFlavor=”UNK”/>

Definitie: De actuele status van het medicatievoorschrift. Bij het verzenden van een nieuw voorschrift is de status per definitie “active”, maar bij het rapporteren van historische voorschriften hangt het er vanaf of de patiënt nog medicatie gebruikt op basis van dit voorschrift. Indien dit niet het geval is dient “completed” te worden gebruikt.

In de meeste gevallen zal het voorschrijvend systeem echter niet over deze informatie beschikken en daarom de nullFlavor ”UNK” opleveren (status voorschrift is onbekend).

XML voorbeeld:

Een huisarts heeft een nieuw recept uitgeschreven, dat dus per definitie ´actief´ is.

<statusCode code="active"/>

Het EVS van een specialist levert historische voorschriften op. Binnen het EVS wordt niet bijgehouden of op basis van een voorschrift nog medicatie wordt gebruikt door de patiënt.

<statusCode nullFlavor="UNK"/>

prescription.subject

Elk medicatievoorschrift hoort bij een specifieke patiënt. Het is echter niet altijd nodig om deze expliciet door te geven binnen het Medicatievoorschrift, omdat de patiënt soms al bekend is door de context. De associatie <subject> is daarom conditioneel verplicht, afhankelijk van de HL7v3 interactie waarbinnen het Medicatievoorschrift wordt gebruikt.

Concreet betekent dit:

• <subject> niet opnemen als het Medicatievoorschrift onderdeel is van een Medicatievoorschriftenlijst (antwoord op interactie OpvragenVoorschriftenlijst).
• <subject> verplicht opnemen als het Medicatievoorschrift wordt gebruikt als op zichzelf staande payload van een notificatie (interactie VerstuurVoorschrift).

Zie voor de CMET R_PatientNL [universal] de [HL7v3 IH Basis].

In de CMET R_PatientNL [universal] zijn geen verplichte elementen behalve het patiëntnummer. In deze context zijn er echter enkele specifieke kenmerken: Het patiëntnummer (<Patient><id>) is altijd een BSN. Er moet een (familie)naam van de patiënt gevuld zijn. De geboortedatum van de patiënt moet gevuld zijn. Het geslacht van de patiënt moet aangeduid zijn. De reden om de aanvullende patiëntgegevens naast het BSN door te geven, ligt in de mogelijkheid om daarmee de identiteit extra te kunnen controleren.

XML voorbeeld:

Er wordt een nieuw medicatievoorschrift verstuurd voor patiënt mevrouw Bette Freriks-van Weezel, geboren op 10 december 1973, die als BSN-nummer 042715231 heeft.

<subject>
   <Patient>
     <id root="2.16.840.1.113883.2.4.6.3" extension="042715231"/>
     <statusCode code="active"/>
     <Person>
       <name>
         <given qualifier="BR">Bette</given>
         <family qualifier="SP">Freriks</family>
         <prefix qualifier="VV">van </prefix>
         <family qualifier="BR">Weezel</family>
       </name>
       <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>
       <birthTime value="19731210"/>
     </Person>	
  </Patient>
</subject>

prescription.author

Formaat

<author>
  
  <AssignedPerson … />
</author>

Elk medicatievoorschrift is op een bepaald moment (voorschrijfmoment) door een voorschrijvend arts opgesteld (en ondertekend). Het voorschrijfmoment moet bij elk voorschrift verplicht worden meegegeven. De voorschrijvende arts is eveneens verplicht, behalve als uit de context waarin het voorschrift wordt doorgegeven duidelijk wordt om welke voorschrijver gaat. Dit is met name het geval als het voorschrift onderdeel is van een overkoepelend (huisarts)dossier. Het <author> element is dus altijd gevuld, maar <author><AssignedPerson> kan ook leeg worden doorgegeven (zie in AssignedPerson).

prescription.author.time

Formaat

<time value="YYYYMMDD[HHMM]"/>

Definitie: De datum en eventueel tijd waarop het bijbehorende voorschrift werd geschreven. In het geval van een voorschrift dat direct elektronisch werd vastgelegd is de voorschrijftijd meestal gelijk aan de systeemtijd op het moment van invoer. In het geval van een handmatig voorschrift dat later elektronisch wordt vastgelegd, kan de voorschrijfdatum met terugwerkende kracht worden ingevoerd (datum papieren recept).

Regel: de voorschrijfdatum mag niet in de toekomst liggen.

XML voorbeeld:

Een nieuw medicatievoorschrift wordt ingevoerd om 14:24 op 10 december 2010.

<time value="201012101424"/>

Het voorschrijvende systeem registreert alleen de voorschrijfdatum (en geen tijd).

<time value="20101210"/>

prescription.author.AssignedPerson

Bij het doorgeven van de voorschrijvende arts wordt gebruik gemaakt van de CMET R_AssignedPerson [identified-confirmable], waarin naast een verplichte identificatie, ook enige aanvullende persoonsgegevens kunnen worden aangeduid. De naam is een verplicht onderdeel, maar ook zorgverlenerrol (bijvoorbeeld huisarts) en adres kunnen worden opgenomen. De CMET staat helaas niet toe om telecominformatie door te geven.

Zie voor R_AssignedPerson [identified-confirmable] de [HL7v3 IH Basis].

De toegestane identificatiemethoden zijn: UZI-nummer (OID 2.16.528.1.1007.3.1) AGB-Z nummer (OID 2.16.840.1.113883.2.4.6.1) Er moet minimaal één van de bovenstaande identificaties aanwezig zijn.

XML voorbeeld:

Er wordt een nieuw medicatievoorschrift verstuurd door huisarts mevrouw B. van Hamelen, die als UZI-nummer 008426371 en AGB-Z nummer 01042119 heeft.

<AssignedPerson>
     <id root="2.16.528.1.1007.3.1" extension="008426371"/>
     <id root="2.16.840.1.113883.2.4.6.1" extension="01042119"/>
     <code code="01.000" codeSystem="2.16.840.1.113883.2.4.15.111"
           displayName="huisarts"/>	
     <assignee>
          <assigneePerson>
               <name>
                 <given qualifier="IN">B.</given>
                 <prefix qualifier="VV">van </prefix>
                 <family>Hamelen</family>
               </name>
          </assigneePerson>
     </assignee>
</AssignedPerson>

Er wordt een medicatievoorschrift verstuurd als onderdeel van een huisartsdossier, waarbij de voorschrijvend arts impliciet duidelijk is (namelijk dossierhoudend huisarts).

<AssignedPerson xsi:nil="true"/>

prescription.directTarget.prescribedMedication

Formaat:

 <directTarget>
  <prescribedMedication>
     <MedicationKind … />
     [	 <productOf … /> ]
     { 	 <therapeuticAgentOf … /> }
  </prescribedMedication>
 </directTarget>

Bij elk medicatievoorschrift moet exact één voorgeschreven medicatie worden aangeduid. Uit bovenstaande sectie van het informatiemodel vallen de volgende zaken af te lezen:

• Bij elk medicatievoorschrift hoort één enkele voorgeschreven medicatie(soort).
• Bij elke voorgeschreven medicatie horen één of meer toedieningsverzoeken.
• Bij elke voorgeschreven medicatie hoort optioneel één verstrekkingsverzoek.

De medicatiesoort wordt weergegeven door middel van CMET E_MedicationKindNL, die elders in dit document wordt beschreven. In een medicatievoorschrift mag het type medicatie worden aangeduid met elk van de beschikbare coderingssystemen, hoewel de richtlijn is om zoveel mogelijk op PRK-niveau voor te schrijven. Soms kan het echter wenselijk zijn om een specifieker niveau (HPK, artikelnummer) te hanteren.

prescription.directTarget.prescribedMedication.medicationKind

Ga naar medicationKind

prescription.directTarget.prescribedMedication.productOf

Bevat een expliciet verzoek (bij een ambulant voorschrift) van de voorschrijver aan een verstrekker (die al dan niet benoemd wordt) om een bepaalde hoeveelheid van de voorgeschreven medicatie te verstrekken aan de patiënt of diens vertegenwoordiger.

Ga naar medicationDispenseRequest

prescription.directTarget.prescribedMedication.therapeuticAgentOf

Het element <therapeuticAgentOf> en diens subelementen bevatten instructies voor toediening van de medicatie aan de patiënt (al dan niet door de patiënt zelf). Dit vormt, samen met de aanduiding van de medicatiesoort, de essentie van de afspraak die de voorschrijver met of ten behoeve van de patiënt heeft gemaakt. Elk subelement onder <therapeuticAgentOf> wordt aangeduid met de term toedieningsverzoek, waarbij de feitelijke instructies worden aangeduid met de CMET A_MedicationAdministrationRequest.

Het element <therapeuticAgentOf> is verplicht en kan herhaald voorkomen. Deze herhaling duidt specifieke toedieningsinstructies binnen de totale gebruiksperiode aan. Elk voorkomen van het element heeft betrekking op één set toedieningskenmerken, waardoor er dus meerdere toedieningsverzoeken aansluitend of parallel ontstaan. Deze ontstaan door variaties in doseerschema, doseerhoeveelheid en/of toedieningsweg, en door de manier waarop in HL7v3 een variabele gebruiksfrequentie wordt aangeduid.

In de volgende situaties ontstaan meerdere parallelle toedieningsverzoeken: A) Vast doseerschema, maar wisselende doseerhoeveelheid binnen de dag ⇒ meerdere parallelle toedieningsverzoeken, één per doseerhoeveelheid. B) Variabele gebruiksfrequentie ⇒ twee parallelle toedieningsverzoeken, één voor het vaste en één voor het variabele deel van de gebruiksfrequentie. In de volgende situaties ontstaan meerdere sequentiële toedieningsverzoeken: C) Vast doseerschema, wisselende doseerhoeveelheid binnen de periode ⇒ meerdere toedieningsverzoeken, één per doseerhoeveelheid. D) Wisselend doseerschema ⇒ meerdere sequentiële toedieningsverzoeken. Binnen elk sequentieel toedieningsverzoek kunnen door wissselende doseerhoeveelheden binnen de dag of door een variabele gebruiksfrequentie parallelle splitsingen ontstaan.

Het feit dat elke wisseling van doseerschema (een periode met een vaste spreiding van toedieningen) leidt tot een apart toedieningsverzoek is niet vanzelfsprekend. In principe zou, zolang de doseerhoeveelheid gelijk is bij elke toediening, een willekeurige serie doseerschema’s kunnen worden gecombineerd in het element <medicationAdministrationRequest> <effectiveTime> van de CMET A_MedicationAdministrationRequest (zie medicationAdministrationRequest.effectivetime). Dit zou echter constructies opleveren die door ontvangers toch opgesplitst moeten worden, zodat is besloten elk toedieningsverzoek te beperken tot één doseerschema.

Voorbeelden van gebruiksinstructies met één toedieningsverzoek:

• gebruik bekend
• 3x daags 2 tabletten
• 3x daags 2 tabletten zo nodig
• 3x daags 2 tabletten, om 08:00, 13:00 en 18:00
• 1x daags 1 tablet gedurende 21 dagen, dan 7 dagen niet

Voorbeelden van gebruiksinstructies met parallelle toedieningsverzoeken:

• per dag 4 tabletten; ’s-ochtends 1, ’s middags 2, ’s avonds 1 tablet
• 2x daags 1 tablet, om 08:00 en 18:00, en 1x daags 2 tabletten, om 13:00
• 1 tot 3x daags 2 tabletten (variabele gebruiksfrequentie = 1x vast, 2x zo nodig)

Voorbeelden van gebruiksinstructies met sequentiële toedieningsverzoeken:

• Eerste dag 4 tabletten, tweede dag 3, derde dag 2, vierde dag 1 tablet
• Eerste week 2x daags 2 tabletten, tweede week 1x daags 2 tabletten
• Eerste week 2x daags 2 tabletten, tweede week 1x daags 1 tablet

Voorbeelden met zowel parallelle als sequentiële toedieningsverzoeken:

• Eerste week 1-2x daags 1 tablet, tweede week 1x daags 2 tabletten
• Eerste week ’s ochtends 1, ’s middags 2, ’s avonds 3 tabletten, tweede week ‘s ochtends 1, ’s middags 1, ’s avonds 1 tablet

Toedieningsverzoeken worden standaard beschouwd als parallel. Dat wil zeggen dat als er een volgorde in de tijd moet worden aangeduid (zoals bij alle sequentiële toedieningsverzoeken), er bij het doseerschema een gebruiksinterval moet staan dat aangeeft hoe het toedieningsverzoek zich verhoudt tot de rest. Dat moet een interval met minimaal een begindatum zijn (geankerd interval), zodat de volgorde direct duidelijk is. Als sprake is van een interval met alleen een duur (zwevend interval), dan is de aanname dat dit toedieningsverzoek parallel loopt met andere ‘zwevende’ toedieningsverzoeken. Zie verder bij het element <medicationAdministrationRequest><effectiveTime> bij de beschrijving van de CMET A_MedicationAdministrationRequest in medicationAdministrationRequest.effectivetime. De volgorde van herhalingen is niet relevant binnen XML. Er mag dus geen enkele aanname worden gedaan over tijdsvolgorde op basis van XML volgorde.

Gelijkblijvende gegevens worden herhaald bij ieder toedieningsverzoek Het bestaan van herhalende <therapeuticAgentOf> elementen betekent ook dat gegevens die voor alle herhalingen gelden, elke keer herhaald moeten worden. Concreet betekent dit dat de volgende elementen herhaald voor kunnen komen: <text>, indien deze de set toedieningsverzoeken als geheel beschrijft; gebruiksduur (IVL_TS binnen <effectiveTime>) bij parallelle verzoeken; <routeCode>, indien een expliciete toedieningsweg is aangegeven; <maxDoseQuantity>, indien een maximale dosering is aangegeven; <support2>, indien er aanvullende instructies bij de toediening zijn; <precondition>, indien er sprake is van ‘zo nodig’ voor de gehele set.

XML voorbeeld:

<prescribedMedication>
 <therapeuticAgentOf>
  <medicationAdministrationRequest>
    …
  </medicationAdministrationRequest>
 </therapeuticAgentOf>
 <therapeuticAgentOf>
  <medicationAdministrationRequest>
   …
  </medicationAdministrationRequest>
 </therapeuticAgentOf>
</prescribedMedication>

prescription.reason

Formaat:

<reason>
     <diagnosisEvent>
       
       <value …/>
     </diagnosisEvent>
</reason>

Definitie: De ‘reden van voorschrijven’ voor het medicatievoorschrift. Hiermee kan een medische indicatie (in de vorm van een diagnose-aanduiding) worden doorgegeven die de directe aanleiding vormde voor het voorschrijven van de betreffende medicatie.

De reden van voorschrijven is conditioneel verplicht, afhankelijk van de medicatiesoort die is voorgeschreven. Dit is een compromis dat voortkomt uit het feit dat verstrekkers geïnteresseerd zijn in dit gegeven (in het kader van hun rol als ‘medicatiebegeleider’, terwijl voorschrijvers meestal niet genegen zijn om het mee te sturen. De lijst met medicatiesoorten die nu is opgesteld, bevat de medicatie waarvoor de medische indicatie relevant is bij het uitvoeren van medicatiebewaking (omdat afhankelijk van de indicatie sprake is van een andere dosering of anders bewaakte interacties).

De aanduiding voor welke medicatiesoorten een reden van voorschrijven relevant is voor de medicatiebewaking (en dus verplicht in het Medicatievoorschrift), wordt beheerd door het WinAp, en is te vinden in het bestand BST401T in de G-Standaard. Dit heeft de vorm van een ‘bijzonder kenmerk’ “uitwisselen reden van voorschrijven noodzakelijk”. Dit kenmerk wordt aan medicatie gekoppeld op het HPK en waar mogelijk PRK niveau.

Zie ook het document bij Z-Index hier.

Consequentie van de conditionele verplichting is dat er sowieso een verplichting ontstaat om (in ieder geval bij de betreffende medicatiecategorieën) de reden van voorschrijven expliciet te registreren. Vooral in de EVS-en die gebruikt worden in de 2e lijn, was dat zeker nog niet de norm. Deze aanpassing past wel in de trend om het EVS verder te ingrereren in de gehele dossiervoering (zodat de reden van voorschrijven automatisch volgt uit het bijbehorende ‘zorgtraject’).

prescription.reason.diagnosisEvent.code

Formaat:

<code code="DX" codeSystem="2.16.840.1.113883.5.4"/ >

Definitie: Code die aangeeft dat de betreffende observatie een ‘diagnosestelling’ is. De code “DX” komt uit het HL7 codesysteem ActCode, met als OID 2.16.840.1.113883.5.4.

prescription.reason.diagnosisEvent.value

Formaat:

<value code="…" codeSystem="…" displayName="…" codeSystemName="…">
  [ {   <translation code="…" codeSystem="..." } ]
</value>

of

<value nullFlavor="OTH">
  <originalText>…</originalText>
</value>

Definitie: Code (of niet-gecodeerde omschrijving) die de aard van de gestelde diagnose aangeeft. De code kan afkomstig zijn uit verschillende diagnosecodesystemen, op basis van nader te maken afspraken. Voorbeelden van dergelijke codesystemen zijn ICD-9CM, ICD-10 en ICPC-1, maar er zijn ook gespecialiseerde codesystemen voor bijvoorbeeld de spoedeisende hulp. Bij de primaire code moet ook de displayName gevuld zijn, zodat de ontvanger zelfs als het gebruikte codesysteem niet bekend is, toch een tekstuele omschrijving aan de gebruiker kan tonen. Naast een primaire code kunnen ook één of meer vertalingen naar secundaire codes worden meegegeven (met <translation>).

Als er in plaats van een gecodeerde diagnosetypering sprake is van een omschrijving, dan kan deze worden doorgegeven door middel van nullFlavor "OTH", in combinatie met het element <originalText> . Aangezien coderen niet verplicht is, moet een ontvangend systeem dus zowel zijn voorbereid op een gecodeerde diagnose als op een vrije tekst.

XML voorbeeld:

Huisarts Jan Jansen heeft de diagnose ‘Astma’ gesteld bij zijn patiënt en stelt een recept op voor het middel Ventolin©, waarvoor deze diagnose als ‘reden van voorschrijven’ fungeert. Vanuit zijn Huisarts Informatie Systeem wordt de juiste ICPC-1 diagnosecode geselecteerd, waarbij het HIS automatisch een diagnosenummer toekent aan deze specifieke diagnosestelling. Het HIS ondersteunt ook de mapping naar ICD-9CM diagnosecodes en de bijbehorende vertaling wordt meegegeven als <translation>.

<value code="R96" codeSystem="2.16.840.1.113883.2.4.4.31.1"
       displayName="Astma" codeSystemName="ICPC-1">
       <translation code="493" codeSystem="2.16.840.1.113883.6.2"/>
</value>

Het Elektronisch Voorschrijf Systeem (EVS) van het Medisch Centrum West bevat de mogelijkheid om op basis van vrije tekst een ‘reden van voorschrijven’ in te geven voor klinische medicatieopdrachten. Deze vrije tekst wordt doorgegeven als <originalText>.

<value nullFlavor="OTH">
       <originalText>Hoge bloeddruk</originalText>
</value>

medicationDispenseRequest

(Onderdeel van prescription/directTarget/prescribedMedication/productOf/)

Formaat:

<productOf>
     <medicationDispenseRequest>
         <statusCode … />
     [		<repeatNumber … /> ]
               <quantity … />
     [		<destination … /> ]
     [		<performer … /> ]
     </medicationDispenseRequest/>
</productOf>

Definitie: Een expliciet verzoek (bij een ambulant voorschrift) van de voorschrijver aan een verstrekker (die al dan niet benoemd wordt) om een bepaalde hoeveelheid van de voorgeschreven medicatie te verstrekken aan de patiënt of diens vertegenwoordiger.

Het element wordt niet gebruikt in de volgende gevallen:

• Voor klinische medicatievoorschriften, omdat de (eventueel) te verstrekken medicatie dan wordt afgeleid uit de toedieningsverzoeken in het voorschrift.
• Voor ambulante medicatievoorschriften zonder noodzaak tot verstrekking van medicatie, omdat de patiënt nog voldoende medicatie beschikbaar heeft.

Deze laatste categorie is nu nog vrij zeldzaam, omdat in die gevallen vaak helemaal geen medicatievoorschrift wordt verzonden. Het streven is echter om de toepassing van het voorschrift steeds meer onafhankelijk te maken van het al dan niet verstrekken van medicatie. Dit is noodzakelijk om te zorgen dat het medicatiebeleid transparant blijft.

De aanwezigheid van de elementen <productOf><medicationDispenseRequest> is feitelijk conditioneel required. Dat wil zeggen dat een zuiver klinisch systeem ze niet zal gebruiken, maar dat elk ambulant systeem ze moet ondersteunen (deze eis heeft betrekking op zowel voorschrijvende als verstrekkende systemen).

Het is overigens mogelijk om in het verstrekkingsverzoek aan te geven dat de verstrekking een aantal malen herhaald mag (of zelfs moet) worden (element <medicationDispenseRequest><repeatNumber>). Op deze manier kan één enkel verzoek dienen als specificatie voor het uitvoeren van meerdere (deel)verstrekkingen.

Optioneel kan een aflverlocatie worden opgegeven in <destination> (zie aldaar voor details).

Bij elk verstrekkingsverzoek moet conditioneel worden aangegeven welke verstrekker (zie bij <performer>) geacht wordt de verstrekking uit te voeren. Hierbij gaat het niet zo zeer om de persoon maar om de instelling voor wie het verstrekkingsverzoek bedoeld is.

medicationDispenseRequest.statusCode

Formaat:

<statusCode nullFlavor="NA"/>

Dit element heeft geen functie meer in het verstrekkingsverzoek (aangezien alleen de status van het gehele voorschrift relevant is), maar moet nog worden meegegeven i.v.m. het XML Schema. Daarom ‘niet van toepassing’ d.m.v. nullFlavor ”NA” (not applicable).

medicationDispenseRequest.repeatNumber

Formaat

<repeatNumber value="9"/>

of

<repeatNumber>

</repeatNumber>

Definitie: Het aantal deelverstrekkingen dat in het kader van dit voorschrift gedaan moet worden. In de meeste gevallen zal dit zelf bepaald worden door de verstrekker, maar het kan met dit element ook expliciet worden aangeduid door de voorschrijver. Als geen waarde wordt meegegeven, dan is de default waarde “1” (waarbij de voorschrijver er dus van uitgaat dat één verstrekking zal plaatsvinden op basis van het voorschrift).

Het datatype van <repeatNumber> is IVL_TS, met achterliggende gedachte dat ook een minumum en/of maximum aantal herhalingen kan worden aangegeven. Van deze mogelijkheid wordt echter (nog) geen gebruik gemaakt!

Alle gegevens binnen de <medicationDispenseRequest> (met name ook de te verstrekken hoeveelheid in <quantity>) hebben betrekking op de afzonderlijke (deel)verstrekkingen, als een <repeatNumber> hoger dan 1 is aangegeven. De totaal te verstrekken hoeveelheid is: <repeatNumber> x <quantity>.

XML voorbeeld:

De voorschrijver suggereert, vanwege de eerder gebleken kans op misbruik van het geneesmiddel, een aantal van drie deelverstrekkingen (van elk 30 tabletten) in het kader van een medicatievoorschrift waarbij in totaal 90 tabletten verstrekt mogen worden.

<repeatNumber value="3"/>
<quantity value="30">
  <translation …/>
</quantity>

medicationDispenseRequest.quantity

Formaat:

Ambulante voorschriften

<quantity value="…" [ unit="…" ]>	
    <translation value="…" code="…" 
                 codeSystem="2.16.840.1.113883.2.4.4.1.900.2" 
                 displayName="…"/>
[   <translation value="…" code="…" 
                 codeSystem="2.16.840.1.113883.2.4.4.12" 
                 displayName="…"/> 
]
</quantity>

Klinische voorschriften

<quantity nullFlavor="NA"/>

Definitie: De hoeveelheid die per (deel)verstrekking moet worden verstrekt.

In Nederland bestaat momenteel voor ambulante medicatievoorschriften (verstrekt in de eerste lijn) de wettelijke verplichting om de te verstrekken hoeveelheid van de medicatie expliciet door te geven. Dit bekent dat dit attribuut in ambulante voorschriften altijd gevuld en groter dan 0 moet zijn. Andersom wordt het bij klinische medicatievoorschriften niet gevuld, omdat bij klinische medicatie de logistiek van medicatieverstrekkingen los staat van het voorschrift.

De primaire eenheid moet afkomstig zijn uit de Unified Codes for Units of Measure (UCUM). Deze lijst met eenheden is wereldwijd geaccepteerd. De lijst met eenheden uit de UCUM is ook opgenomen als HL7 vocabulary domain UnitsOfMeasureCaseSensitive.

Het datatype PQ dat hierbij gebruikt wordt, kan betrekking hebben op een meetbare hoeveelheid van het geneesmiddel (bijvoorbeeld in grammen of liters) of op het aantal telbare eenheden (bijvoorbeeld tabletten of ampullen). HL7v3 hanteert dit als volgt:

• ‘Meetbare’ hoeveelheden worden in overeenkomstige fysieke eenheden uitgedrukt;
• ‘Telbare’ hoeveelheden kennen alleen een aantal met als eenheid ‘1’ (’units’).

Vooral het feit dat HL7v3 geen ‘telbare’ eenheden, zoals tabletten, ondersteunt, leidt soms tot verwarring. De gedachte is dat dit feitelijk geen teleenheden zijn, maar de farmaceutische vorm van de medicatie. Deze is impliciet door de gekozen medicatiecode of kan desgewenst expliciet worden doorgegeven. Op deze manier wordt inconsistentie tussen hoeveelheid en vorm voorkomen.

De unit ”1” is de default voor telbare eenheden (het betekent dus ‘eenheden’ en niets meer). Het weglaten van de unit wordt dus geïnterpreteerd als unit=”1”.}}

Normaal gesproken zijn alleen de volgende eenheden nodig in de praktijk:

Typische UCUM eenheden

unit	betekenis	opmerkingen
m	meter	zie voorvoegsels
g	gram	zie voorvoegsels
l	liter	zie voorvoegsels
[drp]	druppel	= 1/12 ml
[tsp_us]	theelepel	= 0.003 l
[tbs_us]	eetlepel	= 0.015 l
[iU]	internationale eenheid	alleen klinisch

Typische UCUM voorvoegsels

voorvoegsel bij unit	betekenis	omrekenfactor
u	micro	1/1.000.000
m	milli	1/1.000
c	centi	1/100
d	deci	1/10
k	kilo	1.000

Deze voorvoegsels kunnen alleen gebruikt worden in combinatie met m, g en l. De achterliggende gedachte achter het attribuut unit van het datatype PQ is dat meetbare waarden zoveel mogelijk naar elkaar omgerekend moeten kunnen worden. Het mag dus niets uitmaken of een systeem 2 mg of 0.002 g stuurt als hoeveelheid, omdat het ontvangende systeem in staat moet zijn om te zien dat deze feitelijk hetzelfde zijn. Ontvangende systemen moeten de mogelijke eenheden kunnen omrekenen.

De waarde van dit gegevenselement hangt samen met het aantal gewenste deelverstrekkingen in het verstrekkingsverzoek. De <quantity> geeft de hoeveelheid te verstrekken medicatie per deelverstrekking aan. De totaal te verstrekken hoeveelheid wordt dan: <repeatNumber> x <quantity>.

VERTALING NAAR ANDERE CODERINGSSYSTEMEN

Het is verplicht om naast (dus niet in plaats van!) de bovengenoemde UCUM codering van HL7, ook een vertaling door te geven naar de G-Standaard basiseenheden (tabel 2 van de thesauraus). Daarnaast kan optioneel een vertaling worden aangeduid naar de G-Standaard deelverpakkingen (tabel 4). In beide gevallen wordt gebruik gemaakt van de numerieke codes uit deze tabellen (doorgegeven zonder voorloopnullen).

• de G-Standaard basiseenheden hebben OID 2.16.840.1.113883.2.4.4.1.900.2.
• de G-Standaard deelverpakkingen hebben OID 2.16.840.1.113883.2.4.4.12.

XML voorbeeld:

Een voorschrijver spreekt met de patiënt af dat deze eerst twee weken lang 3 x daags een tablet van een geneesmiddel zal slikken, vervolgens vier weken lang 2 x daags en tenslotte 6 weken lang 1 x daags een tablet (afbouwschema). In het verstrekkingsverzoek aan de openbare apotheek wordt een aantal van (14x3) + (28x2) + (42x1) = 140 tabletten genoemd als totaal te verstrekken hoeveelheid (in één verstrekking).

Daarbij wordt een vertaling meegegeven naar G-Standaard basiseenheden (subtabel 2 van de thesaurus). Hiermee wordt aangeduid dat het gaat om basiseenheid “245" (stuk). Merk op dat unit de defaultwaarde “1" heeft, en dus ook weggelaten mag worden.

<quantity value="140" unit="1">
  <translation value="150" code="245" 
     codeSystem="2.16.840.1.113883.2.4.4.1.900.2" 
     displayName="stuk"/>
</quantity>

Er wordt doorgegeven dat het gaat om 20 milliliter van de te verstrekken medicatie, maar daarbij wordt een vertaling meegegeven naar G-Standaard deelverpakkingen (subtabel 4 van de thesaurus). Hiermee wordt aangeduid dat het gaat om 2 ampullen.

Merk op dat er in dit geval niet alleen een andere (vertaalde) eenheid wordt gebruikt, maar dat daarbij natuurlijk ook een andere hoeveelheid hoort (20 ml = 2 ampullen).

<quantity value="20" unit="ml">
  <translation value="20" code="233" 
     codeSystem="2.16.840.1.113883.2.4.4.1.900.2" 
     displayName="MILLILITER"/>
  <translation value="2" code="1" 
     codeSystem="2.16.840.1.113883.2.4.4.12" 
     displayName="AMPUL"/>
</quantity>

In een klinische medicatieopdracht staat geen expliciete te verstrekken hoeveelheid.

<quantity nullFlavor="NA"/>

medicationDispenseRequest.destination

Formaat (afleverlocatie)

Bij elk verstrekkingsverzoek kan optioneel worden aangegeven op welke plaats de medicatie verstrekt (of liever gezegd: afgeleverd) dient te worden. Als deze locatie de apotheek zelf is, dan dit gegeven vanzelfsprekend niet nodig. Het dient dus alleen gebruikt te worden om een afwijkend afleveradres (in een ambulante situatie) aan te duiden

XML voorbeeld: Medicatie moet op het woonadres bezorgd worden.

<destination>
    <serviceDeliveryLocation>
        <code nullFlavor="NI"/>
        <addr use="HP">
            <streetName>Prikstraat</streetName>
            <houseNumber>12</houseNumber>
            <city>Amsterdam</city>
        </addr>
    </serviceDeliveryLocation>
</destination>

Als de afleverlocatie wordt doorgegeven, dan is dit attribuut verplicht gevuld en bevat het adres waar de verstrekking van medicatie geacht wordt plaats te vinden. Aangezien dit momenteel beperkt is tot ambulante medicatievoorschriften, zal dit in de praktijk meestal het woonadres van de patiënt zijn (dit kan ook in een verzorgingshuis zijn).

Aangezien het woonadres van de patiënt meestal al bekend zal zijn (omdat voorschrijver en verstrekker gesynchroniseerde patiëntgegevens hebben of omdat de patiëntgegevens zijn meegestuurd met het voorschrift), is het handig om zo eenvoudig mogelijk te kunnen aanduiden dat aflevering bij de patiënt thuis dient plaats te vinden. In dat geval hoeft slechts de use code ‘HP’ te worden doorgegeven en niet het woonadres zelf.

XML voorbeeld: Er wordt doorgegeven dat aflevering op het (bekende) woonadres moet plaatsvinden:

<addr use=’HP’/>

Het is ook mogelijk dat een adres al bekend is, maar een nadere toelichting nodig is in een specifieke situatie. Bijvoorbeeld bij iemand die in een verpleeghuis woont, hetgeen ook bekend is bij de apotheek, maar waar aangegeven wordt waar de medicatie afgegeven kan worden.

XML voorbeeld: Wanneer het adres bekend is, kan ook volstaan worden met een nadere toelichting voor de afleverlocatie.

<destination>
    <serviceDeliveryLocation>
        <code nullFlavor="NI"></code>
        <addr>
            <desc>Bezorgen aan de balie.</desc>
        </addr>
    </serviceDeliveryLocation>
</destination>

De heer Pietersen is op vakantie in de regio van apotheek ‘De Gulden Pil’. Zijn reguliere woonadres wordt doorgegeven bij de patiëntgegevens in het voorschrift, maar daarnaast wordt doorgegeven dat de medicatie moet worden afgeleverd op het vakantieadres:

XML voorbeeld: Een vakantieadres.

<addr use=’HV’>
    <streetAddressLine>Camping de Wigwam</streetAddressLine>
    <streetAddressLine>plaats 4F</streetAddressLine>
    <streetName>Landweg</streetName>
    <houseNumber>20-24</houseNumber>
    <postalCode>9999AA</postalCode>
    <city>Buitendorp</city>
</addr>

medicationDispenseRequest.performer

Formaat:

<performer>
      <assignedPerson>
          <representedOrganization … />
      </assignedPerson>
</performer>

Definitie: De (beoogde) verstrekker aan wie een verstrekkingsverzoek is gedaan.

Waarom moet dit element expliciet worden opgenomen in een medicatievoorschrift als het direct van een voorschrijver naar een specifieke verstrekker is verzonden (wiens applicatie wordt geadresseerd in de transmission wrapper)? Omdat de HL7 payload elk aspect van de gegevensinhoud moet omvatten. Dit biedt de mogelijkheid om (beter) te voorkomen dat de medicatie (ten onrechte) alsnog door een andere apotheek wordt verstrekt. Aangezien de transmission wrapper meestal niet bewaard blijft, biedt deze geen persistente informatie.

Het element <performer><assignedPerson> is verplicht in een medicatievoorschrift als:

• Het medicatievoorschrift (via het LSP) wordt verzonden (of eerder is verzonden en nu wordt opgeleverd) naar een specifieke apotheek.

Het element <performer><assignedPerson> is afwezig in een medicatievoorschrift als:

• Het medicatievoorschrift een impliciet bekende verstrekker heeft (klinische MO of voorgeschreven door apotheekhoudende huisarts).

Het element <assignedPerson> is slechts een ‘lege huls’ om de bijbehorende zorginstelling te kunnen aanduiden (zie <representedOrganization> hieronder), want er is vooralsnog geen reden bekend om een specifieke persoon als verstrekker aan te duiden.

assignedPerson.representedOrganization

(Onderdeel van prescription/directTarget/prescribedMedication/productOf/medicationDispenseRequest/performer/)

Formaat:

<representedOrganization>
        <id … />
   [    <name … /> ]
   [    <addr … /> ]
</representedOrganization>

Definitie: De zorginstelling onder wiens verantwoordelijkheid de medicatieverstreking geacht wordt plaats te vinden. Zie ook de richtlijnen hiervoor in assignedPerson.

Deze zorginstelling moet verplicht worden geïdentificeerd (met een URA-nummer). Optioneel kan daarnaast de naam en de vestigingsplaats worden doorgegeven.

assignedPerson.representedOrganization.id

Formaat:

 <id root="2.16.528.1.1007.3.3" extension="$URA-nummer"/>

Definitie: Een unieke identificatie van de (beoogde) verstrekkende zorginstelling.

Het is op dit moment nog niet zeker dat UZI abonneenummers 100% geschikt zijn voor de identificatie van zorginstellingen, aangezien in feite elk samenwerkingsverband van zorgverleners eigen UZI passen kan aanvragen, en daarmee UZI abonneehouder kan worden. Het is echter de enige identificatiemethode voor zorginstellingen binnen de UZI systematiek, die verder geheel gericht is op identificatie van individuele zorgverleners en andere medewerkers.

De root OID voor UZI-abonneenummers is: 2.16.528.1.1007.3.3. De UZI-abonneenummers bestaan uit een 8-cijferig nummer, inclusief voorloopnullen.

Een medisch specialist schrijft een poliklinisch voorschrift uit en geeft aan dat de verstrekking plaats dient te vinden bij een apotheek naar keuze van de patiënt.

<id root="2.16.528.1.1007.3.3" extension="00432011"/>

assignedPerson.representedOrganization.name

Formaat:

 <name>$naam</name>

Definitie: De naam van de verstrekkende zorginstelling. Deze is alleen relevant als de ontvanger geen gegevens bij het URA-nummer heeft en toch een omschrijving wil kunnen tonen van de zorginstelling waar de verstrekking geacht wordt plaats te vinden.

Het datatype van dit element is ON (Organization Name), waarbij binnen Nederland is afgesproken om dit als één string door te geven (zie [HL7v3 IH Basis]).

XML voorbeeld:

Er heeft een verstrekking plaatsgevonden in openbare apotheek ‘De Gulden Pil’. Merk op dat de naam als ‘mixed content’ wordt doorgegeven, dus zonder quotes.

<name>De Gulden Pil</name>

assignedPerson.representedOrganization.addr

Formaat:

<addr use="WP"><city>$plaats</city></addr>

Definitie: De vestigingsplaats van de verstrekkende zorginstelling. Deze is alleen relevant als de ontvanger geen gegevens bij het URA-nummer heeft en, aanvullend op de naam, ook de plaats wil tonen waar de verstrekking geacht wordt plaats te vinden.

Het datatype van dit element is AD (Postal Address), maar in deze context is het voldoende om de <city> door te geven als onderscheidend kenmerk van de instelling.

XML voorbeeld:

Er heeft een verstrekking plaatsgevonden in een apotheek in Amersfoort. Merk op dat de stad als ‘mixed content’ wordt doorgegeven, dus zonder quotes.

<addr use="WP">
     <city>Amersfoort</city>
</addr>

Medicatieverstrekking (PORX/COCT_MT924000NL02)

D-MIM:	Pharmacy
HL7v3 gestructureerde naam:	Medication Dispense Event

Diagram

Beschrijving
De bovenstaande R-MIM´s zijn bedoeld om alle relevante gegevens rond een medicatieverstrekking weer te geven. Het payload model PORX_MT924000NL02 wordt gebruikt bij het versturen van een nieuwe verstrekking, maar bestaat op zichzelf uit niets anders dan de CMET COCT_MT924000NL02. Een CMET mag echter niet direct als payload fungeren, dus vandaar dat een dummymodel nodig is. De CMET fungeert daarnaast als onderdeel van de Medicatieverstrekkingenlijst, als component van een opgeleverde lijst.

De belangrijkste kenmerken van het model zijn:

• Elke verstrekking heeft betrekking op één enkele patiënt.
• Elke verstrekking hoort bij max. één medicatievoorschrift.
• Elke verstrekking kent één enkele verstrekker als uitvoerder.
• Elke verstrekking heeft één ‘verantwoordelijke zorgverlener’.
• Elke verstrekking heeft betrekking op één enkele soort medicatie.
• Elke verstrekking zal één of meer toedieningsverzoeken betreffen.

De zogenaamde focal class is de klasse MedicationDispenseEvent, die betrekking heeft op één enkele medicatieverstrekking. Deze klasse fungeert als entry point (startpunt) voor de payload van interacties op basis van het message type PORX_MT924000NL02 en als onderdeel van andere message types die CMET COCT_MT924000NL02 gebruiken.

Bij elk medicatievoorschrift hoort logisch gezien één patiënt, maar die wordt niet altijd expliciet doorgegeven, omdat deze in veel gevallen wordt bepaald door de context (met name bij rapportage als onderdeel van een lijst).

Binnen het R-MIM wordt gebruik gemaakt van een aantal domeinspecifieke CMET’s (Common Message Element Types) die hergebruikt worden in verschillende R-MIM’s:

• E_MedicationKindNL voor de verstrekte medicatiesoort;
• A_MedicationAdministrationRequestNL voor ‘toedieningsverzoeken’.

De implementatierichtlijnen voor deze CMET’s worden elders in dit doument uitgewerkt.

Het huidige model voor medicatieverstrekkingen is zowel bruikbaar voor verstrekkingen op voorschrift als voor “handverkoop”, afhankelijk van de aanwezigheid van het element <prescription> is. Het is niet de bedoeling om ‘handverkoop’, ook aangeduid als ‘over the counter’ (OTC), door te geven door een fictief voorschrift te registreren met als ‘voorschrijver’ bijvoorbeeld “handverkoop”. Door zo’n dummy-voorschrijver te gebruiken, zou geen verschil meer te maken zijn tussen verstrekkingen zonder voorschrift en die met onbekende voorschrijver. Een verstrekking zonder voorschrift moet dus worden aangeven door het element <prescription> weg te laten!

Merk op dat binnen de verstrekking twee nauw verwante concepten bestaan. Deze worden in navolging van afspraken tussen NHG en KNMP aangeduid als therapeutische GEbruiksperiode en logistieke VERbruiksperiode. Therapeutische gebruiksperiode geeft aan hoe lang de voorschrijver wil dat de patiënt dit middel als therapie blijft gebruiken. Dit therapeutische gegeven bevindt zich in <medicationAdministrationRequest><effectiveTime>. Logistieke verbruiksperiode geeft aan hoe lang de patiënt voort kan met de hoeveelheid medicatie die deze keer verstrekt is. Dit logistieke gegeven bevindt zich in <medicationDispenseEvent><expectedUseTime>. Het is bekend dat de meeste AIS'en nog geen onderscheid maken tussen deze twee concepten. In deze AIS'en wordt meestal een periode berekend op basis van verstrekte hoeveelheid en dosering, waarbij niet kan worden aangegeven of dit zuiver logistieke of ook therapeutische informatie betreft. Om historische redenen zijn er AIS'en die deze berekende periode in <medicationDispenseEvent><expectedUseTime> plaatsen, maar ook AIS'en die het in <medicationAdministrationRequest><effectiveTime> plaatsen. Ontvangende systemen moeten er rekening mee houden dat dit gegeven op beide plaatsen kan staan. Hierbij geldt dat wanneer beide een waarde bevatten, de logistieke verbruiksperiode uit <medicationDispenseEvent><expectedUseTime> gehaald moet worden.

Hierarchical Message Description

<medicationDispenseEvent>	Medicatieverstrekking
<performer><assignedPerson>	Verstr. medewerker
<product><dispensedMedication> <MedicationKind>	Verstrekte medicatie
[{ <activeIngredient> [ <activeIngredientMaterialKind> ] }]	Werkzame stof
[{ <otherIngredient><ingredientMaterialKind> }]	Andere ingrediënt
[ <directTargetOf> <prescription>	Medicatievoorschrift
[ <subject> <Patient> ]	Patiënt
[ <author> <AssignedPerson> ]	Voorschrijvende arts
]
{ <therapeuticAgentOf><medicationAdministrationRequest>	Toedieningsverzoek
[{ <support2><medicationAdministrationInstruction> }]	Gebruiksinstructie
[{ <precondition> <observationEventCriterion> }]	Randvoorwaarde
}
<responsibleParty> <assignedCareProvider>	Verantw. zorgverlener
<representedOrganization>	Verantw. zorginstelling

medicationDispenseEvent

Formaat:

<medicationDispenseEvent>
    <id …/>
    <statusCode …/>
    <effectiveTime …/>
    <quantity …/>
    <performer …/>
    <product …/>
    <responsibleParty …/>
</medicationDispenseEvent>

Definitie: afhankelijk van toepassing in ambulante respectievelijk klinische situatie:

Ambulante verstrekkingen

Bij ambulante verstrekkingen betreft elke <medicationDispenseEvent> één enkele overdracht van één enkele medicatie ten behoeve van één enkele patiënt. Dat wil zeggen dat als dezelfde patiënt twee keer op dezelfde dag met een recept verschijnt, er twee aparte medicatieverstrekkingen worden gerapporteerd. Strikt genomen is sprake van een medicatieverstrekking zodra overdracht heeft plaatsgevonden aan de patiënt of diens vertegenwoordiger (die namens de patiënt de voorgeschreven medicatie komt ophalen).

Officieel is het bepalende moment de overdracht van de medicatie aan de toediener, maar het is bekend dat veel (openbare) apotheeksystemen de verstrekking al registreren zodra de medicatie klaarstaat! Dit wordt vooralsnog geaccepteerd, maar het kan wel betekenen dat een verstrekking wordt gerapporteerd terwijl de betreffende medicatie nooit wordt opgehaald. Pas bij periodieke opschoning zal een dergelijke verstrekking dan ongedaan gemaakt worden, hetgeen (nog) niet expliciet kan worden gerapporteerd.

Klinische verstrekkingen

Bij klinische verstrekkingen is het eigenlijk niet zo interessant om te kijken naar de feitelijke logistiek van de medicatiestroom, aangezien die vaak nauwelijks te koppelen is aan de medicatie voor een afzonderlijke patiënt. Strikt genomen zou je ook hier kunnen zeggen dat sprake is van een verstrekking als bepaalde medicatie vanuit voorraad ‘gekoppeld wordt’ aan een specifieke patiënt, of dat nu in de ziekenhuisapotheek of op de verpleegafdeling gebeurt. Dit zou zeer veel afzonderlijke verstrekkingen opleveren.

Er wordt gewerkt met een benadering van een ‘klinische verstrekking’, waarbij de essentie is dat de ziekenhuisapotheker akkoord moet zijn met het geleverde. De interpretatie is dus: een door de apotheek geaccordeerde medicatieopdracht, samengevat over de looptijd van de opdracht (tot nu). Merk op dat er wel een beperking is tot medicatie die wordt geleverd door het ziekenhuis, dus doorgebruikte thuismedicatie valt hier sowieso buiten!

Voor extra en achtergrondinformatie ga naar Medicatieverstrekking

medicationDispenseEvent.id

Formaat:

 <id root="…" extension="…"/>

Definitie: De identificatie van de medicatieverstrekking. De identificatie wordt gegenereerd door het verstrekkende systeem (van de apotheek) en moet wereldwijd en eeuwig uniek zijn. Zie [HL7v3 IH Basis] voor een toelichting op het gebruik van datatype II om een dergelijke identifier aan te duiden.

Het verstrekkende systeem moet er dus voor zorgen dat elke medicatieverstrekking een eigen (en persistente) <id> krijgt. Een ontvangend systeem (bijvoorbeeld van een andere apotheek) dat deze informatie (als kopie) bewaart, mag er van uitgaan dat als het dezelfde identifier ontvangt, dit om actuele gegevens van dezelfde verstrekking gaat.

XML voorbeeld:

Een Apotheek Informatie Systeem registreert medicatieverstrekkingen en levert deze op bij bevraging via het LSP. Elke verstrekking heeft een uniek 10-cijferig referentienummer, dat wordt gecombineerd met de root OID die hoort bij het identificatiesysteem.

<id extension="0008112345" root="2.16.528.1.1007.3.3.345678.1.1"
    assigningAuthorityName="AIS van Apotheek de Gulden Gaper"/>

In bovenstaand voorbeeld heeft de apotheek blijkbaar URA nummer ‘00345678’ (er mogen geen voorloopnullen in een OID node voorkomen), is ‘1’ de aanduiding voor het AIS dat men gebruikt en is ‘1’ de aanduiding voor de verstrekkingsnummers binnen dat AIS. Deze opbouw is géén eis (zolang de OID maar uniek is), maar slechts een suggestie.

medicationDispenseEvent.statusCode

Formaat:

<statusCode code="completed"/>

Definitie: De status van de medicatieverstrekking. Deze is bij het rapporteren van de verstrekking altijd completed, aangezien de verstrekking reeds (volledig) heeft plaatsgevonden. Er wordt nog geen aparte status bijgehouden voor verschillende fasen tijdens het voorbereiden/uitvoeren van een verstrekking (dat wil zeggen het verwerken van het voorschrift, waarbij medicatie uit voorraad wordt gehaald of eventueel wordt bereid).

XML voorbeeld:

<statusCode code="completed"/>

medicationDispenseEvent.effectiveTime

Formaat:

 <effectiveTime value="YYYYMMDD[HHMM]"/>

of

<effectiveTime>
       <low value="YYYYMMDDHHMM"/>
    [  <high value ="YYYYMMDDHHMM"/> ]
</effectiveTime>

Definitie: De datum (eventueel met tijdstip) of periode waarin de medicatieverstrekking plaatsvond. Het datatype is IVL_TS (interval van time stamps), maar bij ambulante verstrekkingen wordt alleen de verstrekkingsdatum (en eventueel –tijd) gerapporteerd.

Bij klinische ‘verstrekkingen’ is er voor gekozen om niet bij elk afzonderlijk verstrekkingsmoment (voor zover daarvan gesproken kan worden) een aparte verstrekking te rapporteren. Het idee is dat per klinisch verstrekte medicatie (zodra die door de ziekenhuisapotheek geaccordeerd is) een ‘virtuele verstrekking’ wordt bepaald, waarin aggregatie plaatsvindt van alle gegevens met betrekking tot die medicatie tijdens de looptijd van de medicatieopdracht. In dat geval wordt bij <medicationDispenseEvent><effectiveTime> geen tijdstip (datatype TS) maar een periode (datatype IVL<TS>) gebuikt, die overeenkomt met de periode waarbinnen de betreffende medicatie door de patiënt is gebruikt. Deze periode kan een ‘open einde’ hebben zolang de medicatieopdracht loopt. Indien sprake is van zo’n klinische periode, zijn tijden bij de grenzen verplicht!

XML voorbeeld:

Een ambulante medicatieverstrekking vindt plaats op 15 februari 2010 om 14:21.

<effectiveTime value="201002151421"/>

Een patiënt is opgenomen en heeft sinds 12 februari 2010 om 09:00 een medicatieopdracht (die door de ziekenhuisapotheek is geaccordeerd) voor bepaalde medicatie.

<effectiveTime> 
     <low value="201002120900"/>
</effectiveTime>

Als dezelfde patiënt op 18 februari 2010 om 16:00 wordt ontslagen (of als de medicatie wordt gestopt, of gewisseld naar andere medicatie) dan wordt <effectiveTime> als volgt:

<effectiveTime> 
     <low value="2010102120900"/>
     <high value="201002181600"/>
</effectiveTime>

medicationDispenseEvent.quantity

Formaat:

Klinische verstrekkingen

<quantity nullFlavor="NA"/>			

Ambulante verstrekkingen

<quantity value="…" [ unit="…" ]>	
    <translation code="…" codeSystem="2.16.840.1.113883.2.4.4.1.900.2" displayName="…"/>
  [ <translation code="…" codeSystem=" 2.16.840.1.113883.2.4.4.12" displayName="…"/> ]
</quantity>	

Definitie: De hoeveelheid medicatie die is verstrekt bij deze medicatieverstrekking.

Er gelden aparte regels voor de ambulante respectievelijk klinische setting:

• Bij ambulante verstrekkingen (meestal bij openbare apotheken) is <quantity> verplicht gevuld met de aan de patiënt of diens vertegenwoordiger afgeleverde hoeveelheid van de medicatie. Deze registratie is momenteel een wettelijke eis.
• Bij klinische verstrekkingen (dus geaccordeerde klinische medicatieopdrachten) hoeft <quantity> niet gevuld te zijn, omdat het in de klinische situatie vaak heel lastig is (en sowieso niet erg zinvol) om de ‘verstrekte’ hoeveelheid te bepalen.

Er wordt dan de nullFlavor "NA" (not applicable) meegegeven in het element.

De primaire eenheid moet afkomstig zijn uit de Codes for Units of Measure] (UCUM). Deze lijst met eenheden is wereldwijd geaccepteerd. De lijst met eenheden uit de UCUM is ook opgenomen als HL7 vocabulary domain UnitsOfMeasureCaseSensitive.

Het datatype PQ dat hierbij gebruikt wordt, kan betrekking hebben op een meetbare hoeveelheid van het geneesmiddel (bijvoorbeeld in grammen of liters) of op het aantal telbare eenheden (bijvoorbeeld tabletten of ampullen). HL7v3 hanteert dit als volgt:

• ‘Meetbare’ hoeveelheden worden in overeenkomstige fysieke eenheden uitgedrukt;
• ‘Telbare’ hoeveelheden kennen alleen een aantal met als eenheid ‘1’ (‘units’).

Vooral het feit dat HL7v3 geen ‘telbare’ eenheden, zoals tabletten, ondersteunt, leidt soms tot verwarring. De gedachte is dat dit feitelijk geen teleenheden zijn, maar de farmaceutische vorm van de medicatie. Deze is impliciet door de gekozen medicatiecode of kan desgewenst expliciet worden doorgegeven. Op deze manier wordt inconsistentie tussen hoeveelheid en vorm voorkomen.

De unit "1" is de default voor telbare eenheden (het betekent dus ‘eenheden’ en niets meer). Het weglaten van de unit wordt dus geïnterpreteerd als unit="1". }}

Normaal gesproken zijn alleen de volgende eenheden nog in de praktijk:

unit	betekenis	opmerkingen
m	meter	zie tabel voorvoegsels
g	gram	zie tabel voorvoegsels
l	liter	zie tabel voorvoegsels
[drp]	druppel	= 1/12 ml
[tsp_us]	theelepel	= 0.003 l
[tbs_us]	eetlepel	= 0.015 l
[iU]	internationale eenheid	alleen klinisch

Tabel voorvoegsels

voorvoegsel bij unit	betekenis	omrekenfactor
u	micro	1/1.000.000
m	milli	1/1.000
c	centi	1/100
d	deci	1/10
k	kilo	1.000

Deze voorvoegsels kunnen alleen gebruikt worden in combinatie met m, g en l. De achterliggende gedachte achter het attribuut unit van het datatype PQ is dat meetbare waarden zoveel mogelijk naar elkaar omgerekend moeten kunnen worden. Het mag dus niets uitmaken of een systeem 2 mg of 0.002 g stuurt als verstrekte hoeveelheid, omdat het ontvangende systeem in staat moet zijn om te zien dat deze feitelijk hetzelfde zijn. Ontvangende systemen moeten de mogelijke eenheden kunnen omrekenen.

VERTALING NAAR ANDERE CODERINGSSYSTEMEN

Het is verplicht om naast (dus niet in plaats van!) de bovengenoemde UCUM codering van HL7, ook een vertaling door te geven naar de G-Standaard basiseenheden (tabel 2 van de thesauraus). Daarnaast kan optioneel een vertaling worden aangeduid naar de G-Standaard deelverpakkingen (tabel 4). In beide gevallen wordt gebruik gemaakt van de numerieke codes uit deze tabellen (doorgegeven zonder voorloopnullen).

De G-Standaard basiseenheden hebben OID 2.16.840.1.113883.2.4.4.1.900.2. De G-Standaard deelverpakkingen hebben OID 2.16.840.1.113883.2.4.4.12.

XML voorbeeld:

Er zijn aan een patiënt in een openbare apotheek 6 verpakkingen met elk 12 tabletten van een bepaald medicijn verstrekt. De totale verstrekte hoeveelheid is dus 72 tabletten. Het feit dat het om tabletten gaat volgt uit de farmaceutische vorm van de medicatie. Merk op dat "unit de defaultwaarde "1" heeft, en dus ook weggelaten mag worden.

<quantity value="72" unit="1">
  <translation value="72" code="245" 
     codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
     displayName="stuk"/>
</quantity>

Een apotheekhoudende huisarts heeft aan een patiënt 200 ml van een vloeistof verstrekt.

<quantity value="200" unit="ml">
   <translation value="200" code="233"
      codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
      displayName="MILLILITER"/>
</quantity>

Er wordt informatie doorgegeven over een (geaccordeerde) klinische medicatieopdracht.

<quantity nullFlavor="NA"/>

medicationDispenseEvent.expectedUseTime

Het veld expectedUseTime bevat optioneel de logistieke verbruiksperiode.

Het datatype IVL<TS> dat hierbij gebruikt wordt, bevat een tijdsduur (onafhankelijk van de begindatum), dit betekent dat alleen het xml element width gebruikt wordt.

XML voorbeeld:

Een voorschrijver spreekt met de patiënt af dat deze eerst twee weken lang 3 x daags een tablet van een geneesmiddel zal slikken, vervolgens vier weken lang 2 x daags en tenslotte 6 weken lang 1 x daags een tablet (afbouwschema). Deze toedieningsperiodes zijn opgenomen in het voorschrift, maar daarnaast wordt in het verstrekkingsverzoek nog meegegeven dat de te verstrekken hoeveelheid voldoende is voor 12 weken gebruik.

<expectedUseTime>
	<width value="12" unit="wk"/>
</expectedUseTime>

medicationDispenseEvent.performer.assignedPerson

De oorspronkelijke gedachte was dat de feitelijke verstrekkende medewerker (van een apotheek of apotheekhoudende huisarts) zou worden doorgegeven, zodat achteraf kan worden nagegaan wie direct betrokken is geweest bij deze handeling. In de praktijk bleek dat er verschillende redenen waren waarom dit geen realistische communicatie-eis was:

• Sommige systemen registreren verstrekkingen niet op afzonderlijke medewerker.
• Sommige apotheken hebben niet voor elke apothekersassistent een UZI-pas.
• Zelfs als er wel een betrouwbare identificatie is, wil men die vaak afschermen.

Dit laatste hangt samen met het feit dat bij het opvragen van medicatieverstrekkingen dan ook de verstrekkende medewerker in te zien is door bijvoorbeeld andere apotheken, maar ook via een patiëntportaal. Dit wordt uit oogpunt van privacy niet wenselijk geacht en weegt niet op tegen de (beperkte) functionele meerwaarde. Dit element wordt dus alleen nog gehandhaafd vanwege XML Schema-compatibiliteit met voorgaande versies.

Merk op dat het natuurlijk toegestaan (en zelfs wenselijk) blijft om binnen het verstrekkende systeem wel een registratie bij te houden van de betrokken medewerker(s) per verstrekking. Waar mogelijk kan dit gekoppeld worden aan de UZI-pas, maar dat is geen vereiste. Deze informatie wordt dus niet (meer) uitgewisseld, maar blijft handig als achteraf navraag gedaan moet worden.

medicationDispenseEvent.performer.assignedPerson.id

Formaat:

<id nullFlavor="MSK"/>

Het element <id> voor het UZI-pasnummer van de verstrekkende medewerker is verplicht aanwezig, maar zoals is toegelicht is het niet wenselijk om het ook feitelijk uit te wisselen. Daarom wordt hier de vaste nullFlavor “MSK” (masked) gebruikt om aan te geven dat de informatie weliswaar bekend is, maar desondanks niet wordt uitgewisseld.

medicationDispenseEvent.product.dispensedMedication

Formaat:

 <product>
      <dispensedMedication>
           <MedicationKind … />
      [	   <directTargetOf … /> ]
      {    <therapeuticAgentOf … /> }
      </dispensedMedication>
 </product>

Bij elke medicatieverstrekking moet exact één verstrekte medicatie worden aangeduid. Uit bovenstaande sectie van het informatiemodel vallen de volgende zaken af te lezen:

• Bij elke medicatieverstrekking hoort één enkele verstrekte medicatie(soort).
• Bij elke verstrekte medicatie horen één of meer toedieningsverzoeken.
• Bij elke verstrekte medicatie kan een medicatievoorschrift horen.

De medicatiesoort wordt weergegeven met de CMET E_MedicationKind NL (zie link). In een medicatieverstrekking geldt de volgende regel:

Bij een medicatieverstrekking moet altijd de meest specifieke aanduiding van de medicatie worden doorgegeven. Het heeft absoluut de voorkeur om daarbij gebruik te maken van het KNMP artikelnummer, maar het kan in sommige klinische apotheeksystemen voorkomen dat niet op dat niveau geregistreerd wordt. In dat geval mag ook op HPK niveau een code worden doorgegeven. Merk op dat deze regel betekent dat ontvangende systemen niet altijd kunnen rekenen op het gebruik van het artikelnummer in het verstrekkingenoverzicht. De enige overige uitzondering betreft magistrale receptuur, waarvoor sowieso geen KNMP artikelnummer beschikbaar is. Naast de meest specifieke code mogen (en soms moeten) ook ‘vertalingen’ naar codes uit minder specifieke codeersystemen worden doorgegeven. Zie verder bij E_MedicationKind NL.

dispensedMedication.medicationKind

Ga naar medicationKind

medicationDispenseEvent.product.dispensedMedication.directTargetOf.prescription

Formaat:

 <directTargetOf>
      <prescription>
           <id … />
           <statusCode … />
      [    <subject … /> ]
      [    <author … /> ]
      </prescription>
 </directTargetOf>

Bij veel medicatieverstrekkingen is sprake van een bijbehorend medicatievoorschrift. Indien de verstrekking plaatsvindt op basis van een voorschrift, dan dient hiernaar te worden verwezen. Toch zijn ook dan niet altijd specifieke gegevens van dit voorschrift bekend, bijvoorbeeld als de verstrekking op basis van een papieren recept is uitgevoerd. In dat geval wordt toch <directTargetOf><prescription> meegegeven, maar zullen niet alle gegevens bekend zijn. Het ontbreken van <directTargetOf><prescription> betekent dus dat de betreffende verstrekking niet op voorschrift (‘over the counter’) is uitgevoerd!

dispensedMedication.directTargetOf.prescription.id

Onderdeel van medicationDispenseEvent/product

Formaat:

   <id root="…" extension="…"/>

OF

   <id nullFlavor="UNK"/>

Definitie: De identificatie van het medicatievoorschrift behorend bij de verstrekking. De identificatie wordt gegenereerd door het voorschrijvende systeem (bijvoorbeeld van de huisarts of medisch specialist) en wordt door het verstrekkend systeem slechts overgenomen ter referentie. Hierbij moet zowel root als extension bewaard worden.

Het is dus niet toegestaan om na het handmatig invoeren van medicatievoorschriften (papieren recepten) op de plaats van dit element een door het verstrekkend systeem (meestal AIS) zelf gegeneerde identificatie voor het voorschrift op te nemen. Deze identificatie kan immers niet dienen als referentie naar de gegevens bij de voorschrijver en heeft dus geen waarde binnen het landelijke EPD. Als geen voorschriftnummer via elektronische uitwisseling met het voorschrijvend systeem verkregen is, dan dient op de plaats van dit element expliciet de nullFlavor "UNK" te worden opgenomen.

XML voorbeeld:

Een Apotheek Informatie Systeem heeft een elektronisch medicatievoorschrift ontvangen en op basis daarvan een verstrekking uitgevoerd. Bij rapportage van de verstrekking wordt een referentie meegestuurd naar het oorspronkelijke voorschriftnummer.

<id extension="0008112345"
	root="2.16.840.1.113883.2.4.6.1.1025463.1.9"
	assigningAuthorityName="HIS van Dr. Jansen"/>

Een Apotheek Informatie Systeem heeft een papieren medicatievoorschrift ontvangen en op basis daarvan een verstrekking uitgevoerd. Bij het rapporteren van de verstrekking wordt aangegeven dat geen referentie bekend is naar een extern voorschriftnummer.

<id nullFlavor="UNK"/>

dispensedMedication.directTargetOf.prescription.statusCode

Onderdeel van medicationDispenseEvent/product

Formaat:

	
   <statusCode code="active|completed"/>

OF

	
   <statusCode nullFlavor="UNK"/>

Definitie: De status van het medicatievoorschrift behorend bij de verstrekking. Die status is “active" als de patiënt nog medicatie gebruikt op basis van dit voorschrift (meestal betreft dit de medicatie die bij de onderhavige verstrekking is geleverd) en “completed" als het gebruik van medicatie op basis van dit voorschrift afgerond is.

In de meeste gevallen zal het verstrekkende systeem echter niet over deze informatie beschikken en daarom de nullFlavor "UNK" opleveren (status voorschrift is onbekend).

XML voorbeeld:

Een openbare apotheek heeft medicatie verstrekt op basis van een voorschrift. Binnen het AIS staat het voorschrift gemarkeerd als ‘actief’, hetgeen aangeeft dat bij medicatiebewaking rekening gehouden wordt met het feit dat de medicatie nog wordt gebruikt.

<statusCode code="active"/>

Een openbare apotheek heeft medicatie verstrekt op basis van een voorschrift. Binnen het AIS wordt niet bijgehouden of bij een voorschrift nog medicatie wordt gebruikt.

<statusCode nullFlavor="UNK"/>

dispensedMedication.directTargetOf.prescription.subject.patient

Onderdeel van medicationDispenseEvent/product

Zie voor de CMET R_PatientNL [universal] de [HL7v3 IH Basis].

Elk medicatievoorschrift hoort bij een specifieke patiënt. Het is echter niet altijd nodig om deze expliciet door te geven binnen de Medicatieverstrekking, omdat de patiënt soms al bekend is door de context. De associatie <subject> is daarom conditioneel verplicht, afhankelijk van de HL7v3 interactie waarbinnen de Medicatieverstrekking wordt gebruikt:

• <subject> niet opnemen als de Medicatieverstrekking onderdeel is van een Medicatieverstrekkingenlijst (antwoord op interactie OpvragenVerstrekkingenlijst).
• <subject> verplicht opnemen als de Medicatieverstrekking wordt gebruikt als op zichzelf staande payload van een notificatie (in de interactie meldVerstrekking).

In de CMET R_PatientNL [universal] zijn geen verplichte elementen behalve het patiëntnummer. In deze context zijn er echter enkele specifieke kenmerken: Het patiëntnummer (<Patient><id>) is altijd een BSN. Er moet een (familie)naam van de patiënt gevuld zijn. De geboortedatum van de patiënt moet gevuld zijn. Het geslacht van de patiënt moet aangeduid zijn. De reden om de aanvullende patiëntgegevens naast het BSN door te geven, ligt in de mogelijkheid om daarmee de identiteit extra te kunnen controleren.

XML voorbeeld:

Er wordt een verstrekking opgevraagd behorende bij een voorschrift voor patiënt mevr. Bette Freriks-van Weezel, geboren op 10 december 1973, met BSN-nummer 042715231.

<subject>
     <Patient>
          <id root="2.16.840.1.113883.2.4.6.3" extension="042715231"/>
     <statusCode code="active"/>
     <Person>
          <name>
              <prefix qualifier="VV">van </prefix>
              <family qualifier="BR">Weezel</family>
          </name>
          <administrativeGenderCode code="F"
            codeSystem="2.16.840.1.113883.5.1"/>
          <birthTime value="19731210"/>
      </Person>
      </Patient>
</subject>

dispensedMedication.directTargetOf.prescription.author

Onderdeel van medicationDispenseEvent/product

Formaat:

		
<author>
    <time … />
    <AssignedPerson … />
</author>

Elk medicatievoorschrift is door een zorgverlener opgesteld (en ondertekend). Het is echter niet altijd bekend wie de voorschrijver was bij elke medicatieverstrekking, omdat soms geput wordt uit historische gegevens die minder volledig zijn. Om rapportage van dergelijke verstrekkingen toch mogelijk te maken is de associatie <author> required. Dat wil zeggen dat de voorschrijver alleen moet worden opgeleverd als deze bekend is.

dispensedMedication.therapeuticAgentOf

Bij een verstrekking van patiëntgebonden medicatie worden altijd één of meer (sets) gebruiksinstructies meegegeven. Dit zijn de oorspronkelijke gebruiksinstructies uit het voorschrift, nadat de verstrekkende apotheker er een (al dan niet actieve) controle op heeft uitgevoerd. Soms worden daarbij nog kleine aanpassingen gemaakt (bijvoorbeeld omdat een artikel met een andere sterkte is verstrekt, waardoor de keerdosis moet worden aangepast), maar over het algemeen komt het exact overeen bij het voorschrift.

In termen van HL7v3 is sprake van een ‘toedieningsverzoek’ (net als bij het voorschrift), alleen is het nu dus nadat de verstrekkende apotheker het heeft beoordeeld. De feitelijke gebruiksinstructies zitten als subelement in de CMET A_MedicationAdministrationRequest.

Voor verdere implementatierichtlijnen met betrekking tot element <therapeuticAgentOf> en subelementen, wordt verwezen naar de toelichting bij Medicatievoorschrift (therapeuticAgentOf).

medicationDispenseEvent.responsibleParty.assignedCareProvider

Formaat:

	
 <responsibleParty>
        <assignedCareProvider>
             <id … />
             <code … />
             <representedOrganization … />
        </assignedCareProvider>
 </responsibleParty>

Definitie: De apotheker of apotheekhoudende huisarts die verantwoordelijk was voor de verstrekking, inclusief de bijbehorende organisatie (zorginstelling) van deze zorgverlener.

Vanzelfsprekend is het in een apotheek met meerdere apothekers niet bij voorbaat duidelijk wie er ‘verantwoordelijk’ is voor een verstrekking. Er moet echter toch een individuele zorgverlener worden aangeduid in het kader van de WGBO. Om dit te bepalen kan bijvoorbeeld het volgende worden gedaan: Eén apotheker wordt aangewezen als verantwoordelijke voor alle verstrekkingen van de apotheek. Dit verdient zeker niet de voorkeur. Er wordt op basis van een dienstrooster bepaald wie er verantwoordelijk is voor verstrekkingen in een bepaald tijdvak. Dit is enigszins bewerkelijk. Er wordt per patiënt bijgehouden wie er een ‘behandelrelatie’ met die patiënt heeft (samenhangend met de rol van ‘medicatiebegeleider’ en deze apotheker is verantwoordelijk voor verstrekkingen aan die patiënt). In alle gevallen kan de verstrekking zijn uitgevoerd zonder dat de betreffende apotheker ervan wist. Dit doet echter niets af aan diens verantwoordelijkheid.

medicationDispenseEvent.responsibleParty.assignedCareProvider.id

Formaat:

	 
<id root="2.16.528.1.1007.3.1" extension="$UZI-nummer"/>

Definitie: Unieke identificatie van de verantwoordelijke zorgverlener. Identificatie vindt plaats met het UZI-nummer. De root OID voor UZI-nummers is: 2.16.528.1.1007.3.1. De UZI-nummers bestaan uit een 9-cijferig nummer, inclusief voorloopnullen.

XML voorbeeld

Een verstrekking is uitgevoerd door een assistent van de openbare apotheker met UZI- nummer “007657555" (en deze apotheker is gemarkeerd als ‘verantwoordelijke’).

<id root="2.16.528.1.1007.3.1" extension="007657555"/>

medicationDispenseEvent.responsibleParty.assignedCareProvider.code

Formaat:

Definitie: De zorgverlenersrol van de zorgverlener die verantwoordelijk is voor de medicatieverstrekking. Het begrip zorgverlenersrol heeft betrekking op de bevoegdheden en specialisatie van de zorgverlener. Hierbij wordt gebruik gemaakt van het codesysteem PractitionerRoleNL met de OID 2.16.840.1.113883.2.4.15.111, dat ook gebruikt wordt voor codering van zorgverlenersrollen op UZI-passen. Mogelijke codes zijn:

Level	Type, Domain name and/or Mnemonic code	Mnemonic	Definition/description
3	L: (01.004)	01.004	Apotheekhoudende huisarts (1)
2	S: (17.000)	17.000	Apotheker (1)
3	L: (17.060)	17.060	Ziekenhuisapotheker (1)

Merk op dat een aparte code bestaat voor ‘apotheekhoudende huisarts’, om deze te onderscheiden van een ‘gewone’ huisarts. Naast overige huisartsgegevens kan de apotheekhoudende dus ook verantwoordelijkheid nemen voor medicatieverstrekkingen.

XML-voorbeeld:

Een verstrekking is uitgevoerd onder verantwoordelijkheid van een openbare apotheker.

<code	code="17.000"
	codeSystem="2.16.840.1.113883.2.4.15.111"
	displayName="Apotheker"/>

medicationDispenseEvent.responsibleParty.assignedCareProvider.representedOrganization

Formaat:

	
 <representedOrganization>
         <id … />
   [	 <name … /> ]
   [	 <addr … /> ]
 </representedOrganization>

Definitie: De zorginstelling onder wiens verantwoordelijkheid de medicatieverstreking heeft plaatsgevonden. Dit kan één van de onderstaande typen zorginstelling betreffen:

• openbare apotheek;
• apotheekhoudende huisartspraktijk;
• ziekenhuis;
• zelfstandige ziekenhuisapotheek.

Deze zorginstelling moet verplicht worden geïdentificeerd (met een URA-nummer). Optioneel kan daarnaast de naam en de vestigingsplaats worden doorgegeven.

medicationDispenseEvent.responsibleParty.assignedCareProvider.representedOrganization.id

Formaat:

	
<id root="2.16.528.1.1007.3.3" extension="$URA-nummer"

Definitie: Unieke identificatie van de verstrekkende zorginstelling. Op basis hiervan kan de ontvanger van deze informatie bepalen waar de verstrekking heeft plaatsgevonden.

Het is op dit moment nog niet zeker dat UZI-abonneenummers 100% geschikt zijn voor de identificatie van zorginstellingen, aangezien in feite elk samenwerkingsverband van zorgverleners eigen UZI-passen kan aanvragen, en daarmee UZI-abonneehouder kan worden. Het is echter de enige identificatiemethode voor zorginstellingen binnen de UZI-systematiek, die verder geheel gericht is op identificatie van individuele zorgverleners en andere medewerkers.

De root OID voor UZI-abonneenummers is: 2.16.528.1.1007.3.3. De UZI-abonneenummers bestaan uit een 8-cijferig nummer, inclusief voorloopnullen.

XML voorbeeld:

Er heeft een verstrekking plaatsgevonden in de apotheek met URA-nummer 00432011.

<id root="2.16.528.1.1007.3.3" extension="00432011"/>

medicationDispenseEvent.responsibleParty.assignedCareProvider.representedOrganization.name

Formaat:

	
<name>$naam</name>

Definitie: De naam van de verstrekkende zorginstelling. Deze is alleen relevant als de ontvanger geen gegevens bij het URA-nummer heeft en toch een omschrijving wil kunnen tonen van de zorginstelling waar de verstrekking heeft plaatsgevonden.

Het datatype van dit element is ON (Organization Name), waarbij binnen Nederland is afgesproken om dit als één string door te geven (zie [HL7v3 IH Basis]).

XML voorbeeld:

Er heeft een verstrekking plaatsgevonden in openbare apotheek ‘De Gulden Pil’. Merk op dat de naam als ‘mixed content’ wordt doorgegeven, dus zonder quotes.

<name>De Gulden Pil</name>

medicationDispenseEvent.responsibleParty.assignedCareProvider.representedOrganization.addr

Formaat:

	
<addr use="WP"><city>$plaats</city></addr>

Definitie: Vestigingsplaats van de verstrekkende zorginstelling. Deze is alleen relevant als de ontvanger geen gegevens bij het URA-nummer heeft en, aanvullend op de naam van de instelling, ook de plaats wil tonen waar de verstrekking heeft plaatsgevonden.

Het datatype van dit element is AD (Postal Address), maar in deze context is het voldoende om de <city> door te geven als onderscheidend kenmerk van de instelling.

XML voorbeeld:

Er heeft een verstrekking plaatsgevonden in een apotheek in Amersfoort. Merk op dat de stad als ‘mixed content’ wordt doorgegeven, dus zonder quotes.

<addr use="WP">
     <city>Amersfoort</city>
</addr>

Toedieningsverzoek

D-MIM:	Pharmacy
HL7v3 gestructureerde naam:	Medication Administration Request

Diagram

Figuur 6 COCT_RM940000NL01 - R-MIM diagram

Beschrijving

De CMET A_MedicationAdministrationRequestNL bevat de gegevenselementen die nodig zijn om de instructies voor het gebruik van de medicatie door te geven. Dit behelst met name doseerschema en doseerhoeveelheid, maar ook aanvullende gebruiksinstructies.

De CMET heeft betrekking op een gebruiksafspraak met één bepaalde doseerhoeveelheid. Indien er sprake is van een medicatievoorschrift met wisselende doseerhoeveelheden, dan dient de CMET meerdere keren opgenomen te zijn (één keer per doseerhoeveelheid).

Hierarchical Message Description

<medicationAdministrationRequest>	Toedieningsverzoek
[{ <support2><medicationAdministrationInstruction> }]	Gebruiksinstructie
[{ <precondition><observationEventCriterion> }]	Randvoorwaarde

De zogenaamde focal class van het R-MIM is dus de klasse MedicationAdministrationRequest, die betrekking heeft op één enkel ‘toedieningsverzoek’. Deze klasse fungeert als entry point voor de CMET in message types die COCT_MT940000NL gebruiken.

medicationAdministrationRequest

Formaat:

			
 <medicationAdministrationRequest>
     <text>…</text>
 [   <effectiveTime … /> ]
 [   <routeCode … /> ]
 [   <doseQuantity … /> ]
 [   <doseCheckQuantity … /> ]
 [   <maxDoseQuantity … /> ]
 [{  <support2 … /> } ]
 [{  <precondition … /> } ]

Definitie: Eén specifieke gebruiksafspraak voor de betreffende medicatie. Dit omvat:

• Eén bepaalde doseerhoeveelheid (per toediening óf per periode);
• Eén doseerschema dat geldt binnen een bepaalde gebruiksperiode;
• Bijbehorende instructies, zoals de toedieningsweg, randvoorwaarden etc.

Het doseerschema kan wisselen in de tijd (datatype GTS), dus het onderscheidende kenmerk van <medicationAdministrationRequest> is de specifieke doseerhoeveelheid.

Voor extra en achtergrondinformatie ga naar Toedieningsverzoek

medicationAdministrationRequest.text

Formaat:

	
<text mediaType="text/plain">$text</text>

Definitie: Een tekstuele weergave van het toedieningsverzoek of de verzameling toedieningsverzoeken (in de 1e lijn meestal aangeduid als het gebruiksvoorschrift). Deze tekst kan afkomstig zijn van het oorspronkelijke ‘papieren’ medicatievoorschrift (na invoer in het verstrekkende systeem), maar kan ook door het voorschrijvende of verstrekkende systeem automatisch worden gegenereerd uit de gecodeerde gegevens.

Bij elk toedieningsverzoek moet verplicht een tekstuele omschrijving gevuld zijn.

De scope van <medicationAdministrationRequest><text> Het is belangrijk om op te merken dat het element <text> alleen betrekking heeft op elementen die op hetzelfde niveau of lager in het bericht zitten. In dit geval mag <text> dus alleen informatie over het toedieningsverzoek en aanverwante zaken bevatten. De tekst mag dus geen aanduiding van de voorgeschreven/verstrekte medicatie en/of het gevraagde/verstrekte aantal bevatten. Het is puur bedoeld om doseerschema, doseerhoeveelheid en aanvullende gebruiksinstructies tekstueel te omschrijven (zie voorbeelden).

Tekstuele versus gecodeerde gegevens Merk op dat <text> aanvullend is op de functie van gecodeerde gegevens in de toedieningsverzoeken, maar die niet kan vervangen. De gecodeerde gegevenselementen zijn belangrijk om automatische verwerking en gebruik voor de medicatiebewaking mogelijk te maken. Het element <text> is er om te zorgen dat een ontvangend systeem direct aan de gebruiker kan tonen wat de intentie van het gebruiksvoorschrift was (zoals vastgelegd in het verzendende systeem). Regels voor de samenhang tussen tekst en gecodeerde gegevens zijn: De <text> moet alle informatie uit de gecodeerde gegevens weergeven; De <text> mag meer informatie bevatten dan de gecodeerde gegevens; De <text> moet inhoudelijk consistent zijn met gecodeerde gegevens. Het feit dat er situaties kunnen zijn waarin er wel een tekstuele, maar geen gecodeerde gebruiksinstructie is (zoals bij ‘gebruik bekend’), wil niet zeggen dat <text> als vervanging voor de gecodeerde gegevens kan dienen. Elk systeem moet in staan zijn met gecodeerde gegevens te werken, indien van toepassing.

Geen tabel 25 instructies doorgeven in <text> Net als bij elk attribuut van datatype ST (String) mag aan de waarde van <text> geen inhoudelijke betekenis worden toegekend bij verwerking van de instructie. Het is dus niet toegestaan om bijvoorbeeld een tabel 25 instructie door te geven in dit element. Als het verzendende systeem in staat is om tabel 25 instructies te genereren (zoals veel huisartsinformatiesystemen in de 1e lijn) dan is het verleidelijk om deze letterlijk door te geven. In praktische zin is het onverstandig om hiervan afhankelijk te zijn, aangezien de meeste systemen in de 2e lijn geen ondersteuning voor tabel 25 bieden. Er dient dus zoveel mogelijk een vertaling te worden gemaakt naar HL7-representatie en, voor zover dat niet mogelijk is, dient de instructie te worden doorgegeven als (ongecodeerde) tekst.

De <text> bij meerdere <medicationAdministrationRequest> elementen Het kan voorkomen dat het element <medicationAdministrationRequest> (MAR) herhalend voorkomt (zoals bij een wisselende doseerhoeveelheid in de tijd). In dergelijke situaties zou strikt genomen het <text> element van elke <MAR> alleen betrekking moeten hebben op de inhoud van dat specifieke <MAR> element. Dit is echter heel lastig te realiseren voor sommige systemen, omdat zij intern één enkele representatie hebben van de gebruiksinstructie. In dergelijke gevallen is het toegestaan om binnen elke herhaling van het <MAR> element dezelfde inhoud van het <text> element op te nemen. Deze tekst heeft dan betrekking op de gehele verzameling van meegestuurde <MAR> elementen. Aan de kant van een ontvangend systeem kan een zij-effect van bovenstaande werkwijze zijn dat dezelfde tekst meerdere keren herhaald wordt (omdat daar de teksten uit de <MAR> elementen achterelkaar worden geplakt). Dit kan worden voorkomen door dubbele teksten te herkennen en slechts éénmaal op te nemen.

XML voorbeeld:

Er wordt een handgeschreven medicatievoorschrift ingevoerd, waarop de tekst ’30 stuks Paracetamol 200 mg, max. 3xdgs 1 tablet bij hoofdpijn. Met water innemen.’ staat. De tekst van de daarin opgenomen gebruiksinstructies wordt letterlijk doorgegeven.

<text mediaType="text/plain">
  Max. 3xdgs 1 tablet bij hoofdpijn. Met water innemen.
</text>

In een elektronisch voorschrijfsysteem (EVS) wordt een klinische medicatieopdracht ingevoerd door het selecteren van een doseerhoeveelheid, een doseerschema en eventuele gecodeerde gebruiksinstructies. Deze informatie-elementen worden op de juiste plaatsen doorgegeven in het toedieningsverzoek, maar daarnaast wordt hieruit (geautomatiseerd) een tekstuele omschrijving van het toedieningsverzoek (dus de bijbehorende gebruiksinstructies) gegenereerd. Dit ziet er bijvoorbeeld als volgt uit:

<text mediaType="text/plain">
  Start: 		21/04/2008
  Stop:			<tot nader order>
  Frequentie: 		1 x daags
  Dosering: 		1 sachet
  Bijzonderheden: 	in water oplossen
</text>

Er wordt een medicatieverstrekking gedaan voor Doxycycline, met als gebruiksinstructie ‘Op de eerste dag 1x daags 2 tabletten, daarna 6 dagen lang 1x daags 1 tablet.’. Het apotheekinformatiesysteem slaat dit echter op als één geheel en is niet in staat om bij de twee <medicationAdministrationRequest> elementen die bij deze instructie ontstaan een aparte tekst te genereren. In dat geval wordt de gehele instructie in <text> herhaald.

<medicationAdministrationRequest>
    <text mediaType="text/plain">
    Op de eerste dag 1x daags 2 tabletten, daarna 6 dagen lang 1x daags 1 tablet.
    </text>
     …
</medicationAdministrationRequest>
<medicationAdministrationRequest>
    <text mediaType="text/plain"> 
    Op de eerste dag 1x daags 2 tabletten, daarna 6 dagen lang 1x daags 1 tablet.
    </text>
     …
</medicationAdministrationRequest>

medicationAdministrationRequest.effectiveTime

Formaat:

<effectiveTime xsi:type="SXPR_TS">
   $gebruiksperiode
   $doseerschema
</effectiveTime>

Zie verder de detailspecificaties in "Specificaties voor datatype GTS voor doseerschema".

Definitie: Aanduiding van de spreiding van toedieningen binnen een bepaalde periode, ook wel aangeduid als het doseerschema (van de betreffende gebruiksperiode).

Dit is één van de meest belangrijke gegevenselementen bij het specificeren van het gebruiksvoorschrift voor medicatie, aangezien het alle informatie bevat ten aanzien van het tijdsinterval waarbinnen de toediening plaatsvindt en het doseerschema dat daarbinnen moet worden gehanteerd. Het datatype van <effectiveTime> is GTS (General Timing Specification). Dit biedt een zeer rijke (maar ook complexe) structuur voor het aanduiden van tijdstippen, tijdsintervallen en tijdspatronen met een vrijwel onbeperkt complexe opbouw. Voor het HL7v3 domein medicatiegegevens is besloten om een ingeperkte toepassing van GTS te hanteren, welke is opgenomen in "Specificaties voor datatype GTS voor doseerschema".

Het element <effectiveTime> moet gevuld zijn als er iets te melden is over gebruiksinterval óf doseerschema. De enige situatie waarin <effectiveTime> leeg blijft is als niets bekend is over het gebruiksinterval én er geen specifiek doseerschema is. Dit kan zich bijvoorbeeld voordoen in de volgende situaties: ‘zo nodig’ medicatie, waarbij de patiënt (of verpleger bij klinische medicatie) zelf bepaalt of en wanneer gebruik van de medicatie nodig is; medicatie waarbij wordt verwezen naar een extern doseerschema, zoals bij ´gebruik bekend´ of ´volgens schema trombosedienst´; medicatie waarvan alleen een periodieke totaaldosis (en geen keerdosis) wordt gemeld, die in <doseCheckQuantity> wordt doorgegeven. Merk op dat het ontbreken van een doseerschema nog niets zegt over het ontbreken van een gebruiksperiode (die ook op zichzelf kan bestaan).

Algemene structuur attribuut effectiveTime

De eerste vraag die gesteld moet worden is of er sprake is van één vast doseerschema (spreiding van toedieningen over de tijd) of van een wisselend doseerschema. In dat laatste geval moet gebruik worden gemaakt van meerdere toedieningsverzoeken (herhalingen van de CMET A_MedicationAdministrationRequest). Theoretisch zou het datatype GTS wel in staat zijn om wisselende doseerschema’s in één constructie op te nemen, maar om de complexiteit in te perken wordt dit niet toegestaan. Elk element <effectiveTime> heeft dus per definitie betrekking op één vast doseerschema.

Dat betekent dat elk element <effectiveTime> de volgende mogelijke onderdelen heeft:

• Therapeutische gebruiksperiode (tijdsinterval waarbinnen doseerschema van toepassing is);
• Doseerschema (spreiding van de toedieningen over de gebruiksperiode).

Beide onderdelen zijn optioneel, omdat ze soms niet expliciet benoemd worden.

Het is bekend dat de meeste AIS'en de therapeutische gebruiksperiode niet als afzonderlijk gegeven vastleggen. Om redenen van backwards compatibility is het deze AIS'en toegestaan, om de therapeutische gebruiksperiode te benaderen met een berekende periode op basis van verstrekte hoeveelheid en dosering.

THERAPEUTISCHE GEBRUIKSPERIODE

Formaat: Ambulante medicatie

<comp xsi:type="IVL_TS" nullFlavor="UNK">

OF

<comp xsi:type="IVL_TS">
  <width value="…" unit="d"/>
</comp>

OF

<comp xsi:type="IVL_TS">
   <low value="YYYYMMDD[HHMM]"/>
[  <width value= "…" unit="d"/> ]
</comp>

        Klinische medicatie

<comp xsi:type="IVL_TS">
   <low value="YYYYMMDDHHMM"/>
[  <high value= "YYYYMMDDHHMM" ]
</comp>

De therapeutische gebruiksperiode kan in een toedieningsverzoek verschillende gedaanten aannemen. Daarbij moet onderscheid gemaakt worden tussen ambulante en klinische situaties.

Ambulante medicatie

• Geen waarde.

Bij ambulante medicatie is er soms geen gebruiksduur (en dus geen gebruiksperiode) bekend. Dit is bijvoorbeeld het geval bij ‘zo nodig’ medicatie (omdat het verbruik door de patiënt afhangt van de mate waarin de klachten optreden).

Merk op dat het onwenselijk is om bij ‘zo nodig’ medicatie of andere situaties waarbij geen gebruiksduur is af te leiden een vaste (default) gebruiksduur door te geven. Momenteel hanteren veel systemen een standaard gebruiksduur van 90 dagen in dat soort gevallen. Dat is een voorbeeld van ‘schijninformatie’, die de ontvanger ten onrechte beperkt bij het uitvoeren van medicatiebewaking.

• Alleen een <width> element.

Meestal is alleen de afgesproken duur van het gebruik bekend. Deze kan bijvoorbeeld expliciet onderdeel zijn van het doseervoorschrift (zoals bij gebruik van sommige b codes in tabel 25).

De gebruiksperiode kan ook in combinatie met een begindatum voorkomen.

Deze methode verdient de voorkeur boven de gangbare methode van het doorgeven van een begin- en einddatum, omdat dit meestal ‘schijninformatie’ is. De datum waarop de patiënt begint met het medicatiegebruik is meestal niet bekend (kan de verstrekkingsdatum zijn, maar ook de dag erna, of nog later). Het is daarom beter de (berekende of afgesproken) gebruiksduur mee te geven, zodat de ontvanger zelf kan bepalen welke periode daaruit wordt afgeleid (meestal zal de ontvanger ook de verstrekkingsdatum als begindatum nemen).

• Een <low> element (met optioneel een <width> element).

Soms zal de voorschrijver of de verstrekker expliciet met de patiënt afspreken dat het gebruik op een bepaalde datum moet beginnen. Dit zal meestal gelijk zijn aan de verstrekkingsdatum, maar kan ook de dag erna of een andere datum in de toekomst zijn. Dit zal meestal het geval zijn bij medicatie die met spoed gestart moet worden, of bij kuren die in een specifieke periode gebruikt moeten worden.

Als een <low> element wordt gebruikt voor de begindatum, dan kan optioneel een <width> element worden toegevoegd als de gebruiksduur bekend is. Zie hiervoor de tekst bij het <width> element.

De meeste elektronische voorschrijfsystemen (EVS-en) voeren standaard geen therapeutische gebruiksperiode in (maar kunnen eventueel wel een gebruiksduur berekenen). De meeste apotheekinformatiesystemen (AIS-en) hanteren echter de methode waarbij een begin- en einddatum van het gebruik worden vastgelegd (met de verstrekkingsdatum als begindatum). Als de verstrekker deze ‘voorstelperiode’ ook kan wijzigen, dan zou gesteld kunnen worden dat daarmee een expliciete gebruiksperiode wordt aangeduid. Als de leverancier dit zo interpreteert, kan de begindatum als <low> element worden meegegeven. In plaats van de einddatum moet echter de (daaruit afgeleide) gebruiksduur worden doorgegeven.

Het is optioneel mogelijk om naast de begindatum ook een precieze begintijd mee te geven, die bij een verstrekking groter of gelijk moet zijn aan het tijdstip waarop de verstrekking plaatsvond. Hiermee kan desgewenst expliciet worden gemaakt dat de gebruiksperiode niet eerder dan de verstrekking is begonnen.

Klinische medicatie Bij klinische medicatie wordt zowel in het EVS als in het AIS (van het ziekenhuis) altijd gewerkt met exacte tijdsperiodes voor begin- en einde van een medicatieopdracht (MO). Daarbij is niet alleen de datum maar ook het tijdstip voor het begin van de toediening altijd bekend. De einddatum (en –tijd) zullen in eerste instantie echter meestal onbekend zijn, omdat de meeste MO’en ‘open einde’ zijn, dat wil zeggen ze blijven actief totdat ze afgebroken of gewijzigd worden. Pas in dat geval komt er een einddatum en –tijd bij.

DOSEERSCHEMA De details van de opbouw van een doseerschema binnen <effectiveTime> worden gegeven in "Specificaties voor datatype GTS voor doseerschema". In de tekst hieronder worden alleen enkele standaardkenmerken doorgenomen, behorende bij diverse mogelijke onderdelen van een doseerschema.

Vaste frequentie Bij veel ambulante voorschriften is het doseerschema van de vorm “m x per dag", of in algemene zin “m x per n dagen/weken/etc." (vergelijkbaar met het Xt deel van tabel 25). Deze zijn vrij eenvoudig aan te duiden door middel van een periodiek herhalend interval:

<comp xsi:type="PIVL_TS" operator="A"> <period value="$herhaalperiode" unit="min|h|d|wk|mo|a"/> </comp>

doseerschema op basis van vaste frequentie

De $herhaalperiode bij een frequentie van m x per n tijdseenheden, wordt bepaald als:

$herhaalperiode = n / m tijdseenheden

waarbij de tijdseenheid gelijk moet zijn aan degene waarin de frequentie was uitgedrukt.

Merk op dat het vaak zal voorkomen dat de value in de <period> een niet-geheel getal is. Als bijv. 2x per dag moet worden toegediend, dan zal <period> <value> de waarde “0.5" hebben (een herhaalperiode van een halve dag). Lastiger nog wordt het bij bijv. 3x per week, dat een <period><value> oplevert van “0.3333". In principe zou de reeks met 3-en natuurlijk oneindig lang kunnen zijn. De regel is echter dat in zo’n geval wordt afgekapt op 4 decimalen! Merk op dat dit dus een ander resultaat kan opleveren dan wanneer wordt afgerond!

Het feit dat de frequentie moet worden omgezet in een ‘herhaalperiode’ (bijvoorbeeld 0.5 dag in plaats van 2x per dag) is onderkend als onpraktische beperking in HL7v3. In de volgende versie van de datatypes (R2) wordt dan ook een extra component <frequency> toegevoegd aan het datatype PIVL_TS, zodat de frequentie direct kan worden doorgegeven. De toevoeging zal backwards compatible zijn, dus het toepassen van de huidige component <period> blijft als alternatief voorhanden.

Variabele frequentie

Bij sommige ambulante voorschriften is het doseerschema van de vorm “m1-m2 x per dag", of in algemene zin “m1-m2 x per n dagen/weken/etc." (ook toegestaan in het Xt deel van tabel 25). Er is geen directe methode om een dergelijke variabele frequentie vast te leggen in het datatype GTS, dus er moet een formaat gebruikt worden die dezelfde betekenis op een andere manier weergeeft. Deze ontstaat door het idee dat m1-m2 x eigenlijk betekent: in ieder geval m1 keer en zo nodig maximaal m2 x.

Elders in dit document (bij het element <precondition>) wordt toegelicht hoe ‘zo nodig’ kan worden doorgegeven. Toepassing hiervan op een variabele frequentie levert op:

$vaste_herhaalperiode = n / m1 tijdseenheden
$zonodig_herhaalperiode = n / (m2 – m1) tijdseenheden

<therapeuticAgentOf> <medicationAdministrationRequest> … <effectiveTime xsi:type="SXPR_TS"> … <comp xsi:type="PIVL_TS" operator="A"> <period value="$vaste_herhaalperiode" unit="min|h|d|wk|mo|a"/> </comp> </effectiveTime> … </medicationAdministrationRequest> <therapeuticAgentOf> <therapeuticAgentOf> <medicationAdministrationRequest> … <effectiveTime xsi:type="SXPR_TS"> … <comp xsi:type="PIVL_TS" operator="A"> <period value="$zonodig_herhaalperiode" unit="min|h|d|wk|mo|a"/> </comp> </effectiveTime> … </medicationAdministrationRequest> <precondition> <observationEventCriterion> <code nullFlavor="NI"/> </observationEventCriterion> </precondition> <therapeuticAgentOf>

doseerschema op basis van variabele frequentie

Het is duidelijk dat bovenstaande methode voor het doorgeven van een variabele frequentie omslachtig is. Het eerder genoemde component <frequency> in de volgende versie van de datatypes (R2) heeft dan ook de mogelijkheid om een variabele frequentie direct door te geven. Daardoor zal het niet meer nodig zijn om de <therapeuticAgentOf> te herhalen.

TOEDIENING OP VASTE TIJDEN (PER DAG)

Bij veel klinische medicatieopdrachten wordt op zeker moment het doseerschema ingevuld met exacte tijdstippen op basis van de vaste toedieningstijdstippen op de betreffende verpleegafdeling. Overigens gebeurt dit meestal pas na bevestiging van de medicatieopdracht door de ziekenhuisapotheek (DMO), dus het oorspronkelijke voorschrift zal ook in de klinische situatie meestal zijn gebaseerd op een frequentie per tijdseenheid (zie boven). Opnieuw wordt in deze situatie gebruik gemaakt van een periodiek tijdsinterval, maar nu met vaste tijdstippen:

<comp xsi:type="SXPR_TS" operator="A"> <comp xsi:type="PIVL_TS"> <phase> <center value="{eerste tijdstip}"/> </phase> <period value="1" unit="d"/> </comp> <comp xsi:type="PIVL_TS" operator="I"> <phase> <center value="{tweede tijdstip}"/> </phase> <period value="1" unit="d"/> </comp> etc. </comp>

doseerschema op basis van vaste tijden (per dag)

De operator “I" is de default in het datatype GTS, hetgeen betekent dat er niet van uitgegaan mag worden dat deze altijd aanwezig is. Het ontbreken van een operator moet dus geïnterpreteerd worden alsof er operator “I" staat. Dit klopt ook met het feit dat de eerste component in een verzameling meestal geen operator krijgt. Als dit gelezen wordt als operator “I" klopt dat nog steeds, omdat er geen voorgaand element is (vereniging met lege set heeft geen effect).

Merk op dat de tijdstippen moeten worden aangeduid inclusief een datum. Hoewel het feitelijk niet uitmaakt welke datum daar gekozen wordt (een periodiek interval strekt zich per definitie onbeperkt uit), verdient het aanbeveling hiervoor de startdatum van de toedieningsperiode te kiezen. Dit is dus het eerste moment (aangeduid als Time Stamp) waarop de betreffende toediening zal plaatsvinden (en elke dag herhaald wordt).

TOEDIENING VOLGENS CYCLISCH SCHEMA

Een veel voorkomend type doseerschema, zowel bij klinische als bij ambulante voorschriften, is het zogenaamde cyclische schema. In feite is dit een algemene vorm van het schema hierboven, waarbij het kenmerk is dat er periodes zijn waarin de toediening wel plaatsvindt en periodes waarin deze niet plaatsvindt. Deze periodes wisselen elkaar onderling af, zoals bij een ‘pilschema’: ’21 dagen 1 maal per dag en dan 7 dagen niet’.

Er zijn twee manieren om een dergelijk schema aan te duiden, namelijk door het schema in de periode van toediening te ‘doorsnijden’ met de lengte van de periode of door de periode waarin niet toegediend wordt ervan uit te sluiten. Stel dat sprake is van een cyclisch toedieningsschema voor m dagen mét en n dagen zónder toediening. Dus:

<comp xsi:type="SXPR_TS" operator="A"> {SERIE VAN PERIODIEKE INTERVALLEN VOOR TOEDIENINGSSCHEMA} <comp xsi:type="PIVL_TS" operator="A"> <phase> <low value="{BEGINDATUM PERIODE MET TOEDIENING}"/> <width value="{m}" unit="d" /> </phase> <period value="{m plus n}" unit="d" /> </comp> </comp>

doseerschema op basis van cyclisch schema (op basis van doorsnijding)

medicationAdministrationRequest.routeCode

Formaat:

		
 <routeCode code="…"
            codeSystem="2.16.840.1.113883.2.4.4.9"
            displayName="…"/>

Definitie: De wijze waarop de medicatie moet worden toegediend aan de patiënt.

Het element is optioneel, omdat in veel gevallen de toedieningsweg reeds volledig wordt bepaald door de aard van de voorgeschreven medicatie. Het expliciet doorgeven van de toedieningsweg mág altijd, maar is alleen noodzakelijk als er meerdere mogelijke toedieningswegen zijn, waarvan de voorschrijver of verstrekker er maar één wil toestaan. Gewoonlijk zal klinisch wel altijd een specifieke toedieningsweg worden aangeduid.

Het element <routeCode> is niet herhalend, dus als er meerdere mogelijke toedieningswegen zijn (die expliciet worden doorgegeven), dan moet gebruik worden gemaakt van codes die er meerdere combineren (zoals de G-Standaard die kent). Als echter de doseerhoeveelheid of het doseerschema verschillend zijn per toedieningsweg, dan moet voor elke toedieningsweg een aparte herhaling van het gehele element <medicationAdministrationRequest> zijn opgenomen.

Binnen Nederland moet altijd gebruik worden gemaakt van de G-Standaard tabel voor toedieningswegen, namelijk subtabel 0007 van de thesaurus. De OID van deze tabel is: 2.16.840.1.113883.2.4.4.9. Er gelden een aantal bijzonderheden bij het gebruik:

• Binnen de G-Standaard wordt de code bij thesaurusrecords (veld TSITNR) aangeduid als numeriek met een lengte van 6 cijfers. Binnen HL7 versie 3 worden codes echter altijd als karakterstring uitgewisseld. In overleg met de betrokken leveranciers is besloten om dit bij thesauruscodes te doen zonder voorloopnullen. Dat wil zeggen dat de code voor ‘NASAAL’ (000006 in de G-Standaard) wordt uitgewisseld als ‘6’.
• De codes 000000 (‘TOEDIENINGSWEG NIET INGEVULD’) en 000001 (‘NIET VAN TOEPASSING’) uit subtabel 0007 mogen niet gebruikt worden, aangezien dergelijke concepten binnen HL7v3 worden uitgedrukt met een nullFlavor. Omdat het element echter optioneel is in het bericht, kan het dan beter helemaal worden weggelaten.

XML voorbeeld:

Er wordt een voorschrift uitgeschreven voor een geneesmiddel dat zowel oculair (via het oog), auriculair (via het oor) als nasaal (via de neus) kan worden toegediend. De voorschrijver wil expliciet duidelijk maken dat het in dit geval via het oor moet worden gebruikt. De betreffende toedieningsweg uit de G-Standaard wordt doorgegeven.

<routeCode code="8" codeSystem="2.16.840.1.113883.2.4.4.9" displayName="auriculair"/>

Er wordt bij een klinische MO aangegeven dat toediening zowel intramusculair als intraveneus kan plaatsvinden, al naar gelang de afweging van de arts of verpleger.

<routeCode code="18" codeSystem="2.16.840.1.113883.2.4.4.9" displayName="IM/IV"/>

medicationAdministrationRequest.doseQuantity

Formaat (vaste keerdosis)

<doseQuantity value="…" [ unit="…" ]>
  $translations	
</doseQuantity>

OF

<doseQuantity>
  <center value="…" [ unit="…" ]>
    $translations
  </center>
</doseQuantity>

Formaat (variabele keerdosis):

<doseQuantity>
  [  <low value="…" [ unit="…" ]>
       $translations
     </low>
  ]
  [  <high value="…" [ unit="…" ]>	
       $translations
     </high>
  ]
</doseQuantity>

waarbij minimaal één van de elementen <low> en <high> aanwezig moet zijn.

$translations

<translation value="…" code="…"
             codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
             displayName="…"/>
  [ <translation	value="…" code="…"
            codeSystem="2.16.840.1.113883.2.4.4.1.361"
            displayName="…"/>
 ]

Definitie: De hoeveelheid van de medicatie die per toediening moet worden ingenomen of aangebracht. De juiste interpretatie van deze hoeveelheid hangt direct samen met de aard van de medicatie waarop de toediening betrekking heeft.

Het element <doseQuantity> moet gevuld zijn als er iets te melden is over de keerdosis. Dat is bijna altijd het geval, behalve in de volgende situaties: ‘zo nodig’ medicatie, indien de patiënt (of verpleger bij klinische medicatie) zelf bepaalt welke hoeveelheid van de medicatie nodig is; medicatie waarbij wordt verwezen naar een extern doseerschema, zoals bij ´gebruik bekend´ of ´volgens schema trombosedienst´; medicatie waarvan alleen een periodieke totaaldosis (en geen keerdosis) wordt gemeld, die in <doseCheckQuantity/> wordt doorgegeven.

De doseerhoeveelheid wordt gespecificeerd als een interval van het datatype PQ (physical quantity). Op deze manier kan een onder- en/of een bovengrens worden aangeduid (met <low> en/of <high>) als de dosering variabel is (bijvoorbeeld 1-3 tabletten per keer). Indien sprake is van een vaste dosering (bijvoorbeeld 20 gram per keer), dan wordt dit aangeduid met het <center> element óf wordt er gebruik gemaakt van demotie van het datatype IVL_PQ naar datatype PQ (zie voorbeelden voor formaat).

De primaire eenheid moet afkomstig zijn uit de Unified Codes for Units of Measure (UCUM). Deze lijst met eenheden is wereldwijd geaccepteerd. De lijst met eenheden uit de UCUM is ook opgenomen als HL7 vocabulary domain UnitsOfMeasureCaseSensitive.

Het datatype PQ dat hierbij gebruikt wordt, kan betrekking hebben op een meetbare hoeveelheid van het geneesmiddel (bijvoorbeeld in microgrammen) of op het aantal telbare eenheden (bijvoorbeeld tabletten of inhalaties). HL7v3 hanteert dit als volgt:

• ‘Meetbare’ hoeveelheden worden in overeenkomstige fysieke eenheden uitgedrukt;
• ‘Telbare’ hoeveelheden kennen alleen een aantal met als eenheid '1' (‘units’).

Vooral het feit dat HL7 v3 geen 'telbare' eenheden, zoals tabletten, ondersteunt, leidt soms tot verwarring. De gedachte is dat dit feitelijk geen teleenheden zijn, maar de farmaceutische vorm van de medicatie. Deze is impliciet door de gekozen medicatiecode of kan desgewenst expliciet worden doorgegeven. Op deze manier wordt inconsistentie tussen hoeveelheid en vorm voorkomen. De unit "1" is de default in dergelijke situaties (het betekent dus 'eenheden' en niets meer). Het weglaten van de unit wordt dus geïnterpreteerd als unit="1".

Normaal gesproken zijn alleen de volgende eenheden nodig in de praktijk:

Typische UCUM eenheden

@unit	betekenis	opmerkingen
m	meter	zie voorvoegsels
g	gram	zie voorvoegsels
l	liter	zie voorvoegsels
[drp]	druppel	= 1/12 ml
[tsp_us]	theelepel	= 0.003 l
[tbs_us]	eetlepel	= 0.015 l
[iU]	internationale eenheid	alleen klinisch

Typische UCUM voorvoegsels

voorvoegsel bij @unit	betekenis	omrekenfactor
u	micro	1/1.000.000
m	milli	1/1.000
c	centi	1/100
d	deci	1/10
k	kilo	1.000

Deze voorvoegsels kunnen alleen gebruikt worden in combinatie met m, g en l. De achterliggende gedachte achter het attribuut @unit van het datatype PQ is dat meetbare waarden zoveel mogelijk naar elkaar omgerekend moeten kunnen worden. Het mag dus niets uitmaken of een systeem 2 mg of 0.002 g stuurt als hoeveelheid, omdat het ontvangende systeem in staat moet zijn om te zien dat deze feitelijk hetzelfde zijn. Ontvangende systemen moeten de mogelijke eenheden kunnen omrekenen.

Vaak zijn bij dezelfde medicatie meerdere doseereenheden mogelijk. Bij een tablet met 50 mg werkzame stof kan de doseerhoeveelheid zijn gegeven als: 100 mg per toediening (om te rekenen naar 2 tabletten); 2 tabletten per keer (zonder eenheid in <doseQuantity>). Of een ampul met 2 ml vloeistof met daarin 100 ug werkzame stof per milliliter: 200 ug per toediening (om te rekenen naar 1 ampul); 2 ml per toediening (om te rekenen naar 1 ampul); 1 ampul per keer (zonder eenheid in <doseQuantity>). Uitgangspunt binnen HL7 is dat de juiste interpretatie volgt uit de eenheid in doseQuantity (met default 1) in combinatie met de farmaceutische vorm van de bijbehorende medicatie. Omdat dit niet altijd waterdicht is (denk aan 1 inhalator met 120 doses, die beiden zouden worden uitgedrukt als telbare eenheden), kan daarnaast worden teruggevallen op vertaling naar andere coderingssystemen.

VERTALING NAAR ANDERE CODERINGSSYSTEMEN

Het is verplicht om naast (dus niet in plaats van!) de bovengenoemde UCUM codering van HL7, ook een vertalingdoor te geven naar de G-Standaard basiseenheden (tabel 2 van de thesauraus). Daarnaast kan optioneel een vertaling worden aangeduid naar de eenheden gebruiksadvies (a component) van tabel 25. In beide gevallen wordt gebruik gemaakt van de numerieke codes (doorgegeven zonder voorloopnullen).

De G-Standaard basiseenheden hebben OID 2.16.840.1.113883.2.4.4.1.900.2. De eenheden gebruiksadvies van tabel 25 worden aangeduid door de OID 2.16.840.1.113883.2.4.4.1.361 en worden elders uitgebreid beschreven.

Er is een vaste volgorde van de mogelijke coderingen voor doseereenheden, namelijk eerst de HL7 UCUM eenheden, dan de G-Standaard basiseenheden en dan (optioneel) de tabel 25 a codes. Voor een ontvangend systeem verdient het echter aanbeveling om de codes met omgekeerde prioriteit te verwerken, aangezien ze een steeds specifiekere aanduiding van de dosis mogelijk maken (tabel 25 a codes duiden de farmaceutische vorm van de medicatie aan). Dus: Als er een tabel 25 a code is (en wordt ondersteund), dan die verwerken. Anders de G-Standaard basiseenheid verwerken (verplicht ondersteund). De UCUM unit is opgenomen in het kader van internationale afstemming.

XML voorbeeld:

Het gaat om 100 mg per toediening van de werkzame stof (bijvoorbeeld in een tablet).

<doseQuantity>
  <center value="100" unit="mg">
    <translation value="100" code="229"
                 codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
                 displayName="milligram"/>
  </center>
</doseQuantity>

Er worden 2 eenheden (stuks) per toediening voorgeschreven. De eenheid zou bijv. tablet kunnen zijn, maar ook een sachet met poeder, en is afhankelijk van de farmaceutische vorm van de betreffende medicatie (zie de CMET E_MedicationKindNL).

<doseQuantity>
  <center value="2" unit="1">
    <translation value="2" code="245"
                 codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
                 displayName="stuk"/>
  </center>
</doseQuantity>

Hetzelfde voorbeeld, maar nu met een vertaling naar zowel G-Standaard basiseenheden als eenheden gebruiksadvies van tabel 25 (ervan uitgaande dat het ging om tabletten).

<doseQuantity>
  <center value="2" unit="1">
    <translation value="2" code="245"
       codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
       displayName="stuk"/>
    <translation value="2" code="100"
       codeSystem="2.16.840.1.113883.2.4.4.1.361"
       displayName="tablet"/>
  </center>
</doseQuantity>

Er moeten 2850 Internationale Eenheden van een injectievloeistof worden toegediend. Er wordt een vertaling naar G-Standaard basiseenheden gegeven (tabel 25 kent geen I.E.).

<doseQuantity>
  <center value="2850" unit="[iU]>
    <translation value="2850" unit="217"
       codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
       displayName="internat.eenh."/>
  </center>
</doseQuantity>

Er moeten 1 tot 3 eenheden (bijvoorbeeld tabletten) worden toegediend.

<doseQuantity>
  <low value="1" unit="1">
    <translation value="1" code="245"
       codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
       displayName="stuk"/>
  </low>
  <high value="3" unit="1">
    <translation value="3" code="245"
       codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
       displayName="stuk"/>
  </high>
</doseQuantity>

medicationAdministrationRequest.doseCheckQuantity

Formaat (vaste periodieke dosis):

           <doseCheckQuantity>
             <numerator xsi:type="PQ" value="…" [unit="…"]>
                   $translations
             </numerator>
             <denominator xsi:type="PQ" value="…" unit="…"/>
           </doseCheckQuantity>

Formaat (variabele periodieke dosis):

           <doseCheckQuantity>
             <numerator xsi:type="IVL_PQ">
               [    <low value="…" [ unit="…" ]>	
                   $translations
                    </low>
               ]
               [    <high value="…" [ unit="…" ]>	
                   $translations
                    </high>
               ]
            </numerator>
            <denominator xsi:type="PQ" value="…" unit="…"/>
          </doseCheckQuantity>

waarbij minimaal één van de elementen <low> en <high> aanwezig moet zijn.

Formaat $translations:

            <translation value="…" code="…"
                         codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
                         displayName="…"/>
         [  <translation value="…" code="…"
                         codeSystem="2.16.840.1.113883.2.4.4.1.361"
                         displayName="…"/>
         ]

Dit element is conditioneel aanwezig in het Toedieningsverzoek en wordt alleen gebruikt in situaties waarin geen exact doseerschema bij de medicatie bekend is. Dit kan voorkomen in enkele situaties, waarbij alleen onvolledige informatie beschikbaar is:

• Er wordt een verstrekking gerapporteerd op basis van historische of anderszins onvolledige gegevens, waarbij om wat voor reden dan ook het doseerschema niet is vastgelegd, maar waarbij wel de dag-, week- of andere periodedosering bekend is.
• Er is sprake van een lokale tabel met doseercodes waarbij niet altijd een vertaling naar tabel 25 aanwezig is. Ook dan moet voor de medicatiebewaking een dosering per periode bekend zijn (voorbeeld is code PIL, met 21 tabletten per 28 dagen).
• Er is sprake van een tabel 25 instructie die (nog) niet volledig vertaald kan worden naar een HL7 codering. Een voorbeeld is tabel 25 instructie –D4T 1-2-1, die staat voor “4 tabletten per dag, 1 's morgens, 2 's middags, 1 ’s avonds". Als men deze b code nog niet kan vertalen, dan biedt de benadering ‘4 tabletten per dag’ (dagdosering zonder schema) in ieder geval informatie voor medicatiebewaking.

Als in zo´n geval een dosis per periode valt te bepalen, dan moet dit element gevuld zijn.

Merk op dat het element <doseCheckQuantity> alleen aanwezig hoort te zijn als elders in het bericht geen specifiek doseerschema is aangeduid. Dit betekent dat het element <doseQuantity> (keerdosis) en de herhaalperiode in het element <effectiveTime> (doseerschema) niet aanwezig mogen zijn.

VERTALING NAAR ANDERE CODERINGSSYSTEMEN

Het is verplicht om naast (dus niet in plaats van!) de bovengenoemde UCUM codering van HL7, ook een vertalingdoor te geven naar de G-Standaard basiseenheden (tabel 2 van de thesauraus). Daarnaast kan optioneel een vertaling worden aangeduid naar de eenheden gebruiksadvies (a component) van tabel 25. In beide gevallen wordt gebruik gemaakt van de numerieke codes (doorgegeven zonder voorloopnullen).

De G-Standaard basiseenheden hebben OID 2.16.840.1.113883.2.4.4.1.900.2. De eenheden gebruiksadvies van tabel 25 worden aangeduid door de OID 2.16.840.1.113883.2.4.4.1.361 en worden elders uitgebreid beschreven.

Er is een vaste volgorde van de mogelijke coderingen voor doseereenheden, namelijk eerst de HL7 UCUM eenheden, dan de G-Standaard basiseenheden en dan (optioneel) de tabel 25 a codes. Voor een ontvangend systeem verdient het echter aanbeveling om de codes met omgekeerde prioriteit te verwerken, aangezien ze een steeds specifiekere aanduiding van de dosis mogelijk maken (tabel 25 a codes duiden de farmaceutische vorm van de medicatie aan). Dus: Als er een tabel 25 a code is (en wordt ondersteund), dan die verwerken. Anders de G-Standaard basiseenheid verwerken (verplicht ondersteund). De UCUM unit is opgenomen in het kader van internationale afstemming.

XML voorbeeld:

Er is alleen bekend dat er 4 tabletten per dag gebruikt zijn/worden.

<doseCheckQuantity>
	<numerator xsi:type="PQ" value="4"/>
	<translation value="4" code="245"
	codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
	displayName="stuk"/>
       </numerator>
       <denominator xsi:type="PQ" value="1" unit="d"/>
</doseCheckQuantity>

Er is elke dag 200 tot 400 milligram gebruikt.

<doseCheckQuantity>
	<numerator xsi:type="IVL_PQ">
		<low value="200" unit="mg"/>
                 <translation value="200" code="229"
		 codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
		 displayName="Milligram"/>
		</low>
                <high value="400" unit="mg"/>
                 <translation value="400" code="229"
		 codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
		 displayName="Milligram"/>
		</high>

	</numerator>
	<denominator xsi:type="PQ" value="1" unit="d"/>
</doseCheckQuantity>

Er is bekend dat er gedurende 2 weken 4 tabletten per dag gebruikt zijn/worden.

<medicationAdministrationRequest>
	…
	<effectiveTime xsi:type="IVL_TS">
		<width value="2" unit="wk"/>
	</effectiveTime>
	<doseCheckQuantity>
		<numerator xsi:type="PQ" value="4"/>
                 <translation value="4" code="245"
		 codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
		 displayName="stuk"/>
		</numerator>
		<denominator xsi:type="PQ" value="1" unit="d"/>
	</doseCheckQuantity>
</medicationAdministrationRequest>

Er is sprake van een tabel 25 instructie –D4T 1-2-1.

<medicationAdministrationRequest>
	…
	<doseCheckQuantity>
		<numerator xsi:type="PQ" value="4"/>
  		 <translation value="4" code="245"
		 codeSystem="2.16.840.1.113883.2.4.4.1.900.2"
		 displayName="stuk"/>
		</numerator>
		<denominator xsi:type="PQ" value="1" unit="d"/>
	</doseCheckQuantity>
	<support2>
		<medicationAdministrationInstruction>
			<code code="1170"
 			   codeSystem="2.16.840.1.113883.2.4.4.5"
	      displayName="1 's morgens, 2 's middags, 1 's avonds"/>
		</medicationAdministrationInstruction>
	</support2>			
</medicationAdministrationRequest>

medicationAdministrationRequest.maxDoseQuantity

Het attribuut maxDoseQuantity is optioneel en mogelijk herhalend aanwezig in het toedieningsverzoek en dient om aan te geven welke hoeveelheid van de medicatie maximaal toegediend mag worden over één of meer specifieke periodes. Het <maxDoseQuantity> is niet bedoeld voor een maximale dosering per toediening, deze wordt immers altijd opgenomen in doseQuantity.high. Het element <maxDoseQuantity> is voor doseringen als 'Paracetamol, zo nodig 1 tot 2 stuks, met een maximum van 6 stuks per dag'. Het gegeven '6 per dag' wordt dan doorgegeven met maxDoseQuantity. Dit is vooral relevant bij medicatie met een variabele dosering (1 tot 3 tabletten) en/of een onzeker toedieningsschema (gebruik ‘indien nodig’), om toch veilige grenzen voor toediening aan te kunnen geven.

Er kunnen meerdere periodes worden aangeduid om bijv. aan te geven wat de maximale dosering per dag, per week en per maand is. Dit is nuttig als bijv. een korte piekdosering wel toegestaan is, maar het totale verbruik over een langere periode niet te groot mag zijn.

In de numerator moet een eenheid gebruikt worden die gelijk is aan de eenheid van de keerdosis. Als er bijvoorbeeld in de keerdosis 'stuks' voorgeschreven worden, is de <maxDoseQuantity>.<numerator> ook in 'stuks'. De denominator van <maxDoseQuantity> moet altijd een tijdseenheid zijn.

Formaat (maximale dosis):

        <maxDoseQuantity>
            <numerator xsi:type="PQ" value=".." unit=".."/>
            <denominator xsi:type="PQ" value=".." unit=".."/>
        </maxDoseQuantity>

Gebruik dus de volgende constructies voor maximale dosis: voor de bovengrens van een keerdosis gebruik <doseQuantity>.<high> voor een hoeveelheid per tijdseenheid wanneer geen precieze keerdosis en/of frequentie bekend is, gebruik <doseCheckQuantity>. wanneer de keerdosis variabel is, of niet bekend of gespecificeerd is, maar wel een maximale totale dosering per tijdseenheid bekend is, gebruik <maxDoseQuantity>. wanneer een precieze keerdosis en frequentie bekend is, valt het maximum daaruit af te leiden, en wordt niet apart doorgegeven.

XML voorbeeld:

<medicationAdministrationRequest>
    <text>zo nodig 1 á 2 stuks, maximaal 6 stuks per dag</text>
    <statusCode code="active"/>
    <doseQuantity>
        <low value="1" unit="1">
            <translation value="1" code="245" codeSystem="2.16.840.1.113883.2.4.4.1.900.2" displayName="stuk"/>
        </low>
        <high value="2" unit="1">
            <translation value="2" code="245" codeSystem="2.16.840.1.113883.2.4.4.1.900.2" displayName="stuk"/>
        </high>
    </doseQuantity>
    <maxDoseQuantity>
        <numerator xsi:type="PQ" value="6" unit="1"/>
        <denominator xsi:type="PQ" value="1" unit="d"/>
    </maxDoseQuantity>
    <precondition>
        <observationEventCriterion>
            <code code="1137" codeSystem="2.16.840.1.113883.2.4.4.5" displayName="zo nodig"/>
        </observationEventCriterion>
    </precondition>
</medicationAdministrationRequest>
</therapeuticAgentOf>

medicationAdministrationInstruction

Formaat:

		
 <support2>
   <medicationAdministrationInstruction>
          <code … />
   </medicationAdministrationInstruction>
 </support2>

Definitie: Aanvullende instructies bij het gebruik van de medicatie. Zeker bij ambulante medicatievoorschriften komen dergelijke instructies vaak voor, aangezien de toediening dan in de meeste gevallen door de patiënt zelf plaatsvindt en niet door een zorgverlener.

Deze instructies mogen niet conflictereren met andere onderdelen van het toedieningsverzoek, aangezien anders de gegevensoverdracht niet eenduidig zou zijn. In Nederland wordt in de 1e lijn meestal NHG tabel 25 gebruikt, die in de vorm van de b component (met ‘aanvullende teksten’) allerlei soorten instructies kent, waaronder diverse die overlappen met andere elementen van het informatiemodel voor medicatiegegevens.

Indien de aanvullende instructies van toepassing zijn op de gehele looptijd, waarbinnen er meerdere <medicationAdministrationRequest> elementen zijn (zoals bij een op- of afbouwschema), dan moeten de aanvullende instructies (en bijbehorende <support2> elementen) binnen elk element herhaald worden.

medicationAdministrationInstruction.code

(Onderdeel van medicationAdministrationRequest/support2)

Formaat:

	
   <code code="…" codeSystem="2.16.840.1.113883.2.4.4.5"/>

OF	

   <code nullFlavor="OTH">
        <originalText>…<originalText>	
   </code>

Definitie: Een gecodeerde of tekstuele aanduiding van een aanvullende instructie bij het toedieningsverzoek. In tabel 25 komt dit overeen met de ‘aanvullende teksten’, oftewel de b codes, die dan ook gebruikt moeten worden als codering voor dit element.

Als codering dient de numerieke code uit (een subset van) de b codes uit tabel 25 gekozen te worden. De OID voor de numerieke b codes is: 2.16.840.1.113883.2.4.4.5. De toegestane codes zijn opgenomen in het overzicht in bijlage B.1 van dit document.

Om binnen het element <medicationAdministrationInstruction> de aanvullende gebruiksintructies gecodeerd door te kunnen geven, wordt gebruik gemaakt van een subset van de b codes uit tabel 25. Daarbij worden echter alle codes uitgesloten die ook kunnen worden weergegeven in andere HL7-elementen. Uitgesloten zijn b codes die betrekking hebben op de volgende gegevens: Doseerhoeveelheid (<doseQuantity> en <doseCheckQuantity>); Doseerschema en gebruiksduur (<effectiveTime>); Maximale dosering (<maxDoseQuantity>); Toedieningsweg (<routeCode>). Daarnaast worden alle b codes uitgesloten die betrekking hebben op randvoorwaarden voor gebruik (omdat deze worden doorgegeven in het aparte element <observationEventCriterion>) en alle bewaarinstructies (omdat deze niet relevant zijn binnen de zorgtoepassing Medicatieproces).

Indien geen b code uit tabel 25 bekend is, moet minimaal een tekstuele omschrijving worden doorgegeven. In dat geval wordt het element gevuld met de nullFlavor "OTH", waarbij de tekstuele omschrijving wordt opgenomen in een subelement <originalText>.

XML voorbeeld:

Bij een geneesmiddel in tabletvorm wil de voorschrijver expliciet aanduiden dat het met water moet worden ingenomen. De bijbehorende numerieke tabel 25 b code is ‘1071’.

<support2>
  <medicationAdministrationInstruction>
    <code code="1071" codeSystem="2.16.840.1.113883.2.4.4.5"
          displayName="met water innemen"/>
  <medicationAdministrationInstruction>
<support2>

Bij een voorschrift voor een geneesmiddel (in poedervorm) wil de voorschrijver expliciet aanduiden dat het eerst in water moet worden opgelost en dat de patiënt daarna de mond er mee moet spoelen en het uit moet spugen. De numerieke tabel 25 b codes zijn respectievelijk ‘27’ (‘eerst oplossen in water’) en ‘69’ (‘mond spoelen, daarna uitspugen).

Merk daarbij op dat de hele associatie met <medicationAdministrationInstruction> herhaald wordt en niet alleen het element <code>. Elk van de herhalingen staat immers voor één enkele aanvullende instructie. De volgorde heeft daarbij geen betekenis.

<support2>
  <medicationAdministrationInstruction>
    <code code="27" codeSystem="2.16.840.1.113883.2.4.4.5" 
          displayName="eerst oplossen in water"/>
  </medicationAdministrationInstruction>
</support2>
<support2>
  <medicationAdministrationInstruction>
    <code code="69" codeSystem="2.16.840.1.113883.2.4.4.5" 
          displayName="mond spoelen, daarna uitspugen"/>
  </medicationAdministrationInstruction>
</support2>

Bij een zalf wil de arts aanduiden dat deze dun aangebracht moet worden. Het EVS ondersteunt echter geen codesysteem voor aanvullende gebruiksinstructies. In plaats daarvan wordt de instructie als vrije tekst doorgegeven in een element <originalText>.

<support2>
  <medicationAdministrationInstruction>
    <code nullFlavor="OTH">
      <originalText>dun aanbrengen</originalText>
    </code>
  </medicationAdministrationInstruction>
</support2>

medicationAdministrationInstruction.precondition.observationEventCriterion

(Onderdeel van medicationAdministrationRequest/support2)

Formaat:

			
 <precondition> 
   <observationEventCriterion>
          <code … />
   </observationEventCriterion>
 </precondition>

Definitie: Gebruiksinstructies die betrekking hebben op precondities (randvoorwaarden) voor toediening van de betreffende medicatie. Deze moeten dus gelezen worden als ‘gebruik de medicatie niet, tenzij aan deze voorwaarde is voldaan’.

Verreweg de meest voorkomende variant van een preconditie is het concept ‘zo nodig’. In feite is er daar sprake van een preconditie die niet expliciet benoemd wordt, maar waarvan wordt aangenomen dat de toediener kan inschatten wanneer eraan voldaan is.

Een bijzonder gebruik van ‘zo nodig’ is bij de weergave van een variabele gebruiksfrequentie. Daarbij wordt de instructie “m tot n x daags” omgezet naar “m x daags vast” plus “n-m x daags zo nodig” (variabele deel), opgesplist in twee herhalingen van het element <therapeuticAgentOf>. Meer informatie over deze toepassing is te vinden bij <mAR><effectiveTime> in effectiveTime).

Een variant hierop is als de gebruiksinstructie in z´n geheel ‘zo nodig’ is, én er daarbinnen nog sprake is van een variabele frequentie (bijv. ‘1 tot 2 x daags zo nodig’). Weliswaar is een dergelijke instructie verwarrend, maar met tabel 25 kan deze zeker worden opgebouwd ( ‘zo nodig’ is een aparte b code). In lijn met bovenstaande kan worden opgsplitst in twee herhalingen van <therapeuticAgentOf> , maar deze hebben in dit geval beide een ‘zo nodig’ aanduiding (degene met het variabele deel is als het ware ‘dubbel zo nodig’). Daarom is het ook voldoende om te volstaan met één herhaling, waarin de maximale frequentie (2x daags in het voorbeeld) geheel als ‘zo nodig’ wordt aangeduid. Dit drukt uit dat de instructie equivalent is met ‘0 tot 2 x daags’.

medicationAdministrationInstruction.code.observationEventCriterion.code

(Onderdeel van medicationAdministrationRequest/support2)

Formaat:

	
   <code code="…" codeSystem="2.16.840.1.113883.2.4.4.5"/>

OF

   <code nullFlavor="OTH">
       <originalText>…<originalText>	
   </code>

OF

   <code nullFlavor="NI"/>

Definitie: De gecodeerde of tekstueel aangeduide preconditie waaraan voldaan moet worden voordat gebruik van de betreffende medicatie plaatsvindt. In zijn simpelste (en meest voorkomende) variant bestaat deze preconditie simpelweg uit ‘zo nodig’, maar het kan ook dat specifieker wordt aangegeven wat de randvoorwaarde voor gebruik is.

Als codesysteem worden daarbij de ‘aanvullende teksten’ uit tabel 25 (b component) gebruikt. De OID voor de numerieke tabel 25 b codes is: 2.16.840.1.113883.2.4.4.5. In dit geval dient slechts een subset van de b codes gebruikt te worden, namelijk degene die betrekking hebben op een preconditie voor gebruik. Het betreft de volgende b codes:

Het is ook mogelijk om ‘zo nodig’ door te geven zonder gebruik van een b code, aangezien ‘zo nodig’ feitelijk betekent dat er wel een preconditie is, maar die niet expliciet wordt benoemd (omdat de aanname is dat die bekend is bij de toediener). Daarbij heeft het de voorkeur om de nullFlavor “NI" (geen informate) toe te passen, hoewel ook andere nullFlavors verwerkt moeten worden door ontvangende systemen.

XML voorbeeld:

Twee gelijkwaardige varianten van een basale ‘zo nodig’ aanduiding:

<code code="1137"
      codeSystem="2.16.840.1.113883.2.4.4.5"
      displayName="zo nodig"/>

<code nullFlavor="NI"/>

Bij een voorschrift geeft de voorschrijver expliciet aan dat het alleen moet worden ingenomen bij benauwdheid (dus als de toediener deze klacht zelf constateert).

<code code="1023"
      codeSystem="2.16.840.1.113883.2.4.4.5"
      displayName="bij benauwdheid"/>

Een preconditie die niet volgens tabel 25 gecodeerd kan worden:

<code nullFlavor="OTH">
    <originalText>alleen als het regent</originalText>
</code>

Medicatiesoort

D-MIM:	Pharmacy
HL7v3 gestructureerde naam:	E_MedicationKind NL

Inleiding
De CMET E_MedicationKind NL biedt een universele informatiestructuur voor het doorgeven van een medicatiesoort, die dus op elke plaats gebruikt kan worden waar het nodig is om medicatie te specificeren, zoals binnen een medicatievoorschrift en een medicatieverstrekking. Alle informatie die betrekking heeft op de aard van de medicatie wordt, zoveel mogelijk gecodeerd, weergegeven in het onderstaande model.

De CMET E_MedicationKind NL voldoet minimaal aan de volgende functionele eisen:

• Het is mogelijk om met één enkele code een medicatiesoort aan te duiden, waarbij die code gekozen kan zijn uit meerdere mogelijke coderingssystemen (concreet GPK, PRK, HPK of artikelnummers).
• Het is mogelijk om naast een primaire code ook alternatieve codes uit andere coderingssystemen aan te duiden (zodat bijvoorbeeld de GPK kan worden meegestuurd als is geregistreerd op basis van PRK).
• Het is mogelijk om zowel impliciet te specificeren (door een medicatiecode te gebruiken) als expliciet de samenstelling van de medicatie aan te duiden, bijvoorbeeld door de (actieve) ingrediënt(en) van de medicatie te benoemen.
• Het is mogelijk om magistrale receptuur door te geven. Dit kan door bovenbedoelde mogelijkheid om gecodeerd ingrediënten aan te duiden, aanvullend daarop mag ook de samenstelling en bereidingswijze als vrije tekst doorgegeven worden.

De invulling van deze functionele eisen wordt duidelijk bij de elementen van de CMET.

Merk op dat de definitie van wat wel en niet tot ‘medicatie’ wordt gerekend, aan de nodige discussie onderhevig is. Het is een ontwerpbeslissing dat in ieder geval alle ‘producten’ die op voorschrift verstrekt worden, in scope zijn voor de zorgtoepassing Medicatieproces. Hierbij zijn ook producten (zoals katheters en verbandmiddelen) die strikt genomen geen medicatie zijn. Daarnaast kan de verstrekker zelf bepalen welke andere (niet op voorschrift verstrekte) producten aan de patiënt gekoppeld worden. Daarbij is de uitzondering dat in ieder geval geen zorgregistratieregels (Z productgroepen) mogen worden opgeleverd, ook al zijn die vaak opgeslagen in dezelfde tabel als (feitelijke) verstrekkingen.

G-standaard

In Nederland is sprake van een belangrijk voordeel ten opzichte van veel andere landen door het feit dat er een breed geaccepteerde verzameling stamtabellen voor medicatie en aanverwante kenmerken bestaat in de vorm van de G-Standaard. Uitgangspunt bij de opbouw van het landelijk elektronisch medicatiedossier is dat zoveel mogelijk gebruik wordt gemaakt van de coderingssystemen uit de G-Standaard, zodat weinig discussie te verwachten is over standaardisatie van de codesystemen voor de betreffende gegevens. Met name bij de classificatie van medicatie, waarvoor de CMET E_MedicationKind NL met name bedoeld is, speelt de G-Standaard een belangrijke rol (zie het element <code>).

Voor meer informatie over de G-Standaard verwijzen wij u naar de web site van het bedrijf Z-Index, dat de standaard beheert en distribueert: [www.z-index.nl].

Diagram

Beschrijving

Er is een centrale klasse voor de medicatiesoort (op verschillende niveaus te coderen), optioneel beschreven als een samenstelling van ingrediënten (met name bij magistrale receptuur), waarbij onderscheid gemaakt mag worden tussen actieve en overige ingrediënten. Het is niet verplicht dit onderscheid te maken, in dat geval mogen alle ingrediënten doorgegeven worden als actief ingrediënt.

medicationKind

Formaat:

	
 <MedicationKind>
     <code … />
 [   <desc>…</desc> ]
 [{  <activeIngredient … /> }]
 [{  <otherIngredient … /> }]
 </MedicationKind>

Definitie: Het soort medicatie, waarvoor diverse coderingssystemen gebruikt kunnen worden. Hierdoor kan zowel op generiek niveau (GPK/PRK) als op specifiek niveau (HPK/artikelnummer) worden gespecificeerd. Daarnaast kan een omschrijving worden meegegeven als geen gecodeerde aanduiding (uit de G-Standaard) beschikbaar is.

Voor extra en achtergrondinformatie ga naar Medicatiesoort

medicationKind.code

Formaat:

 	
   <code code="$artikel|$HPK|$PRK|$GPK"
         codeSystem="2.16.840.1.113883.2.4.4.8|7|10|1"
         displayName="…">
   [ {   <translation code="$HPK|$PRK|$GPK"
                      codeSystem="2.16.840.1.113883.2.4.4.7|10|1"
                      [ displayName="…" ] />
   } ]
   </code>

OF

 
   <code nullFlavor="OTH">
         <originalText>…</originalText>
   </code>

waarbij er geen <translation> kan zijn wanneer de primaire code $GPK is. (De vroegere verplichting om een <translation> naar $GPK mee te zenden als de primaire code $PRK is, is vervallen.)

Definitie: De code voor een medicatiesoort, zoals vastgelegd in één van de vier coderingsniveaus uit de G-Standaard. Er kan daarbij worden gekozen uit de volgende

Codesysteem	OID	Omschrijving	Voorbeeld
GPK	2.16.840.1.113883.2.4.4.1	Generieke productcode merkloze aanduiding op basis van de werkzame stof, inclusief de sterkte, de farmaceutische vorm en soms toedieningsweg.	Code: 20664 DIAZEPAM TABLET 5 MG toedieningsweg: ORAAL
PRK	2.16.840.1.113883.2.4.4.10	Voorschrijfcode GPK inclusief extra kenmerken om te zorgen dat alle bij het voorschrijven relevante informatie in één code gevangen wordt (soms ook hulpstoffen).	Code: 7447 DIAZEPAM TABLET 5 MG toedieningsweg: ORAAL bevat hulpstof <xxx>
HPK	2.16.840.1.113883.2.4.4.7	Handelsproductcode GPK inclusief merkaanduiding van een specifieke fabrikant.	Code: 239038 VALIUM TABLET 5MG STESOLID TABLET 5MG
KNMPnummer	2.16.840.1.113883.2.4.4.8	Artikelnummer HPK inclusief aanduiding van specifieke verpakkingsvorm.	Code: 546342 VALIUM TABLET 5MG 5 strip à 10 tablet, 1 verpakking à 50 EAV

Het element <code> heeft datatype CE, hetgeen betekent dat naast een primaire code ook één of meer ‘vertalingen’ ervan kunnen worden opgenomen (uit andere codesystemen). Op deze manier kan naast de code die de voorschrijver heeft geselecteerd of die bij verstrekking is vastgelegd ook de code op één van de meer algemene niveaus worden meegestuurd. Het ontvangende systeem kan zelf bepalen welke van deze codes het meest geschikt is om in de eigen software te verwerken.

De primaire code in het datatype CE moet de meest specifieke aanduiding zijn die in het registrerende systeem is vastgelegd. De vertalingen (element <translation>) in het datatype CE bevatten dan equivalente of meer generieke codes uit andere coderingssystemen, maar nooit meer specifieke codes.

Naast code en codeSystem, is het verplicht dat het attribuut displayName altijd gevuld is voor de primaire code. De reden is dat het voor kan komen dat de ontvanger de code niet kent, maar toch iets op het scherm wil tonen. Deze situatie komt onder andere voor als: De ontvanger iets achterloopt bij het bijwerken van de G-Standaard tabellen, waardoor een bepaalde nieuwe code nog niet bekend is. De ontvanger überhaupt geen gebruik maakt van de G-Standaard, zoals bijvoorbeeld het geval kan zijn bij een patiëntportaal (web interface).

Het element is required, hetgeen betekent dat zowel zender als ontvanger moeten kunnen omgaan met gecodeerde medicatiesoorten. In het geval van magistrale receptuur of andere vormen van eigen bereiding zal meestal geen code uit de G-Standaard beschikbaar zijn (aangezien een zogenaamd 90.000.000 nummer niet wordt gezien als onderdeel van de G-Standaard). Bij magistrale receptuur (eigen bereiding) is het verplicht om: Het element te vullen met de nullFlavor "OTH". Een subelement <originalText> toe te voegen, met daarin een korte omschrijving van de medicatie. Een uitgebreidere beschrijving van samenstelling en bereidingswijze door te geven (zie hiervoor de hiernavolgende elementen). De ingrediënten gecodeerd door te geven. (zie hiervoor de hiernavolgende elementen)

Voor een ontvangend systeem geldt de eis dat elke medicatiecode verwerkt kan worden, ook als die niet bekend is in de eigen versie van de tabel. Dit kan voorkomen als de ontvanger achterloopt met het bijwerken van de tabellen van de G-Standaard, maar ook als bij het opvragen van historie een inmiddels vervallen code wordt opgeleverd (die in de G-Standaard niet meer voorkomt). Er mag dus geen foutmelding gegeven worden als de (primaire) code niet bekend is, maar er moet dan gebruik worden gemaakt van de (verplicht) meegegeven displayName (zie hierboven) om te zorgen dat aan de gebruiker toch een omschrijving getoond kan worden. Bij opslag in de eigen database kan bijvoorbeeld gewerkt worden met een 90.000.000 nummer (net als bij zelf ingevoerde medicatie), zodat toch sprake is van referentiële integriteit.

Merk op dat in het subelement <originalText> geen tekstformattering mag voorkomen, dus ook geen regeleinde, tab stop, en andere opmaakkarakters. De <originalText> moet een korte omschrijving van de betreffende (niet-gecodeerde) medicatie geven, terwijl een uitgebreidere toelichting (van de samenstelling en eventueel bereidingswijze) in het aparte element <desc> komt. Meestal zal een lokaal gedefinieerd 90.000.000 nummer sowieso een korte omschrijving hebben ten behoeve van weergave in overzichten.

XML voorbeeld:

Een voorschrijver schrijft DIAZEPAM TABLET 5 MG voor op het niveau van de GPK.

<code code="20664" codeSystem="2.16.840.1.113883.2.4.4.1"
      displayName="DIAZEPAM TABLET 5 MG"/>

Een voorschrijver schrijft voor op het niveau van de PRK.

<code code="7447" codeSystem="2.16.840.1.113883.2.4.4.10"
      displayName="DIAZEPAM TABLET 5 MG">
</code>

Een voorschrijver schrijft voor op het niveau van de PRK, maar zijn software zorgt er automatisch voor dat ook de bijbehorende GPK meegegeven wordt (n-op-1 relatie).

<code code="7447" codeSystem="2.16.840.1.113883.2.4.4.10"
      displayName="DIAZEPAM TABLET 5 MG">
      <translation code="20664" codeSystem="2.16.840.1.113883.2.4.4.1"/>
</code>

Een voorschrijver schrijft voor op het niveau van de HPK, maar zijn software zorgt er voor dat zowel de bijbehorende PRK als de GPK meegegeven worden (n-op-1 relatie).

<code code="239038" codeSystem="2.16.840.1.113883.2.4.4.7"
      displayName="VALIUM TABLET 5 MG">
      <translation code="7447" codeSystem="2.16.840.1.113883.2.4.4.10"/>
      <translation code="20664" codeSystem="2.16.840.1.113883.2.4.4.1"/>
</code>

Er heeft een verstrekking plaatsgevonden, waarbij een specifiek artikel is geregistreerd. Het apotheeksysteem verzendt het artikelnummer, plus vertalingen naar HPK en PRK.

<code code="546342" codeSystem="2.16.840.1.113883.2.4.4.8"
      displayName="VALIUM TABLET 5 MG">
      <translation code="239038" codeSystem="2.16.840.1.113883.2.4.4.7"/>
      <translation code="20664" codeSystem="2.16.840.1.113883.2.4.4.1"/>
</code>

Er is een voorschrift of een verstrekking die betrekking heeft op zelfbereide medicatie, waarvoor geen standaardcodering binnen de G-Standaard bestaat (90.000.000 nummer).

<code nullFlavor="OTH">
      <originalText>Zelfbereide zinkzalf</originalText>
</code>

medicationKind.desc

Formaat:

	
<desc mediaType="text/plain">...</desc>

Definitie: Een tekstuele beschrijving van de medicatiesoort (inclusief relevante kenmerken van de samenstelling en eventueel de bereidingswijze), die alleen gebruikt wordt als geen gecodeerde aanduiding uit de G-Standaard beschikbaar is (magistrale receptuur). Bij magistrale receptuur is <desc> verplicht gevuld.

Merk op dat in het element <desc> desgewenst ook tekstformattering mag voorkomen, inclusief regeleinde, tab, en andere ‘plain text’ opmaakkarakters. De <desc> geeft een omschrijving van de betreffende (niet-gecodeerde) medicatie, naast een eventuele opsomming van ingrediënten daarvan (zie daarvoor de elementen <activeIngredient> en <otherIngredient>).

Samenvattend:

Het <code> element bevat een code	Het <desc> element niet gebruiken
Het <code> element bevat nullFlavor	Het <desc> element is verplicht om de magistrale receptuur te beschrijven

XML voorbeeld:

Een EVS geeft een magistrale receptuur aan door simpelweg de KNMP artikelnummers van de ingrediënten in tekst op te sommen (en zal daarnaast deze ingrediënten gecodeerd doorgeven in subelementen onder <MedicationKind>).

<desc> KNMPNR 13492497
KNMPNR 14168502
KNMPNR 14284022
KNMPNR 13725793
</desc>

Een door een apotheek verstrekte eigen bereiding wordt als volgt gespecificeerd:

<desc>kalii bromidum 100 mg
 diazepamum 2 mg
 paracetamolum 500 mg
 mfc dtd no 30</desc>

medicationKind.activeIngredient-otherIngredient

Bij magistrale receptuur moeten de ingrediënten meegestuurd worden.

Formaat:

<activeIngredient>
[		<quantity … /> ]
[		<activeIngredientMaterialKind … /> ]
</activeIngredient>

resp.

<otherIngredient>
[    <quantity … /> ]
     <ingredientMaterialKind … />
</otherIngredient>

Waarbij tenminste één van de subelementen aanwezig moet zijn.

Definitie: De ingrediënten van de aangeduide medicatiesoort. De werkzame stoffen worden aangeduid als <activeIngredient> en spelen een bijzondere rol, omdat deze

1. bepalend zijn voor de farmacotherapeutische werking van de medicatie en
2. de basis zijn voor aanduiding van de sterkte van de medicatie (bijv. 200 mg).

Met <otherIngredient> worden hulpstoffen aangeduid die in de medicatie verwerkt zijn.

De volgende regels gelden voor gebruik van <activeIngredient> en <otherIngredient>:

• De medicatiecode geeft de samenstelling van de medicatiesoort volledig weer (dat wil zeggen dat de samenstelling impliciet wordt bepaald door de geselecteerde code), inclusief de werkzame stof en de relatieve hoeveelheid (sterkte) daarvan.

    ⇒ In dat geval moet zowel <activeIngredient> als <otherIngredient> niet gebruikt worden, aangezien deze overbodige informatie bevatten.

• De medicatiecode geeft de samenstelling van de medicatiesoort gedeeltelijk weer, met uitzondering van de relatieve hoeveelheid (sterkte) van de werkzame stof.

    ⇒ Er moet één enkele klasse <activeIngredient> gebruikt worden, met de relatieve hoeveelheid in het <quantity> element.

      Het element hoeft geen <materialKind> als ‘player’ te hebben, aangezien deze stof wel bekend is.

• De medicatiecode is niet gevuld (nullFlavor), in geval van magistrale receptuur.

    ⇒ Alle relevante ingrediënten moeten worden aangeduid.

      De (relatieve) hoeveelheid van elke stof staat in het <quantity> element;

      de betreffende stof is de ‘player’ (en wordt daar bij voorkeur gecodeerd weergegeven).

Het is niet mogelijk een strikte regel aan te geven voor de mate van detail voor de ingrediënten. In het algemeen moet de opsomming (inclusief een eventuele omschrijving in het <medicationKind><desc> element) voldoende zijn voor de apotheker om de medicatie samen te stellen met de samenstelling die de voorschrijver bedoeld heeft.

XML voorbeeld:

Een compleet voorbeeld van magistrale medicatie:

<MedicationKind>
   <code nullFlavor="OTH">
      <originalText>Nafazoline oogdruppels 0,025% ex FNA</originalText>
   </code>
   <desc>
      Titel: Nafazoline oogdruppels 0,025% ex FNA 
      Regel: Naphazolini nitras 25 mg 
      Regel: Boorzuur-benzalk opl FNA ad 100 ml
   </desc>
   <activeIngredient>
      <quantity>
         <numerator xsi:type="PQ" value="25" unit="mg"/>
         <denominator xsi:type="PQ" value="100" unit="ml"/>
      </quantity>
      <activeIngredientMaterialKind>
         <code code="256234" codeSystem="2.16.840.1.113883.2.4.4.7" displayName="NAPHAZOLINI HYDROCHLORIDUM">
            <translation code="30600" codeSystem="2.16.840.1.113883.2.4.4.1" displayName="NAFAZOLINE HYDROCHLORIDE"/>
         </code>
      </activeIngredientMaterialKind>
   </activeIngredient>
   <otherIngredient>
      <!-- Recept wordt aangevuld met hulpstof tot 100 ml, de hoeveelheid van de hulpstof kan dus niet precies gegeven worden, dus geen <quantity>  -->
      <ingredientMaterialKind>
         <code code="261173" codeSystem="2.16.840.1.113883.2.4.4.7" displayName="BOORZUUR-BENZALKONIUMOPLOSSING FNA MR">
            <translation code="24155" codeSystem="2.16.840.1.113883.2.4.4.1" displayName="GRONDSTOF VLOEIBAAR"/>
         </code>
      </ingredientMaterialKind>
   </otherIngredient>
</MedicationKind>

medicationKind.activeIngredient-otherIngredient.quantity

Formaat:

 <quantity>
   <numerator xsi:type="PQ" value="…" [unit="…"]/>
 [ <denominator xsi:type="PQ" value="…" [unit="…"]> ]
 </quantity>

Definitie: De relatieve hoeveelheid van dit ingrediënt in de aangeduide medicatie. Het duidt de relatieve hoeveelheid aan van de ‘player’ van de rol (de stof die als ingrediënt fungeert) per hoeveelheid van de ‘scoper’ (de door de CMET aangeduide medicatie).

Het datatype van dit element is RTO_QTY_QTY. Dit is een ratio (quotiënt) van twee hoeveelheden, die respectievelijk de numerator en de denominator worden genoemd. In XML moet het abstracte datatype QTY worden omgezet in een specialisatie. Dat is in dit geval altijd PQ (physical quantity), zodat xsi:type="PQ" moet worden opgenomen in de numerator en denominator (zie voorbeelden).

De tweede component van het RTO datatype (de denominator) is default 1 als er niets is aangegeven. Dit betekent één eenheid van de farmaceutische vorm van de betreffende medicatie (dit kan alleen bij een telbare vorm, zoals één tablet).

XML voorbeeld:

Bij de ingrediënten van deze siroop (‘scoper’) hoort 200 mg (numerator) van de werkzame stof paracetamol (‘player’) per 200 ml (denominator) van de siroop.

<quantity>
      <numerator xsi:type="PQ" value="200" unit="mg"/>
      <denominator xsi:type="PQ" value="500" unit="ml"/>
</quantity>

Bij de ingrediënten van deze tablet (‘scoper’) hoort 250 mg (numerator) van de werkzame stof (‘player’ niet expliciet genoemd) per eenheid (default denominator).

<quantity>
      <numerator xsi:type="PQ" value="250" unit="mg"/>
</quantity>

Bij de ingrediënten van deze infuusoplossing (‘scoper’) hoort 4 g (numerator) keukenzout (NaCl, ‘player’) per liter (denominator) van de basisvloeistof (= de medicatie als geheel).

<quantity>
      <numerator xsi:type="PQ" value="4" unit="g"/>
      <denominator xsi:type="PQ" value="1" unit="l"/>
</quantity>

De hoeveelheid van de basisstof zelf (zoals bij infuusoplossing) kan worden aangeduid door expliciet bijv. 1 l / 1 l aan te geven. Feitelijk hoeft de hoeveelheid van de basisstof echter niet te worden genoemd, omdat de totaal toe te dienen hoeveelheid blijkt uit de dosering in <medicationAdministrationRequest>.

medicationKind.activeIngredient-otherIngredient.ingredientMaterialKind

(Onderdeel van medicationKind)

Het element <materialKind> wordt gebruikt om een stof of ander materiaal aan te duiden, als ingrediënt van een medicatiesoort. Bij elk relevant ingrediënt hoort een <materialKind> element, behalve als de werkzame stof (<activeIngredient>) wordt bedoeld en de aard van deze stof wordt geïmpliceerd door de medicatiecode. In dat geval wordt de ActiveIngredient klasse alleen gebruikt om de sterkte van deze ‘impliciete materiaalsoort’ in de medicatie aan te duiden.

Indien mogelijk moet de materiaalsoort met een code worden aangeduid, maar als geen code beschikbaar is kan ook de nullFlavor ”OTH” met <originalText> worden gebruikt.

medicationKind.activeIngredient-otherIngredient.ingredientMaterialKind.code

Formaat:

   <code code="$artikel|$HPK|$PRK|$GPK|$ATC"
         codeSystem=
           "2.16.840.1.113883.2.4.4.8|7|10|1" | "2.16.840.1.113883.6.73"
         displayName="…">
   [{    <translation code="$HPK|$PRK|$GPK|$ATC"
                      codeSystem=
           "2.16.840.1.113883.2.4.4.8|7|10|1" | "2.16.840.1.113883.6.73"
                      [ displayName="…" ] />
   } ]
   </code>

OF

   <code nullFlavor="OTH">
         <originalText>…</originalText>
   </code>

waarbij er geen <translation> kan zijn wanneer de primaire code $ATC is.

Definitie: Gecodeerde aanduiding voor de materiaalsoort (type stof) die als ingrediënt fungeert. De primaire code in het CE datatype moet de code zijn die door de persoon of het systeem dat de samenstelling van de medicatie specificeert is bepaald. Eventuele <translation> elementen zijn equivalente of meer algemene alternatieve coderingen.

Bij de bepaling van mogelijke coderingen wordt de vrijheid gevolgd die geldt binnen de EDIFACT koppeling van OZIS. Dat wil zeggen dat naast het KNMP artikelnummer (meest specifieke niveau), ook HPK, PRK of GPK mogen worden toegepast (analoog aan het aanduiden van de medicatie als geheel).

Voorschriftquery

D-MIM:	Pharmacy
HL7v3 gestructureerde naam:	Medication Combined Order Query

Diagram

Figuur 8 QURX_RM990001NL - R-MIM diagram

Beschrijving

Deze query is bedoeld om selectiecriteria te specificeren voor het opvragen van medicatievoorschriften bij een voorschrijvend systeem. Het uitgangspunt is dat één of meer criteria worden benoemd waarop een voorschrijvend systeem een selectie moet kunnen maken uit de binnen het systeem gegenereerde en vastgelegde voorschriften.

In de context van AORTA is de parameter op basis van patiëntnummer verplicht.

Hierarchical Message Description

<queryByParameter>	Querybody
[ <administrationRequestEffectiveTimeInterval> ]	Beoogde toedieningsperiode(s)
[ <medicationCombinedOrderID> ]	Voorschriftnummer
<patientID>	Patiëntnummer

Voorschriftquery.queryByParameter.administrationRequestEffectiveTimeInterval

Deze parameter kan gebruikt worden om een gebruiksinterval door te geven van de voorgeschreven medicatie. Alle geretourneerde voorschriften hebben betrekking op medicatie die (voor zover dat afleidbaar is uit de voorschriftgegevens) binnen deze periode is gebruikt of zal worden gebruikt. Dit is geen waterdicht criterium:

De beoogde gebruiksperiode van een medicatievoorschrift (zelfs als de verstrekking reeds heeft plaatsgevonden) kent vaak een flinke mate van onzekerheid in de ambulante setting. Zo is vaak niet zeker wanneer de patiënt precies met het gebruik zal beginnen en wordt veel medicatie verstrekt op basis van een ‘zo nodig’ dosering, die betekent dat deze tot aan de maximale houdbaarheidsdatum in gebruik kan zijn. Het is bij het afhandelen van een Voorschriftquery aan het antwoordende systeem welk algoritme wordt toegepast om de beoogde gebruiksperiode van de opgeslagen voorschriften te bepalen. Als de vrager niet afhankelijk wil zijn van het algoritme dat het antwoordende systeem hiertoe gebruikt (en dat de vrager meestal niet kent), dan wordt deze query parameter bij voorkeur niet gebruikt, maar moet de vrager zelf filteren in de geretourneerde voorschriftgegevens.

Als dit criterium gebruikt wordt om te filteren welke voorschriften relevant zijn in het kader van de medicatiebewaking, dan is niet alleen de beoogde gebruiksperiode, maar ook de zogenaamde ‘interactierelevantieperiode’ van belang. De interactierelevantieperiode geeft aan hoe lang na het beëindigen van de toediening de medicatie nog interacties kan hebben met andere medicatie of bepaalde condities. Op basis van de medicatiecode is afleidbaar hoe lang de interactierelevantieperiode is, zodat de ontvanger daar zelf rekening mee kan houden. Het is niet wenselijk dat een antwoordend systeem deze marge reeds incalculeert bij interpretatie van <administrationRequestEffectiveTimeInterval>.

Voorschriftquery.queryByParameter.administrationRequestEffectiveTimeInterval.value

Formaat:

<value>
[ <low	value="YYYYMMDD0000"/> ]	
[ <high value="YYYYMMDD2359"/> ]
</value>

waarbij minimaal één van de elementen <low> en <high> aanwezig moet zijn.

Definitie: Een tijdsinterval dat betrekking heeft op de periode waarin medicatiegebruik op basis van de gezochte voorschriften zal plaatsvinden of heeft plaatsgevonden. Om misverstanden over de interpretatie van de einddatum (<high>) te voorkomen, is het verplicht om bij onder- en bovengrens respectievelijk de vaste tijden "0000" en "2359" toe te voegen achter de datum (zodat duidelijk is dat ‘tot en met’ wordt bedoeld).

XML voorbeeld:

Opvragen van de medicatievoorschriften waarvan de medicatie (voor zover dit is af te leiden uit het voorschrift) op 12 maart 2008 gebruikt werd (interval met breedte 1 dag).

<value>
   <low value="200803120000"/>
   <high value="200803122359"/>
</value>

Opvragen van de medicatievoorschriften waarvan de medicatie (voor zover dit is af te leiden uit het voorschrift) op of na vandaag gebruikt wordt (ofwel: ‘actuele medicatie’).

<value>
   <low value="201011190000"/>
</value>

Voorschriftquery.queryByParameter.medicationCombinedOrderID

Deze parameter kan gebruikt worden om een specifiek medicatievoorschrift op te zoeken op basis van het bijbehorende unieke voorschriftnummer (zoals uitgegeven door het bronsysteem). Deze parameter is bijvoorbeeld nodig als een serie verstrekkingen is opgevraagd via het LSP (met daarin referenties naar de bijbehorende voorschriften) en men wil detailgegevens opvragen van de medicatievoorschriften bij deze verstrekkingen.

Weliswaar hoort elk medicatievoorschrift bij één specifieke patiënt, maar toch moet als de parameter <medicationCombinedOrderID> gebruikt wordt evengoed de parameter <patientID> worden meegegeven. De reden hiervoor is dat het LSP de autorisatie alleen checkt op basis van het gevraagde BSN.

Voorschriftquery.queryByParameter.medicationCombinedOrderID.value

Formaat:

 <value root="…" extension="…"/>

Definitie: De unieke identifier van een specifiek medicatievoorschrift dat gezocht wordt.

Let op dat in het datatype II zowel de extension (de unieke identificatie van het voorschrift binnen een bepaald identificatiesysteem) als de root (de unieke identificatie van dat identificatiesysteem zelf) moeten worden aangegeven.

XML voorbeeld:

Opvragen van het medicatievoorschrift met nummer ‘0012462311’, zoals toegekend door het EPD-systeem van een bepaald ziekenhuis. Het vragend systeem kan dit nummer uit een andere bron hebben verkregen en zo de detailgegevens van dit voorschrift opvragen.

<value root="2.16.840.1.113883.2.4.6.1.6005432.2.8.1" extension="0012462311"/>

Voorschriftquery.queryByParameter.patientID

Deze parameter wordt gebruikt om medicatievoorschriften op te zoeken die betrekking hebben op een specifieke patiënt, die wordt geïdentificeerd door middel van diens BSN.

De bedrijfsregels voor het Landelijk Schakelpunt (LSP) bepalen dat deze parameter altijd gevuld dient te zijn bij queries naar het LSP. Dit om te garanderen dat per query bepaald kan worden of de opvragende partij voldoende geautoriseerd is (voor gegevens van de betreffende patiënt).

Voorschriftquery.queryByParameter.patientID.value

Formaat:

<value root="2.16.840.1.113883.2.4.6.3" extension="$BSN"/>

Definitie: Het burgerservicenummer (BSN) dat de gezochte patiënt uniek identificeert. Het is niet mogelijk om via het LSP gegevens op te vragen op basis van lokale patiëntnummers.

Let op dat in het datatype II zowel de extension (de unieke identificatie van de patiënt binnen een bepaald identificatiesysteem) als de root (de unieke identificatie van dat identificatiesysteem zelf) moet worden aangegeven.

XML voorbeeld:

Opvragen van voorschriften van de patiënt met landelijk BSN “562632643".

<value root="2.16.840.1.113883.2.4.6.3" extension="562632643"/>

Verstrekkingsquery

D-MIM:	Pharmacy
HL7v3 gestructureerde naam:	Medication Dispense Event Query

Diagram

Figuur 9 QURX_RM990011NL - R-MIM diagram

Beschrijving

Deze query is bedoeld om selectiecriteria te specificeren voor het opvragen van medicatieverstrekkingen bij een verstrekkend systeem. Het uitgangspunt is dat één of meer criteria worden benoemd waarop een verstrekkend systeem een selectie moet kunnen maken uit de binnen het systeem gegenereerde en vastgelegde verstrekkingen.

In de context van AORTA is de parameter op basis van patiëntnummer verplicht.

Hierarchical Message Description

<queryByParameter>	Querybody
[ <administrationRequestEffectiveTimeInterval> ]	Beoogde toedieningsperiode(s)
[ <dispenseEventEffectiveTimeInterval>	Verstrekkingsperiode(s)
[ <mostRecentDispenseForEachRxIndicator> ]	Laatste verstrekking per voorschrift?
<patientID>	Patiëntnummer

Verstrekkingsquery.queryByParameter.administrationRequestEffectiveTimeInterval

Deze parameter kan gebruikt worden om een gebruiksinterval door te geven van de verstrekte medicatie. Alle geretourneerde verstrekkingen hebben betrekking op medicatie die (voor zover dat afleidbaar is uit de gebruiksvoorschriften) binnen deze periode is gebruikt of zal worden gebruikt. Dit is geen waterdicht criterium:

De beoogde gebruiksperiode van een medicatievoorschrift (zelfs als de verstrekking reeds heeft plaatsgevonden) kent vaak een flinke mate van onzekerheid in de ambulante setting. Zo is vaak niet zeker wanneer de patiënt precies met het gebruik zal beginnen en wordt veel medicatie verstrekt op basis van een ‘zo nodig’ dosering, die betekent dat deze tot aan de maximale houdbaarheidsdatum in gebruik kan zijn. Het is bij het afhandelen van een Verstrekkingsquery aan het antwoordende systeem welk algoritme wordt toegepast om de beoogde gebruiksperiode van de opgeslagen verstrekkingen te bepalen. Als de vrager niet afhankelijk wil zijn van het algoritme dat het antwoordende systeem hiertoe gebruikt (en dat de vrager meestal niet kent), dan wordt deze query parameter bij voorkeur niet gebruikt, maar moet de vrager zelf filteren in de geretourneerde resultaatset.

Als dit criterium gebruikt wordt om te filteren welke verstrekkingen relevant zijn in het kader van de medicatiebewaking, dan is niet alleen de beoogde gebruiksperiode, maar ook de zogenaamde ‘interactierelevantieperiode’ van belang. De interactierelevantieperiode geeft aan hoe lang na het beëindigen van de toediening de medicatie nog interacties kan hebben met andere medicatie of bepaalde condities. Op basis van de medicatiecode is afleidbaar hoe lang de interactierelevantieperiode is, zodat de ontvanger daar zelf rekening mee kan houden. Het is niet wenselijk dat een antwoordend systeem deze aanvullende marge reeds incalculeert bij de interpretatie van de queryparameter <administrationRequestEffectiveTimeInterval>.

Verstrekkingsquery.queryByParameter.administrationRequestEffectiveTimeInterval.value

Formaat:

		
 <value>
 [   <low value="YYYYMMDD0000"/> ]	
 [   <high value="YYYYMMDD2359"/> ]
 </value>
waarbij minimaal één van de elementen <low> en <high> aanwezig moet zijn.

Dit bestaat uit een tijdsinterval dat betrekking heeft op de periode waarin medicatiegebruik op basis van de gezochte verstrekkingen zal plaatsvinden of heeft plaatsgevonden. Om misverstanden over de interpretatie van de einddatum (<high>) te voorkomen, is het verplicht om bij onder- en bovengrens “0000" respectievelijk “2359" toe te voegen aan de datum (zodat duidelijk is dat ‘tot en met’ wordt bedoeld).

XML voorbeeld:

Opvragen van de medicatieverstrekkingen waarvan de medicatie (voor zover dit is af te leiden uit het voorschrift) op 12 maart 2008 gebruikt werd (interval met breedte 1 dag).

<value>
   <low value="200803120000"/>
   <high value="200803122359"/>
</value>

Opvragen van de medicatieverstrekkingen waarvan de medicatie (voor zover dit is af te leiden uit het voorschrift) op of na vandaag gebruikt wordt (ofwel: ‘actuele medicatie’).

<value>
   <low value="201011190000"/>
</value>

Verstrekkingsquery.queryByParameter.dispenseEventEffectiveTimeInterval

Deze parameter kan gebruikt worden om alle medicatieverstrekkingen op te zoeken die zijn uitgevoerd binnen een bepaalde periode (tijdsinterval). Het gaat hier dus om het moment van uitvoeren van de verstrekkingen en niet om de verwachte gebruiksperiode van de voorgeschreven medicatie (zie voor de queryparameter op de gebruiksperiode <administrationRequestEffectiveTimeInterval>).

Verstrekkingsquery.queryByParameter.dispenseEventEffectiveTimeInterval.value

Formaat:

		
 <value> 
 [    <low value="YYYYMMDD0000"/> ]	
 [    <high value="YYYYMMDD2359"/> ]
 </value>

waarbij minimaal één van de elementen <low> en <high> aanwezig moet zijn.

Dit bestaat uit een tijdsinterval dat betrekking heeft op de periode waarin de verstrekkingen hebben plaatsgevonden. Om misverstanden over de interpretatie van de einddatum (<high>) te voorkomen, is het verplicht om bij onder- en bovengrens “0000" respctievelijk “2359" toe te voegen (zodat duidelijk ‘tot en met’ wordt bedoeld).

XML voorbeeld:

Opvragen van de medicatieverstrekkingen die vanaf 2009 zijn uitgevoerd.

<value>	
    <low value="200901010000"/>
</value>

Verstrekkingsquery.queryByParameter.mostRecentDispenseForEachRxIndicator

Deze parameter kan gebruikt worden om aan te geven dat per medicatievoorschrift alleen de chronologisch laatste verstrekking moet worden geretourneerd. Dit is dus een wezenlijk ander type parameter dan de andere, omdat hiermee een ‘vlag’ wordt gezet, in plaats van het doorgeven van specifieke filterwaarden waarop geselecteerd moet worden.

Deze parameter is met name ingevoerd om te zorgen dat er geen wildgroei aan opgeleverde verstrekkingen ontstaat bij zogenaamde Baxter-leveringen. Dit zijn situaties waarbij op basis van een lopend medicatievoorschrift zeer veel kleine deelverstrekkingen plaatsvinden (bijvoorbeeld met een dag- of weekdosis). Dit gebeurt met name in semi-klinische situaties, zoals een verpleeg- of verzorghuis.

Deze parameter kan vanzelfsprekend alleen worden toegepast indien het verwerkende systeem kennis heeft van de relatie tussen verstrekkingen en bijbehorende voorschriften. Als van een verstrekking niet bekend is bij welk voorschrift(nummer) het hoort, dan moet deze verstrekking in ieder geval gerapporteerd worden. Als het voorschrift wel bekend is (en de parameter is op ”true” gezet), dan wordt de verstrekking alleen gerapporteerd indien het de meest recente verstrekking bij het voorschrift is.

Verstrekkingsquery.queryByParameter.mostRecentDispenseForEachRxIndicator.value

Formaat:

 <value value=”false|true”/>

Dit is een logische waarde en bevat dus “true” of “false”. Als het element <mostRecentDispenseForEachRxIndicator> niet wordt meegegeven, is de default waarde “false”.

Als expliciet “true” als <value> wordt meegegeven, dan wordt per medicatievoorschrift (voor zover bekend) dus alleen de chronologisch laatste verstrekking geretourneerd.

XML voorbeeld:

Opvragen van de laatste verstrekking per voorschrift.

<value value="true"/>

Verstrekkingsquery.queryByParameter.patientID

Deze parameter wordt gebruikt om medicatieverstrekkingen te selecteren die betrekking hebben op een specifieke patiënt, die wordt geïdentificeerd door middel van diens BSN.

De bedrijfsregels voor het Landelijk Schakelpunt (LSP) bepalen dat deze parameter altijd gevuld dient te zijn bij queries naar het LSP. Dit om te garanderen dat per query bepaald kan worden of de opvragende partij voldoende geautoriseerd is (voor gegevens van de betreffende patiënt).

Verstrekkingsquery.queryByParameter.patientID.value

Formaat:

	
 <value root="2.16.840.1.113883.2.4.6.3" extension="$BSN"/>

Definitie: Een burgerservicenummer (BSN) dat de gezochte patiënt uniek identificeert. Het is niet mogelijk om via het LSP gegevens op te vragen op basis van lokale patiëntnummers.

Let op dat in het datatype II zowel de extension (de unieke identificatie van de patiënt binnen een bepaald identificatiesysteem) als de root (de unieke identificatie van dat identificatiesysteem zelf) moet worden aangegeven.

XML voorbeeld:

Opvragen van verstrekkingen van de patiënt met landelijk BSN "562632643".

<value root="2.16.840.1.113883.2.4.6.3" extension="562632643"/>

Medicatievoorschriftenlijst

D-MIM:	Pharmacy
HL7v3 gestructureerde naam:	Medication Prescription List

Diagram

Figuur 10 PORX_RM924100NL - R-MIM diagram

Beschrijving

De medicatievoorschriftenlijst is geïntroduceerd als efficiënter mechanisme voor het opleveren van voorschriften door een bronsysteem. Bij de traditionele bevraging was sprake van een serie voorschriften als payloads van de query response, waarbij in elk van deze voorschriften de patiënt herhaald werd (als verplicht onderdeel van het model voor het medicatievoorschrift), soms zelfs met diverse (optionele) patiëntgegevens.

In het model van de medicatievoorschriftenlijst is er de klasse MedicationPrescriptionList, waaraan enerzijds de patiënt gekoppeld is (met CMET R_PatientNL [universal]) en anderzijds een serie voorschriften (met CMET A_MedicationCombinedOrderNL, waarin de patiënt een optioneel onderdeel is en in dit geval dus kan worden weggelaten). Zo wordt een lijst van alle relevante medicatievoorschriften voor deze patiënt doorgegeven.

Hierarchical Message Description

<MedicationPrescriptionList>	Medicatievoorschriftenlijst
<subject><Patient>	Patiënt
[{ <component><Prescription>	Medicatievoorschrift
<subject><Patient>	Patiënt
<author><AssignedPerson>	Voorschrijvende arts
<directTarget><prescribedMedication>] <MedicationKind>	Voorgeschr. medicatie
[{ <activeIngredient> [ <activeIngredientMaterialKind> ] }]	Werkzame stof
[{ <otherIngredient><ingredientMaterialKind> }]	Overige ingrediënt
[ <productOf><medicationDispenseRequest>	Verstrekkingsverzoek
[ <performer><assignedPerson> <representedOrganization>>	Beoogde verstrekker
]
]
{ <therapeuticAgentOf><medicationAdministrationRequest>	Toedieningsverzoek
[{ <support2><medicationAdministrationInstruction> }]	Gebruiksinstructie
[{ <precondition><observationEventCriterion> }]	Randvoorwaarde
}
[ <reason><diagnosisEvent> ]	Voorschrijfreden
}

medicationPrescriptionList

Formaat:

	
 <MedicationPrescriptionList>
     <subject … />
 [{  <component … /> } ]
 </MedicationPrescriptionList>

Definitie: De lijst met medicatievoorschriften die wordt gerapporteerd. Deze lijst zorgt ervoor dat de patiënt slechts één keer hoeft te worden aangeduid (per lijst), terwijl eronder een verzameling medicatievoorschriften van die patiënt opgenomen is.

Per <MedicationPrescriptionList> moet precies één patiënt worden doorgegeven met de CMET R_PatientNL [universal]. De lijst medicatievoorschriften kan ook leeg zijn en heeft geen maximale lengte. Elk medicatievoorschrift wordt weergegeven met de CMET A_MedicationCombinerOrderNL, die in dit document in detail wordt beschreven.

Indien bij een bevraging geen voorschriften voldoen aan de opgegeven criteria, dan kan toch een <MedicationPrescriptionList> worden opgeleverd, die echter geen componenten heeft. Dit betekent dat bij een dergelijke query de aanwezigheid van een payload niet betekent dat er ook echt iets ‘gevonden’ is.

Voor extra en achtergrondinformatie zie Medicatievoorschriftenlijst

medicationPrescriptionList.code

Formaat:

	
 <code codeSystem="2.16.840.1.113883.5.4" code="MEDLIST"/>

Definitie: Code uit het HL7v3-codesysteem ActCode, die aangeeft dat het betreffende element een lijst met medicaties is. Op een dergelijke lijst zouden zowel medicatievoorschriften, -verstrekkingen, -toedieningen als zogenaamde ‘medication statements’ kunnen staan. In dit geval is dat een lijst met medicatievoorschriften (van één patiënt).

medicationPrescriptionList.subject

Zie voor de CMET R_PatientNL [universal] de [HL7v3 IH Basis].

Elke medicatievoorschriftenlijst heeft één specifieke patiënt als onderwerp.

In de CMET R_PatientNL [universal] zijn geen verplichte elementen behalve het patiëntnummer. In deze context zijn er echter enkele specifieke kenmerken: Het patiëntnummer (<Patient><id>) is altijd een BSN. Er moet een (familie)naam van de patiënt gevuld zijn. De geboortedatum van de patiënt moet gevuld zijn. Het geslacht van de patiënt moet aangeduid zijn. De reden om de aanvullende patiëntgegevens naast het BSN door te geven, ligt in de mogelijkheid om daarmee de identiteit extra te kunnen controleren.

XML voorbeeld:

Er wordt een voorschriftenlijst opgevraagd met voorschriften voor patiënt mevr. Bette Freriks-van Weezel, geboren op 10 december 1973, met BSN-nummer 042715231.

<subject>
   <Patient>
        <id root="2.16.840.1.113883.2.4.6.3" extension="042715231"/>
        <statusCode code="active"/>
        <Person>
            <name>
                <given qualifier="BR">Bette</given>
                <family qualifier="SP">Freriks</family>
                <prefix qualifier="VV">van </prefix>
                <family qualifier="BR">Weezel</family>
            </name>
            <administrativeGenderCode code="F"
                codeSystem="2.16.840.1.113883.5.1"/>
            <birthTime value="19731210"/>
       </Person>
   </Patient>
</subject>

medicationPrescriptionList.component

Formaat:

		
<component>
  <prescription … />  
</component>

Het element <component> bevat de afzonderlijke medicatievoorschriften die onderdeel zijn van de opgeleverde lijst. De medicatievoorschriften zitten als subelement binnen de CMET A_MedicationCombinedOrderNL, waarbinnen in dit geval geen patiënt voorkomt (omdat die impliciet bekend is door de patiënt die aan de lijst als geheel is gekoppeld).

Het element <component> kan herhaald voorkomen binnen één voorschriftenlijst. Deze herhaling heeft altijd betrekking op dezelfde patiënt, maar duidt telkens een ander medicatievoorschrift aan (van een bepaalde medicatie, door een bepaalde voorschrijver).

Zie voor details van de medicatievoorschriften de CMET A_MedicationCombinedOrderNL.

Medicatieverstrekkingenlijst

D-MIM:	Pharmacy
HL7v3 gestructureerde naam:	Medication Dispense List

Diagram

Beschrijving
De medicatieverstrekkingenlijst is geïntroduceerd als efficiënter mechanisme voor het opleveren van verstrekkingen door een bronsysteem. Bij de traditionele bevraging was sprake van een serie verstrekkingen als payloads van de query response, waarbij in elk van deze verstrekkingen de patiënt herhaald werd (als verplicht onderdeel van het model voor de medicatieverstrekking), soms zelfs met diverse (optionele) patiëntgegevens.

In het model van de medicatieverstrekkingenlijst is er de klasse MedicationDispenseList, waaraan enerzijds de patiënt gekoppeld is (met CMET R_PatientNL [universal]) en anderzijds een serie verstrekkingen (met CMET A_MedicationAdministrationRequestNL, waarin de patiënt een optioneel onderdeel is en in dit geval dus kan worden weggelaten). Zo wordt een lijst van alle relevante medicatieverstrekkingen voor deze patiënt doorgegeven.

Hierarchical Message Description

<medicationDispenseList>	Medicatieverstrekkinglijst
<subject><Patient>	Patiënt
[{ <component><medicationDispenseEvent>	Medicatieverstrekking
<performer><assignedPerson>	Verstr. medewerker
<product><dispensedMedication><MedicationKind>	Verstrekte medicatie
[{ <activeIngredient> [ <activeIngredientMaterialKind> ] }]	Werkzame stof
[{ <otherIngredient><ingredientMaterialKind> }]	Andere ingrediënt
<directTargetOf> <prescription>	Medicatievoorschrift
[ <author> <AssignedPerson> ]	Voorschrijvende arts
{ <therapeuticAgentOf><medicationAdministrationRequest>	Toedieningsverzoek
[{ <support2><medicationAdministrationInstruction> }]	Gebruiksinstructie
[{ <precondition> <observationEventCriterion> }]	Randvoorwaarde
}
<responsibleParty> <assignedCareProvider>	Verantw. zorgverlener
<representedOrganization>	Verantw. zorginstelling

medicationDispenseList

Formaat:

		
 <MedicationDispenseList>
     <subject … />
 [ {	<component … /> } ]
 </MedicationDispenseList>

Definitie: De lijst met medicatieverstrekkingen die wordt gerapporteerd. Deze lijst zorgt ervoor dat de patiënt slechts één keer hoeft te worden aangeduid (per lijst), terwijl eronder een verzameling medicatieverstrekkingen van die patiënt opgenomen is.

Per <MedicationDispenseList> moet precies één patiënt worden doorgegeven met de CMET R_PatientNL [universal]. De lijst medicatieverstrekkingen kan ook leeg zijn en heeft geen maximale lengte. Elke medicatieverstrekking wordt weergegeven met de CMET A_MedicationDispenseEventNL, die in dit document in detail wordt beschreven.

Indien bij een bevraging geen verstrekkingen voldoen aan de opgegeven criteria, dan kan toch een <MedicationDispenseList> worden opgeleverd, die echter geen componenten heeft. Dit betekent dat bij een dergelijke query de aanwezigheid van een payload niet betekent dat er ook echt iets ‘gevonden’ is.

Voor extra en achtergrondinformatie zie Medicatieverstrekkingenlijst

medicationDispenseList.code

Formaat:

	
 <code codeSystem="2.16.840.1.113883.5.4" code="MEDLIST"/>

Definitie: Code uit het HL7 codesysteem ActCode, die aangeeft dat het betreffende element een lijst met medicaties is. Op een dergelijke lijst zouden zowel medicatievoorschriften, -verstrekkingen, -toedieningen als zogenaamde ‘medication statements’ kunnen staan. In dit geval is dat een lijst met medicatieverstrekkingen (van één patiënt).

medicationDispenseList.subject

Zie voor de CMET R_PatientNL [universal] de [HL7v3 IH Basis].

Elke medicatieverstrekkingenlijst heeft één specifieke patiënt als onderwerp.

In de CMET R_PatientNL [universal] zijn geen verplichte elementen behalve het patiëntnummer. In deze context zijn er echter enkele specifieke kenmerken: Het patiëntnummer (<Patient><id>) is altijd een BSN. Er moet een (familie)naam van de patiënt gevuld zijn. De geboortedatum van de patiënt moet gevuld zijn. Het geslacht van de patiënt moet aangeduid zijn. De reden om de aanvullende patiëntgegevens naast het BSN door te geven, ligt in de mogelijkheid om daarmee de identiteit extra te kunnen controleren.

XML voorbeeld:

Er wordt een verstrekkingenlijst opgevraagd met verstrekkingen aan patiënt mevr. Bette Freriks-van Weezel, geboren op 10 december 1973, met BSN-nummer 042715231.

<subject>
    <Patient>
         <id root="2.16.840.1.113883.2.4.6.3" extension="042715231"/>
         <statusCode code="active"/>
         <Person>
             <name>
                 <given qualifier="BR">Bette</given>
                 <family qualifier="SP">Freriks</family>
                 <prefix qualifier="VV">van </prefix>
                 <family qualifier="BR">Weezel</family>
             </name>
             <administrativeGenderCode code="F"
                             codeSystem="2.16.840.1.113883.5.1"/>
             <birthTime value="19731210"/>
        </Person>
    </Patient>
</subject>

medicationDispenseList.component

Formaat:

	
 <component>
   <medicationDispenseEvent … /> 
 </component>

Het element <component> bevat de afzonderlijke medicatieverstrekkingen die onderdeel zijn van de opgeleverde lijst. De medicatieverstrekkingen zitten als subelement binnen de CMET A_MedicationDispenseEventNL, waarbinnen in dit geval geen patiënt voorkomt (omdat die impliciet bekend is door de patiënt die aan de lijst als geheel is gekoppeld).

Het element <component> kan herhaald voorkomen binnen één verstrekkingenlijst. Deze herhaling heeft altijd betrekking op dezelfde patiënt, maar duidt telkens een andere medicatieverstrekking aan (van een bepaalde medicatie, door een bepaalde apotheek).

Zie voor details van de medicatieverstrekkingen de CMET A_MedicationDispenseEventNL.

Aanmelden gegevens

Inleiding

In het kader van de zorgtoepassing Medicatieproces zijn vooralsnog twee zogenaamde gegevenssoorten relevant, namelijk medicatievoorschriften en -verstrekkingen. Deze gegevenssoorten zijn gerelateerd aan de twee typen queries (opvraaginteracties) die beschreven zijn in de HL7v3-implementatiehandleiding voor Medicatieproces (en waarvan de bijbehorende payloadmodellen worden besproken in dit document). Elk van deze queries is bedoeld voor het opvragen van één van de beide gegevenssoorten. Dat wil zeggen dat via de ZIM de aangemelde XIS-en worden bevraagd voor brongegevens.

Medicatievoorschriften

De gegevenssoort medicatievoorschriften wordt aangemeld door zogenaamde voorschrijvende systemen (XIS-en waarin nieuwe medicatievoorschriften ontstaan). Normaal gesproken wordt deze categorie systemen aangeduid als Elektronische Voorschrijfsystemen (EVS-en). Dit kan gaan om een zelfstandig systeem, bijvoorbeeld draaiend naast het ziekenhuisinformatiesysteem (ZIS) in een ziekenhuis of GGZ-instelling. Het kan echter ook gaan om een module die is geïntegreerd in een breder opgezet XIS. In veel ziekenhuizen is het EVS geïntegreerd in het EPD (per specialisme of centraal) en bij huisartsen is het vrijwel altijd een functie binnen hun huisartsinformatiesysteem (HIS). In het HIS van apotheekhoudende huisartsen is deze functie geïntegreerd met die van het verstrekkend systeem, maar deze wordt apart beschreven.

De spelregels voor het aanmelden van medicatievoorschriften zijn als volgt:

• De gebruikte gegevenssoort is ”722933” (zie [HL7v3 IH Wrp]).
• Er moet een nieuwe aanmelding plaatsvinden voor elke patiënt waarbij voor het eerst een (niet afgeschermd) medicatievoorschrift wordt vastgelegd in het EVS.
• Er moet een heraanmelding plaatsvinden bij elk volgend (niet afgeschermd) medicatievoorschrift dat bij een eerder aangemelde patiënt wordt vastgelegd.
• Er moet een heraanmelding plaatsvinden bij elke mutatie op een eerder vastgelegd voorschrift (zie voorgaande regel, want veel systemen hanteren het principe dat mutaties op een eerder voorschrift leiden tot een nieuw voorschrift).
• Er moet een afmelding plaatsvinden voor een patiënt op het moment dat alle eerder vastgelegde voorschriften zijn verwijderd of afgeschermd in het EVS.
• Er mag slechts één aanmelding per patiënt zijn voor deze gegevenssoort.

In alle gevallen mogen brongegevens alleen worden aangemeld door het systeem waarin de gegevens ontstaan! Dat wil zeggen dat externe gegevens die (al dan niet via een ZIM) worden opgevraagd, en die worden geïntegreerd in het lokale dossier, herkenbaar moeten zijn als kopie en nooit mogen worden aangemeld (en dus niet mogen worden opgeleverd bij bevraging via de ZIM)!

Medicatieverstrekkingen

De gegevenssoort medicatieverstrekkingen wordt aangemeld door zogenaamde verstrekkende systemen (XIS-en waarin nieuwe medicatieverstrekkingen worden geregistreerd). In een openbare apotheek ondersteunt een apotheekinformatiesysteem (AIS) meestal de gehele bedrijfsvoering. In een ziekenhuis of GGZ-instelling is het begrip verstrekking gedefinieerd als een ‘door een apotheker bevestigde medicatieopdracht’. Het aanmelden van deze ‘verstrekkingen’ kan gebeuren door een ziekenhuis-AIS (ZAIS), maar kan ook gedelegeerd worden aan het ZIS of EPD-systeem dat eraan gekoppeld is. Bij apotheekhoudende huisartsen gebeurt het vastleggen van verstrekkingen meestal in een aparte module, die echter is geïntegreerd in het huisartsinformatiesysteem (HIS).

De spelregels voor het aanmelden van medicatieverstrekkingen zijn als volgt:

• De gebruikte gegevenssoort is "272353" (zie [HL7v3 IH Wrp]).
• Er moet een nieuwe aanmelding plaatsvinden voor elke patiënt waarbij voor het eerst een (niet afgeschermde) medicatieverstrekking wordt vastgelegd in het EVS.
• Er moet een heraanmelding plaatsvinden bij elke volgende (niet afgeschermde) medicatieverstrekking die bij een eerder aangemelde patiënt wordt vastgelegd.
• Er moet een heraanmelding plaatsvinden bij elke mutatie op een eerder vastgelegde verstrekking (het wijzigen van de patiënt bij een verstrekking moet gezien worden als toevoeging voor de nieuwe en verwijdering voor de oude).
• Er moet een afmelding plaatsvinden voor een patiënt op het moment dat alle eerder vastgelegde verstrekkingen zijn verwijderd of afgeschermd in het XIS.
• Er mag slechts één aanmelding per patiënt zijn voor deze gegevenssoort.

Het is bekend dat veel AIS-en reeds een verstrekking registreren op het moment dat een voorschrift is verwerkt en de medicatie is klaargezet voor de patiënt. Formeel is dat niet juist, omdat rapportage van verstrekkingen in het EMD is gekoppeld aan het afleveren van de medicatie aan de patiënt of diens vertegenwoordiger. Voorlopig worden beide werkwijzen echter door elkaar gehanteerd, in afwachting van nadere afspraken met koepels en leveranciers.

In alle gevallen mogen brongegevens alleen worden aangemeld door het systeem waarin de gegevens ontstaan! Dat wil zeggen dat externe gegevens die (al dan niet via een ZIM) worden opgevraagd, en die worden geïntegreerd in het lokale dossier, herkenbaar moeten zijn als kopie en nooit mogen worden aangemeld (en dus niet mogen worden opgeleverd bij bevraging via de ZIM)!

Een medicatieverstrekking is niet hetzelfde als een regel in een medicatieprofiel. Relevant zijn: op voorschrift verstrekte medicatie door de eigen apotheek. De volgende registraties (‘medicatieregels’) worden dus nadrukkelijk uitgesloten: vrije verkoop (‘over the counter’ medicatie); niet-geneesmiddelen (met name journaalregels); elders verstrekte medicatie (gemeld door de patiënt). Deze registraties worden vaak gecombineerd met eigen verstrekkingen, ter completering van het medicatieprofiel (een overzicht van de actuele medicatie).

Specificaties voor datatype GTS voor doseerschema

Inleiding

Achtergrond

Het datatype GTS (General Timing Specification) in HL7v3 biedt een zeer generiek mechanisme voor het doorgeven van tijdschema’s. In het geval van medicatiegegevens wordt dit toegepast in het attribuut effectiveTime van MedicationAdministrationRequest (medicatietoedieningsverzoek), waarmee het doseerschema exact wordt aangeduid.

GTS is gebaseerd op het toepassen van zogenaamde verzamelingenlogica, waarbij een tijdschema wordt uitgedrukt als een verzameling met elkaar samenhangende, al dan niet in de tijd herhalende, tijdstippen of intervallen. Op deze manier kan (vrijwel) elk doseerschema op een eenduidige (maar niet eenvormige) manier worden uitgedrukt.

Probleemstelling

Tijdens de implementatie van de berichten voor medicatiegegevens is gebleken dat de ‘veelvormige’ structuur van het datatype GTS veel leveranciers voor problemen stelt. Het genereren van GTS syntax is goed te automatiseren, maar het verwerken (parsen) ervan kan erg complex zijn. De reden hiervoor is dat een verzender zelf kan bepalen welke uitdrukkingsvorm gebruikt wordt om een bepaald tijdschema aan te duiden, terwijl een ontvanger voorbereid moet zijn op alle mogelijke variaties die gehanteerd kunnen worden.

Dit is inherent aan het feit dat GTS een ‘algoritme’ is dat meerdere vormen (syntax) met dezelfde betekenis (semantiek) mogelijk maakt. Er kunnen daarom de volgende gevaren zijn als GTS vrijuit wordt toegepast bij de implementatie van medicatiedoseerschema’s:

• Leveranciers maken fouten bij het verwerken van doseerschema’s in hun systeem.

    ⇒Merk op dat dit potentieel tot fouten bij voorschrijven of bewaking kan leiden!

• Leveranciers kunnen sommige aangeleverde doseerschema’s simpelweg niet aan.

    ⇒ Hierdoor onstaat onvolledige informatievoorziening naar vragende zorgverleners!

• Het is verleidelijk om vrije tekst te gebruiken in plaats van gestructureerde informatie.

    ⇒ Gevolg is dat er geen basis meer is voor geautomatiseerde medicatiebewaking!

Doelstelling

Het doel van inperking van de syntactische specificaties voor GTS voor doseerschema’s is om eenduidigheid en eenvormigheid met elkaar af te stemmen. Dat wil zeggen dat voor elke vorm van een doseerschema een specifiek formaat wordt vastgelegd, dat voor zowel verzenders als ontvangers duidelijkheid schept. Vanzelfsprekend stelt dit strengere eisen aan de verzender (hoewel deze daar eenduidige richtlijnen en voorbeelden voor terug krijgt). Voor de ontvanger wordt het verwerken van GTS schema’s juist eenvoudiger.

De richtlijnen voor GTS bij doseerschema’s worden onderdeel van de XIS beoordelingscriteria. Ze zijn mede bepalend of een bericht correct is, hetgeen ook wordt gecontroleerd in Schematron. Daarnaast wordt het door de striktere specificatie van GTS formaten eenvoudiger om te vertalen van 1e naar 2e lijn (en vice versa). Tenslotte wordt het mogelijk om geautomatiseerd tekstuele beschrijvingen te genereren bij doseerschema’s, zodanig dat in alle gevallen naast een gestructureerde ook een tekstuele vorm bestaat.

Uitgangspunten GTS voor medicatiedoseerschema's

Het datatype GTS wordt beschreven in de Datatype-CMET gids van HL7 Nederland (ook onderdeel van de AORTA documentatie). In deze syntactische specificaties wordt hierop een nadere inperking beschreven, bedoeld voor toepassing in medicatiedoseerschema’s.

Er zijn diverse uitgangspunten bij het inperken van GTS formaten bij doseerschema’s:

• In principe wordt voor elk type doseerschema exact één syntax beschreven, zodat eenheid van vorm bereikt wordt (naast de bestaande semantische eenduidigheid).
• Het is niet wenselijk om (in plaats van of zelfs naast) de in HL7 gecodeerde doseerinstructie een tabel 25 instructie mee te geven in HL7 berichten (tenzij als onderdeel van de vrije tekst). De redundantie die wordt veroorzaakt door twee verschillende manieren om doseerinstructies door te geven is onwenselijk.
• Het datatype EIVL_TS (Event Related Interval of Time) wordt vooralsnog niet gebruikt in Nederland en is niet toegestaan totdat hier richtlijnen voor bestaan.
• Overige features van GTS, zoals alignment en institutionSpecified mogen nog niet worden gebruikt als daar nog geen concrete use case voor bestaat. Dergelijke features kunnen desgewenst later nog worden toegevoegd aan de richtlijnen.

Verschijningsvormen GTS

Elke GTS in het veld effectiveTime van een MedicationAdministration (die looptijd en/of doseerschema weergeeft) komt overeen met één van de volgende standaardtypen:

1. Enkel tijdstip (eenmalig gebruik).
2. Enkel tijdsinterval (gespreid gebruik zonder doseerschema).
3. Enkelvoudig herhaalpatroon (met onbepaald gebruiksinterval).
4. Gecombineerd herhaalpatroon (met onbepaald gebruiksinterval).
5. Combinaties van tijdsinterval en herhaalpatronen.

Elk van deze hoofdformaten worden hieronder beschreven en ingedeeld in subtypes.

GTS.Tijdstip

Dit formaat wordt gebruikt als sprake is van eenmalig gebruik van medicatie. Er hoeft dan geen expliciet datatype te worden doorgegeven, omdat het datatype TS (time stamp) de default is bij gebruik van GTS (het is in dat geval een verzameling van één time stamp).

Toepassing: Dit wordt gebruikt als zowel datum als tijd van een eenmalige toediening bekend is.

Formaat:

<effectiveTime value="yyyymmddhhmm" />

Toepassing: Dit wordt gebruikt als wel bekend is op welke dag (eenmalige) toediening moet plaatsvinden, maar niet bekend is (of niet relevant is) op welk tijdstip op die dag.

Formaat:

<effectiveTime value="yyyymmdd" />

Noot: Het is nog niet zo eenvoudig om aan te geven dat medicatie eenmalig (of een x aantal keer) gebruikt moet worden, zónder een specifieke datum of tijdstip aan te duiden. Feitelijk is er momenteel geen manier beschreven om dat eenduidig te doen, dus dat zou alleen kunnen worden weergegeven in de tekstuele beschrijving van de doseerinstructie.

GTS.Tijdsinterval (gespreid gebruik)

Een tijdsinterval heeft het expliciete datatype IVL_TS (als specialisatie van GTS). Het kan voorkomen als een op zichzelf staande GTS aanduiding en betreft dan gespreid gebruik zonder doseerschema (dat wil zeggen het schema is niet bekend of niet relevant of wordt bekend verondersteld). Meestal zal het echter voorkomen in combinatie met een doseerschema. Deze laatste categorie wordt behandeld in Combinaties van tijdsinterval en herhaalpatroon. In de huidige paragraaf worden algemene regels gegeven voor de toepassing van een gebruiksinterval.

In alle gevallen wordt een dergelijk tijdsinterval niet alleen voorzien van een datum als onder- en/of bovengrens, maar ook van een tijd. Dit heeft te maken met mogelijke verwarring over het al dan niet inclusief zijn van de bovengrens. Als een gebruiksmoment precies op de intervalgrens valt, dan is het uitgangspunt dat het *wel* moet plaatsvinden c.q. heeft plaatsgevonden. Er is in HL7 een mogelijkheid om de grens expliciet uit te sluiten, maar die wordt niet gebruikt.

In de volgende paragrafen volgen enkele toepassingen van een gebruiksinterval.

GTS.Open interval

Toepassing: Dit wordt gebruikt als alleen het begin van het gebruiksinterval bekend is, maar het einde daarvan (nog) niet. Dit is vrijwel altijd het geval bij klinisch voorgeschreven medicatie en ook vaak bij ambulante medicatie die ‘zo nodig’ gebruikt moet worden of waarvan het gebruik door de patiënt zelf wordt gereguleerd (zoals bij insulinegebruik door diabetici).

Formaat:

<effectiveTime xsi:type="IVL_TS">		
	<low value="yyyymmddhhmm" />
</effectiveTime>

Toelichting: Belangrijk is de aanvullende regel dat het beginpunt altijd inclusief tijdstip moet worden doorgegeven (zie GTS Interval met exacte tijdstippen voor toelichting). Dit betekent dat altijd 0000 wordt toegevoegd aan een begindatum, tenzij er een specifiek begintijdstip (bijvoorbeeld 1400) is.

Discussie: Bij sommige AIS leveranciers in de eerste lijn wordt bij ‘zo nodig’ medicatie uitgegaan van een vaste gebruiksperiode na de eerste verstrekkingsdatum bij het bepalen van de actuele medicatie. De enig juiste aanpak is om het gebruiksinterval open (of weg) te laten als geen harde einddatum te bepalen is. Een einddatum kan soms ook expliciet worden aangegeven door de voorschrijver, zelfs als de medicatie ‘zo nodig’ wordt gebruikt.

Noot: dit hangt samen met de wens om in het kader van het EMD af te dwingen dat een AIS het onderscheid kan maken tussen een default einddatum en een expliciet ingevoerde einddatum. Met name bij ‘zo nodig’ voorschriften zou geen default termijn (bijvoorbeeld 90 dagen) mogen worden doorgegeven in de berichten, aangezien dit schijninformatie is.

GTS.Gesloten interval

Een gesloten interval heeft een bepaalde (eindige) duur. Er bestaan meerdere varianten.

GTS.Interval met exacte tijdstippen

Toepassing: Dit wordt gebruikt als het gebruiksinterval volledig bekend is (of daarover een aanname wordt gedaan). Voorbeeld is een kuur die op een vaste datum (of per direct) begonnen moet worden en waarvan (op basis van een vaste dosering) het eindpunt bekend is.

Formaat:

<effectiveTime xsi:type="IVL_TS">
	<low value="yyyymmddhhmm" />
	<high value="yyyymmddhhmm" />
</effectiveTime>

Toelichting: Belangrijk is dat hier de aanvullende regel is gesteld dat altijd inclusief tijdstippen moet worden doorgegeven. Voorheen werd meestal alleen een datum meegegeven, maar dit leidt tot de vreemde situatie dat de berichten strikt genomen niet weergeven wat er intuïtief mee bedoeld wordt. Dit wordt geïllustreerd door het onderstaande voorbeeld.

Wat is de betekenis van het interval?

<low value="20080101">
<high value="20080109">

Het officiële HL7 standpunt is dat dit betekent dat TOT 9 januari ’07 een interval loopt. Er is een attribuut inclusive, waarmee kan worden aangegeven of de grens al dan niet meedoet (de defaultwaarde hiervan is TRUE), maar dit heeft alleen betrekking op het ‘eerste moment’ van 9 januari ’07. De dag zelf doet dus NIET mee. Dit is tegenstrijdig met de intuïtieve beleving van een tijdsinterval, want (zeker als er expliciet inclusive = TRUE bij zou staan) zou de standaardinterpretatie zijn dat 9 januari ’07 WEL in z’n geheel bij het interval hoort. Dit komt omdat een datum feitelijk niet wordt gezien als een enkele waarde (zoals een integer), maar als een interval met een duur van één dag.

De officiële interpretatie van de grenzen van een tijdsinterval is consistent met de toepassing van intervallen van andere data types, zoals numerieke waarden (REAL). Het zal immers niemand verbazen dat 4.1 NIET als onderdeel van het interval tussen 2 en 4 wordt gerekend, zelfs als inclusive = TRUE wordt vermeld. Door het verschil tussen formele betekenis en interpretatie kunnen echter communicatieproblemen en zelfs gevaarlijke situaties onstaan. Het is dus belangrijk dat hier eenduidigheid wordt bereikt.

Noot: het verwerken van inclusive = FALSE is niet nodig in de Nederlandse situatie.

Dit wordt bereikt door bij een gesloten interval met begin- en einddatum expliciet een tijdstip aan de datum toe te voegen. Hierdoor ligt met name het eindpunt exact vast.

Het eerder genoemde interval moet dan worden doorgegeven als:

<low value="200801010000">
<high value="200801092359">

Hierdoor wordt verwarring over de interpretatie voorkomen. Theoretisch valt de laatste minuut van 9 januari nog steeds buiten het interval, maar dat is in de praktijk nooit een probleem. Essentieel is dat 2359 wordt gebruikt om de einddatum volledig te dekken.

GTS.Geankerd interval

Toepassing:

Een geankerd interval komt nooit op zichzelf staand voor in een GTS expressie, maar wordt gebruikt in een zogenaamd herhalend interval (zie Herhalend interval) om een periode van één of meer gehele dagen aan te duiden.

Formaat:

<effectiveTime xsi:type="IVL_TS">		
	<low value="yyyymmdd" />		let op: hier mag geen tijdstip staan!
	<width value="{n>=1}" unit="d" />
</effectiveTime>

Toelichting: Een geankerd interval is mathematisch equivalent aan een interval met exacte tijdstippen.

<effectiveTime xsi:type="IVL_TS">
	<low value="20080101"/>
	<width value="4" unit="d"/>
</effectiveTime>

is dus equivalent met:

<effectiveTime xsi:type="IVL_TS">
	<low value="200801010000"/>
	<high value="200801042359"/>
</effectiveTime>

GTS.Zwevend interval

Toepassing:

Een zwevend interval wordt gebruikt als wel de looptijd (in dagen, weken, maanden of jaren) bekend is, maar (nog) geen exacte begindatum. Dit is de manier waarop veel ambulante voorschriften feitelijk worden bedoeld door de auteur, hoewel in de praktijk toch vaak een begin- en een einddatum (zie paragraaf 5.2.2.2.1) worden vermeld.

Formaat:

<effectiveTime xsi:type="IVL_TS">		
	<width value="{n>=1}" unit="[d|wk|mo|a]" />
</effectiveTime>

Noot: vrijwel alle ontvangende systemen kunnen een dergelijke gebruiksduur alleen opslaan door er een expliciete begin- en einddatum aan te hangen (waarbij meestal als begindatum de verstrekkingsdatum zal worden genomen). Dit wordt geaccepteerd, maar feitelijk wordt in die gevallen bij opslag van de periode ‘schijninformatie’ toegevoegd.

GTS.Periodieke herhaling

Een periodieke herhaling heeft het expliciete datatype PIVL_TS (specialisatie van GTS). Het kan voorkomen als een op zichzelf staande GTS-aanduiding en betreft dan een doseerschema zonder specifieke looptijd (de looptijd is onbekend, niet relevant of wordt bekend verondersteld). Meestal zal het echter voorkomen in combinatie met andere componenten. Deze cominaties worden behandeld in "Gecombineerde herhaalpatronen" en "Combinaties van tijdsinterval en herhaalpatroon". In de huidige paragraaf worden algemene regels gegeven bij toepassing van periodieke herhalingen.

GTS.Gebruiksfrequentie

Een gebruiksfrequentie in GTS heeft de vorm van een ‘periodiek herhalend moment’. Dit heeft betrekking op situaties waarbij een gebeurtenis (het gebruik van medicatie) volgens een vast patroon wordt herhaald, zonder dat hierbij expliciet tijdstippen worden benoemd.

Toepassing:

Bij veel ambulante voorschriften is het alleen relevant om de gebruiksfrequentie (uitgedrukt met de periode tussen opeenvolgende gebruiksmomenten) door te geven. Dit is bijvoorbeeld de enige manier waarop het doseerschema in tabel 25 wordt aangeduid (afgezien van bepaalde b codes), hetgeen vaak input is voor een vertaling naar GTS.

Formaat:

<effectiveTime xsi:type="PIVL_TS">		
	<period value="x" unit="y" />			
</effectiveTime>

Toelichting:

Bovenstaand PIVL formaat geeft alleen een periodieke herhaling aan, zonder precieze tijdstippen. In feite wordt een impliciet gebruiksmoment herhaald conform de <period>.

Noot: Er is bij deze doseervariant geen expliciete verwachting over de spreiding van de toedieningen, ook al lijkt de <period> te duiden op een exacte tijdsduur. Er wordt verondersteld dat de ontvanger c.q. toediener weet welke spreiding al dan niet toelaatbaar is.

Voorbeelden:

1x per dag

<effectiveTime xsi:type="PIVL_TS">		
	<period value="1" unit="d" />			
</effectiveTime>

4x per dag

<effectiveTime xsi:type="PIVL_TS">		
	<period value="0.25" unit="d" />			
</effectiveTime>

3x per week

<effectiveTime xsi:type="PIVL_TS">		
	<period value="0.3333" unit="wk" />			
</effectiveTime>

1x per 3 dagen

<effectiveTime xsi:type="PIVL_TS">		
	<period value="3" unit="d" />			
</effectiveTime>

Vertaling naar tabel 25:

Een GTS met een herhalend moment zonder vast tijdstip kan in de meeste gevallen exact worden vertaald naar tabel 25. Er wordt daarbij echter altijd omgezet naar een frequentie van een geheel aantal keer per enkele tijdseenheid (uur, dag, week of maand). Dat wil zeggen dat een afrondingsfout ontstaat als de <period > bijv. 2/3 dag is (want deze wordt omgezet naar 2x per dag. De bovengenoemde voorbeelden worden vertaald naar 1D1T, 4D1T, 3W25ML respectievelijk 1DD25ML (hier wordt dus vertaald naar de juiste t code).

GTS.Herhalend interval

Toepassing:

Een herhalend interval komt nooit op zichzelf staand voor in een GTS expressie, maar wordt gebruikt om een herhalend moment in te perken, zodanig dat een patroon ontstaat waarin bepaalde periodes wel en bepaalde periodes niet voorkomen.

Dit is bijvoorbeeld van toepassing bij een zogenaamd ‘pilschema’, waarbij om en om 21 dagen wel en 7 dagen geen gebruik plaatsvindt. De component waarmee de periode van 21 dagen wordt aangeduid noemen we dus het herhalend interval. Deze wordt gecombineerd met één of meer herhalende momenten om een zogenaamd intervalschema te vormen (zie "Intervalschema"). Het herhalend interval is dus zuiver een bouwsteen daarvoor.

Formaat:

Een herhalend geankerd interval:

<effectiveTime xsi:type="PIVL_TS" />		
	<phase>
		{geankerd interval}		altijd duur in geheel aantal dagen!
	</phase>
	<period value=”{n>=1}” unit=”d” />
</effectiveTime>

Een herhalend zwevend interval:

<effectiveTime xsi:type="PIVL_TS" />		
	<phase>
		{zwevend interval}		altijd duur in geheel aantal dagen!
	</phase>
	<period value=”{n>=1}” unit=”d” />
</effectiveTime>

Toelichting:

Een herhalend interval bestaat dus altijd uit een geankerd of een zwevend interval dat periodiek herhaald wordt. Er is de regel gesteld dat het interval altijd een geheel aantal dagen moet beslaan en dat de herhaalperiode een geheel aantal dagen moet omvatten. Dit omdat de intervalschema’s waarin een herhalend interval wordt gebruikt in principe altijd de vorm hebben “m dagen wel, n dagen niet” (totdat er andere use cases zijn).

Voorbeeld:

´om de dag´

<effectiveTime xsi:type="PIVL_TS">
		<phase>
				<width value=”1” unit=”d”/>
    	</phase>
    	<period value="2" unit="d"/>
</effectiveTime>

Zie voor meer voorbeelden het gebruik in intervalschema’s in "Intervalschema" en "Geneste combinatie van herhaalpatronen".

GTS.Gecombineerde herhaalpatronen

Niet-geneste combinatie van herhaalpatronen

GTS.Herhalende tijdstippen per dag

Toepassing:

Bij klinische voorschriften is het gebruikelijk om (na bevestiging door de apotheek) de toedieningen in te plannen op specifieke tijdstippen. Deze tijdstippen worden meestal bepaald door de deelrondes van de betreffende verpleegafdeling. In de meeste gevallen luisteren de tijden medisch gezien niet zo nauw, en hebben ze vooral een logistieke reden.

Formaat:

<effectiveTime xsi:type="SXPR_TS">
	<comp xsi:type="PIVL_TS">		
		<phase>					
			<center value="yyyymmddhhmm" />
		</phase>
		<period value="1" unit="d" />
	</comp>
	[	<comp xsi:type="PIVL_TS" [ operator="I"> ]
			…
		</comp>								]
	...									
</effectiveTime>

Merk op dat de operator “I" optioneel is, omdat het de default operator in het XML Schema van datatype GTS is. Voor de leesbaarheid wordt aangeraden de operator altijd mee te geven, maar bij ontbreken ervan moet operator “I" worden verondersteld. Standaard worden subsets in GTS dus met elkaar verenigd.

Toelichting:

Een gecombineerd patroon met herhalende tijdstippen bestaat uit een serie van één of meer herhalende vaste tijdstippen per dag. Merk op dat het dus ook is toegestaan om slechts één herhalend tijdstip op te nemen, ook al ontstaat daardoor een ‘loze’ schil. De reden hiervoor is dat het aantal tijdstippen meestal variabel is (de gebruiksfrequentie), en het lastig is om aparte formaten te hanteren afhankelijk van het aantal herhalingen.

De volgende beperkingen worden gesteld aan herhalende tijdstippen:

• Elk tijdstip moet tot op de minuut gespecificeerd zijn (dus niet alleen een datum).
• Er moet sprake zijn van een dagschema: <period> moet gelijk zijn aan één dag.

Deze laatste eis is gesteld omdat klinische doseerschema’s bijna altijd als dagschema’s zijn opgezet. Natuurlijk is het mogelijk om dagen over te slaan in het schema, maar dit gebeurt door middel van doorsnede met een periodiek herhalend interval (zie "Herhalend interval").

Deze herhalingen worden gecombineerd door ze te verenigen met de set operator ‘I’. Die ‘vereniging’ wil simpelweg zeggen dat de herhalende tijdstippen parallel plaatsvinden.

Voorbeeld:

dagelijks om 09:00

<effectiveTime xsi:type="PIVL_TS">
	<phase>
		<center value="200802010900"/>
	</phase>		
	<period value="1" unit="d" />
</effectiveTime>

dagelijks om 09:00 en 18:00

<effectiveTime xsi:type="SXPR_TS">
	<comp xsi:type="PIVL_TS">
		<phase>
      			<center value="200801310900"/>
		</phase>
		<period value="1" unit="d"/>
    	</comp>
    	<comp xsi:type="PIVL_TS" operator="I">
		<phase>
      			<center value="200801311800"/>
		</phase>
		<period value="1" unit="d"/>
    	</comp>
</effectiveTime>

Er zou verwarring kunnen ontstaan over het feit dat de datum in bovenstaande PIVL_TS elementen feitelijk niets betekent (hier zou ook 1 jan. 1600 kunnen staan en dan betekent het exact hetzelfde!). De PIVL_TS elementen strekken zich ‘oneindig’ uit en de feitelijke toedieningsperiode wordt bepaald door het interval (IVL_TS) waarmee doorsneden wordt (indien dit expliciet wordt aangegeven). Om verwarring te voorkomen wordt de volgende implementatierichtlijn gegeven voor de datum die gebruikt wordt in de <center> elementen van de PIVL_TS: als een expliciet gebruiksinterval wordt meegegeven bij het doseerschema, dan dient de eerste datum van dat interval gebruikt te worden; in alle andere gevallen dient bij voorkeur de voorschrijf- of verstrekkingsdatum (afhankelijk van de context) te worden gebruikt. Merk overigens op dat het XML Schema van GTS ook toestaat dat <phase value=…/> wordt gebruikt in plaats van <phase><center value=…/></phase>. Deze vorm wordt echter expliciet uitgesloten voor maximale standaardisatie.

Vertaling naar tabel 25: Een GTS met herhalende tijdstippen per dag kan niet zonder informatieverlies worden vertaald naar tabel 25, omdat in tabel 25 geen vaste tijdstippen aangeduid kunnen worden. Theoretisch is omzetting naar dagdelen (ochtend, middag, avond) mogelijk, maar ook dan vindt informatieverlies plaats. Bovenstaand voorbeeld wordt normaal gesproken omgezet naar een doseerinstructie voor 2x per dag (bijv. 2D1T als het om 1 tablet ging).

GTS.Intervalschema

Toepassing:

De simpelste variant van een intervalschema treedt op als een bepaald gebruikspatroon niet op elke dag moet plaatsvinden, maar op bepaalde dagen wel en op andere dagen niet. In dat geval wordt gebruik gemaakt van de mogelijkheid om het patroon (dat is in de simpelste variant een herhalend moment) te doorsnijden met een herhalend interval.

De betekenis hiervan is dat het gebruik van de medicatie alleen plaatsvindt op de dagen die binnen het herhalende interval vallen. De andere dagen vallen buiten de doorsnede.

Formaat:

<effectiveTime xsi:type="SXPR_TS">		
	{ herhalend moment }
	{ herhalend interval } operator="A"    datum moment = datum anker interval!
</effectiveTime>

Het datatype GTS staat ook toe om een intervalschema uit te drukken met behulp van de operator “E”, die staat voor het verschil tussen twee verzamelingen. Omdat hetzelfde effect echter bereikt kan worden met operator “A” (doorsnede), wordt operator “E” niet meer gebruikt bij het doorgeven van doseerschema’s.

Voorbeelden:

1x per dag gedurende 21 dagen, dan 7 dagen niet (pilschema)

<effectiveTime xsi:type="SXPR_TS">
	<comp xsi:type="PIVL_TS">
     		<period value="1" unit="d"/>
    	</comp>
    	<comp xsi:type="PIVL_TS" operator="A">
     		<phase>
			<width value=”21” unit=”d”/>
     		</phase>
     		<period value="28" unit="d"/>
    	</comp>
</effectiveTime>

Toelichting:

Uit bovenstaand voorbeeld blijkt al dat ook sprake kan zijn van een zwevend herhalend interval in een intervalschema, indien niet bepaald is op welke dag de toediening start.

dagelijks om 09:00, telkens 4 dagen wel en dan 2 dagen niet, vanaf 31/1/2008

<effectiveTime xsi:type="SXPR_TS">
		<comp xsi:type="PIVL_TS">
     		<phase>
      			<center value="200801310900"/>
     		</phase>
     		<period value="1" unit="d"/>
    	</comp>
    	<comp xsi:type="PIVL_TS" operator="A">
     		<phase>
      			<low value="20080131"/>					Deze datum moet gelijk zijn aan
			<width value=”4” unit=”d”/>			die van het herhalende moment.
     		</phase>
     		<period value="6" unit="d"/>
    	</comp>
</effectiveTime>

Vertaling naar tabel 25:

Het is niet mogelijk om een intervalschema zonder informatieverlies om te zetten naar tabel 25, omdat de gebruikte versie van tabel 25 geen standaardmechanisme heeft voor het aangeven van (herhalende) periodes zonder medicatiegebruik. De huidige transformatie herkent alleen een herhalend interval van 1 dag per 2 dagen en zet dit om naar de tabel 25 instructie voor ‘om de dag’. Voor alle andere gevallen zal hoogstens een benadering mogelijk zijn, waarbij alleen de cumulatieve dosering over de duur van het herhalende interval wordt bepaald (bijv. “per 4 weken 21 tabletten” bij het pilschema). Dat is voldoende informatie voor de meeste vormen van medicatiebewaking.

GTS.Geneste combinatie van herhaalpatronen

Intervalschema met herhalende tijdstippen

Toepassing:

Een intervalschema kan ook voorkomen in combinatie met een patroon met herhalende tijdstippen. Het effect is hetzelfde, namelijk dat het betreffende herhaalpatroon alleen betrekking heeft op de dagen die binnen de doorsnede met het herhalende interval vallen.

Formaat:

<effectiveTime xsi:type="SXPR_TS">		
	{ herhalende tijdstippen per dag }
	{ herhalend interval } operator="A" 		
</effectiveTime>

Voorbeeld:

2x per dag om 08:00 en 18:00 gedurende 3 dagen, dan 1 dag niet

<effectiveTime xsi:type="SXPR_TS">
	<comp xsi:type="SXPR_TS">
		<comp xsi:type="PIVL_TS">
			<phase>
				<center value="200801310800"/>
    			</phase>
     		<period value="1" unit="d"/>
    		</comp>
		<comp xsi:type="PIVL_TS" operator="I">
     			<phase>
      				<center value="200801311800"/>
     			</phase>
     			<period value="1" unit="d"/>
    		</comp>
	</comp>
    	<comp xsi:type="PIVL_TS" operator="A">
     		<phase>
      			<low value="20080131"/>		Deze datum moet gelijk zijn aan
			<width value="3" unit="d"/>	die v/d herhalende momenten.
     		</phase>
     		<period value="4" unit="d"/>
    	</comp>
</effectiveTime>

GTS.Meervoudig intervalschema

Toepassing:

Het is ook mogelijk dat intervalschema’s zelf weer gecombineerd worden, om complexere patronen van dagen met en zonder medicatiegebruik te vormen. Dit kan gebeuren met alle eerder beschreven varianten van een intervalschema, hetgeen zelfs drie niveaus van nesting van het SXPR_TS data type op kan leveren.

Formaat:

<effectiveTime xsi:type="SXPR_TS">		
	{ intervalschema }
	{ intervalschema } [ operator="I" ]
	...						
</effectiveTime>

Voorbeeld:

3 dagen 1x daags om 14:00, dan een rustdag, dan 1 dag 2x daags om 08:00 en 18:00 dit alles elke 5 dagen herhalend

<effectiveTime xsi:type="SXPR_TS">
	<comp xsi:type="SXPR_TS">
		<comp xsi:type="PIVL_TS">
     			<phase>
      				<center value="200801311400"/>
     			</phase>
     			<period value="1" unit="d"/>
    		</comp>
    		<comp xsi:type="PIVL_TS" operator="A">
     			<phase>
      				<low value="20080131"/>		
				<width value=”3” unit=”d”/>	
     			</phase>
     			<period value="5" unit="d"/>
    		</comp>
	</comp>
	<comp xsi:type="SXPR_TS" operator="I">
		<comp xsi:type="SXPR_TS">
			<comp xsi:type="PIVL_TS">
     				<phase>
      					<center value="200802040800"/>
     				</phase>
     				<period value="1" unit="d"/>
    			</comp>
			<comp xsi:type="PIVL_TS" operator="I">
     				<phase>
      					<center value="200802041800"/>
     				</phase>
     				<period value="1" unit="d"/>
    			</comp>
		</comp>
    		<comp xsi:type="PIVL_TS" operator="A">
     			<phase>
      				<low value="20080204"/>
				<width value=”1” unit=”d”/>
     			</phase>
     			<period value="5" unit="d"/>
    		</comp>
	</comp>
</effectiveTime>

Toelichting:

In bovenstaand voorbeeld wordt al duidelijk dat voor elk van de intervalschema’s geldt dat de <phase> geankerd wordt op de eerste dag van een periode waarop het gebruik betrekking heeft. Dus in bovenstaande situatie wordt de eerste periode (van telkens 3 dagen) geankerd op 31/1 en de derde periode (van telkens 1 dag) op 4/2. De rustdag wordt niet expliciet aangeduid, maar is een impliciet gevolg van het feit dat tussen de genoemde periodes een dag zonder gebruik zit. Merk op dat rustperiodes niet mogen worden aangeduid door expliciet een periode met een dosering van 0 op te nemen!

Intervalschema met herhalende tijdstippen

Toepassing:

Een intervalschema kan ook voorkomen in combinatie met een patroon met herhalende tijdstippen. Het effect is hetzelfde, namelijk dat het betreffende herhaalpatroon alleen betrekking heeft op de dagen die binnen de doorsnede met het herhalende interval vallen.

Formaat:

<effectiveTime xsi:type="SXPR_TS">		
	{ herhalende tijdstippen per dag }
	{ herhalend interval } operator="A" 		
</effectiveTime>

Voorbeeld:

2x per dag om 08:00 en 18:00 gedurende 3 dagen, dan 1 dag niet

<effectiveTime xsi:type="SXPR_TS">
	<comp xsi:type="SXPR_TS">
		<comp xsi:type="PIVL_TS">
			<phase>
				<center value="200801310800"/>
    			</phase>
     		<period value="1" unit="d"/>
    		</comp>
		<comp xsi:type="PIVL_TS" operator="I">
     			<phase>
      				<center value="200801311800"/>
     			</phase>
     			<period value="1" unit="d"/>
    		</comp>
	</comp>
    	<comp xsi:type="PIVL_TS" operator="A">
     		<phase>
      			<low value="20080131"/>		Deze datum moet gelijk zijn aan
			<width value="3" unit="d"/>	die v/d herhalende momenten.
     		</phase>
     		<period value="4" unit="d"/>
    	</comp>
</effectiveTime>

GTS.Meervoudig intervalschema

Toepassing:

Het is ook mogelijk dat intervalschema’s zelf weer gecombineerd worden, om complexere patronen van dagen met en zonder medicatiegebruik te vormen. Dit kan gebeuren met alle eerder beschreven varianten van een intervalschema, hetgeen zelfs drie niveaus van nesting van het SXPR_TS data type op kan leveren.

Formaat:

<effectiveTime xsi:type="SXPR_TS">		
	{ intervalschema }
	{ intervalschema } [ operator="I" ]
	...						
</effectiveTime>

Voorbeeld:

3 dagen 1x daags om 14:00, dan een rustdag, dan 1 dag 2x daags om 08:00 en 18:00 dit alles elke 5 dagen herhalend

<effectiveTime xsi:type="SXPR_TS">
	<comp xsi:type="SXPR_TS">
		<comp xsi:type="PIVL_TS">
     			<phase>
      				<center value="200801311400"/>
     			</phase>
     			<period value="1" unit="d"/>
    		</comp>
    		<comp xsi:type="PIVL_TS" operator="A">
     			<phase>
      				<low value="20080131"/>		
				<width value=”3” unit=”d”/>	
     			</phase>
     			<period value="5" unit="d"/>
    		</comp>
	</comp>
	<comp xsi:type="SXPR_TS" operator="I">
		<comp xsi:type="SXPR_TS">
			<comp xsi:type="PIVL_TS">
     				<phase>
      					<center value="200802040800"/>
     				</phase>
     				<period value="1" unit="d"/>
    			</comp>
			<comp xsi:type="PIVL_TS" operator="I">
     				<phase>
      					<center value="200802041800"/>
     				</phase>
     				<period value="1" unit="d"/>
    			</comp>
		</comp>
    		<comp xsi:type="PIVL_TS" operator="A">
     			<phase>
      				<low value="20080204"/>
				<width value=”1” unit=”d”/>
     			</phase>
     			<period value="5" unit="d"/>
    		</comp>
	</comp>
</effectiveTime>

Toelichting:

In bovenstaand voorbeeld wordt al duidelijk dat voor elk van de intervalschema’s geldt dat de <phase> geankerd wordt op de eerste dag van een periode waarop het gebruik betrekking heeft. Dus in bovenstaande situatie wordt de eerste periode (van telkens 3 dagen) geankerd op 31/1 en de derde periode (van telkens 1 dag) op 4/2. De rustdag wordt niet expliciet aangeduid, maar is een impliciet gevolg van het feit dat tussen de genoemde periodes een dag zonder gebruik zit. Merk op dat rustperiodes niet mogen worden aangeduid door expliciet een periode met een dosering van 0 op te nemen!

GTS.Combinaties van tijdsinterval en herhaalpatroon

Toepassing:

Vanzelfsprekend kunnen alle eerder genoemde herhaalpatronen (zowel enkelvoudig als gecombineerd) voorkomen in combinatie met een tijdsinterval voor de gebruiksperiode. In dat geval wordt één extra niveau van nesting toegevoegd, omdat altijd sprake is van doorsnijding van het gebruiksinterval. Dit betekent dan dat het betreffende patroon van toepassing is binnen het aangeduide gebruiksinterval (zoals bij de meeste voorschriften).

Formaat (voorbeelden):

<effectiveTime xsi:type="SXPR_TS">	gebruiksfrequentie met looptijd
	{ tijdsinterval }
	{ gebruiksfrequentie operator="A" }
</effectiveTime>

<effectiveTime xsi:type="SXPR_TS">		intervalschema met looptijd
	{ tijdsinterval }
	{ intervalschema operator="A" }
</effectiveTime>

<effectiveTime xsi:type="SXPR_TS">	herhalende tijdstippen met looptijd
	{ tijdsinterval }
	{ herhalende tijdstippen operator="A" }
</effectiveTime>

Toelichting:

Als een tijdsinterval wordt gecombineerd met een herhaalpatroon, dan is de regel dat het tijdsinterval als eerste element moet voorkomen in de gecombineerde <effectiveTime>.

Het ondertekend elektronisch voorschrift

Een ondertekend elektronisch voorschrift (voorschrifttoken) bestaat uit twee delen:

• de ondertekende gegevens;
• de bijbehorende elektronische handtekening.

De elektronische handtekening is beschreven in [IH EH UZI-pas] en [IH tokens generiek]. De ondertekende gegevens worden hier behandeld.

EV.Structuur

De structuur van de voor het voorschrift ondertekende gegevens is als volgt:

signedDataPrescription {
  signatureMetaData {
    signatureVersion,
    X509IssuerSerial {X509IssuerName, X509SerialNumber}
  },
  prescription {
    id {root, extension},
    dateTime,
    patient {
      id {root, extension},
      name,
      gender,
      birthdate
     },
    author {
      id {root, extension},
      rolcode {codeSystem, code, displayName},
      name,
      address
    },
    medication {codeSystem, code, displayName},
    quantity {
      repeatNumber,
      value,
      unit {code, displayName}
    },
    usage
  }
}

EV.Gegevens

Dit gegeven is opgenomen in de Soap Header authenticationTokens. Zie voor details hierover de [IH EH UZI-pas] en [IH tokens generiek].

 <signatureVersion>http://www.aortarelease.nl/805/emd/1</signatureVersion>
  <X509IssuerSerial>
    <ds:X509IssuerName>CN=TEST UZI-register Zorgverlener CA,
      O=agentschap Centraal Informatiepunt Beroepen Gezondheidszorg,
      C=NL</ds:X509IssuerName>
   <ds:X509SerialNumber>2754…99</ds:X509SerialNumber>
  </X509IssuerSerial>
</signatureMetaData>

EV.X5091IssuerSerial

Element: X509IssuerSerial
Pad: signedDataPrescription/signatureMetaData
Subelement	Tonen	DT	#	C	LBA	Omschrijving
X509IssuerName	nee	string	1..1	M
	Moet gelijk zijn aan issuer.commonName op certificaat van de voor het tekenen gebruikte pas.
X509Serialnumber	nee	string	1..1	M
	Moet gelijk zijn aan serialNumber op certificaat van de voor het tekenen gebruikte pas.

EV.prescription

In het prescription deel staan de gegevens die betrekking hebben op het recept.

Element: prescription
Pad: signedDataPrescription
Subelement	Tonen	DT	#	C	LBA	Omschrijving
id	deels	iiType	1..1	M	Voorschriftnummer	Zie hieronder.
dateTime	ja	datum-tijd	1..1	M	Datum van tijd en tekenen	Precisie tot seconden; bij tonen aan de zorgverlener mag dit in minuten. Bij het tonen wordt deze met afbreektekens (-) en dubbele punten opgemaakt. Bijvoorbeeld: 2009-11-19 17:36
	Moet overeenkomen met voorschrijftijd in bericht: PORX_IN932000NL/ControlActProcess/subject/Prescription/author/time
patiënt	deels		1..1	M	Patiënt	Zie hieronder.
author	deels		1..1	M	Voorschrijver	Zie hieronder.
medication	deels		1..1	M	Geneesmiddelomschrijving	Zie hieronder.
quantity	deels		1..1	M	Te verstrekken hoeveelheid	Zie hieronder.
usage	ja		1..1	M	Gebruiksomschrijving	Zie hieronder.

Voorbeeld:

<prescription>
  <id>
    <root>2.16.840.1.113883.2.4.6.1.1028432.1.9</root>
    <extension>0000191201</extension>
  </id>
  <dateTime>20100718151043</dateTime> 
  <patient>...</patient>
  <author>...</author>
  <medication>...</medication>
  <quantity>...</quantity>
  <usage>...</usage>
</prescription>

EV.prescription.id

In het HL7 bericht is de eis dat iedere identifier van het datatype II (Instance Identifier) globaal uniek is. Dat wordt gerealiseerd doordat de partij die de II uitgeeft, een unieke OID gebruikt (in II root), en daar de eigen, lokale identifiers aan toevoegt (in II extension). De extension moet dus uniek zijn binnen de gebruikte OID.

Bij een elektronisch voorschrift ligt het voor de hand voorschriftnummers te gebruiken zoals die op een papieren recept ook staan. Deze zijn uniek voor de zorgverlener die het voorschrift opstelt. De applicatie die het elektronisch voorschrift opstelt, dient te borgen dat het voorschriftnummer, dat in extension gebruikt wordt, zowel uniek is binnen de gebruikte root OID als binnen de door de zorgverlener uitgegeven voorschriften.

Element: id
Pad: signedDataPrescription.prescription
Subelement	Tonen	DT	#	C	LBA	Omschrijving
root	nee		1..1	M		Root OID van het voorschrijvend systeem voor voorschriftnummers.
	Root OID van het voorschrijvend systeem voor voorschriftnummers.
EXTENSION	ja		1..1	M	Voorschriftnummer	Feitelijk voorschriftnummer
	Moet overeenkomen met prescription.id in HL7 bericht: PORX_IN932000NL/ControlActProcess/subject/Prescription/id/@extension

Voorbeeld:

  <id>
    <root>2.16.840.1.113883.2.4.6.1.1028432.1.9</root>
    <extension>0000191201</extension>
  </id>

Bij het tonen van de ondertekende gegevens, wordt alleen het voorschriftnummer, dus de waarde in extension getoond. Dit nummer dient dus uniek te zijn voor de voorschrijver.

EV.patient

Van de patiënt worden het BSN en een paar gegevens, zoals die normaliter ook op een papieren recept staan, opgenomen.

Element: patient
Pad: signedDataPrescription.prescription
Subelement	Tonen	DT	#	C	LBA	Omschrijving
id	deels	iiType	1..1	M	BSN patiënt	Zie hieronder
name	ja	string	1..1	M	Naam patiënt	De naam, in een enkele string, zoals deze ook op een papieren voorschrift getoond wordt.
	Geen matching met bericht. De naam moet wel overeenkomen met een eventuele naam in het bericht op logisch niveau, een geautomatiseerde controle is echter te complex.
gender	ja	enum	1..1	M	Geslacht patiënt	Toegestane waarden zijn: 'M', 'V', 'O', 'Man', 'Vrouw', 'Niet-gedifferentieerd'.
	Moet overeenkomen met geslacht in het bericht als dit in bericht is opgenomen. PORX_IN932000NL/ControlActProcess/subject/Prescription/subject/Patient/Person/ administrativeGenderCode/@code
	Geslacht in bericht			Geslacht in token
	leeg			Maakt niet uit
	'M'			'M' of 'Man'
	'F'			'V' of 'Vrouw'
	'UN'			'Niet-gedifferentieerd'
birthdate	ja		1..1	M	Geboortedatum patiënt	Opmaken bij het tonen. Bijvoorbeeld: 1968-08-16.
	Moet overeenkomen met geboortedatum in het bericht als dit in bericht is opgenomen. PORX_IN932000NL/ControlActProcess/subject/Prescription/subject/Patient/Person/ birthTime/@value

Voorbeeld:

  <patient>
    <id>
      <root>2.16.840.1.113883.2.4.6.3</root>
      <extension>012345672</extension>
    </id>
    <name>J.M. Breed</name>
    <gender>Man</gender>
    <birthdate>19680816</birthdate>
  </patient>

EV.patient.id

Element: id
Pad: signedDataPrescription.prescription.patient
Subelement	Tonen	DT	#	C	LBA	Omschrijving
root	nee		1..1	M		Root OID van BSN
	Vaste waarde: 2.16.840.1.113883.2.4.6.3
extension	ja		1..1	M	BSN
	Moet overeenkomen met BSN in HL7 bericht: PORX_IN932000NL/ControlActProcess/subject/Prescription/ subject/Patient/ Hieronder de waarde in de extension van het id met root 2.16.840.1.113883.2.4.6.3'

EV.author

Element: author
Pad: signedDataPrescription.prescription
Subelement	Tonen	DT	#	C	LBA	Omschrijving
id	deels	iiType	1..1	M	UZI nummer voorschrijver	Zie hieronder.
rolecode	deels	codeType	1..1	M	rol	Zie hieronder.
name	ja		1..1	M	Naam voorschrijver
	Geen matching met bericht. De naam moet wel overeenkomen met een eventuele naam in het bericht op logisch niveau, een geautomatiseerde controle is echter te complex.
address	ja		1..1	M	Zorgaanbieder	Het werkadres
	Dit zit niet in het bericht

Voorbeeld:

  <author>
    <id>
      <root>2.16.528.1.1007.3.1</root>
      <extension>006797896</extension>
    </id>
    <rolcode>
      <codeSystem>2.16.840.1.113883.2.4.15.111</codeSystem>
      <code>01.015</code>
      <displayName>Huisarts</displayName>
    </rolcode>
    <name>Dr. Frans Rijtje</name>
    <address>Waterstraaat 14, Nattelanden</address>
  </author>

EV.author.id

Element: id
Pad: signedDataPrescription.prescription.author
Subelement	Tonen	DT	#	C	LBA	Omschrijving
root	nee	iiType	1..1	M		Root OID van UZI nummer
	Vaste waarde: 2.16.528.1.1007.3.1
extension	ja		1..1	M	UZI nummer voorschrijver	Feitelijk voorschrijfnummer
	Moet overeenkomen met UZI nummer in HL7 bericht: PORX_IN932000NL/ControlActProcess/subject/Prescription/author/AssignedPerson/id Hieronder de extension van het id met root 2.16.528.1.1007.3.1
	Moet gelijk zijn aan subject.serialNumber op certificaat van de voor het tekenen gebruikte pas.

De author van de ondertekende gegevens dient dezelfde te zijn als de author van de payload. Dit is de voorschrijver, de auteur van het medicatievoorschrift. Het UZI-nummer van de author dient overeen te komen met

De authorOrPerformer uit de Control Act Wrapper is degene die het authenticatietoken getekend heeft. Dit kan de arts zijn die voorschrijft, maar ook een gemandateerde medewerker.

De overseer is bij mandatering degene die de medewerker, die authorOrPerformer is, mandateert. Veelal zal dat de auteur van de payload zijn.

EV.roleCode

Element: rolecode
Pad: signedDataPrescription.prescription.author
Subelement	Tonen	DT	#	C	LBA	Omschrijving
codeSystem	nee		1..1	M
	Vaste waarde: 2.16.840.1.113883.2.4.15.111
code	nee		1..1	M		Rol van de zorgverlener
	Moet overeenkomen met de waarde van rol in subjectAltName.otherName op certificaat van de voor het tekenen gebruikte pas. Wanneer de rol van de auteur van de payload gevuld is, moet deze hier aan gelijk zijn: PORX_IN932000NL/ControlActProcess/subject/Prescription/author/AssignedPerson/id
displayName	ja		1..1	M		Leesbare omschrijving van de rol.
	Moet overeenkomen met de rolnaam in 2.16.840.1.113883.2.4.15.111.xml

EV.medication

Element: medication
Pad: signedDataPrescription.prescription
Subelement	Tonen	DT	#	C	LBA	Omschrijving
codeSystem	ja		1..1	M
	Moet overeenkomen met bericht: PORX_IN932000NL/ControlActProcess/subject/Prescription/directTarget/prescribedMedication/MedicationKind/code/@codeSystem
code	ja		1..1	M	Medicatiecode
	Moet overeenkomen met bericht: PORX_IN932000NL/ControlActProcess/subject/Prescription/directTarget/prescribedMedication/MedicationKind/code/@code
displayName	ja		1..1	M	Geneesmiddelomschrijving
	Moet overeenkomen met bericht (deze is ook verplicht gevuld bij medicatie): PORX_IN932000NL/ControlActProcess/subject/Prescription/directTarget/prescribedMedication/MedicationKind/code/@displayName

Voorbeeld:

<medication>
    <codeSystem>2.16.840.1.113883.2.4.4.7</codeSystem>
    <code>999999</code>
    <displayName>Acetylcyteine pch poeder skvr 600mg in sachet</displayName>
  </medication>

Een alternatieve vulling is er voor magistrale receptuur.

Element: medication
Pad: signedDataPrescription.prescription
Subelement	Tonen	DT	#	C	LBA	Omschrijving
desc	ja	string	1..1	M	Geneesmiddelomschrijving	Magistrale receptuur
	Moet overeenkomen met bericht: PORX_IN932000NL/ControlActProcess/subject/Prescription/directTarget/prescribedMedication/MedicationKind/desc

Voorbeeld:

  <medication>
    <desc>Hier staat een beschrijving van de magistrale receptuur.</desc>
  </medication>

EV.quantity

Element: quantity
Pad: signedDataPrescription.prescription
Subelement	Tonen	DT	#	C	LBA	Omschrijving
iter	ja, als aanwezig	positieve integer	1..1	R	Iter	Aantal herhalingen, indien van toepassing
	Een waarde van 0 wordt bij voorkeur niet opgenomen. Wanneer er sprake is van deelverstrekkingen is dit een waarde >= 1. Een waarde van 0 betekent niet herhalen, en is logisch gelijk aan afwezigheid. Moet overeenkomen met de waarde in PORX_IN932000NL/ControlActProcess/subject/Prescription/directTarget/prescribedMedication/productOf/medicationDispenseRequest/repeatNumber waarbij geldt iter = repeatNumber - 1
value	ja	string	1..1	M	Aantal te verstrekken eenheden
	Moet overeenkomen met de waarde in PORX_IN932000NL/ControlActProcess/subject/Prescription/directTarget/prescribedMedication/productOf/medicationDispenseRequest/quantity/@value
unit		string	1..1	M	Eenheden	Zie hieronder.

Voorbeeld:

<quantity>
    <repeatNumber>2</repeatNumber>
    <value>56</value>
    <unit>
      <code>1</code>
      <displayName>stuks</displayName>
    </unit>
  </quantity>

EV.unit

Element: unit
Pad: signedDataPrescription.prescription.quantity
Subelement	Tonen	DT	#	C	LBA	Omschrijving
code	nee		1..1	M		Code volgens UCUM; zie elders in deze gids.
	Moet overeenkomen met de waarde in PORX_IN932000NL/ControlActProcess/subject/Prescription/directTarget/prescribedMedication/productOf/medicationDispenseRequest/quantity/@unit Wanneer de waarde in code "1" is, mag genoemd attribuut unit in het HL7 bericht ook ontbreken.
displayName	ja		1..1	M		Omschrijving van de code volgens UCUM; zie elders in deze gids
	Zit niet in het bericht, maar is opgenomen als leesbare weergave. Bij code '1' mag de displayName 'stuks' zijn of leeg; anders de tekstuele weergave horende bij de code. Deze kan hetzelfde zijn (mg en mg), mag uitgebreider zijn (mg en milligram) en is nodig wanneer de code niet direct herkenbaar is. De displayName is wat de zorgverlener ziet, de code is voor matching met het bericht. Het verzendende systeem dient ervoor te zorgen dat code en displayName semantisch gelijk zijn.

XML-voorbeeld

<unit>
  <code>1</code>
  <displayName>stuks</displayName>
</unit>

<unit>
  <code>1</code>
  <displayName></displayName>
</unit>

<unit>
  <code>mg</code>
  <displayName>milligram</displayName>
</unit>

<unit>
  <code>mg</code>
  <displayName>mg</displayName>
</unit>

<unit>
  <code>[tsp_us]</code>
  <displayName>theelepel</displayName>
</unit>

EV.usage

Element: usage
Pad: signedDataPrescription.prescription
Subelement	Tonen	DT	#	C	LBA	Omschrijving
	ja	string	1..1	M	gebruiksomschrijving
	Geen matching met bericht.

De inhoud van usage moet inhoudelijk overeenkomen met de inhoud van de medicationAdministrationRequest elementen in het bericht. Omdat de vorm in het HL7v3 bericht heel anders is (gecodeerde informatie) vindt er geen matching plaats met het bericht. De zender dient ervoor te zorgen dat de tekstuele weergave in de ondertekende gegevens overeenkomt met het HL7v3 bericht.

Voorbeeld:

  <usage>eerst 2 weken lang 2x daags 2 tabletten dan aansluitend 2 weken lang 2x daags 1 tablet en 4 weken lang 1x daags 1 tablet</usage>

EV.Complexe datatypes

In het token worden niet de standaard HL7v3-datatypes gebruikt. Over het algemeen worden de datatypes van XML Schema gebruikt. Hier een overzicht van de overige gebruikte dataypes.

EV.Enkelvoudige datatypes

Datatype	Afgeleid van	Omschrijving
datumtijd	xs:string	Datum en tijd met precies in seconden; formaat JJJJMMDDUUMMSS. Bijvoorbeeld: 20101119171853
datum	xs:string	Datum; formaat JJJJMMDD. Bijvoorbeeld: 20101119

EV.iiType

Type: iiType
Subelement	DT	#	C	LBA	Omschrijving
root	string	1..1	M		Moet een OID zijn.
extension	string	1..1	M

EV.codeType

Type: codeType
Subelement	DT	#	C	LBA	Omschrijving
codeSystem	string	1..1	M		Moet een OID zijn die een coderingsstelsel identificeert.
code	string	1..1	M		De bijbehorende code.
displayName	string	0..1	M		Displayname is veelal optioneel in een HL7v3-bericht. In het kader van de elektronische handtekening is het vullen verplicht: er moet een menselijk leesbare representatie van de gegevens zijn.

PH.Bijlage:Referenties

De onderstaande documenten zijn beschouwd als leidend voor dit document:

Tabel 9 Referenties

Referentie	Document	Versie
[DO]	Documentatieoverzicht	6.11.0.0
[Verklarende woordenlijst]	Verklarende woordenlijst	6.11.0.0
[DD medicatiegegevens]	Domeindefinitie medicatiegegevens	6.12.0.0
[HL7v3 IH Wrp]	HL7v3-implementatiehandleiding berichtwrappers	6.11.0.0
[HL7v3 IH Basis]	Implementatiehandleiding HL7v3 basiscomponenten	2.2
[IH tokens generiek]	Implementatiehandleiding security tokens generiek	6.11.0.0
[IH EH UZI-pas]	Implementatiehandleiding elektronische handtekening met UZI-pas	6.11.0.0

PH.Bijlage: Overzicht gebruikte OIDS

Tabel 10 Overzicht OID's

OID	Beheerder	Nederlandse omschrijving
2.16.528.1.1007.3.1	UZI-register	universele zorgverleneridentificatie
2.16.528.1.1007.3.3	UZI-register	UZI-register abonneenummers
2.16.840.1.113883.2.4.4.1	Z-Index	G-Standaard generieke productcode (GPK)
2.16.840.1.113883.2.4.4.1.361	NHG	tabel 25 eenheden gebruiksadvies (a code numeriek)
2.16.840.1.113883.2.4.4.1.900.2	Z-Index	G-Standaard basiseenheden
2.16.840.1.113883.2.4.4.5	NHG	tabel 25 aanvullende teksten (b code numeriek)
2.16.840.1.113883.2.4.4.7	Z-Index	G-Standaard handelsproductcode (HPK)
2.16.840.1.113883.2.4.4.8	Z-Index	G-Standaard artikelnummer/KNMP-nummer
2.16.840.1.113883.2.4.4.9	Z-Index	G-Standaard toedieningswegen
2.16.840.1.113883.2.4.4.10	Z-Index	G-Standaard prescriptiecode (PRK)
2.16.840.1.113883.2.4.4.11	Z-Index	G-Standaard farmaceutische vormen
2.16.840.1.113883.2.4.4.12	Z-Index	G-Standaard deelverpakkingen
2.16.840.1.113883.2.4.4.31.1	NHG	Diagnosecodes volgens ICPC-1-2000NL
2.16.840.1.113883.2.4.6.1	Vektis	AGB-Z zorgverleneridenticatie
2.16.840.1.113883.2.4.15.111	HL7 Nederland	PractitionerRoleNL (zorgverlenerrollen)
2.16.840.1.113883.5.4	HL7 internat.	ActCode (algemene classificatie voor Acts)
2.16.840.1.113883.6.2	NCHS	ICD-9-CM diagnosecodes
2.16.840.1.113883.6.73	WHO	Anatomical Therapeutical Classification (ATC)