Andy, Thanks for the feedback!
I understand what you are saying about combining a lot of functionality into this registration module and agree that some of it will be in other modules. We are intentionally trying to look at the "registration" functionality from the viewpoint of the hospital/clinic personnel that are responsible for it. As such, we have had meetings with a few institutions around the Nairobi area to work through how their registration process currently works, how they would like it to work, and what other activities they (usually the records department) perform. It is from these meetings that we came up with this feature list and I do believe that it accurately represents many of the responsibilities commonly handled. The registration of patients is the core feature, the other features flow from that or are typically handled by the same people. Some of these features will only be referenced by our registration module: visit history, data lifetime, notifications, scheduling, and record accessibility. I would expect that these features would either use existing modules or be created as distinct modules with the required hooks for other modules. We are trying to balance a very modular approach (lots of small modules) with a more comprehensive approach (fewer modules, each with a more broad scope). Our reasoning behind wanting a comprehensive approach is to simplify the selection and implementation of the OpenHMIS modules. I know that I had a difficult time determining which modules are actively developed and supported, will work properly together, etc. I can only imagine that this is a very difficult process for implementers and likely leads to duplication of module development effort. That said, I am new to OpenMRS and know that others have already thought about this; is there any guidance on the generally accepted scope for a module? We do have some use cases and will be putting them up on the wiki soon. I agree that our goals are ambitious, but hopefully not too ambitious! -Wes On Fri, May 18, 2012 at 6:36 PM, Andrew Kanter <[email protected]>wrote: > Wes, > This looks quite ambitious! I wondered why you combined so much > functionality into a "registration" module. It seems that many of the > functions are better separated out for patient interaction. Seems that > registration shouldn't include actual visits, etc. Do you have a use case > document which describes the actors and functions that will use this system? > > I am sure that Hamish and many others would be quite interested. > > BTW, great project! > Good luck! > Andy > > *-------------------- > Andrew S. Kanter, MD MPH > > * > Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology > Columbia University > Email: [email protected] > Mobile: +1 (646) 469-2421 > Office: +1 (212) 305-4842 > Skype: akanter-ippnw > Yahoo: andy_kanter > > ------------------------------ > *From:* Wesley Brown <[email protected]> > *To:* [email protected] > *Sent:* Friday, May 18, 2012 7:53 AM > *Subject:* [OPENMRS-DEV] OpenHMIS Registration Module - Design > > 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 > > > ------------------------------ > 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]
