Mike/Darius, I am very new to openMRS so please correct me if I am wrong. But , the other benefit that I see with the Reporting module approach is you can query the database with different parameters for a single patient or for a group of patient. On the other hand, the htmlformentry approach, though may have certain constrain, but may be a quick development option and thus both of them can run in parrallel and then can compliment each other. I will love to join in the requirement gathering session for this - I try to understand the design etc, but am not a developer in any stretch :-) but have few years of experience working as a healthinformatics consultant to optimize clinical workflows etc - So any help that i can provide, i am available .. Thanks, Rajib
________________________________ From: Michael Seaton <[email protected]> To: [email protected] Sent: Wednesday, February 29, 2012 9:37 AM Subject: Re: [OPENMRS-DEV] Couple of GSOC 2012 Project ideas Darius,I have been thinking for a while now that the reporting module is also a good candidate for supporting a more easily configurable clinical summary. eg. Create a Report containing whatever datasets you need, then use an HTML / Excel / PDF template renderer to produce either a single patient summary or collection of patient summaries.Win and I have had a few conversations about prototyping a next version of the clinical summary module that would sit on top of reporting and use it's evaluation and rendering capabilities to do it's thing, rather than re-implement them, but we haven't done it yet.This could complement and htmlformentry approach for sure - the benefit of reporting is that you are not limited to an html output style, and you have all of the data that the reporting module can produce accessible to you - but I also like the htmlformentry idea. We should discuss a bit if either/both these ideas have legs to implement independently, or if we want to come up with a more unified approach...MikeOn 02/29/2012 01:32 AM, Darius Jazayeri 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 PURKAYASTHAMy Tech Blog: >>http://sunnytalkstech.blogspot.comYou 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 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 list > >________________________________ >Click here to unsubscribe from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe 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]
