Wes, Also, HISP india has developed a lot of HMIS modules here https://github.com/hispindia
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, May 18, 2012 at 1:02 PM, Burke Mamlin <bmam...@regenstrief.org>wrote: > Wesley, > > Thank you for this message. There have been many registration-related > efforts over the years (e.g., amrsregistration, registration, > remoteregistration, and rwandaprimarycare modules represent some of these). > Most of these share some fundamental traits, but were created as separate > projects because of varying requirements, for lack of resources for the > extra effort needed to collaborate, or simply for lack of coordinated > efforts). It would be wonderful to start converging on the basic > registration functions needed and get these into a registration module that > can be shared. Since most of the modules have different > requirements/dependencies at the UI layer, one approach might be to try to > create a registration module that focuses on providing the registration > service (API functions) needed across most/all registration applications > (finding a unique patient, tools to find/avoid creating duplicate patients, > registration-specific events like providing a hook for other modules to > listen for registration events and/or sending out an HL7 ADT message upon > registration, etc.). While there might be a single registration > application (UI) that would meet most needs, it may be more effective to > start by tackling the smaller task of creating the fundamental > services/pieces needed across registration applications and thereby > creating a module all other registration modules could use as a foundation > from which they could focus solely on implementation-specific UI needs. > > My assumption would be that some of these services would need to provide > hooks for implementations to insert their special sauce. For example, > provide default algorithms for searching for a patient and for searching > for potential duplicate patients, but expose hooks that implementations (or > other modules) could easily adjust or replace these algorithms to meet > their local needs. > > So, you may consider splitting your module in two: focusing the > collaborative effort on creating a foundational registration module upon > which multiple implementation could share the load, and then creating the > rest of the functionality you need in a module that depends on this first > module and implements the features for which you may have a harder time > finding collaboration opportunities. > > This sounds like a potential topic for an upcoming forum. Maybe a message > to the implementers list to locate people with existing solutions, > interest, ideas that could be consolidated within an OpenMRS > Forum<http://connect.openmrs.org>. > Then adding this to an agenda or two of future design forums. > > Cheers, > > -Burke > > > On Fri, May 18, 2012 at 7:53 AM, Wesley Brown <w...@weslandia.org> wrote: > >> Hello fellow OpenMRS developers! >> >> My name is Wesley Brown and I am writing on behalf of the OpenHMIS team >> to get some feedback on the design for our Registration Module. The >> OpenHMIS Registration Module is the entry point of the data for all of our >> patient-related activities. All forthcoming OpenHMIS modules that deal >> with patient data will rely on this registration module in some fashion, if >> only for the data that is collected. As such, the registration module >> functionality will likely grow to support the additional interfaces and >> requirements over time. >> >> The features that will be included in our initial release are: >> >> - Gather Patient Registration Details >> - Support Multiple Registration Queues (e.g. Inpatient, Outpatient, >> etc) >> - Gather Patient Visit History >> - Patient Visit Slip Generation >> - Support Flexible Patient Queries >> - Patient Data Lifetime >> - Registration Notifications >> - Support for Patient Sponsorship >> - Appointment Scheduling >> - Patient Record Accessibility >> >> Each of these features is discussed in more depth on our wiki page: >> https://wiki.openmrs.org/display/docs/OpenHMIS+-+Registration+Module >> The OpenHMIS code is currently hosted at github: >> https://github.com/OpenHMIS/registration Note that the features above >> have not yet been implemented so there isn't very much in the way of code >> to look at. >> >> It seems like there are a number of groups working on adding more robust >> registration capabilities to OpenMRS, as well as other hospital management >> features. I have heard of at least two: a group from PIH and a group from >> AMPATH. However I have not been able to find any public information about >> their progress or overall design. Has there been any discussion about >> collaborating with each other so that we don't duplicate our efforts and >> end up with a bunch of fragmented HMIS modules? If not, is there any >> interest to do so? >> >> We would also like to get some feedback from the OpenMRS development >> community and hopefully utilize existing work rather than reinvent the >> wheel. >> >> Thanks! >> -Wes Brown >> ------------------------------ >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
