Relaunch of an Electronic Health Record system

Chayka Clinic

Chayka Clinics is a network of premium healthcare facilities with top-notch doctors, where you can get help for anything from a broken leg to a toothache.
To manage their operations, they use a custom Electronic Health Record System(EHR), built by a small in-house team of developers.

Challenges

The client brought us in as consultants: their dev team was slow to deliver new features, hiring new developers was tough, and even when they did hire, the new folks increased payroll without speeding up the delivery of critical business features. The business wanted to know why this was happening and how to fix it.

Business Needs

Improve the billing system

Build a meta-laboratory

Create a new, user-friendly interface for doctors

Solution

We realized it’d be faster and more effective to overhaul the technical architecture and processes by bringing in our own small dev team and implementing the new architecture hands-on—showing by example how to work more efficiently.

Adopted a standard data model based on FHIR (Fast Healthcare Interoperability Resources). Beyond the obvious benefit of keeping data in a unified standard, FHIR helped us dive into the medical domain. For example, studying the standard taught us that diagnoses need to be linked to specific body parts (e.g., “caries” on “tooth 22, tongue side”).

Built an event-driven model to allow relaunching the system in parts. For instance, if the business plans to open new clinics in Dubai, we could focus on integrating with local payment systems (mandatory for operations) without rewriting the medical components.

AstraShare

5 months

We built a service to check all risks of integrating AstraShare. The idea is simple: when Chayka’s doctors send patient data to another hospital or insurance company, they don’t need to print hundreds of pages of medical history. Instead, they can share it electronically or download a PDF to print themselves.

We created one big “medical record updated” event for all event-driven models, which our system then processed. But even this massive event had issues—about 0.5% of the time, it didn’t generate properly.

To fix this, we gave admins the ability to resend patient records to the service. The business loved the result: they got a new service and a team that knows exactly what’s possible and what’s not.

AstraLab — Meta-Laboratory

6 months

Chayka works with multiple labs, sending patients there and retrieving test results. Naturally, this process needed maximum automation.

Integrations like this are tricky: other systems are built by developers with their own ideas about the domain, data structures, and reliability of data transfer.

In the new architecture, we managed to build this module as a standalone service with a team of 4 developers in 6 months.

AstraDental

7 months

Once we proved we could speak the same language as Chayka’s business team and deliver work on time, it was time for bigger projects.

Our main goal from the start was to create a user-friendly interface for doctors.
‍
The problem? Doctors had to fill out patient records in a way that mirrored the database structure: select a patient, enter a diagnosis, type observations. Great for developers, terrible for doctors.

Back in the 1960s, a better format for clinical notes was developed—SOAP (Subjective, Objective, Assessment, Plan). Our new interface uses this format, speeding up data entry wherever possible.

Implementing this “live” was tough: patient records are the heart of the MIS. To avoid rewriting the entire working system, we focused on a small but exciting piece—dentistry.

This task was technically tougher than the others. We had to integrate deeply with the old system: add more data to the event stream, tackle technical debt in the streaming setup, and implement cross-authorization so users could switch seamlessly between the old and new systems.

To ensure seamlessness, we figured out how to embed our frontend into the existing one.

There are elegant solutions like micro-frontends, but we needed results fast, so we worked within the current frontend, setting aside our beloved Vue.js to work with React.

Outcome

We launched several cool services and solved some urgent business needs. But the big goal—“build a technical foundation and team that can predictably and quickly tackle business tasks”—wasn’t fully achieved.

This was a blow for us, but we don’t blame the client—it was a force majeure situation.

Could we have hit the big goal faster? Sure. We could’ve taken risks, like starting a major service without testing on a smaller scale, or pushed the product team harder to run more projects in parallel. But those steps would’ve raised risks beyond what we or the client were comfortable with.

Takeaway

Stepping back to our “big hypothesis”—that transforming a business’s tech is easier with a small, highly skilled dev team implementing changes hands-on—we think it mostly held true. Right now, we’re kicking off another similar project, and we hope to see it through this time.
‍
If you need this kind of help or just some awesome development work, ping Samat Galimov.