Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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:

  1. PHR Patient Registration
  2. PHR Invited Self Registration
  3. PHR Relationship & Sharing
  4. 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 
2. Unable to check privilege on direct DWR or Web Service calls 
3. Unable to check privilege on base OpenMRS domain access

1. Add <personalhr:require> and <personalhr:hasPrivilege> tags in each jsp page 
2. Map privilege text (registered or not) to PHR dynamic role(s)

1. Non-PHR pages are sufficiently protected by <openmrs:require> and <openmrs:hasPrivilege> tags 
2. PHR users do not have permanent openmrs privileges 
3. PHR users are given temporary openmrs privileges once logged in

URL only security

1. No Java code change is needed to bring in new modules into PHR application 
2. No JSP page change is needed to bring in new modules into PHR application

1. URL privilege mapping is needed for every page and DWR call 
1. Data identification not always possible (e.g. if naming convention not followed) 
2. Unable to check the privilege on embeded JSP script 
3. Very hard to check the privilege on a POST request, DWR, or Web Service call

1. Check if URL is allowed for given user in URL filter 
2. Check if data (as identified by patientId, personId, encounterId, etc) is allowed for given user in URL filter 
3. Map URL to PHR dynamic role(s) 
4. DWR filter is needed to check if DWR call is allowed?

1. PHR users do not have permanent openmrs privileges 
2. PHR users are given temporary openmrs privileges once logged in

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 
2. PHR users do not have permanent openmrs privileges 
3. PHR users are given temporary openmrs privileges when making openmrs requests from PHR compliant functions and give away those privileges when finishing the requests

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 
2. PHR users do not have permanent openmrs privileges 
3. PHR users are given temporary openmrs privileges once logged in

  • No labels