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]
