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