We developed a medical data platform for a company to store, manage and edit endoscopic image and video data. The focus was on secure medical data management, taking clinical requirements into account, and video viewing functions. The project also covered long-term archiving and anonymisation of sensitive datasets.
Initial situation
A company needed a solution for handling endoscopic image and video data. The task was to create a platform that supports the storage, management and editing of this data while also covering topics such as long-term archiving and anonymisation.
To do this, we had to capture the specialist requirements from the clinical environment and turn them into a technically viable foundation. As a result, one focus right from the start was requirements engineering, meaning the structured identification and alignment of requirements between the business side and development.
Solution
We took on the system architecture for secure medical data management and worked out the clinical requirements as part of the requirements engineering process. On this basis, we developed the application as a full-stack solution with ASP.NET MVC and implemented video viewing functions in particular.
The project also included the storage, management and editing of endoscopic image and video data, long-term archiving, and anonymisation. The implementation was organised over the period from April 2014 to May 2016 with a team of 4 people. In terms of content, the project combined web development with requirements relating to data storage and specialist processes.
Result
What we delivered was a completed medical data platform for endoscopic image and video data. Its functionality included storing, managing and editing this data, including long-term archiving and anonymisation, as well as a solution for video viewing.
The project ran from April 2014 to May 2016 and had a duration of 26 months. It was implemented and completed by a team of 4 people.
Technology
C# and the .NET Framework were used as the foundation of the application. We used ASP.NET MVC for the full-stack development of the web application and in particular for video viewing.
TypeScript and KnockoutJS were used for the client-side logic and the user interface. Telerik was used to support UI components. Firebird and MS SQL Server were used for data storage; databases provide the structured basis for storing, finding and processing information. We used TFS to organise the development work.
Why a medical data platform is built this way
A medical data platform must do more than simply store information; it must integrate it into meaningful specialist workflows. Particularly with image and video data, it is typically not enough just to save files. What is needed are functions for structured management, targeted retrieval, editing and controlled provision. If long-term archiving and anonymisation are also required, the demands on the data model, user interface and operation increase significantly.
For tasks like these, a browser-based specialist application from web development is often a suitable approach. The advantage is that workstations can access a shared application without complex local installation. A specialist application is software that supports a specific business or work process. Especially in environments with different roles, workstations and approvals, a central system is often easier to maintain than many separate distributed solutions.
A clear separation of responsibilities in the architecture is also important. In projects like this, the user interface, business logic and data storage are typically structured so that changes in one area do not unnecessarily affect the others. This makes later enhancements easier and helps to implement complex requirements in a transparent way. When image and video data are involved, this also affects the question of how metadata and the actual media files are brought together. Metadata is descriptive information, for example about the source, point in time or assignment of a dataset.
The protection of sensitive information is another key factor. In a medical data platform, security means not only access protection, but also well-designed processes for display, editing, export, logging and anonymisation. Anonymisation means removing or changing personal references in such a way that direct identification is not readily possible. How far this needs to go in a specific project should be assessed from both a specialist and legal perspective; for legal assessments, coordination with data protection officers or legal advisers is recommended.
Data storage is also a central design element. In similar projects, structured specialist data, references to media content and search criteria need to work together reliably. That is why sound database development is often required so that the platform not only works today, but also remains manageable when changes are made later.
How projects for medical data platforms are implemented
In projects of this kind, the work typically starts with a clear understanding of the specialist objective. Decision-makers, the business side and development need to clarify together which data will be processed, which workflows the system should support and which roles will work with it. Especially in environments involving medical information, it is risky to start too quickly with individual screens or detailed functions without understanding the overall process.
That is why requirements engineering is an important step. This means the structured capture, review and alignment of requirements. The aim is not just to collect wishes, but to make dependencies, terminology, constraints and open points visible. For a platform for image and video data, this often includes questions about the origin of the data, search and review processes, editing steps, archiving and anonymisation.
On this basis, the specialist and technical concept follows. Typically, this defines which parts will be implemented as a web application, how the data storage will be structured, which interfaces are necessary and how permissions will be designed. An interface is a defined connection through which systems exchange data. Particular care is worthwhile at this stage because many later risks stem from unclear fundamental decisions.
During implementation, larger projects are usually developed step by step and coordinated regularly with the business side. This is especially important when the application has to display or edit complex content, such as media holdings with additional specialist information. Regular feedback reduces the risk of developing past the actual need. In parallel, quality assurance should be prepared. Quality assurance includes methods used to check whether functions work as intended and whether requirements are met in a traceable way.
Before go-live, projects like this typically bring together data, roles, workflows and operational matters once again. This also includes topics such as permission concepts, logging, backups and recovery. Depending on the framework conditions, operation can take place in a company's own environments or in the cloud; if required, we also support hosting and operation in the Microsoft Cloud. For an initial assessment of a project, a project check can be useful if a description or specification document is already available.
Typical pitfalls in systems for sensitive media data
In platforms for sensitive image and video data, the biggest risks often lie not in individual functions but in overlooked constraints. One common pitfall is an overly broad description of requirements. If it remains unclear who may view, edit or anonymise which data, conflicts later arise in permissions, the user interface and process logic. These points should be named early and aligned from a specialist perspective.
Another critical area is handling different types of data. Such systems often have to bring together structured datasets, file content and descriptive information. If the data model is not designed cleanly for this, search, assignment and later enhancements become unnecessarily complicated. The data model is the specialist and technical structure according to which information is stored and linked.
Interfaces are also often underestimated. As soon as data needs to be taken from other systems or returned to them, it must be clear which content is available in what quality and how deviations will be handled. Without clear rules, media discontinuities, duplicate entry or incorrect assignments are likely. That is why import, export and validation should be considered from the outset. Validation means checking whether data is complete, plausible and present in the expected format.
Later operation is no less important. A platform for sensitive information typically needs traceable access, reliable backups, clear responsibilities and a process for changes. Anyone who only looks at operations towards the end often has to make up fundamental decisions under time pressure. This also includes questions about monitoring the system. Monitoring here means observing the technical condition of the application so that problems can be identified early.
The issue of protection requirements also deserves particular attention. Wherever medical data is being processed, security and data protection are part of the design from the very beginning, not just an add-on at the end. Which organisational and legal measures are required must be assessed separately in the specific context; this is not a technical decision alone and should be coordinated with data protection officers or legal advisers.
Anyone planning a similar project should therefore look not only at functions, but at the interaction between specialist process, data, security, operation and further development. For an initial assessment of scope, our team at ballmüller solutions can help with a no-obligation initial consultation; alternatively, the cost calculator provides rough guidance.
Frequently asked questions
What do the costs of a medical data platform depend on?
The costs depend above all on the specialist scope, the roles and permissions required, the complexity of the data storage, interfaces, and requirements for security, archiving and operation. Additional factors include the quality of the existing requirements documents and whether existing data needs to be migrated. For a rough assessment, the cost calculator is suitable; for more specific documentation, a project check is more appropriate.
How long does it typically take to implement such a system?
That depends heavily on how clearly the requirements are already described and how many specialist discussions are needed during the project. Interfaces, migration needs, approval processes and the desired level of maturity at launch also have an impact. Especially with sensitive data, time should be allowed for specialist clarification, testing and operational matters. A more reliable estimate usually requires a concrete view of the project.
Which approach makes sense for a project like this?
A sensible approach is usually one that starts with a structured requirements capture process and develops from this a concept that is viable both from a specialist and technical perspective. The solution is then implemented step by step and coordinated regularly with the responsible stakeholders. This makes it possible to identify open points early and take decisions in a transparent way. It is particularly important to consider the specialist process, data model, permissions concept and later operational requirements together rather than separately.
Which risks should clients keep a particularly close eye on?
Typical risks are unclear requirements, underestimated dependencies on other systems, operations being considered too late, and incomplete rules for roles, approvals or anonymisation. Equally critical is a data model that does not sufficiently support later search and editing processes. For topics such as data protection, retention or other legal requirements, the assessment should not be made on a purely technical basis, but together with the responsible internal departments or with legal advice.
What needs to be considered when operating such a platform?
What matters are clear responsibilities for maintenance, changes, user management, backups and monitoring of the technical condition. Traceable access, regulated approvals and a process for dealing with incidents are just as relevant. If interfaces are connected, their failures and changes must also be taken into account. Depending on the framework conditions, operation can take place in the company's own environment or in the cloud; both should be considered conceptually at an early stage.
