Paving the way for better healthcare services for patients with diabetes

Integrating with the EESZT

Rebuilding their diabetes management platform from the ground up opened endless possibilities for 77 Elektronika in the form of new features and improvements to their platform. The integration with Hungary's National eHealth Infrastructure (EESZT) was one of the improvements they had been looking forward to from the beginning. At the time, no other telemedical systems were communicating with the EESZT. Still, our client wanted to provide more ways for their users to improve patient-doctor relations.

They have been developing their platform more and more independently since we helped them bring their 10+ year-old outsourced service in-house. Yet, this integration needed more than they could handle, so they contacted us for help to ensure everything went as planned.

Integrational challenges

Dcont's new architecture, which we helped 77 Elektronika build in the past years, was proved to be open for new features without affecting the rest of the software. So, extending the web API with new modules wasn't part of the difficulties. However, we still faced several obstacles during development independent of Dcont's architecture.

Incompatible technolgies

From a technological standpoint, we met a significant challenge in EESZT's communication protocol since, at the time, .NET Core didn't have built-in support for using SOAP communication and SAML authentication that all EESZT modules required. This meant that we couldn't use any of the provided WSDL (Web Service Description Language) files to ease the integration.

On top of that, all the official sample applications were using obsolete or unavailable APIs since they were all implemented using earlier versions of the .NET framework.

Unprecedented requirements

In addition to the technological barriers, Dcont was the country's first telemedical platform to connect to the EESZT, implementing a module integration that was never used before.

In fact, the PHR (Patient Health Record) module was not even 100% ready, meaning we had to work tightly with the EESZT developer team to keep us up to date with their APIs. This also meant we had to adapt to scope changes for reasons beyond our control.

Close deadline

Another thing that made the integration process more difficult was our tight schedule. Since this integration was unique, our client already made plans for a grand reveal during their presentation at the annual diabetes congress, coming in just a few months in the early days of fall. We had pre-planning based on our early meetings with core EESZT developers, but we could only start working on the integration actively during the summer.

The fact that this was the first time Dcont tried to connect to the EESZT made our schedule 1-2 weeks shorter since we had to calculate in the audit that every first-time integrator must go through before getting access to the production environment.

Integrationail milestones

Apart from the integration, the goal was to keep the core architecture intact so the developers at 77 Elektronika could keep maintaining their software independently.

Our first task was creating a structure where all the EESZT-related functionalities could live. We separated all these logic from the core system so they never leak into other layers of the architecture. This way, our client would only have to touch these parts of the platform if they wanted to introduce new features related to the integration.

Connecting to the EESZT requires plenty of administrative work to ensure no one can access sensitive healthcare records randomly. Our partners at 77 Elektronika always handled these on time so we could focus on the technical side of the integration.

Sending the first request

The first step for every integrator is to solve the task of authentication. The system supports different types of authentication for patients and doctors alike, but since, in our case, the data flow was an automated synchronisation between two services (S2S) without a person controlling the process, we had to implement a special certificate-based authentication method.

As mentioned before, this first step was the hardest to take since SOAP communication support was basically non-existent in our .NET version at the time, and since we had a rapidly approaching deadline, we couldn't just wait for Microsoft to come out with an update and solve the problem for us.

We could only use the provided WSDL files partially to generate the basic schema for our API requests, so we didn't have to start from absolute zero.

Although the sample applications didn't match our stack, they provided an excellent outline for our solution. With the lack of SOAP-related APIs, we had to implement a custom client where we manually constructed the XML envelopes and HTTP requests.

Finding a common language

Until then, EESZT has worked solely with document files in PDF format. This was the first time someone tried to send structured data to their system, so we had to make sure we used a standard that all future integrators could understand.

This standard was HL7 FHIR (Fast Healthcare Interoperability Resources), which is an interoperability standard designed to enable health data, including clinical and administrative data, to be quickly and efficiently exchanged.

77 Elektronika stores a lot of supplementary information about their stored blood glucose values, some of which are custom to their service or measurement devices. This helps patients get better treatment based on their medical records.

We put great effort into including as much useful information as possible in FHIR's Observation resource, which can record vital data, measurements, or test results. It is used to support clinical diagnosis, monitor progress, and evaluate patient characteristics.

After designing the schema, it was a matter of implementing mappers that converted Dcont's custom blood glucose records to the desired FHIR format.

Implementing data flow

Synchronising data with the EESZT is a scheduled automated process usually running during the evening, as it was the recommended solution for all PHR data. We solved this using .NET's hosted background services with configurable scheduling so 77 Elektronika can fine-tune the time of the synchronisation process.

The first time we synchronise a patient, we only send measurements made in the past 3 months, as that's the relevant period from the perspective of the patient's therapy.

We keep track of all synchronised data to optimise the process, ensuring we never process the same measurement twice. As a result, following the initial synchronisation, we only send new measurements taken the day before. This guarantees that all patients have their profile up to date with the EESZT for the next morning in case they go for a doctor's visit.

If someone needs their data instantly in the EESZT, we implemented an option in the patient profile section on Dcont to manually initiate a synchronisation for their measurements.

A new era for diabetes treatment

Being first in something is always exciting, but it comes with its unique challenges. Since there are no precedents, you have to figure everything out by yourself without any help coming from outside.

Implementing the integration for the other EESZT modules was considered standard practice at that point, along with advanced documentation, example source codes, and already discovered edge cases. The wiki pages created for every module to help developers in the integration were basically empty for ours. Occasionally, we could contact the maintainers for questions, but we ended up doing the heavy lifting.

We managed to finish on time for the audit and released a version in production before the MDT conference. The presentation was a success, and our client got a lot of positive feedback and appreciation from medical and technical actors alike.

This integration opened the gate for structured medical data in our national health record system. It raised interest in other telemedical system maintainers to integrate with the EESZT, benefiting the end users.

And why does this all matter? As stated on a diabetes-focused website in their article about this integration:

• With the connection of Dcont eDiary to EESZT, blood glucose data measured at home with the Dcont device becomes accessible to all authorised healthcare professionals.
• Healthcare professionals, for patients using the system, no longer need to retrieve data from the blood glucose meter's memory or scroll through the patient's diabetes logbook; they can simply check the values on the familiar EESZT interface.
• Graphs, tables, and statistics generated from the data assist in analysis.
• Diabetic patients can consult with their doctor over the phone.
• Patients can share their blood glucose data with doctors other than their primary physician.
• Personal doctor-patient meetings that can be replaced by telemedicine visits can be avoided, saving time for both the patient and the doctor.
• It assists the doctor in issuing medical certificates.
• With the help of graphs, tables, and markers, patients can quickly review and manage their diabetes.

This update enabled better quality treatment in healthcare for patients living with diabetes while helping doctors do their job more efficiently.