Understanding The Commonwealth Government ‘My Health Record’ Project

A stakeholder map is a diagram that is used to show where different types of stakeholders lie in terms of power/influence and interest to a project. From a project perspective, a stakeholder is any organization or individual that stands to gain or lose with the success or failure of a project (McDonald, 2017). They are involved directly or indirectly with the project. A stakeholder is used to give a conceptual view of the stakeholder analysis results. For my health record system, there are four types of stakeholders;

• Internal executive stakeholders
• Internal operation stakeholders
• External executive stakeholders
• External operation stakeholders.

The following diagram shows the stakeholder map for my health record system;

 

The stakeholder map has two parameters that determine which quadrant a stakeholder lies in;

• Power/influence- this is the ability of a stakeholders to make decisions that affect the project.
• Interest- this is the level of involvement on the project both during the project development life cycle and after the deployment of the project.

Based on these two parameters, stakeholders for my health record system can be explained as;

• External executive stakeholders- According to the stakeholder map, this type of stakeholders have high power or influence on the project but do not have a lot of interest on the project. For my Health Record system, this stakeholder is the government which is funding the project. They have the power on the project because without the funds to implement the project, the project is not possible. Their interest on the project is low because after funding the project, they are not very involved with the project as that work is given to the project team to handle. External stakeholders expect feedback about the project and consultation during decision making thus the project team should try to improve their level of interest on the project by actively engaging them with what is going on concerning the project.
• Internal executive stakeholders- According to the stakeholder map, internal executive stakeholders have the highest level of interest on the project and the highest influence on how the project is undertaken. For my Health record system, the internal executive stakeholders is the project team that is supposed to manage the project but not the actual development team that will carry out the development of the application. The internal executive stakeholders is the project management team that is in charge of making all decisions concerning the project. They have the highest interest on the project because they are responsible for the success or failure of the project thus they have to be actively involved with all that is going on with the project to ensure that the project is a success.
• Internal operation stakeholders- According to the stakeholder map, the internal operation stakeholders is the development team that will be involved with the actual implementation of the project throughout the software development life cycle. They have a high interest on the project but have low influence or power on the project (Morphy, 2015). They are not involved in decision making but are consulted by the internal executive team before most decisions are made. Their level of interest is high because they know everything about the project.
• External operation stakeholders- According to the stakeholder map in figure 1 above, external operation stakeholders are the target users of the system. They have little or no influence on any decision making that is made by the internal executive team. They have low interest on the project especially before the project is deployed. However, during the requirements engineering phase of the project they must be actively consulted to get their views on the system. The project team should aim to increase their interest on the project as early as possible so that they use the application when it is finally deployed.

Use of questionnaire as a method of requirements gathering is a very effective and easy to method to implement. Analyzing the data after conducting the research is also easy when questionnaires are used. For my health record system, requirements gathering will be done using questionnaires. There are different stakeholders that will be given different questionnaires but for this report I focus on the external executive stakeholders specifically the headspace workers.

My health record system requirements gathering questionnaire designed to gather requirements from headspace workers on how effectively can be stored in one central database to facilitate better treatment for young people experiencing anxiety and depression.

Use case diagrams are used to show interactions of different actors with the system. The interactions happen within a system  boundary (Badgareti, 2009)

Figure 1: My health record system use case diagram

• Manage patient use case- this use case includes add patient, update patient and delete patient. Adding a patient is registering a new patient to the system. Updating a patient is updating details of an existing patient in the system while deleting is removing a patient from the system. This use case is done by headspace employee.
• Record patient story- This use case is done by the headspace employee who is the actor. Adding a patient history is added for a patient who is does not have a story in the system.
• Send patient to doctor- this use case is done by the headspace employee. A headspace worker refers a mental patient to a doctor.
• View patient history- an Ed worker views patient history before treating a patient. This is done to avoid the patient from repeating their story to the ED worker. The ED worker can use the system to access the history of the patient.
• Admit patient- an ED worker admits a patient who is referred by a health space worker. The admit record is related to the referral record done by the headspace worker.
• Update patient history- this is done by a ED worker after treating a patient. The ED worker adds necessary patient history to the record of the patient.
• Discharge patient. An ED worker discharges a patient using this use case. This use case includes sending a notification to the headspace employee informing the headspace worker that the patient has been discharged.

Use case ID	1
Use case Name	Record patient history
Actor	Headspace employee
Success scenario	1. Headspace employee opens record story page 2. System displays record story page 3. Headspace employee selects a patient 4. System fetches details of the patients and checks whether the patient already has a story added to the system 5. System displays add story field. 6. Headspace worker fills the field and presses save. 7. System saves the story under that patient.
Alternative flow	4. System fetches details of the patients and checks whether the patient already has a story added to the system 4.1 system finds patient already has a story        4.2 System displays the story

References

Badgareti. (2009). Software Engineering – Use Case Diagrams / Descriptions. Computer science source. Retrieved 2 May 2018, from https://computersciencesource.wordpress.com/2009/11/22/year-2-software-engineering-use-case-diagrams-descriptions/

McDonald, K. (2017). Stakeholder Map. kbp.media. Retrieved 2 May 2018, from https://www.kbp.media/stakeholder-map/

Morphy, T. (2015). Stakeholder Mapping Stakeholder Analysis, Project Management, templates and advice. Stakeholdermap.com. Retrieved 2 May 2018, from https://www.stakeholdermap.com/stakeholder-analysis.html