Darius, For start, I think HTML form entry is a good place to start. A WYSIWYG or a wizard like tool will be the ultimate goal. A way to tackle this requirements, can be, to use reporting tools which provides this type of wizard like tools out-of-the-box. As par my knowledge, there are at-least three good open-source BIRT (which I am assuming openMRS is already using), Pentaho and jasper. I haven't looked at the openMRS BIRT report module - But, planning to take a look at it. Thanks, Rajib
________________________________ From: Darius Jazayeri <[email protected]> To: [email protected] Sent: Tuesday, February 28, 2012 7:25 PM Subject: Re: [OPENMRS-DEV] Couple of GSOC 2012 Project ideas Hi Rajib, For project #2, are you thinking of something that assumes a similar level of knowledge to HTML Form Entry? For example, if HTML Form Entry had 10 new tags that let you do things like display a table of lab results, would that be enough? Or are you envisioning something with a WYSIWYG editor, or at least some wizard-like tool to let non-html-aware clinicians create their own summaries? -Darius On Tue, Feb 28, 2012 at 4:06 PM, Rajib Sengupta <[email protected]> wrote: Ben, > >I have created the Project 1 :Upload and View/Download Image/File in HTMLForm >Entry Module > >For project 2: Configurable Clinical Summart >I briefly looked at the clinicalsummary and the patientsummary module. > >We are really looking for something more then this basic functionality of >printing the patient summary. You are right that, it is probably possible to >create HTMLForm to do this. But this will require significant HTML/Javascript >technical knowledge - and still I believe it will not be possible using the >existing HTMLForm tags. > >This requirement primarily started with the idea that the doctor >(non-technical users) can decide what data of patients (in openMRS >termionology which concepts in specific encounter) will show up in the patient >summary. It will be ideal, if one doctor can configure this and save/share it >as a template which can be used by other doctors. In several proprietary EMR >software, that I have worked on earlier, I have seen these type of features. I >can write up a more detailed requirement, when this project is assigned. > >I will create the project 2 also, so that we don't lose sight of it. It may >not get assigned as part of GSOC 2012. Let me know if you think otherwise. > >Thanks, >Rajib > >From: Ben Wolfe <[email protected]> >To: [email protected] >Sent: Tuesday, February 28, 2012 8:34 AM >Subject: Re: [OPENMRS-DEV] Couple of GSOC 2012 Project ideas > >That first one sounds like a good project. Can you create a new page in the >Unassigned Projects section here? http://projects.openmrs.org/The second one >may or may not be covered already. We have a clinicalsummary module and a >patientsummary module, both similar, and perhaps a few other custom ones >already. You might even be able to just create an htmlform that just does >lookup display of data. The only caveat is that you want the user to choose >which encounters should be used to populate the data. Is that really what you >want, or do you want to choose from the patient's entire record?Ben >On Tue, Feb 28, 2012 at 12:05 AM, Robby O'Connor <[email protected]> >wrote: >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 “Tag†, say “Upload File†or “browse†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 “Edit†and “View†icon as the “File Uploaded†>>>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 encounterAs 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 from OpenMRS Developers' mailing list >>Click here to unsubscribe from OpenMRS Developers' mailing list >Click here to unsubscribe from OpenMRS Developers' mailing list > >________________________________ >Click here to unsubscribe from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe from OpenMRS Developers' mailing lis _________________________________________ 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]
