
Janne Pullat
Head of the Health Data Unit at Metrosert’s Applied Research Center
Every year, Estonia produces new health technology solutions promising to make healthcare more efficient, faster, and more accurate. There is no shortage of ideas, developers, or technological capability. Yet, only a few of them reach everyday use. A large portion remains stuck as pilot projects or within testing environments.
This is often interpreted as conservatism within the healthcare system or a resistance to change among healthcare professionals. However, the actual reason is usually far more practical: solutions tend to be developed without sufficient consideration for healthcare workflows and quality requirements. Too often, the focus is solely on what the technology can do, rather than how the solution fits into existing workflows and what the end-user’s daily reality looks like.
Implementing a new digital solution is never just about launching software. Every new solution intervenes in an existing clinical process and must fit into a system that encompasses treatment guidelines, documentation requirements, chains of accountability, audit trails, and data protection principles. If a solution does not align with these elements, it is inevitably treated as a “side project” rather than a natural part of the healthcare system.
Innovation and Responsibility
Health technology developers must understand that healthcare institutions are not simply organizations that use IT systems. They are institutions with rigorous quality systems where work is inextricably linked to patient safety and legal liability. Therefore, even a seemingly simple change—such as introducing software with a new function—can necessitate updating documentation processes, training staff, amending quality manuals, and, in most cases, updating accreditation procedures.
This does not stem from an opposition to innovation. On the contrary—the healthcare system must be cautious regarding changes, as every decision impacts patient safety and treatment outcomes.
For example, an AI algorithm might help a radiologist detect potential lesions on an X-ray or support a doctor in making a diagnosis. Technically, such a solution may work perfectly. For the hospital, however, practical questions immediately arise:
- Should the algorithm’s recommendation be documented in the patient’s medical record?
- Does the doctor need to confirm it, or can the system take it into account automatically?
- Will it be possible later to understand what role the algorithm played in the decision-making process?
- And finally: who is responsible if the algorithm’s recommendation proves to be inaccurate?
These are much more than mere legal details.
Reducing or Increasing the Burden?
The creator of any new solution must also be able to demonstrate how the technology streamlines daily operations. Does the implementation reduce duplication or create an extra step in the process? Does documentation become clearer, or does it add a new administrative burden?
For instance, a new digital solution might require a doctor to provide separate confirmations or data entries in addition to filling out the standard medical history. In such a case, the technological “innovation” may simply manifest as an additional administrative hurdle in daily work.
Data quality is just as important as the technology itself. If a health tech solution relies on health data or an algorithm, it must be clear where that data originates and how it has been processed.
An algorithm might be trained on data from a very specific patient group. In that case, it might not provide equally reliable results in other hospitals or for patients with different health profiles. Therefore, it must be possible to understand the data upon which the technology bases its conclusions and the limitations of that data.
Fertile Ground for New Solutions
Today, the future of data usage at the European level is being shaped by the European Health Data Space regulation. Its goal is to create common standards for the secure use and exchange of health data. More unified rules could open up a significantly larger market for Estonian developers and simplify the adoption of solutions across different countries.
However, this also means that solutions must be developed in a way that accounts for data quality, security, and liability from the very beginning. The earlier these issues are considered—and the earlier end-users (doctors, healthcare institutions, and organizations familiar with healthcare quality frameworks) are involved—the higher the probability that a technological solution will move from a pilot project into actual clinical use.
The Health Data Unit at Metrosert’s Applied Research Center was established specifically to support health tech developers in these matters. The unit helps developers assess and design solutions so they fit into healthcare workflows, data usage patterns, and quality requirements, allowing them to reach actual use more successfully. This enables developers to avoid typical pitfalls where a technically functional solution fails to align with the actual operational logic of the healthcare system.
Estonian healthcare is actively seeking solutions that help achieve more with limited resources. If technological solutions are developed from the outset with the logic of the healthcare system in mind, they have a much better chance of transitioning from pilots to everyday practice. Such solutions have the real potential to make healthcare more efficient—both in Estonia and across Europe.
