OpenHMIS Registration Module - Design

classic Classic list List threaded Threaded
7 messages Options
Wesley Brown Wesley Brown
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

[hidden email] from OpenMRS Developers' mailing list
Andrew Kanter Andrew Kanter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenHMIS Registration Module - Design

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: [hidden email]
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter


From: Wesley Brown <[hidden email]>
To: [hidden email]
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

[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenHMIS Registration Module - Design

In reply to this post by Wesley Brown
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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Joaquín Blaya Joaquín Blaya
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenHMIS Registration Module - Design

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


On Fri, May 18, 2012 at 1:02 PM, Burke Mamlin <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Wesley Brown Wesley Brown
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenHMIS Registration Module - Design

In reply to this post by Andrew Kanter
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 <[hidden email]> 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: [hidden email]
Mobile: <a href="tel:%2B1%20%28646%29%20469-2421" value="+16464692421" target="_blank">+1 (646) 469-2421
Office: <a href="tel:%2B1%20%28212%29%20305-4842" value="+12123054842" target="_blank">+1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter


From: Wesley Brown <[hidden email]>
To: [hidden email]
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

[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Wesley Brown Wesley Brown
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenHMIS Registration Module - Design

In reply to this post by Burke Mamlin
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 <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
judy wawira judy wawira
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenHMIS Registration Module - Design

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 <[hidden email]> 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 <[hidden email]> 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

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Loading...