Page Comparison

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	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.
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	This will be generated based on the treatment history
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	This might be generated based on a logic involving his medications/treatment
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	This will be generated based on a logic involving his medications/treatment
7	Burdette Portal Integration	Pete needs to log into the Burdette portal with the OpenMRS credentials and look up resources there	Must Have	Will be using Burdette portal , will mostly be just providing a page to access Burdette portal in
8	Messaging Function	Pete needs to be able to communicate with his relationships	Must Have	Will act as a client to gmail, most likely will be using messaging module
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	Will be generated base on the patient conditions
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	Will most likely replace the relationship feature
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	Caregivers do not yet have their own profiles.
15	Review patient progress	Dr. 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.
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

Versions Compared

Old Version 2

New Version Current

Key