Burke, I think part of what makes our project different from some of the others is that we are very intentionally not working with one specific hospital in mind. We have a couple of pilot sites here in Nairobi, Kenya that we are using to help determine our specifications and eventually test our releases but one of our key design goals is to build a very flexible solution. We want our modules to be flexible enough to work in as wide a range of institutions as possible; primarily though configuration that a non-programmer could do and secondarily as the basis for a customized module. So all that is to say that I think that our goals closely match what is needed to start the convergence that you mention.
Thanks for your thoughts about how to better divide this module, I agree that splitting apart the functionality into a service API and a UI will make it easier to collaborate and reuse. I suppose that making the design process as collaborative as possible would increase the likelihood that the resulting module(s) are easily reusable! I will take your advice and email the implementer list and then try to get this added to an upcoming design forum. Thanks very much for the feedback! -Wes On Fri, May 18, 2012 at 8: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]
