If reports are only the problem, our solution was just to filter out the test patients through sql and plug it into a jasper report. If the jasper report module in openmrs does not work, you could install a jasper server.
On Thu, Apr 26, 2012 at 10:58 PM, Joaquín Blaya < [email protected]> wrote: > Yes, agreed for them to show up in the patient search and not in the > reporting module. I'm going to create a parallel ticket for reporting > compatibility and hopefully we'll replicate the solution from the reporting > module once it's done. > > > Joaquín > ___________________________________________________________________ > Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> > Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/> > Moderador, GHDOnline.org <http://www.ghdonline.org/> > > > On Wed, Apr 25, 2012 at 5:10 PM, Burke Mamlin <[email protected]>wrote: > >> You actually want test patients/users to show up in searches when you're >> looking for them. Agreed that addressing this in reporting (the ticket >> Darius mentioned) is the first step. >> >> -Burke >> >> >> On Wed, Apr 25, 2012 at 12:20 PM, Darius Jazayeri < >> [email protected]> wrote: >> >>> Joaquin, >>> >>> There's a reporting module ticket about this: >>> https://tickets.openmrs.org/browse/REPORT-143 >>> >>> You should vote on it if interested. (Though I guess you're using >>> reporting-compatibility.) >>> >>> -Darius >>> >>> >>> On Wed, Apr 25, 2012 at 8:57 AM, Joaquín Blaya < >>> [email protected]> wrote: >>> >>>> Thanks Burke. >>>> >>>> I was actually hoping for an internal OpenMRS way to create these test >>>> patients which would automatically not include them in any reports or >>>> patient search, rather than having to include in every search the statement >>>> of "not a test patient" >>>> >>>> Does that make sense? >>>> >>>> >>>> Joaquín >>>> ___________________________________________________________________ >>>> Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> >>>> Research Fellow, Escuela de Medicina de Harvard<http://hms.harvard.edu/> >>>> Moderador, GHDOnline.org <http://www.ghdonline.org/> >>>> >>>> >>>> On Wed, Apr 25, 2012 at 10:03 AM, Burke Mamlin <[email protected] >>>> > wrote: >>>> >>>>> This is more of a social issue than a technical one – i.e., training >>>>> anyone who can create patients in the system that they should never create >>>>> test patients on their own; rather, follow an SOP that goes through a >>>>> single person/committee when/if they believe that a new test patient/user >>>>> is needed. In the vast majority of cases, you can get by with a handful >>>>> of >>>>> test patients & users (e.g., 1-10 fake patients, depending on the size of >>>>> your implementation and a fake user for each organizational role you need >>>>> to test). It helps to have them readily identifiable (e.g., using the >>>>> 9-1, >>>>> 99-2, 999-3, … identifier pattern or something similar and ensuring that >>>>> their names are obviously fake). Finally, making it clear to everyone who >>>>> the test patients/users are & how/when to use them. You can, of course, >>>>> restrict access to test user accounts by restricting access to their >>>>> password. For reporting/filtering needs, you could follow AMPATH's >>>>> example >>>>> of creating a boolean person attribute like "Test or Fake Patient" and >>>>> making sure it's set to true for these patients. You could then create a >>>>> cohort from this list. >>>>> >>>>> -Burke >>>>> >>>>> >>>>> On Wed, Apr 25, 2012 at 8:15 AM, Joaquín Blaya < >>>>> [email protected]> wrote: >>>>> >>>>>> A bit late on this, but for us it's important to have the test >>>>>> patients in the production server because we try to have as little >>>>>> training >>>>>> required, so it's much easier to have a single URL with a single user >>>>>> than >>>>>> having separate training and production servers. This is especially true >>>>>> since we are not working with OpenMRS as an EMR, but rather as a way to >>>>>> view data obtained from different mobile systems. >>>>>> >>>>>> Burke how can we do your recommendations for being able to enter test >>>>>> patients, should I create tickets in JIRA for this? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Joaquín >>>>>> ___________________________________________________________________ >>>>>> Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> >>>>>> Research Fellow, Escuela de Medicina de Harvard<http://hms.harvard.edu/> >>>>>> Moderador, GHDOnline.org <http://www.ghdonline.org/> >>>>>> >>>>>> >>>>>> On Fri, Mar 30, 2012 at 11:11 AM, Friedman, Roger (CDC/CGH/DGHA) >>>>>> (CTR) <[email protected]> wrote: >>>>>> >>>>>>> Burke --**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> It's a reality only because there is no system admin function >>>>>>> separate from the developer/implementer function so there is no one to >>>>>>> stop >>>>>>> it. In the big shops where I have worked, there are separate >>>>>>> development, >>>>>>> training, production and in some cases staging instances. No developer >>>>>>> would ever be given access to the production DB (except as a normal >>>>>>> user, >>>>>>> such as a time and attendance system).**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> We get frequent questions here on how to run multiple instances of >>>>>>> OpenMRS under Tomcat, and during demos I've seen some of the core >>>>>>> developers running multiple instances of OpenMRS on their machines. >>>>>>> That >>>>>>> is certainly one solution to the testing/training DB issue, and if there >>>>>>> are issues of file placement and naming or environment variables that >>>>>>> inhibit the ability to run multiple instances on the same machine, we >>>>>>> should correct them. In the DHIS2 installation I worked on in Ghana, we >>>>>>> set up separate training and production instances.**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> However, the new tools seem to make it so easy to do the right >>>>>>> thing, we should stop doing the wrong thing. Then it won't be reality. >>>>>>> **** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> *From:* [email protected] [mailto:[email protected]] *On >>>>>>> Behalf Of *Burke Mamlin >>>>>>> *Sent:* Thursday, March 29, 2012 5:08 PM >>>>>>> >>>>>>> *To:* [email protected] >>>>>>> *Subject:* Re: [OPENMRS-IMPLEMENTERS] Labeling patients as test in >>>>>>> a production instance of OpenMRS**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Roger,**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Whether or not it's good practice, it's reality. Test patients are >>>>>>> common within production systems for … er … testing (surprise!), >>>>>>> training, >>>>>>> troubleshooting, demonstrating, etc. It's generally only an issue when >>>>>>> building cohorts for reporting/research. We just need those tools have >>>>>>> an >>>>>>> easy way to recognize & filter out test patients (and anyone pulling >>>>>>> data >>>>>>> out directly via SQL would need the list of test patients too, but >>>>>>> that's >>>>>>> common practice).**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Pragmatically speaking, best practice, is to moderate the creation >>>>>>> of test patients in order to keep the list from continually growing and >>>>>>> to >>>>>>> make the patients easily recognized (e.g., with names like "TEST >>>>>>> PATIENT"). >>>>>>> At Regenstrief, we've used the identifiers 9-1, 99-2, 999-3, etc. for >>>>>>> test >>>>>>> patients because they're easy to remember (figuring out the check digit >>>>>>> is >>>>>>> easy) and easy to recognize.**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Rather than having "test" status permeate the API like >>>>>>> voided/retired, we could probably get what we need with two small >>>>>>> changes that reporting & related tools could be refactored to use: (1) >>>>>>> something like a CohortService.*getTestPatients()* method in the >>>>>>> core API and (2) a utility function to remove test patients from a >>>>>>> Cohort . >>>>>>> **** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Cheers,**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> -Burke**** >>>>>>> >>>>>>> On Thu, Mar 29, 2012 at 4:22 PM, Friedman, Roger (CDC/CGH/DGHA) >>>>>>> (CTR) <[email protected]> wrote:**** >>>>>>> >>>>>>> With the tools we now have (h2 DB, testing DB builder), does it >>>>>>> really make sense to put test data in a production server? It's >>>>>>> certainly >>>>>>> not best practice.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> *From:* [email protected] [mailto:[email protected]] *On >>>>>>> Behalf Of *Michael Seaton >>>>>>> *Sent:* Wednesday, March 28, 2012 10:06 PM >>>>>>> *To:* [email protected] >>>>>>> *Subject:* Re: [OPENMRS-IMPLEMENTERS] Labeling patients as test in >>>>>>> a production instance of OpenMRS**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> There is a pending ticket in the reporting module (REPORT-143 - Add >>>>>>> option to exclude Test/Fake Patients from running >>>>>>> queries/reports<https://tickets.openmrs.org/browse/REPORT-143>) >>>>>>> for supporting this in the reporting module. >>>>>>> >>>>>>> The planned design is to allow for a saved cohort definition to >>>>>>> represent the cohort of test patients (this allows for test patients to >>>>>>> be >>>>>>> defined as a given implementation wants). Then, the reporting module >>>>>>> would >>>>>>> exclude these patients from any query / report that it produces. >>>>>>> >>>>>>> That being said, I wouldn't be at all opposed to some sort of "test" >>>>>>> column on the person table... >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> On 03/28/2012 09:35 PM, Burke Mamlin wrote: **** >>>>>>> >>>>>>> This has come up before. While I can imagine a module trying to >>>>>>> make test patients behave as if they're voided, we should probably make >>>>>>> this a core feature (marking persons/patients as test). As Ada points >>>>>>> out, >>>>>>> a person attribute can serve very well as a way of tagging test patients >>>>>>> for exclusion from reports. **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -Burke**** >>>>>>> >>>>>>> On Wed, Mar 28, 2012 at 9:13 PM, Yeung, Ada K. <[email protected]> >>>>>>> wrote:**** >>>>>>> >>>>>>> AMPATH creates a person_attribute_type of test patient. Whenever we >>>>>>> create new test patients, we tick the test patient >>>>>>> person_attribute_type on >>>>>>> the dashboard. When it’s time to generate reports or prepare datasets >>>>>>> for >>>>>>> research studies, we can exclude those test patients easily.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -ada**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> *From:* [email protected] [mailto:[email protected]] *On >>>>>>> Behalf Of *Joaquín Blaya >>>>>>> *Sent:* Wednesday, March 28, 2012 6:16 PM >>>>>>> *To:* [email protected] >>>>>>> *Subject:* [OPENMRS-IMPLEMENTERS] Labeling patients as test in a >>>>>>> production instance of OpenMRS**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> Hi,**** >>>>>>> >>>>>>> Is there a way to have test patients in a production version of >>>>>>> OpenMRS that allows them not to be counted in statistics e.g. some kind >>>>>>> of >>>>>>> label? **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> The idea is that in a production server you can have a handful of >>>>>>> test patients and a test form so that when people start to learn it they >>>>>>> can use those.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Joaquín >>>>>>> ___________________________________________________________________ >>>>>>> Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> >>>>>>> Research Fellow, Escuela de Medicina de Harvard<http://hms.harvard.edu/> >>>>>>> Moderador, GHDOnline.org <http://www.ghdonline.org/>**** >>>>>>> >>>>>>> **** >>>>>>> ------------------------------ >>>>>>> >>>>>>> Click here to >>>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>>>>>> OpenMRS Implementers' mailing list >>>>>>> **** >>>>>>> ------------------------------ >>>>>>> >>>>>>> Click here to >>>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>>>>>> OpenMRS Implementers' mailing list >>>>>>> **** >>>>>>> >>>>>>> ** ** >>>>>>> ------------------------------ >>>>>>> >>>>>>> Click here to >>>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>>>>>> OpenMRS Implementers' mailing list >>>>>>> **** >>>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> Click here to >>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>>>>> OpenMRS Implementers' mailing list >>>>>> >>>>> >>>>> ------------------------------ >>>>> Click here to >>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>>>> OpenMRS Implementers' mailing list >>>>> >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>>> OpenMRS Implementers' mailing list >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>> OpenMRS Implementers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list > -- Jonathan D. Galingan, MD Project Manager for Computerization Philippine General Hospital _________________________________________ 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]
