Deploying OpenMRS on Raspberry Pi: The EMR4All Project

1

EMR4All Project Update

I would like to extend our heartfelt thanks to @grace and the OpenMRS board members for supporting this initiative and for providing the opportunity to share updates about OpenMRS on Raspberry Pi with the community.

You are most welcome to contribute, providing constructive inputs and ideas for the growth of this open-source initiative.

This talk will provide an update on the EMR4All project, which aims to deploy OpenMRS on Raspberry Pi, starting with version 2.x of the platform. The EMR4All initiative focuses on overcoming challenges related to electricity and internet connectivity in remote locations by providing a portable, affordable mini-server solution. This powerful mini-server allows health facilities in low- and middle-income countries (LMICs) to run OpenMRS offline on local networks, with the ability to sync data to remote servers for patient data sharing and telemedicine.

Through this talks the EMR4all team will share update on the infrastructure, source code and implementation strategies behind this project, including how it facilitates data sharing between remote Raspberry Pi devices and cloud servers, enabling remote management and patient care.

The talk will also cover how this initiative aligns with the broader OpenMRS vision of open-source collaboration, resource sharing, and universal access to healthcare solutions.

Learn more about the EMR4All project through the following link: EMR4All Project Presentation.

You can also preview the EMR4All light presentation at the OpenMRS Implementers Conference 2024 here: OpenMRS Conference Presentation.

The resource documentation for EMR4All is accessible via:
Wiki Hub for EMR4All: EMR4All - Confluence (atlassian.net).

For implementers who wish to support the project, please join the Slack channel for discussions and framework conversations: Join EMR4All Slack Channel.

Join us for an in-depth look at how EMR4All is revolutionizing healthcare in resource-limited settings and the ways in which you can contribute to the project’s growth.

2

Custom Sync Service Components for Raspberry PI

The custom sync service for Raspberry Pi devices comprises several key components to ensure efficient, reliable data synchronization to the cloud. Below is an overview of the core mechanisms involved:

1. Change Detection Mechanism

  • Polling for Changes: The sync service periodically checks the relevant tables in the local OpenMRS database for changes, such as new or modified patient demographic data.
  • Retry Logic with Exponential Backoff: In case of transient errors during synchronization, the service employs retry logic with an exponential backoff strategy to manage retries (detailed below).
  • Error Logging: Errors encountered during synchronization are logged for later analysis and debugging, allowing for rapid identification of potential issues.

2. Error Handling & Retry Mechanism

  • Timestamps and Version Numbers: Each record carries timestamps and version numbers to track changes and avoid duplicate or conflicting data during synchronization.
  • Manual Review: In case of persistent errors, flagged records are available for manual review to resolve discrepancies or issues before further synchronization attempts.

3. Data Transfer Mechanism

  • API-based Data Transfer: A RESTful API hosted on the cloud server receives data from the Raspberry Pi devices. This API facilitates secure, structured data communication between distributed devices and the central server.
  • Backoff Strategy for Retries:
    • Exponential Backoff Logic:
      • Backoff Factor: Set to 2, meaning the wait time between retry attempts doubles after each failure.
      • Random Jitter: A random time offset is added to the wait time to prevent multiple devices from retrying simultaneously in case of system-wide issues.
      • Retry Attempts: The sync function attempts data transfer up to max_retries times. If all attempts fail, the error is logged for future review.
      • Sleep Time Formula: The sleep time between retry attempts is calculated using the formula:
        Sleep time = backoff_factor X attempt_number + random.uniform(0,1)
        This ensures exponential growth of the wait time with some randomness to avoid simultaneous retries.
    • Benefits of Exponential Backoff:
      • Helps to handle transient errors effectively.
      • Prevents overloading the cloud server by managing the retry intervals.
      • Increases the likelihood of successful data transfer on subsequent attempts.

4. Asynchronous Processing (Using asyncio and aiohttp Libraries)

  • Asynchronous Data Fetching: The sync service uses asynchronous I/O operations (with await) to fetch changes without blocking the event loop, ensuring smooth and efficient performance.
  • Non-blocking HTTP Requests: Data is transmitted to the cloud asynchronously using aiohttp, allowing for non-blocking HTTP requests, which significantly enhances the performance of the sync service.
  • Asynchronous Record Updates: After successful synchronization, records are marked as synced asynchronously to avoid delays and maintain responsiveness.

5. Server-side Asynchronous Framework

  • FastAPI Framework: The cloud server uses the FastAPI asynchronous framework to handle incoming data efficiently. FastAPI is optimized for high performance and is well-suited for I/O-bound tasks like handling large amounts of sync requests.
  • Uvicorn: The FastAPI application is deployed using Uvicorn, an ASGI (Asynchronous Server Gateway Interface) server. Uvicorn is known for its speed and supports SSL for secure data communication.

This combination of asynchronous processing, exponential backoff, and error handling ensures that the sync service is both efficient and resilient, capable of handling real-world network and system uncertainties while maximizing performance and data reliability.

You can view a live demo of the sync process through the following link: Live Sync Demo. This demo illustrates the functionality of the custom sync service, including data synchronization from Raspberry Pi devices to the cloud, error handling, and the use of asynchronous processing. For more in-depth technical details, please refer to the EMR4All Wiki space,

3

Progress Update: Multiple Raspberry Pis Sync to One cloud Server

EMR4All has achieved a critical milestone with the full synchronization of patient demographic data from multiple Raspberry Pi devices to a centralized cloud server. This advancement enables two key outcomes:

  1. Data Synchronization from Distributed Raspberry Pi Devices: Data from multiple Raspberry Pi devices running local instances of OpenMRS has been synchronized to a central server. This demonstrates the feasibility of consolidating data from decentralized sites, effectively addressing challenges related to the accessibility and availability of patient information across geographically dispersed locations.

  2. Data Synchronization status: The successful synchronization of all demographic data, encompassing a large volume of patient encounters, provides clear visibility into additional clinical data types .Here’s the status of the data synchronization flow:

  • Person - the core person record :white_check_mark:
  • Person address - address information :white_check_mark:
  • Person name - names associated with the person :white_check_mark:
  • Person attributes - custom attributes (e.g., telephone number) :white_check_mark:
  • Patient - the patient record itself :white_check_mark:
  • Patient identifier - unique identifiers associated with the patient :white_check_mark:
  • Visit - tracking visits by the patient :white_check_mark:
  • Encounter - encounters during each visit :white_check_mark:
  • Obs (Observations) - observations for each encounter of every visit [Still a work in progress]

This achievement establishes a robust framework for broader data integration and analytics. Thank you for your continued support, and stay tuned for more updates!

1 Like
4

You’re Invited: EMR4All Webinar on 25 October 2025! (OpenMRS on Raspberry Pi)

We are pleased to invite you to our webinar on 25 October, from 13:00 GMT / 15:00 CET, where the EMR4All project team will be presenting progress on integrating OpenMRS 2.x on Raspberry Pi.

During the webinar, we will highlight key advancements, including:

  • Seamless Sync Feature for Multiple Devices: We will discuss the advancements in the sync feature that allows all patient data from Raspberry Pi devices to be securely synced to the cloud from multiple sites to a central OpenMRS database. A showcase will be presented during the webinar, detailing the progress made for datasets beyond demographics.

  • New EMR4All Case Box: Our team has designed the first prototype for a case that combines a Raspberry Pi, power bank, and modem into one portable solution, making it easy to carry to field locations. The case will be presented during the webinar, along with future versions that will include a solar panel to provide power in remote areas with limited electricity.

  • We have provisions for a live demo and an interactive Q&A session to gather your feedback and recommendations for improving this project for the benefit of community health.

Register here: OpenMRS on Raspberry Pi - Revealing EMR4All Kit - WebinarNinja

We look forward to seeing you at the webinar as we take a big step forward in healthcare technology for remote and rural areas!

5

Update on Sync Optimization for EMR4ALL Health Kit

We’ve been making strides in optimizing the data synchronization process for the EMR4ALL Health Kit, especially when dealing with large datasets. So far, initial testing has gone smoothly with the extensive demo data from OpenMRS, showing promising results. However, further testing is underway to ensure consistent performance and reliability.

Next steps include acquiring access to de-identified referral facility-level data to expand our testing. This data will allow us to refine the sync feature, ultimately improving the Health Kit’s ability to manage larger volumes of patient information in real-time across remote facilities.

Stay tuned for more updates as we continue to enhance the Health Kit’s capabilities to better support healthcare delivery in remote and rural areas!

6

Dear Community Member,

We are pleased to share some updates on the EMR4All project!

1. Access to the Source Code:

If you wish to access the source code or implementation details for OpenMRS on Raspberry Pi, you can find all the documentation and source code on our Confluence site. You can also access it through the resources page on our website.

In addition, here are some important updates:

2. Recommendation for High-Volume Hospitals:

For those planning to deploy OpenMRS on Raspberry Pi in large hospitals, we recommend using “Pirony 5.” This case offers significant advantages, including improved thermal control and high storage capacity, making it ideal for efficiently managing large volumes of patient data. Detailed specifications and purchasing options are available on our Pirony 5 page.

3. Cost Calculation Tool:

To help with budgeting, we’ve added a costing tool to our website. This tool allows you to simulate project costs and estimate expenditures before purchasing materials. It’s designed to help you make informed decisions based on your specific project requirements. You can explore the tool here.

For more details, please visit our homepage.

Best regards, Benjamin nyange

2 Likes
7

EMR4All: Achievements in 2024 and Plans for 2025

A Special Thanks

We extend our heartfelt gratitude to the entire OpenMRS community and all supporters of the EMR4All initiative. Your continued support and collaboration are vital to our mission of improving healthcare delivery globally.

:tv: Watch our recap video: YouTube Link :page_facing_up: Download the presentation: PowerPoint on SlideShare :globe_with_meridians: Visit our website for more: www.emr4all.org

Achievements in 2024

  • Advanced Sync Feature: Enabled secure synchronization of multi-site data from Raspberry Pi devices to a central OpenMRS database, extending functionality to handle more complex datasets.
  • Prototype Case Box: Developed a portable case combining Raspberry Pi, power bank, and modem, with plans to include solar panel support.
  • Optimization for Large Datasets: Enhanced sync performance for managing large volumes of patient data, with successful testing.
  • Resources & Tools: Opened access to the source code, added documentation, and launched a cost calculation tool to aid deployments.
  • Support for High-Volume Hospitals: Recommended the “Pirony 5” case for improved thermal management and higher data storage capacity.

Plans for 2025

  • Demo Cloud Server: Launching a community AWS server for pilot projects and centralized data management.
  • Enhanced Health Kit Box: Introducing a versatile, solar-powered kit for rural, field, and high-volume healthcare facilities.
  • Installer Package: Developing a compiled installer for OpenMRS on Raspberry Pi, including features like wireless access points and pre-configured sync functionality.
  • Bahmni on Raspberry Pi: Expanding functionality with Bahmni integration to serve diverse healthcare needs.
  • Solar-Powered Case: Releasing a solar-powered Raspberry Pi case to address power challenges in low-resource areas.
  • O3 Integration: Incorporating OpenMRS 3 for a more modern and user-friendly system.

We are excited to continue this journey together, advancing accessible and effective healthcare solutions worldwide. Thank you for being part of the EMR4All mission!

3 Likes
8

Thanks for the update @bennyange

9

When working on a Demo Cloud Server on AWS you may consider using GitHub - openmrs/openmrs-contrib-cluster: Contains terraform and helm charts to deploy OpenMRS distro in a cluster or GitHub - openmrs/openmrs-contrib-cluster-aws-ecs

To lower the monthly cost of a demo server you could pick smaller instances and reduce replication.

1 Like