We developed a web-based medical imaging platform for the operating theatre for a company. The platform provides medical apps for image, video and streaming. Our contribution covered architectural concepts for agile teams, the development of highly available microservices, and work on an event bus for exchanging events between parts of the system.
Initial situation
A company needed a web-based platform for the operating theatre to provide medical apps for image, video and streaming.
This required a technical foundation suited to a distributed application landscape with several teams. Our responsibilities included architectural concepts based on Domain-Driven Design and an event-driven architecture for agile teams.
Solution
We developed architectural concepts for agile teams and implemented them in the development of key platform components. One focus was on highly available microservices in C# and .NET Core, including a medical image archive. Microservices are small, functionally separate services that together form a larger application.
We also developed an event bus using RabbitMQ and Apache Kafka. An event bus distributes business events between parts of a system so they can work together with loose coupling. In addition, we led architecture boards and provided mentoring. The implementation ran from June 2016 to March 2019 with a team of 7.
Result
The delivered solution was a web-based platform for the operating theatre, providing medical apps for image, video and streaming.
Our project contribution included architectural concepts for agile teams, highly available microservices, a medical image archive, an event bus with RabbitMQ and Apache Kafka, as well as leading architecture boards and mentoring. The project ran for 34 months and was completed in March 2019.
Technology
C# and .NET Core were used to develop highly available microservices.
- Microservices as an architectural approach for functionally separated services within the platform
- DDD for structuring the domain from a business perspective; Domain-Driven Design organises software around business logic
- CQRS for separating read and write operations; this can make complex business processes easier to structure clearly
- RabbitMQ and Apache Kafka for the event bus
- Angular for the platform’s web interface and its applications as part of web development
- Service Fabric for running distributed services
- Azure DevOps to support development
- T-SQL for database-related work
- OIDC, MFA and PKI for sign-in, additional protection and certificate concepts
- SpecFlow for behaviour-driven testing; this describes requirements in a form that business stakeholders and the team can both read
Why a medical imaging platform is built this way
A medical imaging platform for clinical processes or workflows close to the operating theatre usually has to bring together very different requirements. On the one hand, specialist departments expect a consistent interface through which images, videos, streams and other functions can be accessed. On the other hand, such systems are often not created as a single monolith, but as a combination of several functionally distinct components. A monolith is an application in which many functions are tightly combined in one large system block. Especially when several teams are working on a platform, a clean functional and technical separation is usually helpful.
For projects like these, an architecture with functionally separated services and clearly defined events is often a good fit. The goal is not technical complexity for its own sake, but change that remains manageable. If one subsystem manages images, another provides media streams and another checks permissions, these parts should be as loosely coupled as possible. Loose coupling means that changes in one part do not unnecessarily trigger changes in many others. That makes coordination, further development and operations easier.
Business modelling is also important in a medical imaging platform. Domain-Driven Design structures software around business terms and responsibilities rather than purely technical layers. This makes it possible to map rules, states and events more closely to the actual processes. This is especially useful when different stakeholders from business departments, product management and development need to use the same terminology.
Availability and security are just as important. In projects like these, sign-in, roles, protected communication and robust operating processes all need to be considered from the outset. OIDC is a standard for sign-in via a central identity service. MFA adds another proof step to sign-in. PKI organises digital certificates for trusted communication. The specific requirements that apply in each case should also be reviewed for sensitive data with the relevant teams responsible for information security, data protection and legal matters.
In technical implementation, database development, interfaces and event-driven communication often come together. An event bus transfers business events between services. This is particularly useful when information does not simply appear in one screen, but is processed by several parts of the system. For decision-makers, the key issue is usually less the individual technology than whether the architecture, data model and operations can support future extensions without the platform having to be fundamentally rebuilt every time something changes.
How a platform for image, video and streaming is created
A project of this kind does not typically begin with selecting individual tools, but with a shared understanding of the task. The first step is to clarify which business processes need support, which user groups will work with the platform and where the system boundaries lie. For a platform for image, video and streaming, it is also important to understand where data is created, how it is provided and which other systems are involved. Only on this basis can a robust target architecture be described.
This is usually followed by defining the business domains and their responsibilities. Terms are aligned, responsibilities assigned and interfaces described. Interfaces are defined handover points through which systems exchange data or functions. In distributed systems, these handover points should be specified precisely at an early stage so that teams can work independently without developing past one another. Especially when several parties are involved, it helps to document architectural decisions in a way that can be understood and to review them together regularly.
During implementation, the platform components are developed step by step and continuously aligned. Central services often come first, for example for sign-in, core business functions, data storage and the exchange of events. Interfaces and further functions are then built on top of these. For browser-based business applications, web development is often the right path because functions can be provided and updated centrally. At the same time, future operations are prepared. Operations means not only hosting, but also monitoring, troubleshooting, approvals and controlled changes in the live system.
Quality assurance that checks both business logic and interaction is also typical. Alongside traditional tests, test scenarios phrased close to the business domain are becoming increasingly important. They help identify misunderstandings at an early stage. This is particularly relevant in complex platforms because errors often affect not just a single screen, but whole workflows across services.
Anyone planning a similar project should gather requirements in a structured way and have feasibility checked early on. For an initial assessment, the Project Check or a no-obligation initial consultation are good options. This makes it possible to clarify before commissioning which parts of the platform make sense first, how risks can be limited and which architecture suits the planned organisational setup.
Typical pitfalls in operations, security and interfaces
The biggest risks in projects like these often lie not in individual functions, but in the interaction of many parts. When a platform provides images, videos or streams, the user interface, business logic, data storage, identity management and operations all come together. Even small ambiguities at an interface can then affect several areas. That is why it is important to separate business responsibilities and technical responsibilities clearly.
A common pitfall is making detailed decisions too early without a robust overall picture. If, for example, individual components are optimised straight away before business boundaries and data flows have been properly described, friction between teams can easily arise later. A platform in which dependencies grow unchecked is just as problematic. Changes then become slow, testing becomes time-consuming and incidents become harder to isolate. A clear architecture with justified guardrails helps limit these effects.
Security should also be part of the architecture from the very beginning. This includes sign-in, the role model, protected communication, certificates and traceable access. In sensitive environments, it is not enough to add security shortly before go-live. At the same time, it is important not to confuse technical measures with legal assessment. Companies should review whether data protection, retention, access rights and other regulatory matters are addressed appropriately with their responsible specialist teams, a data protection officer or legal advisers.
In operations, it often becomes clear whether a platform has really been designed to last. Monitoring is about more than whether a server can be reached. It also involves whether events are being processed, whether individual services interact correctly and whether problems can be narrowed down quickly. A distributed service consists of several separate application parts working together. Such systems need clear logging, traceable approvals and operations that introduce changes in a controlled way. Depending on the project, an approach based on hosting and operations in the Microsoft Cloud may be suitable.
Anyone planning a similar platform should also bear in mind that external and internal systems are rarely equally stable or equally well documented from the outset. Interfaces change, data is inconsistent and responsibilities lie with different parties. That is exactly why an approach that closely integrates architecture, development, quality assurance and operations is worthwhile. If you are preparing such a project, we at ballmüller solutions can support you from the initial assessment through to implementation and with a structured start via a no-obligation conversation.
Frequently asked questions
What do the effort and cost of a platform like this depend on?
In projects like these, the main factors are the breadth of business requirements, the number and quality of interfaces, requirements for availability, the security concept, data storage, user roles and the desired operating framework. The question of whether a platform is intended to serve as a central entry point for several applications also has a significant impact on effort. For an initial assessment, we recommend the cost calculator or a Project Check based on an existing description.
What is a sensible way to approach a project for a medical imaging platform?
A sensible approach is to start by clarifying objectives, user groups, data flows and system boundaries. On that basis, the business domains, interfaces and architectural principles are described before implementation begins. In projects like these, close coordination between business stakeholders, product management, architecture and development is especially important. This makes decisions easier to understand and helps reduce later conflicts between the interface, data model, security and operations.
Which risks should be considered early on for image, video and streaming functions?
Typical risks include inconsistent data sources, unclear responsibilities, a high degree of dependency between parts of the system and a security concept that is considered too late. There are also requirements for sign-in, permissions, protected communication and reliable exchange between services. Business misunderstandings can also become expensive if terms and processes are not clearly defined. That is why architecture, the business model and quality assurance should be considered together from the outset.
What does the later operation of such a solution need to deliver?
Operations must support not only technical availability, but also monitoring, logging, secure deployment of changes and traceable error analysis. In distributed platforms, it is important that events, interfaces and services can be observed as one overall system. Anyone planning operations should also define identity management, certificates, approval processes and responsibilities at an early stage. The exact design depends heavily on the environment and protection requirements.
What role do architecture boards and mentoring play in projects like these?
In platform projects involving several parties, architecture boards help establish technical guardrails and keep decisions consistent. This prevents teams from solving similar problems in different ways and the platform from drifting apart unnecessarily. Mentoring also helps turn architectural principles into something understandable and practical in day-to-day work. For decision-makers, this matters because good coordination affects not only technical quality, but also collaboration, changeability and how manageable the system remains throughout the project.
