Sounds good to me. (My plan had been to add a separate page that would list all the patient's encounters, but do so via server-side paging. And we'd link to this from the encounters tab as "view all encounters". But your proposed fix is quicker, and fine.)
-Darius On Tue, Oct 25, 2011 at 8:13 AM, Michael Seaton <[email protected]> wrote: > ** > I agree with Christian. We should, at minimum, let this be configurable by > the end user. I've created a ticket to apply this fix, which will introduce > a global property allowing for the number of encounters on the patient > dashboard to be limited to a configurable number, defaulting to null so that > the default behavior will be to not limit the encounters at all. > > https://tickets.openmrs.org/browse/TRUNK-2783 > > For the rare implementations that have patients with 30,000 encounters, > they can set the global property to whatever number they like and see the > same behavior as now. > > I'll plan to do this and backport it back to 1.7.x unless there are strong > objections... > > Mike > > On Oct 23, 2011, at 11:47 PM, Christian Neumann wrote: > > > OK. So this seems intentional. But I feel like I don't understand all the > reasoning behind it. > > Here are my current thoughts: > - If OpenMRS hides older data from the user, it should be obvious to the > user. The only indication is the little message at the bottom "Showing 1 to > 20 out of 145 entries". > - For us using the workaround 'Administration - Manage Encounters' almost > equals "old encounter data lost". I don't want to have the average user > dealing with the Admin page at all. > - The paging seems like a client-side paging (as opposed to load the page on > the server and only send the chunks of data). So in my understanding this > paging is only a 'visual' effect without any impact on performance (ignoring > rendering time of the browser). If this is the case, then the paging seems a > little bit redundant. > - I see the point about a patient with 40000+ encounters. But this is either > a very sick patient (...) or a clear test case for development. Not sure if > such a test case ('corner case') should dictate behavior for 'real world' > patients. But I understand that 100 would be as an arbitrary number as 150 or > 500. > > I assume that a 'real (server-side) paging' is difficult/impossible (not sure > if I've seen this anywhere else in OpenMRS). > > Darius, how would your 'hacky encounter search' look like? > > Ideally the use of OpenMRS shouldn't differ whether a patient has 99 or 101 > encounters. Is there a way to at least make this limit configurable (so that > I can choose my own arbitrary maximum)? > > christian > > On Oct 22, 2011, at 3:42 AM, James Arbaugh wrote: > > > Yes, this change was intentional; loading the patient dashboard took WAY > too long; especially for patients that are used regularly. As a work > around for patients with more than 100 encounters, you can search for > encounters under Administration, Manage Encounters. This even works for > the unmanageable cases, like my generic patient with 41093 encounters. > > Thanks, > James > > -----Original Message----- > From: [email protected] [mailto:[email protected] > <[email protected]>] On > Behalf Of Christian Neumann > Sent: Friday, October 21, 2011 8:58 AM > To: [email protected] > Subject: [OPENMRS-IMPLEMENTERS] Patients with more than 100 encounters > > Hi, > > Is it intentional that OpenMRS 1.7.2 only shows the most recent 100 > encounters per patient? > > Using OpenMRS at the Point-of-Care for a couple of years leads to > several cases where we have more than this. But these encounters are no > longer accessible. > > Cheers, > christian > _________________________________________ > > To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail > to [email protected] with "SIGNOFF openmrs-implement-l" in the > body (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l > <[email protected]?body=SIGNOFF%20openmrs-implement-l>] > _________________________________________ > > To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to > [email protected] with "SIGNOFF openmrs-implement-l" in the body > (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l > <[email protected]?body=SIGNOFF%20openmrs-implement-l>] > > _________________________________________ > > To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to > [email protected] with "SIGNOFF openmrs-implement-l" in the body > (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l > <[email protected]?body=SIGNOFF%20openmrs-implement-l>] > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
