OpenHMIS - Registration Module

What this module does

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.

Design

Summary

The registration module will automate patient administration functions and provide a high-quality patient care process that is flexible enough to support many varied registration processes.

High-Level Requirements

The features that will be included in the 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

The primary function of the registration module is gathering and tracking patient data, this is the functional area that these activities fall under.  The tracked fields are grouped into a registration Field Set that is configurable so that institutions can define their own fields, lookups, and validation rules.  Field Sets can be imported and exported during the configuration process so that a common set of fields can be used by institutions that wish to standardize.

The data entry is performed on the Patient Data Entry form which uses the current registration Field Set and registration Set Layout to determine the rules for how to display, validate, and save the patient data.

The patient search supports simple searches using registration field data as well as more specialized searches using devices like finger-print or retina scanners.  The searching options are configured on the Patient Search Configuration page.

Inputs
This functional area includes the following forms:

• Registration Module Configuration

  • Select Field Set

  • Module Options?

  • Patient Data Entry

  • Patient Search

  • Patient Search Configuration

  • Patient Summary (control)

  • Schedule Appointment

  • View Appointments

The data is primarily input from the Patient Data Entry and Schedule Appointment forms with the configuration forms only affecting metadata.

Processing
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.

Outputs
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.

Multiple Registration Queues

Inputs

Processing

Outputs

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 version 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. 

Reports and/or alerts will be created to help identify patient visits that appear to be orphaned.  These reports will have to take into account the type of visit (in-patient, out-patient, etc) to determine which visits appear to be suspicious.  This report will likely be run daily by the records personnel who will also then have the ability to end those visits retroactively.  Likewise, when a patient registers and warning will appear if the patient already has an active visit to ensure that the records personnel is aware of their current state.

Inputs
The start and end of the visit must be tracked.  The logical place to record the start of the visit is in the registration module; once the registration information has been entered the patient will automatically have a new visit started (provided a visit is not currently active).  The records personnel will also have the option to not start the visit, but this will not be the default.

The party responsible for ending the visit will vary by site and needs to be configurable.  At the most basic, this can simply be a button or link on the patient summary that is only visible for certain roles or users.  It may make sense to also enable tighter integration with the overall patient workflow so that the option to end the visit appears at the appropriate stage; perhaps as a dialog or other attention-demanding element.

Processing
When a new visit is started a new record will be created to track the visit.  Unless and until more data are required about a patient visit the only information that really needs to be tracked is the start and end time of the visit and possibly the type of visit (though this might be able to be inferred from the encounters that occur during the visit.  This minimizes or even eliminates changes to the core OpenMRS system because encounters, observations, and orders that occur within the start and end of a visit are simply considered part of that visit.

Outputs
While a visit is active some information noting that should appear in the patient summary on each page.  The information about visits should be available to various reports where that information might be useful.  Also, patient information should have a configurable option to group by visits.  This might be tied to certain roles, users, or just be a display option on pages that list this information.

Patient Visit Slip

After registering, patients will usually receive a patient card that has their basic information that will be needed during their visit.  The site is able to determine exactly how the card looks as well as what information appears on it. 

Inputs
All the data for the visit slip comes from the registration page.  The card will be printed after the patient registration data gathering is complete so that any internal identifiers have been generated.

Processing
The card itself has no processing associated with it as it is effectively just a printed report.  However, the card will be used as the starting point for many other processes so that the patient information can be looked up within the system.  As such, the card must include enough information to make this lookup as easy as possible.

Outputs
The only output is the visit slip itself.

Patient Queries

Inputs

Processing

Outputs

Patient Data Lifetime

Patient data is vitally important to any medical records system and the process around marking data as no longer needed or removing that data from the system must be carefully managed.  OpenHMIS supports a four-stage data lifetime policy: Active, Archived, Transferred, and Purged. 

These processes and workflows are all configurable so that administrators can define the rules for what data should be archived, transferred, or purged and then optionally set up schedule tasks to do execute this process on an ongoing basis.  When executed, these tasks send out a notification with a summary of the operations performed.  More detailed data about the archived, transferred, or purged records can also be viewed from within OpenHMIS.

Inputs
All the configuration settings for what records to archive, transfer, and purge, as well as the specific settings for those processes are configured via forms in OpenHMIS and can also be imported from or exported to other installations.

All historical information about patient records moving from one state to another is recorded and viewable from within OpenHMIS, both in summary and in detail.

Forms:

• View Archive Definition List

• Add/Edit Archive Definition

• View Archive History Summary

• View Archive Detail

• View Transfer Definition List

• Add/Edit Transfer Definition

• View Transfer History Summary

• View Transfer Detail

• View Purge Definition List

• Add/Edit Purge Definition

• View Purge History Summary

• View Purge Detail

• Export/Import Definition

Processing
When the record state changes the following occurs:

• Active: Most data in the system is considered Active and will be returned in searches, show up in reports, and is generally accessible within the system. 

• Archived: The data still remains in the system but is flagged as being archived and thus will not appear in searches or most reports, unless archived records are specifically included.

• Transferred: Records that have been exported to some persistent external data store are considered Transferred and become eligible to be purged from the system.  Note that this is different than a backup because a backup will likely be overwritten over time as new backup are created.  The external data store for transferred records should remain intact for as long as the data could possibly be needed.

• Purged: Once records have been transferred they can be deleted from the system without fear of data being lost. The information about what records were purged and which external data stores they can be found in is recorded to help in case the data needs to be restored and to provide an audit trail of when and why the data was purged.

Outputs
Historical information about patient record state changes is tracked and is accessible via the history summary and detail pages.  Also, the configuration settings can be exported to an external file.

Registration Notifications

Inputs

Processing

Outputs

Patient Sponsorship

Some patients are members of a company-paid or sponsored health plans and all patient bills should go to that company or sponsor.  We track the company balance, individual payments made by the company, patients that have used their company benefit. This list of companies must be managed by the records or billing departments.

Does each sponsor have a maximum credit balance?

Can sponsors set a maximum per-visit payment?

Do sponsors cover some treatments but not others?

Do sponsors have different levels of coverage?

Inputs
When a sponsored patient registers they must give their company information so that the company is associated with the current visit.  When the patient goes to pay their bill the cashier will look to see that the patient is sponsored and charge the company account rather than the patient directly.

Processing

Outputs

Appointment Scheduling

Inputs

Processing

Outputs

Patient Record Accessibility

Patient record data must be protected so that the information is only visible to the appropriate personnel at the appropriate time.  In the default state a patient record is only accessible to users with the appropriate role to be able to search for patient records, usually records personnel.  A patient record can be assigned to a specific user, user group, or department/clinic queue.  Each record can be assigned to multiple users/groups/queues at the same time; when a record is assigned it is considered to be ‘owned’ by the assigned party or parties. 

When a record is assigned to a queue, any user with access to that queue can take ownership of the record until the patient progresses to the next stage of their visit.  For example, if a patient record is assigned to the triage queue, the triage nurse can take ownership of the record, make the necessary observations on that record, and then transfer it to a specific doctor or another queue.  Once the record is transferred the assignment to the triage nurse is deleted, removing the nurse’s access to the patient record.

Each assignment can optionally have a time span associated with it.  This time span is either a specific time period or a relative time span from when the record is first opened by the assigned party.  Record assignments without a time span will remain assigned until the assignment is specifically removed; this is called an ‘Unrestricted Assignment’.

To provide accountability all patient record assignments and accesses are tracked and visible in the patient record by users with the appropriate role.

Inputs
Configuring the accessibility occurs primarily through assigning privileges to users and user groups so that they have the ability to search, view, assign, and edit patient records as needed.  The following privileges are defined by the registration module:

• OpenHMIS.Registration Search Patient: Allows a user to search patients

• OpenHMIS.Registration Assign Patient: Allows a user to assign a patient

• OpenHMIS.Registration Unassign Patient: Allows a user to un-assign a patient from another user

This functional area has the following forms:

• Patient Search

• Patient Search Configuration

• Assign Patient Record

• View Patient Assignments

• View Patient Access History

• View User Assignments

Processing
When patient records are assigned audit and history records are created so that the usage of the record can be tracked. 

Outputs
Reports:

• Unrestricted Record Assignments

• Unassigned Record Accesses?

Documentation

Downloads / Source

Source code is hosted at github: https://github.com/OpenHMIS/registration

Screenshots

Release Notes

About

This module was developed by the Christian Health Association of Kenya.