Phase III. Process analysis
The Analysis of the Prescribing Process Using Conceptual Model of Workflow Elements. Successful implementations of e-prescribing systems and the precise depiction of UML diagrams require a deep understanding of the main elements of prescription-writing workflow (
38). However, there are different approaches toward definition and evaluation of workflow (
23,
65,
66); therefore, we used the conceptual model of workflow elements to define the basic workflow elements of the current prescribing process in Iran (
Figure 1). The model of elements defining workflow developed by Unertell
et al. is grounded in the systematic literature review, and is composed of two levels: pervasive and specific.
The pervasive level includes three components that apply throughout specific elements of the workflow: context, temporal factors and aggregate factors.
The specific level is composed of actors, artifacts, actions, characteristics, and outcomes (
61).
The conceptual model of workflow components for current prescribing process in Iran.
Analysis of the prescribing process using the technique of modeling “as-is” processes Modeling as-is business processes provides a foundation for defining business activities and improves business processes. In recent years, UML has been highly regarded as an effective technique of modeling business processes and has been recognized as the best way to analyze processes and describe system characteristics using graphical techniques (
40,
52,
67), while being comprehensible for people lacking scientific and technical skills (
68). Therefore, UML activity and use case diagrams were used to analyze the prescribing process in this study.
Business process modeling of medication prescription in iran using business usecase diagram
In first, the context diagram was used in two levels of abstraction in order to find actors, and then the related use cases were recognized according to what people want from the system (
Figure 2).
The context diagram of prescribing system in Iran
Use case diagrams
are the
starting point for other UML diagrams, and
in spite of their simplicity, they provide a general overview of the analyzed process. The
use case model contains a set of use cases, actors, and their relationships extracted from collected data. An actor defines a coherent set of roles that users of an entity can play when interacting with the entity, including human users and other systems. A use case represents the steps in a specific business function or process. The «include» or «uses» relationship indicates that the path of one use case is included in another. The «extends» allows to modify the behaviour of the base use case and shows that a use case provides additional functionality that may be required in another use case (
62,
63).
As the use case diagram for the current prescription process indicates in
Figure 3, there are six main use cases (including prescribing the medicine, transferring the prescription to pharmacy, dispensing drugs, relationship with the insurance organization, request for reimbursement of prescriptions), and four main actors (including physician, patient, dispenser, and insurance office) in this area. The dispenser actor means
pharmacy,
dispensing pharmacist or pharmacy technician, and the insurance office consists of the
prescribing investigators or verifier staff in insurance organizations.
Use case diagram of the prescription process in Iran
In this diagram, the relationship between use cases of patient visit and prescribing was shown by «extend» connection, because visit use case is complete even without prescribing use case, and the visit might be done without any medication prescription. The use case of prescription is, therefore, optional. In this analysis, we only considered visits that entailed prescriptions.
Considering that in the process of dispensing, the circumstances might be different, we also used «extend» relation for illustrating the relationship between the dispensing under different circumstances (for instance dispensing of special patients' prescriptions and verification of medication prescriptions), indicating that the dispensing process in these conditions differs from that in general prescriptions.
Nowadays, dispensing medication to special patients (including those being treated for complex disorders such as haemophilia, multiple sclerosis and thalassemia, as well as transplant and kidney dialysis patients) requires creation of a medication record in the database of special patients, only to be performed by personal encounter at related insurance offices. Hence, the «include» relationship was used for depicting the compulsory connection between use cases related to the dispensing of medication to special patients, creating patient medication record, and also the relationship with insurance agencies. Also, personal attendance at insurance offices and creation of a medication record is initially required for internet verification of some other prescriptions as their medication are above the defined cost limit pricing. In following encounters, however, it is possible to verify the medication from the pharmacy through the internet. On the other hand, pharmacies are eligible to verify prescriptions under the defined cost limit pricing online without having to create a medication record. Therefore, «extend» relationship was used to represent the conditional relationship between use cases of verification of medication prescription and creating patient medication.
The base use case of reimbursing the expenses includes the functionality of request for reimbursement use case, as prescription investigation in order to reimburse the costs can only be done after receiving all necessary documents for related insurance agencies (including a list of prescriptions, electronic files for prescription records, physical prescriptions, and paper reimbursement claims). This is the reason why “include” obligatory relation was used between these use cases. The diagonal line on use cases and actors refers to business use case modeling with UML2.
Business process modeling of prescription in iran using activity diagram
“Activity diagram is typically used for modeling the logic captured in a specific use case in a use case diagram” (
64). An activity diagram, also referred to as a workflow diagram, employs traditional flowchart techniques to model workflow, information exchange, and business processes (
33,
38,
69-
71). This type of diagram is suitable for depicting the dynamic nature of the prescription process. Activity Diagram is used to model a specific actor's workflow within the entire system and shows all potential sequence flows in an activity. The Activity Diagram is comprised of the model elements including, actions, decision point, transaction,
join nodes or
fork nodes, swim lane,
initial and endstate (64). The activity diagram of the prescription process in Iran (
Figure 4) indicates the order of activities, tasks and how they are assigned to different actors (roles) in this business process. Prescription process starts with the activity initial node of the patient-physician encounter and ends in the activity final node of the
reimbursement for dispensed
prescription medications. The activity diagram displays four swim lanes, representing the roles of the patient, the physician, the dispenser and the insurance office (sequencing). These swim lanes contain the sequence of
activities performed by the
actors.The fork node at the beginning and the joint node at the end have been used in order to show simultaneous and parallel activities associated with the use case of visiting the patient in the physician swim lane column (including patient interview, patient physical examination, and clinical results interpretation), and also to depict parallel activities associated with the use case of dispensing in the dispenser swim lane column (including dispensing for special patients and medication prescriptions requiring insurance verification). The reason is that a fork node has one input flow and several output flows, while a join node has several input flows and one output flow. Using decision nodes, the change in the work content of dispenser activities has been demonstrated based on conditions resulting from different types of medication prescription (including those belonging to special patients that require insurance verification and the creation of medication records in insurance offices) and also evaluation of prescriptions by the pharmacist (including problematic prescriptions, and prescriptions that require the pharmacist's accessibility to the patient).
Activity diagram of prescription process in Iran
Phase III: Bottlenecks identification
Qualitative Content analysis based on defective areas category and also process analysis to address problematic areas (e.g. redundant and duplicated work, concentration of decision nodes, and communicative weaknesses among stakeholders) led to detecting bottlenecks of the prescription process in Iran. These bottlenecks then categorised by research team based on identified use cases and swim lanes of the current prescribing process models in Iran. The results of the bottlenecks Identification phase is presented as below:
In the use case of prescription and the swim lane of the physician: The physician prescribes medications without considering the patient’s financial status, medication coverage by the patient's insurance plan, Iranian pharmacopoeia of insurance coverage, and patient preferences. This kind of prescription increases the patient’s dissatisfaction and leads to generation of prescriptions that are not covered by any insurance plan.
Paper-based prescribing prevents evaluation of medication-specific factors and patient-specific clinical and non-clinical factors, access to external resources, and the use of clinical decision support systems for the medication prescription process. Therefore, warnings about drug interactions, contraindications, medication allergies and repetitive medication do not appear at the time of prescribing. Also, it is not possible to calculate dosage automatically according to age, gender, weight, health history, and so forth.
Prescription does not have a unique prescription number for identification and tracking. The volume and page number of the patient’s insurance booklet is the only prescription identifier that has been used in pharmacy software systems over the years. However, Social Security Insurance Organization has recently started recording the 18-digit serial number and barcode (composed of the patient’s National Identifier Number, insurance branch code, volume number and page number) on each page of the Social Security Insurance booklet in order to provide the required preparation for electronic health record implementation.
There is no data element about the number and duration of refills on medication prescription.
The physician cannot review and track the paper prescription after the drug is picked up by the patient. Therefore, it is not possible to modify and cancel the existing prescription, or discontinue a specific medication, if the patient's condition changes.
All paper prescription data must be entered in the pharmacy software system to provide the electronic file containing prescriptions and dispensing information to be sent to insurance offices. This causes a bottleneck that slows down the process of dispensing prescriptions and imposes extra work on the pharmacy.
The patient's insurance number is the most important identifier of the patient in the pharmacy software system, while it is not a unique patient identifier. In this regard, the Social Security Insurance Organization has withdrawn the old insurance booklets that did not contain the National Identifier Number, and has replaced insurance booklet serial numbers with this unique number.
Pharmacies do not have a unique national identifier so the Iranian Food and Drug Organization of the Ministry of Health and insurance organizations use different identifiers to recognize pharmacies.
A fundamental difficulty of this process is the multiple drug codes used by Food and Drug Organization of the Ministry of Health and Medical Education of Iran [Iran Registration Code (IRC) and European Article Number 13 (EAN-13)], insurer organizations formal five-digit medication code, and Saman Salamat Company (16 digit authentication code of drugs). IRC is a common number for pharmaceutical products stored in the data bank of the Division of Pharmaceutical and Narcotic Affairs of the Drug Supervision and Evaluation Office, from which all information about pharmaceutical products can be obtained.
Creation of a medication record is initially required for internet verification of prescriptions with medications that are above the defined cost limit pricing.
Although provided opportunity for online verification of prescriptions from the pharmacy, the poor quality of the internet connection in some cases has caused wandering of the patients to have their medication prescriptions verified.
Special patient smart cards are only used for dispensing each specific patient's medication based on the defined medication ratio, while this card has been designed for use through the prescription processes.
Refilling and renewal of covered medication prescriptions is not possible through pharmacy and without referring to the physician. If the number of refills is indicated on the prescription, the total price for the renewed prescription will have to be paid by the patient without taking insurance coverage into consideration.
Phone call is the only communication channel between pharmacists and physicians; therefore, the patient will be referred to the physician if accessibility to physician is not possible through this channel when required. This shows the weakness of communication between pharmacists and physicians.
The physician cannot be notified of the filled or refilled prescriptions in the expected time course, and therefore it is not possible to identify the unfilled prescriptions.
In the swim lane of the dispenser, decision node concentration is seen in activities of medication prescriptions verification, dispensing of prescription for special patients, evaluation of prescription by pharmacists, and pharmacists’ communications with physicians. The use case management of dispensing is therefore difficult because of the unpredictability of the activities resulting from these nodes.
Despite automation of some activities in the prescription process such as entering the prescription data in the pharmacy software system and the online claiming system of Social Security Insurance Organization, the prescriptions investigation in insurance offices is still done after receiving physical prescriptions.
Insurance offices have different policies regarding receiving, investigating and verifying medication prescriptions, and identical services are provided differently by different health insurance organizations.
Paper prescriptions are legally the only valid documents for dispensing and investigating medication prescriptions, and using electronic prescriptions is legally forbidden. This legal limitation has led to rework loops, redundant and duplicated work in this process.