Personal Health Record Module Enhancement

 Personal Health Record Module Enhancement

Abstract

The aim of this project is to build a Patient portal on top of the core OpenMRS where individual health record is owned and managed by the patient. We consider this project to be in two stages:

Stage 1: A Personal Health Record Module on top of a single OpenMRS install that provides individuals access to their health record

Stage 2: A Personal Health Record portal application on top of multiple openMRS install that provides an aggregated view of the individual health record.

Project Champions

MissionArogya

Objectives

The current PHR module 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.The details are here : https://openmrs.atlassian.net/wiki/display/docs/PHR+Module

We will like to extend and enhance this module to satisfy the goal of stage 1 -

A Personal Health Record Module on top of a single OpenMRS install that provides individuals access to their health record - To be precise, while the clinicians will use the classic OpenMRS to enter clinical data for multiple patients, this module will be used by the patients to access his/her personal health record only.

Section 1: Requirements

Patient Registration feature (Texts in smaller font is available using standard OpenMRS functionality, it is included for understanding of a complete flow)

If the patient visits the Clinic/Hospital as a new patient:

1. The Clinic/Hospital registers the patient using standard OpenMRS process of “Create Person” they should provide the Patient a Unique ID. This process is part of standard OpenMRS and thus outside the scope of this project.

2. The patient will have a link in the login page of OpenMRS to register using this unique id to generate his/her user-id (which can be the unique id also) and password to access the Patient dashboard mentioned below 

If the patient registers before visiting the Clinic/Hospital:

1. The Patient can also request to create his/her account before visiting the clinic, in which case the request will come to a new user request queue. At this step it will be a nice to have feature, if other patient attributes and medical information can be captured from the patient.

2. The admin will validate the identity of the patient, will ensure it is not a duplicate entry, and generate an unique id using standard OpenMRS. The data submitted by patient will be entered as much as possible using standard OpenMRS functionality and HTMLForms. Not part of the scope of this project.

3. Once the patient gets the unique id, the patient can use the same process as above, to generate his/her user-id and password to access the Patient dashboard mentioned below

Design Questions:

1. Can the "First Time User Registration" Process in the current PHR Module be modified/enhanced to fit this requirement?
2. What will be the user-id of the patient? Can it be the generated unique id itself or does it need to be something else? If something else, it will be good to have email as the user id.

(Note: After registration, while the Patient visits the clinic, the patient will provide his/her unique ID (not the userid) to the doctor.  The clinician will open up the patient record using the unique patient id. Doctor/Nurse/Clinician will enter/update patients data using standard OpenMRS functionality and HTMLForms that are outside the scope of this project)

Patient Dashboard showing the Problems, Allergy, Medications and Encounters

1.Patient logs in using the user-id/password.

2.They will directly land in the following patient dashboard (or something similar like this), which shouldn’t have any options of editing*. No Editing is allowed*

Overview: 

Regimen:

Encounters: Clicking on the View of one encounter will open the form that will show the details of the encounters.

Section 2: Nice to Have Requirement (Need to be decided by the Primary Mentor which one can be implemented as part of GSOC)
On top of the above the following features will be really helpful. These features are similar to what is available in the current PHR module for Lance Armstrong Foundation along with some enhancements – Please refer the video for the current features:

http://www.indiana.edu/~video/stream/launchflash.html?folder=techserv&filename=PCT_INTRO.mp4

 1. Patient Clinical Summary Tab - We can start with a static page which will show a predefined summary of the Patient's personal health record. It will be a nice to have feature, if the Patient can decide (configure) which part of his/her medical record he/she wants to see in the summary page

 2. Printout of Patient Medical record. Until, the clinical summary happens, please make sure that the print mechanism is available in the overview, regimens, encounter tabs and in the HTMLForms 

 3. My Journal (to capture the patient’s ongoing recovery by the patient). This feature is already implemented as part of the current PHR module and will not require much change.

 4. My Relationships (to share information). This feature is already implemented as part of the current PHR module and will not require much change. If the country law permits, an enhancement may be done. so that the patients medical record can be send securely (encrypted email) to an external doctor who is not in OpenMRS.

 5. My Follow-Up Care. This feature is already implemented as part of the current PHR module. This will need enhancement with a message module to send text message or email for not only follow-up cares but medications also.

The patient should be able to customize which message he/she like to receive and in what method. The patient may also create message for his/her own benefit.

A simple example case study: A travelling sales person is suffering from chronic severe high blood pressure. He needs to take his blood pressure medications regularly to avoid fatal complications. With a hectic work-schedule, possibilities exist, that the patient may forget to take the medications. A SMS message alert can be configured in ArogyaNet to send automatic daily reminder in his cell phone for his regular medications.

 6. The Side Effects and Communities tabs which are currently available in the current PHR module need to be configurable from the admin tab. That means, these pages will be different for different type of patients (cancer patient vs HIV patient).

 7. It will be ideal, to have some type of clinical decision support embedded in the side effect tab or separately.

A simple example case study: A patient on warfarin, a blood thinner, strained his calf muscle while exercising and wanted to take an over the counter pain-killer. His doctor had mentioned him about adverse effect of certain pain-killer. He types “Advil” into his personal health record list to see if there are any potential interactions with the list of medications in his record. Indeed, taking any Advil (Ibuprufen) would significantly increase his risk for serious bleeding, while Acetaminophen/Paracetamol is safe.

Extra Credit

Resources

Current PHR Module: PHR Module

Demo: http://www.indiana.edu/~video/stream/launchflash.html?folder=techserv&filename=PCT_INTRO.mp4