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