Overview

One of the challenges to data collection in rural clinics is a lack of network connectivity or even power. While mobile data collection can ease some of this burden, we also need ways to support data entry through laptops or desktops in the clinics in an offline manner. For some of our implementations, the lack of remote data entry requires encounter forms to be hand carried to a central site for central data entry before these encounter forms can be returned to the patients' charts; during this time, a patient could come back to the clinic and their most recent encounter form would be unavailable.

The module should be used in the case of disconnected servers. If your server is able to be connected via an internet connection, bi-directional synchronization would be the better option for remote/central servers. (Note: bidirectional synchronization is not available yet)

What This Module Does Do

• Allows multiple disconnected OpenMRS servers to exist within the same implementation

• Allows paper forms can stay at the remote clinic.

• The global patient list is visible in this remote site. (patients added at other remote locations)

What This Module Does Not Do

• Relationships are not synchronized from remote to central server (Supported as of module v2.8)

• Program/Workflow memberships are not synchronized from remote to central server

Example Usage

• A server exists remotely in a disconnected fashion.

• Data assistants at the remote location fill out infopath forms as usual in the remote sites.

• Once a week a user travels from the remote location to the central server with those electronic forms on a usb key. The user imports that data into the central server.

• When returning to the remote server the next time, the user will take back data that has been parsed centrally to the remote sites. This returning of data is necessary to get the updated central patient list to the remote location.

Resources

• Remote FormEntry User Guide

• Download Module

Release Notes

• 2.9.7-SNAPSHOT

  • Mavenized source code

  • RFE-13 - Relatives with empty patient identifier information caused import errors

• 2.9.6

  • RFE-8 - Empty but not null relationship type id in remote form caused NumberFormatException

• 2.9.5

  • RFE-3 - person attributes were being duplicated during processing

• 2.9.4

  • RFE-2 - fixed file import order (was not chronological)

• 2.9.3

  • RFE-4 - Added UUIDs to ALL_PATIENT_DATA

• 2.9.2

  • RFE-5 - fixed importing of empty relationships

• 2.9.1

  • Fixed patient identifier lookup for 1.6

• 2.9

  • Fixed patient identifier lookup in non-default setup for identifier searches

• 2.8

  • Fixed module for 1.5

  • Added ability to transfer relationships

• 2.7

  • Added setting (formerly Global Property from 1.8 downwards) remoteformentry.generated_return_data_tables_to_ignore so admins can specify which tables to leave out of the returnData sql file.

• 2.6

  • Added remoteformentry.invalid_identifier_type setting (formerly Global Property from 1.8 downwards) so an admin can specify which identifier type to automatically convert bad checkdigit-ed identifiers to

• 2.5.1

  • Fixed bug where privileges were defined incorrectly per ticket 1198

• 2.5

  • Added archiving and logging of all downloaded and uploaded files

• 2.4.2

  • Fixed Receive Data From Central when central has a new scheduled task

  • Added optional scheduled task for source key extraction

• 2.4

  • Fixed NPE described by wetuwetu

  • Added additional checks to the "Receive Data from Central" workflow in case an error occurs in the middle of it

• 2.3

  • Added remoteformentry.remote_locations global property to limit the available remote locations

• 2.1

  • Added options to "Resolve errors in import" screen to help with deleting/adding patients

  • Fixed screen message output if there are still pending queue items

• 2.0

  • Fixed bug that was not deleting pending queue items on the remote server

Developers

?@Ben Wolfe