PrescribeIT™ Specification and Guide Version 2.0 Revision F

 

The purpose of the PrescribeIT™ Message Specification "package" is to provide the technical guidelines, business rules and processes that Electronic Medical Record (EMR) and Pharmacy Management System (PMS) vendors must adhere to in order to become compliant with the PrescribeIT™ service. This package contains the core specifications that must be implemented by the vendor in order to integrate and complete the conformance process with the PrescribeIT™ service.

There are two main areas of the PrescribeIT™ Message Specification and Implementation Guide package; the PrescribeIT™ specification which provides details on the FHIR clinical messaging (electronic prescription and renewals) and the Shared Health specification which provides details for communicating with PrescribeIT™, including the API specification, Provider Registry and Polling messages. It is expected that implementers also familiarize themselves with the core FHIR specification on which the PrescribeIT™ FHIR messages are based. Links to pertinent FHIR materials are found within this specification.

This online PrescribeIT Specification and Guide must be used in conjunction with the functional requirement word documents that are provided to the EMR and PMS vendors separately. The functional requirements documents provided to the EMR vendors include 1) PrescribeIT EMR Functional Specification and 2) PrescribeIT Shared Functional Specification. The functional requirements documents provided to the PMS vendors include 1) PrescribeIT EMR Functional Specification and 2)PrescribeIT Shared Functional Specification.

The specifications provided are intended for software vendors wishing to modify their systems to send, receive and respond to the PrescribeIT™ messages. The targeted audience is the technical team who will use the implementation specifications to develop and incorporate this message set into their application in order to facilitate electronic prescription submission.

This Specification is based on the May 2016 FHIR specification. Note that the May 2016 FHIR publication (sometimes called FHIR 2.1) was an "interim" release of FHIR and is not the current official FHIR release. However, this specification is tied to that specific FHIR version. So when browsing links in the May 2016 FHIR spec, disregard the notice at the top of some pages that attempts to redirect you to the STU 3 or newer releases of FHIR. This specification will not work with any release other than the May 2016 release of FHIR.

This specification is made up of two distinct parts; the PrescribeIT™ specification which provides the clinical message details and the Shared Health Specification which provides details on the FHIR APIs and shared messaging to support Registry queries and Polling. Each specification contains technical artifacts in addition to providing guidance on implementation . It is strongly recommended that vendors first read through both PrescribeIT™ and Shared specifications to provide the overall context. Key areas of importance are the Product Overview and the Business Scope. Readers should gain an understanding of the Messaging Sequence and the API Summary which describes the overall flow of messaging between the EMR/PMS and PrescribeIT™ Switch.

This implementation uses FHIR “messaging” for the EMR and PMS Tasks as well as the 999 and 901 messages; these are POSTed using the RouteMessageToInbox API. To understand the messaging details, vendors should use the horizontal drop down menus at the top of the page to navigate through the clinical EMR and PMS Tasks profiles that are in scope for PrescribeIT™. Each task profile will include a diagram which depicts the overall message structure and the relationships between resources. To the left of the diagram there are links to all of the profiles (one for each resource) that is included in a particular message. All FHIR “messages” will include a bundle profile, message header profile, task profile and all profiles for the resources that pertain to the task. The data level conformance rules and constraints that are specific to PrescribeIT™ are found within each profile. Each profile provides multiple formal views of profile content but the Grid View is recommended as it reflects the PrescribeIT™ scope and the conformance rules (i.e. Constraints and Usage) are visible. In contrast, the Snapshot Table of the profile describes both the base FHIR profile and the supported elements for PrescribeIT™.

PrescribeIT™ is committed to providing support to our development partners. A point of contact will be provided to you. Any clarification or technical guidance will be arranged by your contact.

The PrescribeIT™ Service was developed to enable the secure electronic exchange of prescriptions and prescription related messages between a prescriber's EMR (Electronic Medical Record) and a PMS (Pharmacy Management System) at a patient's pharmacy of choice. Communication may be initiated by the prescriber or the pharmacy depending upon the type of transaction. This specification outlines the various transaction types that are initiated by either prescribers or pharmacies along with the associated business rules governing the usage of each transaction type. The PrescribeIT™ service consists of the following key components:

  1. The PrescribeIT™ Switch
    1. Exposes the PrescribeIT™ Service securely to Prescribing systems such as EMRs and PMSs
    2. Orchestrates the delivery of messages between prescribing systems and PMSs using a queue based message polling architecture
    3. Ensures conformance of prescribing systems and PMSs to the PrescribeIT™ messaging specification and terminologies
  2. The PrescribeIT™ Secure Token Service (STS)
    1. Facilitates 2 factor authentication through the provision of OTPs (One time passwords) to prescribers
    2. Allows prescribers to obtain PrescribeIT™ tokens that can be used to sign prescriptions
  3. The PrescribeIT™ Provider Registry
    1. Provides information about Prescribers, prescribing organizations, and pharmacies
    2. Source of the CPRID that is used to direct messages to the correct prescribing system or PMS
  4. System Registry
    1. This is a registry of vendors and associated application instances and organizations that they represent.
  5. SDF (API Gateway)
    1. This is the point of entry into PrescribeIT™. They issue client certificates for POS and perform run time system level authentication.
Overview diagram

Pharmacies begin using the PrescribeIT by registering for the service and being assigned a CPRID, an application instance identifier (if they do not have one), and system certificate that is used to secure the connectivity between the phamacy’s PMS and the PrescribeIT™ service. The pharmacy/organization is also assigned an CPRID identifier to allow them to utilize the PrescribeITTM functionality. There is no individual user-based authentication or authorization for PMS users access the PrescribeIT service.

Prescribers must register both their individual identity as well as their prescribing system and organization. Their prescribing system is assigned a PrescribeIT™ certificate that is used to secure the connectivity between their EMR and the PrescribeIT™ service. The prescriber must provide a Canadian cell phone number than can be used to issue OTPs (One time passwords). These one time passwords are used to provide 2nd factor authentication prior to issuing a PrescribeIT™ token. The PrescribeIT™ token is then included in any prescription related messages that are sent to the PrescribeIT™ service in order to provide pharmacies with an assurance of the identity of the prescriber authorizing any electronic prescriptions.

The process for a issuing a secure token to a prescribing system using the OTP is outline in the following diagram:

Overview diagram

The following is a list of interactions that will be supported by the PrescribeIT™ Service product. (For a complete review of the business requirements, please refer to the Business Requirement documents that were included in your package). These interactions are in addition to the Shared Health interactions found in the Shared Health implementation guide.

  • New Rx Fill Request: (e110-m) A new prescription (i.e., a new therapy for the patient) is created by a prescriber registered for the PrescribeIT™ service and transmitted, via the service, to a selected pharmacy that is also registered for the service
  • Renewal RX Fill Request: (e120-m) A prescriber registered for the PrescribeIT™ service creates a new prescription for an existing therapy (for a medication or non-medication). This new prescription is transmitted electronically, via the PrescribeIT™ service, to a selected pharmacy that is also registered for the service.
  • Rx Cancel Fill Request: (e140-m) A request by a registered prescriber that a pharmacy cancel a previously submitted request for the filling of a prescription.
  • Rx Cancel Fill Responses: (e141, 2, 3-m) The pharmacy transmits a response indicating whether they were able to cancel the prescription as requested.
  • Rx Renewal Responses: (e161, 2, 3, 4-m) The prescriber electronically transmits a Response to an electronic Rx Renewal Request from the pharmacy.
  • Deferred Rx Fill Request: (e180-m) A new or renewal prescription is stored by the PrescribeIT™ system for retrieval by a pharmacy who is provided a paper copy of the prescription by the patient.
  • RX Renewal Create Request: (p160-m) A request for a renewal of an existing treatment is transmitted electronically, via the PrescribeIT™ Service, from a registered pharmacy to a registered prescriber.
  • Rx Dispense Notification: (p200-m) A pharmacy notifies a prescriber that the dispense of a medication has occurred.
  • Rx Dispense Cancel Notification: (p210-m) A pharmacy notifies a prescriber that a previously processed dispense has been reversed (e.g. patient did not pick up medication).

The following provides some key responsibilities of the stakeholders involved in the PrescribeIT™ service.

Electronic Medical Record (EMR) software vendors

  • Creating the software according to the PrescribeIT™ specifications
  • Participating in the PrescribeIT™ service conformance program
  • First line support to their clients (e.g. EMRs)

Pharmacy (PMS) software vendors

  • Creating the software according to the PrescribeIT™ specification
  • Participating in the PrescribeIT™ service conformance program
  • First line support to their clients eg: Pharmacy

Medical Clinics, Prescribers and Adminstrative staff

  • Registering in the Provider Registry
  • Supporting the Shared Health Provider Management Group in their credentialing process
  • Activation and maintenance of PrescribeIT™

Pharmacy Retail

  • Registering the Pharmacy in the Provider Registry
  • Supporting the Shared Health Pharmacy Group in their credentialing process
  • Activation and maintenance of PrescribeIT™

Please refer to Shared Health implementation guide Shared Health - Understanding FHIR

The Data Dictionary and Snapshot Table are the “true” view of what implementers need to provide.

The Grid View is generated from the Snapshot Table. It only includes things that are marked as “must support”. When there is a (data) type and the child elements for that datatype are displayed (tighter conformance rules), the proper interpretation is that “both” must be adhered too; it is the intersection of the two. The datatype rules apply but may not be complete. This is much easier shown in the Snapshot Table or the data dictionary view (accessed by clicking on an element/extension). Example: The datatype can state a cardinality of 0..1 and the child elements can state a cardinality of 1..1. The proper interpretation is that this is the intersection, aka 1..1. The “intersection” is not shown in the Grid View but rather on the SnapShot Table. The FHIR community has discussed and it is difficult to do.

The Excel representation is driven from the Snapshot Table. It includes everything and it is filtered to only include the must support elements. This is the intersection of the datatype and the child elements. If we have a profile and additional inline constraints vendors need to look at both.

Child elements appear in the Grid View for a datatype when are further constraints applied to the datatype

Please refer here for FHIR Slicing explanation For example, in Shared Health Patient, Patient.identifier is an "Open by value:type" and not "Closed" slice. This causes the validator to examine both 1) the base type "identifier" which currently has all child elements as optional (0..1) and 2) the complete Required Pattern: {"coding":[{"system":"http://hl7.org/fhir/v2/0203","code":"JHN"}]} (e.g. if you comment out even one of the child elements such as "code", then the validator will ignore this 2nd condition and only consider the base type "identifier").

At the highest level, a bundle is submitted using a RESTful FHIR interface (HTTP POST). The bundle will contain a message header resource that includes key content relating to the source and destination and one or more tasks. Each task represents a single message (e.g. medication orders) and these may be submitted together if for the same patient and target clinic or pharmacy. The following Messaging Events have been created and are used for the execution of task(s) from either a prescriber office (EMR) or from a Pharmacy (PMS):

  • Event Code: 101 Execute Tasks from prescriber office. POST of Message bundle containing 1..* tasks and associated payloads
  • Event Code: 201 Execute Tasks from a PMS. POST of Message bundle containing 1..* tasks and associated payloads
  • Event Code: 305 Send Clinician Communication. POST of Message bundle containing 1 communication and associated resources
  • Event Code: 401 Execute Deferred Tasks from prescriber office. POST of Message bundle containing 1..* tasks and associated payloads

This solution focuses on the routing of messaging-based exchanges between EMR and PMS applications. The PrescribeIT™ service has defined FHIR-based Messaging for the submission of key events such as electronic prescriptions, renewal requests and supporting messages. The messages are structured as a Bundle and each bundle must contain a message header and the MessageHeader.data element will always be a reference to a Task resource. A single message may contain up to 25 tasks.

In addition to the Shared Health common messages, the PrescribeIT™ service supports the following messages:

Message event Interaction Description Payload profiles Examples
101 Execute tasks from an EMR from an EMR to PrescribeIT™ Switch. Requests processing of one or more tasks by the specified target recipient Bundle: interaction-bundle-101 examples
MessageHeader: interaction-messageheader-101
201 Execute tasks from a PMS from a PMS to PrescribeIT™ Switch. Requests processing of one or more tasks by the specified target recipient Bundle: interaction-bundle-201 examples
MessageHeader: interaction-messageheader-201
305 Send Clinician Communication From any PoS to any other PoS via PrescribeIT™. Message identifies both target systems as well as individuals or organizations (i.e. pharmacies or clinics) within those systems. Bundle: interaction-bundle-305 examples
MessageHeader: interaction-messageheader-305
401 Execute unassigned tasks from an EMR from an EMR to PrescribeIT™ Switch. Requests processing of one or more tasks but does not specify intended performer Bundle: interaction-bundle-401 examples
MessageHeader: interaction-messageheader-401

The primary focus of this guide is to allow prescribers and pharmacies to communicate with each other. Each communication is about some sort of specific event related to the electronic prescribing space. This might be a request to fill a new prescription or a request to renew a prescription. Each of these events is considered a "workflow" activity in FHIR and is represented by the Task resource. As a conformance limitation, we are restricting to a maximum of 25 Tasks to be included in a single bundle. The guide defines a number of tasks that can be conveyed within a message. Messages support conveying multiple tasks to ensure that content can be delivered in a single group of related information.

Each task will define the additional resources that need to be conveyed in order to allow the recipient to execute the task. Some tasks are stand-alone, but most tasks will reference additional resources. Those resources may in turn reference other resources. For example, a task seeking the fulfillment of a prescription would reference a MedicationOrder resource. That resource in turn would reference a Patient resource, a Practitioner resource, one or more Observation resources, etc. The Observation resources would also reference the same Patient. The complete set of interrelated referenced resources are all transmitted as separate entries in the message bundle, their relationships managed through the use of identifiers present at the start of each resource and in the references that link one resource to another.

Every task will be associated with a single patient and will have a creator (the one requesting or notifying) and an owner (the one being requested of or notified). Similar tasks will be given different codes even if the only difference is the type of initiating or receiving system because who is sending and who is receiving can result in slightly different constraints on the information being exchanged.

The order of the tasks must make business logical sense ie) you cannot 'renew' a prescription that has not yet been 'created/New Rx'. The task identifies the business event taking place and provides reference to the 'payload', 'patient', the 'practitioner' and the 'pharmacy'. The important business identifier included each task resource is the 'ext-task-requisition-id'. This must be the same value for all tasks within the interaction that the business deems MUST be managed together. There is a business constraint to limit the number of tasks in a bundle to ‘25’. Within each response there is a technical reference back to the original request task (ext-task-basedon), to assist with matching the response with the original request.

The tasks defined within this specifiction are provided in the table below. Content describes the information that needs to be present in the message along with the task to allow it to be fulfilled. Complete details are provided by traversing the profile hyperlinked to by the code, however the information is summarized here. The "subject" resource represents the primary focus of the task. Additional "named" resources or elements are sent using the task's input element. Any "other" resources are resources that are linked to by one or more of the other resources and may also appear in the message bundle. All tasks will have "other" resources of Patient, Practitioner and Organization (Service Location). Therefore, these resources are not listed in the table.

Cardinality is indicated as follows:

  • "?" = 0..1
  • "*" = 0..*
  • "+" = 1..*

Note that cardinalities reflect limitations of the task. If a message contains multiple tasks, it is possible that a particular resource type might repeat more than once in a message, even though only one repetition might be supported for a given task.

Code & Name Response to Sender Receiver Status Content
Prescriptions
e110-m - New RX Fill Request N/A EMR PMS requested Subject: New MedicationOrder
Input (previouslyUsed): code or date
Other: Detected Issue - DUR*
Observation - Pharmacy-related*
e120-m - Renewal RX Fill Request N/A EMR PMS requested Subject: Renewal MedicationOrder
Other: Detected Issue - DUR*
Observation - Pharmacy-related*
e180-m - Deferred RX Fill Request N/A EMR PMS requested Subject: MedicationOrder
Input (daysSinceLastDispense): code or date
Other: Detected Issue - DUR*
Observation - Pharmacy-related*
Cancel RX Fill Request
e140-m - Cancel RX Fill Request N/A EMR PMS requested Subject: MedicationOrder
p141-m - Cancel RX Request Denied e140-m - Cancel RX Fill Request PMS EMR rejected Subject: Identifier reference to medication or non-medication order for which cancellation is rejected
p142-m - Cancel RX Request Approved e140-m - Cancel RX Fill Request PMS EMR competed Subject: Identifier reference to medication or non-medication order for which cancellation is partially accepted
p143-m - Cancel RX Remaining Fills Revoked e140-m - Cancel RX Fill Request PMS EMR competed Subject: Identifier reference to medication or non-medication order for which cancellation is rejected
New RX Renewal Create
p160-m - RX Renewal Create Request N/A PMS EMR requested Subject: MedicationOrder
Input (daysSinceLastDispense): unsignedint
Input (lastDispense): Dispense
Input (instruction): string
Other: Detected Issue - DUR*
Observation - Pharmacy-related*
e161-m - RX Renewal Response - Denied p160-m - RX Renewal Create Request EMR PMS rejected Subject Identifier reference to medication or non-medication order for which renewal is requested
e162-m - RX Renewal Response - Approved p160-m - RX Renewal Create Request EMR PMS requested Subject: Renewal MedicationOrder
Other: Detected Issue - DUR*
Observation - Pharmacy-related*
e163-m - RX Renewal Response - Approved with Changes p160-m - RX Renewal Create Request EMR PMS requested Subject: Renewal MedicationOrder
Other: Detected Issue - DUR*
Observation - Pharmacy-related*
e164-m - RX Renewal Response - Under Review p160-m - RX Renewal Create Request EMR PMS in-progress Subject: Identifier reference to medication or non-medication order for which renewal is requested
p200-m - RX Dispense Notification N/A PMS EMR completed Subject: Dispense
p210-m - RX Dispense Cancel Notification N/A PMS EMR completed Subject: Dispense

With the exception of Task.id, there is no Resource ID that is required to be stored. References within the Bundle are done through URLs, References outside the Bundle are done through Extension business identifiers. Task.ids are the exception because there is no Business identifier included in the task.

The following matrix identifies the Profile/Resources that make reference to other resources. It identifies the type of reference and the value that is needed to complete the reference.

Profile Resource name element name reference type reference to by profile name Reference to by resource name reference value
e120-m task for bundle Shared Health Patient patient URL
e120-m task creator/owner bundle Shared Health SAML Practitioner practitioner URL
e161-m e163-m task ext-task-basedon reference PrescribeIT™ base Task profile task task id GUID
e161-m e163-m task ext-task-basedon reference PrescribeIT™ base Task profile task task id GUID
e161-m e164-m task subject reference PrescribeIT™ Prescription medicationOrder ext-reference-identifier
e162-m e163-m task ext-task-basedon reference (Task.id of the request task being responded to) task task id GUID
e162-m e163-m task subject bundle PrescribeIT™ Renewal Prescription medicationOrder-renew URL
p166-m FUTURE task subject reference PrescribeIT™ base Task profile task task id GUID
p200-m task subject bundle PrescribeIT™ Dispense Dispense URL
p210-m task subject bundle PrescribeIT™ Dispense Dispense URL
list-allergies list subject choice Shared Health Patient patient URL
NewPrescription medicationOrder ext-request-coverage bundle PrescribeIT™ Coverage (NOT SUPPORTED) coverage URL
NewPrescription medicationOrder ext-medicationorder-supportinginfo bundle PrescribeIT™ List - Allergies (FUTURE) List - Allergies URL
NewPrescription medicationOrder ext-request-detectedissue bundle PrescribeIT™ DUR detectedIssue URL
NewPrescription medicationOrder medicationReference contained PrescribeIT™ Medication medication URL
NewPrescription medicationOrder patient bundle Shared Health Patient patient URL
NewPrescription medicationOrder ext-medicationorder-supportinginfo bundle PrescribeIT™ Pharmacy-related Observation observation URL
NewPrescription medicationOrder prescriber bundle Shared Health Practitioner practitioner URL
observation observation subject bundle Shared Health Patient patient URL
p160-m task input.valueReference bundle PrescribeIT™ Dispense Dispense URL
p160-m task subject bundle PrescribeIT™ Prescription medicationOrder ext-reference-identifier
p160-m task owner/creator bundle Shared Health erx Service Location organization URL
p160-m task for bundle Shared Health Patient patient URL
p160-m task creator/owner bundle Shared Health SAML Practitioner practitioner URL
p160-m task input.valueReference bundle PrescribeIT™ Dispense medicationDispense URL
Prescription medicationOrder ext-request-coverage bundle PrescribeIT™ Coverage (NOT SUPPORTED) coverage URL
Prescription medicationOrder ext-medicationorder-supportinginfo bundle PrescribeIT™ List - Allergies (FUTURE) List - Allergies URL
Prescription medicationOrder ext-request-detectedissue bundle PrescribeIT™ DUR detectedIssue URL
Prescription medicationOrder medicationReference contained PrescribeIT™ Medication medication URL
Prescription medicationOrder patient bundle Shared Health Patient patient URL
Prescription medicationOrder ext-medicationorder-supportinginfo bundle PrescribeIT™ Pharmacy-related Observation observation URL
Prescription medicationOrder prescriber bundle Shared Health Practitioner practitioner URL
Prescription medicationOrder priorPrescription reference PrescribeIT™ Prescription medicationOrder URL
RenewPrescription medicationOrder ext-request-coverage bundle PrescribeIT™ Coverage (NOT SUPPORTED) coverage URL
RenewPrescription medicationOrder ext-medicationorder-supportinginfo bundle PrescribeIT™ List - Allergies (FUTURE) List - Allergies URL
RenewPrescription medicationOrder ext-request-detectedissue bundle PrescribeIT™ DUR detectedIssue URL
RenewPrescription medicationOrder medicationReference contained PrescribeIT™ Medication medication URL
RenewPrescription medicationOrder patient bundle Shared Health Patient patient URL
RenewPrescription medicationOrder ext-medicationorder-supportinginfo bundle ELUS Health Pharmacy-related Observation observation URL
RenewPrescription medicationOrder prescriber bundle Shared Health Practitioner practitioner URL
Dispense medicationDispense patient bundle Shared Health Patient patient URL
Dispense medicationDispense dispenser.extension bundle Shared Health Organization organization URL
Dispense medicationDispense authorizingPrescription bundle or reference Prescription medicationOrder URL or identifier
Dispense Cancel medicationDispense patient bundle Shared Health Patient patient URL
Dispense Cancel medicationDispense dispenser.extension bundle Shared Health Organization organization URL
Dispense Cancel medicationDispense authorizingPrescription reference Prescription medicationOrder identifier
Shared Health Practitioner practitioner organization bundle Shared Health Organization - Provider Registry organization URL
Shared Health SAML Practitioner practitioner organization bundle Shared Health - eRx Service Location organization URL

The following represents the pattern of delivery of messages:

  1. The sender will post a message to the PrescribeIT™ Switch
  2. The PrescribeIT™ Switch will acknowledge receipt and post in the receiver's inbox. If the PrescribeIT™ Switch is able to process the message successfully, the POST will be responded to with an HTTP 201 status indicating that the message has been successfully stored. If not, the status will be either a 4xx or 5xx series code and an OperationOutcome instance may be returned.
  3. The receiver will poll their inbox on a scheduled basis and retrieve any messages.
  4. The receiver must then clear their inbox of all of the retrieved messages.
Posting and Polling Sequence diagram

At the time of prescribing, if the patient does not know which pharmacy they would like to direct their prescription to the prescriber can send a Deferred (Non-authoritative) Prescription Order to PrescribeIT™ with no target pharmacy using the 401 interaction.

The EMR will create an electronic prescription request that will be stored in the PrescribeIT™ database. The EMR will provide the patient with a paper prescription with the appropriate data elements needed, so that the pharmacy that the Patient chooses to go to, can request the electronic version of the prescription.

When the Pharmacy is presented with the paper prescription, they will download the electronic version. This will allow the Pharmacy to pre-populate data within their PMS solutions and position them to electronically transact subsequent actions, like dispense notifications. It is important to note that the paper prescription remains the authoritative copy.

Deferred Sequence diagram

Errors and exceptions can occur at various points within the message delivery process. The chart below identifies the various types of error condition that may occur when submitting a message to PrescribeIT™. It is expected that vendors adhere to the appropriate action that is associated with each to ensure that the outcome of these exception scenarios is consistently handled across the solution.

Scenario Detail Description Expected Action
Service Unavailable HTTP 503 - Server error

( https://tools.ietf.org/html/rfc7231#section-6.6.4)

The PrescribeIT™ server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state. Used for scheduled outages
The server MAY send a Retry-After header field to suggest an appropriate amount of time for the client to wait before retrying the request.

Sender should not retry automatically. If the Retry-after header is populated, the sender may retry in accordance with this value.

Timeout No response received This is issued by PrescribeIT™ when there is a break in communication after the message is submitted. There is no way to determine whether or not the response was successfully received by PrescribeIT™. Retryable error. Sending system is expected to retry using the same MessageHeader.id and other identifiers. If the message was received earlier by PrescribeIT™, the HTTP2xx response will be returned. If the message was not received, it will be processed normally and an HTTP response will be returned.
Maximum Retry = 3 times, then revert to a manual process.
General Server error HTTP 5xx - Server errors ( https://tools.ietf.org/html/rfc7231#section-6.6) This is issued by PrescribeIT™ when server errors are detected. From the senders perspective, It is inclusive as to whether the message was successfully delivered as this depends on where the error occurred within the PrescribeIT™.
*Excludes HTTP 503 error noted above.
Retryable error. Sending system is expected to retry using the same MessageHeader.id and other identifiers.
Maximum Retry = 3 times, then revert to a manual process.
Client Error HTTP 4xx - Client errors ( https://tools.ietf.org/html/rfc7231#section-6.5) The message has successfully processed by PrescribeIT™ but errors have been detected. Sending system (user) should address the issue that is identified in the operation outcome associated with the HTTP4xx.
Delivery Exception Scenario - Event Type 101 or 201 999 - Asynchronous Issue This is issued by PrescribeIT™ for occur with the 101 event type (Execute Tasks from an EMR). Or 201 event type (Execute Tasks from a PMS) . This is used to advise the sending application of an exception scenario A) when a destination does not pick up a message in the allotted timeframe (ageing process) or B) a 101 event type when a fax delivery failure occurs. Sending system should update their record to record that the message was not received. Further, the user should be alerted that the message was not received so that appropriate action may be taken.
Asynchronous Errors detected by Destination – Event Type 101, 201 or 401 999 - Asynchronous Technical or Business Issue This is issued by the destination/receiving application when asynchronous errors are detected on a 101, 201 or 401 event type as follows: A) technical issues such as parsing B) Business issues (e.g. patient not found). Sending system should address the issues as identified in the Operation Outcome. In rare cases (e.g. 401 authorization error) errors will be produced by the SDF that does not contain Operation Outcome.
Recipient Failures for Secure Messaging 997 – Recipient Asynchronous Reject This is used in exception scenarios associated with Clinician communications – 305 messaging. Detailed of various scenarios where this may occur are found in the table below. Refer to table below for further details.
Destination Failure for Secure Messaging 998 - Generic Hub Asynchronous Reject This is used in exception scenarios associated with Clinician communications – 305 messaging. Details of various scenarios when this may occur are found in the table below. Refer to table below for further details.

The following table provides further details with respect to errors and exceptions that may occur during processing.

Message Who Creates Reject Scenario
(refer to the last column for detail scenario description)
Detailled scenarios:
997 Destination Destination - Rejects a 305 from a single destination/location

EMR001 - Destination was not able to process this message successfully, therefore the message was NOT delivered to this Clinic/Location.

Include: messageHeader.source.endpoint (CPR Id)
Sender (Clinic/Location A) posts a bundle to the PrescribeIT™
PrescribeIT™ processes the bundle and puts it in the inbox of Clinic/Location B
Destination (Clinic/Location B) polls successfully and parses the response
Destination (Clinic/Location B) cannot process the 305 properly
Destination (Clinic/Location B) sends a Clear message queue for the 305
Destination (Clinic/Location B) generates a 997, referencing the Message Header ID (*this is as generated from the original 305 posting)
PrescribeIT™ receives the 997 and passes it through to original sender (Clinic/Location A) via inbox
Clinic/Location A polls to get the 997
Clinic/Location A - Receives and processes. Clear message queue for the 997
The following rules apply if attachments were part of the failed message.
Conformance Rule: If Clinic/Location A corrects the situation and re-issues the 305, the MUST upload the attachments again. Attachments are one time use ONLY
Conformance Rule: If the 305 fails, the system who has failed it (in this case Clinic/Location B) MUST not attempt to download the attachments
Usage Note: The Destination (Clinic/Location B) may GET attachments prior to clearing the queue if that order of operations is preferred
997 Destination Destination - Fails to GET Attachment

EMR002 - Destination received this Message, but was not successful in downloading one or more of the attachments.

(messageHeader.source.endpoint (CPR Id)



Sender (Clinic/Location A) POSTS a 305 with attachment
Destination (Clinic/Location B) gets the 305 via poll - successful
Destination (Clinic/Location B) clears the queue for the 305
Destination (Clinic/Location B) attempts a GET for the attachment but it fails (eg GUID not recognized)
PrescribeIT™ returns an HTTP 4xx
Destination (Clinic/Location B) retries but still fails.
Destination (Clinic/Location B) generates a 997 to fail the entire 305 for this destination; the Operation Outcome may detail the failed attachment if there are multiples
Destination (Clinic/Location B) must include a delete for any "successful" attachments in the clear message queue
997 PrescribeIT™ Destination - Did not successfully pick up (Poll Response Failure)

THX003 - PrescribeIT™ was unable to deliver this message to this Clinic/Location.
(MessageHeader.source.endpoint (CPR Id))
Destination polls and gets the 305 (or not)
Destination never clears the queue and it ages out (implies that it was never delivered)
PrescribeIT™ generates a 997 on behalf of the failed destination; the failed destination is indicated in the source
The 997 includes details in the Operation Outcome which indicates the swtich has created the message on behalf of the destination
HTTP4xx PrescribeIT™ PrescribeIT™ synchronous HTTP rejection with OperationOutcome

THX004 - PrescribeIT™ has detected a virus on an attachment that was related to this Message.


Sender (Clinic/Location/Location A) Posts a 305
Sender Generates an HTTP PUT for Attachment
PrescribeIT™ accepts it with an HTTP 2xx.
PrescribeIT™ then does further checking, eg virus check and rejects
The details are conveyed in the operation outcome; it will indicate the GUID of the attachment that failed
Sender receives the 998 (including GUID for 998 and the failed attachment)
Sender MUST mark the entire 305 as failed as it was not delivered to any destinations
998 PrescribeIT™ PrescribeIT™ Asynchrous Failure Message - Attachment NOT received by PrescribeIT™ in allotted time
(Aged processing)

THX005 - PrescribeIT™ did not receive the attachments that were identified in this message, in the allotted time.
Sender (Clinic/Location A) successfully POSTs a 305 with references to 2 attachments
Sender posts the first attachment but does not post the 2nd
PrescribeIT™ process ages out after a configuration amount of time (eg 30 minutes)
PrescribeIT™ creates a 998 and places in inbox of sender
Sender polls and retrieves the failure message and understands that the entire 305 has failed / did not get to any recipients
Sender must mark the entire 305 as failed as it was not delivered to any destinations
998 PrescribeIT™ PrescribeIT™ receives 305 but never receives the attachment in the alotted time

THX005 - PrescribeIT™ did not receive the attachments that were identified in this message, in the allotted time.
Sender successfully POST a 305 with references to the attachment
305 ages out because the attachment does not arrive (configurable, e.g. 20 mins)
If the message header.id is re-used, the PrescribeIT™ will detect this, check the hash against the original submission. If it matches, the PrescribeIT™ will send the original HTTP 201 response. The PrescribeIT™ will not reprocess this as it is considered as a duplicate.
The PrescribeIT™ creates a 998 and places in the inbox for the sender
The sender polls and receives the 998 and marks the entire 305 as unprocessed

HTTP 4xx PrescribeIT™ Duplicate checking
eRx_RouteMessage.resubmitMsg

THX102 - This is a duplicate message submission.
This Message Header Id has already been submitted. However, it seems that the content of the message differs from the original submission (hash values do not match). This message is rejected.
If the message header.id is re-used, the PrescribeIT™ will detect this, check the hash against the original submission. If it matches, the PrescribeIT™ will send the original HTTP 201 response. The PrescribeIT™ will not reprocess this as it is considered as a duplicate.
If the message header.id is re-used and the hash does not match the original, an HTTP 4xxx will be sent with an appropriate operation outcome
HTTP 201 PrescribeIT™ Duplicate checking
eRx_RouteMessage.foundDupMsg

THX101 - This Message Header Id has already been submitted. This is a Duplicate submission. We are providing the response we previously returned with the original (first) submission.
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.orgNotExist

THX103 - This Clinic/Organization/Location is not recognized in the Provider Registry. CPR Id: %value cprId%
Sender (Clinic/Location A)POSTs a 305
PrescribeIT™ rejects with an HTTP 4xx due to Provider or destination unrecognized.
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure eRx_RouteMessage.practitionerIsInactive

THX104 - This Practitioner is not active for this service. CPR Id: %value cprId%
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.practitionerIsnotCorrect

THX104 - This Practitioner is not recognized in the Provider Registry. CPR Id: %value cprId%

HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.SDFAppIdNotInApplicationInstance

THX105 - PrescribeIT™ is unable to confirm the Sender's Clinic/application identifier with the Conformance Version # identified in our profiles. (SDF_APP_ID: %value SDFAppId% and ApplicateInstanceID: %value appInstanceId%) does not match capability application name and vendor version.
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.SenderEntityIdNotMatchOBO

THX106 - The Clinic/Organization/Location identified as the Sender, must match the Clinic/Organization/Location for the Reply To (on behalf of).
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.senderEntitynotPassCapability

THX107 - Vendor Profiles indicate that for the Software Version identified in this message, conformance has not been registered for the following profile(s). Profile: %value profileURL%
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.destEntitynotPassCapability

THX108 - Vendor profiles indicate that the identified Destination is unable to process this profile for the version identified. Profile: %value profileURL%
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.OrgIsnotCorrect

THX109 - Unable to validate this Organization/Clinic/Location's existence or registration for this service (Organization role is not correct). CPR Id: %value cprId%
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.practitionerIsnotMD

THX110 - This Practitioner is not active for this service. CPR Id: %value cprId%
HTTP 4xx PrescribeIT™ PrescribeIT™ reject due to synchronous validation failure
eRx_RouteMessage.destHeadernotmatchOBOOrg

THX111 - The Destination Clinic/Organization/location must also appear as a Recipient within the communication message.
HTTP 4xx PrescribeIT™ Attachment Validation Failure
eRx_Attachment.attachmentDoesNotExist

THX112 - PrescribeIT™ is comparing the sent attachment to the details provided in the original communication.
This attachment cannot be found.
Attachment arrives but no associated with the 305, or if the validations on it fail, including the size is exceeded, the type is not recognizedor does not match the size/content type from the 305.
When sender receives the 4xx, they should address the issues and re-try
HTTP 4xx PrescribeIT™ Attachment Validation Failure
eRx_Attachment.contentTypeNotCorrect

THX113 - PrescribeIT™ is comparing the sent attachment to the details provided in the original communication
The mime type of this attachment does not match what was specified in the communication message.
HTTP 4xx PrescribeIT™ Attachment Validation Failure
eRx_Attachment.attachmentSizeNotCorrect

THX114 - PrescribeIT™ is comparing the sent attachment to the details provided in the original communication.
The size of this attachment, does not match what was specified in the communication message.
HTTP 4xx PrescribeIT™ Attachment Validation Failure
eRx_Attachment.attachmentSizeExceed

THX115 - The accumulative size of 'all' attachments received is exceeding the maximum limit of 50MB.
HTTP 4xx PrescribeIT™ Attachment Validation Failure
eRx_Attachment.attachmentGUIDnotExist

THX116 -Attachment identifier is required.
HTTP 4xx PrescribeIT™ Attachment Validation Failure
eRx_Attachment.attachmentSenderNotValid

THX117 - The Sender of this upload attachment request is not authorized. The sender does not match the sender of the original communication message.
HTTP 4xx PrescribeIT™ Attachment Validation Failure
eRx_Attachment.attachmentCheckSumNotCorrect

THX118 - The PrescribeIT™ has already received and uploaded an attachment for this identifier/url. This attachment does not match what was previously uploaded. (hash values do not match).
HTTP 4xx PrescribeIT™ Attachment Validation Failure - download
eRx_Attachment.attachmentDownloadNotAuthorized

thx119 - The Sender of this request is not authorized to download this attachment. Only the sender or recipient identified in the original message may request the download.
HTTP 4xx PrescribeIT™ PrescribeIT™ receives a 997 from Destination but cannot process Sender POSTs a 305 and it is successful
PrescribeIT™ delivers the 305 to the destination
Destination successfully picks up the 305 and deletes from the queue
PrescribeIT™ receives a 997 from the destination (based on Message Header ID)
The 997 cannot be processed by the swtich as it fails validation
PrescribeIT™ generates an HTTP 4xx back
*** This should be escalated by the Central service to process manually. In addition, the clinic who generated the 997 and received the rejection is responsible for escalation to ensure the sender understands that this rejected
*** No further action taken; this is NOT routed to the inbox; sender beleives that this was successfully delivered

The PrescribeIT™ specification follows the profiling approach documented in the Shared Health implementation guide. There are base profiles at the interaction level as well as Bundle profiles, Message Header profiles and task profiles. In this guide, profiles are organized into the following categories:

  • Interaction Profiles
    • Transport level profiles
    • Constrains data such as Creators (e.g. must be practitioner for EMR requests) and Owners (e.g. must be a Pharmacy Organization
  • Task Profiles - Current
    • Apply fixed values for key data such as the Profile ID's and the Task type codes, e.g. New RX Fill Request has a fixed value of E-110M. These profiles define the overall structure of a given task.
  • Payload Profiles
    • These are the core profiles for each resource within the message
    • There may be more than one profile relating to a single resource, e.g. Shared Health Task Profile which constrains globally for all Tasks, and the Shared Health EMR Request Task, which has further constraints that are specific to EMR Request Tasks
  • Data Type Profiles
    • Constraints that apply to a particular data type, e.g. Address

In addition to the Shared Health identifiers from the Shared Health implementation guide, the PrescribeIT™ service makes use of the following additional identifiers:

The majority of the business identifiers will have the system expressed as an OID where the mandatory system (uri) and value (string) will comprise a globally unique identifier. The “value” contains the human-readable component. OIDs must be structured as shown in the table below.

The OID structure or URL is identified in the table below. In all cases, the identifiers (system string – OIDs) must be unique and this will be validated during conformance testing and at time of registration of each application instance.

Identifier Branch OIDs only Recommended OID Structure Notes
Vendor (Organization OID) Base OID only Vendor must obtain an Organizational OID if one does not already exist. Please call PrescribeIT™ Technical support for assistance as this must be a registered OID, under www.HL7.org or another OID registration body.
Application Instance Identifier N/A Vendor.ApplicationInstanceID Conformance Rule: The Application Instance ID must be assigned by the vendor as a branch under the vendor OID (see above). This identifier will be registered with PrescribeIT™ Switch as part of the EMR/Pharmacy registration process. There is no human readable portion (extension) for this.
Medication Order Identifier
(RX or Renewal Identifier)
.2 [Vendor].[ApplicationInstance].2 Conformance Rule: A branch, ".2" is appended to create a unique namespace for the Medication Order Identifier
MedicationOrder.priorPrescription.extension [Vendor].[ApplicationInstance].2 Same as above
Requisition Identifier (grouping Identifier) .3 [Vendor].[ApplicationInstance].3 Conformance Rule: A branch, ".3" is appended to create a unique namespace for the Requisition ID
MedicationDispense Identifier .4 [Vendor].[ApplicationInstance].4 Conformance Rule: A branch, ".4" is appended to create a unique namespace for the MedicationDispense.Identifier

The majority of technical identifiers will have the value expressed as a FHIR id type. Key ids are shown in the table below.

ID Notes
Bundle.id Usage Note: This value is assigned by the PrescribeIT™ system upon receipt of a bundle and returned synchronously in the response to that bundle. This ID should not be confused with the traceID that is also returned in the response and is generally used when diagnosing message failures within the PrescribeIT™ system logs. The Bundle.id is also used by receiving systems to remove the bundle from their inbox after they have successfully retrieved the bundle.
MessageHeader.id Usage Note: This value is assigned by the system that creates a bundle and is unique to the specific message instance of the bundle and the uniqueness of this value will be validated by the PrescribeIT™ service. This value is sometimes referenced in error messages.

Code values must use the defined Value/code sets. Within the Grid View the vocabulary set is provided as the 'Binding'. It is a hyper-link that will take you to the code set. Code values must use the defined Value/code sets. Within the Grid View the vocabulary set is provided as the 'Binding'. It is a hyper-link that will take you to the code set. Customized value sets are maintained by Canada Health Infoway. The hyper-link will take you to the Infoway site, where you will have to login, in order to get access to the Infoway Terminology Gateway. The Terminology Gateway is a web-based solution that enables the distribution and sharing of terminology concepts, subsets and concept maps, making them available for web browsing, download or real time query. Some of the Value Sets are a fixed list and linked specifically to a Message Specification version (version will be noted in the url). Other Value Sets will be updated periodically by Canada Health Infoway. For these, the Vendors should (through the Terminology Gateway) subscribe to notifications so they will be informed of the changes being made and can make the necessary modifications to support. (PrescriptionMedicinalProduct. PrescriptionDrugForm. PrescriptionRouteOfAdministration. PrescriptionAdministrationSite. PrescriptionForUse.)

To get a view of all value sets used in a particular implementation guide, use the artifact list. Value sets are also identified within the Profiles with a link to the supported value set.

A value set may be comprised of multiple code sets. Codes are not necessarily unique within a value set, therefore when defining the system for a code, it must reflect the ‘code system url’ and not that of the value set. More information can be found here: FHIR Value Sets

The following is a list of conformance rules that must be adhered to. Adherence will be validated through the Conformance program. The rules listed here are either 'general' for the program, or are associated to Tasks. These rules applyin addition to the Shared Health rules specified in the Shared Health implementation guide. Note: This table is also found in the EMR and PMS Vendor Requirements document.

Type Resource Conformance and Usage rules
General All All tasks that are marked as "high priority" must be presented at the top of the queue.
General Bundle 101 A Bundle may include several Tasks but all must be for a single patient. From an EMR:
Conformance:  The EMR may wish to bundle these, OR they may wish to send them separately and either is acceptable.  If possible, it is best that all related patient events are published together.
It will be the responsibility of the Pharmacy software to aggregate all incoming messages from the same patient from the same prescriber for viewing purposes so that the pharmacist is able to manage all events for a given patient at the same time.
General Bundle 201 A Bundle may include several Tasks but all must be for a single patient. From a PMS:
Conformance:  If the Pharmacy is able to bundle tasks for a given patient, they should do so.
RX Fill Request e110-m Prescriptions for selected Devices will be codified as a part of the Canadian Clinical Drug Data Set. If a code is not available a textual description of the device will be submitted and displayed to the Pharmacist.
RX Fill Request e110-m Dosage specification:
Conformance Rule:
There are two ways to convey dosage; EMR's (and PMS for eRAR) MUST include the entire dosage instruction as text in the RENDERED_DOSAGE_INSTRUCTION.  This MUST include the following:   Dosage quantity, dosage unit, dosage frequency, route of administration and where applicable, the administration site.  In addition, any additional information (e.g. take with food, starting one day before dental appointment).

The second mechanism, that should be supplied In addition to text is as follows:  EMR's, (and PMS for Renewal) who support discrete data elements are strongly encouraged to use the structured dosage lines to convey this information as it is very useful to PMS who can import some of the data elements and limit the amount of manual intervention for the pharmacist to re-key and interpret data.  It is also essential for DIS mapping in some cases. 
Renewal RX Drug Fill request e120-m Multiple medication orders/devices in a single request.
Conformance Rule:
The prescriber may initiate a renewal request for one or more medications or devices.  Each medication will include a reference to the “prior prescription number”.  This identifier has been assigned by the EMR and is associated with each Medication Order within the EMR. The PMS will use this identifier to link with the prior prescription for which the renewal is requested.
RX Renewal Create Request p160-m Use Cases for Renewal:
A renewal request may be directed to the same Prescriber in the same clinic who wrote the initial prescription.
A renewal request may be directed to a different Prescriber, in the same clinic, where the initial prescription was written.
A renewal request may be directed to the same or different prescriber in a different Clinic.
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Renewal Response Bundle:
Conformance Rule:
The Renewal Bundle MUST include all medications that were part of the same Renewal request.
This is identified by the Requisition ID, aka the "GROUPING_IDENTIFIER" that is assigned to each related task within a bundle for the Renewal request.
The bundle must include a Renewal response task (e.g. approved denial, etc) for each medication in the Renewal Request grouping.
Each Renewal response task will reference the requisition ID of the Renewal request." 
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Renewal Response:
Conformance Rule:
Each medication in the Renewal request MUST be responded to with either a Denial, Approved, Approved with Changes or Under Review in the initial response.    Further, the Renewal response bundle, MAY include one or more New RX orders that reference a medication in the Renewal request.  This may be useful if the Prescriber is replacing a medication within the request with a different medication as the Pharmacist will have the complete overview of the patient treatment in one response.
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Approved:
Conformance Rule:
An Approved status is used when the Renewal is approved with the same drug.  It may have a different quantity or number of refills. 
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Approved with Changes:
Conformance Rule:
An Approved with Changes is a prescription for the same drug that has a different dose or frequency or “prn” status or instructions or strength or form.   In other words, it will be used where the prescription is for a drug with the same generic ingredients and route
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Approved with Changes:
Usage Note:
The  "same drug" means "same generic ingredients and route"; a change of drug must be handled as a Denial, with a reason code = "Replaced with a different Medication"
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Approved with Changes:
Usage Note:
  The same drug can have multiple DINs; the pharmacy can ask for a different brand name, but it is still the same drug
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Conformance Rule:
  The Prescriber will include a textual description where appropriate.  This would be a substantive change such as a change in dose, frequency or patient instructions, or a change of classification of drugs or the DIN itself which is used to treat the same condition. 
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Renewal Response:
Usage Rule:
Upon receipt of the Renewal response, the status should be shown to the Pharmacist (e.g. Denial, Approved, Approved with Changes)
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Approved with Changes:
Conformance Rule:
The PMS Must display the “Approval with Changes “text”  to the Pharmacist/Pharmacy Technician if it is present in the Message
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Renewal includes two Medications; the prescriber issues one medication that covers both
Conformance Rule:
  If there is a request for a single medication that the prescriber splits into to Medications, the prescriber will respond with a Denial and issue two new RX Orders in the same bundle that have a reference to the Renewal request Grouping ID as specified in the Renewal request.

Also, the prescriber may replace for one medication in the Renewal request with two (combination medication that is then split into two).  Rationale:  This could occur because of a drug shortage, or where the drug claim cost is too high for a combination drug
nd with a Denial for both and issue a new RX Orders in the same bundle thaIf there are two or more medications submitted and the prescriber replies with a single medication, the prescriber will respot have a reference to the Renewal Grouping ID as specified in the Renewal request.
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
Renewal Response:
Usage Rule:
When a prescriber responds to a renewal request no matter which replies they send that renewal request is considered complete on both sides (EMR/PMS) and reaches a terminal end state. No further actions or messaging can happen on that specific renewal request message. If further actions or messaging is required the PMS would need to initiate another renewal request or the prescriber would initiate a New Rx or Renewal Rx or whatever message would be appropriate.
RX Drug Renewal Create p160-m
e161-m
e162-m
e163-m
e164-m
 Renewal Response – Under Review:
Usage Rule:
Upon receipt of an "under review", the PMS should consider this to be "closed" on their side as there will be no subsequent transactions relating to the Renewal. Any subsequent action by the prescriber to renew modify the dose of the medication will result in a Prescriber renewal (e120) that references the most recent prior medication order. If the Pharmacy wishes to inquire about the status of renewal that has been "under review", they may generate another renewal for this medication that is distinct and separate.
MedicationOrder Representative DIN Conformance rules for PMS software:
MedicationOrder Representative DIN PMS Must NOT display the representative DIN to the user
MedicationOrder Representative DIN Must display the drug name from the message, along with the form and strength, if present in the message, and the route, which is mandatory. Once the application knows the ingredient, it would be appropriate to show the pharmacist the generic name
MedicationOrder Representative DIN The PMS may use the “ingredient(s)” associated with the representative DIN, plus the form (if submitted) and the strength (if submitted) and route, to automate and present a list of DINs to the pharmacist that matches this criteria. 
The pharmacist can select a medication from this list or may select another generic equivalent with the same prescribed dosage
MedicationOrder Representative DIN Note: If the form and route are not supplied in the message, then the prescriber must specify the dosage. 

PrescribeIT™ is a Canada Health Infoway electronic prescription service meant to establish an eco-system where prescribers through their EMR systems can exchange digital prescriptions with pharmacists through their PMS systems.

At the heart of this eco-system is PrescribeIT™ Exchange, which is a central hub for exchanging digital prescription messages between EMR and PMS systems.

We shall discuss the solution security measures from an EMR and PMS systems vendor point-of-view. Security measures that are of no concern to EMR and PMS systems integration efforts are considered out-of-scope for this document.

The measures to be discussed are:

  • Identity Management
  • Authentication
  • Authorization
  • Data in Transit
  • e-Signature

Identifying the interactive entities in a digital security realm and binding the real world identities of these entities to their digital identities is what IDM is about.

In the PrescribeIT™ security realm we can identify the following real world entities:

Human Entities
  • Prescribers
  • Pharmacists
  • Administrators
System Entities
  • EMR Systems
  • PMS Systems
  • PrescribeIT™ Switch

Binding a real world identity to a digital one is done through creating user and system accounts in a digital identity repository. The level of certainty of the real world identity is called assurance level. As the certainty of the real world identity gets higher the IDM system is seen to posses a high assurance level.

In the previous section we have identified the six real-world identities that exist in the PrescribeIT™ digital security realm, next we shall describe the process of binding each identified real world identity to its digital self.

Prescribers play the role of the prescriber in the PrescribeIT™ security realm, they create the digital prescription.

Prescribers are issued PrescribeIT™ digital identities through Provider Registry service.

The Provider Registry is run by the Provider Management Group.

The Provider Registry provides an administration console that would allow PrescribeIT™ Administrators to create and onboard providers. It is expected that Infoway or Jurisdictional resources would perform any necessary credential verifications required for Providers before proceeding to create accounts in the Provider Registry.

The actual registration process will vary by Jurisdiction. The steps below describe a conceptual summary of the Provider registration process into the PrescribeIT™ Service.

  1. Provider Registry Team Member or Provincial Health Authority staff visits/contact the clinic and engages a prescriber for the PrescribeIT™
  2. If demographic information can't be leveraged from already existing Provincial Health Authority assets like the Provincial Provider Registry, a Provider Registry Team Member shall manually gather demographic information, the prescriber's license #, checks the college credentials and validates the prescriber's ID
  3. Terms and conditions are reviewed and agreed to by the prescriber, this step can happen through Provincial Health Authority assets and will be different per jurisdiction.
  4. Prescriber Cell Phone number is captured for 2nd-factor authentication. This is captured in the registration details.
  5. Provider Registry Team Member creates the account in the Provider Registry
    1. The demographic data is entered into the Provider Registry
    2. The second-factor channel and 2nd-factor ID are entered into the Provider Registry.

For the purpose of PrescribeIT™, up to the current release, pharmamcists do not have any personal role to play. Prescriptions created by Prescribers are directed to a specific Pharmacy, but not a specific pharmacist.

Any pharmacist present at the time, the pharmacy PMS get a prescription to fulfill, will just act on it. The PMS will be responsible to secure access to prescriptions received from the PrescribeIT™ service as well as auditing pharmacy staff actions.

Out-of-scope

For EMR Systems to join the PrescribeIT™ eco-system or virtual closed network it must be registered at the service.

The Registration process is made out of 2 steps:

  1. EMR instance identification
  2. EMR instance SDF account creation

As a clinic is enrolled into the PrescribeIT™ service the EMR instance used by the clinic shall have a PrescribeIT™ account created and issued a PrescribeIT™Vendor Application Instance ID.

Also, a Provider Registry ID will be issued to the clinic which is more of a business level identifier representing the clinic that owns the EMR instance

The second step will be for the EMR instance to be registered with the PrescribeIT™ Service Delivery Framework (SDF) layer. SDF is the API gateway to PrescribeIT™ services. All communications between EMR systems and PrescribeIT™ must go through the SDF layer. Upon registering with SDF the EMR instance will be issued an SDF PKI x509 digital certificate, the SDF will also issue a systems ID for the EMR instance, which is separate from the Vendor Application Instance ID and is more of a technical identifier.

The x509 digital certificate will be used to authenticate the EMR instance/system to the SDF layer for all communications between the 2 systems. Without this certificate, the EMR instance will have no access to any PrescribeIT™ services.

Below are the EMR instance/system account attributes recorded/issued by PrescribeIT™:

  1. Vendor Application instance ID
  2. SDF System ID
  3. PKI x509 digital Certificate
  4. Clinic Address
  5. Clinic Phone Number
  6. Clinic Fax
  7. Clinic Provider Registry ID
  8. Software Vendor ID
  9. Software Title

For PMS Systems to join the PrescribeIT™ eco-system or virtual closed network it must be registered with the service.

The Registration process is made out of 2 steps:

  1. PMS instance identification.
  2. PMS instance SDF account creation.

As a pharmacy is enrolled into the PrescribeIT™ service the PMS instance used by the pharmacy shall have a PrescribeIT™ account created and issued a PrescribeIT™ Vendor Application Instance ID.

Also, a Provider Registry ID will be issued to the pharmacy which is more of a business level identifier representing the pharmacy that owns the PMS instance

The second step will be for the PMS instance to be registered with the PrescribeIT™ Service Delivery Framework (SDF) layer. SDF is the API gateway to PrescribeIT™ services. All communications between PMS systems and PrescribeIT™ must go through the SDF layer. Upon registering with SDF the PMS instance will be issued an SDF PKI x509 digital certificate, the SDF will also issue a systems ID for the PMS instance, which is separate from the Vendor Application Instance ID and is more of a technical identifier.

The x509 digital certificate will be used to authenticate the PMS instance/system to the SDF layer for all communications between the two systems. Without this certificate, the PMS instance will have no access to any PrescribeIT™ services.

Below are the PMS instance/system account attributes recorded/issued by PrescribeIT™:

  1. Vendor Application instance ID
  2. SDF System ID
  3. PKI x509 digital Certificate
  4. Pharmacy Address
  5. Pharmacy Phone Number
  6. Pharmacy Fax
  7. Pharmacy Provider Registry ID
  8. PMS Software Vendor ID
  9. PMS Software Title
PrescribeIT™ Switch

The PrescribeIT™ Switch will have its own Public PKI x509 digital certificate that identifies the PrescribeIT™ service to the outside world. This certificate will be used by PrescribeIT™ to digitally sign all prescriptions going through the PrescribeIT™ service.

Authentication is the act of verification of digital identities. The Solution uses SAML v2.0 authentication tokens as means of user authentication. The tokens are issued by the Secure Token Service (STS), a component of the solution

PrescribeIT™ implements a layered authentication approach. First PrescribeIT™ authenticates the connecting systems using SSL mutual authentication against the certificate that was issued in the system registration step. Secondly, PrescribeIT™ authenticates the user using SAML v2.0 identity claims tokens.

PrescribeIT™ will only accept SAML tokens issued by PrescribeIT™ Secure Token Service (STS). To be issued a token a user must undergo a multi-factor authentication process. To request a Token from the STS the user must use a registered and trusted EMR system instance as the STS will mutually authenticate the connecting System as well.

Once a Request is received by the STS it will start an out-of-band second-factor authentication process in order to authenticate the user, using the user registered cell phone as the second factor of authentication, once successful the STS will issue the requested SAML v2.0 authentication token.

SAML diagram

The EMR password based login is considered as the Prescribers first-factor of authentication.

EMR to send the token with each and every message directed from the prescriber to PrescribeIT™.

Since there is no direct interaction between the prescriber and the PrescribeIT™ Switch, current main-stream 2-factor authentication schemes doesn't fit the PrescribeIT™ workflow.

A Secure Token Service (STS) would be ideal in such a situation. An EMR would request a Secure Token for its logged-on user to be able to exchange message with the PrescribeIT™ on behalf of the user. The STS would invoke a 2nd factor of Authentication and upon success would issue a secure token to the EMR. The EMR would store the token for a predefined amount of time and would use it as the authentication token in the claims based authentication relationship with PrescriebIT.

The EMR must store the token in a user centric storage, where only the user issued the token can have access to it, i.e. a user session in a web application. If the token will be stored on disk/DB it must be secured as such OS or DB level users won't have access to it through OS/DB interfaces.

For One Time Password (OTP) in SMS will be used as 2nd factor of Authentication.

The EMR will send a request to the PrescribeIT™ STS to start a digital prescription session which will trigger the STS to send an SMS message to the prescriber registered cell phone. The SMS will contain a short lived One Time Password (OTP). Upon receiving the SMS the prescriber should enter the OTP contained in the SMS in an EMR screen that will trigger the EMR to send a request to the STS to obtain an authentication token. The STS will verify the OTP in the request and if valid will issue an authentication token for the prescriber that is valid for a predefined amount of time. All subsequent interactions between the EMR and PrescribeIT™ must contain the previously obtained authentication token.

PMS systems support 1 mode of communications with PrescribeIT™:

  1. Pull Mode

PMS systems connecting to PrescribeIT™ in a pull mode shall be authenticated using TLS Mutual Authentication using the PrescribeIT™ SDF digital certificate issued to the PMS system at registration time.

The PrescribeIT™ main resources are prescriptions and the different auxiliary interactions that complete the life cycle of a digital prescription.

The main goal of the access control stance of the PrescribeIT™ Switch is to build logical encapsulations of data interactions between Prescribers, EMR Systems and the PMS systems.

There is no direct interaction between a Prescriber and the PrescribeIT™ Switch. Prescribers use their EMR applications to create/Cancel prescriptions. And the EMR sends the digital prescription to the Switch for delivery to a specific Pharmacy or for later pick up by the pharmacy of the choice of the patient.

For Prescribers the solution access control stance would be one of verification. Where the solution would verify that the Prescriber still in good standing. This would be done by checking the Prescriber status in the Provider Registry system. If the prescriber still marked as active in the Provider Registry system; the transaction would be allowed, while if the Prescribers status in the Provider Registry changes to inactive/disabled or the prescriber is no longer exist in the Provider Registry system, the transaction will be flagged for error.

Only registered and compliant EMR Systems will be allowed to connect and exchange messages with PrescribeIT™. As mentioned before each connecting system will be issued a PKI x509 digital certificate for system identification and will have a System account created in PrescribeIT™ SDF.

A registered EMR system instance would have the following attributes:

  1. PKI Cert DN
  2. Vendor Application Instance ID
  3. SDF System ID
  4. Application Profile

PKI Cert DN

This is the DN assigned to the EMR System in its PKI Cert.

Vendor Application Instance ID

A unique digital identifier representing a specific instance of an EMR application. The Application instance ID will be an auto generated GUID or a PrescribeIT™ assigned OID formatted number.

SDF System ID

A unique digital identifier representing specific instance of an EMR application to the PrescribeIT™ SDF layer (API Gateway)

Application Profile

This attribute will indicate that this system is acting under the EMR application Profile, which will give the system the permission to only send specific interactions to the PrescribeIT™ Switch.

Application Profile will be implemented as a string based attribute with a value of EMR-eRx

The IDs associated with EMR System instance will be used to scope any data interaction between the System and PrescribeIT™.

Only registered and compliant PMS Systems will be allowed to connect and exchange messages with PrescribeIT™. As mentioned before each connecting system will be issued a PKI x509 digital certificate for system identification and will have a System account created in PrescribeIT™ SDF.

A registered EMR system instance would have the following attributes:

  1. PKI Cert DN
  2. Application Instance ID
  3. SDF System ID
  4. Application Profile
  5. List of Pharmacies associated with this PMS system

PKI Cert DN

This is the DN assigned to the EMR System in its PKI Cert.

Application Instance ID

A unique digital identifier representing a specific instance of a PMS application. The Application instance ID will be an auto generated GUID.

SDF System ID

A unique digital identifier representing specific instance of an EMR application to the PrescribeIT™ SDF layer (API Gateway)

Application Profile

This attribute will indicate that this system is acting under the PMS application Profile, which will give the system the permission to only send specific interactions to the PrescribeIT™ Switch.

Application Profile will be implemented as a string based attribute with a value of PMS-eRx

List of Pharmacies

As some Pharmacy chains will be using an aggregator system to connect to the PrescribeIT™ Switch. This aggregator system will be pulling prescriptions for more than a single pharmacy. This list will be a list of Pharmacy identifiers allowing the PrescribeIT™ Switch to know which prescriptions to send back as part of such a system pull request.

As a digital prescription is classified as PHI, its privacy and confidentiality must be maintained at all times.

HTTPS will be used to encrypt data as it travels across the network from EMR systems to the PrescribeIT™ and from PrescribeIT™ to PMS systems.

TLS 1.2 or higher would be the only allowed HTTPS standard to be used with 128 bits ciphers or stronger.

When a prescriber composes a new prescription and then presses the "sign and send" button, the EMR system acts as an electronic agent of the prescriber in the production of this electronic information. The EMR system ensures that the electronic information signifying this act of signing is placed in a FHIR message along with the prescription record, together with the SAML token that uniquely identifies the signatory, as well as adding electronic information recording a time and date stamp to ensure that each signed prescription is unique.

PrescribeIT™ (which has already authenticated the prescriber using 2FA) receives the prescription from the prescriber's EMR system and then, acting as an electronic agent of the prescriber, digitally signs the prescription.

The now digitally signed message is routed to the PMS server, acting as an electronic agent of the pharmacy, receives, verifies, and processes the prescription. The digital signature attached to each prescription message is permanent, immutable, and non-repudiable. It can (and should) be archived by the receiving PMS as evidence that the prescription was securely received from PrescribeIT™ on-behalf of the prescriber and that PrescribeIT™ guarantees that the contents as received are precisely what the prescriber sent.

The standard messaging workflow presumes that messages are targeted to a particular point-of-service recipient. With deferred prescriptions, no specific pharmacy is identified in the MessageHeader, so these messages will not appear in the "in-box" of any pharmacy. Instead, a different workflow is employed.

  1. EMR submits the unassigned prescription to the PrescribeIT™ Switch using the 401 message event, POSTing it in the same manner as they would any other message.
  2. The PrescribeIT™ Switch assigns a short human-readable alpha-numeric "key" (PrescribeIT™ Rx ID) to the message and adds it to the message as a tag. It also adds tags for the patient's last name and date-of-birth.
  3. The PrescribeIT™ Switch returns a copy of the updated (tagged) message to the EMR as part of the standard HTTP 201 Created response.
  4. The EMR extracts the 'key' (PrescribeIT™ Rx ID) and includes it prominently on the printed authoritative copy of the prescription made available to the patient.
  5. The patient chooses the pharmacy where they want to have their prescription filled and gives the authoritative paper script to the pharmacy
  6. The pharmacist or technician types the "key" (PrescribeIT™ Rx ID) into their PMS which then submits a query to the PrescribeIT™ Switch using the key and either the patient's last name or date of birth to retrieve the message
  7. The PMS loads the information for all of the MedicationOrders and other information in the message in the same manner it would have if the message had been directed.
  8. The PMS deletes the message Bundle from the PrescribeIT™ system in the same manner it would have if it were downloading directed messages.

Tags are sent as "Codings" with a combination of 'system' and 'code'. The two pieces of information will be expressed in the message as follows:

Tag type 'system' 'code' notes
key http://prescribeit.ca/fhir/CodeSystem/message-key the PrescribeIT™-assigned message key (Rx ID) The key will be an alphanumeric string with constraints on letters used to minimize the chances of transcription errors
birth date http://prescribeit.ca/fhir/CodeSystem/birth-date the patient's date of birth Expressed as YYYY-MM-DD. This is the date of birth as specified in the message and on the authoritative prescription (not necessarily what's in the PMS's records)
last name http://prescribeit.ca/fhir/CodeSystem/last-name the patient's last name This will be the patient's last name

The following shows how Example A1 would be adjusted when echoed back in the POST'sHTTP 201 Created response

<Bundle xmlns="http://hl7.org/fhir">
  <id value="example-a1-401-e180"/>
  <meta>
    <profile value="http://prescribeit.ca/fhir/StructureDefinition/interaction-bundle-401"/>
    <profile value="http://sharedhealth.exchange/fhir/StructureDefinition/profile-bundle-message"/>
    <tag>
      <system value="https://fhir.infoway-inforoute.ca/CodeSystem/sharedspecificationversion"/>
      <code value="PrescribeIT2.0"/>
    </tag>
    <tag>
      <system value="http://prescribeit.ca/fhir/CodeSystem/message-key"/>
      <code value="S724THSR5LDA"/>
    </tag>
    <tag>
      <system value="http://prescribeit.ca/fhir/CodeSystem/birth-date"/>
      <code value="2012-06-07"/>
    </tag>
  </meta>
  ...
</Bundle>
  

Note: The tags don't have to be in any particular order.

For information on retrieval of deferred prescriptions, look at the Queries and Operations page.

Cancelation of deferred prescriptions is expected to be handled manually by contacting the patient.

PrescribeIT™ has many internal configuration parameters that vendors do not necessarily need to know in order to conform and that are subject to change. However, there are few production configuration parameters worth noting including the following:

  • OTP validity TTL: 300 seconds
  • Attachment Max Size: 52428800 bytes
  • Aged Message Processing Response Wait Time In Minutes: 5
  • Aged MessageProcessing Unrouted Message Age In Minutes: 30
  • eFax Message Delivery Processing Retry Count: 5
  • eRx Inbox MessageProcessing Batch Count For Message Polling: 20
  • SAML validity TTL: 480 minutes