Stakeholder
Discuss about the Use Case Diagram and Description.
Stakeholder |
Type |
Interest |
Project Manager |
Internal |
Completing the project preventing any challenge A final outcome that meets user requirement |
Project Sponsor |
Internal |
Great function system |
Project Team |
Internal |
A final outcome that meets user requirement |
Project Owner |
Internal |
A system that can support progressive treatment process |
National Government |
External |
Innovative ideas that can implemented country wide |
Patient |
External |
Improved treatment and communication |
Medical Officers |
External |
Collaborating platform |
The questionnaire is designed for specialist.
Question 1: Do you think video conference is good for patient treatment?
Question 2: What is your experience of accessing health care application?
Question 3: Is the healthcare application suitable for suggesting treatments from remote location?
Question 4: Do you want the system to mail you important information?
Question 5: Do prefer collaborative platform?
Question 6: Do you want to text chat with patient?
Question 7: Do you want the system to support file transfer?
Question 8: Do you think, that the system must handle all request as soon as possible?
Question 9: Do you want the system to collaborate with hospitals?
Question 10: Do you think interface must be better than functionality?
Register: The application follows the conventional process of registration. The user input required details and the system stores all the data against individual user. The system waits for admin response and if the admin allows the registration then the system registers the patient and sends an email. The patient, specialist and doctors are the actors of the system. Any of the end user can trigger the registration process without concerning others. It is essential to note that an end-user cannot register into the system if the end-user is already registered into the system. After the registration is complete, the system will provide the auto generated login id and password to the user through email. The user must have access to the registered email so that login id and password can be retrieved. In order to register into the system, the user will enter the required details to fill the registration form and then submit the form. After that the system will in out the data and verify all the inputted details. If the verification is successful, then the user will be registered. The user will see a message on the screen that he/she has been registered and login id and password is sent to their mail.
Chat: The system will have a chat option within the application. The patient can only with chat with the doctors he/she had visited. The patient, specialist and doctors are the actors of the system. The system is the main stakeholder of thus use case. This use case associated with the login use case. It is because, if the user is not logged in, then the system will redirect the user to login page. This implies that in order to chat with the doctor/specialist/patient the user must be logged in. After the chat is complete, the user must rate the chat without that rating, the user will not be able to access other sections of the system. The user will click on the chat option and the application ask for an id. This id is the other user’s id with whom chat will be done. After the id is provided, the system will check whether the id is valid or not. The system will send a chat request to the other user. If the user is available, he will enter into the chat section and start chatting. Only if the user internet connection disrupts or any of the user’s device start malfunctioning, the system will end the chat automatically.
Questionnaire
Update Patient Treatment Record: The specialists and doctors can access the patient treatment record input section. After each session with a patient, the doctor and specialist will input the patient treatment related data. The doctor and specialist are the actors of the system. The system is again the main stakeholder of the system. The doctor or the specialist will have a different section which is only available to them. In order to update a specific patient details, the doctor or specialist must be providing consolation to that patient. The system will not allow any random user to update patient treatment records. After each consultation, the doctor or specialist will fill the patient treatment progress form and save it. The system will take every input from the form and store into database. These data will be accessible by the doctor or specialist that specific patient only.
Video Conference: The patient can chat with the doctors through video conference. This options are not available for every patient. Video conference is another chatting option, supported by the system, but differ from text chatting. In video conference, the system will catch the real time presence of the user through the device camera. This option is not available for every patient as mentioned before, it can be accessed by only those who cannot travel due to illness and for elderlies. The admin will determine which user will get access to this function. The patient will fix a meeting with the doctor or specialist and select remote treatment as visit method. The system will notify both of the participants 10 minutes before scheduled visit. The system will automatically start video conference function, each of the users will accept option to make them visible to each other.
Delete User: The system will have power over all the end-users. As automatic processes require complex technology and lot of money, the deletion of a user will be responsibility of the administrator. Administrator is the only actor of this use case. The admin will open admin porta where all the options will be available. Administrator will enter the patient id to select a specific patient. Then he will click on the delete button. As soon as the delete button is clicked, the system will run server side scripts and delete all the details of the user from the database.
Install Patch: In order to maintain system, the administrator will be responsible for installing patch. The patches will be provided by the hardware manufacturers, software vendors and many more. The administrator will open the boot section of the system. Then a list of options will be shown to the user by the system. The administrator will store the patches into the HDD of the system and locate the patch files from boot section. After that system will automatically install the patches and update the system configuration.
Allow Registration: The administrator will check the user registration details and click on either allow or deny button. There are various predefined conditions based on what the administrator will allow a registration.
Use case components |
Interview session |
|
Use Case name |
Login |
|
Scenario |
For logging into the application, the user has to input the login id and password. In addition with that, the user have to input the four digit number sent to their mail or phone. |
|
Event trigger |
The patient, doctor or specialist want to access the system |
|
Description |
The registered end users will login to the system using the username/email and password. |
|
Related use case |
Registration |
|
Actor |
Patient, Doctor and Specialist |
|
System stakeholder |
System, Patient, specialist and doctors |
|
Pre-condition |
The user must be registered |
|
Post condition |
The user is not deleted by the admin |
|
Flow of the activities |
Actor |
System |
1. the end user open login section 2. input login id and password |
3. system checks user login id and password 4. After successful verification system allows the user to access the system |
|
Expected outcome |
The system server is down |
Alemdar, H., & Ersoy, C. (2010). Wireless sensor networks for healthcare: A survey. Computer networks, 54(15), 2688-2710.
Allaki, D., Dahchour, M., & En-Nouaary, A. (2016, April). A Constraint-based Approach for Checking Vertical Inconsistencies between Class and Sequence UML Diagrams. In ICEIS (1) (pp. 441-447).
Brown, G., Strickland-Munro, J., Kobryn, H., & Moore, S. A. (2017). Mixed methods participatory GIS: An evaluation of the validity of qualitative and quantitative mapping methods. Applied geography, 79, 153-166.
Hu, J., Huang, L., Cao, B., & Chang, X. (2014). Extended DEVSML as a Model Transformation Intermediary to Make UML Diagrams Executable. In SEKE (pp. 314-317).
Kaur, B., & Kaur, E. H. (2015). Clone Detection in UML Sequence Diagrams Using Token Based Approach. International Journal of Advanced Research in Computer Science and Software Engineering, 5(5).
Kermagoret, C., Levrel, H., Carlier, A., & Ponsero, A. (2016). Stakeholder perceptions of offshore wind power: a fuzzy cognitive mapping approach. Society & Natural Resources, 29(8), 916-931.
Ko, J., Lu, C., Srivastava, M. B., Stankovic, J. A., Terzis, A., & Welsh, M. (2010). Wireless sensor networks for healthcare. Proceedings of the IEEE, 98(11), 1947-1960.
Mok, K. Y., Shen, G. Q., & Yang, J. (2015). Stakeholder management studies in mega construction projects: A review and future directions. International Journal of Project Management, 33(2), 446-457.
Wu, Y. L., Chen, X., Wang, W., & Loh, X. J. (2016). Engineering bioresponsive hydrogels toward healthcare applications. Macromolecular Chemistry and Physics, 217(2), 175-188.
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.
f