Supporting the Backend for a Remote Healthcare Service

PMT Online is a remote healthcare service offering medical devices to its clients that track crucial health indicators and transmit the data to a centralized system. This information is used to generate reports, which are then sent to healthcare professionals. These reports help the healthcare providers determine if adjustments to the treatment plan or immediate action are necessary.

The company turned to Evrone when the need for updates became apparent and a critical volume of technical debt had accumulated. The foundation of the data reception and processing system relies on Ruby services integrated into a unified system with EventMachine, alongside several Rails applications.

Approaches of FHIR Implementation: Data Exchange According to Standards

The field of healthcare is highly specific, and data exchange in e-Health is regulated by the FHIR standard (Fast Healthcare Interoperability Resources) to ensure regulatory compliance in healthcare. FHIR describes the formats of medical data and their exchange through APIs, enabling even outdated systems to interact with one another and granting access to data from various devices.

Our task was to create an API for data exchange between our service and external healthcare information systems (HIS) while implementing the HL7 FHIR standard. Typically, these HIS belong to clinics where doctors can develop healthcare support for remote patient monitoring and track patients' conditions based on reports and data from the PMT online service.

The FHIR implementation challenges lie in the fact that the standard provides rather general recommendations, with more detailed implementation described in profiles for different regions. Russia lacks such a profile, allowing us some freedom in choosing solutions while aiming for maximum compatibility. Our goal was to identify the correct objects or attributes that would allow us to precisely describe the standard's operations for our system.

This is where Chat GPT-4 proved extremely valuable. This version of OpenAI's technology demonstrated a thorough understanding of real-Life FHIR standard implementation. In addition to "digesting" documentation, this neural network appears to possess a wealth of implementation examples, providing insights from developers. With all this information, we were able to efficiently generate resource examples with explanations, outlining why it's best to proceed in a particular way. This was instrumental in comprehending the standard and saving a considerable amount of time during the learning process.

Report Generation

The primary purpose of the data collected is to generate reports. These reports are automatically created based on the information received from medical devices over a specific period. They should reflect the indicators throughout the cycle and highlight potential issues.

Initially, the logic for generating reports was relatively straightforward, but it became increasingly complex over time. Different devices monitor various indicators, and a change in the value of any of these indicators can signal a potential issue. Various types of reports rely on different indicators, and we aimed to provide a universal solution that wouldn't overwhelm our already extensive codebase. In the end, we managed to account for numerous conditions for each value and proposed an extremely flexible solution.

API for Mobile Applications

To make it convenient for patients to monitor their health, numerous mobile applications are used to collect data for our system. We developed a universal API through which various applications can exchange data.

For this purpose, we actively utilized Grape, a REST-like API infrastructure for Ruby. It is designed to work with Rack or complement frameworks like Rails and Sinatra. Grape boasts a multitude of built-in features tailored for creating APIs, making it our preferred choice over traditional Rails for data exchange tasks.

Doctor's Dashboard

Within the system, there are separate applications for the doctor and the patient, each with distinct functionalities. These applications had outdated interfaces, and they didn't always function correctly. Our task was not only to develop new functionalities, such as reports but also to support the team in creating an API for the new frontend of the medical service.

The old dashboards were partially rendered on the backend and partially on React, leading to code chaos and numerous issues. Currently, our in-house team is working on fully migrating the frontend to React, and we are assisting them in this transition.

Technology Stack

One of the primary tasks during the initial stages of our work was refactoring the Ruby on Rails App. Due to outdated software versions, we couldn't utilize new tools, so our first step was to upgrade Ruby from version 2.3.8 to 2.7.7 and Rails from version four to five. After doing code refactoring for a telehealth platform, we were able to begin using certain libraries that were incompatible with the old version, such as dry-rb. Dry-rb is a system of libraries for implementing common programming patterns in Ruby, as well as advanced functional programming patterns. For instance, dry-monads elegantly implements the Monad pattern, which controls the execution sequence of operations with side effects. A Monad is a functional programming pattern that defines rules for the sequential execution of operations considering the context (the so-called effects) of these operations. For example, a complex business transaction, where the execution of each subsequent step depends on the successful completion of the previous step. In functional programming terminology, the transaction becomes a Monad, and the possibility of failure in the execution chain is the context, with information about potential failure being the effect.

We use RabbitMQ as the message broker. This open-source tool helps organize message queues between two applications and provides temporary storage. Modules within the system exchange data through it, and it assists in processing data received through the interfaces of the personal dashboards and forming tasks.

Results

We continue to work with PMT online and support the telehealth and remote patient monitoring system. Over time, our presence on the project has grown, and we assist the client's in-house team, even participating in the technical interview process for new developers.

Clients choose Evrone for remote patient-monitoring software development due to our extensive experience and willingness to share our expertise. We not only solve the tasks at hand but also elevate the overall level of the development team by contributing to the client's knowledge base. We provide guidance on optimizing and configuring development and help in implementing the plan. If you have a request for building a remote patient monitoring system or refactoring telemedicine services, please reach out to us, and we will be sure to help you create a successful project.