This is committed to trunk with a post-commit review pending. Once
approved, I'll backport it to 1.8.x and 1.7.x.
Mike
On 10/25/2011 11:32 AM, Darius Jazayeri wrote:
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]
<mailto:[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
<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]>
[mailto:[email protected]] On
Behalf Of Christian Neumann
Sent: Friday, October 21, 2011 8:58 AM
To:[email protected]
<mailto:[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
[email protected] <mailto:[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]
_________________________________________
To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail
[email protected] <mailto:[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]
_________________________________________
To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail
[email protected] <mailto:[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]
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l>
from OpenMRS Implementers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[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]
