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 <[email protected]> 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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
