Stakeholder Map
Figure 1: Mapping of Headspace Project Stakeholders
(Source: Created by Author)
Patient case Record: The framework will have the capacity to store the patient story inside the cloud database. This story will be utilized for the inside reason as it were. A portion of the approved staff of headspace can get to the account of the patient.
Distribution of patient story: The patient story will be shared among the staff of headspace. The headspace will permit a portion of the specific specialists like general expert, clinician and couple of other to see the patient story. The patient story can be checked whether just the patient visit them.
Data Flow: The stored in the database rather will be sent to the authorized staff of headspace. The case manager will include all the data assembled from the patient into the story segment of the framework. The framework can’t naturally enter information from different gadgets. Just approved faculty can enter the information into tolerant story board.
Case worker: The case worker are the staff in Headspace who can store the patient information into the database.
General practitioner: General practitioner will direct meeting the patient to accumulate required information with respect to quiet condition. Notwithstanding that, the partner will utilize that information to treat persistent.
Psychiatrist: Psychiatrist will lead meeting the patient to accumulate required information with respect to understanding condition. Notwithstanding that, the partner will utilize that information to treat quiet.
Psychologist: Psychologist will direct meeting the patient to assemble required information with respect to quiet condition. Notwithstanding that, the partner will utilize that information to treat tolerant.
Cloud data store: The information will be assembled from the machines introduced in Headspace and diverted to cloud. The lump database will hold the information.
Cloud application: The applications that the Headspace laborers will be utilizing will be introduced in the cloud framework.
SLA: Service level agreement is the evidence of rundown of shared acknowledgments with respect to administrations that the cloud merchant will give to Headspace. It holds the installment strategies too.
Legislation: The framework execution must be done through after the nearby and national principles the NSW and Australia separately.
System Analyst: The framework examiners is the key of building up the framework in Headspace.
Government: The administration will be controlling the framework advancement in a roundabout way through the IT related standards and enactment.
Cloud vendor: The cloud vendor will be giving the cloud related administrations to Headspace. It is the outsider specialist co-op.
Questionnaire for patient or their relative are as following.
- How the framework will have the capacity to help you? As you would see it.
- Would you like to enlist objection into the framework?
- What different highlights you need the framework to have?
- What capacities do you need the framework to have?
- What sort of data you need to share?
- What number of ways would you like to speak with the people in Headspace?
- Would you like to offer positioning to the laborers who goes over you?
- Should the framework store your story?
The questionnaire for case worker are as following.
- Do you need the framework to access to any account of the patient?
- How would you need the framework to enter information from you?
- For how long the framework should store a story?
Figure 2: The Use Case Diagram of Headspace System
(Source: Created by Author)
Use case Name |
Input Patient Story |
Description |
A patient story will be inputted into the database |
Actor(s) |
Case worker |
Related use case(s) |
None |
Stakeholder(s) |
Case worker, psychologist, general practitioner, psychiatrist and cloud vendor |
Precondition |
The patient should be current one |
Post condition |
Successfully recorded the patient story is |
Exception(s) |
The story is not recorded within the cloud data store |
Use case Name |
Patient Test Report |
Description |
The patient reports will be further assisting in understanding the patient condition. The staff of headspace will store the reports |
Actor(s) |
Case worker, psychologist, general practitioner and psychiatrist |
Related use case(s) |
None |
Stakeholder(s) |
Case worker, psychologist, general practitioner, psychiatrist and administrator |
Precondition |
The report must be valid |
Post condition |
The report is registered |
Exception(s) |
The report is perfect but system does not recognize the id |
Use case Name |
Register |
Description |
The user need to get enlisted so as to utilize the functionalities of the framework. The cloud seller will make client id and secret word for the clients through enlisting them into the framework. |
Actor(s) |
Case worker, psychologist, psychiatrist and general practitioner |
Related use case(s) |
Login |
Stakeholder(s) |
Case worker, administrator, general practitioner, psychiatrist and psychologist |
Precondition |
The client must not be enrolled as of now |
Post condition |
The framework has enrolled the users |
Exception(s) |
The framework is not associated with database legitimately |
Use case Name |
Login |
Description |
The user must utilize the client id and watchword made amid enlistment for login to the framework |
Actor(s) |
Case worker, general practitioner, psychologist and psychiatrist |
Related use case(s) |
Register |
Stakeholder(s) |
Case worker, general practitioner, psychologist and psychiatrist and administrator |
Precondition |
The clients must be enrolled to the framework |
Post condition |
The framework has permitted to login the clients |
Exception(s) |
The framework is not associated with database appropriately |
Fully described use case description:
Name of the use case |
Access Story |
|
Scenario |
The patient story that has been recorded by case worker is now accessible by authorized personnel of headspace |
|
Trigger Event |
Providing access to patient story |
|
Description |
Each of the on-screen characters in the utilization case outline must have the capacity to get to the stories that has been put away in the database |
|
Actors |
General practitioner, psychologist and psychiatrist |
|
Related use case |
None |
|
Stakeholders |
General practitioner, psychiatrist, psychologist and cloud vendor |
|
Preconditions |
The staff must have approval |
|
Post conditions |
The framework has enabled access to the patient story |
|
Flow of activities |
Actor |
System |
The users will request for a particular patient story through patient name |
The system will check if ay story against that patient is available r not |
|
The system will check the users authentication |
||
If everything is alright then the system will allow access to the story |
||
The user access the patient story |
||
Exemption conditions |
The patient story is ruined |
‘Boulos, M. N. K., Brewer, A. C., Karimkhani, C., Buller, D. B., & Dellavalle, R. P. (2014). Mobile medical and health apps: state of the art, concerns, regulatory control and certification. Online journal of public health informatics, 5(3).
Kerns, J. W., Krist, A. H., Longo, D. R., Kuzel, A. J., & Woolf, S. H. (2013). How patients want to engage with their personal health record: a qualitative study. BMJ open, 3(7), e002931.
Li, H., Gupta, A., Zhang, J., & Sarathy, R. (2014). Examining the decision to use standalone personal health record systems as a trust-enabled fair social contract. Decision Support Systems, 57, 376-386.
Nazi, K. M., Turvey, C. L., Klein, D. M., Hogan, T. P., & Woods, S. S. (2014). VA OpenNotes: exploring the experiences of early patient adopters with access to clinical notes. Journal of the American Medical Informatics Association, amiajnl-2014.
Pavlik, V., Brown, A. E., Nash, S., & Gossey, J. T. (2014). Association of patient recall, satisfaction, and adherence to content of an electronic health record (EHR)–generated after visit summary: a randomized clinical trial. The Journal of the American Board of Family Medicine, 27(2), 209-218.
Pearce, C., & Bainbridge, M. (2014). A personally controlled electronic health record for Australia. Journal of the American Medical Informatics Association, 21(4), 707-713.
Pearl, R. (2014). Kaiser Permanente Northern California: current experiences with internet, mobile, and video technologies. Health Affairs, 33(2), 251-257.
Shortliffe, E. H., & Cimino, J. J. (Eds.). (2013). Biomedical informatics: computer applications in health care and biomedicine. Springer Science & Business Media.
Shortliffe, E. H., & Cimino, J. J. (Eds.). (2013). Biomedical informatics: computer applications in health care and biomedicine. Springer Science & Business Media.
Singh, H., Spitzmueller, C., Petersen, N. J., Sawhney, M. K., Smith, M. W., Murphy, D. R., … & Sittig, D. F. (2013). Primary care practitioners’ views on test result management in EHR-enabled health systems: a national survey. Journal of the American Medical Informatics Association, 20(4), 727-735.
Ventola, C. L. (2014). Mobile devices and apps for health care professionals: uses and benefits. PT, 39(5), 356-364.
Ventola, C. L. (2014). Mobile devices and apps for health care professionals: uses and benefits. PT, 39(5), 356-364.
Waterson, P. (2014). Health information technology and sociotechnical systems: A progress report on recent developments within the UK National Health Service (NHS). Applied Ergonomics, 45(2), 150-161.
Jacobs, M. L., Clawson, J., & Mynatt, E. D. (2014, April). My journey compass: a preliminary investigation of a mobile tool for cancer patients. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 663-672). ACM.