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?


This is the main page in the module that has all the options for the patients.


Journals gives the ability to writes posts and share it with the Doctor/Caregiver helping others better understand their conditions and state of mind. 


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.


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.


This gives the patient details regarding the communities available near him.

Calendar/Followup Care




User Story
1Write and share a journal entryPete 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
  • We're assuming that this patient has multiple people in his network. If he didn't, it would only be shared with himself.
  • Patient must be able to share based the posts to different layers of members.
2Create/view Treatment SummaryPete should be able to add his latest treatment summary from the profile/treatment history pageMust Have


 3Check follow-up appointmentsPete 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
  •  This will be generated based on the treatment history
4Create RelationshipsPete should be able to create a relationship about his family members and providers even if they don't exist in the OpenMRS systemMust Have 
 5Lookup communitiesA static list of support and educational communities should be accessible by the patient.Must have
  • This might be generated based on a logic involving his medications/treatment
Check on side effectsPete 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
  •  This will be generated based on a logic involving his medications/treatment
7Burdette Portal IntegrationPete needs to log into the Burdette portal with the OpenMRS credentials and look up resources thereMust Have
  • Will be using Burdette portal , will mostly be just providing a page to access Burdette portal in
8Messaging FunctionPete needs to be able to communicate with his relationshipsMust Have
  • Will act as a client to gmail, most likely will be using messaging module
9Single Sign OnOpenMRS 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 
10Healthy BehaviorPete is suggested with a diet plan so that he can improve his health.Next To Must Have - 2
  • Will be generated base on the patient conditions
11Prevention RemindersPatients need to get prevention reminders based on surveying their dataNext To Must Have-3 
12Social NetworkPatients 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
  • Will most likely replace the relationship feature
13Highlight side effectsPete 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 
14Review past user storiesSam, 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
  • Caregivers do not yet have their own profiles.
15Review patient progressDr. Martian is curious about her patients' progress.Really nice to have
  • Currently physicians do not have their own profiles, which makes reviewing their patients' progress difficult.
16Import professional tweetsIf 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 



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:

  1. PHR Patient Registration
  2. PHR Invited Self Registration
  3. PHR Relationship & Sharing
  4. 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