Medication Modelling

Related Links Pharmacy Home Page

MEDICATION DOMAIN

This section of the document contains information about the medication model, including how it was develped and a section on medication requirements.

MEDICATION MODEL

Introduction

This Medication Model deals with the description of a medicine for the purposes of messaging information about medicines.

Using a medicine is the most common intervention made in the practice of healthcare, and as such, a medicine is referenced in an almost bewildering variety of processes, contexts, domains and applications. These range from prescribing a medicine for administration to an individual patient, through recording that in an electronic health record, referencing it in the ordering of a laboratory test and in the interpretation of that test result, referencing it in a clinical communication to another healthcare professional, to requesting and receiving payment for the medication from a reimbursement organisation.

In addition, information about medicines is required to support a variety of clinical, decision support, regulatory and public health monitoring/investigative operations.

In order to have harmony and consistency in the representation of the requirements for these diverse yet clearly related applications, and because of the central importance of the entity commonly described as a "medicine" to the practice of healthcare, the Pharmacy Special Interest Group have produced an overarching model of the elements required in the description of a medicine. The aim is that each domain area that has a need to describe "medication" can take the relevant elements in their structure from this model to produce a medication model (Domain X Medication CMET) that meets their needs, without having extraneous information required for another domain, whilst retaining overall consistency of both the structure of the representation and the definition of the objects involved. Implementers should be aware that Pharmacy has been an active participant in the development of the Common Product Model (CPM) under the auspices of Orders and Observation. Once the CPM becomes stable, it is expected that Pharmacy will undertake to develop and ballot a Medication Model Release 2 which will be a constrained version of the overarching CPM.

As with all Version 3 structures, each concept and attribute used has definition, and, if appropriate, vocabulary or a vocabulary domain to support its use. Realms and enterprises may extend or constrain vocabulary as appropriate, according to the V3 rules for this. Where possible, if implementations find significant additional requirements for vocabulary are necessary, we would be grateful if these were brought back to the Pharmacy SIG for discussion and resolution on an international basis.

In building this model, there is a commitment to capture requirements at a level that supports all the known realm-specific issues, but to describe these in as generic and as widely applicable manner as possible (for example, various realms and domains have the concept of "equivalence" and this features in the model; however, the generic concept of equivalence must be fully described and implemented according to local business practice at a level below this overarching model). The requirements themselves are detailed in the Storyboard section of this ballot. Over time, as new requirements emerge, these will be analysed and included, to ensure that the model remains appropriate for use throughout V3 Communication.

There is no dynamic modeling accompanying the Medication Model. This is because it is describing a group of entities and the relationships between them, for use within communications, rather than clinical processes using complete communications between applications, for which a dynamic model can be described. As detailed above, CMETs can and should be derived from the overall model, to describe medication in the way that is most appropriate for the business process of each domain. For example, Reimbursement use cases will probably be very interested in pack size information, but have little requirement to know, in a message, who licenced the medicine.

MEDICATION MODEL REQUIREMENTS

Introduction

In all cases of messaging to support clinical processes, there is an assumption that systems will be of a level of sophistication such that a modeled vocabulary (terminology) to describe medicines in a clinically recognisable form is being used. The terminology will provide a variety of factual information about the medicine to all its users and therefore this factual information does not need to be messaged from one system to another.

The following requirements therefore detail the information about a medicine that must be passed between systems in order to provide the necessary information for the message to be received and interpreted correctly.

Prescribing Requirements

This relates to the requirements to describe a medicine in the Substance Administration Act in the mood of "Request" (with or without a supply act combined) - "Please give this medicine" .

The core requirement for prescribing (ordering) a medication for administration to an individual patient is to identify the medication at any given level of abstraction present within the terminology model being used to provide the vocabulary for medication. This level of abstraction will vary according to the business rules both of the setting (e.g. community or institution) and realm, but is likely to range from a description purely of the therapeutic moiety to be given (leaving selection of the product to another healthcare professional or application) through a product description (generic or proprietary, including the name of the manufacturer, if necessary) to the description of a particular pack of a medication (and the pack may or may not have an additional administration device specified as included).

Prescribing of a medication will always occur at the "kind" level; the prescriber has no control over which one absolute real world thing will be supplied and/or administered. Batch number and expiry information will therefore not be required nor available.

In situations where there is some concern as to the shared nature of the medicines terminology being used by the communicating systems to describe the medication, or in circumstances where an extemporaneous (magistral) recipe medication is to be compounded for administration (for example, for a complex intravenous infusion such as parenteral nutrition), it may be necessary to give an additional description of the medication by describing its components - ingredients with their amounts, the overall dose form, etc. Again, local business rules will dictate whether or not a total quantity of the recipe medication must be stated by the prescriber. There may be a need to state that a particular ingredient is itself made up of components.

There is a requirement to be able to make comment about an ordered medication, such as "not to contain substance x", for example, sugar, gluten, preservative, colour.

There is a requirement to be able to describe the Medication in terms of an equivalent concept that is separate from the description of the Medication itself, for example to describe both a proprietary product Medication, and the generic representation of this, as separate and distinct concepts.

There is a requirement for the prescriber to be able to specify particular attributes of the container used for the medication, such as an easy-open top, or a compliance pack.

Dispensing Requirements

This first section relates to the requirements to describe a medicine in the Supply Act in the mood of "Promise" and/or "Request" - "I will be supplying" or "Please supply"

The core requirement is to describe a medication to be supplied in recognisable real world terms, in various levels of abstraction depending on local business process rules, ranging from a generic description of a product through to the description of the particular proprietary pack of medication, which may also contain an administration device.

This description will occur at the "kind" level, as the one actual real world item to be supplied has yet to be identified. Batch number and expiry information will not be required nor available.

This second section relates to the requirements to describe a medicine in the Supply Act in the mood of "Event" - "I have supplied"

The core requirement is to describe the medication that was supplied, both in terms of the actual manufactured product, and in terms of the pack that it was supplied in. In addition, depending on local business process rules, there may be a requirement to describe the medication as an amount taken from one or more of a manufacturers pack (container) and supplied in a (dispensing) container , which may also contain or be supplied with an administration device, if appropriate.

This description will occur at the "instance" level, as it represents the actual real world item(s) that have been supplied and which can be physically held and identified. The requirement to have batch number and expiry information will depend on local business rules, but should be available if required.

In order to make claims for reimbursement for dispensing medications, the requirement to identify the size and price of the original container that the dispensing supply was taken from (for example, 50 tablets taken from a "stock" pot of 1000 tablets).

Packs of medicines as supplied from a manufacturer generally have a UPC code (also known variously as the GTIN code or the EAN code); there is a requirement to be able to use this identifier is acknowledged.

Dispensed medication may also require additional information about that medication, such as "risk" and "handling" information (for example: 'Shake the Bottle', 'Store in the Refrigerator').

For all dispensing processes, there may be the requirement as stated above to be able to describe the dispensed Medication in terms of an equivalent concept that is separate from the description of the Medication itself, for example to describe both a proprietary product Medication, and the generic representation of this, as separate and distinct concepts.

Administration Requirements

This relates to the requirements to describe a medicine in the Substance Administration Act in the mood of "Event" - "I have administered this medicine" For prescribing administrations, see above .

The core requirement for recording the event of administration of a medication to an individual patient is to describe and identify the actual medication that was used to make the administration, from which manufactured pack (even if an extemporaneous preparation was prescribed, this must be "manufactured" into a real product in order to be able to be administered. If a part of a pack was used, this must be able to be clearly differentiated too.

This description will occur at the "instance" level, as it represents the actual real world item(s) that have been administered and which are physically identifiable. The requirement to have batch number and expiry information will depend on local business rules, but should be available if required.

Public Health (Reporting) Domain Requirements

Whilst the majority of communication in the Public Health (Reporting) domain is likely to be using systems with a level of sophistication such that a modelled vocabulary (terminology) to describe medicines in a clinically recognisable form is being used, there may be occasion when this is not the case. Therefore the requirement to have the facility to communicate greater detail about the factual information of the medicine than would be required in a purely clinical communication must be recognised.

The following requirements therefore detail the information about a medicine that must be passed between systems in order to provide the necessary information for a Public Health report message to be received and interpreted correctly.

The report will need to capture a description of the (suspect) medication in as much detail as can be provided. If a modelled medications vocabulary is shared between the communicating systems, this is a considerably easier task, but in environments where that is not likely, the organisation receiving reports from diverse sources throughout healthcare, and possibly beyond (for example, from legal representatives) must be able to collect all the relevant information in order to identify the medicine accurately. As well as information about the name of the medicine, its active ingredients, their strength(s) and its dose form, there is a requirement to detail as much information as possible about the pack or container the medicine was supplied in, and from this, the batch number and possibly the expiry date of the medication. The contents of the pack (and possibly even the sub-pack, especially for vaccines) may require description in detail, including information about any devices supplied with the medication in the pack. In addition to a description of the medication, an indication of equivalence (for example, the generic description of a proprietary product) may be required, partly for verification and partly for information categorisation and analysis at a later stage.

As in the clinical domain, there is a requirement to be able to describe the Medication in terms of an equivalent concept that is separate from the description of the Medication itself, for example to describe both a proprietary product Medication, and the generic representation of this, as separate and distinct concepts.

Details of the provenance of a medicine, such as its manufacturer, and possibly other information about its progress through the supply chain (wholesale and/or retail) may also be required. Because of the nature of the pharmaceutical industry, there is sometimes more than one "manufacturer" of a particular product, as items are re-packaged in the supply chain process. Detailing this is both complex and time-consuming and, at a modelling level, requires such a specificity of definition of concepts as to be almost unmanageable. Therefore, the term "manufacturer" is taken to be the organisation having regulatory responsibility for the production of the medicine for sale in the particular realm under consideration.

In some cases, there will be a requirement to capture the manufacturer of the ingredients of a medicine; this is a requirement for some of the Regulatory Affairs domains, but is also a requirement in the case of reporting of an Adverse Event involving a medication that has been compounded (a magistral).

As the information collected in the Public Health domain is designed for amalgamation and analysis across both time and other axes, it may be pooled from a variety of sources, and sometimes even a variety of realms. There may therefore be the requirement to capture regulatory authority information applicable to the medication as part of the overall description of the medicine.

Masterfile Requirements

When communicating Medicine Masterfile information in a modeled and structured communication such as an HL7 V3 message, it is almost a case of reproducing the terminology model of the masterfile being communicated. This is likely to contain a variety of "clinical knowledge" type concepts (such as known contra-indications, allergen groups etc.) as well as the more factual pharmaceutical information used in the description of a medication. Consequently, the requirements are not fully and individually articulated in this current specification. Readers are directed to read the Structured Product Label ballot, as this contains patterns for the description of this type of clinical knowledge information.