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.
Design/Requirements
Architecture
The Patient Portal module should create 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
This module provides basic user interfaces such as Patient Dashboard, Restricted User Dashboard, and Administrator Dashboard.
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
PHR Security
PHR authentication and authorization is implemented by PHR security checking at URL Level, Page Level, Controller Level, and Service Level. The Pro & Con of various levels of security are listed as follows:
| PRO | CON | Detail | Assumptions |
Page only security | 1. No Java code change is needed to bring in new modules into PHR application | 1. JSP page change is needed to bring in new modules into PHR application | 1. Add <personalhr:require> and <personalhr:hasPrivilege> tags in each jsp page | 1. Non-PHR pages are sufficiently protected by <openmrs:require> and <openmrs:hasPrivilege> tags |
URL only security | 1. No Java code change is needed to bring in new modules into PHR application | 1. URL privilege mapping is needed for every page and DWR call | 1. Check if URL is allowed for given user in URL filter | 1. PHR users do not have permanent openmrs privileges |
Controller only security | 1. No need to hold temporary privileges for a prolonged time | 1. Java code change is needed to bring in new modules into PHR application | including controllers, servlet, dwr, etc. | 1. Non-PHR pages are sufficiently protected by <openmrs:require> and <openmrs:hasPrivilege> tags |
Service only security | I. Protect the right data at the right time | 1. Java code change is needed to bring in new modules into PHR application and to secure exisitng base OpenMRS services | including PHR specific services and other services provided by base OpenMRS and other dependent-upon modules | 1. Non-PHR pages are sufficiently protected by <openmrs:require> and <openmrs:hasPrivilege> tags |