Pharmacy
 ANSI/HL7 V3 RXMDSVNT, R1-2012 HL7 Version 3 Standard: Pharmacy; Medication Dispense and Supply Event, Release 1 3/23/2012 |
ANSI/HL7 V3 RXMEDORDER, R1-2009 HL7 Version 3 Standard: Pharmacy; Medication Order, Release 1 9/10/2009 |
| Responsible Group | Pharmacy Work Group HL7 |
| Vocabulary Facilitator | Julie James, MRPharmS julie_james@bluewaveinformatics.co.uk Blue Wave Informatics |
| Pharmacy Workgroup Co-Chair | Robert Hallowell robert.hallowell@siemens.com Siemens |
| Pharmacy Workgroup Co-Chair | Hugh Glover hugh_glover@bluewaveinformatics.co.uk Blue Wave Informatics |
| Pharmacy Workgroup Co-Chair | Melva Peters jenaker@telus.net Jenaker Consulting |
| Pharmacy Workgroup Co-Chair | Garry Cruickshank garry.cruickshank@gpinformatics.com Gordon Point Informatics Ltd. |
| Pharmacy Workgroup Co-Chair | Tom de Jong tom@nova-pro.nl Nova Pro Consultancy |
| Modeling Facilitator | Jean Duteau jean.duteau@gpinformatics.com Gordon Point Informatics Ltd. |
| Contributor | John Hatem john.hatem@oracle.com Oracle |
HTML Generated: 2012-09-02T15:10:11
Content Last Edited: 2012-03-06T13:34:34
HL7® Version 3 Standard, © 2009-2012 Health Level Seven® International All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of these materials is governed by HL7 International's IP Compliance Policy.
Table of Contents
Preface
i Notes to Readers
ii Message Design Element Navigation
1 Overview
1.1 Introduction & Scope
1.2 Domain Information Models
1.3 Storyboards
2 Medication Order Topic
2.1 Introduction
2.2 Application Roles
2.3 Trigger Events
2.4 Refined Message Information Models
2.5 Hierarchical Message Descriptions
2.6 Interactions
3 Medication Dispense Event Topic
3.1 Introduction
3.2 Application Roles
3.3 Trigger Events
3.4 Refined Message Information Models
3.5 Hierarchical Message Descriptions
3.6 Interactions
4 Quality Analysis Report Topic
5 CMETs Defined by this Domain
6 CMETs Used by this Domain
7 Interactions Annex
7.1 By Application Role
7.2 By Trigger Event
7.3 By Message Type
8 Glossary
PREFACE
May 2009 Ballot
Re-ballot Medication Order Topic. All changes were based solely on the Ballot Reconcilliation Package.
January 2008 Ballot
Re-ballot the Medication Order Topic. Made changes based on the ballot reconciliation for the Medication Order Topic. The R-MIM attribute descriptions were added.
May 2007 Ballot
Continue balloting domain topics at committee due primarily to restructuring PORX domain message information model (DMIM) to align with Common Order pattern. Individual models, derived from the DMIM still required verification to ensure they are proper subsets of the DMIM. In addition, Device topics have been removed from Committee ballot (included as Informative) in order that they be aligned with the Common Order pattern. In addition, the Pharmacy SIG is working with other committees to include Shared Messages and common CMETs required by Pharmacy in other ballot topics (these were previously balloted by Pharmacy as proposed topics, during past ballot cycles).
January 2007 Ballot
Re-balloted this domain as committee following significant progress on resolution of outstanding ballot reconcilation comments. Items of significance include updating the DMIM to offer a choice of header/no header in RMIM design, relaxing cardinalities to universalize the models originally developed by realms, and changing "drug" to "medication".
September 2006 Ballot
Re-balloted the May 2006 domain as informative, as no substantial progress was made on resolving outstanding ballot reconcilation comments.
May 2006 Ballot
Further refinements on the January 2006 ballot.
January 2006 Ballot
This ballot contains significant new content that was previously introduced as Informative in the previous ballot cycle. Balloters are requested to review the complete domain content in detail. Harmonized domain content has been sourced from numerous international projects, including Canada, UK, Netherlands as well as institutional pharmacy requirements.
It is anticipated that materials from the POIZ (Immunizations) domain will be included in this domain for a subsequent ballot.
This ballot contains a set of application roles for illustrative purposes only (application roles are not-normative materials). Given the broad variations in existing and planned implementation architectures, particularly for electronic prescribing initiatives and distributed EHR implementations in various realms, it is impossible to describe all the possible application roles that might be required. It is currently anticipated that each implementation will need to define its application roles in tight alignment with its chosen architecture. Therefore, application roles included in this ballot are for information only and will be adjusted in a subsequent ballot.
This ballot also contains proposed shared messages and CMETs that have not yet been accepted/proposed to HL7. These are noted as Pharmacy Proposed Shared Message Topic and Pharmacy Proposed CMETs Topic.
August 2005 Ballot
This ballot sees the addition of significant content in support of 'institutional' pharmacy. It has also reorganized the content into different topics and changed business names to be more 'user-friendly'. Hopefully these changes will enhance the readability of the specification. This ballot also includes informative content from some of the HL7 international affiliates. The committee intends to internationalize some of this content for inclusion in future specifications. Comments on priorities and needed changes to adopt the content to international needs would be most welcome.
May 2005 Ballot
This ballot sees only minor changes from the last as we have addressed negative comments and done some tidying up.
January 2005 Ballot
Since the last ballot we have done yet more work to the Medication Model and this has now moved into a separate domain.
Within this pharmacy domain ballot we have done a total overhaul of the D-MIM and R-MIMs. The design work was done at an out of cycle meeting in Toronto in October 2004. As you look at the new D-MIM and R-MIMs presented here there are a number of data types and data type flavours indicated in anticipation of developments through harmonisation and tooling work. Some of our harmonisation proposals were tabled at the last harmonisation meeting and we shall continue to work through the harmonisation we require. Future DSTU releases will reflect the harmonisation decisions that have been reached.
Harmonization
Some items are subject to harmonisation agreement. These have been noted on the drawings where the changes have been pre-adopted.
|
||||||||||||
|
PHARMACY DOMAIN
Introduction
The Pharmacy domain deals with
- Messaging to support the prescription (also known as request or order), dispensing (also known as supply) and administration of medications (also known as drugs), in both a Community (e.g. family practice or community pharmacy) and an Institutional (e.g. hospital) setting. These activities may also occur between or across care settings. Note: a hospital can order a drug to be dispensed in a community pharmacy.
- The messaging to support the requesting of information about drugs dispensed or prescribed in a patient medication record.
Prescribing and Dispensing
Pharmacy Domain Topic Scopes Medication Order Topic This topic deals with all content related to the ordering of medications, both for dispensing (supply) and for administration. It is intended to cover community prescribing, discharge prescriptions and institutional medication orders. The models are intended to support the requirements of all jurisdictions. Appendix - Dosage Instruction Topic The representation of instructions to the patient, for medication self administration, or to the patients agent (usually a nursing practitioner in institutional health care settings) for medication administration is a key clinical function. Medicines, even when prescribed judiciously and appropriately, can only be effective and safe if administered as intended. Many medication adverse events occur due to errors in the recording, interpreting and performance of dosage instructions. Considerable evidence has demonstrated the capacity of information and communication technology to minimize errors in medication prescribing and use. An example of this is the ability to flag medication orders which are due to expire or where calculation of expected rate of consumption of medicines does not match with the actual quantities prescribed. Increasing sophisticated clinical information systems are capable of monitoring medication administration and monitoring and alerting for missed or repeated doses. To achieve use cases such as these it is essential that not only are medicines unequivocally identified but also that the dosage instructions are recorded in a way that can be interpreted by the people involved (prescriber, dispenser, health care workers and patients or their agents) as well as the computerized medication management systems. While it may not seem all that difficult to computerize the concept of "take one table, three times a day", the reality is that dosage regimens can be extremely complex and that event simple instructions assume a lot of implicit knowledge. For example in the above case does this mean take "the tablet every 8 hours exactly" or just "take 3 spaced out as well as possible in a 24 hour period during waking hours and at convenient times." Most of the time this does not matter greatly, however there are times when it does and being able to deal with these does pose a challenge to health care professionals and computer information systems. This being said the common approach to dealing with representation of dosage instructions in health ICT systems is to use "free text" which meets the human readability criteria, but does not support reliable machine processing. The HL7 Pharmacy Special Interest Group (and others such as the National Council on Prescription Drug Programs or NCPDP) have recognized the need to systematically tackle the issue of representation of medication dosage instructions.
Prescribing is an activity that can be performed by a variety of healthcare professionals and involves a variety of orderable items (see glossary entry). For the purposes of the following ballot material, prescribing is defined as the act of prescribing a medication in either an ambulatory or an institutional setting. This could include initiating a new medication order or making all kinds of modifications to existing orders.
Dispensing is an activity undertaken to fulfill the logistical requirements of a prescription. It supplies the materials needed to perform the prescribed actions by those who will perform them. Examples of dispensing include eyeglasses, contact lenses and medications. For the purposes of the following ballot material, dispensing is defined as supplying a medication in fulfillment of a prescription or medication order. While dispensing in these circumstances would usually be performed by a pharmacist, other health care providers such as nurses or physicians might also dispense medications. Additionally, in terms of the topics within this ballot, supply of medication in single units or bulk quantities, usually to a ward or unit, without any information on its likely use/administration is included.
Those familiar with using HL7 version 2.x messages will be looking at the version 3 approach with a view on both comparison with data items and functions covered under version 2 and will be interested in the terms used to describe identical or similar concepts in version 2 and version 3. Now that version 3 is becoming well developed, a workgroup is examining these issues and this is expected to result in publication of a comparison, and if necessary refinement of the version 3 content during the ongoing development of the standard.
It is acknowledged that the scope of the HL7 version 3 pharmacy interactions or messages in this ballot is still limited, and will not be able to address all the interactions currently being used by implementers of version 2 messages or other legitimate use cases. A limited number of interactions covering the promise mood are now included to close this gap.
Messages dealing with use cases not yet documented in this ballot will be included in time, subject to a requirement being identified. This is a deliberate policy of the Pharmacy Special Interest Group in the interests of completing the ballot cycle and publishing a standard for at least a sample group of interactions.
Contents of This Section of the Document
This section covers the following background issues:
- Medication Management Architectures, Applications and the Dynamic Model - this explains the relationship between real life medication management system applications, the architectures that they operate in and the dynamic model we have used.
- Medication Processes - this briefly introduces the main clinical processes and the concepts that represent them. These elements are later related to the static model in the DMIM and RMIM walkthroughs.
- Implementation Issues - here we bring together some areas of implementation guidance for the description of "Timing" in the domain, including using GTS to represent Dose timings and the relationship between real world prescription IDs and Act IDs
1. Medication Management Architectures, Applications, and the Dynamic Model
The Dynamic model describes the ways different real world systems interact (send messages) in the process of supporting medication management.
ArchitecturesThe establishment of electronic prescribing and dispensing solutions, particularly in a community pharmacy context, is significantly impacted by legislative and business dynamics in an implementing setting. These dynamics, in turn, drive substantial variations in implementation architectures.
Since the specifications in this Pharmacy ballot are intended to support the broadest spectrum of such architectures, a given implementation can be expected to be supported by a subset of interactions.
This following specimen architectural patterns have been identified and should be considered by readers.
"Hub-based" Architectures
These are characterised by "prescribe" messages being sent to a central repository by clinical applications that support the prescribing process. In order for the clinical function of dispensing to take place, dispensing applications must obtain the requisite information from the central repository. There will be a variety of ways that this information is requested and sent (queries, requests etc.) and a variety of "exceptions" (e.g. prescription already at another pharmacy) and types of "responses" that may occur or be required. This will depend, in part, on the extent to which the hub plays a co-ordinating role.
Note that the hub-based architectures can/do support designating the dispenser that the prescriber/patient wants to perform the dispensing (nomination or targeting), but that this is in the message payload, and must be actioned by the hub application functionality; it is not in the message transmission wrapper.
The hub-based architectures are of particular application in the community sector, and implementation examples of this can be found in the Canadian Electronic Drug (CeRx) specification and the English National Health Service's (NHS) Connecting for Health (CfH) Electronic Transfer of Prescriptions programme.
Directed (point-to-point) Architectures
These are characterised by "prescribe" messages being sent directly to the dispenser (or to a system that takes responsibility for dispensing, as in a hospital pharmacy system that then directs the prescription to a robotic dispensing system for filling). The dispensing system may or may not communicate directly back to the prescriber: in some models, a "promise" may be returned, confirming to the prescriber that an action will take place in response to the "prescribe; in other models, no information is returned.
The directed architectures are of particular application to the institutional sector, but may also be used in the community. An implementation example of this would be the EMD (Elektronische Medicatie Dossier) initiative currently being implemented in the Netherlands under the sponsorship of NICTIZ (National IT Institute for Healthcare).
Applications
This ballot contains a set of application roles for illustrative purposes only and these form non-normative content. Given the broad variations in existing and planned implementation architectures, particularly for electronic prescribing initiatives and distributed EHR implementations in various realms, it is impossible to describe all the possible application roles that might be required. It is currently anticipated that each implementation will need to define its application roles in tight alignment with its chosen architecture.
The following proposed 'illustrative' application role stereotypes have been identified. Corresponding application roles are defined in those topic areas where interactions exist that are appropriate to be sent from or received by these stereotypes:
| Prescribing System | A system intended to support a clinician with prescribing authority. |
| Dispensing System | A system intended to support a clinician with dispensing authority. |
| Administering System | A system intended to support a clinician in the recording or updating of medication administrations. |
| EHR System | A system intended to act as a clinical repository. In the context of this domain the shared medication repository aspect of EHRs reflects the dominant use case. |
| ePrescribing Hub | A system intended to intermediate between prescribers and dispensers. |
| Drug Knowledge Base | A system intended to provide information (knowledge) about medications including, but not limited to, monographs and drug-to-drug interactions. |
Please note the following additional considerations:
- Interactions will only be defined as optional against the most appropriate application role for illustrative and roll-up purposes.
- In certain architectures the medication repository component of the EHR is tightly coupled with - and partially enabled through - ePrescribing capabilities; for readers familiar with these architectures the separation in the "EHR System" and "ePrescribing Hub" roles may appear non-intuitive.
- The application role numbering scheme proposed deviates from the normal numbering scheme adopted in this domain to reflect the illustrative nature of these roles. It is not anticipated that these roles would themselves be specialized on a realm specific basis.
- These application roles are described in system functionality terms, using words that are familiar in a business sense. They are deliberately not defined in the V3 stereotypical terms of "placer-filler", "informer-tracker" terms, as these are more granular and relate to the role of an application for any one particular interaction in any one particular context.
It is anticipated that these roles will eventually be aligned more appropriately with the topic breakdown for this domain.
Statechart
A focal act has an associated state (such as "Active" or "Cancelled"). The HL7 architecture specifies these in an Act Statechart within the RIM. All of these states are valid for Medication orders (SubstanceAdmin and Supply Acts), but for simplicity, and in common with many systems only a limited set of states are considered here. The restricted set which is addressed in the current ballot is shown in the diagram below. Other states may be addressed in the future.
2. Medication Processes
In HL7 terms, Pharmacy messaging is described using two clinical acts which are used separately or together to convey information:
- Substance Administration, which is concerned with actually administering a medicine (in)to a patient
- Supply which is concerned with dispensing or providing a stock of the medicine to be given. Supply has been the traditional HL7 term for this function, however the term "dispense" is more widely used in clinical settings. For the purpose of this discussion the terms are used interchangeably.
Prescription processing, however, focuses on three major activities:
- A prescription is a formal representation of an authorized "order" for one or more medications to be administered: it may or may not require a "supply" to support the administration. A physical or electronic prescription may contain one or more items in both hospital and community settings. In some cases it is important to be able to group medications as they were prescribed at one time either for payment purposes (UK NHS) or to reflect workflow. In an electronic prescribing system there is still the concept of prescription to enable reconciliation with the paper or physical prescription at the time of dispensing. However in such cases it is also necessary to be able to treat each individual item ordered separately e.g. to have the ability to cancel one line item on a prescription and to supply the remainder. The concept of prescription also has regulatory overtones and may be different across national boundaries.
- A dispense covers the "traditional" understanding of dispensing (the individually labeled supply of medication for an individual patient in response to a "prescription" from an authorised prescriber, that details the administration instructions) through to "supply only" situations, where a medication is supplied, in single units or bulk quantities, usually to a ward or unit, without any information on its likely use/administration. Note that a supply can be made for a named patient; this has no explicit expression of administration. The main focus of the Dispense topic is therefore the SUPPLY act, with a medication or vaccine as the consumable participating in that supply.
- Administration is the process of giving the medication to the patient. In the community, this process is usually not recorded, since the majority occurs in the patient's home; only administrations undertaken by a healthcare professional, such as vaccination, tend to be formally documented. Administration of medication in the institutional setting is usually recorded on a "dose by dose" basis, and may be messaged on that basis, or a summary of all the administrations occurring during an inpatient stay may be described.
Medication may be described in prescribing by any one of a variety of ways, all of which are supported in this domain e.g. prescribing by brand name, or "generically" at either the pack or unit dose level or prescribing a substance which may be an active ingredient of a medication or a virtual concept which groups similar or identical active ingredients. It is assumed that the application implementing these messages will have access to a drug terminology which covers the list of prescribable medication concepts and products which can be dispensed and administered.
The Medication
The need for agreement on medication terminology is widely accepted in many countries that have considered national systems to support exchange of medication information and electronic prescribing. HL7 version 3 allows for each realm to specify a common medicines terminology to ensure enable "semantic interoperability" between systems. The related domain in this ballot, "Medication", (POME) represents the detail of how Medication should be described in Pharmacy messages, and supports all the levels of granularity that use cases have so far identified.
3. Implementation Issues
Timing Issues
Representation of Timing
Timed events occur frequently in healthcare where time has to be recorded for clinical, administrative or medico-legal reasons. The following discussion relates to timed events in the medication management domain as represented in the Medication Information model. Additional material on timing is available in the RIM and Data types sections of the HL7 documentation.
In the medication information model the concept of time apply to ACTS (eg. medication prescription, supply and administration) in the various moods of Act (eg. promise, order, event) and to PARTICIPATIONS (e.g. authoring, data entry, verifying, or performing a medication promise, order, event). Not all combinations of these Acts, Moods, and Participations will be relevant to any particular message hence not all potential timed events will be required. Because there are so many potential time related issues following a medication process from prescription through to administration, this discussion has been prepared to enable those implementing Version 3 messages to achieve a clear understanding of the time recording issues. Each of the various HL7 time artifacts has to correspond to the records of timed events in the real world.
Time Data Types
The following data types are used to represent time in medication information model:
- The time stamp (TS) which identifies a particular point in time. It can vary in precision from describing a particular year to a particular millisecond.
- The interval of time stamps (IVL_TS) describes a low value time stamp, which is usually a "start" time, a high value time stamp, which is usually a "stop" or "end" time, and the interval between, either as a "width" (value and units) or centre point time stamp. Any or all of these characteristics might be specified in any interval attribute.
- The Generic Timing Specification (GTS) describes complex patterns of time in terms of interrelated sets of time stamps and/or intervals of time. Within this Pharmacy domain, the most common implementation of this will be the Periodic Interval of Time, the PIVL, which is a generalization of the more complex GTS.
Timing Attributes in "Act"
In general, Act classes in HL7 have the following types of timing events:
- The time(s) that the act will occur or has occurred from a clinical effect perspective, is described in the EFFECTIVE TIME. The effective time can describe the time an event started, stopped and its duration (the interval between start and stop) or complex timing sequences which are variations of this. The focus is on the time that is 'biologically relevant' to the patient. In the Pharmacy domain, for the SBADM act, this is therefore closely related to the "when" part of the dosage information; however, because "a substance administration act" may be describing an ongoing process that occurs at many points in time (e.g. "three times a day) within a time period (which may or may not be indefinite, e.g. "for 7 days", or "continuously"), the description of timing is often "nested". For the SPLY act, the effective time is the "when" the supply is to be or was made. (Data Type - GTS)
- The time (s) during which the act will occur or which occurred from an administrative or resource use perspective, is known as the ACTIVITY TIME. This can describe the time an event started, stopped and the interval or complex timing sequences which occurred between. For example this could be the time taken to prepare, commence, monitor, finish and clean up after the administration of an intravenous solution. (Data Type - GTS)
- The time at which the system recorded or became aware of the Act, is known as the AVAILABLITY TIME. This allows for Acts which occurred in the past to be recorded. The availability time will in most cases be the same time as the effective time and is not widely used. But there are some example use cases, such as to describe when the statement that "a particular medication is known to have been administered to a patient at some time in the past" becomes known and recorded. (Data Type - Time Stamp)
Note: The context (mood) of the event being described will determine how the timing attributes should be interpreted. Further information is available from the RIM documentation relating to the timing attributes of ACT.
Participation Time Events
An Act is also modified by participations which occur such as authoring, performing, data recording, and verifying. The relevance of these participations will be determined by the story board as in some situations not all of these occur or are recorded as occurring separately.
In the Pharmacy Information model the Authoring (prescribing or ordering) PARTICIPATION TIME is modeled; this is usually the key information about the "when" a prescription is authorised. The data recording, and verifying times may be recorded if necessary. A performer time is not used, because in this domain, this is synonymous with the key attribute of effective time within the act itself.
While Participation Times allow for the interval of time datatype, in pharmacy we will generally only use the Time Stamp data type to signify time that a prescription is written (authored) or transcribed (data enterer etc.). However in the example below we have also used an interval time to demonstrate that it possible to record the duration of this process in some situations.
Storyboard to Illustrate Medication Information Timing
The following limited storyboard covers the timed events which are included in the Pharmacy information model.
- Dr. Hypocrites writes a prescription at 1330 hrs. on January 1, 2003 (time A).
- Dr. Hypocrites' billing system records the time taken to create the prescription (including drug selection, contraindication management and printing) is two minutes (time B).
- The prescription is ordered to commence at noon on January 2nd (time C) , and is to be completed two weeks later on the 16th January (time D).
- The prescription calls for an intravenous drug solution to be administered twice a day (time E) for a period of 30 minutes (time F).
- The prescription also indicates that the first allowed fill (dispense) date is January 2nd (time G) and the last allowed fill date (expiry date) is January 16 (time H), with dispensing to occur on a daily interval (time I).
- The pharmacy receives the prescription, and Suzy Supply takes 10 minutes (time J) to mix and prepare the i.v. solution.
- She dispenses it to the Coronary Care Unit at 10am (time K).
- Florence Nightingale prepares to give the infusion at 10.50am on 2nd January (set up the i.v tubing etc) and commences the infusion at 11am (time L) and it is complete by 11.30am (time M).
- She removes the iv and cleans up and finishes at 11.40am. The total nursing time involved (including setup, monitoring and completion) is 50 minutes (time N) .
Note: Times A to I refer to the "prescription", which in this example is a combined substance administration and supply order, where the focal act(s) are in the mood RQO.
| Time | Topic | Notes |
| A | Description | Time a script was written (date prescribed or ordered), date written on the prescription |
| Model Mapping | Participation.time end time on the 'Author' participation for an Order | |
| Data Types | IVL(TS) (end) or TS (if no interval is required - usual situation) | |
| B | Description | Time taken to write the prescription (tracked for billing purposes) |
| Model Mapping | Length of Participation.time duration on the 'Author' participation for an Order | |
| Data Types | IVL(TS) (width) | |
| C | Description | Part of the dosage instructions: the medication process start date (first time patient should be administered the drug under the course of treatment covered by the prescription) |
| Model Mapping | Outer boundary start on the phase of PIVL within the in EffectiveTime attribute in the SubstanceAdministrationProcess act. | |
| Data Types | Phase attribute of a bounded PIVL in GTS | |
| D | Description | Part of the dosage instructions: the medication process end date (last time patient should be administered the drug under the course of treatment covered by the prescription) |
| Model Mapping | Outer boundary end on the phase of PIVL within the Effective Time attribute in the SubstanceAdministrationProcess act | |
| Data Types | Phase attribute of a bounded PIVL in GTS | |
| E | Description | Part of the dosage instructions - the dosage frequency - twice a day |
| Model Mapping | The Frequency attribute of PIVL within the EffectiveTime attribute in the SubstanceAdministrationProcess act | |
| Data Types | Frequency attribute within (a bounded) PIVL (see datatypes R2) | |
| F | Description | Part of the dosage instructions - the duration of each actual administration - 30 minutes |
| Model Mapping | The amount of time of the Period attribute in (a bounded) PIVL within the Effective Time attribute in the SubstanceAdministrationProcess act | |
| Data Types | PQ in Period of PIVL in GTS | |
| G | Description | Supply start date - the first day the medication can be dispensed |
| Model Mapping | Outer boundary start on the phase of PIVL within the in the Supply Process effectiveTime | |
| Data Types | Phase attribute of PIVL in GTS | |
| H | Description | Supply end date - last day the medication can be dispensed |
| Model Mapping | Outer boundary end on the phase of PIVL within the in the SupplyProcess effectiveTime | |
| Data Types | Phase attribute of PIVL in GTS | |
| I | Description | Part of the supply instructions - the Dispense interval |
| Model Mapping | The Frequency attribute of PIVL within the effectiveTime attribute in the SupplyProcess act | |
| Data Types | Frequency attribute within PIVL (see datatypes R2 |
Note: Times J to K refer to the "dispense", which in this example is a combined supply with substance administration , where the focal act (SPLY) is in the mood EVN.
| Time | Topic | Notes |
| J | Description | Administrative time to dispense (time taken to prepare the medication for supply) |
| Model Mapping | Duration of the activityTime for the Supply process event | |
| Data Types | Width attribute of the IVL in the IVL part of a bounded PIVL in GTS | |
| K | Description | The actual time of (one of the) dispense act(s) |
| Model Mapping | The High attribute of the IVL in the IVL part of a bounded PIVL in the effective Time of the SupplyProcess | |
| Data Types | The High attribute of the IVL in the IVL part of a bounded PIVL in GTS |
Note: Times L to N refer to the "administration", which in this example is a substance administration so the focal act (SBADM) is in the mood EVN.
| Time | Topic | Notes |
| L | Description | The infusion administration start time |
| Model Mapping | The inner boundary start on the phase of PIVL within the in EffectiveTime attribute in the SubstanceAdministrationProcess | |
| Data Types | Phase attribute of a bounded PIVL in GTS | |
| M | Description | The infusion administration end time |
| Model Mapping | The inner boundary end on the phase of PIVL within the in EffectiveTime attribute in the SubstanceAdministrationProcess | |
| Data Types | Phase attribute of a bounded PIVL in GTS | |
| N | Description | Administrative time to perform the administration (retrieve drug from cart, prep injection site, perform injection, dispose of remains) start, stop and width 50min |
| Model Mapping | Duration of the activityTime attribute of the SubstanceAdministrationProcess | |
| Data Types | Width attribute of the IVL in the IVL part of a bounded PIVL in GTS |
For further information on how to describe timing of dosage, please see the Dosage Instructions document in the Appendix to the Pharmacy ballot.
Relationship Between Message IDs and Real World Order IDs
In the "real" world each medication prescription or dispensing will have some form of identifier by which it can be tracked through the various process performed on it. This ID may be a system generated ID or it may be a pre-assigned ID stamped on a paper form. When generating a message about an order it is important to be able to pass on information about the ID so that the order can be tracked in external systems that are outside the HL7 messaging framework.
Each Act has an attribute of id and this is used to carry the real world id. Within the Pharmacy domain the real world ID is carried by the id in both the SubstanceAdmninistration acts and the Supply acts.
A Prescription or a Dispense may involve several medications and in the real world each of these items may not have their own distinct ID. For the purposes of pharmacy messages, applications will have to generate an id for each item as well as using the ID for the entire order.
The relationship between a the prescription (or dispense) and its items, and between (say) an administration event and the administration request that gave rise to it are captured in the RMIMs through the InFulfillmentOf relation. In each case the target of the relation will be a previous request or promise act and the representation of this will carry an id as its only attribute. This id should be the real world id.
Diagram
DESCRIPTION OF THE PHARMACY MODEL
The Pharmacy Domain Model (Pharmacy DMIM) is the global model used to derive message patterns to describe and communicate processes related to medication. From this, each specific message pattern is defined by its own Refined Message Information Model (RMIM) This DMIM contains all the elements that are required for the specific messages, which are derived from it by constraining the model and making it specific to the particular task.
The primary real life processes being represented in the DMIM are the making of a prescription or medication order, the organizing of a supply of a medication and the administration of the medication to a patient. As a high level model, the DMIM may not appear to mimic exactly real life objects or classes. Analysis of the way this real life process works in systems terms requires some of the real life objects to be represented as more than one class: for example a prescription can be viewed as a "header" with a medication administration and supply order.
We also have to recognize that each class will progress through a number of distinct moods before the business process is complete eg. substance administration in the mood of order (as on a prescription) and also substance administration in the mood of event (as in a notification of administration). Overall the DMIM is a tool to assist the process of generating specific pharmacy message models and is not intended to be used by those unfamiliar with HL7 Version 3 modeling. Hence some of the following description draws heavily on the technical language and concepts of Version 3 modeling and may not be clear to the casual reader
Pharmacy DMIM Core Structure
The primary focal class and primary entry point of the Pharmacy DMIM is CombinedMedicationProcess, a SubstanceAdministration specialization of Act. Based upon the mood (moodCode), this may represent the central aspect of a medication order (mood = request), a suggestion for a medication order (mood = proposal), a commitment by the filler to do an order (mood = promise), or the administration of a therapeutic agent (mood = event). The relationship between CombinedMedicationProcess "request" and "promise" or "event" is accomplished through the recursive act relationship "sourceOf". This class acts as the "header" to hold information that is common to both the Substance Administration act and the Supply act for a medication that are linked to the "header" via the component relationships.
The second core class of the Pharmacy DMIM is SubstanceAdministrationProcess, again a a SubstanceAdministration specialization of Act. It represents the actual "giving the medication into or onto the patient" part of any prescription or medication order or administration process.
SupplyProcess is another focal class for the Pharmacy DMIM. A Supply specialization of Act, MedicationSupply represents the information associated with supplying therapeutic agent(s) related to an order or the execution of an order.
Another significant aspect of the Pharmacy DMIM is link to the representation of the medicine or therapeutic product. The ways medicines are described will vary according to the message type. For example the reference to a medicine being dispensed should relate to a physical product rather than a generic concept. However reference to a medication ordered could be a real product or a product concept such as the generic name of the drug or active ingredient. The medicine may be linked to SubstanceAdministrationProcess via a participation of Consumable (CSM) meaning that the medicine will be used up during the act. Conversely the medication may be linked to MedicationSupply via a participation of product (PRD) indicating that the medicine is "produced" for later use during the supply act. The medicine may also be linked to the "header" act via the directTarget participation - if this is used, for example in a combined order, the medicine need only be specified once, and both the substance administration and the supply act may reference it.
The overall description of a medicine is detailed in the Medication domain (POME); here in the Pharmacy DMIM, it is referenced by the one of the CMETs R_OrderableMedication or R_AdministerableMedication.
Pharmacy DMIM Classes
1. COMBINED MEDICATION PROCESS
The CombinedMedicationProcess class is the primary entry point for the Pharmacy DMIM. It represents the "header", something that can be used to "hold together" the other acts (substance administration and supply) that are intimately related and in some senses equally important in the clinical process being described for a Pharmacy domain communication. It also functions as a holder for the information that is related to the whole process of adminstration and supply. It can be used as a representation of a "prescription" or of a "line item" and indeed when necessary may be cloned and unrolled to represent both a prescription and a line item within the prescription.
Key Attributes
classCode - This attribute is always populated with either "SBADM" which defines this class as a SubstanceAdministration specialization of Act or "SPLY" which defines it as a supply act. It is felt that, since there is no class code for an act behaving as a "header", the code should reflect the main focus of the entire act which will be either Substance Administration or Supply. Where opinion is divided the convention is to select SBADM.
moodCode - This attribute is limited to the x_MoodIntentEvent vocabulary domain, which includes the moods of Intent (INT), that is the Request (RQO) mood, Promise (PRMS) mood, and the Propose (PRS), and then the Event (EVN) mood. The value of this attribute is specified in each RMIM to define whether this class is describing an intent to perform (PRP), an order (RQO), a filler's intent to perform (PRMS) or the act of administration (EVN).
id - is the unique identifier for a particular header act and its associated information as used in a message - see separate discussion in the introduction on identifiers in pharmacy messages.
text - the full "human readable" text of the header act
statusCode - a code giving the "state" of the act (and therefore relating to the Act State Transition diagram); e.g. active, suspended, completed
priorityCode - [varies according to mood] - describes the urgency with which the combined medication process (the dispense and the administration) needs to happen, is happening or has happened. For instance regular - give during the scheduled medicines round; ASAP - give as soon as possible e.g. for an analgesic to cover breakthrough pain)
confidentialityCode - controls the level of disclosure about the substance administration act; some medicines for used for treating certain sensitive clinical conditions may have restrictions on who may access this information
Participations
author or performer (to AssignedPerson) - this describes who is responsible for "doing the act", as in authoring an order for a medication, or performing an medication event; the cardinality is 1..1, there should always be information about the one person who is responsible for "doing the act" in the medication domain. There is the facility to hold information about the time of the authorisation (which corresponds to the "date" on a paper prescription), to record the mode of the data capture (verbally dictated, written, faxed etc.) and a signature, both in the form of a code, and/or in the form of some formal representation - this has an ED datatype that could be used to transmit a "picture" of a signature right through a formal encripted digital signature. There is also a note facility, to communicate any additional information from the author, and the context control is set to "AP" so that the information shown in the participation is "additive to" the act and "propagates" to other the related SBADM and SPLY acts.
dataEnterer or verifier (to AssignedPerson) - this gives information about a person who has recorded the information being described, or who verifies that the information is correct (as required for some realms for particular types of medicines such as narcotics). The same facilities as are on the authorOrPerformer participation, to hold information and allow it to flow to the related acts are on this recorder-validator participation. Both these and the author and performer participations link to the R_AssignedPerson[universal] CMET for description of a person in a specific formal responsibility role.
subject (to Patient) - this describes information about the patient who is going to receive the medication; it links to the R_Patient[universal] CMET for description of a person as a patient.
Act Relationships
sourceOf to Combined Medication Process (recursive) - this allows for relationships between various acts in the moods of order, promise, event etc. to be related together as the business process progresses.
componentOf1 from Encounter - this facilitates the description of the "encounter" or healthcare act that the medication act is a part of. For example, the encounter might be a visit to a family physician that results in a combined admin/supply order for a medication being made. It links to the A_Encounter[universal] CMET that describes such healthcare events. The direction of the relationship is such that the medication act is a component of the overall encounter event.
subjectOf1 from Review - this structure allows information about when the medication act should be reviewed to be captured. The medication act is the subject of an intended "review act", at a time specified within the effectiveTime attribute of the review act.
componentOf3 from Working ListEvent - this allows the communication of information about the medication act as component of a Working List (a problem list, a "to do" list, etc.). The Working List act could be specialised to support using this structure to hold in formation about what is considered to be "current medication" for a patient.
definition to SubstanceAdministrationDefinition - this would be used to reference pharmacy protocols governing how a medicine should be prescribed/ administered
reason to SupportingClinicalInformation - this allows the description of the indication for the medication treatment using the A_SupportingClinicalInformation[universal] CMET. This act relationship has a priority number attribute; therefore if more than one reason for the medication act, the "order" in which these should be evaluated may also be communicated.
pertinentInformation to SupportingClinicalInformation - this allows the description of any other clinical information that may be communicated with information about medication treatment that is not specifically an indication (see above); this might be allergy information, for example, or a patient's weight, to be used in a dosage calculation. As above, it references the A_SupportingClinicalInformation[universal] CMET to actually describe the clinical information.
component1 to Substitution Permission - this describes whether or not permission is given for the medication act may be subject to any form of "substitution act". In some realms or enterprises, when a medication administration or supply request is made, the author may indicate that they give permission (or not) for a different medication to be used in fulfilment of the order other than the medicine specified by the prescriber in the order.
coverage to Coverage - this identifies information about an eligibility check or authorization that has been received in relation to whether the particular substance administration/supply act will be/has been "covered" by a particular underwriting scheme. It references the A_Coverage[universal] CMET that describes coverage and eligibility information.
subjectOf 2 from Annotation - this structure allows communication of particular pieces of coded information that the medication act is the subject of, such as a particular "endorsement" by the prescriber of the prescription, such that it meets local business rules and can be processed. The annotation act has two participations, author and dataEnterer, linked to the Assigned Person description, so that, if the annotation is separate from the authoring of the medication act, this can be captured and communicated here.
subjectOf3 from Detected Medication Issue - this is used to indicate a detected issue (i.e. an alert) which has been identified previously in relation to this medication act and is therefore known by the author; the implication is that this information has been evaluated in the process of doing the medication act, and does not need further consideration/action before process can be undertaken.
component2 to Supply Process - this links the "header" medication act to a component Supply act. There is a sequence integer to specify the relative ordering of this relationship among other like-types relationships having the same source Act. There is a priority number which is an integer specifying the relative preference for considering this relationship before other like-typed relationships having the same source Act; relationships with lower priorityNumber values are considered before and above those with higher values. The conjunction code specifies the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or). Finally, the Separatable Indicator on this act relationship is "false", therefore the Supply act cannot be considered without reference to the information held in the header act and its attributes.
directTarget (to choice of R_OderableMedication or R_AdministerableMedication) - this links the "header" medication act to the description of the medication that it is referencing, for example if the "header" is acting as the description of a line item.
component3 to Substance Administration Process - this links the "header" medication act to a component Substance Administration act. There is a sequence integer to specify the relative ordering of this relationship among other like-types relationships having the same source Act. There is a priority number which is an integer specifying the relative preference for considering this relationship before other like-typed relationships having the same source Act; relationships with lower priorityNumber values are considered before and above those with higher values. The conjunction code specifies the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or). Finally, the Separatable Indicator on this act relationship is "false", therefore the Supply act cannot be considered without reference to the information held in the header act and its attributes.
SUBSTANCE ADMINISTRATION PROCESS
This is the second key class within the Pharmacy DMIM, and is used to describe the actual process of administration of a medicine, and as such, its attributes are all concerned with the process of "giving" a medicine.
Key Attributes
classCode - This attribute is always populated with "SBADM" which defines this class as a SubstanceAdministration specialization of Act.
moodCode - this attribute is limited to the x_MoodIntentEvent vocabulary domain, which includes the moods of Intent (INT), and Event (EVN). The Intent mood includes Request (RQO), Promise (PRMS), and Propose (PRS) moods.
id - this is the unique identifier for a particular substance administration act and its associated information as used in a message - see separate discussion in the introduction on identifiers in pharmacy messages.
code - this is intended to further specify the nature of the substance administration act. To date the SIG have made no use of this attribute.
text - this is the full "human readable" text of the substance administration act
statusCode - this is a code giving the "state" of the act (and therefore relating to the Act State Transition diagram); e.g. active, suspended, completed
effectiveTime - the usage of this attribute in the substance administration act varies according to the mood - in PRMS, PRP and RQO this would hold the time that the medicine administration should take place (i.e. the timing part of the dosage instructions), in EVN, it is the time that the administration did take place. Please refer to the discussion of timing in pharmacy messaging in the Introduction and to a separate analysis and discussion of Dosage Instructions.
repeatNumber - this is an interval of integer numbers stating the minimal and maximal number of repetitions of the substance administration. If it is used, it must be used with care so as not to be confused with information about "timing" from dosage instructions.
independentIndicator - this is an indicator specifying whether the substance administration act can be manipulated independently of other acts (header and supply). By default the independentInd should be set to true.
routeCode - this attribute uses coded data for the Route of Administration information for the administration of the medicine.
approachSiteCode - this uses coded data to describe the site of body area used to achieve the route desired. A route should usually exist for this attribute to be used, although in some cases, such as "into the left eye", a site may be used on its own.
doseQuantity - the amount of the medicine to be administered (or that was administered in the EVN mood). Further detail on the use of the doseQuantity attribute is given in a Dosage Instructions analysis.
rateQuantity - this attribute is used for medicines administered continuously (e.g. gases or infusions), so that the rate of administration can be specified. Further detail on the use of the rateQuantity attribute is given in a Dosage Instructions analysis.
doseCheckQuantity - an optional check value for the total amount of medicine expected to be administered over a stated period of time. This attribute is rarely used.
maxDoseQuantity - this attribute may be used to state the maximum amount of medicine that can be administered over a stated period of time; this is especially useful for limiting "as required" medications. Further detail on the use of the MaxDoseQuantity attribute is given in a Dosage Instructions analysis.
administrationUnitCode - this is used to specify the unit of measure used when describing the amount to be given to the patient in a single dose and where the unit is not implied by the product description.
Participations
device (to choice of Assigned Device or Access->Device2) - this allows the description of a device used in the substance administration process, such as an infusion pump or other delivery device. There is a choice of using the R_Assigned Device CMET, or using the role of Access scoped by a Device entity.
location (to Service Delivery Location) - this describes a location for the substance administration act to take place. For example, a substance administration of a radiopharmaceutical may need to take place in a specific room or unit; this would be described using this structure.
consumable (to choice of R_OderableMedication or R_AdministerableMedication) - this describes the medication that will be "consumed" during the substance administration act; it links to one of the CMETs R_OderableMedication or R_AdministerableMedication for description of the medicine itself. This participation may be used if the "line item direct target" participation is not used from the header act.
Act Relationships
precondition to Observation Event Criterion - this allows description of any event that forms a precondition to the substance administration event; for example "give if blood pressure is below 70mmHg". It is more directive than the "trigger" described below, in that if the precondition occurs, then the administration should be effected. Further detail on the use of the precondition act relationship is given in a Dosage Instructions analysis.
trigger to Observation Event Criterion - this allows description of an event that is a trigger to the administration of a medicine; for example "take three days before travel" or "take when required to relieve nausea". It is less proscriptive than the "precondition" described above, in that, once the trigger has occurred, the administration can take place. Further detail on the use of the trigger act relationship is given in a Dosage Instructions analysis.
goal to Observation Event Criterion - the class code of this act relationship is "ActRelationshipObjective", and this facilitates description of an event that is either a maintenance objective or final objective of the substance administration act. Further detail on the use of the source of/objective act relationship is given in a Dosage Instructions analysis.
subjectOf to Annotation - this is shown as shadowed, since it is an exact replica of the structure shown in full on the Combined Medication Process act. It allows communication of particular pieces of coded information that the substance administration act is the subject of.
sourceOf to Substance Administration Process (recursive) - this allows for relationships between various acts in the moods of order, promise, event etc. to be related together as the business process progresses.
3. SUPPLY PROCESS
The Supply Process class is the third key class within the Pharmacy DMIM, and is used to describe the process of dispensing or supply of a medicine, and as such, its attributes are all concerned with the process of "supplying" a medicine. In refining and constraining this class, it can be employed to describe the an order to supply medication, but, if used alone, it has no concept of the administration of the medication (e.g. dosage). This latter is always handled by the SubstanceAdministrationProcess act, which is often related to it in a "combined order".
Key Attributes
classCode - this attribute is always populated with "SPLY" which defines this class as a Supply specialization of Act
moodCode - this attribute is limited to the x_MoodIntentEvent vocabulary domain, which includes the moods of Intent (INT), that is the Request (RQO) mood, Promise (PRMS) mood, and the Propose (PRS), and then the Event (EVN) mood. The value of this attribute is specified in each RMIM to define whether this class is describing an intent to perform (PRP), an order (RQO), a filler's intent to perform (PRMS) or the act of supply (EVN).
id - this is the unique identifier for a particular substance administration act and its associated information as used in a message - see separate discussion in the introduction on identifiers in pharmacy messages.
code - this attribute contains coded information to convey the kind of supply act that is being described; it references the vocabulary domain of ActPharmacySupplyType, which includes descriptions for partial supplies, emergency supplies, trial supplies, etc.
text - the full "human readable" text of the Supply act
statusCode - this is a code giving the "state" of the act (and therefore relating to the Act State Transition diagram); e.g. active, suspended, completed
effectiveTime - the usage of this attribute varies according to the mood of the supply act; it can indicate the earliest/last allowed dispense times, frequency of supply restrictions, when the supply was made etc. Refer to the "Effective Time" table in the Introduction.
repeatNumber - he usage of this attribute varies according to the mood of the supply act; it can be used to describe the number of repeats (refills) that may be provided (in order mood) or the sequence number of the repeat supply (in event mood).
independentIndicator - this is an indicator specifying whether the substance administration act can be manipulated independently of other acts (header and supply). By default the independentInd should be set to true.
quantity - the amount of medication that was (event) or is to be (order, promise, propose) supplied in this supply act.
expectedUseTime - this attribute indicates the period of time that the supply is intended to be used through, or the period of time that the supply is intended to cover.
Participations
product (to R_AdministerableMedication) - this describes the medication as a product that will be supplied in the supply act; it links to the R_AdministerableMedication CMET for description of the medicine itself. This participation may be used if the "line item direct target" participation is not used from the header act.
performer (to Assigned Organisation) - this describes the organisation that is responsible for making the medication supply. At the DMIM level, this has been specified at the abstract "organisation" level; in the more constrained RMIM situations, this may be specialised to a person as a performer of a supply act.
receiver (to Assigned Person) - this describes the person who will receive the supply. It may be the patient, or a carer. It links to the R_AssignedPerson[universal] CMET.
destination (to Service Delivery Location) - this describes the destination of the supply act; it links to the R_ServiceDeliveryLocation[universal] CMET to describe the particular place for the destination.
Act Relationships
sourceOf to Supply Process (recursive) - this allows for relationships between various acts in the moods of order, promise, event etc. to be related together as the business process progresses.
subjectOf to Annotation - this is shown as shadowed, since it is an exact replica of the structure shown in full on the Combined Medication Process act. It allows communication of particular pieces of coded information that the supply act is the subject of.
consumable to R_AdministerableMedication - This allows us to specify the pack that was used to make up the actual pack supply. For instance a pack of 28 tablets may be drawn from a stock bottle of 1000 tables. This participation indicates the stock bottle.
|
||||||||||||||||||||||||||||||||||||
|
To demonstrate the flow of events with a patient getting a prescription from his family physician and his regular pharmacy is closed.
| Medication Order Record Request |  PORX_IN010380UV01 |
Mr. Adam Everyman, 55 years old, calls his family physician of many years, Dr. Fay Family. Adam is known to have a long history of smoking at least a pack a day and has chronic obstructive pulmonary disease (COPD) also known as bronchitis. Earlier this week he caught a cold and is now experiencing difficulty breathing.
Mr. Everyman is an established patient with Dr. Family, his family physician. On a Thursday evening his cold and breathing have been getting progressively worse. Mr. Everyman can't wait until the next day to see Dr. Family. He calls her answering service and she returns her call as she is on call that evening.
Dr. Family logs into her EMR and opens Adam's chart to review his medical history and allergies. Her EMR automatically does routine queries to the EHR/DIS to get the latest information on Adam, including a history of medications dispensed, unfilled prescriptions (PORX_IN060290UV) (PORX_IN060300UV), allergies and medical conditions if available. She notes that he has high blood pressure and is taking hydrochlorthiazide (HCTZ) 25 mg once daily. She takes a history and comes to the conclusion that he is experiencing an acute exacerbation of his COPD. Dr. Family prescribes Combivent 2 puffs four times a day and Septra DS twice daily for Adam. Her EMR conducts a DUR and notes a drug-drug interaction between Septra and HCTZ. Dr. Family discusses the potential for an interaction with Adam. He points out that he does not have insurance coverage of medications as he is currently out of a job and would prefer a low cost antibiotic to a more expensive one. Together they decide that Adam should get the Septra and keep an eye out for any side-effects. Dr. Family then over-rides the alert and creates the prescription in the EHR/DIS (PORX_IN010380UV) (PORX_IN010390UV). The EHR/DIS notes the DUR over-ride and does not conduct another DUR. The EHR/DIS assigns a prescription ID to the resulting prescription and posts the prescription for pull down by a pharmacy.
Unfortunately, Adam's usual pharmacy closes at 10 pm. Dr. Family instructs Adam to pick up the script from another nearby pharmacy, which is open until 1 am.
Adam immediately goes to the pharmacist, Susan Script. Susan obtains the pertinent demographic information from Adam and using the appropriate queries, pulls Adam's prescription and dispense history (PORX_IN060290UV) (PORX_IN060300UV) along with his allergies, intolerances and medical conditions from the EHR/DIS. Susan pulls the prescription from the EHR/DIS (PORX_IN020190UV) (PORX_IN020130UV) and processes the prescription. The EHR/DIS alerts Susan of the detected medication issue. Susan checks the prescription and ascertains that Dr. Family was aware of the medication issue and used a management code to proceed with the prescription. Susan dialogues with Adam and concurs with the management. Susan also uses a management code to allow the fill to proceed. Susan notifies the EHR/DIS of the dispense and pick-up. (PORX_IN020080UV) (PORX_IN020090UV)
To illustrate how an EHR/DIS sets a prescription status to ""complete"" when medication expires.
| Medication Order Record Request | PORX_IN010380UV01 |
Adam visits his family physician, Dr. Fay Family, who confirms he is having an asthma attack because of seasonal allergies. Dr. Family prescribes (PORX_IN010380UV) (PORX_IN010390UV) Advair 250 ug twice daily for 4 weeks until the medication is used up.
Adam picks up his medication from his local pharmacy the same day. At dispense time, the pharmacist notes that the prescription status is "active" (PORX_IN060290UV) (PORX_IN060300UV) and can be dispensed. The pharmacist confirms the days supply as being 30 days from the original prescription (PORX_IN010100UV) (PORX_IN010110UV) (PORX_IN020190UV) (PORX_IN020130UV) (PORX_IN010070UV) .
Adam returns to the pharmacy after 6 weeks to get a repeat of the Advair. The pharmacist looks up the prescription (PORX_IN010290UV) (PORX_IN010300UV) and notes that there are no dispenses left against the original prescription. The pharmacist notes that the prescription status has been set to "complete" by the ePrescribing System in the period since Adam first came.
This storyboard illustrates how a prescription can be sent sent from a prescriber directly to a community pharmacy.
| Medication Order Fulfillment Request Notification | PORX_IN010650UV01 |
Adam Everyman visits his GP Dr. Patrick Pump with complains of ulcer pains in the abdomen. After thorough investigation and blood tests Dr. Pump concludes that Adam Everyman suffers from Duodenal Ulcer. The ulcer is caused by Helicobacter Pylori and to eliminate this bacteria Dr. Pump decides to prescribe a combination of drugs. These drugs are conveniently prepacked in 14 individual daily dose packs as a combo pack called Prevpac(r). This Prevpac(r) contains three different drugs: lansoprazole, amoxicillin, and clarithromycin Each daily dose pack contains. - 2 capsule of lansoprazole (Prevacid(r) 30 mg) - 4 capsules of amoxicillin (Trimox(r) 500 mg) - 2 tablet of clarithromycin (Biaxin(r) 500 mg). Adam is instructed to take half of the contents (that is one lansoprazole, 2 amoxicillin and 1 clarithromycin) twice a day. Dr. Pump enters the required information in his GP application and transmits the prescription electronically to the "Overwhere" community pharmacy (PORX_IN010650UV) .
The prescriber sends a prescription to a community pharmacy. The prescription consists of a dispense and administration order. The pharmacy confirms the dispense by sending a dispense notification to the prescriber.
| Medication Order Fulfillment Request Notification | PORX_IN010650UV01 |
John Toe has been to his GP Dr. Rajiv Ramsey for his regular check-up on asthma. His inhalation aerosol has almost run out and Dr. Ramsey renews a prescription for salbutamol (PORX_IN010650UV) . The prescription is transmitted to the "Overwhere" community pharmacy, where Phedras Philodendron, a pharmacy technician, prepares the distribution. Phedras Philodendron picks one Ventolin(r) aerosol inhaler from the shelves and prints the drug label with dosage instructions. The dispense information is as follows: Dispensed : 1 Ventolin(r) aerosol inhaler 200 micrograms/dose Patient dosage instructions: 2 puffs when necessary with a maximum of 12 per day. The label is applied on the Ventolin outer package. When John Toe appears at the "Overwhere" pharmacy, he shows his identity card and pays for the inhaler. Mr. Phedras Philodendron then notifies Dr. Ramsey with a dispense message, that the prescription has been dispensed (PORX_IN020160UV).
To illustrate how contraindication checking will be carried out in situations where the patient has complex medical issues and the physician does not have access to their own EMR.
Dr. Fay Family comes to see Mrs. Everywoman and takes a focused history and does a focused physical examination. Dr. Family determines that Mrs. Everywoman is suffering an asthma attack and decides to prescribe her prednisone. However, because Mrs. Everywoman has a complex history, she wants to make sure she won't cause more problems than benefit by prescribing a new medication.
Luckily, Mrs. Everywoman has a computer with Internet access at her house. Dr. Family is able to access the EHR System directly from Mrs. Everywoman's computer. Dr. Family logs in and brings up Mrs. Everywoman's profile. She then asks the system to check for contraindications to prednisone for Mrs. Everywoman (PORX_IN050010UV) . The system returns that prednisone is expected to increase her blood glucose levels and may cause depression and confusion (PORX_IN050020UV) . Prednisone is not expected to interact with any of her myriad medications.
Dr. Family reconsiders her treatment plan in light of the information provided by the EHR System.
Mid-wife prescribes medication via EHR host. Patient realizes afterward that the medication didn't work the last time they used it. Pharmacist recommends a new prescription.
| Medication Order Record Request | PORX_IN010380UV01 |
Eve Everywoman has recently conceived and as a result, she is experiencing severe nausea related to the pregnancy. The nausea is so debilitating that Eve is having trouble in caring for her other young child. As she did in her first pregnancy, Eve has engaged a midwife, Clara Certified, as part of her healthcare team. During her next scheduled appointment with Clara Certified, Eve discuses her problem with nausea. Following an appropriate assessment, Clara prescribes Diclectin, an anti-nauseant approved for use in pregnancy.
Following the appointment, Eve goes to Good Neighbor Pharmacy to get her medication. Prior to dispensing the medication, Susan Script, the pharmacist on duty dialogues with Eve about the Dicelctin. During her last pregnancy, Eve had also experienced severe nausea and was prescribed Dicelctin. Unfortunately, it had not been effective and this was noted in Eve's record in the Pharmacy. Following the discussion, Eve asks Susan Script to telephone Clara Certified and request a prescription for a different medication.
Susan telephones Clara Certified and discusses Eve's nausea and the Dicelctin prescription. Susan suggests that dimenhydrinate might be a suitable alternative. While it has not been specifically approved for use in pregnancy, it has a long record of such use and has demonstrated an excellent safety profile. Clara agrees to the suggested change and dictates a replacement prescription for dimenhydrinate to Susan (PORX_IN010380UV) (PORX_IN010390UV) . She further states that she will abort the Diclectin prescription when she returns to her office. Susan Script dispenses the medication (PORX_IN020190UV) (PORX_IN020130UV) , dialogues with Eva and provides her with the medication (PORX_IN010070UV) .
To illustrate flow when patient attends more than one physician and more than one pharmacy. Chronic patient who has seen another physician for an antibiotic comes in for her repeat medications to her regular FP. Patient had developed an allergy to the antibiotic which is recorded. Physician does query of patient medication history before writing prescription. Meds are prescribed with 3 repeats.
| Medication Order Record Request | PORX_IN010380UV01 |
Mrs. Eve Everywoman lives in Pickering and works in Toronto. Her family doctor in Pickering is Dr. Patricia Primary. She occasionally sees another family physician at a downtown Toronto walk-in clinic, near her work. She has diabetes, arthritis and atrial fibrillation. She is on multiple medications for her diseases. Mrs. Everywoman usually goes to only one pharmacy, as she understands the value of having one pharmacy know all her medications. However, she does occasionally go to a downtown Toronto pharmacy, if necessary. Last week, she went in to work in spite of feeling unwell. She decided to go to the walk-in clinic to have herself checked out. She saw Dr. Fay Family who took a history and did a focused physical examination. She determined that Mrs. Everywoman had a community acquired pneumonia and prescribed Amoxicillin 500 mg three times a day (tid). Mrs. Everywoman picked up the antibiotic from the pharmacy near her work and took the antibiotic. That night she developed rashes and and a persistent non productive cough. She discontinued the Amoxicillin, and she improved.
Today, Mrs. Everywoman needs to get a repeat of her usual medications -Glyburide 5 mg tid, Metformin 500 mg tid, Coumadin 5 mg once daily (od), Celebrex 100 mg od. She comes in to see her regular FP, Dr. Primary. She updates Dr. Primary about the episode with the antibiotic. Dr. Primary pulls up Mrs. Everywoman's chart in her EMR, which automatically queries the EHR System for current medication, allergy history and medical conditions and downloads the information to her EMR (PORX_IN060390UV) (PORX_IN010400UV) . Dr. Primary updates her EMR with Mrs. Everywoman's new allergy. She also notes that Mrs. Everywoman's last HbA1c (a measure of long-term glucose control) was high and recommends that Mrs. Everywoman start a new medication, Roziglitazone 4 mg od. Dr. Primary's EMR automatically conducts a Drug Utilization Review (DUR). She then re-prescribes for Mrs. Everywoman all her usual medications using her EMR. Once Dr. Primary is satisfied that there are no drug-drug interactions, she initiates a transfer of the prescription to the ePrescribing Hub and tells Mrs. Everywoman that she has prescribed the medications for her with 3 repeats and that she can pick them up from the pharmacy of her choice (PORX_IN010380UV) (PORX_IN010390UV) . When Dr. Primary closes Mrs. Everywoman's chart on her EMR, it automatically updates the EHR System with the updated information she has agreed to send; in this case just the allergies. As a general rule, Dr. Primary chooses not to send medical condition information or current diagnoses.
Mrs. Everywoman goes to her usual pharmacist and gets her medications dispensed for her. The pharmacist pulls the prescription from the ePrescribing Hub (PORX_IN060290UV) (PORX_IN010300UV) (PORX_IN010100UV) (PORX_IN010110UV) , dispenses the medication (PORX_IN020190UV) (PORX_IN020130UV) and notifies the ePrescribing Hub that the patient has received the medication (PORX_IN010070UV) . The pharmacist ascertains from Mrs Everywoman that she has no questions about her continuing medication and undertakes a dialogue about her new medication.
| Medication Order Record Request | PORX_IN010380UV01 |
| Medication Order Record Request | PORX_IN010380UV01 |
Mr. Adam Everyman is an established patient with Dr. Fay Family. Mr. Everyman has a chronic non-malignant pain and requires opioid analgesics for treatment. He has only one day's worth of medications left on Friday night. Mr. Everyman had tried to get in earlier during the week, but Dr. Family had been away on a weeklong medical education program; the staff at the clinic had mentioned that she would be back in town on Friday evening. On Friday night, he calls Dr. Family for a repeat prescription.
Dr. Family takes a focused history and realizes that this last minute request was unavoidable. Since Mr. Everyman has an opioid treatment contract with Dr. Family, he couldn't get the medication from another doctor. Dr. Family wants to make sure that Mr. Everyman didn't get any opioids from another physician while she was away. She signs on to the EHR System and requests an update of Mr. Everyman's current medication (PORX_IN010070UV) (PORX_IN060380UV) , allergy and narcotics history. She checks the system for previous fills of the same narcotic medication and finds that Mr. Everyman has met the terms of the contract. Once Dr. Family is satisfied with her analysis, she prescribes the narcotic, oxycocet 1 tablet three times daily for one-week supply (21 tablets), directly on the ePrescribing Hub (PORX_IN010380UV) (PORX_IN010390UV) . Dr. Family also remembers that Mr. Everyman should be on EC-ASA 80 mg daily and reminds him of it. She tells him that she will put a reminder in to the pharmacist to remind Mr. Everyman to get some the next time he's in the pharmacy (PORX_IN010380UV) (PORX_IN010390UV) . Mr. Everyman is told that he should retrieve his opioid script from his regular pharmacy as the medication can only be picked up at that pharmacy by contract. Dr. Family writes a note on the ePrescribing Hub to indicate that this prescription is to be filled out by Lou's Corner Pharmacy and that if the patient needs it filled at another pharmacy, the pharmacist should call and confirm the dispense with Dr. Family first.
On Saturday, Mr. Everyman visits his usual pharmacist. The pharmacist pulls the prescription from the ePrescribing Hub (PORX_IN060230UV) (PORX_IN060240) (PORX_IN060290UV) (PORX_IN060300UV) (PORX_IN010100UV) (PORX_IN010110UV) and indicates that he has dispensed the prescription (PORX_IN020190UV) (PORX_IN020130UV) and that the patient has picked it up (PORX_IN010070UV) .
On Monday, when Dr. Family gets to her office, she runs a query to see if the prescription had been dispensed for Adam (PORX_IN030210UV) (PORX_IN060220UV) . She learns from the EHR System that Mr. Everyman has picked up the script and the transaction is completed.
A woman suffers a condom failure during intercourse and is concerned with the possibility of an ensuing pregnancy. She attends at her local pharmacy to dialogue with the pharmacist and receive the emergency contraceptive pill.
| Medication Order Record Request | PORX_IN010380UV01 |
A young married couple have two young children, a girl aged 2 years and a boy aged 4 years. The couple has discussed their family plans and have agreed that they do not want to raise a larger family. Concerned with possible side effects from birth control tablets, they chose condoms augmented with spermicidal gel as their method of birth control.
One evening following intercourse, the couple discovered that the condom had torn. While they had also used the spermicidal gel, they were concerned with the possibility of pregnancy. Through public service announcements, they were aware that trained pharmacists could provide emergency contraceptives. The next morning, a Saturday, knowing that their family physician was unavailable on the weekend, the couple went to their regular pharmacist.
Following the appropriate assessment and dialogue with the couple, the pharmacist decided that the use of an emergency contraceptive was appropriate. During the course of the conversation, the couple expressed a concern that the use of the emergency contraceptive would appear in the wife's record. The pharmacist discussed the use of a "mask" to block access to the information, a suggestion that the couple agreed to follow. The pharmacist obtained the appropriate medical updates from the EHR System (PORX_IN060390UV) (PORX_IN010400UV) . The pharmacist undertook to create a prescription for the contraceptive (PORX_IN010380UV) (PORX_IN010390UV) and dispense the medication (PORX_IN020190UV) (PORX_IN020130UV) (PORX_IN010070UV) , both which were noted in the patient's medical record as masked events. The pharmacy system automatically conducts a DUR.
To illustrate the process for a pharmacist to request renewal of an existing prescription when there are no refills remaining, on the request of the patient.
| Medication Order Record Request | PORX_IN010380UV01 |
Adam Everyman has been on Dilantin for epileptic seizures for several years. Noticing that his supply is quite low, Mr Everyman contacts his regular pharmacy and requests that another refill be dispensed. The pharmacy staff queries the EHR System for the prescription and determines that the prescription in question has no refill authorizations remaining. They also confirm that there is no unfilled prescription for Dilantin on the EHR System (PORX_IN060290UV) (PORX_IN060250UV).
The pharmacy staff sends a message to Mr Everyman's family physician requesting a renewal for the Dilantin (PORX_IN010720UV). Dr Family's office system is made aware of and retrieves the waiting message (MCCI_IN102001). Dr Family checks Mr Everyman's prescription record for compliance (PORX_IN060370UV) (PORX_IN060380UV) and creates a new prescription for three additional dispenses of the drug (PORX_IN010380UV) (PORX_IN010390UV) (PORX_IN010730UV) . The pharmacy system is made aware of and retrieves the waiting message (MCCI_IN102001). The pharmacy assigns the prescription to their store (PORX_IN010100UV) (PORX_IN010110UV) and processes the new prescription (PORX_IN020190UV) (PORX_IN020130UV). The pharmacy staff notify Mr Everyman that his medication is ready to be picked up.
Three months later, Adam is nearing the end of his medication again. The pharmacist sends a request for renewal to Dr. Family (PORX_IN010720UV) (MCCI_IN102001) (PORX_IN060370UV) (PORX_IN060380UV). Dr Family determines that he is not going to renew the prescription and refuses the renewal request, indicating he wants an office visit with Adam before prescribing additional Dilantin (PORX_IN010740UV) (MCCI_IN102001). The pharmacist notifies Adam that he must see Dr. Family in order to get a new prescription.
To illustrate how a refusal to fill a prescription by a pharmacist will be recorded in the medication record.
Several months ago, Adam Everyman had a tooth extracted. His dentist prescribed an antibiotic, a mouth rinse and some Tylenol #3 tablets for pain. Mr. Everyman had the antibiotic and mouth rinse prescriptions dispensed but decided not to get the Tylenol #3.
For the past couple of weeks, Mr. Everyman has been experiencing severe headaches. He remembered that his dentist had prescribed some 'pain killers' for him when he had his tooth pulled and he decides he will go and have that prescription dispensed. Mr. Everyman goes to the Good Neighbor Pharmacy and tells Sue Script, the pharmacist on duty, that he wants his pain killers filled. Sue queries the EHR System for unfilled prescriptions (PORX_IN060290UV) (PORX_IN060300UV) for Mr. Everyman and the only prescription returned is the months old Tylenol #3 prescription from the dentist. Through a dialogue, Sue learns that Adam wants the Tylenol #3 for his sever headaches. Sue Script tells Mr. Everyman that she is concerned that the headaches may be an indicator of a more severe problem and that he really ought to see his family physician as soon as possible. She also tells Mr. Everyman that she will not fill the Tylenol #3 prescription because in that her judgment, there is no relationship between the earlier prescription from the dentist and the condition Mr. Everyman currently wants to treat. Mr. Everyman becomes quite belligerent, tells Sue that if she won't fill the prescription he will find someone who will and he storms out of the pharmacy.
Sue decides to document her decision and notes her refusal to fill against the Tylenol #3 prescription still on file in the ePrescribing Hub (PORX_IN060300UV) (PORX_IN010070UV) . She makes a note to herself to contact the dentist the following day to request that he abort the prescription.
To illustrate the use of the hold and release messages.
| Medication Order Record Request | PORX_IN010380UV01 |
Adam Everyman visits his physician, Dr. Fay Family, complaining of sinus congestion and facial pain with fever. These symptoms have been present for one week and are worsening. Dr Family takes a history and performs a focused examinations following which she arrives at the diagnosis of sinusitis. Adam will need an antibiotic for this condition and Dr. Family decides to use Biaxin 500 mg. tablets twice a day (bid) for 10 days. Dr. Family queries the EHR System and receives the current medication profile for Adam (PORX_IN060390UV) (PORX_IN010400UV) ; she notes that he is taking simvastatin 20 mg for elevated cholesterol. She realizes that the DUR will advise against using the two medications simultaneously so she decides to request a drug hold for the simvastatin during the time Adam is taking the Biaxin.
She requests the hold on the Biaxin using the appropriate message to the ePrescribing Hub (PORX_IN010440UV) and receives acceptance of the request (PORX_IN010450UV) . Dr. Family counsels Adam to stop taking the simvastatin while he is taking this antibiotic and she completes the prescription for Biaxin (PORX_IN010380UV) (PORX_IN010390UV) . She informs Adam to return to the clinic once the supply of the Biaxin is completed for follow up. At that time she intends to request removal of the hold on his prescription for Biaxin.
Adam returns to see DR. Family as he was requested. Dr. Family undertakes an assessment of Adam and determines that his infection is resolved. Dr. Family recalls that she was to release the hold on Adams simvastatin. She sends a request the the ePrescribing Hub (PORX_IN010520UV) which is accepted (PORX_IN010530UV) . She instructs Adam to continue with his simvastatin therapy.
To illustrate the use of the stop/ abort message.
Adam Everyman visits his physician, Dr. Fay Family, complaining of muscle cramps during both the days and wakening him at night. The cramps have occurred over the past several months since he last visited the physician to have his chronic medications repeated.
Dr. Family takes a focused history and performs an examination. Adam wonders if the cramping might be due to his medication which has recently been changed. Dr. Family queries the EHR System to determine which mediations might be causing the cramping (PORX_IN060370UV) . Her request for a medication profile is returned (PORX_IN060380UV) and she determines that the recent prescription for Crestor 20 mg OD is probably causing the cramping. She determines that a change in medication would help and she send a message to stop the Crestor 20 mg (PORX_IN010840UV) (PORX_IN010840UV) and requests that Adam discontinue the lipid lowering medication and return in two weeks to assess his response to the cessation of the medication.
To illustrate how a prescription can be assigned from one pharmacy to another.
Adam Everyman, having seen his family physician the previous day, telephones his regular pharmacy near his home and after identifying himself, asks that they retrieve his new prescription from his record so that it can be prepared in advance of his arrival at the store. The pharmacy staff complies with his request and retrieve (PORX_IN060290UV) (PORX_IN060300UV) (PORX_IN010100UV) (PORX_IN010110UV) and process the prescription (PORX_IN020190UV) (PORX_IN020130UV) .
Later the same day, Adam realizes that he will have to continue working into the evening. Concerned that he may not get the pharmacy before it closes, he telephones Good Neighbor Pharmacy which was near his work place and asks if they could get the prescription from his home pharmacy and prepare it for him. As Adam has had prescriptions filled through them before, they agree to do this for him.
Sue Script, the pharmacist at Good Neighbor Pharmacy, initiates the transfer from the original pharmacy (PORX_IN010100UV) . Once the transfer is confirmed, a notification is sent to the original pharmacy (PORX_IN010090UV) (PORX_IN020190UV) (PORX_IN020130UV) (PORX_IN010070UV) .
To illustrate the process for a pharmacist to request another refill, on the request of the patient.
| Medication Order Record Request | PORX_IN010380UV01 |
| Medication Order Predetermination Request | PORX_IN010420UV01 |
| Medication Order Predetermination Request Accepted | PORX_IN010640UV01 |
Adam Everyman has been on Dilantin for epileptic seizures for several years. Noticing that his supply is quite low, Mr Everyman contacts his regular pharmacy and requests that another refill be dispensed. The pharmacy staff queries the EHR System for the prescription and determines that the prescription in question has no refill authorizations remaining (PORX_IN030210UV) (PORX_IN060220UV) . They confirm that there is no unfilled prescription for Dilantin on the EHR System (PORX_IN060290UV) (PORX_IN060300UV) .
The pharmacy staff sends a message to Mr Everyman's family physician requesting a renewal for the Dilantin (PORX_IN010720UV) . Dr Family checks Mr Everyman's prescription record for compliance (PORX_IN060370UV) (PORX_IN060380UV) and issues a new prescription for three additional dispenses of the drug (PORX_IN010380UV) (PORX_IN010390UV) (PORX_IN010730UV) . The pharmacy processes the prescription (PORX_IN020190UV) (PORX_IN020130UV) and notifies Mr Everyman that it is ready to be picked up.
A few days later, Mr Everyman keeps an appointment with his neurologist. The neurologist decides to try Mr Everyman on a newer drug product. The neurologist, Dr. Barry Brain, initiates the prescription on the ePrescribing Hub as he does not have an EMR. He conducts a quick DUR for the new medication against Mr. Everyman's drug profile on the EHR System (PORX_IN010420UV) (PORX_IN010430UV) . The DUR does not flag any medication issues and Dr. Brian creates the new prescription on the ePrescribing Hub (PORX_IN010380UV) (PORX_IN010390UV) . Mr. Everyman is instructed to discontinue the Dilantin and start on Lamotrigine 100mg twice daily. Mr Everyman has that prescription filled at another pharmacy (PORX_IN010290UV) (PORX_IN010300UV) (PORX_IN010100UV) (PORX_IN010110UV) (PORX_IN020190UV) (PORX_IN020130UV) (PORX_IN010070UV) but neglects to inform his regular pharmacy that he will not need his Dilantin. A couple of weeks later the pharmacy staff contacts Mr Everyman to inquire if he still needs the Dilantin. Being told he does not, the pharmacy staff return the Dilantin to stock and abort the prescription fill (PORX_IN010840UV) (PORX_IN010850UV) .
This illustrates a partial fill scenario such as when the pharmacist discovers that she has insufficient stock on hand to fill the prescription as ordered.
| Record med disp Rx processing request | PORX_IN020190UV01 |
| Record med disp Rx processing request accepted | PORX_IN020130UV01 |
| Record med disp Rx processing request | PORX_IN020190UV01 |
| Record med disp Rx processing request accepted | PORX_IN020130UV01 |
As a result of a recurring urinary tract infection, Eve Everywoman has been prescribed 20 tablets of Cipro 500 mg to be taken twice daily until finished. Eve goes to her pharmacist, Sue Script at Good Neighbor Pharmacy and asks that the prescription be dispensed. Eve received the Prescription Order Number from her physician and supplies it to Sue.
Sue retrieves the new prescription from the ePrescribing System. Prior to transmitting the 'Rx Dispense Processing Request', Sue discovers that she only has 15 tablets in her inventory. She discusses the options with Eve and Eve agrees to take the 15 tablets today and return in a few days to pickup the balance.
Sue processes the prescription as Eve is waiting. As is the usual practice, Sue transmits a financial claim for the 20 tablets. The balance of 5 tablets will be provided to Eve at no charge. Sue then sends a Medication Dispense Processing Request for 15 tablets (PORX_IN020190UV) . The request is accepted (PORX_IN020130UV) and Sue notifies the ePrescribing Hub of the pickup (PORX_IN010070UV) . Four days later, a new supply of medication is received into stock. Sue processes the Medication Dispense Processing Request (PORX_IN020130UV) for the remaining 5 tablets, being sure to include the expected start date to avoid getting a 'DUPLICATE THERAPY' alert and a code indicating that this is a balance of a dispense . A pharmacy staff member telephones Eve and lets her know the balance of her prescription is ready to be picked up. The following day, Eve comes to get the balance of her prescription. The ePrescribing Hub is notified that the balance has been received (PORX_IN010070UV) .
| Return to top of page |