OpenHMIS Registration Module - Design

[Wesley Brown]

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

[Andrew Kanter]

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: andrew...@dbmi.columbia.edu
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter

---

From: Wesley Brown <w...@WESLANDIA.ORG>
To: openmrs...@LISTSERV.IUPUI.EDU
Sent: Friday, May 18, 2012 7:53 AM
Subject: [OPENMRS-DEV] OpenHMIS Registration Module - Design

---

Click here to unsubscribe from OpenMRS Developers' mailing list

[Burke Mamlin]

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

[Joaquín Blaya]

Wes,

Also, HISP india has developed a lot of HMIS modules here https://github.com/hispindia

Joaquín
___________________________________________________________________
Gerente de Desarrollo, eHealth Systems
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org

[Wesley Brown]

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

[Wesley Brown]

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

[judy gichoya]

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

[Burke Mamlin]

Wesley,

Over ambitious goals?  I think your goals aren't ambitious enough! ;-)

Getting a strong patient administration component would be a tremendous help and some would argue that this is the place we should have started.  The ultimate registration module would not only have the features you listed, but also would allow for OpenMRS to work with an external master patient index.  And it would not only serve the needs of multiple hospitals in Kenya, but also serve the needs of dozens/hundreds of implementations around the world.

My suggestion of splitting the module was primarily to allow you to focus on building collaboration (on the most fundamental pieces) without slowing you down or hampering your ability to cut corners to meet deadlines (not good for a "generic" module, but okay if your doing it in a module sitting atop the "generic" module).

I'm excited that you've come to the community with this and would love to see the development … even the seedling … of a shared registration foundation against which any implementation could build.  Just let us know how we can help!

Cheers,

-Burke

[Wesley Brown]

Judy,

I suspect these types of name complications are a large part of the reason why every institution we have spoken with is very interested in some form of bio-metric identification system.  Around here all of the Nakumatt stores (for those that don't know, a local grocery chain) use fingerprint scanners for cashier login and manager overrides.  The hope is that the registration process would be able to take advantage of a similarly "simple" biometric lookup to try and avoid such issues.  While we are not yet convinced that affordable biometric solutions provide the level of accuracy needed, we have not yet done any testing to determine this.

That being said, I am sure that there are many institutions where a biometric solution is not an option and so I am looking forward to seeing what you come up with in the patient matching module!

-Wes

[Wesley Brown]

Joaquín,

Thanks for the link!  I got a couple of your modules up and running but am not sure about how to configure my OpenMRS instance to use it correctly.  Do you have any setup documentation?

-Wes

[judy gichoya]

Hello Wesley

The use of biometric is an interesting topic , (one that should probably be shared with the implementers for their feedback). I don't think there is a single one solution to person identification and record linkage, and the biometric techniques come with their own challenges. What happens to the grand mother from the village who had a cut finger while in the firm and comes with dirty fingers and a cataract?

In the USA one of the big issues has been the worry  about the legal repercussions of biometric identification. In health care this is sensitive due to issues around rape and medical fraud. It will be interesting to watch how this space evolves in Africa , where HIPPA regulations are non existent

PS: The patient matching is already in use within openmrs and as a standalone, what we are doing is just improvements

Thanks

Judy

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