Hello Wesley The main challenge will be how to correctly reconcile patients
Specifically for Kenya , the issue of name transposition is a nightmare to record linkage and patient matching. There exists a module in OpenMRS for patient matching , and we are currently evaluating effective strategies to account for lack of adequate demographic reference points during patient registration(as in physical street addresses) and the problem of name transposition We will be incorporating these features into the recmatch patient matching module in openmrs (also available as a standalone version) We already have some tools that could come in handy, like a master list of local Kenyan names, for use when cleaning data and normalizing it for patient matching Judy On May 21, 2012, at 9:51 AM, Wesley Brown wrote: > 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. 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 from OpenMRS Developers' mailing list > > Click here to unsubscribe from OpenMRS Developers' mailing list > > Click here to unsubscribe from OpenMRS Developers' mailing list -- OpenMRS Developers: http://go.openmrs.org/dev Post: dev@openmrs.org Unsubscribe: dev+unsubscr...@openmrs.org _________________________________________ 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]
