Case Reports: 2019 Vol: 25 Issue: 5
Dina Rateb, The American University in Cairo
Amr Rashad, The American University in Cairo
This case study examines the effect of using Information Technology (IT) on a private medical tests laboratory by analyzing an existing Medical Test System to improve the patient’s experience and to create an online presence for the enterprise. A major concern was that the business faced fierce competition by a couple of well-established laboratories in the market. The purpose of this case study is to provide an opportunity for IS/IT Capstone graduation project students as well as students in a Systems Analysis and Design course to review a comprehensive realistic project that proceeds through the systems development life cycle and in which they apply almost everything they learnt in the IS/IT program such as Project Costing and Benefits, Scheduling, Project Planning and Project Management, Requirements Analysis, Data Modeling, Process Modeling, and System Design. Some of the essential textbooks that we use in teaching are listed in the references ((Elmasri & Navathe, 2011; George et al., 2006; Larman, 2004; Kendall et al., 2014; Riccardi, 2003; Sommerville, 2016). Based on the case synopsis, deliverables may be requested to include process and data modeling requirements and design artifacts (such as a use case diagram, a class diagram, detailed transaction scenarios, system architecture, activity diagrams, sequence diagrams as well as a database and an interface design). This may require 15-25 hours to complete if students work in groups of 2-3 in class or outside normal class time. The case study is of moderate difficulty and is designed for junior and senior students. Similar case studies were reported by Terry Fox in JIACS (2011 & 2017).
This case study examines the effect of using Information Technology (IT) on a private medical tests laboratory by analyzing an existing Medical Test System to improve the patient’s experience and to create an online presence for the enterprise. A major concern was that the business faced fierce competition by a couple of well-established laboratories in the market.
The purpose of this case study is to provide an opportunity for IS/IT Capstone graduation project students as well as students in a Systems Analysis and Design course to review a comprehensive realistic project that proceeds through the systems development life cycle and in which they apply almost everything they learnt in the IS/IT program such as Project Costing and Benefits, Scheduling, Project Planning and Project Management, Requirements Analysis, Data Modeling, Process Modeling, and System Design. Some of the essential textbooks that we use in teaching are listed in the references ((Elmasri & Navathe, 2011; George et al., 2006; Larman, 2004; Kendall et al., 2014; Riccardi, 2003; Sommerville, 2016).
Based on the case synopsis, deliverables may be requested to include process and data modeling requirements and design artifacts (such as a use case diagram, a class diagram, detailed transaction scenarios, system architecture, activity diagrams, sequence diagrams as well as a database and an interface design). This may require 15-25 hours to complete if students work in groups of 2-3 in class or outside normal class time. The case study is of moderate difficulty and is designed for junior and senior students. Similar case studies were reported by Terry Fox in JIACS (2011 & 2017).
Information Systems Analysis and Design, Object-Oriented Process and Data Modeling, Requirements Analysis.
This case study examines the effect of using Information Technology (IT) on a private medical tests laboratory to design an Online Medical Test System to improve the patient’s experience and to create an online presence for the enterprise. The Online Medical Test Management system is expected to help overcome most of the technical concerns, reduce errors, enhance the patients’ experience, record all the current patients’ data to merge it within the new system, and above all to focus on the type of patient to look for and retain; all this was correlated with the anticipated increase in profit.
System Requirements Definition
Dr. Magdy Fekry’s laboratory is a private medical tests laboratory that offers a range of diagnostic medical testing. Patient’s specimen may be collected either in the laboratory or at the patient’s home residence. The main features that are expected from the new Online Medical Test Management system should allow the patients to book for home sampling, request test diagnosis, pay online and view their test results; admins to assign Lab assistants and lab doctors to specimen collection and analysis; Lab assistants to record the specimen details; and Lab doctors to submit the test results.
System Objectives
1. The main objectives from the new system include the following:
2. Allow the lab to reach more patients and enhance the patient’s experience as well as enable the patient to reach his/her current and previous test results online with their diagnostics.
3. Make the overall system more efficient from both the patient’s side and the laboratory’s side
4. Allow the handling of a larger number of specimen collection requests and test diagnostics
5. Achieve a more efficient transactions recording system and test results recording system
6. Reduce the chances of errors in handling and recording the test results
7. Improve the test results' reporting process while ensuring the privacy of patient records
The System Scope
An online medical test management system is much needed to improve the current management system that Dr. Magdy Fekry laboratory currently has and it would increase the laboratory’s competitiveness. The system should include a website whereby the patient can reserve an appointment and choose the type of tests he/she wants. After receiving confirmation and having his/her specimen collected the patient can then access the website and download his/her test results once they are uploaded by the lab.
As shown in Figure 1, the system will shift the payment method to online means as well as cash (as an option) giving each capable patient an online presence and option to pay for and receive his/her test results. The system will enhance the communication processes between the laboratory’s staff by facilitating the role of the secretary while assigning sample requests to lab assistants and assigning test requests to lab doctors since they will be able to perform the test recording procedures online. Lab assistants will be able to record a patient’s specimen details online and the lab doctors will be able to submit the patient’s test results shown in Figure 2, on the system’s database.
Main System Services
There are eight main Services to be offered by this system:
1. Booking home sampling (patient)
2. Request test diagnosis (patient)
3. Assigning Lab assistants and lab doctors to specimen collection and analysis (Admin)
4. Recording specimen details (Lab assistant)
5. Submitting test results (Lab doctor)
6. Online payment (patient)
7. Displaying test results (all users)
8. Display reports (Management)
Target users and required services details
1. Patients (customers) should be able to create an account on the system, log-in, access the lab's website to place a request to collect the test specimen and specify the diagnostic tests. They can also pay online and at a later stage access their sample test results, online. A sample interaction service scenario for the payment online is shown below:
Use case: Pay the due test request amount (fees) online.
Scope: Web home sampling system.
Level: User goal.
Intention in context: the intention of the patient is to pay his/her test request amount to be able to view his/her test results online.
Primary actor: patient.
Stakeholder’s interest:
Patient: the intention of the patient is to pay his/her tests’ bill amount to be able to view his/her test results online.
Dr. Magdy’s laboratory: to serve as many patients as possible.
Minimum guarantees: patient is able to view the test types requested and the total amount due.
Success guarantees: the system has received the due payment and generated an electronic receipt.
Trigger: patient requests to check and pay the test requests due amount
Pre-condition: Patient has logged in and pending sample test request
Main success scenario
1. User requests to pay the test requests due amount.
2. System retrieves patient account.
3. System displays the patient’s current due amount.
4. User enters credit card number and confirms debiting the total due amount from his/her credit card.
5. System validates patient credit card.
6. System debits patient’s due payment from his/her credit card.
7. The system makes the due balance equal to zero once the amount is received and notifies the accountant at Dr. Magdy’s laboratory to issue a receipt.
8. System sends an electronic receipt by email to patient.
Extensions:
(1-3) a. System detects that user has left.
(1-3) a.1 use case ends in failure.
1a. System is down.
1a.1. System informs patient and use case ends in failure.
2a. System is unable to access the patients’ account database.
2a.1. System informs patient and use case ends in failure.
5a. System is unable to debit credit card.
5a.1. System asks the user to enter another credit card number; use case goes back to step 4.
6a. Due payment is greater than the user’s credit limit.
6a.1. System asks the user to enter another credit card number; use case goes back to step 4.
2. Admins should be able to access the test requests, assign each test request to a lab assistant and notify the lab to send a representative to collect the patient’s specimen. Admins should also assign test requests to a lab doctor.
3. Lab assistants who collect the specimen should be able to record the specimen's details
4. Lab doctors who perform the tests, submit the test results and diagnostics report and add them to the patient’s record
5. Managers should be able to generate intelligent reports for all the performed medical tests, accounts, patients’ records…etc.
Identified Objects
Some of the identified objects include: patient, time slot, test request, test library, lab equipment, lab doctor, lab assistant, patient specimen, test result, test material, invoices, accounts receivable and accounts payable. Some of the above objects’ data fields were identified (from the Lab documents) to be as follows:
Patient: Patient ID (PID), Patient name, gender, age, test results, cell phone number, address
Test request: Test request ID (TRequestID) and test name (TName) are primary keys, time slot ID, test request status (confirmed or cancelled), assigned lab assistant name, assigned lab doctor, test request status, date, time
Test library Item: Test name (TName), required Equipment, Test description, Test price, Specimen type, requested Test(s)
Lab assistant: name (LAName), address, salary, phone number
Lab doctor personal details: name (LDName), address, salary, phone number
Lab equipment: Equipment ID (EID), Equipment name (EName)
Patient’s specimen: Patient specimen ID (PSID), Test request, Specimen type, assigned lab doctor name, assigned lab assistant, test name
Test result: Patient specimen ID (PSID), Test results, Diagnosis (see Appendix)
Accounts receivable: Invoice ID is primary key, Test request, down payment, down payment date, final payment, final payment date, amount due, payment details, test name, patient name
Test material: Test material name (TMName), Test name, quantity, purchase order ID
Overall project requirements from the students
1. During the project planning phase, the project objectives are set and the overall project tasks and their time estimates (the schedule of the project) and resources are identified. A problem/opportunity in-depth cause-effect analysis is carried out as well as Cost-benefit and SWOT analysis. The project proposal is submitted and reviewed.
2. In the requirements collection and analysis phase, the requirements are gathered for the project directly from the users and based on the user needs; the target system is fully analyzed using data and process models to discover areas of weakness that may be improved in the business process and the expected system deliverables and services. Functional requirements as well as non-functional requirements are fully specified. Use case diagrams are used to represent the summary level scenario of all the features in the project and textual use cases are used to represent the detailed scenarios and required user interactions.
3. In the system design phase, various modules are identified that match the features and requirements identified in the Requirements phase. The modules designs are represented using process and data modeling tools and techniques (such as class diagrams, sequence and activity diagrams). The database design is implemented and a GUI interface design prototype is developed for the desk top or mobile app.
4. At the end of the semester, the students compile all the project documents in one report and provide additional sections on the challenges/problems faced during the project life cycle and how they addressed them, the comparable existing systems/applications, and the lessons learnt as well as future enhancements.
The Project Outcomes
At the end of the project, the students have gained a solid experience in each of the following:
1. Identifying software project objectives, opportunities, problems and challenges.
2. Conducting root cause analysis, cost-benefit and SWOT analysis.
3. Preparing a project proposal, a feasibility study, and a project plan.
4. Identifying, analyzing and tracing the requirements and writing unambiguous, correct and consistent Requirements Specification documents.
5. Developing software design solution and creating interface design artifacts.
We follow a waterfall model approach with some modifications in the phases of requirements analysis and design to overcome its weaknesses such as delay in feedback and changes. The students will gain a hands-on experience in the typical real life Software Development project Processes. They get to express the Software Problem, Costing, Scheduling, Project Planning and Project Management, Requirements Analysis, Specification and Modeling. They also get to appreciate the value of a good Software Requirements and Software Design documentation. The design process and the different design approaches include function-oriented design and object-oriented modeling techniques. In this case study we focus on the latter deliverables.
Based on the case synopsis, deliverables may be requested which would include process and data modeling requirements and design artifacts (such as a use case diagram, a class diagram shown in Figure 3,detailed transaction scenarios, system architecture, activity diagrams, sequence diagrams as well as a database and an interface design). This may require 15-25 hours to complete if students work in groups of 2-3 in class or outside normal class time. The case study is of moderate difficulty and is designed for junior and senior students.
From the given requirements, students can suggest interaction scenarios as well as process and data models for the proposed system requirements and design of the realistic project and compare their suggestions to what has already been achieved in the case study. Sample elements from the suggested solution , include object oriented requirements and design models shown in Figures 4-7, (use case diagram, textual use case, class diagram, sequence and activity diagrams).
The graphical requirements analysis and design models that were developed to represent the requirements (the problem) as well as the design (pre-implemented solution) for the online medical test laboratory management system may be given out as practice questions to students in a Systems Analysis and Design course or a Capstone Graduation project course. Students can identify, analyze and trace the requirements and suggest requirements models as well as develop design artifacts for the new system. The study offers the students an opportunity to apply the process and data modeling methods and techniques in a realistic project and to compare their solutions to an existing solution.
The case represents a study on a typical medical tests laboratory service provider which is a widely spread private business practice in the Middle East as well as in many African and Asian countries. Hence, this experience is replicable in its source country (Egypt) as well as many of the other countries that have similar labs.
Use case: Request home sampling.
Scope: Web home sampling system.
Level: User goal.
Intention in context: the intention of the patient to request home sampling.
Primary actor: patient.
Stakeholder’s interest:
Patient: to request home sampling.
Dr. Magdy’s laboratory: to serve as many patients as possible.
Minimum guarantees: patient is able to view available time slots.
Success guarantees: the system has received the submitted time slots and submitted test types and was able to store them in the time slots and test requests database.
Trigger: patient requests home sampling.
Pre-condition: Patient has logged in.
Main success scenario:
1. Patient requests home sampling
2. System retrieves appointments
3. System displays available time slots
4. The patient selects desired time slot
5. System reserves the submitted time slot and stores its content in the time slots database and informs patient that his/her time slot is reserved successfully
6. System retrieves available test items
7. System displays available test items
8. Patient selects desired test items
9. System adds the selected test items
10. System computes total test items price
11. System displays the total test types cost and request confirmation from patient
12. Patient confirms on the displayed cost
13. Systems records confirmation and stores the test request details in the test requests database and assign it to patient and adds the total price to patient’s accounts
14. System send to patient a test request confirmation email
Extensions:
(1-4) a. (at any time) the patient cancels the home sampling process.
(1-4) a.1. System loads the website’s homepage; use case ends in failure.
1a. Website is down.
1a.1. System informs patient use case ends in failure.
2a. System unable to generate a list of available time slots.
2a.1. System informs patient use case ends in failure.
4a. Patient does not select a time slot and times out.
4a.1. System asks the user to re-select a time slot; use case continues from where it was interrupted in step.
5a. System is unable to access the time slots database to store the patient’s desired time slot.
5a.1. System informs patient use case ends in failure.
6a. System is unable to generate a list of available test types.
6a.1. System informs patient use case ends in failure.
7a. Patient does not select test type and times out.
7a.1. System asks the user to re-select a test type; use case continues from where it was interrupted in step.
8a. System is unable to access the test requests database to store the patient’s desired time slot.
8a.1. System informs patient use case ends in failure.