7phcy:V6.12.7 medicationAdministrationRequest.text: verschil tussen versies
(Copy of V6.12.3) |
k (Tekst vervangen - "{{DISPLAYTITLE:.*}}" door "") |
||
| (Een tussenliggende versie door dezelfde gebruiker niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
| − | + | ||
<noinclude>{{DocumentPart|ns=7phcy|title=V6.12.7_HL7v3-domeinspecificatie_Pharmacy}}</noinclude> | <noinclude>{{DocumentPart|ns=7phcy|title=V6.12.7_HL7v3-domeinspecificatie_Pharmacy}}</noinclude> | ||
Huidige versie van 25 aug 2020 om 14:07
Dit materiaal is onderdeel van HL7v3-domein Pharmacy V6.12.7_HL7v3-domeinspecificatie_Pharmacy.
|
medicationAdministrationRequest.text
<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.
|
|
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). |
|
|
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:
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. |
|
|
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. |
|
|
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>