Implementation of WASFATY Prescription System for HPCs and Provider Integration Solution

·        Supplier price and alternative price and SFDA price.

·        All fields exist in MDR just need to rename the fields Name.

MDR:

1-     need the following fields about price and cost.

2-     Need to add a flag “Is Contracted”

Is contracted” field will be used to select the price to be used for the transaction as the following:

o   If True, will use supplier price and Supplier price will be mandatory field

o   If False, will use the SFDA price. And SFDA price will be mandatory filed

3-     Add a label as a net price under the generic code in MDR.

·        The Net Price will be mapped based on the flag of contracted or not contracted.

(Example)

All fields to be added to drug list on MDR report.

LMU: to sync all fields from drug to drug list from MDR

OI: Fields update on RQ-002 data mart sheet- drug information

MDR: to have a flag at generic to determine the assigned trades to be displayed at Physician side

LMU: To add a column at Generic for display the Trade

To add a column for display trade at trade list

PP: if Display Trade is checked the Physician will be able to see the Trade drugs assigned to the generic.

·        If the Option for showing Brands is enabled for the physician: he will be able to see the active brands name next to the generic name, (physician can’t edit or select, brand drug only for view, content to be Grey colour not bold)

·        In case the generic connected to different Brands drug the system should show all the brands.

(Example)

·        At PP when the physician selects the Generic name, system will display the assigned Trades to the generic with no action on it (if the drug is checked to be displayed.

OI: At LMU lists Generic information

(RQ-002- Data mart sheet)

·        The system must show only the active branded drugs.

·        The system must consider the division of the drug.

·        The system must consider the speciality level.

list of required fields (refer to prescription page contents).

·        Patient Profile (patient id, patient name, contact number, gender, weight, patient file no, DOB

·        Facility name, facility id, city

·        Physician: Physician name, physician id, physician contact #

·        Pharmacy: pharmacy name, pharmacy id

·        Pharmacist: pharmacist name, pharmacist id

·        Prescription Data:  eRx #, Start date, generic name, trade name, ROA, Instruction, Dispense quantity

(Example)

·        From a predefined list, drag and drop fields on the label layout, change field location, remove fields from layout

For example: admin user, can predefined list to drag it in the required places as below:

·        after assigning the fields, Admin can view a test label for check and confirmation

·        Label Size1 and label size 2

·        If the Pharmacist use his POS this will not be applicable

·        All prices should be able to be displayed OI, TMB and API service

(Example)

·        Cost

·        VAT

·        Net Price

Integration:
for the POS Dispensing system, need to take into consideration to sync with drug price (Net and VAT).

Need to consider expanding the businesses in the future as below

·        Starting with private sector.

·        Starting with insurance company.

·        Integrating with payment engine.

Where the pricing will be configure based on net price with margin depend on the provider or insurance company network and co-payment policy

(Example)

WASFATY Admin, should be able to add the pharmacy profit margin for all pharmacies

And to be calculated in the financial report

·        Total price with the profit in the required Report as below, where he can build the question and add the column needed

·        Total Price= net price + (profit %* net price)

The uploaded file must reflect on all WASFATY components.

·        Will be used for new or updating drugs.

(Example)

·        Will provide templates for adding new drugs.

·        NUPCO admin should Fill in the template all mandatory fields as its ID

Example:

Package type: Blister Pack, will fill the ID =87

·        Terminology will part of the ,

·        Added trade should be linked to an existing Generic code.

·        Multiple Divisions, ingredient and strength should be separated by |,

·        System will validate the data and

·        Once the drug released, it will be active on all other system.

LMU:

·        NUPCO, MOH, SFDA, NHIC codes will be added to drug list in LMU

OI:

·        NUPCO, MOH, SFDA, NHIC codes will be added to drug list in LMU

·        Adding validation in the NUPCO number (duplication).

(Example)

·        Once system define new generic, NUPCO code will have empty value.

o   system will warn the User to fill the values needed for new generic in   order to activated once trade codes saved.

o   Another validation level at release page, before release the drugs.

Rejection Message:

·        Added MOH code already registered with another generic name,

.

·        Added NUPCO code already registered with another generic name,

.

LMU:

·        NUPCO and MOH code will be added to generic list in LMU

OI:

·        NUPCO and MOH code will be added to generic list in LMU

·        Adding validation in the SFDA number (duplication)

Refer to RQ-031 for adding SFDA code

(Example)

At MDR:

User will be able to configure the at component page at drug level with below setup

Once adding new drug and assigning the SFDA code

The system must show user, the notification if he wants to continue saving the drug.

SFDA # Can be added even if duplicate

Upon adding new trade, the system must show user, the notification if he wants to continue saving the drug in case the code (SFDA code) is already register with another generic name.

Notification Message: Added SFDA code already registered with another generic name

Are you sure to continue?

If press yes: will save the drug

If press no: need to change the code

LMU:

·        NUPCO, MOH, SFDA, NHIC codes will be added to drug list in LMU

OI:

·        NUPCO, MOH, SFDA, NHIC codes will be added to drug list in LMU

·        Validation needs to be added (If there are any drug with the same code)

·        Validation should be applied on the different code terminology. E.g.: SFDA code, NUPCO code, MOH code

Refer to RQ-031 for adding SFDA code

(Example)

User will be able to configure the at component page at drug level with below setup

When saving a new drug, notification will appear if they are any existing drug has any similar codes (all codes)

Upon adding new, the system must show user, the notification if he wants to continue saving the drug in case the code (MOH code) or (one Additional code is already register with another generic name.

Notification Message: Added NUPCO code already registered with another generic name

Are you sure to continue?

If press yes: will save the drug

If press no: need to change the code

LMU:

·        NUPCO, MOH, SFDA, NHIC codes will be added to drug list in LMU

OI:

·        NUPCO, MOH, SFDA, NHIC codes will be added to drug list in LMU

·        System should sync with LMU, PP, CORE.

(Example)

·        System should sync with LMU, PP, CORE, TMB.

(Example)

·        System should sync with LMU, PP, CORE.

(Example)

·        System should sync with LMU, PP, CORE, TMB.

(Example)

·        PHC

·        Hospital

·        All

To (add, modify, delete) the generic drug prescribing based on facility type: PHC or Hospital or both, and this will be synced to LMU and will be synced to PP and TMB.

(Example)

Example: Once authority is All

At LMU authority configured per code in the LMU-generic

LMU-GENERIC (mock-up)

( list ) (mock-up)

·        PHC

·        Hospital

·        Pharmacy

To define (add, modify, delete) the trade drug prescribing based on facility type: PHC or Hospital or pharmacy

This to enable the drug to be dispensed per hospital or clinic pharmacies

(Example)

At LMU: a new column at LMU with authority code for the trade, with multiple Value

At PP:

Drug will be shown at dispensed provider if the authority code checked matched the provider type.

This to enable the drug to be dispensed per hospital or clinic pharmacies.

·        If the (clinic/hospital) using WASFATY system for dispense, drug will be active based on the above setup

·        If the (clinic/hospital) using their HIS for dispense (or POS), eRx dispense authorization to WASFATY is included non-authorized item, authorization will be rejected from dispense.

·        System should sync with LMU, PP, CORE, TMB.

(Example)

Ability to assign trade drugs to the chain pharmacy and their branches

·        System should sync with LMU, PP, CORE, TMB.

(Example)

.

(Example)

·        WASFATY Admin (user) can select activate or de-activate supplier,

·        If he de-activate the supplier all Active drugs supplied by him will be discontinued

·        When activate the supplier all Active drugs supplied by him will (as registered in the MDR) will be activate and user will be having the option for release all item or some of them.

·        Validation will be applied in case a generic only linked to one trade and the trade deactivated, system will alert the user to check the related generic

LMU:

·        Supplier list (Agent) to be added in LMU (ID, Description and status)

·        MDR to sync the list to LMU

OI: add a supplier list in LMU list at data mart (RQ-002)

(Example)

·        Activate and De-activate user

·        He should be able to search for a user with below fields

§  User ID (National id)

§  Medical License

§  User Type

§  Username

·        Add new user: once the user activated an SMS /email will be sent to the user for notification him for the activation of his account.

·        Edit user data and privilege: all validation for all filed to be applied.

(Example)

:

WASFATY Admin has the privilege to add/edit/remove user’s privileges accounts (for all accounts based on specific role) and this will reflect on PP, CORE, LMU, OI.

·        Can assign Main Role for predefined Roles based on user profession

·        Can select custom role and assign any privilege from the available roles in the list.

At MDR:

Admin user at Admin Page, can add user, and assign privilege to him

The admin users need to have rights to add modify and deactivate any facility admin user privileges.

(Example)

For any systems (CP, PP, OI, LMU, CORE)

·        Assign new privilege or role to user.

·        Remove privilege

retention time per Days range from (30 Days to 3650 days)

(Example)

The retention time will be implemented for all users (PP and CP user).

·        Retention time will be counted from last user login.

·        OI must contain report for all deactivated user by retention time.

·        The mentioned deactivation doesn’t include the licenses expiry date (only user account).

Minimum # of activity by default =1 integer

Maximum # of activity = 50 integers

(Example)

At PP: when Physician added an activity exceeding the setup value a message will show to him that he exceeds the maximum allowed Activity per prescription.

English message: “you Exceeded maximum number of drugs per prescription (maximum number of drugs per prescription is 10)”

Arabic message:

“لقد تم تجاوز أقصى كمية مسموحه لعدد الأدوية في الوصفة الواحدة (أقصى عدد مسموح للأدوية للوصفة هو 10)”

Integration:

System should reject any eRx from HIS if it exceeds the limit max value to be mapped from CP to TMB to reject any eRx includes prescribed medication more than setup value.

Details

Minimum # of Diagnose by default =1 Integer

Maximum # of diagnose Activity =20 integer

(Example)

UI at the system to Configure the maximum number of Diagnose by Prescription

At PP: when Physician added a Diagnose exceeding the setup value, a message will show to him that he exceeds the maximum allowed Diagnose per prescription.

English message:

“you Exceeded maximum number of Diagnose per prescription (maximum number of Diagnose per prescription is 5)”

Arabic message:

“لقد تم تجاوز أقصى كمية مسموحه لعدد التشخيصات في الوصفة الواحدة (أقصى عدد مسموح للتشخيصات للوصفة هو 5)”

Integration:

System should reject any eRx from HIS if it exceeds the limit max value to be mapped from CP to TMB   to reject any eRx includes diagnosis more than setup value

The Facility admin can’t add users more than the above defined value for this facility.

(Example)

Setup will be on Facility level

When adding new Pharmacy branch NUPCO Admin will setup the maximum number of users for this branch

At CP: Facility Admin can’t exceed the setup value with a message appear to him that the pharmacy branch exceeded number of assigned users

OI: Will sync the facility information from LMU that includes maximum # of users

Table: facility list (RQ-002) includes max # of user per facility

For previous configured facility admin can’t add new users until the number of active user under his/her facility become less than Maximum Number of active users that defined on LMU level for the same facility.

·        The limit should be in integers only. With default value

o   Zero (0) value means unlimited # of users.

The Facility admin can’t add users more than the above defined value for this facility.

(Example)

Setup will be on Facility level

When adding new PHC, NUPCO Admin will setup the maximum number of users on this PHC branch

At CP: Facility Admin can’t exceed the setup value with a message appear to him that the pharmacy branch exceeded number of assigned users

·        The limit should be in integers only. With default value

o   Zero (0) value means unlimited # of users.

OI: Will sync the facility information from LMU that includes maximum # of users

Table: facility list (RQ-002) includes max # of user per facility

·        For previous configured facility admin can’t add new users until the number of active user under his/her facility become less than Maximum Number of active users that defined on LMU level for the same facility.

·        The limit should be in integers only. (More than zero).

·        System should give warning message in user login to inform the user about the facility expiration that defined to user account.

(Example)

·        to configure the system to send an email to facility admin notify for facility licence        expiry before X days from expiry.

·        once user login to system to notify him about facility Expiration before 30 days

·        once facility licence expired user can’t access the system.

TMB Should also reject any transactions submitted on expired facility and return a clear error message mentioning that facility license has expired please contact the system admin.

(Example)

Wil add new module for adding Facility with its details as RQ-020

WASFATY Admin will be able to add, modify and deactivate facility.

·        For hiding facility, it must hide from user assigned and report dropdown list.

·        For deactivated facility, the facility needs to be identified in all dropdown list in all systems.

Refer to RQ-021

·        Hiding for facility with or without transaction.

·

·        NUPCO should have the functionality to approve the activation of the pharmacy branch once it’s been created.

Refer to RQ-022

(Example)

·        Facility admin for pharmacy chain to log in and add new facility and fill all required data as in RQ-21

·        Once NUPCO Admin approves and activate the Facility, the facility admin will get notification via SMS / Email with activation code

·        Facility admin can start adding and assign user to the created facility.

·        If NUPCO Admin reject the registration for the user, an email should be sent to the user with reason for rejection.

Example: Once the PP is inactive and not in use for 25 minutes, PP will log off automatically.

(Example)

·        Below configuration should be applied to all system component (PP, CP, LMU, CORE, MDR)

the duration of session time out.

·        Before 2 minutes of session timeout, system should notify the user of an auto-logout after 2 minutes,

·        After the 2 minutes, the system must log out the user if there is no action from the user.

MDR:

·        Before last 10 days from the expiry date (everyday), system must show user a notification as a reminder to the expiry date.

(Example)

At Login Page once the user enters his credential, system will check the facility license   expiry date:

·        If the license is valid, he will be logged in to system

·        If license is near expire, system will notify the user with message for near expiry

o   Before last 10 days from the expiry date (everyday), system must show user a notification as a reminder to the expiry date.

·        If the license is expired, user will be able to login to CP but he will not be able to access any other systems

o   Message to the user: as table below

TMB:

·        To validate the transactions from PP and external vendors (HIS, POS) regarding the clinician’s licences for below transaction:

o   Post New prescription

o   Edit new prescription

o   Cancel prescription (for another physician)

o   Request authorization for Dispense

o   Claim dispenses

·        TMB to reject any transaction if the clinician licence is expired with below denial code

Validation Clinician with NHIC:

·        Register new Clinician at CP system

ü  Admin/user to fill the user document ID and Date of birth

ü  CP will call NHIC API, if user has valid licence with status active, data retrieved from NHIC will be auto refill in CP system.

o   User can’t fill any data that should be filled by NHIC.

o   User should fill the fields that is not retrieved from NHIC.

·        Issue an e- Prescription (Physician) (PP& integrated vendor)

o   Once Prescription posted in TMB, TMB will call the NHIC API to validate for the clinician licence

ü  If licence is valid and user is active, prescription will be approved

ü  If licence is not valid prescription will be rejected with return message to the user

“User license is expired, kindly check with NHIC for more details”

الرخصة الطبية منتهية الصلاحية، يرجى مراجعة هيئة التخصصات الصحية لمزيد من المعلومات

·        Request authorization for dispense (Pharmacist) (PP& integrated vendor)

o   Once user send a request for dispense in TMB, TMB will call the NHIC API to validate for the clinician licence

ü  If licence is valid and user is active, prescription will be approved

ü  If licence is not valid prescription will be rejected with return message to the user

“User license is expired, kindly check with NHIC for more details”

الرخصة الطبية منتهية الصلاحية، يرجى مراجعة هيئة التخصصات الصحية لمزيد من المعلومات

ü  Real-time with NHIC.

ü  Near-real time: where system will call the NHIC once every x hours and update the facility data on the LMU

ü  If NHIC is down, system should have an option to validate on LMU data without calling NHIC.

ü  System could be switch between option 1 or option2

·        If the user is assigned to two or more pharmacies, he can login only to the active (license not expired) pharmacy.

·        Message to the user: Your facility licence is near to expire, kindly notify your facility admin for renewal.

·        Before last 10 days from the expiry date (everyday), system must show user a notification as a reminder to the expiry date.

(Example)

At Login Page once the user enters his credential, system will check the facility license   expiry date:

·        If the license is valid, he will be logged in to system

·        If license is near expire, system will notify the user with message for near expiry

o   Before last 10 days from the expiry date (everyday), system must show user a notification as a reminder to the expiry date.

·        If the license is expired, user will be able to login to CP, but he will not be able to access any other systems

o   Message to the user: as table below

Selection of facility must be before login is complete.

TMB:

·        To validate the transactions from PP and external vendors (HIS, POS) regarding the Facility licences for below transaction:

o   Post New prescription

o   Edit new prescription

o   Cancel prescription (for another physician)

o   Request authorization for Dispense

·        TMB to reject any transaction if the facility licence is expired with below denial code

Validation Facility with NHIC:

·        Register new facility at CP system

ü  Admin/user to fill the facility  data

ü  CP will Call NHIC API, if facility has valid licence with status active, data retrieved from NHIC will be auto refill in CP system.

o   User can’t fill any data that should be filled by NHIC.

o   User should fill the fields that is not retrieved from NHIC.

·        Issue an e- Prescription (PP& integrated vendor)

o   Once Prescription posted in TMB, TMB will call the NHIC API to validate for the Facility licence

ü  If licence is valid and user is active, prescription will be approved

ü  If licence is not valid prescription will be rejected with return message to the user

“The facility license is expired, kindly check with NHIC for more details”

“رخصة المنشأة منتهية الصلاحية، يرجى مراجعة هيئة التخصصات الصحية لمزيد من المعلومات

·        Request authorization for dispense PP& integrated vendor)

o   Once user send a request for dispense in TMB, TMB will call the NHIC API to validate for the Facility licence

ü  If licence is valid and user is active, authorization for dispense will be approved

ü  If licence is not valid, authorization for dispense will be rejected with return message to the user

“The facility license is expired, kindly check with NHIC for more details”

“رخصة المنشأة منتهية الصلاحية، يرجى مراجعة هيئة التخصصات الصحية لمزيد من المعلومات

ü  Real-time with NHIC

ü  Near-real time: where system will call the NHIC once every x hours and update the facility data on the LMU

ü  If NHIC is down, system should have an option to validate on LMU data without calling NHIC.

ü  System could be switch between option 1 or option2

It must be aligned with the RQ-086 and RQ-156.

·        The type of the update

·        The user who updates the prescription

·        The time and the date

·        The details of the update.:

i)       Update (add or remove) patient allergy

ii)      Update patient chronic diseases

iii)    Update

iv)    Update patient weight & height

v)     Add/ delete activity

vi)    Edit quantity per activity

vii)   Edit instruction per activity

viii) Edit indication per activity

ix)    Editing physician comments

Refer to RQ-139-143, any update on the prescription to be registered in the log

(Example)

Log section per prescription level to show the physician all modification happens for the prescription

·        Audit log record must be available based on the user log.

to any prescription.

At TMB

 Log must be available as table to above to save the prescription as well received from external HIS.

 At OI

to reflect same log in the report extracted from TMB data (Refer to RQ-139).

·        Recommend to used centralized audit log for all solutions to use and to give holistic view on all action performed by users on all different systems.

Audit log should have a filter allowing to search by User, system component, subcomponent, and date.

(Example)

each Systems to access the login- logout section for the: CP, PP, MDR, CORE, LMU, and OI

Below screen from CP:

OI: to have centralized login logout history for each system, where user can select the    system, Table: User logging. (RQ-002 excel sheet)

·        Recommend to used centralized audit log for all solutions to use and to give holistic view on all action performed by users on all different systems.

Audit log should have a filter allowing to search by User, system component, subcomponent, and date.

(Example)

OI: to have a report to view users account modification from CP

Table: user edit log (RQ-002, excel sheet)

·        Recommend to used centralized audit log for all solutions to use and to give holistic view on all action performed by users on all different systems.

Audit log should have a filter allowing to search by User, system component, subcomponent, and date.

(Example)

NUPCO Admin can check the logs for patient file registry for any modification on patient file

·        Example: one user change patient mobile #, the log will show the date of change and type of change and who did the change

·        NUPCO admin can give a user right to any user to check patient data.

OI: to have a report to view patients file data modification from pp

Table: Patient registry log (RQ-002, excel sheet)

(Example)

(Example)

·        Patient Name

1.      Should have:  FIRST (Mandatory), SECOND, THIRD, FAMILY (Mandatory).

2.      Name can be in Arabic or English, if the user adds first name in Arabic all other fields for the name should be mandatory Arabic and same for English

3.      Should not accept numbers or special character except (- and ‘)

·        DOB

1.      No DOB should be accepted less than year 1900 Georgian or 1320 lunar.

2.      DOB format to be DD/MM/YEAR (21/03/1990), (21/03/1399)

·        Patient E-health ID.

·        Document ID: Need to be set based on Nationality and Residency type

·        Saudi National: Residency Type should be Citizen, and document type should be national card by default and locked and document ID # should start with 1xxxxxxx, to be only 10 digits.

·         For non-Saudi as follow

1.      2.If residency type selected resident, document type should be locked Resident Card and Document ID # should start with 2xxxxx to be only 10 digits

2.      3.If residency type is visitor and document type boarder number, Document ID # should start with 3xxxxx or 4xxxxx to be only 10 digits.

3.      For Visitor and document type passport, keep field with

String

4.      For GCC, Document ID # should be number and accept from 8 to 15 digits.

5.      Add new Nationality (Not defined – بدون)

If select (Not defined – بدون) in the nationality field, the fields of Residency Document ID will be using facility ID + file no at facility ID as a temporary solution.

·        Contact number:

1.      It should accept only numerical digits.

2.      The default “ xxxxxxxxx” needs to be locked to 14 digits.

3.      For International code , field will accept any numericals and no limitation on the number of numericals.

4.      For domestic code, it should start with 0 with only 10 digits.

5.      If the entry is 0 followed by any non- zero number, then the limitation is of 10 digits.

·        The default “Preferred Language” needs to be “Arabic”. For all Saudi patients the preferred language needs to be Arabic.

(Example)

(Example)

(Example)

(Example)

·        The system should have the ability to add more than one file number based on the facility the patient visits.

(Example)

·        When patient visited new Facility, system should force the Physician /receptions to add a new file number assigned to the new facility.

·        Facility # will be populated by the system based on the user facility.

OI: for each patient transaction, patient file number relating to the issuing facility to be added in the transaction.

Table: Patient visits (RQ-002 excel sheet)

TMB:

To add “Patient File #” field to the schema, and to be part of eRx Post Request in the “Encounter” tag.

(Example)

Duplicated with RQ-079

(Example)

(Example)

Admin can enable of disable this functionality

·        NUPCO to activate or deactivate this functionality.

The Default is the de-active.

·        OTP Expiry time is 4 minutes

·        System can resend the OTP if expired, or patient didn’t receive the SMS.

(Example)

o   On system level

o   On Group level (Ex. MOH)

PP: if OTP for Patient registration is Active:

1-     When the user registers new patient, with the required data.

2-     User can add and save the patient but with inactive status.

3-     System will send SMS (OTP) to the Patient mobile #

4-     User with Registration rights will enter the activation code sent to patient

5-     If the OTP entered wrongly, system to popup a message with rejection reason (activation code is incorrect, please re-enter again)

6-     If the code is correct Patient file registration will be activated

7-     In case any problem in patient’s mobile, WASFATY support team can provide an OTP (auto generated and change every time for one use only) to the registration module to complete the register.

8-     The register must have the ability to resend the OTP.

9-     Once file activated, a SMS message will be sent to patient for confirming the activation of the file

based on the system level, or Group level (based on group requirements) by NUPCO Admin user.

(Example)

·        After every Login

·        After every session timeout

TMB:

·        To validate the transactions from PP and external vendors (HIS, POS) regarding the clinician’s assigned facility for below transaction:

o   Post New prescription

o   Edit new prescription

o   Cancel prescription (for another physician)

·        TMB to reject any transaction if the clinician facility is not match the assigned facility with below denial code

(Example)

1-     Patient name

2-     Patient file number

3-     Patient ID

4-     Patient mobile #

5-     e-Rx number

(Example)

1-     e-Rx Status

2-     Date

3-     Nationality

4-     Gender

1-     e-Rx Status (Drop list: Requested, approved, partially approved, canceled, rejected)

2-     Date (Start date- end date: in Georgian calendar, date from time of search and earlier)

3-     Nationality (Drop Down List)

4-     Gender. (Drop Down List)

(Example)

(Example)

(Example)

·        Chronic List should read from Predefined list, usually it’s a sub list from ICD10-AM (Not the full ICD10-AM list).

·        Same functionality as exists for allergies, Physician can Add, delete from the List.

·        Should be loaded when Choosing the Patient record.

·        A new list to be added for Chronic diseases drop down options in LMU

·        Should be added to WASFATY E-prescription report.

(Example)

(Example)

·        Same as Weight functionality.

Should be available on Pharmacy side also, same as weight

(Example)

·        Vital sign (add/modify) must be considered as a user privilege to be added to any user role.

·        It should be accessed by user with certain privilege (view, add, edit, delete any vital sign).

·        Physician must have the ability to add/modify a vital sign without closing the prescription for the same visit date

·        Vital sign is not mandatory.

·        System must ask for a double confirmation if he is sure to continue without entering the vital sign

·        Vital sign must be sent to the pharmacist with the prescription data.

(Example)

Need to add new fields at patient profile menu (new prescription tab next to height/ weight/ active drugs as optional fields) under the Vital Signs for blood pressure and blood sugar, to be registered at each prescription by physician.

Blood Pressure

ضغط الدم

At TMB: All added field to be added to patient profile in the schema to consider the integration with other HIS.

OI: for each patient transaction, vital signs data to be added in the transaction

Table: eRxR-eRxA (RQ-002 excel sheet)

توفير إمكانية إضافة أو تعديل أو حذف نسبة السكر في الدم للمريض

Required to add fields for registering the patient blood pressure per visit.

·        Vital sign (add/modify) must be considered as a user privilege to be added to any user role.

·        It should be accessed by user with certain privilege (view, add, edit, delete any vital sign).

·        Physician must have the ability to add/modify a vital sign without closing the prescription for the same visit date

·        Vital sign is not mandatory.

·        System must ask for a double confirmation if he is sure to continue without entering the vital sign

·        Vital sign must be sent to the pharmacist with the prescription data.

(Example)

·        Need to add new fields at patient registration menu under the Vital Signs for blood sugar, to be registered at each patient visit to the clinic

·        Data to be added on the e- prescription printout

Blood Sugar:

At TMB: All added field to be added to patient profile in the schema to consider the integration with other HIS.

OI: for each patient transaction, vital signs data to be added in the transaction

Table: eRxR-eRxA (RQ-002 excel sheet)

·        We need to consider the following:

o   The special case must be a drop-down list

o   More than one special case can be added or removed

o   Special case is not mandatory.

o   Special case must be shown in the pharmacist and physician role.

o   Drop down list

(Example)

·        Physician page, Physician needs to register any   special needs on patient profile

·        Pharmacist can view patient special needs with no modification

TMB:

·        TMB to add the special needs on patient profile schema with same selection options from above (coded values).

OI: for each patient transaction, special needs data to be added in the transaction

Table: eRxR-eRxA (RQ-002 excel sheet) and at patient visit table

·         

·        About pregnancy, it would not be a mandatory list. The list contains (T1, T2, T3, NONE).

·        About lactating, it would not be a mandatory list and the list must contain Yes/ NO.

·        The above two points must be considered in the decision support system.

·        About “التقرحات،” (ulcers) it will be with special cases.

·        About allergy, we need to consider the following:

o   The allergy must be from the SNOMED list for both post level.

o   The allergy must be sent to the pharmacist

o   The allergy can add or removed.

o   The allergy can be none (The none value must be added in the SNOMED list).

o   The allergy is mandatory to be added.

o   The allergy must be considered in the decision support system for the warning and the physician advisory.

o   Any allergy should have a severity level to be entered by the physician as the following: SEVERE, MODERATE, MILD.

(Example)

·        Physician should be able to add, modify or delete the pregnancy or lactating status of the female.

·        CCE: Need to check any drug to pregnancy/lactating interaction for the prescribed drug, workflow applied as Drug-diagnose interaction, etc…

·        Pharmacist should be able to view the allergy, special needs, pregnancy and

Lactating status.

the allergy, special needs, pregnancy and Lactating status should be views at

prescription print out.

TMB:

·        TMB to add to patient profile and to consider HIS integration for adding/modifying/deleting conditions.

·         

OI: for each patient transaction, special cases data to be added in the transaction

Table: eRxR-eRxA (RQ-002 excel sheet) and patient visit table

Refer to RQ-074

(Example)

·        All historical information of a patient to be displayed.

·        A new link called “Historical information” to be created in patient profile, that will be shown after the physician open patient profile.

·        The “To date” will be populated default from the system date and the “From date” will be populated as 1 month before the system date.

(Example)

·        Default View:

·        Physician can search for older prescription by selecting from to date search. (end date must not exceed start date).

·        Physician can view single prescription details by clicking on view button.

o   System should retrieve the below data per prescription

·        In the history details will show the prescription/activity status as below

o   Prescription Status

ü  Dispensed (All activity has been dispensed with their refills)

ü  Partially dispensed (if any activity/refill not dispensed yet)

ü  Cancelled (All activities have been cancelled)

ü  Blocked (All activities have been blocked)

ü  Not dispensed (none of the activity has been dispensed yet)

ü  Expired

o   Activity Status

ü  Dispensed (Activity has been dispensed with its refills)

ü  Partially dispensed (Activity dispensed partially, or one of refill still not dispensed)

ü  Cancelled (Activity has been cancelled)

ü  Blocked (Activity has been blocked)

ü  Not dispensed (Activity has been dispensed yet)

Patient history visits with default of active prescription

(Example)

Physician should be able to search for a visit or prescription for specific period

Period for search shouldn’t be more than 365 days.

View: prescription with its detail will populate

Status: Active: prescription still valid and contains active drugs for the patient.

(Example)

(Example)

·        Physician should be able to see the history by Clicking on

.

(Example)

(Y/N)

(Example)

(Example)

(Example)

(Example)

(Example)

Diagnose and generic name

(Example)

(Example)

The system should have the ability to send out a warning to the physician whenever there is an overdose in prescribing according to duration, age, active dispensed quantity.

(Example)

·        Allergies

·        Diagnosis

·        Medications

·        Indications

·        Comments: predefined drop list

(Example)

·        The physician will have a screen where he will define his favourite list for the below from the original lists:

Allergies

Diagnosis

Medications

Indications

Example screen shot:

And for comments: he will add his predefined comments to table.

Comments:

·        The physician can switch between the below three lists:

All List

Physician Favourite list (default list)

o   home delivery OR

o   not allowed for delivery OR

o   None

·        Allowing the flag based on the drug configuration on MDR.

·        At least one generic drug on the prescription must be allowed in MDR to be delivered.

·        At least one generic drug on the prescription marked as not allowed for delivery, will disable the home delivery option on a prescription level.

·        If there are no drug allowed to be delivered, system must show a notification message.

·        The data of this flag and all prescription data must be designed to be integrated to other systems.

(Example)

LMU: new list to include the is Delivery columns (generic and trade)

PP: to sync the new field instantly to manage the delivery validation on prescribing level- Doctor

On dispensing Level – pharmacy PP should show the future refills with the details (generic, date, quantity, duration)

TMB:  to have the Items Flagged and return the remain Refills on activity level including the delivery flag every time the transaction is downloaded by the pharmacy

This should be reflected in the lookup table to allow ocean insight to pull the needed reports

Ocean insight: to generate a report with the delivery items including the details related (Prescription ID, Activity ID, code, duration, quantity, member ID, National ID, Clinician ID, Contact Number)

The integrated providers should do the same steps on the system they are using, however for the reporting on Ocean insight, the above deliver items will be covered

·        The Flag for delivery to be true or false based on the below workflow rules on prescription level.

Prescription Flagged with home delivery:

·        Can be dispensed by patient from Pharmacy

·        Can be home delivery

·        Prescription valid for delivery is not meant that it is dispensed.

·        Dispense for delivery should be through WASFATY system

Refer to RQ-114.

(Example)

At PP will follow req114 as below workflow

1-      Dispensing or Partial Dispense

2-      Rejection (at prescribe or dispense).

When: notification while he is accessing the system, if he was offline, once he login to get all notification.

(Example)

·        Will Develop a notification sevrer where any change in the prescription from physician side or from dispense side will be pushed to it.

·        Notification server will retain any new changes recived up to 3 days.

·        Provider Portal will be able to get the notification for the  changes in the prescription real time by connetcing to the notification server.

·        External HIS will be able to get the notification for the  changes in the eRx real time by
PP:

·        PP will establish a real time connection with  notification server to get any changes in prescription loged and send it to a notiofcation Panel built in PP.

·        Notification Center at PP will be able to save notifciation and to be viewed by the physician user with below configuration:

o   Notifcation will be expired on the Notification center after xx days

o   Notifcation center will be able to show the leatest xx notifctaions to the Physician.

o   Notifcation Center will allow physician to filter the notification by status

ü  Blocked

ü  Cancelled

ü  Dispensed.

·         At Provider Portal , for any prescription status changes, prescription satatus will be updated and physician will be able to review the updated prescription status once recived from the notifciation server.

Note: Sample Mock-up might change during development

(Example)

(Example)

·        CP System will integrate with OI to show the statistics dashboard for user

·        Any Physician   authorized to issue prescription in WASFATY SYSTEM will have an access on CP portal and will be able to see the number for dispensed and rejected prescriptions for PP and other HIS for a standard period.

·        User should be able to view statistics for all transactions issued by him, using WASFATY provide portal, or using external integrated system

·        The user can change the period of the number of the statistics.

·        Dashboard should show only the transactions for user accessing the CP only

The physician can change the period of the number of the statistics.

(Example)

(Example)

(Example)

·        In prescription page the doctor should be able to check the related trade drugs of the selected generic drug, if the generic drug has option to show the trade based on the previous point.

·        The details of the shown trade must include the following:

o   ROA Description.

o   Unite Type

o   Package Size

o   Strength.

(Example)

·        At LMU: to add the show trade flag to generic list

·        At PP when the physician selects the Generic name, system will display the assigned Trades to the generic with no action on it (if the drug is checked to be displayed.

·

·        The system must show only the active branded drugs.

·        The system must consider the division of the drug of the selected physician

(Example)