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