yes, that will be really useful... and if you say it is quite straightforward to implement, then this is awesome!! I thought it will be tough to implement these. Image upload/download, Better skip-logic in HTMLFormEntry and this will really be great...
--- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 29 February 2012 12:02, Darius Jazayeri <[email protected]> wrote: > What I mean is: what if the HTML Form Entry infrastructure were broadened, > or we wrote some similar code from scratch, which was *not* encounter-based, > but let you do something like this: > > <html> > <h1><lookup code="patient.name"/></h1> > > <showIfAny cssClass="alert" calculations="LateCD4,NeedsCXR,FallingWeight"/> > > <div style="float: right; border: 1px black solid"> > Recent Labs > <labResultTable conceptIds="123,234,345" withinDays="180" > maxResults="5"/> > </div> > > Etc. > </html> > > I.e. something "just like HTML Form Entry" (it could even *be* HTML Form > Entry) with an extra set of custom tags, or groovy functions, or whatever, > that provide you some common things you'd want to show on a summary sheet. > (And of course the ability to save that summary definition to the database.) > > I feel like that would be quite straightforward to implement, and provide > a lot of bang-for-the-buck. > > -Darius > > > On Tue, Feb 28, 2012 at 9:16 PM, Saptarshi Purkayastha > <[email protected]>wrote: > >> I think the clinical summary module is useful, but is very hard for >> someone new. >> A WYSIWYG editor for the clinical summary module will be very useful. >> >> With the HTMLFormEntry it means we are able to use only summary from one >> encounter, which is not the case in our requirement >> What we are looking for is creating a summary of multiple encounters and >> showing the summary across a period of time for a patient. A BIRT report is >> fairly useful to do that, but the clinical summary module demo shown by Win >> a few days back was nice... If only it was easier to make those for >> non-developer. >> >> --- >> Regards, >> Saptarshi PURKAYASTHA >> >> My Tech Blog: http://sunnytalkstech.blogspot.com >> You Live by CHOICE, Not by CHANCE >> >> >> >> On 29 February 2012 05:55, Darius Jazayeri <[email protected]>wrote: >> >>> 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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>>> ** >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> **** >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>> >>> >> ------------------------------ >> Click here to >> unsubscribe<[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]
