ePrescribing
Draft for comments
INSTRUCTIONS: please edit the text/add comments in tracked changes and return to
submissions@haad.ae by 15 April
1. CONTENTS
1.
CONTENTS.................................................................................................................................................. 2
2.
DOCUMENT HISTORY ............................................................................................................................. 3
3.
INTRODUCTION........................................................................................................................................ 3
4.
PURPOSE ..................................................................................................................................................... 4
5.
SCOPE .......................................................................................................................................................... 4
6.
PROCESS DIAGRAM ................................................................................................................................ 5
7.
PROCESS DESCRIPTION ....................................................................................................................... 6
7.1.
Step 1: Initial ePrescription Request ............................................................................................... 6
7.1.1.Download Patient History Drug dispensing ................................................................................... 6
7.1.2.ePrescription Prior.Request (Provider request) ........................................................................... 6
7.1.3.ePrescription Prior.Authorization (adjudication response) ...................................................... 8
7.2.
Step 2: ePrescription Download (Prescription Exchange Service “PES”) .......................... 9
7.3.
Step 3: Pharmacy Prior.Request (Conditional) ............................................................................ 9
7.3.1.Pharmacy Prior.Request (PBM Request) ........................................................................................ 9
7.3.2.Pharmacy Prior.Authorization (PBM Response) ........................................................................... 9
7.4.
Step 4: ePrescription Deactivation ................................................................................................. 10
7.4.1.Using on-spot Claim.Submission ..................................................................................................... 10
7.5.
General Considerations ....................................................................................................................... 11
7.5.1.Transaction Turnaround Governance ............................................................................................ 11
7.5.2.General Governance and Regulatory Considerations .............................................................. 11
7.5.3.Miscellaneous .......................................................................................................................................... 11
7.5.4.Communications protocol for unplanned Shafafiya downtime ............................................ 12
2. DOCUMENT HISTORY
Version
Date
Author
Explanation
1.0
22/09/2013
Daman, NAS
Initial Draft
1.5
17/02/2014
Daman, NAS
Revised after HAAD comments
2.0
25/03/2014
HAAD
Edited with proposals for alternative
options
2.1
[Date]
[please put the
name of your
organization here]
Comments on version 2.0
3. INTRODUCTION
Pharmacy Benefits Management (PBM) is an important aspect of a modern healthcare system, and a
key quality and cost containment mechanism for the most prevalent intervention modality in Abu
Dhabi, namely Drug Prescriptions.
The Health Authority of Abu Dhabi mandates the implementation of PBM services (Circular
Reference: PHP/PHM/PBM/V0.9) for the management and monitoring of pharmacy benefits under
the health insurance scheme in Abu Dhabi, to ensure quality outcomes and efficient prescribing
practices.
We believe that a key component towards greatly improving the effectiveness of PBM lies with the
implementation of the Electronic prescription (ePrescription), a measure that will deliver the
following advantages:

Close an important gap: With both PBM and EClaims, we are currently receiving electronic
information on what is being dispensed / claimed, but not on what was actually prescribed.

Reduce inconvenience to patients: Information about clinical conditions (e.g. drug to drug
interaction, duplicate therapy) and/or coverage conditions (e.g. formularies) should be conveyed
directly to the treating physician rather than to the dispensing facility who has no other choice
but to refer the patient to his treating physician (i.e. another appointment and delay in receiving
required treatment).

Prepare for future initiatives: There is no technical reason for limiting ePrescriptions to
medications. For example, the concept could be easily expanded to prescribe outpatient
diagnostic tests, thus eliminating a considerable number of unnecessary and costly duplications.

Maintain Abu Dhabi’s leading position as a technical innovator in the eHealth space:
ePrescription is the only remaining missing link in Shafafiya. In line with its track record on
introducing ground breaking initiatives, HAAD should continue in setting the standards that
others can use and follow.
4. PURPOSE
The purpose of this document is to propose some of the required changes to the current
ePrescription standards, and highlight topics that require further discussions with all relevant
stakeholders in order to ensure successful implementation. This is in order to address the market’s
operational and technical concerns with reliable process and solutions.
5. SCOPE
The scope of this document is to propose governing processes and standards for electronic
prescription in its different phases. This will be addressed along with proposed business rules which
need to be implemented to enable the execution of the process.
The document refers and responds to the current published standards for ePrescription by HAAD, as
well as brain-storming sessions with various healthcare and health insurance stakeholders and
experts in the market.
6. PROCESS DIAGRAM
New Webservice: DrugHistoryDownload
Notes:

Step; ePrescription transaction initiated exclusively by the treating doctor via
Prior.Request transaction. Payer/TPA will return medical adjudication results using
Prior.Authorization (refer to 7.1.).

Step; downloading the ePrescription by the retail pharmacy along with the Payer/TPA
response. This transaction is necessary prior to the dispensing (refer to 7.2.).

Step; conditional Prior.Request submitted by the pharmacist for the brands he wants to
dispense. Required under specific conditions only (refer to 7.3.1.).

Step; disabling/removing the dispensed drugs from the prescription server by one of the
following ways;
o Using on-spot Claim.Submission (refer to 7.4.2.).
o “SetDrugDispensed” webservice to accommodate the providers with monthly claims
submission (refer to 7.4.1.)

Optional Step DrugHistoryDownload: Doctors and Pharmacist can consult the patient’s
drug dispensing history to help them in decision making.
7. PROCESS DESCRIPTION
7.1.
Step 1: Initial ePrescription Request
7.1.1.
Download Patient History Drug dispensing
This is a place holder for an additional service that PBM could provide with great value to the
provider reading the data from previous claims and pending ePrescriptions.
The Doctor who will be doing ePrescriptions is given the opportunity to download the drug
history for the patient that is in his office. This will allow the doctor to see what the patient
has been taking and prescribe accordingly.
Things to be defined: what information is shown, such as:
 PrescriptionDate
 Facility
 Drug (commercial drug given),
 Frequency,
 duration,
 quantity
 Probably: Diagnosis for the encounter, prescribing doctor
Possibly not all history will be shown but the last year only, unless the doctor requests older
data
Patient confidentiality issues have to be addressed: should some drugs be hidden? Patient
authorization to view drug history, etc.
This service will require further discussion as it’s a first step in sharing Patient health records
between facilities using KEH data
7.1.2.


ePrescription Prior.Request (Provider request)
Sender: Treating/prescribing doctor
Condition:
-

Outpatient encounter in which the treatment plan requires drugs prescription. Therefore,
by default it excludes any daycare or inpatient encounter types
Description:
-
Authorization.Type must be “Prescription”
-
Activity.Type is restricted to “Generic” (ideally) OR “Drug” (exceptionally)
-
“Authorization.ID” must be globally unique, with a format convention (FacilityIDreference number, e.g. MF123-ABC123456).
-
All Drugs will be associated with the following descriptive Observations
Observation
Type
Patient
Weight
LOINC
Route
Text
Code
3141-9
Value
Float
Value
Type
Kg
Mandatory
Yes
(Generic and
Brand)
Route
See
codes;
Proposed
codes:
Route_Of_Admin_Re
lease_20130702_Public_v2.xlsx
Current
codes:
Yes
(Generic
only)
Microsoft Excel
97-2003 Worksheet
Duration
Text
Duration
Integer
Days
Yes
(Generic and
Brand)
Units Per
Administration
Text
Frequency
Text
UnitsPerAdministration
Float
Yes
(Generic and
Brand)
Frequency
Integer
Possible
Values:
- Hour
- Day
- Week
Once
Alternative
proposal:
continue
using
current list
Yes
(Generic and
Brand)
Microsoft Excel
97-2003 Worksheet
Refill
Why Brand
Text
Text
Refill
WhyBrand
(for activity type
5 only)
Instruction
Text
Instruction
Integer
See codes
below
Yes
Yes
Text
No
(Brand only)
(Generic and
Brand)
-
The current “Dose” and “Dosage Form” observations should be waived, as both are
indicated in the generic code itself
-
“Duration” observation implies the treatment duration of each refill. Payer/TPA may limit
the Duration value in each refill in agreement with the provider to accommodate the
different Refill policies in the market.
-
“UnitsPerAdministration” observation implies the number of granular units to be
administered in each dose of the prescribed frequency.
-
“Frequency” observation implies the number of repetitions of
"UnitsPerAdministration" in a specific time unit (hour, day, week, etc.)
-
“Refill” observation implies the number of times the prescription can be re-dispensed on
top of the initial dispense. For acute prescription (one time prescriptions) the Refill value
will be zero.
-
“WhyBrand” Observation.Value is restricted to one of below values
o WB-001; Over-The-Counter Drug
o WB-002; Dietary Supplement
o WB-003; Herbal/Homeopathic Remedy
o WB-004; Vaccine or Insulin Preparation
o WB-005; Allergic/Adverse Reaction History
o WB-006; Unsuccessful Therapeutic Control History
o WB-007; Narrow Therapeutic Range Drug
o WB-008; No Generic Code Available
-
Activity.Start indicates the date at which the member is expected to start consuming the
drug
the
prescribed
-
Splitting of prescriptions into multiple PriorRequests on grounds not clinically indicated will
be treated as Abuse. However, it’s Payer/TPA’s responsibility to monitor and control such
practice.
7.1.3.
ePrescription Prior.Authorization (adjudication response)

Sender: Payer/TPA

Condition: New ePrescription Prior.Request is available in Shafafiya and ready for download.

Description:
- Payer/TPA will perform the following;
o
(Member, Provider and Network) Eligibility Check
o
Any additional checks that improve patient safety, quality of service and providers’
revenue cycle. As a minimum:

Medical Utilization Review checks; (Drug-Age, Drug-Gender, Drug-Diagnosis,
Drug-Drug, etc.)

Coverage related
Exclusions, etc.)

Supply Management Check (i.e. Refill-Too-Soon)
checks
(Formulary
and
sublimit
restrictions,
General
-
Payer/TPA will not perform any payment related calculations at this level, except for the
consultation claim.
-
“Authorization.Limit”; is the total amount available for the prescription at the time of
approval (Prior.Authorization). The communication of the Authorization.Limit is advisory in
nature and no provisions or limits will be guaranteed for any period of time.
-
In general, Activity. (List, PatientShare and PaymentAmount) will be null (Empty) or Zero
[blank?] in the Payer/TPA response on ePrescription. In case an activity is not covered, an
appropriate denial code will be given explaining the reason for rejection.
-
Payer/TPA may reflect the medical checks results as non-binding comments, unless these
results indicate a life-threatening effect or if deemed medically unjustified (in line with the
general exclusions of policies) which will result in a denial. However, there will always be a
last resort in the form of self-payment.
-
“Activity.DenialCode” must be returned for each denied activity.
-
Payer/TPA will return the following observations on each activity in the prescription.
Observation
Type
Code
Dispense
Date
Text
DispenseDate
Payer
Comments
Text
PayerComments
Value
Date
DDMMYYYY
HH:MM
Text
Value
Type
Mandatory
Approved Rejected
Activity
Activity
Yes
No
No
No
-
Payer/TPA may return an advisory formulary based on the member’s schedule of benefits
(i.e. proposed brands for each approved generic)
-
Proposed brands will be linked to the respective generic using the Activity.ID (e.g. if the
approved generic has Activity.ID = 2, proposed brands will get Activity.ID 2-1, 2-2, etc.)
-
Physician/Provider can provide the patient a printed version of the prescription with the
Payer/TPA response for patient education purposes to ensure awareness of the possible
brand drugs for the prescribed generic and the difference in the coverage liabilities. This
concept delivers a biased-free decision in selecting the brand, unless a specific brand is
medically indicated and this is covered by “WhyBrand” observation.
7.2.
Step 2: ePrescription Download (Prescription Exchange Service “PES”)

Sender: Pharmacist

Condition: ePrescription is available for the member in the post office with at least one
activity NOT tagged as dispensed.

Description:
- Pharmacist will use “GetPrescriptions” webservice
- The current logic of the transaction will remain the same without change
7.3.
Step 3: Pharmacy Prior.Request (Conditional)
7.3.1.
Pharmacy Prior.Request (PBM Request)

Sender: Pharmacist

Condition:
- If an applicable financial limit is provided in the “Authorization.Limit” field in the
received ePrescription Prior.Authorization (7.1.2.).
- In case of a paper prescription (only for transition phase)
- Receiving a paper prescription from a provider outside Abu Dhabi
- In case of partial dispensing of a prescription
- In case Payer/TPA response on the ePrescription included advisory formulary
- Refill Dispensing
- In case the payer requests PBM for a product for other reasons such as controlling R2S

Description:
- Authorization.Type must be ”Authorization”
- All Drugs must be requested in brands (Activity.Type = 5)
- OPTION1: Add a new element called “Authorization.PrescriptionID” which must have a
value equal to the “Authorization.ID” of (valid and not fully claimed/dispensed)
ePrescription.
- OPTION2: does not require a new element “PrescriptionID” but uses Observations to add
the PrescriptionID in it. Each activity will include an observation with the following values
-
-
7.3.2.

Observation
Type
Code
PrescriptionID
Text
PrescriptionID
Value
Value
Type
Text
Mandatory
ePrescriptions Non
ePrescription
Yes
No
This option will allow the pharmacy to send a PriorAuthorization for drugs that come from
more than just one ePrescription eventually
If ePrescription didn’t exist, then below must be considered;
o For OPTION1: Authorization.PrescriptionID will carry a default value “000”; for
paper prescriptions. Each Activity must be associated with descriptive
Observations for (Patient Weight, Route, Duration, Units Per Administration
and Frequency), and optionally with (Instruction) as explained in 7.1.1.
o For OPTION2: should not add the PrescriptionID observation
Activity.ID of the requested brand must be identical to the ID of the equivalent
(generic/brand) in the ePrescription if existed
Activity.Start” indicates the date at which the member is expected to start consuming
the drug
Splitting of one prescription into multiple PBM PriorRequests for each drug will be treated
as Abuse, unless the pharmacy is intending to partially dispense the prescription based on
the supply availability or other practical issue related to cancellations.
Pharmacy Prior.Authorization (PBM Response)
Sender: Payer/TPA

Condition: New Pharmacy Prior.Request is available in KEH and ready for download (7.3.1.).

Description:
- Payer will call the “CheckForNewPriorAuthorizationTransaction” webservice and download
the Prior.Request submitted in (7.3.1.)
-
Payer/TPA will perform a cross matching between the PBM Request and its equivalent
ePrescription. This step is necessary to ensure that the medications is being dispensed as
prescribed which grants the maximum safety for the member
-
If ePrescription didn’t exist, then Payer/TPA will perform complete Medical Utilization
Review checks; (Drug-Age, Drug-Gender, Drug-Diagnosis, Drug-Drug, etc.)
-
Payment related Checks will be performed by the Payer as below:
-
(Member, Provider and Network) Eligibility Check.
o
Payment calculations and other benefit related checks.
o
Activity.Start in the Pharmacy Prior.Request
ePrescription in the Refill-Too-Soon check.
o
Any additional checks that improve Provider’s revenue cycle
overrules
the
Activity.Start
in
Payer will respond to each activity in corresponding PriorRequest including:
-
7.4.
o
o
full payment information
PaymentAmount)
for
each
approved
activity (List, PatientShare and
o
“Activity.DenialCode” for each denied or adjusted activity
Payer will use “UploadTransaction” webservice to return the Prior.Authorization for
dispensing.
Step 4: ePrescription Deactivation

Sender: Pharmacist

Condition: Pharmacist reached the point of dispensing for at least one approved drug

Description:
-
The ePrescription will be available on the server as long as there is a drug in the
prescription that has not been dispensed
-
Proofing the dispense can be achieved by one of two ways which accommodate the
different billing patterns in the market;
7.4.1.
Using on-spot Claim.Submission








Post office will validate if the Activity has been dispensed previously, if yes then
validation error is generated. If not, Claim.Submission will pass
Dispensing Validation Logic: Claim.Submission.Activity.Start value is less or
equal to (activity’s last dispensed date + Activity.Observation.Duration.Value).
Each activity passing the Dispensing Validation will be marked “Dispensed” by
the post office.
Activity.Type must be “Drug” (Type 5)
Activity.Start indicates the date at which dispensing occurred
“PrescriptionID” must exist and indicates the equivalent “Authorization.ID” of
the (ePrescription/Pharmacy) Prior.Request
Turnaround Time of Payer/TPA Remittance.Advice must follow the current terms
and conditions defined in the SPC.
Same business rules apply as in the current Claim.Submission
7.5.
General Considerations
7.5.1.
Transaction Turnaround Governance
Below rules govern the turnaround time for the Payer/TPA response on both ePrescription and PBM
transactions. Post Office maintains the necessary time stamps to provide the audit trail.
 During a transition phase, the time limit is 10 minutes and will be periodically reviewed and
adjusted downwards by a technical working group that reports to the Data Standards Panel
 If the Prior.Request has a non-empty Instruction observation, the time limit is 15 minutes
 If Manual adjudication is required by the Payer/TPA for the submitted Prior.Request, then
Payer/TPA must notify the provider with one of the following adjustment codes
o AUTM-001: Expect PriorAuthorisation within 15 minutes
o AUTM-002: Expect PriorAuthorisation within 30 minutes
o AUTM-003: Expect PriorAuthorisation within 1 hour
 Payer/TPA must not use above adjustment codes in more than 10% of the transactions and
it can not be used more than once in the same transaction. Payers’ compliance will be
enforced through validation rules.
 If Payer/TPA exceeded the turnaround time stated by DSP, or the delay time communicated
in above adjustment codes, then Pharmacy will automatically have the right to dispense the
requested drugs, unless the member’s “Schedule Of Benefits” states otherwise (e.g.
Prescription Drugs above AED 500 with pre-authorization only, etc.)
o Alternative HAAD proposal: once the AUTM codes are used and the time has run out
the prescription is approved without any additional requirement
 Performance expectation: 90% of the responses to complaints are dealt with under 30
minutes
o Alternative proposal: The time limit for response to complaints is 15 minutes
7.5.2.




We propose introducing an extra security layer in the ePrescription Prior.Request
transactions to authenticate the prescribing physician. This layer should be deployed on top
of (or in combination with) the current provider specific layer. Rational; control, monitor
and reduce the potential misuse of the electronic medium by issuing prescriptions through
unauthorized personnel in the provider facility. This security layer can replace the current
physical signature and stamp of the doctor.
The current prescription template should be modified, as the current template
accommodates the generic prescribed medications only. While ePrescription requires
combining the Payer/TPA response (including the proposed brands, Refills information,
Eligibility results, Dispense dates, medical review results, etc.).
Correcting, Cancelling or modifying the prescription is an explicit right of the prescribing
doctor. Shafafiya will ensure not passing any resubmission or cancellation on a prescription
unless submitted by the same prescribing doctor.
Provider systems will need to ensure a full audit trail for all data elements from the time the
prescription is created by the doctor and pharmacy until it’s uploaded into shafafiya.
Prescribing clinician has to be identified in the audit trace unequivocally.
7.5.3.


General Governance and Regulatory Considerations
Miscellaneous
Payers and providers are expected to agree a protocol to follow, should the Post Office not
be available. HAAD will provide a service which enables independent verification of Post
Office Status
The following transactions will follow the current standards with no special logic for
ePrescriptions:
o Resubmission Correction Prior.Request Transaction
o Resubmission Internal Complaint Prior.Request Transaction
o Eligibility Prior.Request Transaction
o Cancellation Prior.Request Transaction
o Status Inquiry Prior.Request Transaction
7.5.4.
Communications protocol for unplanned Shafafiya downtime and
support SLA
This requires to create a coordination group with the main players.
Support team head, HAAD representatives (IT and Strategy departments), SEHA representative, Daman
representative, others as per future agreements
When there is an incident this is how it will work.
1. Detection of incident can happen by:
a. Alerts in Shafafiya are raised through automated monitoring systems
b. User reports incident by email to shafafiya support email
c. User from HAAD calls Support team
2. Support team logs request and assigns severity based on the agreed severity table (see SLA table below)
3. Support team investigates within 15-30 minutes:
a. Review of alerts
b. Review of similar issues from other providers
c. Call back user to find out more details if needed
d. Analyze if problem is related to Shafafiya or other systems outside the scope of Shafafiya
e. Support team inform the user estimated resolution time if possible
4. If issues is classified as "Critical" or "Major" within the first assessment, Support team communicates by
phone within 30 minutes to Core team and through Webpage announcement section to the whole market
5. If issue is classified as "Ordinary" Support team communicates by email within 8 hours with:
a. HAAD core team
b. Affected users only (including Daman/SEHA only if affected)
6. If action is required by response team, a phone conference is established coordinated by Support team
7. During the duration of the event, Support team will update the Core team on the progress
8. Members of Daman and SEHA will review their systems and functions and inform back the Status to the
Core team. This might be required more than one time depending on the duration of the incident.
9. If the issue is related to port and network access within Injazat HAAD IT will intervene within 15 minutes of
communication
10. If the issue is Critical and it's not solved within 60 minutes a conference call must be done between Main
contact team and is escalated to next level: heads of HAAD IT, HAAD Strategy, Daman IT, SEHA IT
11. HAAD will communicate with market about the situation through the Shafafiya website if available or
through email alternatively for critical issues not solved within the first 45 minutes or earlier if the
resolution is expected to take longer than 1 hour.
12. Alternative procedures within the Market players may be initiated according to standard protocols for each
user.
13. Resolution of an incident:
a. If a Known error with no resolution: use workaround planned
b. If a new error with not known resolution: agree on possible action plan with Core team and proceed
to fix. This requires permanent communication within technical teams
c. If it might require an emergency changes. This need to be confirmed with HAAD Strategy team and
communicated to Core team. HAAD Strategy will determine if needs to communicate to market the
change
14. Once the issues are resolved, this must be confirmed by all member Main contact group before it is
considered Closed. An incident report will be generated
15. Change management planning: The result of the resolution of the incident will feed to the Change
management and Capacity planning process
16. Root Cause Analysis: After a Critical incident has happened HAAD core team and Support team will produce
a root cause analysis of the incident and incorporate this to the next planning cycle
17. Affected Healthcare Entities share reports on business impact of the incident with HAAD
Support team SLA targets:
Priority
Impact
Examples
1 – Critical
Service outage or a major
application problem making
it impossible to use the
service.
Service is not available;
application does not save critical
data correctly.
2 – Major
Majority of users are
impacted and no
workaround exists.
3 – Ordinary
4 – Low
Reports from
Shafafiya users
sent to the
designated
email address
Reporting
Reaction Time
Resolution Time
Phone
30 minutes
2 hours
Slow application response time,
session timeouts, some
application functionality is
broken.
Phone
2 hours
8 hours
Impact on a small number of
users or impact on a large
number of users, but a
workaround exists.
Some minor application
functionality is broken, but the
software is still usable.
Email
8 hours
2 working days
No impact on users
A request for a new feature.
Email
24 hours
4 working days
Email
24 hours
5 working days
8. FURTHER DEVELOPMENT
The following issues require further discussion and definition:






Detailing the mechanism of refills for chronic medications - assessing what is required at HAAD's end and
how that would be implemented
Analyzing the implications that may arise from a medico-legal point of view (i.e. no signed paper prescription)
Setting the rules on who has the right to, and how a chronic prescription can, be changed
Identifying required steps to introducing Formularies (e.g. generic codes)
Making medical reports available electronically
Expanding ePrescriptions to include diagnostic tests and other outpatient treatments