I like these ideas.
On 2/27/2012 11:38 PM, Rajib Sengupta wrote:
*
Project 1: Upload and View/Download Image/File in HTMLForm Entry Module
*
Primary mentor N/A
Backup mentor N/A
Assigned to N/A
Background
*
It is important to load images or other files (such as Excel
spreadsheets generated during EBRT - External Beam radiation Therapy
or Brachytherapy based Oncology treatments) with patients clinical record.
Abstract
We are proposing this project so that, the implementers while
developing the HTML Forms using the HTMLForm entry module can provide
a file upload button to the data entry user. Consequently, when the
user load a file/image while doing data entry for an encounter, those
files should be stored in the server so that they are available to be
viewed/downloaded by other users.
Project Champions:
* Implementation: MissionArogya - ArogyaNet
Objectives
1.Tag: Provide a âEURoeTagâEUR?, say âEURoeUpload FileâEUR? or
âEURoebrowseâEUR? in the HTMLFormEntry module to upload file. It will
show up as a button to upload file.
2.Upload: When the data entry user (the clinician), will enter data
for an encounter, they will be provided with this button in the form.
While clicked on that button, it will open a file explorer pop-up
window. The user can go to his/her desktop/network to locate the file
and load it. When the file is loaded it can be stored in the database
or as a file in the server itself.
3.View or Download: In the Encounter lists of the Patient add another
icon next to the âEURoeEditâEUR? and âEURoeViewâEUR? icon as the
âEURoeFile UploadedâEUR? icon. While clicked on that it should open up
another UI (or pop-up) with links to all the files that are attached
to that specific encounter. WHile clicked on that link, either the
file will be opened or can be downloaded.
==========================================================================================================
*
Project 2: Configurable Clinical Summary
*
Primary mentor N/A
Backup mentor N/A
Assigned to N/A
Background
*
During the implementation, the implementation team, which consists of
the Doctors also, soon realized that, due to the flexibility in the
HTMLForms and Concept Dictionary, any type of data can be captured
very effectively using multiple modularized forms. But, as the patient
data entered using multiple forms will span across multiple
encounters, a Consultant Doctor needs to look up each of the forms to
get an idea of the Patients medical condition. The Doctor has only few
minutes to go over each patient record in an already crowded public
health domain. It will increase the Doctors work several fold. As a
result, it seems, currently in several OpenMRS implementations there
is a tendency of creating one long form with multiple sections and
data is entered retroactively for a period of time, so that the
patient record is viewed at once.
Abstract
We are proposing a Patient Clinical Summary Module to be developed
a) To realize the true potential of encounter concept, so that a
Patients medical history is time-stamped and b) the data entry is
easier with multiple form based encounter
As OpenMRS implementation can be very different from one site to
another, so the Patient Clinical Summary View will be different from
one implementation to another. So, it is important that the Clinical
Summary need to be configured based on concept dictionary and
encounters chosen.
Project Champions:
* Implementation: MissionArogya - ArogyaNet
Objectives
1. A Clinical Summary Template function : Users (Admins) should be
able to select concepts to define the template for a clinical
summary. The users should be able to format the template also
(either using HTMLForm or a WYSIWYG editor)
2. Select Encounters and Create the Clinical Summary View/Report:
Users (Doctors) will be finding the patient first. Then they
should be able to select the encounters, from which the Clinical
Summary Template will be populated. It should have a print
function also.
**
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
