Stakeholder Map:
![]()
Figure 1: Stakeholder Map of My Healthcare Application
(Source: Created by Author)
Internal Executive: The project manager, project sponsor and project team will act as the internal executive. The project manager will control the project processes. The sponsor will provide the resources and handle the out scope issues. The team will execute the project activities.
|
Stakeholders (Internal Executives)
|
Interest
|
|
Project Manager
|
Complete system that meets all the requirements of the owner. Project manager is recruited for handling the project management activities properly. The project can be disrupted by the internet quarrels of the team members. The PM is responsible for maintaining proper working environment and resolve the team conflicts. The project manager is also interested in allocating required resources to all the activities. The project manager requires physical meeting, video conference and email for communication purposes. A project manager is expected to deliver the expected outcome with quality within deadline.
|
|
Project Sponsor
|
System that can deliver efficiency and effectivity in business. Project sponsor has more power on the project that project manager. The sponsor provides the required resources like technical, financial, non-technical and many other kinds of resources. The project sponsor is interested in handling the project out-scope challenges and issues. The project must have all the project progress related information. The project sponsor also requires physical meeting, video conference and email for communication purposes. The project sponsor is expected to be supporting the project while it faces many challenges and need stakeholder support. In order to do that the sponsor must have equal knowledge of the project like project manager.
|
|
Project Team Members
|
High quality system is the main interest of the project team members from the system. The team members will be responsible for carrying out the main tasks of the project. The designing team is interested in modeling the proposed system in such a way that it can support the organization objectives. The development or coding team will implement the units. The actual system is developed by the coders.
|
External Executives: Project owner, state government, patients, doctors and medical officers ate the external executives of the project. The project owner is the client. The state government has rules and regulations that a must be followed for system development. Patients, doctors and medical officers are end users of the system.
|
Stakeholders (External Executives)
|
Interest
|
|
Project Owner
|
The project owner needs a system that provide seamless execution of operations. The project owner has the most power over the project. The project owner is responsible for scanting the project and approve additional resources and time. The owner is more interested in the final product that the project itself.
|
|
State Government
|
This stakeholder is interested in a system that enhance lives of the citizens. The government implement the regulations that guide the project and system activities.
|
|
Patient
|
The patients are interested in a system that can provide them access to schedule appointment and see their health details. The patients are responsible for providing feedback after using the system. These feedbacks are used for making changes to the system and make the system as per user requirement.
|
|
Doctors
|
The doctors are needed to have an application that can allow them see patient details and treatment history. The Doctors are also responsible for providing feedback after using the system. These feedbacks are used for making changes to the system and make the system as per user requirement.
|
|
Medical Officers
|
The doctors are needed to have an application that can allow them see patient details and treatment history. The Medical Officers are responsible for providing feedback after using the system. These feedbacks are used for making changes to the system and make the system as per user requirement.
|
Questionnaire:
The questionnaire is made for the doctors. The questionnaire is developed with the purpose of collecting useful information.
Question 1: Do you want a login option in the application?
Question 2: How do like to register into the application?
Question 3: Do you like to communicate with the patient through the application?
Question 4: How often do you think you will access the application?
Question 5: The level of security checking you want in the system?
Question 6: Do you have previous experience in medical application usage?
Question 7: Do you think that system must ask a doctor enter his medical degree proof during registration?
Question 8: Do you want to see the details of the patients?
Question 9: Do you want to see the previous prescriptions of the patient?
Question 10: Do you like to collaborate with other doctors for patient treatment?
Use Case Diagram and Description:
Figure 2: Use Case Diagram
(Source: Created by Author)
Upload test report: The medical officers will upload the test reports of the patient to the system. These reports will be linked to individual patient treatment process. The medical officers are the only actor associated with this use case. The medical officers must have logged in to the system for unloading the test reports. There are two ways a medical officer can upload report, either by enter the raw value or by uploading the softcopy of the report.
Sign Up: The patients will register themselves into the system by providing required information. After the registration is complete, the system will send the password and username to the patient through e-mail. The registration process is for the patients and medical officers. The system can allow a patient or medical officer only after they are registered into the system. The end-users will fill up the registration form and save the details to the system. The system will verify the inputted information and approve their registration request.
Login: The user will login to the system using the username and password provided through the mail. The login is the basic step toward system access approval. The system users provide the username and password during registration process. In order to login to the system, the user must use that user name and password. The system will match the inputted data with existing data. If the data matched, then the user will be allowed to login.
Treatment History: The doctors can see the history of each patient treatment. The users will access the treatment of the patient. The doctors can only see the treatment history of those patients who are vesting him/her. Medical officers are allowed to see all the patient’s medical history. The users must be logged in to the system before requesting a patient’s treatment history. The treatment history will include the impact of a medication on patient, treatment progress, test reports and many more.
|
Use case components
|
Interview session
|
|
Use Case name
|
Appointment Booking
|
|
Scenario
|
The patients will open the app and enter the date of appointment and expertise. The system will provide list of doctors available on that day. The patient will book appointment with the doctor.
|
|
Event trigger
|
Appointment to be scheduled for a patient
|
|
Description
|
The patients will open the app and enter the date of appointment and expertise. The system will provide list of doctors available on that day. The patient will book appointment with the doctor.
|
|
Related use case
|
None
|
|
Actor
|
Patients
|
|
System stakeholder
|
Patients and doctors
|
|
Primary condition
|
The patient is logged in
|
|
Post condition
|
Patient never visited that doctor before
|
|
Flow of the activities
|
Actor
1. Patient will open application
2. Enter date and select expertise
3. Patient enter search button
5. Patient will confirm appointment
|
System
4. System searches database and show the available doctors
6. System sends notification to patent and doctor
|
|
Expected outcome
|
The doctor patient visit limit is reached
|
Bibliography:
Asiedu, K., & Huising, J. (2017). The WASHC project stakeholder mapping & categorisation report.
Brenton, P., & Hoffman, B. (2016). Political economy of regional integration in sub-Saharan Africa.
Charani, E., Castro-Sánchez, E., Moore, L. S., & Holmes, A. (2014). Do smartphone applications in healthcare require a governance and legal framework? It depends on the application!. BMC medicine, 12(1), 29.
Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems analysis and design: An object-oriented approach with UML. John wiley & sons.
Nassif, A. B., Capretz, L. F., & Ho, D. (2016). Enhancing use case points estimation method using soft computing techniques. arXiv preprint arXiv:1612.01078.
Reed, M. S., & Curzon, R. (2015). Stakeholder mapping for the governance of biosecurity: a literature review. Journal of Integrative Environmental Sciences, 12(1), 15-38.
Slabá, M. (2016). Stakeholder profile and stakeholder mapping of SMEs. Littera Scripta, 9(1), 123-139.
Wolters, D., Gerth, C., & Engels, G. (2016). Modeling Cross-Device Systems with Use Case Diagrams. In CAiSE Forum (pp. 89-96).
Yue, T., Briand, L. C., & Labiche, Y. (2015). aToucan: an automated framework to derive UML analysis models from use case models. ACM Transactions on Software Engineering and Methodology (TOSEM), 24(3), 13.
Zhang, F., Cao, J., Khan, S. U., Li, K., & Hwang, K. (2015). A task-level adaptive MapReduce framework for real-time streaming data in healthcare applications. Future Generation Computer Systems, 43, 149-160.
