Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0


The OpenHMIS Registration Module is the entry point of the data for all 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 initial data that is collected.  As such, the registration module functionality will likely grow to support the additional interfaces and requirements.  This page currently details only the functionality related to the Drop A release of OpenHMIS.


The features that will be included in the Phase 1 Drop A release are:

  • Patient Registration Details
  • Multiple Registration Queues (e.g. Inpatient, Outpatient, etc)
  • Patient Visit History
  • Patient Visit Slip
  • Patient Queries
  • Patient Data Lifetime
  • Registration Notifications
  • Patient Sponsorship
  • Appointment Scheduling
  • Patient Record Accessibility

Functional Areas

Functional areas that have not yet been defined are included for completeness, but left blank.

Patient Registration Details


If patient is new, registration data is entered and a new visit is created.  Otherwise just a new visit is created.  Once the new encounter has been created the patient is moved to the next stage in the patient workflow.  For example, at some sites this will be into the billing queue for the patient to pay their initial fees; others may move the patient directly to a clinic or triage queue.  The patient can be moved through this workflow by the records personnel who decide where the patient should go and can put this into the appropriate queue, if one exists.Describe what is done by the function. Where algorithms, equations, or other logic are used, they are described here. If calculations are done utilizing the methods of specific standards or references, these are cited. Database definitions are also included where relevant.

The patient will be identified and their data will be collected or updated.  Additionally, the patient visit will be started, provided they continue past registration to some other stage.

Describe the outputs of the function. Where a user interface description is relevant, it is included. Define any reports.

Multiple Registration Queues





Patient Visit History

The patient visit history must be available via reports and possibly in the main UI.  The visit history is a grouping of the various encounters, observations, bills, and payments into a ‘Visit’, which has a start and end date.  Certain roles or users may not want to see the patient history grouped in this manner so the option to view patient data like this should be configurable.  For example, a doctor may not care to see each encounter under a specific visit and may rather just see the list of encounters ordered by date.  OpenMRS does not currently have a concept of a ‘Visit’, rather each patient interaction is recorded as an Encounter, Observation, or Orderversion 1.9 is adding support for visits.  Once the design is complete we will need to see if this design will work for our requirements.

To support grouping data into a Visit the start and end date/time must be tracked for each patient.  The start of the visit can be easily tracked when a patient registers; determining the end of the visit may be more problematic.  Ideally, the last representative that a patient interacts with should be responsible for ending the visit.  However this is likely to lead to orphaned visits with no end date/time because if everyone is responsible to end the visit, no one will be responsible to end the visit.  At the sites we have been to thus far it will likely be fall on the Cashier and possibly the Pharmacy (once added to OpenHMIS) to be responsible to end a patient visit. 


Source code is hosted at github:


Release Notes