Rostelecom releases the first version of Medialog 2.0
The first Medialog 2.0 release adds a microservice architecture, modular configuration and integration with state healthcare information systems.
Contents
On 22 July 2026, Post Modern Technology, part of the Rostelecom Health cluster, announced the first release of the Medialog 2.0 medical information system. The new version uses a microservice architecture and open-source components and offers modular configuration for a clinic’s processes.
According to the company, the previous version operates in more than one thousand medical organisations and supports over 40,000 workplaces annually across Russia and CIS countries. At that scale, moving to a new architecture is not merely a product update. It is a migration programme for distributed organisations with sensitive data and continuous operations.
What has changed in the architecture
In a monolithic system, functional areas are tightly coupled and often released together. A microservice approach separates them into independent components with defined interfaces. Scheduling, billing, laboratory workflows or analytics can then evolve without one large release of the complete product.
Medialog 2.0 is presented as a modular system adaptable to an organisation’s size and specialism. Employees receive a web interface, while customers are offered built-in tools for extending functionality. The Pulsar development platform behind the product is included in the Russian software register.
The provider also describes complete process logging, resilience, integration with state healthcare information systems and alignment with industry standards.
Why modularity does not mean a simple migration
Service separation improves flexibility but adds distributed dependencies. A single application becomes a collection of APIs, queues, configuration services, identity controls, traces and data stores. A failure may be partial: a patient record remains available while delivery of a result to another system is delayed.
Before transition, an organisation needs an inventory of:
- current modules and customisations;
- external systems and exchange formats;
- roles and access matrices;
- reference data and synchronisation rules;
- reports used in mandatory processes;
- critical user journeys;
- retention and audit requirements.
Without that inventory, a new platform may launch technically while failing to reproduce an important part of daily operations.
Integrations become part of reliability
A medical information system interacts with laboratory equipment, diagnostic systems, finance services, state platforms and internal analytics. Each interface has its own response times and retry rules.
A resilient integration requires versioned contracts, operation identifiers, idempotent retries and a queue for temporarily unavailable recipients. The audit trail should show not only a technical message but the state of the business operation: created, delivered, acknowledged or awaiting manual attention. Our guide to API integration architecture covers these foundations.
What to verify in a migration pilot
A pilot should cover an end-to-end journey, such as an appointment through to a diagnostic result, rather than one screen. Tests should include:
- Data migration and completeness checks.
- Role behaviour, including temporary staff substitution.
- Exchange with every system in the journey.
- Duplicate and delayed messages.
- Audit coverage for data reads and changes.
- Performance during a morning or shift peak.
- Backup and restore.
- Rollback to an agreed point after an unsuccessful migration.
Degraded operation needs a separate test. One unavailable service should not hide data already accepted or block every other function without a clear message to the user.
Security of medical data
A domestic technology stack and a place in a software register matter for procurement and compliance, but they do not describe the actual security of an implementation. A customer still needs to verify segmentation, administration, secret storage, component patching and export of events to monitoring systems.
Logs deserve particular attention. They support investigations but may contain patient identifiers and operational details. Retention periods, stored fields and access to the log platform must be restricted by policy.
A recovery plan must be demonstrated through restore tests rather than the existence of a backup. RPO, RTO and verification scenarios are covered in our guide to backup and fault tolerance.
Practical conclusion
Medialog 2.0 reflects a wider move in industry-specific enterprise systems towards modular web platforms with open interfaces. This creates more options for integration and incremental development.
The main risk is not the choice between a monolith and microservices, but the quality of the transition. An organisation needs a dependency map, a measurable pilot, a compatibility plan and verified recovery. Those controls turn an architectural upgrade into an operational improvement rather than a new interface over old limitations.
Primary source: Rostelecom: first release of the Medialog 2.0 medical system
