I built a cardiac monitoring app. A Polar H10 chest strap streams ECG data over Bluetooth, a cloud backend processes the signal, and a physician sees the results on a mobile screen. It works. I was proud of it.
Then I started working in medical device software professionally. I spent the next few weeks going back through my own codebase and asking what it would actually take to bring something like this to market legally. I work at the intersection of signal processing and medical device software, and the answer turned out to be more structured and more interesting than I expected. Every layer of the architecture raises a different regulatory question. This post walks through each one.
Before I get into the architecture, let me address the question I would have asked reading a post like this: why does any of this apply to me?
You do not choose whether your software is a medical device. The intended use does. The moment your software makes a claim directed at a clinical decision, detecting a condition, supporting a diagnosis, informing treatment, it enters medical device territory under the EU Medical Device Regulation (MDR) regardless of what you call it or how you distribute it. A fitness app that shows heart rate is not a medical device. An app that displays cardiac parameters to a physician assessing heart health probably is. The code can be identical. The claim is what changes the classification.
Ignorance is not a defense. Understanding where the regulatory boundary sits is what lets you make a deliberate choice about which side of it you want to be on.
The Architecture
The architecture diagram above shows how the pieces connect, but it helps to walk through the user journey once before getting into the regulatory analysis. The measurement starts with the patient wearing the Polar H10 chest strap. The Malik app on the physician’s smartphone connects to the sensor over Bluetooth and runs a 5-minute ECG recording session. During that time the app collects raw ECG data locally and displays a live waveform so the physician can verify signal quality. When the session ends, the physician initiates the upload. The measurement is sent to Google Firebase, where a cloud function triggers automatically and runs the signal processing pipeline: noise reduction, beat detection, and calculation of cardiovascular parameters. The results are written back to the database and the app displays them to the physician in the same session.
That is the full loop. One sensor, one app, one cloud backend, one user.
Is the Polar H10 a medical device?
No, it is not and does not need to be.
The H10 is regarded as a gold standard for heart rate measurement in the consumer grade fitness industry. It records clinical-grade ECG measurements but Polar markets it for wellness and fitness purposes. It is CE-marked as a consumer device but has no MDR certification, because Polar does not intend it for medical use.
When a developer pairs this consumer sensor with software that has a medical purpose, the regulatory picture is more subtle than “the software becomes the medical device.” What gets placed on the market is a system: app plus sensor, evaluated together. The MDR classification attaches to that combination, and the proof of safety and performance covers the whole chain. In practice that means I am also responsible for demonstrating that the H10’s measurements are reliable enough for the intended clinical use, and that validation becomes part of the technical file.
This is not hypothetical. The Czech telemedicine startup Kardi Ai achieved MDR IIa certification for their arrhythmia detection system using the Polar H10 as the sensor component. Polar states explicitly that the certification applies only to the Kardi Ai app in combination with the H10. The sensor on its own remains a consumer device. The certified object is the system.
Is the software a medical device?
In the architecture diagram, everything inside the dashed SaMD (Software as a Medical Device) boundary, the Malik app and the signal processing backend, is the software under regulatory evaluation.
Whether software qualifies as a medical device depends entirely on what you claim it does. The framework for this determination is laid out in MDCG 2019-11, most recently revised in June 2025.
This was the part that surprised me most. I could run the exact same noise reduction, beat detection and parameter calculation algorithms and market them as a fitness feature with no clinical claim. In that case, Malik would likely not be a medical device. The code does not change. The intended purpose does.
What risk class?
Rule 11 of MDR Annex VIII is the classification rule that most standalone decision-support software falls under. It is not the only rule that can apply to software, software that drives or influences another active device inherits that device’s rule, but for an app like Malik, Rule 11 is the relevant one. It has three sub-rules, each mapping to a different risk class.
Sub-rule 11a covers software that provides information used in diagnostic or therapeutic decisions. That is Malik. The physician uses cardiac parameters to assess heart health, which is diagnostic decision support. Class IIa.
Sub-rule 11b is where it gets uncomfortable. Software where a misrepresentation could lead to serious deterioration of health or trigger a surgical intervention falls into Class IIb. When I read that, I had to ask honestly whether a miscalculated HRV parameter in Malik could lead to serious deterioration. I do not have a clean answer. That is a judgment call that gets resolved in dialogue with a notified body, not something a developer can decide unilaterally.
The tension this creates is real. Adding more specific diagnostic claims, for example automated atrial fibrillation detection, increases clinical value but may push the classification to IIb or III. AF detection is the classic case: high clinical value, but it likely triggers a notified body audit of the algorithm itself. Each feature on your roadmap that adds a clinical claim should be evaluated for its classification impact before it is built, not after.
What does Class IIa require in practice?
- a quality management system (typically built against ISO 13485, which is the harmonized standard most manufacturers use to satisfy the MDR’s QMS requirement)
- risk management per ISO 14971
- post-market surveillance of the medical device
- technical files per MDR Annex II
- audit by a notified body
- clinical evaluation
A notified body is an independent organization designated by an EU member state to assess whether your device and your processes meet MDR requirements. You cannot self-certify a Class IIa device.
The clinical evaluation requirement deserves more honesty than it usually gets in developer-facing writing. Under the old MDD, literature review and equivalence claims to existing products were a common shortcut. Under MDR, that shortcut has narrowed sharply. Article 61(5) requires contractual access to the equivalent device’s full technical documentation, which is essentially impossible to obtain from a competitor. For novel software, notified bodies increasingly expect your own clinical investigation or prospective clinical performance data. Small teams should plan for real clinical work, not assume they can lean on published literature alone.
The standard that would change my daily work most concretely is IEC 62304. It defines the software development lifecycle requirements: how you plan, document, verify and maintain your code. Every commit, every change, every test needs to fit into a traceable process. That is a different way of working than most developers are used to.
Kardi Ai went through exactly this process with their Polar H10-based system and achieved Class IIa certification. The path exists and it is navigable, though it is not short.
What does Firebase mean for health data?
The ECG recordings, heart rate values, and cardiac parameters flowing through Malik fall under GDPR Article 9 as health data, the highest protection tier in European data protection law. Processing health data is prohibited by default unless you meet one of a narrow set of exceptions.
There are two that matter for a medical app, and which one applies depends on the setting. Article 9(2)(a), explicit, informed, specific, and freely given consent, is the one developers usually reach for first. For actual clinical use, though, Article 9(2)(h), processing necessary for medical diagnosis or the provision of health care by a professional under a confidentiality obligation, is often the more robust basis. Consent can be withdrawn at any time and is hard to characterize as “freely given” in a care relationship where the patient feels they have no real alternative. Several EU data protection authorities explicitly prefer 9(2)(h) for clinical contexts. Which basis fits depends on whether your app is used inside a care pathway or outside one, and it is worth deciding deliberately rather than defaulting to consent.
Who is responsible for what?
Firebase operates under a controller-processor model. I am the data controller. Google is the data processor for the core Firebase services covered by its Data Processing and Security Terms. Firebase services hold ISO 27001, SOC 1, SOC 2, and SOC 3 certifications. (Note that Google may act as a controller for limited service-improvement and telemetry purposes, which is worth reading in the current DPA.)
On paper, this is a workable foundation. In practice, there are pitfalls that are easy to miss.
The pitfalls
Data residency is not automatic. Firestore and Cloud Storage allow you to select EU regions but this is a configuration choice, not the default. If you did not explicitly set your Firestore location to an EEA region when creating the database, your patient ECG data may be stored on US servers. Firebase Authentication has historically stored identifier data on US infrastructure without a region selector; Google has been expanding data residency options, so verify the current state against Firebase’s documentation before you rely on it.
Firebase’s own operational telemetry may also flow through US infrastructure. Disabling unnecessary services like Analytics or Crashlytics reduces your exposure.
A Data Protection Impact Assessment (DPIA) is almost certainly required. GDPR Article 35 requires one when processing health data using new technologies at scale. A mobile app that records ECG data, transmits it to a cloud backend, and processes it for clinical purposes checks all three boxes. This is a legal obligation that should be completed before processing begins, not something to draft retroactively.
Is Firebase the right choice for a medical device?
For a prototype or research tool, which is where Malik currently sits, Firebase is workable. Configure Firestore for an EU region, disable non-essential analytics services, implement an appropriate legal basis for processing, activate Google’s Data Processing Agreement in your project settings, and document everything.
For a CE-marked medical device headed for market the answer gets more complicated. A notified body examining your technical file will ask where exactly the data is stored, who has access, what happens during a Google infrastructure update, how you guarantee data integrity, and what your recovery procedures are. With Firebase, many of those answers are “Google controls that, and I rely on their terms.” That is not a disqualifier, but it creates a dependency that is harder to document and defend than infrastructure you fully control.
EU-hosted alternatives like AWS Frankfurt, Azure Germany, or specialized medical cloud providers give you direct control over the processing environment and cleaner answers for auditors. Every architecture choice you make will need to be explained and defended in your technical file. Infrastructure is not just an engineering decision.
What to check if you are already on Firebase
Regardless of whether you are prototyping or heading for production, review these now:
Check if your Firestore data location is set to an EEA region. Verify the current data residency behavior of Firebase Authentication against Google’s documentation. Review which Firebase services are enabled and disable anything non-essential. Confirm that Google’s Data Processing Agreement is activated in your Firebase project settings. Draft a DPIA for health data. Decide which Article 9(2) basis you are relying on, and implement the corresponding consent or care-context workflow.
If you are building a prototype or research tool, this is sufficient to work responsibly with health data on Firebase.
If you are heading toward a CE-marked product, start planning your migration. Evaluate EU-hosted alternatives where you control the infrastructure directly. A notified body will expect clear answers about data residency, access control, integrity, and recovery, and those answers are easier to give when you own the environment.
Who sees the results - and why it matters
In Malik’s current version, the physician sets up the Polar H10 with the patient, performs the measurement, and views the results on the same mobile device in the same session. When I designed it this way I was thinking about simplicity. It turns out that simplicity is also a regulatory advantage.
There is one intended user: the physician. One interface. One device. The physician interprets the cardiac parameters directly and in the presence of the patient. There is no unsupervised patient interaction with clinical data, no remote transmission of results, and no automated alert that a patient receives alone at home.
This matters because the user interface is not just a screen, it is a regulatory deliverable. MDR Annex I requires instructions for use that clearly state the intended purpose, the intended user, indications, contraindications, and warnings. Even for a digital-only product with no physical packaging, these must exist and be accessible to the user. The physician needs to understand what the software does, what its limitations are, and when not to rely on its output.
What changes when the product evolves?
Most features on a typical medical software roadmap look straightforward from an engineering perspective and add significant complexity from a regulatory one.
A separate physician web dashboard means a second interface that needs its own usability evaluation. Under IEC 62366-1, each user interface must be assessed for use errors that could lead to harm. Two interfaces mean two assessments.
Home use by the patient changes the intended user from a trained physician to a layperson, and the usability requirements shift substantially. What does a patient do with a cardiac parameter they don’t understand? What if an alert causes unnecessary panic? What if they ignore a finding that needed medical attention? The instructions for use must be written for a non-expert, and the risk management file must account for foreseeable misuse by someone without medical training.
Automated alerts sent to the patient without a physician in the loop raise the hardest design question of all: who is overseeing the output? If the patient sees it first, human oversight stops being something satisfied by default and becomes a core design constraint you have to engineer for explicitly.
All of these features are buildable. Each one expands the regulatory surface area of the interface and increases the need for usability work, risk analysis and documentation. It is cheaper to know this during feature planning than to discover it afterward.
A note on the EU AI Act
You may have noticed I haven’t claimed Malik is outside the scope of the EU AI Act. The honest answer is that the boundary is genuinely unsettled. The Act defines an AI system around the capacity to infer outputs from inputs with some degree of autonomy, not strictly around whether a model was trained. Recital 12 and the Commission’s February 2025 guidelines on the AI system definition carve out systems based purely on rules defined by natural persons, which is where classical signal processing plausibly sits, but the line between “deterministic math” and “inference” is drawn by interpretation rather than by a clean technical test. For a cardiac app built on filters, beat detection and parameter calculation with no trained model, a reasoned argument that the AI Act does not apply is defensible, but it is a position that needs to be documented, not a conclusion I can hand down in a blog post. I will come back to this in a dedicated post once I have worked through it more carefully.
Where Malik stands
The current single-device, physician-supervised model keeps the interface layer as simple as it can be for a medical device. The physician is the intended user, they are trained, and they see results in context. This is a starting point that makes initial certification more approachable, with room to expand the interface as long as each step is taken with the compliance implications in mind.
The full picture
| Architecture Layer | Regulatory Question | Key Frameworks | Status for Malik |
|---|---|---|---|
| Polar H10 sensor | Consumer vs. medical device? | MDR qualification | Consumer device; certification attaches to the app+sensor system |
| Malik app + signal processing backend | Is the software a medical device? What class? | MDR Rule 11, MDCG 2019-11 | Class IIa, diagnostic decision support for physician |
| Google Firebase | Health data compliance, data residency? | GDPR Art. 9, Data Processing Agreement | Needs EEA configuration, DPIA, Art. 9(2)(a) or 9(2)(h) basis |
| Signal processing pipeline | Does the EU AI Act apply? | EU AI Act Art. 3, Art. 6 | Unsettled; defensible position needed, out of scope for this post |
| Physician interface | Usability, labeling, instructions for use? | MDR Annex I, IEC 62366-1 | Single-user supervised setup, simplest regulatory case |
One app. Five architecture layers. Each one raised a different regulatory question, governed by a different framework and requiring different documentation than the one before it.
The sensor does not protect you because the MDR classification attaches to the system you place on the market. The cloud infrastructure creates data protection obligations that go well beyond a standard privacy policy. And the user interface is a regulatory deliverable that shapes your risk classification by defining who the intended user is.
None of this is meant to discourage developers from building medical software. I find these frameworks genuinely interesting, and understanding them early is what separates a certifiable product from an expensive re-architecture later.
The path requires knowing where the boundaries are before you write the code, not after. If this walkthrough helps one developer ask the right questions earlier, it was worth writing.