Domain Message Information Model - Pharmacy

Dit materiaal is onderdeel van HL7v3-domein Pharmacy V6.12.8_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.

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.