Patient Portal Module - Personal Cancer Toolkit Project Revamp
What this module does
This module (i.e. Patient Portal) allows you to create a patient controlled health records application. It gives the patient the full control of his/her own health records and other personal information, and enables him/her to share part or all of those information to any one in his/her social network such as a family member, a doctor, or any other caregiver he/she trusts.
Â
How can the Patient control his/her own health records through this module?
Home
This is the main page in the module that has all the options for the patients.
Journals
Journals gives the ability to writes posts and share it with the Doctor/Caregiver helping others better understand their conditions and state of mind.Â
Connections
This allows the person to manage their relationships with Doctors/Caregivers, Family and Friends. The patients can control what level of permission he wants to allow their connections to have over his profile.
Treatments
This has a summary of his general history and all the Cancer treatments he had undergone.
Side EffectsÂ
These are the side effects that the patient might experience due to his conditions and treatments.
Community
This gives the patient details regarding the communities available near him.
Calendar/Followup Care
Messaging
Design/Requirements
Â
# | Title | User Story | Importance | Notes |
---|---|---|---|---|
1 | Write and share a journal entry | Pete is feeling unusually well after chemotherapy. He wants to share his experience so that he can talk about what might be different about his experience today vs. other days. This information might also be nice for his caregivers to hear, so he clues them in by sharing his journal entry with them rather than just himself. | Must have |
|
2 | Create/view Treatment Summary | Pete should be able to add his latest treatment summary from the profile/treatment history page | Must Have | Â |
 3 | Check follow-up appointments | Pete can't remember when he needs to set up his next appointment. The calendar widget helps him keep track of his upcoming appointments. | Must have |
|
4 | Create Relationships | Pete should be able to create a relationship about his family members and providers even if they don't exist in the OpenMRS system | Must Have | Â |
 5 | Lookup communities | A static list of support and educational communities should be accessible by the patient. | Must have |
|
6Â | Check on side effects | Pete needs to look at the list of side effects for a new medication that he was put on. He's been feeling queasy. | Must have |
|
7 | Burdette Portal Integration | Pete needs to log into the Burdette portal with the OpenMRS credentials and look up resources there | Must Have |
|
8 | Messaging Function | Pete needs to be able to communicate with his relationships | Must Have |
|
9 | Single Sign On | OpenMRS requires a creation of a person then creation of a USER, this needs to be combined and as soon as a person is created a user needs to be created. | Next To Must Have -1 | Â |
10 | Healthy Behavior | Pete is suggested with a diet plan so that he can improve his health. | Next To Must Have - 2 |
|
11 | Prevention Reminders | Patients need to get prevention reminders based on surveying their data | Next To Must Have-3 | Â |
12 | Social Network | Patients Connecting through the relationship option before must be able to connect with others in the network without creating the relationship. | Next To Must Have-4 |
|
13 | Highlight side effects | Pete looks at his big list of side effects related to medications and diagnoses and sees that the one that he typed into the finder has been highlighted. | Really nice to have | Â |
14 | Review past user stories | Sam, Pete's caregiver, wants to review her brother's past few months' journal entries. She signs in, clicks on her brother's profile, and reads the last five entries. | Nice to have |
|
15 | Review patient progress | Dr. Martian is curious about her patients' progress. | Really nice to have |
|
16 | Import professional tweets | If a physician user opts in, he can share his tweets with his patients. These tweets might include interesting articles or valuable advice or encouragement. The idea here is that physicians do not have a lot of time to check several social networks, so the more that we can integrate this one with existing ones, the better. | Nice to have | Â |
Â
Architecture
The PHR module defines the following (static) OpenMRS roles / privileges:
PHR Patient / PHR Single Patient Access
PHR Restricted User / PHR Restricted Patient Access
PHR Administrator / PHR All Patients Access
 , and is composed of the following functional components:
PHR Patient Registration
PHR Invited Self Registration
PHR Relationship & Sharing
PHR Authentication & Authorization
PHR module provides basic user interfaces such as PHR Patient Dashboard, PHR Restricted User Dashboard, and PHR Administrator Dashboard, which can be extended by other modules to create a fully blown PHR application.Â
Sharing Process
When Patient adds a new relationship by entering name, relationship type, email address and sharing type and submitting,
System creates a new record in phr_sharing_token table
System sends an email to the authorized person containing a link to OpenMRS PHR Login window and the sharing token string
When the targeted Person receives the invitation and clicks the URL with Sharing Token embedded to access the information shared by the Patient
System pops up a login window (embedded with Sharing Token)
When the targeted Person (Sharee) clicks Sign Up button on the login window
System pops up a self registration window not pre-populated with Patient entered info (still embedded with Sharing Token)
The Person entered his personal information that can be different from Patient entered information and provides username and password to be created
System creates a new OpenMRS Person object and a new OpenMRS User account with PHR Restricted User role
The Sharing Token record is updated with the proper share_activate_date, and relation_person_id
Generate warning if user entered name or email address do not match those stored in the phr_sharing_token table
When the targeted Person (Sharee) clicks Login button after supplying his username and password created before on the login window
The Sharing Token embedded (if there is one) is checked against phr_sharing_table and corresponding record is updated if and only if relation_person_id is null.
When the targeted Person clicks the Person link in his relationship list after logging in
To display the relationship list, System looks up the phr_sharing_token table with the current user's Person ID to find all of the patients he has relationship with
After clicking the Patient link in his relationship list, System checks if the current user has a Data sharing Relationship with that clicked Patient by looking up the Relationship table with the clicked person's Person ID and the current user's Person ID and all of its matched Person ID's found in the person_match tableÂ