PrescribeIT™ Specification and Guide Version 2.0 Revision F

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

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 business requirements, please refer to the Business Requirement documents that were included in your package). These interactions are in addition to the Shared Health interactions found in the Shared Health implementation guide.

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

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

Please refer to Shared Health implementation guide 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

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

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 Execute Deferred 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 25 Tasks to be included in a single bundle. The guide defines a number of tasks that can be conveyed within a message. Messages support conveying multiple tasks to ensure that content can be delivered in a single group of related information.

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

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

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

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

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 (non-directed)

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

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

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

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 General Conformance and Usage Rules

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

0.15 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.15.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.15.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.15.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.15.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.15.1.1.3 Administrators

Out-of-scope

0.15.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.15.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.15.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.15.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.15.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.15.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.15.2.4 PMS Systems Authentication

PMS systems support 1 mode of communications with PrescribeIT™:

1. Pull Mode

0.15.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.15.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.15.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 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.15.3.2 EMR Systems Access Control

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

A registered EMR system instance would have the following attributes:

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

PKI Cert DN

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

Vendor Application Instance ID

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

SDF System ID

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

Application Profile

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

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

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

0.15.3.3 PMS Systems Access Control

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

A registered EMR system instance would have the following attributes:

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

PKI Cert DN

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

Application Instance ID

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

SDF System ID

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

Application Profile

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

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

List of Pharmacies

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

0.15.3.4 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.15.3.5 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.16 Deferred Prescriptions

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

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

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

0.16.1 example

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

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

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

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

0.16.2 Cancelling Deferred Prescriptions

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

0.17 Production Configuration Values

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

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