PrescribeIT® Specification and Guide Version 5.0

 

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: 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 requirements, Refer to the functional specification documents that were included in your specification package). These interactions are in addition to the Shared Health interactions found in the Shared Health implementation guide and any other supplemental features that support the exchange of any of electronic messages (i.e. 2FA, formulary query, provider registry queries etc.

  • 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 which is targeted to be received or retrieved by 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 targeted to be received or retrieved by a selected pharmacy that is also registered for the service.
  • Cancel Rx Fill Request: (e140-m) A request by a registered prescriber that a pharmacy cancel a previously submitted request for the filling of a prescription.
  • Cancel Rx Fill Responses: (e141, 2, 3-m) The pharmacy transmits a response indicating whether they were able to cancel the prescription as requested or they were not able to cancel the prescription as request and acted on it in a different way.
  • Discontinue Rx Fill Request: (e150-m) A request by a registered prescriber that a pharmacy discontinue a previously submitted request for the filling of a prescription.
  • 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 copy is stored by the PrescribeIT® system for retrieval by a pharmacy who is provided a paper/faxed copy of the prescription.
  • 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/clinic.
  • 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).
  • Pharmacist Adapt: (p170) A pharmacy notifies a prescriber that they adapted a prescription that was prescribed by the prescriber
  • Pharmacist Prescribe: (p190) A pharmacy notifies a prescriber of a medication that they are prescribing for a patient under their scope of practice (i.e. renewal extensions, prescribing for minor aliments etc.)
  • Clinician Communication: (305) Secure message exchange between the prescriber/clinic and the pharmacy

PrescribeIT® is a national e-prescribing service that provides safer and more efficient medication management by enabling the digital transmission of prescriptions, prescription related messages as well as secure communication messaging.

Given PrescribeIT® is a national service, each jurisdiction is consulted in order to provide a solution that complies with their respective e-prescribing policies. As such, some features may or may not be applicable to all jurisdictions or may vary between the jurisdictions.

A summary of the current jurisdictional business scope as it relates to the PrescribeIT® interactions and tasks type that are in place can be found below.

Interaction Jurisdiction Task
EMR Initiated
101 All excluding QC e110 Prescription
101 All excluding QC e120 Renewal
101 All excluding QC e140 Cancel
101 All excluding QC e161 Denial
101 All excluding QC e162 Approved
101 All excluding QC e163 Approved with changes
101 All excluding QC e164 Under Review
401 All e180 Deferred
401 QC e110 Prescription
401 QC e120 Renewal
401 QC e150 Discontinue
401 QC e161 Denial
401 QC e162 Approved
401 QC e163 Approved with changes
401 QC e164 Under Review
PMS Initiated
201 All p160 Renewal Request
201 All excluding QC p141 Cancel Denied
201 All excluding QC p142 Cancel Approved
201 All excluding QC p143 Cancel Refills Revoked
201 All excluding QC p170 Adapt
201 All excluding QC p190 Pharmacist Prescribe
201 All p200 Dispense Notification
201 All p210 Dispense Cancel Notification
Interactions - No Tasks
305 All N/A Clinical Communication
901 All N/A Fax Delivery Notification
902 AB N/A Jurisdictional RX ID Notification
903 QC N/A Jurisdictional RX Summary Notification
997 All N/A Generic Recipient Error
998 All N/A General Hub Async Reject
999 All N/A Asynchronous Message Reject

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®

Refer to 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

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 Send Deferred or Held 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.

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 50 Tasks to be included in a single bundle. The guide defines a number of tasks that can be conveyed within a message and grouped either individually or mixed together. Messages support conveying multiple tasks to ensure that content can be delivered in a single group of related information. Refer to the PrescribeIT® Version 5.0 Jurisdictional Rules and Task Grouping Excel spreadsheet rules for a full list of scenarios.

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 various resources, including 'patient', 'practitioner', 'organization' and the 'prescription'. The important business identifier included each task resource is the Task.extension(groupIdentifier). This business identifier is assigned by the sending application and is used to group tasks together that need to be processed and managed together.

There are many resource Constraints, Conformance Rules, and Usage Notes to ensure conformity to the specification. For example, in PrescribeIT® Message Bundle for Tasks, 'max50tasks' is used to to limit the number of tasks in a message bundle to ‘50’. Within each RX 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
Discontinue RX Fill Request
e150-m - Discontinue RX Fill Request N/A EMR PMS requested Subject: MedicationOrder - Discontinue
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

The FHIR specification contains two main types of identifiers, namely logical and business.

A logical identifier normally has the label of type "id". Once assigned to a particular resource, this value never changes and it uniquely identifies the resource both within a bundle and across bundles (e.g. you might refer to a resource from another bundle and you would do this by referring to its' logical "id"). Logical identifiers should never be seen or used by actual EMR or PMS users. Logical identifiers should only be used by applications and not people.

A business identifier is a real life identifier that is understood by EMR or PMS users and is used to day to day business. It is normally labelled as type "identifier". This identifier is not unique across resources because the same identifier might be used for a 110 or a 140 (as an example). A good example of a business identifier is an EMR placer number (otherwise known a prescription number that uniquely identifies a prescription).

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
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

Further details can be found in Deferred Prescriptions Bundle or Held Prescriptions sections which also contain flow diagrams.

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
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.
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 (CPRID)
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 (CPRID)



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 (CPRID))
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 Created 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 Created 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. CPRID: %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. CPRID: %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. CPRID: %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). CPRID: %value CPRID%
HTTP 4xx PrescribeIT® PrescribeIT® reject due to synchronous validation failure
eRx_RouteMessage.practitionerIsnotMD

THX110 - This Practitioner is not active for this service. CPRID: %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. 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.
Patient Identifier .1 [Vendor].[ApplicationInstance].1 Conformance Rule: A branch, ".1" is appended to create a unique namespace for Patient.identifier(senderPatientIdentifier)
MedicationOrder Prescription Identifier
(RX or Renewal Identifier)
.2 [Vendor].[ApplicationInstance].2 Conformance Rule: A branch, ".2" is appended to create a unique namespace for MedicationOrder.identifier(EMR-id)
MedicationOrder Prior Prescription .2 [Vendor].[ApplicationInstance].2 Conformance Rule: A branch, ".2" is appended to create a unique namespace for the MedicationOrder.priorPrescription
Group Identifier .3 [Vendor].[ApplicationInstance].3 Conformance Rule: A branch, ".3" is appended to create a unique namespace for Task.extension(groupIdentifier)
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

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, or discontinue 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/PMS systems will be allowed to connect and exchange messages with PrescribeIT®. As mentioned before each connecting system instance will be issued a PKI x509 digital certificate for system identification and will have a System account created in PrescribeIT® SDF.

A registered EMR/PMS system instance would have the following attributes:

  1. PKI Cert DN
  2. Developer Key
  3. Application Instance ID
  4. SDF System ID
  5. Application Profile

PKI Cert DN

This is the Distinguishing Name (DN) assigned to the EMR/PMS system instance in its PKI Cert.

Developer Key

This is a character string issued to each EMR/PMS system instance and is required to be able to successfully invoke the PrescribeIT® APIs (along with its corresponding valid client certificate).

The value of the developer key needs to be submitted as part of every API call to the PrescribeIT® Central Switch. Structurally, the developer key is a base64-encoded version of a string which consists of SDF Application ID and password separated by colon.

The developer Key is considered to be the main authorization instrument for the EMR/PMS system instance: if it is lost, it cannot be programmatically recovered and needs to be manually reset by PrescribeIT® registration team.

Each EMR/PMS system instance receives their initial developer key through the CRM registration process and uses it to provision the first client certificate (the developer key changes to a new value during this process).

The developer key also changes if the EMR/PMS system instance needs to replace an expired client certificate.

Application Instance ID

This is a unique digital identifier representing a specific instance of an EMR/PMS application. The application instance id is a concatenation of the EMR/PMS registered HL7 vendor OID and the SDF System ID assigned by PrescribeIT®. In some configuration models the organization specific CPRID is also included as part of the application instance id value.

SDF System ID

A unique digital identifier representing a specific certificate instance of an EMR/PMS application to the PrescribeIT® SDF layer (API Gateway). This is a PrescribeIT® assigned ID.

Application Profile

The application profile consists of multiple attributes including the application name, conformance version and capability profile which controls which EMR/PMS applications and versions can connect to PrescribeIT® and what transactions those specific applications and versions are allowed to send and receive.

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 that electronic prescriptions are targeted to a particular point-of-service recipient. With deferred prescription bundles, no specific pharmacy is identified in the MessageHeader, so these messages will not appear in the "inbox" of any pharmacy. Instead, a different workflow is employed. Refer to the PrescribeIT® Version 5.0 Jurisdictional Rules and Task Grouping Excel spreadsheet rules for a full list of scenarios.

For Deferred Prescription Bundles, the following flow is applicable.

  1. When the prescriber uses the print or fax option, the EMR submits the unassigned deferred bundle to the PrescribeIT® Switch using the 401 Interaction message event, POSTing it in the same manner as they would any other message. The deferred bundle contains a copy of the authoritative medication order(s) that were included on the printed paper or faxed prescription. The deferred copy is considered non-authoritative.
  2. The PrescribeIT® Switch assigns a human-readable alpha-numeric "message-key" (PrescribeIT® Rx ID) to the message and adds it to the deferred bundle and adds this 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. See Deferred example section for an example and more details.
  4. The EMR extracts the "message-key" (PrescribeIT® Rx ID) and includes it prominently on the printed authoritative copy of the prescription which is given to the patient, or the authoritative faxed copy which is faxed to the pharmacy.
  5. The patient chooses the pharmacy where they want to have their prescription filled and gives the authoritative paper prescription to the pharmacy or the pharmacy receives the faxed prescription from the prescriber.
  6. The pharmacy user initiates the action to retrieve the deferred bundle and types the "message-key" (PrescribeIT® Rx ID) into their PMS along with either the patient's "last-name" or "birth-date" which then submits a query to the PrescribeIT® Switch to retrieve the deferred prescription bundle.
  7. The PMS sends a request to DELETE the deferred bundle from the PrescribeIT® system in the same manner it would have if it were retrieving messages from the inbox. For more information on this DELETE request, refer to the Interaction Bundle - Batch Clear Message Queue Request section.
  8. The PMS loads the information for all the Medication Orders contained within the deferred bundle within the pharmacy application for the user to action (NOTE: all orders retrieved from a deferred bundle are considered non-authoritative and require the pharmacy to obtain the authoritative prescription).
Deferred Sequence diagram

As part of step 3 above where PrescribeIT returns the updated tagged response, the tag structure is returned as "Codings" with a combination of 'system' and 'code'. The three pieces of information will be expressed in the message as follows:

Tag type 'system' 'code' notes
key http://prescribeit.ca/fhir/CodeSystem/message-key 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
last name http://prescribeit.ca/fhir/CodeSystem/last-name Patient's "last-name" This will be the patient's last name as specified in the deferred message from the EMR
birth date http://prescribeit.ca/fhir/CodeSystem/birth-date Patient's "birth-date" Expressed as YYYY-MM-DD. This is the "birth-date" as specified in the deferred message from the EMR

The following shows how Example A1 would be adjusted when echoed back in the POST's HTTP 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="PrescribeIT5.0"/>
    </tag>
    <tag>
      <system value="http://prescribeit.ca/fhir/CodeSystem/message-key"/>
      <code value="A888GAGP"/>
    </tag>
    <tag>
	  <system value="http://prescribeit.ca/fhir/CodeSystem/last-name"/>
	  <code value="Lerr Jr"/>
	</tag>    
    <tag>
      <system value="http://prescribeit.ca/fhir/CodeSystem/birth-date"/>
      <code value="2012-06-07"/>
    </tag>    
  </meta>
  ...
</Bundle>
  

Note: The tags are not sent in any particular order.

Sending an electronic Cancel request for a deferred prescription bundle that was successfully sent to PrescribeIT® is not supported and is expected to be handled manually by the prescriber locally cancelling the prescription and contacting the patient who received the authoritative copy of the prescription or the pharmacy that received the authoritative faxed copy and providing the proper instructions for them to cancel the prescription.

With deferred Discontinue Orders, no specific pharmacy is identified in the MessageHeader, so these messages will not appear in the "inbox" of any pharmacy. Instead, a different workflow is employed.

The standard messaging workflow presumes that messages are targeted to a particular point-of-service recipient. In jurisdictions where electronic prescriptions or renewal responses cannot be sent directly to the specified pharmacy, a hold and retrieve flow will be used instead (Note: refer to the Functional Specification documents to understand which jurisdictions this is applicable). With Held bundles, a specific pharmacy is identified in the MessageHeader, but these messages will not appear in the "inbox" of that specified pharmacy. Instead, the PrescribeIT® Switch will hold the bundle in PrescribeIT®, and generate and place a Interaction Bundle 903 - Bundle Available for Retrieval Notification in the inbox of the specified pharmacy. This notification informs the pharmacy user that a bundle is available for retrieval, at which point the pharmacy user can then initiate the retrieval at their discretion. Refer to PrescribeIT® Version 5.0 Jurisdictional Rules and Task Grouping Excel spreadsheet rules for a full list of scenarios.

For Held Bundles, the following flow is applicable.

  1. The patient chooses the pharmacy where they want to have their prescription filled or for renewal responses the response will go back to the pharmacy that sent the original electronic renewal request.
  2. When the prescriber uses the e-sign and send option, the EMR submits the assigned bundle to the PrescribeIT® Switch using the 401 Interaction message event, POSTing it in the same manner as they would any other message. The MessageHeader.destination references the pharmacy that is intended to retrieve the held bundle.
  3. The held bundle contains authoritative electronic medication orders. The PrescribeIT® Switch assigns a human-readable alpha-numeric "message-key" (PrescribeIT® Rx ID) to the held bundle and adds it to the message as a tag It also adds tags for the patient's last name and date-of-birth.
  4. The PrescribeIT® Switch returns a copy of the updated (tagged) message to the EMR as part of the standard HTTP 201 Created response in the same manner it does for deferred prescription bundles. See example below for more details.
  5. The PrescribeIT® Switch triggers a 903 Bundle Available for Retrieval Notification that contains the "message-key" (PrescribeIT® Rx ID) tag and places it in the inbox of the destination pharmacy
  6. The PMS retrieves the 903 Bundle Available for Retrieval Notification through the standard inbox polling process and sends an acknowledgement to DELETE the 903 notifications from their inbox .
  7. The PMS then displays the PrescribeIT® Retrieval notification in the PMS application for the user to action.
  8. The pharmacy user initiates an action to retrieve the held bundle from the PrescribeIT® Retrieval Notification.
  9. Using the “"message-key"” and “last name or "birth-date"” as received in the 903 notification, the PMS sends a query to the PrescribeIT® Switch to retrieve the held bundle.
  10. The PMS sends a request to DELETE the held Bundle from the PrescribeIT® system in the same manner it would have if it were retrieving messages from the inbox For more information on this delete request, refer to the Interaction Bundle - Batch Clear Message Queue Request section.
  11. The PMS loads the information for all the Medication Orders contained within the held bundle along with any other information within the pharmacy application for the user to action (Note: all orders retrieved from a held bundle are considered authoritative and do not require any other additional documentation).
Held Sequence diagram

Sending an electronic Cancel request for a held bundle that was successfully sent to PrescribeIT® is not supported and is expected to be handled manually by the prescriber completing the cancellation locally and contacting the specified destination pharmacy to provide instructions to them to cancel the orders retrieved from the held bundle.

In jurisdictions where electronic prescriptions or renewal responses cannot be sent directly to the specified pharmacy, a hold and retrieve flow will be used instead (Note: refer to the Functional Specification documents to understand which jurisdictions this is applicable). With Held bundles, a specific pharmacy is identified in the MessageHeader, but these messages will not appear in the "inbox" of that specified pharmacy. Instead, the PrescribeIT® Switch will hold the bundle in PrescribeIT®, and generate and place a Interaction Bundle 903 - Bundle Available for Retrieval Notification in the inbox of the specified pharmacy. This notification informs the pharmacy user that a bundle is available for retrieval, at which point the pharmacy user can then initiate the retrieval at their discretion.

PrescribeIT® has many internal configuration parameters that vendors do not necessarily need to know in order to conform. However, there are few configuration parameters that are the same for both Production and Pre-Conformance environments worth noting in the following table. Note: Pre-Conformance values may be subject to change.

Configuration Name

Configuration Description

UAT

Pre-Conformance

Production

OTP validity TTL

Number of minutes One Time Password (OTP) is valid.

5 minutes

5 minutes

5 minutes

SAML validity TTL

Number of minutes between SAML generation time and SAML expiry.

720 minutes

720 minutes

720 minutes

Aged Message Processing Response Wait Time

If the FHIR Message was retrieved 5 times from the Inbox but has not been acknowledged, THX will trigger the following workflow: wait for the [specified number of minutes] for acknowledgment and will fail the message if the acknowledgment did not occur.

5 minutes

5 minutes

5 minutes

Aged MessageProcessing Unrouted Message Age

When a 305 (PrescribeIT®) message comes with an attachment info in the FHIR then the message will not be routed to the recipient Inbox until all the attachments are uploaded. So in case if the attachments are not uploaded then it will be in the transient (waiting) state for [value configured by this parameter] minutes and after that aged message processor will pick this message and fail it.

30 minutes

30 minutes

30 minutes

eFax Message Delivery Processing Retry Count

Number of times the Fax delivery subsystem will attempt to try transmitting the fax if the delivery is unsuccessful.

6

6

6

Inbox MessageProcessing Batch Count For Message Polling

Maximum number of FHIR messages returned in one Inbox polling call.

20

20

20