7phcy:V6.12 GTS.inleiding

{{#customtitle:Inleiding|Inleiding}}

Dit materiaal is onderdeel van HL7v3-domein Pharmacy V6.12_HL7v3-domeinspecificatie_Pharmacy. Compatible wijzigingen/nadere bewoordingen, tikfouten kunnen direct in de Wiki gewijzigd worden Open issues die discussie vergen s.v.p. in de commentaarsectie opnemen.

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.