Navigating the territory between cutting-edge AI innovation and the rigid constraints of MDR and the AI Act requires a fundamental shift in architectural philosophy. Jan Hauser, CEO UK at Applifting, discloses in detail why embedding regulatory rigour into your MVP is the only way to transform a high-risk prototype into a scalable, global healthcare solution.
What technical challenges do you see when building AI-driven healthtech products that must comply with both the AI Act and MDR/IVDR? How has this influenced your application development?
Our ability to efficiently deliver healthtech products and build client trust stems from the close parallels with the Fintech sector, where Applifting has been active since its inception. Requirements for data security and encryption (both at rest and in transit), the emphasis on user consent, KYC processes, or the need for local storage and on-premise data management within specific jurisdictions are essentially identical to the demands of the financial world. We often operate in a mode where – as an external vendor – we never actually access sensitive PII data. This is a standard we automatically carry over into healthcare projects.
However, when developing AI applications, it is necessary to look deeper into the very nature of how we use LLMs. Given that these are “fuzzy” systems from a determinist perspective, where one cannot guarantee an identical output for n identical inputs, we approach their integration into workflows with maximum deliberation. We only deploy AI in parts of the algorithms where it brings indisputable value and cannot be replaced by a deterministic system. During the design phase, we place extreme emphasis on this distinction, which many people fail to realise. The issue of accountability is closely linked to this; we work with patient data where an erroneous output can have real-world impacts on human health. Therefore, we build systems that are as transparent as possible. It must be perfectly clear how the system arrived at a result, and there must always be a specialist at the end of the process to validate the output. The goal of our solutions is not to replace the doctor, but to allow them to focus on their specialisation by easing their regular routine.
Within our client partnerships, we formally aim to offload the control of regulatory requirements to the IP owner – however, our Product Managers act as experienced sparring partners, possessing an in-depth mastery of these demands. Setting aside the client’s procedural obligations, the European AI Act emphasises transparency, technical documentation, and the traceability of logs – requirements that are a natural “default” for us within a standard SDLC. At the same time, we strictly adhere to the principle of human oversight, whereby AI must not make autonomous decisions regarding human health. We take a similar approach to MDR and IVDR; although clinical certification is the client’s responsibility, as their technology partner, we monitor whether a web or mobile application has crossed into the definition of a Medical Device. This is particularly crucial for more complex projects, such as drug management hardware or navigation systems for the visually impaired.
We also reflect our responsibility in healthtech within the actual use of AI tooling during development. We have a clearly defined internal policy and transparently set rules for client collaboration. Here we emphasise a critical review of every line of code generated by models and precise test coverage. Overall, it can be said that the main innovations arriving with the era of AI in medicine represent – for us – three primary pillars:
- An emphasis on workflow stability and the use of AI/LLMs with strict guardrails that limit the unwanted “creativity” of the models.
- Ensuring full transparency of the process and human oversight, so that the system is easily understood and controllable by a specialist.
- Rigorous adherence to procedural development standards that form the essential basis for technical documentation under MDR and the AI Act.
What are the most common forms of technical debt you see? When building a healthtech startup from the ground up, what do you recommend founders consider technically from the MVP stage, so they don’t have to rewrite everything later for compliance?
When building a healthtech startup from scratch, there is no simple answer that provides a universal checklist for an MVP implementation. Unlike standard applications, these software solutions – again, much like those in Fintech – must be compliance-first. For this reason, a two-phase approach is often chosen: first, creating a functional prototype for closed internal testing and validating the core concept using mock data. This is essentially a quick and dirty proof of concept with minimal focus on the UI. Only after validation do we move to a fully regulatory compliant process for the MVP phase. Regarding specific recommendations for a healthtech MVP, it is crucial to keep the following points in mind:
- Technology stack: Avoid choosing niche technologies with a short track record. In a regulated environment, the risk of end-of-life support is critical. Not just for stability, but for the availability of security patches. Betting on robust, proven technologies is fundamental.
- Security and data management: Have a clear understanding of what data you are processing and why, right from day one. You must precisely specify who manages sensitive data and seek ways to minimise the regulatory burden early on; for example, by building your solution as an overlay on an existing system.
- Audit Trail: From the MVP stage, you must technically account for the fact that every access to sensitive data or change in AI decision-making must be logged in an immutable form. Retrospectively “bolting on” auditability to a finished system is one of the most expensive forms of technical debt.
- Platforms and over-engineering: You need a cohesive view on where the MVP will run, as mobile development, for instance, is more costly than web. While it is easy to design a complex architecture that doesn’t make sense for an MVP, you must always consider scalability so that core components don’t require a complete rewrite during growth.
- Interoperability and standards: Even in the early stages, it pays to follow healthcare data exchange standards (e.g. FHIR). If you build a closed “data island”, you will hit a massive brick wall the moment you try to integrate with hospital systems.
- Regional readiness (Scale-ready): The architecture should strictly decouple the identity and data management layers from the business logic. Compliance requirements differ between the EU (GDPR/MDR) and the USA (HIPAA). If a system is hardcoded for only one jurisdiction, expansion becomes a technical nightmare.
- Targeted management of technical debt: Tech debt will always exist, but in healthtech, it must be constructive and traceable. You must be aware of it and have a remediation plan, because in a regulated environment, undocumented debt can halt your progress during an audit or certification.
Therefore, the foundation of success lies in understanding that in healthtech, compliance is not an extra feature to be added later. It is an inherent property of the product. While a well-built MVP on solid technological foundations requires a bit more discipline at the start, it ultimately saves founders years of refactoring and millions in costs related to legal and technical compliance.
We are also interested in the collaboration between Applifting and Telus. From your perspective, could you compare the legislative challenges and the overall context of healthtech development in the Canadian and European landscapes?
Thanks to our partnership with Telus Health, we have a unique comparison between the European and North American markets. While in the European Economic Area we rely on the unified framework of GDPR, which facilitates the movement of data between member states, the Canadian environment is significantly more fragmented. Requirements for data residency and privacy protection vary from province to province (e.g. PHIPA in Ontario vs. Act 25 in Quebec), which places extreme demands on system architecture and interoperability.
The main challenge we addressed with Telus was the synchronisation and harmonisation of patient records (EHR/MHR). Clinics often utilise diverse systems that do not communicate with one another. Our role consisted of transforming this data into standardised formats, such as FHIR, which enabled the seamless sharing of information across the entire organisation. In parallel with the Telus collaboration, we have also been developing these experiences through internal initiatives. These utilise private ledger technology to enhance interoperability, traceability, and control over the sharing of sensitive data – a direction that modern healthtech is inevitably taking.
Beyond the data layer, we focused on the sector’s most pressing issue: staffing shortages. Optimising administrative processes using AI – for instance, by implementing voice assistants for routine tasks or automating workflows – led to time savings of up to 20% in our projects. In real terms, this equates to approximately 10,000 hours saved annually per clinic, which staff can then dedicate to direct patient care instead of filling in spreadsheets.
From a startup perspective, while the EU market is more accessible for a quick launch due to its legislative unity, the Canadian and US markets offer enormous potential for those who are not deterred by the complexity of local standards. Our recommendation for founders is to account for these standards (such as FHIR or the specifics of data residency) from the very beginning. Doing so will dramatically facilitate future overseas expansion.
