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 > _________________________________________ 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]
