Request for Registration Module Feedback

[Wesley Brown]

Greetings!

My name is Wes Brown and I am a part of a group creating a set of general-purpose HMIS modules for OpenMRS; a project that we are calling OpenHMIS.  One of our primary goals is to create modules that are flexible enough to work in as many institutions as possible, in hopes of reducing the amount of baseline work needed to create institution-specific modules.  

As part of this effort we would like to get your feedback on the current registration modules that are in use.  We are going to create a registration API module that will handle much of the core back end registration activities and we want to make sure that we include as many of the core features as possible.  What we are looking for is information about the current registration module that you are using (or developing) and the features that you would consider are integral to it or, conversely, that are missing from it.  We will then gather this information and come up with a list of the 'core' registration features that we will support, hopefully in a manner that makes it easy for other module developers to reuse.

If there is sufficient interest, we would also like to discuss this at an upcoming Design Forum.  There is so much great HMIS work that has been done already for OpenMRS and we do not want to unnecessarily duplicate this work; our hope is that we can collaborate together so that these type of efforts do not have to start from nothing each time!

Thanks,

-Wes Brown

[Paul Biondich]

Wesley, thanks for the nice note and introduction.

As one of the founders of OpenMRS, I am very supportive of this
effort. We are trying to encourage the notion in the community of
"distributions". That is, more customized, generic implementations of
systems that have OpenMRS inside. Kind of like how Ubuntu has the
Linux kernel inside. I think what you're describing is a potential
distribution of OpenMRS.

I believe there are a number of constituencies interested in your
goal, many of them have development and cash resources to lend to such
an effort. I would like to find a way to support this work by helping
you all get more organized and use the public fora that already exist
to influence how we develop our roadmap, and how we all move forward
as a community.

Please let us all know when you've found a time to talk publicly about
this effort, and I will definitely find a way to attend.

I appreciate your efforts here!
-Paul

> -- OpenMRS Implementers: http://go.openmrs.org/implementers
> Post: implem...@openmrs.org
> Unsubscribe: implementers...@openmrs.org

[Burke Mamlin]

At AMPATH, in Kenya, we're using the amrsregistration module, which has pretty basic registration functionality; however, the UI is not as nice as we'd like.

Some of the aspects of registration that are important to us:

• Allowing suggested matches to be presented as the registration data are being entered.
• This involves getting the most important matching element up front (early in the form)
• Only showing suggestions when/if the potential matches gets to a useful amount (e.g., 5-10 or fewer matches).
• The ability to customize the algorithm to determine potential matches to balance sensitivity & specificity.  For example, gender should always match, but if many other demographics match, then you might suggest matches that differ in gender.  In Kenya, order of names is meaningless, so the algorithm needs to consider this, while this is not true for other environments.
• Performing a much more specific search for possible duplicates at the time that a new registration is attempted
• This algorithm is more specific than the initial algorithm as an attempt to prevent duplicates once a full registration form is being submitted.
• Flexibility with how medical identifiers are assigned – e.g., working with the idgen module.
• Would love to have an observer pattern for interested code to listen for registration events along with an HL7 registration event message generated when patients are registered.
• For example, we want to send a message to scheduling software or invoke a module that will print out an identifier card for new patients.
• The option for the registration to "take over" the UI – i.e., so a registration clerk does not see the rest of the OpenMRS application.
• The option to invoke another URL at the end of the registration process and/or an extension point that another modules could use to introduce some workflow just before or just after the registration occurs.
• The use case here was that the hospital wanted registration clerks to enter some financial information specific to their needs immediately after each registration event.

There are probably other thoughts/requirement… but these are ones that come to mind.

Cheers,

-Burke

On Thu, May 24, 2012 at 9:26 AM, Wesley Brown <wesb...@gmail.com> wrote:

-- OpenMRS Implementers: http://go.openmrs.org/implementers
Post: implem...@openmrs.org
Unsubscribe: implementers...@openmrs.org

[Tobin Greensweig]

Hi Wes,

Our registration clerks do both new patient registration and "check in/update" existing patients.

To strongly second some of Burke's ideas and add a few more:

- works with the idgen module

- print id cards to a card or label printer after registration

- custom registration ui for registration clerks

- integration via url or extension point with other modules

     -appointment scheduling (both to invoke a patient for registration and to make appointment for registered patient)

     -"workflow" assigning patients to a list for the care providers to call patients from (we have a prototype of this running if you're interested in seeing it)

-managing programs, relationships, and allergies from within the registration screens

-support for barcodes (both generation for id cards and opening a file from a barcode scan) 

I'm working with a clinic for Refugees in Tel Aviv and we're hoping to have some senior university students working on what may be similar modules in the near future, perhaps we can collaborate?

Tobin

--
Tobin

[Wesley Brown]

Paul,

Thanks for your encouraging message.  The creation of an OpenHMIS distribution is something that we have been thinking about so as to make the implementation and setup easier.  We are also hoping that this collaboration effort will help HMIS module development outside of the any forthcoming OpenHMIS distribution.  

We welcome any advice or assistance that you can provide!  We are basically figuring this out as we are doing it but, in all honesty, the main area where I feel comfortable is with the development-related activities so any organizational support would be extremely helpful.

I am going to try and schedule some time at an upcoming design forum to discuss our plans with those interested in helping.

-Wes

> Unsubscribe: implementers+unsubscribe@openmrs.org

[Wesley Brown]

Burke,

Thanks for the information about your registration system.  Do you have any of your documentation/specifications publically available?  I am going through each response to spec out what features should be included (or at least discussed) in a generalized registration module.  Given that you already have a system in place your experience would be very helpful!

Our team is located in Nairobi and if I remember correctly your team is up in Eldoret; perhaps we could get together sometime?

-Wes

-Burke

Unsubscribe: implementers+unsubscribe@openmrs.org

[Wesley Brown]

For those that are interested, I am purposing that we discuss this at an upcoming design forum, maybe June 6th?  I'm not sure if that meeting already has other things planned as I cannot see the upcoming topics on the wiki page but that date would work well for us.

I am gathering all the features that have been mentioned so that we can have a concrete list to discuss and putting it up here.  Feel free to add to, update, or comment that page.

Thanks!

-Wes

[Ben Wolfe]

Discussing next week should be fine.  I have added it to the agenda for June 6th: http://notes.openmrs.org/Design-Forum-2012-06-06
If you (or anyone else) has more ideas you can add them either to that agenda page or as a comment on the HMIS/registration page you started: https://wiki.openmrs.org/display/docs/OpenHMIS+Registration+API+Design

Ben

-- OpenMRS Implementers: http://go.openmrs.org/implementers
Post: implem...@openmrs.org

Unsubscribe: implementers...@openmrs.org

[mvila]

Hi all, 

We have a registration module running in a Hospital in India since last year and I would like to share some feedback we got from the users, and some other features we identified as useful when implementing the system in different hospitals.

I just saw you are discussing it today...hope is not too late

I copy the comments here, but I also added them to the wiki, as you required...

Search

• Advance Search Option
  
• Filters patients by gender
  
• Age +-Range
  
• Last Visit
  
• Relative Name
  
• Telephone Number
  

General

• Manage user Categories
• Create new categories
• Define category Type 
  
• Define incompatibilities amongst categories and patient restrictions
  
• Dynamic design of the available fields  in the registration form selecting from person attributes
  
• Integrate with a patient queue system that send the patient to the selected ward
  
• Print patient slip after registration
  
• Dynamic design of the print layout
  
• Configure the precision on the calculated age to show (years, months, days)
  

 

UI 

• Design a screen-size layout to avoid scroll while registering
  

Hope is useful!

Regards,

Marta

Unsubscribe: implementers+unsubscribe@openmrs.org

Unsubscribe: implementers+unsubscribe@openmrs.org

[Wesley Brown]

Marta,

Thanks for contributing this!  We are going to discuss this at the design forum later today, 2PM ET, which may be a bit late depending on where you are located.  If it's not, I hope that you can join.

-Wes

[Marta Vila]

a bit late here in India...

will check the notes!

thanks

-- OpenMRS Developers: http://go.openmrs.org/dev
Post: d...@openmrs.org
Unsubscribe: dev+uns...@openmrs.org

[Wesley Brown]

My apologies for the long silence!  One of the things that came from this design forum was that it might be helpful for to be able to review the custom registration modules that have been built and attempt to determine the commonality between them.  Part of this effort is the OpenHMIS Registration API Design page but it would also be very helpful if I could see these modules in action.

If you have created a custom registration module I would like to set up a Skype or an Adobe Connect session to review what you have done and continue to add to the API Design page.  If a live session is not possible screenshots with descriptions would also be fine.  My goal is to review as many of the OpenMRS registration modules as possible so that I can spec out a base registration module that can be reused in as many registration processes as we can.

If you are interested in helping with this please contact me here or via email (w...@weslandia.org).

Thanks!

-Wes

Unsubscribe: implementers+unsubscribe@openmrs.org