PrescribeIT® Specification and Guide Version 5.0

0.1 Introduction

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.

0.1 Audience

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.

0.2 Background

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.

0.2.1 Getting Started

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

0.2.2 Contact - Support

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.

0.3 Product Overview

0.3.1 PrescribeIT® Product Description

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.

0.3.2 PrescribeIT® Authentication and Authorization

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:

0.4 Business Scope

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

0.4.1 Jurisdictional Business Scope Rule Set

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.

0.5 Stakeholders

0.5.1 Roles and Responsibilities

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®

0.6 Understanding FHIR

Refer to Shared Health - Understanding FHIR

0.7 Understanding Formal Views of Profile Content

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

0.8 Understanding Slicing

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").

0.9 Understanding the Message Structure

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

0.9.2 Tasks

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.

0.9.2.1 Task Overview

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.

0.9.3 Resources, Identifiers, IDs, and References

0.9.3.1 Logical versus Business Identifiers

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.

0.10 Messaging sequence

0.10.1 Posting Messages - Directed

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.

0.10.2 Posting Messages - Deferred or Held Bundles

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

0.11 Exception and Error Handling

0.11.1 Error and Exception Handling Scenarios

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.

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

0.12 Profiling

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

0.13 Use of Message Identifiers

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

0.13.1 Business 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.

0.13.2 Technical Identifiers

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

0.13.3 Value Sets (Vocabulary/Terminology)

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

0.14 Security Measures

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

0.14.1 Identity Management (IDM)

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

0.14.1.1 Digital Identity Binding

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.

0.14.1.1.1 Prescribers

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.

0.14.1.1.2 Pharmacists

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.

0.14.1.1.3 Administrators

Out-of-scope

0.14.1.1.4 EMR Systems

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

0.14.1.1.5 PMS Systems

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.

0.14.2 Authentication

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.

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

0.14.2.1 2^nd factor Authentication Service through STS

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 2^nd 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.

0.14.2.2 PrescribeIT® 2^nd factor of Authentication

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

0.14.2.3 One Time Password in SMS

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.

0.14.2.4 PMS Systems Authentication

PMS systems support 1 mode of communications with PrescribeIT®:

1. Pull Mode

0.14.2.5 Pull Mode Authentication

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.

0.14.3 Authorization

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.

0.14.3.1 Prescriber Access Control

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.

0.14.3.2 Systems Access Control

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.

0.14.3.3 Data in Transit

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.

0.14.3.4 e-Signature

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.

0.15 Deferred Prescription Bundles

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

0.15.1 example

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:

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.

0.15.2 Cancelling Deferred Prescription Bundles

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.

0.15.3 Deferred Discontinue Order

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.

​

0.16 Held Prescriptions

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

0.16.1 Cancelling Held Bundles

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.

0.16.2 Held Discontinue Order

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.

0.17 Environment Configuration Values

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